device announcement; assume a sector size of 512 instead (likely to be
right at all).
This case happens when booting with a removable disk device attached
(e.g. an MOD), but no medium inserted.
I think it's time for Ugen to get a freefall account, just so I can
direct mail at him directly and let him drop off patches for us here. Ugen?
Done!
Submitted by: ugen
Given the right circumstances, a call to kvm_open can result in a core
dump.
The diff belows fixes this (note that this change is already in the
NetBSD code). Could somebody apply this?
Gary J.
Submitted by: gj
Somebody should make a mib variable for it.
Just now it is pointless to dump the kernel, since we have nothing which
can read the dump.
Furthermore is should never be the default to dump.
options DODUMP
will enable dumps.
profiling and wchar_t. Profiled libraries will shrink.
tm.h:
Our wchar_t is int, not unsigned short.
Always link statically if profiling.
Define all the SPECs together.
final.c, tm.h:
Don't emit unused profiling code and data.
aux-output.c:
Always preserve the PIC register if profiling.
aux-output.c, tm.h:
Implement FUNCTION_PROFILER_EPILOGUE (currently not used).
New:
tm.h:
Set the target defaults in the correct way.
there is an extra target now for creating a 1.2MB floppy at the cost
of a few of the doc files. Just do a `make small.floppies' instead of
a `make floppies' to make a small set.
When we get an EN8 response while we're already sending the file using
the i protocol, this can happen:
In send.c, flocal_send_await_reply() is called. This function calls
flocal_send_fail() to process the aborted transfer. After this, we run
into the branch that calls ffileseekend() to force the end of the
actual transfer.
Now flocal_send_fail() frees qtrans, but qtrans is still used later!
I propose to fix this by moving the usfree_send(qtrans) out of
flocal_send_fail(), as in the patch I append to this mail.
...
I have found a race condition in the uucp 1.05 code. The typical result
is that the connections mysteriously fails with "conversation failed",
even while all files were transmitted. This is the problem:
At least for the i protocol, the code to send a packet can receive and
process packets after sending.
In several places in the code, we send a command and then prepare to
receive an answer.
Now the answer might already arrive during the call that sends the
command while we aren't ready to process it.
The general solution is IMHO first to do all preparations and only as a
last step to send out the command.
Reviewed by: John Dyson
Submitted by: Johannes Stille
MKINIT line that doesn't have a comment on it (we have at least two).
This mkinit program was written by someone who obviously doesn't believe
in defensive programming. :-( There's a LOT of work that needs to be done
on this thing. :-( :-( :-(
Enabled via REL2_1.
Added support for doing object collapses "on the fly". Enabled via REL2_1a.
Improved object collapses so that they can happen in more cases. Improved
sensing of modified pages to fix an apparant race condition and improve
clustered pageout opportunities. Fixed an "oops" with not restarting page
scan after a potential block in vm_pageout_clean() (not doing this can result
in strange behavior in some cases).
Submitted by: John Dyson & David Greenman
process output dialogs (or any way to stop the output, for that matter!).
2. Install the very first cut of my bininst stage6 script. VERY rough,
it doesn't actually do anything just yet, but I need to make sure that
it's at least executed for the moment.
main.c sanitize the logic of what we do when:
if(getpid()!=1) do stage0 & stage1 (very useful actually)
else if (floppy-marker-file is there) stage0-2, reboot
else stage3-5
