Re: 2.6.19-rc5 x86_64 irq 22: nobody cared
Yinghai Lu wrote: olivier, lspci -vvxxx please. it seems usb and audio share the interrtupts by ioapic. YH lspci -vvxxx is available at http://olivn.trollprod.org/lspci.gz 2.6.19-rc5 can be booted properly on my system if notsc parameter is used. Could it be related to http://lkml.org/lkml/2006/10/27/141 as I'm usage a dual core AMD64 ? Olivier - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19-rc5 x86_64 irq 22: nobody cared
Takashi, You are right, setting disable_msi=1 as an option for snd-hda-intel module solve my problem. Thanks Olivier Takashi Iwai wrote: At Thu, 9 Nov 2006 07:49:56 +0100, Adrian Bunk wrote: On Wed, Nov 08, 2006 at 01:44:29PM +0100, Olivier Nicolas wrote: Hi, Hi Olivier, 2.6.19-rc5 does not boot properly, I have tried pci=routeirq, irpoll without success. Full details (.config, dmesg, /proc/interrupts) are in http://olivn.trollprod.org/2.6.19-rc5-irq.tar.gz thanks for your report! I might be wrong, but looking at the dmesg: - irq 22 is the hda_intel IRQ - the irq 22: nobody cared is immediately before the hda_intel: No response from codec, disabling MSI... - in the routeirq case, the hda_intel IRQ as well as the IRQ in the error message change to 21 So it might be related to the hda_intel MSI check. To disable MSI from the beginning, set disable_msi=1 module option for snd-hda-intel. Takashi - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19-rc5 x86_64 irq 22: nobody cared
On Thu, 9 Nov 2006 07:49:56 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: On Wed, Nov 08, 2006 at 01:44:29PM +0100, Olivier Nicolas wrote: Hi, Hi Olivier, 2.6.19-rc5 does not boot properly, I have tried pci=routeirq, irpoll without success. Full details (.config, dmesg, /proc/interrupts) are in http://olivn.trollprod.org/2.6.19-rc5-irq.tar.gz thanks for your report! I might be wrong, but looking at the dmesg: - irq 22 is the hda_intel IRQ - the irq 22: nobody cared is immediately before the hda_intel: No response from codec, disabling MSI... - in the routeirq case, the hda_intel IRQ as well as the IRQ in the error message change to 21 So it might be related to the hda_intel MSI check. More likely the MSI management routines don't work for disabling MSI. I am debugging a problem where MSI doesn't work across suspend/resume, I suspect the base MSI code needs fixing. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.19-rc5 x86_64 irq 22: nobody cared
CPU0 CPU1 0:214 24856 IO-APIC-edge timer 1: 0359 IO-APIC-edge i8042 6: 0 5 IO-APIC-edge floppy 8: 0 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 0103 IO-APIC-edge i8042 14: 0128 IO-APIC-edge ide0 16: 0 0 IO-APIC-fasteoi libata 17: 1 2 IO-APIC-fasteoi bttv0 20: 22 6469 IO-APIC-fasteoi libata 21: 11 99989 IO-APIC-fasteoi ehci_hcd:usb2, HDA Intel 22: 0 1 IO-APIC-fasteoi libata, ohci_hcd:usb1 23: 0 0 IO-APIC-fasteoi libata 308: 8 2378 PCI-MSI-edge eth1 309: 0 9 PCI-MSI-edge eth1 310: 0 9 PCI-MSI-edge eth1 311: 4 2401 PCI-MSI-edge eth0 312: 0 0 PCI-MSI-edge eth0 313: 0 1 PCI-MSI-edge eth0 NMI: 74 47 LOC: 25024 24991 ERR: 0 But according to the irq router in pci conf, the ehci and audio share to use irq 20. sata0 and ohci use irq 23 sata1 use irq 22, (MAC1 share it but kernel will use MSI) sata2 use irq 21, (MAC0 share it but kernel will use MSI) the ACPI report wrong GSI for them? Can you disable the acpi and check the interrupt and lspci? YH - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Video output shutdown
nicolas ricard wrote: Hi, I run linux kernel 2.6.13 with ACPI enabled on a PC104 board from DigitalLogic with Pentium M and integrated graphic chipset (915GM or 955GM i think). The system runs with a video output and XFree86 as X server, but no input like keyboard or mouse. My problem is that after a while (~ 15'), the video output is switched off. If i plug a mouse, a mouse move is enougth to switch it on again. Do you think this is an ACPI issue? If so, how can i avoid that video switch off ? Thanks for your response. Nicolas RICARD man XFree86.conf should fix your problem... Janosch - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
New ibm-acpi development mailinglist
Hello ibm-acpi users and linux-acpi developers, In order not to generate too much extra noise in the linux-thinkpad mailinglist, and to keep driver-specific traffic outside of linux-acpi, I have created an ibm-acpi-devel mailing list on sourceforge.net. The URI for the mailman list information page is: https://lists.sourceforge.net/mailman/listinfo/ibm-acpi-devel The mailinglist is public and anyone can join, but posts from non-members will be moderated and thus may be delayed a bit. If you need some email address whitelisted for direct posting without moderation, and would rather not subscribe such address in do not receive posts mode, please contact me. I would appreciate if patches, comments and bug reports specific to ibm-acpi are directed or carbon-copied to that mailinglist from now on. Patchsets deemed ready to begin the merge-into-mainline review process shall be sent to at least both of linux-acpi and ibm-acpi-devel. In fact, please consider this email an explicit call for pending ibm-acpi patches. If you have any patches for ibm-acpi that are not yet merged or queued-for-merging into linux-acpi-2.6, please send them to ibm-acpi-devel. It doesn't matter if you sent them already to linux-acpi or to Borislav, please submit them again to ibm-acpi-devel. Should something important or interesting for ibm-acpi users happen, I will crosspost announcements to both ibm-acpi-devel and to linux-thinkpad. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] backlight: do not power off backlight when unregistering
On Mon, 06 Nov 2006, Richard Purdie wrote: Those commits were designed to standardise several behaviours amongst several drivers and this specific case was added to the core rather than coding it in each of several drivers. We therefore really need to update those other drivers too (locomo at the very least). The following in-tree drivers need changes: drivers/video/backlight/locomolcd.c drivers/video/backlight/hp680_bl.c drivers/video/backlight/corgi_bl.c I will repost the patch with locomolcd.c and hp680_bl.c included. The following in-tree (latest linux-2.6 git tree) drivers are desktop/laptop devices and likely do not want the dim and power off backlight on backlight_device_unregister behavior: drivers/video/aty/* drivers/video/riva/fbdev.c drivers/video/nvidia/nv_backlight.c drivers/misc/msi-laptop.c The ACPI drivers being converted to backlight sysfs are very unlikely to want the power off backlight on backlight_device_unregister behavior, so I have not hunted after backlight sysfs conversions in the linux-acpi-2.6 git tree. Still, linux-acpi is cc'ed. I have CC'ed the relevant people (please forgive me any ommissions) for the drivers listed above, so they can chime in if their driver should retain the dim and power off backlight on backlight_device_unregister behaviour. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] backlight: do not power off backlight when unregistering (try 2)
ACPI drivers like ibm-acpi are moving to the backlight sysfs infrastructure.
During ibm-acpi testing, I have noticed that backlight_device_unregister()
sets the display brightness and power to zero.
This causes the display to be dimmed on ibm-acpi module removal. It will
affect all other ACPI drivers that are being converted to use the backlight
class, as well. It also affects a number of framebuffer devices that are
used on desktops and laptops which might also not want such behaviour.
Since working around this behaviour requires undesireable hacks, Richard
Purdie decided that we would be better off reverting the changes in the
sysfs class, and adding the code to dim and power off the backlight device
to the drivers that want it. This patch is my attempt to do so.
Patch against latest linux-2.6.git. Changes untested, as I lack the
required hardware. Still, they are trivial enough that, apart from typos,
there is little chance of getting them wrong.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Cc: Richard Purdie [EMAIL PROTECTED]
Cc: Andriy Skulysh [EMAIL PROTECTED]
Cc: Antonino Daplas [EMAIL PROTECTED]
--
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 27597c5..de5a6b3 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -259,12 +259,6 @@ void backlight_device_unregister(struct
bl_class_device_attributes[i]);
down(bd-sem);
- if (likely(bd-props bd-props-update_status)) {
- bd-props-brightness = 0;
- bd-props-power = 0;
- bd-props-update_status(bd);
- }
-
bd-props = NULL;
up(bd-sem);
diff --git a/drivers/video/backlight/corgi_bl.c
b/drivers/video/backlight/corgi_bl.c
index d07ecb5..61587ca 100644
--- a/drivers/video/backlight/corgi_bl.c
+++ b/drivers/video/backlight/corgi_bl.c
@@ -135,6 +135,10 @@ static int corgibl_probe(struct platform
static int corgibl_remove(struct platform_device *dev)
{
+ corgibl_data.power = 0;
+ corgibl_data.brightness = 0;
+ corgibl_send_intensity(corgi_backlight_device);
+
backlight_device_unregister(corgi_backlight_device);
printk(Corgi Backlight Driver Unloaded\n);
diff --git a/drivers/video/backlight/hp680_bl.c
b/drivers/video/backlight/hp680_bl.c
index e399321..1c569fb 100644
--- a/drivers/video/backlight/hp680_bl.c
+++ b/drivers/video/backlight/hp680_bl.c
@@ -117,6 +117,10 @@ static int __init hp680bl_probe(struct p
static int hp680bl_remove(struct platform_device *dev)
{
+ hp680bl_data.brightness = 0;
+ hp680bl_data.power = 0;
+ hp680bl_send_intensity(hp680_backlight_device);
+
backlight_device_unregister(hp680_backlight_device);
return 0;
diff --git a/drivers/video/backlight/locomolcd.c
b/drivers/video/backlight/locomolcd.c
index 628571c..2d79054 100644
--- a/drivers/video/backlight/locomolcd.c
+++ b/drivers/video/backlight/locomolcd.c
@@ -200,6 +200,10 @@ static int locomolcd_remove(struct locom
{
unsigned long flags;
+ locomobl_data.brightness = 0;
+ locomobl_data.power = 0;
+ locomolcd_set_intensity(locomolcd_bl_device);
+
backlight_device_unregister(locomolcd_bl_device);
local_irq_save(flags);
locomolcd_dev = NULL;
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
+ updated-acpi-add-state-propagation-for-dynamic-broadcasting.patch added to -mm tree
The patch titled
ACPI: Add state propagation for dynamic broadcasting
has been added to the -mm tree. Its filename is
updated-acpi-add-state-propagation-for-dynamic-broadcasting.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
--
Subject: ACPI: Add state propagation for dynamic broadcasting
From: Thomas Gleixner [EMAIL PROTECTED]
This is a preparatory patch for high resolution timers and dynticks.
The local APIC timer is fast and per CPU, but it gets stopped in C3 state. On
some broken systems, especially AMD based ones it gets stopped in C2. This
also affects akpm's jinxed VAIO.
The broadcast function informs the local APIC management code that a state
which stops the local APIC is going to be entered/exited. This switches the
local APIC timer to the PIT broadcast mode. The clockevents layer takes care
of the distribution of events.
The lapic_timer_idle_broadcast() function is an empty inline for now, which
will be replaced by the later clockevents patches for the affected
architectures.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Cc: Brown, Len [EMAIL PROTECTED]
Cc: linux-acpi@vger.kernel.org
Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/processor_idle.c | 20
include/asm-i386/apic.h |1 +
include/asm-x86_64/apic.h |1 +
3 files changed, 22 insertions(+)
diff -puN
drivers/acpi/processor_idle.c~updated-acpi-add-state-propagation-for-dynamic-broadcasting
drivers/acpi/processor_idle.c
---
a/drivers/acpi/processor_idle.c~updated-acpi-add-state-propagation-for-dynamic-broadcasting
+++ a/drivers/acpi/processor_idle.c
@@ -281,11 +281,27 @@ static void acpi_propagate_timer_broadca
on_each_cpu(switch_ipi_to_APIC_timer, mask, 1, 1);
}
+/* Power(C) State timer broadcast control */
+static void acpi_state_timer_broadcast(struct acpi_processor *pr,
+ struct acpi_processor_cx *cx,
+ int broadcast)
+{
+ int state = cx - pr-power.states;
+
+ if (state = pr-power.timer_broadcast_on_state)
+ lapic_timer_idle_broadcast(broadcast);
+}
+
#else
static void acpi_timer_check_state(int state, struct acpi_processor *pr,
struct acpi_processor_cx *cstate) { }
static void acpi_propagate_timer_broadcast(struct acpi_processor *pr) { }
+static void acpi_state_timer_broadcast(struct acpi_processor *pr,
+ struct acpi_processor_cx *cx,
+ int broadcast)
+{
+}
#endif
@@ -431,6 +447,7 @@ static void acpi_processor_idle(void)
/* Get start time (ticks) */
t1 = inl(acpi_fadt.xpm_tmr_blk.address);
/* Invoke C2 */
+ acpi_state_timer_broadcast(pr, cx, 1);
acpi_cstate_enter(cx);
/* Get end time (ticks) */
t2 = inl(acpi_fadt.xpm_tmr_blk.address);
@@ -445,6 +462,7 @@ static void acpi_processor_idle(void)
/* Compute time (ticks) that we were actually asleep */
sleep_ticks =
ticks_elapsed(t1, t2) - cx-latency_ticks - C2_OVERHEAD;
+ acpi_state_timer_broadcast(pr, cx, 0);
break;
case ACPI_STATE_C3:
@@ -467,6 +485,7 @@ static void acpi_processor_idle(void)
/* Get start time (ticks) */
t1 = inl(acpi_fadt.xpm_tmr_blk.address);
/* Invoke C3 */
+ acpi_state_timer_broadcast(pr, cx, 1);
acpi_cstate_enter(cx);
/* Get end time (ticks) */
t2 = inl(acpi_fadt.xpm_tmr_blk.address);
@@ -487,6 +506,7 @@ static void acpi_processor_idle(void)
/* Compute time (ticks) that we were actually asleep */
sleep_ticks =
ticks_elapsed(t1, t2) - cx-latency_ticks - C3_OVERHEAD;
+ acpi_state_timer_broadcast(pr, cx, 0);
break;
default:
diff -puN
include/asm-i386/apic.h~updated-acpi-add-state-propagation-for-dynamic-broadcasting
include/asm-i386/apic.h
---
a/include/asm-i386/apic.h~updated-acpi-add-state-propagation-for-dynamic-broadcasting
+++ a/include/asm-i386/apic.h
@@ -113,6 +113,7 @@ extern void setup_secondary_APIC_clock (
extern int APIC_init_uniprocessor (void);
extern void disable_APIC_timer(void);
extern void enable_APIC_timer(void);
+static inline void lapic_timer_idle_broadcast(int broadcast) { }
extern void enable_NMI_through_LVT0 (void * dummy);
diff -puN
include/asm-x86_64/apic.h~updated-acpi-add-state-propagation-for-dynamic-broadcasting
include/asm-x86_64/apic.h
---
+ updated-acpi-keep-track-of-timer-broadcast.patch added to -mm tree
The patch titled
ACPI: Keep track of timer broadcast
has been added to the -mm tree. Its filename is
updated-acpi-keep-track-of-timer-broadcast.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
--
Subject: ACPI: Keep track of timer broadcast
From: Thomas Gleixner [EMAIL PROTECTED]
This is a preperatory patch for highres/dyntick:
- replace the big #ifdef ARCH_APICTIMER_STOPS_ON_C3 hackery by functions
- remove the double switch in the power verify function (in the worst case
we switched ipi to apic and 20usec later apic to ipi)
- keep track of the the state which stops local APIC timer
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Cc: Brown, Len [EMAIL PROTECTED]
Cc: linux-acpi@vger.kernel.org
Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/processor_idle.c | 67 ++--
include/acpi/processor.h |1
2 files changed, 49 insertions(+), 19 deletions(-)
diff -puN
drivers/acpi/processor_idle.c~updated-acpi-keep-track-of-timer-broadcast
drivers/acpi/processor_idle.c
--- a/drivers/acpi/processor_idle.c~updated-acpi-keep-track-of-timer-broadcast
+++ a/drivers/acpi/processor_idle.c
@@ -246,6 +246,49 @@ static void acpi_cstate_enter(struct acp
}
}
+#ifdef ARCH_APICTIMER_STOPS_ON_C3
+
+/*
+ * Some BIOS implementations switch to C3 in the published C2 state. This seems
+ * to be a common problem on AMD boxen.
+ */
+static void acpi_timer_check_state(int state, struct acpi_processor *pr,
+ struct acpi_processor_cx *cx)
+{
+ struct acpi_processor_power *pwr = pr-power;
+
+ /*
+* Check, if one of the previous states already marked the lapic
+* unstable
+*/
+ if (pwr-timer_broadcast_on_state state)
+ return;
+
+ if(cx-type == ACPI_STATE_C3 ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+ pr-power.timer_broadcast_on_state = state;
+ return;
+ }
+}
+
+static void acpi_propagate_timer_broadcast(struct acpi_processor *pr)
+{
+ cpumask_t mask = cpumask_of_cpu(pr-id);
+
+ if (pr-power.timer_broadcast_on_state INT_MAX)
+ on_each_cpu(switch_APIC_timer_to_ipi, mask, 1, 1);
+ else
+ on_each_cpu(switch_ipi_to_APIC_timer, mask, 1, 1);
+}
+
+#else
+
+static void acpi_timer_check_state(int state, struct acpi_processor *pr,
+ struct acpi_processor_cx *cstate) { }
+static void acpi_propagate_timer_broadcast(struct acpi_processor *pr) { }
+
+#endif
+
static void acpi_processor_idle(void)
{
struct acpi_processor *pr = NULL;
@@ -912,11 +955,7 @@ static int acpi_processor_power_verify(s
unsigned int i;
unsigned int working = 0;
-#ifdef ARCH_APICTIMER_STOPS_ON_C3
- int timer_broadcast = 0;
- cpumask_t mask = cpumask_of_cpu(pr-id);
- on_each_cpu(switch_ipi_to_APIC_timer, mask, 1, 1);
-#endif
+ pr-power.timer_broadcast_on_state = INT_MAX;
for (i = 1; i ACPI_PROCESSOR_MAX_POWER; i++) {
struct acpi_processor_cx *cx = pr-power.states[i];
@@ -928,21 +967,14 @@ static int acpi_processor_power_verify(s
case ACPI_STATE_C2:
acpi_processor_power_verify_c2(cx);
-#ifdef ARCH_APICTIMER_STOPS_ON_C3
- /* Some AMD systems fake C3 as C2, but still
- have timer troubles */
- if (cx-valid
- boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
- timer_broadcast++;
-#endif
+ if (cx-valid)
+ acpi_timer_check_state(i, pr, cx);
break;
case ACPI_STATE_C3:
acpi_processor_power_verify_c3(pr, cx);
-#ifdef ARCH_APICTIMER_STOPS_ON_C3
if (cx-valid)
- timer_broadcast++;
-#endif
+ acpi_timer_check_state(i, pr, cx);
break;
}
@@ -950,10 +982,7 @@ static int acpi_processor_power_verify(s
working++;
}
-#ifdef ARCH_APICTIMER_STOPS_ON_C3
- if (timer_broadcast)
- on_each_cpu(switch_APIC_timer_to_ipi, mask, 1, 1);
-#endif
+ acpi_propagate_timer_broadcast(pr);
return (working);
}
diff -puN include/acpi/processor.h~updated-acpi-keep-track-of-timer-broadcast
include/acpi/processor.h
--- a/include/acpi/processor.h~updated-acpi-keep-track-of-timer-broadcast
+++ a/include/acpi/processor.h
@@ -79,6 +79,7 @@ struct acpi_processor_power {
u32 bm_activity;
int count;
struct acpi_processor_cx states[ACPI_PROCESSOR_MAX_POWER];
+
