Re: Not getting login prompt after CPU entered into cpu_idle() state

2012-07-05 Thread sk.syed2
> Here are the final debug statements which we are seeing in the hyper terminal.

Can you post the full logs WITHOUT your debug prints. What is the
toolchain you are using?

> If we load 2.6.10 kernel image, we are getting login prompt in the
> hyper terminal on the same Phytec board.

You can isolate the problem by writing a small utility(blinky) which
would blink some LED on the board and then pass (init = /sbin/blinky)
it in your kernel command line.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Not getting login prompt after CPU entered into cpu_idle() state

2012-07-05 Thread Mulyadi Santosa
On Fri, Jul 6, 2012 at 1:02 AM, Jonathan Neuschäfer
 wrote:
> On Fri, Jul 06, 2012 at 12:56:45AM +0700, Mulyadi Santosa wrote:
> Only if 0 is already in use.
>
> But isn't that exec and not open?

hm, right, it's execso it should be just launch the init with
return value as programmed ( 0?)

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Not getting login prompt after CPU entered into cpu_idle() state

2012-07-05 Thread Jonathan Neuschäfer
On Fri, Jul 06, 2012 at 12:56:45AM +0700, Mulyadi Santosa wrote:
> Hi...
> 
> On Thu, Jul 5, 2012 at 12:12 PM, Srinidhi M  wrote:
> > .@ <271> ret = 0 : 
> > /sbin/init
> 
> FYI I absolutely has no hands on experience on this kind of hack, so
> this is purely speculation.
> 
> I am thinking, ret=0 when calling /sbin/init? AFAIK, a successful
> open() operation should return something bigger than 0 as the file
> descriptor.

Only if 0 is already in use.

But isn't that exec and not open?


Thanks,
Jonathan

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Not getting login prompt after CPU entered into cpu_idle() state

2012-07-05 Thread Mulyadi Santosa
Hi...

On Thu, Jul 5, 2012 at 12:12 PM, Srinidhi M  wrote:
> .@ <271> ret = 0 : 
> /sbin/init

FYI I absolutely has no hands on experience on this kind of hack, so
this is purely speculation.

I am thinking, ret=0 when calling /sbin/init? AFAIK, a successful
open() operation should return something bigger than 0 as the file
descriptor.

Also, init should call /sbin/login or something similar. maybe
something is wrong when reading /etc/fstab or anything similar for
your kernel?



-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


RE: Why can not processes switch in atomic context?

2012-07-05 Thread 卜弋天


 

> Date: Wed, 4 Jul 2012 08:12:25 -0700
> Subject: Re: Why can not processes switch in atomic context?
> From: dhyla...@gmail.com
> To: bu...@live.cn
> CC: mobile.parmeni...@gmail.com; kernelnewbies@kernelnewbies.org
> 
> Hi,
> 
> On Wed, Jul 4, 2012 at 3:44 AM, 弋天 卜  wrote:
> >
> >
> > 在 2012-7-3,22:26,"Parmenides"  写道:
> >
> ...snip...
> >> 1. For the spinlock case, it is easy to get if preemption is allowed
> >> in critical section, the purpose of protection provided by spinlock
> >> can not be achieved readily.
> >>
> > i think disable preemption in spinlock is not for safe, it is
> > For efficiency. Spinlock should exit as soon as possible.
> > If tank1 get spinlock and goto sleep for 100 seconds before
> > Release spinlock, task2 which requests the same spinlock
> > Should wait for 100 seconds, for this example, mutex should be used instead 
> > of spinlock.
> 
> Unless, of course, the interrupt that fired tried to acquire the
> spinlock it preempted, in which case you would have deadlock, even on
> an SMP system, if the same processor happened to be used for both.
> 
 
yes, i think you are right, suppose task1 use spin_lock_irqsave() to get a 
spinlock, 
then call schedule() to sleep for a long time, the interrupt on this cpu core 
will be
enabled by kernel, and if there is an interrupt triggered on the same cpu and 
get the same spinlock, deadlock will happen.
 

  ___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies