config SYSV_FS tristate "System V/Xenix/V7/Coherent file system support" depends on BLOCK help SCO, Xenix and Coherent are commercial Unix systems for Intel machines, and Version 7 was used on the DEC PDP-11. Saying Y here would allow you to read from their floppies and hard disk partitions. If you have floppies or hard disk partitions like that, it is likely that they contain binaries from those other Unix systems; in order to run these binaries, you will want to install linux-abi which is a set of kernel modules that lets you run SCO, Xenix, Wyse, UnixWare, Dell Unix and System V programs under Linux. It is available via FTP (user: ftp) from ). NOTE: that will work only for binaries from Intel-based systems; PDP ones will have to wait until somebody ports Linux to -11 ;-) If you only intend to mount files from some other Unix over the network using NFS, you don't need the System V file system support (but you need NFS file system support obviously). Note that this option is generally not needed for floppies, since a good portable way to transport files and directories between unixes (and even other operating systems) is given by the tar program ("man tar" or preferably "info tar"). Note also that this option has nothing whatsoever to do with the option "System V IPC". Read about the System V file system in . Saying Y here will enlarge your kernel by about 27 KB. To compile this as a module, choose M here: the module will be called sysv. If you haven't heard about all of this before, it's safe to say N. -next.git/log/include/dt-bindings/power'>logtreecommitdiff
path: root/include/dt-bindings/power
diff options
context:
space:
mode:
authorNicolai Stange <nicstange@gmail.com>2016-12-07 22:21:33 +0100
committerTejun Heo <tj@kernel.org>2016-12-07 16:29:09 -0500
commite185934ff94466b4a449165e5f1c164a44d005f2 (patch)
treec773d05d4c72292e3babd4ce1a8bd56d965ebb4c /include/dt-bindings/power
parent5c3ef39738f74a3759918cc1a1ad099504f9d1b7 (diff)
libata-scsi: disable SCT Write Same for the moment
SCT Write Same support had been introduced with commit 7b2030942859 ("libata: Add support for SCT Write Same") Some problems, namely excessive userspace segfaults, had been reported at http://lkml.kernel.org/r/20160908192736.GA4356@gmail.com This lead to commit 0ce1b18c42a5 ("libata: Some drives failing on SCT Write Same") which strived to disable SCT Write Same on !ZAC devices. Due to the way this was done and to the logic in sd_config_write_same(), this didn't work for those devices that have ->max_ws_blocks > SD_MAX_WS10_BLOCKS: for these, ->no_write_same and ->max_write_same_sectors would still be non-zero, but ->ws10 == ->ws16 == 0. This would cause sd_setup_write_same_cmnd() to demultiplex REQ_OP_WRITE_SAME requests to WRITE_SAME, and these in turn aren't supported by libata-scsi: EXT4-fs (dm-1): Delayed block allocation failed for inode 2625094 at logical offset 2032 with max blocks 2 with error 121 EXT4-fs (dm-1): This should not happen!! Data will be lost 121 == EREMOTEIO is what scsi_io_completion() asserts in case of invalid opcodes. Back to the original problem of userspace segfaults: this can be tracked down to ata_format_sct_write_same() overwriting the input page. Sometimes, this page is ZERO_PAGE(0) which ceases to be filled with zeros from that point on. Since ZERO_PAGE(0) is used for userspace .bss mappings, code of the following is doomed: static char *a = NULL; /* .bss */ ... if (a) *a = 'a'; This problem is not solved by disabling SCT Write Same for !ZAC devices only. It can certainly be fixed, but the final release is quite close -- so disable SCT Write Same for all ATA devices rather than introducing some SCT key buffer allocation schemes at this point. Fixes: 7b2030942859 ("libata: Add support for SCT Write Same") Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'include/dt-bindings/power')