Re: (Missing) power states of an Atom N455-based netbook

2011-07-16 Thread Vitaly Magerya 
Taku YAMAMOTO t...@tackymt.homeip.net wrote:
 Maybe we have to tell the BIOS that we are going to utilize _CST via SMI.
 In fact, the major difference between mine and jkim's is that in mine
 I took the following snippet (which we can find in acpi_cpu_startup_cx
 function, living in sys/dev/acpica/acpi_cpu.c) out of #ifdef notyet.

 -#ifdef notyet
  /* Signal platform that we can handle _CST notification. */
  if (!cpu_cx_generic  cpu_cst_cnt != 0) {
   ACPI_LOCK(acpi);
   AcpiOsWritePort(cpu_smi_cmd, cpu_cst_cnt, 8);
   ACPI_UNLOCK(acpi);
  }
 -#endif

 Vitaly, could you remove the above-mentioned #ifdef-#endif pair (to activate
 the code inbetween) and test jkim's patch again?

It hangs on the same spot.

 Actually, I abandoned the patches and I am thinking about rewriting it
 from scratch, e.g., refactoring MI/MD support code
 (dev/acpica/acpi_cpu.c - machine/machdep.c  acpica/acpi_machdep.c).
 Unfortunately, I don't have much time nor hardware to test, so it
 won't happen any time soon.  Sorry.

 If anyone wants to pick it up from here, please feel free.

 [...]

 I will happily test your new patches next time.

I'll provide any testing help needed as well.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: (Missing) power states of an Atom N455-based netbook

2011-07-13 Thread Vitaly Magerya 
Taku YAMAMOTO t...@tackymt.homeip.net wrote:
 Ah, the line in the acpi_cpu_mwait function should be read as:

   cpu_monitor(state, 0, 0);

 Vitaly, could you test the jkim's patch again with the above line modified?

Sure. With the above change it hangs during the boot.

Here are the last two lines before the hang with verbose boot:

acpi_acad0: acline initialization start
acpi_battery0: battery initialization start
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: (Missing) power states of an Atom N455-based netbook

2011-07-12 Thread Andriy Gapon 
on 11/07/2011 19:07 Vitaly Magerya said the following:
 Andriy Gapon a...@freebsd.org wrote:
 on 06/07/2011 22:20 Vitaly Magerya said the following:
 --- acpi_cpu.c.orig 2011-07-05 19:50:31.0 +
 +++ acpi_cpu.c  2011-07-06 17:23:16.0 +
 @@ -1194,7 +1194,7 @@
  if (strlen(state)  2 || toupper(state[0]) != 'C')
 return (EINVAL);
  val = (int) strtol(state + 1, NULL, 10) - 1;
 -if (val  0 || val  cpu_cx_count - 1)
 +if (val  0)
 return (EINVAL);
  cpu_cx_lowest = val;

 This change is a little bit more intrusive than I would like.
 There are some things about cpu_cx_lowest handling in the code that make me 
 a bit
 unsure if this change is completely safe.
 
 Can you elaborate? From my reading, the only place cpu_cx_lowest
 is used is in acpi_cpu_notify, where sc-cpu_cx_lowest is optionally
 increased to min(cpu_cx_lowest, sc-cpu_cx_count - 1), which should
 be safe in any situation.

This is exactly the place that I am concerned about.
Probably my mind is clouded but I can not understand why 
acpi_cpu_set_cx_lowest()
call is under the condition:
if (sc-cpu_cx_lowest  cpu_cx_lowest)
acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc-cpu_cx_count - 1));

If you or someone else can explain to me why that condition is there...

 Also note that we currently do not update cpu_cx_lowest immediately
 when the number of available states changes (only devd+power_profile
 does that). For example, if I kill devd and plug the power cord
 off, cpu_cx_lowest remains at C3, even though only C2 is reported.
 This is why the above patch shouldn't introduce situations we don't
 already have.

Yes, quite a good point.
Although I am not sure yet if what you describe is not a bug that should be 
fixed.

 I suspect that there could be problems
 on systems where number Cx states becomes smaller after some events (e.g. AC 
 connection).
 
 I have such a system; if there are situations you'd like me to test,
 I can do so (so far it looks good).

I am not exactly sure what to look for...
Perhaps something like this (if your system would allow it):
- place the system in a state where at least C3 is supported
- set global cx_lowest to C3
- set per-CPU cx_lowest for one CPU to C2
- place a system in a state where only C1 is supported

This testcase is only tangentially related to your proposed change.  It's more
about that code that I don't understand.

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

Re: (Missing) power states of an Atom N455-based netbook

2011-07-12 Thread Vitaly Magerya 
Andriy Gapon a...@freebsd.org wrote:
 on 11/07/2011 19:07 Vitaly Magerya said the following:
 Can you elaborate? From my reading, the only place cpu_cx_lowest
 is used is in acpi_cpu_notify, where sc-cpu_cx_lowest is optionally
 increased to min(cpu_cx_lowest, sc-cpu_cx_count - 1), which should
 be safe in any situation.

 This is exactly the place that I am concerned about.
 Probably my mind is clouded but I can not understand why
 acpi_cpu_set_cx_lowest()
 call is under the condition:
 if (sc-cpu_cx_lowest  cpu_cx_lowest)
 acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc-cpu_cx_count - 1));

 If you or someone else can explain to me why that condition is there...

Now that I think about it, yes it does look like a bug. Here's how to
trigger it:

1. Kill devd.
2. Make sure you've got C3, set hw.acpi.cpu.cx_lowest to C3.
3. Plug the power cord in (only C2 is now reported).
4. Look at dev.cpu.N.cx_lowest: it's still C3, even though
   dev.cpu.N.cx_supported only has C1 and C2.

This happens because normally sc-cpu_cx_lowest == cpu_cx_lowest,
so the update isn't executed, and sc-cpu_cx_lowest remains as
before.

In short, that update should probably be executed unconditionally.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: (Missing) power states of an Atom N455-based netbook

2011-07-11 Thread Vitaly Magerya 
Andriy Gapon a...@freebsd.org wrote:
 on 06/07/2011 22:20 Vitaly Magerya said the following:
 --- acpi_cpu.c.orig 2011-07-05 19:50:31.0 +
 +++ acpi_cpu.c  2011-07-06 17:23:16.0 +
 @@ -1194,7 +1194,7 @@
  if (strlen(state)  2 || toupper(state[0]) != 'C')
 return (EINVAL);
  val = (int) strtol(state + 1, NULL, 10) - 1;
 -if (val  0 || val  cpu_cx_count - 1)
 +if (val  0)
 return (EINVAL);
  cpu_cx_lowest = val;

 This change is a little bit more intrusive than I would like.
 There are some things about cpu_cx_lowest handling in the code that make me a 
 bit
 unsure if this change is completely safe.

Can you elaborate? From my reading, the only place cpu_cx_lowest
is used is in acpi_cpu_notify, where sc-cpu_cx_lowest is optionally
increased to min(cpu_cx_lowest, sc-cpu_cx_count - 1), which should
be safe in any situation.

Also note that we currently do not update cpu_cx_lowest immediately
when the number of available states changes (only devd+power_profile
does that). For example, if I kill devd and plug the power cord
off, cpu_cx_lowest remains at C3, even though only C2 is reported.
This is why the above patch shouldn't introduce situations we don't
already have.

 I suspect that there could be problems
 on systems where number Cx states becomes smaller after some events (e.g. AC 
 connection).

I have such a system; if there are situations you'd like me to test,
I can do so (so far it looks good).

 I would prefer other developers to also comment on this.
 Maybe it's worth while opening a PR for this proposed change.

 You can even simplify power_profile with this change:

 --- power_profile.orig  2011-07-06 18:39:27.0 +
 +++ power_profile   2011-07-06 18:40:20.0 +
 @@ -81,8 +81,7 @@
  # Set the various sysctls based on the profile's values.
  node=hw.acpi.cpu.cx_lowest
  highest_value=C1
 -lowest_value=`(sysctl -n dev.cpu.0.cx_supported | \
 -   awk '{ print C split($0, a) }' -) 2 /dev/null`
 +lowest_value=C99
  eval value=\$${profile}_cx_lowest
  sysctl_set

 C99 looks too scary (and too familiar) :-)
 I think that C6 would be sufficient here.

I expect people to get confused over such change to power_profile,
so I'm not sure if I like it myself.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: (Missing) power states of an Atom N455-based netbook

2011-07-08 Thread Andriy Gapon 
on 06/07/2011 22:20 Vitaly Magerya said the following:
 Actually, I have a simpler fix. We could allow setting hw.acpi.cx_lowest
 to any value, including states that are not currently present. Then,
 on updates to available Cx states, our ACPI code will automatically
 set dev.cpu.N.cx_lowest to the closest valid value without the need
 for a separate power_profile invocation.
 
 Here's the diff:
 
 --- acpi_cpu.c.orig 2011-07-05 19:50:31.0 +
 +++ acpi_cpu.c  2011-07-06 17:23:16.0 +
 @@ -1194,7 +1194,7 @@
  if (strlen(state)  2 || toupper(state[0]) != 'C')
 return (EINVAL);
  val = (int) strtol(state + 1, NULL, 10) - 1;
 -if (val  0 || val  cpu_cx_count - 1)
 +if (val  0)
 return (EINVAL);
  cpu_cx_lowest = val;

