Re: [linux-pm] [PATCH] PCI PM: Restore standard config registers of all devices early (was: Re: EeePC resume failure - timers)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Wed, 21 Jan 2009, Linus Torvalds wrote:
> 
> I was going to say that I've been VT switching and it has worked, but I 
> decided to double-check. And yes, I can reproduce it that way. And no, no 
> kernel messages that are visible that way either. 

Ahhah!

No kernel messages, because the kernel isn't actually dead. Just X is. 

I verified that by doing a

	while : ; do echo t > /proc/sys/sysrq-trigger; sleep 5; done

while doing these things. I'm travelling, it's 7AM in Hobart now, and I 
don't have another machine, so when X dies in graphics mode, there's not a 
whole lot else I can do to debug it. No other machine to use to ssh into 
the machine from etc..

Also, the reason I at one point thought that VT switching works is that 
quite often it _does_ work. I seem to need some timing or interrupt thing 
happening to trigger the problem, because when I wasn't doing anything 
else, I could VT switch back and forth something like 10 times without 
problems.

That probably also explains why it then happens all the time on 
suspend/resume: other things are most definitely happening.

So I did another shell loop (that also gives an audible clue that things 
are working, even if the machine appears dead):

	while : ; do cat /bin/echo ; sleep 5; done > /dev/audio

and the VT switch failed the very next time I tried it. 

And since I had the sysrq loop running, and since it still made progress, 
I can now say that X seems to hang here:

	Xorg          S f52a3b98  6088  2252   2251
	 f68db340 00003082 c06ea2f8 f52a3b98 c07bb73c c07bec40 c07bec40 c07bec4
	 c07bec40 f4a58980 f4a58be8 c2010c40 00000000 00000000 bfc1f838 0000020
	 bfc1f838 f4a58be8 fffe9b5a 000a037f 00003282 c022d7ff f514fe98 f4a58c5
	Call Trace:
	 [<c022d7ff>] lock_timer_base+0x19/0x35
	 [<c022d983>] __mod_timer+0xba/0xc3
	 [<c05a65ef>] schedule_timeout+0x9f/0xbb
	 [<c022d522>] process_timeout+0x0/0x5
	 [<c05a65ea>] schedule_timeout+0x9a/0xbb
	 [<c038c494>] drm_wait_vblank+0x2d8/0x396
	 [<c0221c4c>] default_wake_function+0x0/0x8
	 [<c038a5ab>] drm_ioctl+0x1a6/0x21e
	 [<c038c1bc>] drm_wait_vblank+0x0/0x396
	 [<c0288d5e>] vfs_ioctl+0x49/0x5f
	 [<c0289527>] do_vfs_ioctl+0x464/0x49f
	 [<c02895a3>] sys_ioctl+0x41/0x58
	 [<c0202d01>] sysenter_do_call+0x12/0x21

ie it seems to be some vblank race. 

Looks like your commit dc1336ff4fe08ae7cfe8301bfd7f0b2cfd31d20a wasn't a
complete solution? Because it's definitely something I have, and I have
compiz, and I see the compiz hangs at VT switch that it claims to have
fixed. 

Added the other people that the git logs say worked on the vblank code
to the Cc.  

What an odd way to debug X lockups. What do you guys usually do? Just 
always make sure to have another machine handy?

				Linus

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux