Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Nov 1999 11:31:30 -0800
From:      Darryl Okahata <darrylo@sr.hp.com>
To:        freebsd-mobile@freebsd.org
Subject:   Solved?  APM needs to reinitialize disks? [ Was: Hibernation & Phoenix Notebios??? ]
Message-ID:  <199911041931.LAA29856@mina.sr.hp.com>
In-Reply-To: Your message of "Mon, 01 Nov 1999 19:08:18 PST." <199911020308.TAA18976@mina.sr.hp.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
     Well, I think my problem is that my particular Phoenix NoteBIOS
(v4.0) does not reinitialize the disks after a resume.  Taking a hint
from a Linux posting:

	http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=414363036

I added some code to FreeBSD to reinitialize the disks at resume time.
After doing so, my hibernation problems went away.  Both
hibernation/suspend-to-disk and plain suspend now appear to work fine,
although I have not yet tried this with X-Windows to see if I have the
X-Windows video suspend bug.

     Unfortunately, I really don't have any patches.  I basically used a 
sledgehammer to test my theory, and so it's not in a state that people
can generally use (also, I suspect there are bugs).  However, if someone
wants to fix this right (I'm not sure I know enough to properly fix
this), I'm going to describe what I did:

1. Add the following function to sys/i386/isa/wd.c:

	void wdunwedgeall (void)
	{
		struct disk *du1;
		int	lunit;
	
		for (lunit = 0; lunit < NWD; lunit++)
			if ((du1 = wddrives[lunit]) != NULL
			    && du1->dk_state > WANTOPEN)
				du1->dk_state = WANTOPEN;
	
		DELAY(RECOVERYTIME);
	}

   This is a simple variant of the wdunwedge() function in the same
   file.

2. Call wdunwedgeall() from apm_default_resume() in sys/i386/apm/apm.c.
   This isn't the correct place to do this.  I think the correct method
   is to use apm_hook_establish().

3. That's basically it.

However, I think the above function, wdunwedgeall(), may have
bugs/issues:

* Suspending during disk I/O may cause a crash or data corruption at
  resume time.  I'm not sure how the resume hooks are called with
  respect to the disk I/O functions.  If the resume hooks are always
  called before any disk I/O is done, the comment in wd.c:wdunwedge()
  about unexpected state changes *might* also apply here; if the resume
  hooks aren't always called before disk I/O, the system will still
  corrupt data and crash.

* DELAY(RECOVERYTIME) may be unnecessary.

* Not everyone needs this, and so it should be made into some kind of
  kernel option.

--
	Darryl Okahata
	darrylo@sr.hp.com

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911041931.LAA29856>