Date: Tue, 12 Nov 2019 00:23:53 +0000 From: bugzilla-noreply@freebsd.org To: emulation@FreeBSD.org Subject: [Bug 241728] linuxkpi: panics after loading radeonkms kernel module (data storage interrupt trap) Message-ID: <bug-241728-4077-WIjwkwU5U6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-241728-4077@https.bugs.freebsd.org/bugzilla/> References: <bug-241728-4077@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241728 --- Comment #24 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Piotr Kubaj from comment #0) [This note reports 5 or so more pcpu_entry_'s that are LOCAL -- and notes that there are around 300 vnet_entry_'s that are LOCAL (around 98 GLOBAL). I start with pcpu_entry_'s.] For my context, beyond linuxkpi.kld there is also . . . ipfw.kld having: 469: 0000000000000000 8 OBJECT LOCAL DEFAULT 20 pcpu_entry_dyn_hp siftr.kld having: 91: 0000000000000000 56 OBJECT LOCAL DEFAULT 18 pcpu_entry_ss which would seem likely to have the same type of problem as linuxkpi.kld ended up with because of the "LOCAL" final results in the .kld files. ipfw, linuxkpi, and siftr were mentioned in bug 232387 (but possibly not all completely fixed). This prompted for me to check my clang 8.0.1 ELFv1 based build tree targeting powerpc64 to see teh above. I have not tested loading ipfw.ko or siftr.ko . I just looked for the pcpu_entry_<?> information via readelf on the .kld files. Going the other way, looking for .kld files with pcpu_entry_ text in that build that I've been looking at: It has 3 more LOCAL's beyond the 3 noted so far: pcpu_entry_epair_dpcpu ( /usr/src/sys/net/if_epair.c ) pcpu_entry_tasklet_worker ( sys/compat/linuxkpi/common/src/linux_tasklet.c ) pcpu_entry_linux_epoch_record ( sys/compat/linuxkpi/common/src/linux_rcu.c ) The first uses DPCPU_DEFINE and the other two use DPCPU_DEFINE_STATIC, but LOCAL can be forced other ways than the macro definitions ( as in the earli= er linuxkld.kld notes ). For reference: # find /usr/obj/powerpc64vtsc_clang_altbinutils/ -name '*.kld' -exec readel= f -a {} \; | grep pcpu_entry_ 000000000020 017800000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_pmc_sampled + 0 000000000168 017800000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_pmc_sampled + 0 376: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND pcpu_entry_pmc_sampled 000000000010 005000000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_epair_dpcpu + 0 00000000017d 005000000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_epair_dpcpu + 0 80: 0000000000000000 56 OBJECT LOCAL DEFAULT 19 pcpu_entry_epair_dpcpu 0000000001f8 01d500000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_dyn_hp + 0 000000015f9b 01d500000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_dyn_hp + 0 469: 0000000000000000 8 OBJECT LOCAL DEFAULT 20 pcpu_entry_dyn_hp 0000000000f8 018400000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_linux_idr_cache + 0 0000000001e0 020b00000026 R_PPC64_ADDR64 0000000000000080 pcpu_entry_linux_epoch_record + 0 000000000290 01c000000026 R_PPC64_ADDR64 0000000000000200 pcpu_entry_tasklet_worker + 0 00000001f60b 018400000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_linux_idr_cache + 0 00000004e25d 020b00000026 R_PPC64_ADDR64 0000000000000080 pcpu_entry_linux_epoch_record + 0 0000000647e9 01c000000026 R_PPC64_ADDR64 0000000000000200 pcpu_entry_tasklet_worker + 0 388: 0000000000000000 48 OBJECT LOCAL DEFAULT 19 pcpu_entry_linux_idr_cache 448: 0000000000000200 256 OBJECT LOCAL DEFAULT 19 pcpu_entry_tasklet_worker 523: 0000000000000080 384 OBJECT LOCAL DEFAULT 19 pcpu_entry_linux_epoch_record 000000000020 005b00000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_s= s + 0 0000000030e5 005b00000026 R_PPC64_ADDR64 0000000000000000 pcpu_entry_s= s + 0 91: 0000000000000000 56 OBJECT LOCAL DEFAULT 18 pcpu_entry_ss The list for vnet_entry_'s that are LOCAL in my build is very long, around 300 of them. I've not done anything to certify that they all lead to failure. On what I've done it just suggests that they need consideration. There are around 98 vnet_entry_'s that are GLOBAL. If there are more than just pcpu_entry_'s and vnet_entry_'s that would have the issue, than I'm unaware and have not covered them at all. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-241728-4077-WIjwkwU5U6>