Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
On Mon, 18 Feb 2008 05:00:49 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Sun, 17 Feb 2008 00:54:08 + (GMT) Chris Rankin [EMAIL PROTECTED] wrote: [Try this again, except this time I'll force the attachment as inline text!] Hi, I have managed to boot 2.6.24.1 on this machine, with the NMI watchdog enabled, by using the acpi=noirq option. (There does seem to be some unhappiness with bridge symlinks in sysfs, though.) ... sysfs: duplicate filename 'bridge' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 1, comm: swapper Not tainted 2.6.24.1 #1 [c0105020] show_trace_log_lvl+0x1a/0x2f [c0105990] show_trace+0x12/0x14 [c010613d] dump_stack+0x6c/0x72 [c01991bf] sysfs_add_one+0x57/0xbc [c0199e41] sysfs_create_link+0xc2/0x10d [c01bae9a] pci_bus_add_devices+0xbd/0x103 [c034016c] pci_legacy_init+0x56/0xe3 [c03274e1] kernel_init+0x157/0x2c3 [c0104c83] kernel_thread_helper+0x7/0x10 === pci :00:01.0: Error creating sysfs bridge symlink, continuing... sysfs: duplicate filename 'bridge' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 1, comm: swapper Not tainted 2.6.24.1 #1 [c0105020] show_trace_log_lvl+0x1a/0x2f [c0105990] show_trace+0x12/0x14 [c010613d] dump_stack+0x6c/0x72 [c01991bf] sysfs_add_one+0x57/0xbc [c0199e41] sysfs_create_link+0xc2/0x10d [c01bae9a] pci_bus_add_devices+0xbd/0x103 [c01bae82] pci_bus_add_devices+0xa5/0x103 [c034016c] pci_legacy_init+0x56/0xe3 [c03274e1] kernel_init+0x157/0x2c3 [c0104c83] kernel_thread_helper+0x7/0x10 === I have a vague feeling that this was fixed, perhaps in 2.6.24.x? Never heard of this, what is the initialization script that causes this? Also do you have the SYSFS_DEPRECATED option configured? that caused issues with regular network drivers. - 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
Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
On Mon, 18 Feb 2008 19:42:25 + (GMT) Chris Rankin [EMAIL PROTECTED] wrote: --- Stephen Hemminger [EMAIL PROTECTED] wrote: sysfs: duplicate filename 'bridge' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 1, comm: swapper Not tainted 2.6.24.1 #1 [c0105020] show_trace_log_lvl+0x1a/0x2f [c0105990] show_trace+0x12/0x14 [c010613d] dump_stack+0x6c/0x72 [c01991bf] sysfs_add_one+0x57/0xbc [c0199e41] sysfs_create_link+0xc2/0x10d [c01bae9a] pci_bus_add_devices+0xbd/0x103 [c034016c] pci_legacy_init+0x56/0xe3 [c03274e1] kernel_init+0x157/0x2c3 [c0104c83] kernel_thread_helper+0x7/0x10 === pci :00:01.0: Error creating sysfs bridge symlink, continuing... sysfs: duplicate filename 'bridge' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 1, comm: swapper Not tainted 2.6.24.1 #1 [c0105020] show_trace_log_lvl+0x1a/0x2f [c0105990] show_trace+0x12/0x14 [c010613d] dump_stack+0x6c/0x72 [c01991bf] sysfs_add_one+0x57/0xbc [c0199e41] sysfs_create_link+0xc2/0x10d [c01bae9a] pci_bus_add_devices+0xbd/0x103 [c01bae82] pci_bus_add_devices+0xa5/0x103 [c034016c] pci_legacy_init+0x56/0xe3 [c03274e1] kernel_init+0x157/0x2c3 [c0104c83] kernel_thread_helper+0x7/0x10 === I have a vague feeling that this was fixed, perhaps in 2.6.24.x? Never heard of this, what is the initialization script that causes this? Also do you have the SYSFS_DEPRECATED option configured? that caused issues with regular network drivers. Yes, SYSFS_DEPRECATED is enabled. And the init scripts are from Fedora 8. There was a bug (fixed in 2.6.24) that had to do with sysfs_create_link and SYSFS_DEPRECATED probably there is a similar problem with directories. - 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
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Sun, 13 Jan 2008 11:27:12 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Sun, 13 Jan 2008 16:08:38 +0100 supersud501 [EMAIL PROTECTED] wrote: supersud501 wrote: Rafael J. Wysocki wrote: Since it seems to be 100% reproducible, it would be very helpful if you could use git-bisect to identify the offending commit. allright, bisect found the offending commit, here's what i've done: first i started bisect with the following command (since i assumed it is a net-driver problem): git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/' after building many kernels and saying good/bad if wol worked/didn't work etc. it identified the following commit: # bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI config writes and refs/bisect/bad gives: 14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad ac93a3946b676025fa55356180e8321639744b31 need some more info? i just checked it: commented out the passage of the commit in kernel 2.6.24-rc7-git4 and compiled it: wol WORKS. so this one line is causing my wol-disturbance... So simply reverting this: commit ac93a3946b676025fa55356180e8321639744b31 Author: Stephen Hemminger [EMAIL PROTECTED] Date: Mon Nov 5 15:52:08 2007 -0800 sky2: enable PCI config writes On some boards, PCI configuration space access is turned off by default. The 2.6.24 driver doesn't turn it on, and should have. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index c27c7d6..4f41a94 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw) sky2_write8(hw, B0_CTST, CS_RST_SET); sky2_write8(hw, B0_CTST, CS_RST_CLR); + /* allow writes to PCI config */ + sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON); + /* clear PCI errors, if any */ pci_read_config_word(pdev, PCI_STATUS, status); status |= PCI_STATUS_ERROR_BITS; fixes this regression? If so, we should revert that change. but i noticed another bug on 2.6.24-rc7-git with sky2: dmesg shows a lot of lines every 5 seconds: [...] [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 [ 362.442039] printk: 41 messages suppressed. [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 [ 367.439151] printk: 18 messages suppressed. [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 [ 372.436267] printk: 30 messages suppressed. [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 [ 377.350236] printk: 19 messages suppressed. [...] since i do not notice any errors (yet) i'll wait till next rc, maybe it will be gone then... That's not good. is this new behaviour? No, reverting that change will break other systems (including mine). -- Stephen Hemminger [EMAIL PROTECTED] - 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
[RFT] sky2: wake-on-lan configuration issues
Please test this patch against Linus's current (approx 2.6.24-rc7-git5).
Ignore Andrew's premature reversion attempt...
This patch disables config mode access after clearing PCI settings.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/drivers/net/sky2.c2008-01-14 09:44:22.0 -0800
+++ b/drivers/net/sky2.c2008-01-14 09:44:51.0 -0800
@@ -621,6 +621,7 @@ static void sky2_phy_power(struct sky2_h
static const u32 phy_power[] = { PCI_Y2_PHY1_POWD, PCI_Y2_PHY2_POWD };
static const u32 coma_mode[] = { PCI_Y2_PHY1_COMA, PCI_Y2_PHY2_COMA };
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
/* Turn on/off phy power saving */
if (onoff)
@@ -632,7 +633,8 @@ static void sky2_phy_power(struct sky2_h
reg1 |= coma_mode[port];
sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
- reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ sky2_pci_read32(hw, PCI_DEV_REG1);
udelay(100);
}
@@ -2426,6 +2428,7 @@ static void sky2_hw_intr(struct sky2_hw
if (status (Y2_IS_MST_ERR | Y2_IS_IRQ_STAT)) {
u16 pci_err;
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
pci_err = sky2_pci_read16(hw, PCI_STATUS);
if (net_ratelimit())
dev_err(pdev-dev, PCI hardware error (0x%x)\n,
@@ -2433,12 +2436,14 @@ static void sky2_hw_intr(struct sky2_hw
sky2_pci_write16(hw, PCI_STATUS,
pci_err | PCI_STATUS_ERROR_BITS);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
if (status Y2_IS_PCI_EXP) {
/* PCI-Express uncorrectable Error occurred */
u32 err;
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
err = sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
sky2_write32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS,
0xul);
@@ -2446,6 +2451,7 @@ static void sky2_hw_intr(struct sky2_hw
dev_err(pdev-dev, PCI Express error (0x%x)\n, err);
sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
if (status Y2_HWE_L1_MASK)
@@ -2811,6 +2817,7 @@ static void sky2_reset(struct sky2_hw *h
}
sky2_power_on(hw);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
for (i = 0; i hw-ports; i++) {
sky2_write8(hw, SK_REG(i, GMAC_LINK_CTRL), GMLC_RST_SET);
-
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
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Wed, 9 Jan 2008 16:03:00 -0800 Andrew Morton [EMAIL PROTECTED] wrote: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 9 Jan 2008 13:05:34 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9721 Summary: wake on lan fails with sky2 module Product: ACPI Version: 2.5 KernelVersion: 2.6.24-rc7 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Power-Sleep-Wake AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This post-2.6.23 regression was assigned to ACPI but is quite possibly a net driver problem? Latest working kernel version: 2.6.23.12 Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel, 2.6.24-rc7 still failing) Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet to make wake on lan work, i.e. network cards are not shutted down on poweroff) Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2 Software Environment: Problem Description: When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following status: 21:56:29 ~ # sudo ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pg Wake-on: g wol enabled Current message level: 0x00ff (255) Link detected: yes but after shutting down the pc doesn't wake up when magic packet is sent. the status lights of the network card are still on (so the card seems to be online). same system with only changed kernel to 2.6.23.12 and same procedure like above: wake on lan works. Steps to reproduce: enable wol on your network card using SKY2 module and it doesn't work too? if you need more information, just tell me, it's my first bug report. regards Wake from power off works on 2.6.24-rc7 for me. Wake from suspend doesn't because Network Manager, HAL, or some other user space tool gets confused. I just rechecked it with Fujitsu Lifebook, which has sky2 (88E8055). There many variations of this chip, and it maybe chip specific problem or ACPI/BIOS issues. If you don't enable Wake on Lan in BIOS, the driver can't do it for you. Also, check how you are shutting down. Also since the device has to restart the PHY, it could be a switch issue if you have some fancy pants switch doing intrusion detection or something, but I doubt that. Is it a clean or fast shutdown, most distributions mark network devices as down on shutdown, but if the distribution does something stupid like remove the driver module, then the driver is unable to setup Wake On Lan. The wake on lan setup is done in one place in the driver, add a printk to see if it is ever called. -- Stephen Hemminger [EMAIL PROTECTED] - 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
[PATCH] remove leftover documentation of acpi_generic_hotkey
This looks leftover text in the kernel parameter in documentation. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- a/Documentation/kernel-parameters.txt 2007-06-26 16:46:57.0 -0400 +++ b/Documentation/kernel-parameters.txt 2007-06-26 16:47:07.0 -0400 @@ -223,11 +223,6 @@ and is between 256 and 4096 characters. acpi_fake_ecdt [HW,ACPI] Workaround failure due to BIOS lacking ECDT - acpi_generic_hotkey [HW,ACPI] - Allow consolidated generic hotkey driver to - override platform specific driver. - See also Documentation/acpi-hotkey.txt. - acpi_pm_good[IA-32,X86-64] Override the pmtimer bug detection: force the kernel to assume that this machine's pmtimer latches its value - 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
Re: ACPI Power Down is broken in 2.6.21.1
On Sun, 13 May 2007 16:29:25 +0200 Michal Piotrowski [EMAIL PROTECTED] wrote: Hi Vladimir, [adding Len and ACPI gurus to CC] On 08/05/07, Vladimir Pouzanov [EMAIL PROTECTED] wrote: Hi all, I have got a problem with Asus F3T notebook and 2.6.21.1 kernel. When I perform powerdown (with user-space app or alt+sysrq+o) I get Power Down. message, but the notebook doesn't turn off. Everything is ok on 2.6.20. There seem to be no changes in acpi/sleep/poweroff.c so I don't know where should I start looking for a bug. F3T is based on Thrion64 X2 CPU (I'm running it in x86 mode with SMP and PREEMPT). Sincerely, Vladimir Farcaller Pouzanov http://hackndev.com I added this bug to the list of known regressions. (http://kernelnewbies.org/known_regressions) Regards, Michal Is the network still connected? Maybe there is a wake on lan problem with the network device. -- Stephen Hemminger [EMAIL PROTECTED] - 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
Re: 2.6.21 known regressions (v2) (for -stable team)
Subject: 2.6.21: sky2 hw csum failure problem References : http://lkml.org/lkml/2007/4/28/105 Submitter : Håkan Lindqvist [EMAIL PROTECTED] Status : unknown This is not a regression it is a bug, that has shown up for some users for quite a while, see: http://bugzilla.kernel.org/show_bug.cgi?id=7579 -- Stephen Hemminger [EMAIL PROTECTED] - 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
ASUS P5W DH boot up messages
:2008116k [ 59.157725] EXT3 FS on sda1, internal journal [ 59.228674] usb 5-7.3: new high speed USB device using ehci_hcd and address 3 [ 59.313003] usb 5-7.3: configuration #1 chosen from 1 choice [ 59.331241] kjournald starting. Commit interval 5 seconds [ 59.331582] EXT3 FS on sda4, internal journal [ 59.331589] EXT3-fs: mounted filesystem with ordered data mode. [ 61.585580] sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control both [ 65.212147] input: Power Button (FF) as /class/input/input3 [ 65.212183] ACPI: Power Button (FF) [PWRF] [ 65.212301] input: Power Button (CM) as /class/input/input4 [ 65.212326] ACPI: Power Button (CM) [PWRB] [ 65.270612] Using specific hotkey driver [ 65.296222] ACPI Warning (tbutils-0158): Incorrect checksum in table [OEMB] - 58, should be 4F [20070126] [ 65.296236] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._OSC] (Node 8100045e7b30), AE_ALREADY_EXISTS [ 65.296245] ACPI: Marking method _OSC as Serialized [ 65.296287] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PDC] (Node 8100045e7b50), AE_ALREADY_EXISTS [ 65.296293] ACPI: Marking method _PDC as Serialized [ 65.296705] ACPI: Processor [CPU1] (supports 8 throttling states) [ 65.296936] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU2._OSC] (Node 8100045e7a10), AE_ALREADY_EXISTS [ 65.296942] ACPI: Marking method _OSC as Serialized [ 65.296979] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU2._PDC] (Node 8100045e7a30), AE_ALREADY_EXISTS [ 65.296985] ACPI: Marking method _PDC as Serialized [ 65.297250] ACPI: Processor [CPU2] (supports 8 throttling states) [ 65.297265] ACPI Exception (acpi_processor-0784): AE_NOT_FOUND, Processor Device is not present [20070126] [ 65.297279] ACPI Exception (acpi_processor-0784): AE_NOT_FOUND, Processor Device is not present [20070126] [ 66.329526] [drm] Initialized drm 1.1.0 20060810 [ 66.418064] ACPI: PCI Interrupt :06:00.0[A] - GSI 16 (level, low) - IRQ 16 [ 66.419685] [drm] Initialized radeon 1.25.0 20060524 on minor 0 [ 66.420468] mtrr: type mismatch for e000,800 old: write-back new: write-combining [ 67.206566] mtrr: type mismatch for e000,800 old: write-back new: write-combining [ 67.417617] mtrr: type mismatch for e000,800 old: write-back new: write-combining [ 67.417736] mtrr: type mismatch for e000,800 old: write-back new: write-combining [ 67.417811] mtrr: type mismatch for e000,800 old: write-back new: write-combining [ 69.296349] NET: Registered protocol family 10 [ 69.296569] lo: Disabled Privacy Extensions [ 69.297300] ADDRCONF(NETDEV_UP): eth2: link is not ready [ 69.297653] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 69.760365] Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). [ 69.774341] [drm] Setting GART location based on new memory map [ 69.774956] [drm] Loading R300 Microcode [ 69.775107] [drm] writeback test succeeded in 1 usecs [ 79.973407] eth0: no IPv6 routers present -- Stephen Hemminger [EMAIL PROTECTED] - 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
Re: [linux-pm] [RFC] ACPI vs device ordering on resume
On Fri, 01 Dec 2006 20:45:51 +0300 Alexey Starikovskiy [EMAIL PROTECTED] wrote: Linus Torvalds wrote: On Fri, 1 Dec 2006, Pavel Machek wrote: So it looks like we need this sequence: enable_nonboot_cpus() /* INIT */ finish() /* _WAK */ device_resume() Can somebody remind me about this immediately after 2.6.19? Remind. But note that freezer is not yet SMP safe... Rafael is working on that. Thanks. On the other hand, I really wonder (and suspect) whether the problem isn't really the freezer or even the kernel resume ordering, but simply an ACPI internal resume ordering thing. Doesn't ACPI have per-device WAK calls anyway? Shouldn't we just call those _individually_ as we walk the device tree (perhaps in the early_resume stage) rather than calling them all in one chunk? Linus _WAK method is system-wide. Individual objects do not have their own resume methods. One way of reordering internal ACPI resume is done in patch series to 7122, I mentioned that earlier. It's possible to resume ACPI devices after execution of _WAK in pm-finish. Does it solve the original problem where finish() was getting run after device_resume(), and finish() was corrupting PCI register settings like MSI? -- Stephen Hemminger [EMAIL PROTECTED] - 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
Re: [linux-pm] [RFC] ACPI vs device ordering on resume
On Wed, 15 Nov 2006 02:03:30 -0500
Len Brown [EMAIL PROTECTED] wrote:
On Tuesday 14 November 2006 18:30, Stephen Hemminger wrote:
If I do a suspend-to-ram then resume on a Sony Vaio laptop with sky2 driver,
the first interrupt gets misrouted to the original shared IRQ, rather than
to the MSI irq expected.
During the pci_restore process, the MSI information and the PCI command
register
are restored properly. But later during resume, inside the ACPI evaluation
of
the WAK method, the PCI_COMMAND INTX_DISABLE (0x400) flag is being cleared.
My guess is that the BIOS ends up doing some resetting of devices.
I may be able to workaround the problem for this one device, but it brings
up
a more general issue about what the ordering should be during resume. If
ACPI
evaluation (which I assume talks to the BIOS), might change device state, it
seems that ACPI code should execute before resuming devices not after. But
changing
the order here seems drastic.
An alternate solution would be to have two pm_ops, one for early_resume
and another for late, and split the ACPI work.
--- 2.6.19-rc5.orig/kernel/power/main.c 2006-11-14 14:24:37.0
-0800
+++ 2.6.19-rc5/kernel/power/main.c 2006-11-14 14:25:23.0 -0800
@@ -132,12 +132,12 @@
static void suspend_finish(suspend_state_t state)
{
+ if (pm_ops pm_ops-finish)
+ pm_ops-finish(state);
device_resume();
resume_console();
thaw_processes();
enable_nonboot_cpus();
- if (pm_ops pm_ops-finish)
- pm_ops-finish(state);
pm_restore_console();
}
Yes, I agree that _WAK needs to come before device_resume().
Need to let any BIOS nasties happen and get over with before we restore
device drivers.
This is consistent with the wording in ACPI 3.0b (section 7.4) that says
11. _WAK is run
12. OSPM notifies all native device drivefrs of the return from the sleep
state transition
However, commit 1a38416cea8ac801ae8f261074721f35317613dc says that
_WAK must follow INIT -- ie finish() must come after enable_nonboot_cpus(),
and this patch as it stands would violate that.
So it looks like we need this sequence:
enable_nonboot_cpus() /* INIT */
finish() /* _WAK */
device_resume()
Do you want to do this, or shall I? send off a patch.
I can test on about 5 machines first.
-
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
[RFC] ACPI vs device ordering on resume
If I do a suspend-to-ram then resume on a Sony Vaio laptop with sky2 driver,
the first interrupt gets misrouted to the original shared IRQ, rather than
to the MSI irq expected.
During the pci_restore process, the MSI information and the PCI command
register
are restored properly. But later during resume, inside the ACPI evaluation of
the WAK method, the PCI_COMMAND INTX_DISABLE (0x400) flag is being cleared.
My guess is that the BIOS ends up doing some resetting of devices.
I may be able to workaround the problem for this one device, but it brings up
a more general issue about what the ordering should be during resume. If ACPI
evaluation (which I assume talks to the BIOS), might change device state, it
seems that ACPI code should execute before resuming devices not after. But
changing
the order here seems drastic.
An alternate solution would be to have two pm_ops, one for early_resume
and another for late, and split the ACPI work.
--- 2.6.19-rc5.orig/kernel/power/main.c 2006-11-14 14:24:37.0 -0800
+++ 2.6.19-rc5/kernel/power/main.c 2006-11-14 14:25:23.0 -0800
@@ -132,12 +132,12 @@
static void suspend_finish(suspend_state_t state)
{
+ if (pm_ops pm_ops-finish)
+ pm_ops-finish(state);
device_resume();
resume_console();
thaw_processes();
enable_nonboot_cpus();
- if (pm_ops pm_ops-finish)
- pm_ops-finish(state);
pm_restore_console();
}
--
Stephen Hemminger [EMAIL PROTECTED]
-
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
Re: 2.6.19-rc5 x86_64 irq 22: nobody cared
On Thu, 9 Nov 2006 07:49:56 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: On Wed, Nov 08, 2006 at 01:44:29PM +0100, Olivier Nicolas wrote: Hi, Hi Olivier, 2.6.19-rc5 does not boot properly, I have tried pci=routeirq, irpoll without success. Full details (.config, dmesg, /proc/interrupts) are in http://olivn.trollprod.org/2.6.19-rc5-irq.tar.gz thanks for your report! I might be wrong, but looking at the dmesg: - irq 22 is the hda_intel IRQ - the irq 22: nobody cared is immediately before the hda_intel: No response from codec, disabling MSI... - in the routeirq case, the hda_intel IRQ as well as the IRQ in the error message change to 21 So it might be related to the hda_intel MSI check. More likely the MSI management routines don't work for disabling MSI. I am debugging a problem where MSI doesn't work across suspend/resume, I suspect the base MSI code needs fixing. -- Stephen Hemminger [EMAIL PROTECTED] - 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
[PATCH] ACPI header length printk format warning
Get rid of warning from printk arguments on 64 bit platforms.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- orig/drivers/acpi/tables/tbget.c
+++ new/drivers/acpi/tables/tbget.c
@@ -324,8 +324,9 @@ acpi_tb_get_this_table(struct acpi_point
if (header-length sizeof(struct acpi_table_header)) {
ACPI_ERROR((AE_INFO,
- Table length (%X) is smaller than minimum (%X),
- header-length, sizeof(struct acpi_table_header)));
+ Table length (%lx) is smaller than minimum (%zx),
+ (unsigned long) header-length,
+ sizeof(struct acpi_table_header)));
return_ACPI_STATUS(AE_INVALID_TABLE_LENGTH);
}
@@ -343,8 +344,8 @@ acpi_tb_get_this_table(struct acpi_point
full_table = ACPI_ALLOCATE(header-length);
if (!full_table) {
ACPI_ERROR((AE_INFO,
- Could not allocate table memory for
[%4.4s] length %X,
- header-signature, header-length));
+ Could not allocate table memory for
[%4.4s] length %lx,
+ header-signature, (unsigned long)
header-length));
return_ACPI_STATUS(AE_NO_MEMORY);
}
-
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
