On Tue, Jul 28, 2009 at 19:44:48, Young, Joseph wrote:
> Hello all,
>
> I am porting the Davinci linux kernel to another architecture, called
> Jacinto2. I've had several problems with the scheduler that I think may
> be related to each other.
>
> The first was located in drivers/char/tty_buffer.c. What occurred was
> that the kernel would boot as far as the shell, but the keyboard would
> not take any input. The serial buffer was indeed receiving characters,
> but for some reason the tty_buffer was not passing them to user space.
>
> The temporary workaround I used was located in the function
> "tty_flip_buffer_push" in tty_buffer.c.
> If the tty had the low latency flag, it would immediately push the
> characters to the line descriptor. However, my kernel was taking the
> other branch, and passing the flush to the scheduler with
> "schedule_delayed_work" as seen below:
>
> if (tty->low_latency)
> flush_to_ldisc(&tty->buf.work.work);
> else
> schedule_delayed_work(&tty->buf.work, 1);
>
> When schedule_delayed_work was called, the kernel would never come back
> to the process that was scheduled, and so I had no keyboard input. My
> workaround was to hard code it to always call flush_to_ldisc. However, I
> think this is a poor fix because it may cause starvation of other
> processes, because the serial input buffer now operates in real-time and
> is very low priority compared to other operations.
>
> The second problem that I had was with the MMC/SD driver I was porting.
> In the file /drivers/mmc/core/core.c, during the function mmc_power_up,
> the mmc_delay function would be called (located in core.h). Tracing
> this, mmc_delay called msleep (in kernel/timer.c) which eventually
> called schedule_timeout. Once again, the scheduler would put the MMC
> setup in the waiting queue for 10mS, and move onto the next driver to
> initialize, but never come back to the MMC setup, so the driver would
> not function.
>
> My workaround here was to change the original mmc_delay function, shown
> below, to always take the first branch and use mdelay, instead of
> calling msleep.
>
> if (ms < 1000 / HZ) {
> cond_resched();
> mdelay(ms);
> }
> else
> msleep(ms);
>
> Once again, this seems to be a poor fix, because mdelay is a
> cycle-wasting loop, while msleep utilizes the scheduler. Plus, I really
> would like to have a working scheduler in my linux kernel. :-p
>
> Has anyone seen any problems with the scheduler like this? Is there a
> strange .config option I am missing? I assume this is a new bug on my
> architecture which became introduced when I was porting to the Jacinto2
> architecture.
> Does anyone have any suggestions, insight, or ideas on ways to fix this
> bug?
Joe,
I will take a guess that the timer interrupt is not
functioning well.
Can you configure out options like CONFIG_NO_HZ to keep
things simple? Then you can check if you have a regular
timer interrupt by monitoring /proc/interrupts.
Thanks,
Sekhar
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
