kernel hang when machine_restart called from isr

kernel hang when machine_restart called from isr

[gopi]

hi..

  linux: hardhat linux for powerpc(linux 2.2.14)

  We are calling machine_restart(which call m8xx_gorom) from an isr,
but the kernel hangs after coming to some stage on the restart.

If we call the same machine_restart from a simple ioctl, it works.

  Is there any limitation on the usage of machine_restart?  Does it
assume something which is not true when called from an ISR?

thanx
gopi


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

why is tty->pgrp set to -1 for console?

[gopi]

hi..

  We had a problem that ctrl-c was not working on the console.  I
figured out that, ctrl-c was getting recognized as the 'intr' signal,
but the function isig (in drivers/char/n_tty.c) sends a signal only if
the tty->pgrp > 0.

  I have put a print stmt in this function and checked that the value
  is 'tty->pgrp = ffffffff' (which is -1).

  What is the correct procedure to follow to get around this problem
and get ctrl-c working on console?

thanx
gopi

following is the output of stty -a on the console
---------------------------------------------------------------------
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^X; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase =
^W;
lnext = ^V; flush = ^U; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb -cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten echo -echoe -echok -echonl -noflsh -xcase -tostop echoprt
echoctl echoke
---------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: why is tty->pgrp set to -1 for console?

[Daniel Jacobowitz]

On Thu, Jan 31, 2002 at 08:58:58PM +0000, gopi@india.tejasnetworks.com wrote:
>
> hi..
>
>   We had a problem that ctrl-c was not working on the console.  I
> figured out that, ctrl-c was getting recognized as the 'intr' signal,
> but the function isig (in drivers/char/n_tty.c) sends a signal only if
> the tty->pgrp > 0.
>
>   I have put a print stmt in this function and checked that the value
>   is 'tty->pgrp = ffffffff' (which is -1).
>
>   What is the correct procedure to follow to get around this problem
> and get ctrl-c working on console?

You need to run a getty on the console in order for SIGINT to get sent
properly.  That should be all it takes.  If the pgrp hasn't been set
yet, the kernel doesn't know where to send them.

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: why is tty->pgrp set to -1 for console?

[Scott Anderson]

gopi@india.tejasnetworks.com wrote:
>   What is the correct procedure to follow to get around this problem
> and get ctrl-c working on console?

It looks like everyone is taking a swing at this one, so I think I'll
join in.  First off, the easiest way I've found to track down why
ctrl-c doesn't work is to just run "ps -j".  For ctrl-c to work, you
need a controlling terminal (the TTY column) and a process group.  If
you have a '?' in the TTY column, ctrl-c won't work.  In the past I
have seen this happen because of this code in drivers/char/tty_io.c:
        if (device == SYSCONS_DEV) {
                struct console *c = console_drivers;
                while(c && !c->device)
                        c = c->next;
                if (!c)
                        return -ENODEV;
                device = c->device(c);
                filp->f_flags |= O_NONBLOCK; /* Don't let /dev/console block */
                noctty = 1;
        }
Note that O_NOCTTY (no controlling terminal) is forced on whenever
/dev/console is opened (noctty = 1).  Possible workarounds:
  1) Run getty on something other than /dev/console.  For example,
     if you console is on the first serial port, run getty on /dev/ttyS0.
     I believe this is the "correct" answer.
  2) You could also change getty to do a TIOCSCTTY ioctl explicitly after
     it has opened the terminal.
  3) You could remove the forcing of noctty on from tty_io.c

    Scott Anderson
    scott_anderson@mvista.com   MontaVista Software Inc.
    (408)328-9214               1237 East Arques Ave.
    http://www.mvista.com       Sunnyvale, CA  94085

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: why is tty->pgrp set to -1 for console?

[gopi]

Thanx, both the options 1 and 3 are working (I didnt try 2).

With option 1, wouldn't we have the problem of some important kernel
messages(say oops) not coming on the terminal as they are put on
'console'.  Even though kmsg will have it, it is good if we can see
it on the console in case something goes wrong.

thanx
gopi
ps: ours is an embedded system


On Thu, 31 Jan 2002, Scott Anderson wrote:

