Hi,
I'm getting the message in $Subject with latest linus:v3.5-8833-g2d534926205d
The dmesg printk is delayed for 5 seconds probably due to async scanning
(see trace below):
[ 10.746148] [drm] vram apper at 0xD0000000
[ 10.750680] [drm] size 786432
[ 10.754050] [drm] fb depth is 8
[ 10.757593] [drm] pitch is 1024
[ 10.761862] fbcon: radeondrmfb (fb0) is primary device
[ 5.163363] ACPI: Invalid Power Resource to register <----
[ 10.949414] Console: switching to colour frame buffer device 128x48
[ 10.977810] fb0: radeondrmfb frame buffer device
[ 10.982601] drm: registered panic notifier
[ 10.986892] [drm] Initialized radeon 2.17.0 20080528 for 0000:02:06.0 on
minor 0
So I added some debugging code to see where exactly this happens:
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index 215ecd097408..d79e0f8c1f4e 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -432,11 +432,17 @@ int acpi_power_resource_register_device(struct device
*dev, acpi_handle handle)
return -ENODEV;
ret = acpi_bus_get_device(handle, &acpi_dev);
- if (ret)
+ if (ret) {
+ pr_warn(PREFIX "error getting device %s\n",
dev_name(&acpi_dev->dev));
+ dump_stack();
goto no_power_resource;
+ }
- if (!acpi_dev->power.flags.power_resources)
+ if (!acpi_dev->power.flags.power_resources) {
+ pr_warn(PREFIX "no power resources %s\n",
dev_name(&acpi_dev->dev));
+ dump_stack();
goto no_power_resource;
+ }
powered_device = kzalloc(sizeof(*powered_device), GFP_KERNEL);
if (!powered_device)
---
and I got the following trace:
---
[ 5.163287] ACPI: no power resources device:1a
[ 5.163292] Pid: 1023, comm: kworker/u:4 Tainted: G W 3.5.0+ #9
[ 5.163293] Call Trace:
[ 5.163300] [<ffffffff81227866>]
acpi_power_resource_register_device+0x8f/0x1bf
[ 5.163305] [<ffffffff81221a5f>] ? acpi_get_child+0x48/0x4e
[ 5.163310] [<ffffffff812e34db>] ata_acpi_bind+0x80/0x87
[ 5.163313] [<ffffffff812d891e>] ata_scsi_scan_host+0x91/0x184
[ 5.163317] [<ffffffff812d4f4f>] async_port_probe+0x4a/0x4f
[ 5.163321] [<ffffffff810568cc>] async_run_entry_fn+0x9a/0x152
[ 5.163325] [<ffffffff8104a103>] process_one_work+0x265/0x438
[ 5.163328] [<ffffffff8104a080>] ? process_one_work+0x1e2/0x438
[ 5.163331] [<ffffffff81475a01>] ? _raw_spin_lock_irq+0x17/0x46
[ 5.163335] [<ffffffff81056832>] ? async_schedule+0x17/0x17
[ 5.163339] [<ffffffff8104c47f>] worker_thread+0x260/0x329
[ 5.163342] [<ffffffff8107ac72>] ? trace_hardirqs_on+0xd/0xf
[ 5.163346] [<ffffffff8104c21f>] ? manage_workers.clone.15+0x1f6/0x1f6
[ 5.163349] [<ffffffff810502ee>] kthread+0x89/0x91
[ 5.163353] [<ffffffff8147dd64>] kernel_thread_helper+0x4/0x10
[ 5.163356] [<ffffffff814762d9>] ? retint_restore_args+0xe/0xe
[ 5.163359] [<ffffffff81050265>] ? __init_kthread_worker+0x5b/0x5b
[ 5.163362] [<ffffffff8147dd60>] ? gs_change+0xb/0xb
And as it looks like, acpi_dev->power.flags.power_resources is 0.
This thing is set in acpi_bus_get_power_flags() so I'd guess some of
those _PR* objects are probably not completely correct and they should
be fixed in the BIOS?
Any comments are appreciated.
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
