64-bit userspace root file system for hppa64

64-bit userspace root file system for hppa64

[Guenter Roeck]

Hi,

I started to play with the new qemu hppa64 emulation. It works pretty well with 32-bit
userspace images. Unfortunately, I have not been able to create a 64-bit userspace
root file system. I am stuck trying to build glibc and/or uclibc-ng.

Does anyone happen to know how to build 64 bit userspace images for hppa64, or more
specifically how to configure glibc and/or uclibc-ng for it ?

Thanks,
Guenter

Re: 64-bit userspace root file system for hppa64

[John David Anglin]

On 2023-12-04 8:08 p.m., Guenter Roeck wrote:
> I started to play with the new qemu hppa64 emulation. It works pretty well with 32-bit
> userspace images. Unfortunately, I have not been able to create a 64-bit userspace
> root file system. I am stuck trying to build glibc and/or uclibc-ng.
>
> Does anyone happen to know how to build 64 bit userspace images for hppa64, or more
> specifically how to configure glibc and/or uclibc-ng for it ?
As far as I know, no one has ported glibc to hppa64.  I started working on it a few months
ago but a lot more work is needed to get it working.

I have a working 64-bit tool chain running on hpux but 64-bit hpux doesn't boot yet under qemu.

Regards,
Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/5/23 03:39, John David Anglin wrote:
> On 2023-12-04 8:08 p.m., Guenter Roeck wrote:
>> I started to play with the new qemu hppa64 emulation.

This emulation is in the first row planned to be able to
be used with 64-bit kernels (until we hopefully once get
64-bit userspace).
Sadly there still seems to be a bug in the emulation
so that it fails when the kernel is built with specific
modules.... :-(
I still don't know where the bug is though.

> It works pretty well with 32-bit
>> userspace images. Unfortunately, I have not been able to create a 64-bit userspace
>> root file system. I am stuck trying to build glibc and/or uclibc-ng.
>>
>> Does anyone happen to know how to build 64 bit userspace images for hppa64, or more
>> specifically how to configure glibc and/or uclibc-ng for it ?
> As far as I know, no one has ported glibc to hppa64.  I started working on it a few months
> ago but a lot more work is needed to get it working.
>
> I have a working 64-bit tool chain running on hpux but 64-bit hpux doesn't boot yet under qemu.

Yep. 32- and 64-bit HP-UX is currently broken in the 64-bit enabled
qemu.

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

Hi Helge,

On 12/5/23 13:58, Helge Deller wrote:
> On 12/5/23 03:39, John David Anglin wrote:
>> On 2023-12-04 8:08 p.m., Guenter Roeck wrote:
>>> I started to play with the new qemu hppa64 emulation.
> 
> This emulation is in the first row planned to be able to
> be used with 64-bit kernels (until we hopefully once get
> 64-bit userspace).
> Sadly there still seems to be a bug in the emulation
> so that it fails when the kernel is built with specific
> modules.... :-(
> I still don't know where the bug is though.
> 

I don't try to build / load modules, so I don't see that problem.

Couple of observations:
- There are spurious issues if I enable more than one CPU.
   I am not sure if that is realistic (the emulated systems seem to be
   single-CPU systems), so I dropped those tests. Historically
   (with older kernels and/or older versions of qemu), multi-core boots
   didn't work at all (they were slower than single-core),
   so there is definitely an improvement, but it isn't stable enough
   to use for kernel regression testing.
- The e1000 and e1000-82544gc network interfaces don't work
   (those work fine with the 32-bit emulation)
- ne2k_pci doesn't work anywhere. I get either a hang or a spinlock recursion
   error if I try.
- Not sure it if is worth mentioning: There may be hung task crashes in
   usb_start_wait_urb/usb_kill_urb during shutdown when booting from usb
   or when using an usb network interface. That happens with all emulations,
   though, and is not parisc specific.

Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/5/23 23:52, Guenter Roeck wrote:
> Hi Helge,
>
> On 12/5/23 13:58, Helge Deller wrote:
>> On 12/5/23 03:39, John David Anglin wrote:
>>> On 2023-12-04 8:08 p.m., Guenter Roeck wrote:
>>>> I started to play with the new qemu hppa64 emulation.
>>
>> This emulation is in the first row planned to be able to
>> be used with 64-bit kernels (until we hopefully once get
>> 64-bit userspace).
>> Sadly there still seems to be a bug in the emulation
>> so that it fails when the kernel is built with specific
>> modules.... :-(
>> I still don't know where the bug is though.
>>
>
> I don't try to build / load modules, so I don't see that problem.

Good :-)

> Couple of observations:
> - There are spurious issues if I enable more than one CPU.

Interesting. What kind of issues? Spurious interrupts?

>    I am not sure if that is realistic (the emulated systems seem to be
>    single-CPU systems)

Yes, but shouldn't matter.

> , so I dropped those tests. Historically
>    (with older kernels and/or older versions of qemu), multi-core boots
>    didn't work at all (they were slower than single-core),

Not sure if this is the case here, but for older qemu's you need
this option so that the virtual CPUs are put into their own threads/cores:
	-accel tcg,thread=multi
This option isn't necessary on newer qemu versions.

>    so there is definitely an improvement, but it isn't stable enough
>    to use for kernel regression testing.
> - The e1000 and e1000-82544gc network interfaces don't work
>    (those work fine with the 32-bit emulation)
> - ne2k_pci doesn't work anywhere. I get either a hang or a spinlock recursion
>    error if I try.

I will try both, but at least for 64-bit emulation I might have an idea.

> - Not sure it if is worth mentioning: There may be hung task crashes in
>    usb_start_wait_urb/usb_kill_urb during shutdown when booting from usb
>    or when using an usb network interface. That happens with all emulations,
>    though, and is not parisc specific.

Did you reported it upstream in the bug tracker?

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/5/23 15:22, Helge Deller wrote:
> On 12/5/23 23:52, Guenter Roeck wrote:
>> Hi Helge,
>>
>> On 12/5/23 13:58, Helge Deller wrote:
>>> On 12/5/23 03:39, John David Anglin wrote:
>>>> On 2023-12-04 8:08 p.m., Guenter Roeck wrote:
>>>>> I started to play with the new qemu hppa64 emulation.
>>>
>>> This emulation is in the first row planned to be able to
>>> be used with 64-bit kernels (until we hopefully once get
>>> 64-bit userspace).
>>> Sadly there still seems to be a bug in the emulation
>>> so that it fails when the kernel is built with specific
>>> modules.... :-(
>>> I still don't know where the bug is though.
>>>
>>
>> I don't try to build / load modules, so I don't see that problem.
> 
> Good :-)
> 
>> Couple of observations:
>> - There are spurious issues if I enable more than one CPU.
> 
> Interesting. What kind of issues? Spurious interrupts?
> 

Frankly I didn't check details. I just noticed that I got a high
percentage of test failures and gave up trying after I realized
that the real hardware doesn't support more than one CPU.

Is it worth testing with multiple CPUs ? I can re-enable it and
check more closely if you think it makes sense. If so, what number
of CPUs would you recommend ?

>>    I am not sure if that is realistic (the emulated systems seem to be
>>    single-CPU systems)
> 
> Yes, but shouldn't matter.
> 
>> , so I dropped those tests. Historically
>>    (with older kernels and/or older versions of qemu), multi-core boots
>>    didn't work at all (they were slower than single-core),
> 
> Not sure if this is the case here, but for older qemu's you need
> this option so that the virtual CPUs are put into their own threads/cores:
>      -accel tcg,thread=multi
> This option isn't necessary on newer qemu versions.
> 

Ah, that might explain it. Thanks a lot for the hint.

>>    so there is definitely an improvement, but it isn't stable enough
>>    to use for kernel regression testing.
>> - The e1000 and e1000-82544gc network interfaces don't work
>>    (those work fine with the 32-bit emulation)
>> - ne2k_pci doesn't work anywhere. I get either a hang or a spinlock recursion
>>    error if I try.
> 
> I will try both, but at least for 64-bit emulation I might have an idea.
> 
>> - Not sure it if is worth mentioning: There may be hung task crashes in
>>    usb_start_wait_urb/usb_kill_urb during shutdown when booting from usb
>>    or when using an usb network interface. That happens with all emulations,
>>    though, and is not parisc specific.
> 
> Did you reported it upstream in the bug tracker?
> 

No, because I have no idea if it is an emulation problem or a linux problem.
I never had the time to track it down. I just noticed that it seemed to be more
prevalent with 64-bit parisc especially if I boot from usb _and_ use a usb
network interface. In case you are interested to see how it looks like, here
are a couple of examples:

https://kerneltests.org/builders/qemu-riscv64-5.4/builds/46/steps/qemubuildcommand/logs/stdio
https://kerneltests.org/builders/qemu-parisc64-6.6/builds/1/steps/qemubuildcommand/logs/stdio

Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/6/23 01:39, Guenter Roeck wrote:
> On 12/5/23 15:22, Helge Deller wrote:
>> On 12/5/23 23:52, Guenter Roeck wrote:
>>> Hi Helge,
>>>
>>> On 12/5/23 13:58, Helge Deller wrote:
>>>> On 12/5/23 03:39, John David Anglin wrote:
>>>>> On 2023-12-04 8:08 p.m., Guenter Roeck wrote:
>>>>>> I started to play with the new qemu hppa64 emulation.
>>>>
>>>> This emulation is in the first row planned to be able to
>>>> be used with 64-bit kernels (until we hopefully once get
>>>> 64-bit userspace).
>>>> Sadly there still seems to be a bug in the emulation
>>>> so that it fails when the kernel is built with specific
>>>> modules.... :-(
>>>> I still don't know where the bug is though.
>>>>
>>>
>>> I don't try to build / load modules, so I don't see that problem.
>>
>> Good :-)
>>
>>> Couple of observations:
>>> - There are spurious issues if I enable more than one CPU.
>>
>> Interesting. What kind of issues? Spurious interrupts?
>>
>
> Frankly I didn't check details. I just noticed that I got a high
> percentage of test failures and gave up trying after I realized
> that the real hardware doesn't support more than one CPU.
>
> Is it worth testing with multiple CPUs ? I can re-enable it and
> check more closely if you think it makes sense. If so, what number
> of CPUs would you recommend ?

I think 4 CPUs is realistic.
But I agree, that you probably see more issues.

Generally the assumption was, that the different caches on parisc
may trigger SMP issues, but given that those issues can be seen on
qemu, it indicates that there are generic SMP issues too.

>>>    I am not sure if that is realistic (the emulated systems seem to be
>>>    single-CPU systems)
>>
>> Yes, but shouldn't matter.
>>
>>> , so I dropped those tests. Historically
>>>    (with older kernels and/or older versions of qemu), multi-core boots
>>>    didn't work at all (they were slower than single-core),
>>
>> Not sure if this is the case here, but for older qemu's you need
>> this option so that the virtual CPUs are put into their own threads/cores:
>>      -accel tcg,thread=multi
>> This option isn't necessary on newer qemu versions.
>>
>
> Ah, that might explain it. Thanks a lot for the hint.
>
>>>    so there is definitely an improvement, but it isn't stable enough
>>>    to use for kernel regression testing.
>>> - The e1000 and e1000-82544gc network interfaces don't work
>>>    (those work fine with the 32-bit emulation)
>>> - ne2k_pci doesn't work anywhere. I get either a hang or a spinlock recursion
>>>    error if I try.
>>
>> I will try both, but at least for 64-bit emulation I might have an idea.
>>
>>> - Not sure it if is worth mentioning: There may be hung task crashes in
>>>    usb_start_wait_urb/usb_kill_urb during shutdown when booting from usb
>>>    or when using an usb network interface. That happens with all emulations,
>>>    though, and is not parisc specific.
>>
>> Did you reported it upstream in the bug tracker?
>>
>
> No, because I have no idea if it is an emulation problem or a linux problem.
> I never had the time to track it down. I just noticed that it seemed to be more
> prevalent with 64-bit parisc especially if I boot from usb _and_ use a usb
> network interface. In case you are interested to see how it looks like, here
> are a couple of examples:
>
> https://kerneltests.org/builders/qemu-riscv64-5.4/builds/46/steps/qemubuildcommand/logs/stdio
> https://kerneltests.org/builders/qemu-parisc64-6.6/builds/1/steps/qemubuildcommand/logs/stdio

Ok, thanks!
But isn't that more or less expected, as the machine can't simply turn
off USB when root disc is on USB? E.g. otherwise it woulnd't find the shutdown
executables? Maybe just the warning should be disabled after shutdown?

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/6/23 09:00, Helge Deller wrote:
[ ... ]
>> Is it worth testing with multiple CPUs ? I can re-enable it and
>> check more closely if you think it makes sense. If so, what number
>> of CPUs would you recommend ?
> 
> I think 4 CPUs is realistic.
> But I agree, that you probably see more issues.
> 
> Generally the assumption was, that the different caches on parisc
> may trigger SMP issues, but given that those issues can be seen on
> qemu, it indicates that there are generic SMP issues too.
> 

Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
stable, with the exception of SCSI controllers. Some fail completely, others
rarely. Here is a quick summary:

- am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
   and a hung task crash.
- megasas and megasas-gen2 fail with
   "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
   followed by
   "megaraid_sas 0000:00:04.0: Unknown command completed!"
   and a hung task crash
- mptsas1068 fails completely (no kernel log message seen)
- dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts

[ ... ]
>>>
>>>> - Not sure it if is worth mentioning: There may be hung task crashes in
>>>>    usb_start_wait_urb/usb_kill_urb during shutdown when booting from usb
>>>>    or when using an usb network interface. That happens with all emulations,
>>>>    though, and is not parisc specific.
>>>
>>> Did you reported it upstream in the bug tracker?
>>>
>>
>> No, because I have no idea if it is an emulation problem or a linux problem.
>> I never had the time to track it down. I just noticed that it seemed to be more
>> prevalent with 64-bit parisc especially if I boot from usb _and_ use a usb
>> network interface. In case you are interested to see how it looks like, here
>> are a couple of examples:
>>
>> https://kerneltests.org/builders/qemu-riscv64-5.4/builds/46/steps/qemubuildcommand/logs/stdio
>> https://kerneltests.org/builders/qemu-parisc64-6.6/builds/1/steps/qemubuildcommand/logs/stdio
> 
> Ok, thanks!
> But isn't that more or less expected, as the machine can't simply turn
> off USB when root disc is on USB? E.g. otherwise it woulnd't find the shutdown
> executables? Maybe just the warning should be disabled after shutdown?
> 

Not sure about that, for a number of reasons: It doesn't happen all the time,
and it is more likely to happen if the system is under load. It also seems
to be associated with OHCI (I am currently running more tests to confirm),
and sometimes the failure is with the network interface. That suggests that
some race condition may be involved.

Thanks,
Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/6/23 21:19, Guenter Roeck wrote:
> On 12/6/23 09:00, Helge Deller wrote:
> [ ... ]
>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>> check more closely if you think it makes sense. If so, what number
>>> of CPUs would you recommend ?
>>
>> I think 4 CPUs is realistic.
>> But I agree, that you probably see more issues.
>>
>> Generally the assumption was, that the different caches on parisc
>> may trigger SMP issues, but given that those issues can be seen on
>> qemu, it indicates that there are generic SMP issues too.
>>
>
> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
> stable,

cool!

> with the exception of SCSI controllers. Some fail completely, others
> rarely. Here is a quick summary:
>
> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>    and a hung task crash.
> - megasas and megasas-gen2 fail with
>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>    followed by
>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>    and a hung task crash
> - mptsas1068 fails completely (no kernel log message seen)
> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts

I think none of those drivers have ever been tested
on physical hardware either.
So I'm astonished that it even worked that far :-)

Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
am53c974 driver. Are you sure you see this message for dc390 and lsi* too?

For megaraid_sas I see a Seabios-hppa firmware patch is required.
Could you please give me the full command line how you start qemu?
Esp. since the lsi scsi is still there, how do you assign a disc to the additional
megaraid_sas driver?

>>>>> - Not sure it if is worth mentioning: There may be hung task crashes in
>>>>>    usb_start_wait_urb/usb_kill_urb during shutdown when booting from usb
>>>>>    or when using an usb network interface. That happens with all emulations,
>>>>>    though, and is not parisc specific.
>>>>
>>>> Did you reported it upstream in the bug tracker?
>>>>
>>>
>>> No, because I have no idea if it is an emulation problem or a linux problem.
>>> I never had the time to track it down. I just noticed that it seemed to be more
>>> prevalent with 64-bit parisc especially if I boot from usb _and_ use a usb
>>> network interface. In case you are interested to see how it looks like, here
>>> are a couple of examples:
>>>
>>> https://kerneltests.org/builders/qemu-riscv64-5.4/builds/46/steps/qemubuildcommand/logs/stdio
>>> https://kerneltests.org/builders/qemu-parisc64-6.6/builds/1/steps/qemubuildcommand/logs/stdio
>>
>> Ok, thanks!
>> But isn't that more or less expected, as the machine can't simply turn
>> off USB when root disc is on USB? E.g. otherwise it woulnd't find the shutdown
>> executables? Maybe just the warning should be disabled after shutdown?
>>
>
> Not sure about that, for a number of reasons: It doesn't happen all the time,
> and it is more likely to happen if the system is under load. It also seems
> to be associated with OHCI (I am currently running more tests to confirm),
> and sometimes the failure is with the network interface. That suggests that
> some race condition may be involved.

Ok, at least it should be looked at...

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/6/23 13:43, Helge Deller wrote:
> On 12/6/23 21:19, Guenter Roeck wrote:
>> On 12/6/23 09:00, Helge Deller wrote:
>> [ ... ]
>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>> check more closely if you think it makes sense. If so, what number
>>>> of CPUs would you recommend ?
>>>
>>> I think 4 CPUs is realistic.
>>> But I agree, that you probably see more issues.
>>>
>>> Generally the assumption was, that the different caches on parisc
>>> may trigger SMP issues, but given that those issues can be seen on
>>> qemu, it indicates that there are generic SMP issues too.
>>>
>>
>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>> stable,
> 
> cool!
> 
>> with the exception of SCSI controllers. Some fail completely, others
>> rarely. Here is a quick summary:
>>
>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>    and a hung task crash.
>> - megasas and megasas-gen2 fail with
>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>    followed by
>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>    and a hung task crash
>> - mptsas1068 fails completely (no kernel log message seen)
>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
> 
> I think none of those drivers have ever been tested
> on physical hardware either.
> So I'm astonished that it even worked that far :-)
> 
> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
> 

Definitely for dc390:

qemu-system-hppa -M C3700 -kernel \
      vmlinux -no-reboot -snapshot -smp 4 -device rtl8139,netdev=net0 \
      -netdev user,id=net0 -device dc390,id=scsi -device \
      scsi-hd,bus=scsi.0,drive=d0 -drive \
      file=/var/cache/buildbot/parisc64/rootfs.ext2,format=raw,if=none,id=d0 \
      -append "root=/dev/sda rootwait console=ttyS0,115200 " \
      -nographic -monitor null

I'll have to re-check lsi*. My notes for lsi53c810 actually say:

     # Random crashes in sym_evaluate_dp(), called from sym_compute_residual()
     # (NULL pointer access). The problem is seen during shutdown. This is a
     # kernel bug, obviously, likely caused by timing differences. It is
     # possible if not likely that an interrupt is seen after the controller
     # was presumably disabled.

but that was for 32-bit. It turns out I don't have any notes for lsi53c895a.
I'll re-check both tonight.

> For megaraid_sas I see a Seabios-hppa firmware patch is required.
> Could you please give me the full command line how you start qemu?
> Esp. since the lsi scsi is still there, how do you assign a disc to the additional
> megaraid_sas driver?
> 

qemu-system-hppa -M C3700 -kernel \
      vmlinux -no-reboot -snapshot -device pcnet,netdev=net0 -netdev \
      user,id=net0 -device megasas,id=scsi -device \
      scsi-hd,bus=scsi.0,drive=d0 -drive \
      file=/var/cache/buildbot/parisc64/rootfs.ext2,format=raw,if=none,id=d0 \
      -append "root=/dev/sda rootwait console=ttyS0,115200 " \
      -nographic -monitor null

>>>>>> - Not sure it if is worth mentioning: There may be hung task crashes in
>>>>>>    usb_start_wait_urb/usb_kill_urb during shutdown when booting from usb
>>>>>>    or when using an usb network interface. That happens with all emulations,
>>>>>>    though, and is not parisc specific.
>>>>>
>>>>> Did you reported it upstream in the bug tracker?
>>>>>
>>>>
>>>> No, because I have no idea if it is an emulation problem or a linux problem.
>>>> I never had the time to track it down. I just noticed that it seemed to be more
>>>> prevalent with 64-bit parisc especially if I boot from usb _and_ use a usb
>>>> network interface. In case you are interested to see how it looks like, here
>>>> are a couple of examples:
>>>>
>>>> https://kerneltests.org/builders/qemu-riscv64-5.4/builds/46/steps/qemubuildcommand/logs/stdio
>>>> https://kerneltests.org/builders/qemu-parisc64-6.6/builds/1/steps/qemubuildcommand/logs/stdio
>>>
>>> Ok, thanks!
>>> But isn't that more or less expected, as the machine can't simply turn
>>> off USB when root disc is on USB? E.g. otherwise it woulnd't find the shutdown
>>> executables? Maybe just the warning should be disabled after shutdown?
>>>
>>
>> Not sure about that, for a number of reasons: It doesn't happen all the time,
>> and it is more likely to happen if the system is under load. It also seems
>> to be associated with OHCI (I am currently running more tests to confirm),
>> and sometimes the failure is with the network interface. That suggests that
>> some race condition may be involved.
> 
> Ok, at least it should be looked at...
> 

I confirmed that this is _only_ seen if the host system is under load. I have not
been able to reproduce the problem on a system which is idle beyond the qemu process.

Guenter

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

Hi Helge,

On 12/6/23 13:43, Helge Deller wrote:
> On 12/6/23 21:19, Guenter Roeck wrote:
>> On 12/6/23 09:00, Helge Deller wrote:
>> [ ... ]
>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>> check more closely if you think it makes sense. If so, what number
>>>> of CPUs would you recommend ?
>>>
>>> I think 4 CPUs is realistic.
>>> But I agree, that you probably see more issues.
>>>
>>> Generally the assumption was, that the different caches on parisc
>>> may trigger SMP issues, but given that those issues can be seen on
>>> qemu, it indicates that there are generic SMP issues too.
>>>
>>
>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>> stable,
> 
> cool!
> 
>> with the exception of SCSI controllers. Some fail completely, others
>> rarely. Here is a quick summary:
>>
>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>    and a hung task crash.
>> - megasas and megasas-gen2 fail with
>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>    followed by
>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>    and a hung task crash
>> - mptsas1068 fails completely (no kernel log message seen)
>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
> 
> I think none of those drivers have ever been tested
> on physical hardware either.
> So I'm astonished that it even worked that far :-)
> 
I actually do have a dc390 board somewhere. I used it some time ago to improve
the emulation.

> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
> 
am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
either. Sorry, I confused that with some old notes.

Either case, I think I found the problem. After handling an interrupt, the Linux
driver checks if another interrupt is pending. It does that by checking the
DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
interrupt handler. Problem with that is that the emulation sets DMA_DONE
prematurely, before it sets the command done bit in the interrupt status register
and before it sets the interrupt pending bit in the status register. As result,
DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
I fixed that up in my code and will test it for some time and with various
architectures before I send a patch.

Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

(looping in Mark Cave-Ayland, since he did some work on qemu esp driver)

On 12/7/23 22:08, Guenter Roeck wrote:
> Hi Helge,
>
> On 12/6/23 13:43, Helge Deller wrote:
>> On 12/6/23 21:19, Guenter Roeck wrote:
>>> On 12/6/23 09:00, Helge Deller wrote:
>>> [ ... ]
>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>> check more closely if you think it makes sense. If so, what number
>>>>> of CPUs would you recommend ?
>>>>
>>>> I think 4 CPUs is realistic.
>>>> But I agree, that you probably see more issues.
>>>>
>>>> Generally the assumption was, that the different caches on parisc
>>>> may trigger SMP issues, but given that those issues can be seen on
>>>> qemu, it indicates that there are generic SMP issues too.
>>>>
>>>
>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>> stable,
>>
>> cool!
>>
>>> with the exception of SCSI controllers. Some fail completely, others
>>> rarely. Here is a quick summary:
>>>
>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>    and a hung task crash.
>>> - megasas and megasas-gen2 fail with
>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>    followed by
>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>    and a hung task crash
>>> - mptsas1068 fails completely (no kernel log message seen)
>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>
>> I think none of those drivers have ever been tested
>> on physical hardware either.
>> So I'm astonished that it even worked that far :-)
>>
> I actually do have a dc390 board somewhere. I used it some time ago to improve
> the emulation.

Do you have a physical hppa box too?

>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>
> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
> either. Sorry, I confused that with some old notes.
>
> Either case, I think I found the problem. After handling an interrupt, the Linux
> driver checks if another interrupt is pending. It does that by checking the
> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
> interrupt handler. Problem with that is that the emulation sets DMA_DONE
> prematurely, before it sets the command done bit in the interrupt status register
> and before it sets the interrupt pending bit in the status register. As result,
> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
> I fixed that up in my code and will test it for some time and with various
> architectures before I send a patch.

Thanks for testing.
But I wonder if the Linux kernel driver needs (on physical hardware!) some more
cache flushing too. I see it uses dma_alloc_coherent(), but I don't see
dma_sync_single_for_device() or dma_sync_sg_for_cpu().
Those are needed for dma on hppa...

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/7/23 13:47, Helge Deller wrote:
> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
> 
> On 12/7/23 22:08, Guenter Roeck wrote:
>> Hi Helge,
>>
>> On 12/6/23 13:43, Helge Deller wrote:
>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>> [ ... ]
>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>> of CPUs would you recommend ?
>>>>>
>>>>> I think 4 CPUs is realistic.
>>>>> But I agree, that you probably see more issues.
>>>>>
>>>>> Generally the assumption was, that the different caches on parisc
>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>
>>>>
>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>> stable,
>>>
>>> cool!
>>>
>>>> with the exception of SCSI controllers. Some fail completely, others
>>>> rarely. Here is a quick summary:
>>>>
>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>    and a hung task crash.
>>>> - megasas and megasas-gen2 fail with
>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>    followed by
>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>    and a hung task crash
>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>
>>> I think none of those drivers have ever been tested
>>> on physical hardware either.
>>> So I'm astonished that it even worked that far :-)
>>>
>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>> the emulation.
> 
> Do you have a physical hppa box too?
> 

No, I used that on an old PC with "real" PCI slots.

>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>
>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>> either. Sorry, I confused that with some old notes.
>>
>> Either case, I think I found the problem. After handling an interrupt, the Linux
>> driver checks if another interrupt is pending. It does that by checking the
>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>> prematurely, before it sets the command done bit in the interrupt status register
>> and before it sets the interrupt pending bit in the status register. As result,
>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>> I fixed that up in my code and will test it for some time and with various
>> architectures before I send a patch.
> 
> Thanks for testing.
> But I wonder if the Linux kernel driver needs (on physical hardware!) some more
> cache flushing too. I see it uses dma_alloc_coherent(), but I don't see
> dma_sync_single_for_device() or dma_sync_sg_for_cpu().
> Those are needed for dma on hppa...
> 

Ah, testing that is beyond my capabilities. All I know is that it worked fine on
an old PC running Linux.

Guenter

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 07/12/2023 21:47, Helge Deller wrote:

> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)

Thanks for the ping!

> On 12/7/23 22:08, Guenter Roeck wrote:
>> Hi Helge,
>>
>> On 12/6/23 13:43, Helge Deller wrote:
>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>> [ ... ]
>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>> of CPUs would you recommend ?
>>>>>
>>>>> I think 4 CPUs is realistic.
>>>>> But I agree, that you probably see more issues.
>>>>>
>>>>> Generally the assumption was, that the different caches on parisc
>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>
>>>>
>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>> stable,
>>>
>>> cool!
>>>
>>>> with the exception of SCSI controllers. Some fail completely, others
>>>> rarely. Here is a quick summary:
>>>>
>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>    and a hung task crash.
>>>> - megasas and megasas-gen2 fail with
>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>    followed by
>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>    and a hung task crash
>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>
>>> I think none of those drivers have ever been tested
>>> on physical hardware either.
>>> So I'm astonished that it even worked that far :-)
>>>
>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>> the emulation.
> 
> Do you have a physical hppa box too?
> 
>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>
>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>> either. Sorry, I confused that with some old notes.
>>
>> Either case, I think I found the problem. After handling an interrupt, the Linux
>> driver checks if another interrupt is pending. It does that by checking the
>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>> prematurely, before it sets the command done bit in the interrupt status register
>> and before it sets the interrupt pending bit in the status register. As result,
>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>> I fixed that up in my code and will test it for some time and with various
>> architectures before I send a patch.

I'm actually in the process of putting the finishing touches to a large rewrite of 
QEMU's core ESP emulation since there are a number of known issues with the existing 
version. In particular there are problems with the SCSI phase being set incorrectly 
after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. Note that this is 
just the ESP core rather than the ESP PCI device.

If you are interested, I could try and find a few minutes to tidy it up a bit more 
and push a testing branch to Github?


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 00:01, Mark Cave-Ayland wrote:
> On 07/12/2023 21:47, Helge Deller wrote:
> 
>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
> 
> Thanks for the ping!
> 
>> On 12/7/23 22:08, Guenter Roeck wrote:
>>> Hi Helge,
>>>
>>> On 12/6/23 13:43, Helge Deller wrote:
>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>> [ ... ]
>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>> of CPUs would you recommend ?
>>>>>>
>>>>>> I think 4 CPUs is realistic.
>>>>>> But I agree, that you probably see more issues.
>>>>>>
>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>
>>>>>
>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>> stable,
>>>>
>>>> cool!
>>>>
>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>> rarely. Here is a quick summary:
>>>>>
>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>    and a hung task crash.
>>>>> - megasas and megasas-gen2 fail with
>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>    followed by
>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>    and a hung task crash
>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>
>>>> I think none of those drivers have ever been tested
>>>> on physical hardware either.
>>>> So I'm astonished that it even worked that far :-)
>>>>
>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>> the emulation.
>>
>> Do you have a physical hppa box too?
>>
>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>
>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>> either. Sorry, I confused that with some old notes.
>>>
>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>> driver checks if another interrupt is pending. It does that by checking the
>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>> prematurely, before it sets the command done bit in the interrupt status register
>>> and before it sets the interrupt pending bit in the status register. As result,
>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>> I fixed that up in my code and will test it for some time and with various
>>> architectures before I send a patch.
> 
> I'm actually in the process of putting the finishing touches to a large rewrite of QEMU's core ESP emulation since there are a number of known issues with the existing version. In particular there are problems with the SCSI phase being set incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. Note that this is just the ESP core rather than the ESP PCI device.
> 
> If you are interested, I could try and find a few minutes to tidy it up a bit more and push a testing branch to Github?
> 

Sure, I'll be happy to give your changes a try.

FWIW, the change I made to fix the spurious interrupt problem is

diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
index 6794acaebc..f624398c55 100644
--- a/hw/scsi/esp-pci.c
+++ b/hw/scsi/esp-pci.c
@@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t *buf, int len,
      /* update status registers */
      pci->dma_regs[DMA_WBC] -= len;
      pci->dma_regs[DMA_WAC] += len;
-    if (pci->dma_regs[DMA_WBC] == 0) {
-        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
-    }
  }

