Dear all,
updating my pc from linux kernel 3.3 to linux kernel 3.4 broke my wlan. I'm
using rt2571 based wlan module from qcom: LR802UKG, which is wired to an
internal usb port of my media center pc. The rfkill switch is hardwired to
make wlan active all the time. This setup is (almost) properly working since
about three years now. (If i ignore the occasional vendor_request_error
things)
When I use kernel 3.4., i get a lot of additional devices reported by the
kernel - three leds and a rfkill switch which have not been there before. (or
at least I did not notice them) The wlan device now refuses to go online,
saying that the kill switch is active, which of course can not be as it is
working with linux kernel 3.3. Furthermore, the driver reports three leds, but
my wlan device has only one, so probably a bad eeprom? i dont know...
Anyway, I noticed, that when I set the radio led to brightness 255, which
takes a lot of time and gives me some vendor_request_errors, the rfkill switch
gets turned off (sys/class/rfkill/../hard = 0). Unfortunately, this doesn't
help to bring the interface online: After doing that I get frequent
vendor_request_failed messages, even the PC becomes stuck on shutdown.
(Probably NetworkManager waiting for something...)
So, what can I do to track down the problem?
Cheers,
Andreas
On Tue, Jun 26, 2012 at 06:03:56PM +0200, Andreas Messer wrote:
> Dear all,
>
> updating my pc from linux kernel 3.3 to linux kernel 3.4 broke my wlan. I'm
> using rt2571 based wlan module from qcom: LR802UKG, which is wired to an
> internal usb port of my media center pc. The rfkill switch is hardwired to
> make wlan active all the time. This setup is (almost) properly working since
> about three years now. (If i ignore the occasional vendor_request_error
> things)
> When I use kernel 3.4., i get a lot of additional devices reported by the
> kernel - three leds and a rfkill switch which have not been there before. (or
> at least I did not notice them) The wlan device now refuses to go online,
> saying that the kill switch is active, which of course can not be as it is
> working with linux kernel 3.3. Furthermore, the driver reports three leds, but
> my wlan device has only one, so probably a bad eeprom? i dont know...
> Anyway, I noticed, that when I set the radio led to brightness 255, which
> takes a lot of time and gives me some vendor_request_errors, the rfkill switch
> gets turned off (sys/class/rfkill/../hard = 0). Unfortunately, this doesn't
> help to bring the interface online: After doing that I get frequent
> vendor_request_failed messages, even the PC becomes stuck on shutdown.
> (Probably NetworkManager waiting for something...)
> So, what can I do to track down the problem?
Andreas,
Hmmm...well, perhaps you can start by doing a git bisect to narrow-down
the commit that started this problem for you? It may take serveral
iterations, if you can only narrow it down to 3.3 working and 3.4 not
working. But, at least that should point us in the right direction.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
>
> I have the same problem with a rt73usb too and with the
> kernel 3.4.4-2-ARCH (Archlinux). The solution was to recompile the
> kernel with the option CONFIG_RFKILL unset (really unset not as a
> module). Then everything works properly (exept you cannot disable it
> with rfkill). I did not had this problem before the kernel 3.4 (but I
> do not know if rfkill actually works, or if the wlan was always
> enabled).
The strange thing is that after having disabled the CONFIG_RFKIL , the
wireless works even if I physically put a physical switch in the off
position. Anyway I prefer having a wireless card that works whgen it
shouldn't than vice versa.
Olive
Hello Again,
Am Dienstag, 26. Juni 2012, 13:18:35 schrieb John W. Linville:
> On Tue, Jun 26, 2012 at 06:03:56PM +0200, Andreas Messer wrote:
> > Dear all,
> >
> > updating my pc from linux kernel 3.3 to linux kernel 3.4 broke my wlan.
> > I'm
> > using rt2571 based wlan module from qcom: LR802UKG, which is wired to an
> > internal usb port of my media center pc. The rfkill switch is hardwired to
> > make wlan active all the time. This setup is (almost) properly working
> > since about three years now. (If i ignore the occasional
> > vendor_request_error things)
> > The wlan device now refuses to go
> > online, saying that the kill switch is active, which of course can not be
> > as it is working with linux kernel 3.3.
> > [...]
> > So, what can I do to track down the problem?
>
> Andreas,
>
> Hmmm...well, perhaps you can start by doing a git bisect to narrow-down
> the commit that started this problem for you? It may take serveral
> iterations, if you can only narrow it down to 3.3 working and 3.4 not
> working. But, at least that should point us in the right direction.
>
> John
first of all, sorry for the long delay. After some hours of compiling and
checking, I have found the following things: The problem is introduced
somewhere between v3.3.8 and v3.4, actually the commit 7e29629 already shows
the problem. So range is v3.3.8...7e29629. I thing there is something wrong
with initialization of the chip because of the following behaviour: If I boot
from power-off into 7e29629 the kill switch reports to be in state 1
(/sys/../hard = 1). If I first boot into 3.3.8 and afterwards re-boot into
7e29629, the kill switch reports to be in state 0 and the WLAN connection
builds up properly.
Hope that helps somehow.
Cheers,
Andreas
On Tue, 26 Jun 2012 18:03:56 +0200
Andreas Messer <[email protected]> wrote:
> Dear all,
>
> updating my pc from linux kernel 3.3 to linux kernel 3.4 broke my
> wlan. I'm using rt2571 based wlan module from qcom: LR802UKG, which
> is wired to an internal usb port of my media center pc. The rfkill
> switch is hardwired to make wlan active all the time. This setup is
> (almost) properly working since about three years now. (If i ignore
> the occasional vendor_request_error things)
> When I use kernel 3.4., i get a lot of additional devices reported by
> the kernel - three leds and a rfkill switch which have not been there
> before. (or at least I did not notice them) The wlan device now
> refuses to go online, saying that the kill switch is active, which of
> course can not be as it is working with linux kernel 3.3.
> Furthermore, the driver reports three leds, but my wlan device has
> only one, so probably a bad eeprom? i dont know... Anyway, I noticed,
> that when I set the radio led to brightness 255, which takes a lot of
> time and gives me some vendor_request_errors, the rfkill switch gets
> turned off (sys/class/rfkill/../hard = 0). Unfortunately, this
> doesn't help to bring the interface online: After doing that I get
> frequent vendor_request_failed messages, even the PC becomes stuck on
> shutdown. (Probably NetworkManager waiting for something...) So, what
> can I do to track down the problem?
>
> Cheers,
> Andreas
I have the same problem with a rt73usb too and with the
kernel 3.4.4-2-ARCH (Archlinux). The solution was to recompile the
kernel with the option CONFIG_RFKILL unset (really unset not as a
module). Then everything works properly (exept you cannot disable it
with rfkill). I did not had this problem before the kernel 3.4 (but I do
not know if rfkill actually works, or if the wlan was always enabled).
Olive
Hey there,
Am Dienstag, 24. Juli 2012, 19:33:34 schrieb Andreas Messer:
> Hello Again,
>
> Am Dienstag, 26. Juni 2012, 13:18:35 schrieb John W. Linville:
> > On Tue, Jun 26, 2012 at 06:03:56PM +0200, Andreas Messer wrote:
> > > Dear all,
> > >
> > > updating my pc from linux kernel 3.3 to linux kernel 3.4 broke my wlan.
I have spent some more time on investigating the cause of the bug and found
the problem. Actually I'm not sure which is the right solution. The problem is
caused by the following points:
1) The rt73 hardware registers are not initialized before bringing the
corresponding network interface up ('ifconfig wlan0 up')
2) Bringing the interface up is not possible because of the kill switch
3) The GPIO input pin for the kill switch is still in 'output mode' (the
default power on value), therefore the register will always read
'killswitch on'
So something like a deadlock. While looking through the code, I have seen,
that the whole rt2xx driver uses here the same concept, that the hardware
register initialization and firmware-download does not happen before the
interface is brought up. Im not sure if that is the right concept, shouldn't
be the hardware initialized properly on loading the driver already? I mean, if
values are read from the hardware in order to e.g. read the kill switch state
shouldn't bethe hardware in a defined state before that? Anyway, it would be
possible to solve this bug easily by only setting up the correct value of the
CSR13 register right after reading the eeprom. For simple testing I have
written the correct gpio mask to CSR13 using the debugfs interface and the
wlan interface immediately was brought up and connected successfully with my
Network.
So which is the right solution? I could make & test a patch for the simple
solution easily.
Cheers
Andreas
Hey Gertjan,
Am Sonntag, 26. August 2012, 20:22:56 schrieb Gertjan van Wingerde:
> Hi Andreas,
>
> On 08/23/12 20:51, Andreas Messer wrote:
> > Hey there,
> >
> > Am Dienstag, 24. Juli 2012, 19:33:34 schrieb Andreas Messer:
> >> Hello Again,
> >>
> >> Am Dienstag, 26. Juni 2012, 13:18:35 schrieb John W. Linville:
> >>> On Tue, Jun 26, 2012 at 06:03:56PM +0200, Andreas Messer wrote:
> >>>> Dear all,
> >>>>
> >>>> updating my pc from linux kernel 3.3 to linux kernel 3.4 broke my wlan.
> >
> > I have spent some more time on investigating the cause of the bug and
> > found
> > the problem. Actually I'm not sure which is the right solution. The
> > problem is caused by the following points:
> >
> > 1) The rt73 hardware registers are not initialized before bringing the
> >
> > corresponding network interface up ('ifconfig wlan0 up')
> >
> > 2) Bringing the interface up is not possible because of the kill switch
> >
> > 3) The GPIO input pin for the kill switch is still in 'output mode' (the
> >
> > default power on value), therefore the register will always read
> > 'killswitch on'
> >
> > [...]
> [...]
> The reason why we do most of the initialization at interface up is that
> that is the earliest possible time we can get the firmware image from
> userspace. A lot of the register programming we have to do for
> initialization depend on the firmware being uploaded and running, hence
> we initialize most at interface up time.
> [...]
Thanks for that explanation. Didn't know that about the firmware.
> Find attached a patch that does this for all the rt2x00 devices. I hope
> you are able to test whether this patch fixes the problem for you.
Yep, the patch works fine for me. (Tested on latest git snapshot)
Cheers
Andreas
Hi Andreas,
On 27 aug. 2012, at 18:33, Andreas Messer <[email protected]> wrote:
> Hey Gertjan,
>
> Am Sonntag, 26. August 2012, 20:22:56 schrieb Gertjan van Wingerde:
>> Hi Andreas,
>>
>> On 08/23/12 20:51, Andreas Messer wrote:
>>> Hey there,
>>>
>>> Am Dienstag, 24. Juli 2012, 19:33:34 schrieb Andreas Messer:
>>>> Hello Again,
>>>>
>>>> Am Dienstag, 26. Juni 2012, 13:18:35 schrieb John W. Linville:
>>>>> On Tue, Jun 26, 2012 at 06:03:56PM +0200, Andreas Messer wrote:
>>>>>> Dear all,
>>>>>>
>>>>>> updating my pc from linux kernel 3.3 to linux kernel 3.4 broke my wlan.
>>>
>>> I have spent some more time on investigating the cause of the bug and
>>> found
>>> the problem. Actually I'm not sure which is the right solution. The
>>> problem is caused by the following points:
>>>
>>> 1) The rt73 hardware registers are not initialized before bringing the
>>>
>>> corresponding network interface up ('ifconfig wlan0 up')
>>>
>>> 2) Bringing the interface up is not possible because of the kill switch
>>>
>>> 3) The GPIO input pin for the kill switch is still in 'output mode' (the
>>>
>>> default power on value), therefore the register will always read
>>> 'killswitch on'
>>>
>>> [...]
>> [...]
>> The reason why we do most of the initialization at interface up is that
>> that is the earliest possible time we can get the firmware image from
>> userspace. A lot of the register programming we have to do for
>> initialization depend on the firmware being uploaded and running, hence
>> we initialize most at interface up time.
>> [...]
>
> Thanks for that explanation. Didn't know that about the firmware.
>
>> Find attached a patch that does this for all the rt2x00 devices. I hope
>> you are able to test whether this patch fixes the problem for you.
>
> Yep, the patch works fine for me. (Tested on latest git snapshot)
>
Thanks for testing. I'll submit the patch-set upstream later this week.
---
Gertjan
Hi Andreas,
On 08/23/12 20:51, Andreas Messer wrote:
> Hey there,
>
> Am Dienstag, 24. Juli 2012, 19:33:34 schrieb Andreas Messer:
>> Hello Again,
>>
>> Am Dienstag, 26. Juni 2012, 13:18:35 schrieb John W. Linville:
>>> On Tue, Jun 26, 2012 at 06:03:56PM +0200, Andreas Messer wrote:
>>>> Dear all,
>>>>
>>>> updating my pc from linux kernel 3.3 to linux kernel 3.4 broke my wlan.
>
> I have spent some more time on investigating the cause of the bug and found
> the problem. Actually I'm not sure which is the right solution. The problem is
> caused by the following points:
>
> 1) The rt73 hardware registers are not initialized before bringing the
> corresponding network interface up ('ifconfig wlan0 up')
>
> 2) Bringing the interface up is not possible because of the kill switch
>
> 3) The GPIO input pin for the kill switch is still in 'output mode' (the
> default power on value), therefore the register will always read
> 'killswitch on'
>
> So something like a deadlock. While looking through the code, I have seen,
> that the whole rt2xx driver uses here the same concept, that the hardware
> register initialization and firmware-download does not happen before the
> interface is brought up. Im not sure if that is the right concept, shouldn't
> be the hardware initialized properly on loading the driver already? I mean, if
> values are read from the hardware in order to e.g. read the kill switch state
> shouldn't bethe hardware in a defined state before that? Anyway, it would be
> possible to solve this bug easily by only setting up the correct value of the
> CSR13 register right after reading the eeprom. For simple testing I have
> written the correct gpio mask to CSR13 using the debugfs interface and the
> wlan interface immediately was brought up and connected successfully with my
> Network.
>
> So which is the right solution? I could make & test a patch for the simple
> solution easily.
>
Thanks for you extensive analysis. You seem to be absolutely right that
we need to properly setup the GPIO direction of the rfkill switch GPIO
pin. And it seems that all rt2x00 drivers (not only rt73usb) are
suffering from this.
The reason why we do most of the initialization at interface up is that
that is the earliest possible time we can get the firmware image from
userspace. A lot of the register programming we have to do for
initialization depend on the firmware being uploaded and running, hence
we initialize most at interface up time.
However, the correct fix IMHO here is to set the GPIO direction of the
rfkill switch GPIO pin to input at driver load time.
Find attached a patch that does this for all the rt2x00 devices. I hope
you are able to test whether this patch fixes the problem for you.
Once you have verified that the patch works, I will submit the changes
as a proper patch series for inclusion upstream.
---
Gertjan