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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
