Messages in this thread | | | Date | Thu, 31 May 2007 23:22:56 +0400 | From | Oleg Nesterov <> | Subject | Re: floppy.c soft lockup |
| |
On 05/31, Mark Hounschell wrote: > > Oleg Nesterov wrote: > > On 05/31, Mark Hounschell wrote: > >> > >> Basically the main RT-process (which is a CPU bound process on processor-2) signals a > >> thread to do some I/O. That RT-thread (running on the other processor) does a simple > > > > If the main RT-process monopolizes processor-2, flush_workqueue() (or cancel_work_sync()) > > can hang of course, we can do nothing. > > > >> ioctl(Q->DevSpec1, FDSETPRM, &medprm) > >> > >> and there is no return from the call. That thread is hung. > > > > What happens if you kill the main RT-process? > > > > When I kill the main process all its threads also go away. Including the floppy thread. > Nothing notable happens with this kernel.
Aha, I missed the word "thread", this is the single process.
Still, this means that flush_workqueue() completes when other sub-threads go away, otherwise the thread doing ioctl() couldn't exit.
Thank you very much.
So, the main question is: is it possible that one of RT processes/threads pins itself to some CPU and eats 100% cpu power?
> On previous (2.6.18) I would get a dump > from the floppy driver in the syslog when I killed the process.
Could you send me this output? just in case...
> > --- OLD/drivers/block/floppy.c~ 2007-04-03 13:04:58.000000000 +0400 > > +++ OLD/drivers/block/floppy.c 2007-05-31 20:50:18.000000000 +0400 > > @@ -862,6 +862,8 @@ static void set_fdc(int drive) > > FDCS->reset = 1; > > } > > > > +static DECLARE_WORK(floppy_work, NULL); > > + > > /* locks the driver */ > > static int _lock_fdc(int drive, int interruptible, int line) > > { > > @@ -893,7 +895,7 @@ static int _lock_fdc(int drive, int inte > > set_current_state(TASK_RUNNING); > > remove_wait_queue(&fdc_wait, &wait); > > > > - flush_scheduled_work(); > > + cancel_work_sync(&floppy_work); > > } > > command_status = FD_COMMAND_NONE; > > > > @@ -992,8 +994,6 @@ static void empty(void) > > { > > } > > > > -static DECLARE_WORK(floppy_work, NULL); > > - > > static void schedule_bh(void (*handler) (void)) > > { > > PREPARE_WORK(&floppy_work, (work_func_t)handler); > > > > The patch does make it work.
I do not understand floppy.c, absolutely, so I am not sure this patch is correct.
Even if correct, this patch doesn't solve this problem (if we really understand what's going on). cancel_work_sync() may still hang if floppy_work->func() runs on the starved CPU. This is unlikely, but possible.
Thanks!
Oleg.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |