Re: Possible bug in acpi_video(4)

[Andriy Gapon]

On 29/05/2020 14:39, MrPhyber wrote:
> Nevermind, after some thinkering I managed to get it to work on
> drm-fbsd12.0-kmod. Now the hardware brightness controls work!
> I am really grateful, thank you. I wonder when this patch will
> be pushed upstream.

In fact, the piece of change that updates amdgpu_atif_handler() is already in 
Linux.
But the LKPI ACPI glue seems to need a bit more polish (or a proper design).

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

Re: Possible bug in acpi_video(4)

[Andriy Gapon]

On 28/05/2020 13:02, MrPhyber wrote:
> 
> I tried the patch you sent, and I have a few questions:
> 1) when will this patch be avaiable on 12.1-RELEASE?

In stable/12 soon.
In 12.1 probably never as the release has been released.

> 2) now the system does not spit out any more errors like
> the one complaining about _BQC missing: in fact it doesn't
> give errors at all, but the hardware brightness controls still
> won't work. Now hw.acpi.video.lcd0.active = 1 but if I try
> to modify hw.acpi.video.lcd0.brightness nothing appens. I
> still think that acpi_video doesn't see all video outputs
> (I investigated a bit further and on OpenBSD there are
> acpivouts on dmesg output, could be an hint). What could
> be wrong?

If your system is like mine then ACPI does not directly control the brightness.
Instead, it posts some events that a video driver (like radeon or amdgpu) is
supposed to listen to and then the driver should update the brightness.
(This can also be thought of as the brightness being controlled by the video
"card" / GPU rather than by a motherboard).
For my laptop I had to patch amdgpu driver:
https://github.com/FreeBSDDesktop/kms-drm/pull/241


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

Re: Possible bug in acpi_video(4)

[Andriy Gapon]

On 28/05/2020 00:34, MrPhyber via freebsd-acpi wrote:
> Hello everyone,
> my laptop is an Acer Swift SF315-41 with an AMD Ryzen 2500U.
> I'm on FreeBSD 12.1-RELEASE-p5 with drm-fbsd12-kmod (amdgpu).
> Everything works on this machine except for the hardware brightness controls.
> On OpenBSD and Linux they work like a charm, and so I think that there is a
> problem in acpi_video(4). I will attach dmesg and acpidump. Whenever I
> try to use the hardware brightness switches, this pops up on
> the system messages: "can't evaluate \_SB_.PCI0.GP17.VGA_.LCD_._BQC - 
> AE_NOT_FOUND". As you will see, FreeBSD sees acpi_video0 only, and this is
> always inactive (sysctl: hw.acpi.video.lcd0.active = 0), but OpenBSD sees 
> acpi_video0, acpi_video1, and others with VGA. Don't know what's the
> matter here, any suggestions?


Please see
 https://svnweb.freebsd.org/base?view=revision=360657
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207086

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

[CFT] call AcpiLeaveSleepStatePrep after re-enabling interrupts

[Andriy Gapon]

I would like ask for help with testing this change
https://reviews.freebsd.org/D15306

I want to do this change because that call (actually,
AcpiHwLegacyWakePrep) does a memory allocation and ACPI namespace
evaluation. Although it is not very likely to run into any trouble, it
is still not safe to make those calls with interrupts disabled. Also,
AcpiLeaveSleepStatePrep is documented as called when interrupts are
enabled. witness(4) and malloc(9) do not currently check for a context
with interrupts disabled via intr_disable and we lack a facility for
doing that. So, those unsafe operations fly under the radar. But if
intr_disable in acpi_EnterSleepState was replaced with spinlock_enter
(which it probably should be), then witness and malloc would
immmediately complain.

The ACPI wakeup sequence is very sensitive to changes, but I consider
this change to be rather safe. What AcpiHwLegacyWakePrep essentially
does is writing a value corresponding to S0 into SLP_TYPx bits of PM1
Control Register(s). According to ACPI specifications that write should
be a NOP as SLP_EN bit is not set. Additionally, there are no accesses
to ACPI hardware and firmware between the old location of the call and
the new one. So, the move should not affect the interaction between
then OS and ACPI platform.

Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c   (revision 333269)
+++ sys/dev/acpica/acpi.c   (working copy)
@@ -2975,8 +2975,6 @@ acpi_EnterSleepState(struct acpi_softc *sc, int st
if (sleep_result == 1 && state != ACPI_STATE_S4)
AcpiWriteBitRegister(ACPI_BITREG_SCI_ENABLE, ACPI_ENABLE_EVENT);

-   AcpiLeaveSleepStatePrep(state);
-
if (sleep_result == 1 && state == ACPI_STATE_S3) {
/*
 * Prevent mis-interpretation of the wakeup by power button
@@ -3005,6 +3003,8 @@ acpi_EnterSleepState(struct acpi_softc *sc, int st
/* call acpi_wakeup_machdep() again with interrupt enabled */
acpi_wakeup_machdep(sc, state, sleep_result, 1);

+   AcpiLeaveSleepStatePrep(state);
+
if (sleep_result == -1)
goto backout;


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

Re: Temorarily disabling ACPI errors

[Andriy Gapon]

On 04/05/2018 23:43, Don Whitteker wrote:
> However I am getting spammed with 4 lines of
> errors every 3-5 seconds.

What are the errors?

> This is making it near impossible to type out
> anything but short commands at the prompt. I can't even open a file in vi
> to try to edit before the spam covers the first 4 lines and makes it
> impossible to read or edit.

Are you saying that the messages go to all terminals / consoles?
Or are you stuck at a single console (like ttyv0) for some reason (e.g. single
user mode)?

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

Fwd: ACPICA missing support for device I/O port ranges

[Andriy Gapon]

Perhaps you would be interested in this message on hackers@.


 Forwarded Message 
Subject: ACPICA missing support for device I/O port ranges
Date: Sat, 18 Nov 2017 18:52:54 +0100
From: Harald Böhm 
To: 'freebsd-hack...@freebsd.org' 


Hi all,

I've been working on a device driver lately and was having trouble
allocating its resources using bus_alloc_resource_any(), although its
I/O ports can be read from its _CRS.

This is the output of acpidump -td:

Device (GMUX)
{
...
Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
{
IO (Decode16,
0x0700, // Range Minimum
0x07FF, // Range Maximum
0x01,   // Alignment
0xFF,   // Length
)
})
...
}

After digging into the code in /sys/dev/acpica/acpi_resources.c I was
able to find the problem. The function acpi_res_set_iorange(), which
seems to be responsible for calling bus_set_resource() is just a
function stub that prints a message that I/O ranges are not supported.

static void
acpi_res_set_iorange(device_t dev, void *context, uint64_t low,
 uint64_t high, uint64_t length, uint64_t align)
{
struct acpi_res_context *cp = (struct acpi_res_context *)context;

if (cp == NULL)
return;
device_printf(dev, "I/O range not supported\n");
}

After adding a call to bus_set_resource() to that function, I was able
to allocate the device's resources.

Does anyone know, why the function has not been implemented or why I/O
ranges are not supported?

Thanks,
Harald

___


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

Re: acpi suspend debugging techniques?

[Andriy Gapon]

On 04/09/2015 01:18, Jung-uk Kim wrote:
> AFAICT, the whole suspend/resume code looks incomplete and very messy.
>  In fact, I'll be very surprised if it ever worked. :-(

It does seem to work for me with the patch and other people report that the code
works for them even without the patch.

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

Re: ENXIOing non-present battery

[Andriy Gapon]

On 07/12/2014 22:49, Colin Percival wrote:
 On 12/07/14 08:03, Adrian Chadd wrote:
 Wait - so it reports a battery with 0% in it, but not that it's not present?
 
 It reports all zeroes: Not Present, 0% power, 0V, 0mA design capacity, etc.
 
 How's this work on other systems? KDE on Linux doesn't lose its mind
 if the second battery is totally flat.
 
 Good question.  I'll download an Ubuntu image and find out.  Given that KDE
 gets this information via hald, it's possible that hald's linux code has a
 workaround for this though -- the battery-status-reading code is entirely
 separate between FreeBSD and Linux.

Or that HAL is no longer used at all in most Linux-based OSes...

-- 
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: 9.2-RC3 - suspend/resume causes slow system performance

[Andriy Gapon]

on 01/09/2013 02:40 Adrian Chadd said the following:
 
 
 
 On 31 August 2013 10:35, Mike Harding mvhard...@gmail.com
 mailto:mvhard...@gmail.com wrote:
 
 I've tracked this down to a single line, details in
 http://www.freebsd.org/cgi/query-pr.cgi?pr=181632.  Basically, the code is
 now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to 
 run
 if idle is disabled.  Given that 'hlt' is the idle instruction, this 
 doesn't
 seem right.
 
 
 Wow, nice!
 
 Avg - can we get this fixed? Or just revert this!

Thank you for trying to be helpful.  But let's not jump to conclusions.
BTW, I am following up on the problem in the PR.

-- 
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: 9.2-RC3 - suspend/resume causes slow system performance

[Andriy Gapon]

on 02/09/2013 00:58 Adrian Chadd said the following:
 On 1 September 2013 14:35, Andriy Gapon a...@freebsd.org
 mailto:a...@freebsd.org wrote:
  
 
 Do you have any evidence that there is anybody else besides Mike who has 
 this
 problem?
 
 
 
 Nope! but we can't assume that users are reporting all the system slowdowns.

Why?

 And honestly, I've heard enough strange stories on mailing lists and IRC of
 things like during disk IO, blah would be really slow, when I change
 timekeeping or halt from ACPI to something else, things get better. So I 
 can't
 discount that this is affecting people and they either don't know, or just 
 chalk
 it up as shitty hardware.

Strange stories are just that.

 Also, I usually try to sort out things after there is a clear 
 understanding of
 what the problem is and how it should be fixed.
 
 
 Well, the big change is that it's now going into a sleep state on a HT core, 
 right?
 
 Are you able to go into an ACPI sleep state on a HT logical CPU, rather than 
 the
 physical core? Or am I mis-understanding what's going on?

Most likely.  I do not see how the change is HT-specific or HT-related at all.

 
  Reverting and fixing it later seems like the safest option to me. Is 
 there a
  bigger problem that you tried to fix in that patch that wasn't as 
 obvious?
 
 I do not see any problem with the code*.*  I do not see any explanation 
 of the
 root cause of the problem that Mike has.  I do not see why anything has 
 to be
 reverted.  Especially because since we're so close to 9.2-REL.
 Just in case, I'll remind that the commit in question is in stable/9 
 since Dec
 23 2012.
 
 
 Right, but I also know a lot of people who just have stayed with 8.x or
 9.0-RELEASE and haven't bothered upgrading. Again, I can't assume that 
 everyone
 has been keeping up to date with stable/9 and providing feedback.

I am positive that it's not everyone who uses (up-to-date) stable/9.  Still, I
believe that a user-base of stable/9 is  1.

-- 
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: 9.2-RC3 - suspend/resume causes slow system performance

[Andriy Gapon]

on 02/09/2013 01:21 Adrian Chadd said the following:
 .. well, when is that pointer NULL?

It's never NULL.  But that is besides the point as we are talking about a
different check.

* if (is_idle_disabled(sc)) {*
-   ACPI_ENABLE_IRQS();
+   acpi_cpu_c1();

 It looks like it's supposed to be NULL for
 one pair of the two HT CPUs?
 
 Are you taking the whole core into an ACPI idle state if one of two logical 
 CPUs
 representing a core is going idle?

-- 
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: 9.2-RC3 - suspend/resume causes slow system performance

[Andriy Gapon]

on 02/09/2013 02:13 Mike Harding said the following:
 I'll ask again, why change that line? 

I got your question the first few times you asked it.
I do not see why you keep asking it when nobody has a clear explanation of what
exactly is going on on your system and I've already told that I want to
investigate / analyze that first.

-- 
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: panics due to buggy ACPI in Dell Latitude E6530?

[Andriy Gapon]

on 31/03/2013 14:42 kron said the following:
 I'm sorry I forgot to update the thread - good you're reminding.
 Andriy did a brilliant job at debugging the issue and I owe him
 to say in public: Thank you, Andriy!

I also apologize for not sharing the information promptly.

So here is a summary.

The problem turned out to be with the reference count in ACPICA.  It doesn't 
have
any internal locking and so it relied on locks obtained by the callers.  But not
all of the callers obtained the relevant locks (namespace, interpreter) and they
not really needed them (except for the reference counting).  Also, our
acpi_battery driver uses ACPICA interfaces that were problematic.  Additionally
the driver allows parallel queries, not sure if that is an intentional choice.

So now the ACPICA developers have fixed the reference counting code and no 
changes
in FreeBSD code should be required.  We are just waiting for the next ACPICA 
release.
That's for head.  Not sure which approach we will take for stable branches,
because we haven't been doing any MFCs of ACPICA imports.  So there are tow 
choices:
- use the below patch to prevent parallel execution in the batter driver
- manually apply the specific reference count change to ACPICA code in the 
branches

Finally many thanks to Olli/kron for doing a lot of testing and debugging.
And many thanks to Tom Lislegaard who did a lot of testing and debugging too - 
in
our debugging session I reached all the same conclusions and came up with a
(different) patch, but then got distracted and completely forgot about the issue
until it resurfaced again.


 The results are:
  - hw.acpi.osname=Linux is not relevant
  - there's some ACPICA issue Andriy took to discuss with other
hackers (and much above my competence to comment)
  - a temporary workaround:
 
 --- sys/dev/acpica/acpi_battery.c   (revision 248682)
 +++ sys/dev/acpica/acpi_battery.c   (working copy)
 @@ -360,6 +360,8 @@
  int error, unit;
  device_t dev;
 
 +mtx_lock(Giant);
 +
  /* For commands that use the ioctl_arg struct, validate it first. */
  error = ENXIO;
  unit = 0;
 @@ -417,6 +419,7 @@
 error = EINVAL;
  }
 
 +mtx_unlock(Giant);
  return (error);
  }
 
 The patch works for me without any problem. I guess it won't hurt
 your system ;-) but I actually don't know if/how it relates to your
 PR.


-- 
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: panics due to buggy ACPI in Dell Latitude E6530?

[Andriy Gapon]

on 02/04/2013 10:29 David Demelier said the following:
 Thanks for that small patch, I'm currently testing it and will tell
 you how it works for me,

The best way to check is to run several
while true ; do acpiconf -i N ; done
in parallel.
If the system survives, then it will most likely survive the typical use too.

-- 
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: call suspend_cpus() under smp_ipi_mtx

[Andriy Gapon]

on 01/04/2013 17:52 John Baldwin said the following:
 Hmm, I think intr_table_lock used to be a spin lock at some point.  I don't 
 remember
 why we changed it to a regular mutex.  It may be that there was a lock order 
 reason
 for that. :(

I came up with the following patch:
http://people.freebsd.org/~avg/intr_table_lock.diff

Please note the witness change.  Part of it is to prepare for smp_ipi_mtx -
intr_table_lock order, but I also had to move entropy harvest mutex because it
is used with msleep_spin. Also intr_table_lock interacts with sched lock.

This seems to work without problems or any warnings with WITNESS 
!WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the
relevant code paths.

P.S. Looking through history it seems that in r169391 intr_table_lock
was changed from a spinlock to a sx lock (later it was changed to the current
mutex).  The commit message explains why spinlock was not needed, but it doesn't
seem to say why it was unacceptable:

 Minor fixes and tweaks to the x86 interrupt code: - Split the intr_table_lock
into an sx lock used for most things, and a spin lock to protect intrcnt_index.
Originally I had this as a spin lock so interrupt code could use it to lookup
sources. However, we don't actually do that because it would add a lot of 
overhead
to interrupts, and if we ever do support removing interrupt sources, we can use
other means to safely do so w/o locking in the interrupt handling code. - 
Replace
is_enabled (boolean) with is_handlers (a count of handlers) to determine if a
source is enabled or not. This allows us to notice when a source is no longer in
use. When that happens, we now invoke a new PIC method (pic_disable_intr()) to
inform the PIC driver that the source is no longer in use. The I/O APIC driver
frees the APIC IDT vector when this happens. The MSI driver no longer needs to
have a hack to clear is_enabled during msi_alloc() and msix_alloc() as a result 
of
this change as well. - Add an apic_disable_vector() to reset an IDT vector back 
to
Xrsvd to complement apic_enable_vector() and use it in the I/O APIC and MSI code
when freeing an IDT vector. - Add a new nexus hook: nexus_add_irq() to ask the
nexus driver to add an IRQ to its irq_rman. The MSI code uses this when it 
creates
new interrupt sources to let the nexus know about newly valid IRQs. Previously 
the
msi_alloc() and msix_alloc() passed some extra stuff back to the nexus methods
which then added the IRQs. This approach is a bit cleaner. - Change the MSI sx
lock to a mutex. If we need to create new sources, drop the lock, create the
required number of sources, then get the lock and try the allocation again.


-- 
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: call suspend_cpus() under smp_ipi_mtx

[Andriy Gapon]

Looks like this issue needs more thinking and discussing.

The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on
SMP systems).
This is for exactly the same reasons as to why we first take smp_ipi_mtx before
calling stop_cpus() in the shutdown path.  Essentially one CPU could be holding
smp_ipi_mtx (and thus with interrupts disabled[*]) and waiting for an
acknowledgement from other CPUs (e.g. in smp_rendezvous or in a TLB shootdown),
while another CPU could be with interrupts disabled (explicitly - like in the
shutdown or ACPI suspend paths) and trying to deliver an IPI to other CPUs.

In my opinion, we must consistently use the same lock, smp_ipi_mtx, for all
regular (non-NMI) synchronous IPI-based communication between CPUs.  Otherwise a
deadlock is quite possible.

Some obstacles for just going ahead and making the suggested change:

- acpi_sleep_machdep() calls intr_suspend() with interrupts disabled; currently
witness(9) is not aware of that, but if smp_ipi_mtx spin-lock is used, then we
would have to make intr_table_lock and msi_lock the spin-locks as well;
- AcpiLeaveSleepStatePrep() (from ACPICA) is called with interrupts disabled and
currently it performs an action that requires memory allocation; again, with
interrupts disabled via intr_disable() this fact is not visible to witness, etc,
but with smp_ipi_mtx it needs to be somehow handled.

I talked to ACPICA guys about the last issue and they told me that what is
currently done in AcpiLeaveSleepStatePrep does not need to be with interrupts
disabled and can be moved to AcpiLeaveSleepState.  This is after the _BFS and
_GTS support was removed.

What do you think?
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: ACPI Debugging

[Andriy Gapon]

on 16/03/2013 11:06 Andriy Gapon said the following:
 on 16/03/2013 10:10 Sean Bruno said the following:
 debug.acpi.level=ACPI_LV_VERBOSE

BTW, please also note what acpi(4) says about this level as opposed to e.g.
ACPI_LV_VERBOSITY3.


-- 
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: panics due to buggy ACPI in Dell Latitude E6530?

[Andriy Gapon]

on 28/02/2013 17:44 Moore, Robert said the following:
 ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node
 0xfe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113)
 
 Sorry, could not reproduce the problem here:
 
 
 - ex _SB_.BAT0._UID
 Evaluating \_SB_.BAT0._UID
 Evaluation of \_SB_.BAT0._UID returned object 000342A0, external buffer 
 length 10
   [Integer] = 0001

To me it is semi-obvious that the reported problem is a consequence of the 
FreeBSD
heisenbug that I reported before.  The one that messes up the internal state 
of
ACPICA and which I previously blamed either on ACPICA object cache or ACPICA
reference counting.  But now I am inclined to think that it is caused by 
something
in FreeBSD adaptation layer.

-- 
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: panics due to buggy ACPI in Dell Latitude E6530?

[Andriy Gapon]

on 27/02/2013 17:22 kron said the following:
 Hi,
 
 I have a Dell notebook (Latitude E6530) on which I track
 9-STABLE. It served excellently until mid-Jan when it started
 to panic a few times a week or so:
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 3; apic id = 03
 fault virtual address = 0x10116
 fault code= supervisor read data, page not present
 instruction pointer   = 0x20:0x802bc360
 stack pointer = 0x28:0xff848f6db390
 frame pointer = 0x28:0xff848f6db3c0
 code segment  = base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags  = interrupt enabled, resume, IOPL = 0
 current process   = 2199 (conky)
 trap number   = 12
 panic: page fault
 cpuid = 3
 
 Before the panics kernel used to emit messages like:
 ACPI Error: No object attached to node 0xfe00094a51c0
 (20110527/exresnte-138)
 ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node
 0xfe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113)

This looks very much like a heisenbug reported several times here.
E.g.:
http://lists.freebsd.org/pipermail/freebsd-acpi/2012-December/007962.html

 I suspected it started with a BIOS update (A07 - A09).
 Following the handbook, I took a look at acpidump. Sad to say,
 it all was Greek to me, I could't even compile it back using
 iasl (35 Errors). However, while skimming it I noticed names
 of many versions of Windows and in addition to that, Linux.
 Just to try, I put hw.acpi.osname=Linux to /boot/loader.conf.
 Since that I've never get the panic again (for ~3 weeks).
 I hope this is not just a coincidence.

It very well could be.

 Maybe this experience can help somebody else.
 
 If any of ACPI developers wants to play with the problem
 I can provide more info (sorry, no crashdump, was not enabled),
 do tests, etc.

Please at least enable printing of a stack trace.
Better do get the crash dump.

P.S. I suspect that the issue we are discussing with hps in this mailing list
could be related to this problem.

-- 
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: uma for acpi object cache

[Andriy Gapon]

on 24/01/2013 22:33 Jung-uk Kim said the following:
 If I am not completely mistaken, this is what's happening:
 
 https://github.com/otcshare/acpica/pull/3
 
 Please see ACPI_OBJECT_COMMON_HEADER macro change in the commit I
 mentioned the pull request.
 
 Before the commit:
 UINT8   Descriptor;
 UINT8   Type;
 UINT16  ReferenceCount;
 union acpi_operand_object   *NextObject;
 UINT8   Flags;
 
 After the commit:
 union acpi_operand_object   *NextObject;
 UINT8   DescriptorType;
 UINT8   Type;
 UINT16  ReferenceCount;
 UINT8   Flags;
 
 It may not look obvious but LinkOffset was used to keep offset of
 NextObject (and it was only safe for certain compilers  platforms).
 
 Alas, it is completely bogus now because the pointer became the first
 element of any object.  Although it was the right decision, the author
 forgot to change the LinkOffset with this commit, I guess.  Now,
 modifying DescriptorType, Type, ReferenceCount, or Flags silently
 corrupts the linked list.  Similarly, modifying any of these before
 setting the pointer gets silently clobbered.  For example,
 ACPI_SET_DESCRIPTOR_TYPE() in AcpiOsReleaseObject() is effectively
 no-op because it's overwritten later.
 
 Does it make sense to you?

Hmm, not sure...

Are you trying to improve behavior in use-after-free scenario or some such
abnormal situation?

My understanding is this.  An object is either in use or it's free/cached.  When
it is in use, then LinkOffset has nothing to do with object (cache linking is
not applied to the object).  When it is cached, then it is not accessed as the
real object (via ACPI_OBJECT_COMMON_HEADER fields), it is accessed only as a
cached entity via the LinkOffset hackery.

So, I do not see any bug in the current code.

Your change makes it look a little bit less ugly, though.  But I do not see any
functional change.

-- 
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: uma for acpi object cache

[Andriy Gapon]

on 24/01/2013 22:33 Jung-uk Kim said the following:
 On 2013-01-24 13:49:07 -0500, Andriy Gapon wrote:
 on 24/01/2013 20:29 Jung-uk Kim said the following:
 BTW, I tried something like that long ago.  In fact, the first
 attempt goes all the way back to this patch (warning: it's naive,
 broken, and overly complicated):

 http://people.freebsd.org/~jkim/acpica/OsdCache.diff

 I have more up-to-date and correct patch to use UMA but I'm still
 not 100% convinced whether we want to do it or not.
 
 Hmm, your patch looks a bit more complicated than mine. What is all
 that extra stuff that you have there?
 
 The main issue was AcpiOsPurgeCache().  For example, we didn't have
 anything like Linux's kmem_cache_shrink() at the time:
 
 http://www.kernel.org/doc/htmldocs/kernel-api/API-kmem-cache-shrink.html
 
 It seems you implemented that with zone_drain() but it wasn't
 available until this commit:
 
 http://svnweb.freebsd.org/base?view=revisionrevision=166213
 
 Also, I had to make sure the cache is empty before we do
 uma_zdestroy(), so on and so forth.

OK, I see.  I don't think that any of that is really needed (now).
If you don't object I'll commit my variant in 1-2 weeks from now.

-- 
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: uma for acpi object cache

[Andriy Gapon]

on 24/01/2013 22:33 Jung-uk Kim said the following:
 On 2013-01-24 13:49:07 -0500, Andriy Gapon wrote:
 on 24/01/2013 20:29 Jung-uk Kim said the following:
 When utcache.c works, it works fairly well, actually. :-)
 
 Well, my primary motivation for the patch is all the reports about
 mysterious panics that seem to involve the cache: 
 http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7562 
 http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7613 
 http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7077
 
 There were a few more reports with the same theme. I hoped that
 using uma(9) instead of hand-rolled code would lead to better 
 diagnostic and debugging cabilities.
 
 Hmm...  I am not really sure local cache is to blame here.  If you
 really want to prove your theory, I think a simple modification to
 utcache.c should do:
 
  Cache-LinkOffset = 8;
  Cache-ListName   = CacheName;
  Cache-ObjectSize = ObjectSize;
 -Cache-MaxDepth   = MaxDepth;
 +Cache-MaxDepth   = 0;
 
  *ReturnCache = Cache;
  return (AE_OK);
 
 This should effectively kill object caching.

That's a very simple trick, I wonder why I didn't think about it :-)
Now I need to wait until one of the reporters resurfaces.

-- 
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

acpi resume related patch

[Andriy Gapon]

If you have ACPI suspend/resume working, if it used to work but stopped working
at some time, if it never worked, but you are still hoping, could you please
test the following patch and report back?

http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch

-- 
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: Kernel panic when playing games/iourbanterror

[Andriy Gapon]

on 24/12/2012 15:52 David Demelier said the following:
 #6  0x806e81bf in calltrap ()
 at /usr/src/sys/amd64/amd64/exception.S:228
 #7  0x802c6f15 in AcpiUtUpdateObjectReference (
 Object=0xfe0001824a80, Action=0)
 at /usr/src/sys/contrib/dev/acpica/utilities/utdelete.c:563
 #8  0x802b77a4 in AcpiExResolveNodeToValue (
 ObjectPtr=0xfe0001a2c2e0, WalkState=0xfe0001a2c000)
 at /usr/src/sys/contrib/dev/acpica/executer/exresnte.c:184
 #9  0x802b7ad3 in AcpiExResolveToValue (StackPtr=0xfe0001a2c2e0,
 WalkState=0xfe0001a2c000)
 at /usr/src/sys/contrib/dev/acpica/executer/exresolv.c:124
 #10 0x802ac433 in AcpiDsEvaluateNamePath 
 (WalkState=0xfe0001a2c000)
 at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:886
 ---Type return to continue, or q return to quit---
 #11 0x802aceef in AcpiDsExecEndOp (WalkState=0xfe0001a2c000)
 at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:436
 #12 0x802c05ba in AcpiPsParseLoop (WalkState=0xfe0001a2c000)
 at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249
 #13 0x802c10a8 in AcpiPsParseAml (WalkState=0xfe0001a2c000)
 at /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525
 #14 0x802c1d45 in AcpiPsExecuteMethod (Info=0xfe0033df8540)
 at /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368
 #15 0x802bb784 in AcpiNsEvaluate (Info=0xfe0033df8540)
 at /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193
 #16 0x802bec91 in AcpiEvaluateObject (Handle=0xfe00017f7b80,
 Pathname=0x8078229f _BST, ExternalParams=0x0,
 ReturnBuffer=0xff80d89ac960)
 at /usr/src/sys/contrib/dev/acpica/namespace/nsxfeval.c:289
 #17 0x80309802 in acpi_cmbat_get_bst (arg=Variable arg is not 
 available.
 )
 at /usr/src/sys/dev/acpica/acpi_cmbat.c:257
 #18 0x80309af8 in acpi_cmbat_bst (dev=0xfe0001936400,
 bstp=0xfe008b319400) at /usr/src/sys/dev/acpica/acpi_cmbat.c:418
 #19 0x8045bd22 in devfs_ioctl_f (fp=0xfe001ba256e0,
 com=3231990289, data=Variable data is not available.
 ) at /usr/src/sys/fs/devfs/devfs_vnops.c:757
 #20 0x8053a23d in kern_ioctl (td=0xfe00039ae8e0, fd=Variable fd 
 is
 not available.
 ) at file.h:293
 #21 0x8053a4ad in sys_ioctl (td=0xfe00039ae8e0,
 uap=0xff80d89acb70) at /usr/src/sys/kern/sys_generic.c:691
 ---Type return to continue, or q return to quit---
 #22 0x806fc902 in amd64_syscall (td=0xfe00039ae8e0, traced=0)
 at subr_syscall.c:135
 #23 0x806e84a7 in Xfast_syscall ()
 at /usr/src/sys/amd64/amd64/exception.S:387
 #24 0x000801d89c5c in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 
 Before the panic, a lot of ACPI Error appears in dmesg like that :
 
 ACPI Error: Method execution failed [\\_SB_.BAT0._UID] (Node 
 0xfe00017f7b00),
 AE_AML_NO_OPERAND (20110527/uteval-113)
 ACPI Error: No object attached to node 0xfe00017f7b00 
 (20110527/exresnte-139)
 ACPI Error: Method execution failed [\\_SB_.BAT0._UID] (Node 
 0xfe00017f7b00),
 AE_AML_NO_OPERAND (20110527/uteval-113)
 ACPI Error: No object attached to node 0xfe00017f7b00 
 (20110527/exresnte-139)
 
 This happens on 9.1-RELEASE amd64

Could you please try a patch from a parallel thread:
http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7562/focus=7611
?

-- 
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: ACPI panic

[Andriy Gapon]

Stefan,

long time, no news...

So, I decided to attempt a different approach to the problem.
Could you please try the following patch if you are still experiencing the
problem?  Could you please report how it goes?

My hope is that, even if the problem persist, it will be easier to debug it
using FreeBSD built-in debugging capabilities like INVARIANTS, WITNESS,
DEBUG_MEMGUARD, etc.

commit 12a6b3610b82e5370bf32f3c3ea5ac1fae46bb63
Author: Andriy Gapon a...@icyb.net.ua
Date:   Sun Dec 23 19:52:26 2012 +0200

[test] acpi: use uma instead of acpica internal object cache implementation

diff --git a/sys/contrib/dev/acpica/include/platform/acfreebsd.h
b/sys/contrib/dev/acpica/include/platform/acfreebsd.h
index d7aa7ed..2f2abd6 100644
--- a/sys/contrib/dev/acpica/include/platform/acfreebsd.h
+++ b/sys/contrib/dev/acpica/include/platform/acfreebsd.h
@@ -54,7 +54,6 @@
 #define ACPI_UINTPTR_T  uintptr_t

 #define ACPI_USE_DO_WHILE_0
-#define ACPI_USE_LOCAL_CACHE
 #define ACPI_USE_SYSTEM_CLIBRARY

 #ifdef _KERNEL
@@ -64,9 +63,11 @@
 #include sys/systm.h
 #include sys/libkern.h
 #include machine/stdarg.h
+#include vm/uma.h

 #include opt_acpi.h

+#define ACPI_CACHE_Tstruct uma_zone
 #define ACPI_MUTEX_TYPE ACPI_OSL_MUTEX

 #ifdef ACPI_DEBUG
diff --git a/sys/dev/acpica/Osd/OsdMemory.c b/sys/dev/acpica/Osd/OsdMemory.c
index b806642..5108f04 100644
--- a/sys/dev/acpica/Osd/OsdMemory.c
+++ b/sys/dev/acpica/Osd/OsdMemory.c
@@ -39,6 +39,7 @@ __FBSDID($FreeBSD$);
 #include sys/malloc.h
 #include vm/vm.h
 #include vm/pmap.h
+#include vm/uma.h

 static MALLOC_DEFINE(M_ACPICA, acpica, ACPI CA memory pool);

@@ -143,3 +144,39 @@ AcpiOsWriteMemory(ACPI_PHYSICAL_ADDRESS Address, UINT64
Value, UINT32 Width)

 return (AE_OK);
 }
