Eric Schnoebelen | 2 Sep 2006 01:14
Favicon

Re: Please test POWERNOW_K[78]


Juan RP writes:
- On Tue, 29 Aug 2006 00:05:52 -0500
- eric <at> cirr.com (Eric Schnoebelen) wrote:
- > Juan RP writes:
- > - The latest code for POWERNOW_K[78] is now in -current, if you have
- > - any AMD Athlon Mobile or Athlon 64 cpu, please try it out and
- > - report success/failure, etc.
- > 
- > 	I know this to be a bit late, but..
- > 
- > 	I have to report failure.. I've got an HP Pavilion
- > ze4500 Laptop with an AMD Atholon XP2500+ processor.
- > 
- > 	Under previous versions of the PowerNow support, it
- > would report being a PowerNow processor, but provide garbage
- > speed values.
- > 
- > 	Under the current PowerNow support, it reports as
- > having TS, FID, and VID, but doesn't offer up the PowerNow speed
- > control support.
- 
- Can you please rebuild your kernel with "options POWERNOW_DEBUG"?

	Done.  No additional output.. :(

	I've included the output from a 3.99.17 kernel (just the
CPU portion), followed by the full dmesg of the 4.0_BETA kernel.

-- CPU portion of dmesg from NetBSD 3.99.17 using modified GENERIC_LAPTOP:
(Continue reading)

Juan RP | 2 Sep 2006 11:48

Re: Please test POWERNOW_K[78]

On Fri, 01 Sep 2006 18:14:45 -0500
eric <at> cirr.com (Eric Schnoebelen) wrote:

