I'm starting to sound like a broken record, I think.
But I'm assuming people would rather have these fixes right away, even
if it makes the patch count annoyingly high.
So I just posted another patch to ls. This fixes a buffer null
termination bug, and it should also prevent ls -R from recursing
forever on ".".
It should be applied over the previous ls patch.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
When converting from host byte ordering to os161 byte ordering, what should
be done with character strings? Should each individual byte be inverted?
(also, does this make a difference? Are the byte orderings different?)
Nick
This is getting silly. However, there are two more patches up, one for
ls and one for testbin/dirtest.
I also have the following semi-official fix for kheap.c.
(Semi-official in that there will be a new version of sol3 with this
and possibly other fixes, but I don't know when, and I want to make
sure this fix gets out soon.)
This fixes a bug remarkably similar to one we already fixed once in
the base system - it was blindly converting physical addresses to
virtual addresses without checking for 0 (aka NULL). This shouldn't
have any effect unless you run out of memory, but if you do run out of
memory it could save you from hours chasing very strange problems.
Index: os161/sol3/kern/lib/kheap.c
===================================================================
RCS file: /disk/disk0/cs161/CVSREPO/os161/sol3/kern/lib/kheap.c,v
retrieving revision 1.14
diff -u -r1.14 kheap.c
--- kheap.c 2001/04/14 04:29:49 1.14
+++ kheap.c 2001/04/21 21:39:25
@@ -9,7 +9,12 @@
vaddr_t
alloc_kpages(int npages)
{
- return PADDR_TO_KVADDR(coremap_findfree(NULL, 0, npages));
+ paddr_t pa;
+ pa = coremap_findfree(NULL, 0, npages);
+ if (pa==0) {
+ return 0;
+ }
+ return PADDR_TO_KVADDR(pa);
}
void
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
There's a missing lock release on error in the FS synchronization
patches. This patch corrects the mistake:
Index: sol4/kern/fs/sfs/sfs_vnode.c
===================================================================
RCS file: /disk/disk0/cs161/CVSREPO/os161/sol4/kern/fs/sfs/sfs_vnode.c,v
retrieving revision 1.8
diff -u -r1.8 sfs_vnode.c
--- sfs_vnode.c 2001/04/22 21:39:42 1.8
+++ sfs_vnode.c 2001/04/22 23:30:21
@@ -274,6 +274,7 @@
lock_acquire(sfs_buflock);
result = sfs_rblock(sfs, idbuf, idblock);
if (result) {
+ lock_release(sfs_buflock);
return result;
}
}
I'm not planning to post a new version of the synchronization patches
(it doesn't seem worthwhile at this point) so just apply this patch.
You're not likely to ever need the fix anyway.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
I'm getting the following message A LOT (like upwards of 60+ times running
some of the fs tests):
sys161: Geometry modeling fault! (Known bug, ignore...)
Now, obviously it's a "known bug," but nonetheless should I be concerned
about it? Does this imply I'm frequently hitting a corner case that I
shouldn't be, would you think?
Thanks,
Nick
I just put up another sfs bug fix (this is sfs-patch4.txt) regarding
missing instances of sv->sv_dirty = 1.
*sigh* I'm sorry my code sucks.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Hi-
Has anyone else ran into troubles where the system keeps barfing on the root
directory:
% sys161 kernel sfs:lhd0 boot:lhd0
...
OS/161 kernel [? for menu]: p
Program: emu0:/bin/sh
OS/161$ emu0:/bin/ls /
panic: sfs: readdir: Short entry (inode 1)
sys161: 1272785571 cycles (6103228k, 21712u, 1266660631i) in 50.931236
seconds (24.9903 mhz)
sys161: 6073 irqs 323 exns 5r/0w disk 115r/967w console 40r/0w/11m emufs
sys161: Elapsed virtual time: 50.911422867 seconds
This was done after creating a brand new disk with a brand new sfs file
system. Am I missing a step somewhere?
Thanks,
Steve
Could someone please tell me what sfs_namefile is supposed to do?
The comments in sfs_vnode.c say:
"get the name for a file", which seems consistent with the function's name.
The comments in vnode.h say:
"Compute pathname relative to filesystem root of the file", which seems
correct considering the function's behaviour without subdirectories.
Which is it?
Thanks,
Fred
Another sfs patch (#3) was posted on the web site this afternoon.
It's included in the solution set Jay just released; if you're not
using that, get it from the downloads page.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Hi All,
An interim assignment 3 solution has been posted on the class website on
the assignments page. There is a list of files that have been altered.
If there is demand for a patch (against SOL2) I will post one.
Before you build/install sol3, take the following into account:
1) This release is an interim release (that's why the tarball has the
suffix -alpha). It still has some bugs that manifest themselves when
concurrent processes page heavily. A patch will be released soon to fix
these bugs. The existing problems should not affect you as any filesystem
test programs that you write should not make excessive use of memory.
2) DO NOT compile the solution with the LRU page replacement algorithm.
It has not been fully tested, so I can't make any guarantees about
anything if you are using the LRU code.
3) The system by default swaps to lhd0. It expects the lhd0 disk to be at
least 10x the size of physical memory. If you have an existing lhd0 disk,
add a disk entry with a lower number than the existing one in your
sys161.conf file. The lhdX devices are enumerated by their slot order in
the LAMEbus. This means that if you have been doing fs tests on lhd0,
they will now be on lhd1. If you really don't like this, change the line
in arch/mips/mips/vm.c:1127 to use lhd1raw, or whatever other lhd device
you want.
4) The solution tarball reflects changes released in all prior patches,
including the asst4 prepatches, so you shouldn't apply them. The list of
altered files includes files that have been patched for asst4.
Please let us know if there are any problems.
Jay
==
== Jay Moorthi * 617.584.2537 (cell) * moorthi(a)fas.harvard.edu ==
== ==
== "Happiness consists in getting enough sleep." RAH, Starship Troopers ==
==
