From owner-freebsd-mobile Sat Oct 25 09:47:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10408 for mobile-outgoing; Sat, 25 Oct 1997 09:47:35 -0700 (PDT) (envelope-from owner-freebsd-mobile) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10403 for ; Sat, 25 Oct 1997 09:47:31 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id KAA28413; Sat, 25 Oct 1997 10:47:28 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA24291; Sat, 25 Oct 1997 10:47:26 -0600 (MDT) Date: Sat, 25 Oct 1997 10:47:26 -0600 (MDT) Message-Id: <199710251647.KAA24291@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mike Smith Cc: Nate Williams , mobile@freebsd.org Subject: Re: Patches from -current for -stable I'd like to commit after testing In-Reply-To: <199710250735.RAA00394@word.smith.net.au> References: <199710241643.KAA20805@rocky.mt.sri.com> <199710250735.RAA00394@word.smith.net.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > ie. the mini-probe > > > is basically going to run the probe and then attach routines again? > > > > Just the probe, not the attach. > > Then my basic gripe remains; in the ethernet case, if I pull card A and > replace with card B of the same type, the arp code will be confused > (wrong MAC address). UTSL. Again, it's a non-issue. > > > (Do you have to do this anyway, to get the PCCARD back to a known > > > state?) > > > > Well, there's the issue, and the answer is 'maybe so, I'm not sure'. I > > don't *think* so, but it may require it. I'm playing with some code to > > try and not require it. I know the linux code doesn't try to save the > > state, and instead does what the apm_pccard_resume code does. (Which > > isn't necessarily a bad thing.) However, I'm not sure what the other > > OS's do (NetBSD for example). Win95 appears to 'suspend/resume' the > > card, although it may just be the 'appearances', and not how it's > > actually implemented under the hood. > > I think that caching "what was in the slot" at a lower level would be > good, but that means moving the CIS parser inside the kernel. I don't think so. *However*, in the tests that I've been performing, on my box if I suspend I lose the port mapping, so I must re-initialize them on the port when we come up, then do the mini-probe (since it fails right now.) More later... Nate