FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.4.0 2020-01-06T09:51:22Z 2020-01-06T09:51:22Z Hans Petter Selasky hselasky@FreeBSD.org 2020-01-06T09:51:22Z urn:sha1:3e4525511e2596d9b8603382f79adbff9327e735 Fix spelling. PR: 242891 Sponsored by: Mellanox Technologies 2019-12-22T17:15:48Z Kyle Evans kevans@FreeBSD.org 2019-12-22T17:15:48Z urn:sha1:cb27c8a992eb66fd184da31932db5b26c0947c9c The genkbd version of these remains exposed for stable branches, but keyboard drivers that just want to use the defaults can simply not provide their own. There shouldn't be any unset in the wild. r355796: kbd: provide default implementations of get_fkeystr/diag Most keyboard drivers are using the genkbd implementations as it is; formally use them for any that aren't set. r355797: chrome_kb: remove default get_fkeystr/diag implementations This file was missed in r355796, but no harm would have come from this. r355799: kbd: patch linker set methods, too This is needed after r355796. Some double-registration of kbd drivers needs to be sorted out, then this sysinit will simply add these drivers into the normal list and kill off any other bits in the driver that are aware of the linker set, for simplicity. 2019-12-22T17:06:56Z Kyle Evans kevans@FreeBSD.org 2019-12-22T17:06:56Z urn:sha1:d3d7fc34c31842eccad44e3c2b9abddb93e2d84f 2019-12-22T16:04:12Z Kyle Evans kevans@FreeBSD.org 2019-12-22T16:04:12Z urn:sha1:b9b55ae7e0ab2a9ea03328dbae9c5652c518d3eb 2019-08-08T22:16:19Z Alexander Motin mav@FreeBSD.org 2019-08-08T22:16:19Z urn:sha1:3411b3aa373e74a6f857b301feedd293a4b10269 This provides a nice wrarpper around the XPT_PATH_INQ ccb creation and calling. 2018-10-29T15:12:15Z Wei Hu whu@FreeBSD.org 2018-10-29T15:12:15Z urn:sha1:52936ab366332b0dc1395119ea0575029ae5bcae r339585: Do not drop UDP traffic when TXCSUM_IPV6 flag is on PR: 231797 Submitted by: whu Reviewed by: dexuan Obtained from: Kevin Morse Sponsored by: Microsoft Differential Revision: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=198333&action=diff 2018-08-17T06:31:30Z Dimitry Andric dim@FreeBSD.org 2018-08-17T06:31:30Z urn:sha1:be797e28e93bf61717d8f1b4d48ed1ad5948f52e Fix build of hyperv with base gcc on i386 Summary: Base gcc fails to compile `sys/dev/hyperv/pcib/vmbus_pcib.c` for i386, with the following -Werror warnings: cc1: warnings being treated as errors /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'new_pcichild_device': /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:567: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'vmbus_pcib_on_channel_callback': /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:940: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_pci_protocol_negotiation': /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1012: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_pci_enter_d0': /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1073: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_send_resources_allocated': /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1125: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'vmbus_pcib_map_msi': /usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1730: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] This is because on i386, several casts from `uint64_t` to a pointer reduce the value from 64 bit to 32 bit. For gcc, this can be fixed by an intermediate cast to uintptr_t. Note that I am assuming the incoming values will always fit into 32 bit! Differential Revision: https://reviews.freebsd.org/D15753 2018-07-23T17:35:20Z Dexuan Cui dexuan@FreeBSD.org 2018-07-23T17:35:20Z urn:sha1:41c76089b78412d7d05d8658cba8fee074eb5f77 r336426 hyperv/hn: Fix panic in hypervisor code upon device detach event Submitted by: hselasky Reviewed by: dexuan Differential Revision: https://reviews.freebsd.org/D16139 2018-04-24T03:06:05Z Dexuan Cui dexuan@FreeBSD.org 2018-04-24T03:06:05Z urn:sha1:f605609c933ba81046df338bc574a1538d1ccc5f r332385: hyperv/storvsc: storvsc_io_done(): do not use CAM_SEL_TIMEOUT CAM_SEL_TIMEOUT was introduced in https://reviews.freebsd.org/D7521 (r304251), which claimed: "VM shall response to CAM layer with CAM_SEL_TIMEOUT to filter those invalid LUNs. Never use CAM_DEV_NOT_THERE which will block LUN scan for LUN number higher than 7." But it turns out this is not correct: I think what really filters the invalid LUNs in r304251 is that: before r304251, we could set the CAM_REQ_CMP without checking vm_srb->srb_status at all: ccb->ccb_h.status |= CAM_REQ_CMP. r304251 checks vm_srb->srb_status and sets ccb->ccb_h.status properly, so the invalid LUNs are filtered. I changed my code version to r304251 but replaced the CAM_SEL_TIMEOUT with CAM_DEV_NOT_THERE, and I confirmed the invalid LUNs can also be filtered, and I successfully hot-added and hot-removed 8 disks to/from the VM without any issue. CAM_SEL_TIMEOUT has an unwanted side effect -- see cam_periph_error(): For a selection timeout, we consider all of the LUNs on the target to be gone. If the status is CAM_DEV_NOT_THERE, then we only get rid of the device(s) specified by the path in the original CCB. This means: for a VM with a valid LUN on 3:0:0:0, when the VM inquires 3:0:0:1 and the host reports 3:0:0:1 doesn't exist and storvsc returns CAM_SEL_TIMEOUT to the CAM layer, CAM will detech 3:0:0:0 as well: this is the bug I reported recently: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226583 PR: 226583 Reviewed by: mav Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D14690 2018-04-05T12:59:50Z Ed Maste emaste@FreeBSD.org 2018-04-05T12:59:50Z urn:sha1:05e7e93c1db411539daf9b7d73706639accb7c2d PR: 226665 Submitted by: Ryo ONODERA