(And 4Kn minidump support, but only for amd64.)
Make sure all I/O to the dump device is of the native sector size. To
that end, we keep a native sector sized buffer associated with dump
devices (di->blockbuf) and use it to pad smaller objects as needed (e.g.
kerneldumpheader).
Add dump_write_pad() as a convenience API to dump smaller objects with
zero padding. (Rather than pull in NPM leftpad, we wrote our own.)
Savecore(1) has been updated to deal with these dumps. The format for
512-byte sector dumps should remain backwards compatible.
Minidumps for other architectures are left as an exercise for the
reader.
PR: 194279
Submitted by: ambrisko@
Reviewed by: cem (earlier version), rpokala
Tested by: rpokala (4Kn/512 except 512 fulldump), cem (512 fulldump)
Relnotes: yes
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D5848
Prior to this change, vdev_geom_open_by_path would call vdev_geom_attach
prior to verifying the device's GUIDs. vdev_geom_attach calls
vdev_geom_attrchange to set the physpath in the vdev object. The result is
that if the disk could not be found, then the labels for other disks in the
same TLD would overwrite the missing disk's physpath with the physpath of
whichever disk currently has the same devname as the missing one used to
have.
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
This revision suggests dtsi patches to be used with the original OpenWRT
dtsi files so we can re-use what has already been done in OpenWRT for the
Mediatek/Ralink SoCs.
The only thing that is required after importing this revision should be
the following:
1. Import OpenWRT dts/dtsi files into sys/gnu/dts/mips
2. Run the following script in sys/gnu/dts/mips:
for f in `ls [mr]t*.dtsi`; do
printf "\n#include <fbsd-$f>\n" > $f
done
This will apply our dtsi patches to OpenWRT's dtsi files and will allow us
to re-use dts/dtsi files for ~170 Mediatek/Ralink boards.
Currently our drivers are not 100% compatible with OpenWRT's dts files, but
they're compatible enough.
We can add more functionality in the future that would better leverage the
OpenWRT work as well.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5965
fdt_static_dtb.S dependency in sys/conf/files is currently set as:
$S/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE}
This is wrong, as what fdt_static_dtb.S actually uses is the DTB file
produced from the FDT_DTS_FILE.
In addition it also makes using DTS files stored in $S/gnu/dts/${MACHINE}/
impossible.
So, change the dependency to "fdt_dtb_file", which seems to be the right
option here anyway.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5963
A lot of dts files define the SPI flashes supported by mx25l as
compatible with 'jedec,spi-nor', so we add this to the mx25l
compat_data.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5962
This revision gets our Mediatek/Ralink drivers closer to OpenWRT's dts
definitions, so we can reuse them with less modifications later in order
to bring support for a lot of boards at once.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5961
This is actually initialized properly within xhci.c, so it's better to
not initialize it in mtk_xhci.c
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5935
the following:
1. Give the appropriate board dts file to be used by either:
1.1. edit the SoC kernel config required (e.g., MT7620A_FDT) and include
the required FDT_DTS_FILE makeoption; or
1.2. simply supply FDT_DTS_FILE="xx.dts" on the command line when building
the kernel
Of course, the user can also create a completely new kernel config to
match the desired board and include the SoC kernel config from within
it.
If required, edit the MEDIATEK config file, which includes optional
drivers and comment out the unneeded ones.
2.1. this would only make sense if kernel size is a concern. Even if we
build the kernel with all drivers, if we lzma it and package it as a uImage,
its size is still around 1.1MiB.
The user will have to choose a dts file (or create a new one) from
sys/gnu/dts/mips , where all Mediatek/Ralink dts files will be imported via
a later revision.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5966
initially configured in the TSC deadline mode, eventtimer subsystem
can be switched to periodic, and then DCR register is loaded with
unitialized value.
Reset the LAPIC eventtimer frequency and min/max periods when changing
between deadline and counted periodic modes.
Reported and tested by: Vladimir Zakharov <zakharov.vv@gmail.com>
Sponsored by: The FreeBSD Foundation
write to the End of Interrupt (EOI) register before handling the interrupt.
This should be a noop as it will be set for all edge triggered interrupts,
however this will not be the case for MSI interrupts. These are also edge
triggered, however we should not write to the EOI register until later in
arm_gic_pre_ithread.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
support MSI and MSI-X interrupts, however intrng needs updates before this
can happen.
For now we just attach the driver until the MSI API is ready.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D5950
Revert r292255 because it can create bounced regions without contiguous
page offsets, which is needed for USB devices.
Another solution would be to force bouncing the full buffer always (even
when only one page requires bouncing), but this seems overly complicated and
unnecessary, and it will probably involve using more bounce pages than the
current code.
Reported by: phk
* Samsung 843T Series SSDs (MZ7WD*)
* Samsung PM851 Series SSDs (MZ7TE*)
* Samsung PM853T Series SSDs (MZ7GE*)
as known having broken NCQ TRIM support as they appear to be based on
the same controller technology as the 840 and 850 series.
I've had at least one report of the PM853 being broken, so err on the
side of caution for the above drives. The PM863/SM863 appears to be
based on a newer controller, so give it the benefit of the doubt.
fgetln(3) will returns NULL if cannot get a line from a stream.
strsep(3) it will returns NULL if the end of the string was reached.
jemalloc(3) malloc will returns NULL if it cannot allocate memory.
fgetln(3) it will returns NULL if it cannot get a line from a stream.
MFC after: 4 weeks
