Kernel Boot Speedup

Kernel Boot Speedup

[Ro0tSiEgE LKML]

What are some things I can change/disable/etc. to cut down the boot time
of the kernel (i386) ? I would like to get one to boot in a couple
seconds, tops. Is this possible, and how?

Re: Kernel Boot Speedup

[Andy Pfiffer]

On Wed, 2003-03-05 at 16:19, Ro0tSiEgE LKML wrote:
> What are some things I can change/disable/etc. to cut down the boot time
> of the kernel (i386) ? I would like to get one to boot in a couple
> seconds, tops. Is this possible, and how?

To get to that kind of boot-up speed, the best way is to never shutdown.

On a StrongArm platform I worked on, we managed to put the CPU to sleep
and the DRAM controller into self-refresh mode and a few other
housekeeping chores (like checksumming our saved CPU state to be able to
verify it on resumption), and could spring back to life with the press
of a power button in about the same amount of time it took for the
cold-cathode back-light to warm up enough to see the built-in screen.

On a modern laptop, it may be possible, in theory, to accomplish the
same kind of thing.  The key is to be able to not lose the contents of
memory.  I'm not well versed on current state-of-the-art
power-management on commodity x86 platforms, so your mileage may vary.

If you want cold-start boot on a PC, you'll probably need to completely
skip the BIOS (have a look at LinuxBIOS and/or kexec), skip the probing
of devices on reboot, and drastically shorten (or run later) any
user-mode scripts that are invoked.

