<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.os.freebsd.devel.acpi">
    <title>gmane.os.freebsd.devel.acpi</title>
    <link>http://blog.gmane.org/gmane.os.freebsd.devel.acpi</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7231"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7230"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7229"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7228"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7227"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7226"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7225"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7223"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7222"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7221"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7220"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7219"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7217"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7214"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7213"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7212"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7211"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7209"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7208"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7207"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7231">
    <title>Re: How can I help with thinkpad x220 issues?</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7231</link>
    <description>&lt;pre&gt;
About the key:

Did you try loading "acpi_ibm", "sysctl dev.acpi_ibm.0.events=1",
"cat /var/run/devd.pipe" and then press the keys. Does anything show up?
&lt;/pre&gt;</description>
    <dc:creator>Lars Engels</dc:creator>
    <dc:date>2012-05-24T06:55:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7230">
    <title>Re: How can I help with thinkpad x220 issues?</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7230</link>
    <description>&lt;pre&gt;
If it has not been committed, the minor fix to make acpi_ibm work on
modern ThinkPads needs to be committed. Once done, the issues
mentioned need to be addressed.This includes getting brightness to be
setable from both the keypad hot-keys and from applications. ATM, I
can set the brightness, but making the hot-keys work will require the
ability to extract the current level so that it may be adjusted
plus/minus one.

The other issue is volume control keys don't work. I suspect it will
be similar to brightness, but I don't know just how to figure it out.

I should also mention that I don't have an X220. I have a T520, but
the issues seem to be identical, so fixing one will probably fix a lot
of recent ThinkPads.
&lt;/pre&gt;</description>
    <dc:creator>Kevin Oberman</dc:creator>
    <dc:date>2012-05-23T22:19:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7229">
    <title>Re: How can I help with thinkpad x220 issues?</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7229</link>
    <description>&lt;pre&gt;
No. I got my X220 AFTER the suspend/resume was broken. There was a point, I
hear, during which it worked properly. I guess we are getting there.
FreeBSD 10 has some hopes for me, including Intel GEM/KMS patch in code and
some other goodies.

&lt;/pre&gt;</description>
    <dc:creator>Любомир Григоров</dc:creator>
    <dc:date>2012-05-23T17:28:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7228">
    <title>Re: How can I help with thinkpad x220 issues?</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7228</link>
    <description>&lt;pre&gt;
 &amp;gt; Good news is that Konstantin's latest patch works with FreeBSD 9-STABLE so
 &amp;gt; no longer need to run HEAD. I would love to see resume work, though.

I don't suppose your Thinkpad maybe one of those that resumes properly, 
from X or from a VTY, with sysctl hw.syscons.sc_no_suspend_vtswitch=1 ?

cheers, Ian
&lt;/pre&gt;</description>
    <dc:creator>Ian Smith</dc:creator>
    <dc:date>2012-05-23T17:25:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7227">
    <title>Re: How can I help with thinkpad x220 issues?</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7227</link>
    <description>&lt;pre&gt;Well, brightness works with the command line, sooo.... I think it has to be
mapped to the hardware keys. There is a long thread where I discussed this
with a couple other members (toward the bottom for the recent brightness
discussion).
http://comments.gmane.org/gmane.os.freebsd.current/135827

Good news is that Konstantin's latest patch works with FreeBSD 9-STABLE so
no longer need to run HEAD. I would love to see resume work, though.

Cheers.



&lt;/pre&gt;</description>
    <dc:creator>Любомир Григоров</dc:creator>
    <dc:date>2012-05-23T17:05:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7226">
    <title>How can I help with thinkpad x220 issues?</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7226</link>
    <description>&lt;pre&gt;Hello,

I happen to be the owner of a brand new Lenovo Thinkpad X220. From a
recent thread here I gather it almost works with FreeBSD, and the
remaining problems are screen brightness and screen left unpowered at
resume. Is that right?

So my question is, how can I help make progress in any of these area?
(though I admit I'm more interested in having the brightness problem
solved than the resume one)

I don't know anything about ACPI or about FreeBSD or Linux internals,
but I'm quite proficient in C and somewhat used to navigate in unknown
huge code bases.

So I guess the first steps to help would be to first learn stuff.

