Re: Debian/SPARC[64]
On 12/01/15 08:32, Karel Gardas wrote:
> On 01/12/15 01:19 AM, Bob Bib wrote:
>> (BTW, we can also ask Gentoo about the current state of its SPARC
>> support).
>
> That's indeed a good remark.
>
>> Karel:
>>> FYI: the issue is that Solaris switched to Sun's asm which does have
>>> different syntax than GNU asm. So to preserve compatibility with GNU or
>>> not to preserve that is the question. :-)
>>
>> Are the differences so hard?
>> Maybe the GNU assembler already has the support for Sun syntax?
>> Then it looks more like a GNU Binutils issue:
>> http://www.gnu.org/software/binutils/
>
> Differences are not so big but before putting this compatibility in
> someone always need to ask if this is not done for completely dead
> horse. Looks like it's not. :-)
Hi Karel,
I've been spending time working on the SPARC64 emulation on QEMU and can
confirm that the latest QEMU 2.2 release is good enough boot, install
and run all of Debian squeeze/wheezy, NetBSD and OpenBSD in -nographic
mode. Work on Solaris is currently a slow on-going task, although
support could be completed sooner if interested parties wanted to
sponsor such work.
Now I've had a couple of personal reports of QEMU users experiencing
hard lockups during periods of high I/O under Debian wheezy similar to
the thread at
http://comments.gmane.org/gmane.linux.debian.ports.sparc/16093 (QEMU
emulation is an approximation of the Ultra 5 machine) which makes me
believe that this could be a kernel bug.
At one point I was given remote access to a system that could reproduce
the issue about 1 in every 10 boots, and from attaching a debugger to
the QEMU session it looked like the wheezy kernel was stuck in a
spinlock, likely waiting for an interrupt that never arrived. It could
of course be possible that this is an emulation bug, but it does seem
suspicious that the same problem occurs also seems present on a real
Ultra 5 too.
If I had to hazard a guess then I would say that it's related to either
the older UltraSPARC processors or the PCI/psycho interrupt handling in
the kernel which may explain why the kernel developers who likely have
much newer hardware aren't noticing the issue.
Sadly as I struggle to reproduce this issue locally then it's almost
impossible for me to say whether this is something that affects all
SPARC64 kernels or just a specific hardware combination, but I'd be very
interested to hear back as to whether you also experience any lockups
during high I/O during your testing with more recent kernels
(particularly virtio seems to help trigger the issue under emulation).
ATB,
Mark.
Reply to: