Date: Thu, 23 Oct 1997 00:56:15 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Mike Smith <mike@smith.net.au> Cc: Nate Williams <nate@mt.sri.com>, mobile@freebsd.org Subject: Re: Patches from -current for -stable I'd like to commit after testing Message-ID: <199710230656.AAA13857@rocky.mt.sri.com> In-Reply-To: <199710230644.QAA00413@word.smith.net.au> References: <199710230556.XAA13744@rocky.mt.sri.com> <199710230644.QAA00413@word.smith.net.au>
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? Given the # of TP560's in the ranks of the developers, I figured breaking what appears to be the most popular laptops seemed a bad things to do. > 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. Yep. Sounds like a job for 'Laptop-Mike'. The hooks are are there in pcic.c:build_freelist. :) > > > 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. So, cards that previously worked with these two interrupts no longer work? *dang* > 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. Good (I think??). > > > 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. I don't remember my "hiding the 'interrupt configuration' messages" changes. Or at least that's not how I think of them, so I'm not sure what changes I made you're talking about. > > 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. Do you have a 3.0 box, or is it now running 2.2? The changes will initially be made to 3.0, since it's already (apparently) broken there. (Although, I'm hoping that it may have been fixed by backing out the change....) If you want them for 2.2, I can make them there as well, although I can't test them on my laptop. :( Finally, any help you can give to figuring out why the current code is not working on your laptop, or better yet a pointer to the code that breaks it would be greatly appreciated. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710230656.AAA13857>