Subject: Strange kernel problems

From: [email-masked] (Niklas Hallqvist)

I've built both a kernel derived from the 940213 sources at sun-lamp
as well as one from 940220.  Both behave well at first, but after some
time, presumably after a certain amount of paging (I still run in 4MB!),
all I can do is to execute bash internal commands.  Every other command
results in "ls: is a directory" type of messages.  I haven't seen anything
on current-users so I suspect it's Amiga-specific (or do all PC NetBSDers
have a reasonable amount of memory?).  Has anoyone tried late versions on
low-mem Amigas?  Typically starting emacs and stopping it (C-z) is enough
to start this behaviour (well, I have never succeeded to do this anyway).
There does not seem to be memory corruption going on, all in-core images
run fine, it's just that I cannot start any new programs.

Another note: as soon as I can get to compile a new kernel, I'll try my
ADOSFS as a LKM, it really seems dead simple!!

BTW those of you who use late sun-lamp code *need* to recompile disklabel
& newfs again as MAXPARTITIONS has changed once more.

Apart from my problems, it's great that we're on sun-lamp now, thanks Chris!

Niklas

---

From: [email-masked] (Chris Hopps)

> run fine, it's just that I cannot start any new programs.

Hmm, I don't know but I am beginning to think that maybe the later
model gcc's (2.5.x) do something more with the kernel when compiled
with -02, try and change that to -O only and see if that clears
anything up.  I run with 2.4.5 all the time now so I can't check.

> ADOSFS as a LKM, it really seems dead simple!!

Yeah I looked at the syscall stuf it seemed to work pretty cleanly.
Really looking forward to ADOSFS. :^) Thanks!

> & newfs again as MAXPARTITIONS has changed once more.

Right, I don't think anyone relized that 32 partitions made the
disklabel struct 660 bytes :^)

> Niklas

Chris.

---

From: [email-masked] (Michael L. Hitch)

> & newfs again as MAXPARTITIONS has changed once more.

  I think programs that rely on knowing the location of the top of the
user stack (USRSTACK) need to be recompiled, also.  Two specific examples
are nfsd and ps.  Nfsd tries to modify the command line arguments and ps
is getting the command line arguements.

Michael

-- 
Michael L. Hitch			INTERNET:  [email-masked]
Computer Consultant			BITNET:  [email-masked]
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA

---

From: [email-masked] (Niklas Hallqvist)

>>>>> "Michael" == Michael L Hitch <[email-masked]> writes:

Michael> On Feb 21, 9:54am, Niklas Hallqvist wrote:
>> I've built both a kernel derived from the 940213 sources at
>> sun-lamp as well as one from 940220.  Both behave well at first,
>> but after some time, presumably after a certain amount of paging (I
>> still run in 4MB!), all I can do is to execute bash internal
>> commands.  Every other command results in "ls: is a directory" type
>> of messages.  I haven't seen anything on current-users so I suspect
>> it's Amiga-specific (or do all PC NetBSDers have a reasonable
>> amount of memory?).  Has anoyone tried late versions on low-mem
>> Amigas?  Typically starting emacs and stopping it (C-z) is enough
>> to start this behaviour (well, I have never succeeded to do this
>> anyway).  There does not seem to be memory corruption going on, all
>> in-core images run fine, it's just that I cannot start any new
>> programs.

Michael>   Try out this fix and see if it helps any.  It has fixed the
Michael> problem I was having with the 940219 kernel.  I finally
Michael> tracked it down when I created a kernel that would give me a
Michael> "init died" panic every time I tried to boot it.  If I varied
Michael> the memory size, I could get it to run with no problem.

I LOVE YOU!

How on earth did you find this one, step by step?  I was really going crazy...
How can I return this favour?  Do you have any pet peeves which you ain't got
time to fix yourself?  Not that I got that much time but I'd like to return
something :-)  I'd almost trade Sweden's olympic hockey gold medal for this :-)

To everyone: Are there any clear evidence that -O2 is bad?  I believe Chris
took it out just in case.  And I wonder: Why didn't the copyinstr bug hit
harder?  It was *really* evil!

OK, now for ADOSFS LKM...  I here people are successfull with the hacker
release.  If just Chris applies the mount.h patch so we can get the MNT_
constant reserved...

Niklas

---

From: [email-masked] (Michael L. Hitch)

> How on earth did you find this one, step by step?  I was really going crazy...

  I first ran into the problem when I was just getting the 5380 driver
code working on my homebuilt SCSI board.  It would panic with "init
died" when trying to start /sbin/init.  I tried to figure out what what
going on, but didn't spend too much time at it.  When I configured all
the SCSI drivers, the problem went away.  Then, when the 940219 kernel
came out, I had problems similar to yours when I tried to run it on an
8M system.  The same kernel ran fine on my other system with 16M, but
failed in the same way if I restricted the memory to 8M.  It would get
lots of errors on files when I tried to start up multi-user mode.  This
last weekend, I updated to the latest sources and was checking to see if
the problem still existed.  I found that 8M (8192K) would run fine, but
when I reduced the memory to 7500K, it started failing.  With 6500K, I
got the "init died" panic - so I figured the two problems were related.

  The final straw came when I generated a kernel that would give me the
panic when booting on a 16M system:  16384K would panic, but 16351K
would run fine.  At that point I decided I had to figure out what the
problem was.  After the panic, I rebooted AmigaDOS and looked at the
kernel stack (my AmigaDOS startup doesn't add the 32 bit memory, so I
can examine all the NetBSD memory from AmigaDOS;  I've even got a little
program that lets me examine the memory using virtual addresses).  From
the stack, it appeared that the execve of /sbin/init was failing, so I
started putting printf statements in the execve routine to determine
what error was occurring.  Once I had narrowed it down to an error
return from copyinstr, I started looking closely at that routine.  It
took me quite a while to figure out why it was returning an "error" code
of 0x0004000.  That turned out to be the maximum length of the string to
copy.  The gas bug that doesn't handle branch instructions properly
resulted in that bogus return value.

> harder?  It was *really* evil!

  I haven't noticed any problems with the kernel using the -O2 option
(this is with the 2.5.6 version of gcc).  Any problems I've had were all
contributed to other bugs in the code.  One bug only showed up with the
-O2 option though.  I originally thought it might be the optimization
that caused the problem, but the real problem was an extraneous
reference to an uninitialized variable.

  The copyinstr bug only hit if the destination address had the low 16
bits of the address zero.  The size of available memory had a
significant impact on when that would occur.  In your case, you had to
run quite a while before it occurred.  I happened to get "lucky" and
have it occur when trying to start init, or when starting multi-user
mode.  I think if gas had assembled the branch instruction correctly, it
would have worked better, although not correctly.  The incorrect code
probably would have failed under certain conditions, depending upon the
maximum length of the copy and upon the actual length of the string.

Michael