+
+ACPI_STATUS
+AcpiOsCreateCache(char *CacheName, UINT16 ObjectSize, UINT16 MaxDepth,
+ACPI_CACHE_T **ReturnCache)
+{
+*ReturnCache = uma_zcreate(CacheName, ObjectSize, NULL, NULL, NULL, NULL,
+   UMA_ALIGN_PTR, 0);
+return (AE_OK);
+}
+
+ACPI_STATUS
+AcpiOsDeleteCache(ACPI_CACHE_T *Cache)
+{
+uma_zdestroy(Cache);
+return (AE_OK);
+}
+
+ACPI_STATUS
+AcpiOsPurgeCache(ACPI_CACHE_T *Cache)
+{
+zone_drain(Cache);
+return (AE_OK);
+}
+
+void *
+AcpiOsAcquireObject(ACPI_CACHE_T *Cache)
+{
+return uma_zalloc(Cache, M_ZERO | M_WAITOK);
+}
+
+ACPI_STATUS
+AcpiOsReleaseObject(ACPI_CACHE_T *Cache, void *Object)
+{
+uma_zfree(Cache, Object);
+return (AE_OK);
+}

-- 
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: panic in AcpiExSystemMemorySpaceHandler

[Andriy Gapon]

on 15/12/2012 17:19 Alexey Dokuchaev said the following:
 On Fri, Dec 14, 2012 at 09:25:51PM +0700, Alexey Dokuchaev wrote:
 On Fri, Dec 14, 2012 at 02:45:32PM +0200, Andriy Gapon wrote:
 How did you obtain these files?
 acpixtract doesn't seem to recognize all.bin...
 Could you please do something like 'acpidump  acpi.dat' ?

 I will do, but not immediately: problematic box is at $work, and I am
 already at home tonight.  I hope to give it to you tomorrow (unless you
 find a way to work with binary files given above :-).
 
 It's here: http://193.124.210.26/lenovo.acpi.dump

Thank you.  I have looked at the dump and could not spot anything obvious.
So, I hope that you would be able to do some debugging.

-- 
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

panic in AcpiExSystemMemorySpaceHandler [Was: 9.1 memstick install panics on boot]

[Andriy Gapon]

on 14/12/2012 05:02 Alexey Dokuchaev said the following:
 On Thu, Dec 13, 2012 at 05:36:35AM -0500, Glen Barber wrote:

 https://snapshots.glenbarber.us/Latest/

 It is a few days behind though.
 
 I've tried 10.0 image from it; still getting (apparently the same) panic [1].

OK.  Let's move this over to acpi@.
Could you please obtain acpidump output using Ubuntu?
It might be available in pmtools package or acpi-something package, not 
sure...

 It seems that something is wrong with AML, but I cannot tell much without
 debug symbols.  Glen, since you include kernel debugger in you snapshots,
 do you think you can ship those .symbols as well?  :-)
 
 ./danfe
 
 [1] http://193.124.210.26/10.0-acpi.dmesg
 


-- 
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: panic in AcpiExSystemMemorySpaceHandler

[Andriy Gapon]

on 14/12/2012 12:44 Alexey Dokuchaev said the following:
 On Fri, Dec 14, 2012 at 11:48:10AM +0200, Andriy Gapon wrote:
 Could you please obtain acpidump output using Ubuntu?
 
 Yup, I already did [1].  Here is the what's inside:
 
   all.bin dump of all tables
   dsdt.bindump of DSDT (original)
   dsdt.dsldecompiled DSDT
   dsdt.amlrecompiled DSDT (from dsdt.dsl)
 
 [1] http://193.124.210.26/lenovo.tgz

How did you obtain these files?  acpixtract doesn't seem to recognize all.bin...
Could you please do something like 'acpidump  acpi.dat' ?

-- 
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: ACPI panic

[Andriy Gapon]

on 04/12/2012 10:50 Stefan Farfeleder said the following:
 These checks have not triggered additional panics. I still get the cycle
 one.

I am really out of ideas now on how that cycle could be created... :-(
Perhaps, try to add another copy of the loop detection code to the place after
an object is added to the cache list and before the mutex is released.
And also, just in case, another copy to AcpiOsAcquireObject.

-- 
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: [rfc] bind curthread to target cpu for _CST change notification

[Andriy Gapon]

on 01/12/2012 11:15 Jean-Sébastien Pédron said the following:
 On 01.12.2012 10:10, Andriy Gapon wrote:
 on 01/12/2012 11:02 Jean-Sébastien Pédron said the following:
 By the way, should _CST appear in a dump from acpidump(8)?
 
 Yes, it depends... :-) _CST could be defined in a dynamically loadable
 region.  If you do not see _CST in the DSDT but see Load() calls, then
 that's the most likely explanation.
 
 How do I see these Load() calls? Are they related to the ACPI_LV_LOAD level
 in debug.acpi.level?

acpidump -dt  somefile.asl
vi somefile.asl
/Load

:-)


-- 
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: [rfc] bind curthread to target cpu for _CST change notification

[Andriy Gapon]

on 29/11/2012 17:29 Andriy Gapon said the following:
 I am working on an alternative approach to these two issues.

Here is my WIP:
http://people.freebsd.org/~avg/acpi_cpu_notify.2.diff

-- 
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: [rfc] bind curthread to target cpu for _CST change notification

[Andriy Gapon]

Turned out not be so rosy...

on 25/11/2012 21:37 Sean Bruno said the following:
 
 
 On Thu, 2012-11-22 at 16:53 +0200, Andriy Gapon wrote:
 I would like to propose the following patch which should kill two birds with 
 one
 stone:

 - avoid race in acpi_cpu_cx_cst if more than one notifications occur in a 
 rapid
 succession for the same CPU and end up being concurrently handled by ACPI 
 taskqeue
 threads

critical_enter was a very a bad idea and can't be used here because
acpi_cpu_cx_cst acquires blockable locks and does waiting memory allocations.
Unfortunately, it was not immediately obvious to me.

 - avoid race acpi_cpu_cx_cst and acpi_cpu_idle where the latter may access
 resources being updated by the former

sched_bind wouldn't guarantee that this would work if critical_enter is not 
used,
because the current thread may block and the idle thread may get to run.


 What do you think?

 Index: sys/dev/acpica/acpi_cpu.c
 ===
 --- sys/dev/acpica/acpi_cpu.c(revision 242854)
 +++ sys/dev/acpica/acpi_cpu.c(working copy)
 @@ -1047,7 +1047,16 @@
  return;

  /* Update the list of Cx states. */
 +thread_lock(curthread);
 +sched_bind(curthread, sc-cpu_pcpu-pc_cpuid);
 +thread_unlock(curthread);
 +critical_enter();
  acpi_cpu_cx_cst(sc);
 +critical_exit();
 +thread_lock(curthread);
 +sched_unbind(curthread);
 +thread_unlock(curthread);
 +
  acpi_cpu_cx_list(sc);

  ACPI_SERIAL_BEGIN(cpu);

 
 Ack.  This looks appropriate to me.

I am working on an alternative approach to these two issues.
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: ACPI panic

[Andriy Gapon]

on 29/11/2012 10:46 Stefan Farfeleder said the following:
 On Mon, Nov 26, 2012 at 01:13:46PM +0200, Andriy Gapon wrote:

 Also, I've just realized that the check is racy...
 Could you please move the whole check block (between and excluding
 AcpiUtAcquireMutex and AcpiUtReleaseMutex) down right below the following 
 lines:

 Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES);
 if (ACPI_FAILURE (Status))
 {
 return (Status);
 }
 
 Sorry for the delay. I'm now running the patch below. I still got the
 cycle panic, this time with a 4-objects cycle. It looks like an object
 gets released twice but I don't understand why the freeing a free
 object check fails to trigger.

Hmmm...
Another bug-catching patch before I start questioning my ability to understand
the code.

index 59ecf21..1687c75b 100644
--- a/sys/contrib/dev/acpica/components/utilities/utcache.c
+++ b/sys/contrib/dev/acpica/components/utilities/utcache.c
@@ -238,6 +238,8 @@ AcpiOsReleaseObject (

 else
 {
+if (AcpiGbl_MutexInfo[ACPI_MTX_CACHES].ThreadId == AcpiOsGetThreadId 
())
+panic(ACPI_MTX_CACHES acquired recursively);
 Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES);
 if (ACPI_FAILURE (Status))
 {
@@ -311,6 +313,8 @@ AcpiOsAcquireObject (
 return (NULL);
 }

+if (AcpiGbl_MutexInfo[ACPI_MTX_CACHES].ThreadId == AcpiOsGetThreadId ())
+panic(ACPI_MTX_CACHES acquired recursively);
 Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES);
 if (ACPI_FAILURE (Status))
 {

 Stefan
 
 Index: components/utilities/utcache.c
 ===
 --- components/utilities/utcache.c(revision 243234)
 +++ components/utilities/utcache.c(working copy)
 @@ -244,6 +244,28 @@
  return (Status);
  }
  
 +char*Curr;
 +char*Next;
 +int Depth;
 +Depth = Cache-CurrentDepth;
 +Next = Cache-ListHead;
 +while (Next)
 +{
 +Curr = Next;
 +Next = *(ACPI_CAST_INDIRECT_PTR (char,
 +(((char *) Curr)[Cache-LinkOffset])));
 +if (*(const unsigned char *) Curr != 0xCA) {
 +panic(detected use after free %p\n, Curr);
 +}
 +if (Object == Curr) {
 +panic(freeing a free object %p, Object);
 +}
 +Depth--;
 +if (Depth  0) {
 +panic(cycle in a cache list);
 +}
 +}
 +
  /* Mark the object as cached */
  
  ACPI_MEMSET (Object, 0xCA, Cache-ObjectSize);
 @@ -312,6 +334,10 @@
  
  Cache-CurrentDepth--;
  
 +if (*(const unsigned char *) Object != 0xCA) {
 +panic(detected use after free %p\n, Object);
 +}
 +
  ACPI_MEM_TRACKING (Cache-Hits++);
  ACPI_DEBUG_PRINT ((ACPI_DB_EXEC,
  Object %p from %s cache\n, Object, Cache-ListName));
 

Just in case: this is exactly what I had in mind.

-- 
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: ACPI panic

[Andriy Gapon]

on 26/11/2012 11:37 Stefan Farfeleder said the following:
 On Mon, Nov 26, 2012 at 11:29:55AM +0200, Andriy Gapon wrote:

 Very interesting, thank you.
 Are you able to get a crash dump?
 
 Yes.

Great!
Could you please cast those cycled objects to 'union acpi_operand_object' and
print them?  Something like 'p *(union acpi_operand_object *)$x'.

 (kgdb) bt
 #0  doadump (textdump=0) at pcpu.h:229
 #1  0x802becae in db_dump (dummy=value optimized out, dummy2=0, 
 dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543
 #2  0x802be874 in db_command (last_cmdp=value optimized out, 
 cmd_table=value optimized out, dopager=1)
 at /usr/src/sys/ddb/db_command.c:449
 #3  0x802be562 in db_command_loop ()
 at /usr/src/sys/ddb/db_command.c:502
 #4  0x802c0e40 in db_trap (type=value optimized out, code=0)
 at /usr/src/sys/ddb/db_main.c:231
 #5  0x804c165e in kdb_trap (type=3, code=0, tf=value optimized out)
 at /usr/src/sys/kern/subr_kdb.c:654
 #6  0x806ee2dc in trap (frame=0xff811fe0e3f0)
 at /usr/src/sys/amd64/amd64/trap.c:579
 #7  0x806d8e43 in calltrap () at /tmp/exception-EAhiLL.s:142
 #8  0x804c0e5e in kdb_enter (why=0x8079246e panic, 
 msg=value optimized out) at cpufunc.h:63
 #9  0x8048ca4f in panic (fmt=value optimized out)
 at /usr/src/sys/kern/kern_shutdown.c:628
 #10 0x802b57ca in AcpiOsReleaseObject (Cache=0xfe000292a700, 
 Object=0xfe0002a60780)
 at /usr/src/sys/contrib/dev/acpica/components/utilities/utcache.c:245
 #11 0x802b679d in AcpiUtUpdateRefCount (Object=0xfe0002a60780, 
 ---Type return to continue, or q return to quit---
 Action=value optimized out)
 at /usr/src/sys/contrib/dev/acpica/components/utilities/utdelete.c:464
 #12 0x802b66fb in AcpiUtUpdateObjectReference (
 Object=0xfe0002a60780, Action=1)
 at /usr/src/sys/contrib/dev/acpica/components/utilities/utdelete.c:648
 #13 0x8029bbc5 in AcpiDsIsResultUsed (Op=0xfe00041b3a00, 
 WalkState=0xfe00061a4800)
 at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:100
 #14 0x8029bd03 in AcpiDsDeleteResultIfNotUsed (Op=0xff811fe0e3b0, 
 ResultObj=0xfe0002a60700, WalkState=0xfe00061a4800)
 at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:388
 #15 0x8029c874 in AcpiDsExecEndOp (WalkState=0xfe00061a4800)
 at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dswexec.c:773
 #16 0x802afe04 in AcpiPsParseLoop (WalkState=0xfe00061a4800)
 at /usr/src/sys/contrib/dev/acpica/components/parser/psloop.c:1276
 #17 0x802b068d in AcpiPsParseAml (WalkState=value optimized out)
 at /usr/src/sys/contrib/dev/acpica/components/parser/psparse.c:525
 #18 0x802b11e7 in AcpiPsExecuteMethod (Info=0xfe0006139440)
 at /usr/src/sys/contrib/dev/acpica/components/parser/psxface.c:368
 #19 0x802aac16 in AcpiNsEvaluate (Info=0xfe0006139440)
 at /usr/src/sys/contrib/dev/acpica/components/namespace/nseval.c:193
 #20 0x802add48 in AcpiEvaluateObject (Handle=0xfe0002a03dc0, 
 Pathname=value optimized out, ExternalParams=value optimized out, 
 ---Type return to continue, or q return to quit---
 ReturnBuffer=0xff811fe0e838)
 at /usr/src/sys/contrib/dev/acpica/components/namespace/nsxfeval.c:289
 #21 0x802c6fdf in acpi_GetInteger (handle=value optimized out, 
 path=0x80756410 _PSR, number=0xff811fe0e884)
 at /usr/src/sys/dev/acpica/acpi.c:2207
 #22 0x802cc8ff in acpi_acad_get_status (context=0xfe0002a3cd00)
 at /usr/src/sys/dev/acpica/acpi_acad.c:106
 #23 0x8024 in acpi_acad_sysctl (oidp=0xfe0004192000, 
 arg1=0xfe0004145980, arg2=-2142478272, req=0xff811fe0e968)
 at /usr/src/sys/dev/acpica/acpi_acad.c:279
 #24 0x80496d0c in sysctl_root (arg1=value optimized out, 
 arg2=value optimized out) at /usr/src/sys/kern/kern_sysctl.c:1513
 #25 0x804972c8 in userland_sysctl (td=value optimized out, 
 name=0xff811fe0ea30, namelen=value optimized out, 
 old=value optimized out, oldlenp=value optimized out, 
 inkernel=value optimized out, new=value optimized out, 
 newlen=value optimized out, retval=value optimized out, 
 flags=534833488) at /usr/src/sys/kern/kern_sysctl.c:1623
 #26 0x804970b4 in sys___sysctl (td=0xfe00061fe900, 
 uap=0xff811fe0eb40) at /usr/src/sys/kern/kern_sysctl.c:1549
 #27 0x806eef8e in amd64_syscall (td=0xfe00061fe900, traced=0)
 at subr_syscall.c:135
 #28 0x806d912b in Xfast_syscall () at /tmp/exception-EAhiLL.s:292
 ---Type return to continue, or q return to quit---
 #29 0x00080093456a in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 Current language:  auto; currently minimal
 (kgdb) f 10
 #10 0x802b57ca

Re: ACPI panic

[Andriy Gapon]

Also, I've just realized that the check is racy...
Could you please move the whole check block (between and excluding
AcpiUtAcquireMutex and AcpiUtReleaseMutex) down right below the following lines:

Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES);
if (ACPI_FAILURE (Status))
{
return (Status);
}

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: ACPI panic

[Andriy Gapon]

