Re: CPU frequency doesn't drop below 1200MHz (like it used to)

2015-05-23 Thread Adrian Chadd
Frequency control may not be relevant on that platform.

Try installing the intel-pcm package; then

# kldload cpuctl
# pcm.x 1

Then paste some of that in here. Let's see if the CPU is idling some other way.



-adrian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Status of NFS4.1 FS_RECLAIM in FreeBSD 10.1?

2015-05-23 Thread Mahmoud Al-Qudsi

 On May 21, 2015, at 8:19 AM, Rick Macklem rmack...@uoguelph.ca wrote:
 
 Well, if you are just doing an NFSv4.1 mount, you could capture
 packets during the failed mount attaempt with tcpdump and then
 email me the raw packet capture, I can take a look at it.
 (tcpdump doesn't handle nfs packets well, but wireshark will accept
 a raw packet capture) Something like:
 # tcpdump -s 0 -w file.pcap host nfs-client
 should work.
 
 When I read RFC-5661 around page #567, it seems clear that the
 client should use RECLAIM_COMPLETE with the fs arg false after
 acquiring a noew clientid, which is what a fresh mount would normally be.
 (If the packet capture shows an EXCHANGEID followed by a RECLAIM_COMPLETE
 with the fs arg true, I think ESXi is broken, but I can send you a patch
 that will just ignore the true, so it works.)
 I think the true case is only used when a file system has been moved
 by a server cluster, indicated to the client via a NFS4ERR_MOVED error
 when it is accessed at the old server, but the working in RFC-5661 isn't
 very clear.
 
 rick


Thank you kindly.
I am travelling at the moment; but as soon as I can, I will get that to you.

Much appreciated,

Mahmoud

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: CPU frequency doesn't drop below 1200MHz (like it used to)

2015-05-23 Thread Kimmo Paasiala
On Sat, May 23, 2015 at 10:41 PM, Adrian Chadd adr...@freebsd.org wrote:
 Frequency control may not be relevant on that platform.

 Try installing the intel-pcm package; then

 # kldload cpuctl
 # pcm.x 1

 Then paste some of that in here. Let's see if the CPU is idling some other 
 way.



 -adrian

Five iterations one every second:

Script started on Sun May 24 00:07:18 2015
command: sudo pcm.x 1 -i=5

 Intel(r) Performance Counter Monitor V2.8 (2014-12-18 12:52:39 +0100
ID=ba39a89)

 Copyright (c) 2009-2014 Intel Corporation

Number of physical cores: 1
Number of logical cores: 4
Number of online logical cores: 4
Threads (logical cores) per physical core: 4
Num sockets: 1
Physical cores per socket: 1
Core PMU (perfmon) version: 3
Number of core PMU generic (programmable) counters: 2
Width of generic (programmable) counters: 40 bits
Number of core PMU fixed counters: 3
Width of fixed counters: 40 bits
Nominal core frequency: 166000 Hz
Delay: 1

Detected Intel(R) Atom(TM) CPU D510 @ 1.66GHz Intel(r)
microarchitecture codename Atom(tm)

 EXEC  : instructions per nominal CPU cycle
 IPC   : instructions per CPU cycle
 FREQ  : relation to nominal CPU frequency='unhalted clock
ticks'/'invariant timer ticks' (includes Intel Turbo Boost)
 L2MISS: L2 cache misses
 L2HIT : L2 cache hit ratio (0.00-1.00)
 TEMP  : Temperature reading in 1 degree Celsius relative to the TjMax
temperature (thermal headroom): 0 corresponds to the max temperature


 Core (SKT) | EXEC | IPC  | FREQ | L2MISS | L2HIT | TEMP

   00 0.00   0.19   0.00   5513  0.85 89
   10 0.00   0.37   0.00   2676  0.84 89
   20 0.00   0.39   0.01 21 K0.83 N/A
   30 0.00   0.28   0.00   4731  0.64 N/A
