On 18/02/2020 23:59, Cédric Le Goater wrote:
> On 2/18/20 1:48 PM, Cédric Le Goater wrote:
>> On 2/18/20 10:40 AM, Cédric Le Goater wrote:
>>> On 2/18/20 10:10 AM, Alexey Kardashevskiy wrote:
>>>>
>>>>
>>>> On 18/02/2020 20:05, Alexey Kardashevskiy wrote:
>>>>>
>>>>>
>>>>> On 18/02/2020 18:12, Cédric Le Goater wrote:
>>>>>> On 2/18/20 1:30 AM, Alexey Kardashevskiy wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 17/02/2020 20:48, Cédric Le Goater wrote:
>>>>>>>> On 2/17/20 3:12 AM, Alexey Kardashevskiy wrote:
>>>>>>>>> The following changes since commit
>>>>>>>>> 05943fb4ca41f626078014c0327781815c6584c5:
>>>>>>>>>
>>>>>>>>> ppc: free 'fdt' after reset the machine (2020-02-17 11:27:23 +1100)
>>>>>>>>>
>>>>>>>>> are available in the Git repository at:
>>>>>>>>>
>>>>>>>>> g...@github.com:aik/qemu.git tags/qemu-slof-20200217
>>>>>>>>>
>>>>>>>>> for you to fetch changes up to
>>>>>>>>> ea9a03e5aa023c5391bab5259898475d0298aac2:
>>>>>>>>>
>>>>>>>>> pseries: Update SLOF firmware image (2020-02-17 13:08:59 +1100)
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>> Alexey Kardashevskiy (1):
>>>>>>>>> pseries: Update SLOF firmware image
>>>>>>>>>
>>>>>>>>> pc-bios/README | 2 +-
>>>>>>>>> pc-bios/slof.bin | Bin 931032 -> 968560 bytes
>>>>>>>>> roms/SLOF | 2 +-
>>>>>>>>> 3 files changed, 2 insertions(+), 2 deletions(-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *** Note: this is not for master, this is for pseries
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hello Alexey,
>>>>>>>>
>>>>>>>> QEMU fails to boot from disk. See below.
>>>>>>>
>>>>>>>
>>>>>>> It does boot mine (fedora 30, ubuntu 18.04), see below. I believe I
>>>>>>> could have broken something but I need more detail. Thanks,
>>>>>>
>>>>>> fedora31 boots but not ubuntu 19.10. Could it be GRUB version 2.04 ?
>>>>>
>>>>>
>>>>> No, not that either:
>>>>
>>>>
>>>> but it might be because of power9 - I only tried power8, rsyncing the
>>>> image to a p9 machine now...
>>>
>>> Here is the disk :
>>>
>>> Disk /dev/sda: 50 GiB, 53687091200 bytes, 104857600 sectors
>>> Disk model: QEMU HARDDISK
>>> Units: sectors of 1 * 512 = 512 bytes
>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>> Disklabel type: gpt
>>> Disk identifier: 27DCE458-231A-4981-9FF1-983F87C2902D
>>>
>>> Device Start End Sectors Size Type
>>> /dev/sda1 2048 16383 14336 7M PowerPC PReP boot
>>> /dev/sda2 16384 100679679 100663296 48G Linux filesystem
>>> /dev/sda3 100679680 104857566 4177887 2G Linux swap
>>>
>>>
>>> GPT ?
>>
>> For the failure, I bisected up to :
>>
>> f12149908705 ("ext2: Read all 64bit of inode number")
>
> Here is a possible fix for it. I did some RPN on my hp28s in the past
> but I am not forth fluent.
you basically zeroed the top bits by shifting them too far right :)
The proper fix I think is:
- 32 lshift or
+ 20 lshift or
I keep forgetting it is all in hex. Can you please give it a try? My
128GB disk does not expose this problem somehow. Thanks,
>
> "slash not found" is still there though.
>
> Cheers,
>
> C.
>
>
> From 92dc9f6dc7c6434419306d5a382adb42169b712a Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <c...@kaod.org>
> Date: Tue, 18 Feb 2020 13:54:54 +0100
> Subject: [PATCH] ext2: Fix 64bit inode number
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Fixes: f12149908705 ("ext2: Read all 64bit of inode number")
> Signed-off-by: Cédric Le Goater <c...@kaod.org>
> ---
> slof/fs/packages/ext2-files.fs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/slof/fs/packages/ext2-files.fs b/slof/fs/packages/ext2-files.fs
> index b6a7880bd88e..f1d9fdfd67e2 100644
> --- a/slof/fs/packages/ext2-files.fs
> +++ b/slof/fs/packages/ext2-files.fs
> @@ -152,7 +152,7 @@ CONSTANT /ext4-ee
> dup
> 8 + l@-le \ reads bg_inode_table_lo
> swap 28 + l@-le \ reads bg_inode_table_hi
> - 32 lshift or
> + 32 rshift or
> block-size @ * \ # in group, inode table
> swap inode-size @ * + xlsplit seek drop inode @ inode-size @ read drop
> ;
>
--
Alexey
