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.
I have not been able to find very much information about the PC98
extended partition layout so this is gleaned from the source in
our pc98 architecture. Corrections and patched very welcome.
Sponsored by: DARPA and NAI Labs.