> - Can you please rebuild your kernel with "options POWERNOW_DEBUG"?
> 
> 	Done.  No additional output.. :(

Ok, I've found the problem... looks like AMD_ERRATA_A0_CPUSIG is not
matching your CPU and needs to match it because your CPU is the one
that has the errata.

Linux checks for a x86_mask member to see if it's a K7 660[A0] CPU, but I
don't know what x86_mask is, so I think the following patch should work too:

Index: x86/include/powernow.h
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/include/powernow.h,v
retrieving revision 1.5
diff -u -p -r1.5 powernow.h
--- x86/include/powernow.h      27 Aug 2006 10:10:55 -0000      1.5
+++ x86/include/powernow.h      2 Sep 2006 09:46:49 -0000
 <at>  <at>  -71,7 +71,8  <at>  <at> 
 #define MSR_AMDK7_FIDVID_CTL           0xc0010041
 #define MSR_AMDK7_FIDVID_STATUS                0xc0010042
 #define AMD_PN_FID_VID                 0x06
-#define AMD_ERRATA_A0_CPUSIG           0x660
+#define AMD_ERRATA_660_CPUSIG          0x660
+#define AMD_ERRATA_660A0_CPUSIG        0x6a0

 #define PN7_FLAG_ERRATA_A0             0x01
(Continue reading)

Joel CARNAT | 2 Sep 2006 16:09
Favicon
Gravatar

Re: Please test POWERNOW_K[78]

Hi,

Here's an update of fully functionnal results on my Shuttle SN85G4v3.
It's a running an "AMD Athlon(tm) 64 Processor 3200+" and can run at
three different speeds (2000, 1800 and 1000 MHz).

Find testings results attached.

I run sysutils/estd on the /amd64 installation to automatically adjust
cpu freq (and it works OK).

Thanks guys for the work!

On Mon, Aug 07 2006 - 23:29, Juan RP wrote:
> 
> Hi,
> 
> The latest code for POWERNOW_K[78] is now in -current, if you have
> any AMD Athlon Mobile or Athlon 64 cpu, please try it out and
> report success/failure, etc.
> 
> The code works in Athlon 64 cpus (reported by Elad Efrat, Joel Carnat,
> Martjin Van Buul), and previously by Rhialto (powernow_k7.c for i386,
> previous version by Martin Vegiard).
> 
> Thanks for your collaboration.
> 
> 
Attachment (PNOW.tar.gz): application/x-tar-gz, 4937 bytes
(Continue reading)

Eric Schnoebelen | 3 Sep 2006 04:13
Favicon

Re: Please test POWERNOW_K[78]


Juan RP writes:
- On Fri, 01 Sep 2006 18:14:45 -0500
- eric <at> cirr.com (Eric Schnoebelen) wrote:
- 
- > - Can you please rebuild your kernel with "options POWERNOW_DEBUG"?
- > 
- > 	Done.  No additional output.. :(
- 
- Ok, I've found the problem... looks like AMD_ERRATA_A0_CPUSIG is not
- matching your CPU and needs to match it because your CPU is the one
- that has the errata.

	In trying that, and then googling for errata on the 660
and 6a0 CPU's, it seems that the AMD_ERRATA_A0_CPUSIG should
only apply to the 660 CPU's.. The 6a0 CPU's have a different
series of errata.. (660 is a K7 model 6, while 6a0 is a K7 model
10).

	However, removing the CPU signature vs the PST signature
check on my system allows it to work, and the CPU speed to be
changed. (yeah!)  Not sure how to best represent the "quirk" in
the code though.

	In reading various bits of information gathered from google,
it appears that it should also be able to gather the CPU clock
information from ACPI. Is there a way to gather that in the NetBSD
kernel? (although expecting that to be any more accurate than the
BIOS tables may be wishful thinking.)

(Continue reading)

Reinoud Zandijk | 3 Sep 2006 19:25
Picon

MPACPI interrupt problem found + fix

Dear folks,

as some of you might remember i had a serious problem running 
GENERIC.MPACPI on my hyperthreading P4 where GENERIC works fine and 
GENERIC.MP just crashes.

The problem manifested itself as generating 140.000 interrupts (!) per 
second slowing down the machine and esp. harddisc access etc. 
significantly. Doing a binary search on the source i eventually found the 
offending patch of the function mpacpi_nonpci_intr :

----------------------------
revision 1.38
date: 2006/08/12 16:19:13;  author: fvdl;  state: Exp;  lines: +3 -2
Record the ACPI global int in the interrupt structure for ISA interrupt
overrided (e.g. the SCI interrupt), so that it may be found correctly by
the ACPI interrupt establish function, should the number be different
from the original source.
-----------------------------

cvs rdiff -u -r 1.37 -r 1.38 src/sys/arch/x86/x86/mpacpi.c
Index: src/sys/arch/x86/x86/mpacpi.c
diff -u src/sys/arch/x86/x86/mpacpi.c:1.37 
src/sys/arch/x86/x86/mpacpi.c:1.38
--- src/sys/arch/x86/x86/mpacpi.c:1.37  Thu Jul 20 05:05:26 2006
+++ src/sys/arch/x86/x86/mpacpi.c       Sat Aug 12 16:19:13 2006
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-/*     $NetBSD: mpacpi.c,v 1.37 2006/07/20 05:05:26 kochi Exp $        */
+/*     $NetBSD: mpacpi.c,v 1.38 2006/08/12 16:19:13 fvdl Exp $ */

(Continue reading)

Hubert Feyrer | 8 Sep 2006 10:44
Picon
Favicon

PXE booting on amd64?


I had a user ask how to PXE boot NetBSD (preferably i386 in my/g4u case) 
on a 64bit machine. I don't know enough about PXE and its dependence on 
the hardware architecture, so the question was raised if a 64bit pxeboot 
is needed. Right now the amd64 port only has a /usr/mdec/pxeboot_ia32.bin 
...

Has anyone tried this, or can provide help how to PXEbboot NetBSD/i386 on 
a 64bit machine?

  - Hubert

---------- Forwarded message ----------
Date: Thu, 7 Sep 2006 15:18:34 -0500
From: William C <w.d.clayton <at> gmail.com>
To: hubert <at> feyrer.de
Subject: amd64 and g4u

Hey!

Love g4u, thanks for all your work on it. Ive used it to stamp out
some linux servers for my friends and it works like a champ.

Lately Ive been trying to make an image via g4u pxe with a dual core
pentium 4 3.0 ghz(no HT), and am told the amd64 build of the netbsd
stuff is necessary...

I just thought I'd ask if you knew of a place where I could get the
right pxe.bin ( currently the base.tgz in the amd64 set of netbsd 3 is
only a 32 bit binary ). It seems like the 32 bit pxe binary has
(Continue reading)

David Laight | 8 Sep 2006 18:26
Picon

Re: PXE booting on amd64?

On Fri, Sep 08, 2006 at 10:44:13AM +0200, Hubert Feyrer wrote:
> 
> I had a user ask how to PXE boot NetBSD (preferably i386 in my/g4u case) 
> on a 64bit machine. I don't know enough about PXE and its dependence on 
> the hardware architecture, so the question was raised if a 64bit pxeboot 
> is needed. Right now the amd64 port only has a /usr/mdec/pxeboot_ia32.bin 
> ...
> 
> Has anyone tried this, or can provide help how to PXEbboot NetBSD/i386 on 
> a 64bit machine?

Just pretend it is a 32 bit machine!
It doesn't 'become' 64 bit until after the kernel is loaded.

To boot a 64 bit kernel you need bootstrap code that understands
the 64 bit ELF - which the boot code in the amd64 tree does.

I believe the amd64 boot code (which is all 32bit code) can load
both amd64 and i386 kernels.
The i386 code can only boot i386 (I'm not sure why).

Of course, your root filesystems have to be different.

	David

--

-- 
David Laight: david <at> l8s.co.uk

Iain Hibbert | 10 Sep 2006 17:58

bluetooth on amd64

Hi,
   This week I cross-compiled an amd64/GENERIC kernel with bluetooth
enabled. I can't test it because I have no hardware, but it does compile
at least - is it ok to commit the below change to the amd64 port?

iain

Index: sys/arch/amd64/conf/files.amd64
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/conf/files.amd64,v
retrieving revision 1.28
diff -u -r1.28 files.amd64
--- sys/arch/amd64/conf/files.amd64	4 Sep 2006 02:16:03 -0000	1.28
+++ sys/arch/amd64/conf/files.amd64	10 Sep 2006 13:13:10 -0000
 <at>  <at>  -194,6 +194,8  <at>  <at> 

 include	"dev/usb/files.usb"

+include	"dev/bluetooth/files.bluetooth"
+
 include	"dev/ieee1394/files.ieee1394"
 include "dev/apm/files.apm"
 include "dev/acpi/files.acpi"
Index: sys/arch/amd64/conf/GENERIC
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.106
diff -u -r1.106 GENERIC
--- sys/arch/amd64/conf/GENERIC	26 Aug 2006 20:26:44 -0000	1.106
+++ sys/arch/amd64/conf/GENERIC	10 Sep 2006 13:13:21 -0000
(Continue reading)

Quentin Garnier | 10 Sep 2006 18:28

Re: bluetooth on amd64

On Sun, Sep 10, 2006 at 04:58:29PM +0100, Iain Hibbert wrote:
> Hi,
>    This week I cross-compiled an amd64/GENERIC kernel with bluetooth
> enabled. I can't test it because I have no hardware, but it does compile
> at least - is it ok to commit the below change to the amd64 port?

Please do.  You'll be more likely to get actual testing, and it's meant
to end up there in that exact shape.

> Index: sys/arch/amd64/conf/files.amd64
> ===================================================================
> RCS file: /cvsroot/src/sys/arch/amd64/conf/files.amd64,v
> retrieving revision 1.28
> diff -u -r1.28 files.amd64
> --- sys/arch/amd64/conf/files.amd64	4 Sep 2006 02:16:03 -0000	1.28
> +++ sys/arch/amd64/conf/files.amd64	10 Sep 2006 13:13:10 -0000
>  <at>  <at>  -194,6 +194,8  <at>  <at> 
> 
>  include	"dev/usb/files.usb"
> 
> +include	"dev/bluetooth/files.bluetooth"
> +
>  include	"dev/ieee1394/files.ieee1394"
>  include "dev/apm/files.apm"
>  include "dev/acpi/files.acpi"
> Index: sys/arch/amd64/conf/GENERIC
> ===================================================================
> RCS file: /cvsroot/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.106
> diff -u -r1.106 GENERIC
(Continue reading)

@ ebe | 10 Sep 2006 23:06

Re: Announcing the start of the NetBSD 4.0 release process

On Fri, Aug 25, 2006 at 07:44:09AM -0700, Jeff Rizzo wrote :

> HOW YOU CAN HELP
> ----------------
> 
> Please test NetBSD 4.0_BETA on your hardware!  A lot of work has
> gone into getting us this far, but we don't have access to every piece
> of hardware out there.  If you've used previous releases of NetBSD,
> please make sure all your devices continue to work; if you have
> spare machines, please test the installation procedures.  With your
> help, this will be the best release of NetBSD yet!
> 

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
    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 4.0_BETA (KIPIX_AMD64_04) #0: Mon Sep  4 21:14:24 CEST 2006
	eric <at> kipix.geodata.name:/reseau/build_release/amd64/obj/sys/arch/amd64/compile/KIPIX_AMD64_04
total memory = 1023 MB
avail memory = 979 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
timecounter: selected timecounter "i8254" frequency 1193182 Hz quality 100
mainbus0 (root)
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD Athlon(tm) 64 Processor 3000+, 1809.36 MHz
cpu0: features: e7dbfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features: e7dbfbff<PGE,MCA,CMOV,PAT,PSE36,MPC,NOX,MMXX,MMX>
(Continue reading)


Gmane