committer filter by committer.
@path/to/ filter by path in repository.
committer@path/to/ filter by committer AND path in repository.
abdef0123 filter by commit's SHA hash.
rNNN filter by SVN revision.
rNNN-rMMM filter by SVN revisions range (inclusive).
Multiple filters can be specified separated by spaces or comas in which case they'll be combined using OR operator.
|9fc7a59f||ian||Feb. 11, 2017, 1:07 a.m.||Stop including sys/types.h from arm's machine/atomic.h, fix the places|
|333b68ab||mm||Feb. 11, 2017, 1 a.m.||MFV r313569:313569:313569:|
|b291029e||behlendorf1||Feb. 11, 2017, 12:09 a.m.||Enclosure LED fixes
- Pass $VDEV_ENC_SYSFS_PATH to 'zpool [iostat|status] -c' to include enclosure LED sysfs path. - Set LEDs correctly after import. This includes clearing any erroniously set LEDs prior to the import, and setting the LED for any UNAVAIL drives. - Include symlink for vdev_attach-led.sh in Makefile.am. - Print the VDEV path in all-syslog.sh, and fix it so the pool GUID actually prints. Reviewed-by: Don Brady <firstname.lastname@example.org> Reviewed-by: Brian Behlendorf <email@example.com> Signed-off-by: Tony Hutter <firstname.lastname@example.org> Closes #5716 Closes #5751cgit
|65a736bc||behlendorf1||Feb. 10, 2017, 11:18 p.m.||Clear enclosure sysfs path from VDEV label when sysfs path isn't present
This clears vdev_enc_sysfs_path from the label if the VDEV's /sys/class/block/<dev>/device/enclosure_device path isn't present. This is important in the case where a disk that is labeled with vdev_enc_sysfs_path is pulled out and put into another enclosure. In that case, it's possible that the old sysfs path would be used to turn on the fault LED for the disk's old slot postion, assuming the new slot didn't have a LED sysfs entry. Reviewed-by: Don Brady <email@example.com> Reviewed-by: Brian Behlendorf <firstname.lastname@example.org> Signed-off-by: Tony Hutter <email@example.com> Closes #5524 Closes #5773cgit
|638a0d36||mm||Feb. 10, 2017, 11:12 p.m.||Update vendor/libarchive to git b3bd0b81a1a06909f766dea8be4072ef81de62b8|
|28ef82eb||ken||Feb. 10, 2017, 10:02 p.m.||Change the isp(4) driver to not adjust the tag type for REQUEST SENSE.
The isp(4) driver was changing the tag type for REQUEST SENSE commands to Head of Queue, when the CAM CCB flag CAM_TAG_ACTION_VALID was NOT set. CAM_TAG_ACTION_VALID is set when the tag action in the XPT_SCSI_IO is not CAM_TAG_ACTION_NONE and when the target has tagged queueing turned on. In most cases when CAM_TAG_ACTION_VALID is not set, it is because the target is not doing tagged queueing. In those cases, trying to send a Head of Queue tag may cause problems. Instead, default to sending a simple tag. IBM tape drives claim to support tagged queueing in their standard Inquiry data, but have the DQue bit set in the control mode page (mode page 10). CAM correctly detects that these drives do not support tagged queueing, and clears the CAM_TAG_ACTION_VALID flag on CCBs sent down to the drives. This caused the isp(4) driver to go down the path of setting the tag action to a default value, and for Request Sense commands only, set the tag action to Head of Queue. If an IBM tape drive does get a Head of Queue tag, it rejects it with Invalid Message Error (0x49,0x00). (The Qlogic firmware translates that to a Transport Error, which the driver translates to an Unrecoverable HBA Error, or CAM_UNREC_HBA_ERROR.) So, by default, it wasn't possible to get a good response from a REQUEST SENSE to an FC-attached IBM tape drive with the isp(4) driver. IBM tape drives (tested on an LTO-5 with G9N1 firmware and a TS1150 with 4470 firmware) also have a bug in that sending a command with a non-simple tag attribute breaks the tape drive's Command Reference Number (CRN) accounting and causes it to ignore all subsequent commands because it and the initiator disagree about the next expected CRN. The drives do reject the initial command with a head of queue tag with an Invalid Message Error (0x49,0x00), but after that they ignore any subsequent commands. IBM confirmed that it is a bug, and sent me test firmware that fixes the bug. However tape drives in the field will still exhibit the bug until they are upgraded. Request Sense is not often sent to targets because most errors are reported automatically through autosense in Fibre Channel and other modern transports. ("Modern" meaning post SCSI-2.) So this is not an error that would crop up frequently. But Request Sense is useful on tape devices to report status information, aside from error reporting. This problem is less serious without FC-Tape features turned on, specifically precise delivery of commands (which enables Command Reference Numbers), enabled on the target and initiator. Without FC-Tape features turned on, the target would return an error and things would continue on. And it also does not cause problems for targets that do tagged queueing, because in those cases the isp(4) driver just uses the tag type that is specified in the CCB, assuming the CAM_TAG_ACTION_VALID flag is set, and defaults to sending a Simple tag action if it isn't an ordered or head of queue tag. sys/dev/isp/isp.c: In isp_start(), don't try to send Request Sense commands with the Head of Queue tag attribute if the CCB doesn't have a valid tag action. The tag action likely isn't valid because the target doesn't support tagged queueing. Sponsored by: Spectra Logic MFC after: 3 dayscgit ViewVC
|bb9b7104||jhb||Feb. 10, 2017, 7:45 p.m.||Regenerate all the system call tables to drop "created from" lines.|
|28e59198||ngie||Feb. 10, 2017, 7:31 p.m.||Expect :mmap__bad_arguments to fail|
|807a7231||jhb||Feb. 10, 2017, 7:25 p.m.||Drop the "created from" line from files generated by makesyscalls.sh.
This information is less useful when the generated files are included in source control along with the source. If needed it can be reconstructed from the $FreeBSD$ tag in the generated file. Removing this information from the generated output permits committing the generated files along with the change to the system call master list without having inconsistent metadata in the generated files. Reviewed by: emaste, kib MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D9497cgit ViewVC
|b6c03f21||emaste||Feb. 10, 2017, 7:17 p.m.||kldxref: bump MAXSEGS to 3|
|d65b2f7e||emaste||Feb. 10, 2017, 7:11 p.m.||kldxref: s/sections/segments/ in warning message|
|449705db||behlendorf1||Feb. 10, 2017, 6:54 p.m.||OpenZFS 5704 - libzfs can only handle 255 file descriptors
Authored by: Simon Klinkert <firstname.lastname@example.org> Reviewed by: Josef 'Jeff' Sipek <email@example.com> Reviewed by: John Kennedy <firstname.lastname@example.org> Approved by: Richard Lowe <email@example.com> Reviewed-by: Brian Behlendorf <firstname.lastname@example.org> Reviewed by: Ned Bass <email@example.com> Reviewed-by: Chunwei Chen <firstname.lastname@example.org> Ported-by: George Melikov <email@example.com> OpenZFS-issue: https://www.illumos.org/issues/5704 OpenZFS-commit: https://github.com/openzfs/openzfs/commit/bde3d61 Closes #5767cgit
|cfff3743||glebius||Feb. 10, 2017, 5:46 p.m.||Move tcp_fields_to_net() static inline into tcp_var.h, just below its|
|10addc1e||glebius||Feb. 10, 2017, 5:37 p.m.||Last consumer of _WANT_RTENTRY gone.|
|00dffd7e||glebius||Feb. 10, 2017, 5:34 p.m.||Don't check struct rtentry on FreeBSD, it is an internal kernel structure.|