NetBSD and ASUS's EeeBox

[Quentin Garnier]

Hi all,

I thought it'd be interesting to have information about how badly the
EeeBox is currently supported by NetBSD, and how close we are to make it
a useful piece of hardware when running NetBSD.

I've had mine for I think more than a month now but the progress has
been very slow.  One reason for that is that neither the wireless
(Ralink) or the gigabit ethernet (Realtek) work under NetBSD-current.

What I have achieved so far:

  - A somewhat working port of OpenBSD's support for newest Ralink
    chips.  As it is, I don't expect it to work in WPA, but it does
    work in WEP.  There is an odd behaviour with channel selection, as
    well as with wpa_supplicant.

  - I've started working on making the re(4) work.  Strangely enough,
    with some additional calls to re_reset() at attach time, and also a
    magic printf(), it will sometimes work rather nicely, but the rest
    of the time it won't produce an interrupt.  It appears that
    rgephy(4) is in need of a lot of work (which mostly consists in
    sending a specific stream of magic numbers to magic registers
    depending on the exact model of the chip).

The rest is pretty much untested.  Yesterday I had a first try with the
X.org we have now in the tree, and the results are not very conclusive.
It insisted on using 1024x768 on my 1080p TV.  It seems that an even
more current xf86-video-intel might help with that.

I have yet to look at the azalia chip, and the one feature that will be
critical to have on such a box, ACPI S3 support.

Note that it is not a very fast machine.  It took 6 hours to build the
base system and X.org on it.

--
Quentin Garnier - cube@... - cube@...
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

[Quentin Garnier]

On Fri, Sep 05, 2008 at 05:33:37PM +0200, Quentin Garnier wrote:
[...]

Oh, I forgot to think of the dmesg fetishists.

http://taryn.cubidou.net/~cube/netbsd/eeebox.dmesg

(Note that the DVD burner is external.)

--
Quentin Garnier - cube@... - cube@...
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

[jcarnat]

Hello,

What about having those informations updated on ports/i386/eee.html ?
Maybe changing the web page title to "NetBSD/i386 on Asus Eee*"...

My 900 had issues with soundcard, while my 701 was working.
It is now 100% functionning though.

Maybe it would be nice to get dmesgs, pcictl output and a "what works,
what doesn't" list for the 900D, 901, 1000, 1000H... updated on this page
too ?

Regards,
     Jo

Le Ven 5 septembre 2008 17:33, Quentin Garnier a écrit :

> Hi all,
>
> I thought it'd be interesting to have information about how badly the
> EeeBox is currently supported by NetBSD, and how close we are to make it
> a useful piece of hardware when running NetBSD.
>
> I've had mine for I think more than a month now but the progress has
> been very slow.  One reason for that is that neither the wireless
> (Ralink) or the gigabit ethernet (Realtek) work under NetBSD-current.
>
> What I have achieved so far:
>
>   - A somewhat working port of OpenBSD's support for newest Ralink
>     chips.  As it is, I don't expect it to work in WPA, but it does
>     work in WEP.  There is an odd behaviour with channel selection, as
>     well as with wpa_supplicant.
>
>   - I've started working on making the re(4) work.  Strangely enough,
>     with some additional calls to re_reset() at attach time, and also a
>     magic printf(), it will sometimes work rather nicely, but the rest
>     of the time it won't produce an interrupt.  It appears that
>     rgephy(4) is in need of a lot of work (which mostly consists in
>     sending a specific stream of magic numbers to magic registers
>     depending on the exact model of the chip).
>
> The rest is pretty much untested.  Yesterday I had a first try with the
> X.org we have now in the tree, and the results are not very conclusive.
> It insisted on using 1024x768 on my 1080p TV.  It seems that an even
> more current xf86-video-intel might help with that.
>
> I have yet to look at the azalia chip, and the one feature that will be
> critical to have on such a box, ACPI S3 support.
>
> Note that it is not a very fast machine.  It took 6 hours to build the
> base system and X.org on it.
>
> --
> Quentin Garnier - cube@... - cube@...
> "See the look on my face from staying too long in one place
> [...] every time the morning breaks I know I'm closer to falling"
> KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
>

[Frederik Sausmikat]

Joel CARNAT wrote:

> My 900 had issues with soundcard, while my 701 was working.
> It is now 100% functionning though.

