From owner-freebsd-mobile Fri Jan 22 11:42:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00217 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 11:42:44 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA00212 for ; Fri, 22 Jan 1999 11:42:41 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA11270; Fri, 22 Jan 1999 12:40:05 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA22323; Fri, 22 Jan 1999 12:40:04 -0700 Date: Fri, 22 Jan 1999 12:40:04 -0700 Message-Id: <199901221940.MAA22323@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 , "Gary T. Corcoran" , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-Reply-To: <199901221930.LAA00927@dingo.cdrom.com> References: <199901221739.KAA21533@mt.sri.com> <199901221930.LAA00927@dingo.cdrom.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > Perhaps we're just looking at this the wrong way? We don't try to > > > > detect when floppies are stupidly removed, perhaps we shouldn't try to > > > > do it with pccard/cardbus cards either? > > > > > > > > Commentary? Are we trying too hard to do something that's not worth > > > > the effort? > > > > > > After following this thread, I've come to the conclusion that since > > > the PCIC hardware _is not designed_ to allow arbitrary card removal > > > (e.g. it doesn't auto-shutoff the IRQ line) > > > > Sure it does. IRQ's are no longer generated on that piece of hardware, > > but it's possible that the IRQ routine was in the middle of processing > > the previous (valid) IRQ that was generated 'just prior' to the removal. > > Uh, it's also possible for the removal itself to generate an interrupt > - I had this 100% repeatable on the Sharp I used to use. Right, but this does not work reliably on all PCIC controllers. It works on mine, but I know a number of controllers it does not work on (for whatever reason). > > > we're trying to come up > > > with, at best, a workaround, for something that the user _just shouldn't > > > do_. > > > > What users shouldn't do and what they actually do are too different > > things. 'But it works in Linux/Win95' is the response you'll get when > > you explain to them why they shouldn't yank their 'active' cards. > > > > (Although, as I understand it, Win98 no longer allows this and locks up > > the computer, unlike Win95. *Most* cards can be yanked under '95, but > > some can't.) > > The observation so far has been that Windows will lock up if you yank a > card on a machine that uses polling. I'm thinking now that we'd be > better off taking the hard line - the card must be shut off in software > before removing. Depends. Maybe Win98 now defaults to polling mode hen, since in Win95 with the same hardware it works, and it doesn't in Win98. (So I've heard, I've not had any direct experience with this). > > > In other words, just make sure mobile users know they _must_ > > > shutdown a card before removing it, and forget about trying to handle > > > stupid (or accidental) user actions. > > > > The use of the IRQ makes it less painful *IF* the user yanks their > > card. Is it worth making it easier? I don't know. > > That's it in a nutshell. You got it. If we've got the IRQ, we *can* make it safer. But, it doesn't work reliably on some hardware, and it 'wastes' an interrupt that might otherwise be used for something else. (I'm using the term 'waste' loosely here, since I think it makes the system more robust..) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message