On the machines that I have measured (p3-800 and p4-1.7Xeon, a
well-configured kernel, after subtracting out BIOS time and stupid scsi
reprobing, is up and open for business in about 10 seconds after the
LILO handoff.  The *system* however, isn't often available for another
30 or 40 seconds, perhaps longer.

Andy

Re: Kernel Boot Speedup

[Adam Sulmicki]

> If you want cold-start boot on a PC, you'll probably need to completely
> skip the BIOS (have a look at LinuxBIOS and/or kexec), skip the probing
> of devices on reboot, and drastically shorten (or run later) any
> user-mode scripts that are invoked.
>
> On the machines that I have measured (p3-800 and p4-1.7Xeon, a
> well-configured kernel, after subtracting out BIOS time and stupid scsi
> reprobing, is up and open for business in about 10 seconds after the
> LILO handoff.  The *system* however, isn't often available for another
> 30 or 40 seconds, perhaps longer.

Also, when you are using LinuxBIOS then time for the hard disk to spin up
actually becomes significant. And it is of order of several seconds (and
up to 30 seconds according to specs for ATA). To counter this problem you
may want to put kernel and root stuff on Compact Flash and then use
CF<->IDE adapter to use CF as primary boot device. (As side benefit it
allows you to easily get around 256KiB limitation of most eerpom (bios)
sockets on your typical motherboard)

-- 
Adam Sulmicki
http://www.eax.com 	The Supreme Headquarters of the 32 bit registers

Re: Kernel Boot Speedup

[Helge Hafting]

Ro0tSiEgE LKML wrote:
> What are some things I can change/disable/etc. to cut down the boot time
> of the kernel (i386) ? I would like to get one to boot in a couple
> seconds, tops. Is this possible, and how?

As a first step, compile the kernel yourself.
Include only drivers for stuff you actually have and use, drop
everything else.  That should give you a kernel that boots in a
few seconds, unless you have some really slow piece of hardware.

Of course the kernel boot time is only part of what we perceive
as "boot time", i.e. time from power-on till you can use the machine.

A normal pc boot goes like this:
1. The bios does its stuff.  No amount of kernel tweaking can help
you with this, because this happens before the kernel is loaded.
You can tweak bios options or get a better bios or motherboard though.
Many bioses are really slow - I'm lucky and have one that gets to the
kernel loading stage so fast that the flat panel screen don't
have time to keep up.  (The bios starts briefly with some graphichs 
mode, then turns to 80x25 text for compatibility reasons.  I don't
get to see that transition unless I pause it at the lilo stage)

2. The bios loads a linux loader, typically lilo.  Lilo then loads the 
kernel of choice. Lilo may be configured with a keypress timeout of 
several seconds - I have shortened that to 0.2 seconds, you may remove 
it entirely. You may also want to configure lilo with the compact 
option, it loads a little faster that way.

3. The kernel boots.  This is what you may shorten by being clever.
Leave out everything you don't need, compile into the kernel
anything needed during boot. (I.e. don't use modules unnecessarily,
they cause extra disk accesses)
You know the kernel boot has started when it print something like
"Linux hh 2.5.63-mm2" or similiar.
The kernel boot has ended when it prints

VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 320k freed

or something like that.  This is usually pretty quick.  The machine
isn't ready for use yet though.

4. Various init scripts run - depending a lot on your distribution.
This typically involves lots of disk access and may be slow.  You can
trim down the init scripts a lot if you know what you're doing - they're
general-purpose but you may have something more specific in mind.

The easy tip is to uninstall anything that have a boot script but
you don't use.  Such as unnecessary servers.  This also makes the
machine safer on a network - less stuff to break into.

You may be able to speed the boot scripts up by creating
some _huge_ initrd containing as much of the boot scripts
and related executables as possible.  This works because an initrd
is loaded by sequential disk accesses while the boot process use
time-consuming seeking.

If all you care about is to login fast, move the script that
enables login earlier in the boot process.  Similiarly, if you
use X, move xdm (or whatever starts X) earlier.
There's no reason to wait for webservers and similar to start
before running X, but thats what distributors usually do,

And if you want to get into X fast - use a lightweight
window manager!  Something like icewm, twm or similiar.
You will particularly want to throw away KDE and gnome.  (This is
is not as drastic as it sounds, because you can run your
kde/gnome apps under plain icewm just fine.)
KDE alone adds 40 seconds or so to my startup time, more
than everything else taken together.  So of course I don't use it.

Unless you have a special machine, most of your startup waiting
will be waiting for the bios, or for disk seeks.
Having 256-512M of RAM helps, because the cache _won't_ run
out during boot.  10000RPM disks helps too.  And you definitely
want more than one drive.  Having /usr and /var on separate
spindles speeds up the boot because the programs loads
from /usr and tends to use data on /var.  Having the root
with /etc on some third spindle is even better, because /etc
is where the programs reads their configuration.
This division will avoid a lot of seeking around as
all your software starts up.

Helge Hafting

Re: Kernel Boot Speedup

[John Bradford]

> 
> Ro0tSiEgE LKML wrote:
> > What are some things I can change/disable/etc. to cut down the boot time
> > of the kernel (i386) ? I would like to get one to boot in a couple
> > seconds, tops. Is this possible, and how?
> 
> As a first step, compile the kernel yourself.
> Include only drivers for stuff you actually have and use, drop
> everything else.  That should give you a kernel that boots in a
> few seconds, unless you have some really slow piece of hardware.
> 
> Of course the kernel boot time is only part of what we perceive
> as "boot time", i.e. time from power-on till you can use the machine.
> 
> A normal pc boot goes like this:
> 1. The bios does its stuff.  No amount of kernel tweaking can help
> you with this, because this happens before the kernel is loaded.
> You can tweak bios options or get a better bios or motherboard though.
> Many bioses are really slow - I'm lucky and have one that gets to the
> kernel loading stage so fast that the flat panel screen don't
> have time to keep up.  (The bios starts briefly with some graphichs 
> mode, then turns to 80x25 text for compatibility reasons.  I don't
> get to see that transition unless I pause it at the lilo stage)
> 
> 2. The bios loads a linux loader, typically lilo.  Lilo then loads the 
> kernel of choice. Lilo may be configured with a keypress timeout of 
> several seconds - I have shortened that to 0.2 seconds, you may remove 
> it entirely. You may also want to configure lilo with the compact 
> option, it loads a little faster that way.
> 
> 3. The kernel boots.  This is what you may shorten by being clever.
> Leave out everything you don't need, compile into the kernel
> anything needed during boot. (I.e. don't use modules unnecessarily,
> they cause extra disk accesses)
> You know the kernel boot has started when it print something like
> "Linux hh 2.5.63-mm2" or similiar.
> The kernel boot has ended when it prints
> 
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 320k freed
> 
> or something like that.  This is usually pretty quick.  The machine
> isn't ready for use yet though.
> 
> 4. Various init scripts run - depending a lot on your distribution.
> This typically involves lots of disk access and may be slow.  You can
> trim down the init scripts a lot if you know what you're doing - they're
> general-purpose but you may have something more specific in mind.

Agreed - you can save a *lot* of boot time like this - my main box
runs just three init scripts, (I use a BSD-style init script layout,
and the main script calls two others).  The main script is 2095 bytes,
and the others are 5144 and 2713 bytes.  Most of that is taken up with
comments.

I've booted a 486, 4Mb laptop in to 2.2.13 in around 30 seconds, (from
power on), by cutting the init scripts down to almost nothing.

> And if you want to get into X fast - use a lightweight
> window manager!  Something like icewm, twm or similiar.

FVWM2 is good, too.

John.

Re: Kernel Boot Speedup

[Daniel Phillips]

On Thu 06 Mar 03 01:19, Ro0tSiEgE LKML wrote:
> What are some things I can change/disable/etc. to cut down the boot time
> of the kernel (i386) ? I would like to get one to boot in a couple
> seconds, tops. Is this possible, and how?

I just noticed this post in an oldish Kernel Traffic.  I got the following 
timing for booting a uml kernel to an IDE root disk:

time ./linux ubd0=/dev/hda6 init=/sbin/halt >/dev/null
real    0m3.146s
user    0m0.310s
sys     0m0.040s

This includes shutdown, and the IDE disk is only 5400 RPM (1 GHz PIII).  UML 
isn't initializing any physical devices, which would account for most of the 
delay on a native kernel.  It doesn't do any decompression either.  On the 
other hand, there are ways to trim the boot time further, e.g., with run-time 
precedence relations to control task start order.  As others have mentioned, 
the limiting factor is likely to be hard disk spin-up time.

To cut down the bios initialization time, use Linux Bios:

   http://www.linuxbios.org/index.html

Claimed fastest boot time is 3 seconds, which sounds like they are talking 
about a full kernel boot as opposed to just bios start.

I suppose a cold start time in the one second range is achievable without 
major hacking of the kernel, using a flash disk, Linux Bios, and minimal 
startup scripts.

Regards,

Daniel

Interpretation of termios flags on a serial driver

[Henrique Gobbi]

Hi,

If this is not the right forum to discuss this matter, excuse me. Please 
point me to the right place.

I'm having some problems understanding three flags on the termios 
struct: PARENB, INPCK, IGNPAR. After reading the termios manual a couple 
of times I'm still not able to understand the different purposes of 
these flags.

What I understood:

1 - PARENB: if this flag is set the serial chip must generate parity 
(odd or even depending on the flag PARODD). If this flag is not set, use 
parity none.

2 - IGNPAR: two cases here:
    	2.1 - PARENB is set: if IGNPAR is set the driver should ignore 			all 
parity and framing errors and send the problematic bytes to 		tty flip 
buffer as normal data. If this flag is not set the 			driver must send the 
problematic data to the tty as problematic 		data.

	2.2 - PARENB is not set: disregard IGNPAR

What I don't understand:

3 - Did I really understand the items 1 and 2 ?

4 - INPCK flag: What's the purpose of this flag. What's the diference in 
relation to IGNPAR;

5 - If the TTY knows the data status (PARITY, FRAMING, OVERRUN, NORMAL), 
why the driver has to deal with the flag IGNPAR. Shouldn't the TTY being 
doing it ?

Thanks in advance
Henrique

Re: Interpretation of termios flags on a serial driver

[Richard B. Johnson]

On Wed, 26 Mar 2003, Henrique Gobbi wrote:

> Hi,
>
> If this is not the right forum to discuss this matter, excuse me. Please
> point me to the right place.
>
> I'm having some problems understanding three flags on the termios
> struct: PARENB, INPCK, IGNPAR. After reading the termios manual a couple
> of times I'm still not able to understand the different purposes of
> these flags.
>
> What I understood:
>
> 1 - PARENB: if this flag is set the serial chip must generate parity
> (odd or even depending on the flag PARODD). If this flag is not set, use
> parity none.
>
> 2 - IGNPAR: two cases here:
>     	2.1 - PARENB is set: if IGNPAR is set the driver should ignore 			all
> parity and framing errors and send the problematic bytes to 		tty flip
> buffer as normal data. If this flag is not set the 			driver must send the
> problematic data to the tty as problematic 		data.
>
> 	2.2 - PARENB is not set: disregard IGNPAR
>
> What I don't understand:
>
> 3 - Did I really understand the items 1 and 2 ?
>
> 4 - INPCK flag: What's the purpose of this flag. What's the diference in
> relation to IGNPAR;
>
> 5 - If the TTY knows the data status (PARITY, FRAMING, OVERRUN, NORMAL),
> why the driver has to deal with the flag IGNPAR. Shouldn't the TTY being
> doing it ?
>
> Thanks in advance
> Henrique
>

Since I've been mucking with serial I/O for many years, I'll
explain what I've descovered.

If PARENB is set you generate parity. It is ODD parity if PARODD
is set, otherwise it's EVEN. There is no provision to generate
"stick parity" even though most UARTS will do that. When you
generate parity, you can also ignore parity on received data if
you want.  This is the IGNPAR flag.

INPCK used to tell the driver to echo the rubout charcter
every time you got a parity error. This would cause the
user to back-space over the rubout character and enter the
errored character again. I don't know if Linux actually does
this. This was the "parity-checking" that you are enabling.
With this enabled, the errored character should go into the
buffer so the user can back-space over it.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: Interpretation of termios flags on a serial driver

[Henrique Gobbi]

Thanks for the feedback.

> If PARENB is set you generate parity. It is ODD parity if PARODD
> is set, otherwise it's EVEN. There is no provision to generate
> "stick parity" even though most UARTS will do that. When you
> generate parity, you can also ignore parity on received data if
> you want.  This is the IGNPAR flag.

Ok. But, considering the 2 states of the flag IGNPAR, what should the 
driver do with the chars that are receiveid with wrong parity, send this 
data to the TTY with the flag TTY_PARITY or just discard this data ?

regards
Henrique

Re: Interpretation of termios flags on a serial driver

[Russell King]

On Wed, Mar 26, 2003 at 03:33:26PM +0000, Henrique Gobbi wrote:
> Thanks for the feedback.
> 
> > If PARENB is set you generate parity. It is ODD parity if PARODD
> > is set, otherwise it's EVEN. There is no provision to generate
> > "stick parity" even though most UARTS will do that. When you
> > generate parity, you can also ignore parity on received data if
> > you want.  This is the IGNPAR flag.
> 
> Ok. But, considering the 2 states of the flag IGNPAR, what should the 
> driver do with the chars that are receiveid with wrong parity, send this 
> data to the TTY with the flag TTY_PARITY or just discard this data ?

We follow POSIX, which says that if IGNPAR is set, bytes with framing
or parity errors (but not break's) are ignored.  If IGNPAR is clear
and INPCK is set, check parity, and flag it via the TTY_PARITY flag.
If INPCK is clear, don't check parity at all.

Note that PARENB enables/disables the generation and reception of
parity.  INPCK controls whether you detect received character parity
errors, and IGNPAR tells you what to do when a character with incorrect
parity is received.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Interpretation of termios flags on a serial driver

[Richard B. Johnson]

On Wed, 26 Mar 2003, Henrique Gobbi wrote:

> Thanks for the feedback.
>
> > If PARENB is set you generate parity. It is ODD parity if PARODD
> > is set, otherwise it's EVEN. There is no provision to generate
> > "stick parity" even though most UARTS will do that. When you
> > generate parity, you can also ignore parity on received data if
> > you want.  This is the IGNPAR flag.
>
> Ok. But, considering the 2 states of the flag IGNPAR, what should the
> driver do with the chars that are receiveid with wrong parity, send this
> data to the TTY with the flag TTY_PARITY or just discard this data ?
>
> regards
> Henrique
>


If the IGNPAR flag is true, you keep the data. You pretend it's
okay. Ignore parity means just that. Ignore it. You do not flag
it in any way. This is essential. If you have a 7-bit link and
somebody is sending you stick-parity, you can still use the data.



Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

RE: Interpretation of termios flags on a serial driver

[Robert White]

Ok, it's been a while... (this goes around the mulberry bush a few times
BTW, I hope you are actually interested... 8-)

First I will seed your mental cache with a few thoughts.

Take a side-trip back to the manual page to appreciate the PARMRK (mark
parity and framing errors or not) and ISTRIP (ASCII is 7-bit unless it is
"Extended ASCII" etc.) bits.  Ah...  How pretty.... 8-)  We'll be back.