> gopi@india.tejasnetworks.com wrote:
> >   What is the correct procedure to follow to get around this problem
> > and get ctrl-c working on console?
>
> It looks like everyone is taking a swing at this one, so I think I'll
> join in.  First off, the easiest way I've found to track down why
> ctrl-c doesn't work is to just run "ps -j".  For ctrl-c to work, you
> need a controlling terminal (the TTY column) and a process group.  If
> you have a '?' in the TTY column, ctrl-c won't work.  In the past I
> have seen this happen because of this code in drivers/char/tty_io.c:
>         if (device == SYSCONS_DEV) {
>                 struct console *c = console_drivers;
>                 while(c && !c->device)
>                         c = c->next;
>                 if (!c)
>                         return -ENODEV;
>                 device = c->device(c);
>                 filp->f_flags |= O_NONBLOCK; /* Don't let /dev/console block */
>                 noctty = 1;
>         }
> Note that O_NOCTTY (no controlling terminal) is forced on whenever
> /dev/console is opened (noctty = 1).  Possible workarounds:
>   1) Run getty on something other than /dev/console.  For example,
>      if you console is on the first serial port, run getty on /dev/ttyS0.
>      I believe this is the "correct" answer.
>   2) You could also change getty to do a TIOCSCTTY ioctl explicitly after
>      it has opened the terminal.
>   3) You could remove the forcing of noctty on from tty_io.c
>
>     Scott Anderson
>     scott_anderson@mvista.com   MontaVista Software Inc.
>     (408)328-9214               1237 East Arques Ave.
>     http://www.mvista.com       Sunnyvale, CA  94085
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Unable to write to SIMASK

[gopi]

hi..

  We have an MPC860T based custom board.

  We wanted to control interrupt on one of the irqs by writing to SIMASK
register using a small driver with two ioctls which will will do
the following:

  // WRITE_MASK_IOCTL
  simask_write_ioctl(mask) {
    cli();
    (volatile unsigned int *)(IMMR + simask_offset) = mask;
    written_value = *(volatile unsigned int *)(IMMR + simask_offset);
    sti();
    printk (written_value);
  }

  // READ_MASK_IOCTL
  simask_read_ioctl() {
    cli(); // Not really needed..
    read_value = *(volatile unsigned int *)(IMMR + simask_offset);
    sti();
    printk (read_value);
  }


  When we make the ioctl calls from user space the value of the mask
seems to be getting changed during the driver time, but is reverted
back to its original value when we try to read it again.

Following is the sequence of events:

  ioctl(fd, READ_MASK_IOCTL) = 0x3edd0000
  ioctl(fd, WRITE_MASK_IOCTL, 0x1edd0000)
    here printk of the driver prints 0x1edd0000, so it looks like
    the value is written
  ioctl(fd, READ_MASK_IOCTL) = 0x3edd0000
    => somebody is reverting it back.

Any clue as to why this is happening?

thanx in advance
gopi

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Unable to write to SIMASK

[Ricardo Scop]

On Wednesday 20 February 2002 21:53, gopi@india.tejasnetworks.com wrote:
> hi..
>
>   We have an MPC860T based custom board.
>
>   We wanted to control interrupt on one of the irqs by writing to SIMASK
> register using a small driver with two ioctls which will will do
> the following:
>
>   // WRITE_MASK_IOCTL
>   simask_write_ioctl(mask) {
>     cli();
better use save_flags(flags); cli();

>     (volatile unsigned int *)(IMMR + simask_offset) = mask;
You're missing a * operator here (don't know about your actual source code,
though...)

>     written_value = *(volatile unsigned int *)(IMMR + simask_offset);
>     sti();
better use restore_flags(flags)... and flags must be defined as an unsigned
long.

>     printk (written_value);
>   }
>
>   // READ_MASK_IOCTL
>   simask_read_ioctl() {
>     cli(); // Not really needed..
>     read_value = *(volatile unsigned int *)(IMMR + simask_offset);
>     sti();
>     printk (read_value);
>   }
>
>
<snip>


HTH,

R. Scop


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Unable to write to SIMASK

[gopi]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1953 bytes --]

hi..

I tried the simple code attatched with this mail:

complied using:
ppc_8xx-gcc -c -D__KERNEL__ -DMODULE -O2 -Wall myMpc.c

Then, on the target board:

>  insmod myMpc.o ; rmmod myMpc
read0 = 3eed0000, read1 = 1eed0000, read2 = 1eed0000
(above was the output of printk from the driver)

> insmod myMpc.o ; rmmod myMpc
read0 = 3eed0000, read1 = 1eed0000, read2 = 1eed0000
(read0 is again 3eed0000 implying the original value is restored)

