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
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
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
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
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')
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
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
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
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
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.
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 :-)
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
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
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.
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.
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
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
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
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
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
20 matches
Mail list logo
