Re: [Syllable-kernel] Kernel land status..

[Kristian V. D. V. <va...@li...>]

On Tuesday 22 February 2005 20:49, Jake Hamby wrote:
> Here's a quick heads-up on my kernel progress.  Yesterday I integrated
> Arno's patches and now I can boot in SMP mode on my P4.  Whoohoo!  The
> bad news is that I'm still getting random lockups every now and then,
> but that's been happening for a while, SMP or no.

Cool :)  The lockups seemed to be worse with the syncronisation primitives 
removed but it's hard to tell.  Obviously we should be aiming for no know 
lock ups no matter what is currently causing them, though!

> My next check-in will be Arno's patches plus commenting out the
> microsecond timer code and the beginnings of the C99 stuff.  I'm pulling
> in the C99 code one file at a time so that I can figure out which one is
> causing the early crash.  The size of the diffs wasn't as big as I was
> afraid of, so I'll probably check in all the rest of the C99/typesafety
> patches in one step, after I verify that I can rebuild all the drivers
> and filesystems, as well as libsyllable and the appserver and run them
> w/o any problems or crashes.

I'd like to hold off on the C99 changes until after 0.5.6, if possible.  It's 
probably best to avoid too many changes all at once, as it may make life 
difficult for us if we need to track down any remaining SMP or lockup bugs.

To the best of my knowledge the appserver currently doesn't build with Gcc 
3.4.3 by the way, although Henrik may have found & fixed this by now.

> There is still one problem with GCC 3.4.3 which is that it occasionally
> generates code which requires memcpy(), which is only available as an
> inline function in kernel land.  If you don't add "-ffreestanding" then
> it sometimes also requires strcpy().

We should modify Gcc 3.4 so that -kernel implies -ffreestanding

> This didn't affect any of the 
> filesystems and only affected one driver (emu10k1) so I just added a
> "gcc34_memcpy.c" file to that build like I did for the kernel.  But the
> -ffreestanding flag is supposed to prevent this kind of code from being
> generated so I would like to know whether it's a bug in GCC itself or in
> our port specifically.

There is nothing about the Gcc port for Syllable that would affect this.  Our 
port just adds configuration files so Gcc builds correctly, but no source 
files are patched.  I had heard of issues with Gcc 3.4 so perhaps it is a 
bug; it may be worth searching GNATS for Gcc?

> So I am going to start writing some unit tests for the kernel that could
> be optionally compiled to run while the kernel is booting to test the
> various features.  I'm also going to add a kassertp() macro to panic if
> the assertion fails, as kassertw() just gives a warning and continues,
> which may not be a good idea if the assertion failure indicates some
> sort of data structure corruption.

Sounds like an excelent idea to me.  kassertp() is probably long overdue, too.

-- 
Vanders (If this email makes it through..)
http://www.syllable.org
http://www.liqwyd.com