I am not a developer, but I stumbled upon this just a couple of days ago
in the OpenWRT forums:
https://forum.openwrt.org/viewtopic.php?id=53215
In short, MediaTek is looking for volunteers to help get their drivers
mainlined in the upstream kernels; this includes drivers for their USB
and PCI wifi hardware under both the MediaTek and Ralink brands. They
are willing to provide "chip info, reference driver, dev board, etc" and
even some degree of sponsorship, apparently subject to their
management's approval.
In exchange, they require that the volunteers fulfill the following
requirements:
- skilled in wifi driver development
- provide a suitable schedule / roadmap
- be able to get the code mainlined in the official linux kernel.
Those who are keen on taking up the task can contact the original poster
at hua.shao[AT]mediatek.com
**Disclaimer: I am in no way related to, or under the employ of MediaTek
or Ralink. I am only posting this here because I have a handful of MT
wifi chips which I hope to see being supported in the upstream kernel so
that I can actually use them under Linux,
On 28-10-14 14:46, John W. Linville wrote:
> On Mon, Oct 27, 2014 at 07:19:32PM +0100, Oleksij Rempel wrote:
>> Am 27.10.2014 um 16:20 schrieb John W. Linville:
>>> On Mon, Oct 27, 2014 at 11:02:00AM +0800, Etna wrote:
>>>> I am not a developer, but I stumbled upon this just a couple of days ago in
>>>> the OpenWRT forums:
>>>>
>>>> https://forum.openwrt.org/viewtopic.php?id=53215
>>>>
>>>> In short, MediaTek is looking for volunteers to help get their drivers
>>>> mainlined in the upstream kernels; this includes drivers for their USB and
>>>> PCI wifi hardware under both the MediaTek and Ralink brands. They are
>>>> willing to provide "chip info, reference driver, dev board, etc" and even
>>>> some degree of sponsorship, apparently subject to their management's
>>>> approval.
>>>>
>>>> In exchange, they require that the volunteers fulfill the following
>>>> requirements:
>>>> - skilled in wifi driver development
>>>> - provide a suitable schedule / roadmap
>>>> - be able to get the code mainlined in the official linux kernel.
>>>>
>>>> Those who are keen on taking up the task can contact the original poster at
>>>> hua.shao[AT]mediatek.com
>>>>
>>>> **Disclaimer: I am in no way related to, or under the employ of MediaTek or
>>>> Ralink. I am only posting this here because I have a handful of MT wifi
>>>> chips which I hope to see being supported in the upstream kernel so that I
>>>> can actually use them under Linux,
>>>
>>> Well, this is mostly good to see. I hope there is someone that wants
>>> to take-up the cause!
>>>
>>> If someone is interested in working-on the project above but for
>>> whatever reason doesn't want to deal with MediaTek on their own,
>>> feel free to contact me. I'll try to be helpful however I can.
>>>
>>> Thanks,
>>>
>>> John
>>
>>
>> Sounds interesting and as perfect possibility to learn. I would like to
>> do it, but i have two concerns:
>> - i never wrote an wifi driver from scratch.
>
> FWIW, I think MediaTek already has some form of drivers. With that
> said, it might be easier to write new mac80211-based ones than to
> adapt the existing ones.
>
>> - i'm seeking for a job. It means if i will find one, this project will
>> get lower priority.
>
> No one can ask anything more.
>
>> If nobody has problems with this two points, then i'm ok.
>
> It sounds like we have a volunteer! Let me know if you need any
> specific help or guidance.
During LPC Felix mentioned GPLed mediatek driver for their 11ac
chipset(s?). It is on github:
https://github.com/openwrt/mtk-wifi-gpl
Regards,
Arend
On Mon, Oct 27, 2014 at 07:19:32PM +0100, Oleksij Rempel wrote:
> Am 27.10.2014 um 16:20 schrieb John W. Linville:
> > On Mon, Oct 27, 2014 at 11:02:00AM +0800, Etna wrote:
> >> I am not a developer, but I stumbled upon this just a couple of days ago in
> >> the OpenWRT forums:
> >>
> >> https://forum.openwrt.org/viewtopic.php?id=53215
> >>
> >> In short, MediaTek is looking for volunteers to help get their drivers
> >> mainlined in the upstream kernels; this includes drivers for their USB and
> >> PCI wifi hardware under both the MediaTek and Ralink brands. They are
> >> willing to provide "chip info, reference driver, dev board, etc" and even
> >> some degree of sponsorship, apparently subject to their management's
> >> approval.
> >>
> >> In exchange, they require that the volunteers fulfill the following
> >> requirements:
> >> - skilled in wifi driver development
> >> - provide a suitable schedule / roadmap
> >> - be able to get the code mainlined in the official linux kernel.
> >>
> >> Those who are keen on taking up the task can contact the original poster at
> >> hua.shao[AT]mediatek.com
> >>
> >> **Disclaimer: I am in no way related to, or under the employ of MediaTek or
> >> Ralink. I am only posting this here because I have a handful of MT wifi
> >> chips which I hope to see being supported in the upstream kernel so that I
> >> can actually use them under Linux,
> >
> > Well, this is mostly good to see. I hope there is someone that wants
> > to take-up the cause!
> >
> > If someone is interested in working-on the project above but for
> > whatever reason doesn't want to deal with MediaTek on their own,
> > feel free to contact me. I'll try to be helpful however I can.
> >
> > Thanks,
> >
> > John
>
>
> Sounds interesting and as perfect possibility to learn. I would like to
> do it, but i have two concerns:
> - i never wrote an wifi driver from scratch.
FWIW, I think MediaTek already has some form of drivers. With that
said, it might be easier to write new mac80211-based ones than to
adapt the existing ones.
> - i'm seeking for a job. It means if i will find one, this project will
> get lower priority.
No one can ask anything more.
> If nobody has problems with this two points, then i'm ok.
It sounds like we have a volunteer! Let me know if you need any
specific help or guidance.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Mon, Oct 27, 2014 at 11:02:00AM +0800, Etna wrote:
> I am not a developer, but I stumbled upon this just a couple of days ago in
> the OpenWRT forums:
>
> https://forum.openwrt.org/viewtopic.php?id=53215
>
> In short, MediaTek is looking for volunteers to help get their drivers
> mainlined in the upstream kernels; this includes drivers for their USB and
> PCI wifi hardware under both the MediaTek and Ralink brands. They are
> willing to provide "chip info, reference driver, dev board, etc" and even
> some degree of sponsorship, apparently subject to their management's
> approval.
>
> In exchange, they require that the volunteers fulfill the following
> requirements:
> - skilled in wifi driver development
> - provide a suitable schedule / roadmap
> - be able to get the code mainlined in the official linux kernel.
>
> Those who are keen on taking up the task can contact the original poster at
> hua.shao[AT]mediatek.com
>
> **Disclaimer: I am in no way related to, or under the employ of MediaTek or
> Ralink. I am only posting this here because I have a handful of MT wifi
> chips which I hope to see being supported in the upstream kernel so that I
> can actually use them under Linux,
Well, this is mostly good to see. I hope there is someone that wants
to take-up the cause!
If someone is interested in working-on the project above but for
whatever reason doesn't want to deal with MediaTek on their own,
feel free to contact me. I'll try to be helpful however I can.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
Am 27.10.2014 um 16:20 schrieb John W. Linville:
> On Mon, Oct 27, 2014 at 11:02:00AM +0800, Etna wrote:
>> I am not a developer, but I stumbled upon this just a couple of days ago in
>> the OpenWRT forums:
>>
>> https://forum.openwrt.org/viewtopic.php?id=53215
>>
>> In short, MediaTek is looking for volunteers to help get their drivers
>> mainlined in the upstream kernels; this includes drivers for their USB and
>> PCI wifi hardware under both the MediaTek and Ralink brands. They are
>> willing to provide "chip info, reference driver, dev board, etc" and even
>> some degree of sponsorship, apparently subject to their management's
>> approval.
>>
>> In exchange, they require that the volunteers fulfill the following
>> requirements:
>> - skilled in wifi driver development
>> - provide a suitable schedule / roadmap
>> - be able to get the code mainlined in the official linux kernel.
>>
>> Those who are keen on taking up the task can contact the original poster at
>> hua.shao[AT]mediatek.com
>>
>> **Disclaimer: I am in no way related to, or under the employ of MediaTek or
>> Ralink. I am only posting this here because I have a handful of MT wifi
>> chips which I hope to see being supported in the upstream kernel so that I
>> can actually use them under Linux,
>
> Well, this is mostly good to see. I hope there is someone that wants
> to take-up the cause!
>
> If someone is interested in working-on the project above but for
> whatever reason doesn't want to deal with MediaTek on their own,
> feel free to contact me. I'll try to be helpful however I can.
>
> Thanks,
>
> John
Sounds interesting and as perfect possibility to learn. I would like to
do it, but i have two concerns:
- i never wrote an wifi driver from scratch.
- i'm seeking for a job. It means if i will find one, this project will
get lower priority.
If nobody has problems with this two points, then i'm ok.
--
Regards,
Oleksij
Am 28.10.2014 um 15:06 schrieb Arend van Spriel:
> On 28-10-14 14:46, John W. Linville wrote:
>> On Mon, Oct 27, 2014 at 07:19:32PM +0100, Oleksij Rempel wrote:
>>> Am 27.10.2014 um 16:20 schrieb John W. Linville:
>>>> On Mon, Oct 27, 2014 at 11:02:00AM +0800, Etna wrote:
>>>>> I am not a developer, but I stumbled upon this just a couple of days ago in
>>>>> the OpenWRT forums:
>>>>>
>>>>> https://forum.openwrt.org/viewtopic.php?id=53215
>>>>>
>>>>> In short, MediaTek is looking for volunteers to help get their drivers
>>>>> mainlined in the upstream kernels; this includes drivers for their USB and
>>>>> PCI wifi hardware under both the MediaTek and Ralink brands. They are
>>>>> willing to provide "chip info, reference driver, dev board, etc" and even
>>>>> some degree of sponsorship, apparently subject to their management's
>>>>> approval.
>>>>>
>>>>> In exchange, they require that the volunteers fulfill the following
>>>>> requirements:
>>>>> - skilled in wifi driver development
>>>>> - provide a suitable schedule / roadmap
>>>>> - be able to get the code mainlined in the official linux kernel.
>>>>>
>>>>> Those who are keen on taking up the task can contact the original poster at
>>>>> hua.shao[AT]mediatek.com
>>>>>
>>>>> **Disclaimer: I am in no way related to, or under the employ of MediaTek or
>>>>> Ralink. I am only posting this here because I have a handful of MT wifi
>>>>> chips which I hope to see being supported in the upstream kernel so that I
>>>>> can actually use them under Linux,
>>>>
>>>> Well, this is mostly good to see. I hope there is someone that wants
>>>> to take-up the cause!
>>>>
>>>> If someone is interested in working-on the project above but for
>>>> whatever reason doesn't want to deal with MediaTek on their own,
>>>> feel free to contact me. I'll try to be helpful however I can.
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>
>>>
>>> Sounds interesting and as perfect possibility to learn. I would like to
>>> do it, but i have two concerns:
>>> - i never wrote an wifi driver from scratch.
>>
>> FWIW, I think MediaTek already has some form of drivers. With that
>> said, it might be easier to write new mac80211-based ones than to
>> adapt the existing ones.
>>
>>> - i'm seeking for a job. It means if i will find one, this project will
>>> get lower priority.
>>
>> No one can ask anything more.
>>
>>> If nobody has problems with this two points, then i'm ok.
>>
>> It sounds like we have a volunteer! Let me know if you need any
>> specific help or guidance.
>
> During LPC Felix mentioned GPLed mediatek driver for their 11ac
> chipset(s?). It is on github:
>
> https://github.com/openwrt/mtk-wifi-gpl
What is the next step?
--
Regards,
Oleksij
Hi Hackers,
Just a quick heads up:
I'm working on a new driver for MT7662E/MT7612E, written from scratch.
It is already able to bring up the firmware, init the MAC and do basic
TX/RX DMA communication with the firmware.
I've decided to not integrate it with rt2x00, because I want to avoid
dealing with the the unnecessarily convoluted abstractions and legacy
code in there. I believe the result will be simpler and easier to
maintain as a new driver.
As soon as the basic structure is in place, I will put it on a public
git tree and post a link here.
- Felix
Am 29.10.2014 um 11:17 schrieb Felix Fietkau:
> Hi Hackers,
>
> Just a quick heads up:
> I'm working on a new driver for MT7662E/MT7612E, written from scratch.
> It is already able to bring up the firmware, init the MAC and do basic
> TX/RX DMA communication with the firmware.
> I've decided to not integrate it with rt2x00, because I want to avoid
> dealing with the the unnecessarily convoluted abstractions and legacy
> code in there. I believe the result will be simpler and easier to
> maintain as a new driver.
> As soon as the basic structure is in place, I will put it on a public
> git tree and post a link here.
>
> - Felix
Which chip would you suggest for starting?
--
Regards,
Oleksij
On 11/12/2014 03:04 PM, Felix Fietkau wrote:
> The chips I'm working with are both MT7662 and MT7612. My driver already
> works as a simple AP or station in 802.11n mode with some limited
> aggregation support. I'm getting around 45-50 Mbit/s TCP throughput on
> HT20 with iperf. I will post code soon, stay tuned!
Felix,
If your driver will work with the MT7630, I will be happy to test it when posted.
Larry
On 2014-11-11 12:55, Oleksij Rempel wrote:
> Am 29.10.2014 um 11:17 schrieb Felix Fietkau:
>> Hi Hackers,
>>
>> Just a quick heads up:
>> I'm working on a new driver for MT7662E/MT7612E, written from scratch.
>> It is already able to bring up the firmware, init the MAC and do basic
>> TX/RX DMA communication with the firmware.
>> I've decided to not integrate it with rt2x00, because I want to avoid
>> dealing with the the unnecessarily convoluted abstractions and legacy
>> code in there. I believe the result will be simpler and easier to
>> maintain as a new driver.
>> As soon as the basic structure is in place, I will put it on a public
>> git tree and post a link here.
>>
>> - Felix
>
> Which chip would you suggest for starting?
The chips I'm working with are both MT7662 and MT7612. My driver already
works as a simple AP or station in 802.11n mode with some limited
aggregation support. I'm getting around 45-50 Mbit/s TCP throughput on
HT20 with iperf. I will post code soon, stay tuned!
- Felix
On 25 February 2015 at 10:33, Jakub Kiciński <[email protected]> wrote:
> On Wed, 25 Feb 2015 01:49:02 +0100, Sergei Antonov wrote:
>> On 6 February 2015 at 18:29, Jakub Kiciński <[email protected]> wrote:
>> > Hello everyone!
>> >
>> > I put together a mac80211 driver for Mediatek MT7601U. It's partially
>> > based on Felix's mt76, but I'm not sure if it will make sense to merge
>> > the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
>> > and mt76 now only supports the latest and greatest ac APs.
>> >
>> > I'm testing STA functionality right now and it seems to be working ok.
>> > The code is very much a work in progress but if anyone is interested you
>> > can get it here:
>> >
>> > https://github.com/kuba-moo/mt7601u
>>
>> Hi, Jakub! I happen to have 7601 dongle, so I tested you driver. There
>> were some problems, see "dmesg | grep mt7" output:
>
> OK, let me start with a set of basic questions.
>
> What device do you have (brand + model or picture on ebay please;))?
http://www.ebay.de/itm/221662285066
> What's the device ID?
Bus 003 Device 006: ID 148f:7601 Ralink Technology, Corp.
> What platform are you working on?
Linux linux64 3.19.0-05375-gd347efe #17 SMP Sun Feb 15 16:38:24 CET
2015 x86_64 GNU/Linux
> Is this error persistent or a one-time thing?
It is persistent.
> Does the vendor driver work with your device?
Yes. I took DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2, applied
rt2870-mt7601Usta-kuid_t-kgid_t.patch (can bee easily googled, it is
needed to compile for recent kernels) and the device was able to
connect to my AP. The only suspicious thing was that the output to the
console was very verbose. I didn't take time to see if it was just
trace or a sign of a problem. I can repeat this and look more closely.
I can also look deeper into the critical moment between ch1 and ch2
you mention.
> Can you also show content of
> /sys/kernel/debug/ieee80211/phy*/mt76/eeprom_param
> ?
/sys/kernel/debug is empty on my machine.
>> [ 3.174960] mt7601u 3-5:1.0: ASIC revision: 76010001 MAC revision: 76010500
>> [ 3.181705] mt7601u 3-5:1.0: Firmware Version: 0.1.00 Build: 7640
>> Build time: 201302052146____
>> [ 3.573018] mt7601u 3-5:1.0: Warning: unsupported EEPROM version 0d
>> [ 3.574853] mt7601u 3-5:1.0: EEPROM ver:0d fae:00
>> [ 3.816647] usbcore: registered new interface driver mt7601u
>> [ 10.461251] mt7601u_add_interface idx:0
>> [ 10.463193] mt7601u_bss_info_changed 0000000e
>> [ 10.469748] mt7601u_conf_tx 03 <- 0000
>> [ 10.473738] mt7601u_conf_tx 02 <- 0001
>> [ 10.477856] mt7601u_conf_tx 01 <- 0002
>> [ 10.481980] mt7601u_conf_tx 00 <- 0003
>> [ 10.486849] mt7601u_bss_info_changed 00002000
>> [ 10.488671] mt7601u_config ffffffff ch:1
>> [ 10.504305] mt76_configure_filter changed:0 total:80000000
>> [ 10.508327] mt76_configure_filter changed:0 total:80000000
>> [ 10.550671] mt76_configure_filter changed:0 total:80000000
>> [ 10.616870] mt7601u_config 00000100 ch:1
>> [ 10.619449] mt76_configure_filter changed:10 total:80000010
>> [ 10.621541] mt7601u_config 00000040 ch:1
>> [ 10.692407] mt7601u_config 00000040 ch:2
>> [ 10.992113] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 11.291819] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 11.591524] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 11.891230] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.190936] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.192790] mt7601u 3-5:1.0: Error: mt7601u_mcu_wait_resp timed out
>
> Firmware clearly died somewhere between switch to channel 1 and to
> channel 2... I made some changes to the FW loading routine, I will try
> to check the traces later today to confirm that I didn't break anything.
>
>> Is it because of "unsupported EEPROM version 0d"?
>
> Don't think so. It's just for compatibility with vendor driver,
> they warn too. All new devices have EEPROM ver == 0x0d though. I plan
> to ask MediaTek about it in a week or two (Chinese New Year) and
> remove the warning.
I did 'git pull' now, recompiled the driver, rebooted. Here is the
relevant piece of dmesg output:
[ 10.931816] mt7601u_add_interface idx:0
[ 10.933012] mt7601u_bss_info_changed 0000000e
[ 10.934126] [prot transition] mode:0000 bgprot:0 non-gf:0 non-ht:0
[ 10.937859] mt7601u_conf_tx 03 <- 0000
[ 10.942100] mt7601u_conf_tx 02 <- 0001
[ 10.945173] mt7601u_conf_tx 01 <- 0002
[ 10.949340] mt7601u_conf_tx 00 <- 0003
[ 10.952607] mt7601u_bss_info_changed 00002000
[ 10.953611] mt7601u_config ffffffff ch:1
[ 10.967710] mt76_configure_filter changed:0 total:80000000
[ 10.967725] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 10.970070] mt76_configure_filter changed:0 total:80000000
[ 10.980384] cfg80211: Calling CRDA to update world regulatory domain
[ 11.012397] mt76_configure_filter changed:0 total:80000000
[ 11.080505] mt7601u_config 00000100 ch:1
[ 11.082447] mt76_configure_filter changed:10 total:80000010
[ 11.083827] mt7601u_config 00000040 ch:1
[ 11.128025] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.2
domain=0x0007 address=0x00000000c99a6000 flags=0x0010]
[ 11.129175] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.2
domain=0x0007 address=0x00000000c99a6040 flags=0x0010]
[ 11.155951] mt7601u_config 00000040 ch:2
[ 11.455658] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 11.755362] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 12.055067] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 12.354758] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 12.654476] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 12.655597] mt7601u 3-5:1.0: Error: mt7601u_mcu_wait_resp timed out
[ 12.656593] mt7601u_config 00000040 ch:3
[ 13.154228] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 13.155318] mt7601u_config 00000040 ch:4
[ 13.653709] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
Note the two messages about IO_PAGE_FAULT in device 00:12.2. This
device is a USB controller:
[ 2.181191] ehci-pci 0000:00:12.2: EHCI Host Controller
But this controller is not guilty :), it works fine with other USB devices.
Don't know if it matters, there are two wlan devices in my computer:
wlan0 - ath9k, my main PCI WiFi card.
wlan1 - mt7601u, the device I'm testing.
On Thu, 26 Feb 2015 00:58:59 +0100, Sergei Antonov wrote:
> On 25 February 2015 at 10:33, Jakub Kiciński <[email protected]> wrote:
> > On Wed, 25 Feb 2015 01:49:02 +0100, Sergei Antonov wrote:
> >> On 6 February 2015 at 18:29, Jakub Kiciński <[email protected]> wrote:
> >> > Hello everyone!
> >> >
> >> > I put together a mac80211 driver for Mediatek MT7601U. It's partially
> >> > based on Felix's mt76, but I'm not sure if it will make sense to merge
> >> > the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
> >> > and mt76 now only supports the latest and greatest ac APs.
> >> >
> >> > I'm testing STA functionality right now and it seems to be working ok.
> >> > The code is very much a work in progress but if anyone is interested you
> >> > can get it here:
> >> >
> >> > https://github.com/kuba-moo/mt7601u
> >>
> >> Hi, Jakub! I happen to have 7601 dongle, so I tested you driver. There
> >> were some problems, see "dmesg | grep mt7" output:
> >
> > OK, let me start with a set of basic questions.
> >
> > What device do you have (brand + model or picture on ebay please;))?
>
> http://www.ebay.de/itm/221662285066
>
> > What's the device ID?
>
> Bus 003 Device 006: ID 148f:7601 Ralink Technology, Corp.
>
> > What platform are you working on?
>
> Linux linux64 3.19.0-05375-gd347efe #17 SMP Sun Feb 15 16:38:24 CET
> 2015 x86_64 GNU/Linux
>
> > Is this error persistent or a one-time thing?
>
> It is persistent.
>
> > Does the vendor driver work with your device?
Thanks for the information, I have exactly that device here and it
works fine, including on x86_64. You can try going back to commits
19cdcb583f18 ("don't allow AMPDUs with probe rates") and
e9d7b296fea0 ("mitigate DMA problems on very poor link") from my repo.
Maybe I did screw something up when cleaning up the MCU code.
> Yes. I took DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2, applied
> rt2870-mt7601Usta-kuid_t-kgid_t.patch (can bee easily googled, it is
> needed to compile for recent kernels) and the device was able to
> connect to my AP. The only suspicious thing was that the output to the
> console was very verbose. I didn't take time to see if it was just
> trace or a sign of a problem. I can repeat this and look more closely.
> I can also look deeper into the critical moment between ch1 and ch2
> you mention.
I would appreciate if you could set RTDebugLevel to RT_DEBUG_LOUD in
src/os/linux/rt_linux.c of the vendor driver (line 54) and get a full
log of it associating to an AP. Please post it somewhere like
pastebin.com or attach to an email. Let me know if you need help.
> > Can you also show content of
> > /sys/kernel/debug/ieee80211/phy*/mt76/eeprom_param
> > ?
>
> /sys/kernel/debug is empty on my machine.
You can mount it by saying (as root):
# mount -t debugfs /sys/kernel/debug/
> I did 'git pull' now, recompiled the driver, rebooted. Here is the
> relevant piece of dmesg output:
>
> [ 10.931816] mt7601u_add_interface idx:0
> [ 10.933012] mt7601u_bss_info_changed 0000000e
> [ 10.934126] [prot transition] mode:0000 bgprot:0 non-gf:0 non-ht:0
> [ 10.937859] mt7601u_conf_tx 03 <- 0000
> [ 10.942100] mt7601u_conf_tx 02 <- 0001
> [ 10.945173] mt7601u_conf_tx 01 <- 0002
> [ 10.949340] mt7601u_conf_tx 00 <- 0003
> [ 10.952607] mt7601u_bss_info_changed 00002000
> [ 10.953611] mt7601u_config ffffffff ch:1
> [ 10.967710] mt76_configure_filter changed:0 total:80000000
> [ 10.967725] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
> [ 10.970070] mt76_configure_filter changed:0 total:80000000
> [ 10.980384] cfg80211: Calling CRDA to update world regulatory domain
> [ 11.012397] mt76_configure_filter changed:0 total:80000000
> [ 11.080505] mt7601u_config 00000100 ch:1
> [ 11.082447] mt76_configure_filter changed:10 total:80000010
> [ 11.083827] mt7601u_config 00000040 ch:1
> [ 11.128025] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.2
> domain=0x0007 address=0x00000000c99a6000 flags=0x0010]
> [ 11.129175] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.2
> domain=0x0007 address=0x00000000c99a6040 flags=0x0010]
> [ 11.155951] mt7601u_config 00000040 ch:2
> [ 11.455658] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 11.755362] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 12.055067] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 12.354758] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 12.654476] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 12.655597] mt7601u 3-5:1.0: Error: mt7601u_mcu_wait_resp timed out
> [ 12.656593] mt7601u_config 00000040 ch:3
> [ 13.154228] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
> [ 13.155318] mt7601u_config 00000040 ch:4
> [ 13.653709] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
>
> Note the two messages about IO_PAGE_FAULT in device 00:12.2. This
> device is a USB controller:
> [ 2.181191] ehci-pci 0000:00:12.2: EHCI Host Controller
> But this controller is not guilty :), it works fine with other USB devices.
Perhaps I have some errors in DMA programming. Can you disable all
automatic WiFi things so they don't mess with the device (NetworkManger
etc.), make sure the interface is not brought up, and then try (as
root):
iw dev wlan1 interface add monT type monitor
ifconfig monT up
iw dev monT set channel 2
iw dev monT set channel 1
iw dev monT set channel 2 HT40+
iw dev monT set channel 10 HT40-
(I assume wlan1 is the mt7601u.) See if after any of these commands the
errors will appear.
On 06.02.2015 18:29, Jakub Kiciński wrote:
> Hello everyone!
>
> I put together a mac80211 driver for Mediatek MT7601U. It's partially
> based on Felix's mt76, but I'm not sure if it will make sense to merge
> the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
> and mt76 now only supports the latest and greatest ac APs.
>
> I'm testing STA functionality right now and it seems to be working ok.
> The code is very much a work in progress but if anyone is interested you
> can get it here:
>
> https://github.com/kuba-moo/mt7601u
>
> Cheers,
> kuba
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
How many mt7601u module editions exists there? :)
- vendor's
- vendor's patched (how many forms of the same)
- your reinvented
- the one on which pán Gruszka allegedly works?
- any more?
On 26 February 2015 at 17:05, Jakub Kiciński <[email protected]> wrote:
> On Thu, 26 Feb 2015 00:58:59 +0100, Sergei Antonov wrote:
>> On 25 February 2015 at 10:33, Jakub Kiciński <[email protected]> wrote:
>> > On Wed, 25 Feb 2015 01:49:02 +0100, Sergei Antonov wrote:
>> >> On 6 February 2015 at 18:29, Jakub Kiciński <[email protected]> wrote:
>> >> > Hello everyone!
>> >> >
>> >> > I put together a mac80211 driver for Mediatek MT7601U. It's partially
>> >> > based on Felix's mt76, but I'm not sure if it will make sense to merge
>> >> > the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
>> >> > and mt76 now only supports the latest and greatest ac APs.
>> >> >
>> >> > I'm testing STA functionality right now and it seems to be working ok.
>> >> > The code is very much a work in progress but if anyone is interested you
>> >> > can get it here:
>> >> >
>> >> > https://github.com/kuba-moo/mt7601u
>> >>
>> >> Hi, Jakub! I happen to have 7601 dongle, so I tested you driver. There
>> >> were some problems, see "dmesg | grep mt7" output:
>> >
>> > OK, let me start with a set of basic questions.
>> >
>> > What device do you have (brand + model or picture on ebay please;))?
>>
>> http://www.ebay.de/itm/221662285066
>>
>> > What's the device ID?
>>
>> Bus 003 Device 006: ID 148f:7601 Ralink Technology, Corp.
>>
>> > What platform are you working on?
>>
>> Linux linux64 3.19.0-05375-gd347efe #17 SMP Sun Feb 15 16:38:24 CET
>> 2015 x86_64 GNU/Linux
>>
>> > Is this error persistent or a one-time thing?
>>
>> It is persistent.
>>
>> > Does the vendor driver work with your device?
>
> Thanks for the information, I have exactly that device here and it
> works fine, including on x86_64. You can try going back to commits
> 19cdcb583f18 ("don't allow AMPDUs with probe rates") and
> e9d7b296fea0 ("mitigate DMA problems on very poor link") from my repo.
> Maybe I did screw something up when cleaning up the MCU code.
>
>> Yes. I took DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2, applied
>> rt2870-mt7601Usta-kuid_t-kgid_t.patch (can bee easily googled, it is
>> needed to compile for recent kernels) and the device was able to
>> connect to my AP. The only suspicious thing was that the output to the
>> console was very verbose. I didn't take time to see if it was just
>> trace or a sign of a problem. I can repeat this and look more closely.
>> I can also look deeper into the critical moment between ch1 and ch2
>> you mention.
>
> I would appreciate if you could set RTDebugLevel to RT_DEBUG_LOUD in
> src/os/linux/rt_linux.c of the vendor driver (line 54) and get a full
> log of it associating to an AP. Please post it somewhere like
> pastebin.com or attach to an email. Let me know if you need help.
>
>> > Can you also show content of
>> > /sys/kernel/debug/ieee80211/phy*/mt76/eeprom_param
>> > ?
>>
>> /sys/kernel/debug is empty on my machine.
>
> You can mount it by saying (as root):
> # mount -t debugfs /sys/kernel/debug/
>
>> I did 'git pull' now, recompiled the driver, rebooted. Here is the
>> relevant piece of dmesg output:
>>
>> [ 10.931816] mt7601u_add_interface idx:0
>> [ 10.933012] mt7601u_bss_info_changed 0000000e
>> [ 10.934126] [prot transition] mode:0000 bgprot:0 non-gf:0 non-ht:0
>> [ 10.937859] mt7601u_conf_tx 03 <- 0000
>> [ 10.942100] mt7601u_conf_tx 02 <- 0001
>> [ 10.945173] mt7601u_conf_tx 01 <- 0002
>> [ 10.949340] mt7601u_conf_tx 00 <- 0003
>> [ 10.952607] mt7601u_bss_info_changed 00002000
>> [ 10.953611] mt7601u_config ffffffff ch:1
>> [ 10.967710] mt76_configure_filter changed:0 total:80000000
>> [ 10.967725] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
>> [ 10.970070] mt76_configure_filter changed:0 total:80000000
>> [ 10.980384] cfg80211: Calling CRDA to update world regulatory domain
>> [ 11.012397] mt76_configure_filter changed:0 total:80000000
>> [ 11.080505] mt7601u_config 00000100 ch:1
>> [ 11.082447] mt76_configure_filter changed:10 total:80000010
>> [ 11.083827] mt7601u_config 00000040 ch:1
>> [ 11.128025] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.2
>> domain=0x0007 address=0x00000000c99a6000 flags=0x0010]
>> [ 11.129175] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.2
>> domain=0x0007 address=0x00000000c99a6040 flags=0x0010]
>> [ 11.155951] mt7601u_config 00000040 ch:2
>> [ 11.455658] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 11.755362] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.055067] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.354758] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.654476] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.655597] mt7601u 3-5:1.0: Error: mt7601u_mcu_wait_resp timed out
>> [ 12.656593] mt7601u_config 00000040 ch:3
>> [ 13.154228] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
>> [ 13.155318] mt7601u_config 00000040 ch:4
>> [ 13.653709] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
>>
>> Note the two messages about IO_PAGE_FAULT in device 00:12.2. This
>> device is a USB controller:
>> [ 2.181191] ehci-pci 0000:00:12.2: EHCI Host Controller
>> But this controller is not guilty :), it works fine with other USB devices.
>
> Perhaps I have some errors in DMA programming. Can you disable all
> automatic WiFi things so they don't mess with the device (NetworkManger
> etc.), make sure the interface is not brought up, and then try (as
> root):
>
> iw dev wlan1 interface add monT type monitor
> ifconfig monT up
> iw dev monT set channel 2
> iw dev monT set channel 1
> iw dev monT set channel 2 HT40+
> iw dev monT set channel 10 HT40-
>
> (I assume wlan1 is the mt7601u.) See if after any of these commands the
> errors will appear.
Jakub, I'll do all of it, but for now just one quick question: what
firmware binary blob should I use with your driver? Maybe I just took
a wrong firmware... You can send me yours.
On Wed, 25 Feb 2015 01:49:02 +0100, Sergei Antonov wrote:
> On 6 February 2015 at 18:29, Jakub Kiciński <[email protected]> wrote:
> > Hello everyone!
> >
> > I put together a mac80211 driver for Mediatek MT7601U. It's partially
> > based on Felix's mt76, but I'm not sure if it will make sense to merge
> > the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
> > and mt76 now only supports the latest and greatest ac APs.
> >
> > I'm testing STA functionality right now and it seems to be working ok.
> > The code is very much a work in progress but if anyone is interested you
> > can get it here:
> >
> > https://github.com/kuba-moo/mt7601u
>
> Hi, Jakub! I happen to have 7601 dongle, so I tested you driver. There
> were some problems, see "dmesg | grep mt7" output:
OK, let me start with a set of basic questions.
What device do you have (brand + model or picture on ebay please;))?
What's the device ID?
What platform are you working on?
Is this error persistent or a one-time thing?
Does the vendor driver work with your device?
Can you also show content of
/sys/kernel/debug/ieee80211/phy*/mt76/eeprom_param
?
> [ 3.174960] mt7601u 3-5:1.0: ASIC revision: 76010001 MAC revision: 76010500
> [ 3.181705] mt7601u 3-5:1.0: Firmware Version: 0.1.00 Build: 7640
> Build time: 201302052146____
> [ 3.573018] mt7601u 3-5:1.0: Warning: unsupported EEPROM version 0d
> [ 3.574853] mt7601u 3-5:1.0: EEPROM ver:0d fae:00
> [ 3.816647] usbcore: registered new interface driver mt7601u
> [ 10.461251] mt7601u_add_interface idx:0
> [ 10.463193] mt7601u_bss_info_changed 0000000e
> [ 10.469748] mt7601u_conf_tx 03 <- 0000
> [ 10.473738] mt7601u_conf_tx 02 <- 0001
> [ 10.477856] mt7601u_conf_tx 01 <- 0002
> [ 10.481980] mt7601u_conf_tx 00 <- 0003
> [ 10.486849] mt7601u_bss_info_changed 00002000
> [ 10.488671] mt7601u_config ffffffff ch:1
> [ 10.504305] mt76_configure_filter changed:0 total:80000000
> [ 10.508327] mt76_configure_filter changed:0 total:80000000
> [ 10.550671] mt76_configure_filter changed:0 total:80000000
> [ 10.616870] mt7601u_config 00000100 ch:1
> [ 10.619449] mt76_configure_filter changed:10 total:80000010
> [ 10.621541] mt7601u_config 00000040 ch:1
> [ 10.692407] mt7601u_config 00000040 ch:2
> [ 10.992113] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 11.291819] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 11.591524] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 11.891230] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 12.190936] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
> [ 12.192790] mt7601u 3-5:1.0: Error: mt7601u_mcu_wait_resp timed out
Firmware clearly died somewhere between switch to channel 1 and to
channel 2... I made some changes to the FW loading routine, I will try
to check the traces later today to confirm that I didn't break anything.
> Is it because of "unsupported EEPROM version 0d"?
Don't think so. It's just for compatibility with vendor driver,
they warn too. All new devices have EEPROM ver == 0x0d though. I plan
to ask MediaTek about it in a week or two (Chinese New Year) and
remove the warning.
On Thu, 26 Feb 2015 14:56:46 +0100, poma wrote:
> On 06.02.2015 18:29, Jakub Kiciński wrote:
> > Hello everyone!
> >
> > I put together a mac80211 driver for Mediatek MT7601U. It's partially
> > based on Felix's mt76, but I'm not sure if it will make sense to merge
> > the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
> > and mt76 now only supports the latest and greatest ac APs.
> >
> > I'm testing STA functionality right now and it seems to be working ok.
> > The code is very much a work in progress but if anyone is interested you
> > can get it here:
> >
> > https://github.com/kuba-moo/mt7601u
> >
> > Cheers,
> > kuba
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> How many mt7601u module editions exists there? :)
> - vendor's
> - vendor's patched (how many forms of the same)
> - your reinvented
> - the one on which pán Gruszka allegedly works?
> - any more?
I assume you mean to ask how many different drivers are there.
There is the vendor 3.0.0.4 STA driver which only has client
functionality. Many patched versions of this driver exist on GitHub.
There is also an older version of vendor driver which can work as an
AP. My mac80211-based driver is the only non-vendor version I'm aware
of.
On Thu, 26 Feb 2015 19:50:04 +0100, Sergei Antonov wrote:
> Jakub, I'll do all of it, but for now just one quick question: what
> firmware binary blob should I use with your driver? Maybe I just took
> a wrong firmware... You can send me yours.
I have the one from vendor package. The MD5 sum is
# md5sum /usr/lib/firmware/mt7601u.bin
696cedb8e76ecc0cda9f9b0d3972c64d /usr/lib/firmware/mt7601u.bin
Hello everyone!
I put together a mac80211 driver for Mediatek MT7601U. It's partially
based on Felix's mt76, but I'm not sure if it will make sense to merge
the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
and mt76 now only supports the latest and greatest ac APs.
I'm testing STA functionality right now and it seems to be working ok.
The code is very much a work in progress but if anyone is interested you
can get it here:
https://github.com/kuba-moo/mt7601u
Cheers,
kuba
On 6 February 2015 at 18:29, Jakub Kiciński <[email protected]> wrote:
> Hello everyone!
>
> I put together a mac80211 driver for Mediatek MT7601U. It's partially
> based on Felix's mt76, but I'm not sure if it will make sense to merge
> the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
> and mt76 now only supports the latest and greatest ac APs.
>
> I'm testing STA functionality right now and it seems to be working ok.
> The code is very much a work in progress but if anyone is interested you
> can get it here:
>
> https://github.com/kuba-moo/mt7601u
Hi, Jakub! I happen to have 7601 dongle, so I tested you driver. There
were some problems, see "dmesg | grep mt7" output:
[ 3.174960] mt7601u 3-5:1.0: ASIC revision: 76010001 MAC revision: 76010500
[ 3.181705] mt7601u 3-5:1.0: Firmware Version: 0.1.00 Build: 7640
Build time: 201302052146____
[ 3.573018] mt7601u 3-5:1.0: Warning: unsupported EEPROM version 0d
[ 3.574853] mt7601u 3-5:1.0: EEPROM ver:0d fae:00
[ 3.816647] usbcore: registered new interface driver mt7601u
[ 10.461251] mt7601u_add_interface idx:0
[ 10.463193] mt7601u_bss_info_changed 0000000e
[ 10.469748] mt7601u_conf_tx 03 <- 0000
[ 10.473738] mt7601u_conf_tx 02 <- 0001
[ 10.477856] mt7601u_conf_tx 01 <- 0002
[ 10.481980] mt7601u_conf_tx 00 <- 0003
[ 10.486849] mt7601u_bss_info_changed 00002000
[ 10.488671] mt7601u_config ffffffff ch:1
[ 10.504305] mt76_configure_filter changed:0 total:80000000
[ 10.508327] mt76_configure_filter changed:0 total:80000000
[ 10.550671] mt76_configure_filter changed:0 total:80000000
[ 10.616870] mt7601u_config 00000100 ch:1
[ 10.619449] mt76_configure_filter changed:10 total:80000010
[ 10.621541] mt7601u_config 00000040 ch:1
[ 10.692407] mt7601u_config 00000040 ch:2
[ 10.992113] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 11.291819] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 11.591524] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 11.891230] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 12.190936] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
[ 12.192790] mt7601u 3-5:1.0: Error: mt7601u_mcu_wait_resp timed out
[ 12.194491] mt7601u_config 00000040 ch:3
[ 12.694660] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 12.696360] mt7601u_config 00000040 ch:4
[ 13.194210] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 13.195873] mt7601u_config 00000040 ch:5
[ 13.693674] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 13.695283] mt7601u_config 00000040 ch:6
[ 14.193225] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 14.194808] mt7601u_config 00000040 ch:7
[ 14.692677] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 14.694374] mt7601u_config 00000040 ch:8
[ 15.192232] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 15.193766] mt7601u_config 00000040 ch:9
[ 15.691688] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 15.693268] mt7601u_config 00000040 ch:10
[ 16.191318] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 16.192891] mt7601u_config 00000040 ch:11
[ 16.690710] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 16.692282] mt7601u_config 00000040 ch:12
[ 17.190270] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 17.191771] mt7601u_config 00000040 ch:13
[ 17.689713] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 17.691243] mt7601u_config 00000040 ch:14
[ 18.189290] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 18.190810] mt7601u_config 00000040 ch:1
[ 18.688839] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
[ 18.690304] mt76_configure_filter changed:0 total:80000000
[ 18.692461] mt7601u_config 00000100 ch:1
Is it because of "unsupported EEPROM version 0d"?
On 26 February 2015 at 17:05, Jakub Kiciński <[email protected]> wrote:
> On Thu, 26 Feb 2015 00:58:59 +0100, Sergei Antonov wrote:
>> On 25 February 2015 at 10:33, Jakub Kiciński <[email protected]> wrote:
>> > On Wed, 25 Feb 2015 01:49:02 +0100, Sergei Antonov wrote:
>> >> On 6 February 2015 at 18:29, Jakub Kiciński <[email protected]> wrote:
>> >> > Hello everyone!
>> >> >
>> >> > I put together a mac80211 driver for Mediatek MT7601U. It's partially
>> >> > based on Felix's mt76, but I'm not sure if it will make sense to merge
>> >> > the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles
>> >> > and mt76 now only supports the latest and greatest ac APs.
>> >> >
>> >> > I'm testing STA functionality right now and it seems to be working ok.
>> >> > The code is very much a work in progress but if anyone is interested you
>> >> > can get it here:
>> >> >
>> >> > https://github.com/kuba-moo/mt7601u
>> >>
>> >> Hi, Jakub! I happen to have 7601 dongle, so I tested you driver. There
>> >> were some problems, see "dmesg | grep mt7" output:
>> >
>> > OK, let me start with a set of basic questions.
>> >
>> > What device do you have (brand + model or picture on ebay please;))?
>>
>> http://www.ebay.de/itm/221662285066
>>
>> > What's the device ID?
>>
>> Bus 003 Device 006: ID 148f:7601 Ralink Technology, Corp.
>>
>> > What platform are you working on?
>>
>> Linux linux64 3.19.0-05375-gd347efe #17 SMP Sun Feb 15 16:38:24 CET
>> 2015 x86_64 GNU/Linux
>>
>> > Is this error persistent or a one-time thing?
>>
>> It is persistent.
>>
>> > Does the vendor driver work with your device?
>
> Thanks for the information, I have exactly that device here and it
> works fine, including on x86_64. You can try going back to commits
> 19cdcb583f18 ("don't allow AMPDUs with probe rates") and
> e9d7b296fea0 ("mitigate DMA problems on very poor link") from my repo.
> Maybe I did screw something up when cleaning up the MCU code.
Going back to them didn't affect the behavior.
>> Yes. I took DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2, applied
>> rt2870-mt7601Usta-kuid_t-kgid_t.patch (can bee easily googled, it is
>> needed to compile for recent kernels) and the device was able to
>> connect to my AP. The only suspicious thing was that the output to the
>> console was very verbose. I didn't take time to see if it was just
>> trace or a sign of a problem. I can repeat this and look more closely.
>> I can also look deeper into the critical moment between ch1 and ch2
>> you mention.
>
> I would appreciate if you could set RTDebugLevel to RT_DEBUG_LOUD in
> src/os/linux/rt_linux.c of the vendor driver (line 54) and get a full
> log of it associating to an AP. Please post it somewhere like
> pastebin.com or attach to an email. Let me know if you need help.
I didn't do it, but I've found a way to fix your driver. See below.
>> > Can you also show content of
>> > /sys/kernel/debug/ieee80211/phy*/mt76/eeprom_param
>> > ?
>>
>> /sys/kernel/debug is empty on my machine.
>
> You can mount it by saying (as root):
> # mount -t debugfs /sys/kernel/debug/
Thanks. Now I see it:
RF freq offset: 2c
RSSI offset: 0 0
Reference temp: f9
LNA gain: 8
Reg channels: 1-14
Per rate power:
raw:05 bw20:05 bw40:05
raw:05 bw20:05 bw40:05
raw:03 bw20:03 bw40:03
raw:03 bw20:03 bw40:03
raw:04 bw20:04 bw40:04
raw:00 bw20:00 bw40:00
raw:00 bw20:00 bw40:00
raw:00 bw20:00 bw40:00
raw:02 bw20:02 bw40:02
raw:00 bw20:00 bw40:00
Per channel power:
tx_power ch1:07 ch2:07
tx_power ch3:07 ch4:07
tx_power ch5:08 ch6:08
tx_power ch7:08 ch8:08
tx_power ch9:09 ch10:09
tx_power ch11:09 ch12:09
tx_power ch13:09 ch14:09
>> I did 'git pull' now, recompiled the driver, rebooted. Here is the
>> relevant piece of dmesg output:
>>
>> [ 10.931816] mt7601u_add_interface idx:0
>> [ 10.933012] mt7601u_bss_info_changed 0000000e
>> [ 10.934126] [prot transition] mode:0000 bgprot:0 non-gf:0 non-ht:0
>> [ 10.937859] mt7601u_conf_tx 03 <- 0000
>> [ 10.942100] mt7601u_conf_tx 02 <- 0001
>> [ 10.945173] mt7601u_conf_tx 01 <- 0002
>> [ 10.949340] mt7601u_conf_tx 00 <- 0003
>> [ 10.952607] mt7601u_bss_info_changed 00002000
>> [ 10.953611] mt7601u_config ffffffff ch:1
>> [ 10.967710] mt76_configure_filter changed:0 total:80000000
>> [ 10.967725] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
>> [ 10.970070] mt76_configure_filter changed:0 total:80000000
>> [ 10.980384] cfg80211: Calling CRDA to update world regulatory domain
>> [ 11.012397] mt76_configure_filter changed:0 total:80000000
>> [ 11.080505] mt7601u_config 00000100 ch:1
>> [ 11.082447] mt76_configure_filter changed:10 total:80000010
>> [ 11.083827] mt7601u_config 00000040 ch:1
>> [ 11.128025] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.2
>> domain=0x0007 address=0x00000000c99a6000 flags=0x0010]
>> [ 11.129175] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.2
>> domain=0x0007 address=0x00000000c99a6040 flags=0x0010]
>> [ 11.155951] mt7601u_config 00000040 ch:2
>> [ 11.455658] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 11.755362] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.055067] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.354758] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.654476] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying
>> [ 12.655597] mt7601u 3-5:1.0: Error: mt7601u_mcu_wait_resp timed out
>> [ 12.656593] mt7601u_config 00000040 ch:3
>> [ 13.154228] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
>> [ 13.155318] mt7601u_config 00000040 ch:4
>> [ 13.653709] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110
>>
>> Note the two messages about IO_PAGE_FAULT in device 00:12.2. This
>> device is a USB controller:
>> [ 2.181191] ehci-pci 0000:00:12.2: EHCI Host Controller
>> But this controller is not guilty :), it works fine with other USB devices.
>
> Perhaps I have some errors in DMA programming. Can you disable all
> automatic WiFi things so they don't mess with the device (NetworkManger
> etc.), make sure the interface is not brought up, and then try (as
> root):
>
> iw dev wlan1 interface add monT type monitor
> ifconfig monT up
> iw dev monT set channel 2
> iw dev monT set channel 1
> iw dev monT set channel 2 HT40+
> iw dev monT set channel 10 HT40-
>
> (I assume wlan1 is the mt7601u.) See if after any of these commands the
> errors will appear.
I did some debugging and comparing against other USB WiFi drivers'
source code and found that this change resolves the issue:
diff --git a/dma.c b/dma.c
index b370210..9059267 100644
--- a/dma.c
+++ b/dma.c
@@ -355,7 +355,7 @@ int usb_kick_out(struct mt7601u_dev *dev, struct
sk_buff *skb, u8 ep)
usb_fill_bulk_urb(q->e[e].urb, usb_dev, snd_pipe, skb->data, skb->len,
mt7601u_complete_tx, q);
q->e[e].urb->transfer_dma = q->e[e].dma;
- q->e[e].urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
+ q->e[e].urb->transfer_flags |= URB_ZERO_PACKET;
ret = usb_submit_urb(q->e[e].urb, GFP_ATOMIC);
if (ret) {
if (ret == -ENODEV)
I saw that drivers/net/wireless/rtlwifi/ driver uses this constant for
TX to device.
Here is my successful dmesg. The connection works. I am only slightly
worried about the last 3 lines.
[ 16.277054] mt7601u_add_interface idx:0
[ 16.279052] mt7601u_bss_info_changed 0000000e
[ 16.281002] [prot transition] mode:0000 bgprot:0 non-gf:0 non-ht:0
[ 16.286761] mt7601u_conf_tx 03 <- 0000
[ 16.291166] mt7601u_conf_tx 02 <- 0001
[ 16.295280] mt7601u_conf_tx 01 <- 0002
[ 16.299424] mt7601u_conf_tx 00 <- 0003
[ 16.303278] mt7601u_bss_info_changed 00002000
[ 16.305043] mt7601u_config ffffffff ch:1
[ 16.318684] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 16.318746] mt76_configure_filter changed:0 total:80000000
[ 16.331196] cfg80211: Calling CRDA to update world regulatory domain
[ 16.365728] mt76_configure_filter changed:0 total:80000000
[ 16.431419] mt7601u_config 00000100 ch:1
[ 16.434003] mt76_configure_filter changed:10 total:80000010
[ 16.436094] mt7601u_config 00000040 ch:1
[ 16.502838] mt7601u_config 00000040 ch:2
[ 16.574766] mt7601u_config 00000040 ch:3
[ 16.646700] mt7601u_config 00000040 ch:4
[ 16.718640] mt7601u_config 00000040 ch:5
[ 16.790582] mt7601u_config 00000040 ch:6
[ 16.862483] mt7601u_config 00000040 ch:7
[ 16.934414] mt7601u_config 00000040 ch:8
[ 17.006343] mt7601u_config 00000040 ch:9
[ 17.074277] mt7601u_config 00000040 ch:10
[ 17.146208] mt7601u_config 00000040 ch:11
[ 17.218134] mt7601u_config 00000040 ch:12
[ 17.342014] mt7601u_config 00000040 ch:13
[ 17.465894] mt7601u_config 00000040 ch:14
[ 17.585786] mt7601u_config 00000040 ch:1
[ 17.586195] wlan1: authenticate with xx:xx:xx:xx:xx:xx
[ 17.601957] mt76_configure_filter changed:0 total:80000000
[ 17.604081] mt7601u_config 00000100 ch:1
[ 17.605497] mt7601u_config 00000100 ch:1
[ 17.606932] mt7601u_config 00000040 ch:8
[ 17.621314] mt7601u_bss_info_changed 00040000
[ 17.622639] mt7601u_bss_info_changed 00004000
[ 17.623845] mt7601u_bss_info_changed 000000e0
[ 17.625804] basic rates: 0000000f
[ 17.629926] wlan1: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[ 17.633019] wlan1: authenticated
[ 17.634571] mt7601u 3-5:1.0 wlan1: disabling HT as WMM/QoS is not
supported by the AP
[ 17.635931] mt7601u 3-5:1.0 wlan1: disabling VHT as WMM/QoS is not
supported by the AP
[ 17.637713] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[ 17.641135] wlan1: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411
status=0 aid=3)
[ 17.642546] mt7601u_sta_add
[ 17.644905] mt7601u_conf_tx 03 <- 0000
[ 17.648499] mt7601u_conf_tx 02 <- 0001
[ 17.651974] mt7601u_conf_tx 01 <- 0002
[ 17.655142] mt7601u_conf_tx 00 <- 0003
[ 17.658639] mt7601u_bss_info_changed 00102009
[ 17.688437] wlan1: associated
[ 17.689610] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 17.690827] mt76_configure_filter changed:0 total:80000000
[ 17.694006] mt7601u_set_key cmd:0 flg:8 kid:0 wid:1
[ 17.695293] setting key for idx:01
[ 17.697372] mt7601u_set_key cmd:0 flg:0 kid:1 wid:7e
[ 17.698623] setting key for idx:7e
[ 17.700558] setting key for vif_idx:00 key_idx:01
[ 21.168348] mt7601u_bss_info_changed 00001000
[ 341.783017] mt7601u_set_key cmd:0 flg:0 kid:2 wid:7e
[ 341.783046] setting key for idx:7e
[ 341.784793] setting key for vif_idx:00 key_idx:02
My firmware binary blob is the same as yours.
This is sorely needed given the miserable state of wifi drivers in the
Linux kernel.
Kernel maintainers, can this be pushed to mainline? It's not a vendor
driver after all, and it uses nl80211 instead of WEXT.
Regards,
Etna
>
>
> On 26/02/15 22:40, Jakub Kiciński wrote:
>>
>> On Thu, 26 Feb 2015 14:56:46 +0100, poma wrote:
>>>
>>> On 06.02.2015 18:29, Jakub Kiciński wrote:
>>>>
>>>> Hello everyone! I put together a mac80211 driver for Mediatek
>>>> MT7601U. It's partially based on Felix's mt76, but I'm not sure if
>>>> it will make sense to merge the two together. MT7601U is a pretty
>>>> old 1x1 bgn chip for USB dongles and mt76 now only supports the
>>>> latest and greatest ac APs. I'm testing STA functionality right now
>>>> and it seems to be working ok. The code is very much a work in
>>>> progress but if anyone is interested you can get it here:
>>>> https://github.com/kuba-moo/mt7601uCheers, kuba -- To unsubscribe
>>>> from this list: send the line "unsubscribe linux-wireless" in the
>>>> body of a message to [email protected] majordomo info
>>>> at http://vger.kernel.org/majordomo-info.html
>>>
>>> How many mt7601u module editions exists there? :) - vendor's -
>>> vendor's patched (how many forms of the same) - your reinvented -
>>> the one on which pán Gruszka allegedly works? - any more?
>>
>> I assume you mean to ask how many different drivers are there. There
>> is the vendor 3.0.0.4 STA driver which only has client functionality.
>> Many patched versions of this driver exist on GitHub. There is also
>> an older version of vendor driver which can work as an AP. My
>> mac80211-based driver is the only non-vendor version I'm aware of.
>
On Wed, 20 May 2015 19:06:04 +0200, poma wrote:
> With the script 'mt7601u-fw-install' can be initiated the download and installation of the required firmware,
> though it would be optimal to resolve it in the following manner:
>
> In OpenWrt repo - mt76 - mac80211 driver for MediaTek MT76x2 802.11ac chips
> https://github.com/openwrt/mt76
>
> there is a license file together with firmwares:
> https://github.com/openwrt/mt76/blob/master/firmware
>
>
> Whether the same can be done with:
> mt7601u - Linux mac80211-based driver for Mediatek MT7601U USB bgn WiFi dongle
> https://github.com/kuba-moo/mt7601u
> ?
I will ask MediaTek to send firmware to linux-firmware.git once the
driver passes review and is accepted to mainline.
kernel 4.0.4 - no more:
WARNING: CPU: x PID: 0 at kernel/softirq.c:150 __local_bh_enable_ip+0x72/0xa0()
One more detail - at least for this MT7601U device, USB extension cable must be high quality.
On 20.05.2015 19:14, Jakub Kiciński wrote:
> On Wed, 20 May 2015 19:06:04 +0200, poma wrote:
>> With the script 'mt7601u-fw-install' can be initiated the download and installation of the required firmware,
>> though it would be optimal to resolve it in the following manner:
>>
>> In OpenWrt repo - mt76 - mac80211 driver for MediaTek MT76x2 802.11ac chips
>> https://github.com/openwrt/mt76
>>
>> there is a license file together with firmwares:
>> https://github.com/openwrt/mt76/blob/master/firmware
>>
>>
>> Whether the same can be done with:
>> mt7601u - Linux mac80211-based driver for Mediatek MT7601U USB bgn WiFi dongle
>> https://github.com/kuba-moo/mt7601u
>> ?
>
> I will ask MediaTek to send firmware to linux-firmware.git once the
> driver passes review and is accepted to mainline.
>
Yeah, the foundation is already there:
linux-firmware: Add firmware files for mtk mt7630/mt7650 chipsets
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=8267525
Good luck.
On 18.05.2015 02:03, poma wrote:
>
> Preliminary test results
>
> - lsusb -d 148f:7601:
> Bus 001 Device 007: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
>
>
> - https://github.com/kuba-moo/mt7601u
> - git log -1:
> commit ad5474ecd9fd6efd4a7f03f4a8c71ea4bb57ca73
> Author: Jakub Kicinski <[email protected]>
> Date: Wed May 6 20:44:18 2015 +0200
>
> make sure .disconnect() doesn't cleanup the device if .resume() failed
>
> Signed-off-by: Jakub Kicinski <[email protected]>
>
>
> - modinfo mt7601u:
> filename: /lib/modules/4.0.3-202.fc21.x86_64/updates/mt7601u.ko
> license: GPL
> firmware: mt7601u.bin
> alias: usb:v7392p7710d*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v2A5Fp1000d*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v2955p1001d*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v2955p0001d*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v2717p4106d*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v2001p3D04d*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v148Fp760Dd*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v148Fp760Cd*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v148Fp760Bd*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v148Fp760Ad*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v148Fp7601d*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v13D3p3434d*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v13D3p3431d*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v0E8Dp760Bd*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v0E8Dp760Ad*dc*dsc*dp*ic*isc*ip*in*
> alias: usb:v0B05p17D3d*dc*dsc*dp*ic*isc*ip*in*
> depends: cfg80211,mac80211
> vermagic: 4.0.3-202.fc21.x86_64 SMP mod_unload
> signer: Fedora kernel signing key
> sig_key: 95:7D:C8:E5:9F:5D:E6:03:71:49:1A:D0:9A:C6:8F:85:16:6C:B3:94
> sig_hashalgo: sha256
>
>
> - md5sum /lib/firmware/mt7601u.bin:
> 696cedb8e76ecc0cda9f9b0d3972c64d /lib/firmware/mt7601u.bin
>
>
> - NetworkManager --version:
> 1.0.2-2.fc21
>
>
> plug in device:
> - dmesg:
> usb 1-4: new high-speed USB device number 6 using ehci-pci
> usb 1-4: New USB device found, idVendor=148f, idProduct=7601
> usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-4: Product: 802.11 n WLAN
> usb 1-4: Manufacturer: MediaTek
> usb 1-4: SerialNumber: 1.0
> cfg80211: ...
> ...
> usb 1-4: reset high-speed USB device number 6 using ehci-pci
> mt7601u 1-4:1.0: ASIC revision: 76010001 MAC revision: 76010500
> mt7601u 1-4:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201302052146____
> mt7601u 1-4:1.0: Warning: unsupported EEPROM version 0d
> mt7601u 1-4:1.0: EEPROM ver:0d fae:00
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> usbcore: registered new interface driver mt7601u
> mt7601u 1-4:1.0 wlp0s2f1u4: renamed from wlan0
> ...
> cfg80211: ...
> ...
> wlp0s2f1u4: authenticate with <BSSID>
> wlp0s2f1u4: send auth to <BSSID> (try 1/3)
> wlp0s2f1u4: authenticated
> wlp0s2f1u4: associate with <BSSID> (try 1/3)
> wlp0s2f1u4: RX AssocResp from <BSSID> (capab=0x411 status=0 aid=1)
> wlp0s2f1u4: associated
>
>
> - iwconfig wlp0s2f1u4:
> wlp0s2f1u4 IEEE 802.11bgn ESSID:"AP"
> Mode:Managed Frequency:2.422 GHz Access Point: <BSSID>
> Bit Rate=135 Mb/s Tx-Power=20 dBm
> Retry short limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> Link Quality=67/70 Signal level=-43 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:873 Missed beacon:0
>
>
...
Can be tested with the test compilation I share with you bona fide:
http://goo.gl/Gm4ffO
ISO/Fedora-Live-Xfce-WiFi.iso
Runs on baremetal & QEMU/KVM/Libvirt/Virtual Machine Manager
http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest
With the script 'mt7601u-fw-install' can be initiated the download and installation of the required firmware,
though it would be optimal to resolve it in the following manner:
In OpenWrt repo - mt76 - mac80211 driver for MediaTek MT76x2 802.11ac chips
https://github.com/openwrt/mt76
there is a license file together with firmwares:
https://github.com/openwrt/mt76/blob/master/firmware
Whether the same can be done with:
mt7601u - Linux mac80211-based driver for Mediatek MT7601U USB bgn WiFi dongle
https://github.com/kuba-moo/mt7601u
?
Preliminary test results
- lsusb -d 148f:7601:
Bus 001 Device 007: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
- https://github.com/kuba-moo/mt7601u
- git log -1:
commit ad5474ecd9fd6efd4a7f03f4a8c71ea4bb57ca73
Author: Jakub Kicinski <[email protected]>
Date: Wed May 6 20:44:18 2015 +0200
make sure .disconnect() doesn't cleanup the device if .resume() failed
Signed-off-by: Jakub Kicinski <[email protected]>
- modinfo mt7601u:
filename: /lib/modules/4.0.3-202.fc21.x86_64/updates/mt7601u.ko
license: GPL
firmware: mt7601u.bin
alias: usb:v7392p7710d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v2A5Fp1000d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v2955p1001d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v2955p0001d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v2717p4106d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v2001p3D04d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v148Fp760Dd*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v148Fp760Cd*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v148Fp760Bd*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v148Fp760Ad*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v148Fp7601d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v13D3p3434d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v13D3p3431d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0E8Dp760Bd*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0E8Dp760Ad*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0B05p17D3d*dc*dsc*dp*ic*isc*ip*in*
depends: cfg80211,mac80211
vermagic: 4.0.3-202.fc21.x86_64 SMP mod_unload
signer: Fedora kernel signing key
sig_key: 95:7D:C8:E5:9F:5D:E6:03:71:49:1A:D0:9A:C6:8F:85:16:6C:B3:94
sig_hashalgo: sha256
- md5sum /lib/firmware/mt7601u.bin:
696cedb8e76ecc0cda9f9b0d3972c64d /lib/firmware/mt7601u.bin
- NetworkManager --version:
1.0.2-2.fc21
plug in device:
- dmesg:
usb 1-4: new high-speed USB device number 6 using ehci-pci
usb 1-4: New USB device found, idVendor=148f, idProduct=7601
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 802.11 n WLAN
usb 1-4: Manufacturer: MediaTek
usb 1-4: SerialNumber: 1.0
cfg80211: ...
...
usb 1-4: reset high-speed USB device number 6 using ehci-pci
mt7601u 1-4:1.0: ASIC revision: 76010001 MAC revision: 76010500
mt7601u 1-4:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201302052146____
mt7601u 1-4:1.0: Warning: unsupported EEPROM version 0d
mt7601u 1-4:1.0: EEPROM ver:0d fae:00
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
usbcore: registered new interface driver mt7601u
mt7601u 1-4:1.0 wlp0s2f1u4: renamed from wlan0
...
cfg80211: ...
...
wlp0s2f1u4: authenticate with <BSSID>
wlp0s2f1u4: send auth to <BSSID> (try 1/3)
wlp0s2f1u4: authenticated
wlp0s2f1u4: associate with <BSSID> (try 1/3)
wlp0s2f1u4: RX AssocResp from <BSSID> (capab=0x411 status=0 aid=1)
wlp0s2f1u4: associated
- iwconfig wlp0s2f1u4:
wlp0s2f1u4 IEEE 802.11bgn ESSID:"AP"
Mode:Managed Frequency:2.422 GHz Access Point: <BSSID>
Bit Rate=135 Mb/s Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=67/70 Signal level=-43 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:873 Missed beacon:0
== suspend to ram test ==
while connected:
- systemctl suspend
- dmesg:
wlp0s2f1u4: deauthenticating from <BSSID> by local choice (Reason: 3=DEAUTH_LEAVING)
cfg80211: ...
...
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
PM: Entering mem sleep
PM: suspend of devices complete after 2579.708 msecs
PM: late suspend of devices complete after 0.653 msecs
PM: noirq suspend of devices complete after 11.487 msecs
ACPI: Preparing to enter system sleep state S3
PM: Saving platform NVS memory
...
..
.
RESUME
.
..
...
ACPI: Low-level resume complete
PM: Restoring platform NVS memory
ACPI: Waking up from system sleep state S3
PM: noirq resume of devices complete after 84.948 msecs
PM: early resume of devices complete after 0.520 msecs
...
mt7601u 1-4:1.0: Error: MCU response pre-completed!
mt7601u 1-4:1.0: Warning: unsupported EEPROM version 0d
mt7601u 1-4:1.0: EEPROM ver:0d fae:00
...
PM: resume of devices complete after 313.068 msecs
PM: Finishing wakeup.
Restarting tasks ...
...
wlp0s2f1u4: authenticate with <BSSID>
wlp0s2f1u4: send auth to <BSSID> (try 1/3)
wlp0s2f1u4: authenticated
wlp0s2f1u4: associate with <BSSID> (try 1/3)
wlp0s2f1u4: RX AssocResp from <BSSID> (capab=0x411 status=0 aid=1)
wlp0s2f1u4: associated
...
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/softirq.c:150 __local_bh_enable_ip+0x72/0xa0()
Modules linked in: ...mt7601u(O) mac80211 cfg80211 ...
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C O 4.0.3-202.fc21.x86_64 #1
...
Call Trace:
<IRQ> [<ffffffff8177cc28>] dump_stack+0x45/0x57
[<ffffffff8109d5ea>] warn_slowpath_common+0x8a/0xc0
[<ffffffff8109d71a>] warn_slowpath_null+0x1a/0x20
[<ffffffff810a14f2>] __local_bh_enable_ip+0x72/0xa0
[<ffffffffa064868b>] destroy_conntrack+0x7b/0x100 [nf_conntrack]
[<ffffffff8169d0e7>] nf_conntrack_destroy+0x17/0x30
[<ffffffff81652165>] skb_release_head_state+0x95/0xe0
[<ffffffff816521c6>] skb_release_all+0x16/0x30
[<ffffffff8165240c>] consume_skb+0x2c/0x80
[<ffffffffa08913d6>] ieee80211_tx_status+0xb66/0xe60 [mac80211]
[<ffffffff8157ba88>] ? ehci_work.part.62+0x9a8/0xa50
[<ffffffffa07dedb4>] ? ieee80211_get_hdrlen_from_skb+0x24/0x40 [cfg80211]
[<ffffffffa07c4997>] mt7601u_tx_status+0x87/0xa0 [mt7601u]
[<ffffffffa07bf00e>] mt7601u_complete_tx+0x8e/0x1c0 [mt7601u]
[<ffffffff8155a065>] __usb_hcd_giveback_urb+0x85/0x140
[<ffffffff8155ad0b>] usb_giveback_urb_bh+0xab/0x100
[<ffffffff810a1786>] tasklet_action+0xe6/0xf0
[<ffffffff810a1bab>] __do_softirq+0x10b/0x2b0
[<ffffffff810a1f75>] irq_exit+0x125/0x130
[<ffffffff817860e8>] do_IRQ+0x58/0xf0
[<ffffffff81783e2d>] common_interrupt+0x6d/0x6d
<EOI> [<ffffffff8104d369>] ? lapic_timer_setup+0x19/0x20
[<ffffffff8105fb86>] ? native_safe_halt+0x6/0x10
[<ffffffff8101fade>] default_idle+0x1e/0xc0
[<ffffffff8101fbff>] amd_e400_idle+0x7f/0x120
[<ffffffff810205af>] arch_cpu_idle+0xf/0x20
[<ffffffff810e02aa>] cpu_startup_entry+0x30a/0x420
[<ffffffff81773137>] rest_init+0x77/0x80
[<ffffffff81d4b03a>] start_kernel+0x4a3/0x4c4
[<ffffffff81d4a120>] ? early_idt_handlers+0x120/0x120
[<ffffffff81d4a4d7>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d4a63a>] x86_64_start_kernel+0x161/0x184
---[ end trace dfa8ecf6346f14b1 ]---
== mini stress test ==
1. unplug device while connected:
- dmesg:
...
usb 1-4: USB disconnect, device number 4
wlp0s2f1u4: deauthenticating from <BSSID> by local choice (Reason: 3=DEAUTH_LEAVING)
mt7601u 1-4:1.0: mt7601u_rxdc_cal timed out
...
2. plug in device a few seconds after:
- dmesg:
...
usb 1-4: new high-speed USB device number 7 using ehci-pci
usb 1-4: New USB device found, idVendor=148f, idProduct=7601
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 802.11 n WLAN
usb 1-4: Manufacturer: MediaTek
usb 1-4: SerialNumber: 1.0
usb 1-4: reset high-speed USB device number 7 using ehci-pci
mt7601u 1-4:1.0: ASIC revision: 76010001 MAC revision: 76010500
mt7601u 1-4:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201302052146____
mt7601u 1-4:1.0: Warning: unsupported EEPROM version 0d
mt7601u 1-4:1.0: EEPROM ver:0d fae:00
mt7601u 1-4:1.0: Error: RX urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp evt:0 seq:5-4!
mt7601u 1-4:1.0: Error: RX urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp evt:0 seq:5-4!
mt7601u 1-4:1.0: Error: RX urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp evt:0 seq:5-4!
mt7601u 1-4:1.0: Error: RX urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp evt:0 seq:5-4!
mt7601u 1-4:1.0: Error: RX urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp urb failed:-71
mt7601u 1-4:1.0: Error: MCU resp evt:0 seq:5-4!
mt7601u 1-4:1.0: Error: mt7601u_mcu_wait_resp timed out
mt7601u 1-4:1.0: Vendor request req:07 off:0080 failed:-71
mt7601u 1-4:1.0: Vendor request req:02 off:0080 failed:-71
mt7601u 1-4:1.0: Vendor request req:02 off:0080 failed:-71
mt7601u: probe of 1-4:1.0 failed with error -110
usb 1-4: USB disconnect, device number 7
usb 1-4: new high-speed USB device number 8 using ehci-pci
usb 1-4: New USB device found, idVendor=148f, idProduct=7601
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 802.11 n WLAN
usb 1-4: Manufacturer: MediaTek
usb 1-4: SerialNumber: 1.0
usb 1-4: reset high-speed USB device number 8 using ehci-pci
mt7601u 1-4:1.0: ASIC revision: 76010001 MAC revision: 76010500
mt7601u 1-4:1.0: Warning: unsupported EEPROM version 0d
mt7601u 1-4:1.0: EEPROM ver:0d fae:00
ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
mt7601u 1-4:1.0 wlp0s2f1u4: renamed from wlan0
...
wlp0s2f1u4: authenticate with <BSSID>
wlp0s2f1u4: send auth to <BSSID> (try 1/3)
wlp0s2f1u4: authenticated
wlp0s2f1u4: associate with <BSSID> (try 1/3)
wlp0s2f1u4: RX AssocResp from <BSSID> (capab=0x411 status=0 aid=1)
wlp0s2f1u4: associated
...
------------[ cut here ]------------
WARNING: CPU: 3 PID: 0 at kernel/softirq.c:150 __local_bh_enable_ip+0x72/0xa0()
Modules linked in: ... mt7601u(O) mac80211 cfg80211 ...
CPU: 3 PID: 0 Comm: swapper/3 Tainted: G O 4.0.3-202.fc21.x86_64 #1
...
Call Trace:
<IRQ> [<ffffffff8177cc28>] dump_stack+0x45/0x57
[<ffffffff8109d5ea>] warn_slowpath_common+0x8a/0xc0
[<ffffffff8109d71a>] warn_slowpath_null+0x1a/0x20
[<ffffffff810a14f2>] __local_bh_enable_ip+0x72/0xa0
[<ffffffffa06c268b>] destroy_conntrack+0x7b/0x100 [nf_conntrack]
[<ffffffff8169d0e7>] nf_conntrack_destroy+0x17/0x30
[<ffffffff81652165>] skb_release_head_state+0x95/0xe0
[<ffffffff816521c6>] skb_release_all+0x16/0x30
[<ffffffff8165240c>] consume_skb+0x2c/0x80
[<ffffffffa07703d6>] ieee80211_tx_status+0xb66/0xe60 [mac80211]
[<ffffffff8157ba88>] ? ehci_work.part.62+0x9a8/0xa50
[<ffffffffa0620db4>] ? ieee80211_get_hdrlen_from_skb+0x24/0x40 [cfg80211]
[<ffffffffa043c997>] mt7601u_tx_status+0x87/0xa0 [mt7601u]
[<ffffffffa043700e>] mt7601u_complete_tx+0x8e/0x1c0 [mt7601u]
[<ffffffff8155a065>] __usb_hcd_giveback_urb+0x85/0x140
[<ffffffff8155ad0b>] usb_giveback_urb_bh+0xab/0x100
[<ffffffff810a1786>] tasklet_action+0xe6/0xf0
[<ffffffff810a1bab>] __do_softirq+0x10b/0x2b0
[<ffffffff810a1f75>] irq_exit+0x125/0x130
[<ffffffff817860e8>] do_IRQ+0x58/0xf0
[<ffffffff81783e2d>] common_interrupt+0x6d/0x6d
<EOI> [<ffffffff8104d369>] ? lapic_timer_setup+0x19/0x20
[<ffffffff8105fb86>] ? native_safe_halt+0x6/0x10
[<ffffffff8101fade>] default_idle+0x1e/0xc0
[<ffffffff8101fbff>] amd_e400_idle+0x7f/0x120
[<ffffffff810205af>] arch_cpu_idle+0xf/0x20
[<ffffffff810e02aa>] cpu_startup_entry+0x30a/0x420
[<ffffffff8104b5c5>] start_secondary+0x1a5/0x1f0
---[ end trace 453a9db773f4554b ]---
== throughput test ==
MT7601U Wi-Fi <~1m LOS~> AP(Wi-Fi <-bridge-> 100Mbit switch) <-> SERVER
- iperf -c <SERVER> -i 1:
------------------------------------------------------------
Client connecting to <SERVER>, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local <CLIENT IP> port 45680 connected with <SERVER IP> port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 11.2 MBytes 94.4 Mbits/sec
[ 3] 1.0- 2.0 sec 11.2 MBytes 94.4 Mbits/sec
[ 3] 2.0- 3.0 sec 11.0 MBytes 92.3 Mbits/sec
[ 3] 3.0- 4.0 sec 11.1 MBytes 93.3 Mbits/sec
[ 3] 4.0- 5.0 sec 10.8 MBytes 90.2 Mbits/sec
[ 3] 5.0- 6.0 sec 11.2 MBytes 94.4 Mbits/sec
[ 3] 6.0- 7.0 sec 10.5 MBytes 88.1 Mbits/sec
[ 3] 7.0- 8.0 sec 10.4 MBytes 87.0 Mbits/sec
[ 3] 8.0- 9.0 sec 11.0 MBytes 92.3 Mbits/sec
[ 3] 9.0-10.0 sec 11.4 MBytes 95.4 Mbits/sec
[ 3] 0.0-10.0 sec 110 MBytes 92.1 Mbits/sec
mt7601u landed in 'linux-next'
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/net/wireless/mediatek/mt7601u
the v4.2 kernel is predicted for Sunday, 2015-08-23
http://phb-crystal-ball.org
For the firmware(mt7601u.bin) as part of the essential functionality of the device
it would be good to land in 'linux-firmware' *even* before the actual kernel release v4.2
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree
tempus fugit
On 27.06.2015 22:45, poma wrote:
>
> mt7601u landed in 'linux-next'
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/net/wireless/mediatek/mt7601u
>
> the v4.2 kernel is predicted for Sunday, 2015-08-23
> http://phb-crystal-ball.org
>
> For the firmware(mt7601u.bin) as part of the essential functionality of the device
> it would be good to land in 'linux-firmware' *even* before the actual kernel release v4.2
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree
>
>
> tempus fugit
>
Add firmware for mt7601u. version 34.
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=9df5430
Thanks Hua Shao for the firmware,
and of course,
thanks Jakub Kiciński for the driver.
Oh yeah!