Date: Thu, 23 Oct 1997 16:14:44 +0930 From: Mike Smith <mike@smith.net.au> To: Nate Williams <nate@mt.sri.com> Cc: Mike Smith <mike@smith.net.au>, mobile@freebsd.org Subject: Re: Patches from -current for -stable I'd like to commit after testing Message-ID: <199710230644.QAA00413@word.smith.net.au> In-Reply-To: Your message of "Wed, 22 Oct 1997 23:56:33 CST." <199710230556.XAA13744@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Sure. Doesn't help though. 8( Allocating IRQ 11 to the pcic actually > > seems harmless; we still get card insertion/removal interrupts, so it > > must be working. > > OK, so that's not it. (Although it was on Brian Handy's TP560). Hmm. Maybe his *does* have something uncivilised on the high interrupt? It'd be nice to have a generic probe-time test-for-an-interrupt function, along the lines of what the sio(4) driver does to test the interrupt function of the 8250. > > Unfortunately I just get the dreaded "driver allocation failed for ..." > > messages, where I didn't before. > > Umm, if you're using IRQ 11, then I suspect your 3c589 card can't use it > for itself. Do you have your configuration hard-coded to use IRQ 11? > (I do, since I can't get it to work anywhere else for some silly > reason.) Sorry, I will clarify. There are two interrupts that I make available for PCCARDs, 9 and 10. These are declared in /etc/pccard.conf, and are not used by anything else in the system. Older kernels allocate IRQ 3 to the pcic, and the newer top-down code allocates IRQ 11. Both of these seem to work, insofar as card insertion/removal events are signalled as expected. > > The kernel that works predates your hiding of the "interrupt > > configuration" messages, if that's any help. > > I'm not sure I follow. I was just trying to give you a "feel" for the vintage of working kernel. I'm just cvsupping the 2.2.5 tag monster; once that's finished I'll be building a batch of kernels to see where things fell down. > Also note that I've made other changes recently > which shouldn't make things any worse, but should make suspend/resume > better in the default case. (More coming, I just did a code review and > want to try out some more 'new' changes on my laptop to see if they make > things better/worse.) Qool. If there's anything I can help with testing, let me know. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710230644.QAA00413>