This change is a little bit more intrusive than I would like.
There are some things about cpu_cx_lowest handling in the code that make me a 
bit
unsure if this change is completely safe.  I suspect that there could be 
problems
on systems where number Cx states becomes smaller after some events (e.g. AC
connection).
I would prefer other developers to also comment on this.
Maybe it's worth while opening a PR for this proposed change.

 You can even simplify power_profile with this change:
 
 --- power_profile.orig  2011-07-06 18:39:27.0 +
 +++ power_profile   2011-07-06 18:40:20.0 +
 @@ -81,8 +81,7 @@
  # Set the various sysctls based on the profile's values.
  node=hw.acpi.cpu.cx_lowest
  highest_value=C1
 -lowest_value=`(sysctl -n dev.cpu.0.cx_supported | \
 -   awk '{ print C split($0, a) }' -) 2 /dev/null`
 +lowest_value=C99
  eval value=\$${profile}_cx_lowest
  sysctl_set

C99 looks too scary (and too familiar) :-)
I think that C6 would be sufficient here.

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

Re: (Missing) power states of an Atom N455-based netbook

2011-07-06 Thread Andriy Gapon 
on 06/07/2011 00:49 Vitaly Magerya said the following:
 Andriy Gapon a...@freebsd.org wrote:
 Possible courses of action:

 1. Do nothing and leave you with your workaround.

 2. Provide intel_idle-like driver for FreeBSD.  I don't like this approach 
 for
 reasons I've stated before.

 3. Try to make FreeBSD smarter with respect to dynamically changing 
 C-states.  I
 think it would be useful if we received a devd notifications about C-state
 reconfiguration.  Then we could execute /etc/rc.d/power_profile to account 
 for the
 new configuration.
 
 This would be the most useful option.

I agree! :)

 Here's what I tried (trivial diff, sending inline):
 
 --- acpi_cpu.c.orig 2011-07-05 19:50:31.0 +
 +++ acpi_cpu.c  2011-07-05 21:44:56.0 +
 @@ -988,12 +988,13 @@
  {
  struct acpi_cpu_softc *sc = (struct acpi_cpu_softc *)context;
  struct acpi_cpu_softc *isc;
 -int i;
 +int prev_cx_count, i;
 
  if (notify != ACPI_NOTIFY_CX_STATES)
 return;
 
  /* Update the list of Cx states. */
 +prev_cx_count = sc-cpu_cx_count;
  acpi_cpu_cx_cst(sc);
  acpi_cpu_cx_list(sc);
 
 @@ -1008,6 +1009,8 @@
  if (sc-cpu_cx_lowest  cpu_cx_lowest)
 acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc-cpu_cx_count - 1));
  ACPI_SERIAL_END(cpu);
 +if (prev_cx_count != sc-cpu_cx_count)
 +   acpi_UserNotify(CPU_CX, h, sc-cpu_cx_count);
  }
 
  static int
 --- devd.conf.orig  2011-07-05 20:19:30.0 +
 +++ devd.conf   2011-07-05 20:30:08.0 +
 @@ -209,6 +209,13 @@
 action /etc/rc.d/power_profile $notify;
  };
 
 +# Update power profile when available CPU Cx states are updated.
 +notify 10 {
 +   match system  ACPI;
 +   match subsystem   CPU_CX;
 +   action /etc/rc.d/power_profile 0x0`sysctl -n hw.acpi.acline`;
 +};
 +
  # Notify all users before beginning emergency shutdown when we get
  # a _CRT or _HOT thermal event and we're going to power down the system
  # very soon.
 
 This generally works, except that power_profile is executed multiple
 times (the event is generated once per core, and when it is triggered
 by plugging the power cord, ACPI ACAD is reported at the same time
 thus resulting in one more power_profile execution).

At this time and for this purpose I would probably send the notification only if
global cx_lowest value changes as we do not do per-CPU power profiles.

Also, I think that cpu_cx_count is not the best parameter for notification.
For per-cpu events I would rather use CPU ID.  For global events, it may makes
sense to use /subsystem/ value of CPU and then discriminate various types of 
CPU
events via /notify/.  E.g. notify=0 could be used to indicate Cx changes.  Maybe
we will have more ACPI CPU events in the future.

