Subject: Re: port-i386/32937
To: None <port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: Stefan Sonnenberg-Carstens <stefan.sonnenberg@freenet.de>
List: netbsd-bugs
Date: 06/24/2006 14:10:02
The following reply was made to PR port-i386/32937; it has been noted by GNATS.

From: Stefan Sonnenberg-Carstens <stefan.sonnenberg@freenet.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-i386/32937
Date: Sat, 24 Jun 2006 16:09:27 +0200

 YONETANI Tomokazu schrieb:
 > The following reply was made to PR port-i386/32937; it has been noted by GNATS.
 >
 > From: YONETANI Tomokazu <qhwt+nbsd@les.ath.cx>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: port-i386/32937
 > Date: Sat, 24 Jun 2006 20:04:35 +0900
 >
 >  Hi.
 >  I'm trying to port your Enhanced SpeedStep driver for DragonFly BSD,
 >  and it seems to be successful for a few people so far, but one of the
 >  user has an issue with the freq/voltage table for his Pentium M 740
 >  (1.73GHz, FSB 533MHz).
 >  
 >  On his notebook, `rdmsr(MSR_PERF_STATUS)' returns 0x6120d2606000d26,
 >  which means IIUC that highest configuration is 1729MHz/1308mV and
 >  lowest configuration is 798MHz/988mV.  However entium_m_n740[] does not
 >  list this voltage, so the driver says it's not supported.  I added
 >  an alternate table for 740 like below and hooked it into
 >  pentium_m_dothan[], and it seems to work for him now.
 >  
 >  static const struct fq_info pentium_m_n740_2[] = {
 >  	{ 1733, 1308 },
 >  	{ 1333, 1148 },
 >  	{ 1067, 1068 },
 >  	{  800,  988 }
 >  };
 >  
 >  I don't know if Intel would release products under the same name
 >  with different setting, is it possible?  Have you received any
 >  such reports from your users before?
 >  
 >  Regards.
 >  
 >   
 As described in my PR,
 the values are read on my HP notebook using ACPI under a Linux kernel
 with a small patch applied.
 I can't tell where the difference comes from, but the static lists that are
 contained in the BSD kernels are not the right way to handle the
 speedstep thingy.
 I spoke to a intel dev and he noticed that the only right way is reading the
 value from acpi.
 
 Hope that helps.