committer filter by committer.
@path/to/ filter by path in repository.
committer@path/to/ filter by committer AND path in repository.
NNN or rNNN filter by revision.
NNN-MMM or rNNN-rMMM filter by revisions range (inclusive).
Multiple filters can be specified separated by spaces or comas in which case they'll be combined using OR operator.
|r348814||imp||June 8, 2019, 7:58 p.m.||Add stuff to disable warning for %S
Add the customary warnings to disable format checking on armv7. Code move to new files, and the unconditional setting of WARNS to 6 provoked it on tinerbox...ViewVC
|r348813||kib||June 8, 2019, 7:50 p.m.||Make trap_msg array constant as well.
Suggested by: tijl Sponsored by: The FreeBSD Foundation MFC after: 1 weekViewVC
|r348812||imp||June 8, 2019, 7:02 p.m.||Create gptboot.efi
This is a primary boot loader that is intended to implement the gptboot partition selection algorithm just like we did for BIOS booting. While the preferred method for UEFI is to use the UEFI Boot Manager protocol, there are situations where that can't be done: some BIOS makers interfere with the protocol in unhelpful ways, there's a new standard for a zero variable write from the client OS, and finally for USB drives that might be mobile between systems with multiple partitions there needs to be a media stable way to select. Reviewed by: tsoome, bcran Differential Revision: https://reviews.freebsd.org/D20547ViewVC
|r348811||imp||June 8, 2019, 6:59 p.m.||Break out the disk selection protocol from the rest of boot1.|
|r348810||jtl||June 8, 2019, 6:26 p.m.||Currently, MCA entries remain on an every-growing linked list. This means
that it becomes increasingly expensive to process a steady stream of correctable errors. Additionally, the memory used by the MCA entries can grow without bound. Change the code to maintain two separate lists: a list of entries which still need to be logged, and a list of entries which have already been logged. Additionally, allow a user-configurable limit on the number of entries which will be saved after they are logged. (The limit defaults to -1 [unlimited], which is the current behavior.) Reviewed by: imp, jhb MFC after: 2 weeks Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D20482ViewVC
|r348809||dougm||June 8, 2019, 5:49 p.m.||Simple code refactoring originally in D13484.
Extract swp_pager_force_dirty() and swp_pager_force_launder() out of swp_pager_force_pagein(). Extract swap_pager_swapoff_object() out of swap_pager_swapoff(). Submitted by: ota_j.email.ne.jp Reviewed by: alc, dougm Approved by: kib (mentor) Differential Revision: https://reviews.freebsd.org/D20545ViewVC
|r348808||bz||June 8, 2019, 5:44 p.m.||Fix dpcpu and vnet panics with complex types at the end of the section.
Apply a linker script when linking i386 kernel modules to apply padding to a set_pcpu or set_vnet section. The padding value is kind-of random and is used to catch modules not compiled with the linker-script, so possibly still having problems leading to kernel panics. This is needed as the code generated on certain architectures for non-simple-types, e.g., an array can generate an absolute relocation on the edge (just outside) the section and thus will not be properly relocated. Adding the padding to the end of the section will ensure that even absolute relocations of complex types will be inside the section, if they are the last object in there and hence relocation will work properly and avoid panics such as observed with carp.ko or ipsec.ko. There is a rather lengthy discussion of various options to apply in the mentioned PRs and their depends/blocks, and the review. There seems no best solution working across multiple toolchains and multiple version of them, so I took the liberty of taking one, as currently our users (and our CI system) are hitting this on just i386 and we need some solution. I wish we would have a proper fix rather than another "hack". Also backout r340009 which manually, temporarily fixed CARP before 12.0-R "by chance" after a lead-up of various other link-elf.c and related fixes. PR: 230857,238012 With suggestions from: arichardson (originally last year) Tested by: lwhsu Event: Waterloo Hackathon 2019 Reported by: lwhsu, olivier MFC after: 6 weeks Differential Revision: https://reviews.freebsd.org/D17512ViewVC
|r348807||bz||June 8, 2019, 5:38 p.m.||Remove extra stray + from a diff from the beginning of the lines after
r348805 to fix the build. Please do not ask how 3 more local builds succeeded without barfing. Pointyhat to: bz MFC after: 6 weeks X-MFC with: r348805ViewVC
|r348806||chuck||June 8, 2019, 5:17 p.m.||Add NVMe support to camdd(8)|
|r348805||bz||June 8, 2019, 4:26 p.m.||Add SDIO support.
Add a CAM-Newbus SDIO support module. This works provides a newbus infrastructure for device drivers wanting to use SDIO. On the lower end while it is connected by newbus to SDHCI, it talks CAM using the MMCCAM framework to get to it. This also duplicates the usbdevs framework to equally create sdiodev header files with #defines for "vendors" and "products". Submitted by: kibab (initial work, see https://reviews.freebsd.org/D12467) Reviewed by: kibab, imp (comments on earlier version) MFC after: 6 weeks Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D19749ViewVC
|r348804||bz||June 8, 2019, 4:15 p.m.||bcm2835_sdhci.c: exit DMA if not enough data left to avoid timeout errors
In the DMA case, given we disable the data interrupts, we never seem to get DATA_END. Given we are relying on DMA interrupts we are not using the SDHCI state machine and hence only call into sdhci_platform_will_handle() for the first check of data. We do not call "will handle" for any following round trips of the same transaction if block size * count > BCM_DMA_BLOCK_SIZE. Manually check "left" in the DMA interrupt handler to see if we have at least another full BCM_DMA_BLOCK_SIZE to handle. Without this change we would DMA that and then even start a DMA with left == 0 which would lead to a timeout and error. Now we re-enable data interrupts and return and let the SDHCI generic interrupt handler and state machine pick the SPACE_AVAIL up and then find that it should punt to the pio_handler for the remaining bytes or finish the data transaction. With this change block mode seems to work beyond 7 * 64byte blocks, which worked as it was below BCM_DMA_BLOCK_SIZE. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D20199ViewVC
|r348803||bz||June 8, 2019, 4:05 p.m.||bcm2835_sdhci.c: save block registers to avoid controller bug
Extending what the initial revision, r273264, r276985, r277346 have started for the transfer mode and command registers, another pair of 16bit registers written in sequence are block size and block count, which fall together onto the same 32bit line and hence the same register(s) would be written twice in sequence for those as well. Use a similar approach to transfer mode and command and save the writes to either of the block regiters and then only execute a write once. We can do this as with transfer mode their values are meaningless until a command is issued so we can use that write to command as a trigger to also write out the block registers. Compared to transfer mode and command the value of block count can change, so we need to keep state and actually read the block registers back the first time after a write. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D20197ViewVC
|r348802||kib||June 8, 2019, 4:03 p.m.||Remove lazy FPU switch support from amd64.
It is incompatible with some future features. Sponsored by: The FreeBSD Foundation MFC after: 1 weekViewVC
|r348801||bz||June 8, 2019, 3:24 p.m.||Improve sdhci slot_printf() debug printing.
Currently slot_printf() uses two printf() calls to print the device-slot name, and actual message. When other printf()s are ongoing in parallel this can lead to interleaved message on the console, which is especially unhelpful for debugging or error messages. Take a hit on the stack and vsnprintf() the message to the buffer. This way it can be printed along with the device-slot name in one go avoiding console gibberish. Reviewed by: marius MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D19747ViewVC
|r348800||bz||June 8, 2019, 3:19 p.m.||Introduce sim_dev and cam_sim_alloc_dev().
Add cam_sim_alloc_dev() as a wrapper to cam_sim_alloc() which takes a device_t instead of the unit_number (which we can derive from the dev again). Add device_t sim_dev to struct cam_sim. It will be used to pass through the bus for cases when both sides of CAM speak newbus already and we want to link them (yet make the calls through CAM for now). SDIO will be the first consumer of this. For that make use of cam_sim_alloc_dev() in sdhci under MMCCAM. This will also allow people to start iterating more on the idea to newbus-ify CAM without changing 50+ device drivers from the start. Also to be clear there are callers to cam_sim_alloc() which do not have a device_t (e.g., XPT) or provide their own unit number so we cannot simply switch the KPI entirely. Submitted by: kibab (original idea, see https://reviews.freebsd.org/D12467) Reviewed by: imp, chuck MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D19746ViewVC