Otherwise I really like this, thank you.

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

Re: (Missing) power states of an Atom N455-based netbook

2011-07-05 Thread Andriy Gapon 
on 02/07/2011 23:30 Vitaly Magerya said the following:
 Andriy Gapon a...@freebsd.org wrote:
 VDRV: 00 - 01

 Looks like this variable should tell if OS has ACPI Video driver, to be 
 precise
 if _BCL method was invoked at least once.
 Looks like in your case the driver doesn't attach for some reason?..
 
 I don't have acpi_video loaded (it's not loaded by default). If I
 do load it, VDRV indeed becomes 1 (brightness controls that acpi_video
 exposes don't work though; this appears to be a known problem with
 Samsung laptops).

This might warrant a separate investigation and a PR if we don't have one 
already.
Not sure if I could be of help with it, though.

 Actually, it seems that they have them simply hardcoded:
 http://lxr.linux.no/#linux+v2.6.39/drivers/idle/intel_idle.c#L171
 I am not sure how to check on Linux which cpuidle driver is being used.  If 
 you
 know, could please check that?  And if the driver is intel_idle, then there 
 is
 no mystery, they use those hardcoded values.
 
 I think the mystery is solved then:
 
 $ cat /sys/devices/system/cpu/cpuidle/current_driver
 intel_idle

Possible courses of action:

1. Do nothing and leave you with your workaround.

2. Provide intel_idle-like driver for FreeBSD.  I don't like this approach for
reasons I've stated before.

3. Try to make FreeBSD smarter with respect to dynamically changing C-states.  I
think it would be useful if we received a devd notifications about C-state
reconfiguration.  Then we could execute /etc/rc.d/power_profile to account for 
the
new configuration.

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

Re: (Missing) power states of an Atom N455-based netbook

2011-07-02 Thread Vitaly Magerya 
Andriy Gapon a...@freebsd.org wrote:
 VDRV: 00 - 01

 Looks like this variable should tell if OS has ACPI Video driver, to be 
 precise
 if _BCL method was invoked at least once.
 Looks like in your case the driver doesn't attach for some reason?..

I don't have acpi_video loaded (it's not loaded by default). If I
do load it, VDRV indeed becomes 1 (brightness controls that acpi_video
exposes don't work though; this appears to be a known problem with
Samsung laptops).

 Unfortunately, I don't remember if or where you provided your dmesg.

It's at [1].

 (Note that C1ON is 0 just as with FreeBSD, and yet powertop does
 report C2 and C4).

 [...]

 Actually, it seems that they have them simply hardcoded:
 http://lxr.linux.no/#linux+v2.6.39/drivers/idle/intel_idle.c#L171
 I am not sure how to check on Linux which cpuidle driver is being used.  If 
 you
 know, could please check that?  And if the driver is intel_idle, then there is
 no mystery, they use those hardcoded values.

I think the mystery is solved then:

$ cat /sys/devices/system/cpu/cpuidle/current_driver
intel_idle

 Then, after about 4 minutes of uptime, C1ON changes to 1 (and
 powertop still reports the same states).

 OK, no difference here.  So it's probably done by firmware based on some 
 unknown
 logic.

It seems that way.

[1] http://tx97.net/~magv/dmesg-n143-verbose.82.txt
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: (Missing) power states of an Atom N455-based netbook

2011-07-01 Thread Andriy Gapon 
on 01/07/2011 14:54 Andriy Gapon said the following:
 Actually, it seems that they have them simply hardcoded:
 http://lxr.linux.no/#linux+v2.6.39/drivers/idle/intel_idle.c#L171

Here is a presentation on intel_idle driver that describes reasons for its
existence and some additional information.  I am not convinced that we need to
follow Linux example.  Unless Intel provides and maintains the driver for us 
like
it does for Linux :-)

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

Re: (Missing) power states of an Atom N455-based netbook

2011-07-01 Thread Andriy Gapon 
on 01/07/2011 16:25 Andriy Gapon said the following:
 on 01/07/2011 14:54 Andriy Gapon said the following:
 Actually, it seems that they have them simply hardcoded:
 http://lxr.linux.no/#linux+v2.6.39/drivers/idle/intel_idle.c#L171
 
 Here 