I tested that with several platforms. There are no more spurious interrupts
after that change, and no other errors either.

Regarding TC after reading the interrupt register, I carry the following
patch locally.

diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index 9b11d8c573..f0cd8705a7 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -986,7 +986,7 @@ uint64_t esp_reg_read(ESPState *s, uint32_t saddr)
           */
          val = s->rregs[ESP_RINTR];
          s->rregs[ESP_RINTR] = 0;
-        s->rregs[ESP_RSTAT] &= ~STAT_TC;
+        // s->rregs[ESP_RSTAT] &= ~STAT_TC;

The comment above that code says "Clear sequence step, interrupt register
and all status bits except TC", which is quite the opposite of what the code
is doing because it clears TC and nothing else. I never spent the time
trying to figure out how to fix that properly; clearing the other bits
like the comment suggests doesn't work (STAT_INT needs to be set for
esp_lower_irq() to work, and clearing the other bits results in transfer
failures).

Thanks,
Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/8/23 15:58, Guenter Roeck wrote:
> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>> On 07/12/2023 21:47, Helge Deller wrote:
>>
>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>
>> Thanks for the ping!
>>
>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>> Hi Helge,
>>>>
>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>> [ ... ]
>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>> of CPUs would you recommend ?
>>>>>>>
>>>>>>> I think 4 CPUs is realistic.
>>>>>>> But I agree, that you probably see more issues.
>>>>>>>
>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>
>>>>>>
>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>> stable,
>>>>>
>>>>> cool!
>>>>>
>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>> rarely. Here is a quick summary:
>>>>>>
>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>    and a hung task crash.
>>>>>> - megasas and megasas-gen2 fail with
>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>    followed by
>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>    and a hung task crash
>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>
>>>>> I think none of those drivers have ever been tested
>>>>> on physical hardware either.
>>>>> So I'm astonished that it even worked that far :-)
>>>>>
>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>> the emulation.
>>>
>>> Do you have a physical hppa box too?
>>>
>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>
>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>> either. Sorry, I confused that with some old notes.
>>>>
>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>> driver checks if another interrupt is pending. It does that by checking the
>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>> prematurely, before it sets the command done bit in the interrupt status register
>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>> I fixed that up in my code and will test it for some time and with various
>>>> architectures before I send a patch.
>>
>> I'm actually in the process of putting the finishing touches to a large rewrite of QEMU's core ESP emulation since there are a number of known issues with the existing version. In particular there are problems with the SCSI phase being set incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. Note that this is just the ESP core rather than the ESP PCI device.
>>
>> If you are interested, I could try and find a few minutes to tidy it up a bit more and push a testing branch to Github?
>>
>
> Sure, I'll be happy to give your changes a try.
>
> FWIW, the change I made to fix the spurious interrupt problem is
>
> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
> index 6794acaebc..f624398c55 100644
> --- a/hw/scsi/esp-pci.c
> +++ b/hw/scsi/esp-pci.c
> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t *buf, int len,
>       /* update status registers */
>       pci->dma_regs[DMA_WBC] -= len;
>       pci->dma_regs[DMA_WAC] += len;
> -    if (pci->dma_regs[DMA_WBC] == 0) {
> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
> -    }
>   }
>
> I tested that with several platforms. There are no more spurious interrupts
> after that change, and no other errors either.
>
> Regarding TC after reading the interrupt register, I carry the following
> patch locally.
>
> diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
> index 9b11d8c573..f0cd8705a7 100644
> --- a/hw/scsi/esp.c
> +++ b/hw/scsi/esp.c
> @@ -986,7 +986,7 @@ uint64_t esp_reg_read(ESPState *s, uint32_t saddr)
>            */
>           val = s->rregs[ESP_RINTR];
>           s->rregs[ESP_RINTR] = 0;
> -        s->rregs[ESP_RSTAT] &= ~STAT_TC;
> +        // s->rregs[ESP_RSTAT] &= ~STAT_TC;
>
> The comment above that code says "Clear sequence step, interrupt register
> and all status bits except TC", which is quite the opposite of what the code
> is doing because it clears TC and nothing else. I never spent the time
> trying to figure out how to fix that properly; clearing the other bits
> like the comment suggests doesn't work (STAT_INT needs to be set for
> esp_lower_irq() to work, and clearing the other bits results in transfer
> failures).

Does qemu-hppa boot for you with those patches?
Even with those I see the discs are found, but later I get:
[    8.519780] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
[    8.545363] Starting init: /sbin/init exists but couldn't execute it (error -67)
[    8.546339] Run /etc/init as init process
[    8.561422] Run /bin/init as init process
[    8.574649] Run /bin/sh as init process
[    8.580495] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm swapper/0: iget: checksum invalid
[    8.586170] Starting init: /bin/sh exists but couldn't execute it (error -67)

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 07:54, Helge Deller wrote:
[ ... ]

>> FWIW, the change I made to fix the spurious interrupt problem is
>>
>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>> index 6794acaebc..f624398c55 100644
>> --- a/hw/scsi/esp-pci.c
>> +++ b/hw/scsi/esp-pci.c
>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t *buf, int len,
>>       /* update status registers */
>>       pci->dma_regs[DMA_WBC] -= len;
>>       pci->dma_regs[DMA_WAC] += len;
>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>> -    }
>>   }
>>
>> I tested that with several platforms. There are no more spurious interrupts
>> after that change, and no other errors either.
>>
>> Regarding TC after reading the interrupt register, I carry the following
>> patch locally.
>>
>> diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
>> index 9b11d8c573..f0cd8705a7 100644
>> --- a/hw/scsi/esp.c
>> +++ b/hw/scsi/esp.c
>> @@ -986,7 +986,7 @@ uint64_t esp_reg_read(ESPState *s, uint32_t saddr)
>>            */
>>           val = s->rregs[ESP_RINTR];
>>           s->rregs[ESP_RINTR] = 0;
>> -        s->rregs[ESP_RSTAT] &= ~STAT_TC;
>> +        // s->rregs[ESP_RSTAT] &= ~STAT_TC;
>>
>> The comment above that code says "Clear sequence step, interrupt register
>> and all status bits except TC", which is quite the opposite of what the code
>> is doing because it clears TC and nothing else. I never spent the time
>> trying to figure out how to fix that properly; clearing the other bits
>> like the comment suggests doesn't work (STAT_INT needs to be set for
>> esp_lower_irq() to work, and clearing the other bits results in transfer
>> failures).
> 
> Does qemu-hppa boot for you with those patches?

Yes, tested with both 32 bit and 64 bit kernels.

> Even with those I see the discs are found, but later I get:
> [    8.519780] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
> [    8.545363] Starting init: /sbin/init exists but couldn't execute it (error -67)
> [    8.546339] Run /etc/init as init process
> [    8.561422] Run /bin/init as init process
> [    8.574649] Run /bin/sh as init process
> [    8.580495] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm swapper/0: iget: checksum invalid
> [    8.586170] Starting init: /bin/sh exists but couldn't execute it (error -67)

-67 is EBADMSG on parisc which is used by ext4 for "Bad CRC detected",
so that matches the "checksum invalid" message. I don't see that
with my root file system, but then mine is a simple ext2 file system.
I'll generate an ext4 root file system and let you know how that goes.

Guenter

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 14:58, Guenter Roeck wrote:

> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>> On 07/12/2023 21:47, Helge Deller wrote:
>>
>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>
>> Thanks for the ping!
>>
>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>> Hi Helge,
>>>>
>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>> [ ... ]
>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>> of CPUs would you recommend ?
>>>>>>>
>>>>>>> I think 4 CPUs is realistic.
>>>>>>> But I agree, that you probably see more issues.
>>>>>>>
>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>
>>>>>>
>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>> stable,
>>>>>
>>>>> cool!
>>>>>
>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>> rarely. Here is a quick summary:
>>>>>>
>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>    and a hung task crash.
>>>>>> - megasas and megasas-gen2 fail with
>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>    followed by
>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>    and a hung task crash
>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>
>>>>> I think none of those drivers have ever been tested
>>>>> on physical hardware either.
>>>>> So I'm astonished that it even worked that far :-)
>>>>>
>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>> the emulation.
>>>
>>> Do you have a physical hppa box too?
>>>
>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen 
>>>>> for the
>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>
>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>> either. Sorry, I confused that with some old notes.
>>>>
>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>> driver checks if another interrupt is pending. It does that by checking the
>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>> prematurely, before it sets the command done bit in the interrupt status register
>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>> I fixed that up in my code and will test it for some time and with various
>>>> architectures before I send a patch.
>>
>> I'm actually in the process of putting the finishing touches to a large rewrite of 
>> QEMU's core ESP emulation since there are a number of known issues with the 
>> existing version. In particular there are problems with the SCSI phase being set 
>> incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. Note 
>> that this is just the ESP core rather than the ESP PCI device.
>>
>> If you are interested, I could try and find a few minutes to tidy it up a bit more 
>> and push a testing branch to Github?
>>
> 
> Sure, I'll be happy to give your changes a try.
> 
> FWIW, the change I made to fix the spurious interrupt problem is
> 
> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
> index 6794acaebc..f624398c55 100644
> --- a/hw/scsi/esp-pci.c
> +++ b/hw/scsi/esp-pci.c
> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t *buf, 
> int len,
>       /* update status registers */
>       pci->dma_regs[DMA_WBC] -= len;
>       pci->dma_regs[DMA_WAC] += len;
> -    if (pci->dma_regs[DMA_WBC] == 0) {
> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
> -    }
>   }
> 
> I tested that with several platforms. There are no more spurious interrupts
> after that change, and no other errors either.

I suspect that this is papering over the real issue, since it appears the code being 
removed sets the DMA completion bit when then the PCI DMA transfer counter reaches zero.

> Regarding TC after reading the interrupt register, I carry the following
> patch locally.
> 
> diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
> index 9b11d8c573..f0cd8705a7 100644
> --- a/hw/scsi/esp.c
> +++ b/hw/scsi/esp.c
> @@ -986,7 +986,7 @@ uint64_t esp_reg_read(ESPState *s, uint32_t saddr)
>            */
>           val = s->rregs[ESP_RINTR];
>           s->rregs[ESP_RINTR] = 0;
> -        s->rregs[ESP_RSTAT] &= ~STAT_TC;
> +        // s->rregs[ESP_RSTAT] &= ~STAT_TC;
> 
> The comment above that code says "Clear sequence step, interrupt register
> and all status bits except TC", which is quite the opposite of what the code
> is doing because it clears TC and nothing else. I never spent the time
> trying to figure out how to fix that properly; clearing the other bits
> like the comment suggests doesn't work (STAT_INT needs to be set for
> esp_lower_irq() to work, and clearing the other bits results in transfer
> failures).

Yeah that's one of the many bugs which should be fixed by my latest series. I've 
pushed the current version of my branch with the ESP rewrite to 
https://github.com/mcayland/qemu/tree/esp-rework-testing if you would both like to 
give it a test.


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/8/23 19:53, Mark Cave-Ayland wrote:
> On 08/12/2023 14:58, Guenter Roeck wrote:
>
>> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>>> On 07/12/2023 21:47, Helge Deller wrote:
>>>
>>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>>
>>> Thanks for the ping!
>>>
>>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>>> Hi Helge,
>>>>>
>>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>>> [ ... ]
>>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>>> of CPUs would you recommend ?
>>>>>>>>
>>>>>>>> I think 4 CPUs is realistic.
>>>>>>>> But I agree, that you probably see more issues.
>>>>>>>>
>>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>>
>>>>>>>
>>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>>> stable,
>>>>>>
>>>>>> cool!
>>>>>>
>>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>>> rarely. Here is a quick summary:
>>>>>>>
>>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>>    and a hung task crash.
>>>>>>> - megasas and megasas-gen2 fail with
>>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>>    followed by
>>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>>    and a hung task crash
>>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>>
>>>>>> I think none of those drivers have ever been tested
>>>>>> on physical hardware either.
>>>>>> So I'm astonished that it even worked that far :-)
>>>>>>
>>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>>> the emulation.
>>>>
>>>> Do you have a physical hppa box too?
>>>>
>>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>>
>>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>>> either. Sorry, I confused that with some old notes.
>>>>>
>>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>>> driver checks if another interrupt is pending. It does that by checking the
>>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>>> prematurely, before it sets the command done bit in the interrupt status register
>>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>>> I fixed that up in my code and will test it for some time and with various
>>>>> architectures before I send a patch.
>>>
>>> I'm actually in the process of putting the finishing touches to a large rewrite of QEMU's core ESP emulation since there are a number of known issues with the existing version. In particular there are problems with the SCSI phase being set incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. Note that this is just the ESP core rather than the ESP PCI device.
>>>
>>> If you are interested, I could try and find a few minutes to tidy it up a bit more and push a testing branch to Github?
>>>
>>
>> Sure, I'll be happy to give your changes a try.
>>
>> FWIW, the change I made to fix the spurious interrupt problem is
>>
>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>> index 6794acaebc..f624398c55 100644
>> --- a/hw/scsi/esp-pci.c
>> +++ b/hw/scsi/esp-pci.c
>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t *buf, int len,
>>       /* update status registers */
>>       pci->dma_regs[DMA_WBC] -= len;
>>       pci->dma_regs[DMA_WAC] += len;
>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>> -    }
>>   }
>>
>> I tested that with several platforms. There are no more spurious interrupts
>> after that change, and no other errors either.
>
> I suspect that this is papering over the real issue, since it appears the code being removed sets the DMA completion bit when then the PCI DMA transfer counter reaches zero.
>
>> Regarding TC after reading the interrupt register, I carry the following
>> patch locally.
>>
>> diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
>> index 9b11d8c573..f0cd8705a7 100644
>> --- a/hw/scsi/esp.c
>> +++ b/hw/scsi/esp.c
>> @@ -986,7 +986,7 @@ uint64_t esp_reg_read(ESPState *s, uint32_t saddr)
>>            */
>>           val = s->rregs[ESP_RINTR];
>>           s->rregs[ESP_RINTR] = 0;
>> -        s->rregs[ESP_RSTAT] &= ~STAT_TC;
>> +        // s->rregs[ESP_RSTAT] &= ~STAT_TC;
>>
>> The comment above that code says "Clear sequence step, interrupt register
>> and all status bits except TC", which is quite the opposite of what the code
>> is doing because it clears TC and nothing else. I never spent the time
>> trying to figure out how to fix that properly; clearing the other bits
>> like the comment suggests doesn't work (STAT_INT needs to be set for
>> esp_lower_irq() to work, and clearing the other bits results in transfer
>> failures).
>
> Yeah that's one of the many bugs which should be fixed by my latest
> series. I've pushed the current version of my branch with the ESP
> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
> if you would both like to give it a test.

Tried it with qemu-hppa:

