[Bug 36003] [Radeon HD 5650 and 5470] Driver crash during recovery boot and in normal boot (Regression from 2.6.38-3 to -4)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36003

--- Comment #12 from Seth Forshee <seth.forshee at canonical.com> 2011-05-19 09:17:59 PDT ---
(In reply to comment #10)
> It's not a bad interaction between i915 and radeon per se.  The switcheroo code
> needs more work to switch properly on some systems it seems.  There are a set
> acpi methods required to activate/deactivate the respective gpus.  The drivers
> need to load and initialize active hw.  If the hw is not active when the driver
> loads, then the hw is not set up properly and it won't work.  Probably some
> ordering issues in how the switcheroo acpi methods are called.

I've been staring at lots of logs from boots that do and don't trigger the
oops, and I can't see that the interactions with the switcheroo code are at all
related. The oops happens during the radeon probe, and by that point the atpx
handler has been registered with vga_switcheroo and possibly radeon_atpx_init()
has been called, depending on what else has happened at that point, but whether
or not radeon_atpx_init() has been called doesn't correlate to whether or not
the oops happens. Nor does it correlate to the order in which the i915 and
radeon probes happen or anything else I can see from the logs. I'd love to hear
more ideas about what's leading to the inconsistency of the power state at
boot, because I'm coming up dry (unless it's just the state inherited from the
BIOS or bootloader).

Does the driver just need to unconditionally enable power via the ATPX handler
during the probe to ensure the probe can continue successfully?

And is it better to carry on this conversation here or on the kernel bugzilla
linked to in comment #5?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.