On Sunday 19 October 2008 14:01:49 Denys Vlasenko wrote:
> > > > If one runs Linux on such a system with HZ=100, poll() with timeout
> > > > of 10ms is basically a "one timer tick timeout". I don't know how
> > > > precise it can be.
> >
> > Sleeps in the linux kernel can never return early unless
On Sunday 19 October 2008 13:59:55 Denys Vlasenko wrote:
> On Sunday 19 October 2008 06:22:37 am Rob Landley wrote:
> > Heh, ok, now I found the message. (Just because I'm paying attention to
> > the busybox list again doesn't mean I've got my mail filters set up right
> > yet. :)
> >
> > > But sc
On Friday 17 October 2008 01:04:35 pm Rob Landley wrote:
> > Also, I don't understand the problem with poll potentially waiting
> > longer that specified under heavy load. If poll really waits longer, it
> > is more likely that additional data has arrived in this time, not less
> > likely.
>
> Yea
On Sunday 19 October 2008 05:16:13 am Rob Landley wrote:
> On Saturday 18 October 2008 16:06:22 Ralf Friedl wrote:
> > Denys Vlasenko wrote:
> > > I think scheduler is at play here.
> > > Imagine a low-end system (say ~100MHz cpu) with rather poor capabilities
> > > wrt measuring time. No microseco
On Sunday 19 October 2008 06:22:37 am Rob Landley wrote:
> Heh, ok, now I found the message. (Just because I'm paying attention to the
> busybox list again doesn't mean I've got my mail filters set up right yet. :)
>
> > But scheduling in the sender can.
>
> The sender almost certainly is using
Heh, ok, now I found the message. (Just because I'm paying attention to the
busybox list again doesn't mean I've got my mail filters set up right yet. :)
> But scheduling in the sender can.
The sender almost certainly is using something like a 16550a UART, which has a
16 byte output buffer. (
On Saturday 18 October 2008 16:06:22 Ralf Friedl wrote:
> Denys Vlasenko wrote:
> > I think scheduler is at play here.
> > Imagine a low-end system (say ~100MHz cpu) with rather poor capabilities
> > wrt measuring time. No microsecond clock, just timer interrupts.
I don't seem to have gotten the o
Denys Vlasenko wrote:
> I think scheduler is at play here.
> Imagine a low-end system (say ~100MHz cpu) with rather poor capabilities
> wrt measuring time. No microsecond clock, just timer interrupts.
>
> If one runs Linux on such a system with HZ=100, poll() with timeout of 10ms
> is basically a "
On Friday 17 October 2008 04:30:48 am Rob Landley wrote:
> > If you got an ESC, next char is delayed by 8ms by serial line and you
> > are scheduled away in poll(), there is no guarantee you come back
> > 25ms and not 25s later.
>
> Sure, but the data will have come in to the kernel and be queued,
On Thursday 16 October 2008 10:16:19 Ralf Friedl wrote:
> I had the impression that original problem was when an ESC-sequence
> crossed the input buffer, not that it had something to do with the
> timeout after the ESC.
> So is this whole discussion now about a different, but related problem?
The
On Thursday 16 October 2008 04:47:37 Denys Vlasenko wrote:
> On Thursday 16 October 2008 08:38:41 am Rob Landley wrote:
> > On Wednesday 15 October 2008 11:36:19 Rob Landley wrote:
> > > I think I can work out a test for this (write a script suspending the
> > > qemu process with "while true; do ki
I had the impression that original problem was when an ESC-sequence
crossed the input buffer, not that it had something to do with the
timeout after the ESC.
So is this whole discussion now about a different, but related problem?
Also, I don't understand the problem with poll potentially waiting
On Thursday 16 October 2008 08:38:41 am Rob Landley wrote:
> On Wednesday 15 October 2008 11:36:19 Rob Landley wrote:
> > I think I can work out a test for this (write a script suspending the qemu
> > process with "while true; do kill -STOP $PID; sleep 1; kill -CONT $PID;
> > sleep 1; done" and the
On Wednesday 15 October 2008 11:36:19 Rob Landley wrote:
> I think I can work out a test for this (write a script suspending the qemu
> process with "while true; do kill -STOP $PID; sleep 1; kill -CONT $PID;
> sleep 1; done" and then hold down "cursor left" in vi for a couple minutes
> and see if i
On Tuesday 14 October 2008 05:34:46 Roberto A. Foglietta wrote:
> 2008/10/14 Denys Vlasenko <[EMAIL PROTECTED]>:
> > On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote:
> >> On Sunday 12 October 2008 23:48:22 Rob Landley wrote:
> >> > Next time it reads a buffer, it starts with the last chara
2008/10/14 Alessandro Rubini <[EMAIL PROTECTED]>:
>
>> Ok, making poll wait 300 miliseconds before deciding there's no next
>> character
>> in a pending escape sequence seems to have fixed it. (At least I can't
>> reproduce the problem under qemu anymore.) The downside is that when you hit
>> es
2008/10/14 Rob Landley <[EMAIL PROTECTED]>:
> On Tuesday 14 October 2008 05:18:44 Denys Vlasenko wrote:
>> On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote:
>> > On Sunday 12 October 2008 23:48:22 Rob Landley wrote:
>> > > Next time it reads a buffer, it starts with the last character of a
On Tuesday 14 October 2008 05:18:44 Denys Vlasenko wrote:
> On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote:
> > On Sunday 12 October 2008 23:48:22 Rob Landley wrote:
> > > Next time it reads a buffer, it starts with the last character of a
> > > cursor left sequence: capital D. Capital D
On Tuesday 14 October 2008 01:01:26 pm Roberto A. Foglietta wrote:
> 2008/10/14 Roberto A. Foglietta <[EMAIL PROTECTED]>:
> Ok, making poll wait 300 miliseconds before deciding there's no next
> character
> in a pending escape sequence seems to have fixed it. (At least I can't
> >>
2008/10/14 Roberto A. Foglietta <[EMAIL PROTECTED]>:
> 2008/10/14 Roberto A. Foglietta <[EMAIL PROTECTED]>:
>> 2008/10/14 Denys Vlasenko <[EMAIL PROTECTED]>:
>>> On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote:
On Sunday 12 October 2008 23:48:22 Rob Landley wrote:
> Next time it
2008/10/14 Roberto A. Foglietta <[EMAIL PROTECTED]>:
> 2008/10/14 Denys Vlasenko <[EMAIL PROTECTED]>:
>> On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote:
>>> On Sunday 12 October 2008 23:48:22 Rob Landley wrote:
>>> > Next time it reads a buffer, it starts with the last character of a curs
2008/10/14 Denys Vlasenko <[EMAIL PROTECTED]>:
> On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote:
>> On Sunday 12 October 2008 23:48:22 Rob Landley wrote:
>> > Next time it reads a buffer, it starts with the last character of a cursor
>> > left sequence: capital D. Capital D is "delete to
On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote:
> On Sunday 12 October 2008 23:48:22 Rob Landley wrote:
> > Next time it reads a buffer, it starts with the last character of a cursor
> > left sequence: capital D. Capital D is "delete to end of line", which it
> > does.
> >
> > So basical
On Monday 13 October 2008 06:48:22 am Rob Landley wrote:
> If you use the cursor keys in vi, it adds three characters at a time. (The
> ansi "move cursor" sequence for the direction you hit.) If you hold it down
> so it repeats, on a slow system (such as qemu's arm emulation) or one that's
> h
2008/10/14 Alessandro Rubini <[EMAIL PROTECTED]>:
>
>> Ok, making poll wait 300 miliseconds before deciding there's no next
>> character
>> in a pending escape sequence seems to have fixed it. (At least I can't
>> reproduce the problem under qemu anymore.) The downside is that when you hit
>> es
> Ok, making poll wait 300 miliseconds before deciding there's no next
> character
> in a pending escape sequence seems to have fixed it. (At least I can't
> reproduce the problem under qemu anymore.) The downside is that when you hit
> escape with nothing after it, the gui won't update for
On Sunday 12 October 2008 23:48:22 Rob Landley wrote:
> Next time it reads a buffer, it starts with the last character of a cursor
> left sequence: capital D. Capital D is "delete to end of line", which it
> does.
>
> So basically, busybox vi is corrupting your data when you cursor around in
> a f
If you use the cursor keys in vi, it adds three characters at a time. (The
ansi "move cursor" sequence for the direction you hit.) If you hold it down
so it repeats, on a slow system (such as qemu's arm emulation) or one that's
heavily loaded, you can easily have several of them queue up befor
28 matches
Mail list logo
