On 8 May 2015 at 11:43, Mark Kettenis <mark.kette...@xs4all.nl> wrote: >> Date: Thu, 7 May 2015 20:58:53 +0200 >> From: Mike Belopuhov <m...@belopuhov.com> >> >> As I've pointed out before, on panic we can be running on any >> CPU and our disk controller's interrupts can interrupt on the >> other one. Since we'll most likely be holding a kernel lock, >> dealing with unlocking it might get hairy very fast. Instead >> what we could do to improve the chances of a clean shutdown on >> panic is to instruct our disk subsystem to do polled I/O that >> will be run on the same CPU with the panic. >> >> Initially I wanted to move "cold = 1" earlier in boot(), but >> after talking to Miod, it started to look like a bad idea. >> >> Thoughts? > > I'm not necessarily against forcing polled I/O in this case, but it > sucks a bit that we have to add checks in fairly low-level code to > accomplish this.
Yes, but it's the place where we make decision what kind of I/O we want to do. SCSI I/O path in the controller or stack never falls back to the polled I/O (unless it's a specific method, i.e. sddump). > And I'm not sure if disk I/O is the only thing that > we should worry about here. > What else? > I think tsleep(9) and msleep(9) need to release and re-acquire the > kernel lock in the "cold || panicstr" case. Well, it's not hard to do really, but... > We might need this for > handling interrupts during autoconf as soon as we start distributing > interrupts over CPUs. > ...cold might mean that interrupts are not ready yet. So then we might need another flag for shutdown?
