wpi(4) and transmitter being off

[Stephen Borrill]

I've got a new laptop which appears to default to having the radio
transmitter off. I get the following errors:
wpi0: timeout waiting for thermal sensors calibration
wpi0: fatal firmware error

which a bit of research[1] suggests is down to the transmitter being off.
There is button which is meant to switch it on, but has no effect. Out of
interest, I tried Ubuntu which did report that the transmitter was off at
boot time. With Ubuntu, when I pressed the wireless button it turned on
the transmitter (and enabled the interface as eth1 appeared). When I
pressed the button again, the kernel flagged that the transmitter was off.
NetBSD should be doing the same (line 1590 in if_wpi.c), but clearly isn't
getting the notification (this is probably generally true - when I
inadvertently switched off the transmitter on a different laptop, I was
unable to switch it back on).

I'm using very current netbsd-4 with version 2.14.4 of the firmware.

[1] http://www.mail-archive.com/***@openbsd.org/msg45567.html

[d***@netbsd.org]

Post by Stephen Borrill
I've got a new laptop which appears to default to having the radio
transmitter off. I get the following errors: wpi0: timeout waiting for
thermal sensors calibration wpi0: fatal firmware error
which a bit of research[1] suggests is down to the transmitter being off.
There is button which is meant to switch it on, but has no effect. Out of
interest, I tried Ubuntu which did report that the transmitter was off at
boot time. With Ubuntu, when I pressed the wireless button it turned on
the transmitter (and enabled the interface as eth1 appeared). When I
pressed the button again, the kernel flagged that the transmitter was
off. NetBSD should be doing the same (line 1590 in if_wpi.c), but clearly
isn't getting the notification (this is probably generally true - when I
inadvertently switched off the transmitter on a different laptop, I was
unable to switch it back on).
I'm using very current netbsd-4 with version 2.14.4 of the firmware.

You are right. This error appears when the transmitter is off. For my card,
you can press the button and the transmitter switch to on even if the
driver is not launched.

The current code calls wpi_stop when we received an event "transmitter is
off" and so we disable interrupt for the card. It is wrong because we can't
receive the int "transmitter is on".

I'm working on a patch for your issue but currently I have an hard lock
during the transition off -> on. I'm still try to understand what happens
but it is a bit difficult to understand what we must do without any specs.

I hope I can send more news quickly. Take cares.

[Stephen Borrill]

Post by d***@netbsd.org

Post by Stephen Borrill
I've got a new laptop which appears to default to having the radio
transmitter off. I get the following errors: wpi0: timeout waiting for
thermal sensors calibration wpi0: fatal firmware error
which a bit of research[1] suggests is down to the transmitter being off.
There is button which is meant to switch it on, but has no effect. Out of
interest, I tried Ubuntu which did report that the transmitter was off at
boot time. With Ubuntu, when I pressed the wireless button it turned on
the transmitter (and enabled the interface as eth1 appeared). When I
pressed the button again, the kernel flagged that the transmitter was
off. NetBSD should be doing the same (line 1590 in if_wpi.c), but clearly
isn't getting the notification (this is probably generally true - when I
inadvertently switched off the transmitter on a different laptop, I was
unable to switch it back on).
I'm using very current netbsd-4 with version 2.14.4 of the firmware.

You are right. This error appears when the transmitter is off. For my card,
you can press the button and the transmitter switch to on even if the
driver is not launched.

Part of the confusion is that with this case the LEDs light up underneath
an unmarked uniform black panel, so I didn't even know where to look for a
light!

It would be useful if we could explicitly spot the transmitter was off and
flag that as such rather than having messages implying it!

Post by d***@netbsd.org
The current code calls wpi_stop when we received an event "transmitter is
off" and so we disable interrupt for the card. It is wrong because we can't
receive the int "transmitter is on".

Yes, spotted that.

After having worked out that "ifconfig wpi0 up" would switch the interface
into RUNNING iff the transmitter was on, I was able to at least print a
message at boot time giving a count down asking for the transmitter button
to be pressed. So it's liveable with (and I'll be asking my OEM supplier
about enabling the transmitter by default), but not ideal.

If we can get the transmitter is on signal, that's going to be great too.

Thanks for your help,

[d***@netbsd.org]

On Mon, Aug 06, 2007 at 10:00:49AM +0100, Stephen Borrill wrote:
[snip]

Post by Stephen Borrill
Yes, spotted that.
After having worked out that "ifconfig wpi0 up" would switch the
interface into RUNNING iff the transmitter was on, I was able to at least
print a message at boot time giving a count down asking for the
transmitter button to be pressed. So it's liveable with (and I'll be
asking my OEM supplier about enabling the transmitter by default), but
not ideal.
If we can get the transmitter is on signal, that's going to be great too.

Can you test the following patch. It tests the status of the transmitter
when we init the card and improve off->on transition.

Note the patch is for current. I don't think you will have trouble to run
in on netbsd-4. Just remove the last args to workqueue_enqueue.

Take cares.

[Stephen Borrill]

Post by d***@netbsd.org
[snip]

Post by Stephen Borrill
Yes, spotted that.
After having worked out that "ifconfig wpi0 up" would switch the
interface into RUNNING iff the transmitter was on, I was able to at least
print a message at boot time giving a count down asking for the
transmitter button to be pressed. So it's liveable with (and I'll be
asking my OEM supplier about enabling the transmitter by default), but
not ideal.
If we can get the transmitter is on signal, that's going to be great too.

Can you test the following patch. It tests the status of the transmitter
when we init the card and improve off->on transition.

