dmesg | grep Bug [ 0.237792] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 155.683318] [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu [ 155.696932] [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu Generally, brigtness buttons work inproperly i.e. With loong delay, sleep has trade-off. More specificaly read https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1078869 with all my current (or some older) settings. Problem still unresolved and developers are not going to resolve. Maybe there i will find help...
Is anybody out there?
Hello Sergey, According to the Ubuntu bugzilla page: suspend/resume both work without workaround script. Brigtness buttons are up without delay but problem with clear screen after restart still present. What do you mean by "clear screen after restart"? Thanks.
Actually not so. There are still two counterpart problems: 1) "clear screen after restart" if suspend/resume done 2) Brigtness buttons with delay if no suspend/resume done P.S. Thx, that someone finally may help me. Will strive to help as i can.
Hello Sergey, Sorry for replying late. I want to know if suspend works for your computer or not. For brightness function control, you may need to open another bug. So does suspend to ram work for your computer?
works...
OK, thanks. So suspend works, but brightness control through Fn key has long delay, and the long delay can be fixed by doing a suspend/resume cycle. Is this correct? BTW, you also mentioned the screen will be black after restarting, this feels like a graphics card driver or BIOS' issue. You should open a new bug for this. Let's just track ACPI related problems here, thanks.
> Is this correct? Yes, that part is correct. And also correct that screen will be black after restarting IF I WILL do suspend. So it still seems to be ACPI problem too (suspect, that powering up of videocard after restarting isn't correct because last wake-up after suspend did something wrong). Wnen i answered "works..." before - it actually relates to suspend-to-ram functionality, and it's OK. Besides, it would be nice to have functionality to not let user open 100500 bugs to find proper package...
(In reply to comment #7) > And also correct that screen will be black after restarting IF I WILL do > suspend. Yes I know. > So it still seems to be ACPI problem too (suspect, that powering up of > videocard after restarting isn't correct because last wake-up after suspend > did > something wrong). While suspend/resume does not involve ACPI only :-) During suspend/resume, individual driver will need to take care of the devices it drives to suspend them and then resume them. If the system can not wakeup from a suspended state, it probably is a ACPI problem. But if after resume, some device does not behave well, it is the driver's problem. If possible, you can try the debug method described here: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt In short, you can do: # echo devices > /sys/power/pm_test # echo disk > state This will make devices go through suspend/resume cycle without involving ACPI, and then you can reboot to see if screen works. Thanks, Aaron
Hi Sergey, Is there any update?