Yep, here :-)
http://events.linuxfoundation.org/slides/2010/linuxcon2010_brown.pdf

 is a presentation on intel_idle driver that describes reasons for its
 existence and some additional information.  I am not convinced that we need to
 follow Linux example.  Unless Intel provides and maintains the driver for us 
 like
 it does for Linux :-)
 


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

Re: (Missing) power states of an Atom N455-based netbook

2011-06-30 Thread Vitaly Magerya 
Andriy Gapon a...@freebsd.org wrote:
 on 28/06/2011 22:37 Vitaly Magerya said the following:
 Is there some simple way of sending fake advertisement? Or will
 that lead to disaster?

 It doesn't make sense without actual support.
 And maybe (just maybe) it won't change much anyway.

I see. Should I hold my breath for this code?

 Since we are now dealing with black box/magic behind ACPI, may I try to 
 suggest
 doing some DSDT hacks and seeing what changes?  One thing to try would be
 replacing \_SB.VDRV with VDRV in _Q51 and _Q52 methods.
 That at least should rid you of those annoying ACPI errors, at best it could
 improve something.  At the very worst it may fry your machine, though...

Just tried this. Nothing seems fried; the visible effect is that
now when I plug the power cord in backlight brightness turns all
the way up, and then back down the I turn it off. No changes in
SNVS or GNVS variables aside from the usual ones.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: (Missing) power states of an Atom N455-based netbook

2011-06-30 Thread Jung-uk Kim 
On Thursday 30 June 2011 03:49 pm, Vitaly Magerya wrote:
 Andriy Gapon a...@freebsd.org wrote:
  on 28/06/2011 22:37 Vitaly Magerya said the following:
  Is there some simple way of sending fake advertisement? Or will
  that lead to disaster?
 
  It doesn't make sense without actual support.
  And maybe (just maybe) it won't change much anyway.

 I see. Should I hold my breath for this code?

:-)

I have written a very rough patch and it is available from here:

http://people.freebsd.org/~jkim/acpi_cst.diff

It compiles but wasn't tested at all, i.e., I have no hardware.  
Please be careful.

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

Re: (Missing) power states of an Atom N455-based netbook

2011-06-30 Thread Vitaly Magerya 
Jung-uk Kim j...@freebsd.org wrote:
 I have written a very rough patch and it is available from here:

 http://people.freebsd.org/~jkim/acpi_cst.diff

 It compiles but wasn't tested at all, i.e., I have no hardware.
 Please be careful.

Cool. I'll try it.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: (Missing) power states of an Atom N455-based netbook

2011-06-30 Thread Vitaly Magerya 
Andriy Gapon a...@freebsd.org wrote:
 Here's what Intel docs say:

 The processor implements two software interfaces for requesting low power
 states, MWAIT instruction extensions with sub-state hints and P_LVLx reads to
 the ACPI P_BLK register block mapped in the processor's I/O address space. The
 P_LVLx I/O reads are converted to equivalent MWAIT C-state requests inside the
 processor and do not directly result in I/O reads on the processor FSB.

 My interpretation is that both mechanism should work equally.

I see.

 Just tried this. Nothing seems fried; the visible effect is that
 now when I plug the power cord in backlight brightness turns all
 the way up, and then back down the I turn it off. No changes in
 SNVS or GNVS variables aside from the usual ones.

 At least some improvement (or just a difference)...

Since VDRV is always 0, you can't really say if it's a coincidence
or the intended behavior.

 Not sure how to proceed here further.  Apparently we do something differently
 from Linux (and presumably Windows) here, but it's quite hard to tell what. 
 The
 problem is that SNVS/GNVS (in particular C1ON) seem to be controlled by some
 firmware/hardware and that's a black box.
 And I am still puzzled about which exactly event triggers change in C1ON value
 on FreeBSD...

I got the dumps for Linux (it appears that you can't just read
/dev/mem on there, you need to mmap it). The summary of differences
between FreeBSD and Linux right after the boot:

DB00: 01 - 00
P80D: 06:08:00:00 - 06:08:4C:00
PCP0: 1D - BF
PCP1: 1D - BF
BRTL: 00 - 1E
VDRV: 00 - 01

(Note that C1ON is 0 just as with FreeBSD, and yet powertop does
report C2 and C4).

Then, after about 4 minutes of uptime, C1ON changes to 1 (and
powertop still reports the same states).

 Do you have powerd enabled?  Can you check if anything changes
 with it disabled (just for the sake of testing).

I do; nothing changes if I don't.

 P.S. Just an idea, maybe the following script could be of some help if you
 have dtrace support in your kernel:
 $ dtrace -n 'fbt::AcpiEvaluateObject:entry { printf(%p-%s\n, args[0],
 (string)args[1]); }'
 I would like to get entries, if any, around the time that the C-states
 become available.

