Prev: mmotm 2010-07-19 - e1000e vs. pm_qos_update_request issues
Next: [PATCH] GIC: Dont disable INT in ack callback
From: Mario 'BitKoenig' Holbe on 22 Jul 2010 19:00
Hello,

the b43 wireless driver inhibits access to /dev/hwrng while the wireless
network interface is down. When the interface is up, /dev/hwrng is
accessible:

root(a)ideapad ~ # uname -a
Linux ideapad 2.6.35-rc5-686 #1 SMP Tue Jul 13 16:16:00 UTC 2010 i686 GNU/Linux
root(a)ideapad ~ # grep name /proc/cpuinfo
model name : VIA Nano processor U2250 (1.6GHz Capable)
root(a)ideapad ~ # lsmod | grep via.rng
via_rng 1243 0
rng_core 2912 2 via_rng,b43
root(a)ideapad ~ # hexdump -n 10 /dev/hwrng
0000000 81f2 8497 71bb d900 f89f
000000a
root(a)ideapad ~ # ifconfig wlan0 down
root(a)ideapad ~ # hexdump -n 10 /dev/hwrng
hexdump: /dev/hwrng: No such device
root(a)ideapad ~ # ifconfig wlan0 up
root(a)ideapad ~ # hexdump -n 10 /dev/hwrng
0000000 86fc 5d33 4dec d97d da7b
000000a
root(a)ideapad ~ #

Aside from such a side-effect being heavily unexpected, this effect is
particularly annoying because it renders rngd failing to start at boot
time - especially when using NetworkManager which is usually started
later than the classic ifupdown methods.

I have no idea whether this issue belongs to the b43 driver or to the
rng core.


Thanks for your work & best regards
Mario
--
The only thing to be scared of, son, is tomorrow.
I don't live for tomorrow. Never saw the fun in it.
-- Denny Crane, Boston Legal
From: John W. Linville on 23 Jul 2010 10:50
On Fri, Jul 23, 2010 at 12:52:12AM +0200, Mario 'BitKoenig' Holbe wrote:
> Hello,
>
> the b43 wireless driver inhibits access to /dev/hwrng while the wireless
> network interface is down. When the interface is up, /dev/hwrng is
> accessible:

<snip>

> I have no idea whether this issue belongs to the b43 driver or to the
> rng core.

The hwrng driver is provided by the b43 hardware, which is shutdown
when the network interface is down. I'm not sure how one could expect
this to work.

John
--
John W. Linville Someday the world will need a hero, and you
linville(a)tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mario 'BitKoenig' Holbe on 23 Jul 2010 11:40
On Fri, Jul 23, 2010 at 10:32:19AM -0400, John W. Linville wrote:
> The hwrng driver is provided by the b43 hardware, which is shutdown
> when the network interface is down. I'm not sure how one could expect
> this to work.

Nope. It's provided by the VIA PadLock hardware (through the via-rng
driver). I'm not sure how one could expect this not to work when the
network interface provided by the b43 driver is down.

Well, maybe let's try to become a bit less offensive... :)
Probably there are two Hardware RNGs on that machine: one provided by
VIA PadLock through via-rng, one provided by BCM4312 through b43:
hw_random/via-rng.c: err = hwrng_register(&via_rng);
b43/main.c: err = hwrng_register(&wl->rng);

But at least now it's a bit more likely that the problem is located in
the rng core which should not render /dev/hwrng inaccessible when only
one of the RNGs unregisters.

However, what I don't fully understand is: I find only one way where b43
unregisters its RNG, which is via
b43_remove() -> b43_rng_exit() -> hwrng_unregister()
And, I'm really not sure if I got this right, but... I guess,
b43_remove() is only called when the module is removed from the kernel
and not when the network interface is shut down.

So, maybe it's not really rng core's fault?
I guess, b43 just stops delivering data through b43_rng_read() when the
hardware is shut down and instead returns ENODEV (which is btw. what I
get when I'm trying to read /dev/hwrng while b43 is down), and the rng
core just delivers this error up when it's trying to deliver the read
request to the b43 RNG.


Mario
--
User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten
From: John W. Linville on 23 Jul 2010 13:50
On Fri, Jul 23, 2010 at 05:31:02PM +0200, Mario 'BitKoenig' Holbe wrote:
> On Fri, Jul 23, 2010 at 10:32:19AM -0400, John W. Linville wrote:
> > The hwrng driver is provided by the b43 hardware, which is shutdown
> > when the network interface is down. I'm not sure how one could expect
> > this to work.
>
> Nope. It's provided by the VIA PadLock hardware (through the via-rng
> driver). I'm not sure how one could expect this not to work when the
> network interface provided by the b43 driver is down.

