On May 26 2007 15:47, David Miller wrote:
>> I have set the OBP to run at 115200, also set agetty on ttyS0 to do the
>> same, and also added console=ttyS0,115200 to silo.conf (and also tried
>> console=ttyS0,115200n8). But! Linux still gives me 9600 8N1. The ominous
>> double screen blanking (why is that done anyway?) already takes place
>> with 9600. I smell a bug. What do you think?
>
>The code in drivers/serial/suncore.c:sunserial_console_termios()
>should be parsing your OBP settings, add some tracing and see why it
>isn't working.
>
>Please track the bug down for us, thanks :-)
Just why did no one get a kernel oops? After all, the code tried to
write to constant memory.
This is the first patch of two. There is yet another section of Linux
code that runs in 9600-only, and I need to figure out which.
---
The Linux kernel ignored the PROM's serial settings (115200,n,8,1 in
my case). This was because mode_prop remained "ttyX-mode" (expected:
"ttya-mode") due to the constness of string literals when used with
"char *". Since there is no "ttyX-mode" property in the PROM, Linux
always used the default 9600.
Signed-off-by: Jan Engelhardt <[email protected]>
---
drivers/serial/suncore.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.21.sparc64/drivers/serial/suncore.c
===================================================================
--- linux-2.6.21.sparc64.orig/drivers/serial/suncore.c
+++ linux-2.6.21.sparc64/drivers/serial/suncore.c
@@ -30,9 +30,9 @@ void
sunserial_console_termios(struct console *con)
{
char mode[16], buf[16], *s;
- char *mode_prop = "ttyX-mode";
- char *cd_prop = "ttyX-ignore-cd";
- char *dtr_prop = "ttyX-rts-dtr-off";
+ char mode_prop[] = "ttyX-mode";
+ char cd_prop[] = "ttyX-ignore-cd";
+ char dtr_prop[] = "ttyX-rts-dtr-off";
char *ssp_console_modes_prop = "ssp-console-modes";
int baud, bits, stop, cflag;
char parity;
#<EOF>
On May 27 2007 18:44, Jan Engelhardt wrote:
>On May 26 2007 15:47, David Miller wrote:
>>> I have set the OBP to run at 115200, also set agetty on ttyS0 to do the
>>> same, and also added console=ttyS0,115200 to silo.conf (and also tried
>>> console=ttyS0,115200n8). But! Linux still gives me 9600 8N1. The ominous
>>> double screen blanking (why is that done anyway?) already takes place
>>> with 9600. I smell a bug. What do you think?
>>
>>The code in drivers/serial/suncore.c:sunserial_console_termios()
>>should be parsing your OBP settings, add some tracing and see why it
>>isn't working.
>>
>>Please track the bug down for us, thanks :-)
>
>Just why did no one get a kernel oops? After all, the code tried to
>write to constant memory.
>
>This is the first patch of two. There is yet another section of Linux
>code that runs in 9600-only, and I need to figure out which.
Ok no second patch. The issue (double blanking at boot, which I presumed
also ran at 9600) was recently fixed too.
Jan
--
From: Jan Engelhardt <[email protected]>
Date: Sun, 27 May 2007 18:44:18 +0200 (MEST)
>
> On May 26 2007 15:47, David Miller wrote:
> >> I have set the OBP to run at 115200, also set agetty on ttyS0 to do the
> >> same, and also added console=ttyS0,115200 to silo.conf (and also tried
> >> console=ttyS0,115200n8). But! Linux still gives me 9600 8N1. The ominous
> >> double screen blanking (why is that done anyway?) already takes place
> >> with 9600. I smell a bug. What do you think?
> >
> >The code in drivers/serial/suncore.c:sunserial_console_termios()
> >should be parsing your OBP settings, add some tracing and see why it
> >isn't working.
> >
> >Please track the bug down for us, thanks :-)
>
> Just why did no one get a kernel oops? After all, the code tried to
> write to constant memory.
>
> This is the first patch of two. There is yet another section of Linux
> code that runs in 9600-only, and I need to figure out which.
There should not be an OOPS, we don't map any section of the
kernel as read-only or execute-only or anything like that.
The kernel image is mapped with full read/write/execute permission.
So even writes to so-called 'read-only' sections of the kernel image
will work and therefore I don't understand what the bug could be other
than the compiler "optimizing" away the write to the constant string
in which case the compiler should have warned about it.
From: David Miller <[email protected]>
Date: Sun, 27 May 2007 14:16:22 -0700 (PDT)
> So even writes to so-called 'read-only' sections of the kernel image
> will work and therefore I don't understand what the bug could be other
> than the compiler "optimizing" away the write to the constant string
> in which case the compiler should have warned about it.
I just stared at the drivers/serial/suncore.s assembler a little
bit and this is indeed what appears to be happening, the compiler
is optimizing the stores away completely yet not doing so much
as emitting a warning, how rude :-)
Perhaps there is some warning option that isn't enabled which
would have caught this...
Thanks a lot for your patch, I'll apply it.
On May 27 2007 14:47, David Miller wrote:
>
>> So even writes to so-called 'read-only' sections of the kernel image
>> will work and therefore I don't understand what the bug could be other
>> than the compiler "optimizing" away the write to the constant string
>> in which case the compiler should have warned about it.
>
>I just stared at the drivers/serial/suncore.s assembler a little
>bit and this is indeed what appears to be happening, the compiler
>is optimizing the stores away completely yet not doing so much
>as emitting a warning, how rude :-)
I do not think it can throw a meaningful warning. After all, whether
dereferencing and writing to a char* actually touches
(a) rw memory
(b) ro memory
(c) rw memory which we'd like to be ro ;-)
is not known to the compiler. Of course, one may add more complicated
code to cover simple cases like the one in suncore.c, but that may
as well just gives us more can't-figure-out-correctly-on-my-own warnings
like "possible uninitialized value used" (int n; set_n(&n); use_n(n);) /
where adding more code to cover all detectable cases increases complexity
too much.
Jan
--