atom feed64 messages in org.freebsd.freebsd-archRe: Racing interrupts
FromSent OnAttachments
Warner LoshOct 23, 1999 11:08 pm 
Wes PetersOct 24, 1999 12:06 am 
Matthew JacobOct 24, 1999 8:25 pm 
Nate WilliamsOct 25, 1999 9:46 am 
Warner LoshOct 25, 1999 11:22 am 
Nate WilliamsOct 25, 1999 11:27 am 
Warner LoshOct 25, 1999 11:40 am 
Warner LoshOct 25, 1999 11:50 am 
Matthew JacobOct 25, 1999 11:52 am 
Nate WilliamsOct 25, 1999 11:57 am 
Nate WilliamsOct 25, 1999 12:02 pm 
Matthew JacobOct 25, 1999 12:12 pm 
Nate WilliamsOct 25, 1999 12:14 pm 
Matthew JacobOct 25, 1999 12:15 pm 
Nate WilliamsOct 25, 1999 12:20 pm 
Matthew JacobOct 25, 1999 12:35 pm 
Warner LoshOct 25, 1999 12:46 pm 
Matthew JacobOct 25, 1999 12:49 pm 
Terry LambertOct 25, 1999 5:55 pm 
Terry LambertOct 25, 1999 6:03 pm 
Nate WilliamsOct 25, 1999 6:04 pm 
Terry LambertOct 25, 1999 6:09 pm 
Terry LambertOct 25, 1999 6:12 pm 
Terry LambertOct 25, 1999 7:20 pm 
Nate WilliamsOct 25, 1999 8:55 pm 
Wes PetersOct 25, 1999 9:54 pm 
Randell JesupOct 26, 1999 4:13 am 
Nate WilliamsOct 26, 1999 8:24 am 
Randell JesupOct 26, 1999 8:37 am 
Bill FumerolaOct 26, 1999 9:06 am 
Wes PetersOct 26, 1999 11:27 am 
Nate WilliamsOct 26, 1999 1:07 pm 
Wes PetersOct 26, 1999 1:08 pm 
Terry LambertOct 26, 1999 6:40 pm 
Terry LambertOct 26, 1999 6:48 pm 
Nate WilliamsOct 26, 1999 7:01 pm 
Nate WilliamsOct 26, 1999 7:03 pm 
Warner LoshOct 26, 1999 7:58 pm 
Christopher MastoOct 27, 1999 1:04 am 
Daniel O'ConnorOct 27, 1999 1:11 am 
Warner LoshOct 27, 1999 9:27 am 
Nate WilliamsOct 27, 1999 10:03 am 
Warner LoshOct 27, 1999 10:11 am 
Wes PetersOct 27, 1999 10:16 am 
Nate WilliamsOct 27, 1999 10:17 am 
Warner LoshOct 27, 1999 10:20 am 
Nate WilliamsOct 27, 1999 10:32 am 
Warner LoshOct 27, 1999 10:39 am 
Wes PetersOct 27, 1999 10:48 am 
Christopher MastoOct 27, 1999 11:34 am 
Warner LoshOct 27, 1999 11:57 am 
Daniel O'ConnorOct 27, 1999 5:33 pm 
Warner LoshOct 27, 1999 8:35 pm 
Daniel O'ConnorOct 27, 1999 8:38 pm 
Wes PetersOct 28, 1999 1:23 pm 
Terry LambertOct 29, 1999 9:56 am 
Nate WilliamsOct 29, 1999 11:51 am 
Terry LambertOct 30, 1999 2:23 pm 
Terry LambertOct 30, 1999 2:26 pm 
Nate WilliamsOct 30, 1999 3:09 pm 
Wes PetersOct 30, 1999 5:04 pm 
Warner LoshOct 30, 1999 10:31 pm 
Terry LambertNov 1, 1999 12:11 pm 
Warner LoshNov 1, 1999 2:35 pm 
Subject:Re: Racing interrupts
From:Terry Lambert (tlam@primenet.com)
Date:Oct 25, 1999 6:03:23 pm
List:org.freebsd.freebsd-arch

This is one reason that I want each driver in its own thread and that the interrupt that says the card is gone to effectively do a longjump to a "You are now gone, don't touch hardware, but cleanup the best you can" routine. However, I'm not sure what this would do to driver complexity.

According to Sean Fagan, Stratus did in fact go to these kinds of lengths to make suspend/resume*insert/eject work, but it required re-writing/re-coding all of the drivers to support.

It's certainly not impossible, but it does make the drivers that much more complex. And, (not to disagree with Sean), I don't see how you fix all the problems, simply because at some point you must assume the hardware exists, and if it disappears in the middle of an operation without any way of knowing that it's gone, how can you recover from it?

When someone removes the bridge away from you while you're walking across the chasm, how can you be expected to 'recover' from it? ;)

In a puff of greasy orange smoke, you appear at the side of the chasm you just left before the bridge went away. 8-).

I really, really don't think there are that many drivers, especially for PCCARD/PCMCIA attached devices, that keep a whole heck of a lot of state, and so I think the impact on the drivers would be rather small, actually.

For drivers that have a lot of state -- well, what the heck do they need all that state for, it makes things difficult for kernel/driver CPU rentrancy! Even so, I think a 32 bit value capable of tracking the state transitions, and checkpointing of dangling pointers into volatile variables before they are made to dangle, should be enough.

Really the only state that you need to recover is state in objects that are owned by the system (e.g. mbuf's, etc.) that you need to recover for a "nice" shutdown.

In many cases, you could intentionally "leak", as an intentional strategy, until the drivers are brought up to spec. (I dislike this, since it seems rather "Windowsy", but it would work as a short term bridge solution).

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message