As one might suspect, when question #6 refers to "the statements in
#1" it in fact means "the statements in #5".
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
I've just posted a patch that adjusts uiomove() so it panics instead
of getting into an infinite loop if the uio structure is initialized
improperly in a particular way (specifically, if uio_resid > iov_len).
The patch is on the downloads page.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
tomorrow's pretty much the last day we'll be accepting t-shirt designs for
voting on thursday.
remember -- full designs are not necessary at this point, just concepts.
submit submit submit! (after all, without any 161 assignment this week,
what else could you possibly be doing? ;)
-a
Your course staff has been doing a lot of thinking. Assignment
three was much more difficult than we intended. We think that
it's pushed people far beyond anything that we wanted. So,
your benevolent staff has decided to:
* Encourage you to submit what you've got if you haven't
already, and get some sleep.
* Delay Assignment 4 by one week.
* Shorten assignment 4 (approximately in half) and make
it due at the same time it was originally intended.
* Let you have fun and go wild on assignment five.
So, we are in the throes of reducing assignment 4 and producing
additional code that we'll now hand out (instead of having you
write). We will try to get this out by the middle of next
week, giving you about a week and a half for what we really
honestly and truly believe will be about a 1-week assignment.
Now, get some rest, work on your other courses, and come to
class next week refreshed.
- Margo
Two more patches for OS/161 have been posted tonight. One fixes some
problems with the MIPS assembly code; the other is another fix to
bitmaps.
The bitmap code was broken in such a way that if the bitmap wasn't an
integer number of bytes, the bitmap_alloc code would ignore the last
few bits.
Some of the assembly code was not following the MIPS calling
conventions quite correctly when calling code written in C. This
has very limited possible effects: (1) crashing with a bus error very
early in boot, before kmain; (2) getting addresses in kseg0 passed to
vm_fault(); or (3) a user-level program clobbering its argv or
argument strings. All of these will only occur if the compiler is
short of registers in the function being called.
[None of the code in the base system or the solution set for asst2 is
affected by #3 or #1. So I don't think anyone's hit those cases, and
hopefully nobody besides the group I helped find the problem has been
hit by #2...]
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
quick question --
a lot of the utility functions given to us (e.g., queue, array, bitmap,
etc.) ungracefully panic() if they run out of memory. this is rather
problematic for the forkbomb() case, because we don't page kernel memory,
and arrays get all angry at us, and poof, there's a panic. yet in the
comments, it says that forkbomb() should grind our system to a halt, but
not panic.
should we alter the utility functions so that they pass NULLs up the
stack, and catch it later on? (the problem, of course, is that there is
no clear feedback mechanism for the functions that auto grow and return
voids, other than to completely change their calling convention.)
-mike
when we run simple user programs, like /bin/false or /bin/true, we end up with
page faults at epc = 0x2000. it should fault there, because all of the
executable actually lives on one page; we're a little confused about why it
doesn't fault sooner, since that seems to indicate that it executes about 4k of
random memory without a hitch. is there any way to get information about
what's going on with the user end of the processor?
(also, could you cc: replies to frichard@fas; i just switched from digest, but
the messages seemed to indicate that i might have to wait till noon for
replies one last time.)
thanks a bunch,
brady
anyone have early numbers on matmult performance? mine runs REALLY slow,
and according to dave holland this is something that should be
completable in 12-13 seconds.
just wondering what results others are getting.
-gwa-
