Problem with Busybox shell

tiejun.chen tiejun.chen at
Thu Jan 20 13:11:11 EST 2011

MohanReddy koppula wrote:
> I further debugged and found that flush_to_ldisc() function is not
> called which actually wakes up the readers. This is a worker function
> and is not being scheduled. I suspected whether timer interrupts are
> generated or not. powerpc uses decrementer exceptions as timer
> interrupts. I see that timer_interrupt() function in
> arch/powerpc/kernel/time.c is not called at all. I printed even
> jiffies values and it is not incremented. And I beleivethis makes
> scheduler is not scheduling this worker thread.
>  I think if flush_to_ldisc is not called nothing can be read from the tty.
> Please let me know what could be the reason for timer interrupt being
> not called.

As you know the decrement exception always is invoked by the TB REGs, unless
there is one higher priority exception to block that.

Here I show the jiffies updating path simply as follows (only one simple path,
actually the timer framework should be more complicated.):
	-> timer_interrupt
		+ evt->event_handler(evt);
			+ tick_handle_periodic()
				+ tick_periodic(cpu);
static void tick_periodic(int cpu)
        if (tick_do_timer_cpu == cpu) {

                /* Keep track of the next tick event */
                tick_next_period = ktime_add(tick_next_period, tick_period);



So if we cannot set/update TB we would have no decrement exception. Or the
kernel is locked/looped somewhere.

Can you track the whole process via print? Maybe you can find out something. And
I'm not familiar with 885, is is SMP?


> Thanks,
> Mohan
> On Wed, Jan 19, 2011 at 12:37 AM, tiejun.chen <tiejun.chen at> wrote:
>> MohanReddy koppula wrote:
>>> But, if there is any problem with cable I could not have seen any
>>> character in the interrupt routine of the driver. I turned off both
>> I suppose the bootloader, i.e u-boot, works well so looks this should not be
>> issued by the cable at least.
>>> software and hardware flow control as by board doesn't have hardware
>>> flow control. tty_read is called and it hangs at ldisc->read. And I
>> Any panic information? Or any dead lock? Which line in detail?
>>> see that data is put into the tty buffer by the driver. Will there be
>>> any problem with copy_to_user() if there is some problem in the
>>> memory?
>> Can the serial driver support the poll mode? If so maybe you can take a try to
>> exclude any interrupt reason.
>> And even you can remove all codes to initialize the corresponding PIN & CLK
>> dedicated to the serial port, then try again since the bootloader already did this.
>> Tiejun
>>> Thanks,
>>> Mohan
>>> On Tue, Jan 18, 2011 at 12:55 PM, Nicholas Mc Guire <der.herr at> wrote:
>>>> On Tue, 18 Jan 2011, MohanReddy koppula wrote:
>>>>> Hi All,
>>>>> I am working on an MPC885 based custom board. I am able to boot up the
>>>>> linux (linux- I could see busybox shell (ash) prompt. But it
>>>>> is not accepting any inputs, I am not able to enter any command, it
>>>>> just hangs there. I am using ttyCPM0 terminal.
>>>>> I suspected if there was any problem in CPM driver interrupts
>>>>> generation and put some printk's in the interrupt handler and could
>>>>> see interrupts are raised and data is read, but shell is not taking
>>>>> the input.
>>>>> I wrote an init.c and opened the ttyCPM0 and tried to read from it,
>>>>> but couldn't. I am able to write to ttyCPM0 and see it on the host
>>>>> minicom.
>>>> if you are using minicom to connect check if you have hardware/software flow
>>>> control turned on - it also could be a cabling problem - had this with the
>>>> beagle board where the tx line was on the wrong pin - so I got output but
>>>> could not get any response to input.
>>>> hofrat

More information about the Linuxppc-dev mailing list