FC3 can no longer successfully burn CDs]

[Fulko.Hew at sita.aero]

Alan Cox asked:

>>>>  1/ The timer on the screensaver does not work.
>>>>     - Time values < 20 minutes are obeyed.
>>>>     - Time values >20 minutes always results in a timeout of 20
minutes.
>>>
>>> Do you have a BIOS set 20 minute display timeout floating around too by
>>> any chance ?
>>
>> And remember, this CD burn problem _is_   kernel specific.
>> I will do tests later today with older kernels and this 20 minute
>> timeout issue and report back.
>
>Yes. My guess at the moment is something involving acpi or the cpu
frequency
>daemon (acpi=off being one test to do). The reason for this is that when
the
>CPU changes speed it has to disconnect from the system busses and
reconnect.
>Thats a complex process and there are chip errata (and also maybe software
>bugs of course) in this area which might foul up a current DMA transfer.

I had done the 'cpu frequency demon test' earlier last week,
and it did not have any effect.

The 'acpi=off' however, does act as a workaround.
By turning it off, the burn is successful.

Regardless of whether the screen blanks or not.

NOTE: acpi=off does _not_ affect the pre-mature screen blanking symptom.

So my (un-confirmed) conclusions are:

 - The issue is related to ACPI (as executed by the kernel).
 - Kernels (post 2.6.7), have changed their ACPI functionality.

 1/ Xscreensaver has a bug, (or is controlled by mysterious/hidden
    ACPI parameters even if ACPI is OFF), regardless of Xscreensaver
    settings.  Because after the '20 minutes' the animated wallpaper
    kicks in regardless of the setting of Xscreensaver.

 2/ ACPI affects hardware regardless of the Xscreensaver setting
    of the "don't inform power management hardware of screen saving"
option.

 3/ My laptop's ACPI code is buggy causing a 'glitch' that affects
    CD-ROM burning (when some un-specified, buggy, ACPI code is
    inappropriately activated, as per 1 & 2 above).

BTW. I have already had to add "acpi_os_name=xxxxxyyyyyzzzzzxxxxx"
     to my boot options to workaround an "ACPI disables the enhanced
     USB (v 2.0) controller when running under Linux" issue, as per
     tests/discussions performed with Greg Kroah ~Sep/04 and the USB
     sub-system.

a) Now I don't know what bugzillas to report.  :-(

b) Would my next step be to disassemble the ACPI/BIOS code
   to see what I can see?