-
 TOTAL  * 0.00   0.33   0.00 34 K0.82 N/A

 Instructions retired:  K ; Active cycles:   20 M ; Time (TSC):
1765 Mticks ; C0 (active,non-halted) core residency: 0.28 %

 C1 core residency: 99.72 %;
 C2 package residency: 0.00 %; C4 package residency: 0.00 %; C6
package residency: 0.00 %;

 PHYSICAL CORE IPC : 1.33 = corresponds to 66.42 %
utilization for cores in active state
 Instructions per nominal CPU cycle: 0.00 = corresponds to 0.19 %
core utilization over time interval
--

 EXEC  : instructions per nominal CPU cycle
 IPC   : instructions per CPU cycle
 FREQ  : relation to nominal CPU frequency='unhalted clock
ticks'/'invariant timer ticks' (includes Intel Turbo Boost)
 L2MISS: L2 cache misses
 L2HIT : L2 cache hit ratio (0.00-1.00)
 TEMP  : Temperature reading in 1 degree Celsius relative to the TjMax
temperature (thermal headroom): 0 corresponds to the max temperature


 Core (SKT) | EXEC | IPC  | FREQ | L2MISS | L2HIT | TEMP

   00 0.00   0.19   0.00   6296  0.82 89
   10 0.00   0.35   0.00 12 K0.81 89
   20 0.00   0.44   0.00   6378  0.84 N/A
   30 0.00   0.24   0.00   3846  0.86 N/A
-
 TOTAL  * 0.00   0.34   0.00 29 K0.83 N/A

 Instructions retired: 6646 K ; Active cycles:   19 M ; Time (TSC):
1766 Mticks ; C0 (active,non-halted) core residency: 0.28 %

 C1 core residency: 99.72 %;
 C2 package residency: 0.00 %; C4 package residency: 0.00 %; C6
package residency: 0.00 %;

 PHYSICAL CORE IPC : 1.34 = corresponds to 67.19 %
utilization for cores in active state
 Instructions per nominal CPU cycle: 0.00 = corresponds to 0.19 %
core utilization over time interval
--

 EXEC  : instructions per nominal CPU cycle
 IPC   : instructions per CPU cycle
 FREQ  : relation to nominal CPU frequency='unhalted clock
ticks'/'invariant timer ticks' (includes Intel Turbo Boost)
 L2MISS: L2 cache misses
 L2HIT : L2 cache hit ratio (0.00-1.00)
 TEMP  : Temperature reading in 1 degree Celsius relative to the TjMax
temperature (thermal headroom): 0 corresponds to the max temperature


 Core (SKT) | EXEC | IPC  | FREQ | L2MISS | L2HIT | TEMP

   00 0.00   0.25   0.00 12 K0.74 89
   10 0.00   0.42   0.00   3166  0.94 89
   20 0.00   0.19   0.00   4869  0.68 94
   30 0.00   0.36   0.00 13 K0.81 94
-
 TOTAL  * 0.00   0.34   0.00 33 K0.82 N/A

 Instructions retired: 8041 K ; Active cycles:   23 M ; Time (TSC):
1755 Mticks ; C0 (active,non-halted) core residency: 0.34 %

 C1 core residency: 99.66 %;
 C2 package residency: 0.00 %; C4 package 

Re: CPU frequency doesn't drop below 1200MHz (like it used to)

2015-05-23 Thread Ian Smith
On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote:
  On Fri, May 22, 2015 at 8:19 PM, Ian Smith smi...@nimnet.asn.au wrote:
   On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote:
 On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko fi...@ukr.net wrote:
[..]
   Try changing the options in /boot/device.hints
   hint.acpi_throttle.0.disabled=0
   hint.p4tcc.0.disabled=0
  
 Thanks, those also fixed powerd(8) for me that stopped working after
 upgrading to stable/10 from releng/10.1. Why are those setting
 suddenly needed now?

 -Kimmo