on 26/11/2012 13:10 Stefan Farfeleder said the following:
 On Mon, Nov 26, 2012 at 01:06:18PM +0200, Andriy Gapon wrote:
 on 26/11/2012 12:47 Stefan Farfeleder said the following:
 BTW, I noticed the ACPI_SET_DESCRIPTOR_TYPE code is pointless, because the
 DescriptorType is at offset 8 from the object start and gets immediately
 overwritten by the next pointer. However I don't think it's a problem.

 Thank you.
 To make things more obvious could you please also examine the objects like 
 this:
 x/9a addr
 ?
 
 (kgdb) x/9a 0xfe0006117600
 0xfe0006117600: 0xcacacacacacacaca  0xfe0006117680
 0xfe0006117610: 0xcacacacacacacaca  0xcacacacacacacaca
 0xfe0006117620: 0xcacacacacacacaca  0xcacacacacacacaca
 0xfe0006117630: 0xcacacacacacacaca  0xcacacacacacacaca
 0xfe0006117640: 0xcacacacacacacaca
 (kgdb) x/9a 0xfe0006117680
 0xfe0006117680: 0xcacacacacacacaca  0xfe0002a60080
 0xfe0006117690: 0xcacacacacacacaca  0xcacacacacacacaca
 0xfe00061176a0: 0xcacacacacacacaca  0xcacacacacacacaca
 0xfe00061176b0: 0xcacacacacacacaca  0xcacacacacacacaca
 0xfe00061176c0: 0xcacacacacacacaca
 (kgdb) x/9a 0xfe0002a60080
 0xfe0002a60080: 0xcacacacacacacaca  0xfe0006117680
 0xfe0002a60090: 0xcacacacacacacaca  0xcacacacacacacaca
 0xfe0002a600a0: 0xcacacacacacacaca  0xcacacacacacacaca
 0xfe0002a600b0: 0xcacacacacacacaca  0xcacacacacacacaca
 0xfe0002a600c0: 0xcacacacacacacaca

So this looks like use after free is unlikely.
It's probably a double-free that was missed in the race which I've just 
realized.

-- 
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: ACPI panic

[Andriy Gapon]

on 25/11/2012 16:00 Stefan Farfeleder said the following:
 Hi Andriy,
 
 with your patch my notebook has a ~50% chance of stalling during boot.
 This always happens after the Entropy harvesting line and I can only
 power it down then.
 I guess somehow cycles are introduced into the acpi objects list? The
 panic was never triggered.

Hmm, I didn't think that the cycles were possible...
Could you please try the following patch on top of the previous ones?
Also, if you don't have DDB in your kernel yet, please add it and try to break
into the debugger if one of those hangs happens again without any panic.

diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c
b/sys/contrib/dev/acpica/components/utilities/utcache.c
index edd9e4f..5eee934 100644
--- a/sys/contrib/dev/acpica/components/utilities/utcache.c
+++ b/sys/contrib/dev/acpica/components/utilities/utcache.c
@@ -229,6 +229,8 @@ AcpiOsReleaseObject (
 (void) AcpiUtAcquireMutex (ACPI_MTX_CACHES);
 char*Curr;
 char*Next;
+int Depth;
+Depth = Cache-CurrentDepth;
 Next = Cache-ListHead;
 while (Next)
 {
@@ -238,6 +240,10 @@ AcpiOsReleaseObject (
 if (Object == Curr) {
 panic(freeing a free object %p, Object);
 }
+Depth--;
+if (Depth  0) {
+panic(cycle in a cache list);
+}
 }
 (void) AcpiUtReleaseMutex (ACPI_MTX_CACHES);



-- 
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: ACPI panic

[Andriy Gapon]

on 22/11/2012 10:18 Stefan Farfeleder said the following:
 I'm afraid the AcpiOsAcquireObject panic is not directly related to
 reference counting. I had the very same panic today with your patch.

OK, let's try to attack it from a different angle.
Please try this patch:
diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c
b/sys/contrib/dev/acpica/components/utilities/utcache.c
index b8efa68..a3d964a 100644
--- a/sys/contrib/dev/acpica/components/utilities/utcache.c
+++ b/sys/contrib/dev/acpica/components/utilities/utcache.c
@@ -226,6 +226,22 @@ AcpiOsReleaseObject (
 return (AE_BAD_PARAMETER);
 }

+(void) AcpiUtAcquireMutex (ACPI_MTX_CACHES);
+char*Curr;
+char*Next;
+Next = Cache-ListHead;
+while (Next)
+{
+Curr = Next;
+Next = *(ACPI_CAST_INDIRECT_PTR (char,
+(((char *) Curr)[Cache-LinkOffset])));
+if (Object == Curr) {
+ACPI_ERROR ((AE_INFO, freeing a free object %p\n, Object));
+Curr = *(volatile char **)NULL; /* induce crash */
+}
+}
+(void) AcpiUtReleaseMutex (ACPI_MTX_CACHES);
+
 /* If cache is full, just free this object */

 if (Cache-CurrentDepth = Cache-MaxDepth)


-- 
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: ACPI panic

[Andriy Gapon]

on 22/11/2012 12:24 Andriy Gapon said the following:
 on 22/11/2012 10:18 Stefan Farfeleder said the following:
 I'm afraid the AcpiOsAcquireObject panic is not directly related to
 reference counting. I had the very same panic today with your patch.
 
 OK, let's try to attack it from a different angle.
 Please try this patch:
[snip]

Or better this one:

diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c
b/sys/contrib/dev/acpica/components/utilities/utcache.c
index b8efa68..09b77b2 100644
--- a/sys/contrib/dev/acpica/components/utilities/utcache.c
+++ b/sys/contrib/dev/acpica/components/utilities/utcache.c
@@ -226,6 +226,22 @@ AcpiOsReleaseObject (
 return (AE_BAD_PARAMETER);
 }

+(void) AcpiUtAcquireMutex (ACPI_MTX_CACHES);
+char*Curr;
+char*Next;
+Next = Cache-ListHead;
+while (Next)
+{
+Curr = Next;
+Next = *(ACPI_CAST_INDIRECT_PTR (char,
+(((char *) Curr)[Cache-LinkOffset])));
+if (Object == Curr) {
+ACPI_ERROR ((AE_INFO, freeing a free object %p\n, Object));
+Curr = *(volatile char **)NULL; /* induce crash */
+}
+}
+(void) AcpiUtReleaseMutex (ACPI_MTX_CACHES);
+
 /* If cache is full, just free this object */

 if (Cache-CurrentDepth = Cache-MaxDepth)
@@ -312,6 +328,11 @@ AcpiOsAcquireObject (

 Cache-CurrentDepth--;

+if (*(const char *) Object != 0xCA) {
+ACPI_ERROR ((AE_INFO, detected use after free %p\n, Object));
+Object = *(volatile char **)NULL; /* induce crash */
+}
+
 ACPI_MEM_TRACKING (Cache-Hits++);
 ACPI_DEBUG_PRINT ((ACPI_DB_EXEC,
 Object %p from %s cache\n, Object, Cache-ListName));

-- 
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: ACPI panic

[Andriy Gapon]

A patch that should actually compile, finally.
BTW, it's probably better to replace the NULL dereference trick with a simple
panic call in the first patch too.

diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c
b/sys/contrib/dev/acpica/components/utilities/utcache.c
index b8efa68..edd9e4f 100644
--- a/sys/contrib/dev/acpica/components/utilities/utcache.c
+++ b/sys/contrib/dev/acpica/components/utilities/utcache.c
@@ -226,6 +226,21 @@ AcpiOsReleaseObject (
 return (AE_BAD_PARAMETER);
 }

+(void) AcpiUtAcquireMutex (ACPI_MTX_CACHES);
+char*Curr;
+char*Next;
+Next = Cache-ListHead;
+while (Next)
+{
+Curr = Next;
+Next = *(ACPI_CAST_INDIRECT_PTR (char,
+(((char *) Curr)[Cache-LinkOffset])));
+if (Object == Curr) {
+panic(freeing a free object %p, Object);
+}
+}
+(void) AcpiUtReleaseMutex (ACPI_MTX_CACHES);
+
 /* If cache is full, just free this object */

 if (Cache-CurrentDepth = Cache-MaxDepth)
@@ -312,6 +327,10 @@ AcpiOsAcquireObject (

 Cache-CurrentDepth--;

+if (*(const unsigned char *) Object != 0xCA) {
+panic(detected use after free %p\n, Object);
+}
+
 ACPI_MEM_TRACKING (Cache-Hits++);
 ACPI_DEBUG_PRINT ((ACPI_DB_EXEC,
 Object %p from %s cache\n, Object, Cache-ListName));

-- 
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

[rfc] bind curthread to target cpu for _CST change notification

[Andriy Gapon]

I would like to propose the following patch which should kill two birds with one
stone:

- avoid race in acpi_cpu_cx_cst if more than one notifications occur in a rapid
succession for the same CPU and end up being concurrently handled by ACPI 
taskqeue
threads
- avoid race acpi_cpu_cx_cst and acpi_cpu_idle where the latter may access
resources being updated by the former

What do you think?

Index: sys/dev/acpica/acpi_cpu.c
===
--- sys/dev/acpica/acpi_cpu.c   (revision 242854)
+++ sys/dev/acpica/acpi_cpu.c   (working copy)
@@ -1047,7 +1047,16 @@
return;

 /* Update the list of Cx states. */
+thread_lock(curthread);
+sched_bind(curthread, sc-cpu_pcpu-pc_cpuid);
+thread_unlock(curthread);
+critical_enter();
 acpi_cpu_cx_cst(sc);
+critical_exit();
+thread_lock(curthread);
+sched_unbind(curthread);
+thread_unlock(curthread);
+
 acpi_cpu_cx_list(sc);

 ACPI_SERIAL_BEGIN(cpu);

-- 
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: ACPI panic

[Andriy Gapon]

:193
 #19 0x802add48 in AcpiEvaluateObject (Handle=0xfe0002a09280, 
 Pathname=value optimized out, ExternalParams=value optimized out, 
 ReturnBuffer=0xff811fe4f7c0)
 at /usr/src/sys/contrib/dev/acpica/components/namespace/nsxfeval.c:289
 #20 0x802ce378 in acpi_cmbat_get_bst (arg=0xfe0002a3d200)
 at /usr/src/sys/dev/acpica/acpi_cmbat.c:258
 #21 0x802ce202 in acpi_cmbat_bst (dev=0xfe0002a3d200, 
 bstp=0xfe0006125300) at /usr/src/sys/dev/acpica/acpi_cmbat.c:419
 #22 0x802cd2ef in acpi_battery_get_battinfo (dev=0x0, 
 battinfo=0x80a5d380) at acpi_if.h:142
 #23 0x802cd91f in acpi_battery_sysctl (oidp=0xfe000418c500, 
 arg1=value optimized out, arg2=64, req=0xff811fe4f968)
 at /usr/src/sys/dev/acpica/acpi_battery.c:428
 #24 0x80496c8c in sysctl_root (arg1=value optimized out, 
 arg2=value optimized out) at /usr/src/sys/kern/kern_sysctl.c:1513
 #25 0x80497248 in userland_sysctl (td=value optimized out, 
 name=0xff811fe4fa30, namelen=value optimized out, 
 old=value optimized out, oldlenp=value optimized out, 
 inkernel=value optimized out, new=value optimized out, 
 newlen=value optimized out, retval=value optimized out, 
 flags=535099728) at /usr/src/sys/kern/kern_sysctl.c:1623
 #26 0x80497034 in sys___sysctl (td=0xfe00041a5900, 
 uap=0xff811fe4fb40) at /usr/src/sys/kern/kern_sysctl.c:1549
 #27 0x806eef0e in amd64_syscall (td=0xfe00041a5900, traced=0)
 at subr_syscall.c:135
 #28 0x806d90ab in Xfast_syscall () at /tmp/exception-EAhiLL.s:292
 #29 0x00080093456a in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 Current language:  auto; currently minimal
 (kgdb) 
 


-- 
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: AcpiOsAcquireObject crash [Was: 9-Stable panic: resource_list_unreserve: can't find resource]

[Andriy Gapon]

on 13/11/2012 17:14 Andriy Gapon said the following:
 I have a better patch, which I tested at least.  I'll send it to you soon-ish.

Here is a tested version of the ref-count patch (still a little bit 
experimental):
http://people.freebsd.org/~avg/acpi-ref-count-exp.diff

-- 
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: AcpiOsAcquireObject crash [Was: 9-Stable panic: resource_list_unreserve: can't find resource]

[Andriy Gapon]

on 09/11/2012 14:17 Tom Lislegaard said the following:
 kgdb) up 7
 #7  0x802d1bdd in AcpiOsAcquireObject (Cache=0xfe00052bac60) at 
 /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316
 316   ACPI_DEBUG_PRINT ((ACPI_DB_EXEC,
 (kgdb) x/9a Cache-ListHead
 0xfffeec85c730:   Cannot access memory at address 0xfffeec85c730

[Slaps forehead] Ah, right, indeed.
I guess the problem hasn't happened again since then?
Does the patch appear to work OK so far (with respect to the original problem)?

I have a suspicion about what causes the new problem.
If it is correct then the following experimental patch may help with it:

--- a/sys/contrib/dev/acpica/components/utilities/utdelete.c
+++ b/sys/contrib/dev/acpica/components/utilities/utdelete.c
@@ -415,6 +415,8 @@ AcpiUtUpdateRefCount (
 return;
 }

+(void) AcpiUtAcquireMutex (ACPI_MTX_REFCOUNTS);
+
 Count = Object-Common.ReferenceCount;
 NewCount = Count;

@@ -490,6 +492,8 @@ AcpiUtUpdateRefCount (
 ACPI_WARNING ((AE_INFO,
 Large Reference Count (0x%X) in object %p, Count, Object));
 }
+
+(void) AcpiUtReleaseMutex (ACPI_MTX_REFCOUNTS);
 }



--- a/sys/contrib/dev/acpica/include/aclocal.h
+++ b/sys/contrib/dev/acpica/include/aclocal.h
@@ -89,8 +89,9 @@ union acpi_parse_object;
 #define ACPI_MTX_MEMORY 5   /* Debug memory tracking lists */
 #define ACPI_MTX_DEBUG_CMD_COMPLETE 6   /* AML debugger */
 #define ACPI_MTX_DEBUG_CMD_READY7   /* AML debugger */
+#define ACPI_MTX_REFCOUNTS  8   /* ACPI object reference counts */

-#define ACPI_MAX_MUTEX  7
+#define ACPI_MAX_MUTEX  8
 #define ACPI_NUM_MUTEX  ACPI_MAX_MUTEX+1



-- 
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: High ACPI CPU usage on a Supermicro X9DRT-HF+

[Andriy Gapon]

on 09/11/2012 20:31 Jason Wolfe said the following:
 I've enabled the info debug level, here is the mere 1600 line resulting boot 
 log. 
 After the system is live I see no ACPI messages being written.  I have also
 enabled DTrace support.
 
 http://nitrology.com/acpi.verbose.info

Are you sure that you have ACPI_DEBUG option enabled?

-- 
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: 9-Stable panic: resource_list_unreserve: can't find resource

[Andriy Gapon]

on 08/11/2012 11:06 Tom Lislegaard said the following:
 
 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: 6. november 2012 19:53
 To: Tom Lislegaard
 Cc: freebsd-sta...@freebsd.org; freebsd-acpi@FreeBSD.org
 Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource

 on 06/11/2012 10:50 Tom Lislegaard said the following:
 No problem, I'm happy to assist in debugging this.

 Enabling the acpi debugging quickly fills the kernel message buffer,
 but it seems to be the same set of messages repeating again and again
 so I think this is representative

 https://dl.dropbox.com/u/13263820/debug_dmesg.txt

 This didn't clarify things as much as I hoped, but I am inclined to think 
 that it is polling from
 userland that triggers all the processor notifications.

 In any case, here is a patch to try:
 http://people.freebsd.org/~avg/acpi_cpu-stable.diff

 Please disable all the tunings added to loader.conf during debugging when 
 testing this patch.

 The patch is a combination of two changes:

 1.
 Do not needlessly use ever-increasing resource IDs.
 Rather use the IDs that are tied to Cx level IDs.
 Also, release previous resources upon _CST change.

 2.
 Bind a thread that processes a processor _CST change notification to the 
 target processor and perform
 _CST processing in a critical section.  These should ensure the following:
 - the CPU doesn't enter an idle state and doesn't try to use Cx level 
 parameters
   while they are being changed
 - Cx level parameters are never concurrently modified when multiple 
 notifications
   fire in a rapid succession and multiple ACPI task threads are configured 
 sched_bind is a heavy-
 weight operation, but it is OK in this context because processor 
 notifications should not occur too
 often

 
 Thanks. I applied the patch yesterday, but found this morning the machine had 
 crashed during the night with a page fault

This looks like an unrelated / new / different problem.
Could you please poke around frame 7?
BTW, what version of FreeBSD do you use?
What ACPICA version is there (debug.acpi.acpi_ca_version) ?

It seems like somewhat similar panics were reported in the past:
http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032637.html
http://lists.freebsd.org/pipermail/freebsd-acpi/2012-January/007406.html

 (kgdb) bt
 #0  doadump (textdump=Variable textdump is not available.
 ) at pcpu.h:229
 #1  0x804441f4 in kern_reboot (howto=260) at 
 /usr/src/sys/kern/kern_shutdown.c:448
 #2  0x804446dc in panic (fmt=0x1 Address 0x1 out of bounds) at 
 /usr/src/sys/kern/kern_shutdown.c:636
 #3  0x806f234d in trap_fatal (frame=0xfe00089264a0, eva=Variable 
 eva is not available.
 ) at /usr/src/sys/amd64/amd64/trap.c:878
 #4  0x806f2668 in trap_pfault (frame=0xff82450401b0, usermode=0) 
 at /usr/src/sys/amd64/amd64/trap.c:794
 #5  0x806f29ec in trap (frame=0xff82450401b0) at 
 /usr/src/sys/amd64/amd64/trap.c:463
 #6  0x806dc5ff in calltrap () at 
 /usr/src/sys/amd64/amd64/exception.S:228
 #7  0x802d1bdd in AcpiOsAcquireObject (Cache=0xfe00052bac60) at 
 /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316
 #8  0x802d6883 in AcpiUtAllocateObjectDescDbg 
 (ModuleName=0x8074c3f0 dsutils, LineNumber=703, 
 ComponentId=Variable ComponentId is not available.
 ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437
 #9  0x802d6a1d in AcpiUtCreateInternalObjectDbg 
 (ModuleName=0x8074c3f0 dsutils, LineNumber=703, ComponentId=64, 
 Type=1) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:112
 #10 0x802a71e8 in AcpiDsCreateOperand (WalkState=0xfe0008a3bc00, 
 Arg=0xfe0005366800, ArgIndex=0) at 
 /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:703
 #11 0x802a7587 in AcpiDsCreateOperands (WalkState=0xfe0008a3bc00, 
 FirstArg=0xfe0005366800) at 
 /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:798
 #12 0x802a856e in AcpiDsExecEndOp (WalkState=0xfe0008a3bc00) at 
 /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:567
 #13 0x802c9441 in AcpiPsParseLoop (WalkState=0xfe0008a3bc00) at 
 /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249
 #14 0x802ca8dd in AcpiPsParseAml (WalkState=0xfe0008a3bc00) at 
 /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525
 #15 0x802cb981 in AcpiPsExecuteMethod (Info=0xfe01a2143100) at 
 /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368
 #16 0x802c2287 in AcpiNsEvaluate (Info=0xfe01a2143100) at 
 /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193
 #17 0x802d3f56 in AcpiUtEvaluateObject 
 (PrefixNode=0xfe00052f6540, Path=0x807538f6 _STA, 
 ExpectedReturnBtypes=1, ReturnDesc=0xff8245040660) at 
 /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:102
 #18 0x802d428f in AcpiUtExecute_STA (DeviceNode=0xfe00052f6540, 
 Flags=0xfe01cc0d1e18