> insmod myMpc.o ; rmmod myMpc
read0 = 3eed0000, read1 = 1eed0000, read2 = 1eed0000

So, it looks like when we go out of the driver(exit from system call),
the value of simask is being restored by some code in the kernel.

I understand that this is not a good way of enabling/disabling
irqs(better use request_8xxirq etc..), but I thought this should work.

gopi


On Wed, 20 Feb 2002, Ricardo Scop wrote:

> On Wednesday 20 February 2002 21:53, gopi@india.tejasnetworks.com wrote:
> > hi..
> >
> >   We have an MPC860T based custom board.
> >
> >   We wanted to control interrupt on one of the irqs by writing to SIMASK
> > register using a small driver with two ioctls which will will do
> > the following:
> >
> >   // WRITE_MASK_IOCTL
> >   simask_write_ioctl(mask) {
> >     cli();
> better use save_flags(flags); cli();
>
> >     (volatile unsigned int *)(IMMR + simask_offset) = mask;
> You're missing a * operator here (don't know about your actual source code,
> though...)
  That was a typing error, it was ok in code.

>
> >     written_value = *(volatile unsigned int *)(IMMR + simask_offset);
> >     sti();
> better use restore_flags(flags)... and flags must be defined as an unsigned
> long.
>
> >     printk (written_value);
> >   }
> >
> >   // READ_MASK_IOCTL
> >   simask_read_ioctl() {
> >     cli(); // Not really needed..
> >     read_value = *(volatile unsigned int *)(IMMR + simask_offset);
> >     sti();
> >     printk (read_value);
> >   }
> >
> >
> <snip>
>
>
> HTH,
>
> R. Scop
>


[-- Attachment #2: Type: TEXT/PLAIN, Size: 818 bytes --]

#include <linux/config.h>
#include <linux/module.h>
#include <linux/version.h>
#include <linux/types.h>
#include <linux/sched.h>
#include <linux/kernel.h>
#include <linux/interrupt.h>
#include <asm/8xx_immap.h>

#define IMAP_ADDR  ((uint)0xff000000)

int init_module(void) {

    volatile immap_t *imp = (immap_t *)IMAP_ADDR;
    volatile sysconf8xx_t *sysp = (sysconf8xx_t *) &(imp->im_siu_conf);
    unsigned int read0, read1, read2;
    unsigned long flags;

    save_flags(flags); cli();
        read0 = sysp->sc_simask;
        sysp->sc_simask = 0x1eed0000;
        read1 = sysp->sc_simask;
    restore_flags(flags);
    read2 = sysp->sc_simask;
    printk("read0 = %x, read1 = %x, read2 = %x\n",read0, read1, read2);

    return 0;

}

int cleanup_module(void) {
    return 0;
}

Re: why is tty->pgrp set to -1 for console?

[David Boutcher]

>  We had a problem that ctrl-c was not working on the console.

You need to be running something like mingetty on the console to have
signals (like ctrl-c) picked up.  If you start Linux with something like
"init=/bin/bash" then job control signals (like control C and control Z)
won't work.

Dave Boutcher
iSeries Linux guy


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: why is tty->pgrp set to -1 for console?

[mod+linuxppc-dev]

>> We had a problem that ctrl-c was not working on the console.
>
>You need to be running something like mingetty on the console to
>have signals (like ctrl-c) picked up.  If you start Linux with
>something like "init=/bin/bash" then job control signals (like
>control C and control Z) won't work.


That doesn't sound correct.  When the system is in
single-user mode the console shell is a direct child
of init and is spawned without any kind of getty, yet
(at least in my case) the behavior of the shell is
indistinguishable from one spawned from mutiuser mode -
all signals (and job control, etc) are handled correctly.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: why is tty->pgrp set to -1 for console?

[Dan Malek]

David Boutcher wrote:


> You need to be running something like mingetty on the console to have
> signals (like ctrl-c) picked up.  If you start Linux with something like
> "init=/bin/bash" then job control signals (like control C and control Z)
> won't work.

One of the main reasons for this is the process in slot 1 (i.e. init)
has special signal handling in the kernel.  There are a variety of ways
to get a shell with job control running on the console.  Starting some
version of getty/mingetty as you mentioned is one, you can also fork a
shell and use stty to set signals, or anything to get a shell running
as process 2 or above.


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/