[..]
   Can you say exactly in what way powerd stopped working then?
  
  Powerd(8) complained (excerpt from dmesg -a):
  
  Starting powerd.
  powerd: no cpufreq(4) support -- aborting: No such file or directory
  /etc/rc: WARNING: failed to start powerd
  
  Putting those two settings in loader.conf and rebooting fixed the
  problem and powerd started working again apparently because cpufreq(4)
  device was available again.

Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus 
powerd - work for you, then it seems likely that you do not have EST 
enabled in your BIOS.  Or at least, we've seen another instance where 
that was the case, which was fixed by enabling EST (or however your
particular BIOS refers to it .. AMD for example use different terms).

What CPU is this?  In what machine?

If EST (ono) IS enabled in your BIOS, this needs further investigation.  

As is, powerd may be running, but it's doing so highly inefficiently; 
refer to Stefan, Adrian and Kevin's responses for details.

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: CPU frequency doesn't drop below 1200MHz (like it used to)

2015-05-23 Thread Ian Smith
On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote:
  On Sat, May 23, 2015 at 10:00 AM, Ian Smith smi...@nimnet.asn.au wrote:
   On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote:
 On Fri, May 22, 2015 at 8:19 PM, Ian Smith smi...@nimnet.asn.au wrote:
  On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote:
On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko fi...@ukr.net 
   wrote:
   [..]
  Try changing the options in /boot/device.hints
  hint.acpi_throttle.0.disabled=0
  hint.p4tcc.0.disabled=0
 
Thanks, those also fixed powerd(8) for me that stopped working 
   after
upgrading to stable/10 from releng/10.1. Why are those setting
suddenly needed now?
   [..]
  Can you say exactly in what way powerd stopped working then?

 Powerd(8) complained (excerpt from dmesg -a):

 Starting powerd.
 powerd: no cpufreq(4) support -- aborting: No such file or directory
 /etc/rc: WARNING: failed to start powerd

 Putting those two settings in loader.conf and rebooting fixed the
 problem and powerd started working again apparently because cpufreq(4)
 device was available again.
  
   Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus
   powerd - work for you, then it seems likely that you do not have EST
   enabled in your BIOS.  Or at least, we've seen another instance where
   that was the case, which was fixed by enabling EST (or however your
   particular BIOS refers to it .. AMD for example use different terms).
  
   What CPU is this?  In what machine?
  
   If EST (ono) IS enabled in your BIOS, this needs further investigation.
  
   As is, powerd may be running, but it's doing so highly inefficiently;
   refer to Stefan, Adrian and Kevin's responses for details.

  It's an Intel Atom running amd64 version of FreeBSD stable/10:
  
  FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
  r283292: Sat May 23 01:08:03 EEST 2015
  r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64
  
  CPU: Intel(R) Atom(TM) CPU D510   @ 1.66GHz (1666.68-MHz K8-class CPU)
Origin=GenuineIntel  Id=0x106ca  Family=0x6  Model=0x1c  Stepping=10

  Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
AMD Features=0x20100800SYSCALL,NX,LM
AMD Features2=0x1LAHF
TSC: P-state invariant, performance statistics
  
  Powerd was working on 10.1-RELEASE but stopped working after upgrade
  to 10-STABLE and nothing was changed in BIOS settings.

