Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)

[Matt Turner]

On Mon, Apr 23, 2018 at 10:34 AM Ivan Kokshaysky
 wrote:
>
> On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
> > On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
> >  wrote:
> > > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
> > >> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
> > >> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas  
> > >> > wrote:
> > >> > > Hi Matt,
> > >> > >
> > >> > > First of all, sorry about breaking Nautilus, and thanks very much for
> > >> > > tracking it down to this commit.
> > >> >
> > >> > It's a particularly weird case, as far as I've been able to discern :)
> > >> >
> > >> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> > >> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> > >> > >> address limits in resource allocation) broke Alpha systems using
> > >> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> > >> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps 
> > >> > >> PCI
> > >> > >> into the upper addresses just below 4GB.
> > >> > >>
> > >> > >> I can get a working kernel by ifdef'ing out the code in
> > >> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> > >> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> > >> > >> kernels.
> > >> > >>
> > >> > >> How can we get Nautilus working again?
> > >> > >
> > >> > > Can you collect a complete dmesg log, ideally both before and after
> > >> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
> > >> > > erroneously assign space for something above 4GB.  But if we know the
> > >> > > correct host bridge apertures, we shouldn't assign space outside 
> > >> > > them,
> > >> > > regardless of the PCI bus address size.
> > >> >
> > >> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
> > >> > the last *working* commit. My apologies. The next commit is
> > >> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
> > >> > breaks Nautilus I've confirmed.
> > >> >
> > >> > Please find attached dmesgs from those two commits, from the commit
> > >> > immediately before them, and another from 4.17-rc1 with my hack of #if
> > >> > 0'ing out the pci_bus_alloc_from_region(..., _high) code.
> > >> >
> > >> > Thanks for having a look!
> > >>
> > >> We're telling the PCI core that the host bridge MMIO aperture is the
> > >> entire 64-bit address space, so when we assign BARs, some of them end
> > >> up above 4GB:
> > >>
> > >>   pci_bus :00: root bus resource [mem 0x-0x]
> > >>   pci :00:09.0: BAR 0: assigned [mem 0x1-0x1 64bit]
> > >>
> > >> But it sounds like the MMIO aperture really ends at 0x, so
> > >> that's not going to work.
> > >
> > > Correct... This would do as a quick fix, I think:
> > >
> > > diff --git a/arch/alpha/kernel/sys_nautilus.c 
> > > b/arch/alpha/kernel/sys_nautilus.c
> > > index ff4f54b..477ba65 100644
> > > --- a/arch/alpha/kernel/sys_nautilus.c
> > > +++ b/arch/alpha/kernel/sys_nautilus.c
> > > @@ -193,6 +193,8 @@ static struct resource irongate_io = {
> > >  };
> > >  static struct resource irongate_mem = {
> > > .name   = "Irongate PCI MEM",
> > > +   .start  = 0,
> > > +   .end= 0x,
> > > .flags  = IORESOURCE_MEM,
> > >  };
> > >  static struct resource busn_resource = {
> > > @@ -218,7 +220,7 @@ nautilus_init_pci(void)
> > > return;
> > >
> > > pci_add_resource(>windows, _resource);
> > > -   pci_add_resource(>windows, _resource);
> > > +   pci_add_resource(>windows, _mem);
> > > pci_add_resource(>windows, _resource);
> > > bridge->dev.parent = NULL;
> > > bridge->sysdata = hose;
> >
> > Thanks. But w

Re: [PATCH] x86: Deprecate a.out support

[Matt Turner]

On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann  wrote:
>
> On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård  wrote:
> > Linus Torvalds  writes:
> > > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård  wrote:
> > >>
> > >> The latest version I have is 5.1, and that uses ECOFF.
> > >
> > > ECOFF _is_ a.out as far as Linux is concerned.
> > >
> > > So Linux basically treats ECOFF as "regular a.out with just some
> > > header extensions".
> > >
> > > We don't have any specific support for ECOFF.
> > >
> > > I _think_. Again, it's been years and years.
> >
> > Right, which is why killing a.out entirely would have the unfortunate
> > effect of also removing the OSF/1 compatibility on Alpha.
> >
> > If we are to support Alpha as an architecture at all, it makes sense to
> > support the things people actually use it for.
> >
> > Now, personally I can live without it.  I just don't like to see
> > features removed without due consideration.
>
> The main historic use case I've heard of was running Netscape
> Navigator on Alpha Linux, before there was an open source version.
> Doing this today to connect to the open internet is probably
> a bit pointless, but there may be other use cases.

The best use case I know of is to run their C compiler. Måns sent
patches in fact to make it work.

There is a Linux version of the same compiler but I have a vague
memory that it's broken in various ways that the Tru64 version is not.

Re: [PATCH] x86: Deprecate a.out support

[Matt Turner]

On Mon, Mar 11, 2019 at 12:47 PM Måns Rullgård  wrote:
>
> Linus Torvalds  writes:
>
> > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård  wrote:
> >>
> >> The latest version I have is 5.1, and that uses ECOFF.
> >
> > ECOFF _is_ a.out as far as Linux is concerned.
> >
> > So Linux basically treats ECOFF as "regular a.out with just some
> > header extensions".
> >
> > We don't have any specific support for ECOFF.
> >
> > I _think_. Again, it's been years and years.
>
> Right, which is why killing a.out entirely would have the unfortunate
> effect of also removing the OSF/1 compatibility on Alpha.
>
> If we are to support Alpha as an architecture at all, it makes sense to
> support the things people actually use it for.

I agree. I was not aware that a.out was effectively the same as ECOFF.

Re: [PATCH] x86: Deprecate a.out support

[Matt Turner]

On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård  wrote:
>
> Linus Torvalds  writes:
>
> > On Sun, Mar 10, 2019 at 2:37 PM Matt Turner  wrote:
> >>
> >> I'm not aware of a reason to keep a.out support on alpha.
> >
> > Hmm. I was looking at removing a.out support entirely, but it's
> > actually fairly incestuous on alpha.
> >
> > For example, arch/alpha/boot/tools/objstrip.c very much has some a.out
> > support in it. Maybe it can just be removed entirely.
> >
> > There's also an a.out.h include in arch/alpha/kernel/binfmt_loader.c.
> >
> > Finally, note that CONFIG_OSF4_COMPAT also no longer makes sense
> > without a.out support.
>
> Anyone running an Alpha machine likely also has some old OSF/1 binaries
> they may wish to use.  It would be a shame to remove this feature, IMO.

Tru64 5.1 uses ECOFF binaries, I believe. Do you know when OSF/1 /
Digital UNIX / Tru64 switched from a.out to ECOFF?

Re: [PATCH] x86: Deprecate a.out support

[Matt Turner]

On Tue, Mar 5, 2019 at 11:04 AM Borislav Petkov  wrote:
>
> On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote:
> > I guess you could Cc arch maintainers with the a.out-core.h removal
> > patch to see if anyone screams.
>
> And they're like two for which we need confirmation:
>
> $ git ls-files | grep a.out-core.h
> arch/alpha/include/asm/a.out-core.h
> arch/m68k/include/asm/a.out-core.h
> arch/um/include/asm/a.out-core.h
> arch/x86/include/asm/a.out-core.h
>
> um and x86 are clear.
>
> Adding alpha and m68k MLs to Cc.

I'm not aware of a reason to keep a.out support on alpha.

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull a few changes for alpha, including a build fix, a fix for the Eiger
platform, and a fix for a tricky bug uncovered by the strace test suite that
has existed since at least 1997 (v2.1.32)!

Thanks,
Matt


The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9:

 Linux 5.0-rc6 (2019-02-10 14:42:20 -0800)

are available in the Git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus

for you to fetch changes up to 491af60ffb848b59e82f7c9145833222e0bf27a5:

 alpha: fix page fault handling for r16-r18 targets (2019-02-10 20:42:23 -0800)


Bob Tracy (1):
 tools uapi: fix Alpha support

Meelis Roos (1):
 alpha: Fix Eiger NR_IRQS to 128

Sergei Trofimovich (1):
 alpha: fix page fault handling for r16-r18 targets

arch/alpha/include/asm/irq.h | 6 +++---
arch/alpha/mm/fault.c| 2 +-
tools/include/uapi/asm/bitsperlong.h | 2 ++
3 files changed, 6 insertions(+), 4 deletions(-)


signature.asc
Description: PGP signature

Re: PWS 433au (Miata) recovery update

[Matt Turner]

On Wed, Feb 6, 2019 at 12:04 AM Meelis Roos  wrote:
>
> I share my experience of fresh install of and embedded SBC Alpha
> (Eiger with EV6 500 MHz).
>
> Only an ancient Debian installer worked for me. The reason appeared to
> be broken IRQ numbers for Eiger.
>
> So I used 2 disks. I first installed the ancient Debian on disk 1.
> That worked.
>
> Next, I used that to bootstrap Gentoo on second disk, with ext3 as was
> supported by Debian tooling.
>
> Then I debugged the new kernel and fixed the IRQ problem. Now I had a
> recent kernel. I sent the patch https://lkml.org/lkml/2018/10/12/379 to
> linux-alpha but it seems to have been ignored - PING!

Sorry, not sure how I missed it. I'll include it in my pull request
this weekend (with Maciej's R-b).

Thanks!

Re: [PATCH v2] alpha: fix page fault handling for r16-r18 targets

[Matt Turner]

On Mon, Dec 31, 2018 at 3:54 AM Sergei Trofimovich  wrote:
>
> Fix page fault handling code to fixup r16-r18 registers.
> Before the patch code had off-by-two registers bug.
> This bug caused overwriting of ps,pc,gp registers instead
> of fixing intended r16,r17,r18 (see `struct pt_regs`).
>
> More details:
>
> Initially Dmitry noticed a kernel bug as a failure
> on strace test suite. Test passes unmapped userspace
> pointer to io_submit:
>
> ```c
> #include 
> #include 
> #include 
> #include 
> int main(void)
> {
> unsigned long ctx = 0;
> if (syscall(__NR_io_setup, 1, ))
> err(1, "io_setup");
> const size_t page_size = sysconf(_SC_PAGESIZE);
> const size_t size = page_size * 2;
> void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
>  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> if (MAP_FAILED == ptr)
> err(1, "mmap(%zu)", size);
> if (munmap(ptr, size))
> err(1, "munmap");
> syscall(__NR_io_submit, ctx, 1, ptr + page_size);
> syscall(__NR_io_destroy, ctx);
> return 0;
> }
> ```
>
> Running this test causes kernel to crash when handling page fault:
>
> ```
> Unable to handle kernel paging request at virtual address 9468
> CPU 3
> aio(26027): Oops 0
> pc = []  ra = []  ps = Not 
> tainted
> pc is at sys_io_submit+0x108/0x200
> ra is at sys_io_submit+0x6c/0x200
> v0 = fc00c58e6300  t0 = fff2  t1 = 0225e000
> t2 = fc01f159fef8  t3 = fc0001009640  t4 = fce0f6e0
> t5 = 020001002e9e  t6 = 4c41564e49452031  t7 = fc01f159c000
> s0 = 0002  s1 = 0225e000  s2 = 
> s3 =   s4 =   s5 = fff2
> s6 = fc00c58e6300
> a0 = fc00c58e6300  a1 =   a2 = 0225e000
> a3 = 021ac260  a4 = 021ac1e8  a5 = 0001
> t8 = 0008  t9 = 00011f8bce30  t10= 021ac440
> t11=   pv = fc6fd320  at = 
> gp =   sp = 265fd174
> Disabling lock debugging due to kernel taint
> Trace:
> [] entSys+0xa4/0xc0
> ```
>
> Here `gp` has invalid value. `gp is s overwritten by a fixup for the
> following page fault handler in `io_submit` syscall handler:
>
> ```
> __se_sys_io_submit
> ...
> ldq a1,0(t1)
> bne t0,4280 <__se_sys_io_submit+0x180>
> ```
>
> After a page fault `t0` should contain -EFALUT and `a1` is 0.
> Instead `gp` was overwritten in place of `a1`.
>
> This happens due to a off-by-two bug in `dpf_reg()` for `r16-r18`
> (aka `a0-a2`).
>
> I think the bug went unnoticed for a long time as `gp` is one
> of scratch registers. Any kernel function call would re-calculate `gp`.
>
> Dmitry tracked down the bug origin back to 2.1.32 kernel version
> where trap_a{0,1,2} fields were inserted into struct pt_regs.
> And even before that `dpf_reg()` contained off-by-one error.

Wow, nice work.

I've vacuumed the patch up and will include it in my next pull req.

Re: [PATCH] 4.18-rc7 on alpha: bitsperlong issue

[Matt Turner]

On Mon, Jan 21, 2019 at 1:42 PM Bob Tracy  wrote:
>
> Apologies for what is essentially a repost with a proper subject header
> in the sense of trying to get the attention of people who collect/approve
> patches for submission upstream.  See my posting from earlier today
> (followup: [FTBFS] kernel 4.18-rc7 bitsperlong.h issue on alpha) for the
> back story.  As mentioned there, this patch applies cleanly to at least
> all mainline kernel source trees >= version 4.18.
>
> Further apologies for including the patch as an attachment, but I don't
> trust my mailer not to impose unintended formatting.

Thanks Bob. I've vacuumed the patch up and will include it in a pull req soon.

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull a few small changes for alpha as well as the new system call table
generation support from Firoz Khan.

Thanks,
Matt


The following changes since commit 9097a058d49e049925d8da72db07fffcee24efa0:

 Merge branch 'i2c/for-current' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux (2018-12-20 14:49:56 
-0800)

are available in the Git repository at:

 https://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus

for you to fetch changes up to 1c3243f61fa7daea78de9866af2625f559ebf456:

 alpha: Remove some unused variables (2018-12-21 16:02:03 -0500)


Alexandre Belloni (1):
 alpha: rtc: simplify alpha_rtc_init

Colin Ian King (1):
 alpha: fix spelling mistake QSD_PORT_ACTUVE -> QSD_PORT_ACTIVE

Daniel Bristot de Oliveira (1):
 alpha: Fix a typo on ptrace.h

Firoz Khan (5):
 alpha: move __IGNORE* entries to non uapi header
 alpha: remove CONFIG_OSF4_COMPAT flag from syscall table
 alpha: add __NR_syscalls along with NR_SYSCALLS
 alpha: add system call table generation support
 alpha: generate uapi header and syscall table header files

Matt Turner (1):
 alpha: Remove some unused variables

arch/alpha/Makefile  |   3 +
arch/alpha/include/asm/Kbuild|   2 +-
arch/alpha/include/asm/unistd.h  |  23 +-
arch/alpha/include/uapi/asm/Kbuild   |   1 +
arch/alpha/include/uapi/asm/ptrace.h |   2 +-
arch/alpha/include/uapi/asm/unistd.h | 484 +--
arch/alpha/kernel/core_wildfire.c|   2 +-
arch/alpha/kernel/osf_sys.c  |  12 +-
arch/alpha/kernel/rtc.c  |  22 +-
arch/alpha/kernel/syscalls/Makefile  |  38 +++
arch/alpha/kernel/syscalls/syscall.tbl   | 453 ++
arch/alpha/kernel/syscalls/syscallhdr.sh |  36 ++
arch/alpha/kernel/syscalls/syscalltbl.sh |  32 ++
arch/alpha/kernel/systbls.S  | 542 +--
14 files changed, 609 insertions(+), 1043 deletions(-)
create mode 100644 arch/alpha/kernel/syscalls/Makefile
create mode 100644 arch/alpha/kernel/syscalls/syscall.tbl
create mode 100644 arch/alpha/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/alpha/kernel/syscalls/syscalltbl.sh


signature.asc
Description: PGP signature

Re: [PATCH v3 0/5] alpha: system call table generation support

[Matt Turner]

On Fri, Dec 14, 2018 at 10:18 AM Firoz Khan  wrote:
>
> Hi Folks,
>
> On Tue, 13 Nov 2018 at 15:02, Firoz Khan  wrote:
> >
> > The purpose of this patch series is, we can easily
> > add/modify/delete system call table support by cha-
> > nging entry in syscall.tbl file instead of manually
> > changing many files. The other goal is to unify the
> > system call table generation support implementation
> > across all the architectures.
> >
> > The system call tables are in different format in
> > all architecture. It will be difficult to manually
> > add, modify or delete the system calls in the resp-
> > ective files manually. To make it easy by keeping a
> > script and which'll generate uapi header file and
> > syscall table file.
> >
> > syscall.tbl contains the list of available system
> > calls along with system call number and correspond-
> > ing entry point. Add a new system call in this arch-
> > itecture will be possible by adding new entry in the
> > syscall.tbl file.
> >
> > Adding a new table entry consisting of:
> > - System call number.
> > - ABI.
> > - System call name.
> > - Entry point name.
> >
> > ARM, s390 and x86 architecuture does exist the sim-
> > ilar support. I leverage their implementation to
> > come up with a generic solution.
> >
> > I have done the same support for work for ia64, m68k,
> > microblaze, mips, parisc, powerpc, sh, sparc and xtensa.
> > Below mentioned git repository contains more details
> > about the workflow.
> >
> > https://github.com/frzkhn/system_call_table_generator/
> >
> > Finally, this is the ground work to solve the Y2038
> > issue. We need to add two dozen of system calls to
> > solve Y2038 issue. So this patch series will help to
> > add new system calls easily by adding new entry in
> > the syscall.tbl.
> >
> > changes since v2:
> >  - changed from generic-y to generated-y in Kbuild.
> >  - made changes in syscall.tbl for removing entry -
> >alpha_ni_syscall.
> >
> > changes since v1:
> >  - optimized/updated the syscall table generation
> >scripts.
> >  - fixed all mixed indentation issues in syscall.tbl.
> >  - added "comments" in syscall.tbl.
> >  - enclosed __NR_sycalls macro with __KERNEL__.
> >  - added missing new line.
> >
> > Firoz Khan (5):
> >   alpha: move __IGNORE* entries to non uapi header
> >   alpha: remove CONFIG_OSF4_COMPAT flag from syscall table
> >   alpha: add __NR_syscalls along with NR_SYSCALLS
> >   alpha: add system call table generation support
> >   alpha: generate uapi header and syscall table header files
>
> Could someone review this patch series and queue it for 4.21
> through alpha tree would be great.

Thank you! I'll take a look.

Re: [PATCH v2 0/5] alpha: system call table generation support

[Matt Turner]

On Thu, Nov 1, 2018 at 6:44 AM Firoz Khan  wrote:
>
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the
> system call table generation support implementation
> across all the architectures.
>
> The system call tables are in different format in
> all architecture. It will be difficult to manually
> add, modify or delete the system calls in the resp-
> ective files manually. To make it easy by keeping a
> script and which'll generate uapi header file and
> syscall table file.
>
> syscall.tbl contains the list of available system
> calls along with system call number and correspond-
> ing entry point. Add a new system call in this arch-
> itecture will be possible by adding new entry in the
> syscall.tbl file.

Sounds like a worthy goal.

I tried applying the patches and it seems they haven't been rebased
since v4.18. My rebases are in
https://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git/log/?h=for-linus

They seem to work for me, FWIW.

Is your plan to have the patches go through the separate architecture
trees, or go in together? I think I'd at least prefer for another
architecture to take the plunge before alpha.

Re: [PATCH] include/asm/cmpxchg.h: Remove duplicate header

[Matt Turner]

On Fri, Nov 2, 2018 at 12:09 PM Souptick Joarder  wrote:
>
> On Sat, Nov 3, 2018 at 12:31 AM Matt Turner  wrote:
> >
> > On Fri, Nov 2, 2018 at 11:55 AM Souptick Joarder  
> > wrote:
> > > We run the static analyser "make includecheck" which list out files where
> > > duplicate headers can be removed and based on that we thought to remove
> > > from this file. Didn't understood about the existence of second include ??
> >
> >
> > #define xchg(type, args...) __xchg ## type ## _local(args)
> > #define cmpxchg(type, args...)  __cmpxchg ## type ## _local(args)
> > #include 
> > [snip]
> > #undef xchg
> > #undef cmpxchg
> > #define xchg(type, args...) __xchg ##type(args)
> > #define cmpxchg(type, args...)  __cmpxchg ##type(args)
> > #include 
> >
> > asm/xchg.h has a comment at the top that says
> >
> > /*
> >  * xchg/xchg_local and cmpxchg/cmpxchg_local share the same code
> >  * except that local version do not have the expensive memory barrier.
> >  * So this file is included twice from asm/cmpxchg.h.
> >  */
>
> Thanks Matt. Sorry for the noise.
> Is there any way to exclude it from static analyser that someone else will
> not do the same mistake in future ?

Since this is not an uncommon pattern in C, I think any static
analysis tool that attempts to find duplicate includes should attempt
to recognize such a pattern.

That, or humans should review the output of their static analysis
tools. Or you could try to compile the patches produced. I think any
of those would have caught the problem with the patch.

Re: [PATCH] include/asm/cmpxchg.h: Remove duplicate header

[Matt Turner]

On Fri, Nov 2, 2018 at 11:55 AM Souptick Joarder  wrote:
> We run the static analyser "make includecheck" which list out files where
> duplicate headers can be removed and based on that we thought to remove
> from this file. Didn't understood about the existence of second include ??


#define xchg(type, args...) __xchg ## type ## _local(args)
#define cmpxchg(type, args...)  __cmpxchg ## type ## _local(args)
#include 
[snip]
#undef xchg
#undef cmpxchg
#define xchg(type, args...) __xchg ##type(args)
#define cmpxchg(type, args...)  __cmpxchg ##type(args)
#include 

asm/xchg.h has a comment at the top that says

/*
 * xchg/xchg_local and cmpxchg/cmpxchg_local share the same code
 * except that local version do not have the expensive memory barrier.
 * So this file is included twice from asm/cmpxchg.h.
 */

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull a few small changes for alpha.

Thanks,
Matt


The following changes since commit c61a56ababa404961fa769a2b24229f18e461961:

  Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2018-04-29 10:06:05 
-0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus

for you to fetch changes up to 92d7223a74235054f2aa7227d207d9c57f84dca0:

  alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering #2 
(2018-05-22 18:10:36 -0700)


Christoph Hellwig (2):
  alpha: use dma_direct_ops for jensen
  alpha: simplify get_arch_dma_ops

Sinan Kaya (1):
  alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering 
#2

 arch/alpha/Kconfig   |  1 +
 arch/alpha/include/asm/dma-mapping.h |  8 ++--
 arch/alpha/kernel/io.c   | 14 +++---
 arch/alpha/kernel/pci-noop.c | 33 -
 arch/alpha/kernel/pci_iommu.c|  4 +---
 5 files changed, 15 insertions(+), 45 deletions(-)


signature.asc
Description: Digital signature

Re: [PATCH] alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering #2

[Matt Turner]

On Fri, Apr 20, 2018 at 9:20 AM, Sinan Kaya  wrote:
> Hi Matt,
>
> On 4/17/2018 2:43 PM, Sinan Kaya wrote:
>> On 4/16/2018 6:16 PM, Sinan Kaya wrote:
>>> memory-barriers.txt has been updated with the following requirement.
>>>
>>> "When using writel(), a prior wmb() is not needed to guarantee that the
>>> cache coherent memory writes have completed before writing to the MMIO
>>> region."
>>>
>>> Current writeX() and iowriteX() implementations on alpha are not
>>> satisfying this requirement as the barrier is after the register write.
>>>
>>> Move mb() in writeX() and iowriteX() functions to guarantee that HW
>>> observes memory changes before performing register operations.
>>>
>>> Signed-off-by: Sinan Kaya 
>>> Reported-by: Arnd Bergmann 
>>> ---
>>>  arch/alpha/kernel/io.c | 14 +++---
>>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> Sorry for catching this late but this also needs to go to 4.17 after
>> review.
>>
>> I missed the writel() implementation on arch/alpha/kernel/io.c file
>> on my first patch.
>>
>
> Can you also queue this for 4.17?
>
> There are already drivers checked into 4.17 that dropped the unnecessary
> barriers.
>
> I really hate to see Alpha broken because of this.

Yes, I will pick it up for 4.17.

Thanks for the patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] alpha: Use OPTIMIZE_INLINING instead of asm/compiler.h

[Matt Turner]

On Mon, May 7, 2018 at 1:42 AM, James Hogan <jho...@kernel.org> wrote:
> On Sun, May 06, 2018 at 12:33:21PM -0700, Matt Turner wrote:
>> On Tue, Apr 17, 2018 at 3:11 AM, James Hogan <jho...@kernel.org> wrote:
>> > Use CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING and CONFIG_OPTIMIZE_INLINING
>> > instead of undefining the inline macros in the alpha specific
>> > asm/compiler.h. This is to allow asm/compiler.h to become a general
>> > header that can be used for overriding linux/compiler*.h.
>> >
>> > A build of alpha's defconfig on GCC 7.3 before and after this series
>> > (i.e. this commit and "compiler.h: Allow arch-specific overrides" which
>> > includes asm/compiler.h from linux/compiler_types.h) results in the
>> > following size differences, which appear harmless to me:
>> >
>> > $ ./scripts/bloat-o-meter vmlinux.1 vmlinux.2
>> > add/remove: 1/1 grow/shrink: 3/0 up/down: 264/-348 (-84)
>> > Function old new   delta
>> > cap_bprm_set_creds  14961664+168
>> > cap_issubset   -  68 +68
>> > flex_array_put   328 344 +16
>> > cap_capset   488 500 +12
>> > nonroot_raised_pE.constprop  348   --348
>> > Total: Before=5823709, After=5823625, chg -0.00%
>> >
>> > Suggested-by: Arnd Bergmann <a...@arndb.de>
>> > Signed-off-by: James Hogan <jho...@kernel.org>
>> > Cc: Richard Henderson <r...@twiddle.net>
>> > Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
>> > Cc: Matt Turner <matts...@gmail.com>
>> > Cc: linux-alpha@vger.kernel.org
>>
>> Looks fine to me.
>>
>> Acked-by: Matt Turner <matts...@gmail.com>
>
> Thanks
>
>>
>> Should I take it through the alpha tree?
>
> I'll take all 3 through the MIPS tree if thats okay with you, as its a
> prerequisite to allowing MIPS to override stuff in linux/compiler-gcc.h
> using asm/compiler.h, which is needed to fix build breakage in 4.17.

Thanks. That works for me.
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)

[Matt Turner]

On Mon, Apr 23, 2018 at 10:34 AM, Ivan Kokshaysky
<i...@jurassic.park.msu.ru> wrote:
> On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
>> On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
>> <i...@jurassic.park.msu.ru> wrote:
>> > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
>> >> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
>> >> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helg...@kernel.org> 
>> >> > wrote:
>> >> > > Hi Matt,
>> >> > >
>> >> > > First of all, sorry about breaking Nautilus, and thanks very much for
>> >> > > tracking it down to this commit.
>> >> >
>> >> > It's a particularly weird case, as far as I've been able to discern :)
>> >> >
>> >> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
>> >> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
>> >> > >> address limits in resource allocation) broke Alpha systems using
>> >> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
>> >> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
>> >> > >> into the upper addresses just below 4GB.
>> >> > >>
>> >> > >> I can get a working kernel by ifdef'ing out the code in
>> >> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
>> >> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
>> >> > >> kernels.
>> >> > >>
>> >> > >> How can we get Nautilus working again?
>> >> > >
>> >> > > Can you collect a complete dmesg log, ideally both before and after
>> >> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
>> >> > > erroneously assign space for something above 4GB.  But if we know the
>> >> > > correct host bridge apertures, we shouldn't assign space outside them,
>> >> > > regardless of the PCI bus address size.
>> >> >
>> >> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
>> >> > the last *working* commit. My apologies. The next commit is
>> >> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
>> >> > breaks Nautilus I've confirmed.
>> >> >
>> >> > Please find attached dmesgs from those two commits, from the commit
>> >> > immediately before them, and another from 4.17-rc1 with my hack of #if
>> >> > 0'ing out the pci_bus_alloc_from_region(..., _high) code.
>> >> >
>> >> > Thanks for having a look!
>> >>
>> >> We're telling the PCI core that the host bridge MMIO aperture is the
>> >> entire 64-bit address space, so when we assign BARs, some of them end
>> >> up above 4GB:
>> >>
>> >>   pci_bus :00: root bus resource [mem 0x-0x]
>> >>   pci :00:09.0: BAR 0: assigned [mem 0x1-0x1 64bit]
>> >>
>> >> But it sounds like the MMIO aperture really ends at 0x, so
>> >> that's not going to work.
>> >
>> > Correct... This would do as a quick fix, I think:
>> >
>> > diff --git a/arch/alpha/kernel/sys_nautilus.c 
>> > b/arch/alpha/kernel/sys_nautilus.c
>> > index ff4f54b..477ba65 100644
>> > --- a/arch/alpha/kernel/sys_nautilus.c
>> > +++ b/arch/alpha/kernel/sys_nautilus.c
>> > @@ -193,6 +193,8 @@ static struct resource irongate_io = {
>> >  };
>> >  static struct resource irongate_mem = {
>> > .name   = "Irongate PCI MEM",
>> > +   .start  = 0,
>> > +   .end= 0x,
>> > .flags  = IORESOURCE_MEM,
>> >  };
>> >  static struct resource busn_resource = {
>> > @@ -218,7 +220,7 @@ nautilus_init_pci(void)
>> > return;
>> >
>> > pci_add_resource(>windows, _resource);
>> > -   pci_add_resource(>windows, _resource);
>> > +   pci_add_resource(>windows, _mem);
>> > pci_add_resource(>windows, _resource);
>> > bridge->dev.parent = NULL;
>> > bridge->sysdata = hose;
>>
>> Thanks. But with that I get
>>
>> PCI host bridge to bu

Re: [PATCH v3 1/3] alpha: Use OPTIMIZE_INLINING instead of asm/compiler.h

[Matt Turner]

On Tue, Apr 17, 2018 at 3:11 AM, James Hogan <jho...@kernel.org> wrote:
> Use CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING and CONFIG_OPTIMIZE_INLINING
> instead of undefining the inline macros in the alpha specific
> asm/compiler.h. This is to allow asm/compiler.h to become a general
> header that can be used for overriding linux/compiler*.h.
>
> A build of alpha's defconfig on GCC 7.3 before and after this series
> (i.e. this commit and "compiler.h: Allow arch-specific overrides" which
> includes asm/compiler.h from linux/compiler_types.h) results in the
> following size differences, which appear harmless to me:
>
> $ ./scripts/bloat-o-meter vmlinux.1 vmlinux.2
> add/remove: 1/1 grow/shrink: 3/0 up/down: 264/-348 (-84)
> Function old new   delta
> cap_bprm_set_creds  14961664+168
> cap_issubset   -  68 +68
> flex_array_put   328 344 +16
> cap_capset   488 500 +12
> nonroot_raised_pE.constprop  348   --348
> Total: Before=5823709, After=5823625, chg -0.00%
>
> Suggested-by: Arnd Bergmann <a...@arndb.de>
> Signed-off-by: James Hogan <jho...@kernel.org>
> Cc: Richard Henderson <r...@twiddle.net>
> Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
> Cc: Matt Turner <matts...@gmail.com>
> Cc: linux-alpha@vger.kernel.org

Looks fine to me.

Acked-by: Matt Turner <matts...@gmail.com>

Should I take it through the alpha tree?
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)

[Matt Turner]

On Wed, May 2, 2018 at 1:33 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
> On Mon, Apr 23, 2018 at 06:34:23PM +0100, Ivan Kokshaysky wrote:
>> On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
>> > On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
>> > <i...@jurassic.park.msu.ru> wrote:
>> > > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
>> > >> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
>> > >> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helg...@kernel.org> 
>> > >> > wrote:
>> > >> > > Hi Matt,
>> > >> > >
>> > >> > > First of all, sorry about breaking Nautilus, and thanks very much 
>> > >> > > for
>> > >> > > tracking it down to this commit.
>> > >> >
>> > >> > It's a particularly weird case, as far as I've been able to discern :)
>> > >> >
>> > >> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
>> > >> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
>> > >> > >> address limits in resource allocation) broke Alpha systems using
>> > >> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
>> > >> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps 
>> > >> > >> PCI
>> > >> > >> into the upper addresses just below 4GB.
>> > >> > >>
>> > >> > >> I can get a working kernel by ifdef'ing out the code in
>> > >> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
>> > >> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
>> > >> > >> kernels.
>> > >> > >>
>> > >> > >> How can we get Nautilus working again?
>> > >> > >
>> > >> > > Can you collect a complete dmesg log, ideally both before and after
>> > >> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
>> > >> > > erroneously assign space for something above 4GB.  But if we know 
>> > >> > > the
>> > >> > > correct host bridge apertures, we shouldn't assign space outside 
>> > >> > > them,
>> > >> > > regardless of the PCI bus address size.
>> > >> >
>> > >> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
>> > >> > the last *working* commit. My apologies. The next commit is
>> > >> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
>> > >> > breaks Nautilus I've confirmed.
>> > >> >
>> > >> > Please find attached dmesgs from those two commits, from the commit
>> > >> > immediately before them, and another from 4.17-rc1 with my hack of #if
>> > >> > 0'ing out the pci_bus_alloc_from_region(..., _high) code.
>> > >> >
>> > >> > Thanks for having a look!
>> > >>
>> > >> We're telling the PCI core that the host bridge MMIO aperture is the
>> > >> entire 64-bit address space, so when we assign BARs, some of them end
>> > >> up above 4GB:
>> > >>
>> > >>   pci_bus :00: root bus resource [mem 0x-0x]
>> > >>   pci :00:09.0: BAR 0: assigned [mem 0x1-0x1 64bit]
>> > >>
>> > >> But it sounds like the MMIO aperture really ends at 0x, so
>> > >> that's not going to work.
>> > >
>> > > Correct... This would do as a quick fix, I think:
>> > >
>> > > diff --git a/arch/alpha/kernel/sys_nautilus.c 
>> > > b/arch/alpha/kernel/sys_nautilus.c
>> > > index ff4f54b..477ba65 100644
>> > > --- a/arch/alpha/kernel/sys_nautilus.c
>> > > +++ b/arch/alpha/kernel/sys_nautilus.c
>> > > @@ -193,6 +193,8 @@ static struct resource irongate_io = {
>> > >  };
>> > >  static struct resource irongate_mem = {
>> > > .name   = "Irongate PCI MEM",
>> > > +   .start  = 0,
>> > > +   .end= 0x,
>> > > .flags  = IORESOURCE_MEM,
>> > >  };
>> > >  static struct resource busn_resource = 

Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)

[Matt Turner]

On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
<i...@jurassic.park.msu.ru> wrote:
> On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
>> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
>> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
>> > > Hi Matt,
>> > >
>> > > First of all, sorry about breaking Nautilus, and thanks very much for
>> > > tracking it down to this commit.
>> >
>> > It's a particularly weird case, as far as I've been able to discern :)
>> >
>> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
>> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
>> > >> address limits in resource allocation) broke Alpha systems using
>> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
>> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
>> > >> into the upper addresses just below 4GB.
>> > >>
>> > >> I can get a working kernel by ifdef'ing out the code in
>> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
>> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
>> > >> kernels.
>> > >>
>> > >> How can we get Nautilus working again?
>> > >
>> > > Can you collect a complete dmesg log, ideally both before and after
>> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
>> > > erroneously assign space for something above 4GB.  But if we know the
>> > > correct host bridge apertures, we shouldn't assign space outside them,
>> > > regardless of the PCI bus address size.
>> >
>> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
>> > the last *working* commit. My apologies. The next commit is
>> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
>> > breaks Nautilus I've confirmed.
>> >
>> > Please find attached dmesgs from those two commits, from the commit
>> > immediately before them, and another from 4.17-rc1 with my hack of #if
>> > 0'ing out the pci_bus_alloc_from_region(..., _high) code.
>> >
>> > Thanks for having a look!
>>
>> We're telling the PCI core that the host bridge MMIO aperture is the
>> entire 64-bit address space, so when we assign BARs, some of them end
>> up above 4GB:
>>
>>   pci_bus :00: root bus resource [mem 0x-0x]
>>   pci :00:09.0: BAR 0: assigned [mem 0x1-0x1 64bit]
>>
>> But it sounds like the MMIO aperture really ends at 0x, so
>> that's not going to work.
>
> Correct... This would do as a quick fix, I think:
>
> diff --git a/arch/alpha/kernel/sys_nautilus.c 
> b/arch/alpha/kernel/sys_nautilus.c
> index ff4f54b..477ba65 100644
> --- a/arch/alpha/kernel/sys_nautilus.c
> +++ b/arch/alpha/kernel/sys_nautilus.c
> @@ -193,6 +193,8 @@ static struct resource irongate_io = {
>  };
>  static struct resource irongate_mem = {
> .name   = "Irongate PCI MEM",
> +   .start  = 0,
> +   .end= 0x,
> .flags  = IORESOURCE_MEM,
>  };
>  static struct resource busn_resource = {
> @@ -218,7 +220,7 @@ nautilus_init_pci(void)
> return;
>
> pci_add_resource(>windows, _resource);
> -   pci_add_resource(>windows, _resource);
> +   pci_add_resource(>windows, _mem);
> pci_add_resource(>windows, _resource);
> bridge->dev.parent = NULL;
> bridge->sysdata = hose;

Thanks. But with that I get

PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x-0x]
pci_bus :00: root bus resource [mem 0x-0x]
pci_bus :00: root bus resource [bus 00-ff]
pci :00:10.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
pci :00:10.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci :00:10.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
pci :00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
pci :00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
pci :00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
pci :00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
pci :00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
pci :00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
pci :00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
pci :00:01.0: BAR 9: assigned [mem 0xc000-0xc2ff pref]
pci :00:01.0

Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)

[Matt Turner]

On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
> Hi Matt,
>
> First of all, sorry about breaking Nautilus, and thanks very much for
> tracking it down to this commit.

It's a particularly weird case, as far as I've been able to discern :)

> On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
>> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
>> address limits in resource allocation) broke Alpha systems using
>> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
>> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
>> into the upper addresses just below 4GB.
>>
>> I can get a working kernel by ifdef'ing out the code in
>> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
>> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
>> kernels.
>>
>> How can we get Nautilus working again?
>
> Can you collect a complete dmesg log, ideally both before and after
> f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
> erroneously assign space for something above 4GB.  But if we know the
> correct host bridge apertures, we shouldn't assign space outside them,
> regardless of the PCI bus address size.

I made a mistake in my initial report. Commit f75b99d5a77d is actually
the last *working* commit. My apologies. The next commit is
d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
breaks Nautilus I've confirmed.

Please find attached dmesgs from those two commits, from the commit
immediately before them, and another from 4.17-rc1 with my hack of #if
0'ing out the pci_bus_alloc_from_region(..., _high) code.

Thanks for having a look!


dmesg-1-36e097a8a297
Description: Binary data


dmesg-2-f75b99d5a77d
Description: Binary data


dmesg-3-d56dbf5bab8c
Description: Binary data


lspci
Description: Binary data


dmesg-patched-4.17
Description: Binary data

Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)

[Matt Turner]

Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
address limits in resource allocation) broke Alpha systems using
CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
into the upper addresses just below 4GB.

I can get a working kernel by ifdef'ing out the code in
drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
kernels.

How can we get Nautilus working again?
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] alpha.git

[Matt Turner]

On Mon, Apr 9, 2018 at 9:13 AM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Sun, Apr 8, 2018 at 11:44 AM, Matt Turner <matts...@gmail.com> wrote:
>>
>> are available in the Git repository at:
>>
>>  git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git
>> for you to fetch changes up to cd0e00c106722eca40b38ebf11cf134c01901086:
>
> They aren't actually where you claimed.
>
> They are in the completely unmentioned "for-linus" branch.
>
> Yes, yes, I can figure that out on my own (particularly since you gave
> me the commit for the branch head, so I can verify using "git
> ls-remote" even before pulling), but I really would like to see it in
> the pull request.
>
>   Linus

Oops. Sorry about that!
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull a few small changes for alpha.

Thanks,
Matt


The following changes since commit bf6879dcc483f0aa087afe27d103285daf435951:

 Merge branch 'misc.compat' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2018-04-07 14:38:01 
-0700)

are available in the Git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git 


for you to fetch changes up to cd0e00c106722eca40b38ebf11cf134c01901086:

 alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering 
(2018-04-07 15:04:15 -0700)


Alexandre Belloni (2):
 alpha: rtc: remove unused set_mmss ops
 alpha: rtc: stop validating rtc_time in .read_time

Michael Cree (1):
 alpha: Implement CPU vulnerabilities sysfs functions.

Sinan Kaya (1):
 alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering

arch/alpha/Kconfig  |   1 +
arch/alpha/include/asm/io.h |  14 +++---
arch/alpha/kernel/Makefile  |   2 +-
arch/alpha/kernel/bugs.c|  45 
arch/alpha/kernel/rtc.c | 101 +---
5 files changed, 55 insertions(+), 108 deletions(-)
create mode 100644 arch/alpha/kernel/bugs.c


signature.asc
Description: Digital signature

Re: [PATCH] alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering

[Matt Turner]

On Thu, Apr 5, 2018 at 6:35 PM, Sinan Kaya  wrote:
> On 4/2/2018 1:48 PM, Sinan Kaya wrote:
>> memory-barriers.txt has been updated with the following requirement.
>>
>> "When using writel(), a prior wmb() is not needed to guarantee that the
>> cache coherent memory writes have completed before writing to the MMIO
>> region."
>>
>> Current writeX() and iowriteX() implementations on alpha are not
>> satisfying this requirement as the barrier is after the register write.
>>
>> Move mb() in writeX() and iowriteX() functions to guarantee that HW
>> observes memory changes before performing register operations.
>>
>> Signed-off-by: Sinan Kaya 
>> Reported-by: Arnd Bergmann 
>> ---
>>  arch/alpha/include/asm/io.h | 14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
>> index d123ff9..4c533fc 100644
>> --- a/arch/alpha/include/asm/io.h
>> +++ b/arch/alpha/include/asm/io.h
>> @@ -341,14 +341,14 @@ extern inline unsigned int ioread16(void __iomem *addr)
>>
>>  extern inline void iowrite8(u8 b, void __iomem *addr)
>>  {
>> - IO_CONCAT(__IO_PREFIX,iowrite8)(b, addr);
>>   mb();
>> + IO_CONCAT(__IO_PREFIX, iowrite8)(b, addr);
>>  }
>>
>>  extern inline void iowrite16(u16 b, void __iomem *addr)
>>  {
>> - IO_CONCAT(__IO_PREFIX,iowrite16)(b, addr);
>>   mb();
>> + IO_CONCAT(__IO_PREFIX, iowrite16)(b, addr);
>>  }
>>
>>  extern inline u8 inb(unsigned long port)
>> @@ -382,8 +382,8 @@ extern inline unsigned int ioread32(void __iomem *addr)
>>
>>  extern inline void iowrite32(u32 b, void __iomem *addr)
>>  {
>> - IO_CONCAT(__IO_PREFIX,iowrite32)(b, addr);
>>   mb();
>> + IO_CONCAT(__IO_PREFIX, iowrite32)(b, addr);
>>  }
>>
>>  extern inline u32 inl(unsigned long port)
>> @@ -434,14 +434,14 @@ extern inline u16 readw(const volatile void __iomem 
>> *addr)
>>
>>  extern inline void writeb(u8 b, volatile void __iomem *addr)
>>  {
>> - __raw_writeb(b, addr);
>>   mb();
>> + __raw_writeb(b, addr);
>>  }
>>
>>  extern inline void writew(u16 b, volatile void __iomem *addr)
>>  {
>> - __raw_writew(b, addr);
>>   mb();
>> + __raw_writew(b, addr);
>>  }
>>  #endif
>>
>> @@ -482,14 +482,14 @@ extern inline u64 readq(const volatile void __iomem 
>> *addr)
>>
>>  extern inline void writel(u32 b, volatile void __iomem *addr)
>>  {
>> - __raw_writel(b, addr);
>>   mb();
>> + __raw_writel(b, addr);
>>  }
>>
>>  extern inline void writeq(u64 b, volatile void __iomem *addr)
>>  {
>> - __raw_writeq(b, addr);
>>   mb();
>> + __raw_writeq(b, addr);
>>  }
>>  #endif
>>
>>
>
>
> Can we get these merged to 4.17?
>
> There was a consensus to fix the architectures having API violation issues.
> https://www.mail-archive.com/netdev@vger.kernel.org/msg225971.html

I expect so. Sorry I haven't had time to collect patches yet. I think
tomorrow or the next day I will.
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull my alpha git tree. It contains a few small fixes and clean ups.

Thanks,
Matt

The following changes since commit 8cbab92dff778e516064c13113ca15d4869ec883:

 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2018-01-16 16:47:40 
-0800)

are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus

for you to fetch changes up to 21ffceda1c8b3807615c40d440d7815e0c85d366:

 alpha: fix crash if pthread_create races with signal delivery (2018-01-20 
17:01:16 -0800)


Arnd Bergmann (2):
 alpha: osf_sys.c: fix put_tv32 regression
 alpha: osf_sys.c: use timespec64 where appropriate

Eugene Syromiatnikov (1):
 alpha: make XTABS equivalent to TAB3

Michael Cree (1):
 alpha: Fix mixed up args in EXC macro in futex operations

Mikulas Patocka (3):
 alpha: fix reboot on Avanti platform
 alpha: fix formating of stack content
 alpha: fix crash if pthread_create races with signal delivery

Sinan Kaya (1):
 alpha: deprecate pci_get_bus_and_slot()

Tobias Klauser (1):
 alpha: make thread_saved_pc static

arch/alpha/include/asm/futex.h |  8 ++--
arch/alpha/include/asm/processor.h |  5 +--
arch/alpha/include/uapi/asm/termbits.h |  6 ++-
arch/alpha/kernel/osf_sys.c| 72 +-
arch/alpha/kernel/pci.c|  2 +-
arch/alpha/kernel/pci_impl.h   |  3 +-
arch/alpha/kernel/process.c|  5 ++-
arch/alpha/kernel/sys_nautilus.c   |  2 +-
arch/alpha/kernel/traps.c  | 13 --
9 files changed, 62 insertions(+), 54 deletions(-)


signature.asc
Description: Digital signature

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull my alpha git tree. It contains a build fix and a regression fix.

Hopefully still in time for 4.15 :)

Thanks,
Matt

The following changes since commit 8cbab92dff778e516064c13113ca15d4869ec883:

 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2018-01-16 16:47:40 
-0800)

are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus

for you to fetch changes up to 86be89939d11a84800f66e2a283b915b704bf33d:

 alpha/PCI: Fix noname IRQ level detection (2018-01-20 16:22:36 -0800)


Lorenzo Pieralisi (1):
 alpha/PCI: Fix noname IRQ level detection

Michael Cree (1):
 alpha: extend memset16 to EV6 optimised routines

arch/alpha/kernel/sys_sio.c | 35 +--
arch/alpha/lib/ev6-memset.S | 12 ++--
2 files changed, 35 insertions(+), 12 deletions(-)


signature.asc
Description: Digital signature

Re: Do any Alpha systems include InfiniBand?

[Matt Turner]

On Fri, Oct 20, 2017 at 12:48 PM, Paul E. McKenney
 wrote:
> Hello, Michael,
>
> Do any of the DEC Alpha systems that run recent kernels have InfiniBand?
> Given my understanding of the history, I believe the answer to be "no".
> If I am wrong, please let me know, as I will otherwise interpret silence
> as assent.  ;-)

I'm not aware of any shipping with Infiniband, and I haven't heard of
anyone putting Infiniband in an Alpha.

Why do you ask? :)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] 4.13.0 kernel build error on Alpha

[Matt Turner]

On Sun, Sep 10, 2017 at 3:34 PM, Bob Tracy  wrote:
> Here we go again :-(.  Tool versions as follows:
>
> gcc version 7.2.0 (Debian 7.2.0-3)
> GNU ld (GNU Binutils for Debian) 2.29 (binutils 2.29-9)
>
> Note evidence of the ".alphalib" section patch first tried with the 4.9
> kernel source.  It has worked well up through 4.12.  I didn't try
> building any of the 4.13 release candidates because of all the compiler
> updates that came through during that time.
>
>   MODPOST vmlinux.o
> WARNING: EXPORT symbol "callback_setenv" [vmlinux] version generation failed, 
> symbol will not be versioned.
> WARNING: EXPORT symbol "strrchr" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "__divl" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "__divqu" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "__memsetw" [vmlinux] version generation failed, 
> symbol will not be versioned.
> WARNING: EXPORT symbol "strchr" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "__reml" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "strcat" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "__copy_user" [vmlinux] version generation failed, 
> symbol will not be versioned.
> WARNING: EXPORT symbol "__remq" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "clear_page" [vmlinux] version generation failed, 
> symbol will not be versioned.
> WARNING: EXPORT symbol "strncpy" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "memmove" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "__remqu" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "memchr" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "__memset" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "copy_page" [vmlinux] version generation failed, 
> symbol will not be versioned.
> WARNING: EXPORT symbol "__divlu" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "strlen" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "strncat" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "callback_save_env" [vmlinux] version generation 
> failed, symbol will not be versioned.
> WARNING: EXPORT symbol "memset" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: "saved_config" [vmlinux] is COMMON symbol
> WARNING: EXPORT symbol "__clear_user" [vmlinux] version generation failed, 
> symbol will not be versioned.
> WARNING: EXPORT symbol "callback_getenv" [vmlinux] version generation failed, 
> symbol will not be versioned.
> WARNING: EXPORT symbol "__divq" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "strcpy" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "___memset" [vmlinux] version generation failed, 
> symbol will not be versioned.
> WARNING: EXPORT symbol "__remlu" [vmlinux] version generation failed, symbol 
> will not be versioned.
> WARNING: EXPORT symbol "csum_ipv6_magic" [vmlinux] version generation failed, 
> symbol will not be versioned.
> WARNING: EXPORT symbol "__constant_c_memset" [vmlinux] version generation 
> failed, symbol will not be versioned.
> WARNING: modpost: Found 24 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'

All of this is fixed by

commit 873f9b5bcbf27f6e89e1879714abe4532cacf5d7
Author: Ben Hutchings 
Date:   Wed Jul 19 01:01:16 2017 +0100

alpha: Restore symbol versions for symbols exported from assembly


> arch/alpha/lib/memmove.o: In function `memmove':
> (.alphalib+0x2c): relocation truncated to fit: BRSGP against symbol `memcpy' 
> defined in .text section in arch/alpha/lib/memcpy.o
> Makefile:1000: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1

I have not yet seen this.

The kernel seemed to be in good shape after my two pull requests were
merged. (commit dd689a68bc3 for 4.13 and commit 6caffe21dde for
4.13-rc1)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull my alpha git tree. It contains a few fixes and wires up some
additional syscalls.

Thanks,
Matt

PS: My alpha has been offline, hence the very late-in-cycle pull request.


The following changes since commit 143c97cc652949893c8056c679012f0aeccb80e5:

 Revert "pty: fix the cached path of the pty slave file descriptor in the 
master" (2017-08-23 18:16:11 -0700)

are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus

for you to fetch changes up to cec80d82142ab25c71eee24b529cfeaf17c43062:

 alpha: uapi: Add support for __SANE_USERSPACE_TYPES__ (2017-08-29 12:02:00 
-0700)


Ben Hutchings (1):
 alpha: uapi: Add support for __SANE_USERSPACE_TYPES__

Guenter Roeck (1):
 alpha: Define ioremap_wc

Matt Turner (2):
 alpha: Fix build error without CONFIG_VGA_HOSE.
 alpha: Fix section mismatches

Michael Cree (1):
 alpha: support R_ALPHA_REFLONG relocations for module loading

Richard Henderson (3):
 alpha: Update for new syscalls
 alpha: Package string routines together
 alpha: Fix typo in ev6-copy_user.S

arch/alpha/include/asm/io.h  |  1 +
arch/alpha/include/asm/types.h   |  2 +-
arch/alpha/include/asm/unistd.h  |  2 +-
arch/alpha/include/uapi/asm/types.h  | 12 +++-
arch/alpha/include/uapi/asm/unistd.h | 14 ++
arch/alpha/kernel/core_marvel.c  |  6 --
arch/alpha/kernel/core_titan.c   |  2 ++
arch/alpha/kernel/module.c   |  3 +++
arch/alpha/kernel/smp.c  |  2 +-
arch/alpha/kernel/systbls.S  |  9 +
arch/alpha/lib/Makefile  | 22 --
arch/alpha/lib/copy_user.S   |  2 +-
arch/alpha/lib/ev6-copy_user.S   |  7 ---
13 files changed, 68 insertions(+), 16 deletions(-)


signature.asc
Description: Digital signature

[PATCH] alpha: Fix section mismatches

[Matt Turner]

Signed-off-by: Matt Turner <matts...@gmail.com>
---
 arch/alpha/kernel/core_marvel.c | 4 ++--
 arch/alpha/kernel/smp.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index db72356714c1..03ff832b1cb4 100644
--- a/arch/alpha/kernel/core_marvel.c
+++ b/arch/alpha/kernel/core_marvel.c
@@ -351,7 +351,7 @@ marvel_init_io7(struct io7 *io7)
}
 }
 
-void
+void __init
 marvel_io7_present(gct6_node *node)
 {
int pe;
@@ -406,7 +406,7 @@ marvel_find_console_vga_hose(void)
 #endif
 }
 
-gct6_search_struct gct_wanted_node_list[] = {
+gct6_search_struct gct_wanted_node_list[] __initdata = {
{ GCT_TYPE_HOSE, GCT_SUBTYPE_IO_PORT_MODULE, marvel_io7_present },
{ 0, 0, NULL }
 };
diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
index 9fc560459ebd..f6726a746427 100644
--- a/arch/alpha/kernel/smp.c
+++ b/arch/alpha/kernel/smp.c
@@ -115,7 +115,7 @@ wait_boot_cpu_to_stop(int cpuid)
 /*
  * Where secondaries begin a life of C.
  */
-void
+void __init
 smp_callin(void)
 {
int cpuid = hard_smp_processor_id();
-- 
2.13.0

--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] alpha: Fix build error without CONFIG_VGA_HOSE.

[Matt Turner]

pci_vga_hose is #defined to 0 in include/asm/vga.h if CONFIG_VGA_HOSE is
not set.

Signed-off-by: Matt Turner <matts...@gmail.com>
---
 arch/alpha/kernel/core_marvel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index d5f0580746a5..db72356714c1 100644
--- a/arch/alpha/kernel/core_marvel.c
+++ b/arch/alpha/kernel/core_marvel.c
@@ -369,6 +369,7 @@ marvel_io7_present(gct6_node *node)
 static void __init
 marvel_find_console_vga_hose(void)
 {
+#ifdef CONFIG_VGA_HOSE
u64 *pu64 = (u64 *)((u64)hwrpb + hwrpb->ctbt_offset);
 
if (pu64[7] == 3) { /* TERM_TYPE == graphics */
@@ -402,6 +403,7 @@ marvel_find_console_vga_hose(void)
pci_vga_hose = hose;
}
}
+#endif
 }
 
 gct6_search_struct gct_wanted_node_list[] = {
-- 
2.13.0

--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] 4.9.0 build error on Alpha

[Matt Turner]

FWIW, when I saw your first email I tried compiling with gcc-4.9.4,
5.4.0, and 6.2.0. All compiled my config fine.

I'm guessing it's another symptom of the old "kernel too big" problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html