Now we must take a moment to appreciate the difference between a framing
error at the character level and at some protocol level.  Ah... pretty
again... 8-)

And a quick side trip back into the days of extremely noisy modem
communications and such.  Individual character errors were really common,
and there were no error correcting modems and such to smooth over the gaps.
/nostalgia... 8-)

RS232 and previous serial communications standards span back into the days
when the electricity sent on the serial line was expected to actually move
real physical devices.  The first teletypes were really "remote print heads"
and the keyboard of one would encode the exact electrical impulses to start
motors and trigger solenoids (sp?).  This is where the "newsroom
clackity-clackity noise" comes from.  /Super-Nostalgia...  8-)

OK.  Now for the meat.

Er... wait... lets do a quick pass at framing a single serial character.
Regardless of any other signals (and the signal ground connection to
complete the circuit so electricity can flow.) there is a single wire
stretching from the transmitter of one device to the receive of another.  In
the idle state the transmitter just asserts a continuous voltage (the "mark
state") on the wire, and everybody is happy.  During a character event, the
transmitter drops that voltage (to the "space state") for "one bit time",
this is the start bit.  Then it sends N bits, with mark being 1 and space
being 0.  The parity bit comes immediately after the character data.  If you
are using "even" parity, and there were an odd number of mark-bits then the
parity bit will be a mark to so that the total number of mark bits was
"even" (guess how "odd" parity works 8-).  Finally there is the stop-bit.
The stop bit is real just the transmitter going back to the mark (voltage
present) state for "at least" so many bit time intervals. (1, 1.5 or 2 bits
worth depending on your stop-bits settings.)  One of the real purposes for
the stop bit was to let the teletype head drop back and prepare for the next
character.

[NOTE: (Part of?) What makes Async communications "asynchronous" is that the
character can start at any time, and is only presaged by that start-bit
transition into the space-state.  This is double-plus good when you are just
putting a keyboard and a print-head together across a large distance.  You
don't need to synchronize the two with any side-band clock information, and
that made the whole thing cheaply possible 60+ years ago...]

So the error and exceptional states are:

Parity Error:  The number of mark-state bit count in the character+parity
bits wasn't "odd" or "even.

Framing Error:  The start or stop bit times weren't long enough or placed
far enough apart.  The most common cause of a framing error is a momentary
electrical disturbance (noise) in the line (acoustic noise on a modem) that
bridges two characters together by not letting the line stabilize into the
mark state.  The second character is thus consumed (kind of... some receive
shift registers will give you the first N bits of an error character, others
will give you the last N bits...  Since this isn't a legal character the
standard is somewhat silent on what might be returned.)

"Break":  PC People are used to thinking about a "break" as being a key
press, and indeed a break used to be generated by a key press just like
everything else.  A "break" at the serial level happens when the transmitter
goes to the space state for something like a character and a half (don't
remember exactly) [via the magic of a limited-latching relay 8-)].  It is a
special case of the framing error that represents a real event, and not an
error per-se.

and finally

"space disconnect" or "long break":  originally generated by holding down
the break key "for a while" the space disconnect would do literally that,
disconnect (surrender) the line, hang up modems, etc.  You'd push and hold
the break key "for a bit" and that was the end of that...

Ok, so we continue...

Inside a serial UART the register that tells you about parity and framing
errors (The Line Status Register [LSR] if I recall correctly) only has a
lifetime of "one read".  If you read that register once you essentially take
"now you know" responsibility for the fact that some zero-or-more previous
characters were bad or was dropped outright.  It is zero or more, not one or
more, because a framing error could be a noise even between characters.  If
it is a noise event happened and there was a full character time after the
noise event ended before a character was actually sent, you would get a
framing or parity error that consumed no actual data characters.  This in
turn infers that the receive shift register didn't actually receive a
character... maybe...

So after an LSR event (which I will, going forward, use in place of "parity
or framing error etc.") your data stream may have zero-or-more additional or
missing characters.  This is particularly ugly if you were doing any kind of
length-encoded protocol.  If your code is blocked waiting for 100
characters, and two of them were munged into one error, and there are not
going to be any more receive events until your code does something, then you
program has just hung because the receive register only shifted out 99
characters.  (if we presume every event did trigger at least some character
to be shifted, the two damaged characters become only one.)  [This soft-hang
would be a protocol-level framing error, PARMRK, when set, by padding in an
extra character, tends to prevent this hang for short disruptions.]

Now, the first thing you will notice about a parity error (if you think
about it) is that it *is* a well-formed character.  That is, it was N-bits
plus a parity bit between a one-bit-wide start-bit space-state and at least
your-stop-bits-wide mark-state trailer.

So a parity error still represents a "reasonably good" character.  That
means that for quick and dirty work, or for suspect equipment, or for "who
knows who is going to call me" circumstances on a text line, it becomes
convenient to configure the device as: Seven data bits, whatever parity,
ignore parity.  (or eight data bits, no parity, strip off high bit using
ISTRIP).  Such a configuration will let you (at say 9600 baud) usefully
communicate with a typing human who configured their terminal in any of the
following ways:

9600-8-N-1
9600-7-E-1 (even parity)
9600-7-O-1 (odd parity)
9600-7-M-1 (mark parity)
9600-7-S-1 (space parity)

You see, as long as there are ten-bits in the frame (1 start, 1 stop, and
either 8 data with no parity, or 7 data with any kind of parity) you will be
able to (by stripping off and ignoring that high bit, or sacrificing it to
the parity detect machinery) communicate in ASCII text while only
considering the textual parts.

In the world of auto-bauding (c.f. getty's "keep pressing enter until you
can read the login prompt" interactive behavior that let you call a
multi-speed modem with any other modem) collapsing five different possible
parity setting per-baud-rate into the one was a SUPER WIN.

Now, if we toss out the framing errors too, then a good number of UARTs will
even let you get away with "9600-7-N-1".  yech...  The REAL(tm) programmatic
reason this setting does both was probably that all this stuff just comes in
on the LSR so you can, if you "turn off" LSR interrupt service, kind of get
"ignore parity" for free.  In pseudo code: "if (termios.setting & IGNPAR)
interrupt_mask |= Disable_LSR_bit;"

So think about it:

PARENB Adds a bit to the character frame.  8-N-1 is one bit wider than
7-N-1, but is the same width as 7-E-1.  This is the job of that bit.  It has
to be there, or not, to make the whole frame the correct length regardless
of whether you actually need to check parity.

IGNPAR Says "don't treat a parity error as any kind of error, I don't care."
The fact that it tosses out framing errors is "something of a bug" as it
kind of threw the baby out with the bath water.

If you don't have parity enabled at all, that bit never happens
electrically, so we can "regain" the framing error check if IGNPAR is itself
ignored if PARENB (parity) is not enabled.

INPCK comes along later to retrieve the metaphorical baby.  The standard
already has INPAR but the guy using it wants to have his parity enabled (so
his transmit/receive frame is the right size) he wants to receive and
process Framing Errors, but he still wants to be able to fold 8-N-1 into the
set-of-five (e.g. 7-(E|O|M|S)-1) for his interactive behaviors.   INPCK
leaves the interrupt serviced but it *DOES* *NOT* do the PARMRK stuff.

Oh look, PARMRK showed up again...

Recall ASCII is Seven Bit.  Also recall that in the case of an LSR error you
don't know what you might get in the receive holding register (e.g. exactly
what gets out of the receive shift register to be seen by the public).

