Keep track of interrupt nesting level. It is normally 0
for syscalls and traps, but is fudged to 1 for their exit
processing in case they metamorphose into an interrupt
handler.
i386/genassym.c;
Remove support for the obsolete pcb_iml and pcb_cmap2.
Add support for pcb_inl.
i386/swtch.s:
Fudge the interrupt nesting level across context switches and in
the idle loop so that the work for preemptive context switches
gets counted as interrupt time, the work for voluntary context
switches gets counted mostly as system time (the part when
curproc == 0 gets counted as interrupt time), and only truly idle
time gets counted as idle time.
Remove obsolete support (commented out and otherwise) for pcb_iml.
Load curpcb just before curproc instead of just after so that
curpcb is always valid if curproc is. A few more changes like
this may fix tracing through context switches.
Remove obsolete function swtch_to_inactive().
include/cpu.h:
Use the new interrupt nesting level variable to implement a
non-fake CLF_INTR() so that accounting for the interrupt state
works.
You can use top, iostat or (best) an up to date systat to see
interrupt overheads. I see the expected huge interrupt overheads
for ISA devices (on a 486DX/33, about 55% for an IDE drive
transferring 1250K/sec and the same for a WD8013EBT network card
transferring 1100K/sec). The huge interrupt overheads for serial
devices are unfortunately normally invisible.
include/pcb.h:
Remove the obsolete pcb_iml and pcb_cmap2. Replace them by
padding to preserve binary compatibility.
Use part of the new padding for pcb_inl.
isa/icu.s:
isa/vector.s:
Keep track of interrupt nesting level.
Now floppy tape support is *disabled* unless you specifically
request otherwise. Poul wanted it this way, and I guess I'm not going to argue
though it may seem counter-intuitive. We can always change it back, later.
flags & 0x1. Somebody should build a kernel with this and see if
the floppy-tape damaged people can turn it off properly with userconfig.
I can't reproduce the original problem here.
This should have been disabled for some time, but I had screwed up ...
This made spurious values appear for fd0 in systat, when there was
NCR SCSI activity.
comconsole will behave as expected. The true problem should be fixed
instead, Bruce' comment for this:
>Anyway, i found the reason for my problems: somehow, ICRNL isn't in
>effect at `userconfig' time (but only for comconsole?), hence only
ICRNL doesn't apply to cngetc(). cnputc() unconditionally does the
equivalent of ONLCR; perhaps cngetc() should unconditionally do the
equivalent of ICRNL. Ddb must be checking for CR. Userconfig only
checks for NL. Userconfig works with syscons because pccngetc()
does the conversion. This is probably the wrong place to do it.
and into ether_input(). It was silly to have bpf want this one way and
ether_input want it another way. Ripped out trailer support from the few
remaining drivers that still had it.
1) make #includes correct
2) fix bugs in address check macros
3) fixed bugs in, and enabled, recopy if heavily fragmented code
4) moved call to bpf tap to be before enqueing packet (probably gratuitous)
5) fixed bug that caused "abnormal interrupt" at boot time/first use
6) added support for reading Zynx address ROM
7) fixed bug that caused broadcasts to not work shortly after booting (only
manifested if not using multicast - e.g. not in FreeBSD 2.0)
8) fixed spelling errors in comments
Submitted by: Matt Thomas
Subject: Mea culpa -- small fix for netboot fixes
In accordance with the unavoidable principle sof Murphy's Law, I discovered
that the fixes I recently contributed for the netboot code had some small
flaws in them. Two of them were just typos and had no effect on how the
program functioned. The other one was a missing line from the rootopts and
swapopts functions I created in bootmenu.c, which was supposed to initialize
the NFS sotype flag. It defaults to UDP, and you can change it to TCP with
the rootopts or swapopts commands, but then you can't change it back again.
I originally had a line at the top of each function to reinitialize this
flag, but somehow it got lost in the shuffle, probably because I don't
actually have a need for that flag yet.
Submitted by: wpaul
That was the good news. The bad news is that bad144 is a proper mess,
and I don't have time to fix it now, so you will probably not be able to
use it anyway.
Sorry guys, go out and buy a 100Mb IDE drive and a paddleboard :-(
If somebody wants to pick up on this: bad144 needs to learn how to
stay inside our slice of the disk. That's the trick.
Go to a single dependancy in files.i386. Using a .c file for the
sequencer code won't work since I need to know the size of the program,
so we just include the generated .h file as:
"../../sys/gnu/misc/aic7770/aic7770_seq.h"
Reviewed by:
Submitted by:
Obtained from:
instead. The entire scheme just doesn't work as envisioned (hint: think
about make depend as well as all). Those extremely rare individuals who
actually hack on the sequencer code will know how to keep stuff in sync,
I *do* get the feeling!
Somehow, I don't think this stuff was tested at all! :-(
I really hope that it actually works, though my hopes are steadily diminishing.
Anyone with 27xx/28xx boards in -current is *strongly encouraged* to give this
stuff a shot! Otherwise, I suspect that we'll be punting this out of
2.0. I haven't found a single part of Justin's commit that wasn't broken
in some way.
