> On 27 Oct 2016, at 02:27, James Clarke <jrtc27@xxxxxxxxxx> wrote: > >> On 26 Oct 2016, at 22:02, David Miller <davem@xxxxxxxxxxxxx> wrote: >> >> From: James Clarke <jrtc27@xxxxxxxxxx> >> Date: Wed, 26 Oct 2016 21:05:36 +0100 >> >>> Thanks for this, it's now compiling. I'll let you know if it works >>> within the next 24 hours. >> >> Thanks. >> >>> Before I forget, what do you think about the following patch? I know >>> Debian used to use the 64-bit kernel for a 32-bit sparc userland, and so >>> "Architecture: sparc" was correct, but obviously sparc64 also exists. It >>> seems more sane to make sparc64 default to "Architecture: sparc64", with >>> sparc users needing to override this with KBUILD_DEBARCH if they want >>> to, rather than providing a setup that's broken out of the box for >>> sparc64 users. >>> >>> From: James Clarke <jrtc27@xxxxxxxxxx> >>> Date: Wed, 26 Oct 2016 20:17:10 +0100 >>> Subject: [PATCH] builddeb: Add support for sparc64 >>> >>> Signed-off-by: James Clarke <jrtc27@xxxxxxxxxx> >> >> I don't know. >> >> I still personally use a 32-bit userland on my sparc64 systems because >> that is what performs the best and is what I will be using for as long >> as I possibly can. >> >> I've actually never used this target, is this for build the kernel or >> userland components? > > Yes, make pkg-deb builds kernel, firmware, headers and linux-libc packages. > By the way, the first build I made of 4.9 (using Debian’s 4.8 config as old > config) wouldn’t boot, since: > > * sunvdc module needs _mcount > * sunvnet module needs _mcount and count_bits > * crc32c_sparc64 module needs _mcount and VISenter > [* raid6_pq module needs memcpy, though that’s just for a data partition] > > The workaround is not to use CONFIG_MODVERSIONS, but this wasn’t at all clear > at first. This is because of d3867f0483, which moved these to being exported in > their .S. > > Anyway, the new kernel is running now and being stress-tested. Hi David, I’ve run it on the T5 and it seems to work without lockups: [5948090.988821] vln_init: *vmap_lazy_nr is 32754 [5948090.989943] vln_init: lazy_max_pages() is 32768 [5948091.157381] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range start=0000000010006000 end=00000000f0000000 PAGE_SIZE=2000 [5948091.157530] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range start=0000000100000000 end=0005ffff8c000000 PAGE_SIZE=2000 [5948091.158240] vln_init: vmap_lazy_nr is caeb1c [5948091.158252] vln_init: *vmap_lazy_nr is 0 [5948091.159311] vln_init: lazy_max_pages() is 32768 ... continues on as normal ... (again, that’s my debugging module to see how close the system is to a flush) I can't (yet) vouch for the IIIi, but when it comes back up I’ll give it a go[1]. I'll also put it on the T1 at some point today, but it *should* also work since it's using the same sun4v/hypervisor implementation as the T5. Thanks, James [1] Not sure how long that will take... -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
