Re: swsusp 'disk' fails in bk-current - intel_agp at fault?

[Stefan Seyfried <seife@suse.de>]

Andy Isaacson wrote:

> OK, anything else I should try?

not really, i just wait for Vojtech and Pavel :-)

> Why does it only fail when I have *both* intel_agp and i8042 aux?

later...

> In the SysRq-T trace I see one interesting process: most things are
> in D state in refrigerator(), but sh shows the following traceback:
> 
> wait_for_completion
> call_usermodehelper
> kobject_hotplug
> kobject_del
> class_device_del
> class_device_unregister
> mousedev_disconnect
> input_unregister_device
> alps_disconnect
> psmouse_disconnect
> serio_driver_remove
> device_release_driver
> serio_release_driver

i think the following happens (but i am in no case an expert for this):
 - alps driver suspends
 - alps driver unregisters the device
 - udev is called via call_usermodehelper (which fails since userspace
   is stopped)
 - now somebody wants to wait for udev which does not work right.

Why only with the ALPS driver and intel_agp?
I think this is an accident. For me, it happens only with init=/bin/bash
and _no_ other drivers loaded (only IDE drivers and psmouse built-in).
As soon as i load any other drivers (i have only tried ehci_hcd and
8139too, to be honest) it works fine again. This leads me to believe it
is a race condition since the extra driver that has to be suspended may
give the ALPS driver the extra time needed to finish the race. For you,
it may be the other way round.

This is mostly guesswork, i am no kernel expert at all.
-- 
seife
                                 Never trust a computer you can't lift.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/