-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sbin/make.cross: Resolve 'Cannot find h8300-linux under <crosstool/fi… #1
Open
bhumikagoyal
wants to merge
8
commits into
fengguang:master
Choose a base branch
from
bhumikagoyal:changeinmake.cross
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains 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
2017-06-10 13:16:23.543596500 [lkp process-result-queue 18815] /lkp/lkp/src/stats/kmsg:116:in `block in <main>': invalid byte sequence in US-ASCII (ArgumentError) 2017-06-10 13:16:23.573724500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/kmsg:113:in `each' 2017-06-10 13:16:23.583804500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/kmsg:113:in `<main>' 2017-06-10 13:16:23.599444500 ERROR [lkp process-result-queue 18815] /lkp/lkp/src/stats/kmsg /result/boot/1/vm-vp-quantal-x86_64/quantal-core-x86_64.cgz/x86_64-randconfig-w0-05080104/gcc-6/16b76293c5c81e6345323d7aef41b26e8390f62d/492/kmsg < /result/boot/1/vm-vp-quantal-x86_64/quantal-core-x86_64.cgz/x86_64-randconfig-w0-05080104/gcc-6/16b76293c5c81e6345323d7aef41b26e8390f62d/492/kmsg exit code 1, check /dev/shm/lkp-stats.5u1qdVNZ 2017-06-10 13:16:23.671045500 ERROR [lkp process-result-queue 18815] Error extract stats /result/boot/1/vm-vp-quantal-x86_64/quantal-core-x86_64.cgz/x86_64-randconfig-w0-05080104/gcc-6/16b76293c5c81e6345323d7aef41b26e8390f62d/492 2017-06-10 13:16:33.717300500 WARN [lkp run-split-dmesg 122789] /cc/COM-serial/lkp-a05 seems to become inactive 2017-06-10 13:16:36.436355500 WARN [lkp process-result-queue 18815] moved bad result from /result/boot/1/vm-vp-quantal-x86_64/quantal-core-x86_64.cgz/x86_64-randconfig-w0-05080104/gcc-6/16b76293c5c81e6345323d7aef41b26e8390f62d/492 to /result/bad/boot/1/vm-vp-quantal-x86_64/quantal-core-x86_64.cgz/x86_64-randconfig-w0-05080104/gcc-6/16b76293c5c81e6345323d7aef41b26e8390f62d/492 ' Signed-off-by: Xiaolong Ye <[email protected]> Signed-off-by: Philip Li <[email protected]>
Now xfstests has remove btrfs/010 and xfs/191 can pass, so update them. Signed-off-by: Xiang Dai <[email protected]> Signed-off-by: Philip Li <[email protected]>
To fix the below issue: 2017-06-10 13:56:15.136104500 [lkp process-result-queue 18815] /lkp/lkp/src/stats/ftrace:24:in `block in generate_prefix': uninitialized constant BDI_DEV_MAPPING (NameError) 2017-06-10 13:56:15.174646500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/ftrace:19:in `each' 2017-06-10 13:56:15.199752500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/ftrace:19:in `generate_prefix' 2017-06-10 13:56:15.206208500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/ftrace:36:in `normlize_record' 2017-06-10 13:56:15.210084500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/ftrace:64:in `normlize_event_data' 2017-06-10 13:56:15.222231500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/ftrace:113:in `parse_event' 2017-06-10 13:56:15.239066500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/ftrace:117:in `block in <main>' 2017-06-10 13:56:15.246140500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/ftrace:116:in `each' 2017-06-10 13:56:15.258365500 [lkp process-result-queue 18815] from /lkp/lkp/src/stats/ftrace:116:in `<main>' Signed-off-by: Xiang Dai <[email protected]> Signed-off-by: Philip Li <[email protected]>
Requested by Niklas: "now I have finally found the time to expose it over the native git protocol." CC: Niklas Söderlund <[email protected]> Signed-off-by: Fengguang Wu <[email protected]> Signed-off-by: Philip Li <[email protected]>
Now obj_pmalloc_mt can not run since bugs, community will fix it in the future. So ignore it util it has been fixed. Signed-off-by: Xiang Dai <[email protected]> Signed-off-by: Philip Li <[email protected]>
…n't grow to 0x4a28000 The issue is as below: obj_tx_add_range_direct/TEST1: SETUP (check/non-pmem/debug/pmemcheck) obj_tx_add_range_direct/TEST1: START: obj_tx_add_range_direct [MATCHING FAILED, COMPLETE FILE (pmemcheck1.log) BELOW] ... pmemcheck1.log.match:1 ==$(*)== pmemcheck$(*) pmemcheck1.log:1 ==67474== pmemcheck-0.2, a simple persistent store checker pmemcheck1.log.match:2 ==$(*)== Copyright$(*) pmemcheck1.log:2 ==67474== Copyright (c) 2014-2016, Intel Corporation pmemcheck1.log.match:3 ==$(*)== Using Valgrind-$(*) pmemcheck1.log:3 ==67474== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info pmemcheck1.log.match:4 ==$(*)== Command: ./obj_tx_add_range_direct$(*) pmemcheck1.log:4 ==67474== Command: ./obj_tx_add_range_direct /tmp/tmp.WoPbIa5vlI//test_obj_tx_add_range_direct1😘⠝⠧⠍⠇ɗNVMLӜ⥺🙋/testfile1 pmemcheck1.log.match:5 ==$(*)== Parent PID: $(*) pmemcheck1.log:5 ==67474== Parent PID: 67379 pmemcheck1.log.match:6 ==$(*)== pmemcheck1.log:6 ==67474== pmemcheck1.log.match:7 ==$(*)== Number of stores not made persistent: 0 pmemcheck1.log:7 ==67474== brk segment overflow in thread fengguang#1: can't grow to 0x4a27000 <=== when allocate memory below 128k, system use brk rather than mmap as default, while mmap behave better. The edge can be changed by MALLOC_MMAP_THRESHOLD_. Set it as zero can make the libc malloc use mmap earlier to ensure system allocate enough brk segment. Signed-off-by: Xiang Dai <[email protected]> Signed-off-by: Philip Li <[email protected]>
Hi, This patch can be applied to f2fs/dev-test, which includes changes from my previous patch. Thanks. > Hi Qiuyang, > > [auto build test ERROR on f2fs/dev] > [also build test ERROR on v4.12-rc4 next-20170607] > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] > > url: https://github.com/0day-ci/linux/commits/sunqiuyang/f2fs-dax-implement-direct-access/20170608-140734 > base: https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev > config: x86_64-randconfig-x010-201723 (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: Signed-off-by: Xiaolong Ye <[email protected]> Signed-off-by: Philip Li <[email protected]>
fengguang
pushed a commit
that referenced
this pull request
Jul 4, 2017
…to 0x4a28000 The issue is as below: obj_tx_add_range_direct/TEST1: SETUP (check/non-pmem/debug/pmemcheck) obj_tx_add_range_direct/TEST1: START: obj_tx_add_range_direct [MATCHING FAILED, COMPLETE FILE (pmemcheck1.log) BELOW] ... pmemcheck1.log.match:1 ==$(*)== pmemcheck$(*) pmemcheck1.log:1 ==67474== pmemcheck-0.2, a simple persistent store checker pmemcheck1.log.match:2 ==$(*)== Copyright$(*) pmemcheck1.log:2 ==67474== Copyright (c) 2014-2016, Intel Corporation pmemcheck1.log.match:3 ==$(*)== Using Valgrind-$(*) pmemcheck1.log:3 ==67474== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info pmemcheck1.log.match:4 ==$(*)== Command: ./obj_tx_add_range_direct$(*) pmemcheck1.log:4 ==67474== Command: ./obj_tx_add_range_direct /tmp/tmp.WoPbIa5vlI//test_obj_tx_add_range_direct1😘⠝⠧⠍⠇ɗNVMLӜ⥺🙋/testfile1 pmemcheck1.log.match:5 ==$(*)== Parent PID: $(*) pmemcheck1.log:5 ==67474== Parent PID: 67379 pmemcheck1.log.match:6 ==$(*)== pmemcheck1.log:6 ==67474== pmemcheck1.log.match:7 ==$(*)== Number of stores not made persistent: 0 pmemcheck1.log:7 ==67474== brk segment overflow in thread #1: can't grow to 0x4a27000 <=== when allocate memory below 128k, system use brk rather than mmap as default, while mmap behave better. The edge can be changed by MALLOC_MMAP_THRESHOLD_. Set it as zero can make the libc malloc use mmap earlier to ensure system allocate enough brk segment. Signed-off-by: Xiang Dai <[email protected]> Signed-off-by: Philip Li <[email protected]>
dbshch
pushed a commit
to dbshch/lkp-tests
that referenced
this pull request
Jul 19, 2017
To capture below error: kern :warn : [ 57.182374 ] ============================================ kern :warn : [ 57.182582 ] WARNING: possible recursive locking detected kern :warn : [ 57.182788 ] 4.12.0-rc4-wt-ath-05992-g2728455 fengguang#1 Not tainted kern :warn : [ 57.183009 ] -------------------------------------------- kern :warn : [ 57.183237 ] repro-8659a50e./13114 is trying to acquire lock: kern :warn : [ 57.183449 ] (sb_writers#5){.+.+.+}, at: [<ffffffff816956c2>] do_iter_write+0x352/0x7d0 kern :warn : [ 57.183781 ] but task is already holding lock: kern :warn : [ 57.184087 ] (sb_writers#5){.+.+.+}, at: [<ffffffff81696f6d>] do_sendfile+0x9bd/0xcc0 kern :warn : [ 57.184407 ] other info that might help us debug this: kern :warn : [ 57.184705 ] Possible unsafe locking scenario: kern :warn : [ 57.184998 ] CPU0 kern :warn : [ 57.185170 ] ---- kern :warn : [ 57.185332 ] lock(sb_writers#5); kern :warn : [ 57.185510 ] lock(sb_writers#5); kern :warn : [ 57.185685 ] *** DEADLOCK *** kern :warn : [ 57.186067 ] May be due to missing lock nesting notation Signed-off-by: Xiaolong Ye <[email protected]> Signed-off-by: Philip Li <[email protected]>
dbshch
pushed a commit
to dbshch/lkp-tests
that referenced
this pull request
Sep 27, 2017
fix the following issues -------- patching file runtest/syscalls Hunk fengguang#1 FAILED at 744. 1 out of 1 hunk FAILED -- saving rejects to file runtest/syscalls.rej -------- Signed-off-by: Hailin Gu <[email protected]> Signed-off-by: Philip Li <[email protected]>
dbshch
pushed a commit
to dbshch/lkp-tests
that referenced
this pull request
Nov 1, 2017
To help auto bisect a number of boot errors. For example, [ 956.671551] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 956.671557] IP: pgtable_trans_huge_withdraw+0x4c/0xc0 ... [ 956.671650] RIP: pgtable_trans_huge_withdraw+0x4c/0xc0 RSP: ffffc90026b07c20 We failed to auto bisect it since the important "RIP:pgtable_trans_huge_withdraw" feature is missed. The remaining ones like "dmesg.BUG:unable_to_handle_kernel" are way too common. wfg@inn /result/stress-ng/1s-memory-performance/lkp-bdw-ep6/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/bb176f67090ca54869fc1262c913aa69d2ede070/0% cat dmesg.json { "dmesg.boot_failures": [ 1 ], "dmesg.BUG:unable_to_handle_kernel": [ 1 ], "dmesg.Oops:#[##]": [ 1 ], "dmesg.Kernel_panic-not_syncing:Fatal_exception": [ 1 ], ... After patch, $ /c/lkp-tests/stats/dmesg dmesg-lkp-bdw-ep6:20171029153441:x86_64-rhel-7.2:gcc-6:4.14.0-rc6:1 boot_failures: 1 # BUG: unable to handle kernel BUG:unable_to_handle_kernel: 1 message:BUG:unable_to_handle_kernel: [ 328.471917] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 pattern:BUG:unable_to_handle_kernel: BUG: unable to handle kernel # Oops: Oops:#[##]: 1 message:Oops:#[##]: [ 328.471930] Oops: 0000 [fengguang#1] SMP pattern:Oops:#[##]: Oops: + # RIP: pgtable_trans_huge_withdraw+0x + RIP:pgtable_trans_huge_withdraw: 1 + message:RIP:pgtable_trans_huge_withdraw: [ 328.471980] RIP: 0010:pgtable_trans_huge_withdraw+0x4c/0xc0 + pattern:RIP:pgtable_trans_huge_withdraw: RIP: pgtable_trans_huge_withdraw+0x # Kernel panic - not syncing: Fatal exception Kernel_panic-not_syncing:Fatal_exception: 1 message:Kernel_panic-not_syncing:Fatal_exception: [ 328.489702] Kernel panic - not syncing: Fatal exception pattern:Kernel_panic-not_syncing:Fatal_exception: Kernel panic - not syncing: Fatal exception timestamp:last: 328.496311 timestamp:BUG:unable_to_handle_kernel: 328.471917 timestamp:Oops:#[##]: 328.471930 timestamp:RIP:pgtable_trans_huge_withdraw: 328.471980 timestamp:Kernel_panic-not_syncing:Fatal_exception: 328.489702 CC: "Kirill A. Shutemov" <[email protected]> Signed-off-by: Fengguang Wu <[email protected]> Signed-off-by: Philip Li <[email protected]>
fengguang
pushed a commit
that referenced
this pull request
Jun 20, 2018
cpu-hotplug needs more than 1G memory, switch it to suitable tbox. fix the following issue: ------ [ 3.010139] Kernel panic - not syncing: Out of memory and no killable processes... [ 3.010139] [ 3.011128] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0 #1 [ 3.011128] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 3.011128] Call Trace: [ 3.011128] dump_stack+0x5c/0x7c [ 3.011128] panic+0xd5/0x242 [ 3.011128] ? dump_header+0x193/0x2ac [ 3.011128] out_of_memory+0x3cb/0x4d0 ------ Signed-off-by: Chen Rong <[email protected]> Signed-off-by: Philip Li <[email protected]>
fengguang
pushed a commit
that referenced
this pull request
Apr 23, 2019
…#1]" to align with others from [ 29.493015 ] Bad pagetable: 000f [#1] PTI to [ 29.493015 ] Bad pagetable: # [#1] PTI Signed-off-by: Chen Rong <[email protected]> Signed-off-by: Philip Li <[email protected]>
fengguang
pushed a commit
that referenced
this pull request
Aug 5, 2019
fix the following issue ------ Run: "Double-Precision Whetstone": Illegal instruction; aborting ------ the root cause is benchmark unixbench has updated, patch unixbench.patch doesn't work. ------ liuyd@inn:~/byte-unixbench$ patch -p1 < unixbench.patch patching file UnixBench/Makefile Hunk #1 FAILED at 86. 1 out of 1 hunk FAILED -- saving rejects to file UnixBench/Makefile.rej ------ adjust unixbench.pacth and repack, unixbench runs well. ------ liuyd@inn:/result/unixbench/performance-30%-300s-whetstone-double-ucode=0x7000017/lkp-bdw-de1/debian-x86_64-2019-05-14.cgz/x86_64-rhel-7.6/gcc-7/v5.2/22$ cat unixbench.json { "unixbench.score": [ 3310.6 ], "unixbench.workload": [ 8484974.6 ] } ------ Signed-off-by: Liu Yiding <[email protected]> Signed-off-by: Philip Li <[email protected]>
fengguang
pushed a commit
that referenced
this pull request
Apr 2, 2020
fix the following issue: sed: -e expression #1, char 16: unterminated `s' command Signed-off-by: Ma XinJian <[email protected]> Signed-off-by: Philip Li <[email protected]>
fengguang
pushed a commit
that referenced
this pull request
Apr 2, 2020
fix the following issue: ``` 16:28:11 ERROR| [stderr] Checking Testing Environment... 16:28:11 ERROR| [stderr] Linux vm-snb-872bde802a4e 5.4.0-rc2-00278-gda0c9ea146cbe #1 SMP Mon Oct 7 07:38:09 CST 2019 x86_64 GNU/Linux 16:28:11 ERROR| [stderr] Virsh command line tool of libvirt: 3.0.0 16:28:11 ERROR| [stderr] sh: 1: libvirtd: not found 16:28:11 ERROR| [stderr] Traceback (most recent call last): ``` Signed-off-by: Zhou Hao <[email protected]> Signed-off-by: Philip Li <[email protected]>
fengguang
pushed a commit
that referenced
this pull request
Apr 2, 2020
fix the following issue: ``` 14:10:16 INFO | Testing item consumption 14:10:16 ERROR| [stderr] Checking Testing Environment... 14:10:16 ERROR| [stderr] Linux vm-snb-ssd-1f9e9baea779 5.4.0-rc2-00278-gda0c9ea146cbe #1 SMP Mon Oct 7 07:38:09 CST 2019 x86_64 GNU/Linux 14:10:16 ERROR| [stderr] Virsh command line tool of libvirt: 3.0.0 14:10:16 ERROR| [stderr] libvirtd (libvirt) 3.0.0 14:10:16 ERROR| [stderr] error: failed to connect to the hypervisor 14:10:16 ERROR| [stderr] error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory 14:10:16 ERROR| [stderr] ``` Signed-off-by: Zhou Hao <[email protected]> Signed-off-by: Philip Li <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
…les url> error
The make.cross file appends the architecture with "-linux" and then fetches from the link https://www.kernel.org/pub/tools/crosstool/files/bin/. Now on this link only h8300 is appended with "-elf" but actually the script is looking for "h8300-linux", so I made the make.cross script fetch "h8300-elf" instead of "h8300-linux.
Before this change when I ran ./make.cross ARCH=h8300 drivers/irqchip/ I got this error:
Cannot find h8300-linux under https://cdn.kernel.org/pub/tools/crosstool/files/bin check /tmp/crosstool-files
After this change, the script is able to fetch from the correct URL.
But even after this change when I run the make.cross command for drivers/irqchip I get this error:
/opt/gcc-4.9.0-nolibc/h8300-elf/bin/h8300-elf-ld: unrecognised emulation mode: h8300helf_linux
Supported emulations: h8300elf h8300helf h8300self h8300hnelf h8300snelf h8300sxelf h8300sxnelf
Maybe I can send a follow up patch for this issue.
and strangely when I run ./make.cross ARCH=h8300 drivers/irqchip/irq-renesas-h8s.o after incorporating my changes, the .o file is obtained which was not the case when compiled it for x86.