qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL v2 1/3] target/hppa: Fix OS reboot issues


From: Michael Tokarev
Subject: Re: [PULL v2 1/3] target/hppa: Fix OS reboot issues
Date: Mon, 26 Jun 2023 15:22:42 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0

25.06.2023 14:20, Helge Deller wrote:

Is this a -stable material?  It applies cleanly to 8.0 and 7.2.

Yes, please.
At least for 8.0 I think it should be added.
I didn't tested 7.2, but can do and would prefer it if could be added there too.

Just tested: The patches work nicely when applied to v7.2 as well.
Could you add them to -stable (or what is the process)?

Hmm. Now I'm a bit confused.

Initially I thought it's just this patch, 1/3, "target/hppa: Fix OS reboot 
issues",
to which I replied, is the one which should perhaps go to -stable.  But now I 
see
it is the whole series, all 3 changes, which are needed.

And for 7.2, things are a bit more interesting in this context: seabios-hppa 
version
in 7.2 is 6, it changed to version 7 in qemu 8.0, and changed further by this 
patchset.
There isn't much differences between seabios-hppa 6 and 7, so it's probably 
okay to
have it of version 7 in qemu-7.2-stable too (esp. since the change in there is 
another
bugfix, with debian 12 as a reproducer).

So, just to confirm: do we update seabios-hppa to this commit 
673d2595d4f773cc266cbf
(version 8) in both stable-7.2 and stable-8.0? :)

The changes in there seems to be okay anyway, should be good to have in -stable.

Besides, I'm having sort of difficult time cherry-picking the commit which 
updates
seabios-hppa submodule and hppa-firmware.img file, - git tells me there's a 
conflict
(even when applying to stable-8.0 branch) but I see no changes to this areas in-
between (yes, a conflict when applying to 7.2 is expected).  So I ended up in
doing:

staging-8.0$ git cherry-pick -xs 34ec3aea54368a92b62a55c656335885ba8c65ef

error: Could not read 20cf9c785c3aa493a39be532642883a7a1dc360c
warning: Cannot merge binary files: pc-bios/hppa-firmware.img (HEAD vs. 
34ec3aea54 (target/hppa: Update to SeaBIOS-hppa version 8))
Auto-merging pc-bios/hppa-firmware.img
CONFLICT (content): Merge conflict in pc-bios/hppa-firmware.img
Failed to merge submodule roms/seabios-hppa (commits don't follow merge-base)
CONFLICT (submodule): Merge conflict in roms/seabios-hppa
Recursive merging with submodules currently only supports trivial cases.
Please manually handle the merging of each conflicted submodule.
This can be accomplished with the following steps:
 - go to submodule (roms/seabios-hppa), and either merge commit 673d2595
   or update to an existing commit which has merged those changes
 - come back to superproject and run:

      git add roms/seabios-hppa

   to record the above merge or update
 - resolve any other conflicts in the superproject
 - commit the resulting index in the superproject
error: could not apply 34ec3aea54... target/hppa: Update to SeaBIOS-hppa 
version 8
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".

staging-8.0$ git checkout 34ec3aea54368a92b62a55c656335885ba8c65ef 
roms/seabios-hppa pc-bios/hppa-firmware.img

Updated 1 path from dc78364a05

staging-8.0$ git status

On branch staging-8.0
You are currently cherry-picking commit 34ec3aea54.
  (all conflicts fixed: run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
        modified:   pc-bios/hppa-firmware.img
        modified:   roms/seabios-hppa

staging-8.0$ git cherry-pick --continue
(commit changes)

Yes, this moves us to the right contents of both the submodule and the binary
file (the same as on master), but I don't see why it goes the way it goes.


Besides, it looks like this is the first change to submodules within qemu-stable
series..


Thanks,

/mjt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]