* The MNT_UPDATE case had a null pointer dereference. (This is a good example
of why blindly adding bogus initializiers is a FUNDAMENTALLY BAD IDEA!)
* Make sure the whole ufsmount is zeroed, as the export code relies on this.
* If we decided to use the second/alternate superblock, make sure to copy the
in-core version from the right buffer.
Also, reenable NFS exporting.
board versions with no BIOS. Separate mailbox interrupts from
IOCB interrupts. Read OUTMAILBOX5 while RISC_INT is active- not
after you clear it (potential race condition). Clear out older broken
BIG_ENDIAN goop. Don't negotiate narrow/async for LVD busses at startup
if already in LVD mode. Note usage of presumptive 1040C revision. For
all the LIP, PDB Changed, Loop UP/DOWN async events, mark fw state
as unknown as well as marking the need to do a getpdb on targets- after
a LIP for certain the f/w has to do PRLI/PLOGI for all targets again
and marking f/w state as unknown gives us a fighting chance to (start
to) hold up for that to complete.
that will SBusify an isp header or the lun/target portions of a request IOCB-
and have these only valid iff __sparc__ (no non-sparc SBus machine that *I*
know about).
remote of the tunnel can be found.
XXX If you manually mark the interface as "UP" and set the MTU later
XXX sending a packet will still cause a kernel panic.
was deasserted and we wanted to change parameters to -crtscts
This effectively stalled the transmitter since with TS_BUSY set
we only change parameters during the Tx interrupt handler.
passing SIOCSIFADDR/SIOIFDSTADDR, but by passing the addresses in
the appropriate structs.
One of the mysteries of ifconfig IMHO...
Should fix kern/6899.
provides the correct functions for primary, secondary, and unified
boot blocks. actually behave correctly (e.g. expect correct arguments,
perform correct operations) depending on which you are. also
some minor cleanup.
guts were actually functionally equivalent to the current guts, but were
much larger, filled with bugs, and indeed poked around at the disklabel
when some of those bugs prevented them from ever using the disklabel!
had a few bugs fixed that let the problem slip in, and since bootxx's
Makefile now goes out of its way to satisfy installboot's undocumented
and totally unreasonable assumptions about the bootxx file it's operating
on. No point in fixing the assumptions, because sooner rather than later
this incarnation of installboot is going to die.
assuming that there's always going to be space for the whole boot
block info struct. (the assumption would cause a malloc'd region
to be overrun, if it proved false.)
