| Summary: | app-emulation/qemu-9999: qemu-x86_64 segfaults on ppc64le (4K page size) when downloading go dependencies: unexpected fault address 0x0 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | darkbasic <darkbasic> |
| Component: | Current packages | Assignee: | Virtualization Team <virtualization> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | dilfridge, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | PPC64 | ||
| OS: | Linux | ||
| See Also: | https://gitlab.com/qemu-project/qemu/-/issues/1494 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
darkbasic
2023-02-22 11:03:01 UTC
Just some rough thoughts to start: - https://wiki.gentoo.org/wiki/Bisecting_with_live_ebuilds is how I normally do bisecting with live ebuilds (your setup seems similar) - For a bug that we're in the middle of, we're doing this: ``` [...] for x in $(seq 1 10); do # We deliberately exit *0* if it fails because we're bisecting for the bad commit, not good timeout 1m bin/llvm-tblgen \ -I /var/tmp/portage/sys-devel/llvm-16.0.0.9999/work/llvm/lib/TargetPowerPC \ -I /var/tmp/portage/sys-devel/llvm-16.0.0.9999/work/llvm/include/ \ -I /var/tmp/portage/sys-devel/llvm-16.0.0.9999/work/llvm/lib/Target/PowerPC/ \ /var/tmp/portage/sys-devel/llvm-16.0.0.9999/work/llvm/lib/Target/PowerPC/PPC.td \ -o /dev/null \ --gen-dag-isel \ -d /dev/null \ --time-phases \ --write-if-changed timeout_result=$? case ${timeout_result} in 124) # Timed out exit 1 ;; 0) ;; *) # Something else happened, skip exit 125 ;; esac done exit 0 ``` You might want to adjust it so that a bad exit code is *also* a failure, but you get the idea. Given you're automating the bisect, I'd say it's fine to give every run/commit several attempts to ensure it's definitely bad. (In reply to darkbasic from comment #0) > How can I stop the error code from propagating? Something like: > killall -9 qemu-x86_64 | enforce-it-to-always-return-success > Try: # Ignore the exit status of qemu-x86_64 killall -9 qemu-x86_64 || true (In reply to Sam James from comment #1) > Just some rough thoughts to start: > - https://wiki.gentoo.org/wiki/Bisecting_with_live_ebuilds is how I normally > do bisecting with live ebuilds (your setup seems similar) > - For a bug that we're in the middle of, we're doing this: > ``` > [...] > for x in $(seq 1 10); do > # We deliberately exit *0* if it fails because we're bisecting for > the bad commit, not good > timeout 1m bin/llvm-tblgen \ > -I > /var/tmp/portage/sys-devel/llvm-16.0.0.9999/work/llvm/lib/TargetPowerPC \ > -I > /var/tmp/portage/sys-devel/llvm-16.0.0.9999/work/llvm/include/ \ > -I > /var/tmp/portage/sys-devel/llvm-16.0.0.9999/work/llvm/lib/Target/PowerPC/ \ > > /var/tmp/portage/sys-devel/llvm-16.0.0.9999/work/llvm/lib/Target/PowerPC/PPC. > td \ > -o /dev/null \ > --gen-dag-isel \ > -d /dev/null \ > --time-phases \ > --write-if-changed > timeout_result=$? > > case ${timeout_result} in > 124) > # Timed out > exit 1 > ;; > 0) > ;; > *) > # Something else happened, skip > exit 125 > ;; > esac > done > > exit 0 > ``` > > You might want to adjust it so that a bad exit code is *also* a failure, but > you get the idea. > i.e. change 'exit 125' to 'exit 1' too. > i.e. change 'exit 125' to 'exit 1' too.
Now that I think about it might be wise to return 125 if the ebuild compilation fails for whatever reason, so to skip the commit while not marking it bad.
Finally bisected it: https://gitlab.com/qemu-project/qemu/-/issues/1494#note_1289797177 It took over 16 hours this time, thanks for your help! (In reply to darkbasic from comment #5) > Finally bisected it: > https://gitlab.com/qemu-project/qemu/-/issues/1494#note_1289797177 > > It took over 16 hours this time, thanks for your help! No problem! What I usually do as a sanity check is then revert that bad commit on top of master and verify that the problem is gone. > What I usually do as a sanity check is then revert that bad commit on top of master and verify that the problem is gone.
I've already gave it a quick try, but it's not trivial to revert that commit on top of git master and would require some digging into subsequent changes.
(In reply to darkbasic from comment #7) > > What I usually do as a sanity check is then revert that bad commit on top of master and verify that the problem is gone. > > I've already gave it a quick try, but it's not trivial to revert that commit > on top of git master and would require some digging into subsequent changes. ack :) https://en.wikipedia.org/wiki/Dell_Dimension#/media/File:Dell_Dimension_433SV_486.jpghttps://en.wikipedia.org/wiki/Dell_Dimension#/media/File:Dell_Dimension_433SV_486.jpghttps://en.wikipedia.org/wiki/Dell_Dimension#/media/File:Dell_Dimension_433SV_486.jpg I am using a Macbook Pro Here and remember something about whether powerpc is dependant on static-libraries or not: I See #Freescale lets look into their board here: Uses ARM: ok well anyway : Using Static Libraries: I see on gentoo it starts to bring in kernel headers : ->: so you need probably the entire kernel configured i can post mine: Its an Intel Macintosh so sorry if its non-conformant; im just waiting on the build to actually start since if your not using any specific set of useflags it seems to build when i go to rebuild it it starts erroring: "but whatever i need to correct my system anyway from trying to downgrade bluetooth to use alsa: -> You can switch the EAPI it doesnt mean that itll Build the Binary: https://pastebin.com/CNDvibHS The Amiga PowerPC G4: ah ok thats what i was loooking for: OK : Jaguar Web Browser sees macOS Using Linux-Kernel Translation: ok as im typing im taking a ram hit so hmm include a disk partition of about 32GB for the TMPFS ->: ok and wherever your swaps going lets say another 8GB: im theorizing when the sysfs is used up itll start swapping not RAM: k could be why these builds are failing: as well as Compiler Flag Options: -Os --jobs=1 --load-average=1 and sitting out the ram hit its successfully compiled: and dont subtract useflags except for test -test and include whichever things you need and for windows you need the bochs tools iso for a standard emulation installation: I hope im getting this right i havent really tried doing it: ->: #not using #gtk or #virtiolibvirtmanager: ->: is what QEMU does not the Linux Kernel: is scheduled translation vs a actual to be scheduled in the scheduler translation?: //////////Running QEMU in BOCHS-Like-Mode: Just RUN it: What it Uses: a Virtual SEABIOS: the SEABIOS is like a Dell Dimension Bios and hardware Configured Emulator based on the CPU: it doesnt particularly have any form of acceleration is what bochs is doing: /////////What QEMU is allowing it to do: use LSPCI or view Hardware and Device on WINDOWS:\\ -device i82801h11,bus=pci.00,addr=00,id=Intel DRAM Controller \ -device ioh3420 (In reply to Anthony Brown from comment #12) This is a Gentoo bug for a specific problem in QEMU. This is not the right venue for whatever your problem is. |