I'll try to compile the kernel with dtrace and post the results back.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org

Re: (Missing) power states of an Atom N455-based netbook

2011-06-28 Thread Jung-uk Kim 
On Tuesday 28 June 2011 07:28 am, Andriy Gapon wrote:
 I think that part (but not all) of the differences between FreeBSD
 and Linux can be explained by the fact that FreeBSD currently
 doesn't advertise itself as featuring ACPI_CAP_SMP_C1_NATIVE and
 ACPI_CAP_SMP_C3_NATIVE.  I am not sure what it would take to
 actually support these features.  I think that Linux does support
 (or at least advertise support) for these features.

Yes, Linux supports this Intel-specific feature.  I think it shouldn't 
be too hard for us, however.  We just have to add support for 
Intel-specific _CST FFH (Functional Fixed Hardware) in 
sys/dev/acpica/acpi_cpu.c.  You can find more information from Intel 
Processor Vendor-Specific ACPI (order number 302223-005) on Intel 
website.  Also, arch/x86/kernel/acpi/cstate.c of Linux source may 
help.  I believe Linux actually supports all Intel-specific FFHs, 
BTW.

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

Re: (Missing) power states of an Atom N455-based netbook

2011-06-28 Thread Andriy Gapon 
on 28/06/2011 22:37 Vitaly Magerya said the following:
 I think that part (but not all) of the differences between FreeBSD and Linux
 can be explained by the fact that FreeBSD currently doesn't advertise itself 
 as
 featuring ACPI_CAP_SMP_C1_NATIVE and ACPI_CAP_SMP_C3_NATIVE.  I am not sure
 what it would take to actually support these features.  I think that Linux 
 does
 support (or at least advertise support) for these features.
 
 Is there some simple way of sending fake advertisement? Or will
 that lead to disaster?

It doesn't make sense without actual support.
And maybe (just maybe) it won't change much anyway.

 I would be interested to see memory dumps of the above region both early
 after boot and later when you get additional C states.
 This can be done with:
 dd if=/dev/mem size=1 iseek=0x3F5C0C7D count=0x00FF

 [...]

 Then, PWRS is declared in GNVS region (Global Non-Volatile Storage?):
 OperationRegion (GNVS, SystemMemory, 0x3F5C0D7C, 0x0100)
 I would like to get two dumps for this region too.
 
 When I boot without power, I get these dumps [1,2]. For your
 convenience, the same dumps decoded are at [3,4]. After C2 and C3
 become available, I get mostly the same dumps [5,6]: only C1ON
 changes from 0 to 1.

Yep.  Now the biggest question is what that C1ON is and what changes its value.
And how do we (and Linux) trigger that change.

[snip]

 If someone will tell me how the hell do you dump memory in Linux,
 I'll submit the dumps for it too. Currently dd fails there with
 this error:
 
 $ sudo dd if=/dev/mem of=... bs=1 skip=0x3F5C0C7D count=0x00FF
 dd: read /dev/mem: Bad address
 
 (Reproduced by memory).

No idea here.
Maybe they don't allow to access memory reserved by kernel from userland, even
to root.

 [1] http://tx97.net/~magv/n143-acpi/mem-3f5c0c7d-before.bin
 [2] http://tx97.net/~magv/n143-acpi/mem-3f5c0d7c-before.bin
 [3] http://tx97.net/~magv/n143-acpi/mem-3f5c0c7d-before.txt
 [4] http://tx97.net/~magv/n143-acpi/mem-3f5c0d7c-before.txt
 [5] http://tx97.net/~magv/n143-acpi/mem-3f5c0c7d-after.bin
 [6] http://tx97.net/~magv/n143-acpi/mem-3f5c0d7c-after.bin


Since we are now dealing with black box/magic behind ACPI, may I try to suggest
doing some DSDT hacks and seeing what changes?  One thing to try would be
replacing \_SB.VDRV with VDRV in _Q51 and _Q52 methods.
That at least should rid you of those annoying ACPI errors, at best it could
improve something.  At the very worst it may fry your machine, though...

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

Re: (Missing) power states of an Atom N455-based netbook

