Re: 64-bit userspace root file system for hppa64

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


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:

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?


[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux