Message ID | 20200217021217.95766-1-aik@ozlabs.ru (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [PULL,SUBSYSTEM,qemu-pseries] pseries: Update SLOF firmware image | expand |
On Mon, Feb 17, 2020 at 01:12:17PM +1100, 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: > > git@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 Merged to ppc-for-5.0, thanks.
Hi Alexey, 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: > > git@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(-) I only received the cover, not the patch, have you posted it? I noticed on your repository you included a 'git shortlog' output in the commit description, thanks for that detail, much appreciated! Regards, Phil.
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: > > git@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. Thanks, C. QEMU Starting Build Date = Feb 17 2020 13:06:47 FW Version = git-42228d763f1fdb7b Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/vty@71000000 Populating /vdevice/nvram@71000001 Populating /pci@800000020000000 00 0800 (D) : 1af4 1004 virtio [ scsi ] Populating /pci@800000020000000/scsi@1 SCSI: Looking for devices 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" 00 1000 (D) : 1af4 1000 virtio [ net ] 00 2000 (D) : 1b36 000d serial bus [ usb-xhci ] No NVRAM common partition, re-initializing... Scanning USB XHCI: Initializing Using default console: /vdevice/vty@71000000 Welcome to Open Firmware Copyright (c) 2004, 2017 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Trying to load: from: /pci@800000020000000/scsi@1/disk@100000000000000 ... slash SCSI-DISK: Access beyond end of device ! Out of internal memory. SCSI-DISK: Access beyond end of device ! SCSI-DISK: Access beyond end of device ! SCSI-DISK: Access beyond end of device ! SCSI-DISK: Access beyond end of device ! SCSI-DISK: Access beyond end of device !
On 2/17/20 10:26 AM, Philippe Mathieu-Daudé wrote: > Hi Alexey, > > 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: >> >> git@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(-) > > I only received the cover, not the patch, have you posted it? OK I see the SLOF binary is almost 1MB. Maybe this got blocked by spam filter. FYI you can use 'git-format-patch --no-binary' to emit the patch with the commit description but without the content. > > I noticed on your repository you included a 'git shortlog' output in the > commit description, thanks for that detail, much appreciated! > > Regards, > > Phil.
On Mon, Feb 17, 2020 at 11:24:11AM +0100, Philippe Mathieu-Daudé wrote: > On 2/17/20 10:26 AM, Philippe Mathieu-Daudé wrote: > > Hi Alexey, > > > > 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: > > > > > > git@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(-) > > > > I only received the cover, not the patch, have you posted it? > > OK I see the SLOF binary is almost 1MB. Maybe this got blocked by spam > filter. FYI you can use 'git-format-patch --no-binary' to emit the patch > with the commit description but without the content. Generally Alexey sends SLOF updates to me just as pull requests without patches in full, because a huge slab of base64 encoded firmware isn't particularly illuminating.
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: >> >> git@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, SLOF ********************************************************************** QEMU Starting Build Date = Feb 17 2020 13:06:47 FW Version = git-42228d763f1fdb7b Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/nvram@71000000 Populating /vdevice/vty@71000110 Populating /pci@800000020000000 00 0000 (D) : 1af4 1000 virtio [ net ] 00 0800 (D) : 1af4 1004 virtio [ scsi ] Populating /pci@800000020000000/scsi@1 SCSI: Looking for devices 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" No NVRAM common partition, re-initializing... Scanning USB Using default console: /vdevice/vty@71000110 Welcome to Open Firmware Copyright (c) 2004, 2017 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Trying to load: from: /pci@800000020000000/scsi@1/disk@100000000000000 ... Successfully loaded Fedora (5.5.0-rc5-le-guest_v5.5-rc5_a+fstn1) 30 (Thirty) Fedora (5.0.9-301.fc30.ppc64le) 30 (Thirty) Fedora (0-rescue-8f8bbec520a44fd09da6af8e0d2c6571) 30 (Thirty) > > Thanks, > > C. > > > QEMU Starting > Build Date = Feb 17 2020 13:06:47 > FW Version = git-42228d763f1fdb7b > Press "s" to enter Open Firmware. > > Populating /vdevice methods > Populating /vdevice/vty@71000000 > Populating /vdevice/nvram@71000001 > Populating /pci@800000020000000 > 00 0800 (D) : 1af4 1004 virtio [ scsi ] > Populating /pci@800000020000000/scsi@1 > SCSI: Looking for devices > 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" > 00 1000 (D) : 1af4 1000 virtio [ net ] > 00 2000 (D) : 1b36 000d serial bus [ usb-xhci ] > No NVRAM common partition, re-initializing... > Scanning USB > XHCI: Initializing > Using default console: /vdevice/vty@71000000 > > Welcome to Open Firmware > > Copyright (c) 2004, 2017 IBM Corporation All rights reserved. > This program and the accompanying materials are made available > under the terms of the BSD License available at > http://www.opensource.org/licenses/bsd-license.php > > > Trying to load: from: /pci@800000020000000/scsi@1/disk@100000000000000 ... slash SCSI-DISK: Access beyond end of device ! > > Out of internal memory. > SCSI-DISK: Access beyond end of device ! > SCSI-DISK: Access beyond end of device ! > SCSI-DISK: Access beyond end of device ! > SCSI-DISK: Access beyond end of device ! > SCSI-DISK: Access beyond end of device ! >
On 17/02/2020 20:26, Philippe Mathieu-Daudé wrote: > Hi Alexey, > > 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: >> >> git@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(-) > > I only received the cover, not the patch, have you posted it? No, for quite some time now - it is too big and does not pass some filters somewhere so rather than fixing filters, I simply send pull requests instead. > > I noticed on your repository you included a 'git shortlog' output in the > commit description, thanks for that detail, much appreciated! I was asked nicely to do so :) > > Regards, > > Phil. >
On 2/17/20 11:46 PM, David Gibson wrote: > On Mon, Feb 17, 2020 at 11:24:11AM +0100, Philippe Mathieu-Daudé wrote: >> On 2/17/20 10:26 AM, Philippe Mathieu-Daudé wrote: >>> Hi Alexey, >>> >>> 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: >>>> >>>> git@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(-) >>> >>> I only received the cover, not the patch, have you posted it? >> >> OK I see the SLOF binary is almost 1MB. Maybe this got blocked by spam >> filter. FYI you can use 'git-format-patch --no-binary' to emit the patch >> with the commit description but without the content. > > Generally Alexey sends SLOF updates to me just as pull requests > without patches in full, because a huge slab of base64 encoded > firmware isn't particularly illuminating. I understand, this is why I later suggested Alexey to use 'git-format-patch --no-binary', because Laszlo uses it for EDK2 submodule, this allow to quickly review the change on the list (without posting the base64), see: https://www.mail-archive.com/qemu-devel@nongnu.org/msg624429.html (pull-request cover) https://www.mail-archive.com/qemu-devel@nongnu.org/msg624432.html "roms/edk2: update submodule" https://www.mail-archive.com/qemu-devel@nongnu.org/msg624435.html "pc-bios: refresh edk2 build artifacts"
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: >>> >>> git@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 ? C. > > > > > SLOF ********************************************************************** > QEMU Starting > Build Date = Feb 17 2020 13:06:47 > FW Version = git-42228d763f1fdb7b > Press "s" to enter Open Firmware. > > Populating /vdevice methods > Populating /vdevice/nvram@71000000 > Populating /vdevice/vty@71000110 > Populating /pci@800000020000000 > 00 0000 (D) : 1af4 1000 virtio [ net ] > 00 0800 (D) : 1af4 1004 virtio [ scsi ] > Populating /pci@800000020000000/scsi@1 > SCSI: Looking for devices > 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" > No NVRAM common partition, re-initializing... > Scanning USB > Using default console: /vdevice/vty@71000110 > > Welcome to Open Firmware > > Copyright (c) 2004, 2017 IBM Corporation All rights reserved. > This program and the accompanying materials are made available > under the terms of the BSD License available at > http://www.opensource.org/licenses/bsd-license.php > > > Trying to load: from: /pci@800000020000000/scsi@1/disk@100000000000000 > ... Successfully loaded > > > > > > > Fedora (5.5.0-rc5-le-guest_v5.5-rc5_a+fstn1) 30 (Thirty) > > Fedora (5.0.9-301.fc30.ppc64le) 30 (Thirty) > > Fedora (0-rescue-8f8bbec520a44fd09da6af8e0d2c6571) 30 (Thirty) > > > > >> >> Thanks, >> >> C. >> >> >> QEMU Starting >> Build Date = Feb 17 2020 13:06:47 >> FW Version = git-42228d763f1fdb7b >> Press "s" to enter Open Firmware. >> >> Populating /vdevice methods >> Populating /vdevice/vty@71000000 >> Populating /vdevice/nvram@71000001 >> Populating /pci@800000020000000 >> 00 0800 (D) : 1af4 1004 virtio [ scsi ] >> Populating /pci@800000020000000/scsi@1 >> SCSI: Looking for devices >> 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" >> 00 1000 (D) : 1af4 1000 virtio [ net ] >> 00 2000 (D) : 1b36 000d serial bus [ usb-xhci ] >> No NVRAM common partition, re-initializing... >> Scanning USB >> XHCI: Initializing >> Using default console: /vdevice/vty@71000000 >> >> Welcome to Open Firmware >> >> Copyright (c) 2004, 2017 IBM Corporation All rights reserved. >> This program and the accompanying materials are made available >> under the terms of the BSD License available at >> http://www.opensource.org/licenses/bsd-license.php >> >> >> Trying to load: from: /pci@800000020000000/scsi@1/disk@100000000000000 ... slash SCSI-DISK: Access beyond end of device ! >> >> Out of internal memory. >> SCSI-DISK: Access beyond end of device ! >> SCSI-DISK: Access beyond end of device ! >> SCSI-DISK: Access beyond end of device ! >> SCSI-DISK: Access beyond end of device ! >> SCSI-DISK: Access beyond end of device ! >> >
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: >>>> >>>> git@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: SLOF ********************************************************************** QEMU Starting Build Date = Feb 17 2020 13:06:47 FW Version = git-42228d763f1fdb7b Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/nvram@71000000 Populating /vdevice/vty@71000110 Populating /pci@800000020000000 00 0000 (B) : 1b36 0001 pci* 01 0000 (D) : 1af4 1002 legacy-device* 00 0800 (D) : 1af4 1001 virtio [ block ] No NVRAM common partition, re-initializing... Scanning USB Using default console: /vdevice/vty@71000110 Welcome to Open Firmware Copyright (c) 2004, 2017 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Trying to load: from: /pci@800000020000000/scsi@1 ... slash not found Successfully loaded Welcome to GRUB! error: no suitable video mode found. GNU GRUB version 2.04 [...] Ubuntu 19.10 aiku1910le hvc0 aiku1910le login: aik Password: Last login: Tue Feb 18 19:57:46 AEDT 2020 from 10.61.161.111 on pts/0 Welcome to Ubuntu 19.10 (GNU/Linux 5.3.0-40-generic ppc64le) > > C. > > >> >> >> >> >> SLOF ********************************************************************** >> QEMU Starting >> Build Date = Feb 17 2020 13:06:47 >> FW Version = git-42228d763f1fdb7b >> Press "s" to enter Open Firmware. >> >> Populating /vdevice methods >> Populating /vdevice/nvram@71000000 >> Populating /vdevice/vty@71000110 >> Populating /pci@800000020000000 >> 00 0000 (D) : 1af4 1000 virtio [ net ] >> 00 0800 (D) : 1af4 1004 virtio [ scsi ] >> Populating /pci@800000020000000/scsi@1 >> SCSI: Looking for devices >> 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" >> No NVRAM common partition, re-initializing... >> Scanning USB >> Using default console: /vdevice/vty@71000110 >> >> Welcome to Open Firmware >> >> Copyright (c) 2004, 2017 IBM Corporation All rights reserved. >> This program and the accompanying materials are made available >> under the terms of the BSD License available at >> http://www.opensource.org/licenses/bsd-license.php >> >> >> Trying to load: from: /pci@800000020000000/scsi@1/disk@100000000000000 >> ... Successfully loaded >> >> >> >> >> >> >> Fedora (5.5.0-rc5-le-guest_v5.5-rc5_a+fstn1) 30 (Thirty) >> >> Fedora (5.0.9-301.fc30.ppc64le) 30 (Thirty) >> >> Fedora (0-rescue-8f8bbec520a44fd09da6af8e0d2c6571) 30 (Thirty) >> >> >> >> >>> >>> Thanks, >>> >>> C. >>> >>> >>> QEMU Starting >>> Build Date = Feb 17 2020 13:06:47 >>> FW Version = git-42228d763f1fdb7b >>> Press "s" to enter Open Firmware. >>> >>> Populating /vdevice methods >>> Populating /vdevice/vty@71000000 >>> Populating /vdevice/nvram@71000001 >>> Populating /pci@800000020000000 >>> 00 0800 (D) : 1af4 1004 virtio [ scsi ] >>> Populating /pci@800000020000000/scsi@1 >>> SCSI: Looking for devices >>> 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" >>> 00 1000 (D) : 1af4 1000 virtio [ net ] >>> 00 2000 (D) : 1b36 000d serial bus [ usb-xhci ] >>> No NVRAM common partition, re-initializing... >>> Scanning USB >>> XHCI: Initializing >>> Using default console: /vdevice/vty@71000000 >>> >>> Welcome to Open Firmware >>> >>> Copyright (c) 2004, 2017 IBM Corporation All rights reserved. >>> This program and the accompanying materials are made available >>> under the terms of the BSD License available at >>> http://www.opensource.org/licenses/bsd-license.php >>> >>> >>> Trying to load: from: /pci@800000020000000/scsi@1/disk@100000000000000 ... slash SCSI-DISK: Access beyond end of device ! >>> >>> Out of internal memory. >>> SCSI-DISK: Access beyond end of device ! >>> SCSI-DISK: Access beyond end of device ! >>> SCSI-DISK: Access beyond end of device ! >>> SCSI-DISK: Access beyond end of device ! >>> SCSI-DISK: Access beyond end of device ! >>> >> >
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: >>>>> >>>>> git@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...
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: >>>>>> >>>>>> git@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 ? C.
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: >>>>>>> >>>>>>> git@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") Also, commit e05b681b32df ("disk-label: Try ext2 filesystem when booting from GPT partition") adds a weird "slash not found" message : Trying to load: from: /pci@800000020000000/scsi@1/disk@100000000000000 ... slash not found Successfully loaded Thanks, C.
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: >>>>>>>> >>>>>>>> git@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. "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?= <clg@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 <clg@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 ;
On Tue, Feb 18, 2020 at 06:48:43AM +0100, Philippe Mathieu-Daudé wrote: > On 2/17/20 11:46 PM, David Gibson wrote: > > On Mon, Feb 17, 2020 at 11:24:11AM +0100, Philippe Mathieu-Daudé wrote: > > > On 2/17/20 10:26 AM, Philippe Mathieu-Daudé wrote: > > > > Hi Alexey, > > > > > > > > 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: > > > > > > > > > > git@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(-) > > > > > > > > I only received the cover, not the patch, have you posted it? > > > > > > OK I see the SLOF binary is almost 1MB. Maybe this got blocked by spam > > > filter. FYI you can use 'git-format-patch --no-binary' to emit the patch > > > with the commit description but without the content. > > > > Generally Alexey sends SLOF updates to me just as pull requests > > without patches in full, because a huge slab of base64 encoded > > firmware isn't particularly illuminating. > > I understand, this is why I later suggested Alexey to use 'git-format-patch > --no-binary', because Laszlo uses it for EDK2 submodule, this allow to > quickly review the change on the list (without posting the base64), see: Hm. What's to review? The only change apart from the binary blob and the submodule tag is the version numbers in pc-bios/README.
On Tue, Feb 18, 2020 at 01:59:44PM +0100, 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: > >>>>>>>> > >>>>>>>> git@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. > > "slash not found" is still there though. I've removed this SLOF update from my ppc-for-5.0 staging tree until we figure out what's going wrong here.
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: >>>>>>>>> >>>>>>>>> git@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?= <clg@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 <clg@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 > ; >
On 19/02/2020 12:20, Alexey Kardashevskiy wrote: > > > 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: >>>>>>>>>> >>>>>>>>>> git@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, Better try this one please: https://github.com/aik/SLOF/tree/ext4 What I still do not understand is why GRUB is using ext2 from SLOF, it should parse ext4 itself :-/ > > >> >> "slash not found" is still there though. Yeah I see these but they are harmless as far as I can tell. >> >> Cheers, >> >> C. >> >> >> From 92dc9f6dc7c6434419306d5a382adb42169b712a Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@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 <clg@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 >> ; >> >
On 2/19/20 7:44 AM, Alexey Kardashevskiy wrote: > > > On 19/02/2020 12:20, Alexey Kardashevskiy wrote: >> >> >> 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: >>>>>>>>>>> >>>>>>>>>>> git@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, > > Better try this one please: > > https://github.com/aik/SLOF/tree/ext4 Tested with the same image. Looks good. > What I still do not understand is why GRUB is using ext2 from SLOF, it > should parse ext4 itself :-/ Here is the fs information. Filesystem volume name: <none> Last mounted on: / Filesystem UUID: 8d53f6b4-ffc2-4d8f-bd09-67ac97d7b0c5 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: unsigned_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 3127296 Block count: 12582912 Reserved block count: 552210 Free blocks: 7907437 Free inodes: 2863361 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1021 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8144 Inode blocks per group: 509 Flex block group size: 16 Filesystem created: Wed Dec 14 15:40:55 2016 Last mount time: Wed Feb 19 08:06:52 2020 Last write time: Wed Feb 19 08:06:46 2020 Mount count: 1863 Maximum mount count: -1 Last checked: Fri Nov 23 19:09:13 2018 Check interval: 0 (<none>) Lifetime writes: 883 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: f7cb5863-4885-47b6-b24b-369df6a3b1a4 Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 128M Journal length: 32768 Journal sequence: 0x0004beb2 Thanks, C. > >> >> >>> >>> "slash not found" is still there though. > > > Yeah I see these but they are harmless as far as I can tell. > > > >>> >>> Cheers, >>> >>> C. >>> >>> >>> From 92dc9f6dc7c6434419306d5a382adb42169b712a Mon Sep 17 00:00:00 2001 >>> From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@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 <clg@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 >>> ; >>> >> >
On 19/02/2020 18:18, Cédric Le Goater wrote: > On 2/19/20 7:44 AM, Alexey Kardashevskiy wrote: >> >> >> On 19/02/2020 12:20, Alexey Kardashevskiy wrote: >>> >>> >>> 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: >>>>>>>>>>>> >>>>>>>>>>>> git@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, >> >> Better try this one please: >> >> https://github.com/aik/SLOF/tree/ext4 > Tested with the same image. Looks good. Thanks for testing. But it is still bizarre behaviour, why do we end up there anyway... >> What I still do not understand is why GRUB is using ext2 from SLOF, it >> should parse ext4 itself :-/ > > Here is the fs information. > > > Filesystem volume name: <none> > Last mounted on: / > Filesystem UUID: 8d53f6b4-ffc2-4d8f-bd09-67ac97d7b0c5 > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize huh, this one does not have 64bit like mine, I blindly assumed that by 2020 everything would be using that. Well that explains the bug. And yours also has uninit_bg (the whole idea of this flag is not obvious but ok). > Filesystem flags: unsigned_directory_hash > Default mount options: user_xattr acl > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 3127296 > Block count: 12582912 > Reserved block count: 552210 > Free blocks: 7907437 > Free inodes: 2863361 > First block: 0 > Block size: 4096 > Fragment size: 4096 Mine here has: Group descriptor size: 64 so there is no "hi" part and this is what my fix now handles (0x32 vs. 0x20 was not the problem actually). Did you do this on purpose or the installer did it? :) Anyway, I'd like to get this particular disk image to understand why on earth it is using the ext2 package from SLOF. Thanks, > Reserved GDT blocks: 1021 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 8144 > Inode blocks per group: 509 > Flex block group size: 16 > Filesystem created: Wed Dec 14 15:40:55 2016 > Last mount time: Wed Feb 19 08:06:52 2020 > Last write time: Wed Feb 19 08:06:46 2020 > Mount count: 1863 > Maximum mount count: -1 > Last checked: Fri Nov 23 19:09:13 2018 > Check interval: 0 (<none>) > Lifetime writes: 883 GB > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 28 > Desired extra isize: 28 > Journal inode: 8 > Default directory hash: half_md4 > Directory Hash Seed: f7cb5863-4885-47b6-b24b-369df6a3b1a4 > Journal backup: inode blocks > Journal features: journal_incompat_revoke > Journal size: 128M > Journal length: 32768 > Journal sequence: 0x0004beb2 > > Thanks, > > C. > >> >>> >>> >>>> >>>> "slash not found" is still there though. >> >> >> Yeah I see these but they are harmless as far as I can tell. >> >> >> >>>> >>>> Cheers, >>>> >>>> C. >>>> >>>> >>>> From 92dc9f6dc7c6434419306d5a382adb42169b712a Mon Sep 17 00:00:00 2001 >>>> From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@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 <clg@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 >>>> ; >>>> >>> >> >
On 2/20/20 2:50 AM, Alexey Kardashevskiy wrote: > > > On 19/02/2020 18:18, Cédric Le Goater wrote: >> On 2/19/20 7:44 AM, Alexey Kardashevskiy wrote: >>> >>> >>> On 19/02/2020 12:20, Alexey Kardashevskiy wrote: >>>> >>>> >>>> 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: >>>>>>>>>>>>> >>>>>>>>>>>>> git@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, >>> >>> Better try this one please: >>> >>> https://github.com/aik/SLOF/tree/ext4 >> Tested with the same image. Looks good. > > > Thanks for testing. But it is still bizarre behaviour, why do we end up > there anyway... > > >>> What I still do not understand is why GRUB is using ext2 from SLOF, it >>> should parse ext4 itself :-/ >> >> Here is the fs information. >> >> >> Filesystem volume name: <none> >> Last mounted on: / >> Filesystem UUID: 8d53f6b4-ffc2-4d8f-bd09-67ac97d7b0c5 >> Filesystem magic number: 0xEF53 >> Filesystem revision #: 1 (dynamic) >> Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize > > > huh, this one does not have 64bit like mine, I blindly assumed that by > 2020 everything would be using that. Well that explains the bug. And > yours also has uninit_bg (the whole idea of this flag is not obvious but > ok). > > >> Filesystem flags: unsigned_directory_hash >> Default mount options: user_xattr acl >> Filesystem state: clean >> Errors behavior: Continue >> Filesystem OS type: Linux >> Inode count: 3127296 >> Block count: 12582912 >> Reserved block count: 552210 >> Free blocks: 7907437 >> Free inodes: 2863361 >> First block: 0 >> Block size: 4096 >> Fragment size: 4096 > > > Mine here has: > Group descriptor size: 64 > > so there is no "hi" part and this is what my fix now handles (0x32 vs. > 0x20 was not the problem actually). > > Did you do this on purpose or the installer did it? :) I don't remember. I think I have kept the same disk image since 14.04 and did some fs resize. > Anyway, I'd like to get this particular disk image to understand why on > earth it is using the ext2 package from SLOF. Thanks, Sure. Thanks, C. > >> Reserved GDT blocks: 1021 >> Blocks per group: 32768 >> Fragments per group: 32768 >> Inodes per group: 8144 >> Inode blocks per group: 509 >> Flex block group size: 16 >> Filesystem created: Wed Dec 14 15:40:55 2016 >> Last mount time: Wed Feb 19 08:06:52 2020 >> Last write time: Wed Feb 19 08:06:46 2020 >> Mount count: 1863 >> Maximum mount count: -1 >> Last checked: Fri Nov 23 19:09:13 2018 >> Check interval: 0 (<none>) >> Lifetime writes: 883 GB >> Reserved blocks uid: 0 (user root) >> Reserved blocks gid: 0 (group root) >> First inode: 11 >> Inode size: 256 >> Required extra isize: 28 >> Desired extra isize: 28 >> Journal inode: 8 >> Default directory hash: half_md4 >> Directory Hash Seed: f7cb5863-4885-47b6-b24b-369df6a3b1a4 >> Journal backup: inode blocks >> Journal features: journal_incompat_revoke >> Journal size: 128M >> Journal length: 32768 >> Journal sequence: 0x0004beb2 >> >> Thanks, >> >> C. >> >>> >>>> >>>> >>>>> >>>>> "slash not found" is still there though. >>> >>> >>> Yeah I see these but they are harmless as far as I can tell. >>> >>> >>> >>>>> >>>>> Cheers, >>>>> >>>>> C. >>>>> >>>>> >>>>> From 92dc9f6dc7c6434419306d5a382adb42169b712a Mon Sep 17 00:00:00 2001 >>>>> From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@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 <clg@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 >>>>> ; >>>>> >>>> >>> >> >
On 18/02/2020 16:48, Philippe Mathieu-Daudé wrote: > On 2/17/20 11:46 PM, David Gibson wrote: >> On Mon, Feb 17, 2020 at 11:24:11AM +0100, Philippe Mathieu-Daudé wrote: >>> On 2/17/20 10:26 AM, Philippe Mathieu-Daudé wrote: >>>> Hi Alexey, >>>> >>>> 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: >>>>> >>>>> git@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(-) >>>> >>>> I only received the cover, not the patch, have you posted it? >>> >>> OK I see the SLOF binary is almost 1MB. Maybe this got blocked by spam >>> filter. FYI you can use 'git-format-patch --no-binary' to emit the patch >>> with the commit description but without the content. >> >> Generally Alexey sends SLOF updates to me just as pull requests >> without patches in full, because a huge slab of base64 encoded >> firmware isn't particularly illuminating. > > I understand, this is why I later suggested Alexey to use > 'git-format-patch --no-binary', because Laszlo uses it for EDK2 > submodule, this allow to quickly review the change on the list (without > posting the base64), see: > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg624429.html > (pull-request cover) > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg624432.html > "roms/edk2: update submodule" > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg624435.html > "pc-bios: refresh edk2 build artifacts" I am not quite sure where to fit this "git-format-patch". I run now "git request-pull" and "git send-email" so am I expected to run format-patch and post it as a patchset but with the pull request mail as a cover letter? This does not seem very useful though. For today, I'll add the change log to the pull request mail. Thanks,
On Fri, Feb 21, 2020 at 03:09:46PM +1100, Alexey Kardashevskiy wrote: > > > On 18/02/2020 16:48, Philippe Mathieu-Daudé wrote: > > On 2/17/20 11:46 PM, David Gibson wrote: > >> On Mon, Feb 17, 2020 at 11:24:11AM +0100, Philippe Mathieu-Daudé wrote: > >>> On 2/17/20 10:26 AM, Philippe Mathieu-Daudé wrote: > >>>> Hi Alexey, > >>>> > >>>> 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: > >>>>> > >>>>> git@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(-) > >>>> > >>>> I only received the cover, not the patch, have you posted it? > >>> > >>> OK I see the SLOF binary is almost 1MB. Maybe this got blocked by spam > >>> filter. FYI you can use 'git-format-patch --no-binary' to emit the patch > >>> with the commit description but without the content. > >> > >> Generally Alexey sends SLOF updates to me just as pull requests > >> without patches in full, because a huge slab of base64 encoded > >> firmware isn't particularly illuminating. > > > > I understand, this is why I later suggested Alexey to use > > 'git-format-patch --no-binary', because Laszlo uses it for EDK2 > > submodule, this allow to quickly review the change on the list (without > > posting the base64), see: > > > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg624429.html > > (pull-request cover) > > > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg624432.html > > "roms/edk2: update submodule" > > > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg624435.html > > "pc-bios: refresh edk2 build artifacts" > > I am not quite sure where to fit this "git-format-patch". I run now "git > request-pull" and "git send-email" so am I expected to run format-patch > and post it as a patchset but with the pull request mail as a cover > letter? This does not seem very useful though. For today, I'll add the > change log to the pull request mail. Thanks, Most git format-patch options can also be passed to git send-email, and it will pass them through.