Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 10/3/2014 2:34 PM, Stephen Boyd wrote: > Hi Frank, > > On 08/13/14 19:42, Frank Rowand wrote: >> On 8/13/2014 7:33 PM, Frank Rowand wrote: >>> On 8/12/2014 5:23 PM, Stephen Boyd wrote: On 08/06/14 17:16, Frank Rowand wrote: >> < snip > >> >>> The patches you sent are a little hard to read since they modify further >>> code >>> that my patch modified. So I have redone your patches, as if my patch was >>> not previously applied. Hopefully I did not make any mistakes there. I >>> will >>> reply to this email with each of your redone patches. >> Stephen's patch alternative number 2: > > I had a discussion with the hardware engineer. Apparently the break bit > in the SR register is not "sticky" so it doesn't always stay set when > the handle_rx_dm() function runs and a break has entered the fifo. I > used your debug patches to confirm this (I never see the break status > bit when the fifo has multiple characters in it). It sounds like this > bit can't really be used reliably. The recommendation is to use either > the break start or break stop interrupt to detect when a break has > occurred and then search the fifo for the break character (an all zero > character). If there are two such characters then we can't be certain > when the break was, but the chances of this seem really slim considering > that the stale timeout probably triggers first before a human can type a > character after the break. That sounds good to me. > On 1.4 hardware we can change the mode to be single character and then > we can reliably detect the break character because only one character > enters the fifo and the higher bits of the fifo can be used to detect if > it is a break or not. Making that change is probably not that hard, I > believe we can reuse all the handle_rx_dm logic and force single > character mode on consoles, but 1.3 hardware doesn't benefit from this > change. I'll try to get something together soon that tries to make this > all work as best as it can. Thanks! I'll be glad to review and test. And whatever else I can do to help. -Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
Hi Frank, On 08/13/14 19:42, Frank Rowand wrote: > On 8/13/2014 7:33 PM, Frank Rowand wrote: >> On 8/12/2014 5:23 PM, Stephen Boyd wrote: >>> On 08/06/14 17:16, Frank Rowand wrote: > < snip > > >> The patches you sent are a little hard to read since they modify further code >> that my patch modified. So I have redone your patches, as if my patch was >> not previously applied. Hopefully I did not make any mistakes there. I will >> reply to this email with each of your redone patches. > Stephen's patch alternative number 2: I had a discussion with the hardware engineer. Apparently the break bit in the SR register is not "sticky" so it doesn't always stay set when the handle_rx_dm() function runs and a break has entered the fifo. I used your debug patches to confirm this (I never see the break status bit when the fifo has multiple characters in it). It sounds like this bit can't really be used reliably. The recommendation is to use either the break start or break stop interrupt to detect when a break has occurred and then search the fifo for the break character (an all zero character). If there are two such characters then we can't be certain when the break was, but the chances of this seem really slim considering that the stale timeout probably triggers first before a human can type a character after the break. On 1.4 hardware we can change the mode to be single character and then we can reliably detect the break character because only one character enters the fifo and the higher bits of the fifo can be used to detect if it is a break or not. Making that change is probably not that hard, I believe we can reuse all the handle_rx_dm logic and force single character mode on consoles, but 1.3 hardware doesn't benefit from this change. I'll try to get something together soon that tries to make this all work as best as it can. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
Hi Frank, On 08/13/14 19:42, Frank Rowand wrote: On 8/13/2014 7:33 PM, Frank Rowand wrote: On 8/12/2014 5:23 PM, Stephen Boyd wrote: On 08/06/14 17:16, Frank Rowand wrote: snip The patches you sent are a little hard to read since they modify further code that my patch modified. So I have redone your patches, as if my patch was not previously applied. Hopefully I did not make any mistakes there. I will reply to this email with each of your redone patches. Stephen's patch alternative number 2: I had a discussion with the hardware engineer. Apparently the break bit in the SR register is not sticky so it doesn't always stay set when the handle_rx_dm() function runs and a break has entered the fifo. I used your debug patches to confirm this (I never see the break status bit when the fifo has multiple characters in it). It sounds like this bit can't really be used reliably. The recommendation is to use either the break start or break stop interrupt to detect when a break has occurred and then search the fifo for the break character (an all zero character). If there are two such characters then we can't be certain when the break was, but the chances of this seem really slim considering that the stale timeout probably triggers first before a human can type a character after the break. On 1.4 hardware we can change the mode to be single character and then we can reliably detect the break character because only one character enters the fifo and the higher bits of the fifo can be used to detect if it is a break or not. Making that change is probably not that hard, I believe we can reuse all the handle_rx_dm logic and force single character mode on consoles, but 1.3 hardware doesn't benefit from this change. I'll try to get something together soon that tries to make this all work as best as it can. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 10/3/2014 2:34 PM, Stephen Boyd wrote: Hi Frank, On 08/13/14 19:42, Frank Rowand wrote: On 8/13/2014 7:33 PM, Frank Rowand wrote: On 8/12/2014 5:23 PM, Stephen Boyd wrote: On 08/06/14 17:16, Frank Rowand wrote: snip The patches you sent are a little hard to read since they modify further code that my patch modified. So I have redone your patches, as if my patch was not previously applied. Hopefully I did not make any mistakes there. I will reply to this email with each of your redone patches. Stephen's patch alternative number 2: I had a discussion with the hardware engineer. Apparently the break bit in the SR register is not sticky so it doesn't always stay set when the handle_rx_dm() function runs and a break has entered the fifo. I used your debug patches to confirm this (I never see the break status bit when the fifo has multiple characters in it). It sounds like this bit can't really be used reliably. The recommendation is to use either the break start or break stop interrupt to detect when a break has occurred and then search the fifo for the break character (an all zero character). If there are two such characters then we can't be certain when the break was, but the chances of this seem really slim considering that the stale timeout probably triggers first before a human can type a character after the break. That sounds good to me. On 1.4 hardware we can change the mode to be single character and then we can reliably detect the break character because only one character enters the fifo and the higher bits of the fifo can be used to detect if it is a break or not. Making that change is probably not that hard, I believe we can reuse all the handle_rx_dm logic and force single character mode on consoles, but 1.3 hardware doesn't benefit from this change. I'll try to get something together soon that tries to make this all work as best as it can. Thanks! I'll be glad to review and test. And whatever else I can do to help. -Frank -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 8/13/2014 7:33 PM, Frank Rowand wrote:
> On 8/12/2014 5:23 PM, Stephen Boyd wrote:
>> On 08/06/14 17:16, Frank Rowand wrote:
< snip >
> The patches you sent are a little hard to read since they modify further code
> that my patch modified. So I have redone your patches, as if my patch was
> not previously applied. Hopefully I did not make any mistakes there. I will
> reply to this email with each of your redone patches.
Stephen's patch alternative number 2:
---
drivers/tty/serial/msm_serial.c | 41 +++-
1 file changed, 28 insertions(+), 13 deletions(-)
Index: b/drivers/tty/serial/msm_serial.c
===
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -125,25 +125,40 @@ static void handle_rx_dm(struct uart_por
port->icount.rx += count;
while (count > 0) {
- unsigned int c;
+ unsigned char buf[4];
+ int sysrq, r_count, i;
sr = msm_read(port, UART_SR);
if ((sr & UART_SR_RX_READY) == 0) {
msm_port->old_snap_state -= count;
break;
}
- c = msm_read(port, UARTDM_RF);
- if (sr & UART_SR_RX_BREAK) {
- port->icount.brk++;
- if (uart_handle_break(port))
- continue;
- } else if (sr & UART_SR_PAR_FRAME_ERR)
- port->icount.frame++;
-
- /* TODO: handle sysrq */
- tty_insert_flip_string(tport, (char *),
- (count > 4) ? 4 : count);
- count -= 4;
+ readsl(port->membase + UARTDM_RF, buf, 1);
+
+ r_count = min_t(int, count, sizeof(buf));
+
+ for (i = 0; i < r_count; i++) {
+ char flag = TTY_NORMAL;
+
+ if (sr & UART_SR_RX_BREAK) {
+ if (buf[i] == 0) {
+ port->icount.brk++;
+ flag = TTY_BREAK;
+ if (uart_handle_break(port))
+ continue;
+ }
+ }
+
+ if (!(port->read_status_mask & UART_SR_RX_BREAK))
+ flag = TTY_NORMAL;
+
+ spin_unlock(>lock);
+ sysrq = uart_handle_sysrq_char(port, buf[i]);
+ spin_lock(>lock);
+ if (!sysrq)
+ tty_insert_flip_char(tport, buf[i], flag);
+ }
+ count -= r_count;
}
spin_unlock(>lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 8/13/2014 7:33 PM, Frank Rowand wrote:
> On 8/12/2014 5:23 PM, Stephen Boyd wrote:
>> On 08/06/14 17:16, Frank Rowand wrote:
< snip >
> The patches you sent are a little hard to read since they modify further code
> that my patch modified. So I have redone your patches, as if my patch was
> not previously applied. Hopefully I did not make any mistakes there. I will
> reply to this email with each of your redone patches.
< snip >
Stephen's patch alternative number 1:
---
drivers/tty/serial/msm_serial.c | 44
drivers/tty/serial/msm_serial.h |8 +++
2 files changed, 39 insertions(+), 13 deletions(-)
Index: b/drivers/tty/serial/msm_serial.c
===
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -125,25 +125,28 @@ static void handle_rx_dm(struct uart_por
port->icount.rx += count;
while (count > 0) {
- unsigned int c;
+ unsigned char buf[4];
+ unsigned char *p = buf;
+ int sysrq, r_count;
sr = msm_read(port, UART_SR);
if ((sr & UART_SR_RX_READY) == 0) {
msm_port->old_snap_state -= count;
break;
}
- c = msm_read(port, UARTDM_RF);
- if (sr & UART_SR_RX_BREAK) {
- port->icount.brk++;
- if (uart_handle_break(port))
- continue;
- } else if (sr & UART_SR_PAR_FRAME_ERR)
- port->icount.frame++;
+ readsl(port->membase + UARTDM_RF, p, 1);
- /* TODO: handle sysrq */
- tty_insert_flip_string(tport, (char *),
- (count > 4) ? 4 : count);
- count -= 4;
+ spin_unlock(>lock);
+ sysrq = uart_handle_sysrq_char(port, buf[0]);
+ spin_lock(>lock);
+ if (sysrq) {
+ p++;
+ count--;
+ }
+ r_count = min_t(int, count, sizeof(buf) - sysrq);
+ if (r_count)
+ tty_insert_flip_string(tport, p, r_count);
+ count -= r_count;
}
spin_unlock(>lock);
@@ -285,6 +288,17 @@ static irqreturn_t msm_irq(int irq, void
misr = msm_read(port, UART_MISR);
msm_write(port, 0, UART_IMR); /* disable interrupt */
+ if (misr & UART_IMR_RXBREAK_END) {
+ uart_handle_break(port);
+ port->icount.brk++;
+ msm_write(port, UART_CR_CMD_RESET_RXBREAK_END, UART_CR);
+ }
+
+ if (misr & UART_IMR_PAR_FRAME_ERR) {
+ port->icount.frame++;
+ msm_write(port, UART_CR_CMD_RESET_PAR_FRAME_ERR, UART_CR);
+ }
+
if (misr & (UART_IMR_RXLEV | UART_IMR_RXSTALE)) {
if (msm_port->is_uartdm)
handle_rx_dm(port, misr);
@@ -491,7 +505,8 @@ static int msm_startup(struct uart_port
/* turn on RX and CTS interrupts */
msm_port->imr = UART_IMR_RXLEV | UART_IMR_RXSTALE |
- UART_IMR_CURRENT_CTS;
+ UART_IMR_CURRENT_CTS | UART_IMR_RXBREAK_END |
+ UART_IMR_PAR_FRAME_ERR;
if (msm_port->is_uartdm) {
msm_write(port, 0xFF, UARTDM_DMRX);
@@ -566,6 +581,9 @@ static void msm_set_termios(struct uart_
else
mr |= UART_MR2_STOP_BIT_LEN_ONE;
+ mr |= UART_MR2_RX_BREAK_ZERO_CHAR_OFF;
+ mr |= UART_MR2_RX_ERROR_CHAR_OFF;
+
/* set parity, bits per char, and stop bit */
msm_write(port, mr, UART_MR2);
Index: b/drivers/tty/serial/msm_serial.h
===
--- a/drivers/tty/serial/msm_serial.h
+++ b/drivers/tty/serial/msm_serial.h
@@ -24,6 +24,8 @@
#define UART_MR1_CTS_CTL (1 << 6)
#define UART_MR2 0x0004
+#define UART_MR2_RX_ERROR_CHAR_OFF (1 << 9)
+#define UART_MR2_RX_BREAK_ZERO_CHAR_OFF(1 << 8)
#define UART_MR2_ERROR_MODE(1 << 6)
#define UART_MR2_BITS_PER_CHAR 0x30
#define UART_MR2_BITS_PER_CHAR_5 (0x0 << 4)
@@ -65,6 +67,9 @@
#define UART_CR_TX_ENABLE (1 << 2)
#define UART_CR_RX_DISABLE (1 << 1)
#define UART_CR_RX_ENABLE (1 << 0)
+#define UART_CR_CMD_RESET_RXBREAK_START((1 << 11) | (2 << 4))
+#define UART_CR_CMD_RESET_RXBREAK_END ((1 << 11) | (3 << 4))
+#define UART_CR_CMD_RESET_PAR_FRAME_ERR((1 << 11) | (4 << 4))
#define UART_IMR 0x0014
#define UART_IMR_TXLEV (1 << 0)
@@ -72,6 +77,9 @@
#define UART_IMR_RXLEV (1 << 4)
#define UART_IMR_DELTA_CTS (1 << 5)
#define UART_IMR_CURRENT_CTS (1 << 6)
+#define
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 8/12/2014 5:23 PM, Stephen Boyd wrote:
> On 08/06/14 17:16, Frank Rowand wrote:
>> Stephen,
>>
>> Can you test this patch on v 1.3 hardware? It works on my v 1.4.
>>
>> If you use kdmx2, the way to send a break is '~B'. The previous
>> key pressed must be for the '~' escape to be recognized.
>>
>> Thanks!
>>
>> -Frank
>>
>>
>>
>> From: Frank Rowand
>>
>> Add missing sysrq handling to msm_serial.
>>
>> Signed-off-by: Frank Rowand
>>
>> ---
>
> It works but I have questions.
>
>> drivers/tty/serial/msm_serial.c | 26 +-
>> 1 file changed, 21 insertions(+), 5 deletions(-)
>>
>> Index: b/drivers/tty/serial/msm_serial.c
>> ===
>> --- a/drivers/tty/serial/msm_serial.c
>> +++ b/drivers/tty/serial/msm_serial.c
>> @@ -126,6 +126,8 @@ static void handle_rx_dm(struct uart_por
>>
>> while (count > 0) {
>> unsigned int c;
>> +unsigned char *cp;
>> +int res;
>>
>> sr = msm_read(port, UART_SR);
>> if ((sr & UART_SR_RX_READY) == 0) {
>> @@ -135,15 +137,29 @@ static void handle_rx_dm(struct uart_por
>> c = msm_read(port, UARTDM_RF);
>> if (sr & UART_SR_RX_BREAK) {
>> port->icount.brk++;
>> -if (uart_handle_break(port))
>> +if (uart_handle_break(port)) {
>> +count -= 1;
>> continue;
>> +}
>
> This looks wrong. If it's a break then I think the fifo takes in a break
> character indicated by all zeros. We could possibly have 3 other
> characters after it in the fifo, or maybe 2 characters in front of it,
> or it could be 30 characters in. We can change this behavior by setting
> a bit in the MR2 register so that the all zero character doesn't enter
> the fifo. The same goes for the parity and frame error conditions, we
> can drop those characters too.
>
> I asked the designers how we're supposed to deal with a break in the
> middle of the fifo and they recommended using the start/stop rx break
> interrupts. Unfortunately, I don't think we can rely on the interrupts
> being distinct so that might not work (but see attached patch). There's
> also a break interrupt that triggers on the start and stop rx break
> events. I don't know how this is useful either because we might get two
> interrupts or we might get one.
>
> So perhaps we need to scan through the 4 characters for a zero character
> when the SR_RX_BREAK bit it set? The second diff does that.
>
> Add another twist with port->read_status_mask. I guess that's there to
> make it so that break characters still enter the tty layer? Is there any
> documentation on this stuff? I'm lost on what the tty layer expects.
< snip >
Yep, the whole break in the middle of a fifo is interesting. If I understand
correctly, there is not enough information to determine where in the byte
stream the break actually occurred. If interrupts were not disabled for any
length of time, then it was probably after all of the characters in the fifo.
But I don't like to depend on winning races. As you noted, finding a \0 in
the fifo is likely the location in the byte stream where the break occurred.
But \0 is also valid data.
I read through the two alternate patches that you attached and read some tty
layer stuff. Your patches look like better code than my original code, and
also leave less cruft in the input stream when stress tested. One stress
test that I have not attempted to create is to hold off processing the break
until after more character have entered the fifo.
The patches you sent are a little hard to read since they modify further code
that my patch modified. So I have redone your patches, as if my patch was
not previously applied. Hopefully I did not make any mistakes there. I will
reply to this email with each of your redone patches.
I do not have a strong preference between the two alternatives you provided,
without digging deeper into the tty layer, which I won't have time for in
the next week. Both alternatives improve the break handling (leave less
cruft in the input stream when stress tested than before applying the
patches). Both alternatives support sysrq in my testing.
If you do not want to submit either of your alternatives, I can dig into
this again in a couple weeks.
Thanks!
-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 8/12/2014 5:23 PM, Stephen Boyd wrote:
On 08/06/14 17:16, Frank Rowand wrote:
Stephen,
Can you test this patch on v 1.3 hardware? It works on my v 1.4.
If you use kdmx2, the way to send a break is '~B'. The previous
key pressed must be enter for the '~' escape to be recognized.
Thanks!
-Frank
From: Frank Rowand frank.row...@sonymobile.com
Add missing sysrq handling to msm_serial.
Signed-off-by: Frank Rowand frank.row...@sonymobile.com
---
It works but I have questions.
drivers/tty/serial/msm_serial.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
Index: b/drivers/tty/serial/msm_serial.c
===
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -126,6 +126,8 @@ static void handle_rx_dm(struct uart_por
while (count 0) {
unsigned int c;
+unsigned char *cp;
+int res;
sr = msm_read(port, UART_SR);
if ((sr UART_SR_RX_READY) == 0) {
@@ -135,15 +137,29 @@ static void handle_rx_dm(struct uart_por
c = msm_read(port, UARTDM_RF);
if (sr UART_SR_RX_BREAK) {
port-icount.brk++;
-if (uart_handle_break(port))
+if (uart_handle_break(port)) {
+count -= 1;
continue;
+}
This looks wrong. If it's a break then I think the fifo takes in a break
character indicated by all zeros. We could possibly have 3 other
characters after it in the fifo, or maybe 2 characters in front of it,
or it could be 30 characters in. We can change this behavior by setting
a bit in the MR2 register so that the all zero character doesn't enter
the fifo. The same goes for the parity and frame error conditions, we
can drop those characters too.
I asked the designers how we're supposed to deal with a break in the
middle of the fifo and they recommended using the start/stop rx break
interrupts. Unfortunately, I don't think we can rely on the interrupts
being distinct so that might not work (but see attached patch). There's
also a break interrupt that triggers on the start and stop rx break
events. I don't know how this is useful either because we might get two
interrupts or we might get one.
So perhaps we need to scan through the 4 characters for a zero character
when the SR_RX_BREAK bit it set? The second diff does that.
Add another twist with port-read_status_mask. I guess that's there to
make it so that break characters still enter the tty layer? Is there any
documentation on this stuff? I'm lost on what the tty layer expects.
snip
Yep, the whole break in the middle of a fifo is interesting. If I understand
correctly, there is not enough information to determine where in the byte
stream the break actually occurred. If interrupts were not disabled for any
length of time, then it was probably after all of the characters in the fifo.
But I don't like to depend on winning races. As you noted, finding a \0 in
the fifo is likely the location in the byte stream where the break occurred.
But \0 is also valid data.
I read through the two alternate patches that you attached and read some tty
layer stuff. Your patches look like better code than my original code, and
also leave less cruft in the input stream when stress tested. One stress
test that I have not attempted to create is to hold off processing the break
until after more character have entered the fifo.
The patches you sent are a little hard to read since they modify further code
that my patch modified. So I have redone your patches, as if my patch was
not previously applied. Hopefully I did not make any mistakes there. I will
reply to this email with each of your redone patches.
I do not have a strong preference between the two alternatives you provided,
without digging deeper into the tty layer, which I won't have time for in
the next week. Both alternatives improve the break handling (leave less
cruft in the input stream when stress tested than before applying the
patches). Both alternatives support sysrq in my testing.
If you do not want to submit either of your alternatives, I can dig into
this again in a couple weeks.
Thanks!
-Frank
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 8/13/2014 7:33 PM, Frank Rowand wrote:
On 8/12/2014 5:23 PM, Stephen Boyd wrote:
On 08/06/14 17:16, Frank Rowand wrote:
snip
The patches you sent are a little hard to read since they modify further code
that my patch modified. So I have redone your patches, as if my patch was
not previously applied. Hopefully I did not make any mistakes there. I will
reply to this email with each of your redone patches.
snip
Stephen's patch alternative number 1:
---
drivers/tty/serial/msm_serial.c | 44
drivers/tty/serial/msm_serial.h |8 +++
2 files changed, 39 insertions(+), 13 deletions(-)
Index: b/drivers/tty/serial/msm_serial.c
===
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -125,25 +125,28 @@ static void handle_rx_dm(struct uart_por
port-icount.rx += count;
while (count 0) {
- unsigned int c;
+ unsigned char buf[4];
+ unsigned char *p = buf;
+ int sysrq, r_count;
sr = msm_read(port, UART_SR);
if ((sr UART_SR_RX_READY) == 0) {
msm_port-old_snap_state -= count;
break;
}
- c = msm_read(port, UARTDM_RF);
- if (sr UART_SR_RX_BREAK) {
- port-icount.brk++;
- if (uart_handle_break(port))
- continue;
- } else if (sr UART_SR_PAR_FRAME_ERR)
- port-icount.frame++;
+ readsl(port-membase + UARTDM_RF, p, 1);
- /* TODO: handle sysrq */
- tty_insert_flip_string(tport, (char *)c,
- (count 4) ? 4 : count);
- count -= 4;
+ spin_unlock(port-lock);
+ sysrq = uart_handle_sysrq_char(port, buf[0]);
+ spin_lock(port-lock);
+ if (sysrq) {
+ p++;
+ count--;
+ }
+ r_count = min_t(int, count, sizeof(buf) - sysrq);
+ if (r_count)
+ tty_insert_flip_string(tport, p, r_count);
+ count -= r_count;
}
spin_unlock(port-lock);
@@ -285,6 +288,17 @@ static irqreturn_t msm_irq(int irq, void
misr = msm_read(port, UART_MISR);
msm_write(port, 0, UART_IMR); /* disable interrupt */
+ if (misr UART_IMR_RXBREAK_END) {
+ uart_handle_break(port);
+ port-icount.brk++;
+ msm_write(port, UART_CR_CMD_RESET_RXBREAK_END, UART_CR);
+ }
+
+ if (misr UART_IMR_PAR_FRAME_ERR) {
+ port-icount.frame++;
+ msm_write(port, UART_CR_CMD_RESET_PAR_FRAME_ERR, UART_CR);
+ }
+
if (misr (UART_IMR_RXLEV | UART_IMR_RXSTALE)) {
if (msm_port-is_uartdm)
handle_rx_dm(port, misr);
@@ -491,7 +505,8 @@ static int msm_startup(struct uart_port
/* turn on RX and CTS interrupts */
msm_port-imr = UART_IMR_RXLEV | UART_IMR_RXSTALE |
- UART_IMR_CURRENT_CTS;
+ UART_IMR_CURRENT_CTS | UART_IMR_RXBREAK_END |
+ UART_IMR_PAR_FRAME_ERR;
if (msm_port-is_uartdm) {
msm_write(port, 0xFF, UARTDM_DMRX);
@@ -566,6 +581,9 @@ static void msm_set_termios(struct uart_
else
mr |= UART_MR2_STOP_BIT_LEN_ONE;
+ mr |= UART_MR2_RX_BREAK_ZERO_CHAR_OFF;
+ mr |= UART_MR2_RX_ERROR_CHAR_OFF;
+
/* set parity, bits per char, and stop bit */
msm_write(port, mr, UART_MR2);
Index: b/drivers/tty/serial/msm_serial.h
===
--- a/drivers/tty/serial/msm_serial.h
+++ b/drivers/tty/serial/msm_serial.h
@@ -24,6 +24,8 @@
#define UART_MR1_CTS_CTL (1 6)
#define UART_MR2 0x0004
+#define UART_MR2_RX_ERROR_CHAR_OFF (1 9)
+#define UART_MR2_RX_BREAK_ZERO_CHAR_OFF(1 8)
#define UART_MR2_ERROR_MODE(1 6)
#define UART_MR2_BITS_PER_CHAR 0x30
#define UART_MR2_BITS_PER_CHAR_5 (0x0 4)
@@ -65,6 +67,9 @@
#define UART_CR_TX_ENABLE (1 2)
#define UART_CR_RX_DISABLE (1 1)
#define UART_CR_RX_ENABLE (1 0)
+#define UART_CR_CMD_RESET_RXBREAK_START((1 11) | (2 4))
+#define UART_CR_CMD_RESET_RXBREAK_END ((1 11) | (3 4))
+#define UART_CR_CMD_RESET_PAR_FRAME_ERR((1 11) | (4 4))
#define UART_IMR 0x0014
#define UART_IMR_TXLEV (1 0)
@@ -72,6 +77,9 @@
#define UART_IMR_RXLEV (1 4)
#define UART_IMR_DELTA_CTS (1 5)
#define UART_IMR_CURRENT_CTS (1 6)
+#define UART_IMR_RXBREAK_START (1 10)
+#define UART_IMR_RXBREAK_END (1
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 8/13/2014 7:33 PM, Frank Rowand wrote:
On 8/12/2014 5:23 PM, Stephen Boyd wrote:
On 08/06/14 17:16, Frank Rowand wrote:
snip
The patches you sent are a little hard to read since they modify further code
that my patch modified. So I have redone your patches, as if my patch was
not previously applied. Hopefully I did not make any mistakes there. I will
reply to this email with each of your redone patches.
Stephen's patch alternative number 2:
---
drivers/tty/serial/msm_serial.c | 41 +++-
1 file changed, 28 insertions(+), 13 deletions(-)
Index: b/drivers/tty/serial/msm_serial.c
===
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -125,25 +125,40 @@ static void handle_rx_dm(struct uart_por
port-icount.rx += count;
while (count 0) {
- unsigned int c;
+ unsigned char buf[4];
+ int sysrq, r_count, i;
sr = msm_read(port, UART_SR);
if ((sr UART_SR_RX_READY) == 0) {
msm_port-old_snap_state -= count;
break;
}
- c = msm_read(port, UARTDM_RF);
- if (sr UART_SR_RX_BREAK) {
- port-icount.brk++;
- if (uart_handle_break(port))
- continue;
- } else if (sr UART_SR_PAR_FRAME_ERR)
- port-icount.frame++;
-
- /* TODO: handle sysrq */
- tty_insert_flip_string(tport, (char *)c,
- (count 4) ? 4 : count);
- count -= 4;
+ readsl(port-membase + UARTDM_RF, buf, 1);
+
+ r_count = min_t(int, count, sizeof(buf));
+
+ for (i = 0; i r_count; i++) {
+ char flag = TTY_NORMAL;
+
+ if (sr UART_SR_RX_BREAK) {
+ if (buf[i] == 0) {
+ port-icount.brk++;
+ flag = TTY_BREAK;
+ if (uart_handle_break(port))
+ continue;
+ }
+ }
+
+ if (!(port-read_status_mask UART_SR_RX_BREAK))
+ flag = TTY_NORMAL;
+
+ spin_unlock(port-lock);
+ sysrq = uart_handle_sysrq_char(port, buf[i]);
+ spin_lock(port-lock);
+ if (!sysrq)
+ tty_insert_flip_char(tport, buf[i], flag);
+ }
+ count -= r_count;
}
spin_unlock(port-lock);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 08/06/14 17:16, Frank Rowand wrote:
> Stephen,
>
> Can you test this patch on v 1.3 hardware? It works on my v 1.4.
>
> If you use kdmx2, the way to send a break is '~B'. The previous
> key pressed must be for the '~' escape to be recognized.
>
> Thanks!
>
> -Frank
>
>
>
> From: Frank Rowand
>
> Add missing sysrq handling to msm_serial.
>
> Signed-off-by: Frank Rowand
>
> ---
It works but I have questions.
> drivers/tty/serial/msm_serial.c | 26 +-
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> Index: b/drivers/tty/serial/msm_serial.c
> ===
> --- a/drivers/tty/serial/msm_serial.c
> +++ b/drivers/tty/serial/msm_serial.c
> @@ -126,6 +126,8 @@ static void handle_rx_dm(struct uart_por
>
> while (count > 0) {
> unsigned int c;
> + unsigned char *cp;
> + int res;
>
> sr = msm_read(port, UART_SR);
> if ((sr & UART_SR_RX_READY) == 0) {
> @@ -135,15 +137,29 @@ static void handle_rx_dm(struct uart_por
> c = msm_read(port, UARTDM_RF);
> if (sr & UART_SR_RX_BREAK) {
> port->icount.brk++;
> - if (uart_handle_break(port))
> + if (uart_handle_break(port)) {
> + count -= 1;
> continue;
> + }
This looks wrong. If it's a break then I think the fifo takes in a break
character indicated by all zeros. We could possibly have 3 other
characters after it in the fifo, or maybe 2 characters in front of it,
or it could be 30 characters in. We can change this behavior by setting
a bit in the MR2 register so that the all zero character doesn't enter
the fifo. The same goes for the parity and frame error conditions, we
can drop those characters too.
I asked the designers how we're supposed to deal with a break in the
middle of the fifo and they recommended using the start/stop rx break
interrupts. Unfortunately, I don't think we can rely on the interrupts
being distinct so that might not work (but see attached patch). There's
also a break interrupt that triggers on the start and stop rx break
events. I don't know how this is useful either because we might get two
interrupts or we might get one.
So perhaps we need to scan through the 4 characters for a zero character
when the SR_RX_BREAK bit it set? The second diff does that.
Add another twist with port->read_status_mask. I guess that's there to
make it so that break characters still enter the tty layer? Is there any
documentation on this stuff? I'm lost on what the tty layer expects.
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index e52a4242b7a1..ba66e487c08a 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -125,41 +125,28 @@ static void handle_rx_dm(struct uart_port *port, unsigned
int misr)
port->icount.rx += count;
while (count > 0) {
- unsigned int c;
- unsigned char *cp;
- int res;
+ unsigned char buf[4];
+ unsigned char *p = buf;
+ int sysrq, r_count;
sr = msm_read(port, UART_SR);
if ((sr & UART_SR_RX_READY) == 0) {
msm_port->old_snap_state -= count;
break;
}
- c = msm_read(port, UARTDM_RF);
- if (sr & UART_SR_RX_BREAK) {
- port->icount.brk++;
- if (uart_handle_break(port)) {
- count -= 1;
- continue;
- }
- } else if (sr & UART_SR_PAR_FRAME_ERR)
- port->icount.frame++;
+ readsl(port->membase + UARTDM_RF, p, 1);
spin_unlock(>lock);
- res = uart_handle_sysrq_char(port, c);
+ sysrq = uart_handle_sysrq_char(port, buf[0]);
spin_lock(>lock);
-
- cp = (unsigned char *)
- if (res) {
- count -= 1;
- tty_insert_flip_string(tport, cp + 1,
- (count > 3) ? 3 : count);
- count -= (count > 3) ? 3 : count;
- } else {
- tty_insert_flip_string(tport, cp,
- (count > 4) ? 4 : count);
- count -= (count > 4) ? 4 : count;
+ if (sysrq) {
+ p++;
+ count--;
}
-
+ r_count = min_t(int, count, sizeof(bu
Re: [PATCH to be tested] serial: msm_serial: add missing sysrq handling
On 08/06/14 17:16, Frank Rowand wrote:
Stephen,
Can you test this patch on v 1.3 hardware? It works on my v 1.4.
If you use kdmx2, the way to send a break is '~B'. The previous
key pressed must be enter for the '~' escape to be recognized.
Thanks!
-Frank
From: Frank Rowand frank.row...@sonymobile.com
Add missing sysrq handling to msm_serial.
Signed-off-by: Frank Rowand frank.row...@sonymobile.com
---
It works but I have questions.
drivers/tty/serial/msm_serial.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
Index: b/drivers/tty/serial/msm_serial.c
===
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -126,6 +126,8 @@ static void handle_rx_dm(struct uart_por
while (count 0) {
unsigned int c;
+ unsigned char *cp;
+ int res;
sr = msm_read(port, UART_SR);
if ((sr UART_SR_RX_READY) == 0) {
@@ -135,15 +137,29 @@ static void handle_rx_dm(struct uart_por
c = msm_read(port, UARTDM_RF);
if (sr UART_SR_RX_BREAK) {
port-icount.brk++;
- if (uart_handle_break(port))
+ if (uart_handle_break(port)) {
+ count -= 1;
continue;
+ }
This looks wrong. If it's a break then I think the fifo takes in a break
character indicated by all zeros. We could possibly have 3 other
characters after it in the fifo, or maybe 2 characters in front of it,
or it could be 30 characters in. We can change this behavior by setting
a bit in the MR2 register so that the all zero character doesn't enter
the fifo. The same goes for the parity and frame error conditions, we
can drop those characters too.
I asked the designers how we're supposed to deal with a break in the
middle of the fifo and they recommended using the start/stop rx break
interrupts. Unfortunately, I don't think we can rely on the interrupts
being distinct so that might not work (but see attached patch). There's
also a break interrupt that triggers on the start and stop rx break
events. I don't know how this is useful either because we might get two
interrupts or we might get one.
So perhaps we need to scan through the 4 characters for a zero character
when the SR_RX_BREAK bit it set? The second diff does that.
Add another twist with port-read_status_mask. I guess that's there to
make it so that break characters still enter the tty layer? Is there any
documentation on this stuff? I'm lost on what the tty layer expects.
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index e52a4242b7a1..ba66e487c08a 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -125,41 +125,28 @@ static void handle_rx_dm(struct uart_port *port, unsigned
int misr)
port-icount.rx += count;
while (count 0) {
- unsigned int c;
- unsigned char *cp;
- int res;
+ unsigned char buf[4];
+ unsigned char *p = buf;
+ int sysrq, r_count;
sr = msm_read(port, UART_SR);
if ((sr UART_SR_RX_READY) == 0) {
msm_port-old_snap_state -= count;
break;
}
- c = msm_read(port, UARTDM_RF);
- if (sr UART_SR_RX_BREAK) {
- port-icount.brk++;
- if (uart_handle_break(port)) {
- count -= 1;
- continue;
- }
- } else if (sr UART_SR_PAR_FRAME_ERR)
- port-icount.frame++;
+ readsl(port-membase + UARTDM_RF, p, 1);
spin_unlock(port-lock);
- res = uart_handle_sysrq_char(port, c);
+ sysrq = uart_handle_sysrq_char(port, buf[0]);
spin_lock(port-lock);
-
- cp = (unsigned char *)c;
- if (res) {
- count -= 1;
- tty_insert_flip_string(tport, cp + 1,
- (count 3) ? 3 : count);
- count -= (count 3) ? 3 : count;
- } else {
- tty_insert_flip_string(tport, cp,
- (count 4) ? 4 : count);
- count -= (count 4) ? 4 : count;
+ if (sysrq) {
+ p++;
+ count--;
}
-
+ r_count = min_t(int, count, sizeof(buf) - sysrq);
+ if (r_count)
+ tty_insert_flip_string(tport, p, r_count);
+ count -= r_count;
}
spin_unlock(port-lock);
@@ -301,6
[PATCH to be tested] serial: msm_serial: add missing sysrq handling
Stephen,
Can you test this patch on v 1.3 hardware? It works on my v 1.4.
If you use kdmx2, the way to send a break is '~B'. The previous
key pressed must be for the '~' escape to be recognized.
Thanks!
-Frank
From: Frank Rowand
Add missing sysrq handling to msm_serial.
Signed-off-by: Frank Rowand
---
drivers/tty/serial/msm_serial.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
Index: b/drivers/tty/serial/msm_serial.c
===
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -126,6 +126,8 @@ static void handle_rx_dm(struct uart_por
while (count > 0) {
unsigned int c;
+ unsigned char *cp;
+ int res;
sr = msm_read(port, UART_SR);
if ((sr & UART_SR_RX_READY) == 0) {
@@ -135,15 +137,29 @@ static void handle_rx_dm(struct uart_por
c = msm_read(port, UARTDM_RF);
if (sr & UART_SR_RX_BREAK) {
port->icount.brk++;
- if (uart_handle_break(port))
+ if (uart_handle_break(port)) {
+ count -= 1;
continue;
+ }
} else if (sr & UART_SR_PAR_FRAME_ERR)
port->icount.frame++;
- /* TODO: handle sysrq */
- tty_insert_flip_string(tport, (char *),
- (count > 4) ? 4 : count);
- count -= 4;
+ spin_unlock(>lock);
+ res = uart_handle_sysrq_char(port, c);
+ spin_lock(>lock);
+
+ cp = (unsigned char *)
+ if (res) {
+ count -= 1;
+ tty_insert_flip_string(tport, cp + 1,
+ (count > 3) ? 3 : count);
+ count -= (count > 3) ? 3 : count;
+ } else {
+ tty_insert_flip_string(tport, cp,
+ (count > 4) ? 4 : count);
+ count -= (count > 4) ? 4 : count;
+ }
+
}
spin_unlock(>lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH to be tested] serial: msm_serial: add missing sysrq handling
Stephen,
Can you test this patch on v 1.3 hardware? It works on my v 1.4.
If you use kdmx2, the way to send a break is '~B'. The previous
key pressed must be enter for the '~' escape to be recognized.
Thanks!
-Frank
From: Frank Rowand frank.row...@sonymobile.com
Add missing sysrq handling to msm_serial.
Signed-off-by: Frank Rowand frank.row...@sonymobile.com
---
drivers/tty/serial/msm_serial.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
Index: b/drivers/tty/serial/msm_serial.c
===
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -126,6 +126,8 @@ static void handle_rx_dm(struct uart_por
while (count 0) {
unsigned int c;
+ unsigned char *cp;
+ int res;
sr = msm_read(port, UART_SR);
if ((sr UART_SR_RX_READY) == 0) {
@@ -135,15 +137,29 @@ static void handle_rx_dm(struct uart_por
c = msm_read(port, UARTDM_RF);
if (sr UART_SR_RX_BREAK) {
port-icount.brk++;
- if (uart_handle_break(port))
+ if (uart_handle_break(port)) {
+ count -= 1;
continue;
+ }
} else if (sr UART_SR_PAR_FRAME_ERR)
port-icount.frame++;
- /* TODO: handle sysrq */
- tty_insert_flip_string(tport, (char *)c,
- (count 4) ? 4 : count);
- count -= 4;
+ spin_unlock(port-lock);
+ res = uart_handle_sysrq_char(port, c);
+ spin_lock(port-lock);
+
+ cp = (unsigned char *)c;
+ if (res) {
+ count -= 1;
+ tty_insert_flip_string(tport, cp + 1,
+ (count 3) ? 3 : count);
+ count -= (count 3) ? 3 : count;
+ } else {
+ tty_insert_flip_string(tport, cp,
+ (count 4) ? 4 : count);
+ count -= (count 4) ? 4 : count;
+ }
+
}
spin_unlock(port-lock);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/21] KGDB: Fix possibility of missing SysRq-G
Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
sysrq_bugfix.patch
From: Jason Wessel <[EMAIL PROTECTED]>
Subject: [PATCH] Fix possibility of missing SysRq-G
It is possible that when SysRq-G is triggered via the keyboard that we
will miss the "up" event and once KGDB lets the kernel go another
SysRq will be required to clear this, without this change.
Signed-off-by: Tom Rini <[EMAIL PROTECTED]>
Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
---
drivers/char/keyboard.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.21.1/drivers/char/keyboard.c
===
--- linux-2.6.21.1.orig/drivers/char/keyboard.c
+++ linux-2.6.21.1/drivers/char/keyboard.c
@@ -1176,6 +1176,7 @@ static void kbd_keycode(unsigned int key
sysrq_down = 0;
if (sysrq_down && down && !rep) {
handle_sysrq(kbd_sysrq_xlate[keycode], tty);
+ sysrq_down = 0; /* In case we miss the 'up' event. */
return;
}
#endif
[PATCH 15/21] KGDB: Fix possibility of missing SysRq-G
Signed-off-by: Jason Wessel [EMAIL PROTECTED]
sysrq_bugfix.patch
From: Jason Wessel [EMAIL PROTECTED]
Subject: [PATCH] Fix possibility of missing SysRq-G
It is possible that when SysRq-G is triggered via the keyboard that we
will miss the up event and once KGDB lets the kernel go another
SysRq will be required to clear this, without this change.
Signed-off-by: Tom Rini [EMAIL PROTECTED]
Signed-off-by: Jason Wessel [EMAIL PROTECTED]
---
drivers/char/keyboard.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.21.1/drivers/char/keyboard.c
===
--- linux-2.6.21.1.orig/drivers/char/keyboard.c
+++ linux-2.6.21.1/drivers/char/keyboard.c
@@ -1176,6 +1176,7 @@ static void kbd_keycode(unsigned int key
sysrq_down = 0;
if (sysrq_down down !rep) {
handle_sysrq(kbd_sysrq_xlate[keycode], tty);
+ sysrq_down = 0; /* In case we miss the 'up' event. */
return;
}
#endif
Re: missing sysrq
BTW, you ONLY need to echo 1 > /proc../sysrq if you use a distribution that puts a 0 there on init. By default the kernel initializes with '1'. David >>>I compiled it, and the sysrq is definitely in the config. No doubt at >>>all. I also use make mrproper and config again before dep and actual >>>compile. Maybe it is just a quirk/oddball. >>> >>>D. Stimits, [EMAIL PROTECTED] >>> >>Have you tried "echo 1 > /proc/sys/kernel/sysrq"? >>You need both, compiled in and activation. >> - 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: missing sysrq
BTW, you ONLY need to echo 1 /proc../sysrq if you use a distribution that puts a 0 there on init. By default the kernel initializes with '1'. David I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. - 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: missing sysrq
"Mike A. Harris" wrote: > > On Fri, 1 Jun 2001, Dieter Nützel wrote: > > >> > In article <[EMAIL PROTECTED]> you wrote: > >> > > However, if I go to /proc/sys/kernel/sysrq does not exist. > >> > > >> > It is a compile time option, so the person who compiled your kernel > >> > left it out. > >> > >> I compiled it, and the sysrq is definitely in the config. No doubt at > >> all. I also use make mrproper and config again before dep and actual > >> compile. Maybe it is just a quirk/oddball. > >> > >> D. Stimits, [EMAIL PROTECTED] > > > >Have you tried "echo 1 > /proc/sys/kernel/sysrq"? > >You need both, compiled in and activation. Since then I've completely removed that kernel source and kernel, only the config file remains (and it had it activated if the config followed it). All kernels before worked, and those since then also work, so I know it isn't the keyboard. I also always run make mrproper and config it again between compiles (I keep a list of config history), so I don't know what was wrong, but replacing the kernel fixed it, and is no longer an issue. I will, however, keep the showkey suggestion handy in case it ever does it again. D. Stimits, [EMAIL PROTECTED] > > If you *know* it is compiled into your kernel, and you *know* it > is enabled via the above, and it still does not work, do the > following: > > Run: > > showkey -s > > Then press LALT quickly followed by SYSRQ, and keep holding both > down, and you should see: > > 0x38 > 0x54 > > You might see a bunch of extra 0x38's which is ok. > > If however when you press ALT-SYSRQ you see: > > 0x38 0x54 0xd4 > > and are still holding both keys down, then your keyboard is > broken and incompatible with the kernel SYSRQ feature. > > A proper keyboard will only show "0x38 0x54". I have written a > patch for SYSRQ to allow it to be used with broken keyboards that > send the make+break code for the SYSRQ sequence simultaneously. > > If you need it, let me know and I'll send it to you. > > -- > Mike A. Harris - Linux advocate - Open Source advocate >Opinions and viewpoints expressed are solely my own. > -- - 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: missing sysrq
On Fri, 1 Jun 2001, Dieter Nützel wrote: >> > In article <[EMAIL PROTECTED]> you wrote: >> > > However, if I go to /proc/sys/kernel/sysrq does not exist. >> > >> > It is a compile time option, so the person who compiled your kernel >> > left it out. >> >> I compiled it, and the sysrq is definitely in the config. No doubt at >> all. I also use make mrproper and config again before dep and actual >> compile. Maybe it is just a quirk/oddball. >> >> D. Stimits, [EMAIL PROTECTED] > >Have you tried "echo 1 > /proc/sys/kernel/sysrq"? >You need both, compiled in and activation. If you *know* it is compiled into your kernel, and you *know* it is enabled via the above, and it still does not work, do the following: Run: showkey -s Then press LALT quickly followed by SYSRQ, and keep holding both down, and you should see: 0x38 0x54 You might see a bunch of extra 0x38's which is ok. If however when you press ALT-SYSRQ you see: 0x38 0x54 0xd4 and are still holding both keys down, then your keyboard is broken and incompatible with the kernel SYSRQ feature. A proper keyboard will only show "0x38 0x54". I have written a patch for SYSRQ to allow it to be used with broken keyboards that send the make+break code for the SYSRQ sequence simultaneously. If you need it, let me know and I'll send it to you. -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- - 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: missing sysrq
On Thu, 31 May 2001, D. Stimits wrote: >Date: Thu, 31 May 2001 17:48:34 -0600 >From: D. Stimits <[EMAIL PROTECTED]> >To: unlisted-recipients:;;@timpanogas.com (no To-header on input) >Cc: [EMAIL PROTECTED] >Content-Type: text/plain; charset=us-ascii >Subject: Re: missing sysrq > >Bernd Eckenfels wrote: >> >> In article <[EMAIL PROTECTED]> you wrote: >> > However, if I go to /proc/sys/kernel/sysrq does not exist. >> >> It is a compile time option, so the person who compiled your kernel left it >> out. > >I compiled it, and the sysrq is definitely in the config. No doubt at >all. I also use make mrproper and config again before dep and actual >compile. Maybe it is just a quirk/oddball. What does this say: ksyms -a |grep -i sysrq -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- Who knows what dangerous code lurks in the hearts of men? Only the Shadowman(TM) knows... Mike A. Harris <[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: missing sysrq
On Thu, 31 May 2001, D. Stimits wrote: Date: Thu, 31 May 2001 17:48:34 -0600 From: D. Stimits [EMAIL PROTECTED] To: unlisted-recipients:;;@timpanogas.com (no To-header on input) Cc: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: missing sysrq Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. What does this say: ksyms -a |grep -i sysrq -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- Who knows what dangerous code lurks in the hearts of men? Only the Shadowman(TM) knows... Mike A. Harris [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: missing sysrq
On Fri, 1 Jun 2001, Dieter Nützel wrote: In article [EMAIL PROTECTED] you wrote: However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. If you *know* it is compiled into your kernel, and you *know* it is enabled via the above, and it still does not work, do the following: Run: showkey -s Then press LALT quickly followed by SYSRQ, and keep holding both down, and you should see: 0x38 0x54 You might see a bunch of extra 0x38's which is ok. If however when you press ALT-SYSRQ you see: 0x38 0x54 0xd4 and are still holding both keys down, then your keyboard is broken and incompatible with the kernel SYSRQ feature. A proper keyboard will only show 0x38 0x54. I have written a patch for SYSRQ to allow it to be used with broken keyboards that send the make+break code for the SYSRQ sequence simultaneously. If you need it, let me know and I'll send it to you. -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- - 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: missing sysrq
Mike A. Harris wrote: On Fri, 1 Jun 2001, Dieter Nützel wrote: In article [EMAIL PROTECTED] you wrote: However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. Since then I've completely removed that kernel source and kernel, only the config file remains (and it had it activated if the config followed it). All kernels before worked, and those since then also work, so I know it isn't the keyboard. I also always run make mrproper and config it again between compiles (I keep a list of config history), so I don't know what was wrong, but replacing the kernel fixed it, and is no longer an issue. I will, however, keep the showkey suggestion handy in case it ever does it again. D. Stimits, [EMAIL PROTECTED] If you *know* it is compiled into your kernel, and you *know* it is enabled via the above, and it still does not work, do the following: Run: showkey -s Then press LALT quickly followed by SYSRQ, and keep holding both down, and you should see: 0x38 0x54 You might see a bunch of extra 0x38's which is ok. If however when you press ALT-SYSRQ you see: 0x38 0x54 0xd4 and are still holding both keys down, then your keyboard is broken and incompatible with the kernel SYSRQ feature. A proper keyboard will only show 0x38 0x54. I have written a patch for SYSRQ to allow it to be used with broken keyboards that send the make+break code for the SYSRQ sequence simultaneously. If you need it, let me know and I'll send it to you. -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- - 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: missing sysrq
On Sat, Jun 02, 2001 at 03:10:55PM -0700, H. Peter Anvin wrote: > That seems like a very bad idea. What if there is a boot script bug? Also think about kernel panics - the only thing that works after that is the power or (if you have it connected) reset button. ctrl-alt-del needs keventd to work, and since sysrq-b is disabled by default... However, IMHO that is a non-point because you need to be physically at the system either way to solve the problem. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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: missing sysrq
Russell King wrote: > > On Sat, Jun 02, 2001 at 03:10:55PM -0700, H. Peter Anvin wrote: > > That seems like a very bad idea. What if there is a boot script bug? > > Also think about kernel panics - the only thing that works after that > is the power or (if you have it connected) reset button. ctrl-alt-del > needs keventd to work, and since sysrq-b is disabled by default... > > However, IMHO that is a non-point because you need to be physically > at the system either way to solve the problem. > Not true if you have a serial console (and SysRq over serial console happens to work correctly that day.) Assuming this change is corrected to be sane. -hpa - 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: missing sysrq
Russell King wrote: > > On Fri, Jun 01, 2001 at 04:13:02PM -0700, H. Peter Anvin wrote: > > Let me guess... you're using a RedHat system? RedHat, for some > > idiotic reason, defaults to actively turning this off for you (and > > they turn Stop-A off on SPARC, too.) > > Umm, its off by default in 2.4.5 kernels, unless altered by a > distributions boot scripts. > That seems like a very bad idea. What if there is a boot script bug? -hpa - 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: missing sysrq
On Fri, Jun 01, 2001 at 04:13:02PM -0700, H. Peter Anvin wrote: > Let me guess... you're using a RedHat system? RedHat, for some > idiotic reason, defaults to actively turning this off for you (and > they turn Stop-A off on SPARC, too.) Umm, its off by default in 2.4.5 kernels, unless altered by a distributions boot scripts. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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: missing sysrq
Followup to: <[EMAIL PROTECTED]> By author:Dieter =?iso-8859-1?q?N=FCtzel?= <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Am Freitag, 1. Juni 2001 16:51 schrieben Sie: > > > Have you tried "echo 1 > /proc/sys/kernel/sysrq"? > > > You need both, compiled in and activation. > > > > no, look at the code. the enable variable defaults to 1. > > Then there must be a bug? > I get "0" with 2.4.5-ac2 and -ac5 without "echo 1". > > Fresh booted 2.4.5-ac2: > > SunWave1>cat /proc/version > Linux version 2.4.5-ac2 (root@SunWave1) (gcc version 2.95.2 19991024 > (release)) #1 Mon May 28 05:42:09 CEST 2001 > SunWave1>cat /proc/sys/kernel/sysrq > 0 > Let me guess... you're using a RedHat system? RedHat, for some idiotic reason, defaults to actively turning this off for you (and they turn Stop-A off on SPARC, too.) -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: missing sysrq
Followup to: [EMAIL PROTECTED] By author:Dieter =?iso-8859-1?q?N=FCtzel?= [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Am Freitag, 1. Juni 2001 16:51 schrieben Sie: Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. no, look at the code. the enable variable defaults to 1. Then there must be a bug? I get 0 with 2.4.5-ac2 and -ac5 without echo 1. Fresh booted 2.4.5-ac2: SunWave1cat /proc/version Linux version 2.4.5-ac2 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Mon May 28 05:42:09 CEST 2001 SunWave1cat /proc/sys/kernel/sysrq 0 Let me guess... you're using a RedHat system? RedHat, for some idiotic reason, defaults to actively turning this off for you (and they turn Stop-A off on SPARC, too.) -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: missing sysrq
On Fri, Jun 01, 2001 at 04:13:02PM -0700, H. Peter Anvin wrote: Let me guess... you're using a RedHat system? RedHat, for some idiotic reason, defaults to actively turning this off for you (and they turn Stop-A off on SPARC, too.) Umm, its off by default in 2.4.5 kernels, unless altered by a distributions boot scripts. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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: missing sysrq
Russell King wrote: On Fri, Jun 01, 2001 at 04:13:02PM -0700, H. Peter Anvin wrote: Let me guess... you're using a RedHat system? RedHat, for some idiotic reason, defaults to actively turning this off for you (and they turn Stop-A off on SPARC, too.) Umm, its off by default in 2.4.5 kernels, unless altered by a distributions boot scripts. That seems like a very bad idea. What if there is a boot script bug? -hpa - 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: missing sysrq
Russell King wrote: On Sat, Jun 02, 2001 at 03:10:55PM -0700, H. Peter Anvin wrote: That seems like a very bad idea. What if there is a boot script bug? Also think about kernel panics - the only thing that works after that is the power or (if you have it connected) reset button. ctrl-alt-del needs keventd to work, and since sysrq-b is disabled by default... However, IMHO that is a non-point because you need to be physically at the system either way to solve the problem. Not true if you have a serial console (and SysRq over serial console happens to work correctly that day.) Assuming this change is corrected to be sane. -hpa - 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: missing sysrq
On Sat, Jun 02, 2001 at 03:10:55PM -0700, H. Peter Anvin wrote: That seems like a very bad idea. What if there is a boot script bug? Also think about kernel panics - the only thing that works after that is the power or (if you have it connected) reset button. ctrl-alt-del needs keventd to work, and since sysrq-b is disabled by default... However, IMHO that is a non-point because you need to be physically at the system either way to solve the problem. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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: missing sysrq
Am Freitag, 1. Juni 2001 16:51 schrieben Sie: > > Have you tried "echo 1 > /proc/sys/kernel/sysrq"? > > You need both, compiled in and activation. > > no, look at the code. the enable variable defaults to 1. Then there must be a bug? I get "0" with 2.4.5-ac2 and -ac5 without "echo 1". Fresh booted 2.4.5-ac2: SunWave1>cat /proc/version Linux version 2.4.5-ac2 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Mon May 28 05:42:09 CEST 2001 SunWave1>cat /proc/sys/kernel/sysrq 0 -Dieter - 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: missing sysrq
Dieter Nützel wrote: > > > D. Stimits wrote: > > > > > Bernd Eckenfels wrote: > > > > > > > In article <[EMAIL PROTECTED]> you wrote: > > > > However, if I go to /proc/sys/kernel/sysrq does not exist. > > > > > > It is a compile time option, so the person who compiled your kernel > > > left it out. > > > > I compiled it, and the sysrq is definitely in the config. No doubt at > > all. I also use make mrproper and config again before dep and actual > > compile. Maybe it is just a quirk/oddball. > > > > D. Stimits, [EMAIL PROTECTED] > > Have you tried "echo 1 > /proc/sys/kernel/sysrq"? > You need both, compiled in and activation. It is compiled in, but the echo is summarily rejected. Root is not allowed to write to that file, which doesn't exist. I'm going to just wipe out everything from that kernel and redo the whole thing. D. Stimits, [EMAIL PROTECTED] > > Regards, > Dieter > -- > Dieter Nützel > Graduate Student, Computer Science > > email: [EMAIL PROTECTED] > @home: [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: missing sysrq
Dieter Nützel wrote: D. Stimits wrote: Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. It is compiled in, but the echo is summarily rejected. Root is not allowed to write to that file, which doesn't exist. I'm going to just wipe out everything from that kernel and redo the whole thing. D. Stimits, [EMAIL PROTECTED] Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science email: [EMAIL PROTECTED] @home: [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: missing sysrq
Am Freitag, 1. Juni 2001 16:51 schrieben Sie: Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. no, look at the code. the enable variable defaults to 1. Then there must be a bug? I get 0 with 2.4.5-ac2 and -ac5 without echo 1. Fresh booted 2.4.5-ac2: SunWave1cat /proc/version Linux version 2.4.5-ac2 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Mon May 28 05:42:09 CEST 2001 SunWave1cat /proc/sys/kernel/sysrq 0 -Dieter - 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: missing sysrq
> D. Stimits wrote: > > > Bernd Eckenfels wrote: > > > > > In article <[EMAIL PROTECTED]> you wrote: > > > However, if I go to /proc/sys/kernel/sysrq does not exist. > > > > It is a compile time option, so the person who compiled your kernel > > left it out. > > I compiled it, and the sysrq is definitely in the config. No doubt at > all. I also use make mrproper and config again before dep and actual > compile. Maybe it is just a quirk/oddball. > > D. Stimits, [EMAIL PROTECTED] Have you tried "echo 1 > /proc/sys/kernel/sysrq"? You need both, compiled in and activation. Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science email: [EMAIL PROTECTED] @home: [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: missing sysrq
Bernd Eckenfels wrote: > > In article <[EMAIL PROTECTED]> you wrote: > > However, if I go to /proc/sys/kernel/sysrq does not exist. > > It is a compile time option, so the person who compiled your kernel left it > out. I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] > > > vm.freepages = 383 766 1149 > > tat feature is removed in recent VM Systems. > > Greetings > Bernd > - > 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: missing sysrq
In article <[EMAIL PROTECTED]> you wrote: > However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. > vm.freepages = 383 766 1149 tat feature is removed in recent VM Systems. Greetings Bernd - 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/
missing sysrq
I have compiled the magic sysrq as enabled in most kernels I've used for quite a while. Most recently 2.4.5-ac5, on a RH 7.1 SMP machine with APIC disabled. The /etc/sysctl.conf contains this line: kernel.sysrq = 1 However, if I go to /proc/sys/kernel/sysrq does not exist. Nor is it possible for root to echo to that file name. Attempts to use the magic sysrq keys, such as for sync, prove that it truly is not enabled, or is otherwise missing. Has something changed in the enabling of magic sysrq? Or is this one of those strange "it should be there" things? A second observation, maybe related (maybe not), is the /var/log/messages line: sysctl: error: permission denied on key 'vm.freepages' This particular line has occurred since install of RH 7.1, even with its original kernel, but continues into 2.4.5-ac5. The relevant line in /etc/sysctl.conf: vm.freepages = 383 766 1149 This line is how the original RH 7.1 install set it up. This particular machine has 256 MB of ram, and somewhat over a 1 GB of swap. Is the vm.freepages not intended to be set in /etc/sysctl.conf? Or maybe the specs are off for this particular hardware? I know a lot of vm changes are going on in the kernel, and wondering if this could be something that used to be supported but no longer is. D. Stimits, [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/
missing sysrq
I have compiled the magic sysrq as enabled in most kernels I've used for quite a while. Most recently 2.4.5-ac5, on a RH 7.1 SMP machine with APIC disabled. The /etc/sysctl.conf contains this line: kernel.sysrq = 1 However, if I go to /proc/sys/kernel/sysrq does not exist. Nor is it possible for root to echo to that file name. Attempts to use the magic sysrq keys, such as for sync, prove that it truly is not enabled, or is otherwise missing. Has something changed in the enabling of magic sysrq? Or is this one of those strange it should be there things? A second observation, maybe related (maybe not), is the /var/log/messages line: sysctl: error: permission denied on key 'vm.freepages' This particular line has occurred since install of RH 7.1, even with its original kernel, but continues into 2.4.5-ac5. The relevant line in /etc/sysctl.conf: vm.freepages = 383 766 1149 This line is how the original RH 7.1 install set it up. This particular machine has 256 MB of ram, and somewhat over a 1 GB of swap. Is the vm.freepages not intended to be set in /etc/sysctl.conf? Or maybe the specs are off for this particular hardware? I know a lot of vm changes are going on in the kernel, and wondering if this could be something that used to be supported but no longer is. D. Stimits, [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: missing sysrq
In article [EMAIL PROTECTED] you wrote: However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. vm.freepages = 383 766 1149 tat feature is removed in recent VM Systems. Greetings Bernd - 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: missing sysrq
Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] vm.freepages = 383 766 1149 tat feature is removed in recent VM Systems. Greetings Bernd - 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: missing sysrq
D. Stimits wrote: Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science email: [EMAIL PROTECTED] @home: [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/