AcpiOsAcquireObject crash [Was: 9-Stable panic: resource_list_unreserve: can't find resource]

[Andriy Gapon]

on 08/11/2012 18:11 Tom Lislegaard said the following:
 I've put up some more info 
 https://dl.dropbox.com/u/13263820/vmcore_7.txt
 
 BTW, what version of FreeBSD do you use?
 
 Version is RELENG_9 checked out ~3 days ago
 
 What ACPICA version is there (debug.acpi.acpi_ca_version) ?
 
 debug.acpi.acpi_ca_version: 20110527

Thanks!
Could you please also do:
x/9a Cache-ListHead
?

I suspect that this bug is of very inconvenient nature: a memory corruption,
either semi-random or some sort of use after free.

-- 
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: High ACPI CPU usage on a Supermicro X9DRT-HF+

[Andriy Gapon]

on 09/11/2012 04:01 Jason Wolfe said the following:
 Hi,
 
 I'm having an issue with a large pool of Supermicro X9DRT-HF+ servers in
 which the ACPI processes basically burn up a whole CPU.  I have ACPI debug
 mode compiled/enabled, but as I'm not actually having any issues per se,
 I'm having trouble with the next steps.  This is fairly new Sandy Bridge
 hardware, so I figure it's possible something needs to be fleshed out in
 the code.  Every BIOS option relating to ACPI has been flipped back and
 forth, and booting without ACPI support causes a panic.
 
 Here is the verbose boot log as well as the acpidump -dt output, and other
 interesting bits:
 
 http://nitrology.com/dmesg.acpi
 http://nitrology.com/jason-X9DRT-HF.asl
 
 sysctl hw.acpi:
 hw.acpi.supported_sleep_state: S1 S4 S5
 hw.acpi.power_button_state: S5
 hw.acpi.sleep_button_state: S1
 hw.acpi.lid_switch_state: NONE
 hw.acpi.standby_state: S1
 hw.acpi.suspend_state: NONE
 hw.acpi.sleep_delay: 1
 hw.acpi.s4bios: 0
 hw.acpi.verbose: 1
 hw.acpi.disable_on_reboot: 0
 hw.acpi.handle_reboot: 1
 hw.acpi.reset_video: 0
 hw.acpi.cpu.cx_lowest: C1
 
 vmstat -i:
 interrupt total rate
 irq9: acpi0 12170706 14610
 cpu0: timer 1662074 1995
 cpu3: timer 1644465 1974
 cpu4: timer 1644529 1974
 cpu1: timer 1644423 1974
 cpu5: timer 1644498 1974
 cpu2: timer 1644479 1974
 
 top -SHb:
 last pid: 1979; load averages: 1.39, 1.35, 0.90 up 0+00:13:54 18:46:27
 160 processes: 8 running, 119 sleeping, 33 waiting
 
 Mem: 2355M Active, 11G Inact, 7431M Wired, 216K Cache, 6559M Buf, 41G Free
 Swap: 24G Total, 24G Free
 
 PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
 11 root 171 ki31 0K 96K RUN 4 11:52 89.70% idle{idle: cpu4}
 11 root 171 ki31 0K 96K CPU5 5 11:55 86.67% idle{idle: cpu5}
 11 root 171 ki31 0K 96K CPU2 2 11:14 84.08% idle{idle: cpu2}
 11 root 171 ki31 0K 96K CPU3 3 9:56 76.76% idle{idle: cpu3}
 11 root 171 ki31 0K 96K CPU1 1 9:09 70.90% idle{idle: cpu1}
 11 root 171 ki31 0K 96K RUN 0 9:24 70.07% idle{idle: cpu0}
 12 root -52 - 0K 528K WAIT 3 3:25 27.29% intr{irq9: acpi0}
 0 root 8 0 0K 320K CPU4 4 3:39 25.59% kernel{acpi_task_2}
 0 root 8 0 0K 320K - 2 3:40 25.39% kernel{acpi_task_0}
 0 root 8 0 0K 320K - 5 3:39 25.20% kernel{acpi_task_1}

As a first step please add the following to the loader.conf and see what gets
reported and at what frequency:
debug.acpi.layer=ACPI_EVENTS
debug.acpi.level=ACPI_LV_INFO

Also, is your system DTrace-enabled?

-- 
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: 9-Stable panic: resource_list_unreserve: can't find resource

[Andriy Gapon]

on 06/11/2012 10:50 Tom Lislegaard said the following:
 No problem, I'm happy to assist in debugging this.
 
 Enabling the acpi debugging quickly fills the kernel message buffer, but it 
 seems to be the same set of messages 
 repeating again and again so I think this is representative
 
 https://dl.dropbox.com/u/13263820/debug_dmesg.txt

This didn't clarify things as much as I hoped, but I am inclined to think that 
it
is polling from userland that triggers all the processor notifications.

In any case, here is a patch to try:
http://people.freebsd.org/~avg/acpi_cpu-stable.diff

Please disable all the tunings added to loader.conf during debugging when 
testing
this patch.

The patch is a combination of two changes:

1.
Do not needlessly use ever-increasing resource IDs.
Rather use the IDs that are tied to Cx level IDs.
Also, release previous resources upon _CST change.

2.
Bind a thread that processes a processor _CST change notification to the target
processor and perform _CST processing in a critical section.  These should 
ensure
the following:
- the CPU doesn't enter an idle state and doesn't try to use Cx level parameters
  while they are being changed
- Cx level parameters are never concurrently modified when multiple 
notifications
  fire in a rapid succession and multiple ACPI task threads are configured
sched_bind is a heavy-weight operation, but it is OK in this context because
processor notifications should not occur too often

 And, btw, thanks for your efforts.

Thank you for all the excellent debugging and testing!

P.S. I still believe that BIOS/ACPI on the machine behaves sub-optimally.
-- 
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: 9-Stable panic: resource_list_unreserve: can't find resource

[Andriy Gapon]

on 05/11/2012 12:26 Tom Lislegaard said the following:
 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 I see.  Could you please try setting debug.acpi.max_threads=1 in 
 /boot/loader.conf, reboot and see if
 that makes any difference?
 
 It does make a difference. I've had the machine running over the week-end, 
 and haven't had a crash in 56 hours.
 
 After applying the setting I get some errors on reboot, no idea if they are 
 harmful in any way (none that I have notced):
 
 AcpiOsExecute: failed to enqueue task, consider increasing the 
 debug.acpi.max_tasks tunable
 ACPI Error: Method parse/execution failed [\\PNOT] (Node 0xfe00052e6400), 
 AE_NO_MEMORY (20110527/psparse-560)
 ACPI Error: Method parse/execution failed [\\_SB_.AC__._PSR] (Node 
 0xfe00052f57c0), AE_NO_MEMORY (20110527/psparse-560)
 
 The same messages repeats 6 times

Thank you for the test!
Try to set debug.acpi.max_tasks to 128 or even higher to get rid of the new ACPI
errors.

Additionally I would like to ask you to do the following test.
Please stop devd and then run it (as root) from command line as such devd -D -d.
Please check what event are reported by devd.  In particular I am interested in
ACAD events, but all high frequency events are important.

Thanks!
-- 
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: 9-Stable panic: resource_list_unreserve: can't find resource

[Andriy Gapon]

on 02/11/2012 11:56 Tom Lislegaard said the following:
 The machine is usually connected to a docking station and I believe the power 
 is very stable. I sometimes take it home and connect it to a different 
 powersupply and sees the same behavior with panics there. Panics can occur 
 while I'm at the machine working, or if I leave the machine idle for some 
 time I find it has paniced/rebooted when I come back.
 The time of panic seems totally random and I can't correlate this to any 
 particular activity like cronjobs, etc.

I see.  Could you please try setting debug.acpi.max_threads=1 in
/boot/loader.conf, reboot and see if that makes any difference?

-- 
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: 9-Stable panic: resource_list_unreserve: can't find resource

[Andriy Gapon]

on 01/11/2012 11:45 Tom Lislegaard said the following:
 
 
 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: 31. oktober 2012 19:51
 To: Tom Lislegaard
 Cc: 'freebsd-sta...@freebsd.org'
 Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource

 on 31/10/2012 12:14 Tom Lislegaard said the following:
 Hi

 I'm running
 FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29 
 16:11:35 CET 2012
 tl@stingray:/usr/obj/usr/src/sys/stingray  amd64
 on a new Dell laptop and keep getting these panics (typically once or twice 
 per day)

 (kgdb) set pagination off
 (kgdb) bt
 #0  doadump (textdump=Variable textdump is not available.
 ) at pcpu.h:229
 #1  0x80425e64 in kern_reboot (howto=260) at 
 /usr/src/sys/kern/kern_shutdown.c:448
 #2  0x8042634c in panic (fmt=0x1 Address 0x1 out of bounds) at
 /usr/src/sys/kern/kern_shutdown.c:636
 #3  0x8045773e in resource_list_unreserve (rl=Variable rl is not 
 available.
 ) at /usr/src/sys/kern/subr_bus.c:3338
 #4  0x802c3ee4 in acpi_delete_resource (bus=0xfe00052c1100, 
 child=0xfe00052c1500,
 type=4, rid=3323) at /usr/src/sys/dev/acpica/acpi.c:1405
 #5  0x802c62bc in acpi_bus_alloc_gas (dev=0xfe00052c1500, 
 type=0xfe00052b786c,
 rid=0xfe00052b7978, gas=Variable gas is not available.
 ) at /usr/src/sys/dev/acpica/acpi.c:1450
 #6  0x802d1663 in acpi_PkgGas (dev=0xfe00052c1500, res=Variable 
 res is not available.
 ) at /usr/src/sys/dev/acpica/acpi_package.c:120
 #7  0x802cbf6b in acpi_cpu_cx_cst (sc=0xfe00052b7800) at
 /usr/src/sys/dev/acpica/acpi_cpu.c:782
 #8  0x802cc3a4 in acpi_cpu_notify (h=Variable h is not available.
 ) at /usr/src/sys/dev/acpica/acpi_cpu.c:1050
 #9  0x802a3fca in AcpiEvNotifyDispatch (Context=0x0) at
 /usr/src/sys/contrib/dev/acpica/events/evmisc.c:283
 #10 0x802c26c3 in acpi_task_execute (context=0xfe00051d6800, 
 pending=Variable pending
 is not available.
 ) at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:134
 #11 0x804683c4 in taskqueue_run_locked (queue=0xfe00052bc100) at
 /usr/src/sys/kern/subr_taskqueue.c:308
 #12 0x80469366 in taskqueue_thread_loop (arg=Variable arg is not 
 available.
 ) at /usr/src/sys/kern/subr_taskqueue.c:497
 #13 0x803f762f in fork_exit (callout=0x80469320 
 taskqueue_thread_loop,
 arg=0x80a20cc8, frame=0xff80002cdb00) at 
 /usr/src/sys/kern/kern_fork.c:992
 #14 0x806be6be in fork_trampoline () at 
 /usr/src/sys/amd64/amd64/exception.S:602

 Could you please provide *sc from frame 7?
 
 (kgdb) up 7
 #7  0x802cbf6b in acpi_cpu_cx_cst (sc=0xfe00052b7800) at 
 /usr/src/sys/dev/acpica/acpi_cpu.c:782
 782   acpi_PkgGas(sc-cpu_dev, pkg, 0, cx_ptr-res_type, 
 sc-cpu_rid,
 (kgdb) print *sc
 $1 = {cpu_dev = 0xfe00052c1500, cpu_handle = 0xfe00052e7a80, cpu_pcpu 
 = 0x80aa6a80, cpu_acpi_id = 1, cpu_p_blk = 1040, cpu_p_blk_len = 6, 
 cpu_cx_states = {{p_lvlx = 0xfe0196f0e380, type = 1, trans_lat = 1, power 
 = 1000, res_type = 4}, {p_lvlx = 0x0, type = 3, trans_lat = 87, power = 200, 
 res_type = 4}, {p_lvlx = 0x0, type = 3, trans_lat = 87, power = 200, res_type 
 = 4}, {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, 
 {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 
 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 0x0, type = 
 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 0x0, type = 0, 
 trans_lat = 0, power = 0, res_type = 0}}, cpu_cx_count = 2, cpu_prev_sleep = 
 619, cpu_features = 31, cpu_non_c3 = 1, cpu_cx_stats = {390, 0, 0, 0, 0, 0, 
 0, 0}, cpu_sysctl_ctx = {tqh_first = 0xfe00088931a0, tqh_last = 
 0xfe0008893228}, cpu_sysctl_tree = 0x0, cpu_cx_lowest = 0, 
 cpu_cx_lowest_lim = 0,
  !
cpu_cx_s
upported = C1/1 C2/59 C3/87, '\0' repeats 47 times, cpu_rid = 3323}

Thank you.
Did this crash occur at the time when you plugged or unplugged AC line?
Do you plug and unplug the line often?
Do you think that the line could have any problems like flaky contacts or some 
such?


-- 
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: notify userland about C-state changes

[Andriy Gapon]

on 02/10/2012 20:18 Sean Bruno said the following:
 
 The following patch adds only per-CPU notifications.

 acpi_cpu: explicitly notify userland about c-state changes

 diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c
 index 82e204a..15201f9 100644
 --- a/sys/dev/acpica/acpi_cpu.c
 +++ b/sys/dev/acpica/acpi_cpu.c
 @@ -1054,6 +1054,8 @@ acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void 
 *context)
  ACPI_SERIAL_BEGIN(cpu);
  acpi_cpu_set_cx_lowest(sc);
  ACPI_SERIAL_END(cpu);
 +
 +acpi_UserNotify(PROCESSOR, sc-cpu_handle, notify);
  }

  static int

 
 So quick question, does this happen a lot on a system with a sporadic
 workload?  Does this introduce overhead to the system to service the
 notification requests?

I am not sure who can answer this question.  It is up to ACPI platform to decide
when it changes _available C-states_.  OS doesn't have control over that.

P.S.  I hope you haven't confused this notification for a notification about
_current_ C-state changing.

-- 
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: notify userland about C-state changes

[Andriy Gapon]

