Well, anyway, as far as I can tell, the following has been lost from
__make_request() in ll_rw_blk.c since the 2.4.0 days:
out:
- if (!q->plugged)
- (q->request_fn)(q);
if (freereq)
The result appears to be that if a block device has called
blk_queue_pluggable() to r
Sorry to repeat .. I didn't see this go out on the list and I haven't
had any reply. So let's ask again. Is this a new coding error in ll_rw_blk?
-
The following has been lost from __make_request() in ll_rw_blk.c since
2.4.2 (incl):
out:
- if (!q->plugged)
-
OK .. thanks Jens. Sorry about the repeat .. my nameserver lost its fix
on the root servers thanks to some hurried upgrades, and sendmail
started quietly bouncing mail for "not having" a dns entry, and you
know about deja. Probably the list dropped me for the bounces.
Those are my excuses. Apologi
"A month of sundays ago Jens Axboe wrote:"
> On Thu, Apr 19 2001, Peter T. Breuer wrote:
> > So the consensus is that I should enable plugging while the plugging
> > function is still here and do nothing when it goes? I must say I don't
> > think it should rea
"Jens Axboe wrote:"
> Examine _why_ you don't want plugging. In 2.2, you would have to edit
> the kernel manually to disable it for your device.
True. Except that I borrowed a major which already got that special
treatment.
>For 2.4, as long as
> there
OK - agreed. But while I have your attention...
"Jens Axboe wrote:"
> On the contrary, you are now given an exceptional opportunity to clean
> up your code and get rid of blk_queue_pluggable and your noop plugging
> function.
In summary: blk_queue_pluggable can be removed for all driver codes
ai
"Jens Axboe wrote:"
> [ptb wrote]
> > through merge_reqeusts function controls.
> > My unease derives, I think, from the fact that I have occasionally used
> > plugging for other purposes. Namely for throttling the device. These
> > uses have always been experimental and uniformly unsuccessful, be
More like "how does one get it to work".
Does anyone have a simple recipe for doing plugging right in 2.4?
I'm doing something wrong.
When I disable plugging on my block driver (by registering a no-op
plugging function), the driver works fine. In particular my end_request
code works fine - it d
"A month of sundays ago Jens Axboe wrote:"
> On Tue, Feb 20 2001, Peter T. Breuer wrote:
> > More like "how does one get it to work".
[snip muddy end_request code]
Probably. I decided that accuracy might get a better response, though
I did have to expand the macro
"A month of sundays ago Jens Axboe wrote:"
> Forgot to mention that the above doesn't make much sense at all. If
> there are no errors, you loop through ending all the buffers. Then
Yes, that's right, thanks. I know I do one more end_that_request_first
than is necessary, but it is harmless as the
"A month of sundays ago Jens Axboe wrote:"
> On Wed, Feb 21 2001, Peter T. Breuer wrote:
> > Hurrr ... are you saying that the buffers in the bh's in the request are
> > not contiguous? My reading of the make_request code in 2.2 was that
> > they were
"Jens Axboe wrote:"
> It will still cluster, the code above checks if the next bh is
> contigious -- if it isn't, then check if we can grow another segment.
> So you may be lucky that some buffer_heads in the chain are indeed
> contiguous, that's what the segment count is for. This is exactly
> t
"A month of sundays ago Jens Axboe wrote:"
> The implementation in ll_rw_blk.c (and other places) assumes that
> a failed request just means the first chunk and it then makes sense
> to just end i/o on that buffer and resetup the request for the next
> buffer. If you want to completely scrap the r
"Alan Cox wrote:"
> Doesnt seem very wild to me, but something did go back 3uS which would imply
> the CPU tsc's are not synched. 2.2 doesnt like that, Boot with 'notsc' and
> repeat the experiment
No change with that, as you already know. But I just noticed that the
ekernel was compiled for i38
I'm running an asus board with a pair of PIII 550s. gettimeofday is
varying wildly on the scale of a few seconds but is accurate over about
a minute, and sleep and hwclock are accurate.
#include
#include
main() {
while(1) {
struct timeval tv;
gettimeofday(&tv,NULL);
printf("%lu\n"
ACPI seemed a fine thing until I found that it doesn't allow for
hibernation or suspension of my laptop, and there is no way
(apparently) to turn it off at boot and let APM take over. Here's
a patch to allow "acpi=off" at boot. There's room for more parsing
in the code.
I didn't notice the proble
The following "sleep under spinlock" is still present as of linux
2.6.12.5 in sound/oss/sequencer.c in midi_outc:
n = 3 * HZ; /* Timeout */
spin_lock_irqsave(&lock,flags);
while (n && !midi_devs[dev]->outputc(dev, data)) {
interruptible_sleep_
"Also sprach Nish Aravamudan:"
> On 8/19/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> > On Gwe, 2005-08-19 at 10:13 +0200, Peter T. Breuer wrote:
> > > The following "sleep under spinlock" is still present as of linux
> > > 2.6.12.5 in sound/oss/
"A month of sundays ago Laramie Leavitt wrote:"
> I think that this is slightly off-topic, but I figure that
I'll second this one (waaay off topic for the kernel list,
but ...)
> someone here knows the answer or where to point me to the
> answer. Please respond privately so the entire list is n
"A month of sundays ago Alan Cox wrote:"
> > What IS the magic combination that makes select interruptible
> > by honest-to-goodness non-blocked signals!
> man
>
> [seriously man sigaction]
Equally seriously .. all signals are unblocked in my code and always
have been. The processes receive sign
"Mark Hahn wrote:"
> > while (1) {
> > int res = select(n,rfds,wfds,efds,&timeout);
> > if (res > 0)
> > return res;// data or error is expected
> > if (res == 0) {
> > return -ETIME; // tim
21 matches
Mail list logo