However I don't have much time available. I guess FreeBSD 11 would reach
end-of-life before I could reach a level of understanding I find
satisfying (though I admit I have high standards there), so I would have
to prioritize. So my question is rather *what* should I learn to provide
help as soon as possible?

For example, if the brightness issue is just a matter of extracting the
right numbers from linux kernel code and plug them into FreeBSD, I
probably won't need to learn anything more about ACPI than what I would
gather looking at the code. I guess if it was that simple someone would
have already done it, but that illustrate well my point about
prioritizing learning.

Or is the barrier of entry too high for me to be of any use?


Thanks in advance for your advice,
Natacha Porté
&lt;/pre&gt;</description>
    <dc:creator>Natacha Porté</dc:creator>
    <dc:date>2012-05-23T15:13:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7225">
    <title>Current problem reports assigned to freebsd-acpi&lt; at &gt;FreeBSD.org</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7225</link>
    <description>&lt;pre&gt;Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/164329  acpi       [acpi] hw.acpi.thermal.tz0.temperature shows strange v
o kern/163268  acpi       [acpi_hp] fix driver detach in absence of CMI
o kern/162859  acpi       [acpi] ACPI battery/acline monitoring partialy working
o kern/161715  acpi       [acpi] Dell E6520 doesn't resume after ACPI suspend
o kern/161713  acpi       [acpi] Suspend on Dell E6520
o kern/160838  acpi       [acpi] ACPI Battery Monitor Non-Functional
o kern/160419  acpi       [acpi_thermal] acpi_thermal kernel thread high CPU usa
o kern/158689  acpi       [acpi] value of sysctl hw.acpi.thermal.polling_rate ne
o kern/154955  acpi       [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3
o kern/152438  acpi       [acpi]: patch to acpi_asus(4) to add extra sysctls for
o kern/152098  acpi       [acpi] Lenovo T61p does not resume
o i386/146715  acpi       [acpi] Suspend works, resume not on a HP Probook 4510s
o kern/145306  acpi       [acpi]: Can't change brightness on HP ProBook 4510s
o i386/143798  acpi       [acpi] shutdown problem with SiS K7S5A
o kern/143420  acpi       [acpi] ACPI issues with Toshiba
o kern/142009  acpi       [acpi] [panic] Panic in AcpiNsGetAttachedObject
o kern/139088  acpi       [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error
o amd64/138210 acpi       [acpi] acer aspire 5536 ACPI problems (S3, brightness,
o kern/137042  acpi       [acpi] hp laptop's lcd not wakes up after suspend to r
o i386/136008  acpi       [acpi] Dell Vostro 1310 will not shutdown (Requires us
o bin/135349   acpi       [patch] teach acpidump(8) to disassemble arbitrary mem
o kern/132602  acpi       [acpi] ACPI Problem with Intel SS4200: System does not
p kern/128634  acpi       [patch] fix acpi_asus(4) in asus a6f laptop
o bin/126162   acpi       [acpi] ACPI autoload failed : loading required module 
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
a i386/122887  acpi       [panic] [atkbdc]  7.0-RELEASE on IBM HS20 panics immed
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/91594   acpi       [acpi] FreeBSD &amp;gt; 5.4 w/ACPI fails to detect Intel Pro/
o kern/73823   acpi       [request] acpi / power-on by timer support
o kern/56024   acpi       ACPI suspend drains battery while in S3

32 problems total.

&lt;/pre&gt;</description>
    <dc:creator>FreeBSD bugmaster</dc:creator>
    <dc:date>2012-05-21T11:07:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7223">
    <title>Re: ACPI 'driver bug: Unable to set devclass'</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7223</link>
    <description>&lt;pre&gt;
Not yet.  I'll try to test it later today unless someone beats me to it. :-P

&lt;/pre&gt;</description>
    <dc:creator>John Baldwin</dc:creator>
    <dc:date>2012-05-17T17:50:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7222">
    <title>Re: ACPI 'driver bug: Unable to set devclass'</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7222</link>
    <description>&lt;pre&gt;on 17/05/2012 17:05 John Baldwin said the following:

The patch has not been compile-tested? :)

&lt;/pre&gt;</description>
    <dc:creator>Andriy Gapon</dc:creator>
    <dc:date>2012-05-17T15:33:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7221">
    <title>Re: ACPI 'driver bug: Unable to set devclass'</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7221</link>
    <description>&lt;pre&gt;
I haven't been able to try this yet, but I have a first cut at
www.freebsd.org/~jhb/patches/acpi_cpu.patch

&lt;/pre&gt;</description>
    <dc:creator>John Baldwin</dc:creator>
    <dc:date>2012-05-17T14:05:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7220">
    <title>Re: ACPI 'driver bug: Unable to set devclass'</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7220</link>
    <description>&lt;pre&gt;
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.

&lt;/pre&gt;</description>
    <dc:creator>John Baldwin</dc:creator>
    <dc:date>2012-05-16T20:07:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7219">
    <title>You do not have much money? We offer a solution to - work in yourspare time in our company</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7219</link>
    <description>&lt;pre&gt;We invite you to work in the remote assistant position.

This work takes 2-3 hours per week and requires absolutely no investment.
The essence of this work for incoming client requests in your city.
The starting salary is about 2500 EUR per month + bonuses.

You get paid your salary every 2 weeks and your bonuses after fulfilling each task!

We guarantee work for everyone. But we accept applications this week only!
Therefore, you should write a request right now. And you will start earning money, starting from next week.

Please indicate in the request:
Your name:
Your email address:
City of residence:

Please send the request to my email Margarito&amp;lt; at &amp;gt;eureseurope.com and I will answer you personally as soon as possible

Sincerely,
Margarito Lacy

&lt;/pre&gt;</description>
    <dc:creator>jmz&lt; at &gt;freebsd.org</dc:creator>
    <dc:date>2012-05-16T19:26:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7217">
    <title>Re: ACPI 'driver bug: Unable to set devclass'</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7217</link>
    <description>&lt;pre&gt;
Yes.  The third step will see that unit 0 is already in use and shouldn't
reuse unit 0.

&lt;/pre&gt;</description>
    <dc:creator>John Baldwin</dc:creator>
    <dc:date>2012-05-16T14:50:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7214">
    <title>Re: ACPI 'driver bug: Unable to set devclass'</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7214</link>
    <description>&lt;pre&gt;on 15/05/2012 17:34 John Baldwin said the following:

Not sure what you disagree with...
First, the wildcard device is added to the child list during the walk.
Then, the unit 0 device is added to the list when acpi_timer identify is executed.
Then, the wildcard device is probed and gets unit number of zero.
Then, the fixed device is being probed and the unit number conflict arises.

Am I misunderstanding something?

&lt;/pre&gt;</description>
    <dc:creator>Andriy Gapon</dc:creator>
    <dc:date>2012-05-15T16:35:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7213">
    <title>Re: ACPI 'driver bug: Unable to set devclass'</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7213</link>
    <description>&lt;pre&gt;
Eh.  This should not be true.  The unit 0 is reserved when device_add_child()
is called in the acpi_timer identify routine.  The wildcard device will not be
assigned a unit number until device_probe_child time.


That is, the unit for the wildcard devices should still be -1 here and should not
even get to this message.

I wonder if this is related to the recent changes to set the unit number for CPUs?

&lt;/pre&gt;</description>
    <dc:creator>John Baldwin</dc:creator>
    <dc:date>2012-05-15T14:34:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7212">
    <title>Re: [CFT] SMP/i386 suspend/resume</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7212</link>
    <description>&lt;pre&gt;
On 2012-May-13 22:53:28 +0900, Mitsuru IWASAKI &amp;lt;iwasaki&amp;lt; at &amp;gt;jp.FreeBSD.org&amp;gt; wrote:

I've tried stable/9 r235399 with your patches as well as
PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND and suspend/resume now works
(for the first time) from VTY.  I haven't tried suspending directly
from X but expect that is still broken.  Thank you very much.

&lt;/pre&gt;</description>
    <dc:creator>Peter Jeremy</dc:creator>
    <dc:date>2012-05-15T07:30:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7211">
    <title>Re: [CFT] SMP/i386 suspend/resume</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7211</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-05-14 00:16:17 -0400, Mitsuru IWASAKI wrote:

First of all, thank you very much for your work!  I wanted to do it
for very long time but I had no time to actually implement it. :-)


I know for sure it is not related to your patches.  In fact, we cannot
resume most NVIDIA controllers without NVIDIA kernel driver + binary
X.org driver + VT switching hack (i.e.,
hw.syscons.sc_no_suspend_vtswitch=0, which is default).  Also, there
is ACPI_PM option for ports/x11/nvidia-driver but it doesn't help much
because it doesn't seem to save/restore GPU registers by itself (off
by default).  Very few NVIDIA controllers can be reset with BIOS POST
or saved/restored with VBE functions.  Many Intel controllers have
similar issues and they need kib's KMS driver.  Usually, ATI/AMD
controllers have no problem when (relatively recent) vesa.ko is
compiled into kernel or loaded as module as they have complete VBE
save/restore functions.  Similarly, any video controllers with correct
save/restore functions should work with vesa.ko.


FYI, we don't need hw.acpi.reset_video any more (and it is even
harmful).  It is done from vesa.ko now.