on 03/10/2012 19:21 Sean Bruno said the following:
 On Wed, 2012-10-03 at 06:08 -0700, Andriy Gapon wrote:

 So quick question, does this happen a lot on a system with a
 sporadic
 workload?  Does this introduce overhead to the system to service the
 notification requests?

 I am not sure who can answer this question.  It is up to ACPI platform
 to decide
 when it changes _available C-states_.  OS doesn't have control over
 that.

 Hrm ... what changes to the machine would make this happen while the
 machine is running?  things like the switching from battery to line
 power?

Yes.  Or something else [?] of similar nature/effect.

 P.S.  I hope you haven't confused this notification for a notification
 about
 _current_ C-state changing. 
 
 I did have it confused.  Thanks for putting this note in.

OK :-)

-- 
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

acpi_wmi: move wmi_info_list into sc

[Andriy Gapon]

Please take a look at the following patch and a commit message that explains it.
I observed the problem on a system with acpi_wmi instances where one instance
overrode GUID list from the other.

commit f1f4109b1588872906ed56086e2680ac1af96268
Author: Andriy Gapon a...@icyb.net.ua
Date:   Thu Sep 27 13:48:18 2012 +0300

acpi_wmi: move wmi_info_list into sc

different instances of acpi_wmi couldn't properly share it and in fact
there was no reason to do that

diff --git a/sys/dev/acpi_support/acpi_wmi.c b/sys/dev/acpi_support/acpi_wmi.c
index 5a37979..5927ee1 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -74,6 +74,7 @@ struct acpi_wmi_softc {
struct sbuf wmistat_sbuf;   /* sbuf for /dev/wmistat output */
pid_t   wmistat_open_pid; /* pid operating on /dev/wmistat */
int wmistat_bufptr; /* /dev/wmistat ptr to buffer position 
*/
+   TAILQ_HEAD(wmi_info_list_head, wmi_info) wmi_info_list;
 };

 /*
@@ -105,8 +106,6 @@ struct wmi_info {
void*event_handler_user_data; /* ev handler cookie  
*/
 };

-TAILQ_HEAD(wmi_info_list_head, wmi_info)
-wmi_info_list = TAILQ_HEAD_INITIALIZER(wmi_info_list);

 ACPI_SERIAL_DECL(acpi_wmi, ACPI-WMI Mapping);

@@ -146,13 +145,13 @@ static ACPI_STATUSacpi_wmi_ec_handler(UINT32 
function,
void *region_context);
 #endif
 /* helpers */
-static ACPI_STATUS acpi_wmi_read_wdg_blocks(ACPI_HANDLE h);
+static ACPI_STATUS acpi_wmi_read_wdg_blocks(struct acpi_wmi_softc *sc,
ACPI_HANDLE h);
 static ACPI_STATUS acpi_wmi_toggle_we_event_generation(device_t dev,
struct wmi_info *winfo,
enum event_generation_state state);
 static int acpi_wmi_guid_string_to_guid(const UINT8 *guid_string,
UINT8 *guid);
-static struct wmi_info* acpi_wmi_lookup_wmi_info_by_guid_string(
+static struct wmi_info* acpi_wmi_lookup_wmi_info_by_guid_string(struct
acpi_wmi_softc *sc,
const char *guid_string);

 static d_open_t acpi_wmi_wmistat_open;
@@ -240,7 +239,7 @@ acpi_wmi_attach(device_t dev)
ACPI_SERIAL_BEGIN(acpi_wmi);
sc-wmi_dev = dev;
sc-wmi_handle = acpi_get_handle(dev);
-   TAILQ_INIT(wmi_info_list);
+   TAILQ_INIT(sc-wmi_info_list);
 #if 0
/* XXX Only works with one EC, but nearly all systems only have one. */
if ((sc-ec_dev = devclass_get_device(devclass_find(acpi_ec), 0))
@@ -263,7 +262,7 @@ acpi_wmi_attach(device_t dev)
acpi_wmi_notify_handler);
}
 #endif
