[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
You can ran into problems using schedule_timeout() in a block device request 
function under 2.4.

This can be demonstrated by starting some I/O intensive tasks to your block
device and running sync in another task. Eventually the block layer will
lock up.

This can be fixed by creating a kernel thread per flash device to handle
the I/O requests. Within the thread schedule_timeout() works fine. This
solution also works under 2.2 and 2.0.38 (David Woodhouse) said:

> said:
> > So it seems to be a bug at least in terms of timing. Unfortunately I
> > only got about 4 replies to the patches that touched 20+ drivers. I
> > suppose I should just hassle maintainers until they fix it or tell me
> > where I've gone wrong ...
> Actually, I was quite happy calling schedule_timeout in the flash drivers
> without changing current->state. I'm waiting to something to happen, and
> just to be considerate, I'm asking to be put to sleep for the 'expected'
> amount of time for whatever's happening. If there's other stuff on the run
> queue, it won't return immediately, will it? If there isn't other stuff on
> the run queue, I'll just busy wait till the flash chip's finished.
> Otherwise, it would be TASK_UNINTERRUPTIBLE.

Fireplug - a Lineo company _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <> 604-461-7532
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.019 / U:1.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site