Re: A question about break and sysrq on a serial console (2.6.19.1)
On Thu, 2007-01-18 at 16:47 +, Russell King wrote: > On Thu, Jan 18, 2007 at 08:19:47AM -0800, Brian Beattie wrote: > > On Thu, 2007-01-18 at 09:13 +, Russell King wrote: > > > On Wed, Jan 17, 2007 at 03:56:54PM -0800, Brian Beattie wrote: > > > > I'm trying to do a SYSRQ over a serial console. As I understand it a > > > > break will do that, but I'm not seeing the SYSRQ. In looking at > > > > uart_handle_break() in drivers/serial/8250.c it looks like the code will > > > > toggle port->sysrq, rather than just setting it when the port is a > > > > console. I think the correct code would be to move the "port->sysrq = > > > > 0;" to follow the closing brace on the next line, or am I missing > > > > something. > > > > > > Thereby preventing the action of (which may be to cause a SAK > > > event, which would be rather important on a console to ensure that > > > you're really logging in rather than typing your password into another > > > users program which just looks like a login program.) > > > > > > Note that the sequence for sysrq is: > > > > > > (non-break characters or nothing) > > > > > well the code as is, is not working. Printk's tell me that > > uart_handle_break() is called repeatedly while the break condition is > > active, toggling port->sysrq so that it's a 50/50 chance on whether > > port->sysrq will be set or cleared when the break condition ends. On > > the other hand the 8250 break condition handling code is not working > > anyway, so the problem may be that the 8250 code is not calling > > uart_handle_break() correctly. > > Please learn to use the "reply to all" button when using mailing lists. I don't post much to LKML, I realized after I hit send I needed to reply all. > > Works fine here. Which UART are you actually using? At a guess, it's > probably a bad clone which does not have a correct break implementation. it's the built-in mpc8349 powerpc uart. > -- Brian Beattie Firmware Engineer APCON, Inc. [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: A question about break and sysrq on a serial console (2.6.19.1)
On Thu, 2007-01-18 at 16:47 +, Russell King wrote: On Thu, Jan 18, 2007 at 08:19:47AM -0800, Brian Beattie wrote: On Thu, 2007-01-18 at 09:13 +, Russell King wrote: On Wed, Jan 17, 2007 at 03:56:54PM -0800, Brian Beattie wrote: I'm trying to do a SYSRQ over a serial console. As I understand it a break will do that, but I'm not seeing the SYSRQ. In looking at uart_handle_break() in drivers/serial/8250.c it looks like the code will toggle port-sysrq, rather than just setting it when the port is a console. I think the correct code would be to move the port-sysrq = 0; to follow the closing brace on the next line, or am I missing something. Thereby preventing the action of break (which may be to cause a SAK event, which would be rather important on a console to ensure that you're really logging in rather than typing your password into another users program which just looks like a login program.) Note that the sequence for sysrq is: (non-break characters or nothing) break sysrq-char well the code as is, is not working. Printk's tell me that uart_handle_break() is called repeatedly while the break condition is active, toggling port-sysrq so that it's a 50/50 chance on whether port-sysrq will be set or cleared when the break condition ends. On the other hand the 8250 break condition handling code is not working anyway, so the problem may be that the 8250 code is not calling uart_handle_break() correctly. Please learn to use the reply to all button when using mailing lists. I don't post much to LKML, I realized after I hit send I needed to reply all. Works fine here. Which UART are you actually using? At a guess, it's probably a bad clone which does not have a correct break implementation. it's the built-in mpc8349 powerpc uart. -- Brian Beattie Firmware Engineer APCON, Inc. [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/
A question about break and sysrq on a serial console (2.6.19.1)
I'm trying to do a SYSRQ over a serial console. As I understand it a
break will do that, but I'm not seeing the SYSRQ. In looking at
uart_handle_break() in drivers/serial/8250.c it looks like the code will
toggle port->sysrq, rather than just setting it when the port is a
console. I think the correct code would be to move the "port->sysrq =
0;" to follow the closing brace on the next line, or am I missing
something.
--
/*
* We do the SysRQ and SAK checking like this...
*/
static inline int uart_handle_break(struct uart_port *port)
{
struct uart_info *info = port->info;
#ifdef SUPPORT_SYSRQ
if (port->cons && port->cons->index == port->line) {
if (!port->sysrq) {
port->sysrq = jiffies + HZ*5;
return 1;
}
port->sysrq = 0;
}
#endif
if (port->flags & UPF_SAK)
do_SAK(info->tty);
return 0;
}
-
It seem to me that this code will toggle port->sysrq.
--
Brian Beattie
Firmware Engineer
APCON, Inc.
[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/
A question about break and sysrq on a serial console (2.6.19.1)
I'm trying to do a SYSRQ over a serial console. As I understand it a
break will do that, but I'm not seeing the SYSRQ. In looking at
uart_handle_break() in drivers/serial/8250.c it looks like the code will
toggle port-sysrq, rather than just setting it when the port is a
console. I think the correct code would be to move the port-sysrq =
0; to follow the closing brace on the next line, or am I missing
something.
--
/*
* We do the SysRQ and SAK checking like this...
*/
static inline int uart_handle_break(struct uart_port *port)
{
struct uart_info *info = port-info;
#ifdef SUPPORT_SYSRQ
if (port-cons port-cons-index == port-line) {
if (!port-sysrq) {
port-sysrq = jiffies + HZ*5;
return 1;
}
port-sysrq = 0;
}
#endif
if (port-flags UPF_SAK)
do_SAK(info-tty);
return 0;
}
-
It seem to me that this code will toggle port-sysrq.
--
Brian Beattie
Firmware Engineer
APCON, Inc.
[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: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote: > > The recommendet _serving_ temperature for coffe is 55 °C or below. > > Nonsense! 55C (100F) is ludicrously low for coffee. > > 70C (125F) is the *minimum* recommended serving temperature. 165-190F is the > preferred serving range. I can cite source after source for this. For > example: > http://www.bunn.com/pages/coffeebasics/cb6holding.html > http://www.millcreekcoffee.com/holding.htm Do you actually read your citations? Your cited sources both give the SERVING temp as 155 - 175 F. -- Brian Beattie Firmware Engineer APCON, Inc. [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: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote: The recommendet _serving_ temperature for coffe is 55 °C or below. Nonsense! 55C (100F) is ludicrously low for coffee. 70C (125F) is the *minimum* recommended serving temperature. 165-190F is the preferred serving range. I can cite source after source for this. For example: http://www.bunn.com/pages/coffeebasics/cb6holding.html http://www.millcreekcoffee.com/holding.htm Do you actually read your citations? Your cited sources both give the SERVING temp as 155 - 175 F. -- Brian Beattie Firmware Engineer APCON, Inc. [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: Help - really messed up kernel
On Sun, 2005-02-20 at 15:22 -0800, Joshua Hudson wrote: > I am trying to install linux on a laptop that cannot boot from cdrom. I handled this by putting smart-boot http://btmgr.webframe.org/ in the hard drive MBR from a dos floppy, smart-boot can boot from a cdrom. Then as long as you don't wipe out your MBR you can still boot from a cdrom. -- Brian Beattie LFS12947 | "Honor isn't about making the right choices. [EMAIL PROTECTED] | It's about dealing with the consequences." www.beattie-home.net | -- Midori Koto - 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: Help - really messed up kernel
On Sun, 2005-02-20 at 15:22 -0800, Joshua Hudson wrote: I am trying to install linux on a laptop that cannot boot from cdrom. I handled this by putting smart-boot http://btmgr.webframe.org/ in the hard drive MBR from a dos floppy, smart-boot can boot from a cdrom. Then as long as you don't wipe out your MBR you can still boot from a cdrom. -- Brian Beattie LFS12947 | Honor isn't about making the right choices. [EMAIL PROTECTED] | It's about dealing with the consequences. www.beattie-home.net | -- Midori Koto - 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: Bug in the file attributes ?
On Thu, 29 Mar 2001, Andreas Dilger wrote: > Xavier Ordoquy writes: > > I just made a manipulation that disturbs me. So I'm asking whether it's a > > bug or a features. > > > > user> su > > root> echo "test" > test > > root> ls -l > > -rw-r--r-- 1 root root5 Mar 29 19:14 test > > root> exit > > user> rm test > > rm: remove write-protected file `test'? y > > user> ls test > > ls: test: No such file or directory > > > > This is in the user home directory. > > Since the file is read only for the user, it should not be able to remove > > it. Moreover, the user can't write to test. > > This is definitely not a bug. Deleting a file (under *nix) does not > "modify" the file at all, it is modifying the directory where the file > resides. To be correct and pedantic, in a traditional Unix type filesystem, one does not remove a file...one dereferences it, i.e. "unlink", as part of this process garbage collection is performed which checks the reference count. If the inode's reference count is zero, the inode and data blocks are returned to their respective free lists. All the rm command does, is to remove the directory entry and decrement the reference count :). This is why Unix has a rm (remove link) as opposed to a del (delete file) command. Brian...just being pedantic :-^ Brian Beattie [EMAIL PROTECTED] 503.578.5899 Des2-3C-5 - 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: Bug in the file attributes ?
On Thu, 29 Mar 2001, Andreas Dilger wrote: Xavier Ordoquy writes: I just made a manipulation that disturbs me. So I'm asking whether it's a bug or a features. user su root echo "test" test root ls -l -rw-r--r-- 1 root root5 Mar 29 19:14 test root exit user rm test rm: remove write-protected file `test'? y user ls test ls: test: No such file or directory This is in the user home directory. Since the file is read only for the user, it should not be able to remove it. Moreover, the user can't write to test. This is definitely not a bug. Deleting a file (under *nix) does not "modify" the file at all, it is modifying the directory where the file resides. To be correct and pedantic, in a traditional Unix type filesystem, one does not remove a file...one dereferences it, i.e. "unlink", as part of this process garbage collection is performed which checks the reference count. If the inode's reference count is zero, the inode and data blocks are returned to their respective free lists. All the rm command does, is to remove the directory entry and decrement the reference count :). This is why Unix has a rm (remove link) as opposed to a del (delete file) command. Brian...just being pedantic :-^ Brian Beattie [EMAIL PROTECTED] 503.578.5899 Des2-3C-5 - 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/