Both, sound and ath? May I ask, what you did to make it work again?

[jcarnat]

Le Ven 5 septembre 2008 21:18, Frederik Sausmikat a écrit :
> Joel CARNAT wrote:
>
>> My 900 had issues with soundcard, while my 701 was working.
>> It is now 100% functionning though.
>
> Both, sound and ath? May I ask, what you did to make it work again?
>

yes: sound, wireless, LAN, suspend/resume, DRI, clockmod.

Sound works since a PR has been recently corrected - a week or two ago.
Wireless works since you patch your source tree with the patch that is
indicated on the Eee support status page. I had to only untar syssrc.tgz
to have it working.

I keep a copy of my 4.99.72 kernel here :
http://www.tumfatig.net/dmesg/ASUS%20Eee%20PC%20900/NetBSD%204.99.64/netbsd.bz2
Help yourself ;)

Regards,
    Jo

[Anders Lindgren-2]

On Fri, 5 Sep 2008, Joel CARNAT wrote:

> Wireless works since you patch your source tree with the patch that is
> indicated on the Eee support status page.

No luck for me there.

> I keep a copy of my 4.99.72 kernel here :

I tried your kernel -- I get the exact same failure as with 4.99.72
GENERIC+atheee.patch from 20080816, and a GENERIC+atheee.patch kernel I
built tonight just for reference:

- if WEP encryption is enabled in the AP, wiconfig ath0 -D finds nothing
unless I first set both ssid and nwkey on the interface in advance. After
ssid+nwkey are set, it does find the AP -- but not always on the first
run.

- setting the nwkey with ifconfig produces the error(?) "setting keyix 0
w/o power".

- If I turn off WEP, wiconfig ath0 -D immediately finds the AP.

- dhclient has problems acquiring an IP address, and must sometimes be
run 2-3 times before succeeding.

- after the network is finally up, a constant 32-35% packet loss is
experienced, seemingly in bursts. This is app. 4m from the AP, and the old
laptop has 0% packetloss everywhere in the house.

- while any kind of traffic is passing over the interface (also during
DHCPDISCOVER), spurious

   "ath0: device timeout (txq 1, txintrperiod N)" (N=1..5)

messages are produced. Setting txintrperiod to 1 on boot in sysctl.conf
seems to improve the rate at which it happens, sometimes.

I've tried disabling ACPI on boot (remembering old posts about interrupt
routing problems), but I didn't notice any difference apart from
"poweroff" failing to actually power off the computer. It just halts and
prompts for a keypress to reboot instead.

Very weird that your kernel works on your eee900 but not mine. I will test
these kernels on other networks this weekend to rule out incompatibility
with this particular old DLink900AP+ (802.11b AP), but it looks a lot more
like an interrupt problem given the frequent TX queue device timeouts.

Grateful for clues,
ali:)

[jcarnat]

Hello,

Le Sam 6 septembre 2008 1:48, Anders Lindgren a écrit :

> On Fri, 5 Sep 2008, Joel CARNAT wrote:
>
>> Wireless works since you patch your source tree with the patch that is
>> indicated on the Eee support status page.
>
> No luck for me there.
>
>> I keep a copy of my 4.99.72 kernel here :
>
> I tried your kernel -- I get the exact same failure as with 4.99.72
> GENERIC+atheee.patch from 20080816, and a GENERIC+atheee.patch kernel I
> built tonight just for reference:
>
> - if WEP encryption is enabled in the AP, wiconfig ath0 -D finds nothing
> unless I first set both ssid and nwkey on the interface in advance. After
> ssid+nwkey are set, it does find the AP -- but not always on the first
> run.
>
> - setting the nwkey with ifconfig produces the error(?) "setting keyix 0
> w/o power".
>
> - If I turn off WEP, wiconfig ath0 -D immediately finds the AP.
>
> - dhclient has problems acquiring an IP address, and must sometimes be
> run 2-3 times before succeeding.
>
> - after the network is finally up, a constant 32-35% packet loss is
> experienced, seemingly in bursts. This is app. 4m from the AP, and the old
> laptop has 0% packetloss everywhere in the house.
>
> - while any kind of traffic is passing over the interface (also during
> DHCPDISCOVER), spurious
>
>    "ath0: device timeout (txq 1, txintrperiod N)" (N=1..5)
>
> messages are produced. Setting txintrperiod to 1 on boot in sysctl.conf
> seems to improve the rate at which it happens, sometimes.
>
> I've tried disabling ACPI on boot (remembering old posts about interrupt
> routing problems), but I didn't notice any difference apart from
> "poweroff" failing to actually power off the computer. It just halts and
> prompts for a keypress to reboot instead.
>
> Very weird that your kernel works on your eee900 but not mine. I will test
> these kernels on other networks this weekend to rule out incompatibility
> with this particular old DLink900AP+ (802.11b AP), but it looks a lot more
> like an interrupt problem given the frequent TX queue device timeouts.
>