2011-06-28 Thread Jung-uk Kim 
On Tuesday 28 June 2011 05:18 pm, Andriy Gapon wrote:
 on 29/06/2011 00:13 Jung-uk Kim said the following:
  On Tuesday 28 June 2011 03:37 pm, Vitaly Magerya wrote:
  I think that part (but not all) of the differences between
  FreeBSD and Linux can be explained by the fact that FreeBSD
  currently doesn't advertise itself as featuring
  ACPI_CAP_SMP_C1_NATIVE and ACPI_CAP_SMP_C3_NATIVE.  I am not
  sure what it would take to actually support these features.  I
  think that Linux does support (or at least advertise support)
  for these features.
 
  Is there some simple way of sending fake advertisement? Or will
  that lead to disaster?
 
  Actually, ACPI_CAP_SMP_C1_NATIVE is kinda supported but without
  hints from ACPI _CST FFH.  It sits in machdep.c as
  cpu_idle_mwait().  So, I think you can advertise them.  The
  easist way is this (not tested):

 But don't we currently ignore FFH-type C state definitions?

Correct.

 I am not sure that mwait that we use (its parameters) would be the
 same as the system would expect us to use unless we actually parse
 FFH data.  Even for C1 sate.

It is unfortunate but you're correct.  We don't have correct support 
code yet.

 Also I am not sure if that would give much gain/difference.

Just for the sake of testing your theory, nothing more, nothing less.

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

Re: (Missing) power states of an Atom N455-based netbook

2011-06-27 Thread Andriy Gapon 
on 25/06/2011 18:47 Vitaly Magerya said the following:
 Andriy Gapon a...@freebsd.org wrote:
 on 24/06/2011 22:13 Vitaly Magerya said the following:
 Right after I start the laptop I only see one supported power state:

 # sysctl dev.cpu.0.cx_supported
 dev.cpu.0.cx_supported: C1/1

 But after 4+ minutes of uptime more power states kick in:

 # sysctl dev.cpu.0.cx_supported
 dev.cpu.0.cx_supported: C1/1 C2/20 C3/100

 I'd like to have all Cx right after the boot. Is this possible?

 (The temporary solution I employ is to update hw.acpi.cpu.cx_lowest
 every time devd gets ACPI CMBAT message; this appears to happen
 right after cx_supported is updated).

 Hmm, strange...
 Can you check if FreeBSD thinks that the system is on AC power until that
 CMBAT message?  (I see in dmesg that during that boot it detected AC as
 disconnected).
 
 AC was indeed disconnected during that boot (and hw.acpi.acline was
 0 as expected). If I boot with power on the problem is the same:
 about 4 minutes there's only C1, after that there are C1 and C2 (C3
 kicks in too once I disable the power).

This is quite unexpected for me.
You can try to run devd in debug mode and capture its output in a file, so that
ACPI events could be examined.

 (I boot with power cord disconnected, since LCD brightness controls
 on the laptop don't work with FreeBSD, so that's the only way to
 turn the brightness down).
 
 Also, when I boot the same machine under Linux (latest Ubuntu),
 powertop reports C1, C2 and C4 right away. Is it possible to get
 C4 under FreeBSD as well?

 I believe that what FreeBSD reports as C3 is the same as what Linux reports
 as C4.
 
 The problem is that on Linux power consumption is 5.2W (without USB
 suspension or any other things powertop suggests), while on FreeBSD
 I'm seeing 6.8W with C3. I assumed this was due to C4/C3 difference,
 but maybe Linux is doing something differently.

Quite possible.

 Other ACPI problems, which I have are:
 1. When the power cord is plugged in, C3 state disappears.

 Does the same happen with Linux?
 Many notebooks disable deep Cx states when on AC power for some reason.
 
 No. On Linux C4 is reported both with and without AC plugged in.

It seems that possibly we present different OS capabilities to ACPI...
Needs more investigation.

Can you also send me two binary files produced as follows:
1. dd if=/dev/mem size=1 iseek=0x3F5B9B71 count=0x0203 of=...
2. dd if=/dev/mem size=1 iseek=0x3F5B92DA count=0x0708 of=...

Or, if it's not too much trouble for you, you can send results of decompilation
of those files using iasl -d filename

 2. When I plug (or unplug) the power cord I get these two messages:

ACPI Error: [\\_SB_.VDRV] Namespace lookup failure, AE_NOT_FOUND
(20101013/psargs-464) ACPI Error: Method parse/execution failed

[\\_SB_.PCI0.LPC0.H_EC._Q51] (Node 0xc42ac1e0), AE_NOT_FOUND
(20101013/psparse-633)

(This appears to be harmless).

 Not sure about these, looks like some additional/external table is not
 loaded. You may check if the same happens with the latest ACPICA in FreeBSD
 CURRENT.
 
 I just tried it with CURRENT snapshot from 2011-05-12; it behaves
 the same.
 
 (For the record, Linux reports similar messages).

