measured accurately for periodic interrupts provided the interrupts
don't need to be serviced very quickly to keep their period almost
constant. sio output interrupts have this property (interrupt service
can be delayed for up to 1 character time without the period changing).
This is non-optional and undocumented so that it can be added and
removed easily. It has no significant effect unless it is enabled by
hacking on a variable using a debugger. Hardclock and statclock interrupts
would work even better for this, at least on i386's, provided their
interrupt handlers are fast (as they are in -current but not in -stable
or in my version of -current).
the osigcontext or ucontext_t rather than useracc() followed by direct user-
space memory accesses. This reduces (o)sigreturn()'s execution time by 5-
50%.
Submitted by: bde
bootinfo block in register r8. In locore.s we save the address
in the global variable 'pa_bootinfo'. In machdep.c we compare
this value against the hardwired address, but don't depend on its
validity yet (ie: we still expect the bootinfo block to be at the
hardwired address). After a small amount of time, we'll flip the
switch and depend on the loader to pass us the address. From that
moment on the loader is free to put it anywhere it likes, provided
the machine itself likes it as well.
Add some verbosity to aid in the transition. We emit a message if
the loader didn't pass the address and we also emit a message if
there's no bootinfo block at the hardwired address.
While in locore.s, reduce the number of redundant serialization
instructions. A srlz.i is a proper superset of a srlz.d and thus
is a valid replacement. Also slightly reorder the movl instructions
to improve bundle density.
register r8. We continue to write the bootinfo block at the same
hardwired address, because the kernel still expects it there.
It is expected that future kernels use register r8 to get to the
bootinfo block and don't depend on the hardwired address anymore.
Bump the loader version once again due to the interface change.
These functions use DEV_STRATEGY() which can easily return a short
count (with no error) for reads near EOF. EOF happens for "disks" too
small to contain a label sector (mainly for empty slices). The functions
didn't understand this at all, and looked for labels in the garbage
in the buffer beyond what DEV_STRATEGY() returned. The recent UMA
changes combined with my local changes and configuration resulted in
the garbage often containing a valid but garbage label left over from
a previous call.
Bugs in EOF handling in -current limited the problem to "disks" with
size precisely LABELSECTOR sectors. LABELSECTOR happens to be a very
unusual "disk" size since it is only 0 for non-i386 arches that don't
usually have disks with DOS MBRs.
provided the latter is nonzero. At this point, the former is a fairly
arbitrary default value (DFTPHYS), so changing it to any reasonable
value specified by the device driver is safe. Using the maximum of
these limits broke ffs clustered i/o for devices whose si_iosize_max
is < DFLTPHYS. Using the minimum would break device drivers' ability
to increase the active limit from DFTLPHYS up to MAXPHYS.
Copied the code for this and the associated (unnecessary?) fixup of
mp_iosize_max to all other filesystems that use clustering (ext2fs and
msdosfs). It was completely missing.
PR: 36309
MFC-after: 1 week
only care if it's network or not at this time. If we're loaded from
the network, we set currdev (=loaddev) so that the kernel is loaded
from the network as well. In all other cases we initialize to disk.
This makes netbooting more convenient and can easily be enhanced to
do more elaborate checking.
Most significantly (from an interfacing point of view) is the
support for the FPSWA pointer passing. Even though that was added
4 months ago, it's probably not a bad idea to bump the version
number to reflect this.
o Query the state field of the protocol mode to determine whether
we need to start and/or initialize the protocol. When we're
loaded across the network, the protocol has already been started
and is already initialized. When no networking has happened yet,
we have to start and initialize the protocol ourselves.
o After initialization, we have to set the receive filters. Not
doing this results in a deaf interface. We set the unicast and
broadcast filters. Multicast may not be supported. This specific
change fixes the problem we had that we could not netboot if
the loader was started from the EFI shell.
o To help future debugging, add a function that dumps the current
mode of the interface. It's conditional on EFINET_DEBUG.
o To help in runtime problems, emit a diagnostic message when we
could not initialize the protocol properly.
an efi_devdesc structure. When we're netbooting, f->f_devdata holds
the address of the network socket variable. Dereferencing this caused
some very unpredictable behaviour, including proper functioning.
So, as a sanity check, we first make sure f->f_dev points to our
own devsw. If not, the open will fail before we use f->f_devdata.
This solves the netboot hangs I invariably got whenever I used the
latest toolchain to compile the EFI loader.
layer to signal transmission of the packet. This resolves the
problem I'm seeing that an immediate call to net->Receive
after calling net->Transmit returns EFI_DEVICE_ERROR. This
condition seems to be sufficiently persistent that BOOTP and
RARP fail.
o While here, unify all functions to have 'nif' defined. Some
have it as arguments. The others now have them as locals. We
now always get the protocol interface by using the 'nif' var.
The current status of netbooting is that even though we now reliably
have BOOTP working (again), opening a file (ie loading a kernel)
across the network causes the loader to hang. I'm working on that now.
exists, otherwise we install it anyway. I interpret this as a very
high desire to install ${PROG}.help. Alas, ${PROG}.help doesn't exist
at the moment and neither does loader.help, so in practice this just
doesn't work, no matter how you interpret it. The compromise is to
install ${PROG}.help IFF it exists. I realize we lost creativity with
this commit, but style should have been preserved, AFAICT :-)
back into the calling MD code. The MD code must ensure no races between
checking the astpening flag and returning to usermode.
Submitted by: peter (ia64 bits)
Tested on: alpha (peter, jeff), i386, ia64 (peter), sparc64
- Make sure the interface is UP and RUNNING in fddi_input().
- Reorder and comment packet tests in fddi_input().
- Call if_attach() in fddi_ifattach().
- Test for a valid return from ifaddr_byindex().
- Use struct fddi_header where appropriate.
- Use bcopy() rather than memcpy().
- Use FDDI_ADDR_LEN macro instead of ETHER_ADDR_LEN macro.
- Add loadable module support.
- Use FDDI_ADDR_LEN rather than a magic number or a sizeof().
- Hide distracting sizeof() behind FDDI_HDR_LEN macro.
- Don't use sizeof(struct llc) in areas where we mean LLC_SNAPFRAMELEN.
allows us to properly parse cards with attribute memory based CIS that
before wouldn't parse correctly, sometimes with a panic. This allows
me to get my 3C562 modem/ethernet card to fail to attach due to
problems in the ep and sio drivers rather than due to problems in the
CIS parsing code :-).
We weren't setting the address to jump to for the function entries.
This caused us to only work when the addional entries were after the
first ones. On the 3C562/3C563 card this was not the case.
We were also mapping Attribute memory when common memory was asked for
in the target of the LONGLINK_{A,C} or LONGLINK_MFC.
My IBM Home And Away Modem/LAN card still fails for reasons unknown.
