Re: Query about cons server in SMP

Warren Toomey <wkt@tuhs.org> writes:

>Andy, status report. We are back on deck after our summer break. We were
>seeing cons continually page fault at startup time. It turns out to be
>the bcopy() in new_client() around line 92 of cons/main.c. Either one or
>both of perms and f->f_perms are 0.

Interesting. f_perms comes in from the kernel via the client connect
message M_CONNECT (in the m_buf portion).

>perms= m->m_buf, but m comes in as a parameter. On line 428 in
>screen_main, m_buf is initialised, but only if "we've received more than
>a single buffer of data". So it is possible that m_buf is never initialised.

m_buf should be an alias for the first message segment (see sys/msg.h).
So the only reason to overwrite this in this code path is when you assemble
multiple segments into one, and then overwrite m_buf to make it look
like a single message segment. Otherwise if m_nseg is 0 then you have
no segments at all, or m_nseg came in as 1 and m_buf is an alias for
the first (and only) message buffer.

>Going back to f_perms, I can't see where it is even initialised! So
>right now, I've changed the bcopy() operation to say:

How about new_client() in the bcopy()? I'm suspicious about what
the M_CONNECT message looks like.

>With the change, we ca now login and do a few things before the system
>crashes; sometimes we can get the kernel to link :-)

Congrats. :->

>If you could comment back on m_buf and f_perms that would be good. I'd
>be keen to know if cons must always receive more than a single buffer of
>data.

My memory is that only fancy clients will be queueing true scatter/gather
I/O to the console. Basic stuff like getting clients connected shouldn't
involve anything other than single message buffers. I quickly scanned
the kernel source and didn't see any such thing, so that sort of confirms
my memory.

Andy
Received on 19 Feb 2004 19:45:53 GMT