Re: Oops when removing button and asus_acpi modules
Tomasz Chmielewski schrieb: I have a kernel OOPS when I remove button and/or asus_acpi modules on 2.6.21.1 kernel. Here's my lspci, if anyone is interested: # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) -- Tomasz Chmielewski http://wpkg.org - 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 3/3] clockevents: Fix resume logic - updated version
On Sat, 2007-05-12 at 18:11 -0700, Andrew Morton wrote: > On Sat, 12 May 2007 21:56:10 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > On Sat, 2007-05-12 at 10:23 -0700, Andrew Morton wrote: > > > The broken-out queue should turn up at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ > > > in a few minutes. > > > > Sigh. I can't reproduce your lockdep problem :( > > We should write a Vaio emulator. :) > > Can you send me your .config please ? > > > > http://userweb.kernel.org/~akpm/config-sony.txt No luck. tglx - 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
Fwd: Re: Linux 2.6.22-rc1
Cc'ing acpi & sony ppl. Jan -- -- Forwarded message -- Date: Sun, 13 May 2007 11:20:39 +0200 (MEST) From: Jan Engelhardt <[EMAIL PROTECTED]> To: Linus Torvalds <[EMAIL PROTECTED]> Cc: Linux Kernel Mailing List <[EMAIL PROTECTED]> Subject: Re: Linux 2.6.22-rc1 On May 12 2007 20:20, Linus Torvalds wrote: > >Ok, the merge window has closed, and 2.6.22-rc1 is out there. I have hit a randconfig compile failure. .config attached. LD .tmp_vmlinux1 drivers/built-in.o: In function `acpi_bus_generate_event': (.text+0x233f7): undefined reference to `event_is_open' drivers/built-in.o: In function `acpi_bus_get_power': (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x237c3): undefined reference to `acpi_power_transition' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x23835): undefined reference to `acpi_power_transition' drivers/built-in.o: In function `sony_pic_fanspeed_store': sony-laptop.c:(.text+0x91930): undefined reference to `ec_write' drivers/built-in.o: In function `sony_pic_fanspeed_show': sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read' make: *** [.tmp_vmlinux1] Error 1 Jan -- randconfig-1.bz2 Description: BZip2 compressed data
Re: Dell Optiplex GX240, ACPI and APIC
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 12 May 2007 07:04:25 -0700 (PDT) Tear <[EMAIL PROTECTED]> wrote:
>
> > Summary: If ACPI is not enabled but APIC is,
> > then there is trouble on Dell Optiplex GX240.
> > If both are enabled or if both are disabled, then
> > everything is fine. The attached patch removes
> > Dell Optiplex GX240 from the ACPI blacklist.
> >
> > ---
> >
> > Hello,
> >
> > I have a Dell Optiplex GX240 and when I boot Linux, ACPI
> > gets set up by only acpi=ht. dmesg shows the following line:
> >
> >DELL GX240 detected: force use of acpi=ht
> >
> > Everything seemed to be fine. However, I discovered that
> > everything is not fine. The USB controller works so slowly
> > that copying a few (uncached) 1 megabyte large photos from
> > a USB-enabled digital camera takes many minutes instead of
> > a couple of seconds.
> >
> > I am using Linux 2.6.21.1 on a Debian 4.0 ("Etch") system.
> >
> > I thought that this might be related to ACPI. So I tried
> > to boot with _only_ "acpi=force" appended to the kernel
> > command line. Voila, the USB controller started to work
> > at full speed and copying photos from my digital camera
> > took only seconds.
> >
> > I tested the system with "acpi=force" and could not find
> > anything which did not work. So, can we please remove
> > Dell Optiplex GX240 from the blacklist in
> >
> > /arch/i386/kernel/acpi/boot.c
> >
> > ? The attached patch does just that: It removes Dell
> > Optiplex GX240 from the ACPI blacklist.
> >
> > I thought that this might be related to interrupts and
> > APIC as well. (Note that this is APIC, not ACPI.) I tried
> > booting with _only_ "noapic" and "nolapic" appended to the
> > command line. Again, the USB controller started to work
> > at full speed.
> >
> > If removing Dell Optiplex GX240 from the ACPI blacklist
> > is not wanted/possible, then is there a way to disable
> > APIC and LAPIC (note that this is APIC not ACPI) by
> > default on Dell GX240 machines? (I.e. Can one patch
> > the kernel so that APIC and LAPIC isn't used on
> > these machines? - I know that I can use the noapic
> > and nolapic options on the kernel command line.)
> >
> > Thank you for your attention.
> >
> > - Tear
> >
> > Note: Please include me in CC of your replies.
> >
> >
> > --- linux-2.6.21.1.orig/arch/i386/kernel/acpi/boot.c2007-05-01
> > 17:10:30.0 +0300
> > +++ linux-2.6.21.1/arch/i386/kernel/acpi/boot.c 2007-05-01
> > 20:31:53.0 +0300
> > @@ -971,14 +971,6 @@
> > },
> > {
> > .callback = force_acpi_ht,
> > -.ident = "DELL GX240",
> > -.matches = {
> > -DMI_MATCH(DMI_BOARD_VENDOR, "Dell Computer Corporation"),
> > -DMI_MATCH(DMI_BOARD_NAME, "OptiPlex GX240"),
> > -},
> > -},
> > - {
> > -.callback = force_acpi_ht,
> > .ident = "HP VISUALIZE NT Workstation",
> > .matches = {
> > DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
> >
>
> Thanks. Let's cc the acpi list.
>
> The origin of that blacklist entry appears to be lost in the mists of time.
> git-blame got tripped up by an intervening Lindent run and my gittiness
> is insufficient for tracking changes before that.
>
Mr. Morton,
I have already sent a very similar e-mail to the linux-acpi
mailing list. Please see the following for that:
http://marc.info/?l=linux-acpi&m=117856470816834&w=2
I haven't received a reply and that is why sent this e-mail
to the linux-kernel mailing list.
I would be very pleased to see the removal of Dell Optiplex
GX240 from the ACPI blacklist.
Is there a blacklist for APIC? (Note that this is APIC,
not ACPI.)
Thank you.
Tear
Boardwalk
for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's
economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI Power Down is broken in 2.6.21.1
Hi Vladimir, [adding Len and ACPI gurus to CC] On 08/05/07, Vladimir Pouzanov <[EMAIL PROTECTED]> wrote: Hi all, I have got a problem with Asus F3T notebook and 2.6.21.1 kernel. When I perform powerdown (with user-space app or alt+sysrq+o) I get "Power Down." message, but the notebook doesn't turn off. Everything is ok on 2.6.20. There seem to be no changes in acpi/sleep/poweroff.c so I don't know where should I start looking for a bug. F3T is based on Thrion64 X2 CPU (I'm running it in x86 mode with SMP and PREEMPT). Sincerely, Vladimir "Farcaller" Pouzanov http://hackndev.com I added this bug to the list of known regressions. (http://kernelnewbies.org/known_regressions) Regards, Michal -- Michal K. K. Piotrowski Kernel Monkeys (http://kernel.wikidot.com/start) - 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 3/3] clockevents: Fix resume logic - updated version
On Sat, 2007-05-12 at 02:00 -0700, Andrew Morton wrote: > Still hangs in the same fashion, sorry. > > It's peculiar that the hang happens when acpi_evaluate_object() hits its > return statement. Any theories there? I assume you have a printk right before the return and one after the call to acpi_evaluate_object(). Can you dump the stack at the point before the return, so we can see if the stack is corrupt there ? A WARN_ON(1) should do the trick. tglx - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI Power Down is broken in 2.6.21.1
On Sun, 13 May 2007 16:29:25 +0200 "Michal Piotrowski" <[EMAIL PROTECTED]> wrote: > Hi Vladimir, > > [adding Len and ACPI gurus to CC] > > On 08/05/07, Vladimir Pouzanov <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I have got a problem with Asus F3T notebook and 2.6.21.1 kernel. When I > > perform powerdown (with user-space app or alt+sysrq+o) I get "Power Down." > > message, but the notebook doesn't turn off. Everything is ok on 2.6.20. > > > > There seem to be no changes in acpi/sleep/poweroff.c so I don't know where > > should I start looking for a bug. > > > > F3T is based on Thrion64 X2 CPU (I'm running it in x86 mode with SMP and > > PREEMPT). > > > > Sincerely, > > Vladimir "Farcaller" Pouzanov > > http://hackndev.com > > > > I added this bug to the list of known regressions. > (http://kernelnewbies.org/known_regressions) > > Regards, > Michal > Is the network still connected? Maybe there is a wake on lan problem with the network device. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] clockevents: Fix resume logic - updated version
On Sun, 2007-05-13 at 10:07 +0200, Thomas Gleixner wrote: > > > Can you send me your .config please ? > > > > > > > http://userweb.kernel.org/~akpm/config-sony.txt > > No luck. I'm making progress. After fiddling with the config options I get a solid lockup of netconsole during boot :( But also lockdep itself is broken on my box, so I would not see warnings anyway: soft-irqs-on + irq-safe-A/21: ok | ok | ok | sirq-safe-A => hirqs-on/12: ok | ok |irq event stamp: 472 hardirqs last enabled at (472): [] irqsafe2A_rlock_12+0x94/0xa1 hardirqs last disabled at (471): [] native_sched_clock+0x55/0xe8 softirqs last enabled at (468): [] irqsafe2A_rlock_12+0x7f/0xa1 softirqs last disabled at (464): [] irqsafe2A_rlock_12+0xb/0xa1 FAILED| [] dump_trace+0x61/0x1e7 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x14 [] dump_stack+0x15/0x17 [] dotest+0x6b/0x3ce [] locking_selftest+0x915/0x1a5a [] start_kernel+0x1d5/0x2a7 === more of those - BUG: 6 unexpected failures (out of 218) - debugging disabled! | - tglx - 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 3/3] clockevents: Fix resume logic - updated version
On Sun, 13 May 2007 18:48:07 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote: > On Sun, 2007-05-13 at 10:07 +0200, Thomas Gleixner wrote: > > > > Can you send me your .config please ? > > > > > > > > > > http://userweb.kernel.org/~akpm/config-sony.txt > > > > No luck. > > I'm making progress. After fiddling with the config options I get a > solid lockup of netconsole during boot :( neat. Sometimes this can be a device driver failure. > But also lockdep itself is broken on my box, so I would not see warnings > anyway: > > soft-irqs-on + irq-safe-A/21: ok | ok | ok | >sirq-safe-A => hirqs-on/12: ok | ok |irq event stamp: 472 > hardirqs last enabled at (472): [] irqsafe2A_rlock_12+0x94/0xa1 > hardirqs last disabled at (471): [] native_sched_clock+0x55/0xe8 > softirqs last enabled at (468): [] irqsafe2A_rlock_12+0x7f/0xa1 > softirqs last disabled at (464): [] irqsafe2A_rlock_12+0xb/0xa1 > FAILED| [] dump_trace+0x61/0x1e7 > [] show_trace_log_lvl+0x1a/0x30 > [] show_trace+0x12/0x14 > [] dump_stack+0x15/0x17 > [] dotest+0x6b/0x3ce > [] locking_selftest+0x915/0x1a5a > [] start_kernel+0x1d5/0x2a7 > === > > more of those > > - > BUG: 6 unexpected failures (out of 218) - debugging disabled! | > - > Yeah, I expect quite a few people will start seeing that. iirc it was triggered by a couple of changes: a local_irq_save/local_irq_restore in sched_clock() and a change Jeremy made to the softlockup detector. There was no reasonable explanation why either of those changes should have triggered the six failures so I just went ahead with them so we can flush the real bug out. - 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 3/3] clockevents: Fix resume logic - updated version
* Andrew Morton <[EMAIL PROTECTED]> wrote: > Yeah, I expect quite a few people will start seeing that. iirc it was > triggered by a couple of changes: a local_irq_save/local_irq_restore > in sched_clock() and a change Jeremy made to the softlockup detector. hm, i specifically asked to not do local_irq_save/restore in sched_clock(). It's the _scheduler_ clock and it very absolutely positively needs no flags save/restore. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] ACPI based hwmon driver for ASUS
Hi,
this is the first attempt to write a hwmon driver for ASUS motherboards
that uses ACPI methods instead of directly touching the sensor chip.
If you haven't followed the discussion[1] we want to avoid concurrent
access to the monitoring hw by ACPI and native driver, since it may
cause a malfunction.
A brief description of the driver:
- I've extended the hwmon userspace interface with *_name attributes;
since ACPI "knows" the wiring and provides a pretty description of
the reading I thought it's worth exposing it.
- all the attributes are read only: for some of them (voltage,
temperature) rw doesn't make sense; for FAN: it's not possible to
directly control the PWM (the native driver can do that) via ACPI;
ASUS provides "Q-FAN" which has 3 settings: "silent", "perfomance",
"auto"; so far I've been unable to make it work. The write path is
basically "write caller supplied magic number to a magic memory
location"...
- various ASUS stuff: my motherboard also has other features like
auto-overclock, PCI-E frequency readings, DRAM voltage and frequency,
CPU clock / ratio (some of the writable at runtime). I've ignored them
since I don't know how they work (magic numbers...)
- I exported a few ACPI functions: acpi_ns_map_handle_to_node,
acpi_ns_convert_entry_to_handle and acpi_ns_get_node for inspecting
ACPI methods and ensure that all the expected stuff is there;
acpi_evaluate_object_typed since it's very handy to let it do the
check on the returned data instead of open-coding it all over the
driver. Patch against 2.6.21:
diff --git a/drivers/acpi/namespace/nsutils.c b/drivers/acpi/namespace/nsutils.c
index 90fd059..97e1139 100644
--- a/drivers/acpi/namespace/nsutils.c
+++ b/drivers/acpi/namespace/nsutils.c
@@ -700,6 +700,7 @@ struct acpi_namespace_node
*acpi_ns_map_handle_to_node(acpi_handle handle)
return (ACPI_CAST_PTR(struct acpi_namespace_node, handle));
}
+EXPORT_SYMBOL(acpi_ns_map_handle_to_node);
/***
*
@@ -736,6 +737,7 @@ acpi_handle acpi_ns_convert_entry_to_handle(struct
acpi_namespace_node *node)
return ((acpi_handle) Node);
--*/
}
+EXPORT_SYMBOL(acpi_ns_convert_entry_to_handle);
/***
*
@@ -875,6 +877,7 @@ acpi_ns_get_node(struct acpi_namespace_node *prefix_node,
ACPI_FREE(internal_path);
return_ACPI_STATUS(status);
}
+EXPORT_SYMBOL(acpi_ns_get_node);
/***
*
diff --git a/drivers/acpi/namespace/nsxfeval.c
b/drivers/acpi/namespace/nsxfeval.c
index 8904d0f..1b81758 100644
--- a/drivers/acpi/namespace/nsxfeval.c
+++ b/drivers/acpi/namespace/nsxfeval.c
@@ -49,7 +49,6 @@
#define _COMPONENT ACPI_NAMESPACE
ACPI_MODULE_NAME("nsxfeval")
-#ifdef ACPI_FUTURE_USAGE
/***
*
* FUNCTION:acpi_evaluate_object_typed
@@ -142,7 +141,6 @@ acpi_evaluate_object_typed(acpi_handle handle,
}
ACPI_EXPORT_SYMBOL(acpi_evaluate_object_typed)
-#endif /* ACPI_FUTURE_USAGE */
/***
*
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index e08f7df..85da346 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -164,14 +164,12 @@ acpi_evaluate_object(acpi_handle object,
struct acpi_object_list *parameter_objects,
struct acpi_buffer *return_object_buffer);
-#ifdef ACPI_FUTURE_USAGE
acpi_status
acpi_evaluate_object_typed(acpi_handle object,
acpi_string pathname,
struct acpi_object_list *external_params,
struct acpi_buffer *return_buffer,
acpi_object_type return_type);
-#endif
acpi_status
acpi_get_object_info(acpi_handle handle, struct acpi_buffer *return_buffer);
I've asked for help to local LUG: the driver has been tested by a couple
of people; unfortunately the board were all very similar (a P5B, a P5B
delux and my P5B-E). If you have a recent ASUS mainboard and the driver
doesn't work you can send me a dump of your DSDT.
Now the driver itself:
/*
* Copyright (C) 2007 Luca Tettamanti <[EMAIL PROTECTED]>
* Distribute under GPLv2.
*/
#define DEBUG
#include
#include
#include
#include
#include
#include
#include
#define ATK_HID "ATK0110"
#define ATK_DRV "atk-hwmon"
#define ASOC "_SB.PCI0.SBRG.ASOC"
struct atk_data {
struct class_device *class_dev;
acpi_handle atk_handle;
struct acpi_device *device;
acpi_handle rtmp_handle;
acpi_handle rvlt_handle;
acpi_handle rfan_handle;
} atk_data;
typedef ssize_t (*sysfs_show_func)(struct
Re: [patch 3/3] clockevents: Fix resume logic - updated version
On Sun, 13 May 2007 22:07:39 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Yeah, I expect quite a few people will start seeing that. iirc it was > > triggered by a couple of changes: a local_irq_save/local_irq_restore > > in sched_clock() and a change Jeremy made to the softlockup detector. > > hm, i specifically asked to not do local_irq_save/restore in > sched_clock(). It's the _scheduler_ clock and it very absolutely > positively needs no flags save/restore. > It got taken out again. It doesn't matter though: a local_irq_save/restore in some callee shouldn't cause the locking API tests to break. And they're apparently now breaking without that local_irq_save/restore in there anyway. - 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] swsusp: Use platform mode by default
Rafael J. Wysocki wrote: On Friday, 11 May 2007 18:30, Linus Torvalds wrote: On Fri, 11 May 2007, Rafael J. Wysocki wrote: We're working on fixing the breakage, but currently it's difficult, because none of my testboxes has problems with the 'platform' hibernation and I cannot reproduce the reported issues. The rule for anything ACPI-related has been: no regressions. It doesn't matter if something fixes 10 boxes, if it breaks a single one, it's going to get reverted. [Well, I think I should stop explaining decisions that weren't mine. Yet, I feel responsible for patches that I sign-off.] Just to clarify, the change in question isn't new. It was introduced by the commit 9185cfa92507d07ac787bc73d06c4eec7239 before 2.6.20, at Seife's request and with Pavel's acceptance. We had much too much of the "two steps forward, one step back" dance with ACPI a few years ago, which is the reason that rule got installed (and which is why it's ACPI-only: in some other subsystems we accept the fact that sometimes we don't know how to fix some hardware issue, but the new situation is at least better than the old one). I agree that it can be aggravating to know that you can fix a problem for some people, but then being limited by the fact that it breaks for others. But beign able to *rely* on something that used to work is just too important, and with ACPI, you can never make a good judgement of which way works better (since it really just depends on some random firmware issues that we have zero visibility into). Also, quite often, it may *seem* like something fixes more boxes than it breaks, but it's because people report *breakage* only, and then a few months later it turns out that it's exactly the other way around: now it's a hundred people who report breakage with the *new* code, and the reason people thought it fixed more than it broke was that the people for whom the old code worked fine obviously never reported it! So this is why "a single regression is considered more important than ten fixes" - because a single regressionr report tends to actually be just the first indication of a lot of people who simply haven't tested the new code yet! People for whom the old code is broken are more likely to test new things. So I'd just suggest changing the default back to PM_DISK_SHUTDOWN (but leave the "pm_ops->enter" testing in place - ie not reverting the other commits in the series). The series actually preserves the 2.6.20/21 behavior. By defaulting back to PM_DISK_SHUTDOWN, we'll cause some users for whom 2.6.20 and 2.6.21 work to report this change as a regression, so please let me avoid making this decision (I'm not the maintainer of the hibernation code after all). The problem is that we don't know about regressions until somebody reports them and if that happens after two affected kernel releases, what should we do? I think that one of the reasons people (guilty) don't report problems with suspend and hibernate is that it's been a problem on and off and when it breaks people don't bother to chase it, they just don't use it unless it's critical, or they install suspend2. I only suggest that if 'platform' is more correct use that, don't change it again. Then fix platform. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: Fwd: Re: Linux 2.6.22-rc1
On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote: > On May 12 2007 20:20, Linus Torvalds wrote: > > > >Ok, the merge window has closed, and 2.6.22-rc1 is out there. > > I have hit a randconfig compile failure. .config attached. > > LD .tmp_vmlinux1 > drivers/built-in.o: In function `acpi_bus_generate_event': > (.text+0x233f7): undefined reference to `event_is_open' > drivers/built-in.o: In function `acpi_bus_get_power': > (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state' > drivers/built-in.o: In function `acpi_bus_set_power': > (.text+0x237c3): undefined reference to `acpi_power_transition' > drivers/built-in.o: In function `acpi_bus_set_power': > (.text+0x23835): undefined reference to `acpi_power_transition' > drivers/built-in.o: In function `sony_pic_fanspeed_store': > sony-laptop.c:(.text+0x91930): undefined reference to `ec_write' > drivers/built-in.o: In function `sony_pic_fanspeed_show': > sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read' > make: *** [.tmp_vmlinux1] Error 1 I actually can't reproduce it with your .config. >From a clean tree, running make fires up the oldconfig which fixes the many missing/garbled dependencies. In any case SONY_LAPTOP depends on ACPI which always build EC statically if selected. clues? -- mattia :wq! - 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: Fwd: Re: Linux 2.6.22-rc1
On May 14 2007 10:55, Mattia Dongili wrote: >On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote: >> On May 12 2007 20:20, Linus Torvalds wrote: >> > >> >Ok, the merge window has closed, and 2.6.22-rc1 is out there. >> >> I have hit a randconfig compile failure. .config attached. >> >> LD .tmp_vmlinux1 >> drivers/built-in.o: In function `acpi_bus_generate_event': >> (.text+0x233f7): undefined reference to `event_is_open' >> drivers/built-in.o: In function `acpi_bus_get_power': >> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state' >> drivers/built-in.o: In function `acpi_bus_set_power': >> (.text+0x237c3): undefined reference to `acpi_power_transition' >> drivers/built-in.o: In function `acpi_bus_set_power': >> (.text+0x23835): undefined reference to `acpi_power_transition' >> drivers/built-in.o: In function `sony_pic_fanspeed_store': >> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write' >> drivers/built-in.o: In function `sony_pic_fanspeed_show': >> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read' >> make: *** [.tmp_vmlinux1] Error 1 > >I actually can't reproduce it with your .config. But I can. Did you try it on x86_64? From 2.6.22-rc1 [ commit 39403865d2e4590802553370a56c9ab93131e4ee in /linux-2.6.git] ? bzip2 -cd randconfig-1.bz2 >.config make -j8 HOSTLD scripts/kconfig/conf scripts/kconfig/conf -s arch/x86_64/Kconfig drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol ' drivers/net/Kconfig:2283:warning: 'select' used by config symbol 'UCC_G drivers/input/keyboard/Kconfig:170:warning: 'select' used by config sym drivers/input/mouse/Kconfig:181:warning: 'select' used by config symbol CHK include/linux/version.h UPD include/linux/version.h CHK include/linux/utsrelease.h UPD include/linux/utsrelease.h SYMLINK include/asm -> include/asm-x86_64 >>From a clean tree, running make fires up the oldconfig which fixes the >many missing/garbled dependencies. In any case SONY_LAPTOP depends on >ACPI which always build EC statically if selected. I really presume it is something on x86_64, because doing gzip -cd /proc/config.gz make on i386 seemed to compile fine - including the sony modules. Jan -- - 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 3/3] clockevents: Fix resume logic - updated version
On Sun, 13 May 2007 18:12:50 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote: > On Sat, 2007-05-12 at 02:00 -0700, Andrew Morton wrote: > > Still hangs in the same fashion, sorry. > > > > It's peculiar that the hang happens when acpi_evaluate_object() hits its > > return statement. Any theories there? > > I assume you have a printk right before the return and one after the > call to acpi_evaluate_object(). > > Can you dump the stack at the point before the return, so we can see if > the stack is corrupt there ? A WARN_ON(1) should do the trick. > It all looks clean. I spose I should do a hex dump and a byte-by-byte walkthough, but time is short... - 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 3/3] clockevents: Fix resume logic - updated version
On Sun, 2007-05-13 at 23:42 -0700, Andrew Morton wrote: > On Sun, 13 May 2007 18:12:50 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > On Sat, 2007-05-12 at 02:00 -0700, Andrew Morton wrote: > > > Still hangs in the same fashion, sorry. > > > > > > It's peculiar that the hang happens when acpi_evaluate_object() hits its > > > return statement. Any theories there? > > > > I assume you have a printk right before the return and one after the > > call to acpi_evaluate_object(). > > > > Can you dump the stack at the point before the return, so we can see if > > the stack is corrupt there ? A WARN_ON(1) should do the trick. > > > > It all looks clean. I spose I should do a hex dump and a byte-by-byte > walkthough, but time is short... I could backport the highres/dyntick stuff to 2.6.20, so we have the other changes out of the picture. tglx - 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
