Re: [PATCH] sunhv: Fix device naming inconsistency between sunhv_console and sunhv_reg

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Tue, 11 Jun 2019 17:38:37 +0200

> In d5a2aa24, the name in struct console sunhv_console was changed from "ttyS"
> to "ttyHV" while the name in struct uart_ops sunhv_pops remained unchanged.
> 
> This results in the hypervisor console device to be listed as "ttyHV0" under
> /proc/consoles while the device node is still named "ttyS0":
> 
> root@osaka:~# cat /proc/consoles
> ttyHV0   -W- (EC p  )4:64
> tty0 -WU (E )4:1
> root@osaka:~# readlink /sys/dev/char/4:64
> ../../devices/root/f02836f0/f0285690/tty/ttyS0
> root@osaka:~#
> 
> This means that any userland code which tries to determine the name of the
> device file of the hypervisor console device can not rely on the information
> provided by /proc/consoles. In particular, booting current versions of debian-
> installer inside a SPARC LDOM will fail with the installer unable to determine
> the console device.
> 
> After renaming the device in struct uart_ops sunhv_pops to "ttyHV" as well,
> the inconsistency is fixed and it is possible again to determine the name
> of the device file of the hypervisor console device by reading the contents
> of /proc/console:
> 
> root@osaka:~# cat /proc/consoles
> ttyHV0   -W- (EC p  )4:64
> tty0 -WU (E )4:1
> root@osaka:~# readlink /sys/dev/char/4:64
> ../../devices/root/f02836f0/f0285690/tty/ttyHV0
> root@osaka:~#
> 
> With this change, debian-installer works correctly when installing inside
> a SPARC LDOM.
> 
> Signed-off-by: John Paul Adrian Glaubitz 

Applied and queued up for -stable, thanks.

Re: Making MAX_PHYS_ADDRESS_BITS configurable

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Fri, 24 May 2019 20:51:33 +0200

> On 5/24/19 6:20 PM, David Miller wrote:
>>> On the other hand, arm64 currently allows the virtual address size
>>> to be configurable, currently defaulting to 48 bits [2, 3]. I was
>>> therefore wondering whether we could make MAX_PHYS_ADDRESS_BITS [4]
>>> configurable as well to be able to support these JITs on
>>> Debian/sparc64 for the foreseeable future by limiting the virtual
>>> address space to 47 or 48 bits.
>> 
>> You can't just do this.
>> 
>> It is possible that all physical memory is mapped to the top of the
>> mappable physical address range, therefore we really need to use the
>> full maximum setting supported by the CPU.
> 
> Yes, my initial mail was incorrect. What I actually meant was reducing
> the size of the va_hole in userspace so that the top-most address that
> mmap() would return is not beyond 2^47.
> 
> Would it be possible to add such a workaround until the JITs have fixed
> their broken code?

I suppose that's doable, sure.

Re: Making MAX_PHYS_ADDRESS_BITS configurable

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Fri, 24 May 2019 12:24:53 +0200

> On the other hand, arm64 currently allows the virtual address size
> to be configurable, currently defaulting to 48 bits [2, 3]. I was
> therefore wondering whether we could make MAX_PHYS_ADDRESS_BITS [4]
> configurable as well to be able to support these JITs on
> Debian/sparc64 for the foreseeable future by limiting the virtual
> address space to 47 or 48 bits.

You can't just do this.

It is possible that all physical memory is mapped to the top of the
mappable physical address range, therefore we really need to use the
full maximum setting supported by the CPU.

Re: Naming inconsistency for serial device on sparc

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Sun, 14 Apr 2019 22:25:57 +0200

> On 4/14/19 10:18 PM, David Miller wrote:
>> From: John Paul Adrian Glaubitz 
>> Date: Sun, 14 Apr 2019 09:21:32 +0200
>> 
>>> Is there any particular reason this device name mismatch exists or
>>> is it just a bug we can fix?
>> 
>> It's probably been there for so long that changing it is likely to
>> have a risk of breaking some other piece of software.
> 
> Hmm, good point. We could maybe change it in the Debian kernel for testing
> purposes and see if anything breaks for our users.
> 
> I'll report back.

That would cover Debian, but what about other distros whose components
are looking for the "wrong" name?

Re: Naming inconsistency for serial device on sparc

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Sun, 14 Apr 2019 09:21:32 +0200

> Is there any particular reason this device name mismatch exists or
> is it just a bug we can fix?

It's probably been there for so long that changing it is likely to
have a risk of breaking some other piece of software.

Re: [PATCH] silo: Add 64-bit support

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 24 Nov 2016 23:26:20 +0100

> On 11/24/2016 11:05 PM, Aaro Koskinen wrote:
>> I think that's your job to try. If you want to "add 64-bit support"
>> (instead of forcing it to everybody), do the required changes so that
>> it's still works for everybody without extra fiddling.
> 
> Don't be so rude, I'm not forcing anything onto anyone.
> 
 Also you broke the tilo build...
>>>
>>> Not here. Just tried it again and it builds fine. Can you be more specific?
>> 
>> The same issue as with silo.
> 
> Don't you think your statements are a bit misleading then? I didn't break 
> anything,
> I changed the default target to 64-bit which is somewhat reasonable in the 
> year
> 2016, isn't it.

Not really.

Many people, including myself, are still using predominantly 32-bit
userspace on sparc64 machines.  It is significantly faster, and for
me speed is really important.

So submitting a patch which breaks a common build environment is
really not acceptable.

Re: [PATCH] silo: Add 64-bit support

[David Miller]

From: Aaro Koskinen 
Date: Fri, 25 Nov 2016 00:05:15 +0200

> Hi,
> 
> On Thu, Nov 24, 2016 at 10:51:14PM +0100, John Paul Adrian Glaubitz wrote:
>> On 11/24/2016 10:23 PM, Aaro Koskinen wrote:
>> > This breaks the native build on my Sun Ultra 5 with 32-bit userspace and 
>> > GCC
>> > defaulting to ultrasparc:
>> 
>> Well, you can just change this part back to "elf32_sparc" and it will work. 
>> Might
>> even be possible to omit the "-m" option altogether to it will default to -m 
>> native.
> 
> I think that's your job to try. If you want to "add 64-bit support"
> (instead of forcing it to everybody), do the required changes so that
> it's still works for everybody without extra fiddling.

+1

This is exactly the kind of trouble the original patch submissions
were causing, and which were not resolved by the person submitting
the patches.

SILO must continue to build and work properly on systems which have a
predominantly 32-bit compilation environment and a gcc which defaults
to 32-bit.

I will not apply any patch which breaks this, because I too am going
to stick with a 32-bit userland on my sparc64 machines for as long as
I feasibly can.

Re: SILO Issues on an E4900

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 24 Nov 2016 11:00:29 +0100

> For SILO, Oracle has created several patches which port SILO to 64-bit (I 
> extracted
> that patch and applied it to the Debian package) and other packages which 
> improve
> SILO on modern sun4v machines.

All of the changes which were submitted to this list I reviewed and
either they were poorly formed or did not apply cleanly at all.

Everything fell to /dev/null and the developers made no effort
whatsoever to address the feedback and make the patches actually apply
to the SILO git tree properly.

The patches were not only poorly formed, or not able to apply to the
GIT tree, they were also extremely poorly documented with either a
very terse and vague commit message provided or none at all.  When
I would ask why a change was doing X or Y, I received no response
at all.

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[David Miller]

From: James Clarke 
Date: Thu, 27 Oct 2016 17:02:32 +0100

> I was just testing it on the IIIi when I got this. Anyway, it seems to work 
> fine.
> It hasn’t (yet) had one of the stupidly high allocations, but it did flush a 
> block
> of 3658 pages just fine (assuming the flush actually worked). Similarly for 
> the T1.

Thanks for testing.  I'll post the final patch I committed.

> The cut-off seems pretty arbitrary, and the only way to determine it properly 
> would
> be benchmarking (or finding out what the relevant delays are). Given x86 uses 
> 33,
> 32 or 64 seem perfectly fine, but going into the hundreds doesn’t sound stupid
> either... For such small numbers it’s probably hardly going to matter.

It's not too hard to write a kernel module which just does dummy TLB flushes in
the loop and count the cycles using the %tick register.  And I plan to hack on
something like that soon'ish.

Another part of the equation is that it blows away, at a minimum, all kernel
TLB entries.  And that has a certain cost too.

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[David Miller]

From: James Clarke 
Date: Thu, 27 Oct 2016 09:25:36 +0100

> 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=10006000 end=f000 PAGE_SIZE=2000
> [5948091.157530] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
> start=0001 end=00058c00 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.

I'm about to test it on my IIIi and will commit this if it seems to work 
properly.

I guess you have no opinion about the cut-off choosen? :-)

Anyways, we can fine tune it later.

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[David Miller]

From: James Clarke 
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 
> Date: Wed, 26 Oct 2016 20:17:10 +0100
> Subject: [PATCH] builddeb: Add support for sparc64
> 
> Signed-off-by: James Clarke 

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?

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[David Miller]

From: James Clarke <jrt...@jrtc27.com>
Date: Wed, 26 Oct 2016 18:21:06 +0100

>> On 26 Oct 2016, at 18:09, David Miller <da...@davemloft.net> wrote:
>> 
>> From: James Clarke <jrt...@jrtc27.com>
>> Date: Wed, 26 Oct 2016 17:58:16 +0100
>> 
>>>> On 26 Oct 2016, at 16:54, David Miller <da...@davemloft.net> wrote:
>>>> 
>>>> From: James Clarke <jrt...@jrtc27.com>
>>>> Date: Wed, 26 Oct 2016 09:28:05 +0100
>>>> 
>>>>> Any progress on TLB flushing?
>>>> 
>>>> I'll keep plugging away at it today.
>>> 
>>> Great; let me know if you need a guinea pig, as it’s pretty easy for me to
>>> reproduce.
>> 
>> Will do, what kind of cpus do you have?
> 
> * UltraSparc T5 (Niagara5)
> * UltraSparc T1 (Niagara)
> * UltraSPARC IIIi
> 
> The IIIi seems to be down at the moment though.

James, here is what I have so far.  I only gave it a brief testing on
sun4v, so no guarantees for the sun4u cases.  This is against the
current sparc GIT tree.

The cut-off is 32 pages, we can discuss whether that's a good value
to use or not.  FWIW, x86_64 has similar code for this situation and
uses a cut-off of 33.  Perhaps 64 is a better value, who knows.

It might even make sense to use a different cut-off for the hypervisor
case since the hypervisor trap we have to use to do the TLB operation
adds even more expense to each iteration of the range loop.

The policy implemented for huge range flushes below is:

1) Spitfire - Flush all non-locked entries, by hand using diagnostic
   TLB accesses.

2) Cheetah - Flush all non-locked entries using "flush all" operation.

3) sun4v/hypervisor - Flush entire kernel context, which does not
   remove locked or "permanent" entries.

Anyways, let me know how it goes.

diff --git a/arch/sparc/mm/ultra.S b/arch/sparc/mm/ultra.S
index 0fa2e62..5d2fd6c 100644
--- a/arch/sparc/mm/ultra.S
+++ b/arch/sparc/mm/ultra.S
@@ -113,12 +113,14 @@ __flush_tlb_pending:  /* 27 insns */
 
.align  32
.globl  __flush_tlb_kernel_range
-__flush_tlb_kernel_range:  /* 19 insns */
+__flush_tlb_kernel_range:  /* 31 insns */
/* %o0=start, %o1=end */
cmp %o0, %o1
be,pn   %xcc, 2f
+sub%o1, %o0, %o3
+   srlx%o3, 18, %o4
+   brnz,pn %o4, __spitfire_flush_tlb_kernel_range_slow
 sethi  %hi(PAGE_SIZE), %o4
-   sub %o1, %o0, %o3
sub %o3, %o4, %o3
or  %o0, 0x20, %o0  ! Nucleus
 1: stxa%g0, [%o0 + %o3] ASI_DMMU_DEMAP
