headers
Zhang Rui | 1 Aug 2007 01:00
Picon
Favicon

[PATCH] [-mm] ACPI: use GFP_KERNEL instead of GFP_ATOMIC

Use GFP_KERNEL instead of GFP_ATOMIC.

GFP_ATOMIC is still needed by the sonypi and sony-laptop driver.

Signed-off-by: Zhang Rui <rui.zhang <at> intel.com>
---
 drivers/acpi/ac.c                 |    3 ++-
 drivers/acpi/asus_acpi.c          |    2 +-
 drivers/acpi/battery.c            |    3 ++-
 drivers/acpi/bus.c                |    7 ++++---
 drivers/acpi/button.c             |    2 +-
 drivers/acpi/event.c              |    6 +++---
 drivers/acpi/processor_core.c     |    7 ++++---
 drivers/acpi/sbs.c                |    2 +-
 drivers/acpi/thermal.c            |    8 ++++----
 drivers/acpi/video.c              |   10 +++++-----
 drivers/char/sonypi.c             |    3 ++-
 drivers/misc/asus-laptop.c        |    2 +-
 drivers/misc/sony-laptop.c        |    4 ++--
 drivers/misc/thinkpad_acpi.c      |   26 +++++++++++++++++---------
 drivers/pci/hotplug/acpiphp_ibm.c |    3 ++-
 include/acpi/acpi_bus.h           |    5 +++--
 16 files changed, 54 insertions(+), 39 deletions(-)

