Re: [PATCH] swsusp: properly suspend and resume *all* devices

[Pavel Machek <pavel@suse.cz>]

Hi!

> > devices. This has been the case since at least 2.6.9, if not earlier.
> > 
> > One effect of this is that resuming fails to properly reconfigure
> > interrupt routers. In 2.6.9 this was obscured by other kernel code,
> > but in 2.6.10 this often causes post-resume APIC errors and near-total
> > failure of some PCI devices (e.g. network, sound and USB controllers).
> 
> I'm seeing a variation (?) of this problem with 2.6.10. I have the same symptoms
> as you describe above, but on a machine without an APIC, using APM for
> suspend/resume. (Toshiba Portege 7220cte, which has an Intel 440BX chipset)
> 
> Obviously, I don't get the APIC errors, but everything else is the same, random
> devices fail and need to be reloaded (3c59x and uhci-hcd in particular), plus
> the system appears to panic somewhere along the way to resume occasionally (as I
> assume from the hung machine and blinking CAPS LOCK), which didn't happen
> previously (2.6.9, 2.6.8.1, ...). I also see lots of 
> 
> drivers/usb/input/hid-core.c: input irq status -84 received
> 
> until I do a 'rmmod uhci_hcd; modprobe uhci_hcd'. This used to happen with 2.6.9
> as well, but the system would recover after about 20 messages or so like this
> after a resume.
> 
> Any suggestions about where to look to track this down?

USB stuff should be discussed on the USB mailing list. Unload uhci_hcd
before suspend and reload it after resume to make sure it does not
interfere.

Check if 3c59x has suspend/resume support. If not, add it.

Panic... we really need to know why it panicked. VESAFB does not
support blanking, just switch to VESAFB and you should be able to see
the messages. 
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!