@@ -134,6 +136,38 @@ __flush_tlb_kernel_range:  /* 19 insns */
nop
nop
nop
+   nop
+   nop
+   nop
+   nop
+   nop
+   nop
+   nop
+   nop
+   nop
+   nop
+
+__spitfire_flush_tlb_kernel_range_slow:
+   mov 63 * 8, %o4
+1: ldxa[%o4] ASI_ITLB_DATA_ACCESS, %o3
+   andcc   %o3, 0x40, %g0  /* _PAGE_L_4U */
+   bne,pn  %xcc, 2f
+movTLB_TAG_ACCESS, %o3
+   stxa%g0, [%o3] ASI_IMMU
+   stxa%g0, [%o4] ASI_ITLB_DATA_ACCESS
+   membar  #Sync
+2: ldxa[%o4] ASI_DTLB_DATA_ACCESS, %o3
+   andcc   %o3, 0x40, %g0
+   bne,pn  %xcc, 2f
+movTLB_TAG_ACCESS, %o3
+   stxa%g0, [%o3] ASI_DMMU
+   stxa%g0, [%o4] ASI_DTLB_DATA_ACCESS
+   membar  #Sync
+2: sub %o4, 8, %o4
+   brgez,pt%o4, 1b
+nop
+   retl
+nop
 
 __spitfire_flush_tlb_mm_slow:
rdpr%pstate, %g1
@@ -288,6 +322,40 @@ __cheetah_flush_tlb_pending:   /* 27 insns */
retl
 wrpr   %g7, 0x0, %pstate
 
+__cheetah_flush_tlb_kernel_range:  /* 31 insns */
+   /* %o0=start, %o1=end */
+   cmp %o0, %o1
+   be,pn   %xcc, 2f
+sub%o1, %o0, %o3
+   srlx%o3, 18, %o4
+   brnz,pn %o4, 3f
+sethi  %hi(PAGE_SIZE), %o4
+   sub %o3, %o4, %o3
+   or  %o0, 0x20, %o0  ! Nucleus
+1: stxa%g0, [%o0 + %o3] ASI_DMMU_DEMAP
+   stxa%g0, [%o0 + %o3] ASI_IMMU_DEMAP
+   membar  #Sync
+   brnz,pt %o3, 1b
+sub%o3, %o4, %o3
+2: sethi   %hi(KERNBASE), %o3
+   flush   %o3
+   retl
+nop
+3: mov 0x80, %o4
+   stxa%g0, [%o4] ASI_DMMU_DEMAP
+   membar  #Sync
+   stxa%g0, [%o4] ASI_IMMU_DEMAP
+   membar  #Sync
+   retl
+nop
+   nop
+   nop
+   n

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[David Miller]

From: James Clarke <jrt...@jrtc27.com>
Date: Wed, 26 Oct 2016 17:58:16 +0100

>> On 26 Oct 2016, at 16:54, David Miller <da...@davemloft.net> wrote:
>> 
>> From: James Clarke <jrt...@jrtc27.com>
>> Date: Wed, 26 Oct 2016 09:28:05 +0100
>> 
>>> Any progress on TLB flushing?
>> 
>> I was half-way through an implementation when I noticed that
>> hypervisor TLB flush handler relative branch bug I posted the
>> fix for last night.
> 
> Yep, I saw that. Looks like you forgot to update the comment on
> __hypervisor_flush_tlb_pending; it still says 16 insns rather than 27.

Fixed, thanks.

And now I noticed that the cross-call hypervisor tlb flush assembler
has the bug and needs to be fixed too...

>> I'll keep plugging away at it today.
> 
> Great; let me know if you need a guinea pig, as it’s pretty easy for me to
> reproduce.

Will do, what kind of cpus do you have?

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[David Miller]

From: James Clarke 
Date: Wed, 26 Oct 2016 09:28:05 +0100

> Any progress on TLB flushing?

I was half-way through an implementation when I noticed that
hypervisor TLB flush handler relative branch bug I posted the
fix for last night.

I'll keep plugging away at it today.

Re: Regression with 4.7.2 on sun4u

[David Miller]

From: James Clarke 
Date: Tue, 25 Oct 2016 01:10:55 +0100

> Sure, that makes sense; updated and tested for a few hours:
> 
> From d5997fd98fc80d1ceabe11f6fcd63dfce99b8253 Mon Sep 17 00:00:00 2001
> From: James Clarke 
> Date: Mon, 24 Oct 2016 19:49:25 +0100
> Subject: [PATCH v2] sparc: Handle negative offsets in
>  arch_jump_label_transform
> 
> Additionally, if the offset will overflow the immediate for a ba,pt
> instruction, fall back on a standard ba to get an extra 3 bits.
> 
> Signed-off-by: James Clarke 

Applied, thanks.

Re: NMI watchdog: BUG: soft lockup

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Tue, 25 Oct 2016 13:18:08 -0400 (EDT)

> So the full virtual address comparison is something like:
> 
>   unsigned long compare = (tag >> 22) << 22; /* Clear CONTEXT bits */
> 
>   compare |= (tsb_index & (nentries - 1)) << 13;
> 
>   if (vaddr == compare)
>   goto match;
> 
> The swapper TSB only stores PAGE_SIZE translations.

Ok, this should work:

static void flush_tsb_kernel_range_scan(unsigned long start, unsigned long end)
{
unsigned long idx;

for (idx = 0; idx < KERNEL_TSB_NENTRIES; idx++) {
struct tsb *ent = _tsb[idx];
unsigned long match = idx << 13;

match |= (ent->tag << 22);
if (match >= start && match < end)
ent->tag = (1UL << TSB_TAG_INVALID_BIT);
}
}

Bits 13-"21+N" come from the TSB index, and the tag always stores
bits 22 and above.  So simply 'or'ing them together always gives
us a usable match value.

Re: NMI watchdog: BUG: soft lockup

[David Miller]

From: James Clarke 
Date: Tue, 25 Oct 2016 16:59:04 +0100

> Can we do a similar thing for the TLB by iterating over all its entries? 
> Surely
> one of the ASIs lets you do that?

Yes, you can di it using diagnostic accesses.

But in my opinion for UltraSPARC-III/IV we should do an "all flush"
and for sun4v do a context 0 flush when the range is huge.

It's so much simpler, easier to audit and validate, and is probably
cheaper in the end.

Re: NMI watchdog: BUG: soft lockup

[David Miller]

From: James Clarke 
Date: Tue, 25 Oct 2016 16:59:04 +0100

> That’s basically the same as my patch, except this potentially flushes things
> outside [start, end) if they’re not on 2^22-byte boundaries.

Oh yes, I see, thanks for pointing that out.

We have to take the index into account for the purposes of virtual
address comparison.

Re: NMI watchdog: BUG: soft lockup

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Tue, 25 Oct 2016 11:22:31 -0400 (EDT)

> From: James Clarke <jrt...@jrtc27.com>
> Date: Tue, 25 Oct 2016 16:11:52 +0100
> 
>> Yep, that fix is still there, but you will note that end *is* above start in
>> the call. Something is being allocated and freed right at the end of the 
>> malloc
>> area, so it’s iterating over almost the entire thing.
> 
> Ok, let me think about this some more.

So, for the TSB part we don't need to do anything fancy, something like
the patch below will suffice.

As per the TLB flush that's a bit more complicated.

For the older chips we need to do more work because they unfortunately
defined the context flush to even remove locked TLB entries.
Otherwise we could simply do a nucleus context flush if the range is
too large.  So we'll have to use diagnostic accesses to implement the
same functionality.

UltraSPARC-III and later provide more usable facilities for this
situation.  UltraSPARC-III/IV have a "flush all" which removes all
non-locked TLB entries.  And all of the sun4v chips have a more
reasonable context flush, which does not remove "permanent" entries.

I'll start hacking something up.

diff --git a/arch/sparc/mm/tsb.c b/arch/sparc/mm/tsb.c
index f2b7711..1f63411 100644
--- a/arch/sparc/mm/tsb.c
+++ b/arch/sparc/mm/tsb.c
@@ -27,6 +27,20 @@ static inline int tag_compare(unsigned long tag, unsigned 
long vaddr)
return (tag == (vaddr >> 22));
 }
 
+static void flush_tsb_kernel_range_scan(unsigned long start, unsigned long end)
+{
+   unsigned long idx;
+
+   start >> 22;
+   end >> 22;
+   for (idx = 0; idx < KERNEL_TSB_NENTRIES; idx++) {
+   struct tsb *ent = _tsb[idx];
+
+   if (ent->tag >= start && end->tag < end)
+   ent->tag = (1UL << TSB_TAG_INVALID_BIT);
+   }
+}
+
 /* TSB flushes need only occur on the processor initiating the address
  * space modification, not on each cpu the address space has run on.
  * Only the TLB flush needs that treatment.
@@ -36,6 +50,9 @@ void flush_tsb_kernel_range(unsigned long start, unsigned 
long end)
 {
unsigned long v;
 
+   if ((end - start) >> PAGE_SHIFT >= 2 * KERNEL_TSB_NENTRIES)
+   return flush_tsb_kernel_range_scan(start, end);
+
for (v = start; v < end; v += PAGE_SIZE) {
unsigned long hash = tsb_hash(v, PAGE_SHIFT,
  KERNEL_TSB_NENTRIES);

Re: NMI watchdog: BUG: soft lockup

[David Miller]

From: James Clarke 
Date: Tue, 25 Oct 2016 16:11:52 +0100

> Yep, that fix is still there, but you will note that end *is* above start in
> the call. Something is being allocated and freed right at the end of the 
> malloc
> area, so it’s iterating over almost the entire thing.

Ok, let me think about this some more.

Re: NMI watchdog: BUG: soft lockup

[David Miller]

From: James Clarke 
Date: Tue, 25 Oct 2016 14:15:26 +0100

> I built a custom kernel with a single extra printk at the start of
> flush_tsb_kernel_range which prints its arguments. I then had to wait for it 
> to
> be hit, and when it was, I got the following:
> 
> [5717559.949396] TSB: DEBUG flush_tsb_kernel_range start=10006000 
> end=f000 PAGE_SIZE=2000
> [5717560.062663] TSB: DEBUG flush_tsb_kernel_range start=0001 
> end=0005a200 PAGE_SIZE=2000

I thought I fixed this a very very long time ago:

commit 473ad7f4fb005d1bb727e4ef27d370d28703a062
Author: David S. Miller 
Date:   Sat Oct 4 21:05:14 2014 -0700

sparc64: Fix reversed start/end in flush_tlb_kernel_range()

When we have to split up a flush request into multiple pieces
(in order to avoid the firmware range) we don't specify the
arguments in the right order for the second piece.

Fix the order, or else we get hangs as the code tries to
flush "a lot" of entries and we get lockups like this:

[ 4422.981276] NMI watchdog: BUG: soft lockup - CPU#12 stuck for 23s! 
[expect:117032]
[ 4422.996130] Modules linked in: ipv6 loop usb_storage igb ptp sg sr_mod 
ehci_pci ehci_hcd pps_core n2_rng rng_core
[ 4423.016617] CPU: 12 PID: 117032 Comm: expect Not tainted 3.17.0-rc4+ 
#1608
[ 4423.030331] task: fff8003cc730e220 ti: fff8003d99d54000 task.ti: 
fff8003d99d54000
[ 4423.045282] TSTATE: 11001602 TPC: 004521e8 TNPC: 
004521ec Y: Not tainted
[ 4423.064905] TPC: <__flush_tlb_kernel_range+0x28/0x40>
[ 4423.074964] g0: 0052fd10 g1: 0001295a8000 g2: 
ff7176ffc000 g3: 2000
[ 4423.092324] g4: fff8003cc730e220 g5: fff8003dfedcc000 g6: 
fff8003d99d54000 g7: 0006
[ 4423.109687] o0:  o1:  o2: 
0003 o3: f000
[ 4423.127058] o4: 0080 o5: 0001295a8000 sp: 
fff8003d99d56d01 ret_pc: 0052ff54
[ 4423.145121] RPC: <__purge_vmap_area_lazy+0x314/0x3a0>
[ 4423.155185] l0:  l1:  l2: 
00a38040 l3: 
[ 4423.172559] l4: fff8003dae8965e0 l5:  l6: 
 l7: f7e2b138
[ 4423.189913] i0: fff8003d99d576a0 i1: fff8003d99d576a8 i2: 
fff8003d99d575e8 i3: 
[ 4423.207284] i4: 8008 i5: fff8003d99d575c8 i6: 
fff8003d99d56df1 i7: 00530c24
[ 4423.224640] I7: 
[ 4423.234193] Call Trace:
[ 4423.239051]  [00530c24] free_vmap_area_noflush+0x64/0x80
[ 4423.251029]  [00531a7c] remove_vm_area+0x5c/0x80
[ 4423.261628]  [00531b80] __vunmap+0x20/0x120
[ 4423.271352]  [0071cf18] n_tty_close+0x18/0x40
[ 4423.281423]  [007222b0] tty_ldisc_close+0x30/0x60
[ 4423.292183]  [007225a4] tty_ldisc_reinit+0x24/0xa0
[ 4423.303120]  [00722ab4] tty_ldisc_hangup+0xd4/0x1e0
[ 4423.314232]  [00719aa0] __tty_hangup+0x280/0x3c0
[ 4423.324835]  [00724cb4] pty_close+0x134/0x1a0
[ 4423.334905]  [0071aa24] tty_release+0x104/0x500
[ 4423.345316]  [005511d0] __fput+0x90/0x1e0
[ 4423.354701]  [0047fa54] task_work_run+0x94/0xe0
[ 4423.365126]  [00404b44] __handle_signal+0xc/0x2c

Fixes: 4ca9a23765da ("sparc64: Guard against flushing openfirmware 
mappings.")
Signed-off-by: David S. Miller 

diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index c8bccaf..bd08ed4 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2837,8 +2837,8 @@ void flush_tlb_kernel_range(unsigned long start, unsigned 
long end)
do_flush_tlb_kernel_range(start, LOW_OBP_ADDRESS);
}
if (end > HI_OBP_ADDRESS) {
-   flush_tsb_kernel_range(end, HI_OBP_ADDRESS);
-   do_flush_tlb_kernel_range(end, HI_OBP_ADDRESS);
+   flush_tsb_kernel_range(HI_OBP_ADDRESS, end);
+   do_flush_tlb_kernel_range(HI_OBP_ADDRESS, end);
}
} else {
flush_tsb_kernel_range(start, end);

Re: Regression with 4.7.2 on sun4u

[David Miller]

From: James Clarke 
Date: Sat, 22 Oct 2016 10:51:28 +0100

> @@ -19,12 +19,20 @@ void arch_jump_label_transform(struct jump_entry *entry,
>   if (type == JUMP_LABEL_JMP) {
>   s32 off = (s32)entry->target - (s32)entry->code;
>  
> + BUG_ON(off & 3);
> +
>  #ifdef CONFIG_SPARC64
> - /* ba,pt %xcc, . + (off << 2) */
> - val = 0x1068 | ((u32) off >> 2);
> + /* WDISP19 - target is . + (immed << 2) */
> + BUG_ON(off > 0xf);
> + BUG_ON(off < -0x10);
> + /* ba,pt %xcc, . + off */
> + val = 0x1068 | (((u32) off >> 2) & 0x7);
>  #else
> - /* ba . + (off << 2) */
> - val = 0x1080 | ((u32) off >> 2);
> + /* WDISP22 - target is . + (immed << 2) */
> + BUG_ON(off > 0x7f);
> + BUG_ON(off < -0x80);
> + /* ba . + off */
> + val = 0x1080 | (((u32) off >> 2) & 0x3f);
>  #endif