N.B. I've not tested this yet.

At a quick glance, this appears to keep the interface in the running state
when the transmitter is off. RUNNING vs not is the only way I can think of
for userland to detect whether the transmitter is on or not, i.e. this
patch will improve the reporting as far as I can see in dmesg (yes, I
_could_ parse that for transmitter state), but will make it _more_
difficult to prompt the user to switch it on. Perhaps an ioctl or sysctl
to retrieve the transmitter state?

[Arnaud Degroote]

Post by Stephen Borrill

Post by d***@netbsd.org
Can you test the following patch. It tests the status of the transmitter
when we init the card and improve off->on transition.

N.B. I've not tested this yet.
At a quick glance, this appears to keep the interface in the running
state when the transmitter is off. RUNNING vs not is the only way I can
think of for userland to detect whether the transmitter is on or not,
i.e. this patch will improve the reporting as far as I can see in dmesg
(yes, I _could_ parse that for transmitter state), but will make it
_more_ difficult to prompt the user to switch it on. Perhaps an ioctl or
sysctl to retrieve the transmitter state?

I can remove the IFF_RUNNING and IFF_OACTIVE in the on->off transition, it
is not a problem. I'm not really sure it will be help userland (and user)
that he must switch the transmitter on.

Currently, on an off->on transition, on my configuration, dhclient is
automaticly restarted and I can use my network.

I can add a sysctl to retrieve the transmitter state but I'm not sure it
really solves the issue. I think that with the message and the man page, it
is quite clear that he must turn the switch on.

You can find an updated patch on
http://zulzul.free.fr/wpi/test/wpi_rfkill.diff.

[Greg Troxel]

Post by Arnaud Degroote
I can remove the IFF_RUNNING and IFF_OACTIVE in the on->off transition, it
is not a problem. I'm not really sure it will be help userland (and user)
that he must switch the transmitter on.

Originally IFF_RUNNING simply meant 'resources have been allocated for
this driver'. That flag isn't supposed to be used by anything outside
the driver. In Linux, it's used for link detection, and maybe also on
Solaris. So using it for transmitter enabled seems likely to cause
incompatibilities.

IFF_OACTIVE is about not having any txq resources left, so that
enqueuing a packet shouldn't invoke the start routine, or perhaps rather
that the packet should not be written to the hardware. So that really
doesn't seem appropriate here.

Perhaps 'ifconfig wpi0 up' should return an error if the killswitch is
on, with EPERM, or something like that. But that may not be helpful
overall.

How about a new media state 'disabled' in addition to active and no
carrier? That's really what's going on.



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stephen Borrill]

Post by Arnaud Degroote

Post by Stephen Borrill
At a quick glance, this appears to keep the interface in the running
state when the transmitter is off. RUNNING vs not is the only way I can
think of for userland to detect whether the transmitter is on or not,
i.e. this patch will improve the reporting as far as I can see in dmesg
(yes, I _could_ parse that for transmitter state), but will make it
_more_ difficult to prompt the user to switch it on. Perhaps an ioctl or
sysctl to retrieve the transmitter state?

I can remove the IFF_RUNNING and IFF_OACTIVE in the on->off transition, it
is not a problem. I'm not really sure it will be help userland (and user)
that he must switch the transmitter on.

Greg's input on the intended meaning of IFF_RUNNING is useful - the fact
that at the moment it can be used to approximate to transmitter on/off is
a side-effect and should not be relied on.

Post by Arnaud Degroote
Currently, on an off->on transition, on my configuration, dhclient is
automaticly restarted and I can use my network.
I can add a sysctl to retrieve the transmitter state but I'm not sure it
really solves the issue. I think that with the message and the man page, it
is quite clear that he must turn the switch on.

You forget that some people want to build embedded or end-user products
based on NetBSD :-)

For my needs:
At early boot time, we determine active interfaces as quickly as possible.
At this point we need to prompt the user to switch on radio if they
intend to use wifi. Associating with an AP takes some time, there's no
point in going through this if they don't want to use it (or cannot
because the transmitter is off). We need to associate with an AP before
running dhclient for reliability.
dhclient is run on interfaces and settings from network required for rest
of boot are retrieved.

I think a sysctl would be neatest solution then we can explicitly retrieve
transmitter status rather than relying in lucky side-effects.

Post by Arnaud Degroote
You can find an updated patch on
http://zulzul.free.fr/wpi/test/wpi_rfkill.diff.

I'll try it when I am back in the office tomorrow.

[Joerg Sonnenberger]

Post by Arnaud Degroote
I can remove the IFF_RUNNING and IFF_OACTIVE in the on->off transition, it
is not a problem. I'm not really sure it will be help userland (and user)
that he must switch the transmitter on.

What about making it a proper media state?

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Scheler]

Post by Greg Troxel
Originally IFF_RUNNING simply meant 'resources have been allocated for
this driver'. That flag isn't supposed to be used by anything outside
the driver. In Linux, it's used for link detection, and maybe also on
Solaris.

No, it is mostly meaningless under Solaris, too.

Link detection is very difficult in Solaris because it works differently
depending on who wrote the driver. For a lot of drivers
"dmesg | grep <drivername>" is the only way to figure out the link state.

Kind regards

[DEGROOTE Arnaud]

I better understand your need now.

I have added a sysctl tree to retrieve the status of the hw transmitter.
Can you try the patch http://zulzul.free.fr/wpi/test/wpi_rfkill2.diff
and tells me if it solves your problem?

--
Arnaud Degroote
***@netbsd.org

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de