Ilya Kantsedikas | 1 Dec 19:30 2010
Picon

No luck with wi-fi on x86_64

Hi all

I am interested in migrating from Linux to NetBSD as I find the NetBSD
approach to what an OS should be like neater. There is however a major
snag in that none of the wi-fi adapters I have seem to agree with
NetBSD-5.{0.2;1}-amd64 on my Vaio laptop (Vaio VGN-SZ7RVN)

The built-in Intel 3945 (wpi), seems to have firmware problems on
amd64 (prints out the error message: "fatal firmware error" whenever I
try to bring it up - there is no such problem on i386 port and it
works with other OSs so the hardware is fine). I have tried various
firmware versions with no success. There seems to be a PR with exactly
the same problem described but it appears it hasn't been followed up
since it was posted (http://gnats.netbsd.org/41833).

Having heard that Atheros-based cards are better supported I got one
of them - a TP-Link TL-WN310G CardBus adapter. Alas this also didn't
work causing a kernel panic whenever the adapter is inserted. Again I
have checked the hardware with my linux and NetBSD/i386 installation
and it is working. Again there is a PR (http://gnats.netbsd.org/41175)
with not much in the way of follow-up.

The reason why I don't want to go with the 32 bit port is that I have
4GB of ram and it seems silly to not use a gig having paid for it in
the first place. Could you please enlighten me if there are any ways
of getting around these wi-fi problems or indeed wi-fi adapters that
definitely will work with the amd64 port.

Many thanks

(Continue reading)

Sad Clouds | 1 Dec 19:48 2010

Re: No luck with wi-fi on x86_64

On Wed, 1 Dec 2010 18:30:15 +0000
Ilya Kantsedikas <i.kantsedikas <at> gmail.com> wrote:

> Hi all
> 
> I am interested in migrating from Linux to NetBSD as I find the NetBSD
> approach to what an OS should be like neater. There is however a major
> snag in that none of the wi-fi adapters I have seem to agree with
> NetBSD-5.{0.2;1}-amd64 on my Vaio laptop (Vaio VGN-SZ7RVN)

Hi, I have a nettop with network adapters that are not supported by NetBSD. I recently bought Asus WL-167G V2
USB adapter and it is supported by rum(4) driver. It seems to work pretty well on x86_64.

Here is a link:

http://www.amazon.co.uk/WL-167G-Wireless-Adaptor-802-11g-54Mbps/dp/B000KFQR5M/ref=sr_1_3?ie=UTF8&qid=1291228956&sr=8-3

Jörn Clausen | 1 Dec 20:36 2010

lockup of Atom 330 machine?

Hi!

I just migrated my personal web server to an Atom 330 based machine.
After about one day "in the wild", the machine locked up. According to
the logs (e.g. /var/log/cron) the machine was completely frozen until
I resetted it. A dmesg output is attached. Are there any known
problems with this hardware? Is there anything I can trim from the
kernel? I have no physical access to the machine, so I am limited in
my possibilities to debug it.

cpuid reports

"         Intel(R) Atom(TM) CPU D510    <at>  1.66GHz"

dmesg output is (MAC address removed)

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 5.1 (GENERIC) #0: Sat Nov  6 13:19:33 UTC 2010
	builds <at> b6.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/amd64/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/amd64/compile/GENERIC
total memory = 2031 MB
avail memory = 1953 MB
timecounter: Timecounters tick every 10.000 msec
RTC BIOS diagnostic error 80<clock_battery>
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
SMBIOS rev. 2.5  <at>  0xe4410 (25 entries)
(Continue reading)

Aleksey Cheusov | 1 Dec 23:03 2010
Picon

Re: lockup of Atom 330 machine?

> Hi!

> I just migrated my personal web server to an Atom 330 based machine.
> After about one day "in the wild", the machine locked up. According to
> the logs (e.g. /var/log/cron) the machine was completely frozen until
> I resetted it. A dmesg output is attached. Are there any known
> problems with this hardware? Is there anything I can trim from the
> kernel? I have no physical access to the machine, so I am limited in
> my possibilities to debug it.

I've been using NetBSD on Atom330-based machine since autumn 2009
as a workstation. I cannot remember any hangs up. Though I had some
problems with it.

HDD.
http://mail-index.netbsd.org/port-amd64/2010/01/08/msg001046.html
I'm still using the patch proposed by Joerg.
I haven't checked whether it is still necessary, though.

USB.
http://blog.gmane.org/gmane.os.netbsd.devel.performance
This was a temporary problem. I don't know how to reproduce it.
I rarely use flashes.

USB.
http://mail-index.netbsd.org/port-amd64/2010/07/12/msg001210.html
I don't know answers to those questions.

Audio.
http://mail-index.netbsd.org/netbsd-users/2010/03/14/msg005815.html
(Continue reading)

Pouya D. Tafti | 10 Dec 13:24 2010

thank you for the updated compat_linux, rpm2pkg, emulators/suse113*, etc.

With the relatively recent updates to Linux emulation support in the
kernel and the new openSUSE 11.3 compat libraries in pkgsrc
(meta-pkgs/suse113), I can now successfully run the latest version of
MATLAB (7.11) as well as the latest beta release of Opera 11 (with
64-bit Adobe Flash and sound too; sound requires a 64-bit
libflashsupport binary) under emulation on NetBSD/amd64-current.
MATLAB even seems to run several times faster on my NetBSD laptop than
it does on a 2x4-core Mac Pro running Mac OS X 11.6.5, which I use at
work (based on a single FFT test)!

In the end, it seems that the only "Linux" I can make peace with is
Linux emulation under NetBSD. :-)

I am extremely grateful for all of this; since I don't know to whom I
should direct my thanks, I am posting them here.

Thank you.

Pouya

Piotr Adamus | 10 Dec 14:00 2010
Picon

Re: thank you for the updated compat_linux, rpm2pkg, emulators/suse113*, etc.

Hello Pouya,

are you able to maybe check Java on amd64 within Linux emulation? I
mean this package: http://pkgsrc.se/lang/sun-jdk6

Are you able to check the plugin within firefox? As you confirmed
Flash works so that's a good sign.

Thank you.

Kr.

Piotr.

On Fri, Dec 10, 2010 at 1:24 PM, Pouya D. Tafti <pouya <at> san-serriffe.org> wrote:
> With the relatively recent updates to Linux emulation support in the
> kernel and the new openSUSE 11.3 compat libraries in pkgsrc
> (meta-pkgs/suse113), I can now successfully run the latest version of
> MATLAB (7.11) as well as the latest beta release of Opera 11 (with
> 64-bit Adobe Flash and sound too; sound requires a 64-bit
> libflashsupport binary) under emulation on NetBSD/amd64-current.
> MATLAB even seems to run several times faster on my NetBSD laptop than
> it does on a 2x4-core Mac Pro running Mac OS X 11.6.5, which I use at
> work (based on a single FFT test)!
>
> In the end, it seems that the only "Linux" I can make peace with is
> Linux emulation under NetBSD. :-)
>
> I am extremely grateful for all of this; since I don't know to whom I
> should direct my thanks, I am posting them here.
(Continue reading)