Since we can determine at run time whether we need to use a non-v9
branch or not, it makes no sense to fail when a v9 branch is out of
range.

We can simply downgrade to a pre-v9 one.

Something like this:

diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
index 59bbeff..689e557 100644
--- a/arch/sparc/kernel/jump_label.c
+++ b/arch/sparc/kernel/jump_label.c
@@ -13,19 +13,24 @@
 void arch_jump_label_transform(struct jump_entry *entry,
   enum jump_label_type type)
 {
-   u32 val;
u32 *insn = (u32 *) (unsigned long) entry->code;
+   u32 val;
 
if (type == JUMP_LABEL_JMP) {
s32 off = (s32)entry->target - (s32)entry->code;
+   bool use_v9_branch = false;
 
 #ifdef CONFIG_SPARC64
-   /* ba,pt %xcc, . + (off << 2) */
-   val = 0x1068 | ((u32) off >> 2);
-#else
-   /* ba . + (off << 2) */
-   val = 0x1080 | ((u32) off >> 2);
+   if (off <= 0xf && off >= -0x10)
+   use_v9_branch = true;
 #endif
+   if (use_v9_branch) {
+   /* ba,pt %xcc, . + (off << 2) */
+   val = 0x1068 | (((u32) off >> 2) & 0x7);
+   } else {
+   /* ba . + (off << 2) */
+   val = 0x1080 | (((u32) off >> 2) & 0x3f);
+   }
} else {
val = 0x0100;
}

Re: Regression with 4.7.2 on sun4u

[David Miller]

From: James Clarke 
Date: Fri, 21 Oct 2016 22:52:45 +0100

> This indeed was the case. The attached patch fixes the problem for me,
> generating 0x1062, which gdb can verify is sensible (of course, the
> addresses have shifted slightly):

Please don't use attachments for patch submissions.

Patches must be inline so that they can be commented upon properly
using simply email quoting mechanisms.

Thank you.

Re: Regression with 4.7.2 on sun4u

[David Miller]

From: Rob Gardner 
Date: Fri, 21 Oct 2016 09:49:30 -0600

> That could be either a stray memory write or a boot time patch gone
> wrong.

It could be that we need to use non-predicting branches in the jump
label implementation.  We could be overflowing the branch displacement
range if the kernel being built is really huge.

Something like the following would fix it if true:

diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
index 59bbeff..841d98e 100644
--- a/arch/sparc/kernel/jump_label.c
+++ b/arch/sparc/kernel/jump_label.c
@@ -19,13 +19,8 @@ void arch_jump_label_transform(struct jump_entry *entry,
if (type == JUMP_LABEL_JMP) {
s32 off = (s32)entry->target - (s32)entry->code;
 
-#ifdef CONFIG_SPARC64
-   /* ba,pt %xcc, . + (off << 2) */
-   val = 0x1068 | ((u32) off >> 2);
-#else
/* ba . + (off << 2) */
val = 0x1080 | ((u32) off >> 2);
-#endif
} else {
val = 0x0100;
}

Re: Regression with 4.7.2 on sun4u

[David Miller]

From: Anatoly Pugachev 
Date: Fri, 21 Oct 2016 15:57:16 +0300

> Any idea how to debug this?

Bisection may be the quickest way.

Re: Please upgrade your machines to sparc64

[David Miller]

From: alexmcwhir...@triadic.us
Date: Thu, 23 Jun 2016 16:12:35 -0400

> 1. Oracle knows sparc32 is faster than sparc64, that's why nearly half
> of Solaris is 32 bit.

+1

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Thu, 23 Jun 2016 21:42:41 +0200

> On 06/23/2016 09:37 PM, David Miller wrote:
>> We're not asking for the old "pure" 32-bit sparc port.
>> 
>> Just a v8+ one, that doesn't support any pre-sparc64 hardware.
>> 
>> Also a large entity doing something doesn't make it the correct
>> thing to do.
> 
> I'm out of this discussion. This is annoying.
> 
> I'm not going to change my opinion on this. I'm not going to go against
> the main flow. I am not getting paid for this, I am doing this completely
> in my free time, so I don't understand why I constantly have to justify
> myself.
> 
> I have invested lots of time and effort to get Debian's sparc64 port to
> where it is now and I'm not going to let this diminished by the naysayers.

You can do a good job and do useful work for people, which you
seem to have done.

But your decisions are still up for criticism and analysis.

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Thu, 23 Jun 2016 21:33:34 +0200

> On 06/23/2016 09:31 PM, David Miller wrote:
>> And all of those binaries you say "don't matter" take up memory,
>> swap space, etc.  And if you add this up for the entire system
>> it's non-trivial.
>> 
>> Multiply this by some factor N when virtualization is involved.
> 
> On a machine with 8 TiB of memory? I have also never heard anyone complain
> about memory issues on x86_64. Are you also running i686 for that reasons?

It's physical memory, cache memory, TLB entries.

Not the amount of physical or virtual "address space" the cpu
supports.

> Intel ICC does exactly that. I even provided a reference for that.

I don't understand how such an optimization is even possible, or would
even apply in common cases where the pointer is actually used.

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 23 Jun 2016 21:25:40 +0200

> As I have mentioned before, the work mainly targets modern
> hardware. We are not doing this so that people can install Debian on
> historic hardware.

We're not asking for the old "pure" 32-bit sparc port.

Just a v8+ one, that doesn't support any pre-sparc64 hardware.

Also a large entity doing something doesn't make it the correct
thing to do.

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Thu, 23 Jun 2016 20:42:31 +0200

> On 06/23/2016 05:06 PM, David Miller wrote:
>> I think what irks people the most about what happened, is that the
>> choosen a path is not the most optimal situation for the target
>> platform.
> 
> Why should it be any different for sparc64 than for ppc64el, amd64,
> arm64, mips64el and so on? Is SPARC so extremely inefficient with
> 64-bit pointers? I don't think so.

It makes a significant performance and memory footprint difference.

This is irrefutable.

And all of those binaries you say "don't matter" take up memory,
swap space, etc.  And if you add this up for the entire system
it's non-trivial.

Multiply this by some factor N when virtualization is involved.

> I don't think it makes sense to compile things like dateutils with
> 32-bit pointers for performance reasons. Also, I would assume that
> modern compilers are able to optimize the code well enough that the
> difference between 32-bit and 64-bit pointers isn't too big that
> it justifies the effort.

No compiler is going to optimize away the pointers in the data
structures, and thus get all of those cache line and tlb misses back.

I do all of my work with 32-bit gcc binaries, even thought I often am
using tools I've built myself.

It makes a huge difference.

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 23 Jun 2016 10:30:14 +0200

> Thus, I don't think any of the objections brought up against the
> sparc64 port are valid. Neither is sparc64 64-bit only nor does
> anyone anyhow prevent you in Debian to mix packages from different
> architectures. In fact, Debian has by far the most flexible approach
> to resolve the 32-bit/64-bit problem by providing a generic approach
> for mixing libraries of different architectures.

I think what irks people the most about what happened, is that the
choosen a path is not the most optimal situation for the target
platform.

The most desirable would have been to build the bulk of userland
binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx
for some v9 cpu), and then for the specific packages that need it,
build 64-bit.

And I would assume that would be perhaps binutils and perhaps gcc
and GIT.

Yes, the 64-bit packages for everything should exist in the repository
and be built, but the default install should not have everything
64-bit.

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Wed, 22 Jun 2016 21:23:40 +0200

> Alas, I haven't done any detailed benchmarking yet.

Too bad, since that's where all the problems will be.

Even just doing a kernel build or a gcc bootstrap, you'll
see it.

And that effects the people like me who you expect to work
on bug fixes.

Frankly, I'm leaving all of my sparc64 machines, yes all of
them, running the unsupported 32-bit userland and will simply
live without upgrades and support.

That's how important this is to me.

Re: [sparc] niagara2 cpu, opcodes not available message?

[David Miller]

From: Anatoly Pugachev 
Date: Wed, 8 Jun 2016 20:30:40 +0300

> Can someone please tell, why do we get a bunch of the following
> messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220,
> T5140, and T5240 servers)
> 
> Asking, because I see the following lines on kernel boot (removing
> first field boot time stamp in cut):
> 
> mator@nvg5120:~/linux-sparc-boot-logs/t5120$ grep opcode
> dmesg-4.7.0-rc2+.log  | cut -f2- -d' ' | sort | uniq -c
>   4 aes_sparc64: sparc64 aes opcodes not available.
>   7 camellia_sparc64: sparc64 camellia opcodes not available.
>  37 crc32c_sparc64: sparc64 crc32c opcode not available.
>   5 des_sparc64: sparc64 des opcodes not available.
>   4 md5_sparc64: sparc64 md5 opcode not available.
>   1 sha1_sparc64: sparc64 sha1 opcode not available.
>   2 sha256_sparc64: sparc64 sha256 opcode not available.
>   3 sha512_sparc64: sparc64 sha512 opcode not available.