-   else if (ACPI_FAILURE((status = acpi_wmi_read_wdg_blocks(
+   else if (ACPI_FAILURE((status = acpi_wmi_read_wdg_blocks(sc,
sc-wmi_handle {
device_printf(sc-wmi_dev, couldn't parse _WDG - %s\n,
AcpiFormatException(status));
@@ -318,11 +317,11 @@ acpi_wmi_detach(device_t dev)
AcpiRemoveAddressSpaceHandler(sc-wmi_handle,
ACPI_ADR_SPACE_EC, acpi_wmi_ec_handler);
 #endif
-   TAILQ_FOREACH_SAFE(winfo, wmi_info_list, wmi_list, tmp) {
+   TAILQ_FOREACH_SAFE(winfo, sc-wmi_info_list, wmi_list, tmp) {
if (winfo-event_handler)
acpi_wmi_toggle_we_event_generation(dev,
winfo, EVENT_GENERATION_OFF);
-   TAILQ_REMOVE(wmi_info_list, winfo, wmi_list);
+   TAILQ_REMOVE(sc-wmi_info_list, winfo, wmi_list);
free(winfo, M_ACPIWMI);
}
if (sc-wmistat_bufptr != -1) {
@@ -347,12 +346,14 @@ acpi_wmi_detach(device_t dev)
 static int
 acpi_wmi_provides_guid_string_method(device_t dev, const char *guid_string)
 {
+   struct acpi_wmi_softc *sc;
struct wmi_info *winfo;
int ret;

+   sc = device_get_softc(dev);
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
ACPI_SERIAL_BEGIN(acpi_wmi);
-   winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string);
+   winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string);
ret = (winfo == NULL)?0:winfo-ginfo.max_instance+1;
ACPI_SERIAL_END(acpi_wmi);

@@ -378,7 +379,7 @@ acpi_wmi_evaluate_call_method(device_t dev, const char
*guid_string,

sc = device_get_softc(dev);
ACPI_SERIAL_BEGIN(acpi_wmi);
-   if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string))
+   if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string))
== NULL)
status = AE_NOT_FOUND;
else if (!(winfo-ginfo.flags  ACPI_WMI_REGFLAG_METHOD))
@@ -420,6 +421,7 @@ static ACPI_STATUS
 acpi_wmi_install_event_handler_method(device_t dev, const char *guid_string,
 ACPI_NOTIFY_HANDLER event_handler, void *data)
 {
+   struct acpi_wmi_softc

Re: notify userland about C-state changes

[Andriy Gapon]

on 03/10/2012 20:40 Ian Smith said the following:
 So are you talking about a devd notification to trigger activity like 
 the AC/battery script, or a sysctl that scripts could poll, or?

devd notification like for AC line status change.

-- 
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: do we always have acpi_cpu for a cpu?

[Andriy Gapon]

[ping]

on 11/09/2012 09:32 Andriy Gapon said the following:
 
 I think that we always expect to have a one-to-one correspondence between
 acpi_cpu devices and actual (APIC) CPUs.  acpi_pcpu_get_id() seems to even
 assert that, if I am reading the code correctly.
 
 The following patch adds the assert to acpi_cpu_idle as well and also removes
 what I believe to be an obsolete comment about HTT CPUs.
 
 acpi_cpu: expect every cpu to have a corresponding acpi_cpu object
 
 ... via Processor object in ASL namespace.
 
 diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c
 index 15201f9..203ed02 100644
 --- a/sys/dev/acpica/acpi_cpu.c
 +++ b/sys/dev/acpica/acpi_cpu.c
 @@ -925,23 +925,15 @@ acpi_cpu_idle()
  uint32_t start_time, end_time;
  int  bm_active, cx_next_idx, i;
 
 +sc = cpu_softc[PCPU_GET(cpuid)];
 +KASSERT(sc != NULL, (acpi_cpu_idle: CPU without ACPI CPU));
 +
  /* If disabled, return immediately. */
  if (cpu_disable_idle) {
   ACPI_ENABLE_IRQS();
   return;
  }
 
 -/*
 - * Look up our CPU id to get our softc.  If it's NULL, we'll use C1
 - * since there is no ACPI processor object for this CPU.  This occurs
 - * for logical CPUs in the HTT case.
 - */
 -sc = cpu_softc[PCPU_GET(cpuid)];
 -if (sc == NULL) {
 - acpi_cpu_c1();
 - return;
 -}
 -
  /* Find the lowest state that has small enough latency. */
  cx_next_idx = 0;
  if (cpu_disable_deep_sleep)
 


-- 
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: improve cx_lowest logic

[Andriy Gapon]

on 05/09/2012 19:23 Kevin Oberman said the following:
 On Wed, Sep 5, 2012 at 9:12 AM, Andriy Gapon a...@freebsd.org wrote:
 on 05/09/2012 18:17 Kevin Oberman said the following:
 Thanks so much! This should finally make Cx states work on my
 ThinkPad! I really appreciate it. Guess it's time to do my weekly
 upgrade of this system.

 I haven't sneaked in that other commit :-(
 
 Oops! :-(
 
 Oh, well. At least it should make it to /base/stable/9 soon. Right???
 (I only run release/ or releng/ or for an occasional test.)
 

It's already in stable/9 :)

-- 
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: improve cx_lowest logic

[Andriy Gapon]

on 05/09/2012 20:41 Kevin Oberman said the following:
 On Wed, Sep 5, 2012 at 9:32 AM, Andriy Gapon a...@freebsd.org wrote:
 on 05/09/2012 19:23 Kevin Oberman said the following:
 On Wed, Sep 5, 2012 at 9:12 AM, Andriy Gapon a...@freebsd.org wrote:
 on 05/09/2012 18:17 Kevin Oberman said the following:
 Thanks so much! This should finally make Cx states work on my
 ThinkPad! I really appreciate it. Guess it's time to do my weekly
 upgrade of this system.

 I haven't sneaked in that other commit :-(

 Oops! :-(

 Oh, well. At least it should make it to /base/stable/9 soon. Right???
 (I only run release/ or releng/ or for an occasional test.)


 It's already in stable/9 :)
 
 Ahh! I now see C3/109, but I see some strange behavior. When on AC
 power, only C1/1 and C2/104 are available, but cx_lowest is C3, even
 though C3 is not available. If I switch to battery, C1/1, C2/80 and
 C3/109 are available (???), but cx_lowest is set to C2. I find the Cx
 value sets a bit odd, but the setting of cx_lowest appears to be a
 bug, at least to me. I can manually set cx_lowest to C3 and I actually
 use C3.
 
 My suspicion is that there is either a race or a logic issue where
 x_lowest is reset to the lowest value before the available Cx values
 are set, so cx_lowest is always set the the lowest Cx state from the
 previous power configuration. (This is a guess, but it fits what I am
 seeing very well.)
 

Hmm, this looks like the older behavior.
What revision are you at?  Also, any local ACPI-related patches?

-- 
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: disabled CST_CNT write

[Andriy Gapon]

on 08/07/2012 13:19 Taku YAMAMOTO said the following:
 In addition, that does not interfere with jkim's acpi_cx_native2.diff;
 I've been enjoying MWAIT C3 with varying sleep depth based upon AC 
 availability.

Are you saying that you have thoroughly tested that patch? :-)
I don't see any reason not to commit it then.
Jung-uk?

-- 
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

acpi_cpu_idle: cpu with no corresponding acpi cpu

[Andriy Gapon]

I have a question about the following block in acpi_cpu_idle:
/*
 * Look up our CPU id to get our softc.  If it's NULL, we'll use C1
 * since there is no ACPI processor object for this CPU.  This occurs
 * for logical CPUs in the HTT case.
 */
sc = cpu_softc[PCPU_GET(cpuid)];
if (sc == NULL) {
acpi_cpu_c1();
return;
}

I believe that a part of the comment that singles out HTT is certainly incorrect
for modern and non-buggy ACPI tables.
But in general, should we expect (and support) ACPI platforms where some real
CPUs (which have to be advertised via ACPI [modulo non-MADT, mptable-only
systems]) do not have corresponding Processor objects in DSDT?
Does acpi_pcpu_get_id provide such support?
Or can the code in question be just replaced with KASSERT?

Thank you in advance.
-- 
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: improve cx_lowest logic

[Andriy Gapon]

on 10/07/2012 18:49 Sean Bruno said the following:
 On Sun, 2012-07-08 at 03:22 -0700, Andriy Gapon wrote: 
 I would like to propose the following change for review and testing:
 http://people.freebsd.org/~avg/acpi_cpu_cx_lowest.diff
 
 Very nice.  After a review I went ahead and applied it for testing.  All
 seems to be well on battery and A/C on my T520 so I'm very happy to see
 this go into the tree.
 
 Let me know if you want me to do the man page update for acpi_cpu(4) 

Sean,

I would appreciate this a lot as I am currently a little bit busier than usual.

On a related note I also have this change for acpi.4:
--- a/share/man/man4/acpi.4
+++ b/share/man/man4/acpi.4
@@ -80,8 +80,12 @@ A scheduling algorithm will select states between
 and this setting
 as system load dictates.
 To enable ACPI CPU idling control,
-.Va machdep.cpu_idle_hlt
-must be set to 1.
+.Va machdep.idle
+should be set to
+.Li acpi
+if it is listed in
+.Va machdep.idle_available
+.
 .It Va hw.acpi.cpu.cx_supported
 List of supported CPU idle states and their transition latency
 in microseconds.

How does this look?
-- 
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: disabled CST_CNT write

[Andriy Gapon]

on 08/07/2012 19:49 Nate Lawson said the following:
 On Jul 8, 2012, at 2:11 AM, Andriy Gapon wrote:
 
 acpi_cpu.c has a block of code to write CST_CNT to SMI_CMD, but the block is
 under #ifdef notyet.  It seems that the code was added that many years ago 
 and
 never enabled.
 Now, judging from the reports I've seen on this mailing list, it appears that
 _CST changes do happen and the driver seem to handle them sufficiently well.
 I think that a lot of modern platforms do not even provide CST_CNT and assume
 that an OS is able to handle C-state change notifications.
 So, I guess that it should be safe to enable the code in question now.

 Could anyone with a FreeBSD laptop and non-zero CST_CNT in FADT please test 
 this?
 
 It was only under an #ifdef because at the time our CST implementation 
 couldn't handle CST changes cleanly. I had added some support for it, but 
 since it couldn't be tested, I wasn't sure how actual hardware would behave.
 
 I think it's fine to enable now. I think 2007-era Thinkpads were some of the 
 first to add this feature.

Nate,

thank you for the information/explanation.

-- 
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

disabled CST_CNT write

[Andriy Gapon]

acpi_cpu.c has a block of code to write CST_CNT to SMI_CMD, but the block is
under #ifdef notyet.  It seems that the code was added that many years ago and
never enabled.
Now, judging from the reports I've seen on this mailing list, it appears that
_CST changes do happen and the driver seem to handle them sufficiently well.
I think that a lot of modern platforms do not even provide CST_CNT and assume
that an OS is able to handle C-state change notifications.
So, I guess that it should be safe to enable the code in question now.

Could anyone with a FreeBSD laptop and non-zero CST_CNT in FADT please test 
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: [rethinking] Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.

[Andriy Gapon]

on 04/07/2012 18:04 Andriy Gapon said the following:
 Our current approach of using C-state indexes as C-state identifiers/names 
 may be
 not so bad after all if we remove confusion by properly documenting the 
 meaning
 (index vs type).
 Here is a link to a past discussion on this topic:
 http://thread.gmane.org/gmane.os.freebsd.current/127860/focus=6373
 I think that messages in a sub-thread starting at the highlighted message may
 provide some useful information.
 Here are couple of links to the code in Linux and OpenSolaris:
 http://lxr.linux.no/#linux+v3.4.4/drivers/acpi/processor_idle.c#L354
 http://lxr.linux.no/#linux+v3.4.4/drivers/acpi/processor_idle.c#L1097
 http://fxr.watson.org/fxr/source/i86pc/os/cpupm/cpu_acpi.c?v=OPENSOLARIS#L683
 http://fxr.watson.org/fxr/source/i86pc/os/cpupm/cpu_idle.c?v=OPENSOLARIS;im=bigexcerpts#L678
 
 So, now as then I still don't have any preference for either of methods.  But 
 the
 decision is not straightforward as you might see now, thus we need some 
 convincing
 that any change is needed actually :-)
 
 For more information about each C-state I would go a way of creating a sysctl
 forest with a tree at each C-state under each CPU (for potential asymmetric
 C-state support), which would describe all available parameters of each 
 C-state
 (power, latency, ACPI (or HW-specific[*]) type, I/O-vs-MWAIT-vs-etc type of
 entrance, etc).
 
 [*] E.g. for intel_idle it could be C-state numbers from Intel specs.
 

Here is an example based on a real i7 system (enslaved by Linux) to make the
situation more easy to comprehend.
The system seems to provide 5 C-states including C0, but uninteresting C0 and C1
will be omitted in the further data.

So:
ACPI (_CST) index   2   3   4
ACPI (_CST) type2   3   3
ACPI I/O register   0x414   0x415   0x416
Intel name (intel_idle) C3  C6  C7
MWAIT hint  0x100x200x30
[*] ACPI tables can advertise C-states either with I/O entry or with MWAIT entry
based on declared OS capabilities (what FreeBSD defines as 
ACPI_CAP_SMP_C3_NATIVE,
to be precise).
MWAIT hints are the same both in ACPI tables and in intel_idle driver.

I make the following observations and conclusions.
All C-states are really different despite two of them having the same ACPI type.
So collapsing C-states based on ACPI type like (Open)Solaris does (did) is 
clearly
a wrong approach.
Using ACPI type as a name (identity) of a C-state also seems to be unhelpful 
(C3
- which C3, the first C3 or the second C3?).
Restoring the vendor designated names of the states (C3, C6, C7) is impossible
from ACPI provided information alone.

Where does this leave us?  I think that it leaves us exactly where we are now 
(and
Linux too).
The only thing that I would perhaps change would be to drop 'C' from FreeBSD
C-state names to minimize confusion with real C-state name/types/whatevers
(whichever one prefers to consider to be the real ones) and to emphasize that 
they
are just indexes/handles/FreeBSD IDs.
But even such a change, being purely cosmetic, probably has too little benefit
considering potential pain of POLA violation.

So I urge you to give up your C-state renaming patch.
At least for me the above example decides the choice.


-- 
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: [rethinking] Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.

[Andriy Gapon]

on 03/07/2012 00:17 Sean Bruno said the following:
 Agreed.  We shall have to discuss further and see where this leads us.
 Its starting to look like some amount of further overhaul may be
 required.

[Just replying to a high-level thing here.]
Or maybe no overhaul at all?.. :-)

Our current approach of using C-state indexes as C-state identifiers/names may 
be
not so bad after all if we remove confusion by properly documenting the meaning
(index vs type).
Here is a link to a past discussion on this topic:
http://thread.gmane.org/gmane.os.freebsd.current/127860/focus=6373
I think that messages in a sub-thread starting at the highlighted message may
provide some useful information.
Here are couple of links to the code in Linux and OpenSolaris:
http://lxr.linux.no/#linux+v3.4.4/drivers/acpi/processor_idle.c#L354
http://lxr.linux.no/#linux+v3.4.4/drivers/acpi/processor_idle.c#L1097
http://fxr.watson.org/fxr/source/i86pc/os/cpupm/cpu_acpi.c?v=OPENSOLARIS#L683
http://fxr.watson.org/fxr/source/i86pc/os/cpupm/cpu_idle.c?v=OPENSOLARIS;im=bigexcerpts#L678

So, now as then I still don't have any preference for either of methods.  But 
the
decision is not straightforward as you might see now, thus we need some 
convincing
that any change is needed actually :-)

For more information about each C-state I would go a way of creating a sysctl
forest with a tree at each C-state under each CPU (for potential asymmetric
C-state support), which would describe all available parameters of each C-state
(power, latency, ACPI (or HW-specific[*]) type, I/O-vs-MWAIT-vs-etc type of
entrance, etc).

[*] E.g. for intel_idle it could be C-state numbers from Intel specs.
-- 
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: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.

[Andriy Gapon]

on 20/06/2012 19:44 Sean Bruno said the following:
 On Tue, 2012-06-19 at 09:02 -0700, Sean Bruno wrote:
 http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt
 
 also, I wanted to point out that I'm returning BUS_PROBE_GENERIC here.
 
 I want to emulate the Intel acpi_idle code that exists in linux-land and
 I *thought* that I could setup an acpi_cpu_idle module that would come
 in at a higher priority on Intel cpus, however there's some SYSINIT()
 hackery going on that I don't know how to handle gracefully.  I'm not
 sure how to proceed with a different idle module here.  thoughts?
 
 e.g.
 
 static void
 acpi_cpu_postattach(void *unused __unused)
 {
 device_t *devices;
 int err;
 int i, n;
 
 err = devclass_get_devices(acpi_cpu_devclass, devices, n);
 if (err != 0) {
 printf(devclass_get_devices(acpi_cpu_devclass) failed\n);
 return;
 }
 for (i = 0; i  n; i++)
 bus_generic_probe(devices[i]);
 for (i = 0; i  n; i++)
 bus_generic_attach(devices[i]);
 free(devices, M_TEMP);
 }
 
 SYSINIT(acpi_cpu, SI_SUB_CONFIGURE, SI_ORDER_MIDDLE,
 acpi_cpu_postattach, NULL);
 
 

Just a little bit of explanation for the code.
acpi_cpu driver is attached very early because it does some ACPI configuration
in its attach method (_OSC/_PDC calls) and correct behavior of other ACPI
drivers may depend on this.  On the other hand, acpi_cpu acts as a bus and has
child devices.  Some of those children can not attach that early because they
need more of the system to be initialized (e.g. PCI bus).  Hence the SYSINIT
hack to attach them later.

-- 
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: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.

[Andriy Gapon]

on 20/06/2012 23:54 Sean Bruno said the following:
 On Wed, 2012-06-20 at 13:18 -0700, Andriy Gapon wrote:
 I also, disagree with the idea of FreeBSD C-states as that is not
 the
 intention of the code.  The code, from my read, is trying to
 interpret
 C-states as though they are always defined sequentially and
 non-sparse.

 I seem to recall that this is an ACPI requirement.  I could be
 mistaken, but no
 time to double-check at the moment.


 
 Just to check as I'm actively looking at this code I went and grabbed
 the December 6, 2011 ACPI spec.  http://www.acpi.info/spec.htm
 
 chap 8.1 pretty clearly states that C2 and C3 are optional states. So it
 appears that you can have a C3 without a C2.  So, I suspect that the
 idea that the index the cx_states array is always going to be 1 less
 that the ACPI Cstate value isn't by spec.  Or something ...  :-)

I think that the chapter on _CST is more relevant here (8.4.2.1 in my copy of
the spec).  But anyway, there is no such requirement in the specification.  I
was misremembering the requirement that states should be ordered.

So, would you like to produce a cleaned up version of your patch with only this
change in it?

-- 
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: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.

[Andriy Gapon]

on 20/06/2012 19:14 Sean Bruno said the following:
 Since this patch changes the output of the sysctl format, I disagree
 with it.

And I am not proposing it for the tree.

 I also, disagree with the idea of FreeBSD C-states as that is not the
 intention of the code.  The code, from my read, is trying to interpret
 C-states as though they are always defined sequentially and non-sparse.

I seem to recall that this is an ACPI requirement.  I could be mistaken, but no
time to double-check at the moment.

 I am still of the opinion that my patch is correct at this point.


-- 
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: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.

[Andriy Gapon]

on 19/06/2012 19:02 Sean Bruno said the following:
 The first impact of this behavior is to list C3 as C2 in the list of
 Cstates when you retrieve the cx_supported sysctls for the cpus.

I do not think that this is a real problem.  A cosmetic one - most likely.

 The
 second impact is that the power_profile script never drops to a valid
 Cstate when you set the economy_lowest variable in rc.conf.

Could you please explain if this somehow follows from your first observation and
how?
If not, could you please share your finding on what exactly causes this to 
happen?

Also, are we talking about a laptop here?  Namely, judging from the reference to
'economy_lowest', are AC state changes in play?

-- 
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: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.

[Andriy Gapon]

on 20/06/2012 00:42 Sean Bruno said the following:
 On Tue, 2012-06-19 at 14:07 -0700, Andriy Gapon wrote:
 on 19/06/2012 19:02 Sean Bruno said the following:
 The first impact of this behavior is to list C3 as C2 in the list of
 Cstates when you retrieve the cx_supported sysctls for the cpus.

 I do not think that this is a real problem.  A cosmetic one - most likely.

 Yes, most likely.  Except that the code seems to think that the index of
 the Cstates is good enough for a comparison to value.  More over, the
 sysctl's accept a value like C3 and manipulate that into an index into
 the Cstate array without checking for the Cstate value.
 
 The impact of this patch corrects this cosmetic display issue.  

If you accept that there are FreeBSD C-states and everything is done in terms
of them, then there is no problem.
I once wrote this trivial patch to see more information about FreeBSD-reported
C-states:
https://gitorious.org/~avg/freebsd/avgbsd/commit/043e9b0da5b46d389971e0166789fbee8a4e8622?format=patch

 The
 second impact is that the power_profile script never drops to a valid
 Cstate when you set the economy_lowest variable in rc.conf.

 Could you please explain if this somehow follows from your first observation 
 and
 how?
 If not, could you please share your finding on what exactly causes this to 
 happen?

 Also, are we talking about a laptop here?  Namely, judging from the 
 reference to
 'economy_lowest', are AC state changes in play?

 
 No, what I was attempting to do was configure a server such that it
 would attempt to use the C3 state at idle.  Since the server gets
 configured by the power_state scripts via devd, the server is never
 configured with its global cx_lowest as anything other than C1.  e.g:
 
 -bash-4.2$ sysctl -a|grep cx_lowest
 hw.acpi.cpu.cx_lowest: C1
 dev.cpu.0.cx_lowest: C1
 dev.cpu.1.cx_lowest: C1
 
 -bash-4.2$ sysctl -a|grep cx_supported
 dev.cpu.0.cx_supported: C1/1 C2/96
 dev.cpu.1.cx_supported: C1/1 C2/96
 
 
 It seems that the rc.conf value of performance_cx_lowest=LOW is what I
 really want, not economy_cx_lowest. 

Yes.  Could you please try this without using your patch?

I get an impression that its effect was to actually request C2 when cx_lowest is
set to C1.

-- 
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: [stable 9] broken hwpstate calls

[Andriy Gapon]

on 07/06/2012 02:02 Jung-uk Kim said the following:
 Any way, hwpstate still isn't quite right even without your patch.
 
 sys/kern/kern_cpu.c cpufreq_curr_sysctl() - CPUFREQ_SET() - /* for all
 CPU devices */ cf_set_method() - /* thread_lock(), sched_bind(), ... */ 
 CPUFREQ_DRV_SET() - sys/x86/cpufreq/hwpstate.c hwpstate_set() - 
 hwpstate_goto_pstate()/* for each CPU unit */ /* thread_lock(),
 sched_bind(), ... */

Oh, I didn't realize that there was the cpufreq-level loop over all CPUs!
That really sucks.

Maybe some day we should accept that different CPUs could legitimately be in
different P-states and provide support for that throughout the stack (from
powerd to drivers).

-- 
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: [stable 9] broken hwpstate calls

[Andriy Gapon]

on 07/06/2012 11:38 Alexander Motin said the following:
 On 06/07/12 11:10, Andriy Gapon wrote:
 on 07/06/2012 02:02 Jung-uk Kim said the following:
 Any way, hwpstate still isn't quite right even without your patch.

 sys/kern/kern_cpu.c cpufreq_curr_sysctl() -  CPUFREQ_SET() -/* for all
 CPU devices */ cf_set_method() -/* thread_lock(), sched_bind(), ... */
 CPUFREQ_DRV_SET() -  sys/x86/cpufreq/hwpstate.c hwpstate_set() -
 hwpstate_goto_pstate()/* for each CPU unit */ /* thread_lock(),
 sched_bind(), ... */

 Oh, I didn't realize that there was the cpufreq-level loop over all CPUs!
 That really sucks.

 Maybe some day we should accept that different CPUs could legitimately be in
 different P-states and provide support for that throughout the stack (from
 powerd to drivers).
 
 Support for different P-states on different CPUs can be useful if CPUs have
 different capabilities.

Not sure what you mean... I was talking about setting different CPUs to
different P-states based on the per-CPU conditions (e.g. utilization).  I
certainly didn't mean to talk about heterogeneous P-state definitions or any
other heterogeneous silicon issues.

 I believe it is very rare, but possible. At this moment
 cpufreq should set for each CPU frequency closest to one that was set on BSP. 
 It
 should be possible to make powerd to read sets of frequencies from all CPUs 
 and
 do the same, just more intelligently.
 
 Same time using very different frequencies for different CPUs can IMHO be very
 problematic even in theory. For SMP systems it is quite difficult (because of
 threads migration and possible inter-operations of multiple threads) to 
 identify
 cases when even global frequency can be reduced without proportional 
 performance
 penalty. Making in per-CPU multiplies number of options and requires awareness
 from the scheduler.

I humbly disagree.  I think that it's not a job of scheduler to be overly smart
when power-saving policies are in effect.  IMO, scheduler should just do its own
job and powerd should react to individual loads of CPUs.  Where latencies really
matter there powerd should not be used (or perhaps used with some different
policy skewed towards performance vs economy).

Also, Linux does it, so it must at least doable :-)

-- 
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: cpu stopping

[Andriy Gapon]

on 06/06/2012 22:03 Mitsuru IWASAKI said the following:
 Hi,
 
 I've created the patches of experimental implementation based on
 discussion so far.
 
 http://people.freebsd.org/~iwasaki/acpi/cpustop_hook-20120606.diff
 
 In acpi_wakeup.c, cpususpend_handler() and susppcbs are replaced with
 cpustop_handler() and stoppcbs.
 
 This is for RELENG_9 and only for i386 but I think it's enough for the
 start.

I think that there is no need for DPCPU here.  All (affected) CPUs should see
the same hook, IMO.  At least I can not imagine the case where something else
would be required.
Also, it might make sense to provide a void pointer as a potential context for
for the context.  As Attilio has said before this has many similarities to what
smp_rendezvous does, just for different kind of situations.

 From: Andriy Gapon a...@freebsd.org
 Subject: Re: cpu stopping
 Date: Sun, 03 Jun 2012 22:45:33 +0300
 Message-ID: 4fcbbedd.5000...@freebsd.org
 
 Never mind :) What I'm trying to do in the patches is just to unify
 amd64/i386 independent part (acpi_wakeup.c) for the code maintenance,
 so please let's commit it first, then start re-design the
 cpususpend_handler().

 In no way I am trying to delay your work :)
 Just shared my view on the design of cpu stopping code.
 
 I got it :)
 
 My view of how this should work is:
 - there can be only one master CPU that controls all other (slave) CPUs
 - the master sets entry and exit hooks

 Entry hook for suspending might be
 
 ctx_fpusave(suspfpusave[cpu]);
 wbinvd();
 CPU_SET_ATOMIC(cpu, stopped_cpus);
 

 and for stopping is
 
 /* Indicate that we are stopped */
 CPU_SET_ATOMIC(cpu, stopped_cpus);
 

 Correct?

 Yes.  The only nit is that CPU_SET_ATOMIC(cpu, stopped_cpus) could be part 
 of
 the wait loop prologue.  No need to duplicate it in each hook.
 
 OK, I did so.
 
 I hope the patch is not far from your idea.
 
 Thanks!


-- 
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: ACPI 'driver bug: Unable to set devclass'

[Andriy Gapon]

on 17/05/2012 17:05 John Baldwin said the following:
 On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote:
 Oh, whoops.  Actually, the right way to do this I think is 
 bus_hint_device_unit()
 (and/or, not make the unit number in cpuX mean anything at all, but use a 
 separate
 ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to).  I 
 think
 the last approach is really the right way to fix this.
 
 I haven't been able to try this yet, but I have a first cut at
 www.freebsd.org/~jhb/patches/acpi_cpu.patch
 

The patch has not been compile-tested? :)

-- 
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: ACPI 'driver bug: Unable to set devclass'

[Andriy Gapon]

on 14/05/2012 01:43 Bruce Cran said the following:
 On 13/05/2012 21:06, Andriy Gapon wrote:
 Can you produce an equivalent snippet with verbose logging enabled? I have a
 suspicion that these messages are a byproduct from r231161. 
 
 acpi0: reservation of fee0, 1000 (3) failed
 acpi0: reservation of 0, a (3) failed
 acpi0: reservation of 10, bbf0 (3) failed
 acpi_sysresource: acpi_sysresource0 already exists; skipping it
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 acpi_timer: acpi_timer0 already exists; skipping it
 driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
 cpu0: ACPI CPU on acpi0
 ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44
 (20120420/tbutils-293)
 ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm  P001Ist 0011 INTL 20051117)
 ACPI: Dynamic OEM Table Load:
 ACPI: SSDT 0 01340 (v01 DpgPmm  P001Ist 0011 INTL 20051117)
 ACPI: SSDT 0xbb791430 004F4 (v01  PmRef  P001Cst 3001 INTL 20051117)
 ACPI: Dynamic OEM Table Load:
 ACPI: SSDT 0 004F4 (v01  PmRef  P001Cst 3001 INTL 20051117)
 acpi_sysresource: acpi_sysresource2 already exists; skipping it
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 cpu2: ACPI CPU on acpi0
 acpi_sysresource: acpi_sysresource1 already exists; skipping it
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 cpu1: ACPI CPU on acpi0
 acpi_sysresource: acpi_sysresource3 already exists; skipping it
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 