Ok, then this is most likely a mistake of BIOS writers, it seems.

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

Re: (Missing) power states of an Atom N455-based netbook

2011-06-25 Thread Andriy Gapon 
on 24/06/2011 22:13 Vitaly Magerya said the following:
 Hi, folks. I'm having a problem with ACPI on an Atom N455-based
 netbook (Samsung N143-DP05UA to be precise).
 
 Right after I start the laptop I only see one supported power state:
 
 # sysctl dev.cpu.0.cx_supported
 dev.cpu.0.cx_supported: C1/1
 
 But after 4+ minutes of uptime more power states kick in:
 
 # sysctl dev.cpu.0.cx_supported
 dev.cpu.0.cx_supported: C1/1 C2/20 C3/100
 
 I'd like to have all Cx right after the boot. Is this possible?
 
 (The temporary solution I employ is to update hw.acpi.cpu.cx_lowest
 every time devd gets ACPI CMBAT message; this appears to happen
 right after cx_supported is updated).

Hmm, strange...
Can you check if FreeBSD thinks that the system is on AC power until that CMBAT
message?  (I see in dmesg that during that boot it detected AC as disconnected).

 Also, when I boot the same machine under Linux (latest Ubuntu),
 powertop reports C1, C2 and C4 right away. Is it possible to get
 C4 under FreeBSD as well?

I believe that what FreeBSD reports as C3 is the same as what Linux reports as 
C4.

 Other ACPI problems, which I have are:
 1. When the power cord is plugged in, C3 state disappears.

Does the same happen with Linux?
Many notebooks disable deep Cx states when on AC power for some reason.

 2. When I plug (or unplug) the power cord I get these two messages:
 
ACPI Error: [\\_SB_.VDRV] Namespace lookup failure, AE_NOT_FOUND
(20101013/psargs-464) ACPI Error: Method parse/execution failed
 
[\\_SB_.PCI0.LPC0.H_EC._Q51] (Node 0xc42ac1e0), AE_NOT_FOUND
(20101013/psparse-633)
 
(This appears to be harmless).

Not sure about these, looks like some additional/external table is not loaded.
You may check if the same happens with the latest ACPICA in FreeBSD CURRENT.

 My verbose dmesg is at [1], ASL dump is at [2], loader.conf is:
 
 kern.hz=100
 hint.p4tcc.0.disabled=1
 hint.acpi_throttle.0.disabled=1
 hw.pci.do_power_nodriver=3
 hint.apic.0.clock=0
 hint.atrtc.0.clock=0
 
 And sysctl hw.acpi output is:
 
 hw.acpi.supported_sleep_state: S3 S4 S5
 hw.acpi.power_button_state: S5
 hw.acpi.sleep_button_state: S3
 hw.acpi.lid_switch_state: NONE
 hw.acpi.standby_state: NONE
 hw.acpi.suspend_state: S3
 hw.acpi.sleep_delay: 1
 hw.acpi.s4bios: 0
 hw.acpi.verbose: 0
 hw.acpi.disable_on_reboot: 0
 hw.acpi.handle_reboot: 1
 hw.acpi.reset_video: 0
 hw.acpi.cpu.cx_lowest: C3
 hw.acpi.acline: 0
 hw.acpi.thermal.min_runtime: 0
 hw.acpi.thermal.polling_rate: 10
 hw.acpi.thermal.user_override: 0
 hw.acpi.thermal.tz0.temperature: 54.0C
 hw.acpi.thermal.tz0.active: -1
 hw.acpi.thermal.tz0.passive_cooling: 1
 hw.acpi.thermal.tz0.thermal_flags: 0
 hw.acpi.thermal.tz0._PSV: 90.0C
 hw.acpi.thermal.tz0._HOT: -1
 hw.acpi.thermal.tz0._CRT: 98.0C
 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 hw.acpi.thermal.tz0._TC1: 0
 hw.acpi.thermal.tz0._TC2: 10
 hw.acpi.thermal.tz0._TSP: 2
 hw.acpi.battery.life: 46
 hw.acpi.battery.time: 194
 hw.acpi.battery.state: 1
 hw.acpi.battery.units: 1
 hw.acpi.battery.info_expire: 5
 
 PS. Please CC me, I'm not subscribed.
 
 [1] http://tx97.net/~magv/dmesg-n143-verbose.82.txt
 [2] http://tx97.net/~magv/n143.asl


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