headers
Jörn Clausen | 1 Dec 2010 20:36

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)

Permalink | Reply | 1 comment |
headers
Aleksey Cheusov | 1 Dec 2010 23:03
Picon
Favicon

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)

Permalink | Reply | 0 comments |
headers
Rui-Xiang Guo | 18 Dec 2010 04:44

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
Permalink | Reply | 5 comments |
headers
Jukka Ruohonen | 30 Dec 2010 17:07
Picon
Picon
Favicon

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.
Permalink | Reply | 2 comments |
headers
Steven Bellovin | 30 Dec 2010 18:15

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)

Permalink | Reply | 1 comment |
headers
Jukka Ruohonen | 31 Dec 2010 06:59
Picon
Picon
Favicon

Re: Enabling acpicpu(4) by default

On Thu, Dec 30, 2010 at 12:15:22PM -0500, Steven Bellovin wrote:
> What about pkgsrc/sysutils/estd -- will that work with acpicpu?

Yes, backwards compatibility is maintained; sysutils/estd or equivalent
solutions should work just fine. But it can be noted that the long-term
goal is to move towards a machine-independent in-kernel implementation, like
in most modern operating systems.

Generally there should be no visible changes to users. The machines that are
affected have been manufactured during the short period in which ACPI was not
yet widely used, but SpeedStep was moved to the "native", MSR-based, interface.
By assumption, this would correspond with Pentium 4 and AMD's Duron. The change
does not affect very old Pentiums that use ichlpcib(4) or even piixpcib(4) for
SpeedStep (largely due design mistakes done by Intel). On the bright side, it
is apparent that the different x86 processor power management facilities have
finally stabilized; presently both AMD and Intel use almost an identical
interface -- and ACPI is a central part of it.

- Jukka.
Permalink | Reply | 0 comments |

Gmane