Alright, sorry I overlooked that. Although it still looks to me like
your current_rng must be the b43-provided one, or else you wouldn't
be experiencing this issue.

> Well, maybe let's try to become a bit less offensive... :)
> Probably there are two Hardware RNGs on that machine: one provided by
> VIA PadLock through via-rng, one provided by BCM4312 through b43:
> hw_random/via-rng.c: err = hwrng_register(&via_rng);
> b43/main.c: err = hwrng_register(&wl->rng);
>
> But at least now it's a bit more likely that the problem is located in
> the rng core which should not render /dev/hwrng inaccessible when only
> one of the RNGs unregisters.
>
> However, what I don't fully understand is: I find only one way where b43
> unregisters its RNG, which is via
> b43_remove() -> b43_rng_exit() -> hwrng_unregister()
> And, I'm really not sure if I got this right, but... I guess,
> b43_remove() is only called when the module is removed from the kernel
> and not when the network interface is shut down.
>
> So, maybe it's not really rng core's fault?
> I guess, b43 just stops delivering data through b43_rng_read() when the
> hardware is shut down and instead returns ENODEV (which is btw. what I
> get when I'm trying to read /dev/hwrng while b43 is down), and the rng
> core just delivers this error up when it's trying to deliver the read
> request to the b43 RNG.

Yes, I believe this is what the b43 hwrng is doing. I suspect you
need/want a way to influence current_rng to favor via-rng. You may
want to reference Documentation/hw_random.txt for further information.

Good luck!

John
--
John W. Linville Someday the world will need a hero, and you
linville(a)tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mario 'BitKoenig' Holbe on 23 Jul 2010 14:30
On Fri, Jul 23, 2010 at 01:32:46PM -0400, John W. Linville wrote:
> Alright, sorry I overlooked that. Although it still looks to me like
> your current_rng must be the b43-provided one, or else you wouldn't
> be experiencing this issue.

Yes. Unfortunately, the b43 module is loaded earlier than the via-rng
module: the former gets loaded via udev autodetection, the latter gets
loaded via my /etc/modules. Thus, the rng core selects b43 as the
"current" RNG.

> > I guess, b43 just stops delivering data through b43_rng_read() when the
> > hardware is shut down and instead returns ENODEV (which is btw. what I
> > get when I'm trying to read /dev/hwrng while b43 is down), and the rng
> Yes, I believe this is what the b43 hwrng is doing. I suspect you
> need/want a way to influence current_rng to favor via-rng. You may

Yes, once knowing what happens it was easy to find a work-around:

root(a)ideapad ~ # cat /etc/modprobe.d/local-b43-workaround.conf
# Work-around: b43 provides a Hardware RNG as well, but returns ENODEV
# on read() when the BCM4312 hardware is down.
# Ensure via-rng is loaded before this module. This way hw_random/core
# delivers read()s on /dev/hwrng to via-rng.
install b43 modprobe via-rng; modprobe --ignore-install b43 $CMDLINE_OPTS

> want to reference Documentation/hw_random.txt for further information.

Indeed, setting /sys/devices/virtual/misc/hw_random/rng_current would
probably be a cleaner solution :) Thanks for that.

However, I still somehow feel like this is a bug - either in the rng
core or in b43. One of both should IMHO be changed: either the rng core
to respect drivers not currently delivering data or (probably cleaner)
to provide an interface to suspend a driver, or the b43 driver to
unregister its rng when the hardware is shut down (or power it up when
the rng is accessed? probably a bit oversized :)).

Unfortunately, Documentation/hw_random.txt has no usage guidelines for
the rng core, i.e. how drivers should behave when no data is available.
It talks about a `hardware "has-data" flag', but I cannot find such a
thing in the code.


Thanks for your help and patience
Mario
--
File names are infinite in length where infinity is set to 255 characters.
-- Peter Collinson, "The Unix File System"
 |  Next  |  Last
Pages: 1 2
Prev: mmotm 2010-07-19 - e1000e vs. pm_qos_update_request issues
Next: [PATCH] GIC: Dont disable INT in ack callback