Rui-Xiang Guo | 18 Dec 04:44 2010

Re: wip/chromium

> I import the chromium-7.0.517.43 in to wip and add the full support on *BSD
> include DragonFly. Of course, it remains the support on Linux.
> So you may have a try if you are interesting in it.
> I have a full build on NetBSD-5.1/amd64 but it still need to do some debug.
> I will find some time to test it under i386. Any volunteer is welcome. :)

I also have made a full build on NetBSD-5.1/i386 but still get a core dump
due to tcmalloc. Has any one ever tested tcmalloc (e.g. with mysql)
under NetBSD? Just a quick review, tcmalloc use some memory functions that
we have not yet implemented under NetBSD-5.1 (e.g. pvalloc()).

-rxg

Pouya D. Tafti | 18 Dec 08:16 2010

Re: wip/chromium

On 18 December 2010 04:44, Rui-Xiang Guo <rxg <at> lavabit.com> wrote:
>> I import the chromium-7.0.517.43 in to wip and add the full support on *BSD
>> include DragonFly. Of course, it remains the support on Linux.
>> So you may have a try if you are interesting in it.
>> I have a full build on NetBSD-5.1/amd64 but it still need to do some debug.
>> I will find some time to test it under i386. Any volunteer is welcome. :)

Thank you for working on this.  The package compiled successfully for
me on amd64-current (with the codecs option; I used the sources from
around 8 Dec.), but it immediately segfaults in __locatime50 upon
execution.  I suppose I shall have to recompile with debugging symbols
to provide more useful details.

p.

Jukka Ruohonen | 30 Dec 17:07 2010
Picon
Picon

Enabling acpicpu(4) by default

Hello.

I would like to enable acpicpu(4) in the i386 and amd64 GENERIC kernels.
The following options(4) must be commented out for this:

	- INTEL_ONDEMAND_CLOCKMOD
	- ENHANCED_SPEEDSTEP
	- EST_FREQ_USERWRITE
	- POWERNOW_K7
	- POWERNOW_K8

As can be read from comments and CVS logs, the listed options are also
increasingly difficult to maintain. From a maintenance point of view, the
used linear interpolation was an improvement from the older table-based
approach, but there are cases where this overestimates the frequencies and
hence carries the risk of writing garbage values to the registers. Against
this, acpicpu(4) can be seen as going back to the roots; most of the existing
tables in "est.c" were actually collected from ACPI information.

Moreover, without acpicpu(4), NetBSD is not going to support such things as
C-states, AMD processors newer than K8, CPU thermal management, or TurboBoost.
No functionality will be lost, but the GENERIC kernels can not provide
out-of-the-box experience for both Pentium III and Core i7.

- Jukka.

Steven Bellovin | 30 Dec 18:15 2010

Re: Enabling acpicpu(4) by default

On Dec 30, 2010, at 11:07 51AM, Jukka Ruohonen wrote:

> Hello.
> 
> I would like to enable acpicpu(4) in the i386 and amd64 GENERIC kernels.
> The following options(4) must be commented out for this:
> 
> 	- INTEL_ONDEMAND_CLOCKMOD
> 	- ENHANCED_SPEEDSTEP
> 	- EST_FREQ_USERWRITE
> 	- POWERNOW_K7
> 	- POWERNOW_K8
> 
> As can be read from comments and CVS logs, the listed options are also
> increasingly difficult to maintain. From a maintenance point of view, the
> used linear interpolation was an improvement from the older table-based
> approach, but there are cases where this overestimates the frequencies and
> hence carries the risk of writing garbage values to the registers. Against
> this, acpicpu(4) can be seen as going back to the roots; most of the existing
> tables in "est.c" were actually collected from ACPI information.
> 
> Moreover, without acpicpu(4), NetBSD is not going to support such things as
> C-states, AMD processors newer than K8, CPU thermal management, or TurboBoost.
> No functionality will be lost, but the GENERIC kernels can not provide
> out-of-the-box experience for both Pentium III and Core i7.
> 
What about pkgsrc/sysutils/estd -- will that work with acpicpu?

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

(Continue reading)


Gmane