[    1.062381] sym53c8xx 0000:00:00.0: enabling SERR and PARITY (0107 -> 0147)
[    1.066381] sym0: <895a> rev 0x0 at pci 0000:00:00.0 irq 66
[    1.073919] sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
[    1.080618] sym0: SCSI BUS has been reset.
[    1.085325] scsi host0: sym-2.2.3
[    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
[    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
[    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
[    8.010626] scsi host1: esp
[    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
[    8.032066] scsi target1:0:0: Beginning Domain Validation
[    8.043254] scsi target1:0:0: Domain Validation skipping write tests
[    8.044284] scsi target1:0:0: Ending Domain Validation
[    8.094991] megasas: 07.727.03.00-rc1
[    8.097635] mpt3sas version 43.100.00.00 loaded
[    8.109417] st: Version 20160209, fixed bufsize 32768, s/g segs 256
[    8.123681] sd 1:0:0:0: Power-on or device reset occurred
[    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
[    8.140043] sd 1:0:0:0: [sda] Write Protect is off
[    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
[    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
[    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
[    8.237107] LASI 82596 driver - Revision: 1.30
[    8.238440] Fusion MPT base driver 3.04.20
[    8.239024] Copyright (c) 1999-2008 LSI Corporation
[    8.240965] Fusion MPT SPI Host driver 3.04.20
[    8.243040] Fusion MPT SAS Host driver 3.04.20
[    8.245172] Fusion MPT misc device (ioctl) driver 3.04.20
[    8.247849] mptctl: Registered with Fusion MPT base driver
[    8.248791] mptctl: /dev/mptctl @ (major,minor=10,220)
[    8.258484] HP SDC: No SDC found.
[    8.271496] rtc-generic rtc-generic: registered as rtc0
[    8.274606] rtc-generic rtc-generic: setting system clock to 2023-12-08T19:25:10 UTC (1702063510)
[    8.278926] device-mapper: uevent: version 1.0.3
[    8.284893] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@redhat.com
[    8.288890] hid: raw HID events driver (C) Jiri Kosina
[    8.302272] usbcore: registered new interface driver usbhid
[    8.303494] usbhid: USB HID core driver
[    8.308155] NET: Registered PF_INET6 protocol family
[    8.337076] Segment Routing with IPv6
[    8.338476] In-situ OAM (IOAM) with IPv6
[    8.340887] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    8.351957] NET: Registered PF_PACKET protocol family
[    8.596153] EXT4-fs (sda5): mounted filesystem f035d934-31b6-430e-b23d-a818f9baaf2e ro with ordered data mode. Quota mode: none.
[    8.599184] VFS: Mounted root (ext4 filesystem) readonly on device 8:5.
[    8.609270] devtmpfs: mounted
[    8.679666] Freeing unused kernel image (initmem) memory: 3072K
[    8.680679] Write protected read-only-after-init data: 2k
[    8.681338] Run /sbin/init as init process
[    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
[    8.736664] scsi host1: Spurious irq, sreg=10.
[    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
[    8.760773] Run /etc/init as init process
[    8.768268] Run /bin/init as init process
[    8.775050] Run /bin/sh as init process
[    8.777917] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm swapper/0: iget: checksum invalid
[    8.779882] scsi host1: Spurious irq, sreg=10.
[    8.780532] scsi host1: Spurious irq, sreg=13.
[    8.781094] Starting init: /bin/sh exists but couldn't execute it (error -67)
[    8.781934] Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
[    8.782740] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc4-32bit #2434
[    8.782740] Hardware name: 9000/785/C3700
[    8.782740] Backtrace:
[    8.782740]  [<104080f0>] show_stack+0x54/0x6c
[    8.782740]  [<10c09498>] dump_stack_lvl+0x58/0x7c
[    8.782740]  [<10c094d8>] dump_stack+0x1c/0x2c
[    8.782740]  [<10bf5698>] panic+0x130/0x2d4
[    8.782740]  [<10c0a024>] kernel_init+0x14c/0x150
[    8.782740]  [<1040201c>] ret_from_kernel_thread+0x1c/0x24

Helge

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/8/23 20:26, Helge Deller wrote:
>> Yeah that's one of the many bugs which should be fixed by my latest
>> series. I've pushed the current version of my branch with the ESP
>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>> if you would both like to give it a test.
>
> Tried it with qemu-hppa:
>
> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
> [    8.010626] scsi host1: esp
> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
> [    8.032066] scsi target1:0:0: Beginning Domain Validation
> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
> [    8.044284] scsi target1:0:0: Ending Domain Validation
> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
> [    8.680679] Write protected read-only-after-init data: 2k
> [    8.681338] Run /sbin/init as init process
> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
> [    8.736664] scsi host1: Spurious irq, sreg=10.
> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)

The driver isn't so bad in general.

With my current seabios-hppa from
https://github.com/hdeller/seabios-hppa/tree/devel
and booting like this:

./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img


it actually can *partly* boot from disc:
...
Selected kernel: /vmlinux from partition 2
Selected ramdisk: /initrd.img from partition 2
ELF64 executable
Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
Loading ramdisk 23869192 bytes @ 3e92a000...

Decompressing Linux... XZ-compressed data is corrupt
  -- System halted

So, it can read partition table, even load some sectors, but
the data returned can be corrupt, as the "XZ-compressed data is corrupt"
message states.
This fits with the CRC checksum errors I saw when booting
from ext4 disc.

Is the dc390/esp driver functional on other big-endian machines?

Helge

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 19:26, Helge Deller wrote:

> On 12/8/23 19:53, Mark Cave-Ayland wrote:
>> On 08/12/2023 14:58, Guenter Roeck wrote:
>>
>>> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>>>> On 07/12/2023 21:47, Helge Deller wrote:
>>>>
>>>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>>>
>>>> Thanks for the ping!
>>>>
>>>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>>>> Hi Helge,
>>>>>>
>>>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>>>> [ ... ]
>>>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>>>> of CPUs would you recommend ?
>>>>>>>>>
>>>>>>>>> I think 4 CPUs is realistic.
>>>>>>>>> But I agree, that you probably see more issues.
>>>>>>>>>
>>>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>>>> stable,
>>>>>>>
>>>>>>> cool!
>>>>>>>
>>>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>>>> rarely. Here is a quick summary:
>>>>>>>>
>>>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>>>    and a hung task crash.
>>>>>>>> - megasas and megasas-gen2 fail with
>>>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>>>    followed by
>>>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>>>    and a hung task crash
>>>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>>>
>>>>>>> I think none of those drivers have ever been tested
>>>>>>> on physical hardware either.
>>>>>>> So I'm astonished that it even worked that far :-)
>>>>>>>
>>>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>>>> the emulation.
>>>>>
>>>>> Do you have a physical hppa box too?
>>>>>
>>>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen 
>>>>>>> for the
>>>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>>>
>>>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>>>> either. Sorry, I confused that with some old notes.
>>>>>>
>>>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>>>> driver checks if another interrupt is pending. It does that by checking the
>>>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>>>> prematurely, before it sets the command done bit in the interrupt status register
>>>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>>>> I fixed that up in my code and will test it for some time and with various
>>>>>> architectures before I send a patch.
>>>>
>>>> I'm actually in the process of putting the finishing touches to a large rewrite 
>>>> of QEMU's core ESP emulation since there are a number of known issues with the 
>>>> existing version. In particular there are problems with the SCSI phase being set 
>>>> incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. 
>>>> Note that this is just the ESP core rather than the ESP PCI device.
>>>>
>>>> If you are interested, I could try and find a few minutes to tidy it up a bit 
>>>> more and push a testing branch to Github?
>>>>
>>>
>>> Sure, I'll be happy to give your changes a try.
>>>
>>> FWIW, the change I made to fix the spurious interrupt problem is
>>>
>>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>>> index 6794acaebc..f624398c55 100644
>>> --- a/hw/scsi/esp-pci.c
>>> +++ b/hw/scsi/esp-pci.c
>>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t 
>>> *buf, int len,
>>>       /* update status registers */
>>>       pci->dma_regs[DMA_WBC] -= len;
>>>       pci->dma_regs[DMA_WAC] += len;
>>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>>> -    }
>>>   }
>>>
>>> I tested that with several platforms. There are no more spurious interrupts
>>> after that change, and no other errors either.
>>
>> I suspect that this is papering over the real issue, since it appears the code 
>> being removed sets the DMA completion bit when then the PCI DMA transfer counter 
>> reaches zero.
>>
>>> Regarding TC after reading the interrupt register, I carry the following
>>> patch locally.
>>>
>>> diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
>>> index 9b11d8c573..f0cd8705a7 100644
>>> --- a/hw/scsi/esp.c
>>> +++ b/hw/scsi/esp.c
>>> @@ -986,7 +986,7 @@ uint64_t esp_reg_read(ESPState *s, uint32_t saddr)
>>>            */
>>>           val = s->rregs[ESP_RINTR];
>>>           s->rregs[ESP_RINTR] = 0;
>>> -        s->rregs[ESP_RSTAT] &= ~STAT_TC;
>>> +        // s->rregs[ESP_RSTAT] &= ~STAT_TC;
>>>
>>> The comment above that code says "Clear sequence step, interrupt register
>>> and all status bits except TC", which is quite the opposite of what the code
>>> is doing because it clears TC and nothing else. I never spent the time
>>> trying to figure out how to fix that properly; clearing the other bits
>>> like the comment suggests doesn't work (STAT_INT needs to be set for
>>> esp_lower_irq() to work, and clearing the other bits results in transfer
>>> failures).
>>
>> Yeah that's one of the many bugs which should be fixed by my latest
>> series. I've pushed the current version of my branch with the ESP
>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>> if you would both like to give it a test.
> 
> Tried it with qemu-hppa:
> 
> [    1.062381] sym53c8xx 0000:00:00.0: enabling SERR and PARITY (0107 -> 0147)
> [    1.066381] sym0: <895a> rev 0x0 at pci 0000:00:00.0 irq 66
> [    1.073919] sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> [    1.080618] sym0: SCSI BUS has been reset.
> [    1.085325] scsi host0: sym-2.2.3
> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
> [    8.010626] scsi host1: esp
> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 
> ANSI: 5
> [    8.032066] scsi target1:0:0: Beginning Domain Validation
> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
> [    8.044284] scsi target1:0:0: Ending Domain Validation
> [    8.094991] megasas: 07.727.03.00-rc1
> [    8.097635] mpt3sas version 43.100.00.00 loaded
> [    8.109417] st: Version 20160209, fixed bufsize 32768, s/g segs 256
> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
> support DPO or FUA
> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
> [    8.237107] LASI 82596 driver - Revision: 1.30
> [    8.238440] Fusion MPT base driver 3.04.20
> [    8.239024] Copyright (c) 1999-2008 LSI Corporation
> [    8.240965] Fusion MPT SPI Host driver 3.04.20
> [    8.243040] Fusion MPT SAS Host driver 3.04.20
> [    8.245172] Fusion MPT misc device (ioctl) driver 3.04.20
> [    8.247849] mptctl: Registered with Fusion MPT base driver
> [    8.248791] mptctl: /dev/mptctl @ (major,minor=10,220)
> [    8.258484] HP SDC: No SDC found.
> [    8.271496] rtc-generic rtc-generic: registered as rtc0
> [    8.274606] rtc-generic rtc-generic: setting system clock to 2023-12-08T19:25:10 
> UTC (1702063510)
> [    8.278926] device-mapper: uevent: version 1.0.3
> [    8.284893] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: 
> dm-devel@redhat.com
> [    8.288890] hid: raw HID events driver (C) Jiri Kosina
> [    8.302272] usbcore: registered new interface driver usbhid
> [    8.303494] usbhid: USB HID core driver
> [    8.308155] NET: Registered PF_INET6 protocol family
> [    8.337076] Segment Routing with IPv6
> [    8.338476] In-situ OAM (IOAM) with IPv6
> [    8.340887] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> [    8.351957] NET: Registered PF_PACKET protocol family
> [    8.596153] EXT4-fs (sda5): mounted filesystem 
> f035d934-31b6-430e-b23d-a818f9baaf2e ro with ordered data mode. Quota mode: none.
> [    8.599184] VFS: Mounted root (ext4 filesystem) readonly on device 8:5.
> [    8.609270] devtmpfs: mounted
> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
> [    8.680679] Write protected read-only-after-init data: 2k
> [    8.681338] Run /sbin/init as init process
> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm 
> swapper/0: iget: checksum invalid
> [    8.736664] scsi host1: Spurious irq, sreg=10.
> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
> [    8.760773] Run /etc/init as init process
> [    8.768268] Run /bin/init as init process
> [    8.775050] Run /bin/sh as init process
> [    8.777917] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm 
> swapper/0: iget: checksum invalid
> [    8.779882] scsi host1: Spurious irq, sreg=10.
> [    8.780532] scsi host1: Spurious irq, sreg=13.
> [    8.781094] Starting init: /bin/sh exists but couldn't execute it (error -67)
> [    8.781934] Kernel panic - not syncing: No working init found.  Try passing init= 
> option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
> [    8.782740] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc4-32bit #2434
> [    8.782740] Hardware name: 9000/785/C3700
> [    8.782740] Backtrace:
> [    8.782740]  [<104080f0>] show_stack+0x54/0x6c
> [    8.782740]  [<10c09498>] dump_stack_lvl+0x58/0x7c
> [    8.782740]  [<10c094d8>] dump_stack+0x1c/0x2c
> [    8.782740]  [<10bf5698>] panic+0x130/0x2d4
> [    8.782740]  [<10c0a024>] kernel_init+0x14c/0x150
> [    8.782740]  [<1040201c>] ret_from_kernel_thread+0x1c/0x24

Ah that's a shame, I was really hoping that would solve the issue. Unless there is 
something amiss with the esp-pci device? I haven't really spent any time looking at 
the PCI DMA implementation.


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 19:37, Helge Deller wrote:

> On 12/8/23 20:26, Helge Deller wrote:
>>> Yeah that's one of the many bugs which should be fixed by my latest
>>> series. I've pushed the current version of my branch with the ESP
>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>> if you would both like to give it a test.
>>
>> Tried it with qemu-hppa:
>>
>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>> [    8.010626] scsi host1: esp
>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 
>> ANSI: 5
>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
>> support DPO or FUA
>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>> [    8.680679] Write protected read-only-after-init data: 2k
>> [    8.681338] Run /sbin/init as init process
>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm 
>> swapper/0: iget: checksum invalid
>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
> 
> The driver isn't so bad in general.
> 
> With my current seabios-hppa from
> https://github.com/hdeller/seabios-hppa/tree/devel
> and booting like this:
> 
> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial 
> mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi 
> -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
> 
> 
> it actually can *partly* boot from disc:
> ...
> Selected kernel: /vmlinux from partition 2
> Selected ramdisk: /initrd.img from partition 2
> ELF64 executable
> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
> Loading ramdisk 23869192 bytes @ 3e92a000...
> 
> Decompressing Linux... XZ-compressed data is corrupt
>   -- System halted
> 
> So, it can read partition table, even load some sectors, but
> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
> message states.
> This fits with the CRC checksum errors I saw when booting
> from ext4 disc.
> 
> Is the dc390/esp driver functional on other big-endian machines?

Yes it is, in fact the majority of my test images were from SPARC/m68k (including a 
hppa image) and the series in its current form passes all my boot tests except for an 
x86 DOS image with ASPI.

The command line I used for testing hppa is below:

./qemu-system-hppa \
     -kernel vmlinux-parisc \
     -no-reboot \
     -snapshot \
     -device am53c974,id=scsi \
     -device scsi-hd,bus=scsi.0,drive=d0 \
     -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
     -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
     -nographic -monitor null

If you are still seeing errors then I'd suspect an issue with the hppa CPU emulation 
or the esp-pci device.


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 11:37, Helge Deller wrote:
> On 12/8/23 20:26, Helge Deller wrote:
>>> Yeah that's one of the many bugs which should be fixed by my latest
>>> series. I've pushed the current version of my branch with the ESP
>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>> if you would both like to give it a test.
>>
>> Tried it with qemu-hppa:
>>
>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>> [    8.010626] scsi host1: esp
>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>> [    8.680679] Write protected read-only-after-init data: 2k
>> [    8.681338] Run /sbin/init as init process
>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
> 
> The driver isn't so bad in general.
> 
> With my current seabios-hppa from
> https://github.com/hdeller/seabios-hppa/tree/devel
> and booting like this:
> 
> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
> 
> 
> it actually can *partly* boot from disc:
> ...
> Selected kernel: /vmlinux from partition 2
> Selected ramdisk: /initrd.img from partition 2
> ELF64 executable
> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
> Loading ramdisk 23869192 bytes @ 3e92a000...
> 
> Decompressing Linux... XZ-compressed data is corrupt
>   -- System halted
> 
> So, it can read partition table, even load some sectors, but
> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
> message states.
> This fits with the CRC checksum errors I saw when booting
> from ext4 disc.
> 
> Is the dc390/esp driver functional on other big-endian machines?
> 

Yes, I have been testing it on alpha and arm64be.

Guenter

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 10:53, Mark Cave-Ayland wrote:
> On 08/12/2023 14:58, Guenter Roeck wrote:
> 
>> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>>> On 07/12/2023 21:47, Helge Deller wrote:
>>>
>>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>>
>>> Thanks for the ping!
>>>
>>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>>> Hi Helge,
>>>>>
>>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>>> [ ... ]
>>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>>> of CPUs would you recommend ?
>>>>>>>>
>>>>>>>> I think 4 CPUs is realistic.
>>>>>>>> But I agree, that you probably see more issues.
>>>>>>>>
>>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>>
>>>>>>>
>>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>>> stable,
>>>>>>
>>>>>> cool!
>>>>>>
>>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>>> rarely. Here is a quick summary:
>>>>>>>
>>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>>    and a hung task crash.
>>>>>>> - megasas and megasas-gen2 fail with
>>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>>    followed by
>>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>>    and a hung task crash
>>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>>
>>>>>> I think none of those drivers have ever been tested
>>>>>> on physical hardware either.
>>>>>> So I'm astonished that it even worked that far :-)
>>>>>>
>>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>>> the emulation.
>>>>
>>>> Do you have a physical hppa box too?
>>>>
>>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>>
>>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>>> either. Sorry, I confused that with some old notes.
>>>>>
>>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>>> driver checks if another interrupt is pending. It does that by checking the
>>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>>> prematurely, before it sets the command done bit in the interrupt status register
>>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>>> I fixed that up in my code and will test it for some time and with various
>>>>> architectures before I send a patch.
>>>
>>> I'm actually in the process of putting the finishing touches to a large rewrite of QEMU's core ESP emulation since there are a number of known issues with the existing version. In particular there are problems with the SCSI phase being set incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. Note that this is just the ESP core rather than the ESP PCI device.
>>>
>>> If you are interested, I could try and find a few minutes to tidy it up a bit more and push a testing branch to Github?
>>>
>>
>> Sure, I'll be happy to give your changes a try.
>>
>> FWIW, the change I made to fix the spurious interrupt problem is
>>
>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>> index 6794acaebc..f624398c55 100644
>> --- a/hw/scsi/esp-pci.c
>> +++ b/hw/scsi/esp-pci.c
>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t *buf, int len,
>>       /* update status registers */
>>       pci->dma_regs[DMA_WBC] -= len;
>>       pci->dma_regs[DMA_WAC] += len;
>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>> -    }
>>   }
>>
>> I tested that with several platforms. There are no more spurious interrupts
>> after that change, and no other errors either.
> 
> I suspect that this is papering over the real issue, since it appears the code being removed sets the DMA completion bit when then the PCI DMA transfer counter reaches zero.
> 

DMA_STAT_DONE is also set in esp_pci_command_complete(), so it doesn't get lost.

Problem is that the Linux kernel driver assumes that the interrupt status bit
is set in parallel with DMA_STAT_DONE. The spurious interrupt is seen because
that is not the case. There may be a better solution, of course. I'll be happy
to give it a try if you find a better solution.

Guenter

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 11:45, Mark Cave-Ayland wrote:
> On 08/12/2023 19:26, Helge Deller wrote:
> 
>> On 12/8/23 19:53, Mark Cave-Ayland wrote:
>>> On 08/12/2023 14:58, Guenter Roeck wrote:
>>>
>>>> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>>>>> On 07/12/2023 21:47, Helge Deller wrote:
>>>>>
>>>>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>>>>
>>>>> Thanks for the ping!
>>>>>
>>>>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>>>>> Hi Helge,
>>>>>>>
>>>>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>>>>> [ ... ]
>>>>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>>>>> of CPUs would you recommend ?
>>>>>>>>>>
>>>>>>>>>> I think 4 CPUs is realistic.
>>>>>>>>>> But I agree, that you probably see more issues.
>>>>>>>>>>
>>>>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>>>>> stable,
>>>>>>>>
>>>>>>>> cool!
>>>>>>>>
>>>>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>>>>> rarely. Here is a quick summary:
>>>>>>>>>
>>>>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>>>>    and a hung task crash.
>>>>>>>>> - megasas and megasas-gen2 fail with
>>>>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>>>>    followed by
>>>>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>>>>    and a hung task crash
>>>>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>>>>
>>>>>>>> I think none of those drivers have ever been tested
>>>>>>>> on physical hardware either.
>>>>>>>> So I'm astonished that it even worked that far :-)
>>>>>>>>
>>>>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>>>>> the emulation.
>>>>>>
>>>>>> Do you have a physical hppa box too?
>>>>>>
>>>>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>>>>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>>>>
>>>>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>>>>> either. Sorry, I confused that with some old notes.
>>>>>>>
>>>>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>>>>> driver checks if another interrupt is pending. It does that by checking the
>>>>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>>>>> prematurely, before it sets the command done bit in the interrupt status register
>>>>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>>>>> I fixed that up in my code and will test it for some time and with various
>>>>>>> architectures before I send a patch.
>>>>>
>>>>> I'm actually in the process of putting the finishing touches to a large rewrite of QEMU's core ESP emulation since there are a number of known issues with the existing version. In particular there are problems with the SCSI phase being set incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. Note that this is just the ESP core rather than the ESP PCI device.
>>>>>
>>>>> If you are interested, I could try and find a few minutes to tidy it up a bit more and push a testing branch to Github?
>>>>>
>>>>
>>>> Sure, I'll be happy to give your changes a try.
>>>>
>>>> FWIW, the change I made to fix the spurious interrupt problem is
>>>>
>>>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>>>> index 6794acaebc..f624398c55 100644
>>>> --- a/hw/scsi/esp-pci.c
>>>> +++ b/hw/scsi/esp-pci.c
>>>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t *buf, int len,
>>>>       /* update status registers */
>>>>       pci->dma_regs[DMA_WBC] -= len;
>>>>       pci->dma_regs[DMA_WAC] += len;
>>>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>>>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>>>> -    }
>>>>   }
>>>>
>>>> I tested that with several platforms. There are no more spurious interrupts
>>>> after that change, and no other errors either.
>>>
>>> I suspect that this is papering over the real issue, since it appears the code being removed sets the DMA completion bit when then the PCI DMA transfer counter reaches zero.
>>>
>>>> Regarding TC after reading the interrupt register, I carry the following
>>>> patch locally.
>>>>
>>>> diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
>>>> index 9b11d8c573..f0cd8705a7 100644
>>>> --- a/hw/scsi/esp.c
>>>> +++ b/hw/scsi/esp.c
>>>> @@ -986,7 +986,7 @@ uint64_t esp_reg_read(ESPState *s, uint32_t saddr)
>>>>            */
>>>>           val = s->rregs[ESP_RINTR];
>>>>           s->rregs[ESP_RINTR] = 0;
>>>> -        s->rregs[ESP_RSTAT] &= ~STAT_TC;
>>>> +        // s->rregs[ESP_RSTAT] &= ~STAT_TC;
>>>>
>>>> The comment above that code says "Clear sequence step, interrupt register
>>>> and all status bits except TC", which is quite the opposite of what the code
>>>> is doing because it clears TC and nothing else. I never spent the time
>>>> trying to figure out how to fix that properly; clearing the other bits
>>>> like the comment suggests doesn't work (STAT_INT needs to be set for
>>>> esp_lower_irq() to work, and clearing the other bits results in transfer
>>>> failures).
>>>
>>> Yeah that's one of the many bugs which should be fixed by my latest
>>> series. I've pushed the current version of my branch with the ESP
>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>> if you would both like to give it a test.
>>
>> Tried it with qemu-hppa:
>>
>> [    1.062381] sym53c8xx 0000:00:00.0: enabling SERR and PARITY (0107 -> 0147)
>> [    1.066381] sym0: <895a> rev 0x0 at pci 0000:00:00.0 irq 66
>> [    1.073919] sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
>> [    1.080618] sym0: SCSI BUS has been reset.
>> [    1.085325] scsi host0: sym-2.2.3
>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>> [    8.010626] scsi host1: esp
>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>> [    8.094991] megasas: 07.727.03.00-rc1
>> [    8.097635] mpt3sas version 43.100.00.00 loaded
>> [    8.109417] st: Version 20160209, fixed bufsize 32768, s/g segs 256
>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>> [    8.237107] LASI 82596 driver - Revision: 1.30
>> [    8.238440] Fusion MPT base driver 3.04.20
>> [    8.239024] Copyright (c) 1999-2008 LSI Corporation
>> [    8.240965] Fusion MPT SPI Host driver 3.04.20
>> [    8.243040] Fusion MPT SAS Host driver 3.04.20
>> [    8.245172] Fusion MPT misc device (ioctl) driver 3.04.20
>> [    8.247849] mptctl: Registered with Fusion MPT base driver
>> [    8.248791] mptctl: /dev/mptctl @ (major,minor=10,220)
>> [    8.258484] HP SDC: No SDC found.
>> [    8.271496] rtc-generic rtc-generic: registered as rtc0
>> [    8.274606] rtc-generic rtc-generic: setting system clock to 2023-12-08T19:25:10 UTC (1702063510)
>> [    8.278926] device-mapper: uevent: version 1.0.3
>> [    8.284893] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@redhat.com
>> [    8.288890] hid: raw HID events driver (C) Jiri Kosina
>> [    8.302272] usbcore: registered new interface driver usbhid
>> [    8.303494] usbhid: USB HID core driver
>> [    8.308155] NET: Registered PF_INET6 protocol family
>> [    8.337076] Segment Routing with IPv6
>> [    8.338476] In-situ OAM (IOAM) with IPv6
>> [    8.340887] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
>> [    8.351957] NET: Registered PF_PACKET protocol family
>> [    8.596153] EXT4-fs (sda5): mounted filesystem f035d934-31b6-430e-b23d-a818f9baaf2e ro with ordered data mode. Quota mode: none.
>> [    8.599184] VFS: Mounted root (ext4 filesystem) readonly on device 8:5.
>> [    8.609270] devtmpfs: mounted
>> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>> [    8.680679] Write protected read-only-after-init data: 2k
>> [    8.681338] Run /sbin/init as init process
>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>> [    8.760773] Run /etc/init as init process
>> [    8.768268] Run /bin/init as init process
>> [    8.775050] Run /bin/sh as init process
>> [    8.777917] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm swapper/0: iget: checksum invalid
>> [    8.779882] scsi host1: Spurious irq, sreg=10.
>> [    8.780532] scsi host1: Spurious irq, sreg=13.
>> [    8.781094] Starting init: /bin/sh exists but couldn't execute it (error -67)
>> [    8.781934] Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
>> [    8.782740] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc4-32bit #2434
>> [    8.782740] Hardware name: 9000/785/C3700
>> [    8.782740] Backtrace:
>> [    8.782740]  [<104080f0>] show_stack+0x54/0x6c
>> [    8.782740]  [<10c09498>] dump_stack_lvl+0x58/0x7c
>> [    8.782740]  [<10c094d8>] dump_stack+0x1c/0x2c
>> [    8.782740]  [<10bf5698>] panic+0x130/0x2d4
>> [    8.782740]  [<10c0a024>] kernel_init+0x14c/0x150
>> [    8.782740]  [<1040201c>] ret_from_kernel_thread+0x1c/0x24
> 
> Ah that's a shame, I was really hoping that would solve the issue. Unless there is something amiss with the esp-pci device? I haven't really spent any time looking at the PCI DMA implementation.
> 

The "technical manual" for AM53C974 from AMD states that an interrupt is supposed
to be generated when the DMA DONE bit is set. The esp-pci code does not do that.

Guenter

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 07:54, Helge Deller wrote:
[ ... ]

> 
> Does qemu-hppa boot for you with those patches?
> Even with those I see the discs are found, but later I get:
> [    8.519780] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
> [    8.545363] Starting init: /sbin/init exists but couldn't execute it (error -67)
> [    8.546339] Run /etc/init as init process
> [    8.561422] Run /bin/init as init process
> [    8.574649] Run /bin/sh as init process
> [    8.580495] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm swapper/0: iget: checksum invalid
> [    8.586170] Starting init: /bin/sh exists but couldn't execute it (error -67)
> 

This is what I get when trying to boot from an ext4 file system:

[   30.664669] Unaligned handler failed, ret = -14
[   30.665314]       _______________________________
[   30.665314]      < Your System ate a SPARC! Gah! >
[   30.665314]       -------------------------------
[   30.665314]              \   ^__^
[   30.665314]                  (__)\       )\/\
[   30.665314]                   U  ||----w |
[   30.665314]                      ||     ||
[   30.665925] ip (pid 689): Unaligned data reference (code 28)
[   30.666282] CPU: 0 PID: 689 Comm: ip Tainted: G                 N 6.7.0-rc4-64bit+ #1
[   30.666487] Hardware name: 9000/785/C3700
[   30.666724]
[   30.666812]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[   30.666978] PSW: 00001000000001001111111100001111 Tainted: G                 N
[   30.667164] r00-03  000000ff0804ff0f 00000000413f57c0 00000000401e15c0 00000000451d8d60
[   30.667351] r04-07  00000000412d5fc0 00000000451d8c78 00000000411bcfe0 00000000417813f8
[   30.667511] r08-11  000000004128e7c0 0000000000000010 00000000000000a0 0000000073c00008
[   30.667665] r12-15  0000000000000000 0000000000000cc0 0000000043086000 0000000041f29640
[   30.667817] r16-19  0000000000000040 00000000451d8a10 0000000041ede0c0 0000000000000000
[   30.667968] r20-23  ffffffffffe00009 0000000073c00008 000000006bc23fd9 000000000fc212c1
[   30.668119] r24-27  0000000000000000 0000000000000008 081e0241371e0200 00000000412d5fc0
[   30.668273] r28-31  0000000000000000 00000000451d8e00 00000000451d8e30 00000000f8ce25bc
[   30.669027] sr00-03  0000000000016c00 0000000000000000 0000000000000000 0000000000016c00
[   30.669292] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   30.669523]
[   30.669615] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e160c 00000000401e15ec
[   30.669870]  IIR: 0fe010dc    ISR: 0000000000000000  IOR: 00000000f8ce25bc
[   30.670072]  CPU:        0   CR30: 0000000043086000 CR31: 0000000000000000
[   30.670270]  ORIG_R28: 00000000402a48b8
[   30.670407]  IAOQ[0]: unwind_once+0x5dc/0x5e0
[   30.671165]  IAOQ[1]: unwind_once+0x5bc/0x5e0
[   30.671332]  RP(r2): unwind_once+0x590/0x5e0
[   30.671575] Backtrace:
[   30.671804]  [<00000000401e482c>] walk_stackframe.constprop.0+0xb4/0x138
[   30.672059]  [<00000000401e48e8>] arch_stack_walk+0x38/0x50
[   30.672232]  [<00000000402a8a8c>] stack_trace_save+0x5c/0x78
[   30.673233]  [<00000000403b2cc4>] set_track_prepare+0x5c/0xa0
[   30.673694]  [<00000000403ba8ec>] ___slab_alloc+0x554/0x930
[   30.673917]  [<00000000403bad28>] __slab_alloc.constprop.0+0x60/0x88
[   30.674141]  [<00000000403bb354>] kmem_cache_alloc+0xf4/0x280
[   30.674342]  [<0000000040389d10>] __anon_vma_prepare+0x98/0x2d0
[   30.674554]  [<0000000040374f50>] __handle_mm_fault+0x410/0xe00
[   30.674752]  [<0000000040375a6c>] handle_mm_fault+0x12c/0x230
[   30.674947]  [<00000000401cc6e0>] do_page_fault+0x1c0/0x708
[   30.675173]  [<00000000401d0b90>] handle_interruption+0xa88/0xbc0
[   30.675367]  [<00000000411bd000>] arch_atomic64_add+0x20/0xb0

That is also seen randomly when booting from other controllers, so it is
not specific to the scsi driver.

Guenter

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 11:55, Mark Cave-Ayland wrote:
> On 08/12/2023 19:37, Helge Deller wrote:
> 
>> On 12/8/23 20:26, Helge Deller wrote:
>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>> series. I've pushed the current version of my branch with the ESP
>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>> if you would both like to give it a test.
>>>
>>> Tried it with qemu-hppa:
>>>
>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>>> [    8.010626] scsi host1: esp
>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>> [    8.680679] Write protected read-only-after-init data: 2k
>>> [    8.681338] Run /sbin/init as init process
>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>
>> The driver isn't so bad in general.
>>
>> With my current seabios-hppa from
>> https://github.com/hdeller/seabios-hppa/tree/devel
>> and booting like this:
>>
>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>
>>
>> it actually can *partly* boot from disc:
>> ...
>> Selected kernel: /vmlinux from partition 2
>> Selected ramdisk: /initrd.img from partition 2
>> ELF64 executable
>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>
>> Decompressing Linux... XZ-compressed data is corrupt
>>   -- System halted
>>
>> So, it can read partition table, even load some sectors, but
>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>> message states.
>> This fits with the CRC checksum errors I saw when booting
>> from ext4 disc.
>>
>> Is the dc390/esp driver functional on other big-endian machines?
> 
> Yes it is, in fact the majority of my test images were from SPARC/m68k (including a hppa image) and the series in its current form passes all my boot tests except for an x86 DOS image with ASPI.
> 
> The command line I used for testing hppa is below:
> 
> ./qemu-system-hppa \
>      -kernel vmlinux-parisc \
>      -no-reboot \
>      -snapshot \
>      -device am53c974,id=scsi \
>      -device scsi-hd,bus=scsi.0,drive=d0 \
>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>      -nographic -monitor null
> 
> If you are still seeing errors then I'd suspect an issue with the hppa CPU emulation or the esp-pci device.
> 

I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
while I get unaligned access crashes with ext4. I started some tests with btrfs
and f2fs in addition to ext2 to see how those are doing.

Guenter

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 11:37, Helge Deller wrote:
> On 12/8/23 20:26, Helge Deller wrote:
>>> Yeah that's one of the many bugs which should be fixed by my latest
>>> series. I've pushed the current version of my branch with the ESP
>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>> if you would both like to give it a test.
>>
>> Tried it with qemu-hppa:
>>
>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>> [    8.010626] scsi host1: esp
>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>> [    8.680679] Write protected read-only-after-init data: 2k
>> [    8.681338] Run /sbin/init as init process
>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
> 
> The driver isn't so bad in general.
> 
> With my current seabios-hppa from
> https://github.com/hdeller/seabios-hppa/tree/devel
> and booting like this:
> 
> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
> 
> 
> it actually can *partly* boot from disc:
> ...
> Selected kernel: /vmlinux from partition 2
> Selected ramdisk: /initrd.img from partition 2
> ELF64 executable
> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
> Loading ramdisk 23869192 bytes @ 3e92a000...
> 
> Decompressing Linux... XZ-compressed data is corrupt
>   -- System halted
> 
> So, it can read partition table, even load some sectors, but
> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
> message states.
> This fits with the CRC checksum errors I saw when booting
> from ext4 disc.
> 
> Is the dc390/esp driver functional on other big-endian machines?
> 

It might make sense to try booting from some other controller. I tried
various usb variants as well as nvme, sata-cmd646, and sdhci (mmc).
This would help identifying if the problem has to do with your ext4 image.
I am not saying that the ext4 image is bad, but it might trigger something
that the emulation doesn't like.

