Console
My name is Kirti Desai. I am trying to write a new console driver. Hence I was going through the source code and I need your help in understanding it. I would be obliged if you can help me out. I am working on Redgar Linux 2.2-14.12 on Celeron 400. * Is console related to a tty_driver? We have two functions register_console and register_tty_driver? How are these two related? In tty_init(tty_io.c) we register dev_tty_driver and dev_syscons_driver? In console_init(tty_io.c) con_init(tty_io.c for CONFIG_VT=y) is called. It registers console_driver and calls register_console(vt_console_driver). * To do printk we need not open the /dev/console file? What I found was start_kernel(init/main.c) calls console_init and kernel_thread(init..) which calls init is called later which opens /dev/console. * How are stdin/stdout/stderr mapped to the tty's? What want to know if that when we call say printf in user program,finally write(1,..) gets called which calls tty_write ,con_write. How does tty come in picture? * What are /dev/console /dev/tty0, /dev/tty1 files? Any pointer to documentation ..would be of great help? Thanks, Kirti Desai __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Console
> My name is Kirti Desai. I am trying to write a new
> console driver.
No problem. What are you looking to do?
> * Is console related to a tty_driver?
A tty is a posix terminals which cover alot of different types of
hardware. Everything from modems to serial consoles to video terminals
which use hardware like VGA video cards. If you are talking about
video consoles (VTs) then they are a subset of ttys types. Remember their
are many types of ttys.
> We have two functions register_console and register_tty_driver? How are
> these two related?
As for register_console you are talking about the system console.
This is the console where things like kernel errors printed via printk
go. Note any kind of tty can be a system console.
> In tty_init(tty_io.c) we register dev_tty_driver and
> dev_syscons_driver?
> In console_init(tty_io.c) con_init(tty_io.c for
> CONFIG_VT=y) is
> called. It registers console_driver and calls
> register_console(vt_console_driver).
This is registering a video terminal (VT) as a system console. Thus
printks will be sent to this terminal.
> * To do printk we need not open the /dev/console file?
Printk is handled inside the kernel. Take a look at linux/kernel/printk.c.
What do you mean by open? Via userland ?
> What I found was
> start_kernel(init/main.c) calls console_init and
> kernel_thread(init..)
> which calls init is called later which opens
> /dev/console.
Right. First we initalize the the basic termios structure and startup up
hardware that can be started early. Later on other types of hardware which
depend on other subsystems running such as the PCI bus are called in
tty_init. Next /dev/console is opened. I believe this is the first opened
file in a linux system thus its file descriptor is 0. It is stdin. With
dup we set stdin, stdout, and stderr all equal to each other.
if (open("/dev/console", O_RDWR, 0) < 0)
printk("Warning: unable to open an initial console.\n");
(void) dup(0);
(void) dup(0);
Then init is started after the kernel is done. It is the father of all
process. It uses the file /etc/inittab to setup all your consoles.
> * How are stdin/stdout/stderr mapped to the tty's?
See above.
> What want to know
> if that when we call say printf in user
> program,finally write(1,..) gets called which calls
> tty_write ,con_write. How does tty come in
> picture?
printf sends by default data to stdout whcih goes to /dev/console threw
the tty layer to con_write if it is VT.
> * What are /dev/console /dev/tty0, /dev/tty1 files?
/dev/console is the system console (where the printk go). /dev/tty
represents the current console for the current process. If I'm on a serial
console and do a echo "hi" > /dev/tty it will print out on the screen. If
I'm using a console run by fbcon it will do the same thing. Now /dev/tty0
represents the current foreground video console. If you do a echo to
/dev/tty0 it will be printed on the current video display. /dev/tty1 and
so on represent the virtaul consoles for VTs. Those are the consoles you
switch to when you press Alt-F[1-6].
> Any pointer to documentation ..would be of great
> help?
Not alot. This is a linux console project which just started. See the
address in my sig.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[EMAIL PROTECTED]] /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Serial Console!!
Hi all, I want to login to my MIPS box through serial port. I execute 'make menuconfig' and select the 'serial console'. But I can't see the login prompt in my window(I use netterm). May I ask how serial console work? Or I forget something? P.S I skip /sbin/init program. Green
Console logging
Hi! I am getting getting "/var/log/messages" on my console. It doesn't save it in /var/log. I have checked entries in /etc/syslog.conf file. Its correct. Can someone help me. Regards, Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
console spin_lock
Some time ago a intel i810 framebuffer driver was written. It only worked
for 2.2.X. With 2.4.X a spinlock is used in the upper layers of the
console system. Sooner or later we are going to run into the situtation
where we will have graphics hardware which has no vga core and wih be
purely DMA/irq based (i.e i810). In this case using the current
console_lock will block the driver itself. I have thought about a
possible solution. A semaphore can't be used since their is a spin_lock
in the console_softirq. Since this is in a interrupt context a
semaphore can't be used. Another idea was to do a
void get_vc_lock(void)
{
while (test_and_set_bit(0, &vc_var))
;
}
Any better ideas?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Serial Console
I'm building boxes with the console set to /dev/ttyS0. However, I can't guarantee that there will always be a term plugged into the serial port. If there is no term on the port, eventually the buffer fills and any processes that write to the console (i.e. init) block. Is there some option somewhere to stop this happening (i.e. either ignoring the flow-control or just allowing the buffer to overflow)? -- - Steve Hill System Administrator Email: [EMAIL PROTECTED] Navaho Technologies Ltd. Tel: +44-870-7034015 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] console updates
Alan,
patch against -ac20 fixes a few things:
- console.c: reviewed and commented locking rules
- tioclinux(): set_selection() was racy wrt console writes, which
causes mouse droppings on the screen when using gpm. It was
always SMP racy. Removing the console_lock make it UP-racy.
Now fixed.
- con_flush_chars(): this is being called from timer context,
and for a couple of people it was going splat on a BUG() I
added when they were switching from X back to the console.
We just skip the flush in this case.
This could possibly cause the cursor to not be present until
a character is output immediately after switching out of X,
but it works for me, and it's not obvious that this is worth
straining over.
- In reset_vc(), don't call set_pallette() in interrupt context.
It's racy. This only happens when SAK is used.
- keyboard.c: poke the cosole after printing, rather than before.
See below for details...
- printk.c: fix the off-by-one which prevented a bare
printk(KERN_ERR);
from working.
- add lib/bust_spinlocks.c for archs which don't provide one.
Outstanding problems (of which I'm aware):
1: riva_hw.c:ShowHideCursor() is called from a timer
handler and a race here could cause registers to get the
wrong values. It was always racy on SMP. The driver
needs locking.
2: This code:
printk(KERN_ERR "something");
console_loglevel = something_else;
is now racy, because the actual printing of the output
could be deferred if someone currently holds console_sem().
The only known instance of this is the sysrq handler, and
I fixed that.
The corresponding patch against 2.4.3-pre6 is at
http://www.uow.edu.au/~andrewm/linux/console.html
--- linux-2.4.2-ac20/drivers/char/console.c Tue Mar 13 20:29:21 2001
+++ ac/drivers/char/console.c Thu Mar 22 21:29:10 2001
@@ -69,6 +69,9 @@
*
* Removed old-style timers, introduced console_timer, made timer
* deletion SMP-safe. 17Jun00, Andrew Morton <[EMAIL PROTECTED]>
+ *
+ * Removed console_lock, enabled interrupts across all console operations
+ * 13 March 2001, Andrew Morton
*/
#include
@@ -1034,6 +1037,7 @@
color = def_color;
}
+/* console_sem is held */
static void csi_m(int currcons)
{
int i;
@@ -1173,6 +1177,7 @@
return report_mouse;
}
+/* console_sem is held */
static void set_mode(int currcons, int on_off)
{
int i;
@@ -1238,6 +1243,7 @@
}
}
+/* console_sem is held */
static void setterm_command(int currcons)
{
switch(par[0]) {
@@ -1292,19 +1298,7 @@
}
}
-static void insert_line(int currcons, unsigned int nr)
-{
- scrdown(currcons,y,bottom,nr);
- need_wrap = 0;
-}
-
-
-static void delete_line(int currcons, unsigned int nr)
-{
- scrup(currcons,y,bottom,nr);
- need_wrap = 0;
-}
-
+/* console_sem is held */
static void csi_at(int currcons, unsigned int nr)
{
if (nr > video_num_columns - x)
@@ -1314,15 +1308,18 @@
insert_char(currcons, nr);
}
+/* console_sem is held */
static void csi_L(int currcons, unsigned int nr)
{
if (nr > video_num_lines - y)
nr = video_num_lines - y;
else if (!nr)
nr = 1;
- insert_line(currcons, nr);
+ scrdown(currcons,y,bottom,nr);
+ need_wrap = 0;
}
+/* console_sem is held */
static void csi_P(int currcons, unsigned int nr)
{
if (nr > video_num_columns - x)
@@ -1332,15 +1329,18 @@
delete_char(currcons, nr);
}
+/* console_sem is held */
static void csi_M(int currcons, unsigned int nr)
{
if (nr > video_num_lines - y)
nr = video_num_lines - y;
else if (!nr)
nr=1;
- delete_line(currcons, nr);
+ scrup(currcons,y,bottom,nr);
+ need_wrap = 0;
}
+/* console_sem is held (except via vc_init->reset_terminal */
static void save_cur(int currcons)
{
saved_x = x;
@@ -1355,6 +1355,7 @@
saved_G1= G1_charset;
}
+/* console_sem is held */
static void restore_cur(int currcons)
{
gotoxy(currcons,saved_x,saved_y);
@@ -1375,6 +1376,7 @@
EShash, ESsetG0, ESsetG1, ESpercent, ESignore, ESnonstd,
ESpalette };
+/* console_sem is held (except via vc_init()) */
static void reset_terminal(int currcons, int do_clear)
{
top = 0;
@@ -1430,6 +1432,7 @@
csi_J(currcons,2);
}
+/* console_sem is held */
static void do_con_trol(struct tty_struct *tty, unsigned int currcons, int c)
{
/*
@@ -1810,6 +1813,7 @@
#define CON_BUF_SIZE PAGE_SIZE
DECLARE_MUTEX(con_buf_sem);
+/* acquires console_sem */
static int do_con_write(struct tty_struct * tty, int from_user,
const unsigned char *buf, int count)
{
@@ -2049,7 +2053,7 @@
void set_console(int nr)
{
want_console = nr;
- schedule_task(
Re: Serial Console!!
Apparently "Green" <[EMAIL PROTECTED]> wrote: > Hi all, > I want to login to my MIPS box through serial port. > I execute 'make menuconfig' and select the 'serial console'. > But I can't see the login prompt in my window(I use netterm). > May I ask how serial console work? > Or I forget something? > P.S I skip /sbin/init program. In order for you to have full serial console port you must do more than simply enable the option in your kernel. Your BIOS/firmware should have serial console support of its own (most PCs don't, most other systems, even most PowerPC based Macs and workstations do, in the form of OpenFirmware --- formerly known as Sun's FCODE). Your MIPS box might have a firmware with serial console support, or it might not. That should allow you to access any pre-boot configuration options or diagnostics (including providing some mechanism to reset the NVRAM and to set the boot device or sequence) Your bootloader would have to support serial console to allow you to select which kernel you want to load and/or to pass kernel command line options and set initial environment variable/value pairs (a feature that seems unique to Linux). Of course, the Linux kernel support must be enabled, though that *only* applies to whether the kernel messages are copied to that device. If you would see it from dmesg, then it won't get copied to the console. To enable logins on a serial device you must spawn some form of getty process (normally done by init). That will listen for connections (normallly by taking login names) and exec() your login program (usually with the login name passed on its argument list). Since you specify that you're not running init, it's obvious why you can't "login." So, please tell me that you didn't actually think that logins and shells were handled directly by UNIX and Linux kernels! -- Jim Dennis Software Analyst Axis Personal Trainers http://www.axispt.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Escape sequences & console
Hi all, Could someone tell me where I can find a document listing all the escape-sequences that could be sent to the console (/dev/console) and what they do. Thank you: Sébastien. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:Escape sequences & console
I would say the escape sequence are for /dev/ttyX since only Vt emulate Dec VT 100s. The web site to look for this info is http://www.vt100.net MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Console logging
On Sat, 6 Jan 2001, Mike wrote: > Hi! > > I am getting getting "/var/log/messages" on my console. It doesn't save > it in /var/log. > I have checked entries in /etc/syslog.conf file. Its correct. > Can someone help me. Syslog isn't running > > Regards, > Mike Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Console logging
Hello Mike , On Sat, 6 Jan 2001, Igmar Palsenberg wrote: > On Sat, 6 Jan 2001, Mike wrote: > > Hi! > > I am getting getting "/var/log/messages" on my console. It doesn't save > > it in /var/log. > > I have checked entries in /etc/syslog.conf file. Its correct. > > Can someone help me. > Syslog isn't running Or the directory/file in /var/log/ hasn't the correct permission to allow program 'X' to write into it . But it is more likely that Igmar is correct . Twyl , JimL ++ | James W. Laferriere | System Techniques | Give me VMS | | NetworkEngineer | 25416 22nd So | Give me Linux | | [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | ++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: console spin_lock
Hi, On Thu, 18 Jan 2001, Andrew Morton wrote: > - Get rid of the special printk buffer - share the > log buffer. (Implies writes to console > devices will be broken into two writes when they > wrap around). > - Teach vsprintf to print into a circular buffer > (snprintf thus comes for free). I have a different vsprintf variant - vpprintf(). It takes a function and a data pointer, this function is called with the print buffer and within that function you can take care of the locking. The only problem is that %n doesn't work anymore, but it's not used anyway in the kernel (as far as I can grep :) ). bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: console spin_lock
James Simmons wrote:
>
> Some time ago a intel i810 framebuffer driver was written. It only worked
> for 2.2.X. With 2.4.X a spinlock is used in the upper layers of the
> console system. Sooner or later we are going to run into the situtation
> where we will have graphics hardware which has no vga core and wih be
> purely DMA/irq based (i.e i810). In this case using the current
> console_lock will block the driver itself. I have thought about a
> possible solution. A semaphore can't be used since their is a spin_lock
> in the console_softirq. Since this is in a interrupt context a
> semaphore can't be used. Another idea was to do a
>
> void get_vc_lock(void)
> {
> while (test_and_set_bit(0, &vc_var))
> ;
> }
>
> Any better ideas?
>
heh.
I'm actually planning on grabbing console_lock and thoroughly strangling
it
next week. It can block interrupts for up to a second. That just isn't
civil.
- Use a semaphore for serialisation.
- For printk in interrupt context, grab the
semaphore (yes, you can do this).
- If it couldn't be acquired from interrupt context,
buffer the text in the log buffer and return. The text will be
printed by whoever holds the semaphore before they
drop it.
- Special "system booting" mode which bypasses all this
stuff.
- Special "oops in progress" mode which just
punches through everything.
- Get rid of the special printk buffer - share the
log buffer. (Implies writes to console
devices will be broken into two writes when they
wrap around).
- Teach vsprintf to print into a circular buffer
(snprintf thus comes for free).
- Get rid of all the printk deadlock opportunities (fourth
attempt).
- Get rid of console_tasklet. Do it in process context callback
or just do it synchronously.
Assumption:
- Once the system is up and running, it's always safe to
call down() when in_interrupt() returns false - probably
not the case in parts of the exit path - tough.
Anyway, that's the thoughtware. Sound sane?
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: console spin_lock
> heh. > > I'm actually planning on grabbing console_lock and thoroughly strangling > it Ha Ha!! > - Use a semaphore for serialisation. I think this would be the best solution as well. > - For printk in interrupt context, grab the > semaphore (yes, you can do this). Don't forget about the idle task also. How is this done? By reintializing the semaphore. > - If it couldn't be acquired from interrupt context, > buffer the text in the log buffer and return. The text will be > printed by whoever holds the semaphore before they > drop it. By you saying couldn't be acquired from interrupt context do you mean from a process context or do you mean it failed to aquire it while in the interrupt context? > - Special "system booting" mode which bypasses all this > stuff. This wouldn't be to hard to do for VTs using the fact that keybaords are not initialized right away. As for serial consoles well that is another story. Of course we could have this flag set/cleared in start_kernel. > - Special "oops in progress" mode which just > punches through everything. You already developed the framework for this. > - Get rid of the special printk buffer - share the > log buffer. (Implies writes to console > devices will be broken into two writes when they > wrap around). > - Teach vsprintf to print into a circular buffer > (snprintf thus comes for free). > - Get rid of all the printk deadlock opportunities (fourth > attempt). Good luck. > - Get rid of console_tasklet. Do it in process context callback > or just do it synchronously. What about multidesktop systems? I have vgacon and mdacon working fine along each other. Each one has their own tasklet to allow them to work independent of each other. Meaning no race condition when both VC switch at the same time. > Assumption: > - Once the system is up and running, it's always safe to > call down() when in_interrupt() returns false - probably > not the case in parts of the exit path - tough. Don't forget the idle_task case as well. exit path? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: console spin_lock
James Simmons wrote: > ... > By you saying couldn't be acquired from interrupt context do you mean > from a process context or do you mean it failed to aquire it while in > the interrupt context? Actually, printk() must always use __down_trylock(). > > - Get rid of console_tasklet. Do it in process context callback > > or just do it synchronously. > > What about multidesktop systems? I have vgacon and mdacon working fine > along each other. Each one has their own tasklet to allow them to work > independent of each other. Meaning no race condition when both VC switch > at the same time. Ah. Thanks. That stuff was actually design-from-memory :) I'll take a closer look when I have something other than a clockwork computer. > > Assumption: > > - Once the system is up and running, it's always safe to > > call down() when in_interrupt() returns false - probably > > not the case in parts of the exit path - tough. > > Don't forget the idle_task case as well. exit path? This statement of mine was grade-A bollocks. printk cannot of course call down(). It needs to use __down_trylock and buffer it up if it fails. (faster, too!) The subtler problem will be interrupt-capable drivers which do a bare spin_lock() to serialise wrt their interrupt routines, relying upon interrupts being disabled. They'll be deadlocky and will need changing. That's trivial to find and fix though. Anyway, this was just a heads-up that I'll be looking at this stuff. Please allow me a week or so to provide some substance. I read that the fbdev developers have been seeking a fix for this for some time, so it seems worth some effort. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: console spin_lock
> This statement of mine was grade-A bollocks. printk cannot of > course call down(). It needs to use __down_trylock and buffer > it up if it fails. (faster, too!) Okay. I'm going to start working on this tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: console spin_lock
Andrew Morton writes: > The subtler problem will be interrupt-capable drivers which > do a bare spin_lock() to serialise wrt their interrupt routines, > relying upon interrupts being disabled. They'll be deadlocky > and will need changing. That's trivial to find and fix though. Uhh, what if you have this situation: interrupt (level triggered) enter interrupt handler printk (can re-enable interrupts?) enter interrupt handler printk (can re-enable interrupts?) enter interrupt handler printk (can re-enable interrupts?) So surely this isn't a new problem? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
In article <[EMAIL PROTECTED]>, Steve Hill <[EMAIL PROTECTED]> wrote: >I'm building boxes with the console set to /dev/ttyS0. However, I can't >guarantee that there will always be a term plugged into the serial >port. If there is no term on the port, eventually the buffer fills and >any processes that write to the console (i.e. init) block. Is there some >option somewhere to stop this happening (i.e. either ignoring the >flow-control or just allowing the buffer to overflow)? Offtopic, but anyway .. Sure, turn flow control off. You'll probably have to configure this on the getty process that runs on ttyS0 Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
On Tue, 5 Dec 2000, Steve Hill wrote: > > I'm building boxes with the console set to /dev/ttyS0. how? symlink to /dev/ttyS0, or with console=ttyS0 boot option? > However, I can't > guarantee that there will always be a term plugged into the serial > port. If there is no term on the port, eventually the buffer fills and > any processes that write to the console (i.e. init) block. Is there some > option somewhere to stop this happening (i.e. either ignoring the > flow-control or just allowing the buffer to overflow)? IIRC/AFAIK: use /dev/console (char, 5,1) for all your programmes and boot the kernel with serial console support and . /dev/console will go to serial, but afaik it doesn't block for lack of a terminal. (has something to do with /dev/console being semantically different to /dev/tty..., eg it doesn't block, not sure of the exact details). --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
On Tue, 5 Dec 2000, PaulJakma wrote: > how? symlink to /dev/ttyS0, or with console=ttyS0 boot option? console=ttyS0 > use /dev/console (char, 5,1) for all your programmes and boot the > kernel with serial console support and . > > /dev/console will go to serial, but afaik it doesn't block for lack of > a terminal. (has something to do with /dev/console being semantically > different to /dev/tty..., eg it doesn't block, not sure of the exact > details). Nope, /dev/console *does* block. ATM I've found a quick workaround - I use "stty -F /dev/console clocal -crtscts" to turn off the serial flow control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite well... of course it doesn't stop some program turning flow control back on and ballsing it all up again :) -- - Steve Hill System Administrator Email: [EMAIL PROTECTED] Navaho Technologies Ltd. Tel: +44-870-7034015 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
> Nope, /dev/console *does* block. ATM I've found a quick workaround - I > use "stty -F /dev/console clocal -crtscts" to turn off the serial flow > control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite > well... of course it doesn't stop some program turning flow control back > on and ballsing it all up again :) ...and to fix that, you could easily travel into /usr/src/linux/drivers/char/serial.c, and a quick conditionional to check whether or not the change was being made to a console port - and if it is, dont allow CRTSCTS to be set. Chad - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
On Tue, 5 Dec 2000, Steve Hill wrote: > On Tue, 5 Dec 2000, PaulJakma wrote: > > > how? symlink to /dev/ttyS0, or with console=ttyS0 boot option? > > console=ttyS0 > > Nope, /dev/console *does* block. very weird.. the reason i replied to you, even though i have no direct experience of serial console, was that last night i read a mail on the linux-mips on almost exactly the same subject (serial console being quite common on linux-mips), and IIRC Ralf Baechle explained how there was a fundamental difference between tty and console precisely because /dev/console might not be going anywhere. Quoting from Ralf's email: "/dev/console (as chardev 5/1) differs from another device in some important ways: - When opened by a process without controlling tty it will not become a CTTY even if the NOCTTY flag is not set. - It will never block but rather loose data. This may sound like a disadvantage but it's actually very important for proper operation. For example, if /dev/console'd block due to a serial console with hardware handshaking enabled (DON'T) syslogd writing to it may also block for an unbounded time and thus as soon as /dev/log is full all services trying to log via syslog(3) will also freeze. Syslogd actually tries to be clever about avoiding this from happening but fails to handle one case correctly, so this is a real world scenario. - It uses different routines to access the console device than normal write access to i.e. ttyS0." perhaps linux-mips is just different? or i386 serial-console is incorrect? > ATM I've found a quick workaround - I > use "stty -F /dev/console clocal -crtscts" to turn off the serial flow > control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite > well... of course it doesn't stop some program turning flow control back > on and ballsing it all up again :) yukkk... /dev/console having non-blocking semantics sounds much cleaner. regards, --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
On Tue, 5 Dec 2000, PaulJakma wrote: > > ATM I've found a quick workaround - I > > use "stty -F /dev/console clocal -crtscts" to turn off the serial flow > > control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite > > well... of course it doesn't stop some program turning flow control back > > on and ballsing it all up again :) > > yukkk... > > /dev/console having non-blocking semantics sounds much cleaner. Yep - having a blocking console just seems like plain stupidity :( -- - Steve Hill System Administrator Email: [EMAIL PROTECTED] Navaho Technologies Ltd. Tel: +44-870-7034015 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
Unless of course you really DO have RTS/CTS (Or DTR-->CTS) flow control turned on - on your terminal, and the terminal shuts off RTS (or DTR) to indicate its fifo level is too high. That *IS* useful. but the ability to hard-code it in a shut-off state is *MUCH* better. Chad > On Tue, 5 Dec 2000, PaulJakma wrote: > > > > ATM I've found a quick workaround - I > > > use "stty -F /dev/console clocal -crtscts" to turn off the serial flow > > > control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite > > > well... of course it doesn't stop some program turning flow control back > > > on and ballsing it all up again :) > > > > yukkk... > > > > /dev/console having non-blocking semantics sounds much cleaner. > > Yep - having a blocking console just seems like plain stupidity :( > > -- > > - Steve Hill > System Administrator Email: [EMAIL PROTECTED] > Navaho Technologies Ltd. Tel: +44-870-7034015 > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
>> >> /dev/console will go to serial, but afaik it doesn't block for lack of >> a terminal. (has something to do with /dev/console being semantically >> different to /dev/tty..., eg it doesn't block, not sure of the exact >> details). >Nope, /dev/console *does* block. ATM I've found a quick workaround - I >use "stty -F /dev/console clocal -crtscts" to turn off the serial flow >control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite >well... of course it doesn't stop some program turning flow control back >on and ballsing it all up again :) I've got a machine here which redirects the console to the serial port using Lilo 'append="console=ttyS0"' and it boots fine without a connection to the serial port without having to do any specific manipulation of the flow control. I think that all serial output is dumped to /dev/null if DCD is not asserted no matter what the flow control says. Perhaps there are some hardware differences in the configuration of the control signal pull-up/downs. Jon Burgess PLANET PROJECT will connect millions of people worldwide through the combined technology of 3Com and the Internet. Find out more and register now at http://www.planetproject.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
See, in an ideal world, that shouldn't be the case, at all. Since we're NOT operating under the assumption that the serial console is a modem, we should be - instead - operating under the assumption that it is a 3-wire NULL connection. (thus, making NO assumptions about the user's hardware..) If the user wants to ADD RTS/CTS flow control or DCD based state checking as an OPTION, well, hey. whatever. Pick your poison. But i sure as hell wouldn't do it that way. Chad > Lilo 'append="console=ttyS0"' and it boots fine without a connection to the > serial port without having to do any specific manipulation of the flow control. > I think that all serial output is dumped to /dev/null if DCD is not asserted no > matter what the flow control says. Perhaps there are some hardware differences > in the configuration of the control signal pull-up/downs. > > Jon Burgess > > > > > PLANET PROJECT will connect millions of people worldwide through the combined > technology of 3Com and the Internet. Find out more and register now at > http://www.planetproject.com > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
In article <[EMAIL PROTECTED]>, Rogier Wolff <[EMAIL PROTECTED]> wrote: >Paul Jakma wrote: >> perhaps linux-mips is just different? or i386 serial-console is >> incorrect? > >No. serial console on i386 doesn't and should not block. >We're constantly using serial consoles here, so I really think I've >seen this work... . It can block. Funny, no message on this list has been quite right ;) /dev/console can block /dev/ttyS0 can block printk() never blocks init(8) reads the tty settings from /etc/ioctl.save at startup. After it leaves single user mode it writes that file again. So mods made in single user mode are saved to /etc/ioctl.save. Every time init executes a program, it restores the console settings to those from /etc/ioctl.save. [Perhaps I should rip that stuff out] However a getty on /dev/ttyS0 which you usually have running in runlevels [12345789] can change the tty settings and they will take effect immidiately. So if you run a getty that turns on hardware handshaking (like mgetty) - you're fscked. The only things in which /dev/console is special are: - it's an alias for the current console - it's always opened with O_NOCTTY Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
Yes it could be a modem on the line, so my comment about DCD is wrong, a comms program must be able to send AT commands to the modem when DCD is not asserted before the call is setup. I was being confused by the login getty which we run on the same serial port. This drops back to the login prompt if it sees DCD being dropped. Jon PLANET PROJECT will connect millions of people worldwide through the combined technology of 3Com and the Internet. Find out more and register now at http://www.planetproject.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
Hi, Steve Hill wrote: > I'm building boxes with the console set to /dev/ttyS0. However, I can't > guarantee that there will always be a term plugged into the serial > port. If there is no term on the port, eventually the buffer fills and > any processes that write to the console (i.e. init) block. Is there some > option somewhere to stop this happening (i.e. either ignoring the > flow-control or just allowing the buffer to overflow)? > Try the following into /etc/inittab s1:12345:respawn:/sbin/agetty -L 19200 ttyS0 vt100 "-L" here means "ignore flow control", the rest, as you wish. Hope this helps, Vitaly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Network console project
On Tue, Feb 20, 2001 at 07:11:26PM -0800, H. Peter Anvin wrote: > Hi everyone, > > We have set up a network console project on sourceforge and are starting > to work on actual details. If you're interested in this subject please > do join that list. DEC's old protocol called MOP (Maintainence and Operations Protocol) comes in mind... MfG, JBG -- Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!! /* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) PGP signature
[PATCH]: console, kernel 2.2.18
Attached is my first submitted patch, so please be gentle. It's actually made against the 2.2.18 kernel, but it should work fine against 2.4.2 from what I can tell. The patch is extremely simple, but I would welcome testing and feedback (I am not on the kernel mailing list). It provides an ioctl call that will forcibly blank the screen. It is essentially the counterpart to TIOCLINUX, subcode=4. -- David Corbin [EMAIL PROTECTED] --- linux-2.2.18/drivers/char/console.c Sun Dec 10 19:49:41 2000 +++ linux/drivers/char/console.cFri Feb 23 06:54:40 2001 @@ -66,6 +66,9 @@ * * Resurrected character buffers in videoram plus lots of other trickery * by Martin Mares <[EMAIL PROTECTED]>, July 1998 + * + * Added ioctl sub-code to forcibly blank screen. + * by David Corbin <[EMAIL PROTECTED]>, February 2001 */ #include @@ -2139,6 +2142,9 @@ return 0; case 12:/* get fg_console */ return fg_console; + case 13: + blank_screen(); + return 0; } return -EINVAL; } Provide ioctl on console to force immediate "blanking", David Corbin <[EMAIL PROTECTED]>
Re: Escape sequences & console
On Thu, 1 Mar 2001, Sébastien HINDERER wrote: > Could someone tell me where I can find a document listing all the > escape-sequences that could be sent to the console (/dev/console) and what > they do. Please don't use those sequences directly, as not everyone has /dev/console on a vt. You can find the information you want in your local terminfo database under "linux". Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! NP: Inside Treatement - Klaustraph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Escape sequences & console
OKAY, but something strange appears: According to linux/drivers/console.c, function setterm_commands, case 12, one can change the virtual console by sending an escape sequence to /dev/cnsole (what I want to do), hower, this is not documented in man pages. Which escape-sequence should I send to /dev/console to switch tty? Thank you: Sébastien. -- > De : Simon Richter <[EMAIL PROTECTED]> > A : Sébastien HINDERER <[EMAIL PROTECTED]> > Cc : [EMAIL PROTECTED] > Objet : Re: Escape sequences & console > Date : jeudi 1 mars 2001 18:21 > > On Thu, 1 Mar 2001, Sébastien HINDERER wrote: > > > Could someone tell me where I can find a document listing all the > > escape-sequences that could be sent to the console (/dev/console) and what > > they do. > > Please don't use those sequences directly, as not everyone has > /dev/console on a vt. You can find the information you want in your local > terminfo database under "linux". > >Simon > > -- > GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc > Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 > Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! > NP: Inside Treatement - Klaustraph > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Escape sequences & console
Followup to: <[EMAIL PROTECTED]> By author:Simon Richter <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Thu, 1 Mar 2001, Sébastien HINDERER wrote: > > > Could someone tell me where I can find a document listing all the > > escape-sequences that could be sent to the console (/dev/console) and what > > they do. > > Please don't use those sequences directly, as not everyone has > /dev/console on a vt. You can find the information you want in your local > terminfo database under "linux". > Well, don't use them directly without checking that $TERM is "linux". Also, normally they should be sent to the current terminal (/dev/tty, or just stdout) rather than /dev/console. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Escape sequences & console
On Thu, Mar 01, 2001 at 07:03:50PM -, Sébastien HINDERER wrote: > Could someone tell me where I can find a document listing the > escape-sequences that could be sent to the console and what > they do. man console_codes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Escape sequences & console
On Thu, Mar 01, 2001 at 08:48:10PM -, Sébastien HINDERER wrote: > According to linux/drivers/console.c, function setterm_commands, case 12, > one can change the virtual console by sending an escape sequence to > /dev/cnsole (what I want to do), hower, this is not documented in man > pages. Hmm. How come I read ESC [ 12 ; n ] Bring specified console to the front. ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Escape sequences & console
On Thu, 1 Mar 2001, Sébastien HINDERER wrote:
> According to linux/drivers/console.c, function setterm_commands, case 12,
> one can change the virtual console by sending an escape sequence to
> /dev/cnsole (what I want to do), hower, this is not documented in man
> pages.
From the source of the chvt program:
if (ioctl(fd,VT_ACTIVATE,num)) {
perror("chvt: VT_ACTIVATE");
exit(1);
}
if (ioctl(fd,VT_WAITACTIVE,num)) {
perror("VT_WAITACTIVE");
exit(1);
}
Where fd is /dev/tty, /dev/tty0, /dev/console or std{in,out,err} (From the
source, I doubt this ioctl works on all of those).
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
UP: 10:29pm up 7 days, 3:40, 8 users, load average: 3.67, 4.43, 4.69
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Escape sequences & console
Followup to:
<[EMAIL PROTECTED]>
By author:Simon Richter <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> From the source of the chvt program:
>
> if (ioctl(fd,VT_ACTIVATE,num)) {
> perror("chvt: VT_ACTIVATE");
> exit(1);
> }
> if (ioctl(fd,VT_WAITACTIVE,num)) {
> perror("VT_WAITACTIVE");
> exit(1);
> }
>
> Where fd is /dev/tty, /dev/tty0, /dev/console or std{in,out,err} (From the
> source, I doubt this ioctl works on all of those).
>
/dev/tty0 would be the correct device (tty0 = current virtual
console.)
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Console driver and printing
Hi, I would like to know if know if there is any support for printing in the console driver. I mean, can the console receive from an application an mc4/mc5 sequence as defined in a terminfo entry and print what was sent in between? If so is there any way to configure the device to which the data would be sent? I hope I do not abuse this list by posting this question here, but I couldn't find any information anywhere else. If I can't print through the console, would anybody have any experience about configuring an xterm (which can print, I tested it) to use a cp437 (IBM) encoding? I've always managed to find everything myself, but I'm running short on time and this is the last problem before installing linux in 50 to 100 stores, so I could use a little help :-) Nicolas Cadou - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
'console=' kernel parameter questions
Hello, I am running an unmodified RedHat 6.2 kernel (kernel version 2.2.14-5.0) I am trying to redirect the linux startup messages to the serial port. I've added the 'console=' parameter to my lilo.conf file. I've tried several iterations such as 'console=ttys0','console=cua0','console=ttys0,9600n8', etc They all fail to produce any output to the serial port although they do remove the text from my screen. When I have booted RedHat I can type 'echo blah > /dev/cua0' and I see text output from the serial port. Interestingly when I try to echo to /dev/ttys0 I get an IO error message. I'm using a null modem cable connect to a windows machine to watch the serial port. My question: why can I see output when booted into RedHat but not when booting the OS? I've read that you have to compile this feature into the kernel. Does anyone know if RedHat's kernel come with this feature built in? Your help appreciated, Paul __ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Riva console frame buffer
List, Hi... I'm trying to use the riva console frame buffer driver under x86 linux. It works, but not the way I want it to, and I'm having a hard time finding info about kernel args for the riva frame buffer. Right now when I bootup it's in 640x480, and I change it to 1024x768 @70Hz w/ fbset in /etc/rc.local . I would like to give the kernel an arg to startup in 1024x768; eg video=riva:mode:1024x768-70,ypan,vc:1-8 Is there a way to do this w/ the riva frame buffer? Is there a list of kernel args for the riva frame buffer? my hardware: VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 15) mag DX700T kernel 2.4.3ac14 and 2.4.4ac3 thank you, -- Sean J. Swallow pgp (6.5.2) keyfile @ https://nurk.org/keyfile.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ACPI - console problems 2.4.4
Is anyone having problems with ACPI causing console problems in kernel 2.4.4 w/ Intel's patches? When watching my system boot over the serial console, things work fine. When looking at my VAIO-FX140's LCD, my console no longer updates after ACPI starts initializing _INI methods. I am able to login and shutdown without my LCD echoing back. Here is my output from the serial port: tbxface-0089: Context Switch from TID to TID 1 ACPI Tables successfully loaded Parsing Methods:... 195 Control Methods found and parsed (554 nodes total) ACPI Namespace successfully loaded at root c034a2d8 ACPI: Core Subsystem version [20010427] evxfevnt-0082: Transition to ACPI mode successful Executing device _INI methods:.. *** LAPTOP CONSOLE NO LONGER DISPLAYS ANYTHING evregion-0304: Ev_address_space_dispatch: Region handler: AE_ERROR [PCIConfig] breakpoint: Fatal error encountered nsinit-0333: \ /_SB_PCI0HUB_CRD1._INI failed: AE_ERROR 54 Devices found: 54 _STA, 1 _INI Completing Region and Field initialization:. 12/18 Regions, 5/5 Fields initialized (554 nodes total) ACPI: Subsystem enabled ACPI: System firmware supports S0 S3 S4 S5 Processor[0]: C0 C1 C2, throttling states: 8 Battery: socket found, battery present Battery: socket found, battery absent AC Adapter: found Power Button: found Lid Switch: found Thermal Zone: found NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. DEBUG: mount root filesystem VFS: Mounted root (ext2 filesystem) readonly. DEBUG: mounted root file DEBUG: free_initmem() Freeing unused kernel memory: 196k freed DEBUG: unlock kernel() DEBUG: open /dev/console DEBUG: exec init somewhere Restarting system. -- Nick PGP KEY: http://www.coelacanth.com/~nick/npapadon.public.asc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Matrox FB console driver
I was playing around with a program that I was using to time differences between kernels (a silly prime program that puts out 100 primes). I noticed a very strange behaviour. On a fresh boot, with the Penguin pictures that the Matrox FB driver puts up, the prime program runs 1 minute, 30 seconds. If I reset, it still runs 1M30S. If I start X, and exit, it runs 48 seconds. Is this a known behaviour? Thanks. Andy Carlson |\ _,,,---,,_ [EMAIL PROTECTED]ZZZzz /,`.-'`'-. ;-;;,_ BJC Health System |,4- ) )-,_. ,\ ( `'-' St. Louis, Missouri '---''(_/--' `-'\_) Cat Pics: http://andyc.dyndns.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Serial console != baud 9k6
Hi,
i am just working on a different arch (mips board) and try to initialize
the serial console from the arch specific setup with
setup_console("ttyS0,57600") which doesnt work it seems as
serial_console_setup is itself "__init" and has a default of 9k6.
So how do i init the serial console from the arch specific stuff with
something else than the default baud rate ?
Flo
--
Florian Lohoff [EMAIL PROTECTED] +49-5201-669912
Why is it called "common sense" when nobody seems to have any?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
console blanking and 2.4.1
Hi Since I installed Kernel 2.4.1 on our server, the monitor does not turn itself off after some minutes off inactivity... The screen goes blank, but the monitor stays turned on... Until and including 2.4.0 it worked fine. Monitor shut down, as soon as the screen (console) went blank. There's no X on the thing, so that should not be the problem. And i used the same .config for 2.4.0 and 2.4.1. ACPI is turned off. APM on. but it makes no differences if i use APM or not (in 2.4.0 and in 2.4.1) Any Idea where the problem could be? It has to be somewhere in the kernel, 'cause i didn't change anything on the system elsewhere and it still works with 2.4.0. But i have no idea where to look at in the sources... i use SuSE 7.0 and it's a Cyrix 200 Mhz. I don't know what kind of bios, but i can have a look, if that's important (i tried different settings there in the APM settings, but nothing helped neither) chregu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] console and bust_spinlocks() fixes
Three things.
- Adds lib/bust_spinlocks.c for architectures which don't
provide bust_spinlocks() .
- Closes a race between tioclinux() and console scrolling
which was leaving bits of stuff on the screen when the
mouse was used with gpm.
- Added a missing break statement in do_syslog() (James Simmons)
Patch against -ac20 is here. The full `remove console_lock' patch
against 2.4.3-pre4 is at http://www.uow.edu.au/~andrewm/linux/console.html
--- linux-2.4.2-ac20/drivers/char/console.c Tue Mar 13 20:29:21 2001
+++ ac/drivers/char/console.c Tue Mar 13 21:12:47 2001
@@ -69,6 +69,9 @@
*
* Removed old-style timers, introduced console_timer, made timer
* deletion SMP-safe. 17Jun00, Andrew Morton <[EMAIL PROTECTED]>
+ *
+ * Removed console_lock, enabled interrupts across all console operations
+ * 13 March 2001, Andrew Morton
*/
#include
@@ -1034,6 +1037,7 @@
color = def_color;
}
+/* console_sem is held */
static void csi_m(int currcons)
{
int i;
@@ -1173,6 +1177,7 @@
return report_mouse;
}
+/* console_sem is held */
static void set_mode(int currcons, int on_off)
{
int i;
@@ -1238,6 +1243,7 @@
}
}
+/* console_sem is held */
static void setterm_command(int currcons)
{
switch(par[0]) {
@@ -1292,19 +1298,7 @@
}
}
-static void insert_line(int currcons, unsigned int nr)
-{
- scrdown(currcons,y,bottom,nr);
- need_wrap = 0;
-}
-
-
-static void delete_line(int currcons, unsigned int nr)
-{
- scrup(currcons,y,bottom,nr);
- need_wrap = 0;
-}
-
+/* console_sem is held */
static void csi_at(int currcons, unsigned int nr)
{
if (nr > video_num_columns - x)
@@ -1314,15 +1308,18 @@
insert_char(currcons, nr);
}
+/* console_sem is held */
static void csi_L(int currcons, unsigned int nr)
{
if (nr > video_num_lines - y)
nr = video_num_lines - y;
else if (!nr)
nr = 1;
- insert_line(currcons, nr);
+ scrdown(currcons,y,bottom,nr);
+ need_wrap = 0;
}
+/* console_sem is held */
static void csi_P(int currcons, unsigned int nr)
{
if (nr > video_num_columns - x)
@@ -1332,15 +1329,18 @@
delete_char(currcons, nr);
}
+/* console_sem is held */
static void csi_M(int currcons, unsigned int nr)
{
if (nr > video_num_lines - y)
nr = video_num_lines - y;
else if (!nr)
nr=1;
- delete_line(currcons, nr);
+ scrup(currcons,y,bottom,nr);
+ need_wrap = 0;
}
+/* console_sem is held (except via vc_init->reset_terminal */
static void save_cur(int currcons)
{
saved_x = x;
@@ -1355,6 +1355,7 @@
saved_G1= G1_charset;
}
+/* console_sem is held */
static void restore_cur(int currcons)
{
gotoxy(currcons,saved_x,saved_y);
@@ -1375,6 +1376,7 @@
EShash, ESsetG0, ESsetG1, ESpercent, ESignore, ESnonstd,
ESpalette };
+/* console_sem is held (except via vc_init()) */
static void reset_terminal(int currcons, int do_clear)
{
top = 0;
@@ -1430,6 +1432,7 @@
csi_J(currcons,2);
}
+/* console_sem is held */
static void do_con_trol(struct tty_struct *tty, unsigned int currcons, int c)
{
/*
@@ -1810,6 +1813,7 @@
#define CON_BUF_SIZE PAGE_SIZE
DECLARE_MUTEX(con_buf_sem);
+/* acquires console_sem */
static int do_con_write(struct tty_struct * tty, int from_user,
const unsigned char *buf, int count)
{
@@ -2049,7 +2053,7 @@
void set_console(int nr)
{
want_console = nr;
- schedule_task(&console_callback_tq);
+ schedule_console_callback();
}
#ifdef CONFIG_VT_CONSOLE
@@ -2171,9 +2175,21 @@
* Handling of Linux-specific VC ioctls
*/
+/*
+ * Generally a bit racy with respect to console_sem().
+ *
+ * There are some functions which don't need it.
+ *
+ * There are some functions which can sleep for arbitrary periods (paste_selection)
+ * but we don't need the lock there anyway.
+ *
+ * set_selection has locking, and definitely needs it
+ */
+
int tioclinux(struct tty_struct *tty, unsigned long arg)
{
char type, data;
+ int ret;
if (tty->driver.type != TTY_DRIVER_TYPE_CONSOLE)
return -EINVAL;
@@ -2181,17 +2197,23 @@
return -EPERM;
if (get_user(type, (char *)arg))
return -EFAULT;
+ ret = 0;
switch (type)
{
case 2:
- return set_selection(arg, tty, 1);
+ acquire_console_sem();
+ ret = set_selection(arg, tty, 1);
+ release_console_sem();
+ break;
case 3:
- return paste_selection(tty);
+ ret = paste_selection(tty);
+ break;
Reliability of serial console driver
Hello All, I am not on the list, so please reply to me with the list with your comments. I was going through some code in serial.c and noticed that there are page allocations/deallocations in rs_open and startup (serial.c). These allocations could fail. This affects reliablity in some minor way Consider a system running out of memory and the administrator decided to grab the serial console (say from home) to see what was wrong.. His open would fail since we are running out of memory and he would not be able to use the remote serial console. I was wondering if it is a good idea to make some such allocations at boot time. This would mean that these allocations would never fail. I agree that the chances of such a scenario occuring is not very high, but it adds to the reliability of the OS. What do you think ? Ba Sin So. __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sudden console lockups (keyb+mouse)
This was about the fifth time when i experienced the following: all of a sudden, my keyboard and mouse (both together, at exactly the same time), stop responding, ie i can't type or move the mouse around. As the keyboard stop responding, i also can't use the Magic-key. All other things go on, process continue to run, i can see everything, but the only thing i can do is to press the reset button. (It seems that if had an other machine i could log in via network and shut it down.) Last time i had this problem about 10 seconds after starting X, but i also met this whitout X (while running for example mc). It might hw related, but i have no idea how could i go for sure (please don't tell me to try it under win :)) I'm running 2.4.1, the mainboard is an Abit VP6, with PS/2 keyboard and mouse. Balazs Pozsar. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 'console=' kernel parameter questions
On Mon, 8 Jan 2001, Paul Powell wrote: > 'console=ttys0','console=cua0','console=ttys0,9600n8', etc ^ console=ttyS0 Matthew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'console=' kernel parameter questions
I do believe RedHat kernels have this feature compiled in. This is probably an typo in the email but it's /dev/ttyS0 . Note the capital 'S'. On Mon, 8 Jan 2001, Paul Powell wrote: > Hello, > > I am running an unmodified RedHat 6.2 kernel > (kernel version 2.2.14-5.0) > > I am trying to redirect the linux startup messages to > the serial port. I've added the 'console=' parameter > to my lilo.conf file. I've tried several iterations > such as > 'console=ttys0','console=cua0','console=ttys0,9600n8', > etc > > They all fail to produce any output to the serial port > although they do remove the text from my screen. When > I have booted RedHat I can type 'echo blah > > /dev/cua0' and I see text output from the serial port. > Interestingly when I try to echo to /dev/ttys0 I get > an IO error message. I'm using a null modem cable > connect to a windows machine to watch the serial port. > > My question: why can I see output when booted into > RedHat but not when booting the OS? I've read that > you have to compile this feature into the kernel. > Does anyone know if RedHat's kernel come with this > feature built in? > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'console=' kernel parameter questions
append="console=/dev/ttyS0" that should do the trick enjoy -kelsery On Mon, 8 Jan 2001, Paul Powell wrote: > Hello, > > I am running an unmodified RedHat 6.2 kernel > (kernel version 2.2.14-5.0) > > I am trying to redirect the linux startup messages to > the serial port. I've added the 'console=' parameter > to my lilo.conf file. I've tried several iterations > such as > 'console=ttys0','console=cua0','console=ttys0,9600n8', > etc > > They all fail to produce any output to the serial port > although they do remove the text from my screen. When > I have booted RedHat I can type 'echo blah > > /dev/cua0' and I see text output from the serial port. > Interestingly when I try to echo to /dev/ttys0 I get > an IO error message. I'm using a null modem cable > connect to a windows machine to watch the serial port. > > My question: why can I see output when booted into > RedHat but not when booting the OS? I've read that > you have to compile this feature into the kernel. > Does anyone know if RedHat's kernel come with this > feature built in? > > Your help appreciated, > Paul > > > __ > Do You Yahoo!? > Yahoo! Photos - Share your holiday photos online! > http://photos.yahoo.com/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > -- Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Riva console frame buffer
> Right now when I bootup it's in 640x480, and I change it to 1024x768 @70Hz > w/ fbset in /etc/rc.local . I would like to give the kernel an arg to > startup in 1024x768; eg video=riva:mode:1024x768-70,ypan,vc:1-8 > > Is there a way to do this w/ the riva frame buffer? Is there a list of > kernel args for the riva frame buffer? Yes. Most fbdev drivers use modedb which provides a standard easy way to select a video resolution. video=riva:x[-][@refresh] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
serial console broken in 2.4.4?
Hello,
I have noticed strange serial console behaviour in 2.4.4.
I have system with gettys on ttyS0 and tty1.
When I boot with usual console (set to tty1), getty on ttyS0 works.
When I boot with console set to ttyS0 ("console=ttyS0,9600n8"),
getty on ttyS0 doesnot respond on input (although ps shows it running);
all kernel messages are showed on ttyS0, but it seems that _input_ is
disallowed/broken. Things were okay somewhere around (AFAIR) 2.4.0pre..
Is this a known 2.4 bug? Any patch to fix this?
--
Regards,
Konstantin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI - console problems 2.4.4
Hi! > Is anyone having problems with ACPI causing console problems in kernel > 2.4.4 w/ Intel's patches? When watching my system boot over the > serial console, things work fine. When looking at my VAIO-FX140's > LCD, my console no longer updates after ACPI starts initializing _INI methods. > > I am able to login and shutdown without my LCD echoing back. > > Here is my output from the serial port: Is this vanilla 2.4.4? I somehow doubt that. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI - console problems 2.4.4
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > > > Is anyone having problems with ACPI causing console problems in kernel > > 2.4.4 w/ Intel's patches? When watching my system boot over the > > serial console, things work fine. When looking at my VAIO-FX140's > > LCD, my console no longer updates after ACPI starts initializing _INI methods. > > > > I am able to login and shutdown without my LCD echoing back. > > > > Here is my output from the serial port: > > Is this vanilla 2.4.4? I somehow doubt that. > Pavel Yes it is, however with Intel's ACPI patches. I suspect there is a problem with the VGA adapter + ACPI. I haven't been able to use ACPI at all because of this. Is there ANYONE out there that has a VAIO? It would be nice if someone could reproduce this too. - Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI - console problems 2.4.4
> Is anyone having problems with ACPI causing console problems in kernel > 2.4.4 w/ Intel's patches? When watching my system boot over the > serial console, things work fine. When looking at my VAIO-FX140's > LCD, my console no longer updates after ACPI starts initializing _INI methods. Generally a good rule is 'dont bother with ACPI'. But do let Andrew Grover know how it fails on your box - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI - console problems 2.4.4
Alan Cox <[EMAIL PROTECTED]> writes: > > Is anyone having problems with ACPI causing console problems in kernel > > 2.4.4 w/ Intel's patches? When watching my system boot over the > > serial console, things work fine. When looking at my VAIO-FX140's > > LCD, my console no longer updates after ACPI starts initializing _INI methods. > > Generally a good rule is 'dont bother with ACPI'. But do let Andrew Grover > know how it fails on your box > My VAIO doesn't support APM. :( I was trying to understand the call path on _INIT. Hopefully with some printk's I can track down the problem. Any direction or areas for me to examine? Thanks. -- Nick PGP KEY: http://www.coelacanth.com/~nick/npapadon.public.asc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Matrox FB console driver
time prime before x real1m23.535s user0m40.550s sys 0m42.980s /proc/mtrr before x reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xfd80 (4056MB), size= 4MB: write-combining, count=1 time prime after x real0m48.732s user0m41.070s sys 0m7.690s /proc/mtrr after x reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xfd80 (4056MB), size= 4MB: write-combining, count=1 time prime in X real0m42.835s user0m41.180s sys 0m1.710s /proc/version Linux version 2.4.3-ac12 (root@bigandy) (gcc version 2.95.2 19991024 (release)) #15 SMP Mon Apr 23 19:35:33 CDT 2001 /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 1 model name : Pentium Pro stepping: 9 cpu MHz : 199.312 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov bogomips: 397.31 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 1 model name : Pentium Pro stepping: 7 cpu MHz : 199.312 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov bogomips: 398.13 Andy Carlson |\ _,,,---,,_ [EMAIL PROTECTED]ZZZzz /,`.-'`'-. ;-;;,_ BJC Health System |,4- ) )-,_. ,\ ( `'-' St. Louis, Missouri '---''(_/--' `-'\_) Cat Pics: http://andyc.dyndns.org On Mon, 23 Apr 2001, Mark Hahn wrote: > > I was playing around with a program that I was using to time differences > > between kernels (a silly prime program that puts out 100 primes). I > > noticed a very strange behaviour. On a fresh boot, with the Penguin > > pictures that the Matrox FB driver puts up, the prime program runs > > 1 minute, 30 seconds. If I reset, it still runs 1M30S. If I start X, > > and exit, it runs 48 seconds. Is this a known behaviour? Thanks. > > do you mean that running and exiting X makes your computer faster? > is /proc/mtrr sane at both times? > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Matrox FB console driver
On Tue, Apr 24, 2001 at 06:19:31AM -0500, Andy Carlson wrote: > time prime before x > real1m23.535s > user0m40.550s > sys 0m42.980s > > time prime in X > real0m42.835s > user0m41.180s > sys 0m1.710s There can be two reasons: (1) You are using matrox's mga module. They have 'program chip core to production level frequency instead of bios safe one' in their changelog. Although difference 100% makes (2) more probably. (2) matroxfb does not try to activate any AGP transfer mode. Maybe some X driver tries and succeeds. You can try: time dd if=/dev/zero of=/dev/fb0 bs=1M count=8 before X and after X. If times are same, then it is chip core frequency. If times are 2:1, it is either chip memory freqency, or AGP... Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
serial console problems with 2.4.4
Hi I just installed 2.4.4 on our alpha SMP boxes (ES40) and now I have problems with the serial console: sulogin does not accept input from the serial line mingetty does not accept input from the serial line agetty works fine Everything works fine for the 2.4.2 kernel. I took the .config file from the 2.4.2 kernel to compile the 2.4.4 kernel. Any ideas? Reto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
console=ttyS0 doesn't work 2.4.4
I compiled the Linux kernel v2.4.4 and can't get 'console=ttyS0,115200 console=tty0' to work. This appended line works fine when I boot into my 2.2.x series kernel. Anyone have similar problems? Has anyone verified serial console output works with the 2.4.x kernels? Thanks. - Nick Here is my /etc/lilo.conf: boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message linear default=linuxold append="console=ttyS0,115200 console=tty0" image=/boot/vmlinuz-2.2.16-22 label=linuxold read-only root=/dev/hda6 image=/boot/vmlinuz-2.4.4 label=linux read-only root=/dev/hda6 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] console palette fix
Hi James,
Linus is not the maintainer of the 2.2.* kernels, Alan Cox is (see CC).
Although this patch is correct, and was accepted in 2.4.*, it creates a
secondary problem after applying it - A dark textmode console for some
cards, unrelated to the frame buffer mode. An *additional* patch is needed
in order to fix it:
--- linux-2.2.17/drivers/char/console.c Mon Sep 4 15:39:17 2000
+++ linux.vanilla/drivers/char/console.cThu Oct 5 15:17:00 2000
@@ -2569,6 +2569,7 @@
console_blanked = 0;
if (console_blank_hook)
console_blank_hook(0);
+ set_palette(currcons);
if (sw->con_blank(vc_cons[currcons].d, 0))
/* Low-level driver cannot restore -> do it ourselves */
update_screen(fg_console);
> Here is patch to fix console palettes for the 2.2.X kernels. Its against
> 2.2.17.
>
> --- console.c.origWed Oct 4 22:23:34 2000
> +++ console.c Wed Oct 4 22:28:50 2000
> @@ -575,10 +575,13 @@
> }
>
> if (redraw) {
> + int update;
> +
> set_origin(currcons);
> + update = sw->con_switch(vc_cons[currcons].d);
> set_palette(currcons);
> - if (sw->con_switch(vc_cons[currcons].d) && vcmode != KD_GRAPHICS)
> - /* Update the screen contents */
> + if (update && vcmode != KD_GRAPHICS)
> + /* Update the screen contents */
> do_update_region(currcons, origin, screenbuf_size/2);
> }
> set_cursor(currcons);
>
--
Dan Aloni
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] console palette fix
On Sat, 7 Oct 2000, James Simmons wrote: > > > Although this patch is correct, and was accepted in 2.4.*, it creates a > > secondary problem after applying it - A dark textmode console for some > > cards, unrelated to the frame buffer mode. An *additional* patch is needed > > in order to fix it: > > Yes their was this problem with a earlier patch but I was under the > impression that the most recent patch (below) fixed this problem. Do you > know which cards have this problem? I like to get a list of them to see > what could be causing the problem. I believe it is a X server problem. My > theory is that the problem occurs for video cards whose X servers use the > gamma ramp. I personally have never seen this problem but if you can tell > which cards specifically I can get that card and track down the problem. > Has your patch been tested with all the cards avaliable with this problem? I've seen the problem on both of my computers with Creative Riva TNT2. On this card the palette turns darker. On other cards the palette turns to rubbish or corrupted in another fashionable ways. It's a bug in those cards - switching to video mode and back to text mode doesn't preserve the text mode palette so the OS must restore it by itself. It's not an X server problem, since the problem doesn't appear on 2.2.16 for instance, no mather which X-server you are using. Search lkml archives for "dark console" you'll see a thread from 2 months ago that discusses about this problem exactly. Read the console.c of 2.4 - Linus already patched it this way (your patch and then my patch), so I suggest we do the same in 2.2. -- Dan Aloni [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] console palette fix
> I've seen the problem on both of my computers with Creative Riva TNT2. On > this card the palette turns darker. On other cards the palette turns to > rubbish or corrupted in another fashionable ways. It's a bug in those > cards - switching to video mode and back to text mode doesn't preserve the > text mode palette so the OS must restore it by itself. Now looking closer to the XFree86 code your right. It is buggy hardware. XFree86 X servers do attempt to reset the VGA palette themselves for all cards. It is basic code and should work on all video cards. > about this problem exactly. Read the console.c of 2.4 - Linus already > patched it this way (your patch and then my patch), so I suggest we do the > same in 2.2. Agree. Alan please patch 2.2.X with both are patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[sligthly OT] serial console on palm
I remember seing a project to get a palm pilot working as a serial console, but now google seems unable to find it. Does anyone know of such a project? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: BOFH excuse #280: Traceroute says that there is a routing problem in the backbone. It's not our problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] serial console vs NMI watchdog
SYSRQ-T on serial console can crash the machine. This
is because a large amount of output is sent to a slow
device while interrupts are disabled. The NMI
watchdog triggers.
The interrupt disabling happens in pc_keyb.c:keyboard_interrupt().
Changing this code to *not* disable interrupts looks complex.
I see two ways of fixing this. One is to do the sysrq
stuff outside the spin_lock_irq(), with:
static void keyboard_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
+ extern void (*sysrq_handler)(void);
+ void (*my_sysrq_handler)(void);
spin_lock_irq(&kbd_controller_lock);
handle_kbd_event();
+ my_sysrq_handler = sysrq_handler;
+ sysrq_handler = 0;
spin_unlock_irq(&kbd_controller_lock);
+ if (my_sysrq_handler)
+ (*my_sysrq_handler)();
}
But I didn't do that, because I suspect there are other
places in the kernel (development and debug stuff) where
we want to turn the NMI watchdog handler off for a while.
So this patch creates a new API function
enable_nmi_watchdog(int yes);
and uses it within the sysrq code.
BTW: NMI watchdog is now disabled by default in 2.4.3-pre3.
The `nmi_watchdog=1' boot option is needed to enable it.
--- linux-2.4.2-ac16/include/linux/irq.hFri Mar 9 17:11:17 2001
+++ linux-ac/include/linux/irq.hSat Mar 10 01:02:12 2001
@@ -56,6 +56,20 @@
#include /* the arch dependent stuff */
+/**
+ * enable_nmi_watchdog - enables/disables NMI watchdog checking.
+ * @yes: If zero, disable
+ *
+ * If the architecture supports the NMI watchdog, enable_nmi_watchdog() may be used
+ * to temporarily disable it. Calls to enable_nmi_watchdog() may be nested - it is
+ * implemented as an up/down counter, so the calls must be balanced.
+ */
+#ifdef ARCH_HAS_NMI_WATCHDOG
+extern void enable_nmi_watchdog(int yes);
+#else
+#define enable_nmi_watchdog(yes) do{} while(0)
+#endif
+
extern int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction *);
extern int setup_irq(unsigned int , struct irqaction * );
--- linux-2.4.2-ac16/include/asm-i386/irq.h Fri Oct 8 03:17:09 1999
+++ linux-ac/include/asm-i386/irq.h Fri Mar 9 22:59:15 2001
@@ -32,4 +32,8 @@
extern void disable_irq_nosync(unsigned int);
extern void enable_irq(unsigned int);
+#ifdef CONFIG_X86_LOCAL_APIC
+#define ARCH_HAS_NMI_WATCHDOG /* See include/linux/irq.h */
+#endif
+
#endif /* _ASM_IRQ_H */
--- linux-2.4.2-ac16/drivers/char/sysrq.c Sun Feb 25 17:37:04 2001
+++ linux-ac/drivers/char/sysrq.c Fri Mar 9 23:00:39 2001
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
@@ -69,6 +70,11 @@
if (!key)
return;
+ /*
+* Interrupts are disabled, and serial consoles are slow. So
+* Let's suspend the NMI watchdog.
+*/
+ enable_nmi_watchdog(0);
console_loglevel = 7;
printk(KERN_INFO "SysRq: ");
switch (key) {
@@ -152,6 +158,7 @@
/* Don't use 'A' as it's handled specially on the Sparc */
}
+ enable_nmi_watchdog(1);
console_loglevel = orig_log_level;
}
--- linux-2.4.2-ac16/arch/i386/kernel/nmi.c Fri Mar 9 17:10:51 2001
+++ linux-ac/arch/i386/kernel/nmi.c Sat Mar 10 01:10:50 2001
@@ -226,6 +226,15 @@
}
static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
+static atomic_t nmi_watchdog_enabled = ATOMIC_INIT(0); /* 0 == enabled */
+
+void enable_nmi_watchdog(int yes)
+{
+ if (yes)
+ atomic_inc(&nmi_watchdog_enabled);
+ else
+ atomic_dec(&nmi_watchdog_enabled);
+}
void nmi_watchdog_tick (struct pt_regs * regs)
{
@@ -255,7 +264,7 @@
sum = apic_timer_irqs[cpu];
- if (last_irq_sums[cpu] == sum) {
+ if (last_irq_sums[cpu] == sum && atomic_read(&nmi_watchdog_enabled) == 0) {
/*
* Ayiee, looks like this CPU is stuck ...
* wait a few IRQs (5 seconds) before doing the oops ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
APM, virtual console problem in 2.4.0
Greetings. When suspending my laptop (Toshiba Satellite 1605CDS; BIOS set to suspend to disk) with Debian 2.2r2's 'apm -s', the screen blanks and then the system locks up hard (not even the power button works). In 2.2.17, 'apm -s' works properly, first blanking the screen (maybe twice), then (apparently) handing off to the BIOS. It looks like the handing off isn't reached in 2.4.0; the screen blanks, but it never reaches the BIOS's 'Saving to Disk' screen. Additionally (included because of the similar symptomology), when changing virtual consoles under 2.4.0 and running X (XFree86 3.3.6; from Debian 2.2r0), the screen blanks once again, but then the system lock up hard, exactly as above. Any ideas what I might be doing wrong or what needs to be fixed? If I get some time in the next few days, I'll look at the code; but school's coming up and I have a lot of work to get done. I can supply more information if you need it. Thanks! -Joseph -- [EMAIL PROTECTED] "I felt a great disturbance in the force. As if a significant plot line suddenly cried out in terror... and was suddenly silenced." -Torg in "Sluggy Freelance" www.sluggy.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] Re: console spin_lock
On 18 Jan 01 at 0:49, Andrew Morton wrote: > Assumption: > - Once the system is up and running, it's always safe to > call down() when in_interrupt() returns false - probably > not the case in parts of the exit path - tough. > > Anyway, that's the thoughtware. Sound sane? Do not forget to handle printk() done by fbdev driver... It may invoke printk() from user context, but with console_semaphore already held... Something like reentrant_semaphore? Also, we should declare which console/fbdev function can printk/can schedule and which must not, as using interrupts & schedule could yield CPU to other tasks when (hardware assisted) operation is performed. Some of them (clear, bmove) can take loong time to finish. Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
vt.c: unimap changes to (fg_?)console
Hi Linus, Alan, Andries,
if you open /dev/tty4 and change the font via ioctl(KDFONTOP), it will be
applied to the opened console, i.e. tty4. Then you set the corresponding
unicodemap via PIO_UNIMAPCLR and PIO_UNIMAP ioctls. Those get applied to the
current foreground console. Which is inconsistent.
Looking at vt.c: vt_ioctl(), the situation is a bit messy: Some ioctls don't
explicitly specify a tty (probably not needed, as some settings are global),
some apply to fg_console, some apply to the opened console which is
((struct vt_struct*)tty->driver_data)->vc_num.
I would appreciate, if somebody with more knowledge could have a look and
check whether this is all correct. At least for the above case, it's not.
(Andries, I would appreciate if you have a look; you understand much more of
it than I do.)
I attach a patch to fix the specific problem reported above. It applies to
both 2.4.4 and 2.2.19. ioctl(PIO_UNIMAP[CLR]) is applied to the opened
console now instead of fg_console.
Please apply until somebody comes with a complete vt.c cleanup!
If you want to test yourself: I also have a patch against kbd-1.05
which allows you to use setfont -c /dev/ttyXX to specify which terminal you
want to. I already sent it to Andries.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
--- linux-244.compile/drivers/char/vt.c.origFri Feb 9 20:30:22 2001
+++ linux-244.compile/drivers/char/vt.c Mon May 7 10:37:25 2001
@@ -392,7 +392,7 @@
}
static inline int
-do_unimap_ioctl(int cmd, struct unimapdesc *user_ud,int perm)
+do_unimap_ioctl(int cmd, struct unimapdesc *user_ud, int perm, unsigned int console)
{
struct unimapdesc tmp;
int i = 0;
@@ -408,9 +408,11 @@
case PIO_UNIMAP:
if (!perm)
return -EPERM;
- return con_set_unimap(fg_console, tmp.entry_ct, tmp.entries);
+ return con_set_unimap(console, tmp.entry_ct, tmp.entries);
case GIO_UNIMAP:
- return con_get_unimap(fg_console, tmp.entry_ct, &(user_ud->entry_ct),
tmp.entries);
+ if (!perm && fg_console != console)
+ return -EPERM;
+ return con_get_unimap(console, tmp.entry_ct, &(user_ud->entry_ct),
+tmp.entries);
}
return 0;
}
@@ -1029,13 +1031,13 @@
return -EPERM;
i = copy_from_user(&ui, (void *)arg, sizeof(struct unimapinit));
if (i) return -EFAULT;
- con_clear_unimap(fg_console, &ui);
+ con_clear_unimap(console, &ui);
return 0;
}
case PIO_UNIMAP:
case GIO_UNIMAP:
- return do_unimap_ioctl(cmd, (struct unimapdesc *)arg, perm);
+ return do_unimap_ioctl(cmd, (struct unimapdesc *)arg, perm, console);
case VT_LOCKSWITCH:
if (!suser())
PGP signature
Re: serial console broken in 2.4.4?
This is not a real patch but it works fine for me:
--- drivers/char/serial.c.orig Thu May 3 09:29:00 2001
+++ drivers/char/serial.c Thu May 3 09:29:34 2001
@@ -1764,8 +1764,8 @@
/*
* !!! ignore all characters if CREAD is not set
*/
- if ((cflag & CREAD) == 0)
- info->ignore_status_mask |= UART_LSR_DR;
+// if ((cflag & CREAD) == 0)
+// info->ignore_status_mask |= UART_LSR_DR;
save_flags(flags); cli();
if (uart_config[info->state->type].flags & UART_STARTECH) {
serial_outp(info, UART_LCR, 0xBF);
This stuff got changed between 2.4.3 and 2.4.4 but I don't know why and
it broke my serial console. Please let me know when you know the "real"
fix for this problem.
Reto
Konstantin Boldyshev wrote:
>
> Hello,
>
> I have noticed strange serial console behaviour in 2.4.4.
> I have system with gettys on ttyS0 and tty1.
> When I boot with usual console (set to tty1), getty on ttyS0 works.
> When I boot with console set to ttyS0 ("console=ttyS0,9600n8"),
> getty on ttyS0 doesnot respond on input (although ps shows it running);
> all kernel messages are showed on ttyS0, but it seems that _input_ is
> disallowed/broken. Things were okay somewhere around (AFAIR) 2.4.0pre..
> Is this a known 2.4 bug? Any patch to fix this?
>
> --
> Regards,
> Konstantin
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
serial console problems under 2.4.4/5
Hi. I have started having serial console problems in the last bunch of kernel releases. I have tried various 2.4.4 and 2.4.5 ac kernels (up to and including 2.4.5-ac4) and the problem has persisted. The problem is basically that serial console doesn't recieve. I know that the hardware works properly, and lilo and other kernels even work fine from serial console. As far as I can tell, only one direction is broken, serial receive. (ie, an echo foo > /dev/ttyS0 shows up on the serial console, but an echo to the serial device on the other end of the console never shows up) The serial hardware is detected: Serial driver version 5.05b (2001-05-03) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A the pertinant parts of .config are: CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set CONFIG_SERIAL_NONSTANDARD=y # CONFIG_COMPUTONE is not set CONFIG_ROCKETPORT=y # CONFIG_CYCLADES is not set Has anyone else seen this, or have any ideas what is broken? thanks... -nld - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Matrox FB console driver
On Mon, Apr 23, 2001 at 08:06:11PM -0500, Andy Carlson wrote: > I was playing around with a program that I was using to time differences > between kernels (a silly prime program that puts out 100 primes). I > noticed a very strange behaviour. On a fresh boot, with the Penguin > pictures that the Matrox FB driver puts up, the prime program runs > 1 minute, 30 seconds. If I reset, it still runs 1M30S. If I start X, > and exit, it runs 48 seconds. Is this a known behaviour? Thanks. is there any change in /proc/mtrr before and after X? Good luck, Jurriaan -- BOFH excuse #176: vapors from evaporating sticky-note adhesives GNU/Linux 2.4.3-ac12 SMP/ReiserFS 2x1743 bogomips load av: 0.13 0.03 0.01 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
On 02 May 2001 10:37:21 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Fabrice Gautier <[EMAIL PROTECTED]> writes:
> > So this this probably a sulogin/mingetty problem. They should set the
> > CREAD flag in your tty c_cflag.
> >
> > the patch for busybox repalced the line
> > tty.c_cflag |= HUPCL|CLOCAL
> > by
> > tty.c_cflag |= CREAD|HUPCL|CLOCAL
> >
> > Hope this help.
>
> This part is correct.
>
> However the kernel sets CREAD by default.
Are your sure? Wasn't this the behaviour for 2.4.2 but changed in 2.4.3
> sysvinit (and possibly other inits) clears CREAD.
In my case I was using busybox as init. So there is no sysinit or any other
init called before this line.
> I wish I knew where the breakage actually occured.
Just look at this diff on serial.c between 2.4.2 and 2.4.3:
--- serial.cSat Apr 21 17:22:53 2001
+++ ../../../linux-2.4.2/drivers/char/serial.c Sat Feb 17 01:02:36 2001
@@ -1764,8 +1765,8 @@
/*
* !!! ignore all characters if CREAD is not set
*/
-// if ((cflag & CREAD) == 0)
-// info->ignore_status_mask |= UART_LSR_DR;
+ if ((cflag & CREAD) == 0)
+ info->ignore_status_mask |= UART_LSR_DR;
save_flags(flags); cli();
if (uart_config[info->state->type].flags & UART_STARTECH) {
serial_outp(info, UART_LCR, 0xBF);
--
Fabrice Gautier <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
Fabrice Gautier <[EMAIL PROTECTED]> writes: > On Wed, 02 May 2001 11:54:11 +0200 > Reto Baettig <[EMAIL PROTECTED]> wrote: > > > Hi > > > > I just installed 2.4.4 on our alpha SMP boxes (ES40) and now I have > > problems with the serial console: > > I get same kind of problem when upgrading from 2.4.2 to 2.4.3 and using > busybox as init/getty > > The problem was a bug in busybox. The console initialisation code was > not correct. > > > > sulogin does not accept input from the serial line > > mingetty does not accept input from the serial line > > agetty works fine > > So this this probably a sulogin/mingetty problem. They should set the > CREAD flag in your tty c_cflag. > > the patch for busybox repalced the line > tty.c_cflag |= HUPCL|CLOCAL > by > tty.c_cflag |= CREAD|HUPCL|CLOCAL > > Hope this help. This part is correct. However the kernel sets CREAD by default. sysvinit (and possibly other inits) clears CREAD. I wish I knew where the breakage actually occured. And then sulogin/mingetty need to reenable it. It's not too big of a deal except the serial code doesn't accept SAK's when CREAD is clear. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
On Wed, 02 May 2001 11:54:11 +0200 Reto Baettig <[EMAIL PROTECTED]> wrote: > Hi > > I just installed 2.4.4 on our alpha SMP boxes (ES40) and now I have > problems with the serial console: I get same kind of problem when upgrading from 2.4.2 to 2.4.3 and using busybox as init/getty The problem was a bug in busybox. The console initialisation code was not correct. > > sulogin does not accept input from the serial line > mingetty does not accept input from the serial line > agetty works fine So this this probably a sulogin/mingetty problem. They should set the CREAD flag in your tty c_cflag. the patch for busybox repalced the line tty.c_cflag |= HUPCL|CLOCAL by tty.c_cflag |= CREAD|HUPCL|CLOCAL Hope this help. -- Fabrice Gautier <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
Fabrice Gautier <[EMAIL PROTECTED]> writes:
> On 02 May 2001 10:37:21 -0600
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> > Fabrice Gautier <[EMAIL PROTECTED]> writes:
> > > So this this probably a sulogin/mingetty problem. They should set the
> > > CREAD flag in your tty c_cflag.
> > >
> > > the patch for busybox repalced the line
> > > tty.c_cflag |= HUPCL|CLOCAL
> > > by
> > > tty.c_cflag |= CREAD|HUPCL|CLOCAL
> > >
> > > Hope this help.
> >
> > This part is correct.
> >
> > However the kernel sets CREAD by default.
>
> Are your sure? Wasn't this the behaviour for 2.4.2 but changed in 2.4.3
init=/bin/bash works fine over a serial console in 2.4.4. So I am
certain.
I get the impression that something in 2.4.3 fixed CREAD handling, and we
started noticing the buggy user space.
> > sysvinit (and possibly other inits) clears CREAD.
>
> In my case I was using busybox as init. So there is no sysinit or any other
> init called before this line.
The busy box init is also clearing CREAD (as of 0.51 anyway).
> > I wish I knew where the breakage actually occured.
>
> Just look at this diff on serial.c between 2.4.2 and 2.4.3:
If it was a real diff between 2.4.2 and 2.4.3 I would agree, however it looks
like your attempt to fix 2.4.3.
Eric
> --- serial.c Sat Apr 21 17:22:53 2001
> +++ ../../../linux-2.4.2/drivers/char/serial.cSat Feb 17 01:02:36 2001
> @@ -1764,8 +1765,8 @@
> /*
>* !!! ignore all characters if CREAD is not set
>*/
> -// if ((cflag & CREAD) == 0)
> -// info->ignore_status_mask |= UART_LSR_DR;
> + if ((cflag & CREAD) == 0)
> + info->ignore_status_mask |= UART_LSR_DR;
> save_flags(flags); cli();
> if (uart_config[info->state->type].flags & UART_STARTECH) {
> serial_outp(info, UART_LCR, 0xBF);
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
On 03 May 2001 02:15:03 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > I get the impression that something in 2.4.3 fixed CREAD handling, and we > started noticing the buggy user space. That's my impression too... > > > I wish I knew where the breakage actually occured. > > > > Just look at this diff on serial.c between 2.4.2 and 2.4.3: > > If it was a real diff between 2.4.2 and 2.4.3 I would agree, however it looks > like your attempt to fix 2.4.3. Err... Yes sorry, in fact this was a workaround proposed by Kanoj, the maintener of serial.c (I think)... Regards. -- Fabrice Gautier <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console=ttyS0 doesn't work 2.4.4
Solved. Disregard. I didn't have serial console support compiled in. Nick Papadonis <[EMAIL PROTECTED]> writes: > I compiled the Linux kernel v2.4.4 and can't get 'console=ttyS0,115200 > console=tty0' to work. This appended line works fine when I boot > into my 2.2.x series kernel. > > Anyone have similar problems? Has anyone verified serial console > output works with the 2.4.x kernels? Thanks. > > - Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.3.x] struct console init
Hi Linus,
This patch converts all initializations of `struct console' objects to new
style initialization constructs.
--- linux-2.4.0-test10-pre1/drivers/char/console.c Fri Aug 11 13:53:24 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/console.c Thu Oct 12 15:27:04
+2000
@@ -2147,17 +2147,13 @@
}
struct console vt_console_driver = {
- "tty",
- vt_console_print,
- NULL,
- vt_console_device,
- keyboard_wait_for_keypress,
- unblank_screen,
- NULL,
- CON_PRINTBUFFER,
- -1,
- 0,
- NULL
+ name: "tty",
+ write: vt_console_print,
+ device: vt_console_device,
+ wait_key: keyboard_wait_for_keypress,
+ unblank:unblank_screen,
+ flags: CON_PRINTBUFFER,
+ index: -1,
};
#endif
--- linux-2.4.0-test10-pre1/drivers/char/dz.c Tue Jul 18 14:07:06 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/dz.c Thu Oct 12 15:27:11 2000
@@ -1553,17 +1553,13 @@
}
static struct console dz_sercons = {
- "ttyS",
- dz_console_print,
- NULL,
- dz_console_device,
- dz_console_wait_key,
- NULL,
- dz_console_setup,
- CON_CONSDEV | CON_PRINTBUFFER,
- CONSOLE_LINE,
- 0,
- NULL
+ name: "ttyS",
+ write: dz_console_print,
+ device: dz_console_device,
+ wait_key: dz_console_wait_key,
+ setup: dz_console_setup,
+ flags: CON_CONSDEV | CON_PRINTBUFFER,
+ index: CONSOLE_LINE,
};
void __init dz_serial_console_init(void)
--- linux-2.4.0-test10-pre1/drivers/char/lp.c Wed Oct 4 19:53:03 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/lp.c Thu Oct 12 15:27:17 2000
@@ -603,17 +603,10 @@
}
static struct console lpcons = {
- "lp",
- lp_console_write,
- NULL,
- lp_console_device,
- NULL,
- NULL,
- NULL,
- CON_PRINTBUFFER,
- 0,
- 0,
- NULL
+ name: "lp",
+ write: lp_console_write,
+ device: lp_console_device,
+ flags: CON_PRINTBUFFER,
};
#endif /* console on line printer */
--- linux-2.4.0-test10-pre1/drivers/char/serial.c Sat Sep 23 17:31:15 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/serial.c Thu Oct 12 15:27:24
+2000
@@ -5666,17 +5666,13 @@
}
static struct console sercons = {
- "ttyS",
- serial_console_write,
- NULL,
- serial_console_device,
- serial_console_wait_key,
- NULL,
- serial_console_setup,
- CON_PRINTBUFFER,
- -1,
- 0,
- NULL
+ name: "ttyS",
+ write: serial_console_write,
+ device: serial_console_device,
+ wait_key: serial_console_wait_key,
+ setup: serial_console_setup,
+ flags: CON_PRINTBUFFER,
+ index: -1,
};
/*
--- linux-2.4.0-test10-pre1/drivers/char/serial167.cMon Jul 17 15:20:00 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/serial167.cThu Oct 12 15:27:31
+2000
@@ -2858,17 +2858,13 @@
static struct console sercons = {
- "ttyS",
- serial167_console_write,
- NULL,
- serial167_console_device,
- serial167_console_wait_key,
- NULL,
- serial167_console_setup,
- CON_PRINTBUFFER,
- -1,
- 0,
- NULL
+ name: "ttyS",
+ write: serial167_console_write,
+ device: serial167_console_device,
+ wait_key: serial167_console_wait_key,
+ setup: serial167_console_setup,
+ flags: CON_PRINTBUFFER,
+ index: -1,
};
--- linux-2.4.0-test10-pre1/drivers/char/serial_21285.c Tue Aug 15 19:00:27 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/serial_21285.c Thu Oct 12 15:27:39
+2000
@@ -490,17 +490,13 @@
static struct console rs285_cons =
{
- SERIAL_21285_NAME,
- rs285_console_write,
- NULL,
- rs285_console_device,
- rs285_console_wait_key,
- NULL,
- rs285_console_setup,
- CON_PRINTBUFFER,
- -1,
- 0,
- NULL
+ name: SERIAL_21285_NAME,
+ write: rs285_console_write,
+ device: rs285_console_device,
+ wait_key: rs285_console_wait_key,
+ setup: rs285_console_setup,
+ flags: CON_PRINTBUFFER,
+ index: -1,
};
void __init rs285_console_init(void)
--- linux-2.4.0-test10-pre1/drivers/char/serial_amba.c Wed Sep 20 13:19:42 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/serial_amba.c Thu Oct 12 15:27:49
+2000
@@ -2016,7 +2016,6 @@
#endif
device: ambauart_conso
[patch] 2.2.18 serial console sysrq backport
Hi *,
i just backported the 2.4.x serial.c changes to enable MAGIC_SYSRQ via
serial console
on 2.2.18. Patch is working ok so far, i have included it here, maybe it
is useful for
someone. You need to enable CONFIG_SERIAL_CONSOLE && CONFIG_MAGIC_SYSRQ
to use it.
To trigger MAGIC_SYSRQ send a "break" to the serial console. e.g.
ALT-a f in minicom. (To trigger the help function try alt-a f h)
Cheers,
-Michael
--
Sik an regeln ortografi unt gramatik su halten erhohen
ferstandlikkeit von gesribene tekste erheblik.
--- linux/drivers/char/serial.c.origFri Feb 2 10:13:25 2001
+++ linux/drivers/char/serial.c Fri Feb 2 10:35:39 2001
@@ -143,6 +143,10 @@
#include
#endif
+#ifdef CONFIG_MAGIC_SYSRQ
+#include
+#endif
+
#include
#include
#include
@@ -178,6 +182,9 @@
#ifdef CONFIG_SERIAL_CONSOLE
static struct console sercons;
#endif
+#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+static unsigned long break_pressed; /* break, really ... */
+#endif
static unsigned detect_uart_irq (struct serial_state * state);
static void autoconfig(struct serial_state * info);
@@ -376,7 +383,7 @@
}
static _INLINE_ void receive_chars(struct async_struct *info,
-int *status)
+int *status, struct pt_regs * regs)
{
struct tty_struct *tty = info->tty;
unsigned char ch;
@@ -403,6 +410,21 @@
if (*status & UART_LSR_BI) {
*status &= ~(UART_LSR_FE | UART_LSR_PE);
icount->brk++;
+/*
+ * We do the SysRQ and SAK checking
+ * here because otherwise the break
+ * may get masked by ignore_status_mask
+ * or read_status_mask.
+ */
+#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+if (info->line == sercons.index) {
+if (!break_pressed) {
+break_pressed = jiffies;
+goto ignore_char;
+}
+break_pressed = 0;
+}
+#endif
} else if (*status & UART_LSR_PE)
icount->parity++;
else if (*status & UART_LSR_FE)
@@ -447,6 +469,17 @@
}
}
}
+#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+if (break_pressed && info->line == sercons.index) {
+if (ch != 0 &&
+time_before(jiffies, break_pressed + HZ*5)) {
+handle_sysrq(ch, regs, NULL, NULL);
+break_pressed = 0;
+goto ignore_char;
+}
+break_pressed = 0;
+}
+#endif
tty->flip.flag_buf_ptr++;
tty->flip.char_buf_ptr++;
tty->flip.count++;
@@ -612,7 +645,7 @@
printk("status = %x...", status);
#endif
if (status & UART_LSR_DR)
- receive_chars(info, &status);
+ receive_chars(info, &status, regs);
check_modem_status(info);
if (status & UART_LSR_THRE)
transmit_chars(info, 0);
@@ -676,7 +709,7 @@
printk("status = %x...", status);
#endif
if (status & UART_LSR_DR)
- receive_chars(info, &status);
+ receive_chars(info, &status, regs);
check_modem_status(info);
if (status & UART_LSR_THRE)
transmit_chars(info, 0);
@@ -739,7 +772,7 @@
printk("status = %x...", status);
#endif
if (status & UART_LSR_DR)
- receive_chars(info, &status);
+ receive_chars(info, &status, regs);
check_modem_status(info);
if (status & UART_LSR_THRE)
transmit_chars(info, 0);
2.4.5-ac9 console NULL pointer pointer dereference
Hi, this happend with 2.4.5-ac9 with serial console on i386. Full boot log and config can be found here: http://www.penguinppc.org/~olaf/bugs/245-ac9/ ksymoops 2.4.1 on i686 2.4.6-pre1. Options used -v /usr/src/OLAF/linux-2.4.5-ac9/vmlinux (specified) -K (specified) -L (specified) -O (specified) -m /usr/src/OLAF/linux-2.4.5-ac9/System.map (specified) WARNING: unexpectC, please mail cpu: 0, clocks: 1001790, slice: 500895 ttyS1 at Unable to handle kernel NULL pointer dereference0x02f8 (irq = 3) at virtual address 0004 Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: ebx: c1231fa4 ecx: 0202 edx: esi: c1231fa4 edi: c1230332 ebp: c123 esp: c1231f8c ds: 0018 es: 0018 ss: 0018 Process keventd (pid: 2, stackpage=c1231000) Stack: c0195a67 c1231fa4 c0119a5c c1230650 c1231fe0 c025a5c4 c025a5c4 c0120f97 c0252d20 0700 c123ffc4 0008e000 c1230650 c1230640 0001 0001 c123 c0252d2c Call Trace: [] [] [] [] Code: 80 78 04 01 74 39 83 3d 00 43 2d c0 00 74 11 a1 88 52 2c c0 >>EIP; c01967c7<= Trace; c0195a67 Trace; c0119a5c <__run_task_queue+60/74> Trace; c0120f97 Trace; c01056cc Code; c01967c7 <_EIP>: Code; c01967c7<= 0: 80 78 04 01 cmpb $0x1,0x4(%eax) <= Code; c01967cb 4: 74 39 je 3f <_EIP+0x3f> c0196806 Code; c01967cd 6: 83 3d 00 43 2d c0 00 cmpl $0x0,0xc02d4300 Code; c01967d4 d: 74 11 je 20 <_EIP+0x20> c01967e7 Code; c01967d6 f: a1 88 52 2c c0mov0xc02c5288,%eax Gruss Olaf -- $ man clone BUGS Main feature not yet implemented... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
Andrew, your patch looks too complex, and doesnt cover the case of the serial driver deadlocking. Why not add a "touch_nmi_watchdog_counter()" function that just changes last_irq_sums instead of adding locking? This way deadlocks will be caught in the serial code too. (because touch_nmi() will only "postpone" the NMI watchdog lockup event, not disable it.) This should be a matter of 5 lines ... Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
On Sun, 11 Mar 2001, Keith Owens wrote: > kdb has to completely disable the nmi counter while it is in control. > All interrupts are disabled, all but one cpus are spinning, the > control cpu does busy wait while it polls the input devices. With > that model there is no alternative to a complete disable. it sure has an alternative. The 'cpus spinning' code calls touch_nmi() within the busy loop, the polling code on the control CPU too. This is sure more robust and catches lockup bugs in kdb too ... Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
On Sun, 11 Mar 2001 08:44:24 +0100 (CET), Ingo Molnar <[EMAIL PROTECTED]> wrote: >Andrew, > >your patch looks too complex, and doesnt cover the case of the serial >driver deadlocking. Why not add a "touch_nmi_watchdog_counter()" function >that just changes last_irq_sums instead of adding locking? This way >deadlocks will be caught in the serial code too. (because touch_nmi() will >only "postpone" the NMI watchdog lockup event, not disable it.) kdb has to completely disable the nmi counter while it is in control. All interrupts are disabled, all but one cpus are spinning, the control cpu does busy wait while it polls the input devices. With that model there is no alternative to a complete disable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
On Sun, 11 Mar 2001 08:53:40 +0100 (CET), Ingo Molnar <[EMAIL PROTECTED]> wrote: >it sure has an alternative. The 'cpus spinning' code calls touch_nmi() >within the busy loop, the polling code on the control CPU too. This is >sure more robust and catches lockup bugs in kdb too ... Works for me. It even makes kdb simpler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
Keith Owens wrote: > > On Sun, 11 Mar 2001 08:53:40 +0100 (CET), > Ingo Molnar <[EMAIL PROTECTED]> wrote: > >it sure has an alternative. The 'cpus spinning' code calls touch_nmi() > >within the busy loop, the polling code on the control CPU too. This is > >sure more robust and catches lockup bugs in kdb too ... > > Works for me. It even makes kdb simpler. humm... OK, this seems doable in the case of serial console. For CONFIG_LP_CONSOLE (which has the same problem) it looks like we can just call touch_nmi() in lp_console_write(). I'll see what Tim has to say. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
Keith Owens wrote: > > On Sun, 11 Mar 2001 08:44:24 +0100 (CET), > Ingo Molnar <[EMAIL PROTECTED]> wrote: > >Andrew, > > > >your patch looks too complex, and doesnt cover the case of the serial > >driver deadlocking. Why not add a "touch_nmi_watchdog_counter()" function > >that just changes last_irq_sums instead of adding locking? This way > >deadlocks will be caught in the serial code too. (because touch_nmi() will > >only "postpone" the NMI watchdog lockup event, not disable it.) > > kdb has to completely disable the nmi counter while it is in control. > All interrupts are disabled, all but one cpus are spinning, the control > cpu does busy wait while it polls the input devices. With that model > there is no alternative to a complete disable. > Consider this. Why not use the NMI to sync the cpus. Kdb would have a function that is called each NMI. If it is doing nothing, just return false, else, if waiting for this cpu, well here it is, put it in spin AFTER saving where it came from so the operator can figure out what it is doing. In kgdb I just put the interrupt registers in the task_struct where they are put when a context switch is done. Then the debugger can do a trace, etc. on that task. A global var that the debugger can see is also set to the cpus, "current". If the cpu is already spinning, return to the nmi code with a true flag which will cause it to ignore the nmi. Same thing if it is the cpu that is doing debug i/o. I went to this for kgdb after the system failed to return from the call to force the other cpus to execute a function (which means they have to be alive). For extra safety I also time the sync. If one or more expected cpus, don't show while looping reading the cycle counter, the code just continues with out the sync. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
On Sun, 11 Mar 2001 20:43:16 -0800, george anzinger <[EMAIL PROTECTED]> wrote: >Consider this. Why not use the NMI to sync the cpus. Kdb would have a >function that is called each NMI. kdb uses NMI IPI to get the other cpu's attention. One cpu is in control and may or may not be accepting NMI, it depends on the event that entered kdb. The other cpus end up in kdb code, spinning waiting for a cpu switch. Initially they are not receiving NMI because they were invoked via NMI which is masked until they exit. However if the user does a cpu switch then single steps the interrupted code, the cpu has to return from the NMI handler to the interrupted code at which time this cpu starts receiving NMI again. The kdb context can change from ignoring NMI to accepting NMI. It is easier to bring all the cpus into kdb and let the kdb code decide if it ignores any NMI that is being received. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
Keith Owens wrote: > > On Sun, 11 Mar 2001 20:43:16 -0800, > george anzinger <[EMAIL PROTECTED]> wrote: > >Consider this. Why not use the NMI to sync the cpus. Kdb would have a > >function that is called each NMI. > > kdb uses NMI IPI to get the other cpu's attention. One cpu is in > control and may or may not be accepting NMI, it depends on the event > that entered kdb. The other cpus end up in kdb code, spinning waiting > for a cpu switch. Initially they are not receiving NMI because they > were invoked via NMI which is masked until they exit. However if the > user does a cpu switch then single steps the interrupted code, the cpu > has to return from the NMI handler to the interrupted code at which > time this cpu starts receiving NMI again. Are you actually twiddling the hardware, or just changing what happens on NMI? > > The kdb context can change from ignoring NMI to accepting NMI. It is > easier to bring all the cpus into kdb and let the kdb code decide if it > ignores any NMI that is being received. Yes. Exactly. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
On Mon, 12 Mar 2001 00:27:14 -0800, george anzinger <[EMAIL PROTECTED]> wrote: >Keith Owens wrote: >> kdb uses NMI IPI to get the other cpu's attention. One cpu is in >> control and may or may not be accepting NMI, it depends on the event >> that entered kdb. The other cpus end up in kdb code, spinning waiting >> for a cpu switch. Initially they are not receiving NMI because they >> were invoked via NMI which is masked until they exit. > >Are you actually twiddling the hardware, or just changing what happens >on NMI? No hardware twiddling. One cpu gets an event which triggers kdb, that event may or may not be via NMI. kdb on ix86 then uses NMI to get the attention of the other cpus, even if they are in a disabled spinloop. ix86 hardware will not deliver another NMI to a cpu until the cpu issues iret to return from the NMI handler. Initially all but one cpu is forced into kdb via the NMI handler so no more NMI events will occur on those cpus. The first cpu may or may not be receiving NMI, it depends on how kdb was invoked on the first cpu. To do single stepping of code, kdb allows one cpu out of kdb state so it can execute one instruction at the point it was interrupted. If the cpu was entered via NMI then that means exiting from the NMI handler back to the original code, do single step then back into kdb again. Having exited the NMI handler, that cpu will start receiving NMI events again, even though it is still under kdb control. So some cpus will get NMI, some will not, depending on user actions. kdb uses a software mechanism to selectively disable the NMI watchdog. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [sligthly OT] serial console on palm
John Lenton writes: > I remember seing a project to get a palm pilot working as a > serial console, but now google seems unable to find it. Does > anyone know of such a project? I got one recently called "serialrecord" for the Palm, but it is one-way only (useful for capturing OOPSes or so. If someone had a two-way console for the Palm, it would be great. Sorry, no URL, but you _should_ be able to find it in l-k archives. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [sligthly OT] serial console on palm
there is a vt100 terminal emulater available for the palm (I had it, but haven't used it in a while, I may have lost it due to not backing things up properly) David Lang On Sun, 18 Mar 2001, Andreas Dilger wrote: > Date: Sun, 18 Mar 2001 22:10:20 -0700 (MST) > From: Andreas Dilger <[EMAIL PROTECTED]> > To: John R Lenton <[EMAIL PROTECTED]> > Cc: Linux Kernel Mailing List <[EMAIL PROTECTED]> > Subject: Re: [sligthly OT] serial console on palm > > John Lenton writes: > > I remember seing a project to get a palm pilot working as a > > serial console, but now google seems unable to find it. Does > > anyone know of such a project? > > I got one recently called "serialrecord" for the Palm, but it is one-way > only (useful for capturing OOPSes or so. If someone had a two-way console > for the Palm, it would be great. Sorry, no URL, but you _should_ be able > to find it in l-k archives. > > Cheers, Andreas > -- > Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, > \ would they cancel out, leaving him still hungry?" > http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [sligthly OT] serial console on palm
I use my Palm VX as a serial console on Linux, OpenBSD, FreeBSD, and Solaris. Just get a serial cable for your unit and some console program such as pTelnet. The rest is quite simple. If you find something different than pTelnet for console, please let me know as I find it crashes too much. pete On Sun, 18 Mar 2001, Andreas Dilger wrote: > John Lenton writes: > > I remember seing a project to get a palm pilot working as a > > serial console, but now google seems unable to find it. Does > > anyone know of such a project? > > I got one recently called "serialrecord" for the Palm, but it is one-way > only (useful for capturing OOPSes or so. If someone had a two-way console > for the Palm, it would be great. Sorry, no URL, but you _should_ be able > to find it in l-k archives. PGP signature
Re: [sligthly OT] serial console on palm
Andreas Dilger wrote: > > John Lenton writes: > > I remember seing a project to get a palm pilot working as a > > serial console, but now google seems unable to find it. Does > > anyone know of such a project? > > I got one recently called "serialrecord" for the Palm, but it is one-way > only (useful for capturing OOPSes or so. If someone had a two-way console > for the Palm, it would be great. Sorry, no URL, but you _should_ be able > to find it in l-k archives. > > Cheers, Andreas > -- > Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, > \ would they cancel out, leaving him still hungry?" > http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ This one has proved handy in the past. I've used it to log into routers and the like, it's pretty cool. The actual website (not palmgear) is incredibly slow tho. http://www.palmgear.com/software/showsoftware.cfm?prodID=552 Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [sligthly OT] serial console on palm
It was posted by Christian Ehrhardt. [EMAIL PROTECTED] wrote: > > On Mon, Feb 12, 2001 at 05:32:39PM +0100, I wrote: > > I wrote a little palm app some time ago that can capture serial > > console output. If anyone is interested I'll build a tar ball with > > sources and binary. > > It is now availiable at http://www.mathematik.uni-ulm.de/~ehrhardt/serial/ > > Sorry for the slightly off topic post but I think enough people > showed interest to justify this. > > regardsChristian Ehrhardt I made a couple of changes to it. Mainly: Made a Makefile increased the speed to 19200 added a scrollbar a filter to get rid of some ansi characters. If someone could add the code to use higher speeds and being able to recall previous logs would make it more usefull. The changed version can be obtained in: http://www.neuronet.pitt.edu/~raffo/SerialRecord/ Bugs: If your machine crashes while booting it will loose the tail of the output, maybe because is not fast enough. -- Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.3 and SysRq over serial console
Hello all. Without the attached patch, SysRq doesn't work over a serial
console here. Has anyone else seen this problem?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
diff -Nru a/linux/drivers/char/n_tty.c b/linux/drivers/char/n_tty.c
--- a/linux/drivers/char/n_tty.cSat Mar 31 16:30:44 2001
+++ b/linux/drivers/char/n_tty.cSat Mar 31 16:30:44 2001
@@ -40,6 +40,10 @@
#include
#include
#include
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+#include
+#include
+#endif
#include
#include
@@ -458,6 +462,12 @@
static inline void n_tty_receive_break(struct tty_struct *tty)
{
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+ struct console *c = console_drivers;
+ if (c && c->device && (c->device(c) == tty->device)
+ && !test_and_change_bit(TTY_DOING_SYSRQ, &tty->flags))
+ return;
+#endif
if (I_IGNBRK(tty))
return;
if (I_BRKINT(tty)) {
@@ -506,6 +516,12 @@
{
unsigned long flags;
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+ if (test_and_clear_bit(TTY_DOING_SYSRQ, &tty->flags)) {
+ handle_sysrq(c, NULL, NULL, tty);
+ return;
+ }
+#endif
if (tty->raw) {
put_tty_queue(c, tty);
return;
diff -Nru a/linux/include/linux/tty.h b/linux/include/linux/tty.h
--- a/linux/include/linux/tty.h Sat Mar 31 16:30:44 2001
+++ b/linux/include/linux/tty.h Sat Mar 31 16:30:44 2001
@@ -329,6 +329,9 @@
#define TTY_PUSH 6
#define TTY_CLOSING 7
#define TTY_DONT_FLIP 8
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+#define TTY_DOING_SYSRQ 9
+#endif
#define TTY_HW_COOK_OUT 14
#define TTY_HW_COOK_IN 15
#define TTY_PTY_LOCK 16
Re: APM, virtual console problem in 2.4.0
Joseph Pingenot <[EMAIL PROTECTED]> writes: > When suspending my laptop (Toshiba Satellite 1605CDS; BIOS set to > suspend to disk) with Debian 2.2r2's 'apm -s', the screen blanks and > then the system locks up hard (not even the power button works). In Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He loves feedback. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
On Sat, 10 Mar 2001 01:21:25 +1100, Andrew Morton <[EMAIL PROTECTED]> wrote: > +/** > + * enable_nmi_watchdog - enables/disables NMI watchdog checking. > + * @yes: If zero, disable Ugh. I have a feeling that your chances to get Linus to accept this are extremely slim. Just have two functions, enable_nmi_watchdog and disable_nmi_watchdog. You can make them inline, or even macros... Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
On Sat, Mar 10, 2001 at 01:21:25AM +1100, Andrew Morton wrote:
> +static atomic_t nmi_watchdog_enabled = ATOMIC_INIT(0); /* 0 == enabled */
> +
> +void enable_nmi_watchdog(int yes)
> +{
> + if (yes)
> + atomic_inc(&nmi_watchdog_enabled);
> + else
> + atomic_dec(&nmi_watchdog_enabled);
> +}
>
> void nmi_watchdog_tick (struct pt_regs * regs)
> {
> @@ -255,7 +264,7 @@
>
> sum = apic_timer_irqs[cpu];
>
> - if (last_irq_sums[cpu] == sum) {
> + if (last_irq_sums[cpu] == sum && atomic_read(&nmi_watchdog_enabled) == 0) {
Shouldn't that be atomic_read(&nmi_watchdog_enabled) != 0?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
