On Saturday 16 February 2008 00:42, Len Brown wrote:
> > drivers/acpi/executer/exregion.c: In function
> > 'acpi_ex_pci_config_space_handler':
> > drivers/acpi/executer/exregion.c:369: warning: passing argument 3 of
> > 'acpi_os_read_pci_configuration' from incompatible pointer type
Subject: AC
: GPE=0x10, ports=0x66, 0x62
[0.584000] ACPI: System BIOS is requesting _OSI(Linux)
[0.584000] ACPI: Please test with "acpi_osi=!Linux"
[0.584000] Please send dmidecode to linux-acpi@vger.kernel.org
...
# dmidecode 2.9
SMBIOS 2.4 present.
20 structures occupying 822 bytes
On Saturday, 16 of February 2008, Len Brown wrote:
> yeah, i know.
>
> Linus personally created this one last week.
>
> We're waiting for him to cool off before we re-suggest a patch that actually
> works:-)
Well, perhaps something like the appended one?
Thanks,
Rafael
---
arch/x86/kernel/a
yeah, i know.
Linus personally created this one last week.
We're waiting for him to cool off before we re-suggest a patch that actually
works:-)
-Len
On Friday 15 February 2008 23:47, Andrew Morton wrote:
> arch/x86/kernel/acpi/sleep.c: In function 'acpi_save_state_mem':
> arch/x86/kernel/acpi
arch/x86/kernel/acpi/sleep.c: In function 'acpi_save_state_mem':
arch/x86/kernel/acpi/sleep.c:55: warning: passing argument 1 of
'native_store_gdt' from incompatible pointer type
arch/x86/kernel/acpi/sleep.c:71: warning: assignment makes integer from pointer
without a cast
arch/x86/kernel/acpi/sl
On Wed, Feb 06, 2008 at 11:18:50PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 07 Feb 2008, Roel Kluin wrote:
> > It's a oneliner and the patch is from linus' tree.
>
> Roel, better to just let me and Len Brown handle it. I will add your patch
> to my thinkpad-acpi queue and send it to Le
f (level & TP_EC_FAN_FULLSPEED)
> > > level |= 7; /* safety min speed 7 */
> > > else if (level & TP_EC_FAN_FULLSPEED)
> > > level |= 4; /* safety min speed 4 */
> > >
> > >
On Thu, Feb 07, 2008 at 12:48:24AM +0100, Roel Kluin wrote:
> Greg KH wrote:
> > On Tue, Feb 05, 2008 at 09:34:54AM +0100, Roel Kluin wrote:
> >> Henrique de Moraes Holschuh wrote:
> >>> On Tue, 05 Feb 2008, Roel Kluin wrote:
> >>>> Roland Dreier wro
On Thu, 07 Feb 2008, Roel Kluin wrote:
> It's a oneliner and the patch is from linus' tree.
Roel, better to just let me and Len Brown handle it. I will add your patch
to my thinkpad-acpi queue and send it to Len soon, along with other simple
patches that are pending. Either I or Len will notify
Greg KH wrote:
> On Tue, Feb 05, 2008 at 09:34:54AM +0100, Roel Kluin wrote:
>> Henrique de Moraes Holschuh wrote:
>>> On Tue, 05 Feb 2008, Roel Kluin wrote:
>>>> Roland Dreier wrote:
>>>>> > Note the duplicate test 'if (level & T
vel & TP_EC_FAN_FULLSPEED)
> >>> > level |= 4; /* safety min speed 4 */
> >>> >
> >>> > Note the duplicate test 'if (level & TP_EC_FAN_FULLSPEED)'. should
> >>> > this be replaced by
> >>&g
On Tuesday 05 February 2008 07:03:23 pm Carlos Corbacho wrote:
> On Wednesday 06 February 2008 00:35:54 Bjorn Helgaas wrote:
> > > Ok. The only other vendors I really have in mind are HP and Fujitsu,
> > > since both those vendors use WMI on their laptops, so they would be my
> > > most likely cand
On Wednesday 06 February 2008 00:35:54 Bjorn Helgaas wrote:
> > Ok. The only other vendors I really have in mind are HP and Fujitsu,
> > since both those vendors use WMI on their laptops, so they would be my
> > most likely candidates to have WMI on an IA64 box (if anyone actually
> > does use WMI
On Tuesday 05 February 2008 02:18:01 pm Carlos Corbacho wrote:
> On Tuesday 05 February 2008 21:03:30 Len Brown wrote:
> > On Monday 04 February 2008 21:16, Carlos Corbacho wrote:
> > > 2) Do you know of any IA64 systems using ACPI-WMI? At the moment, WMI
> > > will work on x86 and hopefully IA64,
rom the
second WMI series; or I can send another patch out later on top of this
series to do this, once you replace the old patches in acpi-test - whichever
is easiest for you)
-Carlos
--
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
-
To unsubscribe from this li
On Monday 04 February 2008 21:16, Carlos Corbacho wrote:
> 2) Do you know of any IA64 systems using ACPI-WMI? At the moment, WMI will
> work
> on x86 and hopefully IA64, but if it turns out that no vendor has or ever will
> implement ACPI-WMI on IA64, then we could safely drop it there.
I recomm
if (level & TP_EC_FAN_FULLSPEED)
>>> > level |= 7; /* safety min speed 7 */
>>> > else if (level & TP_EC_FAN_FULLSPEED)
>>> > level |= 4; /* safety min speed 4 */
>>
t; > > level |= 7; /* safety min speed 7 */
> > > else if (level & TP_EC_FAN_FULLSPEED)
> > > level |= 4; /* safety min speed 4 */
> > >
> > > Note the duplicate test '
Len,
These patches replace the previous five you have in acpi-test - due to the
changes to patch #2 (the sysfs support), and some other problems that turned
up in some extra testing with it, I'd prefer if you replace the original patch
series with this one.
Any further patches can then s
7; /* safety min speed 7 */
> > else if (level & TP_EC_FAN_FULLSPEED)
> > level |= 4; /* safety min speed 4 */
> >
> > Note the duplicate test 'if (level & TP_EC_FAN_FULLSPEED)'. should
> > this be replaced by
&
ed 7 */
else if (level & TP_EC_FAN_FULLSPEED)
level |= 4; /* safety min speed 4 */
note the nonsense duplicate test 'if (level & TP_EC_FAN_FULLSPEED)'.
should this be changed to:
if (level & TP_EC_FAN_FULLSPEED)
else if (level & TP_EC_FAN_FULLSPEED)
> level |= 4; /* safety min speed 4 */
>
> Note the duplicate test 'if (level & TP_EC_FAN_FULLSPEED)'. should
> this be replaced by
Actually I suspect one of the two tests should be against TP_EC_FAN_A
ed 7 */
else if (level & TP_EC_FAN_FULLSPEED)
level |= 4; /* safety min speed 4 */
Note the duplicate test 'if (level & TP_EC_FAN_FULLSPEED)'. should
this be replaced by
if (level & TP_EC_FAN_FULLSPEED)
> For future patches - do you want me to resend them, or send you incremental
> patches against what is currently in your tree?
I can handle either way,
but if they are revisions of the existing patches rather
than adding additional logically independent changes,
then it is cleaner to re-send th
t of tree in the hopes of shipping something more
> final in the first shot.
The main problem with the sysfs interface is that, unlike the kernel one,
there are no real users yet.
I have a hacked together test application which does some basic read/ write to
sysfs, but that's about it.
Hi Carlos,
Thanks for your persistence.
I've included this patch series to the acpi-test branch.
I think the indication of success of this effort will be
other people writing drivers to do useful things with
the WMI hooks you are exposing. So we certainly want to
get the base driver out
Len,
Can you please review, and hopefully apply, at least the first two patches in
this series, as I would like to get them into acpi-test (then -mm and eventually
2.6.26-rc1).
It's a little late now to put these into 2.6.25-rc1, and I don't want to
miss another merge window - so
On Monday 12 November 2007 11:19, Chris Dennis wrote:
> System Information
> Manufacturer: Acer
> Product Name: TravelMate 7510
thanks for the two dmesg, but nothing jumps out at me there.
With 2.6.22, did you notice any _functional_ difference with "acpi_osi=!Linux"?
(or since t
Hi,
In my Dmesg I see "Please send dmidecode to
linux-acpi@vger.kernel.org" so I do... I hope this can help you :-) . I
try with "acpi_osi=!Linux" but I have the same Dmesg after reboot. If
you want more informations you can contact me vithout hesitation.
++
# dmidecode 2.9
SMBIOS 2.4 p
Hi,
This series of patches adds a new testing facility for suspend and hibernation.
The first patch adds the possibility to test the suspend (STD) core code
without actually suspending, which is useful for tracking problems with drivers
etc.
The second one modifies the hibernation core so that
I am on Ubuntu Gutsy amd64(2.6.22-14-generic).
Tested with "acpi_osi=!Linux", I am sending dmidecod attached.
regards,
SJY
# dmidecode 2.9
SMBIOS 2.4 present.
37 structures occupying 1293 bytes.
Table at 0x000F0420.
Handle 0xDA00, DMI type 218, 131 bytes
OEM-specific Type
Header and
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Here are the patches currently on the ACPI test branch
(above the handful just send on the release branch)
that are candidates for 2.6.24.
I'm sure I mised some, and I may have a couple that are
not the latest versions sent to me -- that is the fun
I get to sort out on Monday.
Note that cp
Hi!
> > > (This should efficiently be the same as the proposed big patch a year
> > > ago from Pekka Enberg, just a bit smaller and should make ACPICA and
> > > kernel/linux people happy:
> > > http://marc.info/?l=linux-kernel&m=113699535303722&w=2)
> >
> > No, you're keeping these obfuscating ma
ss to Intel hardware,
I became so alarmed at these failures that I purchased an HP nx2125
and an HP nx6325 to figure out what the HP BIOS developers were thinking.
The nx6325 is now working perfectly -- I test kernels on it almost every day.
The nx6125 is for Alexy, but unfortunately, it seems to b
-
> > 6 | 1717(+64.0%) | 1494(+42.6%) |1047 (100%) |1046 (-0.10%)
> > ---
> > All measured values are in us. TSC was used to obtain the values.
On Thursday 31 May 2007 14:57, Pekka Enberg wrote:
> On 5/31/07, Thomas Renninger <[EMAIL PROTECTED]> wrote:
> > (This should efficiently be the same as the proposed big patch a year
> > ago from Pekka Enberg, just a bit smaller and should make ACPICA and
> > kernel/linux people happy:
> > http://m
On 5/31/07, Thomas Renninger <[EMAIL PROTECTED]> wrote:
(This should efficiently be the same as the proposed big patch a year
ago from Pekka Enberg, just a bit smaller and should make ACPICA and
kernel/linux people happy:
http://marc.info/?l=linux-kernel&m=113699535303722&w=2)
No, you're keepin
-
> All measured values are in us. TSC was used to obtain the values.
> do_gettimeofday did only provide valid values after hpet got setup
> (after pci_link).
>
> I wonder why only the short time taking measures show that extreme
>
I_DEBUG without function trace, you get
about +5 ms boot time (which may vary from machine to machine...).
This should be acceptable for test and develop kernels.
If nothing bad happens in Beta phase I'd like to include this one into
the final OpenSUSE kernel to get detailed bug reports.
It would
On Thu, 2007-03-29 at 14:56 +0800, Luming Yu wrote:
> why do you think so?
>
> On 3/29/07, Conke Hu <[EMAIL PROTECTED]> wrote:
> > my mail does not work ?
> >
It seems OK:)
Pls just ignore or delete the message.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body
why do you think so?
On 3/29/07, Conke Hu <[EMAIL PROTECTED]> wrote:
my mail does not work ?
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscrib
my mail does not work ?
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Len,
After you have updated to the latest linus tree, please pull from:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test
to receive the following patches:
ACPI: ibm-acpi: kill trailing whitespace
ACPI: ibm-acpi: rename some identifiers
Sergio Monteiro Basto wrote:
On Fri, 2007-03-09 at 23:00 -0500, Len Brown wrote:
These patches are in test for Linux-2.6.22.
Since we have big changes on ACPI for 2.6.21 , why we don't test all at
once (why we don't also include this on 6.21) ?
Best regards,
Because
On Fri, 2007-03-09 at 23:00 -0500, Len Brown wrote:
> These patches are in test for Linux-2.6.22.
>
Since we have big changes on ACPI for 2.6.21 , why we don't test all at
once (why we don't also include this on 6.21) ?
Best regards,
--
Sérgio M. B.
smime.p7s
Des
On Sun, 11 Mar 2007, Len Brown wrote:
> > Please merge them into acpi-test, targetting 2.6.22.
>
> series applied to acpi-test.
Thanks.
> BTW. do you have a plan for moving this driver to drivers/misc?
Whenever you want to. Would you like me to prepare patches for acpi-test,
ta
On Sunday 11 March 2007 20:20, Henrique de Moraes Holschuh wrote:
> Len,
>
> Please pull from:
> git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> branch for-upstream/acpi-test
>
> to receive the following patches:
> ACPI: ibm-acpi: kill trailing whit
Len,
Please pull from:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test
to receive the following patches:
ACPI: ibm-acpi: kill trailing whitespace
ACPI: ibm-acpi: rename some identifiers
ACPI: ibm-acpi: add header file
ACPI: ibm
These patches are in test for Linux-2.6.22.
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git test
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
These patches are on the test branch of the acpi tree
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git test
They are candidates for Linux-2.6.22
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message
* 2) We want to disable all wake GPEs, since we are now awake
>*/
> + acpi_gbl_system_awake_and_running = TRUE;
> (void)acpi_hw_disable_all_gpes();
> }
Acked-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
The above patc
Here is the patch
Regards,
Alex.
Henrique de Moraes Holschuh wrote:
On Thu, 08 Feb 2007, Alexey Starikovskiy wrote:
first thing to check is timing of acpi_hw_disable_all_gpes() at
drivers/acpi/events/evgpe.c:647,
printk() around it should be good.
Done, and the thing is looping l
t;Subject: Re: Bad libata resume behaviour due to ACPICA change (in acpi-
>test)
>
>On Thu, 08 Feb 2007, Starikovskiy, Alexey Y wrote:
>> Please also try to set acpi_gbl_system_awake_and_running to true in
the
>> same place, if you find that disable_all_gpes() is called
On Thu, 08 Feb 2007, Starikovskiy, Alexey Y wrote:
> Please also try to set acpi_gbl_system_awake_and_running to true in the
> same place, if you find that disable_all_gpes() is called not once...
Here's what happens if I "acpi_gbl_system_awake_and_running = true;" right
after the call to acpi_hw_
On Thu, 08 Feb 2007, Alexey Starikovskiy wrote:
> first thing to check is timing of acpi_hw_disable_all_gpes() at
> drivers/acpi/events/evgpe.c:647,
> printk() around it should be good.
Done, and the thing is looping like heck, and wasting time:
Feb 9 00:23:44 thorin kernel: Stopping tasks ...
2007 8:51 PM
>To: Henrique de Moraes Holschuh
>Cc: Starikovskiy, Alexey Y; linux-acpi@vger.kernel.org; Brown, Len
>Subject: Re: Bad libata resume behaviour due to ACPICA change (in acpi-
>test)
>
>first thing to check is timing of acpi_hw_disable_all_gpes() at
>drivers/ac
first thing to check is timing of acpi_hw_disable_all_gpes() at
drivers/acpi/events/evgpe.c:647,
printk() around it should be good.
Henrique de Moraes Holschuh wrote:
On Mon, 05 Feb 2007, Starikovskiy, Alexey Y wrote:
I cannot reproduce your problem with T43 here on linux-acpi-test with
On Mon, 05 Feb 2007, Starikovskiy, Alexey Y wrote:
> I cannot reproduce your problem with T43 here on linux-acpi-test with
> defconfig (relevant ACPI modules were tried both dynamic and static).
> Resume time is about 4-6 seconds, not 20-40 as you mention.
> Could you please send your
e to ACPICA change (in acpi-
>test)
>
>On Mon, 05 Feb 2007, Starikovskiy, Alexey Y wrote:
>> I cannot reproduce your problem with T43 here on linux-acpi-test with
>> defconfig (relevant ACPI modules were tried both dynamic and static).
>> Resume time is about 4-6 second
On Mon, 05 Feb 2007, Starikovskiy, Alexey Y wrote:
> I cannot reproduce your problem with T43 here on linux-acpi-test with
> defconfig (relevant ACPI modules were tried both dynamic and static).
> Resume time is about 4-6 seconds, not 20-40 as you mention.
Never tried a thinkpad in defco
Henrique,
I cannot reproduce your problem with T43 here on linux-acpi-test with
defconfig (relevant ACPI modules were tried both dynamic and static).
Resume time is about 4-6 seconds, not 20-40 as you mention.
Could you please send your .config and try defconfig on your machine?
BTW, my T43 use
On an otherwise ordinary ThinkPad T43, v2.6.20-rc7-g190ff5b runs and works
beaufully, however if I apply the acpi-test patches, it adds a 40-50s pause
right after libata tries to resume the disks.
Here's the relevant info:
1. The relevant detail of logs of a normal resume:
Feb 1 20:50:02 t
With Rui's patch below, I've merged sysfs back into the main test branch in the
acpi git tree.
As usual, the test branch is also available as a plain patch:
http://ftp.kernel.org:/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.20/acpi-test-20060707-2.6.20-rc1.diff.gz
thanks
Please pull from the ibm-acpi-devel git tree at:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test, to receve this patch series.
This series contains just one patch that was dropped from acpi-test
for some unknown reason. It is the same patch I submitted
better? I believe it
> > should resolve both the oops and the fact that your devices behind the
> > pci bridge are not found. Thanks very much for continuing to test the
> > patches.
>
> after adding acpi-dock-driver-acpi_get_device_fix.patch the Oops is
> truly gone, alth
ehind the
> pci bridge are not found. Thanks very much for continuing to test the
> patches.
after adding acpi-dock-driver-acpi_get_device_fix.patch the Oops is
truly gone, although the current behaviour seems dangerous to me. AFAIR
the undock button causes the disk to spin down and the
it
should resolve both the oops and the fact that your devices behind the
pci bridge are not found. Thanks very much for continuing to test the
patches.
Kristen
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More ma
led
>several updates to GNOME. Probably not related, but who knows?
>
>
>Anyway, here's the output of the abat tests.
Thanks, I tried to use non-root to run, failed too, it seems some
commands invoked by test case need root privilege.
>I now note that the tests apparently left
ora Core release 5 (Bordeaux)
Kernel \r on an \m
Linux tfr 2.6.16-1.2080_FC5 #1 Tue Mar 28 03:38:34 EST 2006 i686 i686
i386 GNU/Linux
***
* Test ACPI file system in
On Tuesday 18 April 2006 00:53, Yu, Ling L wrote:
> >I thought you should know that this test suite hung my laptop,
> >forcing a complete power off to recover.
> >
> Thanks for your test; could you send me the "lsmod" output?
No problem; attached.
> >Here&#x
This is the test results for my laptop:
http://www.nephila.it/~yakky/acpitest0.1_v6v_ia32_2.6.17-rc1_testresults
Hardware Platform: Asus V6V
Kernel: 2.6.17-RC1
I executed the tests with acpid disabled and no X
--
Regards
IS
Iacopo Spalletti
PGP key block: http://www.spalletti.it/pgp
>I thought you should know that this test suite hung my laptop, forcing
a
>complete power off to recover.
>
Thanks for your test; could you send me the "lsmod" output?
>Here's where it hung: (I got this by running the test suite as a n
On Monday 17 April 2006 22:18, Yu, Ling L wrote:
> All
> I and Kexin Zhang wrote some ACPI function test suite, please download
> it from
> http://acpi.sourceforge.net/validation/testcases/acpi-test-0.1.tar.gz
> (which also includes the ABAT0.2 I published before)
I thought you s
ACPI ABAT test results on HP nx6130, delivered by James, [EMAIL PROTECTED]
Date: 2006/4/17
Hardware Platform: HP nx6130
Kernel & patches: Kernel 2.6.14 + suspend2 patch
(http://www.suspend2.net/downloads/all/suspend2-2.2-rc13-for-2.6.14.tar.bz2)
Test Cases: ABAT 0.2
(
All
I and Kexin Zhang wrote some ACPI function test suite, please download
it from
http://acpi.sourceforge.net/validation/testcases/acpi-test-0.1.tar.gz
(which also includes the ABAT0.2 I published before)
The main function tested by these cases includes:
C-state
Validate the C-state
Folks,
Please nuke your local copy of my acpi test branch before you pull it again.
I needed to check in modified versions of some of the patches and the will
conflict with the original versions.
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the
Added an ACPICA update that fixes some long-standing bugs...
latest patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git acpica
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git test
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb
an updated patch on top of 2.6.16-rc1.
Yes, there is more to come -- i'm still catching up on the backlog from
traveling last week.
It is important to test this version because we're hoping to push the majority
of these patches into 2.6.16, which has already hit rc1. In particular t
79 matches
Mail list logo
