After switching the affected machine to Fedora 16 with 3.1.5-6.fc16.x86_64 kernel this log spamming as described above apparently stopped and setting /sys/module/drm_kms_helper/parameters/poll to "N" and/or using as boot parameter drm_kms_helper.poll=0 does not seem to be required anymore.
Other over and over repeating messages are showing up instead. Like this:
....
... radeon_dri2_schedule_flip:670 fevent[0x27b51a0]
... radeon_dri2_flip_event_handler:1067 fevent[0x27b51a0] width 1280 pitch 5120 (/4 1280)
...
but this far not on that scale like previously.
Other things instead are conspiring to make logs hard to use - like gnome-shell spilling tons of "DEBUG(+)" messages - but this is not that bug anymore.
BTW - recorded in Xorg.0.log EDID data are the same as in the original report with this exception that now I see:
RADEON(0): Using EDID range info for horizontal sync
RADEON(0): Using EDID range info for vertical refresh
After switching the affected machine to Fedora 16 with 3.1.5-6.fc16.x86_64 kernel this log spamming as described above apparently stopped and setting /sys/module/ drm_kms_ helper/ parameters/ poll to "N" and/or using as boot parameter drm_kms_ helper. poll=0 does not seem to be required anymore.
Other over and over repeating messages are showing up instead. Like this: dri2_schedule_ flip:670 fevent[0x27b51a0] dri2_flip_ event_handler: 1067 fevent[0x27b51a0] width 1280 pitch 5120 (/4 1280)
....
... radeon_
... radeon_
...
but this far not on that scale like previously.
Other things instead are conspiring to make logs hard to use - like gnome-shell spilling tons of "DEBUG(+)" messages - but this is not that bug anymore.
BTW - recorded in Xorg.0.log EDID data are the same as in the original report with this exception that now I see:
RADEON(0): Using EDID range info for horizontal sync
RADEON(0): Using EDID range info for vertical refresh
while before these were "from config file".