I think that the following is what happens here in the acpi_timer case.
Previously one acpi_timer device_t was added with an order of zero and a fixed
unit number of zero in acpi_timer_identify().  Then, another acpi_timer device_t
could be added when walking the ACPI device tree, that device would always have 
a
later order and a wildcard unit number (-1).
Now both the hardwired device and auto-probed device are added with the same
order of 2 and it also so happens that the hardwired device is after the
auto-probed in the device list.  So first the auto-probed device just takes the
unit number of zero because it is free and then the hardwired device fails to
claim the same unit number.

The call chain is:
device_probe_child - device_set_devclass - devclass_add_device -
devclass_alloc_unit.

BTW, it seems that acpi_timer_probe is hardcoded to succeed only for the 
hardwired
device, so I am not if we should just skip creating an auto-probed device.  In 
any
case, setting any special properties for the auto-probed device (like the order)
seems to be completely pointless.

I am not really sure what happens for the acpi_sysresource devices.

-- 
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: ACPI 'driver bug: Unable to set devclass'

[Andriy Gapon]

on 13/05/2012 11:39 Bruce Cran said the following:
 I've just updated to -current and noticed the following errors in dmesg:
 
 acpi0: NEC  on motherboard
 acpi0: Power Button (fixed)
 acpi0: reservation of fee0, 1000 (3) failed
 acpi0: reservation of 0, a (3) failed
 acpi0: reservation of 10, bbf0 (3) failed
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
 cpu0: ACPI CPU on acpi0
 ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44
 (20120420/tbutils-293)
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 cpu2: ACPI CPU on acpi0
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 cpu1: ACPI CPU on acpi0
 driver bug: Unable to set devclass (class: acpi_sysresource devname: 
 (unknown))
 

Can you produce an equivalent snippet with verbose logging enabled?
I have a suspicion that these messages are a byproduct from r231161.
-- 
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: intpm - AMD SMBus Controller

[Andriy Gapon]

on 23/03/2012 17:20 Oliver Lehmann said the following:
 Hi,
 
 I've an Asus E35M1-M. When I load intpm.ko I get:
 
 intsmb0: AMD SB600/700/710/750 SMBus Controller at device 20.0 on pci0
 intsmb0: Could not allocate I/O space
 device_attach: intsmb0 attach returned 6
 
 Any idea what I could do to investigate further?

The chipset is not really supported by the driver.  It shouldn't even try to 
attach.

-- 
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: bin/126162: [acpi] ACPI autoload failed : loading required module quot;pciquot; - no such file or directories

[Andriy Gapon]

The following reply was made to PR bin/126162; it has been noted by GNATS.

From: Andriy Gapon a...@freebsd.org
To: bug-follo...@freebsd.org, ad...@mail.ru
Cc:  
Subject: Re: bin/126162: [acpi] ACPI autoload failed : loading required module
 quot;pciquot; - no such file or directories
Date: Sun, 19 Feb 2012 23:32:25 +0200

 The report seems rather old.  Can the problem still be reproduced?
 On the newer releases the ACPI code is built into kernel and so there should 
not
 be any module loading issue in principle.
 
 -- 
 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: [panic] general protection fault - triggered in acpi_cmbat_get_bst() ?

[Andriy Gapon]

on 26/01/2012 16:20 Glen Barber said the following:
 On Thu, Jan 26, 2012 at 02:47:10PM +0200, Andriy Gapon wrote:
 Prior to Monday's email, I was out of town and mostly away from the
 laptop.  I can't definitively say, but it's likely I didn't have the
 laptop running long enough to experience the problem.

 Still confused - are you saying that you have _never_ let this laptop run 
 long enough?

 
 No.  I'm saying I haven't seen the machine crash from gkrellm polling
 the battery state.  FWIW, all three crashes (before disabling that
 monitor) occurred when the laptop was plugged in, and at 100% battery.
 
 Also, what's debug.acpi.acpi_ca_version on this system?


 nucleus % sysctl debug.acpi.acpi_ca_version
 debug.acpi.acpi_ca_version: 20120111

 So, from your experience with this laptop, can the problem be caused by the 
 latest
 ACPICA import?  Or do you suppose that the problem could have existed before 
 it?

 
 I of course can't be 100% certain the problem didn't exist before, but I
 definitely have had this laptop running for a few hours in the past.
 It's possible it was the ACPICA import, but the version of -CURRENT I
 was running before upgrading on the 21st was only three days old or so.


Given that there hasn't been any changes to sys/dev/acpica (i.e. FreeBSD ACPI
code) at all since 2011-12-29, I am inclined to assume that the problem is 
caused
by the ACPICA 20120111 import.

-- 
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: [panic] general protection fault - triggered in acpi_cmbat_get_bst() ?

[Andriy Gapon]

on 26/01/2012 16:49 Glen Barber said the following:
 On Thu, Jan 26, 2012 at 04:45:26PM +0200, Andriy Gapon wrote:
 Given that there hasn't been any changes to sys/dev/acpica (i.e. FreeBSD ACPI
 code) at all since 2011-12-29, I am inclined to assume that the problem is 
 caused
 by the ACPICA 20120111 import.

 
 I've just re-enabled the battery monitor in gkrellm.  Should the machine
 crash again for the same reason, is there anything specific I can
 provide to troubleshoot this?  I can drop the core.txt.N file somewhere
 public if that helps, as well as any kgdb output needed.

I would help to get a backtrace with line numbers from kgdb.
And also to get detailed information about values of variables in the
AcpiUtAllocateObjectDescDbg frame.

-- 
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: [panic] general protection fault - triggered in acpi_cmbat_get_bst() ?

[Andriy Gapon]

on 23/01/2012 19:25 Glen Barber said the following:
 Hi,
 
 I'm running a 2-day old -CURRENT:
 
 FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r230418M: Sat Jan
 21 00:17:24 EST 2012 gjb@nucleus:/usr/obj/usr/src/sys/NUCLEUS  amd64
 
 I've just had an ACPI-related panic, caused by the sysutils/gkrellm2
 port, which looks to me like the battery state was not available.
 
 I have kgdb output attached, and can provide any additional information
 necessary.

The following is not clear from your description: this looks like a new problem,
so what's changed - the version of FreeBSD or the hardware?

Also, what's debug.acpi.acpi_ca_version on this system?

-- 
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: acpi_ibm fails to work on new laptop

[Andriy Gapon]

on 14/07/2011 18:22 Kevin Oberman said the following:
 #define _COMPONENT ACPI_OEM
 ACPI_MODULE_NAME(IBM)
 
 I'm guessing that the OEMID and the ACPI_MODULE_NAME need to match.

No.

-- 
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

[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) brightness controls of an Atom N455-based netbook

[Andriy Gapon]

on 11/07/2011 19:08 Vitaly Magerya said the following:
 Andriy Gapon a...@freebsd.org wrote:
 From what I heard this isn't a problem with FreeBSD ACPI code, it's
 a problem with Samsung firmware. AFAIK to get brightness controls
 working on Windows you need to setup Samsung software that uses
 undocument BIOS interface for it's function.

 Linux has what appears to be a reverse-engineered driver [1] that
 does the same. Someone (probably me) needs to port it.

 Maybe, maybe not...  Can you please verify which driver Linux actually uses 
 on
 your system?
 
 Nothing but generic ACPI; samsung-laptop dirver is not used because
 it doesn't white-list my laptop model (and for some reason fails
 to attach when I load it with force=1, even though my BIOS definitely
 has the signatures it is looking for).
 
 At any rate, brightness controls don't work under Linux.

I officially give up on this case then :-)
Maybe you'd want to report this problem to Linux folks too.
If they come up with a fix we may borrow it from them.

 So I can see how this behavior can easily confuse our acpi_video driver.
 I see that Linux acpi video driver has some quirks in it, but not sure if it 
 is
 able to handle this kind of issues.  I would doubt that.

 Maybe you would feel adventurous enough to experiment with hacking your DSDT 
 some
 more.  For a start I would just try to remove that level % 10 == 0 check.
 
 Sure. I removed those checks, but there isn't much difference.
 Here's a sample transcript:
 
 # sysctl hw.acpi.video
 hw.acpi.video.crt0.active: 0
 hw.acpi.video.lcd0.active: 0
 hw.acpi.video.lcd0.brightness: 5
 hw.acpi.video.lcd0.fullpower: 100
 hw.acpi.video.lcd0.ecoomy: 5
 hw.acpi.video.lcd0.levels: 100 5 15 24 30 45 60 80
 hw.acpi.video.ext0.active: 0
 hw.acpi.video.out0.active: 0
 # sysctl hw.acpi.video.lcd0.brightness=45
 hw.acpi.video.lcd0.brightness: 5 - 45
 # sysctl hw.acpi.video.lcd0.brightness=100
 hw.acpi.video.lcd0.brightness: 45 - 100
 
 No brightness changes actually occur during this.


-- 
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

[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

[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

[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: Atom N270 - ACPI Error: [RTMP] Namespace lookup failure

[Andriy Gapon]

on 02/07/2011 05:16 Ed VanderPloeg said the following:
 
 # egrep '(^| )est' dmesg.8-release
 est0: Enhanced SpeedStep Frequency Control on cpu0
 est: CPU supports Enhanced Speedstep, but is not recognized.
 est: cpu_vendor GenuineIntel, msr 60f0c270600060f
 device_attach: est0 attach returned 6
 est1: Enhanced SpeedStep Frequency Control on cpu1
 est: CPU supports Enhanced Speedstep, but is not recognized.
 est: cpu_vendor GenuineIntel, msr 60f0c270600060f
 device_attach: est1 attach returned 6
 
 # egrep '(^| )est' dmesg.8-stable
 est0: Enhanced SpeedStep Frequency Control on cpu0
 est1: Enhanced SpeedStep Frequency Control on cpu1

So this was improved.  Thanks!

-- 
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

[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

[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: Atom N270 - ACPI Error: [RTMP] Namespace lookup failure

[Andriy Gapon]

on 01/07/2011 07:16 Ed VanderPloeg said the following:
 On 2011-06-30 1:59 PM, Andriy Gapon wrote:
 on 30/06/2011 19:32 Ed VanderPloeg said the following:
 I updated to 8-stable but am still getting ACPI error messages to console 
 every
 10 seconds.

 Just for my curiosity - has anything changed with respect to est driver
 attachment?
 
 I'm not sure what you mean by attachment.  With 8-stable now installed:
 
 stanbud# kldstat -v | grep est
 445 cpu/est
 
 Is there anything you would like me to check?

Yes, your dmesg (search for est).

-- 
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

[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

[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

[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

Re: paper on reverse-engineering drivers

[Andriy Gapon]

on 26/05/2011 22:25 Nate Lawson said the following:
 This might be a useful source for making ACPI compatible with Windows.
 
 http://dslab.epfl.ch/pubs/revnic
 
 I had thought of a project like this before. My idea was to take QEMU
 and map PCI config space and allow direct access to the bare hardware
 for only one device. The developer would install Windows in this QEMU
 image on a system with the target device, identify it by its PCI id, and
 then run Windows normally. The VM would log the driver's accesses to
 config space as well as use CoW semantics for DMA accesses to memory and
 IO ports.

Something like this?
http://www.serialice.com/News/News.html

 Now that Intel/AMD support hardware virtualization and DMA isolation, it
 would be better to do this with a modified Xen hypervisor.

-- 
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: acpi resources problem potentially because of new pcib code

[Andriy Gapon]

on 23/05/2011 11:12 Andriy Gapon said the following:
 
 John,
 
 it seems that possibly your recent changes for PCI bridges could have broken
 something for my old 440BX/PIIX4/PIII type test machine.
 Looks like now some I/O resources get assigned to a PCI bridge instead of 
 ACPI.
 
 Some highlights follow:
 ...
 acpi_timer0: couldn't allocate resource (port 0x4008)
 ...
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff,0x4000-0x4041,0x5000-0x500f on 
 acpi0
 ...
 device_attach: acpi_throttle0 attach returned 6
 
 More data here:
 http://people.freebsd.org/~avg/ms6163/
 
 I see that _CRS of the Host-PCI bridge indeed claims that 0x4000 range, so I
 realize that this is a BIOS bug, but I think that perhaps we could have some
 quirk there to leave this range to ACPI.

I fixed this for myself by creating a custom dsdt override where I moved the
following resource from _CRS of Device PCI0 (PNP0A03) to that of Device SYSR
(PNP0C02):

IO (Decode16,
0x4000, // Range Minimum
0x4000, // Range Maximum
0x01,   // Alignment
0x42,   // Length
)

Maybe this could help other people with similarly broken BIOSes.
I hope that not too many systems with that hardware survived to these days,
because it seems that almost all of them shared a lot of common bugs in their 
BIOS
(and good luck getting any fixes for those systems from their vendors now).

-- 
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: ACPI errors

[Andriy Gapon]

on 02/03/2011 13:12 Tom said the following:
 Hello,
 
 I have some strang errors in my dmesg.boot regarding ACPI, namely:
 
 ACPI Error: Field [I9MN] at 544 exceeds Buffer [IORT] size 464 (bits)
 (20100331/dsopcode-697) ACPI Error (psparse-0633): Method
 parse/execution failed [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node
 0xff0002693740), AE_AML_BUFFER_LIMIT ACPI Error (uteval-0318):
 Method execution failed [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node
 0xff0002693740), AE_AML_BUFFER_LIMIT can't fetch resources for
 \\_SB_.PCI0.LPC0.PMIO - AE_AML_BUFFER_LIMIT
 
 I was googling around in search of some hints as to what dose it all
 mean but couldn't find anything similar. Most common error I came
 across involved issues with batter - in my case booting with or without
 battery make no difference. Could some one please enlighten me as to
 what those errors are about and how I can get rid of them?

These look like reports about bugs in ASL.
Have you tried booting some recent Linux on this system?  Not sure if ACPI error
logging would be enabled there by default.  But it would be interesting if Linux
reports the same problems.

My opinion is that the mistake is most likely in the ASL, but it's possible that
there is something incorrect or untypical about how FreeBSD calls the ASL.

 I'm on 8.1 running generic amd64 kernel, verbose output from my
 dmesg.boot is here:
 
 http://dl.dropbox.com/u/11250432/dmesg.boot
 
 output from sysctl hw.acpi:
 
 http://dl.dropbox.com/u/11250432/hw.acpi
 
 and my ASL:
 
 http://dl.dropbox.com/u/11250432/TomPavilion_dv9702ea.asl
 
 I can't attache dmesg output with ACPI disabled as my machine is
 refusing to boot like that.
 And please ignore other errors in dmesg - I'm slowly making my way
 through them but as I'm very new to FreeBSD and *nix in general it will
 take some time.
 
 Thanks,
 
 
 Tom


-- 
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: Searching mentor for EFI support subject in project idea page

[Andriy Gapon]

on 15/02/2011 19:28 deloff_t said the following:
  Hi,
 
 I'm searching someone who can be a mentor on this subject (I would like to do 
 GSoC 2011, I'm trying to get ahead with EFI):
 Finish EFI support on the i386/amd64 ports. Final work should be able to 
 boot a FreeBSD kernel into single user mode, at least.
 
 I contacted Rui Paulo who was the contact but he's not longer available and 
 he suggests me to ask on mailing list.
 I think that its the most appropriate mailing list for my issue.
 
 I'm going to begin to search some documentations on EFI and boot process in 
 general.
 If you have some advices, they'll be welcome ! :)

Not sure if you picked the best mailing list.

-- 
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: amd64/144551: [acpi] ACPI issues on SuperMicro X7SPA-H

[Andriy Gapon]

The following reply was made to PR amd64/144551; it has been noted by GNATS.

From: Andriy Gapon a...@freebsd.org
To: bug-follo...@freebsd.org, dan.nau...@gmail.com
Cc:  
Subject: Re: amd64/144551: [acpi] ACPI issues on SuperMicro X7SPA-H
Date: Sun, 05 Dec 2010 16:13:28 +0200

 It's interesting question why the frequency at boot time is not the maximu
 frequency, but I suspect that it's more of a question to vendor/BIOS.
 
 Would you mind if I close this PR?
 
 -- 
 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