Ben Pfaff [Mon, 23 Apr 2007 00:05:33 +0000 (00:05 +0000)]
Correctly initialize the esp0 pointer in the TSS for the initial
kernel thread. Shouldn't actually matter in practice, because that
pointer is only used on a user->kernel transition, and the initial
kernel thread never runs a user process.
Ben Pfaff [Thu, 11 Jan 2007 08:02:13 +0000 (08:02 +0000)]
Set VERBOSE to empty string by default, which prevents an environment
variable named VERBOSE from causing trouble but still allows it to be
overridden by the user on the command line. (Some of the Stanford
machines set VERBOSE=yes in the environment by default on log-in.)
Ben Pfaff [Mon, 11 Dec 2006 20:40:20 +0000 (20:40 +0000)]
Parse command-line options much earlier, so that thread_mlfqs is
initialized before thread_init() gets hold of it.
Also allow console output much earlier, by doing initialization
whenever we call into it first and by only trying to take the console
lock after threads have been initialized.
Don't try to take the console lock after the kernel panics, to avoid
getting nailed so hard by bugs in lock_acquire().
Ben Pfaff [Fri, 8 Dec 2006 16:06:31 +0000 (16:06 +0000)]
Revert the bitmap randomization change, which had the side effect of
causing enough disk fragmentation for the base (extent-based) file
system that in some cases tests would fail. Also, it confused the
hell out of everyone. Failed experiment.
Ben Pfaff [Fri, 8 Dec 2006 15:39:32 +0000 (15:39 +0000)]
When reading files out of the scratch disk, don't die with an error
exit code if there's a bad signature, because that's a guest error not
a host error. (If we do exit with an error code, it fouls up the
grading process.) Instead, just make sure that the host file(s) we
were supposed to retrieve is unlinked.
Godmar Back [Fri, 10 Nov 2006 04:36:14 +0000 (04:36 +0000)]
Rewrite of multi-oom. Now descends 10 times and expects to reach the same
depth every time. In addition, fires off some children that consume resources
and then crash. Much more difficult than before.
Ben Pfaff [Fri, 3 Nov 2006 02:54:48 +0000 (02:54 +0000)]
Remove O_EXCL from flags used to create files to be copied out of a
Pintos scratch disk, in get_scratch_file.
Thanks to Godmar Back for pointing out the problem.
Ben Pfaff [Thu, 5 Oct 2006 00:44:09 +0000 (00:44 +0000)]
Make Pintos able to build with "gcc -m32" on x86-64 hosts without the
need for the host to have any 32-bit libraries (specifically, without
needing libgcc).
Ben Pfaff [Thu, 28 Sep 2006 17:45:27 +0000 (17:45 +0000)]
Irq 7 is special. It is not just the parallel port. It can also be a
"spurious" irq, one that is not associated with any particular device.
Real hardware can generate spurious irqs for various reasons (try
Google for details), but it never occurred to me that simulated
hardware would ever do so.
However, it can, at least under Bochs. Pintos programs the PIT to
interrupt at 100 Hz. The PIT does so by generating a output signal
that stays high most of the time but drops low for a single clock
cycle 100 times per second. The low-to-high transition causes the
timer interrupt.
The problem occurs when we've been doing work with interrupts
disabled, causing a timer interrupt to be delayed. If we enable
interrupts on the same clock cycle as the PIT's high-to-low
transition, we will still get an interrupt, because the interrupt
controller latched the presence of an interrupt. However, when the
CPU attempts to determine the irq number, the interrupt controller
sees that all of its incoming interrupt lines are low. Thus, it
reports irq 7 to the CPU, and we end up with an interrupt 0x27.
It doesn't happen very often, because there's only a 1-cycle window,
and it requires that we do a good deal of work with interrupts off,
and it can only happen if no other interrupts (e.g. serial) are
pending. But it's darned annoying when it happens.
Here's a filtered excerpt from a Bochs log with debugging enabled
where you can see the problem. The first interrupt (32 or 0x20) is
properly a timer interrupt, because irq line 0 is high. The second
interrupt (39 or 0x27) is the spurious one; you can see that irq line
0 went low on the same cycle.
Ben Pfaff [Mon, 25 Sep 2006 21:43:09 +0000 (21:43 +0000)]
Move assignment to _end_kernel_text inside .rodata.
Without this change, any orphan, read-only sections (such as .eh_frame
from libgcc) will be placed by GNU ld between .rodata and
_end_kernel_text. The result is that _end_kernel_text gets pushed
into the middle of a page that now contains some read-only and some
read/write data. After paging_init() marks that page read-only, the
first write to it (in intr_init() in my case) causes Pintos to go
ka-boom!
With this change, orphan read-only sections just don't get marked
read-only in the page tables. Big deal.
Ben Pfaff [Mon, 25 Sep 2006 20:26:35 +0000 (20:26 +0000)]
Fix two bugs in the base Pintos code:
1. Idle thread doesn't get initialized well: it hangs around on the
ready list until we have idle time. Fix by using a semaphore to
make sure the idle thread gets initialized.
2. After idle thread does get initialized, it can get put back on the
ready list if you yield from the timer interrupt. Fix by not ever
putting the idle thread on the ready list.
Plus fix a bug in the sample solution that tends to mask #2:
3. Doesn't yield from timer interrupt when unblocking a thread. Fix
by yielding from timer interrupt when unblocking a thread (of
higher priority).
Also, fix something that confused students:
4. Rename enable_mlfqs to thread_mlfqs and move it to thread.c (to
reduce confusion about where it is declared), and heavily comment
to ensure that students know when it gets initialized.
These problems were drawn to my attention by Godmar Back. Thanks!
Ben Pfaff [Sat, 9 Sep 2006 16:53:56 +0000 (16:53 +0000)]
Fix issue reported by Godmar Back:
I may have found a problem with the triple fault patch, though I don't
know how to solve it.
If you add a *(int *)0=42 right after paging_init(), but before
intr_init(), gdb will just hang:
...
where it hangs while Pintos prints:
Triple fault: stopping for gdb
Triple fault: stopping for gdb
Triple fault: stopping for gdb
Triple fault: stopping for gdb
Triple fault: stopping for gdb
Triple fault: stopping for gdb
Triple fault: stopping for gdb
Triple fault: stopping for gdb
Triple fault: stopping for gdb
Triple fault: stopping for gdb
Triple fault: stopping for gdb
etc.
It stops properly if I don't next-step (that is, if I just let it run.)