Guenter

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 19:56, Guenter Roeck wrote:

> On 12/8/23 10:53, Mark Cave-Ayland wrote:
>> On 08/12/2023 14:58, Guenter Roeck wrote:
>>
>>> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>>>> On 07/12/2023 21:47, Helge Deller wrote:
>>>>
>>>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>>>
>>>> Thanks for the ping!
>>>>
>>>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>>>> Hi Helge,
>>>>>>
>>>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>>>> [ ... ]
>>>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>>>> of CPUs would you recommend ?
>>>>>>>>>
>>>>>>>>> I think 4 CPUs is realistic.
>>>>>>>>> But I agree, that you probably see more issues.
>>>>>>>>>
>>>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>>>> stable,
>>>>>>>
>>>>>>> cool!
>>>>>>>
>>>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>>>> rarely. Here is a quick summary:
>>>>>>>>
>>>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>>>    and a hung task crash.
>>>>>>>> - megasas and megasas-gen2 fail with
>>>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>>>    followed by
>>>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>>>    and a hung task crash
>>>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>>>
>>>>>>> I think none of those drivers have ever been tested
>>>>>>> on physical hardware either.
>>>>>>> So I'm astonished that it even worked that far :-)
>>>>>>>
>>>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>>>> the emulation.
>>>>>
>>>>> Do you have a physical hppa box too?
>>>>>
>>>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen 
>>>>>>> for the
>>>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>>>
>>>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>>>> either. Sorry, I confused that with some old notes.
>>>>>>
>>>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>>>> driver checks if another interrupt is pending. It does that by checking the
>>>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>>>> prematurely, before it sets the command done bit in the interrupt status register
>>>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>>>> I fixed that up in my code and will test it for some time and with various
>>>>>> architectures before I send a patch.
>>>>
>>>> I'm actually in the process of putting the finishing touches to a large rewrite 
>>>> of QEMU's core ESP emulation since there are a number of known issues with the 
>>>> existing version. In particular there are problems with the SCSI phase being set 
>>>> incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. 
>>>> Note that this is just the ESP core rather than the ESP PCI device.
>>>>
>>>> If you are interested, I could try and find a few minutes to tidy it up a bit 
>>>> more and push a testing branch to Github?
>>>>
>>>
>>> Sure, I'll be happy to give your changes a try.
>>>
>>> FWIW, the change I made to fix the spurious interrupt problem is
>>>
>>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>>> index 6794acaebc..f624398c55 100644
>>> --- a/hw/scsi/esp-pci.c
>>> +++ b/hw/scsi/esp-pci.c
>>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t 
>>> *buf, int len,
>>>       /* update status registers */
>>>       pci->dma_regs[DMA_WBC] -= len;
>>>       pci->dma_regs[DMA_WAC] += len;
>>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>>> -    }
>>>   }
>>>
>>> I tested that with several platforms. There are no more spurious interrupts
>>> after that change, and no other errors either.
>>
>> I suspect that this is papering over the real issue, since it appears the code 
>> being removed sets the DMA completion bit when then the PCI DMA transfer counter 
>> reaches zero.
>>
> 
> DMA_STAT_DONE is also set in esp_pci_command_complete(), so it doesn't get lost.

That doesn't seem right from a QEMU perspective: the command_complete callback is 
invoked when the SCSI layer has completed its data transfer to the emulated device, 
or immediately if there is no data phase. From a DMA perspective triggering an 
interrupt when the byte counter is zero feels like it should be the correct behaviour.

> Problem is that the Linux kernel driver assumes that the interrupt status bit
> is set in parallel with DMA_STAT_DONE. The spurious interrupt is seen because
> that is not the case. There may be a better solution, of course. I'll be happy
> to give it a try if you find a better solution.

Could you provide a github link to the file/line in question so I can have a look?


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 20:09, Guenter Roeck wrote:
> On 12/8/23 11:45, Mark Cave-Ayland wrote:
>> On 08/12/2023 19:26, Helge Deller wrote:
>>
>>> On 12/8/23 19:53, Mark Cave-Ayland wrote:
>>>> On 08/12/2023 14:58, Guenter Roeck wrote:
>>>>
>>>>> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>>>>>> On 07/12/2023 21:47, Helge Deller wrote:
>>>>>>
>>>>>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>>>>>
>>>>>> Thanks for the ping!
>>>>>>
>>>>>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>>>>>> Hi Helge,
>>>>>>>>
>>>>>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>>>>>> [ ... ]
>>>>>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>>>>>> of CPUs would you recommend ?
>>>>>>>>>>>
>>>>>>>>>>> I think 4 CPUs is realistic.
>>>>>>>>>>> But I agree, that you probably see more issues.
>>>>>>>>>>>
>>>>>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>>>>>> stable,
>>>>>>>>>
>>>>>>>>> cool!
>>>>>>>>>
>>>>>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>>>>>> rarely. Here is a quick summary:
>>>>>>>>>>
>>>>>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>>>>>    and a hung task crash.
>>>>>>>>>> - megasas and megasas-gen2 fail with
>>>>>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>>>>>    followed by
>>>>>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>>>>>    and a hung task crash
>>>>>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>>>>>
>>>>>>>>> I think none of those drivers have ever been tested
>>>>>>>>> on physical hardware either.
>>>>>>>>> So I'm astonished that it even worked that far :-)
>>>>>>>>>
>>>>>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>>>>>> the emulation.
>>>>>>>
>>>>>>> Do you have a physical hppa box too?
>>>>>>>
>>>>>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only 
>>>>>>>>> happen for the
>>>>>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>>>>>
>>>>>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>>>>>> either. Sorry, I confused that with some old notes.
>>>>>>>>
>>>>>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>>>>>> driver checks if another interrupt is pending. It does that by checking the
>>>>>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>>>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>>>>>> prematurely, before it sets the command done bit in the interrupt status 
>>>>>>>> register
>>>>>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>>>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>>>>>> I fixed that up in my code and will test it for some time and with various
>>>>>>>> architectures before I send a patch.
>>>>>>
>>>>>> I'm actually in the process of putting the finishing touches to a large rewrite 
>>>>>> of QEMU's core ESP emulation since there are a number of known issues with the 
>>>>>> existing version. In particular there are problems with the SCSI phase being 
>>>>>> set incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being 
>>>>>> correct. Note that this is just the ESP core rather than the ESP PCI device.
>>>>>>
>>>>>> If you are interested, I could try and find a few minutes to tidy it up a bit 
>>>>>> more and push a testing branch to Github?
>>>>>>
>>>>>
>>>>> Sure, I'll be happy to give your changes a try.
>>>>>
>>>>> FWIW, the change I made to fix the spurious interrupt problem is
>>>>>
>>>>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>>>>> index 6794acaebc..f624398c55 100644
>>>>> --- a/hw/scsi/esp-pci.c
>>>>> +++ b/hw/scsi/esp-pci.c
>>>>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t 
>>>>> *buf, int len,
>>>>>       /* update status registers */
>>>>>       pci->dma_regs[DMA_WBC] -= len;
>>>>>       pci->dma_regs[DMA_WAC] += len;
>>>>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>>>>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>>>>> -    }
>>>>>   }
>>>>>
>>>>> I tested that with several platforms. There are no more spurious interrupts
>>>>> after that change, and no other errors either.
>>>>
>>>> I suspect that this is papering over the real issue, since it appears the code 
>>>> being removed sets the DMA completion bit when then the PCI DMA transfer counter 
>>>> reaches zero.
>>>>
>>>>> Regarding TC after reading the interrupt register, I carry the following
>>>>> patch locally.
>>>>>
>>>>> diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
>>>>> index 9b11d8c573..f0cd8705a7 100644
>>>>> --- a/hw/scsi/esp.c
>>>>> +++ b/hw/scsi/esp.c
>>>>> @@ -986,7 +986,7 @@ uint64_t esp_reg_read(ESPState *s, uint32_t saddr)
>>>>>            */
>>>>>           val = s->rregs[ESP_RINTR];
>>>>>           s->rregs[ESP_RINTR] = 0;
>>>>> -        s->rregs[ESP_RSTAT] &= ~STAT_TC;
>>>>> +        // s->rregs[ESP_RSTAT] &= ~STAT_TC;
>>>>>
>>>>> The comment above that code says "Clear sequence step, interrupt register
>>>>> and all status bits except TC", which is quite the opposite of what the code
>>>>> is doing because it clears TC and nothing else. I never spent the time
>>>>> trying to figure out how to fix that properly; clearing the other bits
>>>>> like the comment suggests doesn't work (STAT_INT needs to be set for
>>>>> esp_lower_irq() to work, and clearing the other bits results in transfer
>>>>> failures).
>>>>
>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>> series. I've pushed the current version of my branch with the ESP
>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>> if you would both like to give it a test.
>>>
>>> Tried it with qemu-hppa:
>>>
>>> [    1.062381] sym53c8xx 0000:00:00.0: enabling SERR and PARITY (0107 -> 0147)
>>> [    1.066381] sym0: <895a> rev 0x0 at pci 0000:00:00.0 irq 66
>>> [    1.073919] sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
>>> [    1.080618] sym0: SCSI BUS has been reset.
>>> [    1.085325] scsi host0: sym-2.2.3
>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>>> [    8.010626] scsi host1: esp
>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 
>>> 0 ANSI: 5
>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>> [    8.094991] megasas: 07.727.03.00-rc1
>>> [    8.097635] mpt3sas version 43.100.00.00 loaded
>>> [    8.109417] st: Version 20160209, fixed bufsize 32768, s/g segs 256
>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>>> doesn't support DPO or FUA
>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>> [    8.237107] LASI 82596 driver - Revision: 1.30
>>> [    8.238440] Fusion MPT base driver 3.04.20
>>> [    8.239024] Copyright (c) 1999-2008 LSI Corporation
>>> [    8.240965] Fusion MPT SPI Host driver 3.04.20
>>> [    8.243040] Fusion MPT SAS Host driver 3.04.20
>>> [    8.245172] Fusion MPT misc device (ioctl) driver 3.04.20
>>> [    8.247849] mptctl: Registered with Fusion MPT base driver
>>> [    8.248791] mptctl: /dev/mptctl @ (major,minor=10,220)
>>> [    8.258484] HP SDC: No SDC found.
>>> [    8.271496] rtc-generic rtc-generic: registered as rtc0
>>> [    8.274606] rtc-generic rtc-generic: setting system clock to 
>>> 2023-12-08T19:25:10 UTC (1702063510)
>>> [    8.278926] device-mapper: uevent: version 1.0.3
>>> [    8.284893] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: 
>>> dm-devel@redhat.com
>>> [    8.288890] hid: raw HID events driver (C) Jiri Kosina
>>> [    8.302272] usbcore: registered new interface driver usbhid
>>> [    8.303494] usbhid: USB HID core driver
>>> [    8.308155] NET: Registered PF_INET6 protocol family
>>> [    8.337076] Segment Routing with IPv6
>>> [    8.338476] In-situ OAM (IOAM) with IPv6
>>> [    8.340887] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
>>> [    8.351957] NET: Registered PF_PACKET protocol family
>>> [    8.596153] EXT4-fs (sda5): mounted filesystem 
>>> f035d934-31b6-430e-b23d-a818f9baaf2e ro with ordered data mode. Quota mode: none.
>>> [    8.599184] VFS: Mounted root (ext4 filesystem) readonly on device 8:5.
>>> [    8.609270] devtmpfs: mounted
>>> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>> [    8.680679] Write protected read-only-after-init data: 2k
>>> [    8.681338] Run /sbin/init as init process
>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm 
>>> swapper/0: iget: checksum invalid
>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>> [    8.760773] Run /etc/init as init process
>>> [    8.768268] Run /bin/init as init process
>>> [    8.775050] Run /bin/sh as init process
>>> [    8.777917] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm 
>>> swapper/0: iget: checksum invalid
>>> [    8.779882] scsi host1: Spurious irq, sreg=10.
>>> [    8.780532] scsi host1: Spurious irq, sreg=13.
>>> [    8.781094] Starting init: /bin/sh exists but couldn't execute it (error -67)
>>> [    8.781934] Kernel panic - not syncing: No working init found.  Try passing 
>>> init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
>>> [    8.782740] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc4-32bit #2434
>>> [    8.782740] Hardware name: 9000/785/C3700
>>> [    8.782740] Backtrace:
>>> [    8.782740]  [<104080f0>] show_stack+0x54/0x6c
>>> [    8.782740]  [<10c09498>] dump_stack_lvl+0x58/0x7c
>>> [    8.782740]  [<10c094d8>] dump_stack+0x1c/0x2c
>>> [    8.782740]  [<10bf5698>] panic+0x130/0x2d4
>>> [    8.782740]  [<10c0a024>] kernel_init+0x14c/0x150
>>> [    8.782740]  [<1040201c>] ret_from_kernel_thread+0x1c/0x24
>>
>> Ah that's a shame, I was really hoping that would solve the issue. Unless there is 
>> something amiss with the esp-pci device? I haven't really spent any time looking at 
>> the PCI DMA implementation.
>>
> 
> The "technical manual" for AM53C974 from AMD states that an interrupt is supposed
> to be generated when the DMA DONE bit is set. The esp-pci code does not do that.

Yeah that seems odd. I'm currently having a look at 
http://www.bitsavers.org/components/amd/_dataSheets/1993_53c974_PCscsi.pdf to 
understand a bit more as to how the PCI DMA block works.


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 20:11, Guenter Roeck wrote:

> On 12/8/23 07:54, Helge Deller wrote:
> [ ... ]
> 
>>
>> Does qemu-hppa boot for you with those patches?
>> Even with those I see the discs are found, but later I get:
>> [    8.519780] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm 
>> swapper/0: iget: checksum invalid
>> [    8.545363] Starting init: /sbin/init exists but couldn't execute it (error -67)
>> [    8.546339] Run /etc/init as init process
>> [    8.561422] Run /bin/init as init process
>> [    8.574649] Run /bin/sh as init process
>> [    8.580495] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm 
>> swapper/0: iget: checksum invalid
>> [    8.586170] Starting init: /bin/sh exists but couldn't execute it (error -67)
>>
> 
> This is what I get when trying to boot from an ext4 file system:
> 
> [   30.664669] Unaligned handler failed, ret = -14
> [   30.665314]       _______________________________
> [   30.665314]      < Your System ate a SPARC! Gah! >
> [   30.665314]       -------------------------------
> [   30.665314]              \   ^__^
> [   30.665314]                  (__)\       )\/\
> [   30.665314]                   U  ||----w |
> [   30.665314]                      ||     ||
> [   30.665925] ip (pid 689): Unaligned data reference (code 28)
> [   30.666282] CPU: 0 PID: 689 Comm: ip Tainted: G                 N 6.7.0-rc4-64bit+ #1
> [   30.666487] Hardware name: 9000/785/C3700
> [   30.666724]
> [   30.666812]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [   30.666978] PSW: 00001000000001001111111100001111 Tainted: G                 N
> [   30.667164] r00-03  000000ff0804ff0f 00000000413f57c0 00000000401e15c0 
> 00000000451d8d60
> [   30.667351] r04-07  00000000412d5fc0 00000000451d8c78 00000000411bcfe0 
> 00000000417813f8
> [   30.667511] r08-11  000000004128e7c0 0000000000000010 00000000000000a0 
> 0000000073c00008
> [   30.667665] r12-15  0000000000000000 0000000000000cc0 0000000043086000 
> 0000000041f29640
> [   30.667817] r16-19  0000000000000040 00000000451d8a10 0000000041ede0c0 
> 0000000000000000
> [   30.667968] r20-23  ffffffffffe00009 0000000073c00008 000000006bc23fd9 
> 000000000fc212c1
> [   30.668119] r24-27  0000000000000000 0000000000000008 081e0241371e0200 
> 00000000412d5fc0
> [   30.668273] r28-31  0000000000000000 00000000451d8e00 00000000451d8e30 
> 00000000f8ce25bc
> [   30.669027] sr00-03  0000000000016c00 0000000000000000 0000000000000000 
> 0000000000016c00
> [   30.669292] sr04-07  0000000000000000 0000000000000000 0000000000000000 
> 0000000000000000
> [   30.669523]
> [   30.669615] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e160c 
> 00000000401e15ec
> [   30.669870]  IIR: 0fe010dc    ISR: 0000000000000000  IOR: 00000000f8ce25bc
> [   30.670072]  CPU:        0   CR30: 0000000043086000 CR31: 0000000000000000
> [   30.670270]  ORIG_R28: 00000000402a48b8
> [   30.670407]  IAOQ[0]: unwind_once+0x5dc/0x5e0
> [   30.671165]  IAOQ[1]: unwind_once+0x5bc/0x5e0
> [   30.671332]  RP(r2): unwind_once+0x590/0x5e0
> [   30.671575] Backtrace:
> [   30.671804]  [<00000000401e482c>] walk_stackframe.constprop.0+0xb4/0x138
> [   30.672059]  [<00000000401e48e8>] arch_stack_walk+0x38/0x50
> [   30.672232]  [<00000000402a8a8c>] stack_trace_save+0x5c/0x78
> [   30.673233]  [<00000000403b2cc4>] set_track_prepare+0x5c/0xa0
> [   30.673694]  [<00000000403ba8ec>] ___slab_alloc+0x554/0x930
> [   30.673917]  [<00000000403bad28>] __slab_alloc.constprop.0+0x60/0x88
> [   30.674141]  [<00000000403bb354>] kmem_cache_alloc+0xf4/0x280
> [   30.674342]  [<0000000040389d10>] __anon_vma_prepare+0x98/0x2d0
> [   30.674554]  [<0000000040374f50>] __handle_mm_fault+0x410/0xe00
> [   30.674752]  [<0000000040375a6c>] handle_mm_fault+0x12c/0x230
> [   30.674947]  [<00000000401cc6e0>] do_page_fault+0x1c0/0x708
> [   30.675173]  [<00000000401d0b90>] handle_interruption+0xa88/0xbc0
> [   30.675367]  [<00000000411bd000>] arch_atomic64_add+0x20/0xb0
> 
> That is also seen randomly when booting from other controllers, so it is
> not specific to the scsi driver.

This certainly feels like a CPU emulation bug, for example checksums as used by ext4 
may make use of optimised instructions for performance which aren't commonly used.


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 20:28, Guenter Roeck wrote:
> On 12/8/23 11:55, Mark Cave-Ayland wrote:
>> On 08/12/2023 19:37, Helge Deller wrote:
>>
>>> On 12/8/23 20:26, Helge Deller wrote:
>>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>>> series. I've pushed the current version of my branch with the ESP
>>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>>> if you would both like to give it a test.
>>>>
>>>> Tried it with qemu-hppa:
>>>>
>>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI 
>>>> ID 15
>>>> [    8.010626] scsi host1: esp
>>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 
>>>> 0 ANSI: 5
>>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>>>> doesn't support DPO or FUA
>>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>>> [    8.680679] Write protected read-only-after-init data: 2k
>>>> [    8.681338] Run /sbin/init as init process
>>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm 
>>>> swapper/0: iget: checksum invalid
>>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>>
>>> The driver isn't so bad in general.
>>>
>>> With my current seabios-hppa from
>>> https://github.com/hdeller/seabios-hppa/tree/devel
>>> and booting like this:
>>>
>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial 
>>> mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi 
>>> -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>>
>>>
>>> it actually can *partly* boot from disc:
>>> ...
>>> Selected kernel: /vmlinux from partition 2
>>> Selected ramdisk: /initrd.img from partition 2
>>> ELF64 executable
>>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>>
>>> Decompressing Linux... XZ-compressed data is corrupt
>>>   -- System halted
>>>
>>> So, it can read partition table, even load some sectors, but
>>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>>> message states.
>>> This fits with the CRC checksum errors I saw when booting
>>> from ext4 disc.
>>>
>>> Is the dc390/esp driver functional on other big-endian machines?
>>
>> Yes it is, in fact the majority of my test images were from SPARC/m68k (including a 
>> hppa image) and the series in its current form passes all my boot tests except for 
>> an x86 DOS image with ASPI.
>>
>> The command line I used for testing hppa is below:
>>
>> ./qemu-system-hppa \
>>      -kernel vmlinux-parisc \
>>      -no-reboot \
>>      -snapshot \
>>      -device am53c974,id=scsi \
>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>      -nographic -monitor null
>>
>> If you are still seeing errors then I'd suspect an issue with the hppa CPU 
>> emulation or the esp-pci device.
>>
> 
> I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
> while I get unaligned access crashes with ext4. I started some tests with btrfs
> and f2fs in addition to ext2 to see how those are doing.

That sounds really useful, thanks for testing.


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 20:32, Guenter Roeck wrote:

> On 12/8/23 11:37, Helge Deller wrote:
>> On 12/8/23 20:26, Helge Deller wrote:
>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>> series. I've pushed the current version of my branch with the ESP
>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>> if you would both like to give it a test.
>>>
>>> Tried it with qemu-hppa:
>>>
>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>>> [    8.010626] scsi host1: esp
>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 
>>> 0 ANSI: 5
>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>>> doesn't support DPO or FUA
>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>> [    8.680679] Write protected read-only-after-init data: 2k
>>> [    8.681338] Run /sbin/init as init process
>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm 
>>> swapper/0: iget: checksum invalid
>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>
>> The driver isn't so bad in general.
>>
>> With my current seabios-hppa from
>> https://github.com/hdeller/seabios-hppa/tree/devel
>> and booting like this:
>>
>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial 
>> mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi 
>> -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>
>>
>> it actually can *partly* boot from disc:
>> ...
>> Selected kernel: /vmlinux from partition 2
>> Selected ramdisk: /initrd.img from partition 2
>> ELF64 executable
>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>
>> Decompressing Linux... XZ-compressed data is corrupt
>>   -- System halted
>>
>> So, it can read partition table, even load some sectors, but
>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>> message states.
>> This fits with the CRC checksum errors I saw when booting
>> from ext4 disc.
>>
>> Is the dc390/esp driver functional on other big-endian machines?
>>
> 
> It might make sense to try booting from some other controller. I tried
> various usb variants as well as nvme, sata-cmd646, and sdhci (mmc).
> This would help identifying if the problem has to do with your ext4 image.
> I am not saying that the ext4 image is bad, but it might trigger something
> that the emulation doesn't like.

I've also had cases working on the ESP series whereby an error would corrupt the 
underlying disk image, and then I'd roll back to an earlier commit and wonder why 
things had stopped working again. Restoring the working image from a backup made 
things start to function as expected.

For testing in QEMU I highly recommend using a qcow2 image with the -snapshot option 
so that the original image remains untouched regardless of any bugs in the emulation.


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/8/23 22:23, Mark Cave-Ayland wrote:
> On 08/12/2023 20:11, Guenter Roeck wrote:
>
>> On 12/8/23 07:54, Helge Deller wrote:
>> [ ... ]
>>
>>>
>>> Does qemu-hppa boot for you with those patches?
>>> Even with those I see the discs are found, but later I get:
>>> [    8.519780] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>> [    8.545363] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>> [    8.546339] Run /etc/init as init process
>>> [    8.561422] Run /bin/init as init process
>>> [    8.574649] Run /bin/sh as init process
>>> [    8.580495] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm swapper/0: iget: checksum invalid
>>> [    8.586170] Starting init: /bin/sh exists but couldn't execute it (error -67)
>>>
>>
>> This is what I get when trying to boot from an ext4 file system:
>>
>> [   30.664669] Unaligned handler failed, ret = -14
>> [   30.665314]       _______________________________
>> [   30.665314]      < Your System ate a SPARC! Gah! >
>> [   30.665314]       -------------------------------
>> [   30.665314]              \   ^__^
>> [   30.665314]                  (__)\       )\/\
>> [   30.665314]                   U  ||----w |
>> [   30.665314]                      ||     ||
>> [   30.665925] ip (pid 689): Unaligned data reference (code 28)
>> [   30.666282] CPU: 0 PID: 689 Comm: ip Tainted: G                 N 6.7.0-rc4-64bit+ #1
>> [   30.666487] Hardware name: 9000/785/C3700
>> [   30.666724]
>> [   30.666812]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>> [   30.666978] PSW: 00001000000001001111111100001111 Tainted: G                 N
>> [   30.667164] r00-03  000000ff0804ff0f 00000000413f57c0 00000000401e15c0 00000000451d8d60
>> [   30.667351] r04-07  00000000412d5fc0 00000000451d8c78 00000000411bcfe0 00000000417813f8
>> [   30.667511] r08-11  000000004128e7c0 0000000000000010 00000000000000a0 0000000073c00008
>> [   30.667665] r12-15  0000000000000000 0000000000000cc0 0000000043086000 0000000041f29640
>> [   30.667817] r16-19  0000000000000040 00000000451d8a10 0000000041ede0c0 0000000000000000
>> [   30.667968] r20-23  ffffffffffe00009 0000000073c00008 000000006bc23fd9 000000000fc212c1
>> [   30.668119] r24-27  0000000000000000 0000000000000008 081e0241371e0200 00000000412d5fc0
>> [   30.668273] r28-31  0000000000000000 00000000451d8e00 00000000451d8e30 00000000f8ce25bc
>> [   30.669027] sr00-03  0000000000016c00 0000000000000000 0000000000000000 0000000000016c00
>> [   30.669292] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [   30.669523]
>> [   30.669615] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e160c 00000000401e15ec
>> [   30.669870]  IIR: 0fe010dc    ISR: 0000000000000000  IOR: 00000000f8ce25bc
>> [   30.670072]  CPU:        0   CR30: 0000000043086000 CR31: 0000000000000000
>> [   30.670270]  ORIG_R28: 00000000402a48b8
>> [   30.670407]  IAOQ[0]: unwind_once+0x5dc/0x5e0
>> [   30.671165]  IAOQ[1]: unwind_once+0x5bc/0x5e0
>> [   30.671332]  RP(r2): unwind_once+0x590/0x5e0
>> [   30.671575] Backtrace:
>> [   30.671804]  [<00000000401e482c>] walk_stackframe.constprop.0+0xb4/0x138
>> [   30.672059]  [<00000000401e48e8>] arch_stack_walk+0x38/0x50
>> [   30.672232]  [<00000000402a8a8c>] stack_trace_save+0x5c/0x78
>> [   30.673233]  [<00000000403b2cc4>] set_track_prepare+0x5c/0xa0
>> [   30.673694]  [<00000000403ba8ec>] ___slab_alloc+0x554/0x930
>> [   30.673917]  [<00000000403bad28>] __slab_alloc.constprop.0+0x60/0x88
>> [   30.674141]  [<00000000403bb354>] kmem_cache_alloc+0xf4/0x280
>> [   30.674342]  [<0000000040389d10>] __anon_vma_prepare+0x98/0x2d0
>> [   30.674554]  [<0000000040374f50>] __handle_mm_fault+0x410/0xe00
>> [   30.674752]  [<0000000040375a6c>] handle_mm_fault+0x12c/0x230
>> [   30.674947]  [<00000000401cc6e0>] do_page_fault+0x1c0/0x708
>> [   30.675173]  [<00000000401d0b90>] handle_interruption+0xa88/0xbc0
>> [   30.675367]  [<00000000411bd000>] arch_atomic64_add+0x20/0xb0
>>
>> That is also seen randomly when booting from other controllers, so it is
>> not specific to the scsi driver.
>
> This certainly feels like a CPU emulation bug, for example checksums
> as used by ext4 may make use of optimised instructions for
> performance which aren't commonly used.>

Although CPU emulation bug might be true (I suspect something like that too),
this specific crash is due to a bug in the unwind_once() function.
This patch:
https://github.com/hdeller/linux/commit/3c4092001f4c2e9c842afd60d1391a0b6ed4565e
should fix it. It's in my for-next tree.
But it doesn't crash on physical hardware, so some kind of emulation bug
is still there too.

Helge

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/8/23 22:25, Mark Cave-Ayland wrote:
> On 08/12/2023 20:28, Guenter Roeck wrote:
>> On 12/8/23 11:55, Mark Cave-Ayland wrote:
>>> On 08/12/2023 19:37, Helge Deller wrote:
>>>
>>>> On 12/8/23 20:26, Helge Deller wrote:
>>>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>>>> series. I've pushed the current version of my branch with the ESP
>>>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>>>> if you would both like to give it a test.
>>>>>
>>>>> Tried it with qemu-hppa:
>>>>>
>>>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>>>>> [    8.010626] scsi host1: esp
>>>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
>>>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>>>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>>>> [    8.680679] Write protected read-only-after-init data: 2k
>>>>> [    8.681338] Run /sbin/init as init process
>>>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>>>
>>>> The driver isn't so bad in general.
>>>>
>>>> With my current seabios-hppa from
>>>> https://github.com/hdeller/seabios-hppa/tree/devel
>>>> and booting like this:
>>>>
>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>>>
>>>>
>>>> it actually can *partly* boot from disc:
>>>> ...
>>>> Selected kernel: /vmlinux from partition 2
>>>> Selected ramdisk: /initrd.img from partition 2
>>>> ELF64 executable
>>>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>>>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>>>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>>>
>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>   -- System halted
>>>>
>>>> So, it can read partition table, even load some sectors, but
>>>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>>>> message states.
>>>> This fits with the CRC checksum errors I saw when booting
>>>> from ext4 disc.
>>>>
>>>> Is the dc390/esp driver functional on other big-endian machines?
>>>
>>> Yes it is, in fact the majority of my test images were from SPARC/m68k (including a hppa image) and the series in its current form passes all my boot tests except for an x86 DOS image with ASPI.
>>>
>>> The command line I used for testing hppa is below:
>>>
>>> ./qemu-system-hppa \
>>>      -kernel vmlinux-parisc \
>>>      -no-reboot \
>>>      -snapshot \
>>>      -device am53c974,id=scsi \
>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>      -nographic -monitor null
>>>
>>> If you are still seeing errors then I'd suspect an issue with the hppa CPU emulation or the esp-pci device.
>>>
>>
>> I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
>> while I get unaligned access crashes with ext4. I started some tests with btrfs
>> and f2fs in addition to ext2 to see how those are doing.
>
> That sounds really useful, thanks for testing.

I think there are multiple issues.
Most likely some CPU emulation bug, maybe happens in CRC checksumming.

Nevertheless, with this command:
./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
I get this error:
Decompressing Linux... XZ-compressed data is corrupt

Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
At this stage no linux kernel is loaded yet, it's just the seabios-hppa
which loaded some scsi blocks into memory.

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 13:20, Mark Cave-Ayland wrote:

[ ... ]

>>>
>>
>> The "technical manual" for AM53C974 from AMD states that an interrupt is supposed
>> to be generated when the DMA DONE bit is set. The esp-pci code does not do that.
> 
> Yeah that seems odd. I'm currently having a look at http://www.bitsavers.org/components/amd/_dataSheets/1993_53c974_PCscsi.pdf to understand a bit more as to how the PCI DMA block works.
> 
Yes, that is the document I was referring to.

I tried your patch series. Without the esp-pci patch it keeps failing
with spurious interrupts and with subsequent command aborts. With the
esp-pci patch applied it works just fine. This only applies to ext2
images. ext4, btrfs, and f2fs fail badly with C3700 and a 64-bit kernel,
but that does not seem to be related to the esp driver.

Next step will be to test 32-bit kernels with both C3700 and B160L.

Guenter

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 14:05, Helge Deller wrote:
> On 12/8/23 22:23, Mark Cave-Ayland wrote:
>> On 08/12/2023 20:11, Guenter Roeck wrote:
>>
>>> On 12/8/23 07:54, Helge Deller wrote:
>>> [ ... ]
>>>
>>>>
>>>> Does qemu-hppa boot for you with those patches?
>>>> Even with those I see the discs are found, but later I get:
>>>> [    8.519780] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>>> [    8.545363] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>>> [    8.546339] Run /etc/init as init process
>>>> [    8.561422] Run /bin/init as init process
>>>> [    8.574649] Run /bin/sh as init process
>>>> [    8.580495] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm swapper/0: iget: checksum invalid
>>>> [    8.586170] Starting init: /bin/sh exists but couldn't execute it (error -67)
>>>>
>>>
>>> This is what I get when trying to boot from an ext4 file system:
>>>
>>> [   30.664669] Unaligned handler failed, ret = -14
>>> [   30.665314]       _______________________________
>>> [   30.665314]      < Your System ate a SPARC! Gah! >
>>> [   30.665314]       -------------------------------
>>> [   30.665314]              \   ^__^
>>> [   30.665314]                  (__)\       )\/\
>>> [   30.665314]                   U  ||----w |
>>> [   30.665314]                      ||     ||
>>> [   30.665925] ip (pid 689): Unaligned data reference (code 28)
>>> [   30.666282] CPU: 0 PID: 689 Comm: ip Tainted: G                 N 6.7.0-rc4-64bit+ #1
>>> [   30.666487] Hardware name: 9000/785/C3700
>>> [   30.666724]
>>> [   30.666812]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>> [   30.666978] PSW: 00001000000001001111111100001111 Tainted: G                 N
>>> [   30.667164] r00-03  000000ff0804ff0f 00000000413f57c0 00000000401e15c0 00000000451d8d60
>>> [   30.667351] r04-07  00000000412d5fc0 00000000451d8c78 00000000411bcfe0 00000000417813f8
>>> [   30.667511] r08-11  000000004128e7c0 0000000000000010 00000000000000a0 0000000073c00008
>>> [   30.667665] r12-15  0000000000000000 0000000000000cc0 0000000043086000 0000000041f29640
>>> [   30.667817] r16-19  0000000000000040 00000000451d8a10 0000000041ede0c0 0000000000000000
>>> [   30.667968] r20-23  ffffffffffe00009 0000000073c00008 000000006bc23fd9 000000000fc212c1
>>> [   30.668119] r24-27  0000000000000000 0000000000000008 081e0241371e0200 00000000412d5fc0
>>> [   30.668273] r28-31  0000000000000000 00000000451d8e00 00000000451d8e30 00000000f8ce25bc
>>> [   30.669027] sr00-03  0000000000016c00 0000000000000000 0000000000000000 0000000000016c00
>>> [   30.669292] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> [   30.669523]
>>> [   30.669615] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e160c 00000000401e15ec
>>> [   30.669870]  IIR: 0fe010dc    ISR: 0000000000000000  IOR: 00000000f8ce25bc
>>> [   30.670072]  CPU:        0   CR30: 0000000043086000 CR31: 0000000000000000
>>> [   30.670270]  ORIG_R28: 00000000402a48b8
>>> [   30.670407]  IAOQ[0]: unwind_once+0x5dc/0x5e0
>>> [   30.671165]  IAOQ[1]: unwind_once+0x5bc/0x5e0
>>> [   30.671332]  RP(r2): unwind_once+0x590/0x5e0
>>> [   30.671575] Backtrace:
>>> [   30.671804]  [<00000000401e482c>] walk_stackframe.constprop.0+0xb4/0x138
>>> [   30.672059]  [<00000000401e48e8>] arch_stack_walk+0x38/0x50
>>> [   30.672232]  [<00000000402a8a8c>] stack_trace_save+0x5c/0x78
>>> [   30.673233]  [<00000000403b2cc4>] set_track_prepare+0x5c/0xa0
>>> [   30.673694]  [<00000000403ba8ec>] ___slab_alloc+0x554/0x930
>>> [   30.673917]  [<00000000403bad28>] __slab_alloc.constprop.0+0x60/0x88
>>> [   30.674141]  [<00000000403bb354>] kmem_cache_alloc+0xf4/0x280
>>> [   30.674342]  [<0000000040389d10>] __anon_vma_prepare+0x98/0x2d0
>>> [   30.674554]  [<0000000040374f50>] __handle_mm_fault+0x410/0xe00
>>> [   30.674752]  [<0000000040375a6c>] handle_mm_fault+0x12c/0x230
>>> [   30.674947]  [<00000000401cc6e0>] do_page_fault+0x1c0/0x708
>>> [   30.675173]  [<00000000401d0b90>] handle_interruption+0xa88/0xbc0
>>> [   30.675367]  [<00000000411bd000>] arch_atomic64_add+0x20/0xb0
>>>
>>> That is also seen randomly when booting from other controllers, so it is
>>> not specific to the scsi driver.
>>
>> This certainly feels like a CPU emulation bug, for example checksums
>> as used by ext4 may make use of optimised instructions for
>> performance which aren't commonly used.>
> 
> Although CPU emulation bug might be true (I suspect something like that too),
> this specific crash is due to a bug in the unwind_once() function.
> This patch:
> https://github.com/hdeller/linux/commit/3c4092001f4c2e9c842afd60d1391a0b6ed4565e
> should fix it. It's in my for-next tree.
> But it doesn't crash on physical hardware, so some kind of emulation bug
> is still there too.
> 

ext4, f2fs, and btrfs work fine for me with a 32-bit kernel. I'll try the 64-bit
tests again with your kernel patch applied.

Guenter

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 13:19, Mark Cave-Ayland wrote:
> On 08/12/2023 19:56, Guenter Roeck wrote:
> 
>> On 12/8/23 10:53, Mark Cave-Ayland wrote:
>>> On 08/12/2023 14:58, Guenter Roeck wrote:
>>>
>>>> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>>>>> On 07/12/2023 21:47, Helge Deller wrote:
>>>>>
>>>>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>>>>
>>>>> Thanks for the ping!
>>>>>
>>>>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>>>>> Hi Helge,
>>>>>>>
>>>>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>>>>> [ ... ]
>>>>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>>>>> of CPUs would you recommend ?
>>>>>>>>>>
>>>>>>>>>> I think 4 CPUs is realistic.
>>>>>>>>>> But I agree, that you probably see more issues.
>>>>>>>>>>
>>>>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>>>>> stable,
>>>>>>>>
>>>>>>>> cool!
>>>>>>>>
>>>>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>>>>> rarely. Here is a quick summary:
>>>>>>>>>
>>>>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>>>>    and a hung task crash.
>>>>>>>>> - megasas and megasas-gen2 fail with
>>>>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>>>>    followed by
>>>>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>>>>    and a hung task crash
>>>>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>>>>
>>>>>>>> I think none of those drivers have ever been tested
>>>>>>>> on physical hardware either.
>>>>>>>> So I'm astonished that it even worked that far :-)
>>>>>>>>
>>>>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>>>>> the emulation.
>>>>>>
>>>>>> Do you have a physical hppa box too?
>>>>>>
>>>>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>>>>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>>>>
>>>>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>>>>> either. Sorry, I confused that with some old notes.
>>>>>>>
>>>>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>>>>> driver checks if another interrupt is pending. It does that by checking the
>>>>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>>>>> prematurely, before it sets the command done bit in the interrupt status register
>>>>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>>>>> I fixed that up in my code and will test it for some time and with various
>>>>>>> architectures before I send a patch.
>>>>>
>>>>> I'm actually in the process of putting the finishing touches to a large rewrite of QEMU's core ESP emulation since there are a number of known issues with the existing version. In particular there are problems with the SCSI phase being set incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. Note that this is just the ESP core rather than the ESP PCI device.
>>>>>
>>>>> If you are interested, I could try and find a few minutes to tidy it up a bit more and push a testing branch to Github?
>>>>>
>>>>
>>>> Sure, I'll be happy to give your changes a try.
>>>>
>>>> FWIW, the change I made to fix the spurious interrupt problem is
>>>>
>>>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>>>> index 6794acaebc..f624398c55 100644
>>>> --- a/hw/scsi/esp-pci.c
>>>> +++ b/hw/scsi/esp-pci.c
>>>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t *buf, int len,
>>>>       /* update status registers */
>>>>       pci->dma_regs[DMA_WBC] -= len;
>>>>       pci->dma_regs[DMA_WAC] += len;
>>>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>>>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>>>> -    }
>>>>   }
>>>>
>>>> I tested that with several platforms. There are no more spurious interrupts
>>>> after that change, and no other errors either.
>>>
>>> I suspect that this is papering over the real issue, since it appears the code being removed sets the DMA completion bit when then the PCI DMA transfer counter reaches zero.
>>>
>>
>> DMA_STAT_DONE is also set in esp_pci_command_complete(), so it doesn't get lost.
> 
> That doesn't seem right from a QEMU perspective: the command_complete callback is invoked when the SCSI layer has completed its data transfer to the emulated device, or immediately if there is no data phase. From a DMA perspective triggering an interrupt when the byte counter is zero feels like it should be the correct behaviour.
> 
>> Problem is that the Linux kernel driver assumes that the interrupt status bit
>> is set in parallel with DMA_STAT_DONE. The spurious interrupt is seen because
>> that is not the case. There may be a better solution, of course. I'll be happy
>> to give it a try if you find a better solution.
> 
> Could you provide a github link to the file/line in question so I can have a look?
> 

Assuming you mean the Linux kernel:

In esp_scsi.c:

The interrupt loop is in scsi_esp_intr(). It calls esp->ops->irq_pending(esp))
to check if another interrupt is pending. Subsequently, it calls __esp_interrupt()
to handle it. __esp_interrupt() calls esp_check_spur_intr(), which expects ESP_INTR_SR
to be set.

The irq_pending function is am53c974.c:pci_esp_irq_pending(). It checks the DMA status
register and assumes that an interrupt is pending if any of (ESP_DMA_STAT_ERROR |
ESP_DMA_STAT_ABORT | ESP_DMA_STAT_DONE | ESP_DMA_STAT_SCSIINT) is set in the DMA
status register.

Hope this helps,

Guenter

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 14:05, Helge Deller wrote:
> On 12/8/23 22:23, Mark Cave-Ayland wrote:
>> On 08/12/2023 20:11, Guenter Roeck wrote:
>>
>>> On 12/8/23 07:54, Helge Deller wrote:
>>> [ ... ]
>>>
>>>>
>>>> Does qemu-hppa boot for you with those patches?
>>>> Even with those I see the discs are found, but later I get:
>>>> [    8.519780] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>>> [    8.545363] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>>> [    8.546339] Run /etc/init as init process
>>>> [    8.561422] Run /bin/init as init process
>>>> [    8.574649] Run /bin/sh as init process
>>>> [    8.580495] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787980: comm swapper/0: iget: checksum invalid
>>>> [    8.586170] Starting init: /bin/sh exists but couldn't execute it (error -67)
>>>>
>>>
>>> This is what I get when trying to boot from an ext4 file system:
>>>
>>> [   30.664669] Unaligned handler failed, ret = -14
>>> [   30.665314]       _______________________________
>>> [   30.665314]      < Your System ate a SPARC! Gah! >
>>> [   30.665314]       -------------------------------
>>> [   30.665314]              \   ^__^
>>> [   30.665314]                  (__)\       )\/\
>>> [   30.665314]                   U  ||----w |
>>> [   30.665314]                      ||     ||
>>> [   30.665925] ip (pid 689): Unaligned data reference (code 28)
>>> [   30.666282] CPU: 0 PID: 689 Comm: ip Tainted: G                 N 6.7.0-rc4-64bit+ #1
>>> [   30.666487] Hardware name: 9000/785/C3700
>>> [   30.666724]
>>> [   30.666812]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>> [   30.666978] PSW: 00001000000001001111111100001111 Tainted: G                 N
>>> [   30.667164] r00-03  000000ff0804ff0f 00000000413f57c0 00000000401e15c0 00000000451d8d60
>>> [   30.667351] r04-07  00000000412d5fc0 00000000451d8c78 00000000411bcfe0 00000000417813f8
>>> [   30.667511] r08-11  000000004128e7c0 0000000000000010 00000000000000a0 0000000073c00008
>>> [   30.667665] r12-15  0000000000000000 0000000000000cc0 0000000043086000 0000000041f29640
>>> [   30.667817] r16-19  0000000000000040 00000000451d8a10 0000000041ede0c0 0000000000000000
>>> [   30.667968] r20-23  ffffffffffe00009 0000000073c00008 000000006bc23fd9 000000000fc212c1
>>> [   30.668119] r24-27  0000000000000000 0000000000000008 081e0241371e0200 00000000412d5fc0
>>> [   30.668273] r28-31  0000000000000000 00000000451d8e00 00000000451d8e30 00000000f8ce25bc
>>> [   30.669027] sr00-03  0000000000016c00 0000000000000000 0000000000000000 0000000000016c00
>>> [   30.669292] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> [   30.669523]
>>> [   30.669615] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e160c 00000000401e15ec
>>> [   30.669870]  IIR: 0fe010dc    ISR: 0000000000000000  IOR: 00000000f8ce25bc
>>> [   30.670072]  CPU:        0   CR30: 0000000043086000 CR31: 0000000000000000
>>> [   30.670270]  ORIG_R28: 00000000402a48b8
>>> [   30.670407]  IAOQ[0]: unwind_once+0x5dc/0x5e0
>>> [   30.671165]  IAOQ[1]: unwind_once+0x5bc/0x5e0
>>> [   30.671332]  RP(r2): unwind_once+0x590/0x5e0
>>> [   30.671575] Backtrace:
>>> [   30.671804]  [<00000000401e482c>] walk_stackframe.constprop.0+0xb4/0x138
>>> [   30.672059]  [<00000000401e48e8>] arch_stack_walk+0x38/0x50
>>> [   30.672232]  [<00000000402a8a8c>] stack_trace_save+0x5c/0x78
>>> [   30.673233]  [<00000000403b2cc4>] set_track_prepare+0x5c/0xa0
>>> [   30.673694]  [<00000000403ba8ec>] ___slab_alloc+0x554/0x930
>>> [   30.673917]  [<00000000403bad28>] __slab_alloc.constprop.0+0x60/0x88
>>> [   30.674141]  [<00000000403bb354>] kmem_cache_alloc+0xf4/0x280
>>> [   30.674342]  [<0000000040389d10>] __anon_vma_prepare+0x98/0x2d0
>>> [   30.674554]  [<0000000040374f50>] __handle_mm_fault+0x410/0xe00
>>> [   30.674752]  [<0000000040375a6c>] handle_mm_fault+0x12c/0x230
>>> [   30.674947]  [<00000000401cc6e0>] do_page_fault+0x1c0/0x708
>>> [   30.675173]  [<00000000401d0b90>] handle_interruption+0xa88/0xbc0
>>> [   30.675367]  [<00000000411bd000>] arch_atomic64_add+0x20/0xb0
>>>
>>> That is also seen randomly when booting from other controllers, so it is
>>> not specific to the scsi driver.
>>
>> This certainly feels like a CPU emulation bug, for example checksums
>> as used by ext4 may make use of optimised instructions for
>> performance which aren't commonly used.>
> 
> Although CPU emulation bug might be true (I suspect something like that too),
> this specific crash is due to a bug in the unwind_once() function.
> This patch:
> https://github.com/hdeller/linux/commit/3c4092001f4c2e9c842afd60d1391a0b6ed4565e
> should fix it. It's in my for-next tree.

With that patch on top of the mainline kernel (5e3f5b81de80c98) I get

[   16.778983] Run /sbin/init as init process
[   16.795086] process '/bin/busybox' started with executable stack
[   16.906327] CPU: 0 PID: 605 Comm: init Tainted: G                 N 6.7.0-rc4-64bit+ #1
[   16.906577] Hardware name: 9000/785/C3700
[   16.906813]
[   16.906896]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[   16.907042] PSW: 00001000000001101111100000001110 Tainted: G                 N
[   16.907241] r00-03  000000ff0806f80e 00000000413931a0 00000000413564a0 00000000f922f180
[   16.907421] r04-07  000000004135f9a0 0000000043560010 0000000041cd2120 000000004486af90
[   16.907570] r08-11  0000000000000000 00000000435604c0 fffffffffffffe00 000000004138e9a0
[   16.907713] r12-15  000000004020682c fffffffffffffe00 0000000000000006 0000000000000000
[   16.907855] r16-19  0000000000000000 0000000000000000 0000000000000000 00000003ef990eec
[   16.907998] r20-23  0000000000000000 000000006d640000 0000000000000000 0000000041cd2a30
[   16.908141] r24-27  0000000041cd2a30 000000004486af90 0000000043560010 000000004135f9a0
[   16.908283] r28-31  00000000413599a0 0000000043508580 00000000451dc080 ffffffffc0000000
[   16.908443] sr00-03  0000000000000400 0000000000000000 0000000000000000 0000000000000800
[   16.908600] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   16.908600]
[   16.908600] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000413564a0 00000000413564a4
[   16.908600]  IIR: 00000000    ISR: 0000000000000000  IOR: 00000000413564a0
[   16.908600]  CPU:        0   CR30: 000000004486af90 CR31: 0000000000000000
[   16.908600]  ORIG_R28: 0000000000000000
[   16.908600]  IAOQ[0]: sys_vfork_wrapper+0x58/0x60
[   16.908600]  IAOQ[1]: 0x401cae9c00000000
[   16.908600]  RP(r2): sys_vfork_wrapper+0x58/0x60
[   16.908600] Backtrace:

That keeps repeating forever until I abort the emulation.
This is with initramfs, no drives involved.

I also tried your entire for-next branch, but unfortunately that doesn't compile
for me.

Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/8/23 23:09, Helge Deller wrote:
> On 12/8/23 22:25, Mark Cave-Ayland wrote:
>> On 08/12/2023 20:28, Guenter Roeck wrote:
>>> On 12/8/23 11:55, Mark Cave-Ayland wrote:
>>>> On 08/12/2023 19:37, Helge Deller wrote:
>>>>
>>>>> On 12/8/23 20:26, Helge Deller wrote:
>>>>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>>>>> series. I've pushed the current version of my branch with the ESP
>>>>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>>>>> if you would both like to give it a test.
>>>>>>
>>>>>> Tried it with qemu-hppa:
>>>>>>
>>>>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>>>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>>>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>>>>>> [    8.010626] scsi host1: esp
>>>>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
>>>>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>>>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>>>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>>>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>>>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>>>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>>>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>>>>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>>>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>>>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>>>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>>>>> [    8.680679] Write protected read-only-after-init data: 2k
>>>>>> [    8.681338] Run /sbin/init as init process
>>>>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>>>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>>>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>>>>
>>>>> The driver isn't so bad in general.
>>>>>
>>>>> With my current seabios-hppa from
>>>>> https://github.com/hdeller/seabios-hppa/tree/devel
>>>>> and booting like this:
>>>>>
>>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>>>>
>>>>>
>>>>> it actually can *partly* boot from disc:
>>>>> ...
>>>>> Selected kernel: /vmlinux from partition 2
>>>>> Selected ramdisk: /initrd.img from partition 2
>>>>> ELF64 executable
>>>>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>>>>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>>>>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>>>>
>>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>>   -- System halted
>>>>>
>>>>> So, it can read partition table, even load some sectors, but
>>>>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>>>>> message states.
>>>>> This fits with the CRC checksum errors I saw when booting
>>>>> from ext4 disc.
>>>>>
>>>>> Is the dc390/esp driver functional on other big-endian machines?
>>>>
>>>> Yes it is, in fact the majority of my test images were from SPARC/m68k (including a hppa image) and the series in its current form passes all my boot tests except for an x86 DOS image with ASPI.
>>>>
>>>> The command line I used for testing hppa is below:
>>>>
>>>> ./qemu-system-hppa \
>>>>      -kernel vmlinux-parisc \
>>>>      -no-reboot \
>>>>      -snapshot \
>>>>      -device am53c974,id=scsi \
>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>      -nographic -monitor null
>>>>
>>>> If you are still seeing errors then I'd suspect an issue with the hppa CPU emulation or the esp-pci device.
>>>>
>>>
>>> I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
>>> while I get unaligned access crashes with ext4. I started some tests with btrfs
>>> and f2fs in addition to ext2 to see how those are doing.
>>
>> That sounds really useful, thanks for testing.
>
> I think there are multiple issues.
> Most likely some CPU emulation bug, maybe happens in CRC checksumming.
>
> Nevertheless, with this command:
> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
> I get this error:
> Decompressing Linux... XZ-compressed data is corrupt
>
> Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
> At this stage no linux kernel is loaded yet, it's just the seabios-hppa
> which loaded some scsi blocks into memory.

Does the esp driver has a limit of only being able to
load max. 64kb at once (per SCSI command) ?
By reducing to 64kb, booting directly from Seabios-hppa
now works for me.

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/8/23 15:36, Helge Deller wrote:
> On 12/8/23 23:09, Helge Deller wrote:
>> On 12/8/23 22:25, Mark Cave-Ayland wrote:
>>> On 08/12/2023 20:28, Guenter Roeck wrote:
>>>> On 12/8/23 11:55, Mark Cave-Ayland wrote:
>>>>> On 08/12/2023 19:37, Helge Deller wrote:
>>>>>
>>>>>> On 12/8/23 20:26, Helge Deller wrote:
>>>>>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>>>>>> series. I've pushed the current version of my branch with the ESP
>>>>>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>>>>>> if you would both like to give it a test.
>>>>>>>
>>>>>>> Tried it with qemu-hppa:
>>>>>>>
>>>>>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>>>>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>>>>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>>>>>>> [    8.010626] scsi host1: esp
>>>>>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
>>>>>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>>>>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>>>>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>>>>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>>>>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>>>>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>>>>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>>>>>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>>>>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>>>>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>>>>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>>>>>> [    8.680679] Write protected read-only-after-init data: 2k
>>>>>>> [    8.681338] Run /sbin/init as init process
>>>>>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>>>>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>>>>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>>>>>
>>>>>> The driver isn't so bad in general.
>>>>>>
>>>>>> With my current seabios-hppa from
>>>>>> https://github.com/hdeller/seabios-hppa/tree/devel
>>>>>> and booting like this:
>>>>>>
>>>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>>>>>
>>>>>>
>>>>>> it actually can *partly* boot from disc:
>>>>>> ...
>>>>>> Selected kernel: /vmlinux from partition 2
>>>>>> Selected ramdisk: /initrd.img from partition 2
>>>>>> ELF64 executable
>>>>>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>>>>>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>>>>>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>>>>>
>>>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>>>   -- System halted
>>>>>>
>>>>>> So, it can read partition table, even load some sectors, but
>>>>>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>>>>>> message states.
>>>>>> This fits with the CRC checksum errors I saw when booting
>>>>>> from ext4 disc.
>>>>>>
>>>>>> Is the dc390/esp driver functional on other big-endian machines?
>>>>>
>>>>> Yes it is, in fact the majority of my test images were from SPARC/m68k (including a hppa image) and the series in its current form passes all my boot tests except for an x86 DOS image with ASPI.
>>>>>
>>>>> The command line I used for testing hppa is below:
>>>>>
>>>>> ./qemu-system-hppa \
>>>>>      -kernel vmlinux-parisc \
>>>>>      -no-reboot \
>>>>>      -snapshot \
>>>>>      -device am53c974,id=scsi \
>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>      -nographic -monitor null
>>>>>
>>>>> If you are still seeing errors then I'd suspect an issue with the hppa CPU emulation or the esp-pci device.
>>>>>
>>>>
>>>> I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
>>>> while I get unaligned access crashes with ext4. I started some tests with btrfs
>>>> and f2fs in addition to ext2 to see how those are doing.
>>>
>>> That sounds really useful, thanks for testing.
>>
>> I think there are multiple issues.
>> Most likely some CPU emulation bug, maybe happens in CRC checksumming.
>>
>> Nevertheless, with this command:
>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>> I get this error:
>> Decompressing Linux... XZ-compressed data is corrupt
>>
>> Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
>> At this stage no linux kernel is loaded yet, it's just the seabios-hppa
>> which loaded some scsi blocks into memory.
> 
> Does the esp driver has a limit of only being able to
> load max. 64kb at once (per SCSI command) ?
> By reducing to 64kb, booting directly from Seabios-hppa
> now works for me.
> 

