Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[llvm-objcopy] broken for x86_64 4.9 and older #480

Closed
nickdesaulniers opened this issue May 14, 2019 · 5 comments
Closed

[llvm-objcopy] broken for x86_64 4.9 and older #480

nickdesaulniers opened this issue May 14, 2019 · 5 comments
Assignees
@rupprecht
Labels
[ARCH] x86_64 This bug impacts ARCH=x86_64 [BUG] llvm A bug that should be fixed in upstream LLVM [FIXED][LLVM] 9 This bug was fixed in LLVM 9.0 [TOOL] llvm-objcopy The issue is relevant to LLVM objcopy

Comments

@nickdesaulniers
Copy link
Member

nickdesaulniers commented May 14, 2019 •
edited by nathanchance
Loading

copypasta from @nathanchance in ClangBuiltLinux/continuous-integration#164:

https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/199950119
https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/199950119
https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/199950121

llvm-objcopy-9: error: 'firmware/e100/d101m_ucode.bin.ihex': The file was not recognized as a valid object file

Relevant bits of Makefile:

fw-shipped-$(CONFIG_E100) += e100/d101m_ucode.bin e100/d101s_ucode.bin \
			     e100/d102e_ucode.bin
...
quiet_cmd_ihex  = IHEX    $@
    cmd_ihex  = $(OBJCOPY) -Iihex -Obinary $< $@

This was "resolved" upstream by torvalds@5620a0d, which we obviously can't backport. We could apply a local patch that removes the fw-shipped rule in the Makefile or fix llvm-objcopy (if it is even broken).

cc @rupprecht
@nickdesaulniers nickdesaulniers added [BUG] linux A bug that should be fixed in the mainline kernel. [PATCH] Exists There is a patch that fixes this issue [ARCH] x86_64 This bug impacts ARCH=x86_64 Needs Backport Should be backported to either linux-stable tree or latest llvm release branch. [TOOL] llvm-objcopy The issue is relevant to LLVM objcopy labels May 14, 2019
@rupprecht
Copy link

rupprecht commented May 14, 2019 •
edited by nickdesaulniers
Loading

ihex support is coming in D60270, but I haven't had any time in the past few weeks to review it.

@nickdesaulniers
Copy link
Member Author

cool, no rush then; I'll revert the use of llvm-objcopy for our CI for now. I'd prefer to simply add the support then on the LLVM side, since we're so close.

@nickdesaulniers nickdesaulniers added [BUG] llvm A bug that should be fixed in upstream LLVM [PATCH] Submitted A patch has been submitted for review and removed [BUG] linux A bug that should be fixed in the mainline kernel. [PATCH] Exists There is a patch that fixes this issue labels May 14, 2019
@nickdesaulniers nickdesaulniers added the low priority This bug is not critical and not a priority label May 14, 2019
@nathanchance
Copy link
Member

D60270 appears to work fine, I just applied it locally to test.

It does appear that it was broken up into reading/writing but I can't find the reading half on Phabricator (which we need).

I was able to apply it locally using these two commands:

curl -LSs 'https://reviews.llvm.org/D60270?id=193910&download=true' | git apply -3 -p0 --directory=llvm --exclude=llvm/tools/llvm-objcopy/CopyConfig.cpp

curl -LSs 'https://reviews.llvm.org/D60270?download=true' | git apply -3 -p0 --directory=llvm --include=llvm/tools/llvm-objcopy/CopyConfig.cpp

nickdesaulniers added a commit to ClangBuiltLinux/continuous-integration that referenced this issue May 14, 2019
@nickdesaulniers
Revert "call correct version check function"
b55baf4 
This reverts commit 4b9394a.

ClangBuiltLinux/linux#480
#164
nickdesaulniers added a commit to ClangBuiltLinux/continuous-integration that referenced this issue May 14, 2019
@nickdesaulniers
Revert "turn on objcopy by default for all targets"
696f9a5 
This reverts commit e9f08e5.

ClangBuiltLinux/linux#480
#164
@nickdesaulniers nickdesaulniers mentioned this issue May 14, 2019
Merged
nickdesaulniers added a commit to ClangBuiltLinux/continuous-integration that referenced this issue May 14, 2019
@nickdesaulniers
Revert "turn on objcopy by default for all targets"
684262f 
This reverts commit e9f08e5.

ClangBuiltLinux/linux#480
#164
@nathanchance nathanchance mentioned this issue May 31, 2019
Closed
@nickdesaulniers nickdesaulniers mentioned this issue Jun 26, 2019
Open
10 tasks
@nickdesaulniers
Copy link
Member Author

Fixed: https://reviews.llvm.org/rL361949

Maybe time to try llvm-objcopy again.

@nickdesaulniers nickdesaulniers added [FIXED][LLVM] 9 This bug was fixed in LLVM 9.0 and removed Needs Backport Should be backported to either linux-stable tree or latest llvm release branch. [PATCH] Submitted A patch has been submitted for review labels Jul 21, 2019
@nathanchance
Copy link
Member

It is still broken, even with this patch: ClangBuiltLinux/continuous-integration#183 (comment)

I'd be fine with whitelisting 4.4 but that will add some complexity to either driver.sh or our Travis matrix.

@tpimh tpimh removed the low priority This bug is not critical and not a priority label Sep 28, 2019
nickdesaulniers added a commit to ClangBuiltLinux/continuous-integration that referenced this issue Oct 4, 2019
@nickdesaulniers
selectively re-enable llvm-objcopy
c810b09 
just for arm64, back to LTS 4.9.

4.4 is still broken:
#183 (comment)

Previously reverted in 684262f

ClangBuiltLinux/linux#480
#164
@nickdesaulniers nickdesaulniers mentioned this issue Oct 4, 2019
Closed
nathanchance pushed a commit that referenced this issue Mar 6, 2020
@alexdeucher
drm/amd/display: Clear link settings on MST disable connector
5ac7fd2 
[Why]
If we have a single MST display and we disconnect it, we dont disable that
link. This causes the old link settings to still exist

Now on a replug for MST we think its a link loss and will try to reallocate
mst payload which will fail, throwing warning below.

[  129.374192] [drm] Failed to updateMST allocation table forpipe idx:0
[  129.374206] ------------[ cut here ]------------
[  129.374284] WARNING: CPU: 14 PID: 1710 at
drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/core/dc_link.c:3153
dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu]

[  129.374285] Modules linked in: amdgpu(OE) amd_iommu_v2 gpu_sched ttm
drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt
binfmt_misc nls_iso8859_1 edac_mce_amd snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio kvm snd_hda_codec_hdmi snd_hda_intel
snd_intel_nhlt snd_hda_codec irqbypass snd_hda_core snd_hwdep snd_pcm
snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul snd_seq
crc32_pclmul ghash_clmulni_intel snd_seq_device snd_timer snd aesni_intel
eeepc_wmi crypto_simd asus_wmi joydev cryptd sparse_keymap input_leds
soundcore video glue_helper wmi_bmof mxm_wmi k10temp ccp mac_hid
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4
hid_generic usbhid hid igb i2c_algo_bit ahci dca i2c_piix4 libahci
gpio_amdpt wmi gpio_generic

[  129.374318] CPU: 14 PID: 1710 Comm: kworker/14:2 Tainted: G        W  OE     5.4.0-rc7bhawan+ #480
[  129.374318] Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 0515 03/30/2017
[  129.374397] Workqueue: events dm_irq_work_func [amdgpu]
[  129.374468] RIP: 0010:dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu]
[  129.374470] Code: 52 20 e8 1c 63 ad f4 48 8b 5d d0 65 48 33 1c 25 28 00
00 00 b8 01 00 00 00 75 16 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3
<0f> 0b e9 fa fe ff ff e8 ed 5b d6 f3 41 0f b6 b6 c4 02 00 00 48 c7
[  129.374471] RSP: 0018:ffff9f9141e7fcc0 EFLAGS: 00010246
[  129.374472] RAX: 0000000000000000 RBX: ffff91ef0762f800 RCX: 0000000000000000
[  129.374473] RDX: 0000000000000005 RSI: ffffffffc0c4a988 RDI: 0000000000000004
[  129.374474] RBP: ffff9f9141e7fd10 R08: 0000000000000005 R09: 0000000000000000
[  129.374475] R10: 0000000000000002 R11: 0000000000000001 R12: ffff91eebd510c00
[  129.374475] R13: ffff91eebd510e58 R14: ffff91ef052c01b8 R15: 0000000000000006
[  129.374476] FS:  0000000000000000(0000) GS:ffff91ef0ef80000(0000) knlGS:0000000000000000
[  129.374477] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  129.374478] CR2: 000055623ea01d50 CR3: 0000000408a8c000 CR4: 00000000003406e0
[  129.374479] Call Trace:
[  129.374550]  dc_link_reallocate_mst_payload+0x12e/0x150 [amdgpu]
[  129.374617]  dc_link_handle_hpd_rx_irq+0x6d4/0x6e0 [amdgpu]
[  129.374693]  handle_hpd_rx_irq+0x77/0x310 [amdgpu]
[  129.374768]  dm_irq_work_func+0x53/0x70 [amdgpu]
[  129.374774]  process_one_work+0x1fd/0x3f0
[  129.374776]  worker_thread+0x255/0x410
[  129.374778]  kthread+0x121/0x140
[  129.374780]  ? process_one_work+0x3f0/0x3f0
[  129.374781]  ? kthread_park+0x90/0x90
[  129.374785]  ret_from_fork+0x22/0x40

[How]
when we disable MST we should clear the cur link settings (lane_count=0 is
good enough). This will cause us to not reallocate payloads earlier than
expected and not throw the warning

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
jesec added a commit to jesec/android_kernel_samsung_sm8250 that referenced this issue Mar 27, 2020
@jesec
Revert "sm8250: convert G9810ZCU1ATBV firmwares to IHEX"
d9b5be7 
This reverts commit 7e69b09.

llvm-objcopy: error: '.ihex': The file was not recognized as a valid object file

ClangBuiltLinux/linux#480
nathanchance pushed a commit that referenced this issue Apr 1, 2020
@alexdeucher
drm/amd/display: Clear link settings on MST disable connector
6d0d645 
[Why]
If we have a single MST display and we disconnect it, we dont disable that
link. This causes the old link settings to still exist

Now on a replug for MST we think its a link loss and will try to reallocate
mst payload which will fail, throwing warning below.

[  129.374192] [drm] Failed to updateMST allocation table forpipe idx:0
[  129.374206] ------------[ cut here ]------------
[  129.374284] WARNING: CPU: 14 PID: 1710 at
drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/core/dc_link.c:3153
dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu]

[  129.374285] Modules linked in: amdgpu(OE) amd_iommu_v2 gpu_sched ttm
drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt
binfmt_misc nls_iso8859_1 edac_mce_amd snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio kvm snd_hda_codec_hdmi snd_hda_intel
snd_intel_nhlt snd_hda_codec irqbypass snd_hda_core snd_hwdep snd_pcm
snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul snd_seq
crc32_pclmul ghash_clmulni_intel snd_seq_device snd_timer snd aesni_intel
eeepc_wmi crypto_simd asus_wmi joydev cryptd sparse_keymap input_leds
soundcore video glue_helper wmi_bmof mxm_wmi k10temp ccp mac_hid
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4
hid_generic usbhid hid igb i2c_algo_bit ahci dca i2c_piix4 libahci
gpio_amdpt wmi gpio_generic

[  129.374318] CPU: 14 PID: 1710 Comm: kworker/14:2 Tainted: G        W  OE     5.4.0-rc7bhawan+ #480
[  129.374318] Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 0515 03/30/2017
[  129.374397] Workqueue: events dm_irq_work_func [amdgpu]
[  129.374468] RIP: 0010:dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu]
[  129.374470] Code: 52 20 e8 1c 63 ad f4 48 8b 5d d0 65 48 33 1c 25 28 00
00 00 b8 01 00 00 00 75 16 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3
<0f> 0b e9 fa fe ff ff e8 ed 5b d6 f3 41 0f b6 b6 c4 02 00 00 48 c7
[  129.374471] RSP: 0018:ffff9f9141e7fcc0 EFLAGS: 00010246
[  129.374472] RAX: 0000000000000000 RBX: ffff91ef0762f800 RCX: 0000000000000000
[  129.374473] RDX: 0000000000000005 RSI: ffffffffc0c4a988 RDI: 0000000000000004
[  129.374474] RBP: ffff9f9141e7fd10 R08: 0000000000000005 R09: 0000000000000000
[  129.374475] R10: 0000000000000002 R11: 0000000000000001 R12: ffff91eebd510c00
[  129.374475] R13: ffff91eebd510e58 R14: ffff91ef052c01b8 R15: 0000000000000006
[  129.374476] FS:  0000000000000000(0000) GS:ffff91ef0ef80000(0000) knlGS:0000000000000000
[  129.374477] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  129.374478] CR2: 000055623ea01d50 CR3: 0000000408a8c000 CR4: 00000000003406e0
[  129.374479] Call Trace:
[  129.374550]  dc_link_reallocate_mst_payload+0x12e/0x150 [amdgpu]
[  129.374617]  dc_link_handle_hpd_rx_irq+0x6d4/0x6e0 [amdgpu]
[  129.374693]  handle_hpd_rx_irq+0x77/0x310 [amdgpu]
[  129.374768]  dm_irq_work_func+0x53/0x70 [amdgpu]
[  129.374774]  process_one_work+0x1fd/0x3f0
[  129.374776]  worker_thread+0x255/0x410
[  129.374778]  kthread+0x121/0x140
[  129.374780]  ? process_one_work+0x3f0/0x3f0
[  129.374781]  ? kthread_park+0x90/0x90
[  129.374785]  ret_from_fork+0x22/0x40

[How]
when we disable MST we should clear the cur link settings (lane_count=0 is
good enough). This will cause us to not reallocate payloads earlier than
expected and not throw the warning

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rupprecht rupprecht

Labels
[ARCH] x86_64 This bug impacts ARCH=x86_64 [BUG] llvm A bug that should be fixed in upstream LLVM [FIXED][LLVM] 9 This bug was fixed in LLVM 9.0 [TOOL] llvm-objcopy The issue is relevant to LLVM objcopy
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rupprecht @tpimh @nickdesaulniers @nathanchance