Because the drivers unconditionally try to load, check the CPU capabilites
and emit the log message if the cpu caps aren't present.

I don't see what the problem is, everying is working as designed.

Re: Definition of __sparc64__ in gcc

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Mon, 16 May 2016 14:23:08 +0200

> Hello!
> 
> While looking at the FTBFS of Firefox, I noticed that Firefox, more
> precisely ipc/chromium was checking for the definition of __sparc64__
> to configure the code for sparc64 [1].
> 
> However, when looking at the actual gcc configuration dump, it's
> apparent that __sparc64__ is actually not used but __arch64__:
> 
> root@landau:~# echo | gcc -E -dM - |grep __arch64__
> #define __arch64__ 1
> root@landau:~# echo | gcc -E -dM - |grep __sparc64__
> root@landau:~#
> 
> Changing the header in Firefox's code base actually fixed this
> particular issue with the firefox package on Debian.
> 
> Thus, my suspicion is that there might be other packages which are
> incorrectly configured on sparc64 and consequently either failing
> to build from source, crashing their testsuite or crashing during
> operation.
> 
> A list of the possibly affected packages can be found in [2].
> 
> Any comments?

The correct test has always been "__sparc__ && __arch64__"

Re: Enable module aliases for vio on sparc/sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 14 Apr 2016 11:00:41 +0200

> Sigh, I shouldn't do such things in the middle of the night, sorry:
> 
> root@deb4g:/sys/devices/channel-devices# cat v*/mod*
> vio:Tvdc-portS
> vio:Tvdc-portS
> vio:Tvdc-portS
> vio:Tvdc-portS
> vio:Tvdc-portS
> vio:Tvlds-portS
> vio:Tvnet-portS
> vio:Tvnet-portS
> vio:Tvnet-portS
> vio:Tvnet-portS
> vio:Tvnet-portS
> vio:Tvnet-portS
> root@deb4g:/sys/devices/channel-devices#

That looks a lot better.

Re: Enable module aliases for vio on sparc/sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 14 Apr 2016 01:22:37 +0200

> From 8d95bce6a35dc037d1e419896af19e12b3cda910 Mon Sep 17 00:00:00 2001
> From: John Paul Adrian Glaubitz 
> Date: Thu, 14 Apr 2016 01:16:14 +0200
> Subject: [PATCH 1/2] sparc/kernel/vio.c: implement modalias_show()
> 
> Signed-off-by: John Paul Adrian Glaubitz 
> ---
>  arch/sparc/kernel/vio.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/sparc/kernel/vio.c b/arch/sparc/kernel/vio.c
> index cb5789c..5a9bb9d 100644
> --- a/arch/sparc/kernel/vio.c
> +++ b/arch/sparc/kernel/vio.c
> @@ -105,6 +105,13 @@ static ssize_t type_show(struct device *dev,
>   return sprintf(buf, "%s\n", vdev->type);
>  }
>  
> +static ssize_t modalias_show(struct device *dev, struct device_attribute 
> *attr,
> + char *buf)
> +{
> + const struct vio_dev *vdev = to_vio_dev(dev);
> + return sprintf(buf, "vio:T%sS%s\n", vdev->type, vdev->compat);
> +}
> +

You're not hooking this function up at all into the operations.  Looks like
you are mixing this patch up with other local changes.

And again, please, empty line after local variable declarations.

Thanks.

Re: Enable module aliases for vio on sparc/sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 14 Apr 2016 01:22:37 +0200

> From 3515ad550f7b1db467664acc9bf0ed3d2aec9fdd Mon Sep 17 00:00:00 2001
> From: John Paul Adrian Glaubitz 
> Date: Thu, 14 Apr 2016 01:19:40 +0200
> Subject: [PATCH 2/2] sparc/kernel/vio.c: implement vio_hotplug and add it to
>  vio_bus_type
> 
> Signed-off-by: John Paul Adrian Glaubitz 
> ---
>  arch/sparc/kernel/vio.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/sparc/kernel/vio.c b/arch/sparc/kernel/vio.c
> index 5a9bb9d..59f4b7c 100644
> --- a/arch/sparc/kernel/vio.c
> +++ b/arch/sparc/kernel/vio.c
> @@ -45,6 +45,13 @@ static const struct vio_device_id *vio_match_device(
>   return NULL;
>  }
>  
> +static int vio_hotplug(struct device *dev, struct kobj_uevent_env *env)
> +{
> + const struct vio_dev *vio_dev = to_vio_dev(dev);
> + add_uevent_var(env, "MODALIAS=vio:T%sS%s", vio_dev->type, 
> vio_dev->compat);
> +  return 0;

Extra space before "return 0" after the TAB.

Need an empty line after the local variable declarations.

Re: Enable module aliases for vio on sparc/sparc64

[David Miller]

From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Thu, 14 Apr 2016 01:04:17 +0200

> On 04/14/2016 01:01 AM, David Miller wrote:
>> Ok those are the block devices, where are the networking interfaces?
> 
> Whoops, sorry:
> 
> root@deb4g:/sys/devices/channel-devices# cat vdc*/mod*
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> root@deb4g:/sys/devices/channel-devices#
> 
> Testing a much simpler version now. Second.

Those all say "vdc-port", which again is the block device.

Where are the networking devices?

Re: Enable module aliases for vio on sparc/sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 14 Apr 2016 00:44:19 +0200

> Yeah, I modified Ben's patch and it works:
> 
> root@deb4g:/sys/devices/channel-devices# cat vdc*/mod*
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown
> vio:Tvdc-portSunknown

Ok those are the block devices, where are the networking interfaces?

Re: Enable module aliases for vio on sparc/sparc64

[David Miller]

From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Thu, 14 Apr 2016 00:35:58 +0200

> On 04/14/2016 12:23 AM, David Miller wrote:
>> The missing bit is probably having the individual sparc64 VIO drivers
>> define proper module aliases.
> 
> I'm actually currently working on a patch. The aliases are already
> working, now it's just the actual hotplug handler which is missing.

Are you sure?  See my other email, VIO devices don't come from the
Openfirmware device tree at all.

Re: Enable module aliases for vio on sparc/sparc64

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Wed, 13 Apr 2016 18:23:49 -0400 (EDT)

> From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
> Date: Wed, 13 Apr 2016 17:33:25 +0200
> 
>> On 04/11/2016 09:04 PM, David Miller wrote:
>>> Either way, I'll look at this patch, thanks.
>> 
>> Just as a heads-up:
>> 
>> The suggested patch does not work unfortunately. Modules are not
>> loaded automatically and it seems modaliases are not generated
>> properly.
>> 
>> It seems that the vio implementation for sparc which you adapted
>> from powerpc uses a different name to retrieve the device nodes.
> 
> The missing bit is probably having the individual sparc64 VIO drivers
> define proper module aliases.

Actually there is another, more fundamental, problem.

The VIO devices on sparc64 are not instantiated from openfirmware
device nodes.

They are instead instantiated from nodes in the machine description.

Ben's patch is therefore buggy, he's looking at the of_node but that
will never be filled in for a VIO device on sparc64.

That's why I kinda cringed when it was suggested that the PowerPC and
Sparc64 VIO stuff should be merged together.  They simply can't, as
they are instantiating devices from two different sources.

Does Debian's installer have a machine description counterpart to the
opernfirmware device probing and discovery?  I bet it doesn't, and
that seems to be the first piece of infrastructure that needs to be
added before any of this can work.

Re: Enable module aliases for vio on sparc/sparc64

[David Miller]

From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Wed, 13 Apr 2016 17:33:25 +0200

> On 04/11/2016 09:04 PM, David Miller wrote:
>> Either way, I'll look at this patch, thanks.
> 
> Just as a heads-up:
> 
> The suggested patch does not work unfortunately. Modules are not
> loaded automatically and it seems modaliases are not generated
> properly.
> 
> It seems that the vio implementation for sparc which you adapted
> from powerpc uses a different name to retrieve the device nodes.

The missing bit is probably having the individual sparc64 VIO drivers
define proper module aliases.

Re: Enable module aliases for vio on sparc/sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Mon, 11 Apr 2016 09:30:54 +0200

> Hi Dave!
> 
> We have had issues when installing Debian's sparc64 port on SPARC
> machines with virtualization support. In order to be able to install
> Linux into an LDOM container, both the modules sunvdc and sunvnet
> need to be loaded to enable block device and networking support
> within the virtual machine.
> 
> Unfortunately, these modules are never loaded automatically despite
> being present and the hardware supporting it. After some discussion
> in Debian's bug tracker [1], Ben Hutchings, Debian's kernel maintainer,
> mentioned that this is a result of the VIO bus implementation on
> sparc/sparc64 not supporting module aliases and consequently automatic
> loading.
> 
> Ben has provided a minimal and dirty patch which enables aliases
> for vio on sparc/sparc64, but he says the better solution would
> be to merge VIO implementations on both sparc/sparc64 and PowerPC,
> the latter already supporting module aliases and auto loading.
> 
> A quick hotfix as Ben suggested would be great for the time being
> as it would unbreak the Debian installation within LDOMs, so
> I was wondering whether you could merge the patch?
> 
> Any other suggestion?

Thanks for bringing this up.

Although I wonder, I was able to successfully install debian just fine
a couple years ago in LDOM guest nodes without any special changes
whatsoever.  Were there autoload hacks placed in /etc or similar
before?

Either way, I'll look at this patch, thanks.

Re: [PATCH] sparc64: use ENTRY/ENDPROC in VISsave

[David Miller]

From: Sam Ravnborg s...@ravnborg.org
Date: Fri, 7 Aug 2015 20:34:12 +0200

 From 7d8a508d74e6cacf0f2438286a959c3195a35a37 Mon Sep 17 00:00:00 2001
 From: Sam Ravnborg s...@ravnborg.org
 Date: Fri, 7 Aug 2015 20:26:12 +0200
 Subject: [PATCH] sparc64: use ENTRY/ENDPROC in VISsave
 
 Commit 44922150d87cef616fd183220d43d8fde4d41390
 (sparc64: Fix userspace FPU register corruptions) left a
 stale globl symbol which was not used.
 
 Fix this and introduce use of ENTRY/ENDPROC
 
 Signed-off-by: Sam Ravnborg s...@ravnborg.org

Applied, thanks Sam.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150807.152256.960911445777356991.da...@davemloft.net

[PATCH] sparc64: Fix userspace FPU register corruptions.

[David Miller]

If we have a series of events from userpsace, with %fprs=FPRS_FEF,
like follows:

ETRAP
ETRAP
VIS_ENTRY(fprs=0x4)
VIS_EXIT
RTRAP (kernel FPU restore with fpu_saved=0x4)
RTRAP

We will not restore the user registers that were clobbered by the FPU
using kernel code in the inner-most trap.

Traps allocate FPU save slots in the thread struct, and FPU using
sequences save the dirty FPU registers only.

This works at the initial trap level because all of the registers
get recorded into the top-level FPU save area, and we'll return
to userspace with the FPU disabled so that any FPU use by the user
will take an FPU disabled trap wherein we'll load the registers
back up properly.

But this is not how trap returns from kernel to kernel operate.

The simplest fix for this bug is to always save all FPU register state
for anything other than the top-most FPU save area.

Getting rid of the optimized inner-slot FPU saving code ends up
making VISEntryHalf degenerate into plain VISEntry.

Longer term we need to do something smarter to reinstate the partial
save optimizations.  Perhaps the fundament error is having trap entry
and exit allocate FPU save slots and restore register state.  Instead,
the VISEntry et al. calls should be doing that work.

This bug is about two decades old.

Reported-by: James Y Knight jykni...@google.com
Signed-off-by: David S. Miller da...@davemloft.net
---

I'll get this to Linus and -stable ASAP...

 arch/sparc/include/asm/visasm.h | 16 +++---
 arch/sparc/lib/NG4memcpy.S  |  5 ++-
 arch/sparc/lib/VISsave.S| 67 ++---
 arch/sparc/lib/ksyms.c  |  4 ---
 4 files changed, 11 insertions(+), 81 deletions(-)

diff --git a/arch/sparc/include/asm/visasm.h b/arch/sparc/include/asm/visasm.h
index 1f0aa20..6424249 100644
--- a/arch/sparc/include/asm/visasm.h
+++ b/arch/sparc/include/asm/visasm.h
@@ -28,16 +28,10 @@
  * Must preserve %o5 between VISEntryHalf and VISExitHalf */
 
 #define VISEntryHalf   \
-   rd  %fprs, %o5; \
-   andcc   %o5, FPRS_FEF, %g0; \
-   be,pt   %icc, 297f; \
-sethi  %hi(298f), %g7; \
-   sethi   %hi(VISenterhalf), %g1; \
-   jmpl%g1 + %lo(VISenterhalf), %g0;   \
-or %g7, %lo(298f), %g7;\
-   clr %o5;\
-297:   wr  %o5, FPRS_FEF, %fprs;   \
-298:
+   VISEntry
+
+#define VISExitHalf\
+   VISExit
 
 #define VISEntryHalfFast(fail_label)   \
rd  %fprs, %o5; \
@@ -47,7 +41,7 @@
ba,a,pt %xcc, fail_label;   \
 297:   wr  %o5, FPRS_FEF, %fprs;
 
-#define VISExitHalf\
+#define VISExitHalfFast\
wr  %o5, 0, %fprs;
 
 #ifndef __ASSEMBLY__
diff --git a/arch/sparc/lib/NG4memcpy.S b/arch/sparc/lib/NG4memcpy.S
index 140527a..83aeeb1 100644
--- a/arch/sparc/lib/NG4memcpy.S
+++ b/arch/sparc/lib/NG4memcpy.S
@@ -240,8 +240,11 @@ FUNC_NAME: /* %o0=dst, %o1=src, %o2=len */
add %o0, 0x40, %o0
bne,pt  %icc, 1b
 LOAD(prefetch, %g1 + 0x200, #n_reads_strong)
+#ifdef NON_USER_COPY
+   VISExitHalfFast
+#else
VISExitHalf
-
+#endif
brz,pn  %o2, .Lexit
 cmp%o2, 19
ble,pn  %icc, .Lsmall_unaligned
diff --git a/arch/sparc/lib/VISsave.S b/arch/sparc/lib/VISsave.S
index b320ae9..a063d84 100644
--- a/arch/sparc/lib/VISsave.S
+++ b/arch/sparc/lib/VISsave.S
@@ -44,9 +44,8 @@ vis1: ldub[%g6 + TI_FPSAVED], %g3
 
 stx%g3, [%g6 + TI_GSR]
 2: add %g6, %g1, %g3
-   cmp %o5, FPRS_DU
-   be,pn   %icc, 6f
-sll%g1, 3, %g1
+   mov FPRS_DU | FPRS_DL | FPRS_FEF, %o5
+   sll %g1, 3, %g1
stb %o5, [%g3 + TI_FPSAVED]
rd  %gsr, %g2
add %g6, %g1, %g3
@@ -80,65 +79,3 @@ vis1:ldub[%g6 + TI_FPSAVED], %g3
.align  32
 80:jmpl%g7 + %g0, %g0
 nop
-
-6: ldub[%g3 + TI_FPSAVED], %o5
-   or  %o5, FPRS_DU, %o5
-   add %g6, TI_FPREGS+0x80, %g2
-   stb %o5, [%g3 + TI_FPSAVED]
-
-   sll %g1, 5, %g1
-   add %g6, TI_FPREGS+0xc0, %g3
-   wr  %g0, FPRS_FEF, %fprs
-   membar  #Sync
-   stda%f32, [%g2 + %g1] ASI_BLK_P
-   stda%f48, [%g3 + %g1] ASI_BLK_P
-   membar  #Sync
-   ba,pt   %xcc, 80f
-  

Re: Linux Sparc FPU register corruption

[David Miller]

From: David Miller da...@davemloft.net
Date: Wed, 10 Jun 2015 13:22:07 -0700 (PDT)

 Good news, I can reproduce it on my T3.
 
 I'll try to debug this.

Just wanted to give a status update on this.  I know what is going
wrong and am working on coming up with a fix.  This is a two decades
old bug.

I wrote a sophisticated tracing mechanism to load all of the FPU state
saves and restores and a special software trap that dumps kernel FPU
saving state which is triggerable from the testcase.

What's really important is to generate this state dump exactly when
the FPU corruption first occurs.  So in the testcase I made it jump
out to the error reporting code from within the inner loop of stores.
So it looks like this:


#if USE_BLKSTORE
  int *mem;
  for (mem = (int*)res; mem  (int*)((char*)res + 0x14); mem += 16) {
// 0xf0 == ASI_BLK_P

   
asm volatile(stda %%f0, [%0] 0xf0 : : r(mem) : memory);
asm volatile(std %%f0, [%0] : : r (xx[0]) : memory);
if (xx[0] != 0x0102030405060708)
goto do_bug;
  }
#else
 ...
do_bug:
  get_fp_regs(xx);

  int i;
  for(i = 0; i  32; ++i) {
if (xx[i] != 0x0102030405060708) {
  // Modifying a low-fp register causes the usleep to not restore the 
values. 
 
  // asm volatile(fsrc2 %f32, %f0);   

   
  // Calling usleep causes the fp registers to regain their proper values.  

   
  //usleep(10); 

   
  __asm__ __volatile__(ta 0x0f);


The ta 0x0f is the special software trap that dumps state into the kernel
log.  Part of what gets dumped is a ring buffer of FPU save/restore events,
it looks like this:

FPU fpsaved[0x7] gsr[0x6] xfsr[0x0]
FREGS0 
[0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708]
FREGS1 
[0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708]
FREGS2 
[0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708]
FREGS3 
[0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708:0102030405060708]
FREGS4 
[:::::::]
FREGS5 
[:::::::]
FREGS6 
[:::::::]
FREGS7 
[:::::::]
FPU_HIST ent(7) [41 03 09 4a 09 4b 08 08]

It dumps the fsr/gsr saved at the top level of the FPU state stack, and the FPU 
registers
from the top two FPU state stack slots.  Then it dumps the FPU event history 
log.

The above log encodes to:


ETRAP
VIS_ENTRY(fprs=0x4)
VIS_EXIT
RTRAP
RTRAP_KFPU_RESTORE(fpu_saved=0x4)
RTRAP
RTRAP_UFPU(fprs=0x4)
ETRAP


The final ETRAP is the one generated by the application for the ta 0x0f
instruction.

At a high level the FPU saving code is trying to minimize the amount
of register saves we do when the kernel wants to use the FPU
internally _or_ we're doing a context switch.  The cpu helps us by
having two dirty bits in the %fprs register, one for the lower half of
the fpu (FPRS_DL) and one for the upper half (FPRS_DU).  This register
also has a float enable bit (FPRS_FEF).

The only complex aspect of this dirty register state mechanism is that
there is no dirty bit for the %gsr and %fsr registers, if the enable
bit is set at all we have to assume that both of these register might
be dirty.

Each context of execution needs a place to store the FPU registers,
and there needs to be an event which triggers the restoration of the
saved FPU register state.  These two jobs are done by trap entry and
exit.

Trap entry allocates FPU save area slots by incrementing a counter
(current_thread_info()-fpdepth).  Trap return looks to see if any FPU
state

Re: Debian drops support for sparc

[David Miller]

From: Josip Rodin j...@entuzijast.net
Date: Thu, 30 Jul 2015 21:22:30 +0200

 On Thu, Jul 30, 2015 at 06:48:24PM +0200, Sam Ravnborg wrote:
  But I think the focus should probably be on the sheer redness of the sparc
  columns at:
  https://release.debian.org/jessie/arch_qualify.html (current release)
 
 From the link above:
 
 sparc
 
 Upstream Support
 
 According to the gcc maintainer 32bit code generation as we use it is no 
 longer supported upstream and we should aim for a switch to 64bit userland 
 anytime soon.
 
 
 Is it correct that 32bit gcc is no longer maintained?
 I have seen nothing on gcc mailaing list about this.
 
 That's from jessie, which was already released. The said note has been
 removed from the list for stretch.

The thing is, it makes no sense to go to a 64-bit only userland
distribition.

What does make sense is maybe only supporting sparc64 kernels,
but with a userland that is built 32-bit targetting v8plus.

 The problem is that numerous other issues - haven't.

It would be nice to narrow things down to the real issues.

The only major blocker I know of is the kernel FPU issue, which is
what I'm spending all of my sparc cycles on.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150730.145333.446433002495236815.da...@davemloft.net

Re: Debian drops support for sparc

[David Miller]

From: Sam Ravnborg s...@ravnborg.org
Date: Thu, 30 Jul 2015 18:48:24 +0200

 From the link above:
 
 sparc
 
 Upstream Support
 
 According to the gcc maintainer 32bit code generation as we use it is no 
 longer supported upstream and we should aim for a switch to 64bit userland 
 anytime soon.
 
 
 Is it correct that 32bit gcc is no longer maintained?
 I have seen nothing on gcc mailaing list about this.

That really can't be true.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150730.50.1222066541237598978.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

From: David Mattli d...@mattli.us
Date: Thu, 18 Jun 2015 11:51:23 -0500

 
 I've submitted a bug to Debian against src:linux requesting that they
 enable SLUB on the sparc kernel because in my testing a SLUB kernel
 never shows an error with Knight's test program and a SLAB kernel shows
 it within seconds.
 
 Enabling SLUB also fixes the nettle FTBFS.
 
 I'd appreciate if you can help by making this change to the linux
 package, adding information to the bug or by confirming whether the
 proposed workaround works for you.

There is no reason why SLUB vs. SLAB can be the real cause of
this problem.

It is definitely the FPU register handling.

I've already root caused the bug.  Specifically if I change the
memcpy in the kernel to one that doesn't use the FPU, the test
case passes just fine.

I'm working on a fix but this and next week I am travelling.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150619.040137.1840459916094858430.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

From: Aurelien Jarno aurel...@aurel32.net
Date: Wed, 10 Jun 2015 09:50:06 +0200

 So it means the userland code doesn't run the same on the various
 CPU. How are we supposed to do with static binaries?

Multiarch works perfectly fine in static binaries, just the same as it
does with dynamically linked executables.

Normally static binaries do not use PLT entries, but with multiarch
it does, so that the proper routine can be resolved at run time just
as it would via the dynamic linker.

 Disabling multiarch support improves a lot the stability on these
 machines.

By disabling it you are creating an even worse situation, for the
reasons I've discussed already, plus guess what I test when I'm
doing development?


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150610.021833.1402529650339691081.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

From: David Miller da...@davemloft.net
Date: Tue, 09 Jun 2015 13:45:37 -0700 (PDT)

 Just FYI, I commented out the usleep() in your test program and have
 been running your:
 
 seq 64 | xargs -n1 -P64 /bin/sh -c 'while ./a.out; do : ; done'
 
 test, and it's been running flawlessly for 2 hours on my T4.
 
 This is with Linus's current tree.
 
 I'll fire up my T3 later and try to reproduce it there.

Good news, I can reproduce it on my T3.

I'll try to debug this.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150610.132207.1606053216447272806.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

From: James Y Knight jykni...@google.com
Date: Wed, 10 Jun 2015 10:40:58 -0400

 But separately from the reliability issue, it seems rather
 unfortunate that the 'default' sparcv9 and sparc64 routines aren't
 actually coded to the base sparcv9 standard instruction set. It
 seems like probably the base routines should limit themselves to
 normal LDX/STX or LDDF/STDF instructions, and leave things like
 LDBLOCKF (which the docs mark CPU-specific, and deprecated, and
 potentially to be removed from future chips), for when a specific
 processor is targeted.

All sparc64 cpus support block loads and stores.

There are documents, and then there is reality.

Those instructions cannot be removed without breaking tons of code
out there and the people making changes to the sparc64 cpus are
painfully aware of this.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150610.110738.1101193887993858245.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

From: Aurelien Jarno aurel...@aurel32.net
Date: Wed, 10 Jun 2015 11:33:14 +0200

 On 2015-06-10 02:18, David Miller wrote:
  Disabling multiarch support improves a lot the stability on these
  machines.
 
 By disabling it you are creating an even worse situation, for the
 reasons I've discussed already, plus guess what I test when I'm
 doing development?
 
 How could it be worse? With the Niagara T1 memcpy routines, the machine
 is not usable, as the processes crashes regularly with a segmentation
 fault. With the default sparc v9 memcpy routines, the machine becomes
 usable.

I do not think this will happen with current kernel and glibc and
all the bug fixes I've been doing over the past few years.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150610.110250.1634796446687407507.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

From: David Miller da...@davemloft.net
Date: Tue, 09 Jun 2015 00:34:14 -0700 (PDT)

 Your test is faulty.
 
 You cannot use ASI_BLK_P loads or stores without appropriate memory
 barriers around them.
 
 The rules for when and where you need the memory barriers are
 complicated, especially if you want to incur the cost of the memory
 barrier as infrequently as possible.

FWIW, you're probably hitting the bug fixed by the following commit in
glibc:

commit 834caf06f33d79be54cff63c274fba2845513593
Author: Jose E. Marchesi jose.march...@oracle.com
Date:   Sat May 17 11:20:27 2014 -0700

Fix sparc memcpy data corruption when using niagara2 optimized routines.

* sysdeps/sparc/sparc64/multiarch/memcpy-niagara2.S: Add missing
membar to avoid block loads/stores to overlap previous stores.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150609.004641.1323317951176412858.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

Your test is faulty.

You cannot use ASI_BLK_P loads or stores without appropriate memory
barriers around them.

The rules for when and where you need the memory barriers are
complicated, especially if you want to incur the cost of the memory
barrier as infrequently as possible.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150609.003414.731851656168946673.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

From: James Y Knight jykni...@google.com
Date: Tue, 9 Jun 2015 08:07:11 -0400

 Debian glibc has multiarch support disabled (done a couple years ago to try
 to workaround the unreliability, not entirely successfully..), so it's not
 using that routine you mention. It's using
 sysdeps/sparc/sparc32/sparcv9/memcpy.S which points to
 sysdeps/sparc/sparc64/memcpy.S

I bet you stop getting corruptions if you use the appropriate optimized
routine.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150609.111649.1613386818130198452.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

From: James Y Knight jykni...@google.com
Date: Tue, 9 Jun 2015 08:13:58 -0400

 Um, but my test isn't testing what is being stored to memory at
 all. It is storing to memory and **never loading from the memory
 after**. Why would writing FROM fp registers TO memory corrupt the
 *registers* due to a missing memory barrier?

The memory barrier is necessary for two reasons, only one of them is
to handle the asynchronousness of the memory operations.

The other reason is that there are strict rules for accessing the FPU
register file around block loads and stores.

Therefore if you don't do the proper memory barriers you can get
corrupted FPU register as well as memory contents.

And complicating things even more, what you can get away with is
different on every single cpu variant.  That's why I really wish
debian didn't disable multiarch as that makes the code use the
UltraSPARC-I/II/III memcpy, which might not be %100 kosher on
Niagara-T1 and later.

Anyways, please put proper memory barriers into your testcase and
let's see if the problem still triggers.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150609.120207.248599655687564710.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

Just FYI, I commented out the usleep() in your test program and have
been running your:

seq 64 | xargs -n1 -P64 /bin/sh -c 'while ./a.out; do : ; done'

test, and it's been running flawlessly for 2 hours on my T4.

This is with Linus's current tree.

I'll fire up my T3 later and try to reproduce it there.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150609.134537.10408041080684182.da...@davemloft.net

Re: Linux Sparc FPU register corruption

[David Miller]

From: James Y Knight jykni...@google.com
Date: Tue, 9 Jun 2015 17:54:10 -0400

 What distro are you running? Maybe I should try the same thing you're using...

Debian 7.0


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150609.163754.1323765095739500628.da...@davemloft.net

Re: Problems with Debian in LDOM

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Sun, 23 Sep 2012 11:33:38 +0100

 Questions: does anyone have properly working setup with Debian (or 
 other Linux) in an LDOM? Should my particular setup (combination of 
 Solaris/LDOM/kernel version) be supported? Is there anything in the 
 LDOM setup I might need to tweak to make it work?

I haven't tested LDOM in at least 2 years, it's very likely
bugs have crept in.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120923.121440.1491137498723341084.da...@davemloft.net

Re: [PATCH] silo: Don't touch %tick_cmpr on sun4v cpus.

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Fri, 7 Sep 2012 09:33:58 +0100

 If you could give it a try to confirm that it now boots successfully 
 on your machine, it would be appreciated.

I'm 3600 miles away from the machine for the next few months so
this isn't practical, sorry.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120907.123044.721451042947158563.da...@davemloft.net

Re: [PATCH] silo: Don't touch %tick_cmpr on sun4v cpus.

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Sun, 19 Aug 2012 16:41:42 +0100

 I just uploaded a new silo package (1.4.14+git20120819-1) including 
 these fixes to unstable, and would encourage everyone to test it (it 
 should appear on the mirrors within a few hours). After a grace period 
 of 10 days we are going to arrange for its propagation to testing, 
 given that no problems are reported.

Thanks a lot Jurij.

Just FYI I also pushed a ext4 fix into the SILO tree yesterday
after I received positive feedback from a bug reporter.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120819.152445.110365253381974516.da...@davemloft.net

Re: [PATCH] silo: Don't touch %tick_cmpr on sun4v cpus.

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Sun, 19 Aug 2012 23:29:05 +0100

 On Sun, Aug 19, 2012 at 03:24:45PM -0700, David Miller wrote:
 From: Jurij Smakov ju...@wooyd.org
 Date: Sun, 19 Aug 2012 16:41:42 +0100
 
  I just uploaded a new silo package (1.4.14+git20120819-1) including 
  these fixes to unstable, and would encourage everyone to test it (it 
  should appear on the mirrors within a few hours). After a grace period 
  of 10 days we are going to arrange for its propagation to testing, 
  given that no problems are reported.
 
 Thanks a lot Jurij.
 
 Just FYI I also pushed a ext4 fix into the SILO tree yesterday
 after I received positive feedback from a bug reporter.
 
 This fix is included in the latest uploaded version as well.

Excellent.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120819.152959.477498039314404709.da...@davemloft.net

[PATCH] silo: Don't touch %tick_cmpr on sun4v cpus.

[David Miller]

This generates an illegal instruction exception.

This has a long history.  For the first sun4v port of SILO in commit
494770a17eea7192d3242051e76f4da6d838e3a1 (SILO Niagara/SUN4V
support) this code was removed entirely.

But later this was found to regress older UltraSPARC boxes, so we put
it back in commit bd708e35bdcd8e92cb7c65368f2a356982df7cd8 (Fix
Ultra10 SILO timer).  But that was wrong too.

The OBP still owns the trap table when SILO runs and it uses the
%tick_cmpr generated interrupt.  This has a bad interraction with how
we use the %tick register in SILO.

SILO first reads the %tick register and remembers this value as the
time base.

Later, we read %tick again, compute the difference, and use this to
calcualte the amount of time elapsed.

OBP's %tick_cmpr interrupt handler is doing something funky, such as
resetting %tick, which makes our timeouts never actually expire.

This issue doesn't exist on sun4v machines, and we absolutely cannot
try to touch the %tick_cmpr register as that generates an illegal
instruction trap on such cpus.

Signed-off-by: David S. Miller da...@davemloft.net
---

I just committed this into the SILO git repo.

Debian folks, you really want this propagated into your installer as
soon as possible.  All the install ISOs will crash in SILO on all
sun4v (Niagara) machines unless an explicit SILO boot target is given
on the boot command line.  I used boot cdrom install to get around
this.

It triggers any time the timer mechanism is enabled (timeout=foo is
specified in silo.conf)

 include/silo.h | 1 +
 second/main.c  | 1 +
 second/misc.c  | 4 +++-
 second/timer.c | 2 +-
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/silo.h b/include/silo.h
index fe5adcb..94d6e31 100644
--- a/include/silo.h
+++ b/include/silo.h
@@ -125,6 +125,7 @@ int strtol (const char *, char **, int);
 int decompress (char *, char *, unsigned char (*)(void), void (*)(void));
 /* main.c */
 extern enum arch architecture;
+extern int sun4v_cpu;
 /* timer.c */
 int init_timer ();
 void close_timer ();
diff --git a/second/main.c b/second/main.c
index 182b263..a45807d 100644
--- a/second/main.c
+++ b/second/main.c
@@ -64,6 +64,7 @@ enum {
 CMD_LS
 } load_cmd;
 enum arch architecture;
+int sun4v_cpu;
 static int timer_status = 0;
 static char *initrd_start;
 static int initrd_size;
diff --git a/second/misc.c b/second/misc.c
index 163738e..d6bcdb1 100644
--- a/second/misc.c
+++ b/second/misc.c
@@ -517,8 +517,10 @@ enum arch silo_get_architecture(void)
return sun4d;
 case 'e':
return sun4e;
-case 'u':
 case 'v':
+   sun4v_cpu = 1;
+   /* FALLTHRU */
+case 'u':
return sun4u;
 default:
for(i = 0; i  NUM_SUN_MACHINES; i++)
diff --git a/second/timer.c b/second/timer.c
index 51e928e..7f03996 100644
--- a/second/timer.c
+++ b/second/timer.c
@@ -156,7 +156,7 @@ static inline int sun4u_init_timer ()
 }
 if (!foundcpu || !clock_frequency)
 clock_frequency = prom_getint(prom_root_node, clock-frequency) / 100;
-if (notimer) {
+if (notimer  !sun4v_cpu) {
 sun4u_notimer = 1;
 __asm__ __volatile__ (\t
rd %%tick_cmpr, %%g1\n\t
-- 
1.7.11.2


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120815.011416.353619816610212386.da...@davemloft.net

Re: [PATCH] silo: Don't touch %tick_cmpr on sun4v cpus.

[David Miller]

From: David Miller da...@davemloft.net
Date: Wed, 15 Aug 2012 01:14:16 -0700 (PDT)

 
 This generates an illegal instruction exception.

Unfortunately, after some more testing, this needs a follow-on fix,
included below and also committed to SILO git.

Sorry for the confusion.


silo: Don't assume P1275 OBP means sun4u.

It could also mean 'sun4v'.

Code this defensively, so that if (for whatever reason)
we can't get at the 'compatible' property in the root
OBP device node we'll still default to sun4u as previous.

Signed-off-by: David S. Miller da...@davemloft.net
---
 second/misc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/second/misc.c b/second/misc.c
index d6bcdb1..d789723 100644
--- a/second/misc.c
+++ b/second/misc.c
@@ -501,7 +501,7 @@ enum arch silo_get_architecture(void)
 if ((i = prom_searchsiblings(i, MicroSPARC-IIep)) != 0) {
 return sun4p;
 }
-return sun4u;
+   buffer[4] = 'u';
 }
 i = prom_getproperty (prom_root_node, compatability, buffer, 8);
 
-- 
1.7.11.2


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120815.164331.1874494086894024620.da...@davemloft.net

Re: UltraSPARC T3 kernel patches

[David Miller]

From: David Miller da...@davemloft.net
Date: Sun, 15 Jan 2012 12:19:04 -0800 (PST)

 I won't be until mid-March before I can test install images again
 since I don't want to be physically away from the machine if something
 goes really wrong and I can't even reset or power cycle it remotely
 via the ILOM.

Ok, I just checked today's netboot sparc installer image and it
seems to be installing fine on my T3 machine.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120313.193113.216786892414675310.da...@davemloft.net

Re: UltraSPARC T3 kernel patches

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Fri, 13 Jan 2012 19:39:11 +

 Thanks for testing. I've committed a fix to Debian kernel svn repo 
 which will add mpt2sas to installer udebs with next kernel upload. 
 I'll let you know once it makes it into the daily installer images.

Thanks a lot.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120113.131345.1109329875578009756.da...@davemloft.net

Re: UltraSPARC T3 kernel patches

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Sat, 12 Nov 2011 10:39:04 +

 On Sun, Aug 14, 2011 at 07:23:28PM +0100, Jurij Smakov wrote:
 Thanks. I've built a test source package including all necessary 
 patches and a test build is running now. Ben tells me, however, that
 3.0.2 which includes all these patches and fixes is expected to come 
 out on Monday, and will be uploaded to unstable shortly after that, so 
 I don't think it makes sense to commit them as a separate patch set 
 anymore.
 
 It took a while, but the daily installer images [0] now include a 
 kernel which should support Niagara T3. David, if you could try it out 
 and report your findings, it would be greatly appreciated.
 
 I would like to use this opportunity to thank Ben and the rest of the 
 kernel team for their efforts on making installer udebs built directly 
 from Debian kernel package source. That means that in the future new 
 kernels will be available in the daily installer builds pretty much 
 immediately after the new Debian kernel package is uploaded.
 
 [0] http://www.debian.org/devel/debian-installer/

These won't install on my T3 because of a lack of the mpt2sas driver
which is needed to see the onboard disks.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120111.140341.1997882996980032603.da...@davemloft.net

Re: UltraSPARC T3 kernel patches

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Sat, 12 Nov 2011 10:39:04 +

 It took a while, but the daily installer images [0] now include a 
 kernel which should support Niagara T3. David, if you could try it out 
 and report your findings, it would be greatly appreciated.
 
 I would like to use this opportunity to thank Ben and the rest of the 
 kernel team for their efforts on making installer udebs built directly 
 from Debian kernel package source. That means that in the future new 
 kernels will be available in the daily installer builds pretty much 
 immediately after the new Debian kernel package is uploaded.

Thanks for taking care of this.  Don't interpret my inability to test this
at the moment as a lack of appreciation :-)


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2029.145012.452988520.da...@davemloft.net

Re: UltraSPARC T3 kernel patches

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Sat, 12 Nov 2011 10:39:04 +

 It took a while, but the daily installer images [0] now include a 
 kernel which should support Niagara T3. David, if you could try it out 
 and report your findings, it would be greatly appreciated.
 
 I would like to use this opportunity to thank Ben and the rest of the 
 kernel team for their efforts on making installer udebs built directly 
 from Debian kernel package source. That means that in the future new 
 kernels will be available in the daily installer builds pretty much 
 immediately after the new Debian kernel package is uploaded.
 
 [0] http://www.debian.org/devel/debian-installer/

I'll take a look at this as soon as I can.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2017.160320.2279482687780639705.da...@davemloft.net

[PATCH] Serious glibc sparc rlimits bug

[David Miller]

Unfortunately, the sparc32 definition of the 64-bit RLIM_INFINITY
value is wrong, and it's been wrong for a while.

This causes serious problems, the worst of which is that no 64-bit
pthread program executing as a child of 'make' can succeed.

GLIBC's pthread_create() uses the current RLIMIT_STACK value as a hint
for sizing thread stacks.  It handles RLIM_INFINITY specially instead
of trying to allocate an enormous stack.

But if RLIM_INFINITY is wrong... right, nothing works.

How this happens is that libpam corrupts the kernel default rlimits
when it creates a login session, because even if you have no explicit
settings in /etc/security/limits.conf it still reads every rlimit
then sets it right back to the same value.  It even has some pre-cooked
defaults, and the default for RLIMIT_STACK is cur=8MB max=RLIM_INFINITY

So if RLIM_INFINITY is wrong (for 32-bit binaries it's too small), the
values will all get truncated down to this incorrect RLIM_INFINITY
value.

Next, make sets the current RLIMIT_STACK 'cur' value to the maximum,
so now the current RLIMIT_STACK has this wrong RLIM_INFINITY value
too.

Then 64-bit glibc doesn't recognize this value as RLIM_INFINITY during
pthread_create() and it tries to allocate a thread stack of size
0x8000 bytes.  This, of course, fails.

A bunch of binaries are going to need to be rebuilt because of this issue
once the glibc build goes through, I would prioritize libpam0g, make,
and emacs23.

I'll be committing this soon to glibc GIT.  I tested this by doing a
glibc deb rebuild with this patch applied, installing, then rebuilding
libpam0g and make.

2011-08-14  David S. Miller  da...@davemloft.net

* sysdeps/unix/sysv/linux/sparc/bits/resource.h (RLIM_INFINITY,
RLIM64_INFINITY): Fix 64-bit values for 32-bit sparc.

diff --git a/sysdeps/unix/sysv/linux/sparc/bits/resource.h 
b/sysdeps/unix/sysv/linux/sparc/bits/resource.h
index 04d33e4..5c00b8f 100644
--- a/sysdeps/unix/sysv/linux/sparc/bits/resource.h
+++ b/sysdeps/unix/sysv/linux/sparc/bits/resource.h
@@ -130,11 +130,11 @@ enum __rlimit_resource
 #ifndef __USE_FILE_OFFSET64
 # define RLIM_INFINITY ((long int)(~0UL  1))
 #else
-# define RLIM_INFINITY 0x7fffLL
+# define RLIM_INFINITY 0xLL
 #endif
 
 #ifdef __USE_LARGEFILE64
-# define RLIM64_INFINITY 0x7fffLL
+# define RLIM64_INFINITY 0xLL
 #endif
 
 #endif


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110814.002918.773510966891265864.da...@davemloft.net

UltraSPARC T3 kernel patches

[David Miller]

Jurij, if I made a set of patches against the current wheezy kernel
for UltraSPARC T3 support, would you be able to make sure they get
submitted for inclusion?

Thanks!


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110805.043637.657515825691740082.da...@davemloft.net

Re: Please add IGB to installer kernel modules

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Wed, 27 Jul 2011 13:11:38 +0100

 On Tue, Jul 26, 2011 at 03:43:09PM -0700, David Miller wrote:
 
 Niagara-T3 systems use Intel IGB 82576 network devices as the on-board
 ethernet.
 
 Therefore the IGB driver is necessary for network installs.
 
 Please turn on CONFIG_IGB for the debian installer kernel on sparc.
 
 Thank you.
 
 These drivers (igb/igbvf) are already enabled in the 3.0.0-1 kernel 
 package, recently uploaded to unstable.   I'll make necessary installer 
 changes next week, once I'm back from vacation.

Please also double check that CONFIG_NIU is in there for the netboot
images as well.

Thanks a lot.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110727.164306.1157286893461349743.da...@redhat.com

Please add IGB to installer kernel modules

[David Miller]

Niagara-T3 systems use Intel IGB 82576 network devices as the on-board
ethernet.

Therefore the IGB driver is necessary for network installs.

Please turn on CONFIG_IGB for the debian installer kernel on sparc.

Thank you.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110726.154309.2266214350085651742.da...@redhat.com

apt sig 10

[David Miller]

Just FYI, this isn't showing up yet in the bug entry but this
is the problem and the included patch fixes it.
---BeginMessage---

The problem is how sha1.cc codes the SHA1 transform, it illegally
casts the on-stack workspace buffer to a type requiring more
alignment than 'workspace' is actually declared to have.

This only shows up recently because gcc-4.6 now does a really
aggressive optimization where it gets rid of the workspace
buffer entirely and just accesses 'buffer' directly, and assumes
it has the necessary alignment for 32-bit loads (which it
doesn't).

This patch fixes the bug:

--- apt-pkg/contrib/sha1.cc~2011-06-17 03:10:20.0 -0700
+++ apt-pkg/contrib/sha1.cc 2011-07-25 15:16:26.774548017 -0700
@@ -74,10 +74,9 @@ static void SHA1Transform(uint32_t state
   uint32_t l[16];
}
CHAR64LONG16;
-   CHAR64LONG16 *block;
+   CHAR64LONG16 workspace, *block;
 
-   uint8_t workspace[64];
-   block = (CHAR64LONG16 *)workspace;
+   block = workspace;
memcpy(block,buffer,sizeof(workspace));
 
/* Copy context-state[] to working vars */
---End Message---

Re: console on Niagara in 6.0.1

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Thu, 26 May 2011 00:27:49 +0100

 If you could confirm that the issue is fixed, it would be appreciated.
 
 [0] 
 http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/sparc/iso-cd/debian-testing-sparc-netinst.iso

Just wanted to report that everything works great now. :-)


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110607.25.776444641780564452.da...@davemloft.net

Re: console on Niagara in 6.0.1

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Thu, 26 May 2011 00:27:49 +0100

 On Tue, Mar 22, 2011 at 06:14:03PM -0700, David Miller wrote:
 From: Jurij Smakov ju...@wooyd.org
 Date: Tue, 22 Mar 2011 23:04:02 +
 
  If you could compile and run it on your machine, it would be very 
  interesting to see whether you'll get /dev/ttyS0 or /dev/ttyHV0 (on my 
  machine sunsab driver is used, and it's using 'ttyS' as prefix for 
  both). At least, this potentially allows us to do a proper fix in the
  next release.
 
 The test program correctly gives /dev/ttyS0 on my machine.
 
 By now various fixes for this issue have made it into testing and 
 unstable, so I believe that the daily Debian installer builds (for 
 example, [0]) should work correctly on your machine and add a getty
 line for serial console in /etc/inittab.
 
 If you could confirm that the issue is fixed, it would be appreciated.
 
 [0] 
 http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/sparc/iso-cd/debian-testing-sparc-netinst.iso

Thanks a lot Jurij, I will test this next week for sure.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110525.214921.387990292204243711.da...@davemloft.net

Re: Warning when mounting btrfs partition, kernel unaligned access

[David Miller]

From: David Sterba d...@jikos.cz
Date: Wed, 13 Apr 2011 11:40:37 +0200

 On Wed, Apr 13, 2011 at 01:03:56AM +0200, Sébastien Bernard wrote:
 Then, after writing on the disk, I got a lot of warning:
 [  822.515875] Kernel unaligned access at TPC[103c2204]
 
 I peeked a look at the btrf_csum_final and here's the function :
 void btrfs_csum_final(u32 crc, char *result)
 {
 *(__le32 *)result = ~cpu_to_le32(crc);
 }
 
 FYI, this has been fixed and is already merged into Linus' tree. Commit
 7e75bf3ff3a716d7b21d8fb43bf823115801c1e9.

Might I suggest adding a BUG_ON() validation of the alignment or
similar here?

You can make the test really cheap, and this way no matter what kind
of systems the btrfs folks do their testing on this kind of regression
will be spotted fast.


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110413.104831.189703153.da...@davemloft.net

Re: console on Niagara in 6.0.1

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Tue, 22 Mar 2011 09:34:32 +

 You may end up with console set to /dev/console if detection logic 
 failed and a fall-through value has been used here:
 
 http://git.debian.org/?p=d-i/rootskel.git;a=blob_plain;f=src/sbin/reopen-console-linux;hb=HEAD
 
 Can you post dmesg output from this machine, booted via a serial 
 console?

Device probing via dmesg parsing, wonderful... :-/ This really isn't
going to ever work reliably.

So this code is going to see ttyHV0 get enabled:

[0.00] console [tty0] enabled, bootconsole disabled
[102839.004039] console [ttyHV0] enabled

But that doesn't tell you the serial device name under /dev

Not even close.

The device for console named ttyHV0 on this machine happens to be
/dev/ttyS0, but it could have been /dev/ttyS1, or /dev/ttyS2, or
similar depending upon the order in which the various serial drivers
probed.

Console name to serial device name is not a 1 to 1 relationship.
They can be, and are often, completely different.

The console name string is used for matching for kernel command
line directives, but that's it.  You cannot use it to determine
the /dev/* name for the underlying device.

As a result you now will have to add logic to this script so that it
knows that this ttyHV? thing allocates from the ttyS? space, and
then you will have to add code which figures out which index in the
ttyS? space it got.

And there are a bunch of other serial device drivers which have the
same issue.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110322.025805.57471409.da...@davemloft.net

Re: console on Niagara in 6.0.1

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Tue, 22 Mar 2011 23:04:02 +

 If you could compile and run it on your machine, it would be very 
 interesting to see whether you'll get /dev/ttyS0 or /dev/ttyHV0 (on my 
 machine sunsab driver is used, and it's using 'ttyS' as prefix for 
 both). At least, this potentially allows us to do a proper fix in the
 next release.

The test program correctly gives /dev/ttyS0 on my machine.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110322.181403.39196928.da...@davemloft.net

NR_CPUS in 6.0.1 SMP images

[David Miller]

Please increase this value to 256.

It is set to 32, which makes 96 of the cpus in my Niagara2+ system
unusable.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110320.230008.104061816.da...@davemloft.net

console on Niagara in 6.0.1

[David Miller]

I problem I've reported repeatedly in the past, is still present in
6.0.1

Namely that the Niagara console does not get setup properly.

So if you don't select SSHD to be installed or similar, the system
cannot be logged into at the first boot since no login gettys get
spawned on the correct device.

Simply making sure the T0 line in /etc/inittab gets uncommented
seems to be enough.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110320.230332.189694697.da...@davemloft.net

Re: install net drivers

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Mon, 21 Mar 2011 09:26:10 +

 On Sun, Mar 20, 2011 at 10:05:11PM -0700, David Miller wrote:
 
 Please add CONFIG_NIU to the network drivers provided on the network
 install image.
 
 Installations on several Niagara variants is not possible without
 this.
 
 This was reported as http://bugs.debian.org/608516, and is fixed in 
 6.0.1 images (I've just verified that netinst image contains
 
 /lib/modules/2.6.32-5-sparc64/kernel/drivers/net/niu.ko
 
 in the nic-modules-2.6.32-5-sparc64-di_1.64+squeeze1_sparc.udeb).

That's great.

I must have had a 6.0 image.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321.022908.48498669.da...@davemloft.net

Re: console on Niagara in 6.0.1

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Mon, 21 Mar 2011 11:51:30 +

 I guess that this might be as simple as console having an unexpected 
 name.

Well, the console is named /dev/ttyS0 and I don't see any case in the
middle switch statement of that script which would accept ttyS? for
$console at all.

It only matches tty[A-Z], duart, etc.

/dev/ttyS? is also what the serial console would be named in other
sparc cases too.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321.051324.260084582.da...@davemloft.net

Re: console on Niagara in 6.0.1

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Mon, 21 Mar 2011 12:21:55 +

 It matches tty[A-Zu]*, so ttyS0 should work (and it does on my 
 machine). Next step would be to check that $console actually gets set 
 to ttyS0 as expected.

I bet it sees ttyHV since that is the value of the name attribute
we use for the struct console object this driver creates.

I'll do some testing later tonight.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321.181509.229749163.da...@davemloft.net

Re: console on Niagara in 6.0.1

[David Miller]

From: Jurij Smakov ju...@wooyd.org
Date: Mon, 21 Mar 2011 11:51:30 +

 4. Run '/bin/sh -x /usr/lib/finish-install.d/90console' and post the 
 output somewhere.

This doesn't log anything because executing 90console actualy spawns
debconf/frontend to execute the script.

So I inspected things by hand:

1) readlink on /proc/$(pidof debian-installer)/fd/0 evaluates to /dev/console
2) mapdevfs returns /dev/console

This is hitting the Pass unknown devices without changes path
in debian-installer/devfs.c:di_system_devfs_map_fron

This code seems to assume that the installer will have the underlying
device openned, but instead it is /dev/console which it will have.

Code needs to be added, somewhere, to translate /dev/console to
whatever the underlying device is.  Or to detect the serial console
in some other manner.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321.203119.02274343.da...@davemloft.net

install net drivers

[David Miller]

Please add CONFIG_NIU to the network drivers provided on the network
install image.

Installations on several Niagara variants is not possible without
this.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110320.220511.226770655.da...@davemloft.net

Re: XVR-600 console not working with e3d

[David Miller]

From: Josip Rodin j...@entuzijast.net
Date: Wed, 18 Aug 2010 11:32:25 +0200

 On Tue, Aug 17, 2010 at 02:48:43PM -0700, David Miller wrote:
 From: Josip Rodin j...@entuzijast.net
 Date: Tue, 17 Aug 2010 16:33:22 +0200
 
  OK, good. So our kernel still has something missing... I'm attaching the
  config in case anyone can spot anything obvious.
 
 Config looks fine, the XVR500 driver will driver those chips.
 
 Probably missing a patch to the driver or similar.
 
 What's the revision of the file you built into xvr600_test.img,
 so that I can compare?

I have no idea, it was half a year ago.

Just compare drivers/video/sunxvr500.c in current mainline with
whatever is in your tree.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100818.131150.71107545.da...@davemloft.net

Re: XVR-600 console not working with e3d

[David Miller]

From: Josip Rodin j...@entuzijast.net
Date: Wed, 18 Aug 2010 23:26:22 +0200

 The substantial difference is bdd32ce95f79fb5cc964cd789d7ae4500bba7c6f.
 If so, can you send it to sta...@kernel.org please?

Will do.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100818.14.102569147.da...@davemloft.net

Re: XVR-600 console not working with e3d

[David Miller]

From: Josip Rodin j...@entuzijast.net
Date: Tue, 17 Aug 2010 16:33:22 +0200

 OK, good. So our kernel still has something missing... I'm attaching the
 config in case anyone can spot anything obvious.

Config looks fine, the XVR500 driver will driver those chips.

Probably missing a patch to the driver or similar.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100817.144843.104046744.da...@davemloft.net

Re: Debian Sparc 5.4 on Sun blade 2500

[David Miller]

From: David Miller da...@davemloft.net
Date: Tue, 16 Mar 2010 21:34:42 -0700 (PDT)

 From: Paul Cao p...@ashland.edu
 Date: Tue, 16 Mar 2010 19:21:53 -0400
 
 I have download the iso image. I will install it tomorrow and post the
 results here.
 
 Meanwhile I tried the DVD myself and it worked with my
 XVR-500.

With the Lenny mini.iso my screen came up just fine on a SunBlade-2500
with an XVR-600 as the console.

There is something not right on your end, because even with what
should be the same hardware I cannot reproduce your problem.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323.115551.56364534.da...@davemloft.net

Re: Debian Sparc 5.4 on Sun blade 2500

[David Miller]

From: Frans van Berckel fberc...@xs4all.nl
Date: Tue, 16 Mar 2010 20:34:50 +0100

 If I am well your card isn't supported yet. Searching the attachment
 it's a XVR 600 true. 
 
 Maybe we can get the XVR 500 driver to do the XVR 600 as well. 
 
 Forwarding this e-mail to the kernel Sparc list. I know kernel developer
 David was looking for the XVR 600 information, to check this out.

The XVR-500 driver supports his XVR-600's PCI ID, 3d3d:07a2


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100316.124042.144387705.da...@davemloft.net

Re: Debian Sparc 5.4 on Sun blade 2500

[David Miller]

From: Paul Cao p...@ashland.edu
Date: Tue, 16 Mar 2010 18:57:45 -0400

 If XVR-500 supports XVR-600 and XVR-500 is enabled in lenny, how can
 the display card not working properly? Are there any other reasons why
 display is garbled?

I have no idea.

I'm travelling this week to NYC where I have an sb2500 with an XVR-600
that will be waiting for me to install, and I'll try to diagnose the
problem.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100316.155902.66272153.da...@davemloft.net

Re: Debian Sparc 5.4 on Sun blade 2500

[David Miller]

BTW just to check, how recent is your install image?
Can you point me to a copy of it?


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100316.155957.139546153.da...@davemloft.net

Re: Debian Sparc 5.4 on Sun blade 2500

[David Miller]

From: Paul Cao p...@ashland.edu
Date: Tue, 16 Mar 2010 19:04:55 -0400

 Thanks so much for helping. The image is debian 5.04 DVD iso from
 http://cdimage.debian.org/debian-cd/5.0.4/sparc/iso-dvd/

Hmmm, can you try the mini.iso instead?  That's what I used.

I put a copy up at:

http://vger.kernel.org/~davem/lenny-mini.iso

so we can make sure we're testing exactly the same thing.

Thanks!


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100316.160753.73638691.da...@davemloft.net

Re: Debian Sparc 5.4 on Sun blade 2500

[David Miller]

From: Paul Cao p...@ashland.edu
Date: Tue, 16 Mar 2010 19:13:36 -0400

 I can't have access to the image on the website. Privilege problem.

Sorry, I've fixed that, please try again.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100316.161807.183711744.da...@davemloft.net

Re: Debian Sparc 5.4 on Sun blade 2500

[David Miller]

From: Paul Cao p...@ashland.edu
Date: Tue, 16 Mar 2010 19:21:53 -0400

 I have download the iso image. I will install it tomorrow and post the
 results here.

Meanwhile I tried the DVD myself and it worked with my
XVR-500.

I looked at the kernel image on the DVD and it has all the
necessary PCI device IDs to match your card.

So something isn't working right.

I've built a test kernel for you to netboot that should
provide some more bootup messages than you're getting
now.  Please find it at:

http://vger.kernel.org/~davem/xvr600_test.img

When netbooted it should print something like:

e3d: Found device at /pci.

when it detects your graphics card.

And then it should say something like:

fbcon: e3d (fb0) is primary device
Console: switching to colour frame buffer device 210x65

If it prints all of that and you still don't get a console
then the framebuffer is mapped on XVR-600/XVR-1200 chips
different than it is on XVR-500 chips and I'll have to
figure that out.  It could take a week or so to fix this
in that case.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100316.213442.69988179.da...@davemloft.net

T5240 onboard ethernet detection...

[David Miller]

This machine uses NIU as the onboard ethernet, but for
whatever reason the debian installer couldn't find it
in the stable install images.

The debian kernel does have the driver built into it, so it's
something to do with detection by device IDs or whatever I suppose.

NIU can appear on sparc64 in two forms.  Either as a PCI device, or as
an OpenFirmware device.

The driver module does have the proper device recognition tags, one
for PCI:

static struct pci_device_id niu_pci_tbl[] = {
{PCI_DEVICE(PCI_VENDOR_ID_SUN, 0xabcd)},
{}
};

MODULE_DEVICE_TABLE(pci, niu_pci_tbl);

and one for OpenFirmware:

static const struct of_device_id niu_match[] = {
{
.name = network,
.compatible = SUNW,niusl,
},
{},
};
MODULE_DEVICE_TABLE(of, niu_match);

The module did load properly when I booted into the installation.

This machine has the PCI variant of the device.

Perhaps the presence of two different kinds of device tables in the
same kernel module is confusing the logic the installer uses to detect
the ethernet device during installation?


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Sparc release requalification

[David Miller]

From: Josip Rodin j...@entuzijast.net
Date: Mon, 23 Nov 2009 23:40:28 +0100

 http://www.backports.org/debian/pool/main/l/linux-2.6/linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb
 
 To extract, use:
 
   dpkg-deb -x linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb 
 newdir
 
 And then you have newdir/boot/vmlinuz-2.6.30-bpo.2-sparc64-smp etc

I've tried everything to reproduce this.

I've tried building 2.6.31.6 -stable from Josip's config using
Debian stable's compiler (gcc-4.3.2)

I've also tried the image in that dpkg.

All of them boot fine on my two similarly configured UltraSPARC-IIIi
systems.

I'll try to think some more about this, but meanwhile if you have some
means by which to make your V240 available to me online to do somet
debugging that would be really useful.

You can see from Hermann's providing access to his V480 to me once I
have access I tend to fix the bug within a day or two :-)


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Sparc release requalification

[David Miller]

From: Hermann Lauer hermann.la...@iwr.uni-heidelberg.de
Date: Wed, 25 Nov 2009 09:36:33 +0100

 On Tue, Nov 24, 2009 at 10:40:47PM -0800, David Miller wrote:
  OK. Yours has gcc 4.2.4, and our ones have gcc 4.3.2 (that we shipped
  as stable :)
  
  I also just tried a newer packaged image, and it has the same issue.
 
 I just tossed lenny onto my main build system and I will try to
 reproduce this and track it down.
 
 FYI:
 lenny uses gcc 4.1.3 for their normal build at least on amd64 and sparc 
 systems:
 
  Linux version 2.6.26-2-sparc64-smp (Debian 2.6.26-19lenny2) 
 (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 
 4.1.2-25)) #1 SMP Thu Nov 5 03:34:29 UTC 2009

I'm confused now :-)  So does gcc-4.1.3 produce the bad kernels or does
gcc-4.3.2?

I built Linus's current tree under Lenny and that booted up perfectly
on my Niagara2 box.

Also, please increase CONFIG_NR_CPUS to 256 in your SMP builds on sparc64
in Debian.  I'm missing most of my cpus with the Debian built kernels :-)

Probably I've mentioned this before :-)


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org