Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, 2008-02-21 at 00:13 -0300, Henrique de Moraes Holschuh wrote: On Wed, 20 Feb 2008, Matthew Garrett wrote: It doesn't punish them. They're the ones who are going to work with us to ensure that Linux works on their hardware, and their needs are going And since when we have to work exactly like Windows (whatever version) does in THAT case? Also, why would one thing (proper replacement for OSI(Linux)) cause any sort of difference over the other (trying to be bug-to-bug compatible with Microsoft crap). I agree with Henrique. Since we have, in fact, more Windows cases than Linux cases and for Linux, just announce that is recommended, osi=linux. Also it is possible put Linuxs bios in a kind of white-list in kernel code ... -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: Proc Lid
On Sun, 2008-02-17 at 15:04 +1000, N J wrote:
Quick question. My laptop lid is always detected as closed. How do I force
the state in /proc/acpi/buttons/lid/LID/state (might not be exact path
because i had to disable acpi on kernel boot to get xorg working) to open?
hi , I am looking for someone that had same troubles than me,
http://bugzilla.kernel.org/show_bug.cgi?id=9642
could you try the proposed patch there and report if you had success or
not.
--- a/drivers/acpi/video.c 2008-02-08 00:08:36.0 +
+++ b/drivers/acpi/video.c 2008-02-07 22:32:37.0 +
@@ -1764,7 +1765,7 @@ static int acpi_video_bus_put_devices(st
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
- return acpi_video_bus_DOS(video, 0, 0);
+ return acpi_video_bus_DOS(video, 1, 0);
}
static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
Thanks in advance,
NJ
-
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
--
Sérgio M. B.
smime.p7s
Description: S/MIME cryptographic signature
[PATCH] fix backlight in compaq nx6110
Hi Len,
I thought, tell you my last bisect kernel, for find the bug
http://bugzilla.kernel.org/show_bug.cgi?id=9642
The patch in attach, the reverts (I don't create it, by myself) of
a patch of the snapshot patch-2.6.23-rc7-git4.
Applied on kernel-2.6.23.14 fix completely, my lid button event, switch
VGA event and set and unset backlight.
I had done hibernation successfully, S3 suspend to ram feature has
worked but I need to switch to console and back to get X screen, but
this I think that is Xorg related and can be fix there.
So, I hope this patch can be accepted ...
Note, I just keep the printk because was the exactly patch that I test
it, by me can be removed.
Thanks,
--
Sérgio M. B.
--- a/drivers/acpi/video.c 2008-02-08 00:08:36.0 +
+++ b/drivers/acpi/video.c 2008-02-07 22:32:37.0 +
@@ -417,6 +417,7 @@ acpi_video_device_lcd_set_level(struct a
arg0.integer.value = level;
status = acpi_evaluate_object(device-dev-handle, _BCM, args, NULL);
+ printk(KERN_DEBUG set_level status: %x\n, status);
return status;
}
@@ -1764,7 +1765,7 @@ static int acpi_video_bus_put_devices(st
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
- return acpi_video_bus_DOS(video, 0, 0);
+ return acpi_video_bus_DOS(video, 1, 0);
}
static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
smime.p7s
Description: S/MIME cryptographic signature
backlight regration from kernel 2.6.22 to 2.6.23
Hi, As a quick message to see if any one is ware of this problem. On kernel 2.6.23 I had a problem with backlight, lid button doesn't work ! If I boot computer and close lid (to plug other devices like mouse and network), after a little while when I open lid, I can't get screen anymore , I have to reboot my laptop to have screen. On suspend after resume, I have to go to console and return to X go get screen maybe I will open other bug to ACPI Thanks in advance , -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
RE: backlight regration from kernel 2.6.22 to 2.6.23
On Thu, 2007-12-27 at 09:17 +0800, Zhang, Rui wrote: Hi, Sergio, Please open a bug at http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI And attach the dmesg and acpidump output. done at http://bugzilla.kernel.org/show_bug.cgi?id=9642 Thanks, Rui -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sergio Monteiro Basto Sent: Thursday, December 27, 2007 4:43 AM To: acpi devel Subject: backlight regration from kernel 2.6.22 to 2.6.23 Hi, As a quick message to see if any one is ware of this problem. On kernel 2.6.23 I had a problem with backlight, lid button doesn't work ! If I boot computer and close lid (to plug other devices like mouse and network), after a little while when I open lid, I can't get screen anymore , I have to reboot my laptop to have screen. On suspend after resume, I have to go to console and return to X go get screen maybe I will open other bug to ACPI Thanks in advance , -- Sérgio M. B. -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: No blacklight Re: [patch] remove debug info in acpi video
On Mon, 2007-11-26 at 09:20 +0800, Zhenyu Wang wrote: No idea how could my simple patch cause your problem... I'm not saying your patch cause the problem , I say when this messages begging to appears at more or less at same time my blacklight stops to works, but not saying that is direct related to this patch. btw , after suspend to disk and resume , blacklight works! . Just trying to help . Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
No blacklight Re: [patch] remove debug info in acpi video
Since I begging to see this message on dmesg , when i press lid button , I don't have black light On Tue, 2007-11-13 at 10:36 +0800, Zhang Rui wrote: On Tue, 2007-11-13 at 08:50 +0800, Zhenyu Wang wrote: Remove acpi video debug message. Signed-off-by: Zhenyu Wang [EMAIL PROTECTED] Acked-by: Zhang Rui [EMAIL PROTECTED] --- drivers/acpi/video.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index bac956b..9c8c8e6 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -1782,9 +1782,6 @@ static void acpi_video_bus_notify(acpi_handle handle, u32 event, void *data) struct input_dev *input; int keycode; - - printk(video bus notify\n); - if (!video) return; -- 1.5.3.3 - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To 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 -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
On Sat, 2007-07-28 at 00:47 +0200, Stefan Richter wrote: Adrian Bunk wrote: The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, It's not entirely unintuitive. That option's full name is Support for suspend on SMP and hot-pluggable CPUs. I have to give reason to Len Brown on limit the options else this is much more difficult. Make sense define SUSPEND_SMP without define HOTPLUG_CPU ? or make sense define HOTPLUG_CPU without define SUSPEND_SMP ? Even if both options could make sense, we have to have the code prepare for it, which couldn't be prepared. But it is more easier and more importante focus on major cases which is: I don't care and force some configuration and everybody test the same code. Else in ACPI we have many issues to resolve like with this define and without other, which philosophically could be interesting but is not the major case and don't let us focus on stability. Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: scary warnings
On Thu, 2007-05-31 at 20:55 -0400, Len Brown wrote: Please open a sighting at bugzilla.kernel.org against ACPI/tables and attach the output from acpidump ok, http://bugzilla.kernel.org/show_bug.cgi?id=8590 Best regards , thanks, -Len On Thursday 31 May 2007 20:11, Sergio Monteiro Basto wrote: I got this messages warnings, I just found it, after had other problems not related with ACPI, I am been running with this kernels one or two months ago, and I don't had problems, just reporting the situation, could be useful anyway. Thanks, ACPI Warning (tbfadt-0360): Ignoring BIOS FADT r2 C-state control [20070126] (...) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI Warning (tbutils-0158): Incorrect checksum in table [ ð] - 00, should be E7 [20070126] ACPI Error (tbinstal-0134): Table has invalid signature [ ð], must be SSDT or PSDT [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PDC] (Node 810037cc3b50), AE_BAD_SIGNATURE ACPI Warning (tbutils-0158): Incorrect checksum in table [ ð] - 00, should be E7 [20070126] ACPI Error (tbinstal-0134): Table has invalid signature [ ð], must be SSDT or PSDT [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU2._PDC] (Node 810037cc3a50), AE_BAD_SIGNATURE ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126] ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126] -- Sérgio M.B. - 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
scary warnings
I got this messages warnings, I just found it, after had other problems not related with ACPI, I am been running with this kernels one or two months ago, and I don't had problems, just reporting the situation, could be useful anyway. Thanks, ACPI Warning (tbfadt-0360): Ignoring BIOS FADT r2 C-state control [20070126] (...) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI Warning (tbutils-0158): Incorrect checksum in table [ ð] - 00, should be E7 [20070126] ACPI Error (tbinstal-0134): Table has invalid signature [ ð], must be SSDT or PSDT [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PDC] (Node 810037cc3b50), AE_BAD_SIGNATURE ACPI Warning (tbutils-0158): Incorrect checksum in table [ ð] - 00, should be E7 [20070126] ACPI Error (tbinstal-0134): Table has invalid signature [ ð], must be SSDT or PSDT [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU2._PDC] (Node 810037cc3a50), AE_BAD_SIGNATURE ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126] ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126] -- Sérgio M.B. BIOS-e820: 3ffb - 3ffc (ACPI data) BIOS-e820: 3ffc - 3fff (ACPI NVS) ACPI: RSDP 000F7CA0, 0014 (r0 ACPIAM) ACPI: RSDT 3FFB, 0034 (r1 A M I OEMRSDT 6000616 MSFT 97) ACPI: FACP 3FFB0200, 0084 (r2 A M I OEMFACP 6000616 MSFT 97) ACPI Warning (tbfadt-0360): Ignoring BIOS FADT r2 C-state control [20070126] ACPI: DSDT 3FFB0450, 3CD7 (r1 75D8P 75D8P0044 INTL 2002026) ACPI: FACS 3FFC, 0040 ACPI: APIC 3FFB0390, 0078 (r1 A M I OEMAPIC 6000616 MSFT 97) ACPI: MCFG 3FFB0410, 003C (r1 A M I OEMMCFG 6000616 MSFT 97) ACPI: OEMB 3FFC0040, 0046 (r1 A M I AMI_OEM 6000616 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) ACPI: IOAPIC (id[0x03] address[0xfecc] gsi_base[24]) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information ACPI: Core revision 20070126 ACPI: bus type pci registered ACPI: Interpreter enabled ACPI: (supports S0 S1 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NBPG._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *10 11 12 14 15) pnp: PnP ACPI init pnp: PnP ACPI: found 15 devices PCI: Using ACPI for IRQ routing Time: acpi_pm clocksource has been installed. ACPI: PCI Interrupt :00:02.0[A] - GSI 27 (level, low) - IRQ 27 ACPI Warning (tbutils-0158): Incorrect checksum in table [ ð] - 00, should be E7 [20070126] ACPI Error (tbinstal-0134): Table has invalid signature [ ð], must be SSDT or PSDT [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PDC] (Node 810037cc3b50), AE_BAD_SIGNATURE ACPI Warning (tbutils-0158): Incorrect checksum in table [ ð] - 00, should be E7 [20070126] ACPI Error (tbinstal-0134): Table has invalid signature [ ð], must be SSDT or PSDT [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU2._PDC] (Node 810037cc3a50), AE_BAD_SIGNATURE ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126] ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126] ACPI: PCI Interrupt :00:10.0[A] - GSI 21 (level, low) - IRQ 21 ACPI: PCI Interrupt :00:10.1[A] - GSI 21 (level, low) - IRQ 21 ACPI: PCI Interrupt :00:10.2[B] - GSI 21 (level, low) - IRQ 21 ACPI: PCI Interrupt :00:10.3[B] - GSI 21 (level, low) - IRQ 21 ACPI: PCI Interrupt :00:10.4[C] - GSI 21 (level, low) - IRQ 21 ACPI: PCI Interrupt :00:0f.0[B] - GSI 20 (level, low) - IRQ 20 ACPI: PCI Interrupt :00:0f.1[A] - GSI 20 (level, low) - IRQ 20 ACPI: PCI Interrupt :00:12.0[A] - GSI 23 (level, low) - IRQ 23 ACPI: PCI Interrupt :00:0b.0[A] - GSI 19 (level, low) - IRQ
[Fwd: [PATCH -mm] working 3D/DRI intel-agp.ko resume for i815 chip; Intel chipset testers wanted! (was: Re: intel-agp PM experiences ...)]
Hi forward this message to dri-devel Mailing List, where you could find more tester on i815 DRI drives . I hope I don't had made a loop :) Forwarded Message From: Andreas Mohr [EMAIL PROTECTED] To: Pavel Machek [EMAIL PROTECTED] Cc: Andrew Morton [EMAIL PROTECTED], [EMAIL PROTECTED], linux-acpi@vger.kernel.org, Matthew Garrett [EMAIL PROTECTED], kernel list [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [PATCH -mm] working 3D/DRI intel-agp.ko resume for i815 chip; Intel chipset testers wanted! (was: Re: intel-agp PM experiences ...) Date: Tue, 1 May 2007 16:59:47 +0200 Hi, On Thu, Jan 18, 2007 at 11:16:51PM +, Pavel Machek wrote: Hi! Especially the PCI video_state trick finally got me a working resume on 2.6.19-ck2 r128 Rage Mobility M4 AGP *WITH*(!) fully enabled and working (and keeping working!) DRI (3D). Can we get whitelist entry for suspend.sf.net? s2ram from there can do all the tricks you described, one letter per trick :-). We even got PCI saving lately. Whitelist? Let me blacklist it all the way to Timbuktu instead! I've been doing more testing, and X never managed to come back to working state without some of my couple intel-agp changes: - a proper suspend method, doing a proper pci_save_state() or improved equivalent - a missing resume check for my i815 chipset - global cache flush in _configure - restoring AGP bridge PCI config space Can you post a patch? Took way longer than I'd have wanted it to (nice daughter and stuff ;), but here it is. - add .suspend handler and pci_set_power_state() calls - add i815-specific function agp_i815_remember_state() to remember important i815 register values - add generic DEBUG_AGP_PM framework which will allow people to resume properly and help identify which registers need attention - add obvious and detailed log message to make people sit up and take notice about long-standing AGP resume issues - spelling fixes Patch against 2.6.21-rc7-mm2, my Inspiron 8000 (i815 with Radeon AGP card, internal Intel VGA unit NOT active) resumes fine with both either i815-specific register saving or generic DEBUG_AGP_PM mechanism enabled. (of course my notebook needs vbetool post and manual saving of video card PCI space, too, but even when doing all this I still had X.org lockups before whenever DRI/3D was enabled) After resume I'm now still able to run both glxgears and glxinfo without anomalies. Right now all I care about is that this gets into mainline relatively soon, since I'm rather certain that many other machines suffer from similar AGP resume lockup issues that could be debugged this way (e.g. some Thinkpads, as witnessed accidentally via IRC chats, and from the well-known don't enable DRI, that will lock up on resume! chants). Yes, this code is a cludge and somewhat far from a nicely generic extended PCI space resume framework, but we've spent almost 10 (TEN!) years without anything even remotely resembling a working cludge for AGP suspend/resume in combination with DRI, so... Feel free to offer thoughts on how this missing generic extended PCI space restore functionality could be implemented, to be used by intel-agp and various other drivers. No promise that it will be me who implements that, though ;) Whitelist entry would still be welcome. OK, I'll work on this next. Thanks! Signed-off-by: Andreas Mohr [EMAIL PROTECTED] --- linux-2.6.21-rc7-mm2.orig/drivers/char/agp/intel-agp.c 2007-05-10 14:52:26.0 +0200 +++ linux-2.6.21-rc7-mm2/drivers/char/agp/intel-agp.c 2007-05-10 14:31:48.0 +0200 @@ -31,9 +31,16 @@ extern int agp_memory_reserved; -/* Intel 815 register */ -#define INTEL_815_APCONT 0x51 -#define INTEL_815_ATTBASE_MASK ~0x1FFF +/* Intel i815 registers, see Intel spec #29068801 */ +#define I815_GMCHCFG 0x50 +#define I815_APCONT0x51 +#define I815_UNKNOWN_800x80 +#define I815_ATTBASE_MASK ~0x1FFF +#define I815_SM_RCOMP 0x98 /* Sys Mem R Compensation Ctrl */ +#define I815_SM0x9c /* System Memory Control Reg */ +#define I815_AGPCMD0xa8 /* AGP Command Register */ +#define I815_ERRSTS0xc8 /* undocumented in i815 spec; since this one is modified on resume and many other related chipsets have it, I assume it *is* ERRSTS */ +#define I815_UNKNOWN_E80xe8 /* Intel i820 registers */ #define INTEL_I820_RDCR0x51 @@ -664,7 +671,7 @@ if ((pg_start + mem-page_count) num_entries) goto out_err; - /* The i830 can't check the GTT for entries since its read only, + /* The i830 can't check the GTT for entries since it's read-only, * depend on the caller to make the correct offset decisions. */ @@ -787,7 +794,7 @@ if ((pg_start + mem-page_count) num_entries) goto out_err; - /* The i915 can't check the GTT for
Re: C2 and C3 processor states cause mouse desynchronization
On Sun, 2007-04-22 at 22:57 -0400, Lex Neva wrote: So, the questions I have: Is this a problem anyone's seen before? Is this a bug? If so, is it in linux-ACPI or psmouse (or something else)? Is there anything I can do to get my power savings and still make the mouse driver happy? Is there any chance that I can work with the linux-ACPI developers to get a fix produced? Well I am not a kernel hacker either but what give you ? cat /sys/devices/system/clocksource/clocksource0/available_clocksource cat /sys/devices/system/clocksource/clocksource0/current_clocksource and boot with parameter: report_lost_ticks and boot with parameter: notsc ( try first report_lost_ticks if you got lost ticket than boot with both notsc and report_lost_ticks ) cat /proc/interrupts At MNI got any value, different than zero ? I got all my ansync computer problems resolved at 2.6.21-rc5, but I had more problems that just a mouse desynchronization Best regards , -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
Re: 2.6.21-rc5-mm4 -- laptop lid button only triggers suspend on HP dv1240us every other time.
On Tue, 2007-04-03 at 22:44 -0700, Andrew Morton wrote: On Wed, 4 Apr 2007 00:33:36 -0500 Miles Lane [EMAIL PROTECTED] wrote: This is an old bug. It has been happening forever, but I'd love to know how I can help get this tracked down and fixed. Yes, I've been hitting something like that in the past 3-4 weeks. We started to diagnose it but I got distracted. For a start, please review http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg05094.html, then see if you are able to take it further than I was. I had a similar problem with my laptop that loose ACPI events, after suspend to disk, on kernels (I don't remember well) works on 2.6.16 or 15, stops work on 2.6.17 and 2.6.18 and works again on 2.6.19 and 20 -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: system freeze with acpi
On Sat, 2007-03-31 at 12:15 +0200, Dominique Michel wrote: My problem is at I really want to use CONFIG_X86_PM_TIMER in the ACPI config. Cheers, Dominique you should put all this information on bugzilla http://bugzilla.kernel.org/enter_bug.cgi?product=Platform%20Specific%2FHardware and _attach_ all the information on this email, what is yours CPU ? Regards -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
Re: ACPI patches in test for Linux-2.6.22
On Fri, 2007-03-09 at 23:00 -0500, Len Brown wrote: These patches are in test for Linux-2.6.22. Since we have big changes on ACPI for 2.6.21 , why we don't test all at once (why we don't also include this on 6.21) ? Best regards, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: and try remove another quirk on this computers Re: [3/6] 2.6.21-rc2: known regressions
On Fri, 2007-03-09 at 21:41 -0800, Linus Torvalds wrote: On Sat, 10 Mar 2007, Sergio Monteiro Basto wrote: With this quirk I got this oops on hibernate (but computer still working) Well, strictly speaking it's a warning, not an oops per se. What happens is that the quirk wants to do an ioremap_nocache(), which allocates memory, and that happens very early during initialization when interrupts are disabled. And you're really not supposed to allocate memory, except using GFP_ATOMIC. But we've always been lax about that during early boot, so we have stuff that does. And resume ends up doing a lot of the same things early boot does, and shows issues like this. So the quirk is probably still a good idea, and the warning message is just that - a very scary warning message, but not an indicator that anything is seriously screwed up for you. (It is an indication of a real bug, though, even though it's harmless in practice in this case) Hi, thanks Just to write, I test last fedora kernel(2.6.20-1.2981.fc7) which is based on 2.6.21-rc3-git5, without any problem, less than the scary warning, talked in this email :) Best regards, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: Strange things on 2.6.19/20 for a dual-core CPU
On Mon, 2007-02-05 at 07:04 +0100, Pavel Troller wrote: Hi! I posted the following question, when 2.6.19 was freshly out. However, nobody has answered. OK, I told myself, let's get things to stabilize, and I waited patiently for 2.6.20. Now, the things are absolutely the same, and IMHO wrong. Could anybody look at this and decide, whether it is a real bug, which has to be fixed, or not ? Hi , I also have a Pentium D with a very strange things http://bugzilla.kernel.org/show_bug.cgi?id=6419 have you test yours in older kernels? With regards, Pavel Troller - Forwarded message from Pavel Troller [EMAIL PROTECTED] - From: Pavel Troller [EMAIL PROTECTED] To: linux-acpi@vger.kernel.org Subject: Strange things on 2.6.19 for a dual-core CPU Mail-Followup-To: Pavel Troller [EMAIL PROTECTED], linux-acpi@vger.kernel.org Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi! I've updated to vanilla 2.6.19 on my Pentium-D (dual-core x86_64) box. Now I can't see even C1 in the /proc/acpi/processor/*/power output: [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU1/power active state:C0 max_cstate: C8 bus master activity: maximum allowed latency: 2000 usec states: [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU2/power active state:C0 max_cstate: C8 bus master activity: maximum allowed latency: 2000 usec states: Another interesting thing is shown here: [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU1/info processor id:0 acpi id: 1 bus mastering control: no power management:no throttling control: yes limit interface: yes [EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU2/info processor id:1 acpi id: 2 bus mastering control: no power management:no throttling control: no limit interface: no As I remember, both cores were showing the same things formerly. The only line referring to CPUs during boot is ACPI: Processor [CPU1] (supports 8 throttling states) and CPU2 is not mentioned at all. The last (but maybe not acpi-related) strange thing is that in /proc/cpuinfo, CPU1 reports 6403.56 bogomips (as always, approximately twice the clock) and CPU2 8314.32 ones (too much). It's also very suspicious. Formerly the difference was very small. Should I provide more info to debug these things, or is it OK ? With regards, Pavel Troller - End forwarded message - - 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 -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
Re: AMD X2 unsynced TSC fix?
On Wed, 2006-11-15 at 19:40 +0100, Andreas Arens wrote: as I see from the dmesg on the Fedora bugzilla, your acpi tables don't provide an entry to the HPET timer. As the VIA8237 happens to have a built-in HPET, I was able to force it on using the attached patch (against 2.6.18) on an X2 system with the same problem, which greatly improved the system stability for me. But I have one Intel(R) Pentium(R) D CPU 2.8 on a VIA8237 My latest suspect of the root of the problem of my computer is not in Processor but in those VIAs. As you find that don't provide an entry to the HPET timer on acpi tables it match, but how do you know that ? I don't send DSDT on bugzilla The patch is hand-crafted from some older clock-tick kernel tree sources I found by googling. The thing is hackish and not suitable for mainline inclusion, but may be useful nontheless. If you find it useful, and it helps you please let me know. I try your patch and it give me this differences on dmesg (file attach), detect a different timer.c but no improvement without notsc boot option and with notsc the computer got worst. -- Sérgio M.B. 2c2 Linux version 2.6.18-1.3_FC5 ([EMAIL PROTECTED]) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Wed Oct 18 23:54:57 WEST 2006 --- Linux version 2.6.18-1.13_2.6.18.2+via_8237_force_hpet_FC6 ([EMAIL PROTECTED]) (gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Thu Nov 16 00:30:41 WET 2006 24,25c24,25 On node 0 totalpages: 254172 DMA zone: 1746 pages, LIFO batch:0 --- On node 0 totalpages: 254180 DMA zone: 1754 pages, LIFO batch:0 48c48 Built 1 zonelists. Total pages: 254172 --- Built 1 zonelists. Total pages: 254180 52,53c52,55 time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. time.c: Detected 2793.051 MHz processor. --- 8800 time.c: WARNING: Enabled VIA8237 HPET at 0xfed0. time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer. time.c: Detected 2793.383 MHz processor. 55c57 time.c: Lost 1 timer tick(s)! rip release_console_sem+0x1bc/0x232) --- time.c: Lost 11 timer tick(s)! rip release_console_sem+0x1b3/0x229) 69,70c71,72 Memory: 1013704k/1048256k available (2391k kernel code, 34164k reserved, 1964k data, 204k init) Calibrating delay using timer specific routine.. 5595.08 BogoMIPS (lpj=11190172) --- Memory: 1013332k/1048256k available (2382k kernel code, 34536k reserved, 1956k data, 204k init) Calibrating delay using timer specific routine.. 5594.01 BogoMIPS (lpj=2797007) 86,88c88,90 result 12468969 Detected 12.468 MHz APIC timer. time.c: Lost 9 timer tick(s)! rip setup_boot_APIC_clock+0x12c/0x12f) --- result 12470375 Detected 12.470 MHz APIC timer. time.c: Lost 35 timer tick(s)! rip setup_boot_APIC_clock+0x128/0x12f) 92c94 Calibrating delay using timer specific routine.. 5586.53 BogoMIPS (lpj=11173068) --- Calibrating delay using timer specific routine.. 5586.07 BogoMIPS (lpj=2793035) 99a102 time.c: Lost 2 timer tick(s)! rip __do_softirq+0x5c/0xf5) 101c104 migration_cost=691 --- migration_cost=681 103c106 Freeing initrd memory: 1100k freed --- Freeing initrd memory: 1507k freed 169a173,174 hpet0: at MMIO 0xfed0 (virtual 0xff5fe000), IRQs 2, 8, 0 hpet0: 3 32-bit timers, 14318180 Hz 191c196 audit(1162252117.788:1): initialized --- audit(1163638320.760:1): initialized 210,211c215,216 ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PDC] (Node 8100027fb810), AE_BAD_HEADER ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU2._PDC] (Node 8100027fb650), AE_BAD_HEADER --- ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PDC] (Node 8100027e0810), AE_BAD_HEADER ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU2._PDC] (Node 8100027e0650), AE_BAD_HEADER 249d253 PM: Adding info for serio:serio1 250a255 PM: Adding info for serio:serio1 259c264 Write protecting the kernel read-only data: 451k --- Write protecting the kernel read-only data: 444k 261,308d265 SCSI subsystem initialized libata version 2.00 loaded. sata_via :00:0f.0: version 2.0 ACPI: PCI Interrupt :00:0f.0[B] - GSI 20 (level, low) - IRQ 193 sata_via :00:0f.0: routed to hard irq line 3 ata1: SATA max UDMA/133 cmd 0xD880 ctl 0xD802 bmdma 0xD080 irq 193 ata2: SATA max UDMA/133 cmd 0xD480 ctl 0xD402 bmdma 0xD088 irq 193 scsi0 : sata_via PM: Adding info for No Bus:host0 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) input: ImPS/2 Generic Wheel Mouse as /class/input/input1 ata1.00: ATA-7, max UDMA/100, 390721968 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/100 scsi1 : sata_via PM: Adding info for No Bus:host1 ata2: SATA link down 1.5 Gbps (SStatus 0 SControl 300) ATA: abnormal status 0x7F on port 0xD487 time.c: Lost 1 timer tick(s)! rip __do_softirq+0x5c/0xf5) PM: Adding info for No Bus:target0:0:0 Vendor: ATA Model: Maxtor 6L200M0Rev: BANC Type:
Re: AMD X2 unsynced TSC fix?
yap Andreas Arens send the patch just for me, I am sending it to the
maling lists.
On Thu, 2006-11-16 at 01:38 +, Sergio Monteiro Basto wrote:
On Wed, 2006-11-15 at 19:40 +0100, Andreas Arens wrote:
as I see from the dmesg on the Fedora bugzilla, your acpi tables
don't provide an entry to the HPET timer.
As the VIA8237 happens to have a built-in HPET, I was able to force it
on using the
attached patch (against 2.6.18) on an X2 system with the same
problem, which greatly improved the system stability for me.
But I have one Intel(R) Pentium(R) D CPU 2.8 on a VIA8237
My latest suspect of the root of the problem of my computer is not in
Processor but in those VIAs. As you find that don't provide an entry to
the HPET timer on acpi tables it match, but how do you know that ?
I don't send DSDT on bugzilla
The patch is hand-crafted from some older clock-tick kernel tree
sources I found by googling.
The thing is hackish and not suitable for mainline inclusion,
but may be useful nontheless.
If you find it useful, and it helps you please let me know.
I try your patch and it give me this differences on dmesg (file attach),
detect a different timer.c but no improvement without notsc boot option
and with notsc the computer got worst.
--
Sérgio M.B.
--- linux-2.6.18-gentoo-r2/arch/x86_64/kernel/time.c.unpatched 2006-11-15 19:29:07.0 +0100
+++ linux-2.6.18-gentoo-r2/arch/x86_64/kernel/time.c 2006-11-15 19:30:51.0 +0100
@@ -42,6 +42,9 @@
#ifdef CONFIG_X86_LOCAL_APIC
#include asm/apic.h
#endif
+#if 1
+#include linux/pci_ids.h
+#endif
#ifdef CONFIG_CPU_FREQ
static void cpufreq_delayed_get(void);
@@ -815,6 +818,48 @@
static int hpet_init(void)
{
unsigned int id;
+#if 1
+ union conf_address {
+ struct {
+ u8 reg;
+ u8 func: 3;
+ u8 dev: 5;
+ u8 bus;
+ u8 reserved:7;
+ u8 enable: 1;
+ } bits;
+ u32 dword;
+ };
+ union conf_address ca = {
+ .bits.reg = 0,
+ .bits.dev = 17,
+ .bits.enable = 1
+ };
+ union {
+ struct {
+ u8 control;
+ u8 address[3];
+ } hpet;
+ unsigned raw;
+ } hpet;
+ u32 vendor_id, control;
+
+ control = inl(0xcf8);
+ printk(%X\n, control);
+ outl(ca.dword, 0xcf8);
+ vendor_id = inl(0xcfc);
+ if (vendor_id == (PCI_VENDOR_ID_VIA + (PCI_DEVICE_ID_VIA_8237 16))) {
+ hpet.raw = 0xFED0;
+ hpet.hpet.control = 0x80;
+ ca.bits.reg = 0x68;
+ outl(ca.dword, 0xcf8);
+ outl(hpet.raw, 0xcfc);
+ outl(ca.dword, 0xcf8);
+ vxtime.hpet_address = (inl(0xcfc) 0xFF00);
+ printk(KERN_WARNING time.c: WARNING: Enabled VIA8237 HPET
+ at %#lx.\n, vxtime.hpet_address);
+ }
+#endif
if (!vxtime.hpet_address)
return -1;
smime.p7s
Description: S/MIME cryptographic signature
Re: SMP broken on pre-ACPI machine.
On Wed, 2006-10-18 at 18:24 -0400, Dave Jones wrote:
I've been chasing a bug that got filed against the Fedora kernel
a while back: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199052
This is a dual pentium pro from an era before we had ACPI, and
it seems to be falling foul of this test in smpboot.c ..
if (!smp_found_config !acpi_lapic) {
printk(KERN_NOTICE SMP motherboard not detected.\n);
smpboot_clear_io_apic_irqs();
phys_cpu_present_map = physid_mask_of_physid(0);
if (APIC_init_uniprocessor())
printk(KERN_NOTICE Local APIC not detected.
Using dummy APIC emulation.\n);
map_cpu_to_logical_apicid();
cpu_set(0, cpu_sibling_map[0]);
cpu_set(0, cpu_core_map[0]);
return;
}
My initial reaction is that the !acpi_lapic test should be conditional
on some variable that gets set if the ACPI parsing actually succeeded.
Thoughts?
Dave
acpi=off ? this machine should work with APM. BTW, so time ago, this
machine would enter in ACPI blacklist (by the year of bios) and ACPI was
turned off automatically.
--
Sérgio M.B.
smime.p7s
Description: S/MIME cryptographic signature
Re: ACPI Exception (acpi_thermal-0412)
Hi, I think this should be reported on ACPI mailing list , so I am Forwarding to this list On Thu, 2006-09-14 at 19:47 -0400, Chuck Ebbert wrote: I get this message at boot on 2.6.18-rc6: ACPI Exception (acpi_thermal-0412): AE_NOT_FOUND, Invalid active threshold [0] [20060707] Followed by: ACPI: Thermal Zone [THRM] (47 C) And looking in /proc/acpi/thermal_zone/THRM/cooling_mode, I see: setting not supported cooling mode: passive The fan seems to run at low speed even when CPU temp is stable at 37C, and speeds up when it gets warmer, so there seems to be no overheating problem (highest temp seen under full load is 60C.) Is this normal? -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
[Fwd: [patch 2.6.18-rc7] ACPI: build warnings begone (x86_64)]
Hi, I think this should be reported on
ACPI mailing list , so I am Forwarding to this list
Forwarded Message
From: David Brownell [EMAIL PROTECTED]
To: Brown, Len [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
Subject: [patch 2.6.18-rc7] ACPI: build warnings begone (x86_64)
Date: Wed, 13 Sep 2006 21:00:33 -0700
This makes various ACPI compiler warnings go away (x86_64),
making builds be warning-free again.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: g26/drivers/acpi/executer/exmutex.c
===
--- g26.orig/drivers/acpi/executer/exmutex.c 2006-07-14 10:03:04.0
-0700
+++ g26/drivers/acpi/executer/exmutex.c 2006-09-13 13:31:10.0
-0700
@@ -266,10 +266,10 @@ acpi_ex_release_mutex(union acpi_operand
walk_state-thread-thread_id)
(obj_desc-mutex.os_mutex != ACPI_GLOBAL_LOCK)) {
ACPI_ERROR((AE_INFO,
- Thread %X cannot release Mutex [%4.4s] acquired by
thread %X,
- (u32) walk_state-thread-thread_id,
+ Thread %p cannot release Mutex [%4.4s] acquired by
thread %p,
+ walk_state-thread-thread_id,
acpi_ut_get_node_name(obj_desc-mutex.node),
- (u32) obj_desc-mutex.owner_thread-thread_id));
+ obj_desc-mutex.owner_thread-thread_id));
return_ACPI_STATUS(AE_AML_NOT_OWNER);
}
Index: g26/drivers/acpi/tables/tbget.c
===
--- g26.orig/drivers/acpi/tables/tbget.c 2006-07-14 10:03:04.0
-0700
+++ g26/drivers/acpi/tables/tbget.c 2006-09-13 13:37:27.0 -0700
@@ -324,7 +324,7 @@ acpi_tb_get_this_table(struct acpi_point
if (header-length sizeof(struct acpi_table_header)) {
ACPI_ERROR((AE_INFO,
- Table length (%X) is smaller than minimum (%X),
+ Table length (%X) is smaller than minimum (%zX),
header-length, sizeof(struct acpi_table_header)));
return_ACPI_STATUS(AE_INVALID_TABLE_LENGTH);
Index: g26/drivers/acpi/utilities/utmutex.c
===
--- g26.orig/drivers/acpi/utilities/utmutex.c 2006-07-14 10:03:04.0
-0700
+++ g26/drivers/acpi/utilities/utmutex.c 2006-09-13 13:39:24.0
-0700
@@ -258,8 +258,8 @@ acpi_status acpi_ut_acquire_mutex(acpi_m
acpi_gbl_mutex_info[mutex_id].thread_id = this_thread_id;
} else {
ACPI_EXCEPTION((AE_INFO, status,
- Thread %X could not acquire Mutex [%X],
- (u32) this_thread_id, mutex_id));
+ Thread %p could not acquire Mutex [%X],
+ this_thread_id, mutex_id));
}
return (status);
Index: g26/drivers/acpi/tables/tbrsdt.c
===
--- g26.orig/drivers/acpi/tables/tbrsdt.c 2006-07-14 10:03:04.0
-0700
+++ g26/drivers/acpi/tables/tbrsdt.c 2006-09-13 13:38:39.0 -0700
@@ -187,7 +187,7 @@ acpi_status acpi_tb_validate_rsdt(struct
if (table_ptr-length sizeof(struct acpi_table_header)) {
ACPI_ERROR((AE_INFO,
- RSDT/XSDT length (%X) is smaller than minimum
(%X),
+ RSDT/XSDT length (%X) is smaller than minimum
(%zX),
table_ptr-length,
sizeof(struct acpi_table_header)));
-
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/
--
Sérgio M.B.
smime.p7s
Description: S/MIME cryptographic signature
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ok , quick question what file in kernel do the dmesg line : ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 drivers/pci/quirks.c ? Thanks, -- Sérgio M. B. - 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
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11, why not in 9 ?
drivers/acpi/pci_link.c, line #583 acpi_irq_penalty[link-irq.active] += PIRQ_PENALTY_PCI_USING; printk(PREFIX %s [%s] enabled at IRQ %d\n, acpi_device_name(link-device), acpi_device_bid(link-device), link-irq.active); any clue about this problem ? Forwarded Message From: Sergio Monteiro Basto Subject: Re: [PATCH V3] VIA IRQ quirk behaviour change Date: Wed, 13 Sep 2006 01:48:28 +0100 On Tue, 2006-09-12 at 23:38 +0200, Stian Jordet wrote: On tir, 2006-09-12 at 13:37 +0100, Sergio Monteiro Basto wrote: Ok, as a quick answer, you have a very primitive VIA SMP board, which make me remember my old laptop. I maintain what a had write in previous emails about this system. Seeing the configuration of irqs on windows, USB are in 9, so could be a clue. If I had your board, I'll try not quirk USB (cause quirk put USB in 11) and make USB interrupts work as IO-APIC-edge. 9: IO-APIC-edge uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3 The point is, that even when I do not quirk (just insert return at the top of the quirk-function), usb still uses irq 11 (as I wrote here: http://lkml.org/lkml/2006/9/6/49 ), but won't work. And acpi (on interrupt 9) gets an interrupt storm, and gets disabled. Good point , you got on your dmesg of kernel 2.6.18-rc6 (http://lkml.org/lkml/2006/9/10/120) USB Universal Host Controller Interface driver v3.0 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 ACPI: PCI Interrupt :00:11.2[D] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 PCI: VIA IRQ fixup for :00:11.2, from 9 to 11 uhci_hcd :00:11.2: UHCI Host Controller uhci_hcd :00:11.2: new USB bus registered, assigned bus number 1 uhci_hcd :00:11.2: irq 11, io base 0x9800 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected but before ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) LNKD was on 9, so may be the bug is on ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 you have to investigate :) Further more, your interrupts have 4 steps ACPI: PCI Interrupt :00:11.2[D] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 and mine just got 3 ACPI: PCI Interrupt :00:10.1[A] - GSI 21 (level, low) - IRQ 201 But if I somehow got usb using irq 9, all my problems might vanish... -Stian - 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: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
If you have a specific issue/problem, it would probably be
better just to focus on that.
on linux-2.6.17/drivers/pci/quirks.c
* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
*/
static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;
I want here put something like: if ( dev-irq != XT-PIC) return and don't
quirk this dev.
else
new_irq = dev-irq 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq);
--
Sérgio M. B.
-
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: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Thu, 2006-06-22 at 14:29 -0700, Randy.Dunlap wrote:
On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:
On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
If you have a specific issue/problem, it would probably be
better just to focus on that.
on linux-2.6.17/drivers/pci/quirks.c
* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
*/
static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;
I want here put something like: if ( dev-irq != XT-PIC) return and don't
quirk this dev.
else
I don't think the interrupt device mode is known by this code (AFAICT
with a quick look). The function is only called for certain VIA chipsets.
Do you want the quirk for any particular hardware device?
You might be able to look at the function's dev parameter
to decide on using the quirk or not.
new_irq = dev-irq 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq);
yap, in my opinion this function should back to
--- orig/drivers/pci/quirks.c 2006-06-21 20:25:41.0 +1000
+++ linux-2.6.17-rc6-mm2/drivers/pci/quirks.c 2006-06-21 20:25:08.0
+1000
@@ -662,13 +662,7 @@
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0,
quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1,
quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3,
quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686,
quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4,
quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
/*
* VIA VT82C598 has its device ID settable and many BIOSes
But do you know or not ? how I know if dev-irq is XT-pic ?
--
Sérgio M. B.
smime.p7s
Description: S/MIME cryptographic signature
Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]
On Thu, 2006-06-22 at 15:54 -0700, Chris Wedgwood wrote: On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto wrote: yap, in my opinion this function should back to +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq); this is *obviousyl* wrong, it should never have been merged like that and there are reports and complaints this causes problems for some people It was like that in kernel 2.6.16 and previous since, I don't know, 2.6.9 or 2.6.13 we should first attempt to get all the IDs (some are clearly missing still, patch coming up to address that) and where that fails perhaps have a kernel command-line parameter to be overly aggressive as a stop-gap until we van figure out the proper solution I believe this quirks is just for VIA system with interrupts in XT-PIC mode (like my old laptop). i'd also like to figure out why the quirk is needed/fails when people are using ACPI for interrupt routing as presumbly that must work as windows relies on it yes, this is other mysterious, why boot with acpi=noirq could be one workaround. But could be other problem more related with usb drives. smime.p7s Description: S/MIME cryptographic signature
Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]
Hi, In first thread of this issue in LKML, some months ago, (right now, I don't have the link). After some discussion, someone arrive the conclusion of that: You only need this quirks, if interrupts are in XT-PIC mode and is harmless if don't (and should only run for VIA southbridges). So if you are in XT-PIC mode, it is more probability that patch -R in question, have some affect. cat /proc/interrupts give you: IO-APIC-... or XT-PIC ? and what PCI_IDs do you have ? (lspci -n) Other issue, you can't revert this patch cleanly because after that we have other patch that adds some more IDs. So just delete any declare of PCI_DEVICE_ID_VIA_82C... and add one declare with PCI_ANY_ID Thanks, Sérgio M. B. On Tue, 2006-06-20 at 04:40 -0700, Andrew Morton wrote: You could try a `patch -R' of the below. commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11 Author: Chris Wedgwood [EMAIL PROTECTED] Date: Tue Apr 18 23:57:09 2006 -0700 - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]
someone has it has a case similar and said that won't work without acpi=noirq http://bugzilla.kernel.org/show_bug.cgi?id=6654 On Tue, 2006-06-20 at 16:09 +0400, Sergey Vlasov wrote: On Tue, Jun 20, 2006 at 09:21:35PM +1000, Johny wrote: [...] Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs and also .17 itself), rc3 works a treat for using USB. I suspect the following line missing in dmesg for rc4 is the reason; -PCI: Via IRQ fixup for :00:11.1, from 255 to 11 Well, not exactly this line (:00:11.1 is the IDE controller, which is in legacy mode and therefore does not use its PCI interrupt), but the next similar line is for the USB 2.0 (EHCI) controller: -PCI: Via IRQ fixup for :00:10.3, from 5 to 10 See the following dmesg files for details; http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working And the diff, for convenience; http://www.agotnes.com/kernelStuff/diff-rc3_rc4 Try as root: setpci -s 00:10.3 INTERRUPT_LINE=0a (this matches ehci_hcd :00:10.3: irq 10, ... in dmesg). If after doing this USB works again (you will need to replug USB devices), the missing VIA IRQ quirk is definitely the problem. I have a Via chipset motherboard (for my sins), further details available on request, again, for convenience, the lspci; http://www.agotnes.com/kernelStuff/lspci You seem to have also the builtin audio and Ethernet on this board - these devices may have the same problem, if you tried to use them. A couple of possible suspect patches introduced in the changelog for rc4 were (with the first one looking particularly interesting, the others less interesting as I go down the list); [PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges [PATCH] x86_64: avoid IRQ0 ioapic pin collision [PATCH] PCI: fix via irq SATA patch [ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips [ALSA] via82xx: tweak VT8251 workaround [ALSA] via82xx: add support for VIA VT8251 (AC'97) I'm no kernel hacker, so I'm not sure how I'd isolate this one patch and reverse / modify it. Please let me know how I can progress testing this as I'm currently prevented from using USB with the latest set of kernels on my test server... I've got all kernels in the 2.6.17-rc1 through to .17 itself there, plus a variety of mm ones too, so patches against any of those I can very easily test. Please keep me cc'd as I'm not on all these lists, thanks :) :)Johny Johny ?gotnes wrote: didn't go through due to missing vger. ... Subject: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues From: Johny [EMAIL PROTECTED] Date: Sun, 18 Jun 2006 21:37:00 +1000 To: Alan Stern [EMAIL PROTECTED] To: Alan Stern [EMAIL PROTECTED] CC: Johny [EMAIL PROTECTED], USB development list linux-usb-devel@lists.sourceforge.net, kernel list linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED] All, I've now tested the following; 2.6.17-rc6-mm2 with the following patch applied; --- git-acpi.patch from ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm2/broken-out/ --- With no difference to the end-result. Next I stripped out 802.11 generic support and acx111 drivers from the kernel (including the acpi patches) to check if it clashes, but the same errors occur Thirdly, I booted with acpi=off on the command line with two kernels, the stock 2.6.17-rc6-mm2 (no acpi patch and including acx111) and the one including the acpi patch and no acx111, the results were; acpi_patch; works a treat, picks up USB devices as expected. stock; works a treat, picks up USB devices as expected, and my acx111 card works too :) Now I'm looking for good suggestions again, this definitely looks like it is related to ACPI, hence the cc' to that list too, as requested by Andrew M. I'm happy to apply patches / config changes as appropriate and for those who may ask for my .config files, please see; http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2 http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2git-acpi_patch Also, I left the output of lspci there for reference; http://www.agotnes.com/kernelStuff/lspci Cheers, :)Johny Alan Stern wrote: [Moved to linux-usb-devel in the hope of getting additional help] On Thu, 15 Jun 2006, Johny wrote: Alan, See comments interspersed, thanks for your assistance :) Alan Stern wrote: On Tue, 13 Jun 2006, Johny wrote: Is this best suited to this mailing list? It's appropriate. I
Re: what is MCFG area ?
On Wed, 2006-06-07 at 06:15 +0200, Pavel Troller wrote: On my buggy computer i get cat dmesg09 | grep MM\|MCFG ACPI: MCFG (v001 A M I OEMMCFG 0x05000602 MSFT 0x0097) @ 0x3ffb0410 PCI: BIOS Bug: MCFG area is not E820-reserved PCI: Not using MMCONFIG. PCI-DMA: Disabling IOMMU. I'm getting exactly the same messages, just the numbers in the MCFG line are different: [EMAIL PROTECTED]:~# dmesg | grep MM\|MCFG ACPI: MCFG (v001 A M I OEMMCFG 0x11000524 MSFT 0x0097) @ 0x3f7d03f0 PCI: BIOS Bug: MCFG area is not E820-reserved PCI: Not using MMCONFIG. PCI-DMA: Disabling IOMMU. It's on a MSI motherboard with Intel 945 chipset (MS-7210). The machine otherwise works very well. The Disabling IOMMU message I'm getting also on another, Nvidia NF4/Opteron based board, without this MCFG bug. I think it's unrelated and because Linux properly detected the BIOS bug and probably fixed it, I think the MCFG message is harmless. With regards, Pavel Troller yes, IOMMU is a different thing some AGPs have it. But I don't what is too. Sérgio M. B. - 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 12/13] Fix HPET operation on 64-bit NVIDIA platforms
Hi,
I experience this kernel panic during boot with acpi=off and IIRC
pci=noacpi, but what I like to know if this can resolve any other
problems on my bug: http://bugzilla.kernel.org/show_bug.cgi?id=6419
http://bugzilla.kernel.org/show_bug.cgi?id=6419#c17
btw I will try this patch anyway
Thanks,
On Thu, 2006-06-01 at 20:18 -0700, [EMAIL PROTECTED] wrote:
From: Andy Currid [EMAIL PROTECTED]
This patch fixes a kernel panic during boot that occurs on NVIDIA platforms
that have HPET enabled.
When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is
advertised as such in the ACPI APIC table - but an earlier workaround in the
kernel was ignoring this override. The fix is to honor timer IRQ overrides
from ACPI when HPET is detected on an NVIDIA platform.
Signed-off-by: Andy Currid [EMAIL PROTECTED]
Cc: Brown, Len [EMAIL PROTECTED]
Cc: Yu, Luming [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/x86_64/kernel/io_apic.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff -puN
arch/x86_64/kernel/io_apic.c~fix-hpet-operation-on-64-bit-nvidia-platforms
arch/x86_64/kernel/io_apic.c
---
devel/arch/x86_64/kernel/io_apic.c~fix-hpet-operation-on-64-bit-nvidia-platforms
2006-06-01 20:17:10.0 -0700
+++ devel-akpm/arch/x86_64/kernel/io_apic.c 2006-06-01 20:17:10.0
-0700
@@ -271,6 +271,18 @@ __setup(enable_8254_timer, setup_enabl
#include linux/pci_ids.h
#include linux/pci.h
+
+#ifdef CONFIG_ACPI
+
+static int nvidia_hpet_detected __initdata;
+
+static int __init nvidia_hpet_check(unsigned long phys, unsigned long size)
+{
+ nvidia_hpet_detected = 1;
+ return 0;
+}
+#endif
+
/* Temporary Hack. Nvidia and VIA boards currently only work with IO-APIC
off. Check for an Nvidia or VIA PCI bridge and turn it off.
Use pci direct infrastructure because this runs before the PCI subsystem.
@@ -317,11 +329,19 @@ void __init check_ioapic(void)
return;
case PCI_VENDOR_ID_NVIDIA:
#ifdef CONFIG_ACPI
- /* All timer overrides on Nvidia
-seem to be wrong. Skip them. */
- acpi_skip_timer_override = 1;
- printk(KERN_INFO
- Nvidia board detected. Ignoring ACPI timer override.\n);
+ /*
+ * All timer overrides on Nvidia are
+ * wrong unless HPET is enabled.
+ */
+ nvidia_hpet_detected = 0;
+ acpi_table_parse(ACPI_HPET,
+ nvidia_hpet_check);
+ if (nvidia_hpet_detected == 0) {
+ acpi_skip_timer_override = 1;
+ printk(KERN_INFO Nvidia board
+ detected. Ignoring ACPI
+ timer override.\n);
+ }
#endif
/* RED-PEN skip them on mptables too? */
return;
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To 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
what is MCFG area ?
http://lkml.org/lkml/2006/3/23/213 On my buggy computer i get cat dmesg09 | grep MM\|MCFG ACPI: MCFG (v001 A M I OEMMCFG 0x05000602 MSFT 0x0097) @ 0x3ffb0410 PCI: BIOS Bug: MCFG area is not E820-reserved PCI: Not using MMCONFIG. PCI-DMA: Disabling IOMMU. Should ACPI read MCFG area ? Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: ACPI screwing up USB ehci_hcd with kernel 2.6.16.18
Hi, Some of yours hardware have same IDs than mine you have as relevant ; cat /usr/include/linux/pci_ids.h | grep 3189 #define PCI_DEVICE_ID_VIA_8377_00x3189 #define PCI_DEVICE_ID_VIA_82C586_1 0x0571 #define PCI_DEVICE_ID_VIA_82C586_2 0x3038 #define PCI_DEVICE_ID_VIA_8237 0x3227 #define PCI_DEVICE_ID_NVIDIA_GEFORCE4_TI_4800_8X0x0281 I have PCI_DEVICE_ID_VIA_82C586_1 PCI_DEVICE_ID_VIA_82C586_2 PCI_DEVICE_ID_VIA_8237_SATA On kernel 2.6.16.17 enter this patch which, if you don't use kernel-rc version doesn't change nothing :D http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel% 2Fv2.6%2Fincr%2Fpatch-2.6.16.16-17.bz2;z=12 if you compile your kernel, you could try remove this 2 lines, DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq); DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq); to see if ACPI IRQ routing works better: Well, this can be done like this cd drives/pci edit and delete the lines on quirks.c cd ../.. make bzImage (backup mv /boot/vmlinuz-2.6.16.18 /boot/vmlinuz-2.6.16.18.orig) mv arch/x86_64/boot/bzImage /boot/vmlinuz-2.6.16.18) and reboot My question which is not meaningfully, because I made a little confusion, but is if you has used other version of kernel before ? Maybe the best is open o bug in bugzilla with a complete dmesg and one lspci -n , etc. I am little curious, why your interrupts are XT-PIC and not IO-APIC Thanks for the report , On Tue, 2006-05-30 at 22:26 +0200, Paul Surgeon wrote: On Monday 29 May 2006 14:11, Sergio Monteiro Basto wrote: and before ? can you send lspci -n ? I can send you a lot more than that. :) I attached a zip file containing 10 log files which hopefully won't be an issue with the mailing list. (a single uncompressed dmesg log is 15KB so hopefully an 18KB zip file won't be a problem) There are two versions of each log file. One before I added acpi=noirq to the boot options and one after I added acpi=noirq to the boot options. logs : dmesg (dmesg after bootup - USB storage device not plugged in) dmesg-usb-plugin (dmesg output after plugging in USB storage device) interrupts lspci lspci-n Hope that helps a bit Paul smime.p7s Description: S/MIME cryptographic signature
Re: ACPI screwing up USB ehci_hcd with kernel 2.6.16.18
and before ? can you send lspci -n ? On Sun, 2006-05-28 at 21:50 +0200, Paul Surgeon wrote: I had a problem with ACPI IRQ routing messing up the USB ehci module. I have to disable the irq routing with apci=noirq in the bootloader config in order to use the ehci module. Failing to do so results in : usb 5-1: new high speed USB device using ehci_hcd and address 3 ehci_hcd :00:10.4: Unlink after no-IRQ? Controller is probably using the wrong IRQ. System : Kernel 2.6.16.18 Chipset VIA KT400A Regards Paul - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To 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
back to discussion of VIA quirk fixup
Hi, Before this matter getting cold, I'd like to tell this: 1º This quirk_via_irq function has been created originally by Bjorn Helgaas, so maybe he can tell better what patch does. 2º This is need it on a Compaq presario 700 (laptop) that I bought on year 2002. After new ACPI get some stability and enter in kernel (2.4.22), some quirks could be deleted. And when Bjorn has being to introduction GSIs stuff, came with this patch that replace another bunch of quirks. 3º On my new desktop, one Intel(R) Pentium(R) D ual, using lscpi -n, I see that I got : cat /usr/include/linux/pci_ids.h | grep VIA | grep 3149 #define PCI_DEVICE_ID_VIA_8237_SATA 0x3149 PCI_DEVICE_ID_VIA_82C586_1 0x0571 PCI_DEVICE_ID_VIA_82C586_2 0x3038 But I think, I don't need this quirks, but with or without the quirks I still have one oops on my ethernet card, you can have more details on: http://bugme.osdl.org/show_bug.cgi?id=6419 I think my system runs better without quirks, but I am not sure and I don't have a way to prove it ! REFERENCES: http://lkml.org/lkml/2006/5/9/250 Subject Re: [PATCH] VIA quirk fixup, additional PCI IDs Dave Jones wrote: On Tue, May 09, 2006 at 12:59:16PM -0700, Andrew Morton wrote: This looks like a 2.6.17-worthy fix, but it's not clear. Help. What happens if 2.6.17 doesn't have this?? We won't run the quirk on machines that used to have it run, so we get buggered up irq routing. and Andrew Morton wrote: OK.. We used to have DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq); and we now have DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq); DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq); DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq); DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq); DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq); DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq); DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq); which is rather a step backwards, because we need to keep that list updated now, and we'll fail to catch new devices. What happens if we just revert 75cf7456dd87335f574dcd53c4ae616a2ad71a11? It says Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running on my system which has no VIA southbridge (but I do have a VIA IEEE 1394 device). but so what? Did anything actually go wrong? Is it likely to go wrong in the future? Is there was a problem, is there something we can do at runtime in quirk_via_irq() to avoid the problem, rather than expanding out the fixup list in this manner? Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
testing latest ACPI patch vs 2.6.17-rc4
Hi , Well I had test latest (at May 14), and don't change much the behavior of my desktop. Anyway though might be useful send the diff of dmesg I have new messages like: ACPI (acpi_bus-0191): Device is not power manageable [20060310] ACPI Exception (acpi_memory-0403): AE_ERROR, handle is no memory device [20060310] Thanks, -- Sérgio M. B. --- dmesg11 2006-05-14 03:29:42.0 +0100 +++ dmesg13 2006-05-14 07:18:21.0 +0100 @@ -1,5 +1,5 @@ Bootdata ok (command line is ro root=LABEL=/1 report_lost_ticks notsc) -Linux version 2.6.16-1.2202_FC6.root ([EMAIL PROTECTED]) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 SMP Sat May 13 21:27:24 WEST 2006 +Linux version 2.6.16-1.2203_FC5.root ([EMAIL PROTECTED]) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 SMP Sun May 14 06:24:33 WEST 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) @@ -21,8 +21,8 @@ No NUMA configuration found Faking a node at -3ffb Bootmem setup node 0 -3ffb -On node 0 totalpages: 256348 - DMA zone: 2410 pages, LIFO batch:0 +On node 0 totalpages: 256346 + DMA zone: 2408 pages, LIFO batch:0 DMA32 zone: 253938 pages, LIFO batch:31 ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 @@ -52,13 +52,13 @@ PID hash table entries: 4096 (order: 12, 32768 bytes) Disabling vsyscall due to use of PM timer time.c: Using 3.579545 MHz WALL PM GTOD PM timer. -time.c: Detected 2793.052 MHz processor. +time.c: Detected 2793.172 MHz processor. Console: colour VGA+ 80x25 -time.c: Lost 782 timer tick(s)! rip start_kernel+0x11a/0x1fb) +time.c: Lost 298 timer tick(s)! rip start_kernel+0x11a/0x1fb) Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) -Memory: 1022456k/1048256k available (2322k kernel code, 25412k reserved, 1675k data, 200k init) -Calibrating delay using timer specific routine.. 5594.11 BogoMIPS (lpj=11188232) +Memory: 1022448k/1048256k available (2326k kernel code, 25420k reserved, 1680k data, 200k init) +Calibrating delay using timer specific routine.. 5594.13 BogoMIPS (lpj=11188274) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode @@ -72,12 +72,12 @@ CPU: Processor Core ID: 0 CPU0: Thermal monitoring enabled (TM1) Using local APIC timer interrupts. -result 12468928 -Detected 12.468 MHz APIC timer. +result 12469459 +Detected 12.469 MHz APIC timer. time.c: Lost 9 timer tick(s)! rip setup_boot_APIC_clock+0x11f/0x121) Booting processor 1/2 APIC 0x1 Initializing CPU#1 -Calibrating delay using timer specific routine.. 5586.52 BogoMIPS (lpj=11173046) +Calibrating delay using timer specific routine.. 5586.47 BogoMIPS (lpj=11172954) CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 @@ -94,7 +94,7 @@ PCI: BIOS Bug: MCFG area is not E820-reserved PCI: Not using MMCONFIG. PCI: Using configuration type 1 -ACPI: Subsystem revision 20060127 +ACPI: Subsystem revision 20060310 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) @@ -128,7 +128,9 @@ IO window: disabled. MEM window: f3e0-f7ef PREFETCH window: bff0-dfef +ACPI (acpi_bus-0191): Device is not power manageable [20060310] PCI: Setting latency timer of device :00:01.0 to 64 +ACPI (acpi_bus-0191): Device is not power manageable [20060310] GSI 16 sharing vector 0xA9 and IRQ 16 ACPI: PCI Interrupt :00:02.0[A] - GSI 27 (level, low) - IRQ 169 PCI: Setting latency timer of device :00:02.0 to 64 @@ -140,7 +142,7 @@ TCP reno registered IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $ audit: initializing netlink socket (disabled) -audit(1147565990.724:1): initialized +audit(1147590942.700:1): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) @@ -148,7 +150,7 @@ Initializing Cryptographic API ksign: Installing public key data Loading keyring -- Added public key 3B934C32D60116F +- Added public key 1BAC065461AA22EC - User ID: Red Hat, Inc. (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered @@ -161,6 +163,10 @@ Allocate Port Service[:00:02.0:pcie00] Allocate Port Service[:00:02.0:pcie02] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 +ACPI Exception (acpi_processor-0668): AE_NOT_FOUND, Processor Device is not present [20060310] +ACPI Error (acpi_processor-0474): Getting cpuindex for acpiid 0x3 [20060310] +ACPI Exception (acpi_processor-0668): AE_NOT_FOUND, Processor Device is not present [20060310] +ACPI Error (acpi_processor-0474): Getting cpuindex for acpiid 0x4 [20060310] Real Time Clock Driver v1.12ac Non-volatile memory driver v1.2 Linux agpgart interface v0.101
Re: [patch 16/16] acpi: suppress power button event on S3 resume
ok here it goes the state of applying this 16 patches against 2.6.17-rc4 Patches 1 2 out of date (n out of m hunks FAILED) 3 4 ok 5 out of date 6 ok 7 8 9 10 out of date 11 12 13 ok 14 out of date 15 16 ok On Thu, 2006-04-27 at 02:25 -0700, [EMAIL PROTECTED] wrote: From: Arnaud Patard [EMAIL PROTECTED] Suppress POWER_BUTTON event on S3 resume. Signed-off-by: Arnaud Patard [EMAIL PROTECTED] Acked-by: Yu, Luming [EMAIL PROTECTED] Cc: Brown, Len [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/acpi/sleep/main.c |8 1 files changed, 8 insertions(+) diff -puN drivers/acpi/sleep/main.c~acpi-suppress-power-button-event-on-s3-resume drivers/acpi/sleep/main.c --- 25/drivers/acpi/sleep/main.c~acpi-suppress-power-button-event-on-s3-resume Wed Apr 26 14:15:19 2006 +++ 25-akpm/drivers/acpi/sleep/main.c Wed Apr 26 14:15:19 2006 @@ -105,6 +105,14 @@ static int acpi_pm_enter(suspend_state_t default: return -EINVAL; } + + /* ACPI 3.0 specs (P62) says that it's the responsabilty + * of the OSPM to clear the status bit [ implying that the + * POWER_BUTTON event should not reach userspace ] + */ + if (ACPI_SUCCESS(status) (acpi_state == ACPI_STATE_S3)) + acpi_clear_event(ACPI_EVENT_POWER_BUTTON); + local_irq_restore(flags); printk(KERN_DEBUG Back to C!\n); _ - 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 smime.p7s Description: S/MIME cryptographic signature
RE: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision
I think, it is about time, not thinking via quirks as workarounds, because all pcis (on via) are quirked, some are quirked twice. And we should think in programmer interrupts of via chipset, in specific function for this propose, for me, doesn't make sense every time VIA put other ID out, we have to add quirks to this ID , as this was an exception. Thanks, On Tue, 2006-04-25 at 15:53 -0400, Brown, Len wrote: I'd rather see the original irq-renaming patch and its subsequent multiple via workaround patches reverted than to further complicate what is becoming a fragile mess. -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
Re: how to back from suspend without shutdown
Hi, unload acpid (service acipd stop) before suspend is more easy and works. thanks, On Thu, 2006-04-20 at 11:20 +1000, Nigel Cunningham wrote: Hi. On Wednesday 19 April 2006 23:49, Sergio Monteiro Basto wrote: Hi everybody, I have a new laptop one HP Compaq NX6110 , that works quite well with suspend and hibernation. But after suspend , how I bring back computer ?, the only key that I know is power button, but after press power button and laptop wake-up, Begins the shutdown process because is triggered the power button shutdown . any ideas ? Other question klaptop let me choose performance profile: userspace or performance, which one is better ? and why ? Klaptop allows also to define CPU throttling which is in 00% but I can choose 0,12 25, 37, 50, 62, 75 and 87. What is the propose of this settings ? thanks in advance , Try building acpi button support as a module and unloading it during the cycle. Regards, Nigel - 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