Larger than 64k transfers are supposedly enabled by setting bit 6 of CNTLREG2.
As fas as I can see, the qemu driver does not check if the bit is set and always
supports large transfers. Unless I am missing something, the linux driver limits
DMA transfer length to 64k, so it is at least questionable if larger transfers
have ever been tested.

Guenter

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 23:36, Helge Deller wrote:

> On 12/8/23 23:09, Helge Deller wrote:
>> On 12/8/23 22:25, Mark Cave-Ayland wrote:
>>> On 08/12/2023 20:28, Guenter Roeck wrote:
>>>> On 12/8/23 11:55, Mark Cave-Ayland wrote:
>>>>> On 08/12/2023 19:37, Helge Deller wrote:
>>>>>
>>>>>> On 12/8/23 20:26, Helge Deller wrote:
>>>>>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>>>>>> series. I've pushed the current version of my branch with the ESP
>>>>>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>>>>>> if you would both like to give it a test.
>>>>>>>
>>>>>>> Tried it with qemu-hppa:
>>>>>>>
>>>>>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>>>>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>>>>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), 
>>>>>>> SCSI ID 15
>>>>>>> [    8.010626] scsi host1: esp
>>>>>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ 
>>>>>>> PQ: 0 ANSI: 5
>>>>>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>>>>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>>>>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>>>>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>>>>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 
>>>>>>> GB/100 GiB)
>>>>>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>>>>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>>>>>>> doesn't support DPO or FUA
>>>>>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>>>>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>>>>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>>>>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>>>>>> [    8.680679] Write protected read-only-after-init data: 2k
>>>>>>> [    8.681338] Run /sbin/init as init process
>>>>>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: 
>>>>>>> comm swapper/0: iget: checksum invalid
>>>>>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>>>>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error 
>>>>>>> -67)
>>>>>>
>>>>>> The driver isn't so bad in general.
>>>>>>
>>>>>> With my current seabios-hppa from
>>>>>> https://github.com/hdeller/seabios-hppa/tree/devel
>>>>>> and booting like this:
>>>>>>
>>>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  
>>>>>> -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device 
>>>>>> dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios 
>>>>>> ../seabios-hppa/out/hppa-firmware.img
>>>>>>
>>>>>>
>>>>>> it actually can *partly* boot from disc:
>>>>>> ...
>>>>>> Selected kernel: /vmlinux from partition 2
>>>>>> Selected ramdisk: /initrd.img from partition 2
>>>>>> ELF64 executable
>>>>>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>>>>>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>>>>>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>>>>>
>>>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>>>   -- System halted
>>>>>>
>>>>>> So, it can read partition table, even load some sectors, but
>>>>>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>>>>>> message states.
>>>>>> This fits with the CRC checksum errors I saw when booting
>>>>>> from ext4 disc.
>>>>>>
>>>>>> Is the dc390/esp driver functional on other big-endian machines?
>>>>>
>>>>> Yes it is, in fact the majority of my test images were from SPARC/m68k 
>>>>> (including a hppa image) and the series in its current form passes all my boot 
>>>>> tests except for an x86 DOS image with ASPI.
>>>>>
>>>>> The command line I used for testing hppa is below:
>>>>>
>>>>> ./qemu-system-hppa \
>>>>>      -kernel vmlinux-parisc \
>>>>>      -no-reboot \
>>>>>      -snapshot \
>>>>>      -device am53c974,id=scsi \
>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>      -nographic -monitor null
>>>>>
>>>>> If you are still seeing errors then I'd suspect an issue with the hppa CPU 
>>>>> emulation or the esp-pci device.
>>>>>
>>>>
>>>> I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
>>>> while I get unaligned access crashes with ext4. I started some tests with btrfs
>>>> and f2fs in addition to ext2 to see how those are doing.
>>>
>>> That sounds really useful, thanks for testing.
>>
>> I think there are multiple issues.
>> Most likely some CPU emulation bug, maybe happens in CRC checksumming.
>>
>> Nevertheless, with this command:
>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial 
>> mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device 
>> am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios 
>> ../seabios-hppa/out/hppa-firmware.img
>> I get this error:
>> Decompressing Linux... XZ-compressed data is corrupt
>>
>> Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
>> At this stage no linux kernel is loaded yet, it's just the seabios-hppa
>> which loaded some scsi blocks into memory.
> 
> Does the esp driver has a limit of only being able to
> load max. 64kb at once (per SCSI command) ?
> By reducing to 64kb, booting directly from Seabios-hppa
> now works for me.

 From a QEMU perspective it should support a maximum 24-bit transfer size. How does 
SeaBIOS calculate the length of the transfer? A post of the output generated by 
"-trace 'esp*' -trace 'scsi*'" using my esp-rework-testing branch would be helpful.


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/9/23 13:12, Mark Cave-Ayland wrote:
> On 08/12/2023 23:36, Helge Deller wrote:
>
>> On 12/8/23 23:09, Helge Deller wrote:
>>> On 12/8/23 22:25, Mark Cave-Ayland wrote:
>>>> On 08/12/2023 20:28, Guenter Roeck wrote:
>>>>> On 12/8/23 11:55, Mark Cave-Ayland wrote:
>>>>>> On 08/12/2023 19:37, Helge Deller wrote:
>>>>>>
>>>>>>> On 12/8/23 20:26, Helge Deller wrote:
>>>>>>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>>>>>>> series. I've pushed the current version of my branch with the ESP
>>>>>>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>>>>>>> if you would both like to give it a test.
>>>>>>>>
>>>>>>>> Tried it with qemu-hppa:
>>>>>>>>
>>>>>>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>>>>>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>>>>>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>>>>>>>> [    8.010626] scsi host1: esp
>>>>>>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
>>>>>>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>>>>>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>>>>>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>>>>>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>>>>>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>>>>>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>>>>>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>>>>>>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>>>>>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>>>>>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>>>>>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>>>>>>> [    8.680679] Write protected read-only-after-init data: 2k
>>>>>>>> [    8.681338] Run /sbin/init as init process
>>>>>>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>>>>>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>>>>>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>>>>>>
>>>>>>> The driver isn't so bad in general.
>>>>>>>
>>>>>>> With my current seabios-hppa from
>>>>>>> https://github.com/hdeller/seabios-hppa/tree/devel
>>>>>>> and booting like this:
>>>>>>>
>>>>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>>>>>>
>>>>>>>
>>>>>>> it actually can *partly* boot from disc:
>>>>>>> ...
>>>>>>> Selected kernel: /vmlinux from partition 2
>>>>>>> Selected ramdisk: /initrd.img from partition 2
>>>>>>> ELF64 executable
>>>>>>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>>>>>>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>>>>>>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>>>>>>
>>>>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>>>>   -- System halted
>>>>>>>
>>>>>>> So, it can read partition table, even load some sectors, but
>>>>>>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>>>>>>> message states.
>>>>>>> This fits with the CRC checksum errors I saw when booting
>>>>>>> from ext4 disc.
>>>>>>>
>>>>>>> Is the dc390/esp driver functional on other big-endian machines?
>>>>>>
>>>>>> Yes it is, in fact the majority of my test images were from SPARC/m68k (including a hppa image) and the series in its current form passes all my boot tests except for an x86 DOS image with ASPI.
>>>>>>
>>>>>> The command line I used for testing hppa is below:
>>>>>>
>>>>>> ./qemu-system-hppa \
>>>>>>      -kernel vmlinux-parisc \
>>>>>>      -no-reboot \
>>>>>>      -snapshot \
>>>>>>      -device am53c974,id=scsi \
>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>>      -nographic -monitor null
>>>>>>
>>>>>> If you are still seeing errors then I'd suspect an issue with the hppa CPU emulation or the esp-pci device.
>>>>>>
>>>>>
>>>>> I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
>>>>> while I get unaligned access crashes with ext4. I started some tests with btrfs
>>>>> and f2fs in addition to ext2 to see how those are doing.
>>>>
>>>> That sounds really useful, thanks for testing.
>>>
>>> I think there are multiple issues.
>>> Most likely some CPU emulation bug, maybe happens in CRC checksumming.
>>>
>>> Nevertheless, with this command:
>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>> I get this error:
>>> Decompressing Linux... XZ-compressed data is corrupt
>>>
>>> Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
>>> At this stage no linux kernel is loaded yet, it's just the seabios-hppa
>>> which loaded some scsi blocks into memory.
>>
>> Does the esp driver has a limit of only being able to
>> load max. 64kb at once (per SCSI command) ?
>> By reducing to 64kb, booting directly from Seabios-hppa
>> now works for me.
>
> From a QEMU perspective it should support a maximum 24-bit transfer size.

I fixed it now in my Seabio-hppa devel branch.
Booting from firmware now works (with your branch), but kernel
still shows crc errors, which is probably a cpu emulation bug.
Still analyzing.

Helge

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/9/23 13:49, Helge Deller wrote:
> On 12/9/23 13:12, Mark Cave-Ayland wrote:
>> On 08/12/2023 23:36, Helge Deller wrote:
>>
>>> On 12/8/23 23:09, Helge Deller wrote:
>>>> On 12/8/23 22:25, Mark Cave-Ayland wrote:
>>>>> On 08/12/2023 20:28, Guenter Roeck wrote:
>>>>>> On 12/8/23 11:55, Mark Cave-Ayland wrote:
>>>>>>> On 08/12/2023 19:37, Helge Deller wrote:
>>>>>>>
>>>>>>>> On 12/8/23 20:26, Helge Deller wrote:
>>>>>>>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>>>>>>>> series. I've pushed the current version of my branch with the ESP
>>>>>>>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>>>>>>>> if you would both like to give it a test.
>>>>>>>>>
>>>>>>>>> Tried it with qemu-hppa:
>>>>>>>>>
>>>>>>>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>>>>>>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>>>>>>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>>>>>>>>> [    8.010626] scsi host1: esp
>>>>>>>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
>>>>>>>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>>>>>>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>>>>>>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>>>>>>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>>>>>>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>>>>>>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>>>>>>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>>>>>>>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>>>>>>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>>>>>>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>>>>>>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>>>>>>>> [    8.680679] Write protected read-only-after-init data: 2k
>>>>>>>>> [    8.681338] Run /sbin/init as init process
>>>>>>>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>>>>>>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>>>>>>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>>>>>>>
>>>>>>>> The driver isn't so bad in general.
>>>>>>>>
>>>>>>>> With my current seabios-hppa from
>>>>>>>> https://github.com/hdeller/seabios-hppa/tree/devel
>>>>>>>> and booting like this:
>>>>>>>>
>>>>>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>>>>>>>
>>>>>>>>
>>>>>>>> it actually can *partly* boot from disc:
>>>>>>>> ...
>>>>>>>> Selected kernel: /vmlinux from partition 2
>>>>>>>> Selected ramdisk: /initrd.img from partition 2
>>>>>>>> ELF64 executable
>>>>>>>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>>>>>>>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>>>>>>>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>>>>>>>
>>>>>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>>>>>   -- System halted
>>>>>>>>
>>>>>>>> So, it can read partition table, even load some sectors, but
>>>>>>>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>>>>>>>> message states.
>>>>>>>> This fits with the CRC checksum errors I saw when booting
>>>>>>>> from ext4 disc.
>>>>>>>>
>>>>>>>> Is the dc390/esp driver functional on other big-endian machines?
>>>>>>>
>>>>>>> Yes it is, in fact the majority of my test images were from SPARC/m68k (including a hppa image) and the series in its current form passes all my boot tests except for an x86 DOS image with ASPI.
>>>>>>>
>>>>>>> The command line I used for testing hppa is below:
>>>>>>>
>>>>>>> ./qemu-system-hppa \
>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>      -no-reboot \
>>>>>>>      -snapshot \
>>>>>>>      -device am53c974,id=scsi \
>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>>>      -nographic -monitor null
>>>>>>>
>>>>>>> If you are still seeing errors then I'd suspect an issue with the hppa CPU emulation or the esp-pci device.
>>>>>>>
>>>>>>
>>>>>> I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
>>>>>> while I get unaligned access crashes with ext4. I started some tests with btrfs
>>>>>> and f2fs in addition to ext2 to see how those are doing.
>>>>>
>>>>> That sounds really useful, thanks for testing.
>>>>
>>>> I think there are multiple issues.
>>>> Most likely some CPU emulation bug, maybe happens in CRC checksumming.
>>>>
>>>> Nevertheless, with this command:
>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>>> I get this error:
>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>
>>>> Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
>>>> At this stage no linux kernel is loaded yet, it's just the seabios-hppa
>>>> which loaded some scsi blocks into memory.
>>>
>>> Does the esp driver has a limit of only being able to
>>> load max. 64kb at once (per SCSI command) ?
>>> By reducing to 64kb, booting directly from Seabios-hppa
>>> now works for me.
>>
>> From a QEMU perspective it should support a maximum 24-bit transfer size.
>
> I fixed it now in my Seabio-hppa devel branch.
> Booting from firmware now works (with your branch), but kernel
> still shows crc errors, which is probably a cpu emulation bug.
> Still analyzing.

If I limit the disc transfer size of am53c974 to just 4K per transaction
(like the patch below against Linux kernel 6.6.4), then qemu-hppa
boots up nicely with qemu git head (and Günther's patches applied).
No ext4 crc errors in this case.
Mark, your git tree then still gives IRQ issues and other problems.

I wonder if this isn't a qemu issue....

diff --git a/drivers/scsi/am53c974.c b/drivers/scsi/am53c974.c
index fbb29dbb1e50..f2066544da5e 100644
--- a/drivers/scsi/am53c974.c
+++ b/drivers/scsi/am53c974.c
@@ -251,6 +251,7 @@ static u32 pci_esp_dma_length_limit(struct esp *esp, u32 dma_addr, u32 dma_len)
          */
         if (esp->config2 & ESP_CONFIG2_FENAB)
                 dma_limit = 24;
+dma_limit = 12; // 4096 bytes

         if (dma_len > (1U << dma_limit))
                 dma_len = (1U << dma_limit);

Helge

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 09/12/2023 17:10, Helge Deller wrote:

> On 12/9/23 13:49, Helge Deller wrote:
>> On 12/9/23 13:12, Mark Cave-Ayland wrote:
>>> On 08/12/2023 23:36, Helge Deller wrote:
>>>
>>>> On 12/8/23 23:09, Helge Deller wrote:
>>>>> On 12/8/23 22:25, Mark Cave-Ayland wrote:
>>>>>> On 08/12/2023 20:28, Guenter Roeck wrote:
>>>>>>> On 12/8/23 11:55, Mark Cave-Ayland wrote:
>>>>>>>> On 08/12/2023 19:37, Helge Deller wrote:
>>>>>>>>
>>>>>>>>> On 12/8/23 20:26, Helge Deller wrote:
>>>>>>>>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>>>>>>>>> series. I've pushed the current version of my branch with the ESP
>>>>>>>>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>>>>>>>>> if you would both like to give it a test.
>>>>>>>>>>
>>>>>>>>>> Tried it with qemu-hppa:
>>>>>>>>>>
>>>>>>>>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>>>>>>>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>>>>>>>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), 
>>>>>>>>>> SCSI ID 15
>>>>>>>>>> [    8.010626] scsi host1: esp
>>>>>>>>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    
>>>>>>>>>> 2.5+ PQ: 0 ANSI: 5
>>>>>>>>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>>>>>>>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>>>>>>>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>>>>>>>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>>>>>>>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 
>>>>>>>>>> GB/100 GiB)
>>>>>>>>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>>>>>>>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>>>>>>>>>> doesn't support DPO or FUA
>>>>>>>>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>>>>>>>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>>>>>>>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>>>>>>>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>>>>>>>>> [    8.680679] Write protected read-only-after-init data: 2k
>>>>>>>>>> [    8.681338] Run /sbin/init as init process
>>>>>>>>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode 
>>>>>>>>>> #787975: comm swapper/0: iget: checksum invalid
>>>>>>>>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>>>>>>>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it 
>>>>>>>>>> (error -67)
>>>>>>>>>
>>>>>>>>> The driver isn't so bad in general.
>>>>>>>>>
>>>>>>>>> With my current seabios-hppa from
>>>>>>>>> https://github.com/hdeller/seabios-hppa/tree/devel
>>>>>>>>> and booting like this:
>>>>>>>>>
>>>>>>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 
>>>>>>>>> -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device 
>>>>>>>>> dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios 
>>>>>>>>> ../seabios-hppa/out/hppa-firmware.img
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> it actually can *partly* boot from disc:
>>>>>>>>> ...
>>>>>>>>> Selected kernel: /vmlinux from partition 2
>>>>>>>>> Selected ramdisk: /initrd.img from partition 2
>>>>>>>>> ELF64 executable
>>>>>>>>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>>>>>>>>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>>>>>>>>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>>>>>>>>
>>>>>>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>>>>>>   -- System halted
>>>>>>>>>
>>>>>>>>> So, it can read partition table, even load some sectors, but
>>>>>>>>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>>>>>>>>> message states.
>>>>>>>>> This fits with the CRC checksum errors I saw when booting
>>>>>>>>> from ext4 disc.
>>>>>>>>>
>>>>>>>>> Is the dc390/esp driver functional on other big-endian machines?
>>>>>>>>
>>>>>>>> Yes it is, in fact the majority of my test images were from SPARC/m68k 
>>>>>>>> (including a hppa image) and the series in its current form passes all my 
>>>>>>>> boot tests except for an x86 DOS image with ASPI.
>>>>>>>>
>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>
>>>>>>>> ./qemu-system-hppa \
>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>      -no-reboot \
>>>>>>>>      -snapshot \
>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>>>>      -nographic -monitor null
>>>>>>>>
>>>>>>>> If you are still seeing errors then I'd suspect an issue with the hppa CPU 
>>>>>>>> emulation or the esp-pci device.
>>>>>>>>
>>>>>>>
>>>>>>> I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine 
>>>>>>> for me
>>>>>>> while I get unaligned access crashes with ext4. I started some tests with btrfs
>>>>>>> and f2fs in addition to ext2 to see how those are doing.
>>>>>>
>>>>>> That sounds really useful, thanks for testing.
>>>>>
>>>>> I think there are multiple issues.
>>>>> Most likely some CPU emulation bug, maybe happens in CRC checksumming.
>>>>>
>>>>> Nevertheless, with this command:
>>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial 
>>>>> mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device 
>>>>> am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios 
>>>>> ../seabios-hppa/out/hppa-firmware.img
>>>>> I get this error:
>>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>>
>>>>> Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
>>>>> At this stage no linux kernel is loaded yet, it's just the seabios-hppa
>>>>> which loaded some scsi blocks into memory.
>>>>
>>>> Does the esp driver has a limit of only being able to
>>>> load max. 64kb at once (per SCSI command) ?
>>>> By reducing to 64kb, booting directly from Seabios-hppa
>>>> now works for me.
>>>
>>> From a QEMU perspective it should support a maximum 24-bit transfer size.
>>
>> I fixed it now in my Seabio-hppa devel branch.
>> Booting from firmware now works (with your branch), but kernel
>> still shows crc errors, which is probably a cpu emulation bug.
>> Still analyzing.
> 
> If I limit the disc transfer size of am53c974 to just 4K per transaction
> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
> boots up nicely with qemu git head (and Günther's patches applied).

Nice detective work :)

If you're using the esp-rework-testing branch then the only patch you should need is 
the patch to esp-pci.c: otherwise if you also apply Günther's esp.c patch then you 
break the reset of the ESP_RSTAT flags when reading ESP_RINTR. Can you confirm that 
this is the case in your tests?

> No ext4 crc errors in this case.
> Mark, your git tree then still gives IRQ issues and other problems.

Presumably this is just the "Spurious irq, sreg=%02x." errors, or are you seeing 
something else?

