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/
From: Daniel Jacobowitz <hidden> Date: 2002-01-31 17:09:22
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/
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/
From: Scott Anderson <hidden> Date: 2002-01-31 21:34:34
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/
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:
quoted
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
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.
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/
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:
quoted
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();
quoted
(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.
quoted
written_value = *(volatile unsigned int *)(IMMR + simask_offset);
sti();
better use restore_flags(flags)... and flags must be defined as an unsigned
long.