Date: Sat, 25 Oct 1997 01:27:59 +0930 From: Mike Smith <mike@smith.net.au> To: Nate Williams <nate@mt.sri.com> Cc: mobile@freebsd.org Subject: Re: Patches from -current for -stable I'd like to commit after testing Message-ID: <199710241558.BAA00950@word.smith.net.au> In-Reply-To: Your message of "Fri, 24 Oct 1997 09:52:38 CST." <199710241552.JAA20521@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > > True, but if you could do a mini-probe (as the current code attempts to > > > do), then it should work. However, somehow things aren't yet 'enough' > > > alive when we call the mini-probe, so it doesn't work. > > > > Um, "mini-probe"? ie. "is what used to be there still there?" > > Yep. epinit(slot, int), where the int says 'is this the first time for > this device'. If the second parameter is 0, then it does a > 'mini-probe'. Not good enough. I take one card out and replace with a similar-but-different one (eg. two 3c589's, two NE2000's, etc.) The miniprobe will say "yes, it's the same", even though it's not. Yes, I'm being pathalogial about this. 8) > > > This is what the code that's enabled by apm_pccard_resume does (sort > > > of). Except that it fakes both remove/insertion at resume time. The > > > bad thing is that it requires that the pccard daemon be running for the > > > 'insertion' to be correctly done. > > > > Natch; it has to rummage the database somehow. How else would you get > > at this information? > > It's already all saved in the kernel now from when the card was > initially inserted. Only if the miniprobe succeeds. If it fails, you still need pccardd to handle a possible new device. I appreciate that the miniprobe is meant as a speed optimisation; I'm just not sure it's robust enough. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710241558.BAA00950>