Most of these Linux hacks are completely obsolete since KMS.  I really
don't want to reiterate Linux mistakes again.

Jung-uk Kim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+xRvcACgkQmlay1b9qnVP1NwCfVPMz1YhvUcyyhWkQjs4JZdgd
B0gAoKuv4ST+N7FInyfaMwMYuFe4AfNx
=jk3/
-----END PGP SIGNATURE-----
&lt;/pre&gt;</description>
    <dc:creator>Jung-uk Kim</dc:creator>
    <dc:date>2012-05-14T17:55:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7209">
    <title>Current problem reports assigned to freebsd-acpi&lt; at &gt;FreeBSD.org</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7209</link>
    <description>&lt;pre&gt;Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/164329  acpi       [acpi] hw.acpi.thermal.tz0.temperature shows strange v
o kern/163268  acpi       [acpi_hp] fix driver detach in absence of CMI
o kern/162859  acpi       [acpi] ACPI battery/acline monitoring partialy working
o kern/161715  acpi       [acpi] Dell E6520 doesn't resume after ACPI suspend
o kern/161713  acpi       [acpi] Suspend on Dell E6520
o kern/160838  acpi       [acpi] ACPI Battery Monitor Non-Functional
o kern/160419  acpi       [acpi_thermal] acpi_thermal kernel thread high CPU usa
o kern/158689  acpi       [acpi] value of sysctl hw.acpi.thermal.polling_rate ne
o kern/154955  acpi       [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3
o kern/152438  acpi       [acpi]: patch to acpi_asus(4) to add extra sysctls for
o kern/152098  acpi       [acpi] Lenovo T61p does not resume
o i386/146715  acpi       [acpi] Suspend works, resume not on a HP Probook 4510s
o kern/145306  acpi       [acpi]: Can't change brightness on HP ProBook 4510s
o i386/143798  acpi       [acpi] shutdown problem with SiS K7S5A
o kern/143420  acpi       [acpi] ACPI issues with Toshiba
o kern/142009  acpi       [acpi] [panic] Panic in AcpiNsGetAttachedObject
o kern/139088  acpi       [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error
o amd64/138210 acpi       [acpi] acer aspire 5536 ACPI problems (S3, brightness,
o kern/137042  acpi       [acpi] hp laptop's lcd not wakes up after suspend to r
o i386/136008  acpi       [acpi] Dell Vostro 1310 will not shutdown (Requires us
o bin/135349   acpi       [patch] teach acpidump(8) to disassemble arbitrary mem
o kern/132602  acpi       [acpi] ACPI Problem with Intel SS4200: System does not
p kern/128634  acpi       [patch] fix acpi_asus(4) in asus a6f laptop
o bin/126162   acpi       [acpi] ACPI autoload failed : loading required module 
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
a i386/122887  acpi       [panic] [atkbdc]  7.0-RELEASE on IBM HS20 panics immed
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/91594   acpi       [acpi] FreeBSD &amp;gt; 5.4 w/ACPI fails to detect Intel Pro/
o kern/73823   acpi       [request] acpi / power-on by timer support
o kern/56024   acpi       ACPI suspend drains battery while in S3

32 problems total.

&lt;/pre&gt;</description>
    <dc:creator>FreeBSD bugmaster</dc:creator>
    <dc:date>2012-05-14T11:07:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7208">
    <title>Re: [CFT] SMP/i386 suspend/resume</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7208</link>
    <description>&lt;pre&gt;

Tested on:
* i386 9.0-STABLE FreeBSD 9.0-STABLE #3 r234558M: Mon May 14 00:46:28 MSK 2012
* Lenovo Ideapad Y550P
* x11/nvidia-driver
* pciconf:
vgapci0&amp;lt; at &amp;gt;pci0:1:0:0:     class=0x030000 card=0x38cd17aa chip=0x0a3410de 
rev=0xa2 hdr=0x00
    vendor     = 'nVidia Corporation'
    device     = 'GT216 [GeForce GT 240M]'
    class      = display
    subclass   = VGA
* sysctl:
hw.nvidia.version: NVIDIA UNIX x86 Kernel Module  295.49  Mon Apr 30 23:45:17 
PDT 2012
hw.model: Intel(R) Core(TM) i3 CPU       M 330  &amp;lt; at &amp;gt; 2.13GHz

acpiconf -s3 tested 3 times, last one full success (suspend/restore), other 2 
less flawless - X or terminal stalled after restoration.

acpiconf -s4 tested 1 time with fail.

Requesting any rc.conf/sysctl.conf/other configuration for smooth 
suspend/restore.

Anyway, this is HUGE success for FBSD.

&lt;/pre&gt;</description>
    <dc:creator>Dmitry Kolosov</dc:creator>
    <dc:date>2012-05-14T10:54:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7207">
    <title>Re: [CFT] SMP/i386 suspend/resume</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7207</link>
    <description>&lt;pre&gt;
   What follows was still done with your patch there.

   First, I tried with acpi_bounce. I saw this on dmesg:

      vgapci0: calling BIOS POST

   I also tried the complete suspend/resume without the nvidia blob. The 
machine showed the same behavior; it came online after suspending. 
Everything working but the video.

   After the suspend/resume cycle and w/o the nvidia blob, I tried to 
ssh it. The screen was completely black. After logging in, I kldload'ed 
the nvidia blob and tried to start X. I got a panic (I was unable to 
read it) and a core after rebooting. The relevant part was:

*************************************************
Unread portion of the kernel message buffer:
NVRM: failed to copy vbios to system memory.
NVRM: RmInitAdapter failed! (0x30:0xffffffff:858)
nvidia0: NVRM: rm_init_adapter() failed!

*************************************************

   So I would say the bios is doing something during the suspend/resume 
cycle. I would say the nvidia module knows to handle this, but the 
module must be loaded before the first suspend/resume cycle. That would 
explain why it works with X running. That would also somehow explain why 
I can resume while working with ttyv1 having X working on ttvy9 
(remember, in that case I had to vidcontrol -s 9 &amp;lt; /dev/console to get 
my screen back online). I'm just guessing.

   Could it be that


   I tried smp disabled on boot (kern.smp.disabled=1) and failed the 
same way.

   I'm compiling w/o your patch (will take it a while) but I guess it 
will do worst. Last time I tried, when 9 was head, it did not resume at 
all.


    Could this all be an ASL problem?
    Thanks,

    Gus

&lt;/pre&gt;</description>
    <dc:creator>Gustau Perez Querol</dc:creator>
    <dc:date>2012-05-14T07:49:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7206">
    <title>Re: [CFT] SMP/i386 suspend/resume</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.acpi/7206</link>
    <description>&lt;pre&gt;Hi,


Yes, if it doesn't bother you.
Hmmm, it doesn't seem related with my SMP/i386 sleep patches.
Could you try also Uni-processer kernel (w/o SMP and apic from config
file) without my patches?


We can improve video initialization on another opportunity.
Linux have many video hacks while we have only hw.acpi.reset_video ;)
http://www.kernel.org/doc/Documentation/power/video.txt
I believe there are some solutions for you in this document, then
we can implement them in our source if found.

Thanks
&lt;/pre&gt;</description>
    <dc:creator>Mitsuru IWASAKI</dc:creator>
    <dc:date>2012-05-14T04:16:17</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.os.freebsd.devel.acpi">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.os.freebsd.devel.acpi</link>
  </textinput>
</rdf:RDF>

