Merge/sound upstream 20201027 #2538
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To servers which do not support directory leases (e.g. Samba) it is wasteful to try to open_shroot (ie attempt to cache the root directory handle). Skip attempt to open_shroot when server does not indicate support for directory leases. Cuts the number of requests on mount from 17 to 15, and cuts the number of requests on stat of the root directory from 4 to 3. Signed-off-by: Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> # v5.1+
If processing recovered log intent items fails, we need to cancel all the unprocessed recovered items immediately so that a subsequent AIL push in the bail out path won't get wedged on the pinned intent items that didn't get processed. This can happen if the log contains (1) an intent that gets and releases an inode, (2) an intent that cannot be recovered successfully, and (3) some third intent item. When recovery of (2) fails, we leave (3) pinned in memory. Inode reclamation is called in the error-out path of xfs_mountfs before xfs_log_cancel_mount. Reclamation calls xfs_ail_push_all_sync, which gets stuck waiting for (3). Therefore, call xlog_recover_cancel_intents if _process_intents fails. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com>
Based on the discussion in [0], update the bpf_redirect_neigh() helper to accept an optional parameter specifying the nexthop information. This makes it possible to combine bpf_fib_lookup() and bpf_redirect_neigh() without incurring a duplicate FIB lookup - since the FIB lookup helper will return the nexthop information even if no neighbour is present, this can simply be passed on to bpf_redirect_neigh() if bpf_fib_lookup() returns BPF_FIB_LKUP_RET_NO_NEIGH. Thus fix & extend it before helper API is frozen. [0] https://lore.kernel.org/bpf/393e17fc-d187-3a8d-2f0d-a627c7c63fca@iogearbox.net/ Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/bpf/160322915615.32199.1187570224032024535.stgit@toke.dk
Sedat reported typos using codespell tool. $ codespell fs/exfat/*.c | grep -v iput fs/exfat/namei.c:293: upto ==> up to fs/exfat/nls.c:14: tabel ==> table $ codespell fs/exfat/*.h fs/exfat/exfat_fs.h:133: usally ==> usually Fix typos found by codespell. Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
We alreday has the interface i_blocksize() to get blocksize, so use it. Signed-off-by: Xianting Tian <tian.xianting@h3c.com> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
The exfat_find_dir_entry() called by exfat_find() doesn't return -EEXIST. Therefore, the root-dir information setting is never executed. Signed-off-by: Tetsuhiro Kohada <kohada.t2@gmail.com> Acked-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
There is nothing in directory just created, so there is no need to scan. Signed-off-by: Tetsuhiro Kohada <kohada.t2@gmail.com> Acked-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Use structure assignment instead of memcpy. Signed-off-by: Tetsuhiro Kohada <kohada.t2@gmail.com> Acked-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Remove 'rwoffset' in exfat_inode_info and replace it with the parameter of exfat_readdir(). Since rwoffset is referenced only by exfat_readdir(), it is not necessary a exfat_inode_info's member. Also, change cpos to point to the next of entry-set, and return the index of dir-entry via dir_entry->entry. Signed-off-by: Tetsuhiro Kohada <kohada.t2@gmail.com> Acked-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
In exfat_move_file(), the identity of source and target directory has been checked by the caller. Also, it gets stream.start_clu from file dir-entry, which is an invalid determination. Signed-off-by: Tetsuhiro Kohada <kohada.t2@gmail.com> Acked-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
…neigh() This updates the test_tc_neigh prog in selftests to use the new syntax of bpf_redirect_neigh(). To exercise the helper both with and without the optional parameter, add an additional test_tc_neigh_fib test program, which does a bpf_fib_lookup() followed by a call to bpf_redirect_neigh() instead of looking up the ifindex in a map. Update the test_tc_redirect.sh script to run both versions of the test, and while we're add it, fix it to work on systems that have a consolidated dual-stack 'ping' binary instead of separate ping/ping6 versions. Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/160322915724.32199.17530068594636950447.stgit@toke.dk
In commit 269e583 ("powerpc/eeh: Delete eeh_pe->config_addr") the following simplification was made: - if (!pe->addr && !pe->config_addr) { + if (!pe->addr) { eeh_stats.no_cfg_addr++; return 0; } This introduced a bug which causes EEH checking to be skipped for devices in PE#0. Before the change above the check would always pass since at least one of the two PE addresses would be non-zero in all circumstances. On PowerNV pe->config_addr would be the BDFN of the first device added to the PE. The zero BDFN is reserved for the PHB's root port, but this is fine since for obscure platform reasons the root port is never assigned to PE#0. Similarly, on pseries pe->addr has always been non-zero for the reasons outlined in commit 42de19d ("powerpc/pseries/eeh: Allow zero to be a valid PE configuration address"). We can fix the problem by deleting the block entirely The original purpose of this test was to avoid performing EEH checks on devices that were not on an EEH capable bus. In modern Linux the edev->pe pointer will be NULL for devices that are not on an EEH capable bus. The code block immediately above this one already checks for the edev->pe == NULL case so this test (new and old) is entirely redundant. Ideally we'd delete eeh_stats.no_cfg_addr too since nothing increments it any more. Unfortunately, that information is exposed via /proc/powerpc/eeh which means it's technically ABI. We could make it hard-coded, but that's a change for another patch. Fixes: 269e583 ("powerpc/eeh: Delete eeh_pe->config_addr") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201021232554.1434687-1-oohall@gmail.com
Yaniv reported a compilation error after pulling latest libbpf:
[...]
../libbpf/src/root/usr/include/bpf/bpf_helpers.h:99:10: error:
unknown register name 'r0' in asm
: "r0", "r1", "r2", "r3", "r4", "r5");
[...]
The issue got triggered given Yaniv was compiling tracing programs with native
target (e.g. x86) instead of BPF target, hence no BTF generated vmlinux.h nor
CO-RE used, and later llc with -march=bpf was invoked to compile from LLVM IR
to BPF object file. Given that clang was expecting x86 inline asm and not BPF
one the error complained that these regs don't exist on the former.
Guard bpf_tail_call_static() with defined(__bpf__) where BPF inline asm is valid
to use. BPF tracing programs on more modern kernels use BPF target anyway and
thus the bpf_tail_call_static() function will be available for them. BPF inline
asm is supported since clang 7 (clang <= 6 otherwise throws same above error),
and __bpf_unreachable() since clang 8, therefore include the latter condition
in order to prevent compilation errors for older clang versions. Given even an
old Ubuntu 18.04 LTS has official LLVM packages all the way up to llvm-10, I did
not bother to special case the __bpf_unreachable() inside bpf_tail_call_static()
further.
Also, undo the sockex3_kern's use of bpf_tail_call_static() sample given they
still have the old hacky way to even compile networking progs with native instead
of BPF target so bpf_tail_call_static() won't be defined there anymore.
Fixes: 0e9f684 ("bpf, libbpf: Add bpf_tail_call_static helper for bpf programs")
Reported-by: Yaniv Agman <yanivagman@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Yonghong Song <yhs@fb.com>
Tested-by: Yaniv Agman <yanivagman@gmail.com>
Link: https://lore.kernel.org/bpf/CAMy7=ZUk08w5Gc2Z-EKi4JFtuUCaZYmE4yzhJjrExXpYKR4L8w@mail.gmail.com
Link: https://lore.kernel.org/bpf/20201021203257.26223-1-daniel@iogearbox.net
The hdlc_rcv function is used as hdlc_packet_type.func to process any
skb received in the kernel with skb->protocol == htons(ETH_P_HDLC).
The purpose of this function is to provide second-stage processing for
skbs not assigned a "real" L3 skb->protocol value in the first stage.
This function assumes the device from which the skb is received is an
HDLC device (a device created by this module). It assumes that
netdev_priv(dev) returns a pointer to "struct hdlc_device".
However, it is possible that some driver in the kernel (not necessarily
in our control) submits a received skb with skb->protocol ==
htons(ETH_P_HDLC), from a non-HDLC device. In this case, the skb would
still be received by hdlc_rcv. This will cause problems.
hdlc_rcv should be able to recognize and drop invalid skbs. It should
first make sure "dev" is actually an HDLC device, before starting its
processing. This patch adds this check to hdlc_rcv.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: Xie He <xie.he.0141@gmail.com>
Link: https://lore.kernel.org/r/20201020013152.89259-1-xie.he.0141@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…her_setup This driver calls ether_setup to set up the network device. The ether_setup function would add the IFF_TX_SKB_SHARING flag to the device. This flag indicates that it is safe to transmit shared skbs to the device. However, this is not true. This driver may pad the frame (in eth_tx) before transmission, so the skb may be modified. Fixes: 550fd08 ("net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared") Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by: Xie He <xie.he.0141@gmail.com> Link: https://lore.kernel.org/r/20201020063420.187497-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The driver depends on mmio regmap API but doesn't select the appropriate Kconfig option. This fixes it. Fixes: 8c7bd5a ("net: ethernet: mtk-star-emac: new driver") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20201020073515.22769-1-brgl@bgdev.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
"ip addr show" command execute error when we have a physical
network card with a large number of VFs
The return value of if_nlmsg_size() in rtnl_calcit() will exceed
range of u16 data type when any network cards has a larger number of
VFs. rtnl_vfinfo_size() will significant increase needed dump size when
the value of num_vfs is larger.
Eventually we get a wrong value of min_ifinfo_dump_size because of overflow
which decides the memory size needed by netlink dump and netlink_dump()
will return -EMSGSIZE because of not enough memory was allocated.
So fix it by promoting min_dump_alloc data type to u32 to
avoid whole netlink message size overflow and it's also align
with the data type of struct netlink_callback{}.min_dump_alloc
which is assigned by return value of rtnl_calcit()
Signed-off-by: Di Zhu <zhudi21@huawei.com>
Link: https://lore.kernel.org/r/20201021020053.1401-1-zhudi21@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
0 causes instruction fetch stall at cache line boundary under some conditions on Navi10. A non-zero prefetch is the preferred default in any case. Fixes soft hang in Luxmark. Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Fix the function used for sienna cichlid to get correct PCIE information by pp_dpm_pcie. Signed-off-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.9.x
This reverts commit 265c280. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
fclk value is missing in pp_dpm_fclk. add this to correctly show the current value. Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.9.x
if it's fine-grained clock dpm, remove the average clock value and reflects the real clock. Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Skip disabled sa to correct the cu_info and active_rbs for sienna cichlid. Signed-off-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.9.x
This patch adds necessary documentation for fast commits. Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201015203802.3597742-2-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
We are running out of mount option bits. Add handling for using s_mount_opt2. Add ext4 and jbd2 fast commit feature flag and also add ability to turn off the fast commit feature in Ext4. Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201015203802.3597742-3-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This patch adds fast commit area trackers in the journal_t structure. These are initialized via the jbd2_fc_init() routine that this patch adds. This patch also adds ext4/fast_commit.c and ext4/fast_commit.h files for fast commit code that will be added in subsequent patches in this series. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201015203802.3597742-4-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This functions adds necessary APIs needed in JBD2 layer for fast commits. Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201015203802.3597742-5-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This patch adds main fast commit commit path handlers. The overall
patch can be divided into two inter-related parts:
(A) Metadata updates tracking
This part consists of helper functions to track changes that need
to be committed during a commit operation. These updates are
maintained by Ext4 in different in-memory queues. Following are
the APIs and their short description that are implemented in this
patch:
- ext4_fc_track_link/unlink/creat() - Track unlink. link and creat
operations
- ext4_fc_track_range() - Track changed logical block offsets
inodes
- ext4_fc_track_inode() - Track inodes
- ext4_fc_mark_ineligible() - Mark file system fast commit
ineligible()
- ext4_fc_start_update() / ext4_fc_stop_update() /
ext4_fc_start_ineligible() / ext4_fc_stop_ineligible() These
functions are useful for co-ordinating inode updates with
commits.
(B) Main commit Path
This part consists of functions to convert updates tracked in
in-memory data structures into on-disk commits. Function
ext4_fc_commit() is the main entry point to commit path.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Link: https://lore.kernel.org/r/20201015203802.3597742-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This patch adds fast commit recovery support in JBD2. Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201015203802.3597742-7-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This patch adds fast commit recovery path support for Ext4 file system. We add several helper functions that are similar in spirit to e2fsprogs journal recovery path handlers. Example of such functions include - a simple block allocator, idempotent block bitmap update function etc. Using these routines and the fast commit log in the fast commit area, the recovery path (ext4_fc_replay()) performs fast commit log recovery. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201015203802.3597742-8-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
…rinivas Kandagatla <srinivas.kandagatla@linaro.org>: This patchset adds support to Qualcomm Robotics RB5 Development Kit based on QRB5165 Robotics SoC. This board has 2 WSA881X smart speakers with onboard DMIC connected to internal LPASS codec via WSA and VA macros respectively. Srinivas Kandagatla (2): ASoC: qcom: dt-bindings: Add SM8250 sound card bindings ASoC: qcom: sm8250: add sound card qrb5165-rb5 support .../bindings/sound/qcom,sm8250.yaml | 161 +++++++++++++ sound/soc/qcom/Kconfig | 11 + sound/soc/qcom/Makefile | 2 + sound/soc/qcom/sm8250.c | 228 ++++++++++++++++++ 4 files changed, 402 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/qcom,sm8250.yaml create mode 100644 sound/soc/qcom/sm8250.c -- 2.21.0
…free()" from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
Hi Mark
soc_pcm_hw_params() does rollback when failed (A),
but, it is almost same as soc_pcm_hw_free().
static int soc_pcm_hw_params(xxx)
{
...
if (ret < 0)
goto xxx_err;
...
return ret;
^ component_err:
| ...
| interface_err:
(A) ...
| codec_err:
| ...
v return ret;
}
This kind of duplicated code can be a hotbed of bugs,
thus, this patch-set share soc_pcm_hw_free() and rollback.
Kuninori Morimoto (6):
ASoC: soc.h: remove for_each_rtd_dais_rollback()
ASoC: soc-pcm: move soc_pcm_hw_free() next to soc_pcm_hw_params()
ASoC: soc-link: add mark for snd_soc_link_hw_params/free()
ASoC: soc-component: add mark for snd_soc_pcm_component_hw_params/free()
ASoC: soc-dai: add mark for snd_soc_dai_hw_params/free()
ASoC: soc-pcm: add soc_pcm_hw_clean() and call it from soc_pcm_hw_params/free()
include/sound/soc-component.h | 6 +-
include/sound/soc-dai.h | 4 +-
include/sound/soc-link.h | 3 +-
include/sound/soc.h | 7 +-
sound/soc/soc-component.c | 19 ++---
sound/soc/soc-dai.c | 13 +++-
sound/soc/soc-dapm.c | 4 +-
sound/soc/soc-link.c | 12 +++-
sound/soc/soc-pcm.c | 131 ++++++++++++++--------------------
9 files changed, 97 insertions(+), 102 deletions(-)
--
2.25.1
…viorel.suman@oss.nxp.com> Viorel Suman <viorel.suman@nxp.com>: From: Viorel Suman <viorel.suman@nxp.com> DAI driver for new XCVR IP found in i.MX8MP. Viorel Suman (2): ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver ASoC: dt-bindings: fsl_xcvr: Add document for XCVR Changes since v1: - improved 6- and 12-ch layout comment - used regmap polling function, improved clocks handling in runtime_resume - added FW size check in FW load function, improved IRQ handler, removed dummy IRQ handlers - fixed yaml file Changes since v2: - used devm_reset_control_get_exclusive instead of of_reset_control_get - moved reset_control_assert into runtime_suspend Changes since v3: - removed "firmware-name" DTS property from both documentation and source code by porting it into SoC specific 'compatible' data structure. .../devicetree/bindings/sound/fsl,xcvr.yaml | 104 ++ sound/soc/fsl/Kconfig | 10 + sound/soc/fsl/Makefile | 2 + sound/soc/fsl/fsl_xcvr.c | 1359 +++++++++++++++++ sound/soc/fsl/fsl_xcvr.h | 266 ++++ 5 files changed, 1741 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,xcvr.yaml create mode 100644 sound/soc/fsl/fsl_xcvr.c create mode 100644 sound/soc/fsl/fsl_xcvr.h -- 2.26.2
…hmanen@linux.intel.com>: Series with multiple code cleanups, plus one fix to remove unnecessary kernel warnings related to firmware loading. Bard Liao (1): ASoC: SOF: loader: handle all SOF_IPC_EXT types Pierre-Louis Bossart (3): ASoC: SOF: control: remove const in sizeof() ASoC: SOF: topology: remove const in sizeof() ASoC: SOF: sof-audio: remove goto used for force-nocodec support sound/soc/sof/control.c | 20 ++++++++++---------- sound/soc/sof/loader.c | 5 +++++ sound/soc/sof/sof-audio.c | 10 +++------- sound/soc/sof/topology.c | 2 +- 4 files changed, 19 insertions(+), 18 deletions(-) -- 2.27.0
Collaborator
Author
|
Wow, surprisingly good results from CI. One new dmesg error from i915: And one case of existing bug: thesofproject/sof#3462 hittin on BSW. |
Member
|
filter suggested in thesofproject/sof-test#476 to work-around DRM issue |
Member
|
SOFCI TEST |
Collaborator
Except for Travis which has been lagging - in every PR, not just this one. https://travis-ci.org/github/thesofproject/linux/builds/739280506 has been received hours ago but not started yet. https://www.traviscistatus.com/ is all green right now. @xiulipan any idea? |
Collaborator
Author
|
Remaining Travis builds are in progress still, but they appear not to be stuck, so maybe they'll complete. If we have any actions specific to us, that cover the new patches (like running checkpatch on them), those are going to take extra time on this PR as we have 14000+ new commits. I got a Github error multiple times, before I could create the pull req (but it did work in the end). |
Collaborator
Author
|
Remaining Travis builds now completed... it seems they just took time. If we have any actions specific to us, that cover the new patches (like running checkpatch on them), those are going to take extra time on this kind of PR as we have 14000+ new commits. I got a Github error multiple times, before I could create the pull req (but it did work in the end). |
Member
Collaborator
Author
|
I pushed my sof-dev-rebase candidate to kv/merge/sof-dev-rebase-20201027 @plbossart @ranj063 @bardliao Results look good now, should we go ahead and merge? This time around, this will require forced rebases to multiple open PRs, but I don't see us lowering this number in a short timeframe, so from that perspective, we could just go ahead now. I'll continue with some local tests while waiting for your input. |
Collaborator
It's very difficult to look at delays because timestamps are surprisingly rare and we still have too many in unknown timezones. Here for instance (cc : @xiulipan) https://sof-ci.01.org/linuxpr/PR2538/build4792/checkpatch/ and https://sof-ci.01.org/linuxpr/PR2538/build4792/devicetest are in different timezones and they are both unknown timezones. This being said, I commented 17 hours ago that Travis had "been stuck for hours". Right now https://travis-ci.org/github/thesofproject/linux/jobs/739280507 says it started 9 hours ago and finished 8 hours ago. So this one was stuck at least for 8 hours before even starting. |
Collaborator
|
@kv2019i can you please try this exact command locally and compare the start of its output with https://travis-ci.org/github/thesofproject/linux/jobs/739280507 ? scripts/checkpatch.pl --strict --codespell -g 8290bd62dfe67dfbbd8177a4eb985c4592c1be05..10c34365cec335fdfcaf3bb32091bbcad97cf3fbIt seems checkpatch is confused again and this time it is not missing the merge base (which used to happen sometimes because of shallow --depth cloning). For now I just want to make sure it fails exactly the same on Travis. it also took too long and timed out but that's a different issue. |
bardliao
approved these changes
Oct 29, 2020
Collaborator
bardliao
left a comment
bardliao
left a comment
There was a problem hiding this comment.
I think we can go ahead to merge since CI test result is good.
|
@plbossart @ranj063 @kv2019i Please check @fredoh9's email for the test result detail. The test is still running, you can decided if this PR is good merge once you checked the result. Next time, you can also trigger a wilder test by yourself once the sof-ci/jenkins/pr-build step completed. |
Collaborator
Author
|
@marc-hb wrote:
No, output doesn't look same at all, so it is getting confused by the shallow clone for sure. Plus, even if it would have worked, it would have timed out still I think. I didn't have patience to let it run to end locally, but on this machine checkpatch churns through ~65patches/minute, so checking the whole set would have taken almost 4 hours. Our Travis job should just ignore these .. waste of compute cycles to check patches that have anyways been already merged. |
Collaborator
Thanks! I finally tested, reproduced, analyzed and understood this. Tentative "fix" submitted in .travis.yml PR #2543 Note https://travis-ci.org/github/thesofproject/linux/builds/740104633 will take hours and hours to complete because Travis.com just made travis.org mostly unusable: https://travis-ci.community/t/builds-hang-in-queued-state/10250 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First rebase after 5.10-rc1
FYI @marc-hb This is a potential interesting one for sof-test and CI infra.