Re: next/master boot: 179 boots: 11 failed, 167 passed with 1 offline (next-20180731)
On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote: > You may have to provide some clue, such as dmesg log, boot disk, ... > I guess you don't use virtio-scsi/virtio-blk since both run at blk-mq > mode at default, even though without d5038a13eca72fb. Boot logs and so on can be found here: https://kernelci.org/boot/id/5b618c9f59b514931f96ba97/ https://kernelci.org/boot/id/5b618ca359b514904d96bac5/ https://kernelci.org/boot/id/5b618cbc59b51492e896baad/ (these are today's but the symptoms are the same.) The ramdisk is unfortunately not linked through the UI, though we don't get that far. signature.asc Description: PGP signature
Re: next/master boot: 179 boots: 11 failed, 167 passed with 1 offline (next-20180731)
On Wed, Aug 01, 2018 at 11:05:36AM +0100, Guillaume Tucker wrote: > On 31/07/18 16:14, kernelci.org bot wrote: > > Boot Regressions Detected: > [...] > > x86: > > > > x86_64_defconfig: > > qemu: > > lab-baylibre: failing since 1 day (last pass: next-20180727 - > > first fail: next-20180730) > > lab-mhart: failing since 1 day (last pass: next-20180727 - > > first fail: next-20180730) > > lab-linaro-lkft: failing since 1 day (last pass: next-20180727 > > - first fail: next-20180730) > I've run a few automated bisection on kernelci.org, it initially > landed on this merge commit: > ff719be3476a Merge remote-tracking branch 'scsi/for-next' > The 2 parent commits boot fine, but not the resulting merge. So I > did another bisection based on the first branch while merging the > incoming one in each iteration, and that landed on this commit: > commit d5038a13eca72fb216c07eb717169092e92284f1 > Author: Johannes Thumshirn > Date: Wed Jul 4 10:53:56 2018 +0200 > > scsi: core: switch to scsi-mq by default > > > I then tried to revert it on top of next-20180731 and it did make it > boot again. Now, I haven't looked much further in the code, it's > entirely possible that the problem is on another incoming branch, in > the code that this config enables. At least it seems to be narrowing > down the scope for where to look for a problem. Copying in everyone else who signed off/acked/reviewed that commit. signature.asc Description: PGP signature
linux-next: manual merge of the scsi tree with the net-next tree
Hi James,
Today's linux-next merge of the scsi tree got a conflict in:
drivers/scsi/qedf/qedf.h
between commit:
8673daf4f55bf3b91 ("qedf: Add get_generic_tlv_data handler.")
from the net-next tree and commit:
4b9b7fabb39b3e9d7 ("scsi: qedf: Improve firmware debug dump handling")
from the scsi tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/scsi/qedf/qedf.h
index cabb6af60fb8,2372a40326f8..
--- a/drivers/scsi/qedf/qedf.h
+++ b/drivers/scsi/qedf/qedf.h
@@@ -501,9 -499,8 +504,10 @@@ extern int qedf_post_io_req(struct qedf
extern void qedf_process_seq_cleanup_compl(struct qedf_ctx *qedf,
struct fcoe_cqe *cqe, struct qedf_ioreq *io_req);
extern int qedf_send_flogi(struct qedf_ctx *qedf);
+extern void qedf_get_protocol_tlv_data(void *dev, void *data);
extern void qedf_fp_io_handler(struct work_struct *work);
+extern void qedf_get_generic_tlv_data(void *dev, struct qed_generic_tlvs
*data);
+ extern void qedf_wq_grcdump(struct work_struct *work);
#define FCOE_WORD_TO_BYTE 4
#define QEDF_MAX_TASK_NUM 0x
signature.asc
Description: PGP signature
Re: [PATCH/RFC 0/6] Allow compile-testing NO_DMA
On Tue, Feb 06, 2018 at 11:14:46AM +0100, Geert Uytterhoeven wrote: > The intention of this is twofold: > 1. To catch users of the DMA API on systems that do no support the DMA > mapping API, > 2. To avoid building drivers that cannot work on such systems anyway. > > However, the disadvantage is that we have to keep on adding dependencies > on HAS_DMA all over the place. > Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or > more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus > already covering intention #2. Having to add an explicit dependency on > HAS_DMA here is cumbersome, and hinders compile-testing. Thanks for doing this, hopefully it'll make everyone's life easier! Reviwed-by: Mark Brown <broo...@kernel.org> signature.asc Description: PGP signature
Re: [PATCH 0/5] Rename regulator_set_optimum_mode
On Wed, Feb 11, 2015 at 07:35:26PM -0800, Bjorn Andersson wrote: Changing the name of the regulator_set_optimum_mode() to regulator_set_load() better reflects that the API is doing. Applied all, thanks. signature.asc Description: Digital signature
Re: [PATCH 0/5] Rename regulator_set_optimum_mode
On Wed, Feb 25, 2015 at 03:40:31PM -0800, Bjorn Andersson wrote: Any comments on this? I'm going to propose a patch to the mmc framework calling this api, so it would be good to know before I add another consumer of the api. Please don't send content free nags. They just add to the volume of mail that needs to be read and responded to. signature.asc Description: Digital signature
next-20141126 build failures in wd719x
On Wed, Nov 26, 2014 at 02:03:14PM +, Build bot for Mark Brown wrote: The wd719x driver fails to build on at least arm and arm64 in today's -next since: arm64-allmodconfig ../drivers/scsi/wd719x.c:247:2: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] arm-allmodconfig ../drivers/scsi/wd719x.c:247:2: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] dma_cache_sync() is not available on these architectures. I can't immediately see something to depend on that'd exclude the driver from these architectures, the other users seem to all have architecture specific dependencies. signature.asc Description: Digital signature
Re: next-20140925 build: 1 failures 106 warnings (next-20140925)
On Fri, Sep 26, 2014 at 12:02:03PM +0530, Sreekanth Reddy wrote: Can you please let me known whether you are observing these warning messages even after inclusion of below patch Well, today's -next has arch/arm build breakages so not immediately. signature.asc Description: Digital signature
Re: next-20140925 build: 1 failures 106 warnings (next-20140925)
On Thu, Sep 25, 2014 at 01:13:56PM +0100, Build bot for Mark Brown wrote: arm-allmodconfig ERROR: __aeabi_uldivmod [drivers/scsi/mpt2sas/mpt2sas.ko] undefined! Today's ARM allmodconfig fails to build due to a call to a GCC intrinsic being emitted from the mpt2sas module - I've not made any effort to investigate this myself yet, unfortunately there's been a build error in this configuration for arch/arm for the past week or so which means that the error may not have been introduced today. signature.asc Description: Digital signature
[PATCH] target: target_core_transport: Don't try to strlen() an integer
In transport_dump_vpd_ident_type() we try to call strlen() on the integer len which is obviously a typo; take the length of the string already in buf instead. Fixes: 6cfa853ceee4a (target: target_core_transport.c: Cleaning up missing null-terminate in conjunction with strncpy) Signed-off-by: Mark Brown broo...@kernel.org --- drivers/target/target_core_transport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 1dd11818f38f..3ce85edc2ea9 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -953,7 +953,7 @@ int transport_dump_vpd_ident_type( strlcat(buf, SCSI name string\n, sizeof(buf)); break; default: - len = strlen(len); + len = strlen(buf); snprintf(buf[len], sizeof(buf) - len, Unsupported: 0x%02x\n, vpd-device_identifier_type); ret = -EINVAL; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