Which would be consistent with EST not being enabled in your BIOS; with 
no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or 
acpi_throttle and uses that, as a last resort really; with those also 
disabled, no cpufreq, so no powerd.  Have you checked BIOS settings to 
confirm that you do have SpeedStep (however termed) properly enabled?

Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels`

  However, reading the other replies to this thread I get the impression
  that powerd(8) doesn't actually save energy on this platform and I'm
  better off without it?

No, I don't think that's correct; using deeper C-states is most likely a 
bigger win, but higher than needed CPU freq will still use extra power, 
so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.

Reason I'm pursuing this is that this change shouldn't hurt, but it will 
flush out those cases where people were only getting cpufreq due to use 
of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS; 
I suspect yours may be one such case :)  If not, there's a bug to fix.

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: CPU frequency doesn't drop below 1200MHz (like it used to)

2015-05-23 Thread Kimmo Paasiala
On Sat, May 23, 2015 at 10:00 AM, Ian Smith smi...@nimnet.asn.au wrote:
 On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote:
   On Fri, May 22, 2015 at 8:19 PM, Ian Smith smi...@nimnet.asn.au wrote:
On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote:
  On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko fi...@ukr.net wrote:
 [..]
Try changing the options in /boot/device.hints
hint.acpi_throttle.0.disabled=0
hint.p4tcc.0.disabled=0
   
  Thanks, those also fixed powerd(8) for me that stopped working after
  upgrading to stable/10 from releng/10.1. Why are those setting
  suddenly needed now?
 
  -Kimmo
 [..]
Can you say exactly in what way powerd stopped working then?
  
   Powerd(8) complained (excerpt from dmesg -a):
  
   Starting powerd.
   powerd: no cpufreq(4) support -- aborting: No such file or directory
   /etc/rc: WARNING: failed to start powerd
  
   Putting those two settings in loader.conf and rebooting fixed the
   problem and powerd started working again apparently because cpufreq(4)
   device was available again.

 Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus
 powerd - work for you, then it seems likely that you do not have EST
 enabled in your BIOS.  Or at least, we've seen another instance where
 that was the case, which was fixed by enabling EST (or however your
 particular BIOS refers to it .. AMD for example use different terms).

 What CPU is this?  In what machine?

 If EST (ono) IS enabled in your BIOS, this needs further investigation.

 As is, powerd may be running, but it's doing so highly inefficiently;
 refer to Stefan, Adrian and Kevin's responses for details.

 cheers, Ian

It's an Intel Atom running amd64 version of FreeBSD stable/10:

FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
r283292: Sat May 23 01:08:03 EEST 2015
r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64

CPU: Intel(R) Atom(TM) CPU D510   @ 1.66GHz (1666.68-MHz K8-class CPU)
  Origin=GenuineIntel  Id=0x106ca  Family=0x6  Model=0x1c  Stepping=10
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
  AMD Features=0x20100800SYSCALL,NX,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant, performance statistics

Powerd was working on 10.1-RELEASE but stopped working after upgrade
to 10-STABLE and nothing was changed in BIOS settings.

However, reading the other replies to this thread I get the impression
that powerd(8) doesn't actually save energy on this platform and I'm
better off without it?

-Kimmo
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: CPU frequency doesn't drop below 1200MHz (like it used to)

2015-05-23 Thread Ian Smith
On Sat, 23 May 2015 17:40:26 +0300, Kimmo Paasiala wrote:
  On Sat, May 23, 2015 at 5:15 PM, Ian Smith smi...@nimnet.asn.au wrote:
[..]
 It's an Intel Atom running amd64 version of FreeBSD stable/10:

 FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
 r283292: Sat May 23 01:08:03 EEST 2015
 r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64

 CPU: Intel(R) Atom(TM) CPU D510   @ 1.66GHz (1666.68-MHz K8-class CPU)
   Origin=GenuineIntel  Id=0x106ca  Family=0x6  Model=0x1c  Stepping=10
   
   Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
   
   Features2=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
   AMD Features=0x20100800SYSCALL,NX,LM
   AMD Features2=0x1LAHF
   TSC: P-state invariant, performance statistics

 Powerd was working on 10.1-RELEASE but stopped working after upgrade
 to 10-STABLE and nothing was changed in BIOS settings.
[..]
 However, reading the other replies to this thread I get the impression
 that powerd(8) doesn't actually save energy on this platform and I'm
 better off without it?
  
   No, I don't think that's correct; using deeper C-states is most likely a
   bigger win, but higher than needed CPU freq will still use extra power,
   so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.
  
   Reason I'm pursuing this is that this change shouldn't hurt, but it will
   flush out those cases where people were only getting cpufreq due to use
   of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS;
   I suspect yours may be one such case :)  If not, there's a bug to fix.

Seems _I've_ got a bug to fix; I need to stop assuming all modern Intel 
CPUs are going to make SpeedStep and/or deeper C-states available :(

  Looking deeper into this it appears I don't have speedstep (EST)
  support in the CPU it being a crappy Atom D510:
  
  http://ark.intel.com/products/43098

Indeed.  It is rated at only 13W TDP, so relatively low power anyway.

  This the full 'sysctl dev.cpu' output:
  
  % sysctl dev.cpu

  dev.cpu.3.cx_usage: 100.00% last 65712us
  dev.cpu.3.cx_lowest: C1
  dev.cpu.3.cx_supported: C1/1/0
[..]
  dev.cpu.0.cx_usage: 100.00% last 3132us
  dev.cpu.0.cx_lowest: C1
  dev.cpu.0.cx_supported: C1/1/0
  dev.cpu.0.%parent: acpi0
  dev.cpu.0.%pnpinfo: _HID=none _UID=0
  dev.cpu.0.%location: handle=\_PR_.P001
  dev.cpu.0.%driver: cpu
  dev.cpu.0.%desc: ACPI CPU
  dev.cpu.%parent:

It doesn't even provide dev.cpu.0.freq, and has no deeper C-states 
('Idle States' on that page) available, so it looks like you may as well 
not bother running powerd.  Others maybe can offer better suggestions.
 
  So I should keep those two hints in loader.conf to use p4tcc I guess?

If this is a desktop I'd just let it run flat out, ie disable p4tcc and 
acpi_throttle, have no cpufreq and forget powerd.

If it's a laptop and power consumption on battery matters to you, you 
could see if p4tcc's lower frequencies actually save any power much, by 
running 'powerd -v' in a terminal while testing with different loads, or 
if your 'acpiconf -i0' shows discharging rates in mA or mW, or both.

Sorry again for my poor assumption, and thanks for the data point!

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: CPU frequency doesn't drop below 1200MHz (like it used to)

2015-05-23 Thread Adrian Chadd
Hm, no thermal monitoring and no speedstep. Could be dangerous/fun.

What's the output of sysctl dev.cpu.0 ?




-adrian


On 23 May 2015 at 07:40, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sat, May 23, 2015 at 5:15 PM, Ian Smith smi...@nimnet.asn.au wrote:
 On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote:
   On Sat, May 23, 2015 at 10:00 AM, Ian Smith smi...@nimnet.asn.au wrote:
On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote:
  On Fri, May 22, 2015 at 8:19 PM, Ian Smith smi...@nimnet.asn.au 
 wrote:
   On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote:
 On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko fi...@ukr.net 
 wrote:
[..]
   Try changing the options in /boot/device.hints
   hint.acpi_throttle.0.disabled=0
   hint.p4tcc.0.disabled=0
  
 Thanks, those also fixed powerd(8) for me that stopped working 
 after
 upgrading to stable/10 from releng/10.1. Why are those setting
 suddenly needed now?
[..]
   Can you say exactly in what way powerd stopped working then?
 
  Powerd(8) complained (excerpt from dmesg -a):
 
  Starting powerd.
  powerd: no cpufreq(4) support -- aborting: No such file or directory
  /etc/rc: WARNING: failed to start powerd
 
  Putting those two settings in loader.conf and rebooting fixed the
  problem and powerd started working again apparently because 
 cpufreq(4)
  device was available again.
   
Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus
powerd - work for you, then it seems likely that you do not have EST
enabled in your BIOS.  Or at least, we've seen another instance where
that was the case, which was fixed by enabling EST (or however your
particular BIOS refers to it .. AMD for example use different terms).
   
What CPU is this?  In what machine?
   
If EST (ono) IS enabled in your BIOS, this needs further investigation.
   
As is, powerd may be running, but it's doing so highly inefficiently;
refer to Stefan, Adrian and Kevin's responses for details.

   It's an Intel Atom running amd64 version of FreeBSD stable/10:
  
   FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
   r283292: Sat May 23 01:08:03 EEST 2015
   r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64
  
   CPU: Intel(R) Atom(TM) CPU D510   @ 1.66GHz (1666.68-MHz K8-class CPU)
 Origin=GenuineIntel  Id=0x106ca  Family=0x6  Model=0x1c  Stepping=10
 
 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
 
 Features2=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
 AMD Features=0x20100800SYSCALL,NX,LM
 AMD Features2=0x1LAHF
 TSC: P-state invariant, performance statistics
  
   Powerd was working on 10.1-RELEASE but stopped working after upgrade
   to 10-STABLE and nothing was changed in BIOS settings.

 Which would be consistent with EST not being enabled in your BIOS; with
 no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or
 acpi_throttle and uses that, as a last resort really; with those also
 disabled, no cpufreq, so no powerd.  Have you checked BIOS settings to
 confirm that you do have SpeedStep (however termed) properly enabled?

 Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels`

   However, reading the other replies to this thread I get the impression
   that powerd(8) doesn't actually save energy on this platform and I'm
   better off without it?

 No, I don't think that's correct; using deeper C-states is most likely a
 bigger win, but higher than needed CPU freq will still use extra power,
 so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.

 Reason I'm pursuing this is that this change shouldn't hurt, but it will
 flush out those cases where people were only getting cpufreq due to use
 of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS;
 I suspect yours may be one such case :)  If not, there's a bug to fix.

 cheers, Ian

 Looking deeper into this it appears I don't have speedstep (EST)
 support in the CPU it being a crappy Atom D510:

 http://ark.intel.com/products/43098

 This the full 'sysctl dev.cpu' output:

 % sysctl dev.cpu
 dev.cpu.3.cx_usage: 100.00% last 65712us
 dev.cpu.3.cx_lowest: C1
 dev.cpu.3.cx_supported: C1/1/0
 dev.cpu.3.%parent: acpi0
 dev.cpu.3.%pnpinfo: _HID=none _UID=0
 dev.cpu.3.%location: handle=\_PR_.P004
 dev.cpu.3.%driver: cpu
 dev.cpu.3.%desc: ACPI CPU
 dev.cpu.2.cx_usage: 100.00% last 41518us
 dev.cpu.2.cx_lowest: C1
 dev.cpu.2.cx_supported: C1/1/0
 dev.cpu.2.%parent: acpi0
 dev.cpu.2.%pnpinfo: _HID=none _UID=0
 dev.cpu.2.%location: handle=\_PR_.P003
 dev.cpu.2.%driver: cpu
 dev.cpu.2.%desc: ACPI CPU
 dev.cpu.1.cx_usage: 100.00% last 12706us
 dev.cpu.1.cx_lowest: C1
 dev.cpu.1.cx_supported: C1/1/0
 dev.cpu.1.%parent: acpi0
 dev.cpu.1.%pnpinfo: _HID=none 

Re: CPU frequency doesn't drop below 1200MHz (like it used to)

2015-05-23 Thread Kimmo Paasiala
On Sat, May 23, 2015 at 6:57 PM, Ian Smith smi...@nimnet.asn.au wrote:
 On Sat, 23 May 2015 17:40:26 +0300, Kimmo Paasiala wrote:
   On Sat, May 23, 2015 at 5:15 PM, Ian Smith smi...@nimnet.asn.au wrote:
 [..]
  It's an Intel Atom running amd64 version of FreeBSD stable/10:
 
  FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
  r283292: Sat May 23 01:08:03 EEST 2015
  r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64
 
  CPU: Intel(R) Atom(TM) CPU D510   @ 1.66GHz (1666.68-MHz K8-class CPU)
Origin=GenuineIntel  Id=0x106ca  Family=0x6  Model=0x1c  
 Stepping=10

 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE

 Features2=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
AMD Features=0x20100800SYSCALL,NX,LM
AMD Features2=0x1LAHF
TSC: P-state invariant, performance statistics
 
  Powerd was working on 10.1-RELEASE but stopped working after upgrade
  to 10-STABLE and nothing was changed in BIOS settings.
 [..]
  However, reading the other replies to this thread I get the impression
  that powerd(8) doesn't actually save energy on this platform and I'm
  better off without it?
   
