It seems that the sol4 host-mksfs, when compiled with gcc to run on
ice, blows up.
Compiling it with cc (DEC's compiler) instead of gcc makes the problem
go away. To do this, edit src/defs.mk and change the definition of
HOST_CC from "gcc" to "cc", and edit the -W options out of HOST_CFLAGS.
Then apply the following patch to src/sbin/mksfs/support.h, and
recompile host-mksfs (and probably host-dumpsfs too).
Sigh.
--- src/sbin/mksfs/support.h~ Sat Apr 14 17:54:52 2001
+++ src/sbin/mksfs/support.h Mon Apr 30 14:52:49 2001
@@ -27,7 +27,7 @@
#ifdef HAS_NO_SIZED_TYPES
-#if defined(__alpha__)
+#if defined(__alpha__) || defined(__alpha)
/* Alpha processor: lp64 */
typedef unsigned int u_int32_t;
typedef unsigned short u_int16_t;
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
If you didn't get the URL and such for Jonathan Ledlie's
talk, here's the scoop.
- Margo
Jonathan Ledlie
ledlie(a)cs.wisc.edu
http://www.cs.wisc.edu/~ledlie/p2p
The solution set for asst4 is up.
As usual, let us know if you spot any problems.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Hi All,
I'm happy to announce that the asst3 solution is now released in full.
It is stable under heavy concurrent paging, and you may use the LRU page
replacement algorithm if you want to (although in terms of wallclock time
it is not all that much faster).
The tarball and the list of files changed between the first sol3 release
and now are posted on the Assignments page of the course website.
This release includes all previous sfs patches.
If you want to use the new sol3 source along with the buffer cache and
directory support you wrote for A4, make sure that you import it into your
cvs repository correctly.
The correct procedure for a CVS import is as follows:
choose a directory into which you will unpack the tarball (e.g.,
~/cs161/tmp).
then execute the following commands:
cd ~/cs161/tmp
tar zxvf asst3-sol.tgz
cd asst3-sol
cvs import -m "Asst3 Solution Release" src cs161-staff asst3-sol
If you get a message about running a checkout to help the merge, do so and
fix any merge conflicts that come up.
Please let me know if you have any problems.
Jay
==
== Jay Moorthi * 617.584.2537 (cell) * moorthi(a)fas.harvard.edu ==
== ==
== "Happiness consists in getting enough sleep." RAH, Starship Troopers ==
==
well, this patch isn't for everyone then. only those that, possibly as far
back as assignment 1, realized that panicing in lock/bitmap_create is
probably not desirable behavior.
one bit of dumb code is not an excuse for more.
-gwa-
> Actually, if you look at thread/synch.c in the lock_create function,
> you'll notice that it panics and dies if kmalloc returns NULL. Unless
> of course you changed lock create to not do this. If you are patching
> against asst3-alpha, then you will never get to the code that kfrees the
> filesystem and returns ENOMEM. bitmap_create has the same panic
> behavior.
> So, long story short, this patch should be unnecessary. If it changes
> anything behavior in any way, then, well, stranger things are happening
> that memory allocation failing.
> Jay
> On Tue, 24 Apr 2001, gwa wrote:
>> this one goes against asst3-alpha and fixes some problems with memory
>> allocation that MIGHT be biting people who are pushing their cache
>> pretty hard... and not using ram_stealmem(). ;-)
>>
>> patch attached.
>>
>> -gwa-
>>
>> --- sfs_fs.c.old Tue Apr 24 21:50:08 2001
>> +++ tarballs/asst3-sol-alpha/kern/fs/sfs/sfs_fs.c Tue Apr 24
21:55:17 2001
>> @@ -328,8 +328,15 @@
>> sfs->sfs_device = dev;
>>
>> /* Create and acquire the locks so various stuff works right */
>> - sfs->sfs_vnlock = lock_create("sfs_vnlock");
>> - sfs->sfs_bitlock = lock_create("sfs_bitlock");
>> + if (!(sfs->sfs_vnlock = lock_create("sfs_vnlock"))) {
>> + kfree(sfs);
>> + return ENOMEM;
>> + }
>> + if (!(sfs->sfs_bitlock = lock_create("sfs_bitlock"))) {
>> + lock_destroy(sfs->sfs_vnlock);
>> + kfree(sfs);
>> + return ENOMEM;
>> + }
>> lock_acquire(sfs->sfs_vnlock);
>> lock_acquire(sfs->sfs_bitlock);
>>
>> @@ -368,7 +375,16 @@
>> sfs->sfs_super.sp_volname[sizeof(sfs->sfs_super.sp_volname)-1] =
0;
>>
>> /* Load free space bitmap */
>> - sfs->sfs_freemap = bitmap_create(SFS_FS_BITMAPSIZE(sfs));
>> + if (!(sfs->sfs_freemap = bitmap_create(SFS_FS_BITMAPSIZE(sfs))))
{
>> + lock_release(sfs->sfs_vnlock);
>> + lock_release(sfs->sfs_bitlock);
>> + lock_destroy(sfs->sfs_vnlock);
>> + lock_destroy(sfs->sfs_bitlock);
>> + bitmap_destroy(sfs->sfs_freemap);
>> + kfree(sfs);
>> + return ENOMEM;
>> + }
>> +
>> result = sfs_mapio(sfs, UIO_READ);
>> if (result) {
>> lock_release(sfs->sfs_vnlock);
>>
>>
>
>==
>== Jay Moorthi * 617.584.2537 (cell) * moorthi(a)fas.harvard.edu
==
>==
>==
>== "Happiness consists in getting enough sleep." RAH, Starship Troopers
>==
==
rank your top three choices, and send them to me as soon as you can.
thanks!
1) WAR IS HELL, with the "war" crossed out, CS161 above it.
2) front: P()
back: V()
(contents of the P and V up for suggestion, could also have a 161
function or similar)
3) Survivor logo, with appropriate changes. (outdesign, outcode, outlive)
4) CS50/CS161 comparison (eg. write cat using open() and read(), write open()
and read(); learn to use malloc and free, write malloc and free, etc.)
5) group animals chasing the bsd daemon (any cartoonists in the house?)
6) front: picture of dholland, written underneath: "this man is a dork"
back: now i am, too.
cs161 2001
7) CS161 Survivor Tour 2001 (list of assignment stuff with dates)
8) something with a monolith (ref. 2001)
9) front:
CS161 isn't
much work.
back:
Ok, so I'm lying.
10) front: i survived cs161
back: and all i got was this crappy tshirt
11)
Three pages for scheduler code in kernel text;
Seven for device drivers storing their data;
Nine for page tables spawned from fork;
One for the kernel heap in its dark corner
In the land of CS161 where the shadows lie.
One kmalloc to rule them all, One kmalloc to find them,
One kmalloc to bring them all and in the darkness bind them,
In the land of CS161 where the shadows lie.
12) some sort of take off of the OS/161 panic message.
13) CS161: it's not a course, it's a lifestyle
14) draw the nine circles of cs161 hell:
(the holes obviously need to be filled in)
#1: ran out of late days
#2:
#3:
#4: forgot to make install
#5: gdb lies about function arguments
#6: forgot to make depend
#7: forgot to cvs commit
#8:
#9: bug in kmalloc
Hey there,
Since nothing else is really working (yet), we are proud to at least have
changed the solution set shell to allow a backspace to work on the wsX
Alphas. There must be other sufferers out there. So Team Llama is
proud to attach a patchfile for sh.c to allow the Alpha backspace as well
as a telnet backspace. It's attached as shpatch, so:
% patch sh.c < shpatch
Maybe we're the only ones with this issue, but I hope this helps somebody
out. As you can tell by the complexity of the fix, it was really a
breakthrough moment for us. Now where was that inode again...?
Cheers,
Ben and Team Llama
when the comment at the top of sfs_vnode.c says:
* Ordering among directory locks is a design concern for the
* implementation of subdirectories.
does this mean we are free to specify that you need to acquire a
subdirectories lock before you acquire its parents if we want? or does that
order fall under the directories before files that are in them constraint?
brady
Due to the excessive number of bugs in SFS, and the other assorted
difficulties this week, we hereby grant every group an additional late
day to use now... or for asst5, as you see fit.
I realize this would have been more helpful if announced last night,
but it took until this morning to round up enough of the course staff
to decide. :-|
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
