Date: Wed, 01 Dec 1999 12:10:20 -0800 From: Mike Smith <msmith@freebsd.org> To: Warner Losh <imp@village.org> Cc: mobile@FreeBSD.org Subject: Re: cvs commit: src/sys/pccard pccard.c src/sys/isa sio.c src/sys/dev/ed if_ed_pccard.c src/sys/dev/ep if_ep_pccard.c Message-ID: <199912012010.MAA00653@mass.cdrom.com> In-Reply-To: Your message of "Wed, 01 Dec 1999 09:00:12 MST." <199912011600.JAA02186@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199912010942.BAA00486@mass.cdrom.com> Mike Smith writes: > : > Fix the hang on card eject problem and maybe the hang on suspend > : > problem. > : > > : > o Create new timeout routine so we don't detach the card inside a ISR > : > but instead drop back to spl0 via a timeout of 0. > : > : This will still fail in most card-device interrupt handlers that don't > : spin-limit themselves. If at all possible, there should be a mechanism > : for a card-device interrupt handler to query the parent bus to determine > : whether the hardware has gone away. (This would allow the handler to bail > : out and let the detach code do its stuff if the handler is spinning madly.) > > I know this will still fail. This is at best a stop-gap approach. It > lessens the chance there will be a hang, but doesn't eliminate it. It doesn't lessen it very much, since when you pull the card you are 99% assured of an interrupt that will leave the card driver spinning in its interrupt handler. Thus the detach handler will never run... > The drivers themselves that support detach will somehow need to know > when they have been detached and check that. They cannot store this > in sotfc because that is automatically free'd when then instance is > detached. I'm thinking a small array of bits that are static to the > driver, one per instance. attach sets the bit, while detach clears > the bit. If someone wants to check the status, they look at the bit. That's not good enough, as I tried to outline in the last message; no cached state is ever going to help. The "is my card still here" test _must_ go all the way directly to the hardware. > Polling the actual card hardware is going to be gross and prone to > races since it would have to ask the bus if the child was still there, > but there is no longer a child handle. There will be a child handle until the card driver detach routine has returned and allowed the detach. The detach routine _must_ not allow the detach while the interrupt handler is running. > Also, there is no card > hardware anymore, so you can't ask it. The card hardware I'm referring to is the PCIC or equivalent. > I'm not sure how to solve this > problem generically, and we've had lots of flame wars about this > before. To be honest, I'm not interested in solving the problem in > the old pccard code at all. I wouldn't want you to waste your time on that, no. 8) > Spin limiters in the ISRs of drivers that support detach. Doing > thinks like sio does with sc->gone (w/o the softc) and other > techniques are going to be what is required to fix this. Again, soft state is not adequate. sc->gone can only be set if something preempts the spinning interrupt handler. In the old old code this only worked because the pcic interrupt handler wasn't masked, so the detach routine could preempt the device interrupt handler and set the gone flag. In the new code you _cannot_ free the softc until the interrupt handler has returned; you have no way of knowing where exactly that code is running and you can't expect it to atomically check the 'gone' flag every time before it dereferences the softc pointer. > I wanted to make things suck less, and this commit does that. I'm > under no illusions that it is perfect. I'm not bashing your attempt, just pointing out that it doesn't achieve very much at all due to the nature of the race. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912012010.MAA00653>