Re: [BUG] [linux-pm] Commit Hibernation: Enter platform hibernation state in a consistent way) makes my system to resume instantly from S4
On Saturday, 27 October 2007 14:05, Maxim Levitsky wrote: Hi, Recently I noticed that my system resumes just after suspend to disk. I traced this to commit 9cd9a0058dd35268b24fa16795a92c800f4086d4. Note: This happens only if I enable WOL using /proc/acpi/wakeup (echo ILAN /proc/acpi/wakeup) What happens after a suspend to RAM? and have ACPI-Hibernate-erroneously-disabled-Suspend-wakeup applied, since otherwise all wake-up sources are disabled in S4. Clearly the above commit confuses the BIOS. Using latest -git with the above patch reverted makes everything work again fine. Well, this patch is needed to make wakeup from peripherals (eg. RTC alarm) work on some boxes. The symptom that you describe is similar to what I'm observing after a suspend to RAM on one test box. Can you produce a log of kernel messages printed before powering off the system? Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB_SUSPEND needs SUSPEND?
On Sunday, 28 October 2007 02:00, Oliver Martin wrote: Hello, it seems that there is some dependency missing for CONFIG_USB_SUSPEND. When I compile a kernel without CONFIG_SUSPEND, USB suspend doesn't work (or at least doesn't expose its interface to userspace). /sys/bus/usb/devices/.../power doesn't exist, but it is there when I enable CONFIG_SUSPEND. So should CONFIG_USB_SUSPEND depend on CONFIG_SUSPEND (or something selected by CONFIG_SUSPEND)? diff between the two configs follows, full config and dmesg for both kernels is available at http://stud4.tuwien.ac.at/~e0626486/usb_suspend/ (though the dmesg diff doesn't seem to be all that interesting). Some CCs added. --- /boot/config-2.6.23.1-nosuspend +++ /boot/config-2.6.23.1-suspend @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23.1 -# Sat Oct 27 23:59:11 2007 +# Sat Oct 27 22:45:27 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y @@ -30,7 +30,7 @@ CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 -CONFIG_LOCALVERSION=-nosuspend +CONFIG_LOCALVERSION=-suspend # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y @@ -229,11 +229,13 @@ CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set +CONFIG_PM_SLEEP=y CONFIG_SUSPEND_UP_POSSIBLE=y -# CONFIG_SUSPEND is not set +CONFIG_SUSPEND=y CONFIG_HIBERNATION_UP_POSSIBLE=y # CONFIG_HIBERNATION is not set CONFIG_ACPI=y +CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=m @@ -255,6 +257,7 @@ CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m CONFIG_ACPI_SBS=m +# CONFIG_APM is not set # # CPU Frequency scaling - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB_SUSPEND needs SUSPEND?
On Sunday, 28 October 2007 17:50, Alan Stern wrote: On Sun, 28 Oct 2007, Rafael J. Wysocki wrote: On Sunday, 28 October 2007 02:00, Oliver Martin wrote: Hello, it seems that there is some dependency missing for CONFIG_USB_SUSPEND. When I compile a kernel without CONFIG_SUSPEND, USB suspend doesn't work (or at least doesn't expose its interface to userspace). /sys/bus/usb/devices/.../power doesn't exist, but it is there when I enable CONFIG_SUSPEND. So should CONFIG_USB_SUSPEND depend on CONFIG_SUSPEND (or something selected by CONFIG_SUSPEND)? diff between the two configs follows, full config and dmesg for both kernels is available at http://stud4.tuwien.ac.at/~e0626486/usb_suspend/ (though the dmesg diff doesn't seem to be all that interesting). Actually I think the problem is the other way around. /sys/.../power should exist whenever CONFIG_PM is defined, not just when CONFIG_SUSPEND is enabled. Agreed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA insert on resume
On Saturday, 27 October 2007 09:45, Pavel Machek wrote:
Hi!
I don't understand why, on resume, the function socket_resume() (in
drivers/pcmcia/cs.c) do:
if (!(skt-state SOCKET_PRESENT)) {
skt-state = ~SOCKET_SUSPEND;
return socket_insert(skt);
}
This cause a powered off socket before suspend to be powered on during
resume.
To avoid such (erroneous?) behaviour I propose this patch:
diff --git a/drivers/pcmcia/cs.c b/drivers/pcmcia/cs.c
index 729e37d..d69de74 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -562,10 +562,8 @@ static int socket_resume(struct pcmcia_socket *skt)
skt-ops-init(skt);
skt-ops-set_socket(skt, skt-socket);
- if (!(skt-state SOCKET_PRESENT)) {
- skt-state = ~SOCKET_SUSPEND;
- return socket_insert(skt);
- }
+ if (!(skt-state SOCKET_PRESENT))
+ goto resume_exit;
ret = socket_setup(skt, SS_COMA, resume_delay);
if (ret == CS_SUCCESS) {
@@ -599,6 +597,7 @@ static int socket_resume(struct pcmcia_socket *skt)
socket_shutdown(skt);
}
+resume_exit:
skt-state = ~SOCKET_SUSPEND;
return CS_SUCCESS;
With this patch if the socket was powered down before the suspend, at
resume time it's not powered on and you need a pccardctl insert to
activate the socket.
Seems okay to me, but I do not know much about pcmcia. Add
signed-off-by, changelog at the beggining, cc me, rafael and akpm... ?
Actually, there are some objections wrt this patch from Russell King.
Greetings,
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WANTED: kernel projects for CS students
On Sunday, 28 October 2007 19:07, Pavel Machek wrote: Hi! - Are large enough to qualify as a student project, luckily there is flexibility here since we get inquiries for anything from 6 week projects to 6 month projects. If you have ideas on what projects would be useful, please add them to this page (or email me): Hard stuff: * network character device -- similar to nbd, but for char devices. either figure out how to forward ioctls(), or implement usb-over-network, or... * openMosix -- they seem to have userspace solution, but not GPLed. The project is no longer being developed, AFAICS. * compression for ext4. Its about time someone did it right. Special bonus if you can do it in a way that it does not slow down. If cpu is free, compress, if it is busy, just write it straight to disk. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cannot hibernate if program being debugged in gdb is paused after SIGABRT in linux 2.6.23 (but can in 2.6.22.7)
On Sunday, 28 October 2007 16:33, C Sights wrote: Well, a test program that triggers the SIGABRT under gdb would be useful. The attached program causes a SIGABRT for me, Thanks, C. Thanks, I'll try to reproduce the problem here and fix it. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] [linux-pm] Commit Hibernation: Enter platform hibernation state in a consistent way) makes my system to resume instantly from S4
On Sunday, 28 October 2007 21:00, Maxim Levitsky wrote: On Saturday 27 October 2007 23:46:45 Rafael J. Wysocki wrote: On Saturday, 27 October 2007 14:05, Maxim Levitsky wrote: Hi, Recently I noticed that my system resumes just after suspend to disk. I traced this to commit 9cd9a0058dd35268b24fa16795a92c800f4086d4. Note: This happens only if I enable WOL using /proc/acpi/wakeup (echo ILAN /proc/acpi/wakeup) What happens after a suspend to RAM? I do more testing tomorrow, but what I remember is that, I had no issues with suspend-to-ram. (And take into account the fact that _all_ wakeup devices were enabled always, the rc.local does that for me, and still I did quite a lot of suspends, but I got the immediate resume, only and always after suspend to disk. Hm, can you please retest with the above commit applied, but with device_suspend() in hibernation_platform_enter() replaced by device_shutdown()? and have ACPI-Hibernate-erroneously-disabled-Suspend-wakeup applied, since otherwise all wake-up sources are disabled in S4. Clearly the above commit confuses the BIOS. Using latest -git with the above patch reverted makes everything work again fine. Well, this patch is needed to make wakeup from peripherals (eg. RTC alarm) work on some boxes. The symptom that you describe is similar to what I'm observing after a suspend to RAM on one test box. Can you produce a log of kernel messages printed before powering off the system? How :-) (I will try to set up netconsole, and turn on acpi debugging, maybe this will help) Yes, I meant something like this. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc1-git4: Reported regressions from 2.6.23
This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Subject : Settings to /proc/sys/net/ipv[46]/conf/all are not propagated. via sysctl too Submitter : Serge van den Boom [EMAIL PROTECTED] References : http://bugzilla.kernel.org/show_bug.cgi?id=9224 Handled-By : Hideaki YOSHIFUJI [EMAIL PROTECTED] Subject : linux-2.6.23-git3: Many sysfs-related warnings in dmesg Submitter : Rafael J. Wysocki [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/13/204 http://lkml.org/lkml/2007/10/26/317 http://bugzilla.kernel.org/show_bug.cgi?id=9244 Handled-By : Greg KH [EMAIL PROTECTED] Kay Sievers [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/10/26/359 Subject : On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at virtual address 3d15b925 Submitter : Giacomo Catenazzi [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/24/487 http://bugzilla.kernel.org/show_bug.cgi?id=9246 Subject : Potential regression in -git15: can't resume stopped root shell? Submitter : Theodore Tso [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/20/114 http://bugzilla.kernel.org/show_bug.cgi?id=9247 Subject : 2.6.24-rc1 fails with lockup and BUG: Submitter : Romano Giannetti [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/24/232 http://bugzilla.kernel.org/show_bug.cgi?id=9248 Handled-By : Ingo Molnar [EMAIL PROTECTED] Peter Zijlstra [EMAIL PROTECTED] Stephen Hemminger [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/10/26/382 Subject : irq 21: nobody cared 2.6.24-rc1 Submitter : Bongani Hlope [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/25/90 http://bugzilla.kernel.org/show_bug.cgi?id=9249 Subject : [BUG] panic after umount (biscted) Submitter : Sebastian Siewior [EMAIL PROTECTED] References : http://marc.info/?l=linux-kernelm=119338387030335w=2 http://bugzilla.kernel.org/show_bug.cgi?id=9250 Handled-By : Jens Axboe [EMAIL PROTECTED] Patch : http://marc.info/?l=linux-kernelm=119348520210349w=2 Subject : 2.6.24-rc1 sysctl table check failed on PowerMac Submitter : Mikael Pettersson [EMAIL PROTECTED] References : http://marc.info/?l=linux-kernelm=119350802331857w=2 http://bugzilla.kernel.org/show_bug.cgi?id=9251 Handled-By : Alexey Dobriyan [EMAIL PROTECTED] Patch : http://marc.info/?l=linux-kernelm=119351015801660w=2 Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel Submitter : Andrey Borzenkov [EMAIL PROTECTED] References : http://marc.info/?l=linux-kernelm=119342005216716w=2 http://bugzilla.kernel.org/show_bug.cgi?id=9252 Handled-By : Alan Cox [EMAIL PROTECTED] Subject : 2.6.24-rc1-gec3b67c1 broken reg. libata-sata_nv in non NCQ mode Submitter : Prakash Punnoor [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/27/34 http://bugzilla.kernel.org/show_bug.cgi?id=9253 Subject : 2.6.24-rc1 freezes on powerbook at first boot stage Submitter : Elimar Riesebieter [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/24/205 http://bugzilla.kernel.org/show_bug.cgi?id=9254 Subject : build #286 failed for 2.6.24-rc1-gea45d15 in linux/arch/x86/kernel/setup_32.c Submitter : Toralf Förster [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/28/110 http://bugzilla.kernel.org/show_bug.cgi?id=9256 Handled-By : H. Peter Anvin [EMAIL PROTECTED] Patch : http://marc.info/[EMAIL PROTECTED] Subject : 2.6.24-rc1 kills onboard r8169 (rtl8111b) NIC Submitter : Sergey S. Kostyliov [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/28/144 http://bugzilla.kernel.org/show_bug.cgi?id=9257 Handled-By : Francois Romieu [EMAIL PROTECTED] Subject : Commit Hibernation: Enter platform hibernation state in a consistent way) makes my system to resume instantly from S4 Submitter : Maxim Levitsky [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/10/27/66 http://bugzilla.kernel.org/show_bug.cgi?id=9258 Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] Subject : [2.6.24-rc1 regression] suspend fails Submitter : Andrey
Re: 2.6.24-rc1-git4: Reported regressions from 2.6.23
On Sunday, 28 October 2007 23:48, Frans Pop wrote: The regression in process CPU usage display in top is still there: http://bugzilla.kernel.org/show_bug.cgi?id=9135 It's a regression from .22, not from .23, but I guess it should still be listed. Well, my intention is to list the most recent regressions in these messages. Your regression is in the bugzilla, is marked as a regression and linked to the appropriate meta bug entry ... Well, perhaps I'll be able to send a post 2.6.22 regressions message with a longer list from time to time, but I can't promise that. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-git4: Reported regressions from 2.6.23
On Sunday, 28 October 2007 23:53, Alan Cox wrote: Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel Submitter : Andrey Borzenkov [EMAIL PROTECTED] References : http://marc.info/?l=linux-kernelm=119342005216716w=2 http://bugzilla.kernel.org/show_bug.cgi?id=9252 Handled-By : Alan Cox [EMAIL PROTECTED] 2.6.23 did not have pata_acpi. Its also not clear this is a bug in pata_acpi as opposed to pata_ali which knows about the ALi quirks. The ACPI and ATA specs sort of disagree here so I'll be trying to fix it anyway. OK, but please let me keep that on the list. It may cause some people to experience problems that were not present before functionality-wise. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-git4: Reported regressions from 2.6.23
On Monday, 29 October 2007 02:17, David Miller wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sun, 28 Oct 2007 23:51:55 +0100 Subject : Settings to /proc/sys/net/ipv[46]/conf/all are not propagated. via sysctl too Submitter : Serge van den Boom [EMAIL PROTECTED] References : http://bugzilla.kernel.org/show_bug.cgi?id=9224 Handled-By : Hideaki YOSHIFUJI [EMAIL PROTECTED] I am to understand, from a reply from Herbert Xu, that this issue has existed a long time, definitely since before 2.6.22, therefore it doesn't belong on the regression list. I have removed it from the list. Thanks, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23] IBM X41 looses time after Suspend2Disk
On Monday, 29 October 2007 21:19, Philipp Matthias Hahn wrote: Hello Thomas, Pavel, Rafael! I have an IBM X41 tablet pc running 2.6.23 with the following problem: Suspend2Ram work fine, but when I do a Suspend2Disk (echo disk /sys/power/state), the notebook hangs showing the following lines: Stopping tasks ... done. Shrinking memory... done (49361 pages freed) Freed 197444 kbytes in 0.64 seconds (308.50 MB/s) Suspending console(s) When I repeatedly press some keys or move the TrackPoint, the SwSusp continues and the notebook powers off. On reboot, the notebook resumes but hangs showing the following screen: Stopping tasks ... done. Loading image data pages (62483 pages) ... done Read 249932 kbytes in 18.63 seconds (13.41 MB/s) Suspending console(s) Generating interrupts by pressing keys or moving the TrackPoints makes the resume continue. But after that, the notebook looses time, xterms don't get updated until I press a key, the beeper beeps until I press a key, etc. Any idea what the problem might be? Nope. DMESG: http://corellon.svs.informatik.uni-oldenburg.de/~pmhahn/x41.dmesg CONFIG: http://corellon.svs.informatik.uni-oldenburg.de/~pmhahn/x41.config If you need more data, just ask. Please try to do echo shutdown /sys/power/disk before hibernation and see what happens. Also, is it an SMP kernel or UP? Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] [linux-pm] Commit Hibernation: Enter platform hibernation state in a consistent way) makes my system to resume instantly from S4
On Monday, 29 October 2007 07:45, Maxim Levitsky wrote: On Sunday 28 October 2007 22:23:15 Rafael J. Wysocki wrote: On Sunday, 28 October 2007 21:00, Maxim Levitsky wrote: On Saturday 27 October 2007 23:46:45 Rafael J. Wysocki wrote: On Saturday, 27 October 2007 14:05, Maxim Levitsky wrote: Hi, Recently I noticed that my system resumes just after suspend to disk. I traced this to commit 9cd9a0058dd35268b24fa16795a92c800f4086d4. Note: This happens only if I enable WOL using /proc/acpi/wakeup (echo ILAN /proc/acpi/wakeup) What happens after a suspend to RAM? I do more testing tomorrow, but what I remember is that, I had no issues with suspend-to-ram. (And take into account the fact that _all_ wakeup devices were enabled always, the rc.local does that for me, and still I did quite a lot of suspends, but I got the immediate resume, only and always after suspend to disk. Hm, can you please retest with the above commit applied, but with device_suspend() in hibernation_platform_enter() replaced by device_shutdown()? Bingo! doing the above fixes this problem. And... strange, since I did test the system with e1000 unloaded, but still got same bug, back when I chased that bug, thus it is probably not related to e1000 and WOL. the ACPI wake-up source (I have read the DSDT, and ICH datasheets, thus I know that this is a set of bits in southbridge) of e1000 is shared with EHCI and HDA sound codec. (But usb on my system only able to wake from S3, and the soundchip which can theoretically wake up from S3 too, doesn't have this ability) (But disabling this wakeup source, fixes this bug too) OK Please get back to device_suspend() in hibernation_platform_enter() and try to unload ehci_hcd before hibernation with the wakeup source enabled. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] [linux-pm] Commit Hibernation: Enter platform hibernation state in a consistent way) makes my system to resume instantly from S4
On Monday, 29 October 2007 23:36, Maxim Levitsky wrote: On Monday 29 October 2007 22:37:37 Rafael J. Wysocki wrote: On Monday, 29 October 2007 07:45, Maxim Levitsky wrote: On Sunday 28 October 2007 22:23:15 Rafael J. Wysocki wrote: On Sunday, 28 October 2007 21:00, Maxim Levitsky wrote: On Saturday 27 October 2007 23:46:45 Rafael J. Wysocki wrote: On Saturday, 27 October 2007 14:05, Maxim Levitsky wrote: Hi, Recently I noticed that my system resumes just after suspend to disk. I traced this to commit 9cd9a0058dd35268b24fa16795a92c800f4086d4. Note: This happens only if I enable WOL using /proc/acpi/wakeup (echo ILAN /proc/acpi/wakeup) What happens after a suspend to RAM? I do more testing tomorrow, but what I remember is that, I had no issues with suspend-to-ram. (And take into account the fact that _all_ wakeup devices were enabled always, the rc.local does that for me, and still I did quite a lot of suspends, but I got the immediate resume, only and always after suspend to disk. Hm, can you please retest with the above commit applied, but with device_suspend() in hibernation_platform_enter() replaced by device_shutdown()? Bingo! doing the above fixes this problem. And... strange, since I did test the system with e1000 unloaded, but still got same bug, back when I chased that bug, thus it is probably not related to e1000 and WOL. the ACPI wake-up source (I have read the DSDT, and ICH datasheets, thus I know that this is a set of bits in southbridge) of e1000 is shared with EHCI and HDA sound codec. (But usb on my system only able to wake from S3, and the soundchip which can theoretically wake up from S3 too, doesn't have this ability) (But disabling this wakeup source, fixes this bug too) OK Please get back to device_suspend() in hibernation_platform_enter() and try to unload ehci_hcd before hibernation with the wakeup source enabled. Well, ... bingo! again! Replacing back the device_suspend() , and unloading the ehci_hcd fixes the problem! Even more, loading this module back causes this problem to reappear, and vise-verso. All wakeup sources are enabled always. Note that I don't have any USB 2.0 devices yet. The usb devices I have are: keyboard,mouse,and joystick. So now this problem looks fixable, I take a look at ehci driver. This is very similar to what I've been observing for some time on one of my test boxes wrt suspending to RAM and in that case the problem is also related to EHCI (this is a pretty old Celeron-based box with an Intel chipset). It looks like in some situations, on some platforms the EHCI controller triggers a resume right after the suspend (or hibernation) if the driver's .suspend() routine is executed before invoking the ACPI firmware to put the system into the sleep state. [The ehci_hcd causes box to resume immediately after suspend to RAM thread on linux-pm was about this problem.] Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23] IBM X41 looses time after Suspend2Disk
On Tuesday, 30 October 2007 09:35, Philipp Matthias Hahn wrote: Hello Rafael, Pavel! Thank you both for the fast help. On Mon, Oct 29, 2007 at 10:05:10PM +0100, Rafael J. Wysocki wrote: On Monday, 29 October 2007 21:19, Philipp Matthias Hahn wrote: I have an IBM X41 tablet pc running 2.6.23 with the following problem: Suspend2Ram work fine, but when I do a Suspend2Disk (echo disk /sys/power/state), the notebook hangs showing the following lines: ... Suspending console(s) When I repeatedly press some keys or move the TrackPoint, the SwSusp continues and the notebook powers off. On reboot, the notebook resumes but hangs showing the following screen: ... Suspending console(s) Generating interrupts by pressing keys or moving the TrackPoints makes the resume continue. But after that, the notebook looses time, xterms don't get updated until I press a key, the beeper beeps until I press a key, etc. ... Please try to do echo shutdown /sys/power/disk before hibernation and see what happens. I'm already doing that. Well, have you tried doing echo platform /sys/power/disk before hibernation instead? Also, is it an SMP kernel or UP? UP. On Mon, Oct 29, 2007 at 10:24:14PM +0100, Pavel Machek wrote: Yep, I seen that before. Try nohz=off. Okay, that seems to solve the timer loosing time after resume problem. But I still need to press some keys on suspend (7-12 key presses and releases) to unhang it. On resume not key presses are needed any more. During on suspend-resume cycle ACPI barfed afer resume spewing messages without end (error during execution of methode \...THM, error evaulation operand ...) I had to remove the battery and pull the power-plug to reboot it. The ACPI platform firmware got confused, apparently. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.24-rc1 regression] AC adapter state does not change after resume
On Tuesday, 30 October 2007 21:24, Andrey Borzenkov wrote: I suspect new ACPI AC adapter code but have to add some printk's to be sure. To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and sysfs still show AC adapter online. Or other way round. Is this a resume from RAM or from disk? Does 2.6.23 work correctly? Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24: (ACPI AC adapter) sending {proc,netlink,kobject}_event from - resume method?
On Tuesday, 30 October 2007 20:33, Andrey Borzenkov wrote: Is it valid to send events from within -resume device method? It is or at least it should be. The GPEs are supposed to be fully functional at this point. If not, what is the proper way to notify user space about hardware changes during suspension? Specifically it seems that new sysfs ACPI power supply interface sometimes missing plugged in AC cord during suspend. I suspect that no event is generated for this; I am not sure whether ACPI is required to generate such events at all in this case. I'll need some time to get reproducible case so I do not categorize this yet as regression. Is the [2.6.24-rc1 regression] AC adapter state does not change after resume message a follow-up to this one? Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iwl3945 in 2.6.24-rc1 dies under load
On Wednesday, 31 October 2007 01:52, Pavel Machek wrote: Hi! ...does not seem to work too well :-(. It connects with the AP (good!), and survives some normal use, but it died at first big tcpspray (bd!). Is this a regression from 2.6.23? Oct 31 01:03:57 amd log1n[1411]: ROOT LOGIN on `tty6' Oct 31 01:05:06 amd kernel: iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.1.17kds Oct 31 01:05:06 amd kernel: iwl3945: Copyright(c) 2003-2007 Intel Corporation Oct 31 01:05:06 amd kernel: PCI: Setting latency timer of device :03:00.0 to 64 Oct 31 01:05:06 amd kernel: iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection Oct 31 01:05:07 amd kernel: iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels Oct 31 01:05:07 amd kernel: phy4: Selected rate control algorithm 'simple' Oct 31 01:06:05 amd kernel: wlan0: Initial auth_alg=0 Oct 31 01:06:05 amd kernel: wlan0: authenticate with AP 00:11:2f:0e:95:a0 Oct 31 01:06:05 amd kernel: wlan0: RX authentication from 00:11:2f:0e:95:a0 (alg=0 transaction=2 status=0) Oct 31 01:06:05 amd kernel: wlan0: authenticated Oct 31 01:06:05 amd kernel: wlan0: associate with AP 00:11:2f:0e:95:a0 Oct 31 01:06:05 amd kernel: wlan0: RX AssocResp from 00:11:2f:0e:95:a0 (capab=0x401 status=0 aid=1) Oct 31 01:06:05 amd kernel: wlan0: associated Oct 31 01:06:05 amd kernel: wlan0: switched to short barker preamble (BSSID=00:11:2f:0e:95:a0) Oct 31 01:06:05 amd kernel: iwl3945: iwl-3945-rs not selected as rate control algo! Oct 31 01:23:52 amd kernel: wlan0: RX deauthentication from 00:11:2f:0e:95:a0 (reason=4) Oct 31 01:23:52 amd kernel: wlan0: deauthenticated Oct 31 01:23:53 amd kernel: wlan0: authenticate with AP 00:11:2f:0e:95:a0 Oct 31 01:23:53 amd kernel: wlan0: RX authentication from 00:11:2f:0e:95:a0 (alg=0 transaction=2 status=0) Oct 31 01:23:53 amd kernel: wlan0: authenticated Oct 31 01:23:53 amd kernel: wlan0: associate with AP 00:11:2f:0e:95:a0 Oct 31 01:23:53 amd kernel: wlan0: RX ReassocResp from 00:11:2f:0e:95:a0 (capab=0x401 status=0 aid=1) Oct 31 01:23:53 amd kernel: wlan0: associated Oct 31 01:23:53 amd kernel: wlan0: switched to short barker preamble (BSSID=00:11:2f:0e:95:a0) Oct 31 01:23:53 amd kernel: iwl3945: iwl-3945-rs not selected as rate control algo! Oct 31 01:23:53 amd kernel: wlan0: CTS protection enabled (BSSID=00:11:2f:0e:95:a0) Oct 31 01:23:53 amd kernel: wlan0: switched to long barker preamble (BSSID=00:11:2f:0e:95:a0) Oct 31 01:35:44 amd -- MARK -- Oct 31 01:38:16 amd kernel: iwl3945: Microcode SW error detected. Restarting 0x8208. Oct 31 01:38:16 amd kernel: iwl3945: Error Reply type 0x0005 cmd REPLY_TX (0x1C) seq 0x0267 ser 0x004B Oct 31 01:38:18 amd kernel: iwl3945: Can't stop Rx DMA. ...unfortunately, microcode sources are not available so Intel should fix this, right? (Actually, it recovered after 3 minutes): Oct 31 01:41:15 amd kernel: wlan0: RX deauthentication from 00:11:2f:0e:95:a0 (reason=4) Oct 31 01:41:15 amd kernel: wlan0: deauthenticated Oct 31 01:41:16 amd kernel: wlan0: authenticate with AP 00:11:2f:0e:95:a0 Oct 31 01:41:16 amd kernel: wlan0: RX authentication from 00:11:2f:0e:95:a0 (alg=0 transaction=2 status=0) Oct 31 01:41:16 amd kernel: wlan0: authenticated Oct 31 01:41:16 amd kernel: wlan0: associate with AP 00:11:2f:0e:95:a0 Oct 31 01:41:16 amd kernel: wlan0: RX ReassocResp from 00:11:2f:0e:95:a0 (capab=0x401 status=0 aid=1) Oct 31 01:41:16 amd kernel: wlan0: associated Oct 31 01:41:16 amd kernel: wlan0: CTS protection enabled (BSSID=00:11:2f:0e:95:a0) Oct 31 01:41:16 amd kernel: iwl3945: iwl-3945-rs not selected as rate control algo! Oct 31 01:41:16 amd kernel: wlan0: switched to short barker preamble (BSSID=00:11:2f:0e:95:a0) Hmm, and it is pretty reproducible, with: tcpspray -n 1 -b 1000 10.0.0.2 Oct 31 01:42:56 amd kernel: iwl3945: Microcode SW error detected. Restarting 0x8208. Oct 31 01:42:56 amd kernel: iwl3945: Error Reply type 0x0005 cmd REPLY_TX (0x1C) seq 0x02C7 ser 0x004B Oct 31 01:42:58 amd kernel: iwl3945: Can't stop Rx DMA. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] swsusp: Use platform mode by default
On Wednesday, 17 October 2007 05:44, Qi Yong wrote: On Wed, Oct 17, 2007 at 10:46:12AM +0800, Qi Yong wrote: On 12/05/2007, Linus Torvalds [EMAIL PROTECTED] wrote: On Fri, 11 May 2007, Rafael J. Wysocki wrote: [--snip--] please apply. Signed-off-by: Qi Yong [EMAIL PROTECTED] --- With your patch applied the default for ACPI systems changes from HIBERNATION_PLATFORM to HIBERNATION_SHUTDOWN. However, it has been HIBERNATION_PLATFORM since 2.6.20 and I'd really prefer it to stay this way. If HIBERNATION_PLATFORM doesn't work for you, please do echo shutdown /sys/power/disk before hibernation or, if you use the userland suspend tools, change the s2disk's configuration file to use the shutdown mode. diff --git a/kernel/power/disk.c b/kernel/power/disk.c index eb72255..95b66ee 100644 --- a/kernel/power/disk.c +++ b/kernel/power/disk.c @@ -61,9 +61,11 @@ void hibernation_set_ops(struct hibernation_ops *ops) } mutex_lock(pm_mutex); hibernation_ops = ops; - if (ops) - hibernation_mode = HIBERNATION_PLATFORM; - else if (hibernation_mode == HIBERNATION_PLATFORM) + + /* + * Turn off HIBERNATION_PLATFORM if we no longer have any platform ops. + */ + if (!ops hibernation_mode == HIBERNATION_PLATFORM) hibernation_mode = HIBERNATION_SHUTDOWN; mutex_unlock(pm_mutex); Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.23-git3: Many sysfs-related warnings in dmesg
On Wednesday, 17 October 2007 12:17, Kay Sievers wrote: On 10/17/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Tuesday, 16 October 2007 23:36, Greg KH wrote: On Tue, Oct 16, 2007 at 11:13:19PM +0200, Rafael J. Wysocki wrote: On Tuesday, 16 October 2007 22:50, Jens Axboe wrote: On Tue, Oct 16 2007, Greg KH wrote: On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote: On Tuesday, 16 October 2007 06:50, Greg KH wrote: On Sat, Oct 13, 2007 at 09:26:32PM +0200, Rafael J. Wysocki wrote: Hi, There are many traces like this in my dmesg from 2.6.23-git3 (they don't appear for vanilla 2.6.23): 4sysfs: duplicate filename 'ethxx1' can not be created WARNING: at /home/rafael/src/linux-2.6/fs/sysfs/dir.c:425 sysfs_add_one() Call Trace: [802d1532] sysfs_add_one+0x5c/0xc9 [802d2411] sysfs_create_link+0xd1/0x12c [803756da] device_rename+0x17a/0x1db [803c903d] dev_change_name+0x114/0x20c [803c9339] dev_ifsioc+0x204/0x2d0 [803c9925] dev_ioctl+0x520/0x633 [803bf445] sk_alloc+0x37/0x10c [8024b977] up_read+0x9/0xb [803bc65e] sock_ioctl+0x1fe/0x20c [8029b34a] do_ioctl+0x2a/0x77 [8029b5e8] vfs_ioctl+0x251/0x26e [8029b664] sys_ioctl+0x5f/0x83 [8020bd4e] system_call+0x7e/0x83 net ethxx1: device_rename: sysfs_create_symlink failed (-17) sysfs: duplicate filename 'eth1' can not be created Everything seems to work, but this just looks fishy. This is a userspace program renaming your network device to a name that is already in use. What distro and release is this? openSUSE 10.2, with some updates (not the most recent, though). Can you try 10.3? I think we fixed this issue there. Ehm nope: Oct 16 19:36:27 carl kernel: sysfs: duplicate filename 'wlan0_rename' can not be created Oct 16 19:36:27 carl kernel: udev: renamed network interface wmaster0 to eth1 Oct 16 19:36:27 carl kernel: WARNING: at fs/sysfs/dir.c:425 sysfs_add_one() Oct 16 19:36:27 carl kernel: [c01b2dbf] sysfs_add_one+0x9f/0xe0 Oct 16 19:36:27 carl kernel: [c01b3b76] sysfs_create_link+0x86/0x110 Oct 16 19:36:27 carl kernel: [c02398ca] device_rename+0x17a/0x1e0 Oct 16 19:36:27 carl kernel: [c015b56f] filemap_fault+0x1ff/0x400 Oct 16 19:36:27 carl kernel: [c02b8fc0] dev_change_name+0xb0/0x210 Oct 16 19:36:27 carl kernel: [c02b9779] dev_ioctl+0x3c9/0x530 Oct 16 19:36:27 carl kernel: [c01a1938] inotify_d_instantiate+0x18/0x80 Oct 16 19:36:27 carl kernel: [c0120044] do_page_fault+0x4a4/0x6f0 Oct 16 19:36:27 carl kernel: [c02ac080] sock_ioctl+0x0/0x220 Oct 16 19:36:27 carl kernel: [c01851ab] do_ioctl+0x2b/0x90 Oct 16 19:36:27 carl kernel: [c02ad50b] sys_socket+0x2b/0x50 Oct 16 19:36:27 carl kernel: [c018542e] vfs_ioctl+0x21e/0x2a0 Oct 16 19:36:27 carl kernel: [c01854ed] sys_ioctl+0x3d/0x70 Oct 16 19:36:27 carl kernel: [c01042d6] sysenter_past_esp+0x6b/0xa1 Oct 16 19:36:27 carl kernel: === Oct 16 19:36:27 carl kernel: net wlan0_rename: device_rename: sysfs_create_symlink failed (-17) Plus it doesn't happen on 2.6.23 on my system, so I count it as a regression. It's a new warning I've added to the kernel to catch stupid userspace and kernel code that is quietly failing when they are doing things incorrectly with kobjects and sysfs. So it's not really a regression in that we never notified anyone of this kind of thing before, think of it as a new feature :) Well, it seems to be a little bit over the top, then. ;-) In the network renaming it's a bit noisy, yes, but for other users which we discovered by this, it already exposed real bugs. Is it possible to change udev rules to avoid the warnings on openSUSE 10.2? Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH -mm] Freezer: Do not allow freezing processes to clear TIF_SIGPENDING
From: Rafael J. Wysocki [EMAIL PROTECTED]
Do not allow processes to clear their TIF_SIGPENDING if TIF_FREEZE is set,
to prevent them from racing with the freezer (like mysqld does, for example).
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/signal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-mm1/kernel/signal.c
===
--- linux-2.6.23-mm1.orig/kernel/signal.c
+++ linux-2.6.23-mm1/kernel/signal.c
@@ -124,7 +124,7 @@ void recalc_sigpending_and_wake(struct t
void recalc_sigpending(void)
{
- if (!recalc_sigpending_tsk(current))
+ if (!recalc_sigpending_tsk(current) !freezing(current))
clear_thread_flag(TIF_SIGPENDING);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm] Freezer: Do not allow freezing processes to clear TIF_SIGPENDING
On Friday, 19 October 2007 09:55, Pavel Machek wrote: On Fri 2007-10-19 00:22:35, Rafael J. Wysocki wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] Do not allow processes to clear their TIF_SIGPENDING if TIF_FREEZE is set, to prevent them from racing with the freezer (like mysqld does, for example). Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] ACK. We want this in 2.6.24. Sure, we do. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mysqld prevents s2ram [Re: 2.6.23-mm1]
On Sunday, 21 October 2007 11:58, Pavel Machek wrote:
Hi!
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
Ok, now that it boots let's go for more.
I cannot suspend if mysqld is running. mysql isn't atually doing
anything useful anyway.
I believe this is known and rafael already has a fix somewhere. The
guilty patch already hit mainline, not sure about the fix patch.
The fix has not been merged yet, but
freezer-use-wait-queue-instead-of-busy-looping.patch has been dropped for
another reason.
The mysqld problem seems to have been caused by another patch, though, and the
fix is appended.
Greetings,
Rafael
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Do not allow processes to clear their TIF_SIGPENDING if TIF_FREEZE is set,
so that they will not race with the freezer (like mysqld, for example).
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/signal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-mm1/kernel/signal.c
===
--- linux-2.6.23-mm1.orig/kernel/signal.c
+++ linux-2.6.23-mm1/kernel/signal.c
@@ -124,7 +124,7 @@ void recalc_sigpending_and_wake(struct t
void recalc_sigpending(void)
{
- if (!recalc_sigpending_tsk(current))
+ if (!recalc_sigpending_tsk(current) !freezing(current))
clear_thread_flag(TIF_SIGPENDING);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Resume problems
On Monday, 22 October 2007 18:15, Gabriel C wrote: Hi all , I'm running current git + aic7xxx suspend patch from http://bugzilla.kernel.org/show_bug.cgi?id=3062 on a Dell Precision WorkStation 530 MT SMP box ( HT enabled ). Suspend works fine but on resume I have some problems. All CPU's but boot CPU won't come back , everything else seems fine. Can you please try to disable HT and suspend? ... Oct 22 15:02:28 lara [ 49.618795] Enabling non-boot CPUs ... Oct 22 15:02:28 lara [ 49.622211] PM: Adding info for No Bus:msr1 Oct 22 15:02:28 lara [ 49.622259] PM: Adding info for No Bus:cpu1 Oct 22 15:02:28 lara [ 49.622302] SMP alternatives: switching to SMP code Oct 22 15:02:28 lara [ 49.623536] Booting processor 1/1 eip 3000 Oct 22 15:02:28 lara [ 54.638093] Not responding. Oct 22 15:02:28 lara [ 54.638096] Inquiring remote APIC #1... Oct 22 15:02:28 lara [ 54.638099] ... APIC #1 ID: failed Oct 22 15:02:28 lara [ 54.638204] ... APIC #1 VERSION: failed Oct 22 15:02:28 lara [ 54.638307] ... APIC #1 SPIV: failed Oct 22 15:02:28 lara [ 54.638427] skipping cpu1, didn't come online Oct 22 15:02:28 lara [ 54.638602] PM: Removing info for No Bus:msr1 Oct 22 15:02:28 lara [ 54.638643] PM: Removing info for No Bus:cpu1 Oct 22 15:02:28 lara [ 54.638678] Error taking CPU1 up: -5 Oct 22 15:02:28 lara [ 54.640908] PM: Adding info for No Bus:msr2 Oct 22 15:02:28 lara [ 54.640939] PM: Adding info for No Bus:cpu2 Oct 22 15:02:28 lara [ 54.640976] SMP alternatives: switching to SMP code Oct 22 15:02:28 lara [ 54.641961] Booting processor 2/2 eip 3000 Oct 22 15:02:28 lara [ 59.656795] Not responding. Oct 22 15:02:28 lara [ 59.656799] Inquiring remote APIC #2... Oct 22 15:02:28 lara [ 59.656803] ... APIC #2 ID: failed Oct 22 15:02:28 lara [ 59.656907] ... APIC #2 VERSION: failed Oct 22 15:02:28 lara [ 59.657011] ... APIC #2 SPIV: failed Oct 22 15:02:28 lara [ 59.657131] skipping cpu2, didn't come online Oct 22 15:02:28 lara [ 59.657300] PM: Removing info for No Bus:msr2 Oct 22 15:02:28 lara [ 59.657343] PM: Removing info for No Bus:cpu2 Oct 22 15:02:28 lara [ 59.657379] Error taking CPU2 up: -5 Oct 22 15:02:28 lara [ 59.659605] PM: Adding info for No Bus:msr3 Oct 22 15:02:28 lara [ 59.659637] PM: Adding info for No Bus:cpu3 Oct 22 15:02:28 lara [ 59.659673] SMP alternatives: switching to SMP code Oct 22 15:02:28 lara [ 59.660725] Booting processor 3/3 eip 3000 Oct 22 15:02:28 lara [ 64.675517] Not responding. Oct 22 15:02:28 lara [ 64.675520] Inquiring remote APIC #3... Oct 22 15:02:28 lara [ 64.675524] ... APIC #3 ID: failed Oct 22 15:02:28 lara [ 64.675628] ... APIC #3 VERSION: failed Oct 22 15:02:28 lara [ 64.675731] ... APIC #3 SPIV: failed Oct 22 15:02:28 lara [ 64.675859] skipping cpu3, didn't come online Oct 22 15:02:28 lara [ 64.676017] PM: Removing info for No Bus:msr3 Oct 22 15:02:28 lara [ 64.676059] PM: Removing info for No Bus:cpu3 Oct 22 15:02:28 lara [ 64.676092] Error taking CPU3 up: -5 Oct 22 15:02:28 lara [ 64.676326] evxfevnt-0079 [00] enable : System is already in ACPI mode ... After I've played with a lot boot options I found out booting with ' acpi=ht ' will make the CPU's work again but now I have a problem on Suspend. Everything seems to just go down disks etc but the box itself is for some reason still on. So I've tested reboot= options with no luck. ( after waiting 5 minutes to be sure everything is really off I can just hit power button). On resume now everything is fine. I'm not really sure what is wrong here acpi/hibernation/cpu-hotplug or a mix of all so I'm CC'ing linux-acpi as well. The only thing I noticed is the 'Breaking affinity for irq XX' on suspend without acpi=ht messages. I can't even tell whatever other kernel versions are working because aic7xxx driver didn't got suspend support till now ( or at least never worked here ). I know suspend worked fine on windows with that box. There is my config and dmesg ( good and bad one ) : http://194.231.229.228/suspend/acpi=ht_working_dmesg.txt http://194.231.229.228/suspend/dmesg_broken_cpus_on_resume.txt http://194.231.229.228/suspend/config Well, I think we have a problem with the CPU hotplug. Can you try to offline-online CPUs (without suspending) and see if that works? Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: 2.6.23-rc9 okay, 2.6.23.1 resume problems
On Monday, 22 October 2007 16:11, Mark Lord wrote: Rafael, What happens to the jiffies variable on resume from RAM, and from DISK? Do we restore it to the value it had at suspend, or just leave it be with whatever? The answer has to be restore the value it had at suspend time, but I figured I'd check here anyway. ?? Well, frankly, I've lost track of that recently, but it seems that we just use the pre-suspend jiffies (at least in the current -git). Thomas knows better, I guess. :-) Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resume problems
On Tuesday, 23 October 2007 01:00, Gabriel C wrote: Rafael J. Wysocki wrote: On Monday, 22 October 2007 18:15, Gabriel C wrote: Hi all , I'm running current git + aic7xxx suspend patch from http://bugzilla.kernel.org/show_bug.cgi?id=3062 on a Dell Precision WorkStation 530 MT SMP box ( HT enabled ). Suspend works fine but on resume I have some problems. All CPU's but boot CPU won't come back , everything else seems fine. Can you please try to disable HT and suspend? So only 'Hibernation' is enabled in kernel and HT disabled in BIOS ? If you mean that , sure I can try doing so. With suspend or hibernation enabled in the kernel, but with HT disabled in the BIOS. I also could disable Suspend to RAM completly from BIOS as well if you want. No, that rather won't work. ... Oct 22 15:02:28 lara [ 49.618795] Enabling non-boot CPUs ... Oct 22 15:02:28 lara [ 49.622211] PM: Adding info for No Bus:msr1 Oct 22 15:02:28 lara [ 49.622259] PM: Adding info for No Bus:cpu1 Oct 22 15:02:28 lara [ 49.622302] SMP alternatives: switching to SMP code Oct 22 15:02:28 lara [ 49.623536] Booting processor 1/1 eip 3000 Oct 22 15:02:28 lara [ 54.638093] Not responding. Oct 22 15:02:28 lara [ 54.638096] Inquiring remote APIC #1... Oct 22 15:02:28 lara [ 54.638099] ... APIC #1 ID: failed Oct 22 15:02:28 lara [ 54.638204] ... APIC #1 VERSION: failed Oct 22 15:02:28 lara [ 54.638307] ... APIC #1 SPIV: failed Oct 22 15:02:28 lara [ 54.638427] skipping cpu1, didn't come online Oct 22 15:02:28 lara [ 54.638602] PM: Removing info for No Bus:msr1 Oct 22 15:02:28 lara [ 54.638643] PM: Removing info for No Bus:cpu1 Oct 22 15:02:28 lara [ 54.638678] Error taking CPU1 up: -5 Oct 22 15:02:28 lara [ 54.640908] PM: Adding info for No Bus:msr2 Oct 22 15:02:28 lara [ 54.640939] PM: Adding info for No Bus:cpu2 Oct 22 15:02:28 lara [ 54.640976] SMP alternatives: switching to SMP code Oct 22 15:02:28 lara [ 54.641961] Booting processor 2/2 eip 3000 Oct 22 15:02:28 lara [ 59.656795] Not responding. Oct 22 15:02:28 lara [ 59.656799] Inquiring remote APIC #2... Oct 22 15:02:28 lara [ 59.656803] ... APIC #2 ID: failed Oct 22 15:02:28 lara [ 59.656907] ... APIC #2 VERSION: failed Oct 22 15:02:28 lara [ 59.657011] ... APIC #2 SPIV: failed Oct 22 15:02:28 lara [ 59.657131] skipping cpu2, didn't come online Oct 22 15:02:28 lara [ 59.657300] PM: Removing info for No Bus:msr2 Oct 22 15:02:28 lara [ 59.657343] PM: Removing info for No Bus:cpu2 Oct 22 15:02:28 lara [ 59.657379] Error taking CPU2 up: -5 Oct 22 15:02:28 lara [ 59.659605] PM: Adding info for No Bus:msr3 Oct 22 15:02:28 lara [ 59.659637] PM: Adding info for No Bus:cpu3 Oct 22 15:02:28 lara [ 59.659673] SMP alternatives: switching to SMP code Oct 22 15:02:28 lara [ 59.660725] Booting processor 3/3 eip 3000 Oct 22 15:02:28 lara [ 64.675517] Not responding. Oct 22 15:02:28 lara [ 64.675520] Inquiring remote APIC #3... Oct 22 15:02:28 lara [ 64.675524] ... APIC #3 ID: failed Oct 22 15:02:28 lara [ 64.675628] ... APIC #3 VERSION: failed Oct 22 15:02:28 lara [ 64.675731] ... APIC #3 SPIV: failed Oct 22 15:02:28 lara [ 64.675859] skipping cpu3, didn't come online Oct 22 15:02:28 lara [ 64.676017] PM: Removing info for No Bus:msr3 Oct 22 15:02:28 lara [ 64.676059] PM: Removing info for No Bus:cpu3 Oct 22 15:02:28 lara [ 64.676092] Error taking CPU3 up: -5 Oct 22 15:02:28 lara [ 64.676326] evxfevnt-0079 [00] enable : System is already in ACPI mode ... After I've played with a lot boot options I found out booting with ' acpi=ht ' will make the CPU's work again but now I have a problem on Suspend. Everything seems to just go down disks etc but the box itself is for some reason still on. So I've tested reboot= options with no luck. ( after waiting 5 minutes to be sure everything is really off I can just hit power button). On resume now everything is fine. I'm not really sure what is wrong here acpi/hibernation/cpu-hotplug or a mix of all so I'm CC'ing linux-acpi as well. The only thing I noticed is the 'Breaking affinity for irq XX' on suspend without acpi=ht messages. I can't even tell whatever other kernel versions are working because aic7xxx driver didn't got suspend support till now ( or at least never worked here ). I know suspend worked fine on windows with that box. There is my config and dmesg ( good and bad one ) : http://194.231.229.228/suspend/acpi=ht_working_dmesg.txt http://194.231.229.228/suspend/dmesg_broken_cpus_on_resume.txt http://194.231.229.228/suspend/config Well, I think we have a problem with the CPU hotplug. Can you try to offline-online CPUs (without suspending) and see if that works? Yes does work when I do it manually : [ 6687.595842] CPU 1 is now offline [ 6687.711425] CPU 2 is now
Re: [BUG] rfcomm]
On Tuesday, 23 October 2007 19:57, Alon Bar-Lev wrote: On 10/23/07, Marcel Holtmann [EMAIL PROTECTED] wrote: first of all, please check if this still happens with 2.6.23, because we had some patches in the area of the RFCOMM TTY code that might have fixed this. These messages are of 2.6.23. Second, can you try without uswsusp or suspend2. Both of them are not upstream and I can't tell how much these would effect this kind of behavior. How can I test this without doing suspend? uswsusp is not upstream?!?! Rafael? It is upstream and is supposed to work. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Freezer: Do not allow freezing processes to clear TIF_SIGPENDING
[Please consider as 2.6.24 material.]
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Do not allow processes to clear their TIF_SIGPENDING if TIF_FREEZE is set,
so that they will not race with the freezer (like mysqld does, for example).
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Nigel Cunningham [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
---
kernel/signal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23/kernel/signal.c
===
--- linux-2.6.23.orig/kernel/signal.c
+++ linux-2.6.23/kernel/signal.c
@@ -124,7 +124,7 @@ void recalc_sigpending_and_wake(struct t
void recalc_sigpending(void)
{
- if (!recalc_sigpending_tsk(current))
+ if (!recalc_sigpending_tsk(current) !freezing(current))
clear_thread_flag(TIF_SIGPENDING);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Resume problems
On Tuesday, 23 October 2007 03:01, Gabriel C wrote: Also box just froze on level 3 but I got a ACPI error at least which I didn't got in any other dmesg till now : ( also patch was tested with HT disabled and Suspend and Hibernation enabled in kernel and BIOS ) ... Oct 23 01:51:05 lara [ 273.512374] PM: Removing info for No Bus:input0 Oct 23 01:51:05 lara [ 274.545158] PM: Removing info for No Bus:mouse0 Oct 23 01:51:05 lara [ 274.551435] PM: Removing info for No Bus:event1 Oct 23 01:51:05 lara [ 274.559493] PM: Removing info for No Bus:input1 Oct 23 01:53:06 lara [ 394.869468] ACPI Error (evevent-0303): No installed handler for fixed event [0002] [20070126] ( I hard reseted after that ) I try level 2 and 1 now I just wanted to let you know. Same issues with level 2 and 1. Yes. If you have a problem at level n, it should always reappear for n-1 etc. BTW I found out why my box does not shutdown with acpi=ht. It seems like libata does not like that acpi mode =) dropping the '... read http://linux-ata.org/shutdown.html , power down manually' message. That works perfectly with full acpi here. After all I think all this problems may be some who ACPI related but the question is why they get triggered by Suspend/Hibernation. They certainly are ACPI-related, because the only difference between level 4 and level 3 suspend testing is that some global ACPI methods are executed at level 3 (in addition to level 4). Unfortunately, I have no idea what to do next, for now. I think you can file a bug report at http://bugzilla.kernel.org and put a link to this thread in there (against ACPI and please add my address to the CC list). Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Thursday, 11 October 2007 22:54, Pavel Machek wrote: Hi! That's certainly possible. We already pass a very small amount of data between the boot and resuming kernels at the moment, and it's done quite simply - by putting the variables we want to 'transfer' in a nosave page/section. Well, if the boot and image kernels are different, which is now possible on x86_64 with some recent patches (currently in -mm), the nosave trick won't work. I guess we should remove the nosave at least from x86-64. If someone tries to use it, he'll get a nasty surprise. Agreed. I'll try to prepare a patch for that when I have a bit of time. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] full suspend/resume support for i915 DRM driver
On Wednesday, 24 October 2007 17:18, Jesse Barnes wrote: On Wednesday, October 24, 2007 6:35:14 am Pavel Machek wrote: Hi! We seem to see a lot of bug reports along the lines of, my machine resumes but I can't see X or, I can see X but only with a bright flashlight, etc. These sorts of problems are due to the fact that the X server isn't designed to do full state save/restore, and none of the available kernel drivers do it on its behalf. Since intelfb and the rest of the Intel drivers are fairly incompatible, this patch makes the DRM bind to the PCI device so it can register real suspend/resume handlers. Those handlers take care of saving and restoring enough state for X to come back reliably on at least one of my problematic test machines, but text mode still has trouble (still debugging VGA state save/restore, including trying to save/restore actual VRAM contents for possible hibernate support). How does this approach look? Is a new DRM driver flag a good thing for similar situations with other drivers? Thoughts? Looks okay to me... from very quick look. + if (!i915_pipe_enabled(dev, pipe)) + return; + + if (pipe == PIPE_A) + array = dev_priv-savePaletteA; coding style, we probably want save_palette_A. Yeah, I tried not to pull over uglies from the X code but I guess I forgot this bit. I should also update the copyright. + unsigned long reg = pipe == PIPE_A ? PALETTE_A : PALETTE_B; Uff. Mixing = and == and ? in one expression is evil. I could put parens around it if you think that would help, or just move it to a new line... I'd use parens around pipe == PIPE_A. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Friday, 8 of February 2008, Pavel Machek wrote:
Hi!
Rafael, this is for you.
Thanks.
My cleanups, relative to your cleanup patch. You may need manual patching
around rep/stosd.
OK, I'll try to merge it.
Rafael
diff --git a/arch/x86/kernel/acpi/realmode/Makefile
b/arch/x86/kernel/acpi/realmode/Makefile
index b239f0f..0e4742b 100644
--- a/arch/x86/kernel/acpi/realmode/Makefile
+++ b/arch/x86/kernel/acpi/realmode/Makefile
@@ -46,7 +46,10 @@ KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__AS
WAKEUP_OBJS = $(addprefix $(obj)/,$(wakeup-y))
LDFLAGS_wakeup.elf := -T
-$(obj)/wakeup.elf: $(src)/wakeup.ld $(WAKEUP_OBJS) FORCE
+
+CPPFLAGS_wakeup.lds += -P -C
+
+$(obj)/wakeup.elf: $(src)/wakeup.lds $(WAKEUP_OBJS) FORCE
$(call if_changed,ld)
OBJCOPYFLAGS_wakeup.bin := -O binary
diff --git a/arch/x86/kernel/acpi/realmode/wakeup.S
b/arch/x86/kernel/acpi/realmode/wakeup.S
index 26145c0..edff763 100644
--- a/arch/x86/kernel/acpi/realmode/wakeup.S
+++ b/arch/x86/kernel/acpi/realmode/wakeup.S
@@ -56,14 +56,6 @@ _start:
cmpl$0x65a22c82, %eax
jne bogus_real_magic
- /* Zero the bss */
- xorl%eax, %eax
- movw$__bss_start, %di
- movw$__bss_end + 3, %cx
- subw%di, %cx
- shrw$2, %cx
- rep; stosl
-
/* Call the C code */
calll main
diff --git a/arch/x86/kernel/acpi/realmode/wakeup.h
b/arch/x86/kernel/acpi/realmode/wakeup.h
index 4a26e27..6a49435 100644
--- a/arch/x86/kernel/acpi/realmode/wakeup.h
+++ b/arch/x86/kernel/acpi/realmode/wakeup.h
@@ -6,12 +6,11 @@
#ifndef ARCH_X86_KERNEL_ACPI_RM_WAKEUP_H
#define ARCH_X86_KERNEL_ACPI_RM_WAKEUP_H
+#ifndef __ASSEMBLY__
#include linux/types.h
/* This must match data at wakeup.S */
struct wakeup_header {
- u16 entry; /* unused */
- u16 total; /* unused */
u16 video_mode; /* Video mode number */
u16 _jmp1;
u32 pmode_entry;/* Protected mode resume point */
@@ -27,5 +26,10 @@ struct wakeup_header {
u16 trampoline_segment;
u32 signature; /* To check we have correct structure */
} __attribute__((__packed__));
+#endif
+
+#define HEADER_OFFSET 0x3f00
+#define WAKEUP_SIZE 0x4000
+
#endif /* ARCH_X86_KERNEL_ACPI_RM_WAKEUP_H */
diff --git a/arch/x86/kernel/acpi/realmode/wakeup.ld
b/arch/x86/kernel/acpi/realmode/wakeup.ld
deleted file mode 100644
index 5dff2f0..000
--- a/arch/x86/kernel/acpi/realmode/wakeup.ld
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * wakeup.ld
- *
- * Linker script for the real-mode wakeup code
- */
-OUTPUT_FORMAT(elf32-i386, elf32-i386, elf32-i386)
-OUTPUT_ARCH(i386)
-ENTRY(_start)
-
-SECTIONS
-{
- . = 0x3f00;
- .header : { *(.header) }
-
- . = 0;
- .text : { *(.text*) }
-
- . = ALIGN(16);
- .rodata : { *(.rodata*) }
-
- .videocards : {
- video_cards = .;
- *(.videocards)
- video_cards_end = .;
- }
-
- . = ALIGN(16);
- .data : { *(.data*) }
-
- .signature : {
- end_signature = .;
- LONG(0x65a22c82)
- }
-
- . = ALIGN(16);
- .bss:
- {
- __bss_start = .;
- *(.bss)
- __bss_end = .;
- }
-
- . = ALIGN(16);
- _end = .;
-
- /DISCARD/ : { *(.note*) }
-
- /* Adjust this as appropriate */
- /* This allows 4 pages (16K) */
- . = ASSERT(_end = 0x4000, Wakeup too big!);
-}
diff --git a/arch/x86/kernel/acpi/realmode/wakeup.lds.S
b/arch/x86/kernel/acpi/realmode/wakeup.lds.S
new file mode 100644
index 000..22fab6c
--- /dev/null
+++ b/arch/x86/kernel/acpi/realmode/wakeup.lds.S
@@ -0,0 +1,61 @@
+/*
+ * wakeup.ld
+ *
+ * Linker script for the real-mode wakeup code
+ */
+#undef i386
+#include wakeup.h
+
+OUTPUT_FORMAT(elf32-i386, elf32-i386, elf32-i386)
+OUTPUT_ARCH(i386)
+ENTRY(_start)
+
+SECTIONS
+{
+ . = HEADER_OFFSET;
+ .header : {
+ *(.header)
+ }
+
+ . = 0;
+ .text : {
+ *(.text*)
+ }
+
+ . = ALIGN(16);
+ .rodata : {
+ *(.rodata*)
+ }
+
+ .videocards : {
+ video_cards = .;
+ *(.videocards)
+ video_cards_end = .;
+ }
+
+ . = ALIGN(16);
+ .data : {
+ *(.data*)
+ }
+
+ .signature : {
+ end_signature = .;
+ LONG(0x65a22c82)
+ }
+
+ . = ALIGN(16);
+ .bss : {
+ __bss_start = .;
+ *(.bss)
+ __bss_end = .;
+ }
+
+ . = ALIGN(16);
+ _end = .;
+
+ /DISCARD/ : {
+ *(.note*)
+ }
+
+ . = ASSERT(_end = WAKEUP_SIZE, Wakeup too big!);
+}
diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Friday, 8 of February 2008, Pavel Machek wrote: On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote: Pavel Machek wrote: See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent to the list). No problem there, but table stored at nonzero offset. Short jump at the beggining of table would fix it (ugly). Ugly, but it's the standard way to deal. We have it in the bzImage format, too. I'd prefer to keep it as it is, there are no problems. This way, we can put debugging instructions at the first byte of wakeup code, which is somehow important. Plus, with right #defines, it should be clean enough. Well, I don't know how to evaluate #defines in *.ld files ... Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Friday, 8 of February 2008, Pavel Machek wrote:
On Fri 2008-02-08 23:01:51, Rafael J. Wysocki wrote:
On Friday, 8 of February 2008, Pavel Machek wrote:
Hi!
Rafael, this is for you.
Thanks.
My cleanups, relative to your cleanup patch. You may need manual patching
around rep/stosd.
OK, I'll try to merge it.
For the record, now it is even tested on 32-bit and test-compiled on
64-bit.
Consolidated patch is appended. I'll test it tomorrow on x86-64.
I'd like to add the cleaned up beeping code to it and perhaps try to push it
for -mm testing without any further changes. We can still do more cleanups in
followup patches.
Thanks,
Rafael
---
arch/x86/boot/Makefile |2
arch/x86/boot/boot.h |5
arch/x86/boot/video-bios.c |6
arch/x86/boot/video-mode.c | 173
arch/x86/boot/video-vesa.c |8
arch/x86/boot/video-vga.c | 12 -
arch/x86/boot/video.c | 157 --
arch/x86/kernel/acpi/Makefile |9
arch/x86/kernel/acpi/realmode/Makefile | 58 +
arch/x86/kernel/acpi/realmode/copy.S |1
arch/x86/kernel/acpi/realmode/video-bios.c |1
arch/x86/kernel/acpi/realmode/video-mode.c |1
arch/x86/kernel/acpi/realmode/video-vesa.c |1
arch/x86/kernel/acpi/realmode/video-vga.c |1
arch/x86/kernel/acpi/realmode/wakemain.c | 26 ++
arch/x86/kernel/acpi/realmode/wakeup.S | 113 ++
arch/x86/kernel/acpi/realmode/wakeup.h | 35 +++
arch/x86/kernel/acpi/realmode/wakeup.lds.S | 61 +
arch/x86/kernel/acpi/sleep.c | 80 ++-
arch/x86/kernel/acpi/wakeup_32.S | 245 +-
arch/x86/kernel/acpi/wakeup_64.S | 313 -
arch/x86/kernel/acpi/wakeup_rm.S | 10
arch/x86/kernel/head_64.S |4
arch/x86/kernel/setup_32.c |4
arch/x86/kernel/smpboot_64.c | 10
25 files changed, 624 insertions(+), 712 deletions(-)
Index: linux-2.6/arch/x86/boot/Makefile
===
--- linux-2.6.orig/arch/x86/boot/Makefile
+++ linux-2.6/arch/x86/boot/Makefile
@@ -30,7 +30,7 @@ subdir- := compressed
setup-y+= a20.o cmdline.o copy.o cpu.o cpucheck.o edd.o
setup-y+= header.o main.o mca.o memory.o pm.o pmjump.o
-setup-y+= printf.o string.o tty.o video.o version.o
+setup-y+= printf.o string.o tty.o video.o video-mode.o
version.o
setup-$(CONFIG_X86_APM_BOOT) += apm.o
setup-$(CONFIG_X86_VOYAGER) += voyager.o
Index: linux-2.6/arch/x86/boot/boot.h
===
--- linux-2.6.orig/arch/x86/boot/boot.h
+++ linux-2.6/arch/x86/boot/boot.h
@@ -286,6 +286,11 @@ int getchar_timeout(void);
/* video.c */
void set_video(void);
+/* video-mode.c */
+int set_mode(u16 mode);
+int mode_defined(u16 mode);
+void probe_cards(int unsafe);
+
/* video-vesa.c */
void vesa_store_edid(void);
Index: linux-2.6/arch/x86/boot/video-bios.c
===
--- linux-2.6.orig/arch/x86/boot/video-bios.c
+++ linux-2.6/arch/x86/boot/video-bios.c
@@ -50,6 +50,7 @@ static int set_bios_mode(u8 mode)
if (new_mode == mode)
return 0; /* Mode change OK */
+#ifndef _WAKEUP
if (new_mode != boot_params.screen_info.orig_video_mode) {
/* Mode setting failed, but we didn't end up where we
started. That's bad. Try to revert to the original
@@ -59,13 +60,18 @@ static int set_bios_mode(u8 mode)
: +a (ax)
: : ebx, ecx, edx, esi, edi);
}
+#endif
return -1;
}
static int bios_probe(void)
{
u8 mode;
+#ifdef _WAKEUP
+ u8 saved_mode = 0x03;
+#else
u8 saved_mode = boot_params.screen_info.orig_video_mode;
+#endif
u16 crtc;
struct mode_info *mi;
int nmodes = 0;
Index: linux-2.6/arch/x86/boot/video-mode.c
===
--- /dev/null
+++ linux-2.6/arch/x86/boot/video-mode.c
@@ -0,0 +1,173 @@
+/* -*- linux-c -*- --- *
+ *
+ * Copyright (C) 1991, 1992 Linus Torvalds
+ * Copyright 2007-2008 rPath, Inc. - All Rights Reserved
+ *
+ * This file is part of the Linux kernel, and is made available under
+ * the terms of the GNU General Public License version 2.
+ *
+ * --- */
+
+/*
+ * arch/i386/boot/video-mode.c
+ *
+ * Set the video mode. This is separated out into a different
+ * file in order to be shared with the ACPI wakeup code.
+ */
+
+#include boot.h
Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Saturday, 9 of February 2008, H. Peter Anvin wrote:
Rafael J. Wysocki wrote:
Consolidated patch is appended. I'll test it tomorrow on x86-64.
I'd like to add the cleaned up beeping code to it and perhaps try to push it
for -mm testing without any further changes. We can still do more cleanups
in
followup patches.
The other thing to figure out is to what extent we can clean up the
conditionals in the video mode code by refactoring. All they really do
here is save space by removing functionality not needed for wakeup,
because I didn't know how much space was realistic.
OK, I have an idea.
For now, below is a patch that adds your beeping code to wakemain.c (on top of
the previous one). ;-)
Rafael
---
arch/x86/kernel/acpi/realmode/wakemain.c | 69 ---
1 file changed, 63 insertions(+), 6 deletions(-)
Index: linux-2.6/arch/x86/kernel/acpi/realmode/wakemain.c
===
--- linux-2.6.orig/arch/x86/kernel/acpi/realmode/wakemain.c
+++ linux-2.6/arch/x86/kernel/acpi/realmode/wakemain.c
@@ -3,20 +3,77 @@
extern volatile struct wakeup_header wakeup_header;
+static void udelay(int loops)
+{
+ while (loops--)
+ io_delay(); /* Approximately 1 us */
+}
+
+static void beep(unsigned int hz)
+{
+ u8 enable;
+
+ if (!hz) {
+ enable = 0x00; /* Turn off speaker */
+ } else {
+ u16 div = 1193181/hz;
+
+ outb(0xb6, 0x43); /* Ctr 2, squarewave, load, binary */
+ io_delay();
+ outb(div, 0x42);/* LSB of counter */
+ io_delay();
+ outb(div 8, 0x42); /* MSB of counter */
+ io_delay();
+
+ enable = 0x03; /* Turn on speaker */
+ }
+ inb(0x61); /* Dummy read of System Control Port B */
+ io_delay();
+ outb(enable, 0x61); /* Enable timer 2 output to speaker */
+ io_delay();
+}
+
+#define DOT_HZ 880
+#define DASH_HZ587
+#define US_PER_DOT 125000
+
+/* Okay, this is totally silly, but it's kind of fun. */
+static void send_morse(const char *pattern)
+{
+ char s;
+
+ while ((s = *pattern++)) {
+ switch (s) {
+ case '.':
+ beep(DOT_HZ);
+ udelay(US_PER_DOT);
+ beep(0);
+ udelay(US_PER_DOT);
+ break;
+ case '-':
+ beep(DASH_HZ);
+ udelay(US_PER_DOT * 3);
+ beep(0);
+ udelay(US_PER_DOT);
+ break;
+ default:/* Assume it's a space */
+ udelay(US_PER_DOT * 3);
+ break;
+ }
+ }
+}
+
void main(void)
{
/* Kill machine if structures are wrong */
if (wakeup_header.real_magic != 0x12345678)
while(1);
- if (wakeup_header.realmode_flags 4) {
- asm volatile(inb $97, %al; outb%al,
$0x80; movb$3, %al;outb%al, $97;
outb%al, $0x80; movb$-74, %al; outb%al,
$67; outb%al, $0x80; movb$-119, %al;
outb%al, $66; outb%al, $0x80; movb$15,
%al; outb%al, $66);
- }
+ if (wakeup_header.realmode_flags 4)
+ send_morse(...-);
- if (wakeup_header.realmode_flags 1) {
+ if (wakeup_header.realmode_flags 1)
asm volatile(lcallw $0xc000,$3);
-// (movw%cs, %ax; movw%ax, %ds; movw%ax,
%es; movw%ax, %ss);
- }
if (wakeup_header.realmode_flags 2) {
/* Need to call BIOS */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression] 2.6.24-git9: RT sched mishandles artswrapper (bisected)
On Thursday, 7 of February 2008, Ingo Molnar wrote: * Rafael J. Wysocki [EMAIL PROTECTED] wrote: http://programming.kicks-ass.net/kernel-patches/sched-rt-group/ on top of sched-devel. Indeed, with these patches applied the issue is not reproducible any more. great! I've queued Peter's fixes and enhancements up in sched-devel. (not pushed out yet) Could you please tell me what's happening to these patches? The regression is still present in the current mainline and it would be a pity if -rc1 went out with it. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION]fan turns at highspeed after suspend2ram
On Sunday, 10 of February 2008, Mirco Tischler wrote:
Hi
Hi,
I think I found a regression in 2.6.24-git. After waking up from suspend
2 ram, the fan of my laptop turns constantly at highest speed. It didn't
do this in 2.6.24.
I bisected it down to this commit:
commit c95d47a868f35cd47643d116a3c680cdaa954df8
Author: Rafael J. Wysocki [EMAIL PROTECTED]
Date: Tue Jan 8 00:05:21 2008 +0100
ACPI: Separate invocations of _GTS and _BFS from _PTS and _WAK
Reverting it resolves the problem for me, but I can't say if this makes
any sense.
Well, _GTS and _BFS are nops on all machines known to me. However, there's
one more change in there that may break things in (very speculative) theory.
Can you apply the appended patch on top of the current mainline and tetest?
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c | 72
1 file changed, 36 insertions(+), 36 deletions(-)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -494,12 +494,47 @@ acpi_status acpi_leave_sleep_state_prep(
struct acpi_object_list arg_list;
union acpi_object arg;
acpi_status status;
+
+ ACPI_FUNCTION_TRACE(acpi_leave_sleep_state_prep);
+
+ /* Execute the _BFS method */
+
+ arg_list.count = 1;
+ arg_list.pointer = arg;
+ arg.type = ACPI_TYPE_INTEGER;
+ arg.integer.value = sleep_state;
+
+ status = acpi_evaluate_object(NULL, METHOD_NAME__BFS, arg_list, NULL);
+ if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
+ ACPI_EXCEPTION((AE_INFO, status, During Method _BFS));
+ }
+
+ return_ACPI_STATUS(status);
+}
+
+/***
+ *
+ * FUNCTION:acpi_leave_sleep_state
+ *
+ * PARAMETERS: sleep_state - Which sleep state we just exited
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Perform OS-independent ACPI cleanup after a sleep
+ * Called with interrupts ENABLED.
+ *
+
**/
+acpi_status acpi_leave_sleep_state(u8 sleep_state)
+{
+ struct acpi_object_list arg_list;
+ union acpi_object arg;
+ acpi_status status;
struct acpi_bit_register_info *sleep_type_reg_info;
struct acpi_bit_register_info *sleep_enable_reg_info;
u32 PM1Acontrol;
u32 PM1Bcontrol;
- ACPI_FUNCTION_TRACE(acpi_leave_sleep_state_prep);
+ ACPI_FUNCTION_TRACE(acpi_leave_sleep_state);
/*
* Set SLP_TYPE and SLP_EN to state S0.
@@ -546,41 +581,6 @@ acpi_status acpi_leave_sleep_state_prep(
}
}
- /* Execute the _BFS method */
-
- arg_list.count = 1;
- arg_list.pointer = arg;
- arg.type = ACPI_TYPE_INTEGER;
- arg.integer.value = sleep_state;
-
- status = acpi_evaluate_object(NULL, METHOD_NAME__BFS, arg_list, NULL);
- if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
- ACPI_EXCEPTION((AE_INFO, status, During Method _BFS));
- }
-
- return_ACPI_STATUS(status);
-}
-
-/***
- *
- * FUNCTION:acpi_leave_sleep_state
- *
- * PARAMETERS: sleep_state - Which sleep state we just exited
- *
- * RETURN: Status
- *
- * DESCRIPTION: Perform OS-independent ACPI cleanup after a sleep
- * Called with interrupts ENABLED.
- *
-
**/
-acpi_status acpi_leave_sleep_state(u8 sleep_state)
-{
- struct acpi_object_list arg_list;
- union acpi_object arg;
- acpi_status status;
-
- ACPI_FUNCTION_TRACE(acpi_leave_sleep_state);
-
/* Ensure enter_sleep_state_prep - enter_sleep_state ordering */
acpi_gbl_sleep_type_a = ACPI_SLEEP_TYPE_INVALID;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION]fan turns at highspeed after suspend2ram
On Sunday, 10 of February 2008, Ray Lee wrote: On Feb 10, 2008 9:21 AM, Mirco Tischler [EMAIL PROTECTED] wrote: Hi I think I found a regression in 2.6.24-git. After waking up from suspend 2 ram, the fan of my laptop turns constantly at highest speed. It didn't do this in 2.6.24. I bisected it down to this commit: commit c95d47a868f35cd47643d116a3c680cdaa954df8 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Tue Jan 8 00:05:21 2008 +0100 ACPI: Separate invocations of _GTS and _BFS from _PTS and _WAK Reverting it resolves the problem for me, but I can't say if this makes any sense. My machine is a Zepto laptop with Intel Santa-Rosa chipset and I'm running a x86_64 Ubuntu Gutsy. I just noticed the same problem. After about ten minutes, it seems like all the ACPI events got 'unstuck' -- my screen's backlight went up and down a couple of times (and battery/AC indicator flipped a couple of times) responding to previous power loss and gain events, I think, and the fans dropped down from high speed to low. I was chalking it up to another charming bug on my HP nx6125, but if someone else is seeing it too... I'm on Ubuntu, x86_64, and git as of a couple days ago as well. I haven't tried reverting the patch. I've just sent a patch to Mirco, please test it too. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION]fan turns at highspeed after suspend2ram
On Monday, 11 of February 2008, Mirco Tischler wrote: On Sunday, 10 of February 2008, Rafaek J. Wysocki wrote: Can you apply the appended patch on top of the current mainline and tetest? Thanks, Rafael Sorry, that doesn't fix it. But I'm pretty sure it is related to that commit. Bisecting went straight forward to it and reverting it fixes the bug. BTW, does the kernel compile for you after reverting this patch? Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable [still broken in 2.6.25-rc1]
On Monday, 11 of February 2008, Alessandro Suardi wrote: On Feb 9, 2008 6:10 PM, Alessandro Suardi [EMAIL PROTECTED] wrote: I finally had a bit of time to try out different kernel versions to find out where this began... and it's in 2.6.24-git2. What happens: Oracle 11g starts up and forks a number of so called background processes. Starting in 2.6.24-git2 the VKTM process never fully completes its initialization but gets in R state, never accumulating CPU, and can't be straced/gdb'd/killed. Sysrq-T reports for VKTM looks like this Feb 9 16:10:46 sandman kernel: === Feb 9 16:10:46 sandman kernel: oracleR running 2684 2258 1 Feb 9 16:10:46 sandman kernel:f591dfb0 00200086 f6bbc3c4 f6863cc0 c010547a b794f62c b7b70600 Feb 9 16:10:46 sandman kernel:b79453dc f591d000 c0103caa b794f62c b7943708 b79453e4 b7b70600 b79453dc Feb 9 16:10:46 sandman kernel:bfb0dd5c b79500b0 007b 007b c032 0e072d7a 0073 Feb 9 16:10:46 sandman kernel: Call Trace: Feb 9 16:10:46 sandman kernel: [c010547a] ? do_IRQ+0xac/0xc1 Feb 9 16:10:46 sandman kernel: [c0103caa] work_resched+0x5/0x16 Feb 9 16:10:46 sandman kernel: [c032] ? pci_setup+0xb3/0x104 Feb 9 16:10:46 sandman kernel: === 2.6.24-git1 is okay 2.6.24-git2 is bad ... 2.6.24-git20 is bad Only differences in kernel .config between -git1 and -git2 are [EMAIL PROTECTED] src]$ diff .config-2.6.24-git[12] 3,4c3,4 # Linux kernel version: 2.6.24-git1 # Sat Jan 26 01:04:43 2008 --- # Linux kernel version: 2.6.24-git2 # Sat Jan 26 12:10:15 2008 121a122,123 CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set 187a190 # CONFIG_RCU_TRACE is not set 230a234 # CONFIG_SCHED_HRTICK is not set 755a760 # CONFIG_PATA_NINJA32 is not set 1807a1813 # CONFIG_LATENCYTOP is not set Symptom is similar to what Rafael reported here http://www.ussg.iu.edu/hypermail/linux/kernel/0801.3/4114.html and similarly VKTM attempts to run at elevated priority as normal user process (Oracle kernel binary is not setuid root). Yes, I think this is the same problem. Please try to unset CONFIG_GROUP_SCHED and see if that helps. Peter Zijlstra's patches mentioned in the above thread, at http://programming.kicks-ass.net/kernel-patches/sched-rt-group , do not appear to be in -git20 yet. I'm available for further testing. Thanks, ciao, Only to add that 2.6.25-rc1 is still broken. Yes, it is. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable [still broken in 2.6.25-rc1]
On Monday, 11 of February 2008, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
no, they were not lost, they just didnt pass QA here (they crashed on
a particularly hard to debug 8-way box i have) and Peter worked on
that queue of fixes up until today to get it really correct. Could you
check:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
combo patch below as well - whichever you prefer. The shortlog can be
found below as well - but i dont yet consider this pullable, i'd like
it to see pass a full night of randconfig tests on my test-systems.
ok, we just found the reason for the 8-way crash, the delta fix from
Peter is below if any of you have tried the previous combo patch.
Updated sched.git as well, new HEAD is
fec13e45305d69fd0bd23b30bd05a0a42cf341f8.
With the previous patch and this patch applied, the issue is not reproducible
here.
Thanks,
Rafael
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -219,6 +219,10 @@ static void start_rt_bandwidth(struct rt
if (rt_b-rt_runtime == RUNTIME_INF)
return;
+ if (hrtimer_active(rt_b-rt_period_timer))
+ return;
+
+ spin_lock(rt_b-rt_runtime_lock);
for (;;) {
if (hrtimer_active(rt_b-rt_period_timer))
break;
@@ -229,6 +233,7 @@ static void start_rt_bandwidth(struct rt
rt_b-rt_period_timer.expires,
HRTIMER_MODE_ABS);
}
+ spin_unlock(rt_b-rt_runtime_lock);
}
#ifdef CONFIG_RT_GROUP_SCHED
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION]fan turns at highspeed after suspend2ram
On Monday, 11 of February 2008, Mirco Tischler wrote: Can you send me the output of acpidump from your system, please? I atach the output. BTW, does the kernel compile for you after reverting this patch? Rafael Yes, the kernel still compiles and runs on 2.6.25-rc1 with the commit reverted. I just tested it again. To eliminate the possible conincidence, can you test the current mainline with the patch from: http://lkml.org/lkml/2008/2/11/472 applied, please? Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION]fan turns at highspeed after suspend2ram
On Monday, 11 of February 2008, Mirco Tischler wrote: Can you send me the output of acpidump from your system, please? I atach the output. BTW, does the kernel compile for you after reverting this patch? Rafael Yes, the kernel still compiles and runs on 2.6.25-rc1 with the commit reverted. I just tested it again. Well, this is strange, because one function introduced by this commit is referred to by the subsequent commits. Can you send me the patch reverting this commit that you apply on top of 2.6.25-rc1, please? Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION]fan turns at highspeed after suspend2ram
On Tuesday, 12 of February 2008, Mirco Tischler wrote:
On Di, 2008-02-12 at 00:05 +0100, Rafael J. Wysocki wrote:
Well, this is strange, because one function introduced by this commit
is
referred to by the subsequent commits. Can you send me the patch
reverting
this commit that you apply on top of 2.6.25-rc1, please?
Thanks,
Rafael
Here is the diff after reverting the patch.
OK, thanks.
Since _GTS and _BFS don't seem to be defined in your box's BIOS, please
try to apply the appended patch on top of the revert and see if that breaks
things again.
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c | 11 ---
1 file changed, 11 deletions(-)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -199,11 +199,6 @@ acpi_status acpi_enter_sleep_state_prep(
return_ACPI_STATUS(status);
}
- status = acpi_evaluate_object(NULL, METHOD_NAME__GTS, arg_list, NULL);
- if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
- return_ACPI_STATUS(status);
- }
-
/* Setup the argument to _SST */
switch (sleep_state) {
@@ -554,12 +549,6 @@ acpi_status acpi_leave_sleep_state(u8 sl
ACPI_EXCEPTION((AE_INFO, status, During Method _SST));
}
- arg.integer.value = sleep_state;
- status = acpi_evaluate_object(NULL, METHOD_NAME__BFS, arg_list, NULL);
- if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
- ACPI_EXCEPTION((AE_INFO, status, During Method _BFS));
- }
-
/*
* GPEs must be enabled before _WAK is called as GPEs
* might get fired there
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable [still broken in 2.6.25-rc1]
On Monday, 11 of February 2008, Linus Torvalds wrote: On Mon, 11 Feb 2008, Rafael J. Wysocki wrote: On Monday, 11 of February 2008, Alessandro Suardi wrote: 2.6.24-git1 is okay 2.6.24-git2 is bad Ok, that's git ID's b47711bfbcd4eb77ca61ef0162487b20e023ae55 2.6.24-git1 9b73e76f3cf63379dcf45fcd4f112f5812418d0a 2.6.24-git2 so if you get a git tree, you can do gitk b47711b..9b73e76 to see what happened in there. However, the obvious candidates are the scheduler or the ocfs2 merge, and the latter is only relevant in case you use ocfs2, of course. The rest of it tends to be the DVB and SCSI updates. But it would be great if you could do a bisect and verify. Just do git bisect start git bisect good b47711bfbcd4eb77ca61ef0162487b20e023ae55 git bisect bad 9b73e76f3cf63379dcf45fcd4f112f5812418d0a and off you go.. Well, I've already bisected that down to commit 6f505b16425a51270058e4a93441fe64de3dd435 sched: rt group scheduling and provided a simple test case. Moreover, there are patches from Peter that fix the problem, but they are lost somewhere in the way from him to you (please see http://lkml.org/lkml/2008/2/5/535 and http://lkml.org/lkml/2008/2/6/320). Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stuck with 2.6.23.14 on x86_64
On Tuesday, 12 of February 2008, Fabio Coatti wrote:
Alle martedì 12 febbraio 2008, Randy Dunlap ha scritto:
On Tue, 12 Feb 2008 15:03:41 +0100 Fabio Coatti wrote:
Hi all,
I'm stuck in a weird situation: I'm unable to go beyond 2.6.23.14, so to
fix the splice bug I've had to apply by hand the patch. (x86_64)
Basically, with 2.6.24.2 (the same with 2.6.24 and .1), tha machine won't
boot due to a problem with cciss driver, that prevents to find the /
partition. (bug described here: Kernel Bug Tracker Bug 9859
http://bugzilla.kernel.org/show_bug.cgi?id=9859 );
With kernels 2.6.23, the lastest that I can compile is 2.6.23.14;
starting from .15 (and .16) I get this message:
==
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `acpi_init':
bus.c:(.init.text+0x1713): undefined reference to `pm_flags'
bus.c:(.init.text+0x1756): undefined reference to `pm_flags'
==
All .config are the same, (make oldconfig) beside the obvious differences
between .23 and .24
Hardware: x86_64 AMD 2216HE
SCSI controller: HP Smart Array E200i Controller
Compiler: gcc (GCC) 4.1.1
binutils: 2.16.1
On a x86 machine, Intel(R) Xeon(TM) CPU 3.20GHz
with a cciss0: HP Smart Array 6i Controller,
the 2.6.24.2 compiles just fine and works, so the cciss problems seems
related only to E200i controller.
Right now, on AMD64 machines, I'm forced to patch by hand the kernel,
that's quite uncomfortable :)
Can someone point me in the right direction to get out of this situation?
Of course I can provide any further information. (.config not inlcuded
now to avoid cluttering )
Thanks for any answer.
a/ send .config file for the build problem above
b/ How do you download and/or apply 2.6.23.{15,16} ?
Full tarball or base tarball + patches?
If patches, what base tree are they applied to?
full tarball from kernel.org (.16), tried also applying patches to 2.6.23
vanilla.(.15,.16) Same process leads to successful compilation for .14
You're not supposed to have CONFIG_PM unset and CONFIG_ACPI set at the same
time. The oldconfig generation must have gone wrong at one point.
Thanks,
Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: stuck with 2.6.23.14 on x86_64
On Tuesday, 12 of February 2008, Randy Dunlap wrote:
On Tue, 12 Feb 2008 18:47:19 +0100 Fabio Coatti wrote:
Alle martedì 12 febbraio 2008, Randy Dunlap ha scritto:
On Tue, 12 Feb 2008 15:03:41 +0100 Fabio Coatti wrote:
Hi all,
I'm stuck in a weird situation: I'm unable to go beyond 2.6.23.14, so to
fix the splice bug I've had to apply by hand the patch. (x86_64)
Basically, with 2.6.24.2 (the same with 2.6.24 and .1), tha machine
won't
boot due to a problem with cciss driver, that prevents to find the /
partition. (bug described here: Kernel Bug Tracker Bug 9859
http://bugzilla.kernel.org/show_bug.cgi?id=9859 );
With kernels 2.6.23, the lastest that I can compile is 2.6.23.14;
starting from .15 (and .16) I get this message:
==
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `acpi_init':
bus.c:(.init.text+0x1713): undefined reference to `pm_flags'
bus.c:(.init.text+0x1756): undefined reference to `pm_flags'
==
All .config are the same, (make oldconfig) beside the obvious
differences
between .23 and .24
Hardware: x86_64 AMD 2216HE
SCSI controller: HP Smart Array E200i Controller
Compiler: gcc (GCC) 4.1.1
binutils: 2.16.1
On a x86 machine, Intel(R) Xeon(TM) CPU 3.20GHz
with a cciss0: HP Smart Array 6i Controller,
the 2.6.24.2 compiles just fine and works, so the cciss problems seems
related only to E200i controller.
Right now, on AMD64 machines, I'm forced to patch by hand the kernel,
that's quite uncomfortable :)
Can someone point me in the right direction to get out of this
situation?
Of course I can provide any further information. (.config not inlcuded
now to avoid cluttering )
Thanks for any answer.
a/ send .config file for the build problem above
b/ How do you download and/or apply 2.6.23.{15,16} ?
Full tarball or base tarball + patches?
If patches, what base tree are they applied to?
full tarball from kernel.org (.16), tried also applying patches to 2.6.23
vanilla.(.15,.16) Same process leads to successful compilation for .14
OK, quite easy to reproduce when CONFIG_PM=n.
For a temp quick fix, you could enable CONFIG_PM.
Len, Rafael: were there any recent patches for the split of ACPI PM
that need to be backported to -stable?
Not that I know of.
Actually, ACPI still depends on PM (in the current mainline as well as in
.23.x).
Thanks,
Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION]fan turns at highspeed after suspend2ram
On Wednesday, 13 of February 2008, Mirco Tischler wrote:
On Mi, 2008-02-13 at 00:23 +0100, Rafael J. Wysocki wrote:
Ah, ok. Thanks for testing. :-)
Can you please check if the current mainline with the following patch
applied
works on your box?
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -616,6 +616,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
return_ACPI_STATUS(status);
}
+ arg.integer.value = sleep_state;
status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, arg_list, NULL);
if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
ACPI_EXCEPTION((AE_INFO, status, During Method _WAK));
Yes, works with current mainline too.
Much thanks for your help
Well, thanks for your patience. :-)
It's a well-hidden bug, so it probably would have taken much time to find it
without your ability to reproduce the problem.
Thanks,
Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI suspend: Execute _WAK with the right argument
On Wednesday, 13 of February 2008, Pavel Machek wrote:
On Wed 2008-02-13 00:32:16, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The _WAK global ACPI control method has to be called with the
argument representing the sleep state being exited. Make it happen.
Special thanks to Mirco Tischler [EMAIL PROTECTED] for reporting the
problem and debugging.
Reported-by: Mirco Tischler [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK. AFAICT this is 2.6.25 material.
Sure, it certainly is. The bug has been breaking suspend on people's boxes
already.
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -616,6 +616,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
return_ACPI_STATUS(status);
}
+ arg.integer.value = sleep_state;
status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, arg_list, NULL);
if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
ACPI_EXCEPTION((AE_INFO, status, During Method _WAK));
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI suspend: Execute _WAK with the right argument
From: Rafael J. Wysocki [EMAIL PROTECTED]
The _WAK global ACPI control method has to be called with the
argument representing the sleep state being exited. Make it happen.
Special thanks to Mirco Tischler [EMAIL PROTECTED] for reporting the
problem and debugging.
Reported-by: Mirco Tischler [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/acpi/hardware/hwsleep.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -616,6 +616,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
return_ACPI_STATUS(status);
}
+ arg.integer.value = sleep_state;
status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, arg_list, NULL);
if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
ACPI_EXCEPTION((AE_INFO, status, During Method _WAK));
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION]fan turns at highspeed after suspend2ram
On Wednesday, 13 of February 2008, Mirco Tischler wrote:
Am Dienstag, den 12.02.2008, 23:18 +0100 schrieb Rafael J. Wysocki:
Ouch. I think I know what the problem is.
On top of this patch, please apply the appended one and retest.
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -566,6 +566,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
return_ACPI_STATUS(status);
}
+ arg.integer.value = sleep_state;
status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, arg_list, NULL);
if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
ACPI_EXCEPTION((AE_INFO, status, During Method _WAK));
Good news. That works perfectly.
Ah, ok. Thanks for testing. :-)
Can you please check if the current mainline with the following patch applied
works on your box?
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -616,6 +616,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
return_ACPI_STATUS(status);
}
+ arg.integer.value = sleep_state;
status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, arg_list, NULL);
if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
ACPI_EXCEPTION((AE_INFO, status, During Method _WAK));
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 9944] suspend to ram doesn't work anymore on Thinkpad T61 with Intel X3100
On Tuesday, 12 of February 2008, [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9944 Distribution: Debian Sid Hardware Environment: Thinkpad T61 Software Environment: Problem Description: Suspend to ram doesn't work anymore on my thinkpad t61 with 2.6.25-rc1. On 2.6.24 I had to pass acpi_sleep=s3bios at boot time and suspend with s2ram -f -a 3. On 2.6.25-rc1 doing (on console, with X not running) that leads to a blank screen and the ___sleep___ led (the moon) on the thinkpad blinks (like when it is currently suspending), but nothing happens then. If I can make some more tests, or if you need more info, please ask. I hope this is no duplicate. I have a t61p and suspend/hibernate is bad and deteriorating. So many things go wrong that I'm afraid to test it any more. There are at least two known suspend regressions, one of which affects the T61 for sure. There's a fix for it, available at: http://lkml.org/lkml/2008/2/11/472 The fix for the second issue is in the works. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION]fan turns at highspeed after suspend2ram
On Tuesday, 12 of February 2008, Mirco Tischler wrote:
Am Dienstag, den 12.02.2008, 01:13 +0100 schrieb Rafael J. Wysocki:
Since _GTS and _BFS don't seem to be defined in your box's BIOS, please
try to apply the appended patch on top of the revert and see if that breaks
things again.
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c | 11 ---
1 file changed, 11 deletions(-)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -199,11 +199,6 @@ acpi_status acpi_enter_sleep_state_prep(
return_ACPI_STATUS(status);
}
- status = acpi_evaluate_object(NULL, METHOD_NAME__GTS, arg_list, NULL);
- if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
- return_ACPI_STATUS(status);
- }
-
/* Setup the argument to _SST */
switch (sleep_state) {
@@ -554,12 +549,6 @@ acpi_status acpi_leave_sleep_state(u8 sl
ACPI_EXCEPTION((AE_INFO, status, During Method _SST));
}
- arg.integer.value = sleep_state;
- status = acpi_evaluate_object(NULL, METHOD_NAME__BFS, arg_list, NULL);
- if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
- ACPI_EXCEPTION((AE_INFO, status, During Method _BFS));
- }
-
/*
* GPEs must be enabled before _WAK is called as GPEs
* might get fired there
Yes, that's it. This patch breaks things again.
Ouch. I think I know what the problem is.
On top of this patch, please apply the appended one and retest.
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -566,6 +566,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
return_ACPI_STATUS(status);
}
+ arg.integer.value = sleep_state;
status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, arg_list, NULL);
if (ACPI_FAILURE(status) status != AE_NOT_FOUND) {
ACPI_EXCEPTION((AE_INFO, status, During Method _WAK));
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.24-mm1 and 2.6.24-git13 kernel panic's while bootup at ide_device_add_all
On Tuesday, 5 of February 2008, Kamalesh Babulal wrote:
Hi,
The kernel bootup panics with the 2.6.24-mm1 and 2.6.24-git13 kernel
while defconfig compiled in for x86_64 (Intel(R) Xeon) box
Is that still happening or has it been fixed?
Rafael
BUG: unable to handle kernel paging request at ffb0
IP: [80413642] init_irq+0x188/0x444
PGD 203067 PUD 204067 PMD 0
Oops: [1] SMP
CPU 2
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24 #1
RIP: 0010:[80413642] [80413642] init_irq+0x188/0x444
RSP: 0018:81022f093e00 EFLAGS: 00010287
RAX: ff90 RBX: 808a9100 RCX:
RDX: RSI: 81022fc039c0 RDI: 8074dd00
RBP: 81022f093e30 R08: 808af880 R09: 0002
R10: 0001 R11: 810bed60 R12: 808b0400
R13: 808b0410 R14: R15:
FS: () GS:81022f0883c0() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: ffb0 CR3: 00201000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper (pid: 1, threadinfo 81022f092000, task 81022f0797d0)
Stack: 81022f093e30 808a9100 808a9120
ffed 81022f093eb0 80414425
81022f093ec0 8074e920 0246
Call Trace:
[80414425] ide_device_add_all+0xb27/0xe1b
[807d2884] ide_generic_init+0x3a/0x3e
[807b473b] kernel_init+0x175/0x2e7
[8020bff8] child_rip+0xa/0x12
[80372350] ? acpi_ds_init_one_object+0x0/0x88
[807b45c6] ? kernel_init+0x0/0x2e7
[8020bfee] ? child_rip+0x0/0x12
Code: 89 03 49 8b 45 18 48 89 18 48 39 1b 75 04 0f 0b eb fe fe 05 51 51 38 00
fb eb 5b 48 8b 83 28 07 00 00 83 ca ff 48 83 e8 70 74 0e 48 8b 40 20 48 8b
80 88 00 00 00 8b 50 04 48 8b 3d 79 ff 2f 00
RIP [80413642] init_irq+0x188/0x444
RSP 81022f093e00
CR2: ffb0
---[ end trace 9010a4c8c4ba608a ]---
(gdb) p init_irq
$1 = {int (ide_hwif_t *)} 0x804134ba init_irq
(gdb) p/x 0x804134ba+0x188
$2 = 0x80413642
(gdb) l *0x80413642
0x80413642 is in init_irq (include/linux/ide.h:1311).
1306print_hex_dump(KERN_INFO, , DUMP_PREFIX_NONE, 16, 2, id,
512, 0);
1307}
1308
1309static inline int hwif_to_node(ide_hwif_t *hwif)
1310{
1311struct pci_dev *dev = to_pci_dev(hwif-dev);
1312return dev ? pcibus_to_node(dev-bus) : -1;
1313}
1314
1315static inline ide_drive_t *ide_get_paired_drive(ide_drive_t *drive)
(gdb)
(gdb) p ide_device_add_all
$1 = {int (u8 *, const struct ide_port_info *)} 0x804138fe
ide_device_add_all
(gdb) p/x 0x804138fe
$2 = 0x804138fe
(gdb) l *0x804138fe
0x804138fe is in ide_device_add_all (drivers/ide/ide-probe.c:1372).
1367hwif-cbl = hwif-cable_detect(hwif);
1368}
1369}
1370
1371int ide_device_add_all(u8 *idx, const struct ide_port_info *d)
1372{
1373ide_hwif_t *hwif, *mate = NULL;
1374int i, rc = 0;
1375
1376for (i = 0; i MAX_HWIFS; i++) {
(gdb)
--
Premature optimization is the root of all evil. - Donald Knuth
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Wednesday, 13 of February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 12:39:13PM +0100, Frans Pop wrote: On Tuesday 12 February 2008, Greg KH wrote: On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote: On Monday 11 February 2008, Frans Pop wrote: In general 2.6.25 if looking quite good on my desktop, but there's one important issue: the system no longer powers off after shutdown. This works fine with 2.6.24. Don't ask me why, but bisection shows this commit to be the cause of the failure to power off: commit c10997f6575f476ff38442fa18fd4a0d80345f9d Author: Greg Kroah-Hartman [EMAIL PROTECTED] Date: Thu Dec 20 08:13:05 2007 -0800 Kobject: convert drivers/* from kobject_unregister() to kobject_put() Because it seemed somewhat unlikely, I have double checked this by doing an extra compilation for this commit and its predecessor. What is the symptom of not powering off? I already noticed yesterday that there's one hunk in that commit that's not a straight replacement: diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 9e102af..5efd555 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1030,8 +1030,6 @@ static int __cpufreq_remove_dev (struct sys_device * sys_dev) unlock_policy_rwsem_write(cpu); - kobject_unregister(data-kobj); - kobject_put(data-kobj); /* we need to make sure that the underlying kobj is actually So, just on the off chance, I applied the patch below and bingo, the system powers off again. I doubt this will be the correct solution, but just in case it is, here's my signed off. A comment why the double put is needed would probably be good though. There is a bug in the cpufreq kref logic that makes this double put necessary. A real fix has already been posted to solve this issue, and I think it should be on it's way to Linus for -rc2 already. Please let me know if -rc2 comes out without this needed fix. Can you point me to the fix, please? Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uml compile error
On Friday, 8 of February 2008, Adrian Bunk wrote: Commit dd2cc4dff3b08ab54c4c177a080046bcc84ac41d broke uml: -- snip -- ... CC fs/hostfs/hostfs_kern.o /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/hostfs/hostfs_kern.c: In function ‘hostfs_show_options’: /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/hostfs/hostfs_kern.c:328: error: dereferencing pointer to incomplete type make[3]: *** [fs/hostfs/hostfs_kern.o] Error 1 -- snip -- Has it been fixed in the mainline? Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git: kmap_atomic() WARN_ON()
Hi Thomas, On Thursday, 7 of February 2008, Thomas Gleixner wrote: current mainline triggers: Has the issue been fixed in the meantime? WARNING: at /home/tglx/work/kernel/x86/linux-2.6/arch/x86/mm/highmem_32.c:52 kmap_atomic_prot+0xe5/0x19b() Modules linked in: ahci(+) sata_sil libata sd_mod scsi_mod raid1 ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 0, comm: swapper Not tainted 2.6.24 #173 [c0126b60] warn_on_slowpath+0x41/0x51 [c011c5eb] ? __enqueue_entity+0x9c/0xa4 [c011c717] ? enqueue_entity+0x124/0x13b [c011cedb] ? enqueue_task_fair+0x41/0x4c [c032ce88] ? _spin_lock_irqsave+0x14/0x2e [c012e885] ? lock_timer_base+0x1f/0x3e [c011ad6d] kmap_atomic_prot+0xe5/0x19b [c011ae37] kmap_atomic+0x14/0x16 [f88ea218] ata_scsi_rbuf_get+0x1e/0x2c [libata] [f88ea821] atapi_qc_complete+0x23f/0x289 [libata] [f88e3d00] __ata_qc_complete+0x8e/0x93 [libata] [f88e3fc7] ata_qc_complete+0x115/0x128 [libata] [f88e8d47] ata_qc_complete_multiple+0x86/0xa0 [libata] [f8841a5d] ahci_interrupt+0x370/0x40d [ahci] [c01512c6] handle_IRQ_event+0x21/0x48 [c01521ca] handle_edge_irq+0xc9/0x10a [c0152101] ? handle_edge_irq+0x0/0x10a [c0107518] do_IRQ+0x8b/0xb7 [c01055db] common_interrupt+0x23/0x28 [c032007b] ? init_chipset_cmd64x+0xb/0x93 [c010316e] ? mwait_idle_with_hints+0x39/0x3d [c0103172] ? mwait_idle+0x0/0xf [c010317f] mwait_idle+0xd/0xf [c0103761] cpu_idle+0xb0/0xe4 [c031b509] rest_init+0x5d/0x5f This is not a new problem. It was pointed out some time ago already, but now the WARN_ON() finally made it into mainline :) The fix is not obvious, as this code seems to be called from various call sites. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: udf regression: broken directory handling
On Tuesday, 12 of February 2008, Marcin Slusarz wrote: On Tue, Feb 12, 2008 at 12:39:17PM +0100, Jan Kara wrote: On Mon 11-02-08 20:13:20, Marcin Slusarz wrote: On Mon, Feb 11, 2008 at 12:09:10PM +0100, Jan Kara wrote: Hi, On Sun 10-02-08 11:48:17, Marcin Slusarz wrote: Current mainline has a problem with reading file list. Simple ls prints only 2 out of 8 files on my testing DVD. Reverting your patch udf: cleanup directory offset handling (af793295bf9ee92660f5e77d337b0493cea3f9b9) fixes the problem. Thanks for testing! Do you have a way to create such UDF filesystem? For the filesystems I've created it seems to work just fine... with patch applied: snip testing Argh, I've submitted an old version of the patch missing changes in dir.c. Below is the missing hunk. Does UDF work for you with it? Yes. Has the issue been fixed in the mainline? Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tg3 broken after PCI: Fix bus resource assignment on 32 bits with 64b resources
On Monday, 4 of February 2008, Alexey Dobriyan wrote: Commit c40a22e0ce5eb400f27449e59e43d021bee58b8d aka PCI: Fix bus resource assignment on 32 bits with 64b resources renders one tg3-equipped box networkless here. Has it been fixed already or is it still happening with the current mainline? Rafael tg3.c:v3.87 (December 20, 2007) tg3: (:02:05.0) phy probe failed, err -19 tg3: Problem fetching invariants of chip, aborting. tg3: (:02:05.1) phy probe failed, err -19 tg3: Problem fetching invariants of chip, aborting. It's 32-bit CONFIG_RESOURCES_64BIT=y box. Not sure what you need this, but below is some lspci -vvvxxx output: 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 Bus: primary=00, secondary=03, subordinate=03, sec-latency=64 I/O behind bridge: a000-bfff Memory behind bridge: 8000-817f Prefetchable memory behind bridge: 8180-818f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- Reset- FastB2B- Capabilities: [c0] HyperTransport: Slave or Primary Interface !!! Possibly incomplete decoding Command: BaseUnitID=6 UnitCnt=4 MastHost- DefDir- Link Control 0: CFlE- CST- CFE- LkFail- Init+ EOC- TXO- CRCErr=0 Link Config 0: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit Link Control 1: CFlE- CST- CFE- LkFail+ Init- EOC+ TXO+ CRCErr=0 Link Config 1: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit Revision ID: 1.02 Capabilities: [f0] HyperTransport: Interrupt Discovery and Configuration 00: 22 10 60 74 17 01 30 02 07 00 04 06 00 40 01 00 10: 00 00 00 00 00 00 00 00 00 03 03 40 a0 b0 00 02 20: 00 80 70 81 80 81 80 81 00 00 00 00 00 00 00 00 30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 0b 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 04 06 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 08 f0 86 00 20 00 00 00 d0 00 00 00 22 00 01 00 d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 0d 00 0f 00 0d 00 11 00 13 00 17 00 00 00 00 00 f0: 08 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) Subsystem: Super Micro Computer Inc Unknown device 0811 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- 00: 22 10 6b 74 00 00 80 02 05 00 80 06 00 40 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 11 08 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 80 b1 09 bc 00 00 00 00 20 04 50 00 00 00 00 03 50: 01 00 00 00 0f 00 00 00 01 50 00 00 00 00 00 00 60: 00 00 80 06 13 00 00 00 00 00 00 00 00 00 00 00 70: 06 29 4b 55 0c 00 00 00 00 00 00 00 d9 15 11 08 80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 31 57 46 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 13) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: 9000-9fff Memory behind bridge: 8190-819f Prefetchable memory behind bridge: 000181a0-000181af Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity+ SERR- NoISA+ VGA- MAbort- Reset- FastB2B- Capabilities: [a0] PCI-X bridge device Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=100MHz Status: Dev=00:0a.0 64bit+ 133MHz+ SCD- USC- SCO- SRD- Upstream:
Re: tg3 broken after PCI: Fix bus resource assignment on 32 bits with 64b resources
On Thursday, 14 of February 2008, Alexey Dobriyan wrote: On Wed, Feb 13, 2008 at 11:52:46PM +0100, Rafael J. Wysocki wrote: On Monday, 4 of February 2008, Alexey Dobriyan wrote: Commit c40a22e0ce5eb400f27449e59e43d021bee58b8d aka PCI: Fix bus resource assignment on 32 bits with 64b resources renders one tg3-equipped box networkless here. Has it been fixed already or is it still happening with the current mainline? It's fine now. See 20651af9ac60fd6e31360688ad44861a7d05256a aka x86: fix mttr trimming. OK, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: first tree
On Thursday, 14 of February 2008, Stephen Rothwell wrote: Hi all, I have created the first cut of the linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git. Things to know about this tree: It has two branches - master and stable. Stable is currently just Linus' tree and will never rebase. Master will rebase on an almost daily basis (maybe slower at the start). The tree consists of subsystem git and quilt trees. Currently, the quilt trees are integrated by importing them into appropriately based git branches and then merging those branches. This has the advantage that any conflict resolution will onlt have to happen once at the merge point rather than, possibly, sevveral times during the series. However, I am considering just applying the quilt trees on top of the current tree to get a result more like Linus' tree - we will see. The git trees are obviously just merged. Between each merge, the tree was built with both an allmodconfig for both powerpc and x86_64. The tree currently contains: Greg's driver-core, pci and usb quilt series (in that order) Alasdair Kergon's device-mapper quilt tree Jiri Kosina's hid git tree Jean Delvare's i2c quilt tree Randy Dunlap's kernel-doc quilt tree Haavard Skinnemoen's avr32 git tree There was only one unresolved conflict which could have been caused because I was not sure where to base the kernel-doc tree. So, comments, please. Also, more trees please ... :-) Perhaps you can add: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 test Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] move wakeup code to .c
On Friday, 15 of February 2008, Pavel Machek wrote:
Hi!
scripts/checkpatch.pl
ERROR: do not initialise externals to 0 or NULL
#113: FILE: arch/x86/boot/video-mode.c:29:
+int do_restore = 0;/* Screen contents changed during mode flip */
We were doing file move with minimal changes.
ERROR: need a space before the open parenthesis '('
#710: FILE: arch/x86/kernel/acpi/realmode/wakemain.c:70:
+ while(1);
Bogus warning.
I'll fix al but this one, but could we do it as a followup patch? I'm
currently at holidays, moving .S code into .c is rather
good/important, and it should get testing ASAP.
I'll move the definitions into a header file.
Thanks,
Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] cpufreq, powernow-k8: Change email address
On Monday, October 29, 2012 06:52:21 PM Andreas Herrmann wrote: Signed-off-by: Andreas Herrmann herrmann.der.u...@googlemail.com Am I supposed to take this one? Rafael --- drivers/cpufreq/powernow-k8.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c index c16a3a5..e3ebb4f 100644 --- a/drivers/cpufreq/powernow-k8.c +++ b/drivers/cpufreq/powernow-k8.c @@ -5,7 +5,7 @@ * http://www.gnu.org/licenses/gpl.html * * Maintainer: - * Andreas Herrmann andreas.herrma...@amd.com + * Andreas Herrmann herrmann.der.u...@googlemail.com * * Based on the powernow-k7.c module written by Dave Jones. * (C) 2003 Dave Jones on behalf of SuSE Labs -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc3
On Sunday, October 28, 2012 12:59:49 PM Linus Torvalds wrote: It's been a week, time for -rc3! Nothing particularly stands out here. Lots of small fixes, exemplified by the series of memory leak fixes in usb serial drivers. Just a lot of random stuff.. Most of it is drivers (all over: drm, wireless, staging, usb, sound), but there's a few filesystem updates (nfs, btrfs, ext4), arch updates (arm, x86 and m68k) and just random stuff. Shortlog appended. Unfortunately, s2disk is broken with this one and previous -rc. In the majority of cases it just hangs the machine during hibernation, although sometimes it returns to user space reporting freezing problems, suspicions RCU usage and similar stuff, pretty much without any useful debug information. I'm quite confident that v3.6 was OK (and -stable based on that too), so it most likely is a recent regression. The in-kernel hibernation (ie. echo disk /sys/power/state) works no problem. So does suspend to RAM on my test boxes. So far I have been able to reproduce this 100% of the time on two machines with Intel CPUs and graphics driven by i915. I _suspect_ that this may be related to VT switching, because s2disk does some ugly things in that area which are not done by the in-kernel code. Dunno. Anyway, it looks like nothing short of bisection is going to help debug this, but I'm afraid I won't have the time to bisect within the next two weeks, so if anyone can reproduce this issue and will be able to bisect it, please help (openSUSE/Tumbleweed users anyone?). Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] ACPI / PM: Provide device PM functions operating on struct acpi_device
On Tuesday, October 30, 2012 03:28:45 PM Aaron Lu wrote:
On Mon, Oct 29, 2012 at 10:11:20AM +0100, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
If the caller of acpi_bus_set_power() already has a pointer to the
struct acpi_device object corresponding to the device in question, it
doesn't make sense for it to go through acpi_bus_get_device(), which
may be costly, because it involves acquiring the global ACPI
namespace mutex.
For this reason, export the function operating on struct acpi_device
objects used internally by acpi_bus_set_power(), so that it may be
called instead of acpi_bus_set_power() in the above case, and change
its name to acpi_device_set_power().
Additionally, introduce two inline wrappers for checking ACPI PM
capabilities of devices represented by struct acpi_device objects.
What about adding yet another wrapper to check power off capability of
the device? If device has _PS3 or _PRx, it means the device can be
powered off from ACPI's perspective. This is useful for ZPODD when
deciding if platform has the required ability to support it.
Sure, no problem with that. Perhaps you can cut a patch for that
on top of this series?
Rafael
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/acpi/bus.c | 15 ---
include/acpi/acpi_bus.h | 11 +++
2 files changed, 23 insertions(+), 3 deletions(-)
Index: linux/drivers/acpi/bus.c
===
--- linux.orig/drivers/acpi/bus.c
+++ linux/drivers/acpi/bus.c
@@ -257,7 +257,15 @@ static int __acpi_bus_get_power(struct a
}
-static int __acpi_bus_set_power(struct acpi_device *device, int state)
+/**
+ * acpi_device_set_power - Set power state of an ACPI device.
+ * @device: Device to set the power state of.
+ * @state: New power state to set.
+ *
+ * Callers must ensure that the device is power manageable before using
this
+ * function.
+ */
+int acpi_device_set_power(struct acpi_device *device, int state)
{
int result = 0;
acpi_status status = AE_OK;
@@ -341,6 +349,7 @@ static int __acpi_bus_set_power(struct a
return result;
}
+EXPORT_SYMBOL(acpi_device_set_power);
int acpi_bus_set_power(acpi_handle handle, int state)
@@ -359,7 +368,7 @@ int acpi_bus_set_power(acpi_handle handl
return -ENODEV;
}
- return __acpi_bus_set_power(device, state);
+ return acpi_device_set_power(device, state);
}
EXPORT_SYMBOL(acpi_bus_set_power);
@@ -402,7 +411,7 @@ int acpi_bus_update_power(acpi_handle ha
if (result)
return result;
- result = __acpi_bus_set_power(device, state);
+ result = acpi_device_set_power(device, state);
if (!result state_p)
*state_p = state;
Index: linux/include/acpi/acpi_bus.h
===
--- linux.orig/include/acpi/acpi_bus.h
+++ linux/include/acpi/acpi_bus.h
@@ -338,6 +338,7 @@ acpi_status acpi_bus_get_status_handle(a
unsigned long long *sta);
int acpi_bus_get_status(struct acpi_device *device);
int acpi_bus_set_power(acpi_handle handle, int state);
+int acpi_device_set_power(struct acpi_device *device, int state);
int acpi_bus_update_power(acpi_handle handle, int *state_p);
bool acpi_bus_power_manageable(acpi_handle handle);
bool acpi_bus_can_wakeup(acpi_handle handle);
@@ -482,6 +483,16 @@ static inline int acpi_pm_device_sleep_w
}
#endif
+static inline bool acpi_device_power_manageable(struct acpi_device *adev)
+{
+ return adev-flags.power_manageable;
+}
+
+static inline bool acpi_device_can_wakeup(struct acpi_device *adev)
+{
+ return adev-wakeup.flags.valid;
+}
+
#else /* CONFIG_ACPI */
static inline int register_acpi_bus_type(void *bus) { return 0; }
--
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tuesday, October 30, 2012 10:51:11 PM Linus Walleij wrote: On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: More seriously the amount of time we seem to have been spending recently on changes which end up requiring us to go through essentially every driver and add code to them (often several times) doesn't seem like we're doing a good job here. If this is your main concern you should be made aware that there are people out there planning to supplant the existing DT probe paths that are now being added to each and every ARM-related driver with an ACPI probe path as ARM servers come into the picture. That's correct. pinctrl is really noticable because it's new but it's not the only thing. As a subsystem maintainer this code just makes me want to add new subsystem features to pull the code out of drivers but obviously that's not something that should be being done at the subsystem level. We did manage to drag the power/voltage domain per se out of the AMBA bus, and recommend that people (like us) do that business using the power domains. I think most people (including OMAP) have bought into the concept of using the runtime PM framework and power domains to control the power domain switches. It's this wider concept of using the loose concept PM resource domains to control also clocks and pins that is at stake, and so far the runtime PM core people (Rafael and Magnus) has not said much so I think we need some kind of indication from them as to what is to happen, long-term, with drivers handling their own clocks and pins. Should it be centralized or not? If it's to be centralized it needs to become a large piece of infrastructure refactoring and needs the attention of Linaro and the like to happen. Well, I personally think it should be centralized somehow. I'm not quite sure how to achieve that, though. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 5/7] efi_pstore: Add a sequence counter to a variable name
On Tuesday, October 30, 2012 08:02:54 PM Seiji Aguchi wrote:
[Issue]
Currently, a variable name, which identifies each entry, consists of type, id
and ctime.
But if multiple events happens in a short time, a second/third event may fail
to log because
efi_pstore can't distinguish each event with current variable name.
[Solution]
A reasonable way to identify all events precisely is introducing a sequence
counter to
the variable name.
The sequence counter has already supported in a pstore layer with oopscount.
So, this patch adds it to a variable name.
Also, it is passed to read/erase callbacks of platform drivers in accordance
with
the modification of the variable name.
before applying this patch
a variable name of first event: dump-type0-1-12345678
a variable name of second event: dump-type0-1-12345678
type:0
id:1
ctime:12345678
If multiple events happen in a short time, efi_pstore can't distinguish them
because
variable names are same among them.
after applying this patch
it can be distinguishable by adding a sequence counter as follows.
a variable name of first event: dump-type0-1-1-12345678
a variable name of Second event: dump-type0-1-2-12345678
type:0
id:1
sequence counter: 1(first event), 2(second event)
ctime:12345678
Signed-off-by: Seiji Aguchi seiji.agu...@hds.com
Please feel free to add
Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
for the erst.c change.
Thanks!
---
drivers/acpi/apei/erst.c | 12 ++--
drivers/firmware/efivars.c | 23 ++-
fs/pstore/inode.c |8 +---
fs/pstore/internal.h |2 +-
fs/pstore/platform.c | 11 ++-
fs/pstore/ram.c|7 +++
include/linux/pstore.h |8 +---
7 files changed, 40 insertions(+), 31 deletions(-)
diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c
index 0bd6ae4..6d894bf 100644
--- a/drivers/acpi/apei/erst.c
+++ b/drivers/acpi/apei/erst.c
@@ -931,13 +931,13 @@ static int erst_check_table(struct acpi_table_erst
*erst_tab)
static int erst_open_pstore(struct pstore_info *psi);
static int erst_close_pstore(struct pstore_info *psi);
-static ssize_t erst_reader(u64 *id, enum pstore_type_id *type,
+static ssize_t erst_reader(u64 *id, enum pstore_type_id *type, int *count,
struct timespec *time, char **buf,
struct pstore_info *psi);
static int erst_writer(enum pstore_type_id type, enum kmsg_dump_reason
reason,
-u64 *id, unsigned int part,
+u64 *id, unsigned int part, int count,
size_t size, struct pstore_info *psi);
-static int erst_clearer(enum pstore_type_id type, u64 id,
+static int erst_clearer(enum pstore_type_id type, u64 id, int count,
struct timespec time, struct pstore_info *psi);
static struct pstore_info erst_info = {
@@ -987,7 +987,7 @@ static int erst_close_pstore(struct pstore_info *psi)
return 0;
}
-static ssize_t erst_reader(u64 *id, enum pstore_type_id *type,
+static ssize_t erst_reader(u64 *id, enum pstore_type_id *type, int *count,
struct timespec *time, char **buf,
struct pstore_info *psi)
{
@@ -1055,7 +1055,7 @@ out:
}
static int erst_writer(enum pstore_type_id type, enum kmsg_dump_reason
reason,
-u64 *id, unsigned int part,
+u64 *id, unsigned int part, int count,
size_t size, struct pstore_info *psi)
{
struct cper_pstore_record *rcd = (struct cper_pstore_record *)
@@ -1101,7 +1101,7 @@ static int erst_writer(enum pstore_type_id type, enum
kmsg_dump_reason reason,
return ret;
}
-static int erst_clearer(enum pstore_type_id type, u64 id,
+static int erst_clearer(enum pstore_type_id type, u64 id, int count,
struct timespec time, struct pstore_info *psi)
{
return erst_clear(id);
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 3803621..7ad3aae 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -658,13 +658,14 @@ static int efi_pstore_close(struct pstore_info *psi)
}
static ssize_t efi_pstore_read(u64 *id, enum pstore_type_id *type,
-struct timespec *timespec,
+int *count, struct timespec *timespec,
char **buf, struct pstore_info *psi)
{
efi_guid_t vendor = LINUX_EFI_CRASH_GUID;
struct efivars *efivars = psi-data;
char name[DUMP_NAME_LEN];
int i;
+ int cnt;
unsigned int part, size;
unsigned long time;
@@ -674,8 +675,10 @@ static ssize_t efi_pstore_read(u64 *id, enum
pstore_type_id *type,
for (i = 0; i DUMP_NAME_LEN; i
Re: [PATCH 3/4] cpufreq, powernow-k8: Change email address
On Tuesday, October 30, 2012 12:31:00 AM Borislav Petkov wrote: On Tue, Oct 30, 2012 at 12:33:15AM +0100, Rafael J. Wysocki wrote: On Monday, October 29, 2012 06:52:21 PM Andreas Herrmann wrote: Signed-off-by: Andreas Herrmann herrmann.der.u...@googlemail.com Am I supposed to take this one? Yes please. OK, I'm going to push it for v3.7. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-next PATCH] PM / devfreq: documentation cleanups for devfreq header
On Tuesday, October 30, 2012 08:09:09 AM MyungJoo Ham wrote: On 10/29/2012 06:02 AM, Nishanth Menon wrote: struct parameters need to have ':' in documentation for scripts/kernel-doc to parse appropriately. Fix the errors reported by: ./scripts/kernel-doc include/linux/devfreq.h /dev/null Cc: Rajagopal Venkat rajagopal.ven...@linaro.org Cc: MyungJoo Ham myungjoo@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Rafael J. Wysocki r...@sisk.pl Cc: Kevin Hilman khil...@ti.com Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Nishanth Menon n...@ti.com Acked-by: Randy Dunlap rdun...@xenotime.net Thanks. Acked-by: MyungJoo Ham myungjoo@samsung.com Applying to git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git for-rafael, which is based on rafael's linux-pm.git / linux-next. http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael I'll apply your Add sysfs node ... patch after refactoring with Jonghwa's (devfreq trans_stat) as the two patches use the same data (list of available freqs). May I assume that you'll handle all of the subsequent devfreq patches too? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] 3.7-rc2 kernel BUG at kernel/power/snapshot.c:517!
On Tuesday, October 30, 2012 09:35:48 PM Maciej Rutecki wrote: On niedziela, 28 października 2012 o 22:45:26 Rafael J. Wysocki wrote: On Sunday, October 28, 2012 10:12:49 PM Maciej Rutecki wrote: On niedziela, 21 października 2012 o 17:12:28 Maciej Rutecki wrote: Error: kernel BUG at kernel/power/snapshot.c:517! Last known good: 3.6.1 Bad: 3.7-rc2 Steps to reproduce: 1. Boot system with 3.7-rc2 kernel 2. Try suspend to disk (s2ram works OK) System dies on message: http://mrutecki.pl/download/kernel/3.7-rc2/swinka/DSCN0280.jpg lspci: http://mrutecki.pl/download/kernel/3.7-rc2/swinka/lspci.txt dmesg: http://mrutecki.pl/download/kernel/3.7-rc2/swinka/dmesg-3.7-rc2.txt Still present in -rc3 This appears to be a memory allocation error and I have no idea what the reason of it is. Any chance to bisect? 7f1290f2f2a4d2c3f1b7ce8e87256e052ca23125 is the first bad commit commit 7f1290f2f2a4d2c3f1b7ce8e87256e052ca23125 Author: Jianguo Wu wujian...@huawei.com Date: Mon Oct 8 16:33:06 2012 -0700 mm: fix-up zone present pages Signed-off-by: Jianguo Wu wujian...@huawei.com Signed-off-by: Jiang Liu jiang@huawei.com Reported-by: Petr Tesarik ptesa...@suse.cz Tested-by: Petr Tesarik ptesa...@suse.cz Cc: Luck, Tony tony.l...@intel.com Cc: Mel Gorman m...@csn.ul.ie Cc: Yinghai Lu ying...@kernel.org Cc: Minchan Kim minchan@gmail.com Cc: Johannes Weiner han...@cmpxchg.org Cc: David Rientjes rient...@google.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org Description says: This patch intends to fix-up zone-present_pages when memory are freed to buddy system on x86_64 and IA64 platforms. but I use 32 bit kernel Revert this commit solves problem. This is good to know, thanks for bisecting it! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] cpufreq: add support for Calxeda ECX-1000 (highbank)
On Tuesday, October 30, 2012 04:04:10 PM Mark Langsdorf wrote: This patch series adds cpufreq support for the Calxeda ECX-1000 (highbank) SoCs. The driver is based on the cpufreq-cpu0 driver. Because of the unique way that highbank uses the EnergyCore Management Engine to manage voltages, it was not possible to use the cpufreq-cpu0 driver. I've got patches [3-6/6] only for some reason. Care to resend the other three with direct CCs to me? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] cpufreq: Make sure target freq is within limits
On Friday, October 26, 2012 06:05:21 PM Viresh Kumar wrote:
__cpufreq_driver_target() must not pass target frequency beyond the limits of
current policy.
Today most of cpufreq platform drivers are doing this check in their target
routines. Why not move it to __cpufreq_driver_target().
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
Hi Rafael,
Resend doesn't contain any change, but fixed commit log
Applied to the linux-next branch of linux-pm.git as v3.8 material.
Thanks,
Rafael
drivers/cpufreq/cpufreq.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 28dc134..2f5ac2d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1470,12 +1470,19 @@ int __cpufreq_driver_target(struct cpufreq_policy
*policy,
unsigned int relation)
{
int retval = -EINVAL;
+ unsigned int old_target_freq = target_freq;
if (cpufreq_disabled())
return -ENODEV;
- pr_debug(target for CPU %u: %u kHz, relation %u\n, policy-cpu,
- target_freq, relation);
+ /* Make sure that target_freq is within supported range */
+ if (target_freq policy-max)
+ target_freq = policy-max;
+ if (target_freq policy-min)
+ target_freq = policy-min;
+
+ pr_debug(target for CPU %u: %u kHz, relation %u, requested %u kHz\n,
+ policy-cpu, target_freq, relation, old_target_freq);
if (target_freq == policy-cur)
return 0;
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy-cur
On Friday, October 26, 2012 01:17:12 PM Rafael J. Wysocki wrote: On Friday, October 26, 2012 03:06:26 PM Viresh Kumar wrote: Avoid calling cpufreq driver's target() routine if new frequency is same as policies current frequency. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org Looks reasonable. Any objection from anyone? OK, no objections. Applied to the linux-next branch of linux-pm.git as v3.8 material. Thanks, Rafael --- drivers/cpufreq/cpufreq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 261ef65..28dc134 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1476,6 +1476,10 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy, pr_debug(target for CPU %u: %u kHz, relation %u\n, policy-cpu, target_freq, relation); + + if (target_freq == policy-cur) + return 0; + if (cpu_online(policy-cpu) cpufreq_driver-target) retval = cpufreq_driver-target(policy, target_freq, relation); -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [for-next PATCH V2] PM / devfreq: Add sysfs node to expose available frequencies
On Friday, October 26, 2012 06:16:36 AM MyungJoo Ham wrote: devfreq governors such as ondemand are controlled by a min and max frequency, while governors like userspace governor allow us to set a specific frequency. However, for the same specific device, depending on the SoC, the available frequencies can vary. So expose the available frequencies as a snapshot over sysfs to allow informed decisions. This was inspired by cpufreq framework's equivalent for similar usage sysfs node: scaling_available_frequencies. Cc: Rajagopal Venkat rajagopal.ven...@linaro.org Cc: MyungJoo Ham myungjoo@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Rafael J. Wysocki r...@sisk.pl Cc: Kevin Hilman khil...@ti.com Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Nishanth Menon n...@ti.com Acked-by: MyungJoo Ham myungjoo@samsung.com Are you going to handle this patch? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI errors with 3.7-rc3
Hi Greg, On Tuesday, October 30, 2012 06:45:27 PM Greg KH wrote: Hi Len and Rafael, With 3.7-rc3, I'm seeing a constant stream of these errors in the kernel log for my MacBook Pro: [30443.430133] ACPI: EC: input buffer is not empty, aborting transaction [30443.430145] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120913/evregion-501) [30443.430162] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88045cc64618), AE_TIME (20120913/psparse-536) [30443.430179] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88045cc64988), AE_TIME (20120913/psparse-536) [30443.430188] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88045cc648c0), AE_TIME (20120913/psparse-536) [30443.430202] ACPI Exception: AE_TIME, Evaluating _BST (20120913/battery-464) They never showed up before in 3.7-rc2. Anything I should try out to resolve this? Well, there are the following two post-3.6 EC-related commits: commit 67bfa9b60bd689601554526d144b21d529f78a09 Author: Feng Tang feng.t...@intel.com Date: Fri Sep 28 15:22:01 2012 +0800 ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop commit a520d52e99b14ba7db135e916348f12f2a6e09be Author: Feng Tang feng.t...@intel.com Date: Fri Sep 28 15:22:00 2012 +0800 ACPI: EC: Make the GPE storm threshold a module parameter Can you please check if reverting the second one helps? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-next PATCH] PM / devfreq: documentation cleanups for devfreq header
On Wednesday, October 31, 2012 02:27:10 AM 함명주 wrote: On Tuesday, October 30, 2012 08:09:09 AM MyungJoo Ham wrote: [] Acked-by: MyungJoo Ham myungjoo@samsung.com Applying to git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git for-rafael, which is based on rafael's linux-pm.git / linux-next. http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael I'll apply your Add sysfs node ... patch after refactoring with Jonghwa's (devfreq trans_stat) as the two patches use the same data (list of available freqs). May I assume that you'll handle all of the subsequent devfreq patches too? Rafael Yes, you may. I'll apply the patches (currently at http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael ) and send pull requests to you or Linus. Anyway, do you want me to keep sending pull requests to you as you've told last time? Yes, please. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [for-next PATCH V2] PM / devfreq: Add sysfs node to expose available frequencies
On Wednesday, October 31, 2012 02:11:06 AM MyungJoo Ham wrote: On Friday, October 26, 2012 06:16:36 AM MyungJoo Ham wrote: devfreq governors such as ondemand are controlled by a min and max frequency, while governors like userspace governor allow us to set a specific frequency. However, for the same specific device, depending on the SoC, the available frequencies can vary. So expose the available frequencies as a snapshot over sysfs to allow informed decisions. This was inspired by cpufreq framework's equivalent for similar usage sysfs node: scaling_available_frequencies. Cc: Rajagopal Venkat rajagopal.ven...@linaro.org Cc: MyungJoo Ham myungjoo@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Rafael J. Wysocki r...@sisk.pl Cc: Kevin Hilman khil...@ti.com Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Nishanth Menon n...@ti.com Acked-by: MyungJoo Ham myungjoo@samsung.com Are you going to handle this patch? Yes, I've just setup the git repository this week and I'm willing to handle this one. It is applied at http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael OK Please let me know when you want me to pull from your tree. Please also note that the release of v3.7-rc6 is the deadline for non-bugfix changes targeted at v3.8. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] ACPI / x86: Export acpi_[un]register_gsi()
From: Andy Shevchenko andriy.shevche...@linux.intel.com
These functions might be called from modules as well so make sure
they are exported.
In addition, implement empty version of acpi_unregister_gsi() and
remove the one from pci_irq.c.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
arch/x86/kernel/acpi/boot.c |6 ++
drivers/acpi/pci_irq.c |5 -
2 files changed, 6 insertions(+), 5 deletions(-)
Index: linux/arch/x86/kernel/acpi/boot.c
===
--- linux.orig/arch/x86/kernel/acpi/boot.c
+++ linux/arch/x86/kernel/acpi/boot.c
@@ -574,6 +574,12 @@ int acpi_register_gsi(struct device *dev
return irq;
}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
void __init acpi_set_irq_model_pic(void)
{
Index: linux/drivers/acpi/pci_irq.c
===
--- linux.orig/drivers/acpi/pci_irq.c
+++ linux/drivers/acpi/pci_irq.c
@@ -495,11 +495,6 @@ int acpi_pci_irq_enable(struct pci_dev *
return 0;
}
-/* FIXME: implement x86/x86_64 version */
-void __attribute__ ((weak)) acpi_unregister_gsi(u32 i)
-{
-}
-
void acpi_pci_irq_disable(struct pci_dev *dev)
{
struct acpi_prt_entry *entry;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] ACPI: Provide generic functions for matching ACPI device nodes
From: Mika Westerberg mika.westerb...@linux.intel.com
Introduce function acpi_match_device() allowing callers to match
struct device objects with populated acpi_handle fields against
arrays of ACPI device IDs. Also introduce function
acpi_driver_match_device() using acpi_match_device() internally and
allowing callers to match a struct device object against an array of
ACPI device IDs provided by a device driver.
Additionally, introduce macro ACPI_PTR() that may be used by device
drivers to escape pointers to data structures whose definitions
depend on CONFIG_ACPI.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/acpi/scan.c | 40 +++-
include/linux/acpi.h | 28
2 files changed, 63 insertions(+), 5 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -372,8 +372,8 @@ static void acpi_device_remove_files(str
ACPI Bus operations
--
*/
-int acpi_match_device_ids(struct acpi_device *device,
- const struct acpi_device_id *ids)
+static const struct acpi_device_id *__acpi_match_device(
+ struct acpi_device *device, const struct acpi_device_id *ids)
{
const struct acpi_device_id *id;
struct acpi_hardware_id *hwid;
@@ -383,14 +383,44 @@ int acpi_match_device_ids(struct acpi_de
* driver for it.
*/
if (!device-status.present)
- return -ENODEV;
+ return NULL;
for (id = ids; id-id[0]; id++)
list_for_each_entry(hwid, device-pnp.ids, list)
if (!strcmp((char *) id-id, hwid-id))
- return 0;
+ return id;
+
+ return NULL;
+}
+
+/**
+ * acpi_match_device - Match a struct device against a given list of ACPI IDs
+ * @ids: Array of struct acpi_device_id object to match against.
+ * @dev: The device structure to match.
+ *
+ * Check if @dev has a valid ACPI handle and if there is a struct acpi_device
+ * object for that handle and use that object to match against a given list of
+ * device IDs.
+ *
+ * Return a pointer to the first matching ID on success or %NULL on failure.
+ */
+const struct acpi_device_id *acpi_match_device(const struct acpi_device_id
*ids,
+ const struct device *dev)
+{
+ struct acpi_device *adev;
- return -ENOENT;
+ if (!ids || !dev-acpi_handle
+ || ACPI_FAILURE(acpi_bus_get_device(dev-acpi_handle, adev)))
+ return NULL;
+
+ return __acpi_match_device(adev, ids);
+}
+EXPORT_SYMBOL_GPL(acpi_match_device);
+
+int acpi_match_device_ids(struct acpi_device *device,
+ const struct acpi_device_id *ids)
+{
+ return __acpi_match_device(device, ids) ? 0 : -ENOENT;
}
EXPORT_SYMBOL(acpi_match_device_ids);
Index: linux/include/linux/acpi.h
===
--- linux.orig/include/linux/acpi.h
+++ linux/include/linux/acpi.h
@@ -26,6 +26,7 @@
#define _LINUX_ACPI_H
#include linux/ioport.h /* for struct resource */
+#include linux/device.h
#ifdef CONFIG_ACPI
@@ -368,6 +369,17 @@ extern int acpi_nvs_register(__u64 start
extern int acpi_nvs_for_each_region(int (*func)(__u64, __u64, void *),
void *data);
+const struct acpi_device_id *acpi_match_device(const struct acpi_device_id
*ids,
+ const struct device *dev);
+
+static inline bool acpi_driver_match_device(struct device *dev,
+ const struct device_driver *drv)
+{
+ return !!acpi_match_device(drv-acpi_match_table, dev);
+}
+
+#define ACPI_PTR(_ptr) (_ptr)
+
#else /* !CONFIG_ACPI */
#define acpi_disabled 1
@@ -422,6 +434,22 @@ static inline int acpi_nvs_for_each_regi
return 0;
}
+struct acpi_device_id;
+
+static inline const struct acpi_device_id *acpi_match_device(
+ const struct acpi_device_id *ids, const struct device *dev)
+{
+ return NULL;
+}
+
+static inline bool acpi_driver_match_device(struct device *dev,
+ const struct device_driver *drv)
+{
+ return false;
+}
+
+#define ACPI_PTR(_ptr) (NULL)
+
#endif /* !CONFIG_ACPI */
#ifdef CONFIG_ACPI
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] ACPI: Add support for platform bus type
From: Mika Westerberg mika.westerb...@linux.intel.com
With ACPI 5 it is now possible to enumerate traditional SoC
peripherals, like serial bus controllers and slave devices behind
them. These devices are typically based on IP-blocks used in many
existing SoC platforms and platform drivers for them may already
be present in the kernel tree.
To make driver porting more straightforward, add ACPI support to
the platform bus type. Instead of writing ACPI glue drivers for
the existing platform drivers, register the platform bus type with
ACPI to create platform device objects for the drivers and bind the
corresponding ACPI handles to those platform devices.
This should allow us to reuse the existing platform drivers for the
devices in question with the minimum amount of modifications.
This changeset is based on Mika Westerberg's and Mathias Nyman's
work.
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/acpi/Makefile|1
drivers/acpi/acpi_platform.c | 285 +++
drivers/acpi/internal.h |7 +
drivers/acpi/scan.c | 16 ++
drivers/base/platform.c |5
5 files changed, 313 insertions(+), 1 deletion(-)
create mode 100644 drivers/acpi/acpi_platform.c
Index: linux/drivers/acpi/Makefile
===
--- linux.orig/drivers/acpi/Makefile
+++ linux/drivers/acpi/Makefile
@@ -37,6 +37,7 @@ acpi-y+= processor_core.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o pci_bind.o
+acpi-y += acpi_platform.o
acpi-y += power.o
acpi-y += event.o
acpi-y += sysfs.o
Index: linux/drivers/acpi/acpi_platform.c
===
--- /dev/null
+++ linux/drivers/acpi/acpi_platform.c
@@ -0,0 +1,285 @@
+/*
+ * ACPI support for platform bus type.
+ *
+ * Copyright (C) 2012, Intel Corporation
+ * Authors: Mika Westerberg mika.westerb...@linux.intel.com
+ * Mathias Nyman mathias.ny...@linux.intel.com
+ * Rafael J. Wysocki rafael.j.wyso...@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/acpi.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+
+ACPI_MODULE_NAME(platform);
+
+struct resource_info {
+ struct device *dev;
+ struct resource *res;
+ size_t n, cur;
+};
+
+static acpi_status acpi_platform_count_resources(struct acpi_resource *res,
+void *data)
+{
+ struct acpi_resource_extended_irq *acpi_xirq;
+ struct resource_info *ri = data;
+
+ switch (res-type) {
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ case ACPI_RESOURCE_TYPE_IRQ:
+ ri-n++;
+ break;
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ acpi_xirq = res-data.extended_irq;
+ ri-n += acpi_xirq-interrupt_count;
+ break;
+ case ACPI_RESOURCE_TYPE_ADDRESS32:
+ if (res-data.address32.resource_type == ACPI_IO_RANGE)
+ ri-n++;
+ break;
+ }
+
+ return AE_OK;
+}
+
+static acpi_status acpi_platform_add_resources(struct acpi_resource *res,
+ void *data)
+{
+ struct acpi_resource_fixed_memory32 *acpi_mem;
+ struct acpi_resource_address32 *acpi_add32;
+ struct acpi_resource_extended_irq *acpi_xirq;
+ struct acpi_resource_irq *acpi_irq;
+ struct resource_info *ri = data;
+ struct resource *r;
+ int irq, i;
+
+ switch (res-type) {
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ acpi_mem = res-data.fixed_memory32;
+ r = ri-res[ri-cur++];
+
+ r-start = acpi_mem-address;
+ r-end = r-start + acpi_mem-address_length - 1;
+ r-flags = IORESOURCE_MEM;
+
+ dev_dbg(ri-dev, Memory32Fixed %pR\n, r);
+ break;
+
+ case ACPI_RESOURCE_TYPE_ADDRESS32:
+ acpi_add32 = res-data.address32;
+
+ if (acpi_add32-resource_type == ACPI_IO_RANGE) {
+ r = ri-res[ri-cur++];
+ r-start = acpi_add32-minimum;
+ r-end = r-start + acpi_add32-address_length - 1;
+ r-flags = IORESOURCE_IO;
+ dev_dbg(ri-dev, Address32 %pR\n, r);
+ }
+ break
[PATCH 1/5] driver core / ACPI: Move ACPI support to core device and driver types
From: Mika Westerberg mika.westerb...@linux.intel.com
With ACPI 5 we are starting to see devices that don't natively support
discovery but can be enumerated with the help of the ACPI namespace.
Typically, these devices can be represented in the Linux device driver
model as platform devices or some serial bus devices, like SPI or I2C
devices.
Since we want to re-use existing drivers for those devices, we need a
way for drivers to specify the ACPI IDs of supported devices, so that
they can be matched against device nodes in the ACPI namespace. To
this end, it is sufficient to add a pointer to an array of supported
ACPI device IDs, that can be provided by the driver, to struct device.
Moreover, things like ACPI power management need to have access to
the ACPI handle of each supported device, because that handle is used
to invoke AML methods associated with the corresponding ACPI device
node. The ACPI handles of devices are now stored in the archdata
member structure of struct device whose definition depends on the
architecture and includes the ACPI handle only on x86 and ia64. Since
the pointer to an array of supported ACPI IDs is added to struct
device_driver in an architecture-independent way, it is logical to
move the ACPI handle from archdata to struct device itself at the same
time. This also makes code more straightforward in some places and
follows the example of Device Trees that have a poiter to struct
device_node in there too.
This changeset is based on Mika Westerberg's work.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
arch/ia64/include/asm/device.h |3 ---
arch/x86/include/asm/device.h |3 ---
drivers/acpi/glue.c| 14 ++
include/acpi/acpi_bus.h|2 +-
include/linux/device.h |4
5 files changed, 11 insertions(+), 15 deletions(-)
Index: linux/drivers/acpi/glue.c
===
--- linux.orig/drivers/acpi/glue.c
+++ linux/drivers/acpi/glue.c
@@ -134,7 +134,7 @@ static int acpi_bind_one(struct device *
char physical_node_name[sizeof(PHYSICAL_NODE_STRING) + 2];
int retval = -EINVAL;
- if (dev-archdata.acpi_handle) {
+ if (dev-acpi_handle) {
dev_warn(dev, Drivers changed 'acpi_handle'\n);
return -EINVAL;
}
@@ -169,7 +169,7 @@ static int acpi_bind_one(struct device *
acpi_dev-physical_node_count++;
mutex_unlock(acpi_dev-physical_node_lock);
- dev-archdata.acpi_handle = handle;
+ dev-acpi_handle = handle;
if (!physical_node-node_id)
strcpy(physical_node_name, PHYSICAL_NODE_STRING);
@@ -198,11 +198,10 @@ static int acpi_unbind_one(struct device
acpi_status status;
struct list_head *node, *next;
- if (!dev-archdata.acpi_handle)
+ if (!dev-acpi_handle)
return 0;
- status = acpi_bus_get_device(dev-archdata.acpi_handle,
- acpi_dev);
+ status = acpi_bus_get_device(dev-acpi_handle, acpi_dev);
if (ACPI_FAILURE(status))
goto err;
@@ -228,7 +227,7 @@ static int acpi_unbind_one(struct device
sysfs_remove_link(acpi_dev-dev.kobj, physical_node_name);
sysfs_remove_link(dev-kobj, firmware_node);
- dev-archdata.acpi_handle = NULL;
+ dev-acpi_handle = NULL;
/* acpi_bind_one increase refcnt by one */
put_device(dev);
kfree(entry);
@@ -269,8 +268,7 @@ static int acpi_platform_notify(struct d
if (!ret) {
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
- acpi_get_name(dev-archdata.acpi_handle,
- ACPI_FULL_PATHNAME, buffer);
+ acpi_get_name(dev-acpi_handle, ACPI_FULL_PATHNAME, buffer);
DBG(Device %s - %s\n, dev_name(dev), (char *)buffer.pointer);
kfree(buffer.pointer);
} else
Index: linux/include/acpi/acpi_bus.h
===
--- linux.orig/include/acpi/acpi_bus.h
+++ linux/include/acpi/acpi_bus.h
@@ -410,7 +410,7 @@ acpi_handle acpi_get_child(acpi_handle,
int acpi_is_root_bridge(acpi_handle);
acpi_handle acpi_get_pci_rootbridge_handle(unsigned int, unsigned int);
struct acpi_pci_root *acpi_pci_find_root(acpi_handle handle);
-#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)-archdata.acpi_handle))
+#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)-acpi_handle))
int acpi_enable_wakeup_device_power(struct acpi_device *dev, int state);
int acpi_disable_wakeup_device_power(struct acpi_device *dev);
Index: linux/include/linux/device.h
===
--- linux.orig/include/linux/device.h
+++ linux/include/linux/device.h
@@ -190,6 +190,7 @@ extern
[PATCH 4/5] ACPI / ia64: Export acpi_[un]register_gsi()
From: Mika Westerberg mika.westerb...@linux.intel.com
These functions might be called from modules as well so make sure
they are exported.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
arch/ia64/kernel/acpi.c |2 ++
1 file changed, 2 insertions(+)
Index: linux/arch/ia64/kernel/acpi.c
===
--- linux.orig/arch/ia64/kernel/acpi.c
+++ linux/arch/ia64/kernel/acpi.c
@@ -633,6 +633,7 @@ int acpi_register_gsi(struct device *dev
ACPI_EDGE_SENSITIVE) ? IOSAPIC_EDGE :
IOSAPIC_LEVEL);
}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
void acpi_unregister_gsi(u32 gsi)
{
@@ -644,6 +645,7 @@ void acpi_unregister_gsi(u32 gsi)
iosapic_unregister_intr(gsi);
}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
static int __init acpi_parse_fadt(struct acpi_table_header *table)
{
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] ACPI-based enumeration of devices that are not discoverable natively
Hi All, The following patch series adds support for ACPI-based enumeration of devices that aren't discoverable natively to the driver core and ACPI subsystem. It covers the generic part and the platform bus type support. Since in this case the role of ACPI is analogous to the role of Device Trees, the idea is to follow what Device Trees did previously. [1/5] Move ACPI handle to struct device and add device IDs table to struct device_driver. [2/5] Generic functions for matching ACPI device nodes. [3/5] Export GSI registration/unregistration functions on x86 (needed by [5/5]). [4/5] Export GSI registration/unregistration functions on ia64 (needed by [5/5]). [5/5] ACPI-based device enumeration support for platform devices. The patches are on top of the linux-next branch of the linux-pm.git tree with the ACPI / PM: ACPI power management callback routines for subsystems patch series applied (although that series is not strictly necessary for them to work). They have been tested by Mika. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] driver core / ACPI: Move ACPI support to core device and driver types
On Wednesday, October 31, 2012 09:24:07 AM Greg Kroah-Hartman wrote: On Wed, Oct 31, 2012 at 10:38:29AM +0100, Rafael J. Wysocki wrote: From: Mika Westerberg mika.westerb...@linux.intel.com With ACPI 5 we are starting to see devices that don't natively support discovery but can be enumerated with the help of the ACPI namespace. Typically, these devices can be represented in the Linux device driver model as platform devices or some serial bus devices, like SPI or I2C devices. Since we want to re-use existing drivers for those devices, we need a way for drivers to specify the ACPI IDs of supported devices, so that they can be matched against device nodes in the ACPI namespace. To this end, it is sufficient to add a pointer to an array of supported ACPI device IDs, that can be provided by the driver, to struct device. Moreover, things like ACPI power management need to have access to the ACPI handle of each supported device, because that handle is used to invoke AML methods associated with the corresponding ACPI device node. The ACPI handles of devices are now stored in the archdata member structure of struct device whose definition depends on the architecture and includes the ACPI handle only on x86 and ia64. Since the pointer to an array of supported ACPI IDs is added to struct device_driver in an architecture-independent way, it is logical to move the ACPI handle from archdata to struct device itself at the same time. This also makes code more straightforward in some places and follows the example of Device Trees that have a poiter to struct device_node in there too. This changeset is based on Mika Westerberg's work. Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com --- arch/ia64/include/asm/device.h |3 --- arch/x86/include/asm/device.h |3 --- drivers/acpi/glue.c| 14 ++ include/acpi/acpi_bus.h|2 +- include/linux/device.h |4 5 files changed, 11 insertions(+), 15 deletions(-) The driver core pieces look fine to me: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Great, thanks! I wonder if the x86 and/or ia64 maintainers have any reservations? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] driver core / ACPI: Move ACPI support to core device and driver types
On Wednesday, October 31, 2012 11:44:45 AM H. Peter Anvin wrote: On 10/31/2012 11:42 AM, Rafael J. Wysocki wrote: Great, thanks! I wonder if the x86 and/or ia64 maintainers have any reservations? None here. Acked-by: H. Peter Anvin h...@zytor.com Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] driver core / ACPI: Move ACPI support to core device and driver types
On Wednesday, October 31, 2012 08:03:34 PM Luck, Tony wrote: On 10/31/2012 11:42 AM, Rafael J. Wysocki wrote: I wonder if the x86 and/or ia64 maintainers have any reservations? Can you elaborate on the tested by mika that you put into the 0/5 message. Especially w.r.t. ia64. Compile tested? Boot tested? Ran with some new device that uses the ACPI enumeration provided by this series? By tested I mean run with some new devices that use the ACPI enumeration provided here, on x86. Sorry for being too vague. Nothing in the concept or code scares me ... but I'd like to know that it actually works :-) Sure. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] driver core / ACPI: Move ACPI support to core device and driver types
On Wednesday, October 31, 2012 08:33:53 PM Luck, Tony wrote: By tested I mean run with some new devices that use the ACPI enumeration provided here, on x86. Sorry for being too vague. Do you or Mika have access to an ia64 box to test. I don't. I'm not sure about Mika. If not, can you suggest some way that I could exercise this code w/o the new devices. Or at least reassure myself that all is benign in a system full of old devices. There are two parts of the new code, one that's always executed, regardless of whether or not there are devices using the support provided by this series, and the other that's executed only for those devices. All depends on what's there in acpi_platform_device_ids[] (added by patch [5/5]), which is empty for now (Mika has a separate patch adding some IDs in there). The second part of the new code will only be run and platform device objects will only be created by it if there is at least one entry in acpi_platform_device_ids[] matching a device ID of an ACPI node in the BIOS. The BIOSes of currently available ia64 systems don't contain ACPI nodes whose IDs will match the IDs of the new devices (ie. the ones that are going to be added to acpi_platform_device_ids[]), so for ia64 it should be sufficient to test that code as is (ie. without any new devices in the system). Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] driver core / ACPI: Move ACPI support to core device and driver types
On Wednesday, October 31, 2012 09:36:36 PM Luck, Tony wrote: The BIOSes of currently available ia64 systems don't contain ACPI nodes whose IDs will match the IDs of the new devices (ie. the ones that are going to be added to acpi_platform_device_ids[]), so for ia64 it should be sufficient to test that code as is (ie. without any new devices in the system). Ok - built cleanly on ia64. Boots too. Just one new console message: ACPI: bus type platform registered that seems pretty harmless. Acked-by: Tony Luck tony.l...@intel.com Thanks a lot! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 RESEND] ACPI: Add ACPI CPU hot-remove support
On Friday, October 19, 2012 01:09:53 PM Toshi Kani wrote:
Added CPU hot-remove support through an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
serializes hot-remove operations between ACPI hot-remove and sysfs
eject requests.
Signed-off-by: Toshi Kani toshi.k...@hp.com
Reviewed-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Tested-by: IgorMammedov imamm...@redhat.com
Tested-by: Vijay Mohan Pandarathil vijaymohan.pandarat...@hp.com
Tested-by: Prarit Bhargava pra...@redhat.com
This doesn't build with modular processor driver.
Thanks,
Rafael
---
v2: Rebased to the current Linus's tree.
---
drivers/acpi/processor_driver.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index e78c2a5..1cc9652 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -694,8 +694,8 @@ int acpi_processor_device_add(acpi_handle handle, struct
acpi_device **device)
static void acpi_processor_hotplug_notify(acpi_handle handle,
u32 event, void *data)
{
- struct acpi_processor *pr;
struct acpi_device *device = NULL;
+ struct acpi_eject_event *ej_event = NULL;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
int result;
@@ -727,20 +727,27 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
received ACPI_NOTIFY_EJECT_REQUEST\n));
if (acpi_bus_get_device(handle, device)) {
- printk(KERN_ERR PREFIX
- Device don't exist, dropping EJECT\n);
+ pr_err(PREFIX Device don't exist, dropping EJECT\n);
break;
}
- pr = acpi_driver_data(device);
- if (!pr) {
- printk(KERN_ERR PREFIX
- Driver data is NULL, dropping EJECT\n);
+ if (!acpi_driver_data(device)) {
+ pr_err(PREFIX Driver data is NULL, dropping EJECT\n);
break;
}
- /* REVISIT: update when eject is supported */
- ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
- break;
+ ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
+ if (!ej_event) {
+ pr_err(PREFIX No memory, dropping EJECT\n);
+ break;
+ }
+
+ ej_event-handle = handle;
+ ej_event-event = ACPI_NOTIFY_EJECT_REQUEST;
+ acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
+ (void *)ej_event);
+
+ /* eject is performed asynchronously */
+ return;
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] ACPI: Add support for platform bus type
On Wednesday, October 31, 2012 11:34:24 PM Yinghai Lu wrote:
On Wed, Oct 31, 2012 at 2:36 AM, Rafael J. Wysocki r...@sisk.pl wrote:
From: Mika Westerberg mika.westerb...@linux.intel.com
With ACPI 5 it is now possible to enumerate traditional SoC
peripherals, like serial bus controllers and slave devices behind
them. These devices are typically based on IP-blocks used in many
existing SoC platforms and platform drivers for them may already
be present in the kernel tree.
To make driver porting more straightforward, add ACPI support to
the platform bus type. Instead of writing ACPI glue drivers for
the existing platform drivers, register the platform bus type with
ACPI to create platform device objects for the drivers and bind the
corresponding ACPI handles to those platform devices.
This should allow us to reuse the existing platform drivers for the
devices in question with the minimum amount of modifications.
This changeset is based on Mika Westerberg's and Mathias Nyman's
work.
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/acpi/Makefile|1
drivers/acpi/acpi_platform.c | 285
+++
drivers/acpi/internal.h |7 +
drivers/acpi/scan.c | 16 ++
drivers/base/platform.c |5
5 files changed, 313 insertions(+), 1 deletion(-)
this patch is too big, and should be split to at least two or more.
create mode 100644 drivers/acpi/acpi_platform.c
Index: linux/drivers/acpi/Makefile
===
--- linux.orig/drivers/acpi/Makefile
+++ linux/drivers/acpi/Makefile
@@ -37,6 +37,7 @@ acpi-y+= processor_core.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
pci_bind.o
+acpi-y += acpi_platform.o
acpi-y += power.o
acpi-y += event.o
acpi-y += sysfs.o
Index: linux/drivers/acpi/acpi_platform.c
===
--- /dev/null
+++ linux/drivers/acpi/acpi_platform.c
@@ -0,0 +1,285 @@
+/*
+ * ACPI support for platform bus type.
+ *
+ * Copyright (C) 2012, Intel Corporation
+ * Authors: Mika Westerberg mika.westerb...@linux.intel.com
+ * Mathias Nyman mathias.ny...@linux.intel.com
+ * Rafael J. Wysocki rafael.j.wyso...@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/acpi.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+
+ACPI_MODULE_NAME(platform);
+
+struct resource_info {
+ struct device *dev;
+ struct resource *res;
+ size_t n, cur;
+};
+
+static acpi_status acpi_platform_count_resources(struct acpi_resource *res,
+void *data)
+{
+ struct acpi_resource_extended_irq *acpi_xirq;
+ struct resource_info *ri = data;
+
+ switch (res-type) {
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ case ACPI_RESOURCE_TYPE_IRQ:
+ ri-n++;
+ break;
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ acpi_xirq = res-data.extended_irq;
+ ri-n += acpi_xirq-interrupt_count;
+ break;
+ case ACPI_RESOURCE_TYPE_ADDRESS32:
+ if (res-data.address32.resource_type == ACPI_IO_RANGE)
+ ri-n++;
+ break;
+ }
+
+ return AE_OK;
+}
+
+static acpi_status acpi_platform_add_resources(struct acpi_resource *res,
+ void *data)
+{
+ struct acpi_resource_fixed_memory32 *acpi_mem;
+ struct acpi_resource_address32 *acpi_add32;
+ struct acpi_resource_extended_irq *acpi_xirq;
+ struct acpi_resource_irq *acpi_irq;
+ struct resource_info *ri = data;
+ struct resource *r;
+ int irq, i;
+
+ switch (res-type) {
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ acpi_mem = res-data.fixed_memory32;
+ r = ri-res[ri-cur++];
+
+ r-start = acpi_mem-address;
+ r-end = r-start + acpi_mem-address_length - 1;
+ r-flags = IORESOURCE_MEM;
+
+ dev_dbg(ri-dev, Memory32Fixed %pR\n, r);
+ break;
+
+ case
Re: [PATCH v3 3/3] Improve container_notify_cb() to support container hot-remove.
On Thursday, November 01, 2012 11:28:25 AM Yinghai Lu wrote:
On Thu, Nov 1, 2012 at 9:43 AM, Toshi Kani toshi.k...@hp.com wrote:
Rafael pointed out in my CPU hot-remove patch that
acpi_bus_hot_remove_device() was not exported for modules. Looks like
you have the same problem here. FYI, I just sent the following patch
that exports acpi_bus_hot_remove_device() and acpi_os_hotplug_execute().
https://lkml.org/lkml/2012/11/1/225
acpi_os_hotplug_execute() does not like having good quality yet.
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 941) /*
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 942)* We
can't run hotplug code in keventd_wq/kacpid_wq/kacpid_notify_wq
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 943)*
because the hotplug code may call driver .remove() functions,
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 944)*
which invoke flush_scheduled_work/acpi_os_wait_events_complete
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 945)* to
flush these workqueues.
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 946)*/
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 947) queue
= hp ? kacpi_hotplug_wq :
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 948)
(type == OSL_NOTIFY_HANDLER ? kacpi_notify_wq : kacpid_wq);
9ac61856 (Bjorn Helgaas 2009-08-31 22:32:10 + 949)
dpc-wait = hp ? 1 : 0;
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 950)
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 951) if
(queue == kacpi_hotplug_wq)
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 952)
INIT_WORK(dpc-work, acpi_os_execute_deferred);
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 953) else
if (queue == kacpi_notify_wq)
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 954)
INIT_WORK(dpc-work, acpi_os_execute_deferred);
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 955) else
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 956)
INIT_WORK(dpc-work, acpi_os_execute_deferred);
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 957)
really don't know why checking queue and call same code in every branch.
from comm:
commit bc73675b99fd9850dd914be01d71af99c5d2a1ae
Author: Zhang Rui rui.zh...@intel.com
Date: Mon Mar 22 15:48:54 2010 +0800
ACPI: fixes a false alarm from lockdep
fixes a false alarm from lockdep, as acpi hotplug workqueue waits other
workqueues.
http://bugzilla.kernel.org/show_bug.cgi?id=14553
https://bugzilla.kernel.org/show_bug.cgi?id=15521
Original-patch-from: Andrew Morton a...@linux-foundation.org
Signed-off-by: Shaohua Li shaohua...@intel.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
Signed-off-by: Len Brown len.br...@intel.com
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 8e6d866..900da68 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -758,7 +758,14 @@ static acpi_status
__acpi_os_execute(acpi_execute_type type,
queue = hp ? kacpi_hotplug_wq :
(type == OSL_NOTIFY_HANDLER ? kacpi_notify_wq : kacpid_wq);
dpc-wait = hp ? 1 : 0;
- INIT_WORK(dpc-work, acpi_os_execute_deferred);
+
+ if (queue == kacpi_hotplug_wq)
+ INIT_WORK(dpc-work, acpi_os_execute_deferred);
+ else if (queue == kacpi_notify_wq)
+ INIT_WORK(dpc-work, acpi_os_execute_deferred);
+ else
+ INIT_WORK(dpc-work, acpi_os_execute_deferred);
+
ret = queue_work(queue, dpc-work);
if (!ret) {
Len or Rafael,
can you just revert that silly patch?
We're removing this as per:
http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=commit;h=77f1966ec9763e85e5f1a9202802e90c297b4c21
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] Improve container_notify_cb() to support container hot-remove.
On Thursday, November 01, 2012 01:17:58 PM Toshi Kani wrote:
On Thu, 2012-11-01 at 11:28 -0700, Yinghai Lu wrote:
On Thu, Nov 1, 2012 at 9:43 AM, Toshi Kani toshi.k...@hp.com wrote:
Rafael pointed out in my CPU hot-remove patch that
acpi_bus_hot_remove_device() was not exported for modules. Looks like
you have the same problem here. FYI, I just sent the following patch
that exports acpi_bus_hot_remove_device() and acpi_os_hotplug_execute().
https://lkml.org/lkml/2012/11/1/225
acpi_os_hotplug_execute() does not like having good quality yet.
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 941) /*
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 942)* We
can't run hotplug code in keventd_wq/kacpid_wq/kacpid_notify_wq
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 943)*
because the hotplug code may call driver .remove() functions,
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 944)*
which invoke flush_scheduled_work/acpi_os_wait_events_complete
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 945)* to
flush these workqueues.
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 946)*/
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 947) queue
= hp ? kacpi_hotplug_wq :
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 948)
(type == OSL_NOTIFY_HANDLER ? kacpi_notify_wq : kacpid_wq);
9ac61856 (Bjorn Helgaas 2009-08-31 22:32:10 + 949)
dpc-wait = hp ? 1 : 0;
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 950)
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 951) if
(queue == kacpi_hotplug_wq)
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 952)
INIT_WORK(dpc-work, acpi_os_execute_deferred);
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 953) else
if (queue == kacpi_notify_wq)
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 954)
INIT_WORK(dpc-work, acpi_os_execute_deferred);
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 955) else
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 956)
INIT_WORK(dpc-work, acpi_os_execute_deferred);
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 957)
really don't know why checking queue and call same code in every branch.
from comm:
commit bc73675b99fd9850dd914be01d71af99c5d2a1ae
Author: Zhang Rui rui.zh...@intel.com
Date: Mon Mar 22 15:48:54 2010 +0800
ACPI: fixes a false alarm from lockdep
fixes a false alarm from lockdep, as acpi hotplug workqueue waits other
workqueues.
http://bugzilla.kernel.org/show_bug.cgi?id=14553
https://bugzilla.kernel.org/show_bug.cgi?id=15521
Original-patch-from: Andrew Morton a...@linux-foundation.org
Signed-off-by: Shaohua Li shaohua...@intel.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
Signed-off-by: Len Brown len.br...@intel.com
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 8e6d866..900da68 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -758,7 +758,14 @@ static acpi_status
__acpi_os_execute(acpi_execute_type type,
queue = hp ? kacpi_hotplug_wq :
(type == OSL_NOTIFY_HANDLER ? kacpi_notify_wq : kacpid_wq);
dpc-wait = hp ? 1 : 0;
- INIT_WORK(dpc-work, acpi_os_execute_deferred);
+
+ if (queue == kacpi_hotplug_wq)
+ INIT_WORK(dpc-work, acpi_os_execute_deferred);
+ else if (queue == kacpi_notify_wq)
+ INIT_WORK(dpc-work, acpi_os_execute_deferred);
+ else
+ INIT_WORK(dpc-work, acpi_os_execute_deferred);
+
ret = queue_work(queue, dpc-work);
if (!ret) {
Len or Rafael,
can you just revert that silly patch?
Hi Yinghai,
Per the following thread, the code seems to be written in this way to
allocate a separate lock_class_key for each work queue. It should have
had some comment to explain this, though.
https://lkml.org/lkml/2009/12/13/304
The code has evolved since then, however, so that it doesn't make sense
any more.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] ACPI: Add support for platform bus type
On Thursday, November 01, 2012 09:19:59 AM Yinghai Lu wrote:
On Thu, Nov 1, 2012 at 7:35 AM, Rafael J. Wysocki r...@sisk.pl wrote:
@@ -1544,8 +1553,13 @@ static acpi_status acpi_bus_check_add(ac
*/
device = NULL;
acpi_bus_get_device(handle, device);
- if (ops-acpi_op_add !device)
+ if (ops-acpi_op_add !device) {
acpi_add_single_object(device, handle, type, sta, ops);
+ /* Is the device a known good platform device? */
+ if (device
+!acpi_match_device_ids(device,
acpi_platform_device_ids))
+ acpi_create_platform_device(device);
+ }
That is ugly! any reason for not using acpi_driver for them.
Yes, a couple of reasons. First off, there are existing platform drivers
for
these things already and there's no reason for creating a glue layer
between
those drivers and struct acpi_device objects. Second, we're going to get
rid
of acpi_driver things entirely going forward (the existing ones will be
replaced
by platform drivers or included into the ACPI core).
that should be glue between acpi_device and platform_device.
how are you going to handle removing path ? aka when acpi_device get
trimed, how those platform get deleted?
This is a valid point.
Roughly, the idea is to walk the dev's list of physical nodes and call
.remove() for each of them in acpi_bus_remove(). Or to do something
equivalent to that.
However, we're not going to add any IDs of removable devices to
acpi_platform_device_ids[] for now, so we simply don't need to modify that
code path just yet (we'll modify it when we're about to add such devices to
that table).
there is not reason to treat those platform_device different from pci
root device and other pnp device.
Well, I agree. :-)
So those things you're talking about we'll be platform devices too in the
future.
something like attached patch. .add of acpi_driver ops could call
acpi_create_platform_device.
Been there, decided to do it differently this time.
So you are going to replace acpi_device/acpi_driver with
platform_device/platform_driver ?
Not exactly. Let me start from the big picture, though. :-)
First off, we need to unify the handling of devices by the ACPI subsystem
regardless of whether they are on a specific bus, like PCI, or they are
busless platform devices.
Currently, if a device is on a specific bus *and* there is a device node in the
ACPI namespace corresponding to it, there will be two objects based on
struct device for it eventually, the physical node, like struct pci_dev, and
the ACPI node represented by struct acpi_device. They are associated with
each other through the code in drivers/acpi/glue.c. In turn, if the device is
busless and not discoverable natively, we only create the ACPI node struct
acpi_device thing for it. Those ACPI nodes are then *sometimes* bind to
drivers (represented by struct acpi_driver).
The fact that the busless devices are *sometimes* handled by binding drivers
directly to struct acpi_device while the other devices are handled through
glue.c confuses things substantially and causes problems to happen right now
(for example, acpi_driver drivers sometimes attempt to bind to things that have
other native drivers and should really be handled by them).
Furthermore, the situation will only get worse over time if we don't do
anything about that, because we're going to see more and more devices that
won't be discoverable natively and will have corresponding nodes in the ACPI
namespace and we're going to see more buses whose devices will have such
nodes.
Moreover, for many of those devices there are native drivers present in
the kernel tree already, because they will be based on IP blocks used in
the current hardware (for example, we may see ARM-based systems based on
exactly the same hardware with ACPI BIOSes and without them). That applies
to busless devices as well as to devices on specific buses.
Now, the problem is how the unification is going to be done and I honestly
don't think we have much *choice* here. Namely, for PCI (and other devices
discoverable natively) we pretty much have to do the glue.c thing (or something
equivalent), because we need to match what we've discovered natively against
the information from the ACPI tables in the BIOS. This means that for busless
devices we need to create physical nodes as well, so that all of them are
handled by drivers binding to the physical node rather than to struct
acpi_device. This also will allow us to reuse the existing drivers with
minimum modifications (well, hopefully).
Pretty much every ACPI developer I have discussed that with so far, including
people like Matthew Garrett and Zhang Rui who have been working on ACPI for
years, seems to agree that this is the way to go.
Thus, in the long run, acpi_driver drivers will be replaced by something
Re: [PATCH v3 3/3] Improve container_notify_cb() to support container hot-remove.
On Thursday, November 01, 2012 01:16:22 PM Yinghai Lu wrote:
On Thu, Nov 1, 2012 at 1:17 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, November 01, 2012 01:17:58 PM Toshi Kani wrote:
On Thu, 2012-11-01 at 11:28 -0700, Yinghai Lu wrote:
On Thu, Nov 1, 2012 at 9:43 AM, Toshi Kani toshi.k...@hp.com wrote:
Rafael pointed out in my CPU hot-remove patch that
acpi_bus_hot_remove_device() was not exported for modules. Looks like
you have the same problem here. FYI, I just sent the following patch
that exports acpi_bus_hot_remove_device() and
acpi_os_hotplug_execute().
https://lkml.org/lkml/2012/11/1/225
acpi_os_hotplug_execute() does not like having good quality yet.
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 941) /*
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 942)* We
can't run hotplug code in keventd_wq/kacpid_wq/kacpid_notify_wq
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 943)*
because the hotplug code may call driver .remove() functions,
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 944)*
which invoke flush_scheduled_work/acpi_os_wait_events_complete
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 945)* to
flush these workqueues.
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 946)*/
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 947) queue
= hp ? kacpi_hotplug_wq :
c02256be (Zhang Rui 2009-06-23 10:20:29 +0800 948)
(type == OSL_NOTIFY_HANDLER ? kacpi_notify_wq : kacpid_wq);
9ac61856 (Bjorn Helgaas 2009-08-31 22:32:10 + 949)
dpc-wait = hp ? 1 : 0;
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 950)
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 951) if
(queue == kacpi_hotplug_wq)
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 952)
INIT_WORK(dpc-work, acpi_os_execute_deferred);
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 953) else
if (queue == kacpi_notify_wq)
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 954)
INIT_WORK(dpc-work, acpi_os_execute_deferred);
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 955) else
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 956)
INIT_WORK(dpc-work, acpi_os_execute_deferred);
bc73675b (Zhang Rui 2010-03-22 15:48:54 +0800 957)
really don't know why checking queue and call same code in every branch.
from comm:
commit bc73675b99fd9850dd914be01d71af99c5d2a1ae
Author: Zhang Rui rui.zh...@intel.com
Date: Mon Mar 22 15:48:54 2010 +0800
ACPI: fixes a false alarm from lockdep
fixes a false alarm from lockdep, as acpi hotplug workqueue waits
other
workqueues.
http://bugzilla.kernel.org/show_bug.cgi?id=14553
https://bugzilla.kernel.org/show_bug.cgi?id=15521
Original-patch-from: Andrew Morton a...@linux-foundation.org
Signed-off-by: Shaohua Li shaohua...@intel.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
Signed-off-by: Len Brown len.br...@intel.com
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 8e6d866..900da68 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -758,7 +758,14 @@ static acpi_status
__acpi_os_execute(acpi_execute_type type,
queue = hp ? kacpi_hotplug_wq :
(type == OSL_NOTIFY_HANDLER ? kacpi_notify_wq :
kacpid_wq);
dpc-wait = hp ? 1 : 0;
- INIT_WORK(dpc-work, acpi_os_execute_deferred);
+
+ if (queue == kacpi_hotplug_wq)
+ INIT_WORK(dpc-work, acpi_os_execute_deferred);
+ else if (queue == kacpi_notify_wq)
+ INIT_WORK(dpc-work, acpi_os_execute_deferred);
+ else
+ INIT_WORK(dpc-work, acpi_os_execute_deferred);
+
ret = queue_work(queue, dpc-work);
if (!ret) {
Len or Rafael,
can you just revert that silly patch?
Hi Yinghai,
Per the following thread, the code seems to be written in this way to
allocate a separate lock_class_key for each work queue. It should have
had some comment to explain this, though.
https://lkml.org/lkml/2009/12/13/304
The code has evolved since then, however, so that it doesn't make sense
any more.
oh, no, that commit should not be reverted. instead we should add some
comment for it...
that mean : three path, will have three separated static lock dep key
from every INIT_WORK.
I see.
OK, I'll drop the patch removing it.
What about the following comment:
To prevent lockdep from complaining unnecessarily, make sure that there
is a different static lockdep key created for each workqueue by using
INIT_WORK for each of them separately.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center
Re: [PATCH v3 3/3] Improve container_notify_cb() to support container hot-remove.
On Thursday, November 01, 2012 03:15:31 PM Yinghai Lu wrote:
On Thu, Nov 1, 2012 at 2:31 PM, Rafael J. Wysocki r...@sisk.pl wrote:
oh, no, that commit should not be reverted. instead we should add some
comment for it...
that mean : three path, will have three separated static lock dep key
from every INIT_WORK.
I see.
OK, I'll drop the patch removing it.
What about the following comment:
To prevent lockdep from complaining unnecessarily, make sure that there
is a different static lockdep key created for each workqueue by using
INIT_WORK for each of them separately.
created ?
how about defined ?
or just remove created
Yes, that's better.
I suppose that the appended patch may be better still, though.
Thanks,
Rafael
---
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Subject: ACPI: Make seemingly useless check in osl.c more understandable
There is a seemingly useless check in drivers/acpi/osl.c added by
commit bc73675 (ACPI: fixes a false alarm from lockdep), which really
is necessary to avoid false positive lockdep complaints. Document
this and rearrange the code related to it so that it makes fewer
checks.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/acpi/osl.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
Index: linux/drivers/acpi/osl.c
===
--- linux.orig/drivers/acpi/osl.c
+++ linux/drivers/acpi/osl.c
@@ -944,17 +944,24 @@ static acpi_status __acpi_os_execute(acp
* because the hotplug code may call driver .remove() functions,
* which invoke flush_scheduled_work/acpi_os_wait_events_complete
* to flush these workqueues.
+*
+* To prevent lockdep from complaining unnecessarily, make sure that
+* there is a different static lockdep key for each workqueue by using
+* INIT_WORK() for each of them separately.
*/
- queue = hp ? kacpi_hotplug_wq :
- (type == OSL_NOTIFY_HANDLER ? kacpi_notify_wq : kacpid_wq);
- dpc-wait = hp ? 1 : 0;
-
- if (queue == kacpi_hotplug_wq)
+ if (hp) {
+ queue = kacpi_hotplug_wq;
+ dpc-wait = 1;
INIT_WORK(dpc-work, acpi_os_execute_deferred);
- else if (queue == kacpi_notify_wq)
+ } else if (type == OSL_NOTIFY_HANDLER) {
+ queue = kacpi_notify_wq;
+ dpc-wait = 0;
INIT_WORK(dpc-work, acpi_os_execute_deferred);
- else
+ } else {
+ queue = kacpid_wq;
+ dpc-wait = 0;
INIT_WORK(dpc-work, acpi_os_execute_deferred);
+ }
/*
* On some machines, a software-initiated SMI causes corruption unless
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] ACPI: Add support for platform bus type
On Thursday, November 01, 2012 03:38:19 PM Yinghai Lu wrote: On Thu, Nov 1, 2012 at 2:21 PM, Rafael J. Wysocki r...@sisk.pl wrote: So you are going to replace acpi_device/acpi_driver with platform_device/platform_driver ? Not exactly. Let me start from the big picture, though. :-) First off, we need to unify the handling of devices by the ACPI subsystem regardless of whether they are on a specific bus, like PCI, or they are busless platform devices. Currently, if a device is on a specific bus *and* there is a device node in the ACPI namespace corresponding to it, there will be two objects based on struct device for it eventually, the physical node, like struct pci_dev, and the ACPI node represented by struct acpi_device. They are associated with each other through the code in drivers/acpi/glue.c. In turn, if the device is busless and not discoverable natively, we only create the ACPI node struct acpi_device thing for it. Those ACPI nodes are then *sometimes* bind to drivers (represented by struct acpi_driver). The fact that the busless devices are *sometimes* handled by binding drivers directly to struct acpi_device while the other devices are handled through glue.c confuses things substantially and causes problems to happen right now (for example, acpi_driver drivers sometimes attempt to bind to things that have other native drivers and should really be handled by them). Furthermore, the situation will only get worse over time if we don't do anything about that, because we're going to see more and more devices that won't be discoverable natively and will have corresponding nodes in the ACPI namespace and we're going to see more buses whose devices will have such nodes. Moreover, for many of those devices there are native drivers present in the kernel tree already, because they will be based on IP blocks used in the current hardware (for example, we may see ARM-based systems based on exactly the same hardware with ACPI BIOSes and without them). That applies to busless devices as well as to devices on specific buses. Now, the problem is how the unification is going to be done and I honestly don't think we have much *choice* here. Namely, for PCI (and other devices discoverable natively) we pretty much have to do the glue.c thing (or something equivalent), because we need to match what we've discovered natively against the information from the ACPI tables in the BIOS. This means that for busless devices we need to create physical nodes as well, so that all of them are handled by drivers binding to the physical node rather than to struct acpi_device. This also will allow us to reuse the existing drivers with minimum modifications (well, hopefully). ok, acpi_driver will be killed at first. acpi_pci_root_driver will be converted to platform driver or add acpi_pci_host_bridge to work with pci_host_bridge. Yup. BTW, the problem for hotadd pci root bus, the acpi_driver ops.add can pci root bus and create pci dev before all acpi device get created still there. https://lkml.org/lkml/2012/10/5/569 Yes, I'm aware of that, it's on my todo list FWIW. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] Improve container_notify_cb() to support container hot-remove.
On Thursday, November 01, 2012 04:39:50 PM Yinghai Lu wrote:
On Thu, Nov 1, 2012 at 4:15 PM, Rafael J. Wysocki r...@sisk.pl wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Subject: ACPI: Make seemingly useless check in osl.c more understandable
There is a seemingly useless check in drivers/acpi/osl.c added by
commit bc73675 (ACPI: fixes a false alarm from lockdep), which really
is necessary to avoid false positive lockdep complaints. Document
this and rearrange the code related to it so that it makes fewer
checks.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/acpi/osl.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
Index: linux/drivers/acpi/osl.c
===
--- linux.orig/drivers/acpi/osl.c
+++ linux/drivers/acpi/osl.c
@@ -944,17 +944,24 @@ static acpi_status __acpi_os_execute(acp
* because the hotplug code may call driver .remove() functions,
* which invoke flush_scheduled_work/acpi_os_wait_events_complete
* to flush these workqueues.
+*
+* To prevent lockdep from complaining unnecessarily, make sure that
+* there is a different static lockdep key for each workqueue by
using
+* INIT_WORK() for each of them separately.
*/
- queue = hp ? kacpi_hotplug_wq :
- (type == OSL_NOTIFY_HANDLER ? kacpi_notify_wq : kacpid_wq);
- dpc-wait = hp ? 1 : 0;
-
- if (queue == kacpi_hotplug_wq)
+ if (hp) {
+ queue = kacpi_hotplug_wq;
+ dpc-wait = 1;
INIT_WORK(dpc-work, acpi_os_execute_deferred);
- else if (queue == kacpi_notify_wq)
+ } else if (type == OSL_NOTIFY_HANDLER) {
+ queue = kacpi_notify_wq;
+ dpc-wait = 0;
yes, much clear.
at the same can you changne
dpc allocation from kmalloc with kzalloc instead.
then we save two lines for dpc-wait = 0
Good idea. :-)
After that
Acked-by: Yinghai Lu ying...@kernel.org
For completeness:
---
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Subject: ACPI: Make seemingly useless check in osl.c more understandable
There is a seemingly useless check in drivers/acpi/osl.c added by
commit bc73675 (ACPI: fixes a false alarm from lockdep), which really
is necessary to avoid false positive lockdep complaints. Document
this and rearrange the code related to it so that it makes fewer
checks.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Acked-by: Yinghai Lu ying...@kernel.org
---
drivers/acpi/osl.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
Index: linux/drivers/acpi/osl.c
===
--- linux.orig/drivers/acpi/osl.c
+++ linux/drivers/acpi/osl.c
@@ -932,7 +932,7 @@ static acpi_status __acpi_os_execute(acp
* having a static work_struct.
*/
- dpc = kmalloc(sizeof(struct acpi_os_dpc), GFP_ATOMIC);
+ dpc = kzalloc(sizeof(struct acpi_os_dpc), GFP_ATOMIC);
if (!dpc)
return AE_NO_MEMORY;
@@ -944,17 +944,22 @@ static acpi_status __acpi_os_execute(acp
* because the hotplug code may call driver .remove() functions,
* which invoke flush_scheduled_work/acpi_os_wait_events_complete
* to flush these workqueues.
+*
+* To prevent lockdep from complaining unnecessarily, make sure that
+* there is a different static lockdep key for each workqueue by using
+* INIT_WORK() for each of them separately.
*/
- queue = hp ? kacpi_hotplug_wq :
- (type == OSL_NOTIFY_HANDLER ? kacpi_notify_wq : kacpid_wq);
- dpc-wait = hp ? 1 : 0;
-
- if (queue == kacpi_hotplug_wq)
+ if (hp) {
+ queue = kacpi_hotplug_wq;
+ dpc-wait = 1;
INIT_WORK(dpc-work, acpi_os_execute_deferred);
- else if (queue == kacpi_notify_wq)
+ } else if (type == OSL_NOTIFY_HANDLER) {
+ queue = kacpi_notify_wq;
INIT_WORK(dpc-work, acpi_os_execute_deferred);
- else
+ } else {
+ queue = kacpid_wq;
INIT_WORK(dpc-work, acpi_os_execute_deferred);
+ }
/*
* On some machines, a software-initiated SMI causes corruption unless
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] ACPI / PM: Provide device PM functions operating on struct acpi_device
On Friday, November 02, 2012 01:17:10 PM Aaron Lu wrote: On 10/30/2012 11:20 PM, Rafael J. Wysocki wrote: On Tuesday, October 30, 2012 03:28:45 PM Aaron Lu wrote: On Mon, Oct 29, 2012 at 10:11:20AM +0100, Rafael J. Wysocki wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com If the caller of acpi_bus_set_power() already has a pointer to the struct acpi_device object corresponding to the device in question, it doesn't make sense for it to go through acpi_bus_get_device(), which may be costly, because it involves acquiring the global ACPI namespace mutex. For this reason, export the function operating on struct acpi_device objects used internally by acpi_bus_set_power(), so that it may be called instead of acpi_bus_set_power() in the above case, and change its name to acpi_device_set_power(). Additionally, introduce two inline wrappers for checking ACPI PM capabilities of devices represented by struct acpi_device objects. What about adding yet another wrapper to check power off capability of the device? If device has _PS3 or _PRx, it means the device can be powered off from ACPI's perspective. This is useful for ZPODD when deciding if platform has the required ability to support it. Sure, no problem with that. Perhaps you can cut a patch for that on top of this series? Do you think it is reasonable to add a new field to acpi_state.flags to represent if we, as OSPM, have a way to put the device into a ACPI device state? This field can be set once in acpi_bus_get_power_flags and used afterwards. The valid field of acpi_state.flags is what we have today, and it means whether this ACPI device state is valid for the device, but not that if OSPM can actually put the device into that power state. Yes, I think that adding such a new flag would make sense. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ACPI: Introduce a new acpi handle to determine HID match.
On Thursday, October 18, 2012 01:50:09 PM Yinghai Lu wrote:
From: Tang Chen tangc...@cn.fujitsu.com
We need to find out if one handle is for root bridge, and install notify
handler for it to handle pci root bus hot add.
At that time, root bridge acpi device is not created yet.
So acpi_match_device_ids() will not work.
This patch add a function to check if new acpi handle's HID matches a list
of IDs. The new api use acpi_device_info instead acpi_device.
-v2: updated changelog, also check length for string info...
change checking sequence by moving string comaring close to for loop.
- Yinghai
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Len Brown l...@kernel.org
Cc: linux-a...@vger.kernel.org
---
drivers/acpi/scan.c | 33 +
include/acpi/acpi_bus.h |2 ++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5dfec09..33ca993 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -312,6 +312,39 @@ int acpi_match_device_ids(struct acpi_device *device,
}
EXPORT_SYMBOL(acpi_match_device_ids);
+int acpi_match_object_info_ids(struct acpi_device_info *info,
+const struct acpi_device_id *ids)
+{
+ const struct acpi_device_id *id;
+ char *str;
+ u32 len;
+ int i;
+
+ len = info-hardware_id.length;
+ if (len) {
+ str = info-hardware_id.string;
+ if (str)
+ for (id = ids; id-id[0]; id++)
+ if (!strcmp((char *)id-id, str))
+ return 0;
+ }
+
+ for (i = 0; i info-compatible_id_list.count; i++) {
+ len = info-compatible_id_list.ids[i].length;
+ if (!len)
+ continue;
+ str = info-compatible_id_list.ids[i].string;
+ if (!str)
+ continue;
+ for (id = ids; id-id[0]; id++)
+ if (!strcmp((char *)id-id, str))
+ return 0;
+ }
+
+ return -ENOENT;
+}
+EXPORT_SYMBOL(acpi_match_object_info_ids);
EXPORT_SYMBOL_GPL, please?
+
static void acpi_free_ids(struct acpi_device *device)
{
struct acpi_hardware_id *id, *tmp;
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 608f92f..6ac415c 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -374,6 +374,8 @@ int acpi_bus_start(struct acpi_device *device);
acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle * ejd);
int acpi_match_device_ids(struct acpi_device *device,
const struct acpi_device_id *ids);
+int acpi_match_object_info_ids(struct acpi_device_info *info,
+const struct acpi_device_id *ids);
int acpi_create_dir(struct acpi_device *);
void acpi_remove_dir(struct acpi_device *);
I wonder which code path(s) is(are) going to use the new routine?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] ACPI: CPU hot-remove support
On Thursday, November 01, 2012 08:42:11 AM Toshi Kani wrote: This patchset adds support of CPU hot-remove via an ACPI eject notification to the ACPI processor driver. The CPU hot-remove operation shares the same code path with the sysfs eject operation. The patchset also exports two functions necessary to initiate hot-remove operations from modules, such as the processor driver. The patchset is based on the current Linus's tree. v3: - Added patch 1/2 to export functions for hot-remove v2: - Rebased to the latest baseline --- Toshi Kani (2): ACPI: Export functions for hot-remove ACPI: Add ACPI CPU hot-remove support Both patches applied to the linux-next branch of the linux-pm.git tree as v3.8 material. Thanks, Rafael --- drivers/acpi/osl.c | 1 + drivers/acpi/processor_driver.c | 27 +-- drivers/acpi/scan.c | 1 + 3 files changed, 19 insertions(+), 10 deletions(-) -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