That ISN'T _exactly_ true.  See, the more variables you try to put into the
silicon, the more complex (read "expensive" and "hot") the silicon has to
become.  Its easiest to make the silicon deterministic.  So most UART chips
give you the "last" bits (4, 5, 6, 7, or 8) received as part of the
character part of the frame.  This can be expressed by a "see a bit-shift a
bit" logic that is great for hardware design.  So if you *don't* have a
framing error, then you *do* have the right number of bits to make a
character.  If you do a parity bit and seven data bits you will have a seven
bit character (high bit off), if you do an 8-data-bit frame, the high order
bit is the parity bit (which you can discard automatically with ISTRIP) so
it is a win either way.

But pesky PARMRK is hunting us.  PARMRK gives you two alternatives.  An
erroneous character *WILL* be a 0x00.  If PARMRK is set, there will be a
0xFF put in front of that 0x00.  This makes sense as a "bad things happened
here" marker in the data stream because there was no way to send any
character larger than an 0x7F  back when seven-data-plus-parity was king.
And regardless, there was originally no control key sequence to send a 0x00.
This meant that you could have the driver whisper (just the 0x00) or shout
(0xFF + 0x00) that something went wrong.

I can't guarantee that this is exactly how the current serial driver code is
implemented, but I can guarantee that this is (what) the practical effect
(should be 8-):

INPCK, when clear, means don't do either of the PARMRK alternatives, just
return the received "bad parity" character *for parity errors* but leaves it
intact for framing errors.

IGNPAR turns off the parity and framing error detect mechanism completely
(probably at the ISR level).


Of course, this is from memory, and if I am wrong I am sure we will be
hearing about it presently... 8-)

Rob.



-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Henrique Gobbi
Sent: Wednesday, March 26, 2003 6:51 AM
To: linux-kernel@vger.kernel.org
Subject: Interpretation of termios flags on a serial driver


Hi,

If this is not the right forum to discuss this matter, excuse me. Please
point me to the right place.

I'm having some problems understanding three flags on the termios
struct: PARENB, INPCK, IGNPAR. After reading the termios manual a couple
of times I'm still not able to understand the different purposes of
these flags.

What I understood:

1 - PARENB: if this flag is set the serial chip must generate parity
(odd or even depending on the flag PARODD). If this flag is not set, use
parity none.

2 - IGNPAR: two cases here:
    	2.1 - PARENB is set: if IGNPAR is set the driver should ignore 			all
parity and framing errors and send the problematic bytes to 		tty flip
buffer as normal data. If this flag is not set the 			driver must send the
problematic data to the tty as problematic 		data.

	2.2 - PARENB is not set: disregard IGNPAR

What I don't understand:

3 - Did I really understand the items 1 and 2 ?

4 - INPCK flag: What's the purpose of this flag. What's the diference in
relation to IGNPAR;

5 - If the TTY knows the data status (PARITY, FRAMING, OVERRUN, NORMAL),
why the driver has to deal with the flag IGNPAR. Shouldn't the TTY being
doing it ?

Thanks in advance
Henrique

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@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: Interpretation of termios flags on a serial driver

[Ed Vance]

On Wed, Mar 26, 2003 at 6:51 AM, Henrique Gobbi wrote:
> 
> I'm having some problems understanding three flags on the termios 
> struct: PARENB, INPCK, IGNPAR. After reading the termios 
> manual a couple 
> of times I'm still not able to understand the different purposes of 
> these flags.
> 
> What I understood:
> 
> 1 - PARENB: if this flag is set the serial chip must generate parity 
> (odd or even depending on the flag PARODD). If this flag is 
> not set, use 
> parity none.
> 
> 2 - IGNPAR: two cases here:
>     	2.1 - PARENB is set: if IGNPAR is set the driver should 
> ignore 			all 
> parity and framing errors and send the problematic bytes to 	
> 	tty flip 
> buffer as normal data. If this flag is not set the 		
> 	driver must send the 
> problematic data to the tty as problematic 		data.
> 
> 	2.2 - PARENB is not set: disregard IGNPAR
> 
> What I don't understand:
> 
> 3 - Did I really understand the items 1 and 2 ?
> 
> 4 - INPCK flag: What's the purpose of this flag. What's the 
> diference in 
> relation to IGNPAR;

     If INPCK is set, input parity checking  is  enabled.      If
     INPCK is  not  set, input parity checking is disabled.  This
     allows output parity generation without input parity errors.
     Note  that  whether input parity checking is enabled or dis-
     abled is independent of whether parity detection is  enabled
     or disabled. If parity detection is enabled but input parity
     checking is disabled, the hardware to which the terminal  is
     connected  will  recognize  the parity bit, but the terminal
     special file will not check whether this is set correctly or
     not.

     If IGNPAR is set, a  byte  with  framing  or  parity  errors
     (other than break) is ignored. This means that the data byte
     with the error is thrown away  by the  driver as if the byte
     had never been received. 

In short,
If INPCK is _not_ set, then all received data bytes will be delivered 
to the user level, regardless of parity errors.
If IGNPAR is set, then only received data bytes that do not have 
parity errors will be delivered to the user level.
If PARENB is _not_ set, then the receiver hardware will not detect 
bad parity, so all received data bytes are considered free of errors. 
Since there are no data bytes with associated error indications, 
setting IGNPAR would have no effect. All of the data are considered 
error free.

> 
> 5 - If the TTY knows the data status (PARITY, FRAMING, 
> OVERRUN, NORMAL), 
> why the driver has to deal with the flag IGNPAR. Shouldn't 
> the TTY being 
> doing it ?

Not sure I understand the question. Received data does not carry any
information about errors with it after it leaves the driver, unless 
PARMRK is set. 
> 
> Thanks in advance
> Henrique

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

RE: Interpretation of termios flags on a serial driver

[Henrique Gobbi]

Hello Ed !
Thanks for the feedback. 

Please read my coments (doubts actually) below:

> > 4 - INPCK flag: What's the purpose of this flag. What's the 
> > diference in 
> > relation to IGNPAR;
>      If INPCK is set, input parity checking  is  enabled.      If
>      INPCK is  not  set, input parity checking is disabled.  This
>      allows output parity generation without input parity errors.
>      Note  that  whether input parity checking is enabled or dis-
>      abled is independent of whether parity detection is  enabled
>      or disabled. If parity detection is enabled but input parity
>      checking is disabled, the hardware to which the terminal  is
>      connected  will  recognize  the parity bit, but the terminal
>      special file will not check whether this is set correctly or
>      not.
> 
>      If IGNPAR is set, a  byte  with  framing  or  parity  errors
>      (other than break) is ignored. This means that the data byte
>      with the error is thrown away  by the  driver as if the byte
>      had never been received. 
> 
> In short,
> If INPCK is _not_ set, then all received data bytes will be delivered 
> to the user level, regardless of parity errors.
> If IGNPAR is set, then only received data bytes that do not have 
> parity errors will be delivered to the user level.
> If PARENB is _not_ set, then the receiver hardware will not detect 
> bad parity, so all received data bytes are considered free of errors. 
> Since there are no data bytes with associated error indications, 
> setting IGNPAR would have no effect. All of the data are considered 
> error free.

Your explanation makes sense to me. With this information I built the
table:
   IGNPAR    INPCK         ACTION:
     0         0           Deliver all data to the user-level
     0         1           Check parity. Discard erroneous bytes
     1         0           ????
     1         1           Check parity. Discard erroneous bytes 

What goes on ????   ?

> > 5 - If the TTY knows the data status (PARITY, FRAMING, 
> > OVERRUN, NORMAL), 
> > why the driver has to deal with the flag IGNPAR. Shouldn't 
> > the TTY being 
> > doing it ?
> 
> Not sure I understand the question. Received data does not carry any
> information about errors with it after it leaves the driver, unless 
> PARMRK is set. 