Index: linux-2.6.23-rc1/drivers/acpi/bus.c
===================================================================
--- linux-2.6.23-rc1.orig/drivers/acpi/bus.c
+++ linux-2.6.23-rc1/drivers/acpi/bus.c
 <at>  <at>  -284,7 +284,8  <at>  <at>  DECLARE_WAIT_QUEUE_HEAD(acpi_bus_event_q
(Continue reading)

Permalink | Reply | 4 comments |
headers
Zhang Rui | 1 Aug 2007 01:04
Picon
Favicon

[RFC] [PATCH] ACPI: use unique ACPI device names in procfs

Use unique device names in procfs.

Device name is not unique in /proc/acpi.
http://bugzilla.kernel.org/show_bug.cgi?id=8798

Use acpi_device->dev.bus_id instead of
acpi_device->pnp.bus_id, like what we've done in sysfs.

ACPI proc I/F will change a lot with this patch applied.
But as /proc/acpi/... won't be removed in a short time,
I still think it's worth doing.

Does this patch miss something?
Or are there any better ideas to make the ACPI device name
unique in procfs?

Any comments are appreciated. Thanks.

Signed-off-by: Zhang Rui <rui.zhang <at> intel.com>
---
 drivers/acpi/bus.c        |   29 +++++++++++++++--------------
 drivers/acpi/power.c      |   10 +++++-----
 drivers/acpi/sbs.c        |    2 +-
 drivers/acpi/scan.c       |    2 +-
 drivers/acpi/sleep/proc.c |   19 ++++++++++---------
 drivers/acpi/thermal.c    |    6 +++---
 include/acpi/acpi_bus.h   |    4 ++--
 7 files changed, 37 insertions(+), 35 deletions(-)

Index: linux-2.6.23-rc1/drivers/acpi/thermal.c
(Continue reading)

Permalink | Reply | 1 comment |
headers
Danny ter Haar | 1 Aug 2007 02:44
Favicon

Re: Update: ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not:

Quoting Len Brown (lenb <at> kernel.org):
> Also, please test with CONFIG_X86_ACPI_CPUFREQ=n
> to remove the acpi-cpufreq driver (and thus this patch)
> from your kernel.  If it still fails, then we know
> that this driver (and this patch) are not related
> to the failure.

It wasn't enabled in any of the kernels i ran:

# grep X86_ACPI ../configs/config*
../configs/config-2.6.22-git14-c3-via5000-firewall:# CONFIG_X86_ACPI_CPUFREQ is not set
../configs/config-2.6.22-git17-c3-via5000-firewall:# CONFIG_X86_ACPI_CPUFREQ is not set
../configs/config-2.6.23-rc1-git5:# CONFIG_X86_ACPI_CPUFREQ is not set
../configs/config-2.6.23-rc1-git6:# CONFIG_X86_ACPI_CPUFREQ is not set
../configs/config-2.6.23-rc1-git9:# CONFIG_X86_ACPI_CPUFREQ is not set
../configs/config-2.6.23-rc1-mm1-c3-firewall:# CONFIG_X86_ACPI_CPUFREQ is not set

> Hmmm, okay, the "big hammer" works.  Please see
> if any of these smaller hammers work:
> 
> pnpacpi=off
> acpi=noirq
> notsc

_none_ of these options will work. The machine locks up solid.
And that's what i'm the most surprised about. The last time i withnessed
a solid kernel lockup without any panic/notification is _years_ ago.

I also tried a kernel without "CPU Frequency scaling", so it is not the
scaling up/down in Mhz of the cpu.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Aug 2007 02:45

Re: [REGRESSION] tg3 dead after s2ram

On Tue, 31 Jul 2007 11:28:32 +0200 "Joachim Deguara" <joachim.deguara <at> amd.com> wrote:

> On my Acer Ferrari 1000 the tg3 ethernet no longer is available after a 
> suspend to ram with the latet 2.6.23-rc1-git9.

Thanks. cc's added, body retained..

>  The tg3 works fine with s2ram 
> in 2.6.22.1.  The tell tail signs that is dead is this message from the 
> kernel log:
> 
> [    6.754133] tg3: eth0: No firmware running.
> [    6.816140] tg3: tg3_load_tso_firmware fails for eth0 to set CPU PC, is 
> ffffffff should be 00010000
> [    7.285797] ACPI: EC: Handler for query 0x80 is not found!
> [    8.016223] tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not 
> clear MAC_TX_MODE=ffffffff
> 
> and trying to bring the link up resuls in:
> 
> # ifconfig eth0 up
> SIOCSIFFLAGS: No such device
> 
> Full kernel log follows.
> 
> -Joachim
> 
> [    0.000000] Linux version 2.6.23-rc1-git9 (joachim <at> avanti) (gcc version 
> 4.2.1 20070705 (prerelease) (SUSE Linux)) #13 SMP PREEMPT Tue Jul 31 11:15:02 
> CEST 2007
(Continue reading)

Permalink | Reply | 35 comments |
headers
Yasha Okshtein | 1 Aug 2007 03:34
Picon

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

On 7/28/07, Jan Dittmer <jdi <at> l4x.org> wrote:
> Andreas Schwab wrote:
> > Jan Dittmer <jdi <at> l4x.org> writes:
> >> Len Brown wrote:
> >> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144.
> > Are you cross-compiling?  The definition of kernel_ulong_t won't work on
> > x86.
> Yes, sorry, should have mentioned that. Build system is x86. Still,
> it didn't happen before the recent acpi merge.

I also have the same error, which I didn't have in 2.6.22:

FATAL: drivers/acpi/ac: sizeof(struct acpi_device_id)=20 is not a
modulo of the size of section __mod_acpi_device_table=48.
Fix definition of struct acpi_device_id in mod_devicetable.h
make[1]: *** [__modpost] Error 1

Build system is x86_64. I'm not cross-compiling, as the target machine
(not the build machine) is also x86_64.

 - Yasha
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Len Brown | 1 Aug 2007 05:27

[PATCH] ACPI: delete CONFIG_ACPI_PROCFS_SLEEP (again)

From: Len Brown <len.brown <at> intel.com>

CONFIG_ACPI_PROCFS_SLEEP is a NO-OP -- delete it (again).

Apparently 296699de6bdc717189a331ab6bbe90e05c94db06 creating CONFIG_SUSPEND
and CONFIG_PM_SLEEP was based on an out-dated version of drivers/acpi/Kconfig,
as it erroneously restored this recently deleted config option.

Signed-off-by: Len Brown <len.brown <at> intel.com>
---
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 934d639..f1372de 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
 <at>  <at>  -68,14 +68,6  <at>  <at>  config ACPI_PROCFS

 	  Say N to delete /proc/acpi/ files that have moved to /sys/
 
-config ACPI_PROCFS_SLEEP
-	bool "/proc/acpi/sleep (deprecated)"
-	depends on PM_SLEEP && ACPI_PROCFS
-	default n
-	---help---
-	  Create /proc/acpi/sleep
-	  Deprecated by /sys/power/state
-
 config ACPI_AC
 	tristate "AC Adapter"
 	depends on X86
(Continue reading)

Permalink | Reply | 2 comments |
headers
Scott Thompson | 1 Aug 2007 07:08
Favicon

[RFC] CONFIG_PM_LEGACY = compiler warnings for deprecation ... solution?

w/ CONFIG_PM_LEGACY .config option set, you get following batch of
compile errors because it marks the functions as 'deprecated'. w/o 
it set, it just uses stubs. compiler warnings for refernece (from 
2.6.23-1, though appears to have been around since at least 2.6.11 
from another mail list post).

However, since these functions are required if you have
CONFIG_PM_LEGACY option marked...

I propose that within the include/linux/pm_legacy.h file, functions
in the CONFIG_PM_LEGACY aren't marked 'deprecated' and functions
outside the #if are marked deprecated.  Then the handful of calls
(12 or so) that actually call the pm_legacy apis can get wrapped in
the CONFIG_PM_LEGACY flag.

This is basically already being done in one case since as of
2.6.20.1 the pm_register function is only used in
drivers/serial/68328serial.c.

The pm_send_all is not wrapped around all uses yet, but that is
pretty easy to patch.  Then the compile will actually complain
should someone try to call it and not wrap w/ the CONFIG_PM_LEGACY
ifdef.

Happy to hear thoughts or other solutions.

------------------------------
Regards,
Scott Thompson / postfail <at> hushmail.com
------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Chan | 1 Aug 2007 09:53
Favicon

Re: [REGRESSION] tg3 dead after s2ram

On Tue, 2007-07-31 at 17:45 -0700, Andrew Morton wrote:
> On Tue, 31 Jul 2007 11:28:32 +0200 "Joachim Deguara"
> <joachim.deguara <at> amd.com> wrote:
> 
> > On my Acer Ferrari 1000 the tg3 ethernet no longer is available
> after a
> > suspend to ram with the latet 2.6.23-rc1-git9.

It seems to work for me on the same 2.6.23-rc1-git9 kernel with the same
tg3 hardware.  Can you narrow down the problem some more?  It seems that
in your case, the chip registers are returning 0xffffffff after resume.
Can you do lspci -xxxvvv on the tg3 adapter after resume?

Here's my log:

tg3.c:v3.79 (July 18, 2007)
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
eth0: Tigon3 [partno(BCM95755m) rev a002 PHY(5755)] (PCI Express) 10/100/1000Ba1eth0: RXcsums[1]
LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[76180000] dma_mask[64-bit]
ACPI: PCI Interrupt 0000:40:00.0[A] -> GSI 17 (level, low) -> IRQ 17
eth1: Tigon3 [partno(BCM95751) rev 4001 PHY(5750)] (PCI Express) 10/100/1000Bas5eth1: RXcsums[1]
LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[76180000] dma_mask[64-bit]
ACPI: PCI Interrupt 0000:05:09.0[A] -> GSI 18 (level, low) -> IRQ 19
eth2: Tigon3 [partno(BCM95788A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/1008eth2: RXcsums[1]
LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[1]
eth2: dma_rwctrl[763f0000] dma_mask[32-bit]
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_UP): eth1: link is not ready
(Continue reading)

Permalink | Reply | 32 comments |
headers
Joachim Deguara | 1 Aug 2007 10:01
Picon
Favicon

Re: [REGRESSION] tg3 dead after s2ram

On Wednesday 01 August 2007 09:53:31 Michael Chan wrote:
> On Tue, 2007-07-31 at 17:45 -0700, Andrew Morton wrote:
> > On Tue, 31 Jul 2007 11:28:32 +0200 "Joachim Deguara"
> >
> > <joachim.deguara <at> amd.com> wrote:
> > > On my Acer Ferrari 1000 the tg3 ethernet no longer is available
> >
> > after a
> >
> > > suspend to ram with the latet 2.6.23-rc1-git9.
>
> It seems to work for me on the same 2.6.23-rc1-git9 kernel with the same
> tg3 hardware.  Can you narrow down the problem some more?  It seems that
> in your case, the chip registers are returning 0xffffffff after resume.
> Can you do lspci -xxxvvv on the tg3 adapter after resume?

Here are the lspci outputs for the tg3

Before

07:00.0 Network controller: Broadcom Corporation Unknown device 4328 (rev 01)
	Subsystem: AMBIT Microsystem Corp. Unknown device 0319
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at d0200000 (64-bit, non-prefetchable) [disabled] [size=16K]
	Region 2: Memory at d8000000 (64-bit, prefetchable) [disabled] [size=1M]
	Capabilities: [40] Power Management version 2
(Continue reading)

Permalink | Reply | 29 comments |
headers
Rafael J. Wysocki | 1 Aug 2007 12:24
Picon
Gravatar

Re: [PATCH] ACPI: delete CONFIG_ACPI_PROCFS_SLEEP (again)

On Wednesday, 1 August 2007 05:27, Len Brown wrote:
> From: Len Brown <len.brown <at> intel.com>
> 
> CONFIG_ACPI_PROCFS_SLEEP is a NO-OP -- delete it (again).
> 
> Apparently 296699de6bdc717189a331ab6bbe90e05c94db06 creating CONFIG_SUSPEND
> and CONFIG_PM_SLEEP was based on an out-dated version of drivers/acpi/Kconfig,
> as it erroneously restored this recently deleted config option.

Some chunks of code in drivers/acpi/sleep/proc.c depend on
CONFIG_ACPI_PROCFS_SLEEP.  Do you also intend to remove that code?

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane