Kernel Boot Speedup

Kernel Boot Speedup

Post by Daniel Phillip » Thu, 27 Mar 2003 11:30:11




Quote:> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel Boot Speedup

Post by Henrique Gobb » Fri, 28 Mar 2003 01:00:15


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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel Boot Speedup

Post by Richard B. Johnso » Fri, 28 Mar 2003 01:20:10



> 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,
* 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

Kernel Boot Speedup

Post by Ed Vanc » Fri, 28 Mar 2003 01:40:10



> 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.

Quote:

> 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.

Quote:

> Thanks in advance
> 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-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel Boot Speedup

Post by Henrique Gobb » Fri, 28 Mar 2003 01:40:12


Thanks for the feedback.

Quote:> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel Boot Speedup

Post by Henrique Gobb » Fri, 28 Mar 2003 02:20:09


Hello Ed !
Thanks for the feedback.

Please read my coments (doubts actually) below:

Quote:> > 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 ????   ?

Quote:> > 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel Boot Speedup

Post by Russell Kin » Fri, 28 Mar 2003 02:30:17



> 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.

--

             http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel Boot Speedup

Post by Robert Whit » Fri, 28 Mar 2003 03:10:08


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 ...

read more »

 
 
 

Kernel Boot Speedup

Post by Ed Vanc » Fri, 28 Mar 2003 03:10:07



> 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);

- Show quoted text -

Quote:}

> > > 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.

Quote:

> 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-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel Boot Speedup

Post by Richard B. Johnso » Fri, 28 Mar 2003 03:40:11



> 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,
* 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

Kernel Boot Speedup

Post by Ed Vanc » Fri, 28 Mar 2003 18:50:10




> > 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
----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel Boot Speedup

Post by Ed Vanc » Fri, 28 Mar 2003 19:10:08



> 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
----------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Kernel Boot Speedup

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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. iMac, linuxppc 4.0 Lite, and 2.2.1 kernel

3. SysV IPC loop speedups, kernel 2.4.3

4. Where is the newsgroup app?

5. Speedup SMP kernel on UP box

6. nis ypbind problem

7. diskless boot hit error while booting kernel, cannot find boot device, dhcp problem?

8. web server design

9. Boot hangs at: Ok booting the kernel

10. KERNEL BOOT DISK WON'T BOOT!

11. FreeBSD kernel boot disk cannot boot in ThinkPAD 750C

12. initrd and /boot/vmLinuz: is the /boot kernel used?

13. How to captures all boot messages from kernel and daemons from cold boot?