dump the trace buffer feasible.
- Remove KTR_EXTEND. This changes the format of the trace entries when
activated, making writing a userland tool which is not tied to a specific
kernel configuration difficult.
- Use get_cyclecount() for timestamps. nanotime() is much too heavy weight
and requires recursion protection due to ktr traces occuring as a result
of ktr traces. KTR_VERBOSE may still require recursion protection, which
is now conditional on it.
- Allow KTR_CPU to be overridden by MD code. This is so that it is possible
to trace early in startup before pcpu and/or curthread are setup.
- Add a version number for the ktr interface. A userland tool can check this
to detect mismatches.
- Use an array for the parameters to make decoding in userland easier.
- Add file and line recording to the non-extended traces now that the extended
version is no more.
These changes will break gdb macros to decode the extended version of the
trace buffer which are floating around. Users of these macros should either
use the show ktr command in ddb, or use the userland utility which can be run
on a core dump.
Approved by: jhb
Tested on: i386, sparc64
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
have ripped all the i386 specific formatting code from their
dump routines. Due to the potential for trashing disks, I did
not want to do this "blind".
This design is my best effort and it is quite likely that people more used
to kernel dumps may want to change this subsequently so two levels of
version numbers are provided: one for the common header and one per
architecture.
Sponsored by: DARPA & NAI Labs.
the non-GEOM code as well. This simplifies the the kernel-dumping
and disk-management tools as less compatibility cruft will be needed.
Sponsored by: DARPA and NAI Labs.
while holding the proc lock, and by holding the pargs structure when
accessing it from outside of the owner.
Submitted by: Jonathan Mini <mini@haikugeek.com>
(65536 * 32 - 1), but MAKEDEV only supports up to (32 * 32 -1). Device
names use the unit number in base 32 for all "digits".
This required fixing an old bug in MAKEDEV:ttyminor(). Its arg was the
global $unit instead of $1.
Reminded by: Valentin K. Ponomarenko <valka@krog.ukrtel.net>
MFC-after: 1 week
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
