It appears as if some of these items are related to your discussion of where to call tsc_resume. I am more than willing to sponsor whatever fixes you might have.
On Tue, 14 Oct 2008, J?rgen Keil wrote: > > So question 1: What are the local changes? > > Certainly, if they are useful to the OS, we should get them > > incorporated as soon as possible. > > I have changes for the issues mentioned in bug 6758678 > > - the kernel hangs on S3 suspend, somewhere in the ata driver > > http://mail.opensolaris.org/pipermail/driver-discuss/2007-October/004603.html > I'll have to re-test if this fix is really needed, but I think it is... > > - the kernel hangs on S3 suppend with an uhci interrupt storm > that got broken after the putback for > 6681221 "Solaris hangs during early boot when EHCI-2 is enabled from BIOS" > I changed the uhci_cpr_suspend() code to fix this... > > - s3 suspend/resume must save / restore the state of the legacy pic > (the toshiba tecra s1 is an uppc machine) > > 6726128 "UPPC IBM Thinkpad Type 2327 panics in resume when interrupts are > restored" > 6652275 "32bit #df double fault traps broken, after 6624280" > > I add save / restore code for the legacy pic to the uppc module. > > - ipw2100 wlan driver is missing suspend / resume support > I added suspend / resume support to ipw. > > - iprb nic driver is missing suspend / resume support > I can't fix this, no open source for iprb > (so I have to use -B disable-iprb=true) > > - the notebook frequently hangs after resume, on the second suspend/resume > cycle > Problem with clock interrupts enabled too early, before tsc_resume() was > called? > > - ata0 "timeout: abort request" errors for PATA HDD after S3 resume > It seems these putbacks are supposed to fix such an issue, > but it doesn't work in the Tecra S1? > 6753758 ata driver doesn't work in snv_99 (older systems only?) > 6752338 ata driver hangs in b99 on Toshiba Tecra A9 > > Problem is that the ata device appear to be already > using [MU]DMA mode, so no command is sent to the device > to enable dma mode. It I force sending a "set dma mode" > command to the drive, it works. > > But I'll have to do a few more tests here... > > > Question 2: what was the value of the TOD and > > gethrtime() before and after s/r, as well as the approximate sleep time? > > IIRC, it complained that the TOD jumped by roughly the number > of seconds that we have been sleeping in S3. I.e. with an automatic > acpi S3 wakeup of "acpi_rtc_wake = 5" seconds, it complained that > the TOD jumped by 0x7 seconds. > > I'lll have to do a few more tests, but I think the root cause could be > that I get cbe_fire() clock interrupt too early during resume, before > tsc_resume() has run. Based on this description, that would be my guess as well (the first effectively sees the suspend time, and the next fire sees a large jump as time catches up to what it should be). What I would like to do, however, is to find out how many of the above fixes is not only still valid, but are ready for a push now. ---- Randy