When the driver copy the data from the controler to the flip buffer it
copies the data to the buffer tty->flip.char_buf_ptr and it set a flag
(TTY_NORMAL, TTY_PARITY, TTY_FRAME, etc) on the buffer
tty->flip.flag_buf_ptr telling the TTY how this byte was received. So
the TTY knows if certain byte was problematic or not. Did you understand
my doubt know ?

Thanks for your patience
Henrique

RE: Interpretation of termios flags on a serial driver

[Ed Vance]

On Wed, Mar 26, 2003 at 4:17 PM, Henrique Gobbi wrote:
> 
> Hello Ed !
> Thanks for the feedback. 
> 
> Please read my coments (doubts actually) below:
> 
> > > 4 - INPCK flag: What's the purpose of this flag. What's the 
> > > diference in 
> > > relation to IGNPAR;
> >      If INPCK is set, input parity checking  is  enabled.      If
> >      INPCK is  not  set, input parity checking is disabled.  This
> >      allows output parity generation without input parity errors.
> >      Note  that  whether input parity checking is enabled or dis-
> >      abled is independent of whether parity detection is  enabled
> >      or disabled. If parity detection is enabled but input parity
> >      checking is disabled, the hardware to which the terminal  is
> >      connected  will  recognize  the parity bit, but the terminal
> >      special file will not check whether this is set correctly or
> >      not.
> > 
> >      If IGNPAR is set, a  byte  with  framing  or  parity  errors
> >      (other than break) is ignored. This means that the data byte
> >      with the error is thrown away  by the  driver as if the byte
> >      had never been received. 
> > 
> > In short,
> > If INPCK is _not_ set, then all received data bytes will be 
> delivered 
> > to the user level, regardless of parity errors.
> > If IGNPAR is set, then only received data bytes that do not have 
> > parity errors will be delivered to the user level.
> > If PARENB is _not_ set, then the receiver hardware will not detect 
> > bad parity, so all received data bytes are considered free 
> of errors. 
> > Since there are no data bytes with associated error indications, 
> > setting IGNPAR would have no effect. All of the data are considered 
> > error free.
> 
> Your explanation makes sense to me. With this information I built the
> table:
>    IGNPAR    INPCK         ACTION:
>      0         0           Deliver all data to the user-level
>      0         1           Check parity. Discard erroneous bytes
>      1         0           ????
>      1         1           Check parity. Discard erroneous bytes 
> 
> What goes on ????   ?

   IGNPAR    INPCK         ACTION:
     0         0           Deliver all data to the user-level, as is.
     0         1           Deliver nulls in place of erroneous bytes
     1         0           Discard erroneous bytes, deliver the rest
     1         1           Discard erroneous bytes, deliver the rest 

IGNPAR gets processed before INPCK: 
(from drivers/char/n_tty.c:488)

static inline void n_tty_receive_parity_error(struct tty_struct *tty,
                                              unsigned char c)
{
        if (I_IGNPAR(tty)) {
                return;          /* discard data */
        }
        if (I_PARMRK(tty)) {
                put_tty_queue('\377', tty);
                put_tty_queue('\0', tty);
                put_tty_queue(c, tty);
        } else  if (I_INPCK(tty))
                put_tty_queue('\0', tty);     /* deliver null */
        else
                put_tty_queue(c, tty);        /* deliver data */
        wake_up_interruptible(&tty->read_wait);
}

> 
> > > 5 - If the TTY knows the data status (PARITY, FRAMING, 
> > > OVERRUN, NORMAL), 
> > > why the driver has to deal with the flag IGNPAR. Shouldn't 
> > > the TTY being 
> > > doing it ?
> > 
> > Not sure I understand the question. Received data does not carry any
> > information about errors with it after it leaves the driver, unless 
> > PARMRK is set. 
> 
> When the driver copy the data from the controler to the flip buffer it
> copies the data to the buffer tty->flip.char_buf_ptr and it set a flag
> (TTY_NORMAL, TTY_PARITY, TTY_FRAME, etc) on the buffer
> tty->flip.flag_buf_ptr telling the TTY how this byte was received. So
> the TTY knows if certain byte was problematic or not. Did you 
> understand my doubt know ?

Yes. I call that part a "line discipline". n_tty is the TTY line 
discipline that implements termio(s) and some legacy functionality.

And yes, for received data with parity errors, the line discipline 
handles IGNPAR, as well INPCK and PARMRK. See snippet of n_tty.c above. 

> 
> Thanks for your patience
> Henrique
> 

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

Re: Interpretation of termios flags on a serial driver

[David Lawyer]

On Wed, Mar 26, 2003 at 04:59:11PM -0800, Ed Vance wrote:
> On Wed, Mar 26, 2003 at 4:17 PM, Henrique Gobbi wrote:
> > 
> > Hello Ed !
> > Thanks for the feedback. 
> > 
> > Please read my comments (doubts actually) below:
> > 
> > > > 4 - INPCK flag: What's the purpose of this flag. What's the 
> > > > difference in relation to IGNPAR;
[snip]
> > 

>From the code snippet, it seems that INPCK only determines how to "mark"
a parity error (when PARENB is set and IGNPAR is unset) and can be
overridden by PARMRK (prefixes the bad char. with \377\0).  INPCK has
no effect unless IGNPAR and PARMRK are both unset.  If they are both
unset then: INPCK set results in the bad character being replaced by \0,
while if INPCK is unset, then the bad character (less the parity bit) is
passed thru.  I've use "mark" in a broad sense, since in one case it's
not marked at all and in the other case it's marked by deleting it and
substituting a \0.

