On Sun, Mar 25, 2001 at 11:10:14PM +, Pavel Machek wrote:
> I've seen similar bugs. If you hook something on schedule_tq and forget
> to set current->need_resched, this is exactly what you get.
keventd fixes tq_scheduler case (tq_scheduler is dead).
Andrea
-
To unsubscribe from this list: se
From: <[EMAIL PROTECTED]>
To: "Manfred Spraul" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, April 08, 2001 7:58 PM
Subject: Re: softirq buggy [Re: Serial port latency]
> Hello!
>
> > But with a huge overhead. I'd prefer to call it dir
Hello!
> But with a huge overhead. I'd prefer to call it directly from within the
> idle functions, the overhead of schedule is IMHO too high.
+ if (current->need_resched) {
+ return 0;
+ }
+ if (softirq_active(smp_processor_id()) & softi
From: <[EMAIL PROTECTED]>
> Hello!
>
> > + if (softirq_active(smp_processor_id()) &
softirq_mask(smp_processor_id())) {
> > + do_softirq();
> > + return 0;
>
> BTW you may delete do_softirq()... schedule() will call this.
>
But with a huge overhead. I'd prefer to call it directly from within the
Hello!
> + if (softirq_active(smp_processor_id()) & softirq_mask(smp_processor_id())) {
> + do_softirq();
> + return 0;
BTW you may delete do_softirq()... schedule() will call this.
> + *
> + * Isn't this identical to default_idle with the 'no-hlt' boot
> + * option
Pavel Machek wrote:
>
> Ok. I was missing the fact it is checked on going userspace.
>
What about the attached patch?
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 3
// EXTRAVERSION = -ac3
--- 2.4/include/linux/interrupt.h Thu Feb 22
Hi!
> > > Ok, there are 2 bugs that are (afaics) impossible to fix without
> > > checking for pending softirq's in cpu_idle():
> > >
> > > a)
> > > queue_task(my_task1, tq_immediate);
> > > mark_bh();
> > > schedule();
> > > ;within schedule: do_softirq()
> > > ;within my_task1:
> > > mark_bh();
From: "Pavel Machek" <[EMAIL PROTECTED]>
>
> > Ok, there are 2 bugs that are (afaics) impossible to fix without
> > checking for pending softirq's in cpu_idle():
> >
> > a)
> > queue_task(my_task1, tq_immediate);
> > mark_bh();
> > schedule();
> > ;within schedule: do_softirq()
> > ;within my_task
Hi!
> > Seems floppy and console is buggy, then.
> >
>
> No. The softirq implementation is buggy.
> I can trigger the problem with the TASKLET_HI (floppy), and both net rx
> and tx (ping -l)
>
> > > What about creating a special cpu_is_idle() function that the idle
> > > functions must call bef
Pavel Machek wrote:
>
> > >
> > > I've seen similar bugs. If you hook something on schedule_tq and
> > forget
> > > to set current->need_resched, this is exactly what you get.
> > >
> > I'm running with a patch that printk's if cpu_idle() is called while a
> > softirq is pending.
> > If I access
Hi!
> > > Is the computer otherwise idle?
> > > I've seen one unexplainable report with atm problems that
> disappeared
> > > (!) if a kernel compile was running.
> >
> > I've seen similar bugs. If you hook something on schedule_tq and
> forget
> > to set current->need_resched, this is exactly wh
From: "Pavel Machek" <[EMAIL PROTECTED]>
> > Is the computer otherwise idle?
> > I've seen one unexplainable report with atm problems that
disappeared
> > (!) if a kernel compile was running.
>
> I've seen similar bugs. If you hook something on schedule_tq and
forget
> to set current->need_resched
Hi!
> Is the computer otherwise idle?
> I've seen one unexplainable report with atm problems that disappeared
> (!) if a kernel compile was running.
I've seen similar bugs. If you hook something on schedule_tq and forget
to set current->need_resched, this is exactly what you get.
--
Philips Vel
Problem solved !
The main problem was that I didn't know that the equipment used
DTR as character acknowledge (not RTS/CTS which is common for flow
control). I didn't even bother to look at those lines with the
oscilloscope. Now the software runs fine with negligible latency.
Now the total laten
Hi!
> My program controls a device (a programmer for microcontrollers) via the
> serial port. The program sits in a tight loop, writing a few (typical 6)
> bytes to the port, and waits for a few (typ. two) bytes to be returned from
> the programmer.
>
> The program works, but it is very slow. I
On Thu, Mar 22, 2001 at 09:32:39PM +0100, Geir Thomassen wrote:
>
> The serial port chip is 16550A, which has a built in fifo. Can this be
> the source of my problems ?
Well, if you set the uart to be 16450 using setserial, this will cause
Linux to avoid enabling the FIFO. That will cause the l
>This is what the program does:
>
> fd=open("/dev/ttyS0",O_NOCTTY | O_RDWR);
>
> tcsetattr(fd,TCSANOW, &tio); /* setting baud, parity, raw mode, etc */
>
> while() {
> write( 6 bytes); /* send command */
> read( 2 bytes);/* wait for reply */
> }
What
Is the computer otherwise idle?
I've seen one unexplainable report with atm problems that disappeared
(!) if a kernel compile was running.
Could you try to run a simple cpu hog (with nice 20)?
<<
main()
{
for(;;) getpid();
}
<<
I'm aware of one bug that could cause a delay of up to 20 ms (c
Jim Penny wrote:
>
> On Thu, Mar 22, 2001 at 07:21:28PM +0100, Geir Thomassen wrote:
> > My program controls a device (a programmer for microcontrollers) via the
> > serial port. The program sits in a tight loop, writing a few (typical 6)
> > bytes to the port, and waits for a few (typ. two) byte
> The serial port chip is 16550A, which has a built in fifo. Can this be
> the source of my problems ?
>
> Geir
I thought about that. If the number of receive bytes in the RX FIFO
is less that the trigger level then a timeout has to occur before
getting the next receive data interrupt.
The 1655
Theodore Tso wrote:
>
> On Thu, Mar 22, 2001 at 07:21:28PM +0100, Geir Thomassen wrote:
> > My program controls a device (a programmer for microcontrollers) via the
> > serial port. The program sits in a tight loop, writing a few (typical 6)
> > bytes to the port, and waits for a few (typ. two) b
Trent Jarvi wrote:
>
> Hi,
>
> I'm not on the kernel list. I just ran across your email while looking at the
> weekly archive.
>
> I think you want to enable software flow control.
>
> tcgetattr( fd, &ttyset );
> ttyset.c_iflag |= IXOFF;
> tcsetattr( fd, TCSANOW, &ttys
On Thu, 22 Mar 2001, Geir Thomassen wrote:
> Trent Jarvi wrote:
> >
> > Hi,
> >
> > I'm not on the kernel list. I just ran across your email while looking at the
> > weekly archive.
> >
> > I think you want to enable software flow control.
> >
> > tcgetattr( fd, &ttyset );
> >
On Thu, Mar 22, 2001 at 07:21:28PM +0100, Geir Thomassen wrote:
> My program controls a device (a programmer for microcontrollers) via the
> serial port. The program sits in a tight loop, writing a few (typical 6)
> bytes to the port, and waits for a few (typ. two) bytes to be returned from
> the
Hi.
My program controls a device (a programmer for microcontrollers) via the
serial port. The program sits in a tight loop, writing a few (typical 6)
bytes to the port, and waits for a few (typ. two) bytes to be returned from
the programmer.
The program works, but it is very slow. I use an osc
25 matches
Mail list logo
