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
On Tue, 2012-06-19 at 22:00 -0700, Andriy Gapon wrote:
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
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
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
On Wed, 2012-06-27 at 05:12 -0700, John Baldwin wrote:
On Tuesday, June 26, 2012 8:23:23 pm Sean Bruno wrote:
Ok, version 2 now in effect. I removed the return of BUS_PROBE_DEFAULT
and this seems to do the right thing in the cases I have.
If there are no objections to this, I'll chuck
http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt
Some sort of a review...
First, going over what seems to be cosmetic changes in the patch.
The change to etc/rc.d/power_profile seems to be a NOP, is it needed?
Ugh, well ... this was *supposed* to be a change to
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
On Tue, 2012-07-10 at 07:27 -0700, Ian Smith wrote:
I wonder if that explains why setting C3 on aforesaid T23 has no
effect
(in terms of dev.cpu.0.cx_usage indicating any time spent in C3)
unless
the machine happened to be booted up on battery, in which case C3 is
shown as working
The new Dell machines are doing a lot more of outstanding ACPI things
currently. So much in fact, that they are exceeding ACPI_MAX_TASKS and
are throwing errors indicating thing:
snip
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on
isa0
AcpiOsExecute: failed to enqueue task,
On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote:
I am currently running with a value of 128 and doing a bit of
testing.
I think it should be something like MAX(32, MAXCPU).
Ah, that sounds WAY more reasonable. I shall test thusly.
Sean
On Tue, 2012-08-07 at 14:30 -0700, John Baldwin wrote:
On Tuesday, August 07, 2012 2:43:17 pm Sean Bruno wrote:
On Tue, 2012-07-31 at 09:13 -0700, Sean Bruno wrote:
On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote:
I am currently running with a value of 128 and doing a bit
On Wed, 2012-08-08 at 04:25 -0700, John Baldwin wrote:
I meant that with the limit jacked up to something that silences the
warning
(such as 128), what is the max number of tasks queued?
I set debug.acpi.max_tasks=128 and added a temp log message to
acpi_task_enqueue(). I see the system
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
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
Finally got around to returning the Dell R620 series BIOS update that
breaks badly on FreeBSD. I suspect that there is an ACPI update going
on here that I need to figure out for -current. I'm going to disable
the pci bus that fails to attach via device hints and get an acpidump in
a bit.
pcib4:
On Tue, 2012-12-11 at 10:13 -0800, Sean Bruno wrote:
Finally got around to returning the Dell R620 series BIOS update that
breaks badly on FreeBSD. I suspect that there is an ACPI update going
on here that I need to figure out for -current. I'm going to disable
the pci bus that fails
On Wed, 2013-03-06 at 16:01 -0800, Robert wrote:
Greetings
Please CC me as I am not on this list.
I was given a Toshiba L505D-LS5010 laptop I tried to load FreeBSD 9.1
from Cd but got the following message (hand copied from picture):
ACPI ERROR: [RSF] Namespace lookup failure,
Been trying to get ACPI Debugging working via
http://www.freebsd.org/doc/handbook/acpi-debug.html and am not getting
any output.
We've compiled with options ACPI_DEBUG, set
debug.acpi.enable_debug_objects, debug.acpi.layer=ACPI_ALL_DRIVERS and
debug.acpi.level=ACPI_LV_VERBOSE
I'm not sure
On Tue, 2013-08-20 at 19:20 +, Moore, Robert wrote:
We have seen at least one video vendor that uses a Buffer object
instead of the ACPI-required package object as the 4th _DSM argument.
The T520 has a Nvidia thingy in it. Is this something we need to deal
with in the BSD ACPI
On Mon, 2013-11-11 at 16:47 -0500, Jung-uk Kim wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-11-11 16:31:30 -0500, Jung-uk Kim wrote:
On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote:
On 11 November 2013 12:00, Jung-uk Kim j...@freebsd.org wrote:
-BEGIN PGP SIGNED
On Mon, 2013-11-11 at 16:47 -0500, Jung-uk Kim wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-11-11 16:31:30 -0500, Jung-uk Kim wrote:
On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote:
On 11 November 2013 12:00, Jung-uk Kim j...@freebsd.org wrote:
-BEGIN PGP SIGNED
On Wed, 2013-11-13 at 18:35 -0500, Jung-uk Kim wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-11-13 18:21:37 -0500, Adrian Chadd wrote:
On 11 November 2013 13:47, Jung-uk Kim j...@freebsd.org wrote:
Just in case, here I attached the uncommitted (and untested)
patch.
getting invoked, I assume that its because of
a variance in ACPI parsing of the relevant IPMI section.
sean
On Fri, Apr 11, 2014 at 8:08 PM, Sean Bruno sbr...@ignoranthack.me
wrote:
On Fri, 2014-04-11 at 07:47 +0400, venom wrote:
ppc1: cannot reserve I/O port range
On Sun, 2014-05-04 at 13:51 -0700, Adrian Chadd wrote:
I've tested it (-HEAD) on:
* T43
* T60
* T60p
* T400
* T500
* T420
* X220
I'm actively using the T60, T400 and X220 right now.
T520, just works. Has for a while. I suspect disabling firewire and
the eSATA port helps quite a
I found sys/dev/acpica/acpi_throttle.c today. Should I have this
removed from a standard laptop configuration? I would think I would
want the system to throttle itself when appropriate. Is this an older
way of doing something like C-states or have I missed something?
sean
On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote:
On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote:
Trying to figure out the failures on suspend resume for the T61 I have.
I see a little acpi error at host startup, but I don't think its
related. However, I'm not sure what it means
On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote:
On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote:
On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote:
On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote:
Trying to figure out the failures on suspend resume for the T61 I have
On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-05-28 17:29:35 -0400, John Baldwin wrote:
Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a
length of zero (and is thus invalid)?
BTW, ACPI 5.0a (page 121)
On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote:
Hi,
Please also document why it is/isn't working. It's only documented as
suspend/resume doesn't work :)
-a
Well there's this that trasz updated to indicate that it works:
https://wiki.freebsd.org/SuspendResume
I just updated this
29 matches
Mail list logo
