Serial (LOM) displays invalid characters when init kicks in

linux4ever · n00b Joined: 05 Dec 2005 Posts: 32

Hello everyone,

Since a few days I'm the proud owner of my first sparc system, however I have serious trouble getting everything up.

Atm, I can boot, but the LOM console more a less fails after init kicks in (all characters are invalid, however the amount of chars sent is still ok). At a certain moment during boot (just before net.lo is started) the console is normal again, but I can't log in (I'm unable to send characters to the console. However it's not a hardware problem since the LOM escape sequence still works).

I have set up sshd, so it's not a real problem, however it renders the whole LOM thing pretty useless, which might prove a problem when anything critical happens to the system.

Is this a bug in the kernel, baselayout or just some configuration option I've set wrong?

Would really appreciate if someone could help.

Some relevant data is following.

This is the log of the system startup:

Malvineous · Posted: Sat Feb 21, 2009 12:51 pm Post subject:

Given the s0/s1 respawning too fast error, that must mean that the serial ports are disabled/inaccessible. Not being familiar with SPARC or LOM, how are you getting the boot messages off the box? If it's over a serial port, are you explicitly sending data over the serial port, or are you sending data to the "console" and the machine is routing the console over the serial port? It could be that the console routing is conflicting with direct serial port access, causing some of these strange issues.

linux4ever · n00b Joined: 05 Dec 2005 Posts: 32

Point is, I'm not familiar with SPARC and LOM either.

What I understand is that the LOM routes the normal console to a special serial port, however I'm not sure if this is the case.

What I figured:

C1 -> LOM (Serial port #1)
ttyS0 -> Serial port #2
ttyS1 -X

Which means I should disable the second serial port in my inittab.

However this doesn't explain in any way why my serial console is not working

Do people think I should report this on bugzilla?

Malvineous · Posted: Sun Feb 22, 2009 4:59 am Post subject:

I don't think you should report it on Bugzilla until you're 100% sure what the problem is. Most of the time things like this are configuration issues, not bugs.

If you disable both consoles on s0 and s1, does that change anything?

linux4ever · n00b Joined: 05 Dec 2005 Posts: 32

When I disable s0 and s1 the

Malvineous · Posted: Sun Feb 22, 2009 11:31 am Post subject:

Well given that you're running a getty on c1 but it's not appearing, the console isn't c1.

I've just noticed something though:

linux4ever · n00b Joined: 05 Dec 2005 Posts: 32

I'm not saying I know something, but this is what I think:

1. The system console (where the kernel outputs it's data to) is tty0, the console that is reachable using alt-ctl-f1 (on a normal PC) is tty1

2. The console is appearing:

Malvineous · Posted: Sun Feb 22, 2009 11:53 am Post subject:

Well as far as I'm aware, on a normal PC the physical screen is tty0, and then tty1 is the first virtual console. When you press Alt+Ctrl+F2 it displays tty2 on tty0. If you echo a message to tty1 you won't see it until you press Alt+Ctrl+F1, but if you echo it to tty0 you'll see it regardless of which terminal you're on.

Since you're running over a serial connection I don't think the whole virtual terminals thing will work, so you might find you only have tty0.

If you can log in to the box, "echo hello0 > /dev/tty0; echo hello1 > /dev/tty1; echo helloS0 > /dev/ttyS0" will probably answer a few questions.

linux4ever · n00b Joined: 05 Dec 2005 Posts: 32

Ok, Both hello0 as hello1 are displayed at the LOM console (and HelloS0 not).

Also when I configure a console on tty0 it shows up, but is still unusable (doesn't accept any input).

So the tty1 -> tty0 mapping seems to work as usual.

This looks to me like a kernel or rc/init issue (not saying it has to be a bug).
BTW, could it be possible that the line doesn't accept input because some kind of control character is sent during the '????????' phase?
Also is it possible with portage 2.1 to set up rc logging?

Anyway, I really appreciate your help Malvineous.

Malvineous · Posted: Sun Feb 22, 2009 1:42 pm Post subject:

No worries. Actually I recall having a similar issue with a virtual machine, I was trying to get a console appearing somewhere, and all I got was text output, but I couldn't type anything in. Unfortunately I don't recall what the issue was :-(

(but I don't think it has anything to do with control characters.)

If the tty1 mapping works then one would think your configuration should be fine. What happens if you disable all the getties *except* the one on tty1? (Just in case it's defaulting to one of the others.) Presumably then "ps aux | grep getty" should show only one instance sitting on tty1. If you kill it, when it respawns do you see anything on the console?

You don't need to manually specify console=something on the command line? Probably not, otherwise you wouldn't see the boot messages. Hmm, tricky...

linux4ever · n00b Joined: 05 Dec 2005 Posts: 32

Ok, it's indeed tty1 we are looking at. (disabled everything else)

When I kill it, nothing really happens, it just respawns:

Kethreveris · n00b Joined: 16 Feb 2009 Posts: 20 Location: Rethwallen

I do know Sun SPARC hardware, and here roughly how (A/E/I)LOM works;

- LOM is an intelligent, always on, (if A.C. is on), supervisor device.
- LOM has an external serial port that the SysAdmin can use as the console, as well as talk to LOM.
- LOM has an internal serial port that the SPARC processor can use as the console.
- Most recent LOMs have a network port that basically is a single port terminal server. (But not the V100 as I recall)
- Most Sun servers also have a plain serial port, (aka TTY-B), that you can use as the console if desired.

You have to be careful with LOM. Simply grabbing the console from LOM using the
"console" command, may get you a warning similar to this;

lom> console
Console in use, proceeding with read/only access
Use #. to return to LOM

So, if that happens, return to LOM and use "console -f" to force your access to be R/W.

Another suggestion is the try using the plain TTY-B port for your console. But, have both wired
and monitoring. The firmware, (OpenBoot), will still use TTY-A unless you purposefully change it to TTY-B.

P.S. The (A/E/I)LOM) works out to;
- Lights Out Manager, (without network port)
- ALOM, Advanced LOM, (generally with network port and a little more functions)
- ELOM, Embedded LOM, (built into system board, used mostly with x86/x64, runs Linux :-)

- ILOM, Integrated LOM, (plug in card to the system board, used mostly with x86/x64, runs Linux :-)

Sun has more varieties, but not relevant to this topic.
_________________
Kethreveris, (aka Kethrery)

Kethreveris · n00b Joined: 16 Feb 2009 Posts: 20 Location: Rethwallen

Now that I have the hopefully helpful comments posted, my turn.

I have the exact problem with garbage printed during boot. My config
is an x86 box though, (fit-PC). Here is the relevant sequence;

...
input: Sleep Button (CM) as /class/input/input2
ACPI: Sleep Button (CM) [SLPB]
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
��
...
��
INIT: version 2.86 booting

Gentoo Linux; http://www.gentoo.org/
...

Seems like when my serial chip is initialized, it changes the bit rate
on me. I have grub, kernel line and inittab set to 38,400bps.

Where is the default bit rate set for the driver?
Is that in the source code?

Under Solaris SPARC, (and possibly Solaris x86/x64), you would set that
in "/kernel/drv/DEVICE.conf". (With "DEVICE" replaced by the device driver name,
like "zs", which was the Zilog serial chip used in earlier Sun SPARC hardware.)
So when the device driver module loads, it loads it's configuration file and would
keep any bit rate I programmed.

If I have to change the bit rate, that's fine. But what do I change it to?
I thought 38,400bps was Linux's default bit rate.
_________________
Kethreveris, (aka Kethrery)

Kethreveris · n00b Joined: 16 Feb 2009 Posts: 20 Location: Rethwallen

Simple testing by changing the bit rate did not find
Linux's default bit rate. Here is the list I tried.

9600
19,200
38,400
57,600
115,200
230,400 (Grub entries did not take effect, but Inittab did work)

Did not try any others.
_________________
Kethreveris, (aka Kethrery)

Malvineous · Posted: Sun Mar 08, 2009 11:09 am Post subject:

You might have to check how the kernel does console-over-serial on PC hardware, because that would have the same issue (and I've never seen garbage before) - the kernel outputs messages over the serial port *before* the hardware is initialised, and initialising it in the middle of the boot sequence doesn't produce garbage.

Maybe if you disable the kernel serial driver it won't try to reset the chip mid-boot, and will continue to use the internal console-over-serial code?