2.6 is getting better! I only have two outstanding issues on my setup.
I've CC:d the appropriate maintainers:
1. Software suspend
This began actually working in -test9. However, if I S4 from within X,
it will never resume. In fact, it will begin resuming, but then it will
go 'Waiting for DMAs to calm down' or something, and then reboot, and
loop rebooting.
Also, my USB devices will not be re-enabled unless I unplug the hub and
replug it back in. Is there a way to kick my hotplug manager in the
shins on resume, or simulate a unplug/replug?
2. Radeon framebuffer
At boot time, since like kernel 2.5.59, there is a pile of random junk
on my framebuffer which scrolls away after a while with the boot
messages. It usually elicits weird questions from my Windows- and Red
Hat-using colleagues. "Whoa, pretty colors!" or "what the hell?" :)
Also only recently I am seeing some text clearing problems especially
when using mutt. Some characters will be stuck on the screen after
paging up and down, and sometimes when I hit the backspace i get a little
dot (like 'o') for each time i press the backspace but it seems to have
no effect on the text processed by programs.
Hoping that these two issues can be resolved.
--
Joshua Kwan
Hi!
> 1. Software suspend
>
> This began actually working in -test9. However, if I S4 from within X,
> it will never resume. In fact, it will begin resuming, but then it will
> go 'Waiting for DMAs to calm down' or something, and then reboot, and
> loop rebooting.
Try unloading agp/dri modules before you suspend. Then write
suspend/resume support for them.
> Also, my USB devices will not be re-enabled unless I unplug the hub and
> replug it back in. Is there a way to kick my hotplug manager in the
> shins on resume, or simulate a unplug/replug?
USB should support this, maybe there's some bug in suspend/resume methods?
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Sun, Nov 09, 2003 at 01:03:27AM +0100, Pavel Machek wrote:
> Try unloading agp/dri modules before you suspend. Then write
> suspend/resume support for them.
Sadly, both are built into the kernel for me :) And I am hardly a kernel
hacker much more than a tester.
However, a little OT, but I managed to pull this out of dmesg from when
my system was suspending:
bad: scheduling while atomic!
Call Trace:
[<c011c9cf>] schedule+0x59c/0x5a1
[<c02a8295>] pci_read+0x3d/0x41
[<c0127dfb>] schedule_timeout+0x63/0xb7
[<c0127d8f>] process_timeout+0x0/0x9
[<c01bf062>] pci_set_power_state+0xd3/0x15e
[<c0233377>] rtl8139_suspend+0x78/0xb1
[<c01c12cb>] pci_device_suspend+0x2c/0x2e
[<c021ebb3>] suspend_device+0x97/0xfd
[<c021ec71>] device_suspend+0x58/0x7a
[<c01370d1>] drivers_suspend+0xf/0x13
[<c01375c7>] do_software_suspend+0x54/0x83
[<c01d9ae6>] acpi_system_write_sleep+0xb3/0xcd
[<c01d9a33>] acpi_system_write_sleep+0x0/0xcd
[<c01547c4>] vfs_write+0xb0/0x119
[<c01548d2>] sys_write+0x42/0x63
[<c02fcf27>] syscall_call+0x7/0xb
Hope this helps.
--
Joshua Kwan