Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p
On Mon, 25 Feb 2008 21:19:24 +0200 Michael S. Tsirkin [EMAIL PROTECTED] wrote: On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses such as Fn-F4 and lid open/close, prints them in /var/log/acpid and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4). You mean suspend-to-ram works correctly on your t61p? Mine suspends, then five seconds later magically resumes itself and the screen is all black. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 10071] New: kernel hang in inet_init
On Sat, 23 Feb 2008 00:34:06 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=10071 Summary: kernel hang in inet_init Product: Networking Version: 2.5 KernelVersion: 2.6.25 rc2 latest git Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: IPV4 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Distribution:ubuntu hardy Hardware Environment:dell dimension 5150 Problem Description: kernel hang mostly but boot slowly sometimes Steps to reproduce: boot when the computer manage to boot, inet_init last some time: [1.725306] NET: Registered protocol family 2 [6.825384] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [6.825803] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [6.826691] TCP bind hash table entries: 65536 (order: 9, 2359296 bytes) [6.836160] TCP: Hash tables configured (established 131072 bind 65536) [6.836255] TCP reno registered [7.081569] initcall 0xc03b8920: inet_init+0x0/0x3aa() returned 0. [7.081569] initcall 0xc03b8920 ran for 5106 msecs: inet_init+0x0/0x3aa() When booting with acpi=ht it works: [0.124668] Calling initcall 0xc03b8920: inet_init+0x0/0x3aa() [0.124867] NET: Registered protocol family 2 [0.288067] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [0.288856] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [0.289739] TCP bind hash table entries: 65536 (order: 9, 2359296 bytes) [0.299156] TCP: Hash tables configured (established 131072 bind 65536) [0.299250] TCP reno registered Feb 23 09:10:28 tiyann kernel: [0.162267] initcall 0xc03b8920: inet_init+0x0/0x3aa() returned 0. [0.162383] initcall 0xc03b8920 ran for 33 msecs: inet_init+0x0/0x3aa() there seem to be a weird interaction between acpi and inet_init any hint on how to provide better information thanks - 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: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
On Tue, 26 Feb 2008 00:48:12 +0200 Michael S. Tsirkin [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 12:39 AM, Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 26 Feb 2008 00:36:54 +0200 Michael S. Tsirkin [EMAIL PROTECTED] wrote: Hmm, mystery partly solved... as you guessed it, this piece of code was not in my tree. (still, how can this cause autoresume after 5 seconds is a mystery to me). Pavel Maybe it doesn't. Andrew saw the autoresume on -rc[2,3] And earlier - I think 2.6.23 does it as well. But that one at least resumes fine, does it not? Nope, the resume-after-five-seconds and black-screen-after-resume have always been there (I've only had the thing a few months). I thought the restoring of the screen after resume is handled by the X server? I'm using the nv.o driver. Perhaps nvidia's driver handles it right, dunno. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.25-rc3] ACPI _PPC limiting processor speed...
On Mon, 25 Feb 2008 21:29:24 + Daniel J Blueman [EMAIL PROTECTED] wrote: My 2.2GHz [1] Thinkpad T61 is unable to get past 1.2GHz, seemingly because of the _PPC ACPI objects [2]. Given that the _PPC object is different for both cores, is this more of a BIOS bug or an ACPI interpreter problem? The problem was present in 2.6.24-rc, 2.6.24 final and since. BIOS is 7LETA9WW/2.09, so current - would any further information be useful for debugging this problem, and would dumping the ACPI tables be useful? Thanks, Daniel --- [1] freq-table: table entry 0: 2201000 kHz, 0 index freq-table: table entry 1: 220 kHz, 1 index freq-table: table entry 2: 160 kHz, 2 index freq-table: table entry 3: 120 kHz, 3 index freq-table: table entry 4: 80 kHz, 4 index --- [2] cpufreq-core: CPU 0: _PPC is 3 - frequency limited cpufreq-core: CPU 1: _PPC is 0 - frequency not limited (cc linux-acpi) If nothing happens, please raise a report at bugzilla.kernel.org, thanks. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.25-rc2 Thinkpad T30 docking fails with oops.
On Tue, 19 Feb 2008 20:47:08 + Paul Martin [EMAIL PROTECTED] wrote: Now, this was working in 2.6.23, but is not in any later kernel. Previously reported, but I guess that the previous report was ignored due to the kernel being tainted. Not really. A lot of acpi-related bug reports get the crickets-chirping treatment. The usual response with acpi is please raise a bugzilla report, and the acpi developers do respond well to bugzilla reports. But really, a recent and oops-causing regression shouldn't require such actions - developers should be running around with their hair on fire. Well, there's nothing other than pure Linus here. When booted up docked, there is no oops until you try to undock. Whilst I will be looking for replies in the list, I'd appreciate being CC'd on any replies. ACPI: \_SB_.PCI0.PCI1.DOCK - docking PCI: Transparent bridge - :02:03.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1.DOCK._PRT] BUG: unable to handle kernel NULL pointer dereference at IP: [c01dd6f2] pdev_sort_resources+0x8a/0x116 *pde = Oops: [#1] PREEMPT SMP Modules linked in: radeon drm rfcomm l2cap bluetooth ppdev lp ipv6 ext3 jbd mbcache fuse dm_crypt crypto_blkcipher dm_mod cpufreq_stats speedstep_ich speedstep_lib thinkpad_acpi nvram acpiphp bay dock pcmcia firmware_class joydev yenta_socket rsrc_nonstatic pcmcia_core battery irtty_sir ac sir_dev snd_intel8x0 snd_ac97_codec nsc_ircc ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer irda parport_pc i2c_i801 button shpchp pci_hotplug crc_ccitt parport snd psmouse intel_agp agpgart iTCO_wdt evdev serio_raw soundcore snd_page_alloc rtc pcspkr xfs floppy e100 mii uhci_hcd usbcore sg sr_mod cdrom sd_mod thermal processor fan ata_piix libata scsi_mod radeonfb fb_ddc i2c_algo_bit i2c_core Pid: 39, comm: kacpi_notify Not tainted (2.6.25-rc2 #1) EIP: 0060:[c01dd6f2] EFLAGS: 00010246 CPU: 0 EIP is at pdev_sort_resources+0x8a/0x116 EAX: EBX: ECX: EDX: 0fff ESI: f5e30cc4 EDI: f74f1e80 EBP: f74f1e68 ESP: f74f1e48 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Process kacpi_notify (pid: 39, ti=f74f task=f74cf120 task.ti=f74f) Stack: f5e30cf0 f74f1e80 f5e30c00 0007 f5e30c00 f74cb414 f74cb400 f74f1e9c c02a9cce f5e30c08 f7431f90 f7431978 f5420c00 f7d6d408 f7d6d3c0 f74f1e9c f7d6d3c8 f7d6d3c0 f74f1ed8 f9b278ca f74cb40c Call Trace: [c02a9cce] ? pci_bus_assign_resources+0x59/0x341 [f9b278ca] ? acpiphp_enable_slot+0x2a1/0x3a3 [acpiphp] [f9b27ad9] ? handle_hotplug_event_func+0x63/0x101 [acpiphp] [f9b27167] ? post_dock_fixups+0x6c/0x79 [acpiphp] [c013506e] ? notifier_call_chain+0x2b/0x4a [f9b27a76] ? handle_hotplug_event_func+0x0/0x101 [acpiphp] [f9b22168] ? hotplug_dock_devices+0x39/0xe1 [dock] [f9b22441] ? dock_notify+0x75/0xc0 [dock] [c01f83c9] ? acpi_ev_notify_dispatch+0x4f/0x5a [c01f32c0] ? acpi_os_execute_deferred+0x20/0x2c [c012ef41] ? run_workqueue+0x78/0xfb [c01f32a0] ? acpi_os_execute_deferred+0x0/0x2c [c012f79d] ? worker_thread+0xb6/0xc2 [c0131b25] ? autoremove_wake_function+0x0/0x30 [c012f6e7] ? worker_thread+0x0/0xc2 [c0131a52] ? kthread+0x3b/0x61 [c0131a17] ? kthread+0x0/0x61 [c010568f] ? kernel_thread_helper+0x7/0x10 === Code: 50 52 51 ff 75 f0 68 a0 af 34 c0 e8 ce 4e f4 ff 83 c4 1c e9 87 00 00 00 8b 7d e8 8d 42 01 83 7d f0 06 89 7d e0 0f 4e c8 8b 45 e0 8b 18 31 c0 85 db 74 29 8b 53 04 8b 43 08 89 d7 05 8c 01 00 00 EIP: [c01dd6f2] pdev_sort_resources+0x8a/0x116 SS:ESP 0068:f74f1e48 ---[ end trace 623ea8d57da4defe ]--- I suppose that if you're feeling keen, a bisection search as per http://www.kernel.org/doc/local/git-quick.html would help things along, thanks. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.25-rc2-mm1 (x64 thermal build failure)
On Wed, 20 Feb 2008 08:21:33 +0100 Thomas Petazzoni [EMAIL PROTECTED] wrote: Le Tue, 19 Feb 2008 15:21:29 -0800, Andrew Morton [EMAIL PROTECTED] a __crit : ug, sorry, if I'd realised it was like this I'd have said don't bother. Apart from the obvious problem, this means that people will keep breaking CONFIG_DMI=n all the time, because they will forget the ifdefs, and the number of people who test with CONFIG_DMI=n will be small. Yes, #ifdef CONFIG_DMI is not very comfortable. That why I proposed things such as DECLARE_DMI_FIXUP_TABLE(), because it would force people to use these macros, which would then be working correctly depending on DMI=y/n. However, there's still the issue of driver_data that I mentionned in my earlier post. What should I do ? Option 1 ? Option 2 ? Give up with the patch ? Thanks for your comments, Option 1 would be best, I think: 1) Remove the #ifdef CONFIG_DMI around DMI fixup tables and callbacks definition, so that everything exists and gcc is happy. gcc is able to optimize out the DMI fixup table (it is not present in the binary when compiling with DMI=n), but gcc doesn't seem to be able to optimize out the DMI fixup callbacks (they are still present in the binary). So this would leave some unused code in the binary, which is not completely satisfying. gcc _should_ be able to remove the callbacks as long as they are static and have no references. If even the latest gcc versions are still incluing the unreferenced, static function in the final vmlinux then let's get gcc fixed? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.25-rc2-mm1 (x64 thermal build failure)
On Tue, 19 Feb 2008 16:55:02 +0100 Thomas Petazzoni [EMAIL PROTECTED] wrote: Le Mon, 18 Feb 2008 04:13:40 -0800, Andrew Morton [EMAIL PROTECTED] a __crit : Option 3 wold be to add more #ifdef CONFIG_DMI lines around the place. How ugly would that get? Like the attached patch. #ifdef CONFIG_DMI everywhere :-( ug, sorry, if I'd realised it was like this I'd have said don't bother. Apart from the obvious problem, this means that people will keep breaking CONFIG_DMI=n all the time, because they will forget the ifdefs, and the number of people who test with CONFIG_DMI=n will be small. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.25-rc2-mm1 (x64 thermal build failure)
On Mon, 18 Feb 2008 11:15:36 +0100 Thomas Petazzoni [EMAIL PROTECTED] wrote:
Hi,
Le Sat, 16 Feb 2008 21:44:10 -0800,
Andrew Morton [EMAIL PROTECTED] a __crit :
Bustage in x86-configurable-dmi-scanning-code.patch. Previously,
DMI=y was just hardwired. Now, it becomes selectable and stuff
breaks.
I guess the DMI=n version of dmi_check_system() could become a macro
so we don't emit a reference to its argument, but that might generate
unused-variable warnings elsewhere.
Thanks for your report. The issue is that some DMI fixup tables and
callbacks are defined inside #ifdef CONFIG_DMI, some others are not. We
need to normalize that to fix the build issue in all situations.
I've thought about it, and I see two options, but I can't decide which
one is the best, so I request your opinion on that.
1) Remove the #ifdef CONFIG_DMI around DMI fixup tables and callbacks
definition, so that everything exists and gcc is happy. gcc is able
to optimize out the DMI fixup table (it is not present in the binary
when compiling with DMI=n), but gcc doesn't seem to be able to
optimize out the DMI fixup callbacks (they are still present in the
binary). So this would leave some unused code in the binary, which
is not completely satisfying.
2) Define macros such as DECLARE_DMI_FIXUP_TABLE and
DECLARE_DMI_FIXUP_CALLBACK, which could then be used like this:
DECLARE_DMI_FIXUP_CALLBACK(set_bios_reboot, __init, d, {
if (reboot_type != BOOT_BIOS) {
reboot_type = BOOT_BIOS;
printk(KERN_INFO %s series board detected. Selecting
BIOS-method for reboots.\n, d-ident);
}
return 0;
});
DECLARE_DMI_FIXUP_TABLE(reboot_dmi_table, __initdata, {
{ /* Handle problems with rebooting on Dell E520's */
.callback = set_bios_reboot,
.ident = Dell E520,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
DMI_MATCH(DMI_PRODUCT_NAME, Dell DM061),
},
}
});
And use them everywhere, so that DMI fixup tables and callbacks
are properly compiled out when DMI=n. Here are the macro definition:
#ifdef CONFIG_DMI
#define DECLARE_DMI_FIXUP_TABLE(name, opts, contents...) \
static struct dmi_system_id opts name [] = contents
#define DECLARE_DMI_FIXUP_CALLBACK(name, opts, id, contents...) \
static int opts name(const struct dmi_system_id *id) contents
#else
#define DECLARE_DMI_FIXUP_TABLE(name, opts, contents...)
#define DECLARE_DMI_FIXUP_CALLBACK(name, opts, contents...)
#endif
The issue I have with this option is that there are sometimes
driver_data associated to DMI callbacks (see
drivers/input/misc/wistron_btns.c for example) and I don't exactly
see how to create a similar DECLARE_DMI_FIXUP_CALLBACK_DATA macro.
Option 3 wold be to add more #ifdef CONFIG_DMI lines around the place. How
ugly would that get?
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
On Sun, 17 Feb 2008 00:54:08 + (GMT) Chris Rankin [EMAIL PROTECTED] wrote: [Try this again, except this time I'll force the attachment as inline text!] Hi, I have managed to boot 2.6.24.1 on this machine, with the NMI watchdog enabled, by using the acpi=noirq option. (There does seem to be some unhappiness with bridge symlinks in sysfs, though.) ... sysfs: duplicate filename 'bridge' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 1, comm: swapper Not tainted 2.6.24.1 #1 [c0105020] show_trace_log_lvl+0x1a/0x2f [c0105990] show_trace+0x12/0x14 [c010613d] dump_stack+0x6c/0x72 [c01991bf] sysfs_add_one+0x57/0xbc [c0199e41] sysfs_create_link+0xc2/0x10d [c01bae9a] pci_bus_add_devices+0xbd/0x103 [c034016c] pci_legacy_init+0x56/0xe3 [c03274e1] kernel_init+0x157/0x2c3 [c0104c83] kernel_thread_helper+0x7/0x10 === pci :00:01.0: Error creating sysfs bridge symlink, continuing... sysfs: duplicate filename 'bridge' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 1, comm: swapper Not tainted 2.6.24.1 #1 [c0105020] show_trace_log_lvl+0x1a/0x2f [c0105990] show_trace+0x12/0x14 [c010613d] dump_stack+0x6c/0x72 [c01991bf] sysfs_add_one+0x57/0xbc [c0199e41] sysfs_create_link+0xc2/0x10d [c01bae9a] pci_bus_add_devices+0xbd/0x103 [c01bae82] pci_bus_add_devices+0xa5/0x103 [c034016c] pci_legacy_init+0x56/0xe3 [c03274e1] kernel_init+0x157/0x2c3 [c0104c83] kernel_thread_helper+0x7/0x10 === I have a vague feeling that this was fixed, perhaps in 2.6.24.x? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
On Sun, 17 Feb 2008 00:54:08 + (GMT) Chris Rankin [EMAIL PROTECTED] wrote: [Try this again, except this time I'll force the attachment as inline text!] Hi, I have managed to boot 2.6.24.1 on this machine, with the NMI watchdog enabled, by using the acpi=noirq option. (There does seem to be some unhappiness with bridge symlinks in sysfs, though.) Is this a regression? If so, which was the latest kernel version which worked OK? NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory NFSD: starting 90-second grace period [drm] Initialized drm 1.1.0 20060810 [drm] Initialized mga 3.2.1 20051102 on minor 0 agpgart: Found an AGP 2.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 4x mode agpgart: Putting AGP V2 device at :01:00.0 into 4x mode [drm] Initialized card for AGP DMA. and here it hangs, I assume? Please add initcall_debug to the kernel boot command line so we can see if we can get a more precise idea of where it went wrong. Do you believe that this hang is somehow caused by x86 NMI? If so, why? Thanks. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.25-rc2-mm1 (x64 thermal build failure)
On Sat, 16 Feb 2008 21:16:03 -0800 Randy Dunlap [EMAIL PROTECTED] wrote: On Sat, 16 Feb 2008 00:25:22 -0800 Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ ACPI is enabled, but DMI=n. linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c: In function 'acpi_thermal_init': linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c:1792: error: 'thermal_dmi_table' undeclared (first use in this function) linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c:1792: error: (Each undeclared identifier is reported only once linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c:1792: error: for each function it appears in.) make[3]: *** [drivers/acpi/thermal.o] Error 1 Bustage in x86-configurable-dmi-scanning-code.patch. Previously, DMI=y was just hardwired. Now, it becomes selectable and stuff breaks. I guess the DMI=n version of dmi_check_system() could become a macro so we don't emit a reference to its argument, but that might generate unused-variable warnings elsewhere. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9995] New: 2.6.25-rc1 regression - IBM ACPI backlight controlls do not work
On Fri, 15 Feb 2008 04:51:15 -0800 (PST)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9995
Summary: 2.6.25-rc1 regression - IBM ACPI backlight controlls do
not work
Product: ACPI
Version: 2.5
KernelVersion: 2.6.25-rc1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: BIOS
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Latest working kernel version: 2.6.24
Earliest failing kernel version: 2.6.25-rc1
Distribution: Ubuntu/Hardy
Hardware Environment: ThinkPad T61
Software Environment: n/a
Problem Description: /sys/class/backlight/acpi_video0 does not control
backlight, nothing happens if I change brightness.
Steps to reproduce: echo {15,5,0}
/sys/class/backlight/acpi_video0/brightness
nothing happens.
I've lost the plot on what's happening with backlight. I think you're
about to find that this is not-a-bug, even though it stopped working.
-
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
i386 warnings in acpi-test
arch/x86/kernel/acpi/sleep.c: In function 'acpi_save_state_mem': arch/x86/kernel/acpi/sleep.c:55: warning: passing argument 1 of 'native_store_gdt' from incompatible pointer type arch/x86/kernel/acpi/sleep.c:71: warning: assignment makes integer from pointer without a cast arch/x86/kernel/acpi/sleep.c:72: warning: assignment makes integer from pointer without a cast drivers/acpi/executer/exregion.c: In function 'acpi_ex_pci_config_space_handler': drivers/acpi/executer/exregion.c:369: warning: passing argument 3 of 'acpi_os_read_pci_configuration' from incompatible pointer type - 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: [Bug-fix]:2.6.25-rc0 Generic thermal management [Patch 1/2]: validating input parameters
On Wed, 13 Feb 2008 16:33:10 +0530 Thomas, Sujith [EMAIL PROTECTED] wrote: For time being I am attaching the patch and in the meanwhile I'll figure out a way to fix the wordwrap issues. This was what Len Brown also had recommended. This patch has no changelog. Please include the full and up-to-date changelog with each iteration of a patch. This patch doesn't apply. My version of Linux has if (trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) return -EINVAL; whereas yours apparently has if (trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) return -EINVAL; (plus other changes). Maybe you have some other patch which predeced this one. You apparently didn't resend [Bug-fix]:2.6.25-rc0 Generic thermal management:ACPI [Patch 2/2]: buildfix for CONFIG_THERMAL=n which was also mangled. So please just start again. Resend all patches, against latest mainline, with full changelogs and appropriate cc's, in an unmangled form. Also it would be good if you could be a bit more conventional with the patch titling. For this one, Subject: [patch 1/2] Generic thermal management: validate input parameters would suit. Section 14 of Documentation/SubmittingPatches has some explanation. Thanks. - 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 2/4] acpi: change cpufreq tables to per_cpu variables
On Wed, 13 Feb 2008 10:10:00 -0800 Mike Travis [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Fri, 08 Feb 2008 15:37:40 -0800 Mike Travis [EMAIL PROTECTED] wrote: Change cpufreq tables from arrays to per_cpu variables in drivers/acpi/processor_thermal.c Based on linux-2.6.git + x86.git I fixed a bunch of rejects in [PATCH 1/4] cpufreq: change cpu freq tables to per_cpu variables and it compiles OK. But this one was beyond my should-i-repair-it threshold, sorry. Should I rebase all the pending patches on 2.6.25-rc1 or 2.6.24-mm1 (or some other combination)? That depends on whether you have other things queued in one of the git trees. If not, against current mainline (which is later than 2.6.25-rc1!) would suit. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9957] New: Battery gives me now two batterys, but only one is present
On Wed, 13 Feb 2008 12:00:11 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9957 Summary: Battery gives me now two batterys, but only one is present yeah, I'm seeing this on the t61p as well, but have thus far ignored it amongst the storm of other problems. Product: ACPI Version: 2.5 KernelVersion: 2.6.24.2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Power-Battery AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Latest working kernel version: 2.6.23.14 Earliest failing kernel version: 2.6.24 And it's a regression. - 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: [Bug-fix]:2.6.25-rc0 Generic thermal management [Patch 1/2]: validating input parameters
On Tue, 12 Feb 2008 21:27:44 +0530 Thomas, Sujith [EMAIL PROTECTED] wrote: The patch is fairly seriously wordwrapped. Should be fixed now. No, even after I fixed all the wordwrapping I saw a large amount of fuzz and several rejects when trying to apply the patch. There's a reason why Len uses his kernel.org account to get real work done ;) - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9944] New: suspend to ram doesn't work anymore on Thinkpad T61 with Intel X3100
(Please respond via emailed reply-to-all, not via the bugzilla web interface) On Tue, 12 Feb 2008 14:02:31 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9944 Summary: suspend to ram doesn't work anymore on Thinkpad T61 with Intel X3100 Product: Power Management Version: 2.5 KernelVersion: 2.6.25-rc1 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Hibernation/Suspend AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Latest working kernel version: 2.6.24.2 Earliest failing kernel version: 2.6.25-rc1 Rafael, is your list opened yet? Distribution: Debian Sid Hardware Environment: Thinkpad T61 Software Environment: Problem Description: Suspend to ram doesn't work anymore on my thinkpad t61 with 2.6.25-rc1. On 2.6.24 I had to pass acpi_sleep=s3bios at boot time and suspend with s2ram -f -a 3. On 2.6.25-rc1 doing (on console, with X not running) that leads to a blank screen and the ___sleep___ led (the moon) on the thinkpad blinks (like when it is currently suspending), but nothing happens then. If I can make some more tests, or if you need more info, please ask. I hope this is no duplicate. I have a t61p and suspend/hibernate is bad and deteriorating. So many things go wrong that I'm afraid to test it any more. - 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 2/4] acpi: change cpufreq tables to per_cpu variables
On Fri, 08 Feb 2008 15:37:40 -0800 Mike Travis [EMAIL PROTECTED] wrote: Change cpufreq tables from arrays to per_cpu variables in drivers/acpi/processor_thermal.c Based on linux-2.6.git + x86.git I fixed a bunch of rejects in [PATCH 1/4] cpufreq: change cpu freq tables to per_cpu variables and it compiles OK. But this one was beyond my should-i-repair-it threshold, sorry. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop [EMAIL PROTECTED] wrote: Symptom is that the system shuts down normally and completely, it just does not power off. I've been struggling with an identically-manifesting regression on one of my test machines for a week. It's due to softlockup changes, and setting CONFIG_DETECT_SOFTLOCKUP=n fixes it. It sounds unlikely, but I'd suggest that you see if it's the same on your machine so we're not both chasing the same bug. - 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: [Bug-fix]:2.6.25-rc0 Generic thermal management [Patch 1/2]: validating input parameters
On Mon, 11 Feb 2008 15:57:06 +0530
Thomas, Sujith [EMAIL PROTECTED] wrote:
From: Thomas Sujith [EMAIL PROTECTED]
Added sanity checks for interface functions in thermal with
other modules such as fan, processor, video etc..
Signed-off-by: Thomas Sujith [EMAIL PROTECTED]
---
drivers/thermal/thermal.c | 69
+-
The patch is fairly seriously wordwrapped.
1 files changed, 44 insertions(+), 25 deletions(-)
Index: linux-2.6.24-rc3/drivers/thermal/thermal.c
===
--- linux-2.6.24-rc3.orig/drivers/thermal/thermal.c
+++ linux-2.6.24-rc3/drivers/thermal/thermal.c
@@ -301,13 +301,27 @@ int thermal_zone_bind_cooling_device(str
{
struct thermal_cooling_device_instance *dev;
struct thermal_cooling_device_instance *pos;
+ struct thermal_zone_device *pos1;
+ struct thermal_cooling_device *pos2;
int result;
+ if (!tz || !cdev)
+ return -EINVAL;
Is this change actually needed? It's sloppy for a caller to be passing
invalid arguments into a callee, and it's not good for the callee to just
hide that sloppiness.
- return NULL;
+ return ERR_PTR(-EINVAL);
the patch adds several spaces like this in places where we don't normally
put them.
-
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 2/5] Provide acpi_check_{mem_}region.
On Sun, 10 Feb 2008 13:25:36 +0100
Jean Delvare [EMAIL PROTECTED] wrote:
Hi Andrew,
On Thu, 7 Feb 2008 23:40:02 -0800, Andrew Morton wrote:
On Wed, 24 Oct 2007 16:32:59 +0200 Thomas Renninger [EMAIL PROTECTED]
wrote:
Provide acpi_check_{mem_}region.
Drivers can additionally check against possible ACPI interference by also
invoking this shortly before they call request_region.
If -EBUSY is returned, the driver must not load.
Use acpi_enforce_resources=strict/lax/no options to:
- strict: let conflicting drivers fail to load with an error message
- lax:let conflicting driver work normal with a warning message
- no: no functional change at all
OK, so Len has merged these into the acpi test tree. My understanding is
that once this work hits mainline, we can then merge
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch.
Correct. Same applies to a second patch:
check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
Both patches should be merged upstream at the same time.
My normal approach would be to send
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch to Mark for
inclusion in git-hwmon one Len has merged the prerequisites into mainline.
Problem is, if Len merges late in the 2.6.26 merge window, Mark might not
have time to gets these changes into mainline before 2.6.27. Which is all
getting a bit dumb considering I first merged everything in October.
Fortunately things aren't mormally _this_ inefficient when one follows the
rules - this was an unusual patchset.
But still, I think we could afford to speed things up a bit more than that.
We could ask Len to consider merging this work into 2.6.25 and then if
Mark can ack check-for-acpi-resource-conflicts-in-hwmon-drivers.patch
(below) for an akpm-merge, we're good to go. But I do recall that people
were a bit uncertain about it all back in October.
Please share your thoughts with us.
Len already merged all the acpi bits for 2.6.25 as far as I can see, so
all that is missing now is these two patches:
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch
check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
Both have been in -mm for quite some time.
Yup, the prerequisites appear to be in mainline now.
In the default mode (acpi_enforce_resources=lax) these patches simply
print warnings but still let the drivers load, so they are safe to
merge, and the sooner, the better. The idea is to get feedback on how
many systems out there have ACPI resource conflicts. Then we'll see how
we can address them (if at all.)
I don't remember anyone objecting to these patches, and anyway the
problem has been there for years and nobody took care, so if anyone
really isn't happy with the solution designed by Thomas, that person
will have to do the work and submit something better later. That
shouldn't delay the merge of what we have now.
Andrew, both patches are
Acked-by: Jean Delvare [EMAIL PROTECTED]
We already have Signed-off-by:you, which I figure outranks acked-by: ;)
and I am totally fine with you pushing them to Linus now. But of course
having Mark's ack would be good too.
That would be nice. But I'll merge them mid-week anyway unless Mark actually
nacks them:
http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
Thanks.
-
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: [BUG] 2.6.24 refuses to boot - NMI watchdog problem?
On Thu, 7 Feb 2008 19:58:10 + (GMT) Chris Rankin [EMAIL PROTECTED] wrote: --- Andrew Morton [EMAIL PROTECTED] wrote: It isn't clear (to me) where in this mess we disabled interrupts around the set_cpus_allowed(). Chris, if this is repeatable it would be helpful to set CONFIG_FRAME_POINTER=y which hopefully will get us a cleaner trace, Here you go, Thanks. Linux version 2.6.24 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP PREEMPT Thu Feb 7 00:01:40 GMT 2008 So it's a CONFIG_SMP=y kernel on a single-cpu machine? BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ffeb000 (usable) BIOS-e820: 1ffeb000 - 1ffef000 (ACPI data) BIOS-e820: 1ffef000 - 1000 (reserved) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) 511MB LOWMEM available. Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 131051 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 131051 DMI 2.3 present. ACPI: RSDP 000F7B40, 0014 (r0 ASUS ) ACPI: RSDT 1FFEB000, 0030 (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: FACP 1FFEB100, 0074 (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: DSDT 1FFEB180, 39FA (r1 ASUS TUSL2-C 1000 MSFT 10B) ACPI: FACS 1000, 0040 ACPI: BOOT 1FFEB040, 0028 (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: APIC 1FFEB080, 005A (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: PM-Timer IO Port: 0xe408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) Enabling APIC mode: Logical Cluster. Using 1 I/O APICs, target cpus f Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130028 Kernel command line: ro root=LABEL=/ nmi_watchdog=1 video=matroxfb:vesa:0x11A console=ttyS0,115200n8 console=tty0 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c035f000 soft=c035b000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1005.086 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled console [ttyS0] enabled Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 513484k/524204k available (1577k kernel code, 10128k reserved, 608k data, 196k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb5000 - 0xf000 ( 296 kB) vmalloc : 0xe080 - 0xfffb3000 ( 503 MB) lowmem : 0xc000 - 0xdffeb000 ( 511 MB) .init : 0xc0327000 - 0xc0358000 ( 196 kB) .data : 0xc028a722 - 0xc03227c4 ( 608 kB) .text : 0xc010 - 0xc028a722 (1577 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 2011.89 BogoMIPS (lpj=4023782) Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to e000. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 9k freed ACPI: Core revision 20070126 CPU0: Intel Pentium III (Coppermine) stepping 06 Leaving ESR disabled. Total of 1 processors activated (2011.89 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 WARNING: at arch/x86/kernel/smp_32.c:561 native_smp_call_function_mask() Pid: 1, comm: swapper Not tainted 2.6.24 #1 [c0105020] show_trace_log_lvl+0x1a/0x2f [c0105990] show_trace+0x12/0x14 [c010613d] dump_stack+0x6c/0x72 [c0113ab5] native_smp_call_function_mask+0x44/0x102 [c0114cc5] smp_call_function+0x1e/0x22 [c0125bb0] on_each_cpu+0x2a/0x57 [c01170f2] setup_nmi+0x33/0x4a [c0332a22] setup_IO_APIC+0x929/0xf11 [c0330178] native_smp_prepare_cpus+0x487/0x497 [c03273de] kernel_init+0x54/0x2c3 [c0104c83] kernel_thread_helper+0x7/0x10 === I'm in a twisty maze of kernel versions, all
Re: [PATCH 2/5] Provide acpi_check_{mem_}region.
On Wed, 24 Oct 2007 16:32:59 +0200 Thomas Renninger [EMAIL PROTECTED] wrote:
Provide acpi_check_{mem_}region.
Drivers can additionally check against possible ACPI interference by also
invoking this shortly before they call request_region.
If -EBUSY is returned, the driver must not load.
Use acpi_enforce_resources=strict/lax/no options to:
- strict: let conflicting drivers fail to load with an error message
- lax:let conflicting driver work normal with a warning message
- no: no functional change at all
OK, so Len has merged these into the acpi test tree. My understanding is
that once this work hits mainline, we can then merge
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch.
My normal approach would be to send
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch to Mark for
inclusion in git-hwmon one Len has merged the prerequisites into mainline.
Problem is, if Len merges late in the 2.6.26 merge window, Mark might not
have time to gets these changes into mainline before 2.6.27. Which is all
getting a bit dumb considering I first merged everything in October.
Fortunately things aren't mormally _this_ inefficient when one follows the
rules - this was an unusual patchset.
But still, I think we could afford to speed things up a bit more than that.
We could ask Len to consider merging this work into 2.6.25 and then if
Mark can ack check-for-acpi-resource-conflicts-in-hwmon-drivers.patch
(below) for an akpm-merge, we're good to go. But I do recall that people
were a bit uncertain about it all back in October.
Please share your thoughts with us.
From: Jean Delvare [EMAIL PROTECTED]
Check for ACPI resource conflicts in hwmon drivers. I've included
all Super-I/O and PCI drivers.
I've voluntarily left out:
* Laptop specific and vendor-specific drivers: if they conflicted
on any system, this would pretty much mean that they conflict on all
systems, and we would know by now.
* Legacy ISA drivers (lm78 and w83781d): they only support chips found
on old designs were ACPI either wasn't supported or didn't deal with
thermal management.
* Drivers accessing the I/O resources indirectly (e.g. through SMBus):
the check will be added where it belongs, i.e. in the bus drivers.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
Cc: Mark M. Hoffman [EMAIL PROTECTED]
Cc: Len Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/hwmon/dme1737.c|5 +
drivers/hwmon/f71805f.c|5 +
drivers/hwmon/f71882fg.c |5 +
drivers/hwmon/it87.c |5 +
drivers/hwmon/pc87360.c|6 ++
drivers/hwmon/pc87427.c|5 +
drivers/hwmon/sis5595.c|5 +
drivers/hwmon/smsc47b397.c |5 +
drivers/hwmon/smsc47m1.c |5 +
drivers/hwmon/via686a.c|5 +
drivers/hwmon/vt1211.c |5 +
drivers/hwmon/vt8231.c |5 +
drivers/hwmon/w83627ehf.c |6 ++
drivers/hwmon/w83627hf.c |5 +
14 files changed, 72 insertions(+)
diff -puN
drivers/hwmon/dme1737.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
drivers/hwmon/dme1737.c
--- a/drivers/hwmon/dme1737.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
+++ a/drivers/hwmon/dme1737.c
@@ -34,6 +34,7 @@
#include linux/hwmon-vid.h
#include linux/err.h
#include linux/mutex.h
+#include linux/acpi.h
#include asm/io.h
/* ISA device, if found */
@@ -2238,6 +2239,10 @@ static int __init dme1737_isa_device_add
};
int err;
+ err = acpi_check_resource_conflict(res);
+ if (err)
+ goto exit;
+
if (!(pdev = platform_device_alloc(dme1737, addr))) {
printk(KERN_ERR dme1737: Failed to allocate device.\n);
err = -ENOMEM;
diff -puN
drivers/hwmon/f71805f.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
drivers/hwmon/f71805f.c
--- a/drivers/hwmon/f71805f.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
+++ a/drivers/hwmon/f71805f.c
@@ -39,6 +39,7 @@
#include linux/mutex.h
#include linux/sysfs.h
#include linux/ioport.h
+#include linux/acpi.h
#include asm/io.h
static unsigned short force_id;
@@ -1455,6 +1456,10 @@ static int __init f71805f_device_add(uns
}
res.name = pdev-name;
+ err = acpi_check_resource_conflict(res);
+ if (err)
+ goto exit_device_put;
+
err = platform_device_add_resources(pdev, res, 1);
if (err) {
printk(KERN_ERR DRVNAME : Device resource addition failed
diff -puN
drivers/hwmon/f71882fg.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
drivers/hwmon/f71882fg.c
---
a/drivers/hwmon/f71882fg.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
+++ a/drivers/hwmon/f71882fg.c
@@ -27,6 +27,7 @@
#include linux/hwmon-sysfs.h
#include linux/err.h
#include linux/mutex.h
+#include linux/acpi.h
#include asm/io.h
#define DRVNAME f71882fg
@@ -898,6 +899,10
Re: [BUG] 2.6.24 refuses to boot - NMI watchdog problem?
On Wed, 6 Feb 2008 13:22:26 -0500 Len Brown [EMAIL PROTECTED] wrote: On Tuesday 05 February 2008 18:32, Andrew Morton wrote: On Sat, 2 Feb 2008 23:36:42 + (GMT) Chris Rankin [EMAIL PROTECTED] wrote: Hi, I have a 1 GHz Coppermine PC with 512 MB RAM, and it is failing to boot with the nmi_watchdog=1 option. This kernel was rebuilt after doing a make mrproper. The dmesg log follows: Can you tell us if earlier kernels worked OK, and if so which version(s)? From your other mail it appears that 2.6.23 was OK? ... ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 WARNING: at arch/x86/kernel/smp_32.c:561 native_smp_call_function_mask() Pid: 1, comm: swapper Not tainted 2.6.24 #1 [c0112a37] native_smp_call_function_mask+0x43/0x114 [c01149f2] enable_NMI_through_LVT0+0x0/0x26 [c01049b3] common_interrupt+0x23/0x28 [c01149f2] enable_NMI_through_LVT0+0x0/0x26 [c01149f2] enable_NMI_through_LVT0+0x0/0x26 [c0113c07] smp_call_function+0x1c/0x1f [c01244e2] on_each_cpu+0x28/0x54 [c0115eee] setup_nmi+0x30/0x47 [c032a820] setup_IO_APIC+0x88c/0xe49 [c01b2166] number+0x159/0x22f [c0103078] __switch_to+0x23/0x133 [c0282231] _spin_unlock_irq+0xe/0x22 [c011bd5a] finish_task_switch+0x1c/0x50 [c02807a5] schedule+0x527/0x541 [c02821a6] _spin_unlock+0xd/0x21 [c028083e] preempt_schedule+0x43/0x54 [c0120c92] vprintk+0x2c1/0x2fc [c020c610] device_add+0x318/0x541 [c0328084] native_smp_prepare_cpus+0x45f/0x46f [c01e0b07] acpi_ns_get_device_callback+0xfe/0x11c [c0282087] _spin_lock+0xd/0x5a [c011a998] task_rq_lock+0x28/0x4b [c028220f] _spin_unlock_irqrestore+0xf/0x23 [c011c13f] set_cpus_allowed+0x86/0x8e [c020e0d9] __driver_attach+0x0/0x7f [c0209860] serial8250_set_termios+0x2b4/0x2c8 [c031f349] kernel_init+0x0/0x2b2 [c031f39b] kernel_init+0x52/0x2b2 [c0282231] _spin_unlock_irq+0xe/0x22 [c011bd5a] finish_task_switch+0x1c/0x50 [c011cced] schedule_tail+0x17/0x51 [c0103ec2] ret_from_fork+0x6/0x1c [c031f349] kernel_init+0x0/0x2b2 [c031f349] kernel_init+0x0/0x2b2 [c0104bc3] kernel_thread_helper+0x7/0x10 === I think we've fixed that now. Len: if so, has that fix been sent in for 2.6.24.1? No, I don't know of any 2.6.24 oops fixes that aren't already in 2.6.24 -- at least I can't think of any right now. Actually on closer inspection I'd say that acpi_ns_get_device_callback is stack gunk and it isn't involved here. It isn't clear (to me) where in this mess we disabled interrupts around the set_cpus_allowed(). Chris, if this is repeatable it would be helpful to set CONFIG_FRAME_POINTER=y which hopefully will get us a cleaner trace, thanks. - 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: [X86 ACPI SMP] system slow after cold start if processor module loaded
On Sat, 2 Feb 2008 16:05:41 +0100 (CET) Guennadi Liakhovetski [EMAIL PROTECTED] wrote: Hi Don't know if this should be considered a bug-report, or just another ACPI bug on my system. In any case, if the CONFIG_ACPI_PROCESSOR is enabled, on first boot after a power off the system is slow. Not like if only 1 of 2 CPUs actually was running, much slower yet. Respectively, if the module is built into the kernel, it is slow more or less from the beginning - I guess, from the moment, when the module is initialized, if built as a module, it is slow after the module gets loaded. Also funny, it is only slow on the first boot, after a reboot into the same kernel it runs normally. The system is a dual [EMAIL PROTECTED], Compaq AP400. It is known to have various ACPI bugs, so, this is just another one of them. No idea whether or not this shall and can be fixed. At least wanted to document it in case someone has a similar problem. (added linux-acpi) If nothing happens with this (likely) then please raise a report against acpi at bugzilla.kernel.org, thanks. - 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] Rationalise ACPI backlight implementation
On Mon, 28 Jan 2008 01:25:50 + Matthew Garrett [EMAIL PROTECTED] wrote: On Sat, Jan 26, 2008 at 10:00:45PM -0800, Andrew Morton wrote: - Create a new /sys node with a new name which has the new semantics. The semantics are the same as they always have been - values between 0 and max_brightness are valid values. If you've made assumptions about what max_brightness is, then that's a bug in the userspace application rather than a change in the semantics of the interface. WTH? My (utterly comedic chase-crap-around-the-tree) brightness script was: ( 0 sh -c echo $1 /proc/acpi/sony/brightness 0 sh -c echo $1 /proc/acpi/sony/brightness_default 0 sh -c echo $1 /sys/class/backlight/sony/brightness 0 sh -c echo $1 /sys/class/backlight/thinkpad_screen/brightness ) 2/dev/null And yes, I had an rc.local command which assumed that 7 (later 8) is max brightness. You cannot seriously tell me that if we are to change this range from 0-8 up to 0-100 then this is not a backwards-incompatible change in semantics. My /sys/class/backlight/ directory is presently empty. Rather than trying to find out why, I think I'll just collapse in laughter. Guys, sort it out, please. - 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] Rationalise ACPI backlight implementation
On Thu, 24 Jan 2008 16:44:48 -0500 Len Brown [EMAIL PROTECTED] wrote: On Tuesday 25 December 2007 21:03, Matthew Garrett wrote: The sysfs backlight class provides no mechanism for querying the acceptable brightness for a backlight. The ACPI spec states that values are only valid if they are reported as available by the firmware. Since we can't provide that information to userspace, instead collapse the range to the number of actual values that can be set. Signed-off-by: Matthew Garrett [EMAIL PROTECTED] I wish we did this in the first place. But doing it now is an API change -- since with the old way 100 always meant 100% brightness, yes? so my concern is that if we change what 10 means, somebody like akpm with an existing script gets grumpy. It takes more than that to make me grumpy. I've been very grumpy lately. - Create a new /sys node with a new name which has the new semantics. - Deprecate the old /sys entry by emitting an angry printk when someone uses it. - Wait 12 months - Kill the old one. - 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] PNP: disable Supermicro H8DCE motherboard resources that overlap SATA BARs
On Thu, 17 Jan 2008 16:03:18 -0700 Bjorn Helgaas [EMAIL PROTECTED] wrote: +static void quirk_supermicro_h8dce_system(struct pnp_dev *dev) hm. If you trace back through the callchain here is seems that large amounts of the pnp code could be made __init/__initdata. The two callers of pnp_add_device() are __init and afaict they're the only callers of the quirk code? Anyway. It's not a lot of fun to pick through all that and it's easy to break things. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc8-mm1
On Thu, 17 Jan 2008 18:16:22 +0530 Balbir Singh [EMAIL PROTECTED] wrote: * Andrew Morton [EMAIL PROTECTED] [2008-01-17 02:35:14]: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/ - selinux is busted on one of my two selinux-enabled test machines. - suspend-to-ram and suspend-to-disk are totally hosed on one of my test machines. I guess I get to bisect this. - git-nfsd is dropped due to conflicts with git-nfs - git-newsetup is dropped due to conflicts with git-x86 (I think) - git-perfmon is dropped due to conflicts with git-x86 (I think) - git-kgdb is dropped due to conflicts with git-damn-near-everything - git-block is dropped due to conflicts with the IDE tree - kvm probably doesn't work properly because I couldn't be bothered fixing the conflicts between git-kvm and the driver tree - the volume of rejects and build errors which are caused by subsystem maintainers fiddling with other people's stuff is quite out of control. Something needs to happen here. Hi, Andrew, May be it was one of the conflicts, but my system fails to get ethernet working with this version. I see e100: Intel(R) PRO/100 Network Driver, 3. 5.23-k4-NAPI e100: Copyright(c) 1999-2006 Intel Corporation ACPI: PCI Interrupt :04:08.0[A] - GSI 20 (level, low) - IRQ 20 modprobe:2584 conflicting cache attribute 5000-50001000 uncached-default e100: :04:08.0: e100_probe: Cannot map device registers, aborting. ACPI: PCI interrupt for device :04:08.0 disabled e100: probe of :04:08.0 failed with error -12 Other interesting boot information Using ACPI (MADT) for SMP configuration information PM: Registered nosave memory: 0008f000 - 000a PM: Registered nosave memory: 000a - 000e PM: Registered nosave memory: 000e - 0010 PM: Registered nosave memory: 3e5d1000 - 3e6e5000 PM: Registered nosave memory: 3f574000 - 3f57c000 PM: Registered nosave memory: 3f62d000 - 3f631000 PM: Registered nosave memory: 3f6a7000 - 3f6e9000 PM: Registered nosave memory: 3f6ed000 - 3f6ff000 Allocating PCI resources starting at 5000 (gap: 4000:bff8) PCI: Bridge: :00:1c.0 IO window: disabled. MEM window: 0x5030-0x503f PREFETCH window: disabled. PCI: Bridge: :00:1c.2 IO window: disabled. MEM window: 0x5040-0x504f PREFETCH window: disabled. PCI: Bridge: :00:1c.3 IO window: disabled. MEM window: 0x5050-0x505f PREFETCH window: disabled. PCI: Bridge: :00:1e.0 IO window: 1000-1fff MEM window: 0x5000-0x500f PREFETCH window: disabled. I am yet to get down to the root cause, thought I'd report it first to the x86 and ACPI list to see if someone has seen the problem before. It appears that the new PAT code didn't like e100's pci_iomap(). Venki, can you take a look please? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc8-mm1
On Thu, 17 Jan 2008 11:22:19 -0800 Pallipadi, Venkatesh [EMAIL PROTECTED] wrote: The problem is modprobe:2584 conflicting cache attribute 5000-50001000 uncached-default Some address range here is being mapped with conflicting types. Somewhere the range was mapped with default (write-back). Later pci_iomap() is mapping that region as uncacheable which is basically aliasing. PAT code detects the aliasing and fails the second uncacheable request which leads in the failure. It sounds to me like you need considerably more runtime debugging and reporting support in that code. Ensure that it generates enough output both during regular operation and during failures for you to be able to diagnose things in a single iteration. We can always take it out later. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Mon, 14 Jan 2008 08:39:26 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote: diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index c27c7d6..4f41a94 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw) sky2_write8(hw, B0_CTST, CS_RST_SET); sky2_write8(hw, B0_CTST, CS_RST_CLR); + /* allow writes to PCI config */ + sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON); + /* clear PCI errors, if any */ pci_read_config_word(pdev, PCI_STATUS, status); status |= PCI_STATUS_ERROR_BITS; fixes this regression? If so, we should revert that change. but i noticed another bug on 2.6.24-rc7-git with sky2: dmesg shows a lot of lines every 5 seconds: [...] [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 [ 362.442039] printk: 41 messages suppressed. [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 [ 367.439151] printk: 18 messages suppressed. [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 [ 372.436267] printk: 30 messages suppressed. [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 [ 377.350236] printk: 19 messages suppressed. [...] since i do not notice any errors (yet) i'll wait till next rc, maybe it will be gone then... That's not good. is this new behaviour? No, reverting that change will break other systems (including mine). Reverting which change? ac93a3946b676025fa55356180e8321639744b31? Linus has very clearly stated on multiple occasions that patches which fix machine A and break machine B will be reverted. For good reasons. I don't have a copy of those reasons handy, but it should be a well-known thing. If you're really interested we can cc him for a reminder, but the effects of that upon ac93a3946b676025fa55356180e8321639744b31 might be quick. And terminal. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Sun, 13 Jan 2008 16:08:38 +0100 supersud501 [EMAIL PROTECTED] wrote: supersud501 wrote: Rafael J. Wysocki wrote: Since it seems to be 100% reproducible, it would be very helpful if you could use git-bisect to identify the offending commit. allright, bisect found the offending commit, here's what i've done: first i started bisect with the following command (since i assumed it is a net-driver problem): git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/' after building many kernels and saying good/bad if wol worked/didn't work etc. it identified the following commit: # bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI config writes and refs/bisect/bad gives: 14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad ac93a3946b676025fa55356180e8321639744b31 need some more info? i just checked it: commented out the passage of the commit in kernel 2.6.24-rc7-git4 and compiled it: wol WORKS. so this one line is causing my wol-disturbance... So simply reverting this: commit ac93a3946b676025fa55356180e8321639744b31 Author: Stephen Hemminger [EMAIL PROTECTED] Date: Mon Nov 5 15:52:08 2007 -0800 sky2: enable PCI config writes On some boards, PCI configuration space access is turned off by default. The 2.6.24 driver doesn't turn it on, and should have. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index c27c7d6..4f41a94 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw) sky2_write8(hw, B0_CTST, CS_RST_SET); sky2_write8(hw, B0_CTST, CS_RST_CLR); + /* allow writes to PCI config */ + sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON); + /* clear PCI errors, if any */ pci_read_config_word(pdev, PCI_STATUS, status); status |= PCI_STATUS_ERROR_BITS; fixes this regression? If so, we should revert that change. but i noticed another bug on 2.6.24-rc7-git with sky2: dmesg shows a lot of lines every 5 seconds: [...] [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 [ 362.442039] printk: 41 messages suppressed. [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 [ 367.439151] printk: 18 messages suppressed. [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 [ 372.436267] printk: 30 messages suppressed. [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 [ 377.350236] printk: 19 messages suppressed. [...] since i do not notice any errors (yet) i'll wait till next rc, maybe it will be gone then... That's not good. is this new behaviour? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Sun, 13 Jan 2008 21:27:40 +0100 supersud501 [EMAIL PROTECTED] wrote: Andrew Morton wrote: So simply reverting this: commit ac93a3946b676025fa55356180e8321639744b31 Author: Stephen Hemminger [EMAIL PROTECTED] Date: Mon Nov 5 15:52:08 2007 -0800 sky2: enable PCI config writes On some boards, PCI configuration space access is turned off by default. The 2.6.24 driver doesn't turn it on, and should have. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index c27c7d6..4f41a94 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw) sky2_write8(hw, B0_CTST, CS_RST_SET); sky2_write8(hw, B0_CTST, CS_RST_CLR); + /* allow writes to PCI config */ + sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON); + /* clear PCI errors, if any */ pci_read_config_word(pdev, PCI_STATUS, status); status |= PCI_STATUS_ERROR_BITS; fixes this regression? If so, we should revert that change. yes, it does. OK, thanks. I queued up the revert and shall wait to hear from Stephen/David/Jeff on this. but i noticed another bug on 2.6.24-rc7-git with sky2: dmesg shows a lot of lines every 5 seconds: [...] [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 [ 362.442039] printk: 41 messages suppressed. [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 [ 367.439151] printk: 18 messages suppressed. [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 [ 372.436267] printk: 30 messages suppressed. [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 [ 377.350236] printk: 19 messages suppressed. [...] since i do not notice any errors (yet) i'll wait till next rc, maybe it will be gone then... That's not good. is this new behaviour? at least on 2.6.23.12 i doesn't happen, so it's now for me in 2.6.24-rc7-git4 (but again, not testet in earlier versions of 2.6.24). since i do not feel any sideeffects yet after using it for ~6 hours (besides a really long dmesg-output), it's just a little bit annoying. if there's a way to identify the source of the problem besides of bisecting, just say so and i will take a look into it the next days. if bisecting is the only (time-consuming) way you have to wait at least until the next weekend :) 2.6.23 also has this warning in sky2_err_intr() but it doesn't trigger there. Rafael, I think we'd have to class this as a post-2.6.23 regression. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9731] New: 2.6.24-rc7: Deadlock when any ACPI eject sys node written
On Fri, 11 Jan 2008 09:38:25 -0800 (PST) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9731
Summary: 2.6.24-rc7: Deadlock when any ACPI eject sys node
written
Product: ACPI
Version: 2.5
KernelVersion: 2.6.24-rc7
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Latest working kernel version: Unknown
Earliest failing kernel version: All 2.6.24-rc versions I've tried
Distribution: sles10
Hardware Environment: x86_64
Software Environment:
Problem Description:
I have hardware that supports ejectable CPUs. Any attempt to eject a CPU by
echoing 1 into the /sys node results in the shell doing the echo deadlocking.
Here's what dmesg says bash is doing:
bash D 0 3552 3372
810007023ca8 0082 8100014327f0
81000ecde0c0 8100014437c0
304a455f0dd521a0 db37 00ff 81000fe37900
Call Trace:
[80447282] wait_for_completion+0xa2/0xf0
[80231d50] default_wake_function+0x0/0x10
[802e2f6d] sysfs_addrm_finish+0x1dd/0x250
[802e17d6] sysfs_hash_and_remove+0xa6/0xc0
[8038d37d] device_remove_file+0x2d/0x60
[803525c3] acpi_device_unregister+0xc8/0x124
[80352778] acpi_bus_remove+0x5e/0x64
[803527f8] acpi_bus_trim+0x7a/0xee
[803528e8] acpi_eject_store+0x7c/0x119
[802e1ef4] sysfs_write_file+0xd4/0x150
[80293f7d] vfs_write+0xdd/0x150
[80294643] sys_write+0x53/0x90
[8020bf1e] system_call+0x7e/0x83
The problem seems to be that acpi_device_unregister tries to delete the sys
node for eject, but the node cannot be deleted until the write completes.
sysfs_write_file calls flush_write_buffer, which does this:
static int
flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer,
size_t
count)
{
struct sysfs_dirent *attr_sd = dentry-d_fsdata;
struct kobject *kobj = attr_sd-s_parent-s_elem.dir.kobj;
struct sysfs_ops * ops = buffer-ops;
int rc;
/* need attr_sd for attr and ops, its parent for kobj */
if (!sysfs_get_active_two(attr_sd))
return -ENODEV;
rc = ops-store(kobj, attr_sd-s_elem.attr.attr, buffer-page, count);
sysfs_put_active_two(attr_sd);
return rc;
}
sysfs_addrm_finish calls sysfs_deactivate, which is stuck waiting forever on
the wait_for_completion call:
/**
* sysfs_deactivate - deactivate sysfs_dirent
* @sd: sysfs_dirent to deactivate
*
* Deny new active references and drain existing ones.
*/
static void sysfs_deactivate(struct sysfs_dirent *sd)
{
DECLARE_COMPLETION_ONSTACK(wait);
int v;
BUG_ON(sd-s_sibling || !(sd-s_flags SYSFS_FLAG_REMOVED));
sd-s_sibling = (void *)wait;
/* atomic_add_return() is a mb(), put_active() will always see
* the updated sd-s_sibling.
*/
v = atomic_add_return(SD_DEACTIVATED_BIAS, sd-s_active);
if (v != SD_DEACTIVATED_BIAS)
wait_for_completion(wait);
sd-s_sibling = NULL;
}
But it looks like to me the wait_for_completion() won't return until the call
to sysfs_put_active_two() in flush_write_buffer() is invoked. This looks like
a deadlock to me.
I can provide more information if it's helpful, and can help with testing any
patches.
I'm not sure when this problem was exactly first introduced. 2.6.22 hung in a
similar way, but it looks like the code that deals with deleting sysfs nodes
got significantly reworked between 2.6.22 and 2.6.24.
Steps to reproduce:
echo 1 into any /sys/devices/LNXSYSTM:00/ACPI*/eject node. Watch the parent
process hang.
Thanks. So it would seem that sysfs core changes caused the acpi code to
fail.
-
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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Fri, 11 Jan 2008 16:46:13 -0800 Andrew Morton [EMAIL PROTECTED] wrote: The first patch in the series introduces such a mechanism. The remaining three patches modify the MSR, x86-64 MCE and cpuid drivers in accordance with the above approach. These patches are a preresuisite to gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch and its later fixed-up versions. So what I have now is revert-gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch pm-introduce-destroy_suspended_device.patch pm-do-not-destroy-create-devices-while-suspended-in-msrc-rev-2.patch pm-do-not-destroy-create-devices-while-suspended-in-mce_64c.patch pm-do-not-destroy-create-devices-while-suspended-in-cpuidc.patch pm-acquire-device-locks-on-suspend-rev-3.patch pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes.patch pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes-2.patch So what needs to happen in Greg's tree is a) drop the old gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch b) apply these four patches c) apply the new pm-acquire-device-locks-on-suspend-rev-3.patch (and its fixups) err, no. pm-introduce-destroy_suspended_device.patch demolishes pm-acquire-device-locks-on-suspend-rev-3.patch Confused, giving up. - 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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Wed, 2 Jan 2008 00:32:44 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: Some device drivers register CPU hotplug notifiers and use them to destroy device objects when removing the corresponding CPUs and to create these objects when adding the CPUs back. Unfortunately, this is not the right thing to do during suspend/hibernation, since in that cases the CPU hotplug notifiers are called after suspending devices and before resuming them, so the operations in question are carried out on the objects representing suspended devices which shouldn't be unregistered behing the PM core's back. __Although right now it usually doesn't lead to any practical complications, it will predictably deadlock if gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is applied. The solution is to prevent drivers from removing/adding devices from within CPU hotplug notifiers during suspend/hibernation using the FROZEN bit in the notifier's action argument. However, this has to be done with care, since the devices objects related to the nonboot CPUs that failed to go online during resume should not be present in the system. For this reason, it seems reasonable to introduce a mechanism allowing drivers to ask the PM core to remove device objects corresponding to suspended devices on their behalf. The first patch in the series introduces such a mechanism. The remaining three patches modify the MSR, x86-64 MCE and cpuid drivers in accordance with the above approach. These patches are a preresuisite to gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch and its later fixed-up versions. So what I have now is revert-gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch pm-introduce-destroy_suspended_device.patch pm-do-not-destroy-create-devices-while-suspended-in-msrc-rev-2.patch pm-do-not-destroy-create-devices-while-suspended-in-mce_64c.patch pm-do-not-destroy-create-devices-while-suspended-in-cpuidc.patch pm-acquire-device-locks-on-suspend-rev-3.patch pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes.patch pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes-2.patch So what needs to happen in Greg's tree is a) drop the old gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch b) apply these four patches c) apply the new pm-acquire-device-locks-on-suspend-rev-3.patch (and its fixups) - 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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Fri, 11 Jan 2008 22:11:52 -0500 (EST) Alan Stern [EMAIL PROTECTED] wrote: On Fri, 11 Jan 2008, Greg KH wrote: On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote: err, no. pm-introduce-destroy_suspended_device.patch demolishes pm-acquire-device-locks-on-suspend-rev-3.patch Confused, giving up. I'm confused too, I have no idea what the proper order of things should be either. Anyone want to give me a hint? Sorry for the confusion. The correct patch to apply is pm-acquire-device-locks-on-suspend-rev-3 (plus the attending style-fixups). It encompasses those earlier patches. The real problem is that our current email workflow patterns don't provide a standardized way for maintainers to tell when a new patch submission is meant to override or replace an earlier submission (or even a set of earlier submissions). Does anybody have some suggestions for a good way to do this? Don't formally send it until it's ready. Seriously. You can always resend it if it didn't get applied anywhere. Once a patch reaches a sufficient level of maturity for it to be ready to be merged into a subsystem tree, any subsequent changes should be sufficiently small that incremental patches are the way to apply touchups. The core problem here is that (lots of) people are flinging patches at tree-owners before they are sufficiently baked. - 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 5/8] rtc: don't write RTC century when setting a wake alarm
On Thu, 13 Dec 2007 15:53:38 -0800 [EMAIL PROTECTED] wrote: From: Mark Lord [EMAIL PROTECTED] Fix /proc/acpi/alarm to not overwrite the RTC century field when setting a wake alarm. The alarm hardware doesn't have a century field, and we really should not be fiddling with the RTC century field here. So this bugfix was summarily ignored without comment and a different one was merged which caused this patch to get 100% rejects. Great stuff. I'll drop this one. Mark, could you please redo and retest and we'll have another go. - 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: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree
On Sun, 06 Jan 2008 16:34:16 -0500 Mark Lord [EMAIL PROTECTED] wrote: Venki Pallipadi wrote: Reintroduce run time configurable max_cstate for !CPU_IDLE case. Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c === --- linux-2.6.24-rc.orig/drivers/acpi/processor_idle.c +++ linux-2.6.24-rc/drivers/acpi/processor_idle.c @@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea #define PM_TIMER_TICKS_TO_US(p)(((p) * 1000)/(PM_TIMER_FREQUENCY/1000)) static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER; +#ifdef CONFIG_CPU_IDLE module_param(max_cstate, uint, ); +#else +module_param(max_cstate, uint, 0644); +#endif static unsigned int nocst __read_mostly; module_param(nocst, uint, ); .. Can we get this patch upstream so that a stock 2.6.24 will work here? umm, OK, I queued it for 2.6.24. I'll give people a day or so to comment on this. I had to invent some silly changlelog for it. Please review it for accuracy and completeness? It isn't complete, really. How come we only make max_cstate writeable if CONFIG_CPU_IDLE=n? What happens to people who were reliant upon writeable max_cstate who now enable CPU_IDLE? Things still break? What is the rationale behind this? What constraints led us to this decision? From: Venki Pallipadi [EMAIL PROTECTED] This was writeable in 2.6.23 but the cpuidle merge made it read-only. But some people's scripts (ie: Mark's) were writing to it. As an unhappy compromise, make max_cstate writeable again if the kernel was configured without CONFIG_CPU_IDLE. Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Cc: Mark Lord [EMAIL PROTECTED] Cc: Arjan van de Ven [EMAIL PROTECTED] Cc: Len Brown [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: Rafael J. Wysocki [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/acpi/processor_idle.c |4 1 file changed, 4 insertions(+) diff -puN drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case drivers/acpi/processor_idle.c --- a/drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case +++ a/drivers/acpi/processor_idle.c @@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea #define PM_TIMER_TICKS_TO_US(p)(((p) * 1000)/(PM_TIMER_FREQUENCY/1000)) static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER; +#ifdef CONFIG_CPU_IDLE module_param(max_cstate, uint, ); +#else +module_param(max_cstate, uint, 0644); +#endif static unsigned int nocst __read_mostly; module_param(nocst, uint, ); _ - 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: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree
On Wed, 2 Jan 2008 16:06:20 -0800 Pallipadi, Venkatesh [EMAIL PROTECTED] wrote: -Original Message- From: Mark Lord [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 02, 2008 3:42 PM To: Arjan van de Ven Cc: Pallipadi, Venkatesh; Andrew Morton; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Ingo Molnar; [EMAIL PROTECTED]; linux-acpi@vger.kernel.org Subject: Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree Arjan van de Ven wrote: On Fri, 30 Nov 2007 22:31:17 -0500 Mark Lord [EMAIL PROTECTED] wrote: Arjan van de Ven wrote: On Fri, 30 Nov 2007 22:14:08 -0500 Mark Lord [EMAIL PROTECTED] wrote: in -mm there is.. the QoS stuff allows you to set maximum tolerable .. That's encouraging, I think, but not for 2.6.24. latency. If your app cant take any latency, you should set those... and the side effect is that the kernel will not do long-latency C-states or P-state transitions.. .. I don't mind the cpufreq changing (actually, I want it to drop in cpugfreq to save power and keep the fan off), but the C-states just kill this app. The app is VMware. I force the max_state=1 when launching, ah but then its' even easier... and can be done in 2.6.24 already. VMWare after all has a kernel module, and the latency stuff is in 2.6.23 and 2.6.24 available inside the kernel already. .. Oh, I'm perfectly happy to write my own kernel module if that's what all you need to do in your kernel module is call add_latency_constraint(mark_wants_his_mouse, 5); or so .. Dredging up an old regression again now: The make my own module to replace /sys/.../max_cstate doesn't work for the single-core machine we use a lot around here. VMware is totally sluggish unless I go to another text window and do this: while ( true ); do echo -n ; done At which point VMware performs well again, the same as with echo 1 max_cstate in 2.6.23. Anyone got any suggestions on how to fix this regression or work around it for 2.6.24 ? Easiest and clean way to do it is to have a driver with set_acceptable_latency() for 1uS or so in init and remove_acceptable_latency() at exit. err, you appear to be suggesting that Mark patch his kernel to make it work as well as 2.6.23? That would be a wrong answer. This regression was known six weeks ago. What do we need to do (or revert) to fix it in 2.6.24? - 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
Fw: [Bugme-new] [Bug 9663] New: in 2.6.24-rc6 function keys on my notebook doesn`t work
Another regression. Begin forwarded message: Date: Sat, 29 Dec 2007 16:07:30 -0800 (PST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 9663] New: in 2.6.24-rc6 function keys on my notebook doesn`t work http://bugzilla.kernel.org/show_bug.cgi?id=9663 Summary: in 2.6.24-rc6 function keys on my notebook doesn`t work Product: ACPI Version: 2.5 KernelVersion: 2.6.24-rc6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: ACPICA-Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: 2.6.23.12 Distribution: debian unstable Hardware Environment: toshiba u300-13m Software Environment: - Problem Description: function keys that tune the brightness of lcd on my notebook stop to work. function key that enable/disable touchpad stop to work. on 2.6.23.12 kernel it work fine, but atkbd.c always report about unknown key code but keys work! on .24 kernel no such reports happen but keys doesn`t work! Steps to reproduce: install 2.6.24-rc6 kernel -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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: brightness control on thinkpad t61p
On Mon, 24 Dec 2007 15:08:37 -0200 Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Sun, 23 Dec 2007, Andrew Morton wrote: When I fire up the latest Linus tree on my thinkpad t61p I get: thinkpad_acpi: ThinkPad ACPI Extras v0.17 thinkpad_acpi: http://ibm-acpi.sf.net/ thinkpad_acpi: ThinkPad BIOS 7LET44WW (1.14 ), EC 7KHT22WW-1.06 thinkpad_acpi: Lenovo ThinkPad T61p thinkpad_acpi: radio switch found; radios are enabled ACPI: Lid Switch [LID] input: Sleep Button (CM) as /class/input/input6 ACPI: Sleep Button (CM) [SLPB] thinkpad_acpi: standard ACPI backlight interface available, not loading native one... and /sys/class/backlight/thinkpad_screen/brightness is no longer present, so my `brightness' script no longer works. That, my friends, is a regression. For thinkpad-acpi at least, it is not a regression. 2.6.23/0.16 did NOT support your thinkpad (it will pretend to work, but it won't work 100% right as it only supports 8 levels of backlight control). Well it may have been partially working, but it worked. 2.6.24-rc4/0.17 added support for it (16-level brightness), but also added the automatic detection of ACPI generic video support. Doesn't work. You can ask thinkpad-acpi for the backlight interface using the brightness_enable=1 parameter, if you'd rather use it instead of the generic ACPI video driver. I don't know if you can ask video to not enable backlight control, though. I shouldn't have to add some module parameter to get previously-working stuff to work again. So I go hunting around and find /sys/class/backlight/acpi_video0/ and /sys/class/backlight/acpi_video1/ Why are there two of them? Two nodes in the ACPI tree (AGP and PCI), and the ACPI drivers don't differentiate a deactivated node from a working node yet. There are some tentative patches flying around to fix it, AFAIK. Both of these have a `brightness' entry which has contents of 100. When I set that to 10, the screen's brightness is not reduced. One of them should work. Maybe X.org is doing something? Dunno. - 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: brightness control on thinkpad t61p
On Mon, 24 Dec 2007 07:34:06 + Matthew Garrett [EMAIL PROTECTED] wrote: On Sun, Dec 23, 2007 at 12:00:57AM -0800, Andrew Morton wrote: and /sys/class/backlight/thinkpad_screen/brightness is no longer present, so my `brightness' script no longer works. That, my friends, is a regression. The thinkpad_acpi brightness interface simply doesn't work correctly on recent Thinkpads. The ACPI interface does, but the currently exported ui to it approximates some sort of horrific loss. I'll try to fix that in the next week or so. Vice versa for me. The thinkpad_acpi driver in 2.6.23 _does_ work, but its interface vanished in 2.6.24-rc5 and the acpi driver does not work. - 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
brightness control on thinkpad t61p
When I fire up the latest Linus tree on my thinkpad t61p I get: thinkpad_acpi: ThinkPad ACPI Extras v0.17 thinkpad_acpi: http://ibm-acpi.sf.net/ thinkpad_acpi: ThinkPad BIOS 7LET44WW (1.14 ), EC 7KHT22WW-1.06 thinkpad_acpi: Lenovo ThinkPad T61p thinkpad_acpi: radio switch found; radios are enabled ACPI: Lid Switch [LID] input: Sleep Button (CM) as /class/input/input6 ACPI: Sleep Button (CM) [SLPB] thinkpad_acpi: standard ACPI backlight interface available, not loading native one... and /sys/class/backlight/thinkpad_screen/brightness is no longer present, so my `brightness' script no longer works. That, my friends, is a regression. Here's my script: ( 0 sh -c echo $1 /proc/acpi/sony/brightness 0 sh -c echo $1 /proc/acpi/sony/brightness_default 0 sh -c echo $1 /sys/class/backlight/sony/brightness 0 sh -c echo $1 /sys/class/backlight/thinkpad_screen/brightness ) 2/dev/null which rather shows how pathetic we are in this area. Ho hum. So I go hunting around and find /sys/class/backlight/acpi_video0/ and /sys/class/backlight/acpi_video1/ Why are there two of them? Both of these have a `brightness' entry which has contents of 100. When I set that to 10, the screen's brightness is not reduced. So as far as I can tell, we have lost the ability to alter the brightness of the screen on this machine. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9627] New: Regression: Battery method parse error
On Sun, 23 Dec 2007 13:00:19 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9627 Looks like another regression to track, please. - 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 2/8] git-acpi build fix
On Fri, 14 Dec 2007 01:24:32 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 14 of December 2007, [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] ia64 allmodconfig: kernel/power/main.c:493: error: `pm_test_attr' undeclared here (not in a function) I've already sent a better fix for that, thanks. I don't think I was cc'ed. Please make sure that I see fixes to trees which are in -mm? - 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: BUG: 2.6.24-rc5-mm1 - pci-disable-decoding-during-sizing-of-bars.patch -- list_add corruption. prev-next should be next (dfe221f0), but was dfe22100. (prev=dfe221f0).
On Fri, 14 Dec 2007 01:00:19 -0500 Miles Lane [EMAIL PROTECTED] wrote: I first hit this BUG with straight 2.6.24-rc5-mm1, and then reproduced it with the pci-disable-decoding-during-sizing-of-bars patch removed. hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x00bf000c lp: driver loaded but no devices found Adding 570268k swap on /dev/sda5. Priority:-1 extents:1 across:570268k EXT3 FS on sda3, internal journal list_add corruption. prev-next should be next (dfe221f0), but was dfe22100. (prev=dfe221f0). BUG: using smp_processor_id() in preemptible [0001] code: modprobe/3107 caller is die+0x5d/0x1db Pid: 3107, comm: modprobe Not tainted 2.6.24-rc5-mm1 #24 [c0108eb2] show_trace_log_lvl+0x12/0x25 [c0109659] show_trace+0xd/0x10 [c0109981] dump_stack+0x57/0x5f [c02017f5] debug_smp_processor_id+0x99/0xb0 [c0109174] die+0x5d/0x1db [c03cdf38] do_trap+0x8a/0xa3 [c0109509] do_invalid_op+0x6c/0x76 [c03cdd02] error_code+0x72/0x78 [f8a446c7] acpi_video_bus_add+0x85b/0xbf4 [video] [c023b3cf] acpi_device_probe+0x3e/0xdb [c02725cd] driver_probe_device+0xaf/0x12a [c0272760] __driver_attach+0x6c/0xa5 [c0271b27] bus_for_each_dev+0x3e/0x60 [c0272455] driver_attach+0x14/0x16 [c0272279] bus_add_driver+0xa9/0x1b0 [c0272957] driver_register+0x47/0xa3 [c023b748] acpi_bus_register_driver+0x3a/0x3c [f8a1d032] acpi_video_init+0x32/0x51 [video] [c014eafb] sys_init_module+0x142b/0x14f4 [c0107cea] sysenter_past_esp+0x6b/0xc1 The above is a silly debugging thing - it's a missed raw_smp_processor_id(). Fix appended. === [ cut here ] kernel BUG at lib/list_debug.c:33! invalid opcode: [#1] PREEMPT SMP last sysfs file: /sys/class/vc/vcsa6/dev Modules linked in: video backlight output dm_crypt sbp2 parport_pc lp parport arc4 ecb crypto_blkcipher cryptomgr snd_hda_intel crypto_algapi snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss pcmcia snd_seq_midi snd_rawmidi iwl3945 snd_seq_midi_event snd_seq sky2 mac80211 tifm_7xx1 snd_timer snd_seq_device tifm_core cfg80211 iTCO_wdt iTCO_vendor_support yenta_socket rsrc_nonstatic pcmcia_core snd watchdog_core soundcore watchdog_dev shpchp pci_hotplug snd_page_alloc ata_generic firewire_ohci piix firewire_core crc_itu_t ide_core Pid: 3107, comm: modprobe Not tainted (2.6.24-rc5-mm1 #24) BUG: using smp_processor_id() in preemptible [0001] code: modprobe/3107 caller is __show_registers+0x8d/0x1af Pid: 3107, comm: modprobe Not tainted 2.6.24-rc5-mm1 #24 [c0108eb2] show_trace_log_lvl+0x12/0x25 [c0109659] show_trace+0xd/0x10 [c0109981] dump_stack+0x57/0x5f [c02017f5] debug_smp_processor_id+0x99/0xb0 [c0106358] __show_registers+0x8d/0x1af [c0108f73] show_registers+0x19/0x1bd [c010922e] die+0x117/0x1db [c03cdf38] do_trap+0x8a/0xa3 [c0109509] do_invalid_op+0x6c/0x76 [c03cdd02] error_code+0x72/0x78 [f8a446c7] acpi_video_bus_add+0x85b/0xbf4 [video] [c023b3cf] acpi_device_probe+0x3e/0xdb [c02725cd] driver_probe_device+0xaf/0x12a [c0272760] __driver_attach+0x6c/0xa5 [c0271b27] bus_for_each_dev+0x3e/0x60 [c0272455] driver_attach+0x14/0x16 [c0272279] bus_add_driver+0xa9/0x1b0 [c0272957] driver_register+0x47/0xa3 [c023b748] acpi_bus_register_driver+0x3a/0x3c [f8a1d032] acpi_video_init+0x32/0x51 [video] [c014eafb] sys_init_module+0x142b/0x14f4 [c0107cea] sysenter_past_esp+0x6b/0xc1 === EIP: 0060:[c0201893] EFLAGS: 00010246 CPU: 0 EIP is at __list_add+0x34/0x4a Well, that's a list_head handling bug in drivers/acpi/video.c. list_add_tail(data-entry, video-video_device_list); went bad.. From: Andrew Morton [EMAIL PROTECTED] We missed one: BUG: using smp_processor_id() in preemptible [0001] code: modprobe/3107 caller is die+0x5d/0x1db Pid: 3107, comm: modprobe Not tainted 2.6.24-rc5-mm1 #24 [c0108eb2] show_trace_log_lvl+0x12/0x25 [c0109659] show_trace+0xd/0x10 [c0109981] dump_stack+0x57/0x5f [c02017f5] debug_smp_processor_id+0x99/0xb0 [c0109174] die+0x5d/0x1db [c03cdf38] do_trap+0x8a/0xa3 [c0109509] do_invalid_op+0x6c/0x76 [c03cdd02] error_code+0x72/0x78 [f8a446c7] acpi_video_bus_add+0x85b/0xbf4 [video] [c023b3cf] acpi_device_probe+0x3e/0xdb Convert the other debugging smp_processor_id() calls in there too - perhaps they are also callable under conditions where preemption is thought to be enabled. Miles Lane [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: Thomas Gleixner [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- arch/x86/kernel/traps_32.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff -puN arch/x86/kernel/traps_32.c~a arch/x86/kernel/traps_32.c --- a/arch/x86/kernel/traps_32.c~a +++ a/arch/x86/kernel/traps_32.c @@ -375,7 +375,7 @@ void die(const char * str, struct pt_reg console_verbose(); __raw_spin_lock(die.lock); raw_local_save_flags
Re: [GIT PATCH] ACPI patches for 2.6.24-rc5
On Fri, 14 Dec 2007 01:26:11 -0500 Len Brown [EMAIL PROTECTED] wrote: please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release This will update the files shown below. thanks! -Len ps. individual patches are available on linux-acpi@vger.kernel.org and a consolidated plain patch is available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.24/acpi-release-20070126-2.6.24-rc5.diff.gz drivers/acpi/battery.c |2 +- drivers/acpi/numa.c |4 ++-- drivers/acpi/video.c |4 ++-- drivers/misc/thinkpad_acpi.c |4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) What's happening with Alexey's sbs regression fixes? - 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: PNP: do not stop/start devices in suspend/resume path
On Thu, 6 Dec 2007 16:25:57 -0700 Bjorn Helgaas [EMAIL PROTECTED] wrote: Andrew, can you add this before pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch? ... PNP: do not stop/start devices in suspend/resume path I did, but I also temporarily dropped pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch. Is it expected that this patch will fix pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch? Should I bring it back? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9555] New: Suspend to RAM horks keyboard autorepeat, system bell, trackpad
(switching to email - please respond via emailed reply-to-all, not via the bugzilla web interface) On Wed, 12 Dec 2007 18:18:05 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9555 Summary: Suspend to RAM horks keyboard autorepeat, system bell, trackpad Product: Power Management Version: 2.5 KernelVersion: 2.6.23.8 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Hibernation/Suspend AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: 2.6.23.1 Distribution: Ubuntu feisty Hardware Environment: Sony Vaio SR71 Software Environment: Problem Description: With 2.6.23.8, when I suspend to RAM (using /usr/sbin/hibernate -F /etc/hibernate/ram.conf) from within X, when I resume I see the following odd behavior: 1. The system bell is now half a second long. 2. Keyboard autorepeat has a very long delay -- like 7 seconds before the first repeated character shows up. 3. If I configure X to use the (Alps) trackpad via the synaptics driver, after resuming, clicks from the trackpad don't work at all -- not only are taps ignored (which is how I've configured xorg.conf) but the physical buttons don't generate click events either. If I configure X to use the trackpad just as a PS/2 mouse, though, it still works normally after resuming. 2.6.23.1 with the same .config (I took the .config from 23.8, copied it into the 23.1 directory, and ran make oldconfig) does NOT exhibit any of these problems -- it resumes from suspend normally and everything still works. Steps to reproduce: Boot 2.6.23.8. Log in, start X, suspend, resume. Hold down the return key and observe no autorepeat (at least for a long time). echo ^G and hear the long bell. xorg.conf to test the trackpad part available upon request. I will attach my .configs from 23.1 and 23.8. I've tried with and without evdev, and with and without tickless, so neither of those is to blame. I wanted to try turning off the synaptic driver, but it seems to be a mandatory part of the PS/2 mouse driver now. I'm happy to try other configuration options. It's possible this is related to bug 7977, but that one is from 2.6.21 and is supposedly fixed now, and nobody there mentioned the keyboard or bell aspects. A regression in the -stable series. IT'd be interesting to see if this has gone into 2.6.24-rc5 too. - 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: suspend to RAM failure on t61p
On Tue, 11 Dec 2007 01:57:51 -0800 Andrew Morton [EMAIL PROTECTED] wrote: Now let me see what caused the keystrokes-no-longer-trigger-resume-from-RAM regression. OK, I must have dreamed this - 2.6.23 requires a power-button tap to come back from suspend-to-RAM as well. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9533] New: 2.6.24-rc4: some ahci/acpi interaction causes delays during boot
On Mon, 10 Dec 2007 05:55:20 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9533 Another box-killing regression to track, please. Either ATA or ACPI. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9533] New: 2.6.24-rc4: some ahci/acpi interaction causes delays during boot
On Mon, 10 Dec 2007 12:52:43 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Mon, 10 Dec 2007 05:55:20 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9533 Another box-killing regression to track, please. Either ATA or ACPI. er, no, not box-killing - just scary warnings. It's not clear what kernel doesn't get to userland yet is referring to - something else I guess. Your desire to avoid doing a bisection search is a good one - I've been trying to do one for a couple of days on and off and there are so many fatally buggy bisection points between 2.6.23 and 2.6.24-rc1 that I've given up on the attempt. - 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: suspend to RAM failure on t61p
On Mon, 10 Dec 2007 12:06:14 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 10 of December 2007, Andrew Morton wrote: On Mon, 10 Dec 2007 02:04:13 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 10 of December 2007, Andrew Morton wrote: On Sun, 09 Dec 2007 13:40:07 +0100 Tomas Carnecky [EMAIL PROTECTED] wrote: Andrew Morton wrote: 2.6.24-rc4 on a Lenovo t61p, using FC8 config. echo mem /sys/power/state while running X. It appears to suspend OK but then it instantly resumes and runs OK except the display is blank. http://bugzilla.kernel.org/show_bug.cgi?id=9258 I have a X61 tablet, and the screen is blank after resume, too, but pressing ctrl+alt+F1/F7 usually fixes it. It seems a problem with the X video driver. I'm not sure though. This machine doesn't bring the display back after resume-from-RAM under 2.6.23 either. The post-2.6.23 regresison here is that the suspend itself fails. Under 2.6.23 the machine suspends and requires a keystrike to start resuming. Under 2.6.24-rc4 it just instantly resumes all by itself. Please see if the appended patch helps (it will probably break the RTC wakeup again, but well ...). --- kernel/power/disk.c |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Index: linux-2.6/kernel/power/disk.c === --- linux-2.6.orig/kernel/power/disk.c +++ linux-2.6/kernel/power/disk.c @@ -378,9 +378,12 @@ int hibernation_platform_enter(void) return error; suspend_console(); - error = device_suspend(PMSG_SUSPEND); - if (error) - goto Resume_console; + /* + * FIXME: device_suspend(PMSG_SUSPEND) should be called here, but + * some EHCI controllers make boxes reboot instead of going into the + * S4 sleep state in that case. + */ + device_shutdown(); error = hibernation_ops-prepare(); if (error) Nope, the machine still instantly resumes after suspend-to-RAM. Sigh. I guess I need to git-bisect my cant-find-root-disk problem and then once that is fixed I can bisect this suspend-to-RAM-resumes-itself regression and the resume-from-disk-causes-reboot regression. Well, please try to revert the entire commit 9cd9a0058dd35268b24fa16795a92c800f4086d4 Hibernation: Enter platform hibernation state in a consistent way for the last one. Yes, reverting 9cd9a0058dd35268b24fa16795a92c800f4086d4 fixes the suspend-to-RAM problem: it now stays suspended. However it doens't resume on a keystroke like 2.6.23 does: I have to tap the power switch to make it resume. However reverting 9cd9a0058dd35268b24fa16795a92c800f4086d4 does not fix the machine-reboots-after-resume-from-disk regression. It gets to here: Attempting manual resume swsusp: Marking nosave pages: 0009d000 - 0010 swsusp: Basic memory bitmaps created Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Loading image data pages (52207 pages) ... done Read 208828 kbytes in 5.40 seconds (38.67 MB/s) Suspending console(s) then everything stops for five seconds then wham. This bug is present in 2.6.24-rc1 but I'm basically unable to bisect it because every bisection point (tried about four so far) hits fatal runtime errors: cant-find-/dev/root, an oops in ipv6, an oops in netfilter, etc. This is just a basic boot-it-on-fc8 test with RH's config and nothing works. The quality of code which people have been checking into the tree is just appalling and here we see the costs of that. I think I'll see if it's present in the last 2.6.23 -mm lineup: I know I can bisect that. Probably it won't be, given the way in which people like to jam vast amounts of new code into the merge window. Sigh. - 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: suspend to RAM failure on t61p
On Mon, 10 Dec 2007 22:21:56 -0800 Andrew Morton [EMAIL PROTECTED] wrote: However reverting 9cd9a0058dd35268b24fa16795a92c800f4086d4 does not fix the machine-reboots-after-resume-from-disk regression. It gets to here: Attempting manual resume swsusp: Marking nosave pages: 0009d000 - 0010 swsusp: Basic memory bitmaps created Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Loading image data pages (52207 pages) ... done Read 208828 kbytes in 5.40 seconds (38.67 MB/s) Suspending console(s) then everything stops for five seconds then wham. This bug is present in 2.6.24-rc1 but I'm basically unable to bisect it because every bisection point (tried about four so far) hits fatal runtime errors: cant-find-/dev/root, an oops in ipv6, an oops in netfilter, etc. This is just a basic boot-it-on-fc8 test with RH's config and nothing works. The quality of code which people have been checking into the tree is just appalling and here we see the costs of that. I think I'll see if it's present in the last 2.6.23 -mm lineup: I know I can bisect that. Probably it won't be, given the way in which people like to jam vast amounts of new code into the merge window. Under 2.6.23-mm1 on the t61p, echo disk /sys/power/state makes the screen go black then nothing at all happens for ten seconds and then the display comes back and it says: t61p:/home/akpm# echo disk /sys/power/state echo: write error: device or resource busy So I have to bisect that first. This really sucks. - 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
suspend to RAM failure on t61p
2.6.24-rc4 on a Lenovo t61p, using FC8 config. echo mem /sys/power/state while running X. It appears to suspend OK but then it instantly resumes and runs OK except the display is blank. A copy of /proc/acpi/dsdt is at http://userweb.kernel.org/~akpm/dsdt.t61p config: http://userweb.kernel.org/~akpm/config-t61p.txt dmesg: http://userweb.kernel.org/~akpm/dmesg-t61p.txt - 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: suspend to RAM failure on t61p
On Sun, 09 Dec 2007 13:40:07 +0100 Tomas Carnecky [EMAIL PROTECTED] wrote: Andrew Morton wrote: 2.6.24-rc4 on a Lenovo t61p, using FC8 config. echo mem /sys/power/state while running X. It appears to suspend OK but then it instantly resumes and runs OK except the display is blank. http://bugzilla.kernel.org/show_bug.cgi?id=9258 I have a X61 tablet, and the screen is blank after resume, too, but pressing ctrl+alt+F1/F7 usually fixes it. It seems a problem with the X video driver. I'm not sure though. This machine doesn't bring the display back after resume-from-RAM under 2.6.23 either. The post-2.6.23 regresison here is that the suspend itself fails. Under 2.6.23 the machine suspends and requires a keystrike to start resuming. Under 2.6.24-rc4 it just instantly resumes all by itself. And I'm having real problems working out why 2.6.23 and 2.6.24-rc4 work OK(ish) but anything in between won't boot: can't open /dev/root. Everything has scrolled off, no serial, no netconsole.. - 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: suspend to RAM failure on t61p
On Mon, 10 Dec 2007 02:04:13 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 10 of December 2007, Andrew Morton wrote: On Sun, 09 Dec 2007 13:40:07 +0100 Tomas Carnecky [EMAIL PROTECTED] wrote: Andrew Morton wrote: 2.6.24-rc4 on a Lenovo t61p, using FC8 config. echo mem /sys/power/state while running X. It appears to suspend OK but then it instantly resumes and runs OK except the display is blank. http://bugzilla.kernel.org/show_bug.cgi?id=9258 I have a X61 tablet, and the screen is blank after resume, too, but pressing ctrl+alt+F1/F7 usually fixes it. It seems a problem with the X video driver. I'm not sure though. This machine doesn't bring the display back after resume-from-RAM under 2.6.23 either. The post-2.6.23 regresison here is that the suspend itself fails. Under 2.6.23 the machine suspends and requires a keystrike to start resuming. Under 2.6.24-rc4 it just instantly resumes all by itself. Please see if the appended patch helps (it will probably break the RTC wakeup again, but well ...). --- kernel/power/disk.c |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Index: linux-2.6/kernel/power/disk.c === --- linux-2.6.orig/kernel/power/disk.c +++ linux-2.6/kernel/power/disk.c @@ -378,9 +378,12 @@ int hibernation_platform_enter(void) return error; suspend_console(); - error = device_suspend(PMSG_SUSPEND); - if (error) - goto Resume_console; + /* + * FIXME: device_suspend(PMSG_SUSPEND) should be called here, but + * some EHCI controllers make boxes reboot instead of going into the + * S4 sleep state in that case. + */ + device_shutdown(); error = hibernation_ops-prepare(); if (error) Nope, the machine still instantly resumes after suspend-to-RAM. Sigh. I guess I need to git-bisect my cant-find-root-disk problem and then once that is fixed I can bisect this suspend-to-RAM-resumes-itself regression and the resume-from-disk-causes-reboot regression. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr [EMAIL PROTECTED] wrote: Hi, On Sat, Dec 08, 2007 at 01:36:31AM -0800, Andrew Morton wrote: Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object Submitter : Hans de Bruin [EMAIL PROTECTED] References: http://bugzilla.kernel.org/show_bug.cgi?id=9320 Handled-By: Robert Moore [EMAIL PROTECTED] Tejun Heo [EMAIL PROTECTED] Fu Michael [EMAIL PROTECTED] Patch : A number of other people are seeing the same thing and Tejun is putting in a blacklist of machines which cannot use libata+acpi. That patch is not yet in any git tree which I pull. AFACIT the machines kepe working OK - there's just some nasty dmesg spew. If any machines _are_ breaking then this could cause real problems and I'd prefer that we either go for a whitelist or arrange to detect the condition and fall back to non-acpi ata. Does this report now win me the lucky draw, pretty please? ;) nah, you have to cc the acpi guys to get a prize ;) Lenco, could you please take a look? Andreas, please do separately report that WOL problem too.. Our list just reached 30. STD regression rc1 - rc234, suspend fails completely, recovering is pretty much useless since HDD is DEAD from this point on anyway. Managed to capture -rc2 suspend logging via still-alive ssh session. 2.6.24-rc1 suspend/resume log, successful (well, a couple seconds delay, most likely due to well-recovered AML failure): swsusp: Marking nosave pages: 0009f000 - 0010 swsusp: Basic memory bitmaps created Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Shrinking memory... done (0 pages freed) Freed 0 kbytes in 0.02 seconds (0.00 MB/s) Suspending console(s) hub 4-0:1.0: hub_suspend usb usb4: bus suspend ehci_hcd :00:10.3: suspend root hub hub 3-0:1.0: hub_suspend usb usb3: bus suspend usb usb3: suspend_rh hub 2-0:1.0: hub_suspend usb usb2: bus suspend usb usb2: suspend_rh hub 1-0:1.0: hub_suspend usb usb1: bus suspend usb usb1: suspend_rh sd 0:0:0:0: [sda] Synchronizing SCSI cache parport_pc 00:09: disabled serial 00:08: disabled serial 00:07: disabled ACPI: PCI interrupt for device :00:11.5 disabled ACPI handle has no context! ACPI: PCI interrupt for device :00:11.1 disabled ACPI: PCI interrupt for device :00:10.3 disabled ehci_hcd :00:10.3: -- PCI D3/wakeup uhci_hcd :00:10.2: uhci_suspend ACPI: PCI interrupt for device :00:10.2 disabled uhci_hcd :00:10.2: -- PCI D3 uhci_hcd :00:10.1: uhci_suspend ACPI: PCI interrupt for device :00:10.1 disabled uhci_hcd :00:10.1: -- PCI D3 uhci_hcd :00:10.0: uhci_suspend ACPI: PCI interrupt for device :00:10.0 disabled uhci_hcd :00:10.0: -- PCI D3 ACPI: PCI interrupt for device :00:0d.0 disabled ACPI handle has no context! ACPI: PCI interrupt for device :00:0c.0 disabled ACPI handle has no context! pci_set_power_state(): :00:00.0: state=3, current state=5 swsusp: critical section: swsusp: Need to copy 51195 pages Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. evxfevnt-0079 [00] enable: System is already in ACPI mode ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20 ACPI: PCI Interrupt Link [ALKB] BIOS reported IRQ 0, using IRQ 21 ACPI: PCI Interrupt Link [ALKC] BIOS reported IRQ 0, using IRQ 22 ACPI: PCI Interrupt Link [ALKD] BIOS reported IRQ 0, using IRQ 23 evxfevnt-0079 [00] enable: System is already in ACPI mode ACPI: Unable to turn cooling device [c180ff60] 'off' PCI: Setting latency timer of device :00:01.0 to 64 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[db14-db1407ff] Max Packet=[2048] IR/IT contexts=[4/8] ACPI: PCI Interrupt :00:0a.0[A] - GSI 18 (level, low) - IRQ 18 e100: eth-intel: e100_watchdog: link up, 100Mbps, full-duplex PM: Writing back config space on device :00:0d.0 at offset 1 (was 217, writing 213) ACPI: PCI Interrupt :00:0d.0[A] - GSI 19 (level, low) - IRQ 22 uhci_hcd :00:10.0: PCI D0, from previous PCI D3 ACPI: PCI Interrupt :00:10.0[A] - Link [ALKB] - GSI 21 (level, low) - IRQ 20 uhci_hcd :00:10.0: uhci_resume uhci_hcd :00:10.0: uhci_check_and_reset_hc: cmd = 0x uhci_hcd :00:10.0: Performing full reset usb usb1: root hub lost power or was reset usb usb1: suspend_rh uhci_hcd :00:10.1: PCI D0, from previous PCI D3 ACPI: PCI Interrupt :00:10.1[B] - Link [ALKB] - GSI 21 (level, low) - IRQ 20 uhci_hcd :00:10.1: uhci_resume uhci_hcd :00:10.1: uhci_check_and_reset_hc: cmd = 0x uhci_hcd :00:10.1: Performing full reset usb usb2: root hub lost power or was reset usb usb2
Re: BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Fri, 7 Dec 2007 17:53:47 -0500 Parag Warudkar [EMAIL PROTECTED] wrote: Got this on today's git (2.6.24-rc4) while compiling stuff - Looks like it is related to CpuIdle stuff. I chose CONFIG_CPU_IDLE for the first time so I don't know when this was introduced. This is on x86_32, SMP. BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3) EIP: 0060:[c0603e22] EFLAGS: 0202 CPU: 1 EIP is at _spin_lock_irqsave+0x16/0x27 EAX: c06b4110 EBX: 0001 ECX: f7873808 EDX: 0293 ESI: 0005 EDI: f7873808 EBP: ESP: f7829f10 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 8005003b CR2: 004f5960 CR3: 372c5000 CR4: 06d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 [c0438233] tick_broadcast_oneshot_control+0x10/0xda [c0437c82] tick_notify+0x1d4/0x2eb [c04281b4] get_next_timer_interrupt+0x143/0x1b4 [c0605819] notifier_call_chain+0x2a/0x47 [c04345a0] raw_notifier_call_chain+0x17/0x1a [c04378b7] clockevents_notify+0x19/0x4f [c0533cc3] acpi_idle_enter_simple+0x183/0x1d0 [c058cea3] cpuidle_idle_call+0x53/0x78 [c058ce50] cpuidle_idle_call+0x0/0x78 [c0402575] cpu_idle+0x97/0xb8 OK, thanks. Another one for the regression list, please. - 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: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree
On Fri, 30 Nov 2007 22:14:08 -0500 Mark Lord [EMAIL PROTECTED] wrote: latency. If your app cant take any latency, you should set those... and the side effect is that the kernel will not do long-latency C-states or P-state transitions.. .. I don't mind the cpufreq changing (actually, I want it to drop in cpugfreq to save power and keep the fan off), but the C-states just kill this app. semi-OT: I was finding that disabling cpufreq altogether on the Vaio speeds up `quilt push 1000' by a lot - around 30% iirc. There do seem to be some unsophisticated decisions in there and we're losing quite a bit of performance as a result. - 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: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree
On Fri, 30 Nov 2007 14:06:55 -0800 Pallipadi, Venkatesh [EMAIL PROTECTED] wrote: Please dont go off-list like this. I put Mark's original mailing list cc's back. I will have to Nack this. The reason max_cstate was initentionally removed due to couple of reasons: It broke userspace without any warning or migration period, afaict. 1) All in kernel users of max_cstate should rather be using pm_qos/latency interfaces. All such max_cstate usages must already be migrated. That code isn't merged. 2) Supporting max_cstate as a dynamic parameter cleanly is no longer possible in acpi/processor_idle.c as the C-state policy has moved to cpuidle instead. It can be done if it is needed. But, just below patch will not really work with cpuidle. Selecting max_cstate at boot time as a debug option still works without this patch. So, just this patch will not get back the functionality with cpuidle. Infact changing it at run time will have no effect. Question however is: Is there a real need to revive this parameter so that user can change max_cstate at run time? It is not known whether Mark is actually writing to this thing. Perhaps read-only permissions would be a suitable fix? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC
On Mon, 26 Nov 2007 14:39:43 -0500
Rik van Riel [EMAIL PROTECTED] wrote:
On Tue, 20 Nov 2007 22:18:39 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
..MP-BIOS bug: 8254 timer not connected to IO-APIC
Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the
'noapic' kernel parameter
ACPI or x86 breakage, I guess.
Did 'noapic' work?
I got the same bug as above, 'noapic' gets past that point
We still don't know what caused this, afaik.
and right to the
next oops. I'm posting it here because this one is different from the others
in the thread, yet looks vaguely related:
Unable to handle kernel NULL pointer dereference at 0021 RIP:
[8108382a] refresh_zone_stat_thresholds+0x6d/0x90
PGD 0
Oops: 0002 [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
RIP: 0010:[8108382a] [8108382a]
refresh_zone_stat_thresholds+0x6d/0x90
RSP: :81007fb59ec0 EFLAGS: 00010293
RAX: RBX: 0004 RCX: 0001
RDX: 0001 RSI: 8146fb38 RDI: 0001
RBP: 8100c000 R08: R09:
R10: 81007fb59e60 R11: 0028 R12: 814d4558
R13: R14: 814b62c0 R15:
FS: () GS:813d9000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 0021 CR3: 00201000 CR4: 06a0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper (pid: 1, threadinfo 81007FB58000, task 81007FB56000)
Stack: 814a3839
8148e626 81007fb56000 8126d36a
8105786b
Call Trace:
[814a3839] setup_vmstat+0x6/0x40
[8148e626] kernel_init+0x169/0x2d8
[8126d36a] trace_hardirqs_on_thunk+0x35/0x3a
[8105786b] trace_hardirqs_on+0x115/0x138
[8100ce48] child_rip+0xa/0x12
[8100c55f] restore_args+0x0/0x30
[8148e4bd] kernel_init+0x0/0x2d8
[8100ce3e] child_rip+0x0/0x12
INFO: lockdep is turned off.
hm. This smells like a startup ordering problem, but everything which
refresh_zone_stat_thresholds() should be set up by the time we run
initcalls. Maybe the zone lists are bad?
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC
On Mon, 26 Nov 2007 23:08:33 +0100 Jiri Slaby [EMAIL PROTECTED] wrote: On 11/26/2007 09:45 PM, Ingo Molnar wrote: * Andrew Morton [EMAIL PROTECTED] wrote: On Mon, 26 Nov 2007 14:39:43 -0500 Rik van Riel [EMAIL PROTECTED] wrote: On Tue, 20 Nov 2007 22:18:39 -0800 Andrew Morton [EMAIL PROTECTED] wrote: ..MP-BIOS bug: 8254 timer not connected to IO-APIC Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter ACPI or x86 breakage, I guess. Did 'noapic' work? I got the same bug as above, 'noapic' gets past that point We still don't know what caused this, afaik. yes. Is it a regression? If yes, could someone try to bisect it so that we can fix it? If it's caused by x86.git then the 'mm' branch of the x86 git tree can be used for bisection: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git I did, but it's hard, if you don't know the BAD point. HEAD boots fine and 'x86: randomize brk' too (the top of git-x86.patch). So the bug wasn't in git-x86 in 2.6.24-rc3-mm1. But it might be in there now, as some patches got moved over. Or it could be git-acpi. Or lots of other things. Andrew, how do you pull it, git #mm doesn't fit to the ids from the patch. The -mm git tree reimports the plain git-foo.patch files back into a new git tree, so the commit IDs won't line up. The way to find the culprit patch in 2.6.24-rc3-mm1 is http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt. It will be quite quick. Maybe if you can emit a broken-out with the fresh pull to test? http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't compile. I'd suggest bisecting 2.6.24-rc3-mm1 would be easier. - 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] Fix segfault when printing battery status
On Mon, 19 Nov 2007 14:09:51 +0300 Alexey Starikovskiy [EMAIL PROTECTED] wrote: Rolf Eike Beer wrote: Alexey Starikovskiy wrote: Rolf Eike Beer wrote: cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:19/PNP0C0A:00/power_ supply/BAT1/status This leads to a stacktrace as acpi_battery_get_property() returns 0 for a case where it does not set val-intval. These value is used as an array index in drivers/power/power_supply_sysfs.c::power_supply_show_property(). I had a situation where the value was 4096 which caused a problem as the array only has 5 entries. Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED] Rolf, thanks for remainding. Huh? This one is unrelated to the problem I reported two weeks ago... Eike You are second to send the same patch, first one I already acked. But it seems that Len did not pick it up yet. Look for ACPI: Always return valid 'status' from acpi_battery_get_property() if interested... This fix is in Len's tree and was in his 2.6.24-rc3 pull request to Linus. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC
On Wed, 21 Nov 2007 14:52:26 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi Andrew, Kernel panic's across different architectures like powerpc, x86_64, powerpc complains about IO-APICs?? Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes) Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes) Mount-cache hash table entries: 256 SMP alternatives: switching to UP code ACPI: Core revision 20070126 ..MP-BIOS bug: 8254 timer not connected to IO-APIC Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter ACPI or x86 breakage, I guess. Did 'noapic' work? Hi Andrew, Passing noapic works, OK. but the kernel oops's [ 97.161103] Unable to handle kernel NULL pointer dereference at 0009 RIP: [ 97.193973] [802341df] cpu_to_allnodes_group+0x69/0x7c [ 97.245359] PGD 0 [ 97.257611] Oops: [1] SMP [ 97.276638] last sysfs file: [ 97.294417] CPU 0 [ 97.306620] Modules linked in: [ 97.325066] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #1 [ 97.360514] RIP: 0010:[802341df] [802341df] cpu_to_allnodes_group+0x69/0x7c [ 97.413287] RSP: :81012fabb650 EFLAGS: 00010286 [ 97.445363] RAX: 809bb060 RBX: 81012fabb650 RCX: 00ff [ 97.488378] RDX: 0001 RSI: 013e RDI: 0100 [ 97.531413] RBP: 81012fabb680 R08: 81012fa88180 R09: [ 97.574428] R10: R11: R12: 810001005f50 [ 97.617394] R13: R14: 81012fa88180 R15: 810001005f40 [ 97.660421] FS: () GS:806c3000() knlGS: [ 97.709327] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [ 97.743995] CR2: 0009 CR3: 00201000 CR4: 06a0 [ 97.787021] DR0: DR1: DR2: [ 97.830053] DR3: DR6: 0ff0 DR7: 0400 [ 97.873036] Process swapper (pid: 1, threadinfo 81012FABA000, task 81012FAB8040) [ 97.921993] Stack: [ 97.971056] 810001005f40 81012fabb700 81012fabbdf0 80235487 [ 98.016420] [ 98.060324] Call Trace: [ 98.076657] [80235487] build_sched_domains+0x1e1/0xc19 [ 98.113383] [8025072a] __kernel_text_address+0x22/0x30 [ 98.150173] [8025b127] check_chain_key+0x9c/0x15f [ 98.184355] [8025d544] mark_lock+0x3b/0x5b3 [ 98.215406] [8025db06] mark_held_locks+0x4a/0x6a [ 98.249027] [80284f4a] get_page_from_freelist+0x42a/0x77d [ 98.287362] [8025dda1] trace_hardirqs_on+0x198/0x1c3 [ 98.323123] [8028527a] get_page_from_freelist+0x75a/0x77d [ 98.361429] [8025d544] mark_lock+0x3b/0x5b3 [ 98.392427] [8025b127] check_chain_key+0x9c/0x15f [ 98.426621] [8034d01a] number+0x115/0x21f [ 98.456594] [8025072a] __kernel_text_address+0x22/0x30 [ 98.493362] [8020d80c] dump_trace+0x248/0x25d [ 98.525493] [8025b127] check_chain_key+0x9c/0x15f [ 98.559678] [8025f03f] __lock_acquire+0xdee/0xf06 [ 98.593868] [8025b127] check_chain_key+0x9c/0x15f [ 98.628038] [8025b127] check_chain_key+0x9c/0x15f [ 98.662225] [8025b127] check_chain_key+0x9c/0x15f [ 98.696370] [8025f03f] __lock_acquire+0xdee/0xf06 [ 98.730563] [8025b127] check_chain_key+0x9c/0x15f [ 98.764689] [8025d544] mark_lock+0x3b/0x5b3 [ 98.795767] [8025db06] mark_held_locks+0x4a/0x6a [ 98.829432] [8034d01a] number+0x115/0x21f [ 98.859460] [804ca267] kprobe_flush_task+0x63/0xa9 [ 98.894166] [8034ddbd] vsnprintf+0x58f/0x5d5 [ 98.925739] [8034de6b] sprintf+0x68/0x6a [ 98.955257] [8025f1c9] lock_acquire+0x72/0xe0 [ 98.987363] [8025ca45] lock_acquired+0x57/0x1d4 [ 99.020446] [8025f430] lock_release+0x67/0x21a [ 99.053079] [8025b127] check_chain_key+0x9c/0x15f [ 99.087261] [8025d544] mark_lock+0x3b/0x5b3 [ 99.118328] [8025d544] mark_lock+0x3b/0x5b3 [ 99.149394] [80236330] arch_init_sched_domains+0x27/0x69 [ 99.187217] [802a5a5f] dbg_redzone2+0x2a/0x52 [ 99.219320] [802a656b] cache_alloc_debugcheck_after+0x16e/0x1cb [ 99.260779] [802a8083] kmem_cache_alloc+0x15e/0x182 [ 99.295944] [80236365] arch_init_sched_domains+0x5c/0x69 [ 99.333768] [8098e501] sched_init_smp+0x27/0x113
Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC
On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi Andrew, Kernel panic's across different architectures like powerpc, x86_64, powerpc complains about IO-APICs?? Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes) Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes) Mount-cache hash table entries: 256 SMP alternatives: switching to UP code ACPI: Core revision 20070126 ..MP-BIOS bug: 8254 timer not connected to IO-APIC Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter ACPI or x86 breakage, I guess. Did 'noapic' work? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9398] New: BUG: soft lockup detected on CPU#0!
(switched to email. Please reply via emailed reply-to-all, not via the bugzilla web interface). On Fri, 16 Nov 2007 14:56:13 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9398 Summary: BUG: soft lockup detected on CPU#0! Product: Other Version: 2.5 KernelVersion: 2.6.23.8 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: 2.6.23.0 Ow. Are you sure? This is a regression which was added into the 2.6.23 stable tree? Distribution: Debian stable Hardware Environment: Pentium M laptop Software Environment: Debian stable Problem Description: Steps to reproduce: i2c-adapter i2c-5: SMBus Quick command not supported, can't probe for chips i2c-adapter i2c-6: SMBus Quick command not supported, can't probe for chips pcmcia: Detected deprecated PCMCIA ioctl usage from process: discover. pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. eth0: link down ieee80211_crypt: registered algorithm 'TKIP' BUG: soft lockup detected on CPU#0! [c0140bf4] softlockup_tick+0x90/0xaf [c0120a17] update_process_times+0x32/0x54 [c012edfd] tick_periodic+0x6e/0x78 [c012ee16] tick_handle_periodic+0xf/0x5d [c0126390] insert_work+0x59/0x5c [c012ef3c] tick_do_broadcast+0x1f/0x3f [c012f05a] tick_do_periodic_broadcast+0x1a/0x31 [c012f08c] tick_handle_periodic_broadcast+0x1b/0x5b [c01272fb] __rcu_process_callbacks+0x112/0x170 [c0106e83] timer_interrupt+0x34/0x3d [c0140e66] handle_IRQ_event+0x1a/0x3f [c01420df] handle_level_irq+0x77/0xd0 [c01061c5] do_IRQ+0x75/0x8c [c0220d76] acpi_hw_register_write+0x11b/0x14b [c0104713] common_interrupt+0x23/0x28 [c011] mc_sysdev_remove+0x2b/0x4b [c0232ddf] acpi_processor_idle+0x22f/0x398 [c0102344] cpu_idle+0x43/0x71 [c03d29de] start_kernel+0x250/0x255 [c03d2317] unknown_bootoption+0x0/0x195 === Looks like acpi_hw_register_write() has locked up. Or someone is continuously calling acpi_hw_register_write(). I assume that the mc_sysdev_remove() in there is just stack garbage. To confirm this could you please set CONFIG_MICROCODE=n and retest? Also, it would be interesting to test whether we have introduced this bug into 2.6.24-rc2 (or -rc3, if it's out). Thanks. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc1: OOPS at acpi_battery_update
On Tue, 13 Nov 2007 11:35:18 +0300 Alexey Starikovskiy [EMAIL PROTECTED] wrote: I can not contact with Len for several days, while the oops on battery seems quite important. It also seem to behave well in -mm tree (as part of Len's acpi-test). Will you send this patch to Linus without approval from Len or should I? Please send it yourself - your latest version seems a little different from the one in git-acpi and I'd just be dangerous trying to work out which one is needed. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9334] New: Kernel 2.6.22 computer turn off
On Thu, 8 Nov 2007 23:12:18 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9334 Summary: Kernel 2.6.22 computer turn off Product: Other Version: 2.5 KernelVersion: 2.6.22 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: Distribution: Debian 4.0 Lenny Hardware Environment: Celeron 2,8 GHz. Mainboard Asrock with socket 478 and Via chipset. It is model P4VM890. Quite new. I have case from one of Fujitsu Siemens models and it has not restart button. So it is not connected. Hard Disk WD 120 GB SATA. Software Environment: Debian 4.0 Lenny Problem Description: I tried to use kernel 2.6.22. It is the last version from testing Lenny. When I stop my computer, it looks like some restart. It stops and after 1 second it begins to start again. After 1 second it stops definitely. It is unpleasant. I have tried 2.6.23 kernel from trunk and it does the same error. By 2.6.18 kernel from ETch it is all right. Steps to reproduce: I sent info to kernel packager and he wrote, it is a kernel bug and not package problem. fwiw, a Nocona machine whcih Intel sent me started doing this about 1.5 years ago. It used to shut down OK, but now it turns on again five seconds later. Suspicions have been raised about wake-on-LAN hardware remaining permanently asserted or something like that, but it is unknown why it used to work then stopped. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc1: OOPS at acpi_battery_update
On Fri, 09 Nov 2007 12:36:43 +0300 Alexey Starikovskiy [EMAIL PROTECTED] wrote: Andrew Morton wrote: A On Thu, 08 Nov 2007 19:35:23 +0300 Alexey Starikovskiy [EMAIL PROTECTED] wrote: [remove_cycle_at_battery_removal.patch text/x-patch (1.7KB)] ACPI: Battery: remove cycle from battery removal. From: Alexey Starikovskiy [EMAIL PROTECTED] get_property() should not call battery_update() on absent battery to avoid cycle and oops. Signed-off-by: Alexey Starikovskiy [EMAIL PROTECTED] Tested-by: Rolf Eike Beer [EMAIL PROTECTED] A patch similar to this one but with an identical changelog was merged into Len's tree on November 2. If it had been promptly merged into mainline then quite a lot of people's time would not have been wasted. Andrew, should I send such patches directly to you/Linus? Well if Len doesn't object and you're confident in the changes, why not? Any time we leave bugs unfixed we drive away testers and that impacts all parts of the kernel. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc1 and 2.6.24.rc2 hangs while running udev on my laptop
(cc's added) On Fri, 9 Nov 2007 09:47:02 +0100 SANGOI DINO LEONARDO [EMAIL PROTECTED] wrote: Hi, My laptop (an HP nx6125) doesn't boot with kernels 2.6.24-rc1 and 2.6.24.rc2. It works fine with 2.6.23 and older. I seen this bug first while running fedora rawhide, so you can find hardware info and boot logs at https://bugzilla.redhat.com/show_bug.cgi?id=312201. I did a git bisect, and got this: $ git bisect bad 4f86d3a8e297205780cca027e974fd5f81064780 is first bad commit commit 4f86d3a8e297205780cca027e974fd5f81064780 Author: Len Brown [EMAIL PROTECTED] Date: Wed Oct 3 18:58:00 2007 -0400 cpuidle: consolidate 2.6.22 cpuidle branch into one patch [SNIP full commit log] :04 04 fadedf003c64838a73d172d6b7c0046d88dedd5e ebb8a32b3bc49d731c13f2812148ae553bc1a533 March :04 04 039a15fe07324bb0481eb1006571f6523c56c254 e3251f5abcc19417472488f523da968e37698ddd Mdrivers :04 04 89a350e5adc6dfd82adbb9c2f327557cd7a95334 14c738510d6c772e9a8db4bc494ce8fb3434a5fb Minclude :04 04 e1d33c4a2558da0fb68f7e98145abf69e885ba94 7987a9110d0749aa7442a3f4c8c6c7d7a3df9426 Mkernel $ git bisect log git-bisect start # bad: [b4f555081fdd27d13e6ff39d455d5aefae9d2c0c] Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block git-bisect bad b4f555081fdd27d13e6ff39d455d5aefae9d2c0c # good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23 git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1 # good: [1f06862e11f23ebc99438c592be9c92560d78548] rt2x00: Add new rt73usb USB ID git-bisect good 1f06862e11f23ebc99438c592be9c92560d78548 # good: [2c6221483169ddd4c04797cd7296ed4fe52fcdd7] Fix discrepancy between VDSO based gettimeofday() and sys_gettimeofday(). git-bisect good 2c6221483169ddd4c04797cd7296ed4fe52fcdd7 # bad: [56d61a0e26c5a61c66d1ac259a59960295939da9] Merge branch 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6 git-bisect bad 56d61a0e26c5a61c66d1ac259a59960295939da9 # good: [ec2626815bf9a9922e49820b03e670e833f3ca3c] Merge git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched git-bisect good ec2626815bf9a9922e49820b03e670e833f3ca3c # bad: [c00046c279a2521075250fad682ca0acc10d4fd7] Merge git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial git-bisect bad c00046c279a2521075250fad682ca0acc10d4fd7 # bad: [e9a404580ccaeb31dd2a976f9929c4f9eb6f3540] nfs: Fix build break with CONFIG_NFS_V4=n git-bisect bad e9a404580ccaeb31dd2a976f9929c4f9eb6f3540 # bad: [4800be295c34268fd3211d49828bfaa6bf62867f] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild git-bisect bad 4800be295c34268fd3211d49828bfaa6bf62867f # good: [a2883dfa2e4a94b24109b2bfe735561e50cc44b4] Pull thermal into release branch git-bisect good a2883dfa2e4a94b24109b2bfe735561e50cc44b4 # good: [731aa5fd9971a5163845fbe55de63d686a11da0a] Pull bugzilla-8709 into release branch git-bisect good 731aa5fd9971a5163845fbe55de63d686a11da0a # good: [910b40468a9ce3f2f5d48c5d260329c27d45adb5] kbuild: introduce cc-cross-prefix git-bisect good 910b40468a9ce3f2f5d48c5d260329c27d45adb5 # bad: [00a2b433557f10736e8a02de619b3e9052556c12] Pull acpica into test branch git-bisect bad 00a2b433557f10736e8a02de619b3e9052556c12 # bad: [de85871a9a53c00cae4c3a70849b5eaad0eb38b2] Pull cpuidle into test branch git-bisect bad de85871a9a53c00cae4c3a70849b5eaad0eb38b2 # bad: [e196441bdf2dbf0526b28a6829c39557c236d611] ACPI: cpuidle: port idle timer suspend/resume workaround to cpuidle git-bisect bad e196441bdf2dbf0526b28a6829c39557c236d611 # bad: [4f86d3a8e297205780cca027e974fd5f81064780] cpuidle: consolidate 2.6.22 cpuidle branch into one patch git-bisect bad 4f86d3a8e297205780cca027e974fd5f81064780 Config is taken from Fedora kernel. CONFIG_CPU_IDLE is set to y (tell me if full config is needed). If I use 'nolapic' parameter, kernel 2.6.24-rc1 boots fine. Setting CONFIG_CPU_IDLE=n also gives me a working kernel. Ask me if more info is needed (please CC me). Thanks, Dino - 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] ACPI: Cleanup linux/acpi.h
On Wed, 7 Nov 2007 14:20:56 +0100
Jean Delvare [EMAIL PROTECTED] wrote:
Two cleanups to linux/acpi.h:
* Stop defining acpi_mp_config, it isn't used anywhere.
* Discard nested #ifdef CONFIG_ACPI, they are useless and
error-prone.
It's not a good time to be doing not-strictly-needed cleanup patches
in there.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
Len, Andrew, this cleanup should go before the patches sent by
Thomas Renninger. I'll send updated patches in a moment so that
we no longer break the build for CONFIG_ACPI=n.
I'm quite confused. I have the following acpi-affecting patches for this
work:
small-acpica-extension-to-be-able-to-store-the-name-of.patch
small-acpica-extension-to-be-able-to-store-the-name-of-fix.patch
export-acpi_check_resource_conflict.patch
export-acpi_check_resource_conflict-fix.patch
mm-only-enforce-acpi-resource-conflict-checks.patch
But now I see two new patches called
Subject: [PATCH] Provide acpi_check_{mem_}region (update)
Subject: [PATCH] ACPI: Export acpi_check_resource_conflict() (update #2)
checks
OK, the first is a renamed version of
small-acpica-extension-to-be-able-to-store-the-name-of.patch, perhaps of
small-acpica-extension-to-be-able-to-store-the-name-of.patch+small-acpica-extension-to-be-able-to-store-the-name-of-fix.patch.
I guess I need to dive into the diffs to find out whether the fix got lost
or not.
Please don't rename patches.
looks more
OK, afacit all we've done here is added this cleanup patch and then churned
all the other patches on top of it. After fixing rejects in the
now-combined
small-acpica-extension-to-be-able-to-store-the-name-of.patch+small-acpica-extension-to-be-able-to-store-the-name-of-fix.patch
I didn't need Provide acpi_check_{mem_}region (update) and ACPI: Export
acpi_check_resource_conflict() (update #2) is just a little cleanup.
-
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: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)
On Thu, 8 Nov 2007 13:02:56 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 09:49:58AM -0800, Andrew Morton wrote: On Thu, 08 Nov 2007 17:43:59 +0100 Roberto Oppedisano [EMAIL PROTECTED] wrote: Andrew Morton wrote, On 11/07/2007 09:13 PM: On Wed, 07 Nov 2007 15:15:07 +0100 Roberto Oppedisano [EMAIL PROTECTED] wrote: Hello. I noticed that after suspending to ram the DVD-ROM/CDRW drive in no more recognized on my laptop. Looking at dmesg after suspend i found: [5.313446] ata2.00: _GTF unexpected object type 0x1 [5.313453] ata2.00: ACPI on devcfg failed the second time, disabling (errno=-22) [5.313457] ata2.00: revalidation failed (errno=1) [5.313459] ata2.00: disabled Not sure when the bug was introduced or if it has been always been there (but I can investigate if needed). More details on request. Following dmesg pre and after suspend. Yes, it would be useful if you could work ot whether this worked OK in an earlier kernel, thanks. Hello Andrew. The bug has been recently added. I did a git-bisect, but the result is probably not completely useful, because many kernel did non build with my config, and I marked them as bad. Those build errors are bad. Please report them. They directly prevented you from finding the commit which caused this regression. The only way in which we'll stop people doing crap like this is to rub their noses (and the person who committed its nose) in it. Anyway here's the output of git-bisect: [EMAIL PROTECTED]:/usr/src/linux-2.6$ git bisect bad 99874d50481c093adfe74e796436024d88b6a48c is first bad commit commit 99874d50481c093adfe74e796436024d88b6a48c Author: Jens Axboe [EMAIL PROTECTED] Date: Fri Oct 12 12:50:41 2007 +0200 [BLOCK] Only include the compat ioctl code if CONFIG_BLOCK is set Add an extra CONFIG_BLOCK_COMPAT that we can use in the Makefile Signed-off-by: Jens Axboe [EMAIL PROTECTED] :04 04 f88b7b0e496edb8fbdd4bc74abd1a742a6a1d6d9 32ead3bd57b52a664cc8ccb662195041868d7632 M block ... If needed I can do further investigation, changing the assumption of efefc6eb38d43b8e5daef482f575d767b002004e to good and see if the bisect points to a different commit. Yes, it'll be some other commit. Sorry. It would help you (and me) if an ata developer could pay some attention. Rafael, please track this as an ata regression. We unfortunately need to bounce this ACPI people. We recently turned on ACPI by default in libata, which INTRODUCES the ability of the BIOS to pass random, unknown-quality ATA commands to the device. I highly expect some breakage related to this... if ACPI folks determine it is not an ACPI bug, then its a firmware bug and we will have to avoid that firmware on that platform. Set module option noacpi to 1, to disable ACPI and see if that fixes the problem. This will be a common diagnosis and workaround, FWIW... I suspect it wold be best to disable the feature for the 2.6.24 release, then reenable it afterwards and keep doing this until the code is sufficiently stable. - 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: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)
On Thu, 8 Nov 2007 13:19:05 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 10:13:41AM -0800, Andrew Morton wrote: On Thu, 8 Nov 2007 13:02:56 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 09:49:58AM -0800, Andrew Morton wrote: On Thu, 08 Nov 2007 17:43:59 +0100 Roberto Oppedisano [EMAIL PROTECTED] wrote: Andrew Morton wrote, On 11/07/2007 09:13 PM: On Wed, 07 Nov 2007 15:15:07 +0100 Roberto Oppedisano [EMAIL PROTECTED] wrote: Hello. I noticed that after suspending to ram the DVD-ROM/CDRW drive in no more recognized on my laptop. Looking at dmesg after suspend i found: [5.313446] ata2.00: _GTF unexpected object type 0x1 [5.313453] ata2.00: ACPI on devcfg failed the second time, disabling (errno=-22) [5.313457] ata2.00: revalidation failed (errno=1) [5.313459] ata2.00: disabled Not sure when the bug was introduced or if it has been always been there (but I can investigate if needed). More details on request. Following dmesg pre and after suspend. Yes, it would be useful if you could work ot whether this worked OK in an earlier kernel, thanks. Hello Andrew. The bug has been recently added. I did a git-bisect, but the result is probably not completely useful, because many kernel did non build with my config, and I marked them as bad. Those build errors are bad. Please report them. They directly prevented you from finding the commit which caused this regression. The only way in which we'll stop people doing crap like this is to rub their noses (and the person who committed its nose) in it. Anyway here's the output of git-bisect: [EMAIL PROTECTED]:/usr/src/linux-2.6$ git bisect bad 99874d50481c093adfe74e796436024d88b6a48c is first bad commit commit 99874d50481c093adfe74e796436024d88b6a48c Author: Jens Axboe [EMAIL PROTECTED] Date: Fri Oct 12 12:50:41 2007 +0200 [BLOCK] Only include the compat ioctl code if CONFIG_BLOCK is set Add an extra CONFIG_BLOCK_COMPAT that we can use in the Makefile Signed-off-by: Jens Axboe [EMAIL PROTECTED] :04 04 f88b7b0e496edb8fbdd4bc74abd1a742a6a1d6d9 32ead3bd57b52a664cc8ccb662195041868d7632 M block ... If needed I can do further investigation, changing the assumption of efefc6eb38d43b8e5daef482f575d767b002004e to good and see if the bisect points to a different commit. Yes, it'll be some other commit. Sorry. It would help you (and me) if an ata developer could pay some attention. Rafael, please track this as an ata regression. We unfortunately need to bounce this ACPI people. We recently turned on ACPI by default in libata, which INTRODUCES the ability of the BIOS to pass random, unknown-quality ATA commands to the device. I highly expect some breakage related to this... if ACPI folks determine it is not an ACPI bug, then its a firmware bug and we will have to avoid that firmware on that platform. Set module option noacpi to 1, to disable ACPI and see if that fixes the problem. This will be a common diagnosis and workaround, FWIW... I suspect it wold be best to disable the feature for the 2.6.24 release, then reenable it afterwards and keep doing this until the code is sufficiently stable. Re-read my message :) The code is stable. Behavior _by definition_ will vary by BIOS. This feature (a) enables suspend/resume, but (b) now sends random unvalidated shite to the device that we hope will work. Look at all the messages where turning on ACPI in libata _fixed_ suspend/resume (because its obviously required for many, including laptops). We fixed a somewhat-known number of machines and broke an unknown number. Linus will come after you with a pointy stick if he finds out. Fixing previously-broken machines is nice, but breaking previously-working ones gets people a lot more upset. So it's not an easy turn it off answer, you break shitloads of suspend/resume that way, that we just fixed. The message _GTF unexpected object type indicates a broken BIOS, so IMO we should proceed in that direction, blacklisting that platform. Suggest that the feature be disabled until we have most of these blacklistings in place. We have a tremendous number of regressions in 2.6.24 (and they're just the ones which we know of) and the regression reports for 2.6.23 are still coming in. At some stage we'll need to get seriosu about this. - 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: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)
On Thu, 08 Nov 2007 14:49:33 -0500 Mark Lord [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Thu, 8 Nov 2007 13:19:05 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 10:13:41AM -0800, Andrew Morton wrote: On Thu, 8 Nov 2007 13:02:56 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 09:49:58AM -0800, Andrew Morton wrote: .. I suspect it wold be best to disable the feature for the 2.6.24 release, then reenable it afterwards and keep doing this until the code is sufficiently stable. Re-read my message :) The code is stable. Behavior _by definition_ will vary by BIOS. This feature (a) enables suspend/resume, but (b) now sends random unvalidated shite to the device that we hope will work. Look at all the messages where turning on ACPI in libata _fixed_ suspend/resume (because its obviously required for many, including laptops). We fixed a somewhat-known number of machines and broke an unknown number. Linus will come after you with a pointy stick if he finds out. Fixing previously-broken machines is nice, but breaking previously-working ones gets people a lot more upset. So it's not an easy turn it off answer, you break shitloads of suspend/resume that way, that we just fixed. The message _GTF unexpected object type indicates a broken BIOS, so IMO we should proceed in that direction, blacklisting that platform. Suggest that the feature be disabled until we have most of these blacklistings in place. .. The problem is, this code has already sat out the last release, and nobody noticed problems exactly because it was not enabled before. If Jeff disables it again, then it will sit out another cycle without anybody exercising it. At some point, we need to turn it on, and collect information about where there are problems (and fix them). We get a decent amount of testing during the -rc's. I think it's OK to turn a feature on during -rc and off for release while it gets settled in. Hopefully Matthew's fix will address this particular problem. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc1: OOPS at acpi_battery_update
A On Thu, 08 Nov 2007 19:35:23 +0300 Alexey Starikovskiy [EMAIL PROTECTED] wrote: [remove_cycle_at_battery_removal.patch text/x-patch (1.7KB)] ACPI: Battery: remove cycle from battery removal. From: Alexey Starikovskiy [EMAIL PROTECTED] get_property() should not call battery_update() on absent battery to avoid cycle and oops. Signed-off-by: Alexey Starikovskiy [EMAIL PROTECTED] Tested-by: Rolf Eike Beer [EMAIL PROTECTED] A patch similar to this one but with an identical changelog was merged into Len's tree on November 2. If it had been promptly merged into mainline then quite a lot of people's time would not have been wasted. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9320] New: PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object
On Wed, 7 Nov 2007 13:35:00 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9320 Summary: PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object Product: ACPI Version: 2.5 KernelVersion: Linux version 2.6.24-rc2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: I rebuild daily, if rebuild script does not fail. The last errorless boot was on october 29. The first boot after this was october 31 Distribution: slack Hardware Environment: VIA C7, CN700 IDE interface: VT82C586A/B/VT82C686/A/B/VT823x/A/C Diskless PXE boot Software Environment: Problem Description: dmesg: ata3: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf900 irq 14 ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf908 irq 15 ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0) is beyond end of object [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.GTM_] (Node c1c0b420), AE_AML_PACKAGE_LIMIT ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.CHN0._GTM] (Node c1c0b228), AE_AML_PACKAGE_LIMIT ata3: ACPI get timing mode failed (AE 0x300d) ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0) is beyond end of object [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.GTM_] (Node c1c0b420), AE_AML_PACKAGE_LIMIT ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.CHN1._GTM] (Node c1c0b330), AE_AML_PACKAGE_LIMIT ata4: ACPI get timing mode failed (AE 0x300d) Seems to be another post-2.6.23 regression. Is it an acpi thing or an ata thing, of just something which the new acpi+ata stuff exposed?? - 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 1/5] Small ACPICA extension to be able to store the name of operation regions in osl.c later
this patch introduces a compile error: drivers/acpi/osl.c:1203: error: conflicting types for 'acpi_os_validate_address' include/acpi/acpiosxf.h:243: error: previous declaration of 'acpi_os_validate_address' was here which the next patch fixes. This breaks git-bisection and will cause great gnashing of teeth to those who hit it. Also, please fix this: drivers/acpi/osl.c: In function 'acpi_os_validate_address': drivers/acpi/osl.c:1365: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'long unsigned int' drivers/acpi/osl.c:1365: warning: format '%s' expects type 'char *', but argument 5 has type 'long unsigned int' it's all covered in Documentation/SubmitChecklist but it seems that file was write-only. goes back to fixing build errors - 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] x86: check boundary in count/setup_resource called by get_current_resources
On Thu, 01 Nov 2007 01:20:29 -0700 Yinghai Lu [EMAIL PROTECTED] wrote: [PATCH] x86: check boundary in count/setup_resource called by get_current_resources need to check info-res_num less than PCI_BUS_NUM_RESOURCES, so info-bus-resource[info-res_num] = res will not beyond of bus resource array when acpi resutrn too many resource entries. Isn't this a bit of a problem? It sounds like PCI_BUS_NUM_RESOURCES is to small for that system? If so, some sort of dynamic allocation might be needed. Index: linux-2.6/arch/x86/pci/acpi.c === --- linux-2.6.orig/arch/x86/pci/acpi.c +++ linux-2.6/arch/x86/pci/acpi.c @@ -77,9 +77,13 @@ count_resource(struct acpi_resource *acp struct acpi_resource_address64 addr; acpi_status status; + if (info-res_num = PCI_BUS_NUM_RESOURCES) + return AE_OK; + status = resource_to_addr(acpi_res, addr); if (ACPI_SUCCESS(status)) info-res_num++; + return AE_OK; } grump. I don't know why people like a blank line before `return': it's just a waste of screen space. And the surrounding code in arch/x86/pci/acpi.c doesn't do this either. @@ -93,6 +97,9 @@ setup_resource(struct acpi_resource *acp unsigned long flags; struct resource *root; + if (info-res_num = PCI_BUS_NUM_RESOURCES) + return AE_OK; And should we really be silently ignoring this problem? Should we at least report it? status = resource_to_addr(acpi_res, addr); if (!ACPI_SUCCESS(status)) return AE_OK; - 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: [PATCH 3/5] Export acpi_check_resource_conflict]
On Wed, 24 Oct 2007 16:33:07 +0200 Thomas Renninger [EMAIL PROTECTED] wrote: From: Thomas Renninger [EMAIL PROTECTED] To: linux-acpi linux-acpi@vger.kernel.org Cc: linux-kernel [EMAIL PROTECTED], Len Brown [EMAIL PROTECTED], Andrew Morton [EMAIL PROTECTED], Jean Delvare [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: [Fwd: [PATCH 3/5] Export acpi_check_resource_conflict] Date: Wed, 24 Oct 2007 16:33:07 +0200 Organization: Novell/SUSE X-Mailer: Evolution 2.8.2 Export acpi_check_resource_conflict(), sometimes drivers already have a struct resource at hand so no need to use the wrappers to build a new one. Signed-off-by: Jean Delvare [EMAIL PROTECTED] --- The attributions on this are all mucked up. I _think_ it was written by Jean, in which case the changlog should have had From:him right at the start to indicate this. And as you were in the delivery path, it should have had your signoff. I'll make those changes - please let me know if I misguessed. - 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 0/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources
On Wed, 24 Oct 2007 16:31:59 +0200 Thomas Renninger [EMAIL PROTECTED] wrote: it seems Len's test tree and Linus tree diverged a bit, at least with this patch set things do not apply cleanly. Therefore I post these for discussion whether and in which kernel tree they should end up before doing work for nothing. If they are still a candidate for 2.6.24 (rather unintrusive), pls tell me whether and when I should base them against Len's test/release branch or whatever other tree. If not, it would be great if they can be included into the -mm tree and I can rebase them against this one. I staged the three acpi patches against Len's tree and I staged the hwmon patch against Mark's tree and I staged the I2C patch against Jean's tree. This means that if/when the ACPI patches have gone me-Len-Linus, I can send the I2C patch to Jean and the hwmon patch to Mark and we're all good. - 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: Fix to All wake-up devices are disabled after suspend-to disk isn't yet included in mainline
On Wed, 17 Oct 2007 04:39:30 +0200 Maxim Levitsky [EMAIL PROTECTED] wrote: A while ago I asked on LKML about the problem of loosing all wake device capabilities, after a suspend to disk (eg: I can't wake the system from keyboard if I suspend to disk and then to ram) I was provided with the patch that fixes this problem completely. The merge window is open, but I still don't see it in the kernel. Due to changes it doesn't anymore apply to latest git. Was it missed? No, it's in Len's git tree. Len's git-pull request from a few days ago didn't work, perhaps because I wanted to know if a recent -mm regression had been fixed and that hasn't been answered yet. I assume that Len is offline. Other acpi developers could presumably have answered that question but for some reason chose not to. I'm presently holding off 20-odd power management patches due to their dependency upon an acpi merge... - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9155] New: No fan control with ATI Radeon display support on HP nx6125.
On Sat, 13 Oct 2007 02:37:35 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9155 Summary: No fan control with ATI Radeon display support on HP nx6125. Product: Drivers Version: 2.5 KernelVersion: 2.6.22, 2.6.23 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(Other) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur:2.6.21 Distribution:gentoo Hardware Environment:HP nx6125 BIOS version F.11 Software Environment:Gnome 2.18, ati-driver 8.40.4 Problem Description:If you enable support for frame buffer devices, Vesa vga graphics support and ati radeon display support under graphics support so you lost fan cantrol on your hp nx6125, that means the fan doens't stop working. Steps to reproduce:Enable support for frame buffer devices, Vesa vga graphics support and ati radeon display support under graphics support on your hp nx6125 and after the next boot the fan will not switched off. Does anyone know whether this is likely to be a radeon driver bug or an acpi bug or something else?? - 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: [GIT PATCH] ACPI paches for 2.6.24-rc0
On Tue, 9 Oct 2007 23:10:47 -0400 Len Brown [EMAIL PROTECTED] wrote: please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release ... drivers/acpi/battery.c | 1038 + Does this introduce the problem which Zan Lynx reported in his unresponded-to email titled 2.6.23-rc8-mm2 ACPI Battery Info in /sys but not /proc/acpi? - 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/6] PNP: use dev_info(), dev_err(), etc in core
On Fri, 28 Sep 2007 10:39:14 -0600 Bjorn Helgaas [EMAIL PROTECTED] wrote: --- w.orig/include/linux/pnp.h2007-09-13 16:25:48.0 -0600 +++ w/include/linux/pnp.h 2007-09-13 16:26:04.0 -0600 @@ -8,6 +8,10 @@ #ifdef __KERNEL__ +#ifdef CONFIG_PNP_DEBUG +#define DEBUG +#endif In file included from include/linux/isapnp.h:26, from drivers/pcmcia/i82365.c:58: include/linux/pnp.h:12:1: warning: DEBUG redefined command line:1:1: warning: this is the location of the previous definition testing problems? - 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 off regression in 2.6.23-rc8 (NOT in rc7)
On Tue, 25 Sep 2007 08:51:09 +0200 Damien Wyart [EMAIL PROTECTED] wrote: Hello, After testing rc8, I noticed that I couldn't power off the computer directly, it only got halted and I had to press the power button manually. Just before displaying System halted, the following message is displayed: ACPI : PCI interrupt for device :02:08.0 disabled I had to first revert 5a50fe709d527f31169263e36601dd83446d5744 then f216cc3748a3a22c2b99390fddcdafa0583791a2 (handling of Sx states) to recover previous behaviour. Let's add some cc's. Attached are the dmesg for rc7, rc8 and rc8 with the two patches reverted. diff -u dmesg.rc8_revert dmesg.rc8 says: --- dmesg.rc8_revert2007-09-25 00:31:33.0 -0700 +++ dmesg.rc8 2007-09-25 00:31:30.0 -0700 @@ -1,4 +1,4 @@ -Linux version 2.6.23-rc8-25092007dw ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-5)) #2 SMP Tue Sep 25 08:31:09 CEST 2007 +Linux version 2.6.23-rc8-25092007dw ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-5)) #1 SMP Tue Sep 25 07:27:10 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) @@ -72,18 +72,18 @@ console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) -Memory: 2074780k/2096592k available (2175k kernel code, 20712k reserved, 815k data, 192k init, 1179088k highmem) +Memory: 2074780k/2096592k available (2175k kernel code, 20712k reserved, 816k data, 192k init, 1179088k highmem) virtual kernel memory layout: fixmap : 0xfff9b000 - 0xf000 ( 400 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc03f - 0xc042 ( 192 kB) - .data : 0xc031fd5c - 0xc03ebd04 ( 815 kB) - .text : 0xc010 - 0xc031fd5c (2175 kB) + .data : 0xc031fcd4 - 0xc03ebd04 ( 816 kB) + .text : 0xc010 - 0xc031fcd4 (2175 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1 -Calibrating delay using timer specific routine.. 5987.66 BogoMIPS (lpj=2993833) +Calibrating delay using timer specific routine.. 5987.60 BogoMIPS (lpj=2993802) Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 041d monitor/mwait feature present. @@ -104,7 +104,7 @@ Booting processor 1/1 eip 2000 CPU 1 irqstacks, hard=c0426000 soft=c0424000 Initializing CPU#1 -Calibrating delay using timer specific routine.. 5984.18 BogoMIPS (lpj=2992093) +Calibrating delay using timer specific routine.. 5984.16 BogoMIPS (lpj=2992084) CPU: After generic identify, caps: bfebfbff 041d monitor/mwait feature present. CPU: Trace cache: 12K uops, L1 D cache: 16K @@ -116,7 +116,7 @@ CPU1: Intel P4/Xeon Extended MCE MSRs (12) available CPU1: Thermal monitoring enabled CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 03 -Total of 2 processors activated (11971.85 BogoMIPS). +Total of 2 processors activated (11971.77 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 checking TSC synchronization [CPU#0 - CPU#1]: passed. @@ -279,6 +279,7 @@ EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 192k freed +input: PC Speaker as /devices/platform/pcspkr/input/input4 sr0: scsi3-mmc drive: 1x/48x cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 @@ -287,7 +288,6 @@ usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb -input: PC Speaker as /devices/platform/pcspkr/input/input4 parport_pc 00:0a: reported by Plug and Play ACPI parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP] USB Universal Host Controller Interface driver v3.0 @@ -299,46 +299,42 @@ usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected -ACPI: PCI Interrupt :00:1d.1[B] - GSI 19 (level, low) - IRQ 20 -PCI: Setting latency timer of device :00:1d.1 to 64 -uhci_hcd :00:1d.1: UHCI Host Controller -uhci_hcd :00:1d.1: new USB bus registered, assigned bus number 2 -uhci_hcd :00:1d.1: irq 20, io base 0xff60 +ACPI: PCI Interrupt :00:1d.7[D] - GSI 23 (level, low) - IRQ 20 +PCI: Setting latency timer of device :00:1d.7 to 64 +ehci_hcd :00:1d.7: EHCI Host Controller +ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 2 +ehci_hcd :00:1d.7: debug port 1 +PCI: cache line size of 128 is not supported by device :00:1d.7
Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)
On Tue, 25 Sep 2007 18:45:15 +0400 Alexey Starikovskiy [EMAIL PROTECTED] wrote: [fix-ACPI_SLEEP_states.patch text/x-patch (2.0KB)] ACPI: suspend: fix ACPI_SLEEP states From: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Alexey Starikovskiy [EMAIL PROTECTED] --- drivers/acpi/sleep/Makefile |2 +- drivers/acpi/sleep/main.c |4 include/acpi/acpi_drivers.h |4 3 files changed, 5 insertions(+), 5 deletions(-) I get a reject applying this to current mainline. Easy enough to fix it, but I worry that the fix might be incorrect when applied to some tree other than that which you were working on. - 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: cpuidle
On Sun, 23 Sep 2007 22:28:30 -0400 Len Brown [EMAIL PROTECTED] wrote: On Sunday 23 September 2007 20:57, Andrew Morton wrote: Wha? Seems that the cpuidle patches all got dropped, but the x86_64 dynticks patches were fairly heavily dependent upon them. (iow: I'm screwed). I can go back to the old version of git-acpi and retain the dynticks patches or I can drop the dynticks patches. (Either way I remain screwed). What's happening? Yes, I dropped cpuidle on Friday with plans to re-merge it Monday. The reason is because I re-wrote my test tree Friday in prep for 2.6.24. As cpuidle had been merged multiple times, I needed to re-merge it and deal with the conflicts, and I ran out of time. What we should end up with on Monday is a single cpuidle patch that sits on top of 2.6.22, and a single patch that merges it up to 2.6.23. I really don't know what I did, but for some reason the patches all applied after I fiddled with something. Maybe I broke something, dunno. I did drop a few acpi patches which were dependent upon cpuidle: -acpi-suspend-consolidate-handling-of-sx-states.patch -acpi-suspend-consolidate-handling-of-sx-states-addendum.patch but they were staged _after_ the dynticks patches so I dunno what's going on. I guess when I try to compile this lot I'll have a better idea... ho hum. I hope I haven't lost any patches during this little episode. - 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: git-acpi breaks resume-from-ram on the Vaio
On Tue, 18 Sep 2007 13:59:04 +0200 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Tuesday, 18 September 2007 13:54, Rafael J. Wysocki wrote: On Tuesday, 18 September 2007 06:40, Andrew Morton wrote: On Mon, 17 Sep 2007 21:12:13 -0700 Andrew Morton [EMAIL PROTECTED] wrote: It suspends OK, then during resume it gets partway through it, then everything just stops. Would prefer not to have to bisect this one - I've done enough bisecting this week to last a lifetime, and bisecting git-acpi is painful due to build bustage at various points (cpuidle). And git-acpi breaks suspend-to-disk as well. It gets up to Suspending console(s) and then the cursor stops blinking at it wedges up. Bisection shows that the resume-from-ram failure is caused by commit 987196fa82d4db52c407e8c9d5dec884ba602183 Author: Venkatesh Pallipadi [EMAIL PROTECTED] Date: Thu Feb 22 13:52:57 2007 -0800 cpuidle take2: Core cpuidle infrastructure Note that this is the patch which *fixed* resume-from-RAM prior to Thomas's git-hrt merge. Now it breaks it!?!?! Also, I'm seeing this, in mainline, when I do echo mem /sys/power/state [ 26.316685] ipw2200: Failed to send WEP_KEY: Aborted due to RF kill switch. [ 33.044631] ipw2200: Failed to send WEP_KEY: Command timed out. [ 39.862821] ipw2200: Failed to send WEP_KEY: Command timed out. [ 68.962896] PM: Preparing system for mem sleep [ 68.979485] Stopping tasks ... WARNING: at kernel/lockdep.c:2658 check_flags() [ 68.980154] [c0104ea4] show_trace_log_lvl+0x1a/0x2f [ 68.980295] [c0105a44] show_trace+0x12/0x14 [ 68.980416] [c0105a5b] dump_stack+0x15/0x17 [ 68.980535] [c0137276] check_flags+0x93/0x13d [ 68.980663] [c013a8ab] lock_acquire+0x3a/0x91 [ 68.980789] [c031948b] _spin_lock+0x38/0x62 [ 68.980913] [c0142a4d] refrigerator+0x13/0xc2 [ 68.981040] [c01283a2] get_signal_to_deliver+0x32/0x405 [ 68.981188] [c01035f4] do_notify_resume+0x91/0x69f [ 68.981323] [c010402d] work_notifysig+0x13/0x1a [ 68.981453] === [ 68.981542] irq event stamp: 1511 [ 68.981624] hardirqs last enabled at (1511): [c010408d] syscall_exit_work+0x11/0x26 [ 68.981834] hardirqs last disabled at (1510): [c0103f63] syscall_exit+0x9/0x1a [ 68.982031] softirqs last enabled at (1418): [c03104c3] unix_accept+0xe5/0xfb [ 68.982230] softirqs last disabled at (1416): [c031958d] _write_lock_bh+0xf/0x67 Can you please compile with CONFIG_DISABLE_CONSOLE_SUSPEND set and try: Ah, that's -mm, sorry. Instead of setting CONFIG_DISABLE_CONSOLE_SUSPEND (which has been removed) please pass no_console_suspend in the command line. Didn't appear to change anything. Bear in mind that e100 netconsole is a bit busted across resume anyway, and the video display on this machine has never ever survived resume-from-ram (but the X server can bring it back). - 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
Fw: 2.6.23-rc6-mm1 and acpi
Begin forwarded message: Date: Tue, 18 Sep 2007 23:42:25 +0200 From: Michael Gerdau [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: 2.6.23-rc6-mm1 and acpi Hi, while trying to compile 2.6.23-rc6-mm1 I came across the following build error: [EMAIL PROTECTED]:/usr/src/linux-2.6.23-rc6-mm1 make modules CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh stdin:1389:2: warning: #warning syscall revokeat not implemented stdin:1393:2: warning: #warning syscall frevoke not implemented CC [M] drivers/acpi/sbs.o drivers/acpi/sbs.c: In function ‘acpi_battery_alarm_show’: drivers/acpi/sbs.c:457: error: implicit declaration of function ‘acpi_battery_get_alarm’ drivers/acpi/sbs.c: In function ‘acpi_battery_alarm_store’: drivers/acpi/sbs.c:472: error: implicit declaration of function ‘acpi_battery_set_alarm’ drivers/acpi/sbs.c: In function ‘acpi_battery_add’: drivers/acpi/sbs.c:829: warning: ignoring return value of ‘device_create_file’, declared with attribute warn_unused_result make[2]: *** [drivers/acpi/sbs.o] Fehler 1 make[1]: *** [drivers/acpi] Fehler 2 make: *** [drivers] Fehler 2 Not sure who to CC, which is why I send it to the list alone. Best, Michael -- Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: PGP signature
Re: git-acpi breaks resume-from-ram on the Vaio
On Tue, 18 Sep 2007 11:21:41 -0400 Len Brown [EMAIL PROTECTED] wrote: On Tuesday 18 September 2007 00:12, Andrew Morton wrote: It suspends OK, then during resume it gets partway through it, then everything just stops. Hmmm, i thought your vaio resume problems were in linus' tree -- did that go away -- or maybe it was in -mm and not in linus' tree all along? It got fixed in Linus's tree by tglx's recent timers merge. This breakage in git-acpi is new, I think. Four or five days ago, git-acpi _fixed_ suspend/resume on Linus's tree. Now it breaks it. But I don't think there have been changes in got-acpi since then, so perhaps the breakage is due to interaction with Thomas's recent merge. Would prefer not to have to bisect this one - I've done enough bisecting this week to last a lifetime, and bisecting git-acpi is painful due to build bustage at various points (cpuidle). bisecting the acpi git three should work well, because it uses topic branches. This includes cpuidle. ie. unless the breakage is within the cpuidle branch itself, the whole cpuidle topic can be removed by skipping the single merge commit that pulls it in. The breakage is within the cpuidle branch. If you like, I can build the topic branch heads and export plain patches for you to try. Also, I'll probably be re-writing the test branch history later today -- so let me know if you dig into it and i'll delay that until you're done. I won't be doing anything here for a day or so. I think what needs to happen is that the commits in the cpuidle code need to be folded together. iirc the first couple of commits don't compile, and the third one fixes them. Or something like that. - 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: git-acpi breaks resume-from-ram on the Vaio
On Tue, 18 Sep 2007 15:58:18 -0400 Len Brown [EMAIL PROTECTED] wrote: On Tuesday 18 September 2007 13:07, Andrew Morton wrote: This breakage in git-acpi is new, I think. Four or five days ago, git-acpi _fixed_ suspend/resume on Linus's tree. Now it breaks it. But I don't think there have been changes in got-acpi since then, so perhaps the breakage is due to interaction with Thomas's recent merge. hmmm, maybe. Perhaps if you are including sony-laptop, you can try excluding it -- since these reverse engineered things are always fraught with peril I think the next thing to test is to revert cpuidle -- let me make sure that my cpuidle branch produces a patch that will revert cleanly... ho hum. I still have the git-acpi tree as a quilt series so this evening I'll bisect these two failures down to a particular git commit. - 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
git-acpi breaks resume-from-ram on the Vaio
It suspends OK, then during resume it gets partway through it, then everything just stops. Would prefer not to have to bisect this one - I've done enough bisecting this week to last a lifetime, and bisecting git-acpi is painful due to build bustage at various points (cpuidle). - 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: git-acpi breaks resume-from-ram on the Vaio
On Mon, 17 Sep 2007 21:12:13 -0700 Andrew Morton [EMAIL PROTECTED] wrote: It suspends OK, then during resume it gets partway through it, then everything just stops. Would prefer not to have to bisect this one - I've done enough bisecting this week to last a lifetime, and bisecting git-acpi is painful due to build bustage at various points (cpuidle). And git-acpi breaks suspend-to-disk as well. It gets up to Suspending console(s) and then the cursor stops blinking at it wedges up. - 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: boot hangs with SMP, USB storage, and ACPI
(cc restored. Please always do reply-to-all) (linux-acpi cc added) On Wed, 12 Sep 2007 15:00:41 +0200 tx tox [EMAIL PROTECTED] wrote: On 12 Lip 2006, 00:41, Eric Cooper [EMAIL PROTECTED] wrote: When I try toboota 2.6.17 kernel compiled forSMP(hyperthreading), it hangs early in thebootsequence (after printing FreeingSMP alternatives). The issue seems to be an interaction between a USB-storage device (an empty flash card reader built into the monitor) andACPI. It boots fine if I do any one of these: - physically disconnect theUSBdevice - disableUSBsupport in the BIOS -bootwithacpi=ht but none of these is completely satisfactory. I'll happily supply more details, run tests, etc. if anyone is interested in looking at this. Thanks, and please CC me if you respond. -- Eric Cooper e c c @ c m u . e d u I have exactly the same problem This happens whenever i boot machine with reader on or usbstick plugged in. It happens with newer kernels as well. It is little bit annoying to reset machine just because i forgot to switch off the printer which has card reader equipped ;) some goofing with printks suggests ACPI as a place whenre it freezes. But i got no proof for that. Any suggestions are welcome. Could you both please test 2.6.22 (or 2.6.23, soon) and if the bug is still present, raise a report against acpi at bugzilla.kernel.org? We'd be particularly internested in knowing if any earlier 2.6 kernel worked OK and if so, which version(s). Thanks. - 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: [Resend][PATCH -mm] Hibernation: Enter platform hibernation state in a consistent way (rev. 4)
On Wed, 12 Sep 2007 13:14:08 +0200
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
+ if (!hibernation_ops)
+ return -ENOSYS;
+
+ /*
+ * We have cancelled the power transition by running
+ * hibernation_ops-finish() before saving the image, so we should let
+ * the firmware know that we're going to enter the sleep state after all
+ */
+ error = hibernation_ops-start();
+ if (error)
+ return error;
+
+ suspend_console();
+ error = device_suspend(PMSG_SUSPEND);
+ if (error)
+ return error;
+
+ error = hibernation_ops-prepare();
+ if (error)
+ goto Resume_devices;
+
+ error = disable_nonboot_cpus();
+ if (error)
+ goto Finish;
+
+ local_irq_disable();
+ error = device_power_down(PMSG_SUSPEND);
+ if (!error) {
+ hibernation_ops-enter();
+ /* We should never get here */
+ while (1);
}
+ local_irq_enable();
+
Confused. afacit there's no way for the caller of this function to know
whether or not suspend_console() was called, so the error recovery doesn't
know whether or not to run resume_console(). How does all that work?
-
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] [-mm] FS: file name must be unique in the same dir in procfs
From: Zhang Rui [EMAIL PROTECTED]
File name should be unique in the same directory.
In order to keep the back-compatibility, only a warning is given
currently, but actions must be taken to fix it when such duplicates
are detected.
Bug report and a simple fix can be found here:
http://bugzilla.kernel.org/show_bug.cgi?id=8798
Signed-off-by: Zhang Rui [EMAIL PROTECTED]
---
fs/proc/generic.c | 12
1 file changed, 12 insertions(+)
Index: linux-2.6/fs/proc/generic.c
===
--- linux-2.6.orig/fs/proc/generic.c
+++ linux-2.6/fs/proc/generic.c
@@ -523,6 +523,7 @@ static const struct inode_operations pro
static int proc_register(struct proc_dir_entry * dir, struct
proc_dir_entry * dp)
Your email client is wordwrapping the text.
{
+ struct proc_dir_entry *tmp = NULL;
That initialisation is unneeded - I removed it.
`tmp' is always a crappy name for anything. I renamed it to `de'.
-
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: libata not working for sis5533
On Sun, 09 Sep 2007 13:35:26 +0200 Patrizio Bassi [EMAIL PROTECTED] wrote: Patrizio Bassi ha scritto: Jan Engelhardt ha scritto: On Sep 8 2007 11:38, Patrizio Bassi wrote: Jan Engelhardt wrote: I shall give this a spin too, since I happen to have sis5513. Just booted this fresh ata-enabled system (a matter of mkinitrd). It has not exploded yet. don't you have the irq 14 issue? No, does not seem so. can you post here your .config? http://rafb.net/p/vfTX0966.html Maybe it is solved in 2.6.22.3? (I don't remember what your version was.) Jan For Alan, libata devs...hope can help debug... this is http://www.patriziobassi.it/downloads/libata_issue.jpg Looks more like a platform irq routing issue than an ata issue. Perhaps an x86 or an acpi person can help out with this. Probably nothing will happen, in which case I'll get back to you later and ask you to raise a bugzilla entry, not that this will get it fixed :( and this is the relative config i'm using http://www.patriziobassi.it/downloads/config Let me know Patrizio more debug: I tried as suggested with the irqpoll option, i just get a faster panic as i don't have the 3 xfermode lines...but always impossibile to boot... Patrizio - 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/ - 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
