Hi,
I finally got around to compiling 2.6.32 for my primary machine, and
with radeon.modeset=1, the machine has a horrifying 33 second boot
delay (it stays at a black screen for the duration).
I figured a 'git bisect v2.6.32 v2.6.31 -- drivers/gpu/drm' would
catch it. Hopefully this bisection helps pin down the underlying
problem:
# bad: [22763c5c] Linux 2.6.32
# good: [74fca6a4] Linux 2.6.31
# bad: [df748b02] drm/ttm: fix refcounting in ttm global code.
# good: [a513c184] drm/radeon/kms: Don't try to process irq when we a
# good: [aadd4e17] drm/radeon: some r420s have a CP race with the DMA
# good: [74bf2ad5] drm/kms: make fb helper work for all drivers.
# bad: [62a8ea3f] drm/radeon/kms: Remove old init path as no hw use
# good: [f0ed1f65] drm/radeon/kms: Convert R520 to new init path and
# skip: [d4550907] drm/radeon/kms: Convert R100 to new init path (V2)
# good: [3bc68535] drm/radeon/kms: Convert RS690/RS740 to new init pa
# bad: [c010f800] drm/radeon/kms: Convert RS600 to new init path
Any ideas why c010f800 would cause this?
Attached is dmesg from v2.6.32 booting on the affected machine. Note
the painful delay between lines 538 and 539.
- Steven
On Mon, 2009-12-07 at 21:01 -0800, Steven Noonan wrote:
> Hi,
>
> I finally got around to compiling 2.6.32 for my primary machine, and
> with radeon.modeset=1, the machine has a horrifying 33 second boot
> delay (it stays at a black screen for the duration).
>
> I figured a 'git bisect v2.6.32 v2.6.31 -- drivers/gpu/drm' would
> catch it. Hopefully this bisection helps pin down the underlying
> problem:
> # bad: [22763c5c] Linux 2.6.32
> # good: [74fca6a4] Linux 2.6.31
> # bad: [df748b02] drm/ttm: fix refcounting in ttm global code.
> # good: [a513c184] drm/radeon/kms: Don't try to process irq when we a
> # good: [aadd4e17] drm/radeon: some r420s have a CP race with the DMA
> # good: [74bf2ad5] drm/kms: make fb helper work for all drivers.
> # bad: [62a8ea3f] drm/radeon/kms: Remove old init path as no hw use
> # good: [f0ed1f65] drm/radeon/kms: Convert R520 to new init path and
> # skip: [d4550907] drm/radeon/kms: Convert R100 to new init path (V2)
> # good: [3bc68535] drm/radeon/kms: Convert RS690/RS740 to new init pa
> # bad: [c010f800] drm/radeon/kms: Convert RS600 to new init path
>
> Any ideas why c010f800 would cause this?
>
Wierd, it seems an unlikely change to affect this, can you boot with
drm.debug=15 on the command line and see if we can glean anymore info
about where its hanging.
It might be good to open a bug either on kernel.org or freedesktop.org
(against Xorg radeon driver - since we mostly hang out there).
Dave.
On Mon, Dec 7, 2009 at 9:05 PM, Dave Airlie <[email protected]> wrote:
> On Mon, 2009-12-07 at 21:01 -0800, Steven Noonan wrote:
>> Hi,
>>
>> I finally got around to compiling 2.6.32 for my primary machine, and
>> with radeon.modeset=1, the machine has a horrifying 33 second boot
>> delay (it stays at a black screen for the duration).
>>
>> I figured a 'git bisect v2.6.32 v2.6.31 -- drivers/gpu/drm' would
>> catch it. Hopefully this bisection helps pin down the underlying
>> problem:
>> ?# bad: ?[22763c5c] Linux 2.6.32
>> ?# good: [74fca6a4] Linux 2.6.31
>> ?# bad: ?[df748b02] drm/ttm: fix refcounting in ttm global code.
>> ?# good: [a513c184] drm/radeon/kms: Don't try to process irq when we a
>> ?# good: [aadd4e17] drm/radeon: some r420s have a CP race with the DMA
>> ?# good: [74bf2ad5] drm/kms: make fb helper work for all drivers.
>> ?# bad: ?[62a8ea3f] drm/radeon/kms: Remove old init path as no hw use
>> ?# good: [f0ed1f65] drm/radeon/kms: Convert R520 to new init path and
>> ?# skip: [d4550907] drm/radeon/kms: Convert R100 to new init path (V2)
>> ?# good: [3bc68535] drm/radeon/kms: Convert RS690/RS740 to new init pa
>> ?# bad: ?[c010f800] drm/radeon/kms: Convert RS600 to new init path
>>
>> Any ideas why c010f800 would cause this?
>>
>
> Wierd, it seems an unlikely change to affect this, can you boot with
> drm.debug=15 on the command line and see if we can glean anymore info
> about where its hanging.
Attached the dmesg with drm.debug=15.
> It might be good to open a bug either on kernel.org or freedesktop.org
> (against Xorg radeon driver - since we mostly hang out there).
>
Okay. Reported. https://bugs.freedesktop.org/show_bug.cgi?id=25506
- Steven