> I wonder if this isn't a qemu issue....
> 
> diff --git a/drivers/scsi/am53c974.c b/drivers/scsi/am53c974.c
> index fbb29dbb1e50..f2066544da5e 100644
> --- a/drivers/scsi/am53c974.c
> +++ b/drivers/scsi/am53c974.c
> @@ -251,6 +251,7 @@ static u32 pci_esp_dma_length_limit(struct esp *esp, u32 
> dma_addr, u32 dma_len)
>           */
>          if (esp->config2 & ESP_CONFIG2_FENAB)
>                  dma_limit = 24;
> +dma_limit = 12; // 4096 bytes
> 
>          if (dma_len > (1U << dma_limit))
>                  dma_len = (1U << dma_limit);


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/9/23 10:56, Mark Cave-Ayland wrote:
> On 09/12/2023 17:10, Helge Deller wrote:
> 
>> On 12/9/23 13:49, Helge Deller wrote:
>>> On 12/9/23 13:12, Mark Cave-Ayland wrote:
>>>> On 08/12/2023 23:36, Helge Deller wrote:
>>>>
>>>>> On 12/8/23 23:09, Helge Deller wrote:
>>>>>> On 12/8/23 22:25, Mark Cave-Ayland wrote:
>>>>>>> On 08/12/2023 20:28, Guenter Roeck wrote:
>>>>>>>> On 12/8/23 11:55, Mark Cave-Ayland wrote:
>>>>>>>>> On 08/12/2023 19:37, Helge Deller wrote:
>>>>>>>>>
>>>>>>>>>> On 12/8/23 20:26, Helge Deller wrote:
>>>>>>>>>>>> Yeah that's one of the many bugs which should be fixed by my latest
>>>>>>>>>>>> series. I've pushed the current version of my branch with the ESP
>>>>>>>>>>>> rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
>>>>>>>>>>>> if you would both like to give it a test.
>>>>>>>>>>>
>>>>>>>>>>> Tried it with qemu-hppa:
>>>>>>>>>>>
>>>>>>>>>>> [    4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
>>>>>>>>>>> [    4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
>>>>>>>>>>> [    4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0), SCSI ID 15
>>>>>>>>>>> [    8.010626] scsi host1: esp
>>>>>>>>>>> [    8.026345] scsi 1:0:0:0: Direct-Access     QEMU     QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5
>>>>>>>>>>> [    8.032066] scsi target1:0:0: Beginning Domain Validation
>>>>>>>>>>> [    8.043254] scsi target1:0:0: Domain Validation skipping write tests
>>>>>>>>>>> [    8.044284] scsi target1:0:0: Ending Domain Validation
>>>>>>>>>>> [    8.123681] sd 1:0:0:0: Power-on or device reset occurred
>>>>>>>>>>> [    8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107 GB/100 GiB)
>>>>>>>>>>> [    8.140043] sd 1:0:0:0: [sda] Write Protect is off
>>>>>>>>>>> [    8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>>>>>>>>>>> [    8.205316]  sda: sda1 sda2 sda3 < sda5 sda6 >
>>>>>>>>>>> [    8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
>>>>>>>>>>> [    8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
>>>>>>>>>> ...> [    8.679666] Freeing unused kernel image (initmem) memory: 3072K
>>>>>>>>>>> [    8.680679] Write protected read-only-after-init data: 2k
>>>>>>>>>>> [    8.681338] Run /sbin/init as init process
>>>>>>>>>>> [    8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode #787975: comm swapper/0: iget: checksum invalid
>>>>>>>>>>> [    8.736664] scsi host1: Spurious irq, sreg=10.
>>>>>>>>>>> [    8.760106] Starting init: /sbin/init exists but couldn't execute it (error -67)
>>>>>>>>>>
>>>>>>>>>> The driver isn't so bad in general.
>>>>>>>>>>
>>>>>>>>>> With my current seabios-hppa from
>>>>>>>>>> https://github.com/hdeller/seabios-hppa/tree/devel
>>>>>>>>>> and booting like this:
>>>>>>>>>>
>>>>>>>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> it actually can *partly* boot from disc:
>>>>>>>>>> ...
>>>>>>>>>> Selected kernel: /vmlinux from partition 2
>>>>>>>>>> Selected ramdisk: /initrd.img from partition 2
>>>>>>>>>> ELF64 executable
>>>>>>>>>> Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
>>>>>>>>>> Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
>>>>>>>>>> Loading ramdisk 23869192 bytes @ 3e92a000...
>>>>>>>>>>
>>>>>>>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>>>>>>>   -- System halted
>>>>>>>>>>
>>>>>>>>>> So, it can read partition table, even load some sectors, but
>>>>>>>>>> the data returned can be corrupt, as the "XZ-compressed data is corrupt"
>>>>>>>>>> message states.
>>>>>>>>>> This fits with the CRC checksum errors I saw when booting
>>>>>>>>>> from ext4 disc.
>>>>>>>>>>
>>>>>>>>>> Is the dc390/esp driver functional on other big-endian machines?
>>>>>>>>>
>>>>>>>>> Yes it is, in fact the majority of my test images were from SPARC/m68k (including a hppa image) and the series in its current form passes all my boot tests except for an x86 DOS image with ASPI.
>>>>>>>>>
>>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>>
>>>>>>>>> ./qemu-system-hppa \
>>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>>      -no-reboot \
>>>>>>>>>      -snapshot \
>>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>>>>>      -nographic -monitor null
>>>>>>>>>
>>>>>>>>> If you are still seeing errors then I'd suspect an issue with the hppa CPU emulation or the esp-pci device.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine for me
>>>>>>>> while I get unaligned access crashes with ext4. I started some tests with btrfs
>>>>>>>> and f2fs in addition to ext2 to see how those are doing.
>>>>>>>
>>>>>>> That sounds really useful, thanks for testing.
>>>>>>
>>>>>> I think there are multiple issues.
>>>>>> Most likely some CPU emulation bug, maybe happens in CRC checksumming.
>>>>>>
>>>>>> Nevertheless, with this command:
>>>>>> ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0  -bios ../seabios-hppa/out/hppa-firmware.img
>>>>>> I get this error:
>>>>>> Decompressing Linux... XZ-compressed data is corrupt
>>>>>>
>>>>>> Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
>>>>>> At this stage no linux kernel is loaded yet, it's just the seabios-hppa
>>>>>> which loaded some scsi blocks into memory.
>>>>>
>>>>> Does the esp driver has a limit of only being able to
>>>>> load max. 64kb at once (per SCSI command) ?
>>>>> By reducing to 64kb, booting directly from Seabios-hppa
>>>>> now works for me.
>>>>
>>>> From a QEMU perspective it should support a maximum 24-bit transfer size.
>>>
>>> I fixed it now in my Seabio-hppa devel branch.
>>> Booting from firmware now works (with your branch), but kernel
>>> still shows crc errors, which is probably a cpu emulation bug.
>>> Still analyzing.
>>
>> If I limit the disc transfer size of am53c974 to just 4K per transaction
>> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
>> boots up nicely with qemu git head (and Günther's patches applied).
> 
> Nice detective work :)
> 
> If you're using the esp-rework-testing branch then the only patch you should need is the patch to esp-pci.c: otherwise if you also apply Günther's esp.c patch then you break the reset of the ESP_RSTAT flags when reading ESP_RINTR. Can you confirm that this is the case in your tests?
> 

FWIW, my patch to esp.c no longer applies to your branch
since you fixed the problem differently.

Guenter

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 08/12/2023 22:39, Guenter Roeck wrote:

> On 12/8/23 13:19, Mark Cave-Ayland wrote:
>> On 08/12/2023 19:56, Guenter Roeck wrote:
>>
>>> On 12/8/23 10:53, Mark Cave-Ayland wrote:
>>>> On 08/12/2023 14:58, Guenter Roeck wrote:
>>>>
>>>>> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>>>>>> On 07/12/2023 21:47, Helge Deller wrote:
>>>>>>
>>>>>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>>>>>
>>>>>> Thanks for the ping!
>>>>>>
>>>>>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>>>>>> Hi Helge,
>>>>>>>>
>>>>>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>>>>>> [ ... ]
>>>>>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>>>>>> of CPUs would you recommend ?
>>>>>>>>>>>
>>>>>>>>>>> I think 4 CPUs is realistic.
>>>>>>>>>>> But I agree, that you probably see more issues.
>>>>>>>>>>>
>>>>>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>>>>>> stable,
>>>>>>>>>
>>>>>>>>> cool!
>>>>>>>>>
>>>>>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>>>>>> rarely. Here is a quick summary:
>>>>>>>>>>
>>>>>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>>>>>    and a hung task crash.
>>>>>>>>>> - megasas and megasas-gen2 fail with
>>>>>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>>>>>    followed by
>>>>>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>>>>>    and a hung task crash
>>>>>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>>>>>
>>>>>>>>> I think none of those drivers have ever been tested
>>>>>>>>> on physical hardware either.
>>>>>>>>> So I'm astonished that it even worked that far :-)
>>>>>>>>>
>>>>>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>>>>>> the emulation.
>>>>>>>
>>>>>>> Do you have a physical hppa box too?
>>>>>>>
>>>>>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only 
>>>>>>>>> happen for the
>>>>>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>>>>>
>>>>>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>>>>>> either. Sorry, I confused that with some old notes.
>>>>>>>>
>>>>>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>>>>>> driver checks if another interrupt is pending. It does that by checking the
>>>>>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>>>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>>>>>> prematurely, before it sets the command done bit in the interrupt status 
>>>>>>>> register
>>>>>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>>>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>>>>>> I fixed that up in my code and will test it for some time and with various
>>>>>>>> architectures before I send a patch.
>>>>>>
>>>>>> I'm actually in the process of putting the finishing touches to a large rewrite 
>>>>>> of QEMU's core ESP emulation since there are a number of known issues with the 
>>>>>> existing version. In particular there are problems with the SCSI phase being 
>>>>>> set incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being 
>>>>>> correct. Note that this is just the ESP core rather than the ESP PCI device.
>>>>>>
>>>>>> If you are interested, I could try and find a few minutes to tidy it up a bit 
>>>>>> more and push a testing branch to Github?
>>>>>>
>>>>>
>>>>> Sure, I'll be happy to give your changes a try.
>>>>>
>>>>> FWIW, the change I made to fix the spurious interrupt problem is
>>>>>
>>>>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>>>>> index 6794acaebc..f624398c55 100644
>>>>> --- a/hw/scsi/esp-pci.c
>>>>> +++ b/hw/scsi/esp-pci.c
>>>>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t 
>>>>> *buf, int len,
>>>>>       /* update status registers */
>>>>>       pci->dma_regs[DMA_WBC] -= len;
>>>>>       pci->dma_regs[DMA_WAC] += len;
>>>>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>>>>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>>>>> -    }
>>>>>   }
>>>>>
>>>>> I tested that with several platforms. There are no more spurious interrupts
>>>>> after that change, and no other errors either.
>>>>
>>>> I suspect that this is papering over the real issue, since it appears the code 
>>>> being removed sets the DMA completion bit when then the PCI DMA transfer counter 
>>>> reaches zero.
>>>>
>>>
>>> DMA_STAT_DONE is also set in esp_pci_command_complete(), so it doesn't get lost.
>>
>> That doesn't seem right from a QEMU perspective: the command_complete callback is 
>> invoked when the SCSI layer has completed its data transfer to the emulated device, 
>> or immediately if there is no data phase. From a DMA perspective triggering an 
>> interrupt when the byte counter is zero feels like it should be the correct behaviour.
>>
>>> Problem is that the Linux kernel driver assumes that the interrupt status bit
>>> is set in parallel with DMA_STAT_DONE. The spurious interrupt is seen because
>>> that is not the case. There may be a better solution, of course. I'll be happy
>>> to give it a try if you find a better solution.
>>
>> Could you provide a github link to the file/line in question so I can have a look?
>>
> 
> Assuming you mean the Linux kernel:
> 
> In esp_scsi.c:
> 
> The interrupt loop is in scsi_esp_intr(). It calls esp->ops->irq_pending(esp))
> to check if another interrupt is pending. Subsequently, it calls __esp_interrupt()
> to handle it. __esp_interrupt() calls esp_check_spur_intr(), which expects ESP_INTR_SR
> to be set.

ESP_INTR_SR appears to be the SCSI bus reset bit? That doesn't seem to make sense here.

> The irq_pending function is am53c974.c:pci_esp_irq_pending(). It checks the DMA status
> register and assumes that an interrupt is pending if any of (ESP_DMA_STAT_ERROR |
> ESP_DMA_STAT_ABORT | ESP_DMA_STAT_DONE | ESP_DMA_STAT_SCSIINT) is set in the DMA
> status register.

Can you send me the output with "-nographic -trace 'esp*' -trace 'scsi*'" so I can 
see at what point in the ESP state machine the error is being generated?


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/9/23 12:23, Mark Cave-Ayland wrote:
> On 08/12/2023 22:39, Guenter Roeck wrote:
> 
>> On 12/8/23 13:19, Mark Cave-Ayland wrote:
>>> On 08/12/2023 19:56, Guenter Roeck wrote:
>>>
>>>> On 12/8/23 10:53, Mark Cave-Ayland wrote:
>>>>> On 08/12/2023 14:58, Guenter Roeck wrote:
>>>>>
>>>>>> On 12/8/23 00:01, Mark Cave-Ayland wrote:
>>>>>>> On 07/12/2023 21:47, Helge Deller wrote:
>>>>>>>
>>>>>>>> (looping in Mark Cave-Ayland, since he did some work on qemu esp driver)
>>>>>>>
>>>>>>> Thanks for the ping!
>>>>>>>
>>>>>>>> On 12/7/23 22:08, Guenter Roeck wrote:
>>>>>>>>> Hi Helge,
>>>>>>>>>
>>>>>>>>> On 12/6/23 13:43, Helge Deller wrote:
>>>>>>>>>> On 12/6/23 21:19, Guenter Roeck wrote:
>>>>>>>>>>> On 12/6/23 09:00, Helge Deller wrote:
>>>>>>>>>>> [ ... ]
>>>>>>>>>>>>> Is it worth testing with multiple CPUs ? I can re-enable it and
>>>>>>>>>>>>> check more closely if you think it makes sense. If so, what number
>>>>>>>>>>>>> of CPUs would you recommend ?
>>>>>>>>>>>>
>>>>>>>>>>>> I think 4 CPUs is realistic.
>>>>>>>>>>>> But I agree, that you probably see more issues.
>>>>>>>>>>>>
>>>>>>>>>>>> Generally the assumption was, that the different caches on parisc
>>>>>>>>>>>> may trigger SMP issues, but given that those issues can be seen on
>>>>>>>>>>>> qemu, it indicates that there are generic SMP issues too.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ok, I ran some tests overnight with 2-8 CPUs. Turns out the system is quite
>>>>>>>>>>> stable,
>>>>>>>>>>
>>>>>>>>>> cool!
>>>>>>>>>>
>>>>>>>>>>> with the exception of SCSI controllers. Some fail completely, others
>>>>>>>>>>> rarely. Here is a quick summary:
>>>>>>>>>>>
>>>>>>>>>>> - am53c974 fails with "Spurious irq, sreg=00", followed by "Aborting command"
>>>>>>>>>>>    and a hung task crash.
>>>>>>>>>>> - megasas and megasas-gen2 fail with
>>>>>>>>>>>    "scsi host1: scsi scan: INQUIRY result too short (5), using 36"
>>>>>>>>>>>    followed by
>>>>>>>>>>>    "megaraid_sas 0000:00:04.0: Unknown command completed!"
>>>>>>>>>>>    and a hung task crash
>>>>>>>>>>> - mptsas1068 fails completely (no kernel log message seen)
>>>>>>>>>>> - dc390 and lsi* report random "Spurious irq, sreg=00" messages and timeouts
>>>>>>>>>>
>>>>>>>>>> I think none of those drivers have ever been tested
>>>>>>>>>> on physical hardware either.
>>>>>>>>>> So I'm astonished that it even worked that far :-)
>>>>>>>>>>
>>>>>>>>> I actually do have a dc390 board somewhere. I used it some time ago to improve
>>>>>>>>> the emulation.
>>>>>>>>
>>>>>>>> Do you have a physical hppa box too?
>>>>>>>>
>>>>>>>>>> Based on kernel sources, the "Spurious irq, sreg=%02x." error can only happen for the
>>>>>>>>>> am53c974 driver. Are you sure you see this message for dc390 and lsi* too?
>>>>>>>>>>
>>>>>>>>> am53c974 and dc390 use the same driver. lsi* doesn't, and doesn't have a problem
>>>>>>>>> either. Sorry, I confused that with some old notes.
>>>>>>>>>
>>>>>>>>> Either case, I think I found the problem. After handling an interrupt, the Linux
>>>>>>>>> driver checks if another interrupt is pending. It does that by checking the
>>>>>>>>> DMA_DONE bit in the DMA status register. If that bit is set, it re-enters the
>>>>>>>>> interrupt handler. Problem with that is that the emulation sets DMA_DONE
>>>>>>>>> prematurely, before it sets the command done bit in the interrupt status register
>>>>>>>>> and before it sets the interrupt pending bit in the status register. As result,
>>>>>>>>> DMA_DONE is set but IRQ_PENDING isn't, and the spurious interrupt is reported.
>>>>>>>>> I fixed that up in my code and will test it for some time and with various
>>>>>>>>> architectures before I send a patch.
>>>>>>>
>>>>>>> I'm actually in the process of putting the finishing touches to a large rewrite of QEMU's core ESP emulation since there are a number of known issues with the existing version. In particular there are problems with the SCSI phase being set incorrectly after reading ESP_INTR and ESP_RSTAT's STAT_TC not being correct. Note that this is just the ESP core rather than the ESP PCI device.
>>>>>>>
>>>>>>> If you are interested, I could try and find a few minutes to tidy it up a bit more and push a testing branch to Github?
>>>>>>>
>>>>>>
>>>>>> Sure, I'll be happy to give your changes a try.
>>>>>>
>>>>>> FWIW, the change I made to fix the spurious interrupt problem is
>>>>>>
>>>>>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>>>>>> index 6794acaebc..f624398c55 100644
>>>>>> --- a/hw/scsi/esp-pci.c
>>>>>> +++ b/hw/scsi/esp-pci.c
>>>>>> @@ -286,9 +286,6 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, uint8_t *buf, int len,
>>>>>>       /* update status registers */
>>>>>>       pci->dma_regs[DMA_WBC] -= len;
>>>>>>       pci->dma_regs[DMA_WAC] += len;
>>>>>> -    if (pci->dma_regs[DMA_WBC] == 0) {
>>>>>> -        pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>>>>>> -    }
>>>>>>   }
>>>>>>
>>>>>> I tested that with several platforms. There are no more spurious interrupts
>>>>>> after that change, and no other errors either.
>>>>>
>>>>> I suspect that this is papering over the real issue, since it appears the code being removed sets the DMA completion bit when then the PCI DMA transfer counter reaches zero.
>>>>>
>>>>
>>>> DMA_STAT_DONE is also set in esp_pci_command_complete(), so it doesn't get lost.
>>>
>>> That doesn't seem right from a QEMU perspective: the command_complete callback is invoked when the SCSI layer has completed its data transfer to the emulated device, or immediately if there is no data phase. From a DMA perspective triggering an interrupt when the byte counter is zero feels like it should be the correct behaviour.
>>>
>>>> Problem is that the Linux kernel driver assumes that the interrupt status bit
>>>> is set in parallel with DMA_STAT_DONE. The spurious interrupt is seen because
>>>> that is not the case. There may be a better solution, of course. I'll be happy
>>>> to give it a try if you find a better solution.
>>>
>>> Could you provide a github link to the file/line in question so I can have a look?
>>>
>>
>> Assuming you mean the Linux kernel:
>>
>> In esp_scsi.c:
>>
>> The interrupt loop is in scsi_esp_intr(). It calls esp->ops->irq_pending(esp))
>> to check if another interrupt is pending. Subsequently, it calls __esp_interrupt()
>> to handle it. __esp_interrupt() calls esp_check_spur_intr(), which expects ESP_INTR_SR
>> to be set.
> 
> ESP_INTR_SR appears to be the SCSI bus reset bit? That doesn't seem to make sense here.
> 

Sorry, I picked the wrong bit. s/ESP_INTR_SR/ESP_STAT_INTR/

See drivers/scsi/esp_scsi.c around line 1009.

                 if (!(esp->sreg & ESP_STAT_INTR)) {
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                         if (esp->ireg & ESP_INTR_SR)
                                 return 1;

                         /* If the DMA is indicating interrupt pending and the
                          * ESP is not, the only possibility is a DMA error.
                          */
                         if (!esp->ops->dma_error(esp)) {
                                 shost_printk(KERN_ERR, esp->host,
                                              "Spurious irq, sreg=%02x.\n",
                                              esp->sreg);
                                 return -1;
                         }


>> The irq_pending function is am53c974.c:pci_esp_irq_pending(). It checks the DMA status
>> register and assumes that an interrupt is pending if any of (ESP_DMA_STAT_ERROR |
>> ESP_DMA_STAT_ABORT | ESP_DMA_STAT_DONE | ESP_DMA_STAT_SCSIINT) is set in the DMA
>> status register.
> 
> Can you send me the output with "-nographic -trace 'esp*' -trace 'scsi*'" so I can see at what point in the ESP state machine the error is being generated?
> 

I'll give it a try.

Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/9/23 19:56, Mark Cave-Ayland wrote:
>>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>>
>>>>>>>>> ./qemu-system-hppa \
>>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>>      -no-reboot \
>>>>>>>>>      -snapshot \
>>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>>>>>      -nographic -monitor null
>>>>>>>>>
...
>> If I limit the disc transfer size of am53c974 to just 4K per transaction
>> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
>> boots up nicely with qemu git head (and Günther's patches applied).
>
> Nice detective work :)
>
> If you're using the esp-rework-testing branch then the only patch you should need is the patch to esp-pci.c: otherwise if you also apply Günther's esp.c patch then you break the reset of the ESP_RSTAT flags when reading ESP_RINTR. Can you confirm that this is the case in your tests?
>
>> No ext4 crc errors in this case.
>> Mark, your git tree then still gives IRQ issues and other problems.
>
> Presumably this is just the "Spurious irq, sreg=%02x." errors, or are you seeing something else?

Mostly spurious irq:

[   41.561399] scsi host1: Spurious irq, sreg=10.
[   41.562700] scsi host1: Spurious irq, sreg=13.

But later too:

[    **] (1 of 5) Job dev-disk-by\x2duuid-ac…ice/start running (50s / 1min 30s)
[   72.700842] scsi host1: Aborting command [0000000016534e32:2a]
[   72.700842] scsi host1: Current command [00000000320ffcdd:2a]
[   72.700842] scsi host1: Queued command [0000000016534e32:2a]
[   72.700842] scsi host1:  Active command [00000000320ffcdd:2a]
[   72.700842] scsi host1: Dumping command log
[   72.700842] scsi host1: ent[13] CMD val[01] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
[   72.700842] scsi host1: ent[14] CMD val[10] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
[   72.700842] scsi host1: ent[15] EVENT val[02] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
[   72.700842] scsi host1: ent[16] EVENT val[0d] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[02]
[   72.700842] scsi host1: ent[17] EVENT val[04] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
[   72.700842] scsi host1: ent[18] CMD val[90] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[04]
[   72.700842] scsi host1: ent[19] EVENT val[05] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[04]
[   72.700842] scsi host1: ent[20] CMD val[01] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[05]
[   72.700842] scsi host1: ent[21] EVENT val[0d] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[05]
[   72.700842] scsi host1: ent[22] CMD val[01] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
[   72.700842] scsi host1: ent[23] CMD val[11] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
[   72.700842] scsi host1: ent[24] EVENT val[0b] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
[   72.700842] scsi host1: ent[25] CMD val[12] sreg[97] seqreg[01] sreg2[00] ireg[08] ss[00] event[0b]
[   72.700842] scsi host1: ent[26] EVENT val[0c] sreg[97] seqreg[01] sreg2[00] ireg[08] ss[00] event[0b]
[   72.700842] scsi host1: ent[27] CMD val[44] sreg[97] seqreg[00] sreg2[00] ireg[20] ss[00] event[0c]
[   72.700842] scsi host1: ent[28] CMD val[01] sreg[97] seqreg[00] sreg2[00] ireg[20] ss[02] event[0c]
[   72.700842] scsi host1: ent[29] CMD val[43] sreg[97] seqreg[00] sreg2[00] ireg[20] ss[02] event[0c]
[   72.700842] scsi host1: ent[30] EVENT val[0d] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[0c]
[   72.700842] scsi host1: ent[31] EVENT val[09] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[0d]
[   72.700842] scsi host1: ent[0] CMD val[01] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[09]
[   72.700842] scsi host1: ent[1] CMD val[10] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[09]
[   72.700842] scsi host1: ent[2] EVENT val[0a] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[09]
[   72.700842] scsi host1: ent[3] CMD val[00] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[0a]
[   72.700842] scsi host1: ent[4] EVENT val[0d] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[0a]
[   72.700842] scsi host1: ent[5] EVENT val[01] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
[   72.700842] scsi host1: ent[6] CMD val[01] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
[   72.700842] scsi host1: ent[7] CMD val[10] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
[   72.700842] scsi host1: ent[8] EVENT val[02] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
[   72.700842] scsi host1: ent[9] EVENT val[0d] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[02]
[   72.700842] scsi host1: ent[10] EVENT val[04] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
[   72.700842] scsi host1: ent[11] CMD val[90] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[04]
[   72.700842] scsi host1: ent[12] EVENT val[05] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[04]
[   72.759532] scsi host1: Aborting command [00000000320ffcdd:2a]
[   72.760847] scsi host1: Current command [00000000320ffcdd:2a]
[   72.760847] scsi host1:  Active command [00000000320ffcdd:2a]
[   72.760847] scsi host1: Dumping command log
[   72.760847] scsi host1: ent[13] CMD val[01] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
[   72.760847] scsi host1: ent[14] CMD val[10] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
[   72.760847] scsi host1: ent[15] EVENT val[02] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
...

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/9/23 13:58, Helge Deller wrote:
> On 12/9/23 19:56, Mark Cave-Ayland wrote:
>>>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>>>
>>>>>>>>>> ./qemu-system-hppa \
>>>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>>>      -no-reboot \
>>>>>>>>>>      -snapshot \
>>>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>>>>>>      -nographic -monitor null
>>>>>>>>>>
> ...
>>> If I limit the disc transfer size of am53c974 to just 4K per transaction
>>> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
>>> boots up nicely with qemu git head (and Günther's patches applied).
>>
>> Nice detective work :)
>>
>> If you're using the esp-rework-testing branch then the only patch you should need is the patch to esp-pci.c: otherwise if you also apply Günther's esp.c patch then you break the reset of the ESP_RSTAT flags when reading ESP_RINTR. Can you confirm that this is the case in your tests?
>>
>>> No ext4 crc errors in this case.
>>> Mark, your git tree then still gives IRQ issues and other problems.
>>
>> Presumably this is just the "Spurious irq, sreg=%02x." errors, or are you seeing something else?
> 
> Mostly spurious irq:
> 
> [   41.561399] scsi host1: Spurious irq, sreg=10.
> [   41.562700] scsi host1: Spurious irq, sreg=13.
> 
> But later too:
> 
> [    **] (1 of 5) Job dev-disk-by\x2duuid-ac…ice/start running (50s / 1min 30s)
> [   72.700842] scsi host1: Aborting command [0000000016534e32:2a]
> [   72.700842] scsi host1: Current command [00000000320ffcdd:2a]
> [   72.700842] scsi host1: Queued command [0000000016534e32:2a]
> [   72.700842] scsi host1:  Active command [00000000320ffcdd:2a]
> [   72.700842] scsi host1: Dumping command log
> [   72.700842] scsi host1: ent[13] CMD val[01] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
> [   72.700842] scsi host1: ent[14] CMD val[10] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
> [   72.700842] scsi host1: ent[15] EVENT val[02] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
> [   72.700842] scsi host1: ent[16] EVENT val[0d] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[02]
> [   72.700842] scsi host1: ent[17] EVENT val[04] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
> [   72.700842] scsi host1: ent[18] CMD val[90] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[04]
> [   72.700842] scsi host1: ent[19] EVENT val[05] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[04]
> [   72.700842] scsi host1: ent[20] CMD val[01] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[05]
> [   72.700842] scsi host1: ent[21] EVENT val[0d] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[05]
> [   72.700842] scsi host1: ent[22] CMD val[01] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
> [   72.700842] scsi host1: ent[23] CMD val[11] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
> [   72.700842] scsi host1: ent[24] EVENT val[0b] sreg[93] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
> [   72.700842] scsi host1: ent[25] CMD val[12] sreg[97] seqreg[01] sreg2[00] ireg[08] ss[00] event[0b]
> [   72.700842] scsi host1: ent[26] EVENT val[0c] sreg[97] seqreg[01] sreg2[00] ireg[08] ss[00] event[0b]
> [   72.700842] scsi host1: ent[27] CMD val[44] sreg[97] seqreg[00] sreg2[00] ireg[20] ss[00] event[0c]
> [   72.700842] scsi host1: ent[28] CMD val[01] sreg[97] seqreg[00] sreg2[00] ireg[20] ss[02] event[0c]
> [   72.700842] scsi host1: ent[29] CMD val[43] sreg[97] seqreg[00] sreg2[00] ireg[20] ss[02] event[0c]
> [   72.700842] scsi host1: ent[30] EVENT val[0d] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[0c]
> [   72.700842] scsi host1: ent[31] EVENT val[09] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[0d]
> [   72.700842] scsi host1: ent[0] CMD val[01] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[09]
> [   72.700842] scsi host1: ent[1] CMD val[10] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[09]
> [   72.700842] scsi host1: ent[2] EVENT val[0a] sreg[96] seqreg[01] sreg2[00] ireg[18] ss[00] event[09]
> [   72.700842] scsi host1: ent[3] CMD val[00] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[0a]
> [   72.700842] scsi host1: ent[4] EVENT val[0d] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[0a]
> [   72.700842] scsi host1: ent[5] EVENT val[01] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
> [   72.700842] scsi host1: ent[6] CMD val[01] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
> [   72.700842] scsi host1: ent[7] CMD val[10] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
> [   72.700842] scsi host1: ent[8] EVENT val[02] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
> [   72.700842] scsi host1: ent[9] EVENT val[0d] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[02]
> [   72.700842] scsi host1: ent[10] EVENT val[04] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
> [   72.700842] scsi host1: ent[11] CMD val[90] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[04]
> [   72.700842] scsi host1: ent[12] EVENT val[05] sreg[90] seqreg[01] sreg2[00] ireg[10] ss[00] event[04]
> [   72.759532] scsi host1: Aborting command [00000000320ffcdd:2a]
> [   72.760847] scsi host1: Current command [00000000320ffcdd:2a]
> [   72.760847] scsi host1:  Active command [00000000320ffcdd:2a]
> [   72.760847] scsi host1: Dumping command log
> [   72.760847] scsi host1: ent[13] CMD val[01] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
> [   72.760847] scsi host1: ent[14] CMD val[10] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
> [   72.760847] scsi host1: ent[15] EVENT val[02] sreg[92] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
> ...
> 

Yes, I see that as well.

Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/9/23 23:57, Guenter Roeck wrote:
> On 12/9/23 13:58, Helge Deller wrote:
>> On 12/9/23 19:56, Mark Cave-Ayland wrote:
>>>>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>>>>
>>>>>>>>>>> ./qemu-system-hppa \
>>>>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>>>>      -no-reboot \
>>>>>>>>>>>      -snapshot \
>>>>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>>>>>>>      -nographic -monitor null
>>>>>>>>>>>
>> ...
>>>> If I limit the disc transfer size of am53c974 to just 4K per transaction
>>>> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
>>>> boots up nicely with qemu git head (and Günther's patches applied).

A diff of the qemu traces shows, that at some stage
esp_transfer_data transfer() is called for 4k/transaction,
but is not started for 12k/transaction...

Full traces are here:
http://www.dellerweb.de/qemu/qemu-bugs/FAIL
http://www.dellerweb.de/qemu/qemu-bugs/OK

verify with:
  diff -u OK FAIL  | vi -
and go to line 2496:

-STC: 1000    hi/mid/lo: 00/10/00
+STC: 3000    hi/mid/lo: 00/30/00
  esp_dma_enable Raise enable
-esp_handle_ti Transfer Information len 4096
+esp_handle_ti Transfer Information len 12288
  esp_raise_irq Raise IRQ
  esp_lower_drq Lower DREQ
-esp_transfer_data transfer 0/4096       <<<<<<<<<<< this seems missing for 12k
  esp_pci_dma_read reg[5]: 0x00000010
  esp_mem_readb reg[4]: 0x91
  esp_mem_readb reg[6]: 0x04
@@ -8081,21 +7111,22 @@

Helge

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 09/12/2023 23:43, Helge Deller wrote:

> On 12/9/23 23:57, Guenter Roeck wrote:
>> On 12/9/23 13:58, Helge Deller wrote:
>>> On 12/9/23 19:56, Mark Cave-Ayland wrote:
>>>>>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>>>>>
>>>>>>>>>>>> ./qemu-system-hppa \
>>>>>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>>>>>      -no-reboot \
>>>>>>>>>>>>      -snapshot \
>>>>>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda 
>>>>>>>>>>>> console=ttyS0,115200" \
>>>>>>>>>>>>      -nographic -monitor null
>>>>>>>>>>>>
>>> ...
>>>>> If I limit the disc transfer size of am53c974 to just 4K per transaction
>>>>> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
>>>>> boots up nicely with qemu git head (and Günther's patches applied).
> 
> A diff of the qemu traces shows, that at some stage
> esp_transfer_data transfer() is called for 4k/transaction,
> but is not started for 12k/transaction...
> 
> Full traces are here:
> http://www.dellerweb.de/qemu/qemu-bugs/FAIL
> http://www.dellerweb.de/qemu/qemu-bugs/OK
> 
> verify with:
>   diff -u OK FAIL  | vi -
> and go to line 2496:
> 
> -STC: 1000    hi/mid/lo: 00/10/00
> +STC: 3000    hi/mid/lo: 00/30/00
>   esp_dma_enable Raise enable
> -esp_handle_ti Transfer Information len 4096
> +esp_handle_ti Transfer Information len 12288
>   esp_raise_irq Raise IRQ
>   esp_lower_drq Lower DREQ
> -esp_transfer_data transfer 0/4096       <<<<<<<<<<< this seems missing for 12k
>   esp_pci_dma_read reg[5]: 0x00000010
>   esp_mem_readb reg[4]: 0x91
>   esp_mem_readb reg[6]: 0x04
> @@ -8081,21 +7111,22 @@

Thanks for the traces, but it looks as if they are from QEMU git master rather than 
the esp-rework-testing branch? The existing code has a number of known issues so it 
would be good to eliminate those first if possible.


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/10/23 01:22, Mark Cave-Ayland wrote:
> On 09/12/2023 23:43, Helge Deller wrote:
>
>> On 12/9/23 23:57, Guenter Roeck wrote:
>>> On 12/9/23 13:58, Helge Deller wrote:
>>>> On 12/9/23 19:56, Mark Cave-Ayland wrote:
>>>>>>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ./qemu-system-hppa \
>>>>>>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>>>>>>      -no-reboot \
>>>>>>>>>>>>>      -snapshot \
>>>>>>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>>>>>>>>>      -nographic -monitor null
>>>>>>>>>>>>>
>>>> ...
>>>>>> If I limit the disc transfer size of am53c974 to just 4K per transaction
>>>>>> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
>>>>>> boots up nicely with qemu git head (and Günther's patches applied).
>>
>> A diff of the qemu traces shows, that at some stage
>> esp_transfer_data transfer() is called for 4k/transaction,
>> but is not started for 12k/transaction...
>>
>> Full traces are here:
>> http://www.dellerweb.de/qemu/qemu-bugs/FAIL
>> http://www.dellerweb.de/qemu/qemu-bugs/OK
>>
>> verify with:
>>   diff -u OK FAIL  | vi -
>> and go to line 2496:
>>
>> -STC: 1000    hi/mid/lo: 00/10/00
>> +STC: 3000    hi/mid/lo: 00/30/00
>>   esp_dma_enable Raise enable
>> -esp_handle_ti Transfer Information len 4096
>> +esp_handle_ti Transfer Information len 12288
>>   esp_raise_irq Raise IRQ
>>   esp_lower_drq Lower DREQ
>> -esp_transfer_data transfer 0/4096       <<<<<<<<<<< this seems missing for 12k
>>   esp_pci_dma_read reg[5]: 0x00000010
>>   esp_mem_readb reg[4]: 0x91
>>   esp_mem_readb reg[6]: 0x04
>> @@ -8081,21 +7111,22 @@
>
> Thanks for the traces, but it looks as if they are from QEMU git
> master rather than the esp-rework-testing branch?

Yes.

> The existing code has a number of known issues so it would be good to
> eliminate those first if possible.
That's probably true, but I assume your new code is for qemu > 8.2,
while a few small fixes for 8.2 would be good to have too.

Anyway, traces with your esp-rework-testing branch are here:
http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-4k
-> transfer limited to 4k, boots up, fails later with spurious irqs
and traces.

http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-8k
-> transfers limited to 8k, fails to boot as empty pages are returned.
(same issue as with git head)

Helge

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 10/12/2023 15:47, Helge Deller wrote:

> On 12/10/23 01:22, Mark Cave-Ayland wrote:
>> On 09/12/2023 23:43, Helge Deller wrote:
>>
>>> On 12/9/23 23:57, Guenter Roeck wrote:
>>>> On 12/9/23 13:58, Helge Deller wrote:
>>>>> On 12/9/23 19:56, Mark Cave-Ayland wrote:
>>>>>>>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ./qemu-system-hppa \
>>>>>>>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>>>>>>>      -no-reboot \
>>>>>>>>>>>>>>      -snapshot \
>>>>>>>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda 
>>>>>>>>>>>>>> console=ttyS0,115200" \
>>>>>>>>>>>>>>      -nographic -monitor null
>>>>>>>>>>>>>>
>>>>> ...
>>>>>>> If I limit the disc transfer size of am53c974 to just 4K per transaction
>>>>>>> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
>>>>>>> boots up nicely with qemu git head (and Günther's patches applied).
>>>
>>> A diff of the qemu traces shows, that at some stage
>>> esp_transfer_data transfer() is called for 4k/transaction,
>>> but is not started for 12k/transaction...
>>>
>>> Full traces are here:
>>> http://www.dellerweb.de/qemu/qemu-bugs/FAIL
>>> http://www.dellerweb.de/qemu/qemu-bugs/OK
>>>
>>> verify with:
>>>   diff -u OK FAIL  | vi -
>>> and go to line 2496:
>>>
>>> -STC: 1000    hi/mid/lo: 00/10/00
>>> +STC: 3000    hi/mid/lo: 00/30/00
>>>   esp_dma_enable Raise enable
>>> -esp_handle_ti Transfer Information len 4096
>>> +esp_handle_ti Transfer Information len 12288
>>>   esp_raise_irq Raise IRQ
>>>   esp_lower_drq Lower DREQ
>>> -esp_transfer_data transfer 0/4096       <<<<<<<<<<< this seems missing for 12k
>>>   esp_pci_dma_read reg[5]: 0x00000010
>>>   esp_mem_readb reg[4]: 0x91
>>>   esp_mem_readb reg[6]: 0x04
>>> @@ -8081,21 +7111,22 @@
>>
>> Thanks for the traces, but it looks as if they are from QEMU git
>> master rather than the esp-rework-testing branch?
> 
> Yes.
> 
>> The existing code has a number of known issues so it would be good to
>> eliminate those first if possible.
> That's probably true, but I assume your new code is for qemu > 8.2,
> while a few small fixes for 8.2 would be good to have too.

I'm not sure if that is possible, mainly because the ESP changes are dependent and 
order sensitive on each other :/

I've repushed the esp-rework-testing branch which contains an extra WIP commit I hope 
should fix the "Spurious IRQ" messages based upon some traces and experiments done by 
Guenter.

> Anyway, traces with your esp-rework-testing branch are here:
> http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-4k
> -> transfer limited to 4k, boots up, fails later with spurious irqs
> and traces.
> 
> http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-8k
> -> transfers limited to 8k, fails to boot as empty pages are returned.
> (same issue as with git head)

As far as I can tell looking at the traces, the 8k DMA transfers look to be correct 
so I'm wondering if either the DMA descriptors are incorrect or there is something 
else going on here. Can you give me some more information as to how you detect the 
empty pages?


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/10/23 22:15, Mark Cave-Ayland wrote:
> On 10/12/2023 15:47, Helge Deller wrote:
>
>> On 12/10/23 01:22, Mark Cave-Ayland wrote:
>>> On 09/12/2023 23:43, Helge Deller wrote:
>>>
>>>> On 12/9/23 23:57, Guenter Roeck wrote:
>>>>> On 12/9/23 13:58, Helge Deller wrote:
>>>>>> On 12/9/23 19:56, Mark Cave-Ayland wrote:
>>>>>>>>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ./qemu-system-hppa \
>>>>>>>>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>>>>>>>>      -no-reboot \
>>>>>>>>>>>>>>>      -snapshot \
>>>>>>>>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
>>>>>>>>>>>>>>>      -nographic -monitor null
>>>>>>>>>>>>>>>
>>>>>> ...
>>>>>>>> If I limit the disc transfer size of am53c974 to just 4K per transaction
>>>>>>>> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
>>>>>>>> boots up nicely with qemu git head (and Günther's patches applied).
>>>>
>>>> A diff of the qemu traces shows, that at some stage
>>>> esp_transfer_data transfer() is called for 4k/transaction,
>>>> but is not started for 12k/transaction...
>>>>
>>>> Full traces are here:
>>>> http://www.dellerweb.de/qemu/qemu-bugs/FAIL
>>>> http://www.dellerweb.de/qemu/qemu-bugs/OK
>>>>
>>>> verify with:
>>>>   diff -u OK FAIL  | vi -
>>>> and go to line 2496:
>>>>
>>>> -STC: 1000    hi/mid/lo: 00/10/00
>>>> +STC: 3000    hi/mid/lo: 00/30/00
>>>>   esp_dma_enable Raise enable
>>>> -esp_handle_ti Transfer Information len 4096
>>>> +esp_handle_ti Transfer Information len 12288
>>>>   esp_raise_irq Raise IRQ
>>>>   esp_lower_drq Lower DREQ
>>>> -esp_transfer_data transfer 0/4096       <<<<<<<<<<< this seems missing for 12k
>>>>   esp_pci_dma_read reg[5]: 0x00000010
>>>>   esp_mem_readb reg[4]: 0x91
>>>>   esp_mem_readb reg[6]: 0x04
>>>> @@ -8081,21 +7111,22 @@
>>>
>>> Thanks for the traces, but it looks as if they are from QEMU git
>>> master rather than the esp-rework-testing branch?
>>
>> Yes.
>>
>>> The existing code has a number of known issues so it would be good to
>>> eliminate those first if possible.
>> That's probably true, but I assume your new code is for qemu > 8.2,
>> while a few small fixes for 8.2 would be good to have too.
>
> I'm not sure if that is possible, mainly because the ESP changes are dependent and order sensitive on each other :/

Sure. I just thought of a simple patch before all your other changes.
But that's not priority.

> I've repushed the esp-rework-testing branch which contains an extra WIP commit I hope should fix the "Spurious IRQ" messages based upon some traces and experiments done by Guenter.

Will try soon.

>> Anyway, traces with your esp-rework-testing branch are here:
>> http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-4k
>> -> transfer limited to 4k, boots up, fails later with spurious irqs
>> and traces.
>>
>> http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-8k
>> -> transfers limited to 8k, fails to boot as empty pages are returned.
>> (same issue as with git head)
>
> As far as I can tell looking at the traces, the 8k DMA transfers look
> to be correct so I'm wondering if either the DMA descriptors are
> incorrect or there is something else going on here. Can you give me
> some more information as to how you detect the empty pages?

I actually don't know if null-bytes are transferred.
But ext4 reports CRC errors, so I added this hunk to the Linux kernel:

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index d7732320431a..9b12fbd44e06 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4732,6 +4736,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
         if (ret < 0)
                 goto bad_inode;
         raw_inode = ext4_raw_inode(&iloc);
+// printk("raw_info  provided %px %x\n", &raw_inode->i_checksum_lo, raw_inode->i_checksum_lo);
+// printk("  iloc->bh->b_data %px  iloc->offset %lx\n", iloc.bh->b_data, iloc.offset);
+if (raw_inode->i_checksum_lo == 0) asm(".word 0xfffdead0");

The last line immediately stops qemu if the checksum is zero.
I start qemu with
  ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -kernel vmlinux  -append "root=/dev/sda5 console=ttyS0 single earlycon=pdc"  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0

qemu aborts with the am53c974 driver.
If I use exactly the same command, but with the lsi53c895a driver instead of am53c974, it boots correctly.

Any other idea?

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/10/23 13:42, Helge Deller wrote:
[ ... ]> I actually don't know if null-bytes are transferred.
> But ext4 reports CRC errors, so I added this hunk to the Linux kernel:
> 
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index d7732320431a..9b12fbd44e06 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4732,6 +4736,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
>          if (ret < 0)
>                  goto bad_inode;
>          raw_inode = ext4_raw_inode(&iloc);
> +// printk("raw_info  provided %px %x\n", &raw_inode->i_checksum_lo, raw_inode->i_checksum_lo);
> +// printk("  iloc->bh->b_data %px  iloc->offset %lx\n", iloc.bh->b_data, iloc.offset);
> +if (raw_inode->i_checksum_lo == 0) asm(".word 0xfffdead0");
> 
> The last line immediately stops qemu if the checksum is zero.
> I start qemu with
>   ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -kernel vmlinux  -append "root=/dev/sda5 console=ttyS0 single earlycon=pdc"  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0
> 
> qemu aborts with the am53c974 driver.
> If I use exactly the same command, but with the lsi53c895a driver instead of am53c974, it boots correctly.
> 
> Any other idea?
> 

Does your code use scatter-gather DMA ? If so, that might explain the problem.
I don't think the qemu code implements that properly. I don't mean the MDL version,
that isn't implemented at all. I mean the non-MDL version, where a single SCSI
command requires multiple DMA transfers which have to be set up one by one.

Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/10/23 22:59, Guenter Roeck wrote:
> On 12/10/23 13:42, Helge Deller wrote:
> [ ... ]> I actually don't know if null-bytes are transferred.
>> But ext4 reports CRC errors, so I added this hunk to the Linux kernel:
>>
>> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
>> index d7732320431a..9b12fbd44e06 100644
>> --- a/fs/ext4/inode.c
>> +++ b/fs/ext4/inode.c
>> @@ -4732,6 +4736,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
>>          if (ret < 0)
>>                  goto bad_inode;
>>          raw_inode = ext4_raw_inode(&iloc);
>> +// printk("raw_info  provided %px %x\n", &raw_inode->i_checksum_lo, raw_inode->i_checksum_lo);
>> +// printk("  iloc->bh->b_data %px  iloc->offset %lx\n", iloc.bh->b_data, iloc.offset);
>> +if (raw_inode->i_checksum_lo == 0) asm(".word 0xfffdead0");
>>
>> The last line immediately stops qemu if the checksum is zero.
>> I start qemu with
>>   ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -kernel vmlinux  -append "root=/dev/sda5 console=ttyS0 single earlycon=pdc"  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0
>>
>> qemu aborts with the am53c974 driver.
>> If I use exactly the same command, but with the lsi53c895a driver instead of am53c974, it boots correctly.
>>
>> Any other idea?
>>
>
> Does your code use scatter-gather DMA ?

Which code? The kernel which mounts the ext4 filesystem?

> If so, that might explain the problem.
> I don't think the qemu code implements that properly. I don't mean the MDL version,
> that isn't implemented at all. I mean the non-MDL version, where a single SCSI
> command requires multiple DMA transfers which have to be set up one by one.

Is there any way I could test, e.g. by disabling SG ?

Helge

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/11/23 07:53, Helge Deller wrote:
> On 12/10/23 22:59, Guenter Roeck wrote:
>> On 12/10/23 13:42, Helge Deller wrote:
>> [ ... ]> I actually don't know if null-bytes are transferred.
>>> But ext4 reports CRC errors, so I added this hunk to the Linux kernel:
>>>
>>> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
>>> index d7732320431a..9b12fbd44e06 100644
>>> --- a/fs/ext4/inode.c
>>> +++ b/fs/ext4/inode.c
>>> @@ -4732,6 +4736,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
>>>          if (ret < 0)
>>>                  goto bad_inode;
>>>          raw_inode = ext4_raw_inode(&iloc);
>>> +// printk("raw_info  provided %px %x\n", &raw_inode->i_checksum_lo, raw_inode->i_checksum_lo);
>>> +// printk("  iloc->bh->b_data %px  iloc->offset %lx\n", iloc.bh->b_data, iloc.offset);
>>> +if (raw_inode->i_checksum_lo == 0) asm(".word 0xfffdead0");
>>>
>>> The last line immediately stops qemu if the checksum is zero.
>>> I start qemu with
>>>   ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -kernel vmlinux  -append "root=/dev/sda5 console=ttyS0 single earlycon=pdc"  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0
>>>
>>> qemu aborts with the am53c974 driver.
>>> If I use exactly the same command, but with the lsi53c895a driver instead of am53c974, it boots correctly.
>>>
>>> Any other idea?
>>>
>>
>> Does your code use scatter-gather DMA ?
> 
> Which code? The kernel which mounts the ext4 filesystem?
> 

Seabios. Sorry, I thought your problem was with that.

>> If so, that might explain the problem.
>> I don't think the qemu code implements that properly. I don't mean the MDL version,
>> that isn't implemented at all. I mean the non-MDL version, where a single SCSI
>> command requires multiple DMA transfers which have to be set up one by one.
> 
> Is there any way I could test, e.g. by disabling SG ?
> 

No idea, but that makes me wonder if ext4 and other file systems somehow trigger SG
operation while ext2 doesn't. I'll do some debugging along that line.

Guenter

Re: 64-bit userspace root file system for hppa64

[Helge Deller]

On 12/11/23 18:26, Guenter Roeck wrote:
> On 12/11/23 07:53, Helge Deller wrote:
>> On 12/10/23 22:59, Guenter Roeck wrote:
>>> On 12/10/23 13:42, Helge Deller wrote:
>>> [ ... ]> I actually don't know if null-bytes are transferred.
>>>> But ext4 reports CRC errors, so I added this hunk to the Linux kernel:
>>>>
>>>> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
>>>> index d7732320431a..9b12fbd44e06 100644
>>>> --- a/fs/ext4/inode.c
>>>> +++ b/fs/ext4/inode.c
>>>> @@ -4732,6 +4736,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
>>>>          if (ret < 0)
>>>>                  goto bad_inode;
>>>>          raw_inode = ext4_raw_inode(&iloc);
>>>> +// printk("raw_info  provided %px %x\n", &raw_inode->i_checksum_lo, raw_inode->i_checksum_lo);
>>>> +// printk("  iloc->bh->b_data %px  iloc->offset %lx\n", iloc.bh->b_data, iloc.offset);
>>>> +if (raw_inode->i_checksum_lo == 0) asm(".word 0xfffdead0");
>>>>
>>>> The last line immediately stops qemu if the checksum is zero.
>>>> I start qemu with
>>>>   ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -kernel vmlinux  -append "root=/dev/sda5 console=ttyS0 single earlycon=pdc"  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0
>>>>
>>>> qemu aborts with the am53c974 driver.
>>>> If I use exactly the same command, but with the lsi53c895a driver instead of am53c974, it boots correctly.
>>>>
>>>> Any other idea?
>>>>
>>>
>>> Does your code use scatter-gather DMA ?
>>
>> Which code? The kernel which mounts the ext4 filesystem?
>>
>
> Seabios. Sorry, I thought your problem was with that.

Yes and no.
My main intention was to test with the Linux kernel primarily.
If this works, then it's easier to test the SeaBIOS code too.

>>> If so, that might explain the problem.
>>> I don't think the qemu code implements that properly. I don't mean the MDL version,
>>> that isn't implemented at all. I mean the non-MDL version, where a single SCSI
>>> command requires multiple DMA transfers which have to be set up one by one.
>>
>> Is there any way I could test, e.g. by disabling SG ?
>>
>
> No idea, but that makes me wonder if ext4 and other file systems somehow trigger SG
> operation while ext2 doesn't. I'll do some debugging along that line.

Ok, thanks!

Helge

Re: 64-bit userspace root file system for hppa64

[Mark Cave-Ayland]

On 10/12/2023 21:42, Helge Deller wrote:

> On 12/10/23 22:15, Mark Cave-Ayland wrote:
>> On 10/12/2023 15:47, Helge Deller wrote:
>>
>>> On 12/10/23 01:22, Mark Cave-Ayland wrote:
>>>> On 09/12/2023 23:43, Helge Deller wrote:
>>>>
>>>>> On 12/9/23 23:57, Guenter Roeck wrote:
>>>>>> On 12/9/23 13:58, Helge Deller wrote:
>>>>>>> On 12/9/23 19:56, Mark Cave-Ayland wrote:
>>>>>>>>>>>>>>>> The command line I used for testing hppa is below:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ./qemu-system-hppa \
>>>>>>>>>>>>>>>>      -kernel vmlinux-parisc \
>>>>>>>>>>>>>>>>      -no-reboot \
>>>>>>>>>>>>>>>>      -snapshot \
>>>>>>>>>>>>>>>>      -device am53c974,id=scsi \
>>>>>>>>>>>>>>>>      -device scsi-hd,bus=scsi.0,drive=d0 \
>>>>>>>>>>>>>>>>      -drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
>>>>>>>>>>>>>>>>      -append "panic=-1 slub_debug=FZPUA root=/dev/sda 
>>>>>>>>>>>>>>>> console=ttyS0,115200" \
>>>>>>>>>>>>>>>>      -nographic -monitor null
>>>>>>>>>>>>>>>>
>>>>>>> ...
>>>>>>>>> If I limit the disc transfer size of am53c974 to just 4K per transaction
>>>>>>>>> (like the patch below against Linux kernel 6.6.4), then qemu-hppa
>>>>>>>>> boots up nicely with qemu git head (and Günther's patches applied).
>>>>>
>>>>> A diff of the qemu traces shows, that at some stage
>>>>> esp_transfer_data transfer() is called for 4k/transaction,
>>>>> but is not started for 12k/transaction...
>>>>>
>>>>> Full traces are here:
>>>>> http://www.dellerweb.de/qemu/qemu-bugs/FAIL
>>>>> http://www.dellerweb.de/qemu/qemu-bugs/OK
>>>>>
>>>>> verify with:
>>>>>   diff -u OK FAIL  | vi -
>>>>> and go to line 2496:
>>>>>
>>>>> -STC: 1000    hi/mid/lo: 00/10/00
>>>>> +STC: 3000    hi/mid/lo: 00/30/00
>>>>>   esp_dma_enable Raise enable
>>>>> -esp_handle_ti Transfer Information len 4096
>>>>> +esp_handle_ti Transfer Information len 12288
>>>>>   esp_raise_irq Raise IRQ
>>>>>   esp_lower_drq Lower DREQ
>>>>> -esp_transfer_data transfer 0/4096       <<<<<<<<<<< this seems missing for 12k
>>>>>   esp_pci_dma_read reg[5]: 0x00000010
>>>>>   esp_mem_readb reg[4]: 0x91
>>>>>   esp_mem_readb reg[6]: 0x04
>>>>> @@ -8081,21 +7111,22 @@
>>>>
>>>> Thanks for the traces, but it looks as if they are from QEMU git
>>>> master rather than the esp-rework-testing branch?
>>>
>>> Yes.
>>>
>>>> The existing code has a number of known issues so it would be good to
>>>> eliminate those first if possible.
>>> That's probably true, but I assume your new code is for qemu > 8.2,
>>> while a few small fixes for 8.2 would be good to have too.
>>
>> I'm not sure if that is possible, mainly because the ESP changes are dependent and 
>> order sensitive on each other :/
> 
> Sure. I just thought of a simple patch before all your other changes.
> But that's not priority.
> 
>> I've repushed the esp-rework-testing branch which contains an extra WIP commit I 
>> hope should fix the "Spurious IRQ" messages based upon some traces and experiments 
>> done by Guenter.
> 
> Will try soon.
> 
>>> Anyway, traces with your esp-rework-testing branch are here:
>>> http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-4k
>>> -> transfer limited to 4k, boots up, fails later with spurious irqs
>>> and traces.
>>>
>>> http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-8k
>>> -> transfers limited to 8k, fails to boot as empty pages are returned.
>>> (same issue as with git head)
>>
>> As far as I can tell looking at the traces, the 8k DMA transfers look
>> to be correct so I'm wondering if either the DMA descriptors are
>> incorrect or there is something else going on here. Can you give me
>> some more information as to how you detect the empty pages?
> 
> I actually don't know if null-bytes are transferred.
> But ext4 reports CRC errors, so I added this hunk to the Linux kernel:
> 
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index d7732320431a..9b12fbd44e06 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4732,6 +4736,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long 
> ino,
>          if (ret < 0)
>                  goto bad_inode;
>          raw_inode = ext4_raw_inode(&iloc);
> +// printk("raw_info  provided %px %x\n", &raw_inode->i_checksum_lo, 
> raw_inode->i_checksum_lo);
> +// printk("  iloc->bh->b_data %px  iloc->offset %lx\n", iloc.bh->b_data, iloc.offset);
> +if (raw_inode->i_checksum_lo == 0) asm(".word 0xfffdead0");
> 
> The last line immediately stops qemu if the checksum is zero.
> I start qemu with
>   ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -kernel 
> vmlinux  -append "root=/dev/sda5 console=ttyS0 single earlycon=pdc"  -serial 
> mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi 
> -device scsi-hd,bus=scsi.0,drive=d0
> 
> qemu aborts with the am53c974 driver.
> If I use exactly the same command, but with the lsi53c895a driver instead of 
> am53c974, it boots correctly.
> 
> Any other idea?

I'd try setting a breakpoint on esp_pci_dma_memory_write() if len > 4096, stepping 
over pci_dma_rw() in esp_pci_dma_memory_rw() and then checking with the monitor that 
the entire 8k transfer is present in memory using the "xp" command to check the start 
and end of the data have been copied to physical memory.

Is there an IOMMU involved here at all?


ATB,

Mark.

Re: 64-bit userspace root file system for hppa64

[Guenter Roeck]

On 12/11/23 13:38, Helge Deller wrote:
> On 12/11/23 18:26, Guenter Roeck wrote:
>> On 12/11/23 07:53, Helge Deller wrote:
>>> On 12/10/23 22:59, Guenter Roeck wrote:
>>>> On 12/10/23 13:42, Helge Deller wrote:
>>>> [ ... ]> I actually don't know if null-bytes are transferred.
>>>>> But ext4 reports CRC errors, so I added this hunk to the Linux kernel:
>>>>>
>>>>> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
>>>>> index d7732320431a..9b12fbd44e06 100644
>>>>> --- a/fs/ext4/inode.c
>>>>> +++ b/fs/ext4/inode.c
>>>>> @@ -4732,6 +4736,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
>>>>>          if (ret < 0)
>>>>>                  goto bad_inode;
>>>>>          raw_inode = ext4_raw_inode(&iloc);
>>>>> +// printk("raw_info  provided %px %x\n", &raw_inode->i_checksum_lo, raw_inode->i_checksum_lo);
>>>>> +// printk("  iloc->bh->b_data %px  iloc->offset %lx\n", iloc.bh->b_data, iloc.offset);
>>>>> +if (raw_inode->i_checksum_lo == 0) asm(".word 0xfffdead0");
>>>>>
>>>>> The last line immediately stops qemu if the checksum is zero.
>>>>> I start qemu with
>>>>>   ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -kernel vmlinux  -append "root=/dev/sda5 console=ttyS0 single earlycon=pdc"  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0
>>>>>
>>>>> qemu aborts with the am53c974 driver.
>>>>> If I use exactly the same command, but with the lsi53c895a driver instead of am53c974, it boots correctly.
>>>>>
>>>>> Any other idea?
>>>>>
>>>>
>>>> Does your code use scatter-gather DMA ?
>>>
>>> Which code? The kernel which mounts the ext4 filesystem?
>>>
>>
>> Seabios. Sorry, I thought your problem was with that.
> 
> Yes and no.
> My main intention was to test with the Linux kernel primarily.
> If this works, then it's easier to test the SeaBIOS code too.
> 
>>>> If so, that might explain the problem.
>>>> I don't think the qemu code implements that properly. I don't mean the MDL version,
>>>> that isn't implemented at all. I mean the non-MDL version, where a single SCSI
>>>> command requires multiple DMA transfers which have to be set up one by one.
>>>
>>> Is there any way I could test, e.g. by disabling SG ?
>>>
>>
>> No idea, but that makes me wonder if ext4 and other file systems somehow trigger SG
>> operation while ext2 doesn't. I'll do some debugging along that line.
> 
> Ok, thanks!
> 

Nothing conclusive. ext2 always passes, ext4 and btrfs sometimes pass, sometimes
fail. They also sometimes fail with lsi53c895a, so that isn't the determining
factor. I always get the "Unaligned handler failed" error.

Guenter