* kernel hang when machine_restart called from isr @ 2002-01-30 12:14 gopi 2002-01-31 20:58 ` why is tty->pgrp set to -1 for console? gopi 0 siblings, 1 reply; 8+ messages in thread From: gopi @ 2002-01-30 12:14 UTC (permalink / raw) To: linuxppc-embedded; +Cc: cort 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* why is tty->pgrp set to -1 for console? 2002-01-30 12:14 kernel hang when machine_restart called from isr gopi @ 2002-01-31 20:58 ` gopi 2002-01-31 17:09 ` Daniel Jacobowitz ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: gopi @ 2002-01-31 20:58 UTC (permalink / raw) To: linuxppc-dev 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: why is tty->pgrp set to -1 for console? 2002-01-31 20:58 ` why is tty->pgrp set to -1 for console? gopi @ 2002-01-31 17:09 ` Daniel Jacobowitz 2002-01-31 21:34 ` Scott Anderson 2002-02-21 0:53 ` Unable to write to SIMASK gopi 2 siblings, 0 replies; 8+ messages in thread From: Daniel Jacobowitz @ 2002-01-31 17:09 UTC (permalink / raw) To: gopi; +Cc: linuxppc-dev 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: why is tty->pgrp set to -1 for console? 2002-01-31 20:58 ` why is tty->pgrp set to -1 for console? gopi 2002-01-31 17:09 ` Daniel Jacobowitz @ 2002-01-31 21:34 ` Scott Anderson 2002-02-01 19:12 ` gopi 2002-02-21 0:53 ` Unable to write to SIMASK gopi 2 siblings, 1 reply; 8+ messages in thread From: Scott Anderson @ 2002-01-31 21:34 UTC (permalink / raw) To: gopi; +Cc: linuxppc-dev 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: why is tty->pgrp set to -1 for console? 2002-01-31 21:34 ` Scott Anderson @ 2002-02-01 19:12 ` gopi 0 siblings, 0 replies; 8+ messages in thread From: gopi @ 2002-02-01 19:12 UTC (permalink / raw) To: Scott Anderson; +Cc: linuxppc-dev 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Unable to write to SIMASK 2002-01-31 20:58 ` why is tty->pgrp set to -1 for console? gopi 2002-01-31 17:09 ` Daniel Jacobowitz 2002-01-31 21:34 ` Scott Anderson @ 2002-02-21 0:53 ` gopi 2002-02-20 21:27 ` Ricardo Scop 2 siblings, 1 reply; 8+ messages in thread From: gopi @ 2002-02-21 0:53 UTC (permalink / raw) To: linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unable to write to SIMASK 2002-02-21 0:53 ` Unable to write to SIMASK gopi @ 2002-02-20 21:27 ` Ricardo Scop 2002-02-21 17:34 ` gopi 0 siblings, 1 reply; 8+ messages in thread From: Ricardo Scop @ 2002-02-20 21:27 UTC (permalink / raw) To: gopi, linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unable to write to SIMASK 2002-02-20 21:27 ` Ricardo Scop @ 2002-02-21 17:34 ` gopi 0 siblings, 0 replies; 8+ messages in thread From: gopi @ 2002-02-21 17:34 UTC (permalink / raw) To: Ricardo Scop; +Cc: linuxppc-embedded [-- 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; } ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-02-21 17:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-01-30 12:14 kernel hang when machine_restart called from isr gopi 2002-01-31 20:58 ` why is tty->pgrp set to -1 for console? gopi 2002-01-31 17:09 ` Daniel Jacobowitz 2002-01-31 21:34 ` Scott Anderson 2002-02-01 19:12 ` gopi 2002-02-21 0:53 ` Unable to write to SIMASK gopi 2002-02-20 21:27 ` Ricardo Scop 2002-02-21 17:34 ` gopi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox