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-
A bug has been found in lhd.c - it seems that the lhd raw device does
not handle I/Os that are more than one sector long correctly. Thanks
to Jeff DeSoto for catching this.
Patch follows.
Index: src/kern/dev/lamebus/lhd.c
===================================================================
RCS file: /disk/disk0/cs161/CVSREPO/os161/src/kern/dev/lamebus/lhd.c,v
retrieving revision 1.4
diff -u -r1.4 lhd.c
--- lhd.c 2001/02/02 10:16:36 1.4
+++ lhd.c 2001/03/23 20:12:42
@@ -186,7 +186,7 @@
}
/* Don't allow I/O past the end of the disk. */
- if (sector >= lh->lh_dev.d_blocks) {
+ if (sector+len >= lh->lh_dev.d_blocks) {
return EINVAL;
}
@@ -213,7 +213,7 @@
}
/* Tell it what sector we want... */
- lhd_wreg(lh, LHD_REG_SECT, sector);
+ lhd_wreg(lh, LHD_REG_SECT, sector+i);
/* and start the operation. */
lhd_wreg(lh, LHD_REG_STAT, statval);
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Hi all,
We are getting a pretty unusual panic during bootstrap:
panic: Fatal exception 2 in kernel mode
panic: EPC 0x80006ca0, exception vaddr 0x4
panic: I can't handle this... I think I'll just die now...
This happens after the lamebus configuration when the console gets
attached to the file system. I've traced the code well into the
nitty-gritty FS subsystems, and have given up on finding the exact line of
code it fails on. Unfortunately, tracing it this deep tells us nothing,
as none of that code is ours.
Oddly, we saw very similar random problems (failure deep within the
filesystem stuff) while doing asst2, and by just changing schedulers (!)
we got things up and running OK (that doesn't work this time).
Can anyone shed light on some probably cause for this kind of issue, or
has anyone seen anything like it before? Am I missing something
obvious? Any and all suggestions appreciated! Thanks.
Regards from the scenic SC basement,
Ben
I know this is a pretty silly question, but I've forgotten what I tagged
the original version of the code so I can't do a diff against it. How do
I view a list of tags? Or, if I was forgetful and forgot to tag, how
should i make a diff?
Thanks,
Bryan
----- -- ---
Bryan T. Kim
----- -- ---
By Phone --> 617.493.6324
By E-Mail --> btkim(a)fas.harvard.edu
By Browser --> http://www.people.fas.harvard.edu/~btkim/
By Courier --> 175 Pforzheimer Mail Center, Cambridge, MA 02138
We're getting an odd problem in mips_trap where tf_sp (stack pointer) seems
to be set to 0x80021e3c. Since it starts at 0x80000000 and is supposed to
grow down, we're not sure how this is happening. Has anybody had similar
problems? Any ideas?
Thanks,
Fred
If you do "cs161-objdump --all-headers" on one of the userlevel
programs for OS/161, and look at the "program headers" (this is what
you use to load the program) you'll discover it looks something like
this:
Program Header:
LOAD off 0x000000b4 vaddr 0x00001000 paddr 0x00001000 align 2**2
filesz 0x00001708 memsz 0x00001708 flags r-x
LOAD off 0x000017c0 vaddr 0x00002720 paddr 0x00002720 align 2**3
filesz 0x00000937 memsz 0x00000937 flags r--
LOAD off 0x000020f8 vaddr 0x00003058 paddr 0x00003058 align 2**2
filesz 0x000000cc memsz 0x000000cc flags rw-
LOAD off 0x000021c8 vaddr 0x00003128 paddr 0x00003128 align 2**3
filesz 0x00000000 memsz 0x00000210 flags rw-
You'll see that the read-only part (code and read-only data) stops at
virtual address 0x3057, and the read-write part starts at virtual
address 0x3058.
Note that this is not a page boundary.
What this means is that without tweaking the linker, you won't be able
to make the last page of the read-only segments read-only without
breaking the read-write segments.
We don't require that you make the read-only segments actually
read-only (as long as writing to them does not corrupt the executable
files or other concurrently running copies of the same program.)
If despite this problem you still want to, you should be able to tweak
the linker by adding "-Tdata 0x01000000" to the linker flags (LDFLAGS)
for userland. (The best place to do this is in src/mk/prog.mk.) This
will cause the linker to start the read-write data at virtual address
0x01000000 instead of immediately after the read-only data.
Theoretically, it should be possible to get the linker to output the
read-write data immediately after the read-only data, but page-aligned
so as to make it possible to protect it differently. However, it
involves detailed fiddling with linker scripts and probably isn't
worthwhile.
Your system may reject executables where the read-only and read-write
portions overlap (as long as it runs the executables you compile for
it.) However, it should, preferably, not assume that code and data are
contiguous.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Those of you who have been breathlessly awaiting the schedulers for
sol2 - they were posted on the downloads page as a patch (a
supplemental patch against the existing sol2) this afternoon.
My apologies for neglecting to announce them.
Note that the scheduler that calls itself priority-queue based does
not actually use a "real" (heap-based) priority queue. Instead it uses
a linear search in a table. One could change it to use a real priority
queue as part of tuning if one so desired.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
There is a line at the bottom of md_usermode which says
assert(((curkstack-1) & 0xffff0000)==(((u_int32_t)&tf) & 0xffff0000));
Can someone give me a hint at what this is testing for?
Our code gets to this point with the values
curkstack: 0x80020008 &tf: 0x8001fee8
and evidently that's bad b/c it fails the assert, but we've got no idea
how to fix it.
Thanks,
Bryan
----- -- ---
Bryan T. Kim
----- -- ---
By Phone --> 617.493.6324
By E-Mail --> btkim(a)fas.harvard.edu
By Browser --> http://www.people.fas.harvard.edu/~btkim/
By Courier --> 175 Pforzheimer Mail Center, Cambridge, MA 02138
I'm learning to loathe this assignment already...
We don't know where to go from here...hopefully someone has a suggestion:
We're trying to test TLB handling/paging (without swapping). We have an
idiot's kmalloc system in place...basically, we stealmem a huge amount (64
pages) before vm bootstrap, and kmalloc from that store, never freeing
anything. We essentially used the existing kmalloc (and subpage) code,
modifying it only so it takes pages from our "repository" rather than
stealmem'ing them. But I digress...so, the system seems to boot fine, and
the thread tests work ok (well, actually, the lock test runs out of memory,
but we think that's to be expected given that it's allocating a stack for
each thread...), but bad things happen when we try to run the shell. The
thing is, what happens when we try to run the shell is that we get a TLB
read fault. Yes, that's right, a read fault. We should be getting a write
fault beforehand, methinks, but we don't. We get a read fault on address
0x4. Gdb traces have revealed that it seems to be invoking the TLB fault
somewhere in load_elf _before_ we load any segments. When we try to step
into the function that, basically, allocates page table entries for the new
program, we get the fault. Here's the weird thing: when we try to step into
the function, we get a fencepost-heuristic warning from gdb, it gives the
faults, and we die. Dereferencing the arguments to the function on their
own doesn't cause the problem. But as soon as we try to call the function,
it dies with the TLB fault at address 0x4. We're very confused and do not
know how to diagnose this problem. Any suggestions are much appreciated.
Thanks,
Nick
Hi-
I know the comments in the makefile say that we should not remove the -O2,
but is there any way around this? The optimizations make gdb behave very
funkily in lots of places.
Thanks,
Steve