The man page for termios needs revision to make this clear.  One can't
just say that INPCK "enables parity checking"; it's a lot more involved.

> 
>    IGNPAR    INPCK         ACTION:
>      0         0           Deliver all data to the user-level, as is.
>      0         1           Deliver nulls in place of erroneous bytes
>      1         0           Discard erroneous bytes, deliver the rest
>      1         1           Discard erroneous bytes, deliver the rest 
> 
> IGNPAR gets processed before INPCK: 
> (from drivers/char/n_tty.c:488)
> 
> static inline void n_tty_receive_parity_error(struct tty_struct *tty,
>                                               unsigned char c)
> {
>         if (I_IGNPAR(tty)) {
>                 return;          /* discard data */
>         }
>         if (I_PARMRK(tty)) {
>                 put_tty_queue('\377', tty);
>                 put_tty_queue('\0', tty);
>                 put_tty_queue(c, tty);
>         } else  if (I_INPCK(tty))
>                 put_tty_queue('\0', tty);     /* deliver null */
>         else
>                 put_tty_queue(c, tty);        /* deliver data */
>         wake_up_interruptible(&tty->read_wait);
> }
> 
> > 
> > > > 5 - If the TTY knows the data status (PARITY, FRAMING, 
> > > > OVERRUN, NORMAL), 
> > > > why the driver has to deal with the flag IGNPAR. Shouldn't 
> > > > the TTY being 
> > > > doing it ?
> > > 
> > > Not sure I understand the question. Received data does not carry any
> > > information about errors with it after it leaves the driver, unless 
> > > PARMRK is set. 
> > 
> > When the driver copy the data from the controller to the flip buffer it
> > copies the data to the buffer tty->flip.char_buf_ptr and it set a flag
> > (TTY_NORMAL, TTY_PARITY, TTY_FRAME, etc) on the buffer
> > tty->flip.flag_buf_ptr telling the TTY how this byte was received. So
> > the TTY knows if certain byte was problematic or not. Did you 
> > understand my doubt know ?
> 
> Yes. I call that part a "line discipline". n_tty is the TTY line 
> discipline that implements termio(s) and some legacy functionality.
> 
> And yes, for received data with parity errors, the line discipline 
> handles IGNPAR, as well INPCK and PARMRK. See snippet of n_tty.c above. 
> 
> > 
> > Thanks for your patience
> > Henrique
> > 
> 
> Cheers,
> Ed
> 
> ---------------------------------------------------------------- 
> Ed Vance              edv (at) macrolink (dot) com
> Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
> ----------------------------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
			David Lawyer

RE: Interpretation of termios flags on a serial driver

[Ed Vance]

On Wed, Mar 26, 2003 at 5:41 PM, Richard B. Johnson wrote:
> 
> On Wed, 26 Mar 2003, Henrique Gobbi wrote:
> 
> > Thanks for the feedback.
> >
> > > If PARENB is set you generate parity. It is ODD parity if PARODD
> > > is set, otherwise it's EVEN. There is no provision to generate
> > > "stick parity" even though most UARTS will do that. When you
> > > generate parity, you can also ignore parity on received data if
> > > you want.  This is the IGNPAR flag.
> >
> > Ok. But, considering the 2 states of the flag IGNPAR, what 
> should the
> > driver do with the chars that are receiveid with wrong 
> parity, send this
> > data to the TTY with the flag TTY_PARITY or just discard this data ?
> >
> > regards
> > Henrique
> >
> 
> 
> If the IGNPAR flag is true, you keep the data. You pretend it's
> okay. Ignore parity means just that. Ignore it. You do not flag
> it in any way. This is essential. If you have a 7-bit link and
> somebody is sending you stick-parity, you can still use the data.
> 
Hi Richard,

Right idea, wrong flag.  ;-)

IGNPAR = 1  discard received data with parity errors. (ignore data)
INPCK = 0   deliver data with parity errors, as is.   (ignore error)

See 2.4/drivers/char/n_tty.c:~500

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

RE: Interpretation of termios flags on a serial driver

[Ed Vance]

On Wed, Mar 26, 2003 at 7:33 AM, Henrique Gobbi wrote:
> 
> Thanks for the feedback.
> 
> > If PARENB is set you generate parity. It is ODD parity if PARODD
> > is set, otherwise it's EVEN. There is no provision to generate
> > "stick parity" even though most UARTS will do that. When you
> > generate parity, you can also ignore parity on received data if
> > you want.  This is the IGNPAR flag.
> 
> Ok. But, considering the 2 states of the flag IGNPAR, what should the 
> driver do with the chars that are receiveid with wrong 
> parity, send this 
> data to the TTY with the flag TTY_PARITY or just discard this data ?
> 
Hi Henrique,

The driver should send all characters with parity errors to the line
discipline marked with TTY_PARITY. The driver is supposed to handle the
hardware. The line discipline is supposed to handle any higher level
protocol. Ideally, the driver should not know or care about the state of
flags like IGNPAR, that are not needed to configure the hardware. 

Two common exceptions are:

1. "smart" UART hardware that directly handles some of the higher level
protocol, so the driver needs to know the higher level settings so it can
configure the hardware properly.

2. defensive actions to avoid bogging down the whole system with interrupt
storms from noisy or unconnected modem status inputs, where the driver could
mask off interrupts on modem status when the higher level options dictate
that all such status will be ignored.

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------