No, I don't think that's correct; using deeper C-states is most likely a
bigger win, but higher than needed CPU freq will still use extra power,
so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.
   
Reason I'm pursuing this is that this change shouldn't hurt, but it will
flush out those cases where people were only getting cpufreq due to use
of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS;
I suspect yours may be one such case :)  If not, there's a bug to fix.

 Seems _I've_ got a bug to fix; I need to stop assuming all modern Intel
 CPUs are going to make SpeedStep and/or deeper C-states available :(

   Looking deeper into this it appears I don't have speedstep (EST)
   support in the CPU it being a crappy Atom D510:
  
   http://ark.intel.com/products/43098

 Indeed.  It is rated at only 13W TDP, so relatively low power anyway.

   This the full 'sysctl dev.cpu' output:
  
   % sysctl dev.cpu

   dev.cpu.3.cx_usage: 100.00% last 65712us
   dev.cpu.3.cx_lowest: C1
   dev.cpu.3.cx_supported: C1/1/0
 [..]
   dev.cpu.0.cx_usage: 100.00% last 3132us
   dev.cpu.0.cx_lowest: C1
   dev.cpu.0.cx_supported: C1/1/0
   dev.cpu.0.%parent: acpi0
   dev.cpu.0.%pnpinfo: _HID=none _UID=0
   dev.cpu.0.%location: handle=\_PR_.P001
   dev.cpu.0.%driver: cpu
   dev.cpu.0.%desc: ACPI CPU
   dev.cpu.%parent:

 It doesn't even provide dev.cpu.0.freq, and has no deeper C-states
 ('Idle States' on that page) available, so it looks like you may as well
 not bother running powerd.  Others maybe can offer better suggestions.

   So I should keep those two hints in loader.conf to use p4tcc I guess?

 If this is a desktop I'd just let it run flat out, ie disable p4tcc and
 acpi_throttle, have no cpufreq and forget powerd.

 If it's a laptop and power consumption on battery matters to you, you
 could see if p4tcc's lower frequencies actually save any power much, by
 running 'powerd -v' in a terminal while testing with different loads, or
 if your 'acpiconf -i0' shows discharging rates in mA or mW, or both.

 Sorry again for my poor assumption, and thanks for the data point!

 cheers, Ian

It's a firewall/router with some minimal services like nginx running.
I'll just leave it like it's now without any frequency control.

Thanks,

-Kimmo
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: CPU frequency doesn't drop below 1200MHz (like it used to)

2015-05-23 Thread Kimmo Paasiala
On Sat, May 23, 2015 at 5:15 PM, Ian Smith smi...@nimnet.asn.au wrote:
 On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote:
   On Sat, May 23, 2015 at 10:00 AM, Ian Smith smi...@nimnet.asn.au wrote:
On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote:
  On Fri, May 22, 2015 at 8:19 PM, Ian Smith smi...@nimnet.asn.au 
 wrote:
   On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote:
 On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko fi...@ukr.net 
 wrote:
[..]
   Try changing the options in /boot/device.hints
   hint.acpi_throttle.0.disabled=0
   hint.p4tcc.0.disabled=0
  
 Thanks, those also fixed powerd(8) for me that stopped working 
 after
 upgrading to stable/10 from releng/10.1. Why are those setting
 suddenly needed now?
[..]
   Can you say exactly in what way powerd stopped working then?
 
  Powerd(8) complained (excerpt from dmesg -a):
 
  Starting powerd.
  powerd: no cpufreq(4) support -- aborting: No such file or directory
  /etc/rc: WARNING: failed to start powerd
 
  Putting those two settings in loader.conf and rebooting fixed the
  problem and powerd started working again apparently because cpufreq(4)
  device was available again.
   
Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus
powerd - work for you, then it seems likely that you do not have EST
enabled in your BIOS.  Or at least, we've seen another instance where
that was the case, which was fixed by enabling EST (or however your
particular BIOS refers to it .. AMD for example use different terms).
   
What CPU is this?  In what machine?
   
If EST (ono) IS enabled in your BIOS, this needs further investigation.
   
As is, powerd may be running, but it's doing so highly inefficiently;
refer to Stefan, Adrian and Kevin's responses for details.

   It's an Intel Atom running amd64 version of FreeBSD stable/10:
  
   FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
   r283292: Sat May 23 01:08:03 EEST 2015
   r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64
  
   CPU: Intel(R) Atom(TM) CPU D510   @ 1.66GHz (1666.68-MHz K8-class CPU)
 Origin=GenuineIntel  Id=0x106ca  Family=0x6  Model=0x1c  Stepping=10
 
 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
 Features2=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
 AMD Features=0x20100800SYSCALL,NX,LM
 AMD Features2=0x1LAHF
 TSC: P-state invariant, performance statistics
  
   Powerd was working on 10.1-RELEASE but stopped working after upgrade
   to 10-STABLE and nothing was changed in BIOS settings.

 Which would be consistent with EST not being enabled in your BIOS; with
 no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or
 acpi_throttle and uses that, as a last resort really; with those also
 disabled, no cpufreq, so no powerd.  Have you checked BIOS settings to
 confirm that you do have SpeedStep (however termed) properly enabled?

 Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels`

   However, reading the other replies to this thread I get the impression
   that powerd(8) doesn't actually save energy on this platform and I'm
   better off without it?

 No, I don't think that's correct; using deeper C-states is most likely a
 bigger win, but higher than needed CPU freq will still use extra power,
 so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.

 Reason I'm pursuing this is that this change shouldn't hurt, but it will
 flush out those cases where people were only getting cpufreq due to use
 of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS;
 I suspect yours may be one such case :)  If not, there's a bug to fix.

 cheers, Ian

Looking deeper into this it appears I don't have speedstep (EST)
support in the CPU it being a crappy Atom D510:

http://ark.intel.com/products/43098

This the full 'sysctl dev.cpu' output:

% sysctl dev.cpu
dev.cpu.3.cx_usage: 100.00% last 65712us
dev.cpu.3.cx_lowest: C1
dev.cpu.3.cx_supported: C1/1/0
dev.cpu.3.%parent: acpi0
dev.cpu.3.%pnpinfo: _HID=none _UID=0
dev.cpu.3.%location: handle=\_PR_.P004
dev.cpu.3.%driver: cpu
dev.cpu.3.%desc: ACPI CPU
dev.cpu.2.cx_usage: 100.00% last 41518us
dev.cpu.2.cx_lowest: C1
dev.cpu.2.cx_supported: C1/1/0
dev.cpu.2.%parent: acpi0
dev.cpu.2.%pnpinfo: _HID=none _UID=0
dev.cpu.2.%location: handle=\_PR_.P003
dev.cpu.2.%driver: cpu
dev.cpu.2.%desc: ACPI CPU
dev.cpu.1.cx_usage: 100.00% last 12706us
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_supported: C1/1/0
dev.cpu.1.%parent: acpi0
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%location: handle=\_PR_.P002
dev.cpu.1.%driver: cpu
dev.cpu.1.%desc: ACPI CPU
dev.cpu.0.cx_usage: 100.00% last 3132us
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_supported: C1/1/0
dev.cpu.0.%parent: acpi0

Re: L2ARC degraded. Checksum errors, I/O errors

2015-05-23 Thread George Kontostanos
Once again, do we know if this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 has been committed
yet?

-- 
George Kontostanos
---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org