Well, from what I understood, the only thing that doesn't work on yours in
WEP connection to a WLAN, right ?

I don't do WEP here, I only use WPA2-Personnal (with a Linksys box).

Try using WPA or clear network instead of WEP to see if that's the issue.

Regards,
     Jo

[Anders Lindgren-2]

On Sat, 6 Sep 2008, Joel CARNAT wrote:

> Well, from what I understood, the only thing that doesn't work on yours in
> WEP connection to a WLAN, right ?

No, WEP only interferes with scanning for APs in that it doesn't seem to
find the AP  unless I set the ssid and nwkey first. Sorry if that wasn't
clear. That's pretty weird behaviour; I don't know if that could somehow
be a simple side effect of the massive packet loss or if it's a separate
issue.

I still have a 32-35% constant packet loss with regular txq device
timeouts, even on a wide open WLAN. WEP itself works -- once an ssid and
nwkey has been assigned to the ath0 interface.

Going to try it with other APs tonight, but given the device errors, I
suspect it's a driver or interrupt problem.

/ali:)

[jcarnat]

Le Sam 6 septembre 2008 14:08, Anders Lindgren a écrit :

> On Sat, 6 Sep 2008, Joel CARNAT wrote:
>
>> Well, from what I understood, the only thing that doesn't work on yours
>> in
>> WEP connection to a WLAN, right ?
>
> No, WEP only interferes with scanning for APs in that it doesn't seem to
> find the AP  unless I set the ssid and nwkey first. Sorry if that wasn't
> clear. That's pretty weird behaviour; I don't know if that could somehow
> be a simple side effect of the massive packet loss or if it's a separate
> issue.
>
> I still have a 32-35% constant packet loss with regular txq device
> timeouts, even on a wide open WLAN. WEP itself works -- once an ssid and
> nwkey has been assigned to the ath0 interface.
>
> Going to try it with other APs tonight, but given the device errors, I
> suspect it's a driver or interrupt problem.
>

Maybe, you can also check booting OpenBSD 4.4 or Ubuntu on USB.
To see if it's an AP or driver problem.

Regards,
   Jo

[Anders Lindgren-2]

On Sat, 6 Sep 2008, Joel CARNAT wrote:

> Le Sam 6 septembre 2008 14:08, Anders Lindgren a écrit :
>> On Sat, 6 Sep 2008, Joel CARNAT wrote:
>>
>>> Well, from what I understood, the only thing that doesn't work on yours
>>> in
>>> WEP connection to a WLAN, right ?
>>
>> No, WEP only interferes with scanning for APs in that it doesn't seem to
>> find the AP  unless I set the ssid and nwkey first. Sorry if that wasn't
>> clear. That's pretty weird behaviour; I don't know if that could somehow
>> be a simple side effect of the massive packet loss or if it's a separate
>> issue.
>>
>> I still have a 32-35% constant packet loss with regular txq device
>> timeouts, even on a wide open WLAN. WEP itself works -- once an ssid and
>> nwkey has been assigned to the ath0 interface.
>>
>> Going to try it with other APs tonight, but given the device errors, I
>> suspect it's a driver or interrupt problem.
>>
>
> Maybe, you can also check booting OpenBSD 4.4 or Ubuntu on USB.
> To see if it's an AP or driver problem.

   I just tested the eee at a friend's place, and.. whaddyaknow. It Just
Works(tm), flawless, on 802.11g networks, with WPA2 and everything.

   So, the issue appears to be exclusively with ath0 running in 802.11b
mode. Well, that's bad I suppose, but my friend even had a spare .11g AP
lying around that I could bring right home with me, so right now I am VERY
pleased. :-)

Best regards,
ali:)