Re: [PATCH] hwmon: applesmc: avoid overlong udelay()

[Matt Turner]

On my late 2013 Macbook Pro, I have a couple of scripts that set the
fans to auto or full-speed:

fan-hi:
#!/bin/sh
sudo sh -c 'echo 1 > /sys/devices/platform/applesmc.768/fan1_manual
echo 1 > /sys/devices/platform/applesmc.768/fan2_manual
cat /sys/devices/platform/applesmc.768/fan1_max > 
/sys/devices/platform/applesmc.768/fan1_output
cat /sys/devices/platform/applesmc.768/fan2_max > 
/sys/devices/platform/applesmc.768/fan2_output'

fan-auto:
#!/bin/sh
sudo sh -c 'echo 0 > /sys/devices/platform/applesmc.768/fan1_manual
echo 0 > /sys/devices/platform/applesmc.768/fan2_manual'

Running ./fan-hi and then ./fan-auto on Linux v5.6 works and doesn't
cause any problems, but after updating to v5.9 I see this in dmesg:

[Nov 6 17:24] applesmc: send_byte(0x01, 0x0300) fail: 0x40
[  +0.05] applesmc: FS! : write data fail
[  +0.191777] applesmc: send_byte(0x30, 0x0300) fail: 0x40
[  +0.09] applesmc: F0Tg: write data fail
[  +7.097416] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  +0.06] applesmc: FS! : write data fail

and the fan controls don't work.

Googling turned up this [1] which looks like the same problem. They said
it began occurring between v5.7 and v5.8, so I looked and found this
commit.

After reverting commit fff2d0f701e6753591609739f8ab9be1c8e80ebb from
v5.9, I no longer see the errors in dmesg and the fan controls work
again.

Any ideas what the problem is?

Thanks,
Matt

[1] 
https://stackoverflow.com/questions/63505469/cant-write-data-to-applesmc-error-after-upgrade-to-arch-linux-kernel-5-8-1


signature.asc
Description: PGP signature

Re: [PATCH v3 02/23] alpha: use asm-generic/mmu_context.h for no-op implementations

[Matt Turner]

On Tue, Sep 1, 2020 at 7:15 AM Nicholas Piggin  wrote:
>
> Cc: Richard Henderson 
> Cc: Ivan Kokshaysky 
> Cc: Matt Turner 
> Cc: linux-al...@vger.kernel.org
> Signed-off-by: Nicholas Piggin 
> ---
>
> Please ack or nack if you object to this being mered via
> Arnd's tree.

That would be great.

Acked-by: Matt Turner 

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull a few changes for alpha. They're mostly small janitorial fixes but
there's also a build fix and most notably a patch from Mikulas that fixes a
hang on boot on the Avanti platform, which required quite a bit of work and
review.

Thanks,
Matt

The following changes since commit 79ca035d2d941839f55f3b8b69f8e81c66946ed8:

  Merge branch 'proc-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace 
(2020-06-10 15:00:11 -0700)

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 47f634ba765085373f851e9c48dccb12ad52:

  alpha: Fix build around srm_sysrq_reboot_op (2020-06-12 17:43:18 -0700)


Chuhong Yuan (1):
  alpha: Replace strncmp with str_has_prefix

Enrico Weigelt, metux IT consult (1):
  alpha: Kconfig: pedantic formatting

Jason Yan (2):
  alpha: remove unneeded semicolon in osf_sys.c
  alpha: remove unneeded semicolon in sys_eiger.c

Joerg Roedel (1):
  alpha: Fix build around srm_sysrq_reboot_op

Matt Turner (1):
  alpha: c_next should increase position index

Mikulas Patocka (2):
  alpha: fix rtc port ranges
  alpha: fix memory barriers so that they conform to the specification

Xu Wang (1):
  alpha: Replace sg++ with sg = sg_next(sg)

 arch/alpha/Kconfig   |  4 +--
 arch/alpha/boot/tools/objstrip.c |  2 +-
 arch/alpha/include/asm/io.h  | 74 
 arch/alpha/kernel/io.c   | 60 
 arch/alpha/kernel/osf_sys.c  |  2 +-
 arch/alpha/kernel/pci_iommu.c|  2 +-
 arch/alpha/kernel/setup.c| 12 +--
 arch/alpha/kernel/sys_eiger.c|  2 +-
 8 files changed, 127 insertions(+), 31 deletions(-)


signature.asc
Description: PGP signature

Re: [PATCH] alpha: Fix build around srm_sysrq_reboot_op

[Matt Turner]

On Thu, Jun 11, 2020 at 2:14 AM Joerg Roedel  wrote:
>
> From: Joerg Roedel 
>
> The patch introducing the struct was probably never compile tested,
> because it sets a handler with a wrong function signature. Wrap the
> handler into a functions with the correct signature to fix the build.
>
> Fixes: 0f1c9688a194 ("tty/sysrq: alpha: export and use __sysrq_get_key_op()")
> Cc: Emil Velikov 
> Cc: Guenter Roeck 
> Signed-off-by: Joerg Roedel 
> ---

Thanks, applied.

Re: Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage)

[Matt Turner]

On Tue, Jun 2, 2020 at 11:03 AM Kees Cook  wrote:
>
> On Mon, Jun 01, 2020 at 07:48:04PM -0700, Matt Turner wrote:
> > I bisected a regression on alpha to f2f84b05e02b (bug: consolidate
> > warn_slowpath_fmt() usage) which looks totally innocuous.
> >
> > Reverting it on master confirms that it somehow is the trigger. At or a
> > little after starting userspace, I'll see an oops like this:
> >
> > Unable to handle kernel paging request at virtual address 
> > CPU 0
> > kworker/u2:5(98): Oops -1
> > pc = [<>]  ra = [<>]  ps = Not 
> > tainted
> > pc is at 0x0
>
>  so, the instruction pointer is NULL. The only way I can imagine
> that happening would be from this line:
>
> worker->current_func(work);
>
> > ra is at 0x0
> > v0 = 0007  t0 = 0001  t1 = 0001
> > t2 =   t3 = fc00bfe68780  t4 = 0001
> > t5 = fc00bf8cc780  t6 = 026f8000  t7 = fc00bfe7
> > s0 = fc000250d310  s1 = fc000250d310  s2 = fc000250d310
> > s3 = fc000250ca40  s4 = fc000250caa0  s5 = 
> > s6 = fc000250ca40
> > a0 = fc00024f0488  a1 = fc00bfe73d98  a2 = fc00bfe68800
> > a3 = fc00bf881400  a4 = 0001  a5 = 0002
> > t8 =   t9 =   t10= 01321800
> > t11= ba4e  pv = fc000189ca00  at = 
> > gp = fc000253e430  sp = 43a83c2e
> > Disabling lock debugging due to kernel taint
> > Trace:
> > [] process_one_work+0x25c/0x5a0
>
> Can you verify where this ^^   is?

It is kernel/workqueue.c:2268, which contains

worker->current_func(work);

as you predicted.

> > [] worker_thread+0x5c/0x7d0
> > [] kthread+0x188/0x1f0
> > [] ret_from_kernel_thread+0x18/0x20
> > [] kthread+0x0/0x1f0
> > [] worker_thread+0x0/0x7d0
> >
> > Code:
> >  
> >  
> >  00063301
> >  12e2
> >  
> >  0005ffde
> >
> > It seems to cause a hard lock on an SMP system, but not on a system with
> > a single CPU. Similarly, if I boot the SMP system (2 CPUs) with
> > maxcpus=1 the oops doesn't happen. Until I tested on a non-SMP system
> > today I suspected that it was unaffected, but I saw the oops there too.
> > With the revert applied, I don't see a warning or an oops.
> >
> > Any clues how this patch could have triggered the oops?
>
> I cannot begin to imagine. :P Compared to other things I've seen like
> this in the past maybe it's some kind of effect from the code size
> changing the location/alignment or timing of something else?
>
> Various questions ranging in degrees of sanity:
>
> Does alpha use work queues for WARN?

I do not know. I don't see much in a few greps of arch/alpha that
would indicate that it uses work queues.

> Which work queue is getting a NULL function? (And then things like "if
> WARN was much slower or much faster, is there a race to something
> setting itself to NULL?")
>
> Was there a WARN before the above Oops?

No, which I suspect means that your much scarier suggestion that this
is somehow due to code size or alignment is increasingly plausible.

> Does WARN have side-effects on alpha?

alpha just uses the asm-generic implementation of WARN as far as I can
tell, so I think not.

> Does __WARN_printf() do something bad that warn_slowpath_null() doesn't?
>
> Does making incremental changes narrow anything down? (e.g. instead of
> this revert, remove the __warn() call in warn_slowpath_fmt() that was
> added? (I mean, that'll be quite broken for WARN, but will it not oops?)

Commenting out the added __warn does not work around the problem.

Readding warn_slowpath_null and the EXPORT_SYMBOL (but not calling it
from WARN) does not work around the problem.

Calling warn_slowpath_fmt() with fmt=" " instead of fmt=NULL does not
work around the problem.

I also tried GCC-10.1 as a stab in the dark, and that doesn't work
around the problem.

So I'm thinking it's something about code size or alignment. I would
be worried it's to do with memory ordering (since this is on Alpha)
but I'm seeing the problem on a single CPU system, so that should be
ruled out, I think?

Using CONFIG_CC_OPTIMIZE_FOR_SIZE=y doesn't work around the problem.
So that hurts the theory of code size being the trigger.

Since I noticed earlier that using maxcpus=1 on a 2-CPU system
prevented the system from hanging, I tried disabling CONFIG_SMP on my
1-CPU system as well. In doing so, I discovered that the RCU torture
module (RCU_TORT

Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage)

[Matt Turner]

I bisected a regression on alpha to f2f84b05e02b (bug: consolidate
warn_slowpath_fmt() usage) which looks totally innocuous.

Reverting it on master confirms that it somehow is the trigger. At or a
little after starting userspace, I'll see an oops like this:

Unable to handle kernel paging request at virtual address 
CPU 0
kworker/u2:5(98): Oops -1
pc = [<>]  ra = [<>]  ps = Not tainted
pc is at 0x0
ra is at 0x0
v0 = 0007  t0 = 0001  t1 = 0001
t2 =   t3 = fc00bfe68780  t4 = 0001
t5 = fc00bf8cc780  t6 = 026f8000  t7 = fc00bfe7
s0 = fc000250d310  s1 = fc000250d310  s2 = fc000250d310
s3 = fc000250ca40  s4 = fc000250caa0  s5 = 
s6 = fc000250ca40
a0 = fc00024f0488  a1 = fc00bfe73d98  a2 = fc00bfe68800
a3 = fc00bf881400  a4 = 0001  a5 = 0002
t8 =   t9 =   t10= 01321800
t11= ba4e  pv = fc000189ca00  at = 
gp = fc000253e430  sp = 43a83c2e
Disabling lock debugging due to kernel taint
Trace:
[] process_one_work+0x25c/0x5a0
[] worker_thread+0x5c/0x7d0
[] kthread+0x188/0x1f0
[] ret_from_kernel_thread+0x18/0x20
[] kthread+0x0/0x1f0
[] worker_thread+0x0/0x7d0

Code:
 
 
 00063301
 12e2
 
 0005ffde

It seems to cause a hard lock on an SMP system, but not on a system with
a single CPU. Similarly, if I boot the SMP system (2 CPUs) with
maxcpus=1 the oops doesn't happen. Until I tested on a non-SMP system
today I suspected that it was unaffected, but I saw the oops there too.
With the revert applied, I don't see a warning or an oops.

Any clues how this patch could have triggered the oops?

Here's the revert, with a trivial conflict resolved, that I've used in
testing:

From fdbdd0f606f0f412ee06c1152e33a22ca17102bc Mon Sep 17 00:00:00 2001
From: Matt Turner 
Date: Sun, 24 May 2020 20:46:00 -0700
Subject: [PATCH] Revert "bug: consolidate warn_slowpath_fmt() usage"

This reverts commit f2f84b05e02b7710a201f0017b3272ad7ef703d1.
---
 include/asm-generic/bug.h |  3 ++-
 kernel/panic.c| 15 +++
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 384b5c835ced..a4a311d4b4b0 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -82,7 +82,8 @@ struct bug_entry {
 extern __printf(4, 5)
 void warn_slowpath_fmt(const char *file, const int line, unsigned taint,
   const char *fmt, ...);
-#define __WARN()   __WARN_printf(TAINT_WARN, NULL)
+extern void warn_slowpath_null(const char *file, const int line);
+#define __WARN()   warn_slowpath_null(__FILE__, __LINE__)
 #define __WARN_printf(taint, arg...)   \
warn_slowpath_fmt(__FILE__, __LINE__, taint, arg)
 #else
diff --git a/kernel/panic.c b/kernel/panic.c
index b69ee9e76cb2..c8ed8046b484 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -603,20 +603,19 @@ void warn_slowpath_fmt(const char *file, int line, 
unsigned taint,
 {
struct warn_args args;
 
-	pr_warn(CUT_HERE);

-
-   if (!fmt) {
-   __warn(file, line, __builtin_return_address(0), taint,
-  NULL, NULL);
-   return;
-   }
-
args.fmt = fmt;
va_start(args.args, fmt);
__warn(file, line, __builtin_return_address(0), taint, NULL, );
va_end(args.args);
 }
 EXPORT_SYMBOL(warn_slowpath_fmt);
+
+void warn_slowpath_null(const char *file, int line)
+{
+   pr_warn(CUT_HERE);
+   __warn(file, line, __builtin_return_address(0), TAINT_WARN, NULL, NULL);
+}
+EXPORT_SYMBOL(warn_slowpath_null);
 #else
 void __warn_printk(const char *fmt, ...)
 {
--
2.26.2


signature.asc
Description: PGP signature

Re: [PATCH 00/13] Modernize Loongson64 Machine

[Matt Turner]

On Tue, Aug 27, 2019 at 1:53 AM Jiaxun Yang  wrote:
> Loongson have a long history of contributing their code to mainline kernel.
> However, it seems like recent years, they are focusing on maintain a kernel 
> by themselves
> rather than contribute there code to the community.

Do you know more about this? I have a Loongson 3A3000 system that I
have never been able to make stable. I tried pulling patches out of
the glibc, binutils, gcc, and Linux repos I found at
https://github.com/loongson-community but my system still hardlocks,
preventing me from doing much of anything with it.

Do we know why critical looking toolchain patches like "Added misses
sync in mips_process_sync_loop for add sync before ll sc" [0] and "Fix
loads for Loongson3 to promoting stability" [1] have not been
submitted upstream?

I'm interested in supporting Loongson 3 in Gentoo, and the hardware
that has been given to me would be extremely useful for Gentoo's MIPS
port in general, but it's just not usable at all currently.

[0] 
https://github.com/loongson-community/gcc/commit/e7e3b0f956929f022caa01ed25a482495b11d575
[1] 
https://github.com/loongson-community/binutils-gdb/commit/2f0e91d2af6093097202fae3adab624ffa86a156

Re: [PATCH 2/2] ipc: fix sparc64 ipc() wrapper

[Matt Turner]

On Thu, Sep 5, 2019 at 8:23 AM Arnd Bergmann  wrote:
>
> Matt bisected a sparc64 specific issue with semctl, shmctl and msgctl
> to a commit from my y2038 series in linux-5.1, as I missed the custom
> sys_ipc() wrapper that sparc64 uses in place of the generic version that
> I patched.
>
> The problem is that the sys_{sem,shm,msg}ctl() functions in the kernel
> now do not allow being called with the IPC_64 flag any more, resulting
> in a -EINVAL error when they don't recognize the command.
>
> Instead, the correct way to do this now is to call the internal
> ksys_old_{sem,shm,msg}ctl() functions to select the API version.
>
> As we generally move towards these functions anyway, change all of
> sparc_ipc() to consistently use those in place of the sys_*() versions,
> and move the required ksys_*() declarations into linux/syscalls.h
>
> Reported-by: Matt Turner 
> Fixes: 275f22148e87 ("ipc: rename old-style shmctl/semctl/msgctl syscalls")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Arnd Bergmann 
> ---
> Hi Matt,
>
> Can you check that this solves your problem?

Works great. Thank you Arnd!

Tested-by: Matt Turner 

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: [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.

[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 Wed, Dec 19, 2018 at 12:08 PM Arnd Bergmann  wrote:
>
> On Wed, Dec 19, 2018 at 4:59 PM Matt Turner  wrote:
> > On Fri, Dec 14, 2018 at 10:18 AM Firoz Khan  wrote:
> > > On Tue, 13 Nov 2018 at 15:02, Firoz Khan  wrote:
> > >
> > > 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.
>
> Hi Matt,
>
> I see that you merged the changes a while ago into
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha#for-linus
>
> This all seems fine, but they never showed up in linux-next,
> which his what had both Firoz and me confused.
>
> Is that intentional, or should it be added there?

Probably so. This is just a super part-time thing for me, so I've
never figured out what I needed to do to be included in linux-next.

> Added Stephen to Cc here in case you want it added.

Thanks!

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 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] parport: Add support for the WCH384 4S multi-IO card

[Matt Turner]

On Thu, Jul 5, 2018 at 3:17 PM Sudip Mukherjee
 wrote:
>
> Hi Matt,
>
> On Sat, May 26, 2018 at 12:35:23PM -0700, Matt Turner wrote:
> > This Multi-IO card has one serial 16550-like serial connectors. Here's
> > the lspci output, after this commit is applied:
> >
> > 01:00.0 Serial controller [0700]: Device [1c00:3470] (rev 10) (prog-if 05 
> > [16850])
> > Subsystem: Device [1c00:3470]
> > Flags: fast devsel, IRQ 16
> > I/O ports at e000 [size=256]
> > Memory at f010 (32-bit, prefetchable) [size=32K]
> > I/O ports at e100 [size=4]
> > Expansion ROM at f7d0 [disabled] [size=32K]
> > Capabilities: [60] Power Management version 3
> > Capabilities: [68] MSI: Enable- Count=1/32 Maskable+ 64bit+
> > Capabilities: [80] Express Legacy Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Kernel driver in use: parport_serial
> >
> > This card was already added to the blacklist of 8250_pci.c in commit
> > 72a3c0e4e662 ("tty: Add support for the WCH384 4S multi-IO card").
> >
> > Cc: Sergej Pupykin 
> > Signed-off-by: Matt Turner 
> > ---
> > It looks like CH355_4S is similarly missing, but I don't have hardware
> > to test.
> >
> > This commit makes me wonder if I'm missing something -- how could
> > anything have worked after commit 72a3c0e4e662 without support in
> > parport_serial?
> >
>
> Is the patch still needed to be applied? After Andy's patch to tty tree,
> the device (0x1c00, 0x3470) will be probed by 8250_pci.c.

Yes, Andy's patch replaces this one. It can be discarded.

Thanks!
Matt

Re: [PATCH] parport: Add support for the WCH384 4S multi-IO card

[Matt Turner]

On Thu, Jul 5, 2018 at 3:17 PM Sudip Mukherjee
 wrote:
>
> Hi Matt,
>
> On Sat, May 26, 2018 at 12:35:23PM -0700, Matt Turner wrote:
> > This Multi-IO card has one serial 16550-like serial connectors. Here's
> > the lspci output, after this commit is applied:
> >
> > 01:00.0 Serial controller [0700]: Device [1c00:3470] (rev 10) (prog-if 05 
> > [16850])
> > Subsystem: Device [1c00:3470]
> > Flags: fast devsel, IRQ 16
> > I/O ports at e000 [size=256]
> > Memory at f010 (32-bit, prefetchable) [size=32K]
> > I/O ports at e100 [size=4]
> > Expansion ROM at f7d0 [disabled] [size=32K]
> > Capabilities: [60] Power Management version 3
> > Capabilities: [68] MSI: Enable- Count=1/32 Maskable+ 64bit+
> > Capabilities: [80] Express Legacy Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Kernel driver in use: parport_serial
> >
> > This card was already added to the blacklist of 8250_pci.c in commit
> > 72a3c0e4e662 ("tty: Add support for the WCH384 4S multi-IO card").
> >
> > Cc: Sergej Pupykin 
> > Signed-off-by: Matt Turner 
> > ---
> > It looks like CH355_4S is similarly missing, but I don't have hardware
> > to test.
> >
> > This commit makes me wonder if I'm missing something -- how could
> > anything have worked after commit 72a3c0e4e662 without support in
> > parport_serial?
> >
>
> Is the patch still needed to be applied? After Andy's patch to tty tree,
> the device (0x1c00, 0x3470) will be probed by 8250_pci.c.

Yes, Andy's patch replaces this one. It can be discarded.

Thanks!
Matt

Re: [PATCH] parport: Add support for the WCH384 4S multi-IO card

[Matt Turner]

On Sat, May 26, 2018 at 12:35 PM, Matt Turner  wrote:
> This Multi-IO card has one serial 16550-like serial connectors. Here's
> the lspci output, after this commit is applied:
>
> 01:00.0 Serial controller [0700]: Device [1c00:3470] (rev 10) (prog-if 05 
> [16850])
> Subsystem: Device [1c00:3470]
> Flags: fast devsel, IRQ 16
> I/O ports at e000 [size=256]
> Memory at f010 (32-bit, prefetchable) [size=32K]
> I/O ports at e100 [size=4]
> Expansion ROM at f7d0 [disabled] [size=32K]
> Capabilities: [60] Power Management version 3
> Capabilities: [68] MSI: Enable- Count=1/32 Maskable+ 64bit+
> Capabilities: [80] Express Legacy Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Kernel driver in use: parport_serial
>
> This card was already added to the blacklist of 8250_pci.c in commit
> 72a3c0e4e662 ("tty: Add support for the WCH384 4S multi-IO card").
>
> Cc: Sergej Pupykin 
> Signed-off-by: Matt Turner 
> ---

Hi,

Can I expect this to be picked up for the 4.18 merge window?

Matt

Re: [PATCH] parport: Add support for the WCH384 4S multi-IO card

[Matt Turner]

On Sat, May 26, 2018 at 12:35 PM, Matt Turner  wrote:
> This Multi-IO card has one serial 16550-like serial connectors. Here's
> the lspci output, after this commit is applied:
>
> 01:00.0 Serial controller [0700]: Device [1c00:3470] (rev 10) (prog-if 05 
> [16850])
> Subsystem: Device [1c00:3470]
> Flags: fast devsel, IRQ 16
> I/O ports at e000 [size=256]
> Memory at f010 (32-bit, prefetchable) [size=32K]
> I/O ports at e100 [size=4]
> Expansion ROM at f7d0 [disabled] [size=32K]
> Capabilities: [60] Power Management version 3
> Capabilities: [68] MSI: Enable- Count=1/32 Maskable+ 64bit+
> Capabilities: [80] Express Legacy Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Kernel driver in use: parport_serial
>
> This card was already added to the blacklist of 8250_pci.c in commit
> 72a3c0e4e662 ("tty: Add support for the WCH384 4S multi-IO card").
>
> Cc: Sergej Pupykin 
> Signed-off-by: Matt Turner 
> ---

Hi,

Can I expect this to be picked up for the 4.18 merge window?

Matt

[PATCH] parport: Add support for the WCH384 4S multi-IO card

[Matt Turner]

This Multi-IO card has one serial 16550-like serial connectors. Here's
the lspci output, after this commit is applied:

01:00.0 Serial controller [0700]: Device [1c00:3470] (rev 10) (prog-if 05 
[16850])
Subsystem: Device [1c00:3470]
Flags: fast devsel, IRQ 16
I/O ports at e000 [size=256]
Memory at f010 (32-bit, prefetchable) [size=32K]
I/O ports at e100 [size=4]
Expansion ROM at f7d0 [disabled] [size=32K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [80] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: parport_serial

This card was already added to the blacklist of 8250_pci.c in commit
72a3c0e4e662 ("tty: Add support for the WCH384 4S multi-IO card").

Cc: Sergej Pupykin <m...@sergej.pp.ru>
Signed-off-by: Matt Turner <matts...@gmail.com>
---
It looks like CH355_4S is similarly missing, but I don't have hardware
to test.

This commit makes me wonder if I'm missing something -- how could
anything have worked after commit 72a3c0e4e662 without support in
parport_serial?

 drivers/parport/parport_serial.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/parport/parport_serial.c b/drivers/parport/parport_serial.c
index e15b4845f7c6..2c166d5a0d91 100644
--- a/drivers/parport/parport_serial.c
+++ b/drivers/parport/parport_serial.c
@@ -65,6 +65,7 @@ enum parport_pc_pci_cards {
wch_ch353_1s1p,
wch_ch353_2s1p,
wch_ch382_2s1p,
+   wch_ch384_4,
sunix_2s1p,
 };
 
@@ -153,6 +154,7 @@ static struct parport_pc_pci cards[] = {
/* wch_ch353_1s1p*/ { 1, { { 1, -1}, } },
/* wch_ch353_2s1p*/ { 1, { { 2, -1}, } },
/* wch_ch382_2s1p*/ { 1, { { 2, -1}, } },
+   /* wch_ch384_4 */   { 1, { { 4, -1}, } },
/* sunix_2s1p */{ 1, { { 3, -1 }, } },
 };
 
@@ -260,6 +262,7 @@ static struct pci_device_id parport_serial_pci_tbl[] = {
{ 0x4348, 0x5053, PCI_ANY_ID, PCI_ANY_ID, 0, 0, wch_ch353_1s1p},
{ 0x4348, 0x7053, 0x4348, 0x3253, 0, 0, wch_ch353_2s1p},
{ 0x1c00, 0x3250, 0x1c00, 0x3250, 0, 0, wch_ch382_2s1p},
+   { 0x1c00, 0x3470, PCI_ANY_ID, PCI_ANY_ID, 0, 0, wch_ch384_4},
 
/*
 * More SUNIX variations. At least one of these has part number
@@ -504,6 +507,13 @@ static struct pciserial_board pci_parport_serial_boards[] 
= {
.uart_offset= 8,
.first_offset   = 0xC0,
},
+   [wch_ch384_4] = {
+   .flags  = FL_BASE0,
+   .num_ports  = 4,
+   .base_baud  = 115200,
+   .uart_offset= 8,
+   .first_offset   = 0xC0,
+   },
[sunix_2s1p] = {
.flags  = FL_BASE0|FL_BASE_BARS,
.num_ports  = 2,
-- 
2.16.1

[PATCH] parport: Add support for the WCH384 4S multi-IO card

[Matt Turner]

This Multi-IO card has one serial 16550-like serial connectors. Here's
the lspci output, after this commit is applied:

01:00.0 Serial controller [0700]: Device [1c00:3470] (rev 10) (prog-if 05 
[16850])
Subsystem: Device [1c00:3470]
Flags: fast devsel, IRQ 16
I/O ports at e000 [size=256]
Memory at f010 (32-bit, prefetchable) [size=32K]
I/O ports at e100 [size=4]
Expansion ROM at f7d0 [disabled] [size=32K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [80] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: parport_serial

This card was already added to the blacklist of 8250_pci.c in commit
72a3c0e4e662 ("tty: Add support for the WCH384 4S multi-IO card").

Cc: Sergej Pupykin 
Signed-off-by: Matt Turner 
---
It looks like CH355_4S is similarly missing, but I don't have hardware
to test.

This commit makes me wonder if I'm missing something -- how could
anything have worked after commit 72a3c0e4e662 without support in
parport_serial?

 drivers/parport/parport_serial.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/parport/parport_serial.c b/drivers/parport/parport_serial.c
index e15b4845f7c6..2c166d5a0d91 100644
--- a/drivers/parport/parport_serial.c
+++ b/drivers/parport/parport_serial.c
@@ -65,6 +65,7 @@ enum parport_pc_pci_cards {
wch_ch353_1s1p,
wch_ch353_2s1p,
wch_ch382_2s1p,
+   wch_ch384_4,
sunix_2s1p,
 };
 
@@ -153,6 +154,7 @@ static struct parport_pc_pci cards[] = {
/* wch_ch353_1s1p*/ { 1, { { 1, -1}, } },
/* wch_ch353_2s1p*/ { 1, { { 2, -1}, } },
/* wch_ch382_2s1p*/ { 1, { { 2, -1}, } },
+   /* wch_ch384_4 */   { 1, { { 4, -1}, } },
/* sunix_2s1p */{ 1, { { 3, -1 }, } },
 };
 
@@ -260,6 +262,7 @@ static struct pci_device_id parport_serial_pci_tbl[] = {
{ 0x4348, 0x5053, PCI_ANY_ID, PCI_ANY_ID, 0, 0, wch_ch353_1s1p},
{ 0x4348, 0x7053, 0x4348, 0x3253, 0, 0, wch_ch353_2s1p},
{ 0x1c00, 0x3250, 0x1c00, 0x3250, 0, 0, wch_ch382_2s1p},
+   { 0x1c00, 0x3470, PCI_ANY_ID, PCI_ANY_ID, 0, 0, wch_ch384_4},
 
/*
 * More SUNIX variations. At least one of these has part number
@@ -504,6 +507,13 @@ static struct pciserial_board pci_parport_serial_boards[] 
= {
.uart_offset= 8,
.first_offset   = 0xC0,
},
+   [wch_ch384_4] = {
+   .flags  = FL_BASE0,
+   .num_ports  = 4,
+   .base_baud  = 115200,
+   .uart_offset= 8,
+   .first_offset   = 0xC0,
+   },
[sunix_2s1p] = {
.flags  = FL_BASE0|FL_BASE_BARS,
.num_ports  = 2,
-- 
2.16.1

[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

[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.

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.

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-al...@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.

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  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  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 
>> > Signed-off-by: James Hogan 
>> > Cc: Richard Henderson 
>> > Cc: Ivan Kokshaysky 
>> > Cc: Matt Turner 
>> > Cc: linux-al...@vger.kernel.org
>>
>> Looks fine to me.
>>
>> Acked-by: Matt Turner 
>
> 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.

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-al...@vger.kernel.org

Looks fine to me.

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

Should I take it through the alpha tree?

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  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 
> Signed-off-by: James Hogan 
> Cc: Richard Henderson 
> Cc: Ivan Kokshaysky 
> Cc: Matt Turner 
> Cc: linux-al...@vger.kernel.org

Looks fine to me.

Acked-by: Matt Turner 

Should I take it through the alpha tree?

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!

Re: [PULL] alpha.git

[Matt Turner]

On Mon, Apr 9, 2018 at 9:13 AM, Linus Torvalds
 wrote:
> On Sun, Apr 8, 2018 at 11:44 AM, Matt Turner  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!

[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

[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 1/2] tools/power turbostat: Correct SNB_C1/C3_AUTO_UNDEMOTE defines

[Matt Turner]

On Tue, Feb 13, 2018 at 11:12 AM, Matt Turner <matts...@gmail.com> wrote:
> According to the Intel Software Developers' Manual, Vol. 4, Order No.
> 335592, these macros have been reversed since they were added.
>
> Fixes: 889facbee3e6 ("tools/power turbostat: v3.0: monitor Watts and 
> Temperature")
> Signed-off-by: Matt Turner <matts...@gmail.com>

Is there something I need to do to ensure these two trivial patches
get picked up?

Re: [PATCH 1/2] tools/power turbostat: Correct SNB_C1/C3_AUTO_UNDEMOTE defines

[Matt Turner]

On Tue, Feb 13, 2018 at 11:12 AM, Matt Turner  wrote:
> According to the Intel Software Developers' Manual, Vol. 4, Order No.
> 335592, these macros have been reversed since they were added.
>
> Fixes: 889facbee3e6 ("tools/power turbostat: v3.0: monitor Watts and 
> Temperature")
> Signed-off-by: Matt Turner 

Is there something I need to do to ensure these two trivial patches
get picked up?

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.

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.

[PATCH 2/2] x86: msr-index.h: Correct SNB_C1/C3_AUTO_UNDEMOTE defines

[Matt Turner]

According to the Intel Software Developers' Manual, Vol. 4, Order No.
335592, these macros have been reversed since they were added in the
initial turbostat commit. The reversed definitions were presumably
copied from turbostat.c to this file.

Fixes: 9c63a650bb10 ("tools/power/x86/turbostat: share kernel MSR #defines")
Signed-off-by: Matt Turner <matts...@gmail.com>
---
 arch/x86/include/asm/msr-index.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index c9084dedfcfa..5c6aa44568c4 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -60,8 +60,8 @@
 #define NHM_C3_AUTO_DEMOTE (1UL << 25)
 #define NHM_C1_AUTO_DEMOTE (1UL << 26)
 #define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
-#define SNB_C1_AUTO_UNDEMOTE   (1UL << 27)
-#define SNB_C3_AUTO_UNDEMOTE   (1UL << 28)
+#define SNB_C3_AUTO_UNDEMOTE   (1UL << 27)
+#define SNB_C1_AUTO_UNDEMOTE   (1UL << 28)
 
 #define MSR_MTRRcap0x00fe
 
-- 
2.13.6

[PATCH 2/2] x86: msr-index.h: Correct SNB_C1/C3_AUTO_UNDEMOTE defines

[Matt Turner]

According to the Intel Software Developers' Manual, Vol. 4, Order No.
335592, these macros have been reversed since they were added in the
initial turbostat commit. The reversed definitions were presumably
copied from turbostat.c to this file.

Fixes: 9c63a650bb10 ("tools/power/x86/turbostat: share kernel MSR #defines")
Signed-off-by: Matt Turner 
---
 arch/x86/include/asm/msr-index.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index c9084dedfcfa..5c6aa44568c4 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -60,8 +60,8 @@
 #define NHM_C3_AUTO_DEMOTE (1UL << 25)
 #define NHM_C1_AUTO_DEMOTE (1UL << 26)
 #define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
-#define SNB_C1_AUTO_UNDEMOTE   (1UL << 27)
-#define SNB_C3_AUTO_UNDEMOTE   (1UL << 28)
+#define SNB_C3_AUTO_UNDEMOTE   (1UL << 27)
+#define SNB_C1_AUTO_UNDEMOTE   (1UL << 28)
 
 #define MSR_MTRRcap0x00fe
 
-- 
2.13.6

[PATCH 1/2] tools/power turbostat: Correct SNB_C1/C3_AUTO_UNDEMOTE defines

[Matt Turner]

According to the Intel Software Developers' Manual, Vol. 4, Order No.
335592, these macros have been reversed since they were added.

Fixes: 889facbee3e6 ("tools/power turbostat: v3.0: monitor Watts and 
Temperature")
Signed-off-by: Matt Turner <matts...@gmail.com>
---
 tools/power/x86/turbostat/turbostat.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..e55dc2e626c4 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -2071,8 +2071,8 @@ dump_nhm_cst_cfg(void)
 
get_msr(base_cpu, MSR_PKG_CST_CONFIG_CONTROL, );
 
-#define SNB_C1_AUTO_UNDEMOTE  (1UL << 27)
-#define SNB_C3_AUTO_UNDEMOTE  (1UL << 28)
+#define SNB_C3_AUTO_UNDEMOTE  (1UL << 27)
+#define SNB_C1_AUTO_UNDEMOTE  (1UL << 28)
 
fprintf(outf, "cpu%d: MSR_PKG_CST_CONFIG_CONTROL: 0x%08llx", base_cpu, 
msr);
 
-- 
2.13.6

[PATCH 1/2] tools/power turbostat: Correct SNB_C1/C3_AUTO_UNDEMOTE defines

[Matt Turner]

According to the Intel Software Developers' Manual, Vol. 4, Order No.
335592, these macros have been reversed since they were added.

Fixes: 889facbee3e6 ("tools/power turbostat: v3.0: monitor Watts and 
Temperature")
Signed-off-by: Matt Turner 
---
 tools/power/x86/turbostat/turbostat.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..e55dc2e626c4 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -2071,8 +2071,8 @@ dump_nhm_cst_cfg(void)
 
get_msr(base_cpu, MSR_PKG_CST_CONFIG_CONTROL, );
 
-#define SNB_C1_AUTO_UNDEMOTE  (1UL << 27)
-#define SNB_C3_AUTO_UNDEMOTE  (1UL << 28)
+#define SNB_C3_AUTO_UNDEMOTE  (1UL << 27)
+#define SNB_C1_AUTO_UNDEMOTE  (1UL << 28)
 
fprintf(outf, "cpu%d: MSR_PKG_CST_CONFIG_CONTROL: 0x%08llx", base_cpu, 
msr);
 
-- 
2.13.6

[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 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

Re: [PULL] alpha.git

[Matt Turner]

On Tue, Jan 23, 2018 at 2:23 AM, Mikulas Patocka <mpato...@redhat.com> wrote:
>
>
> On Sat, 20 Jan 2018, Matt Turner wrote:
>
>> 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
>
> Hi
>
> Will you also submit these patches? The first one fixes a crash when
> pthread_create races with signal delivery, it could cause random crashing
> in applications.
>
> https://marc.info/?l=linux-alpha=151491969711913=2
> https://marc.info/?l=linux-alpha=151491960011839=2
> https://marc.info/?l=linux-alpha=151491963911901=2

Yes, I've already queued them up for the next merge window. I wasn't
sure if they were appropriate for 4.15 so late in the cycle. If you
think they are, I can send another pull request for 4.15.

https://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git/log/?h=alpha-next

Thanks,
Matt

Re: [PULL] alpha.git

[Matt Turner]

On Tue, Jan 23, 2018 at 2:23 AM, Mikulas Patocka  wrote:
>
>
> On Sat, 20 Jan 2018, Matt Turner wrote:
>
>> 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
>
> Hi
>
> Will you also submit these patches? The first one fixes a crash when
> pthread_create races with signal delivery, it could cause random crashing
> in applications.
>
> https://marc.info/?l=linux-alpha=151491969711913=2
> https://marc.info/?l=linux-alpha=151491960011839=2
> https://marc.info/?l=linux-alpha=151491963911901=2

Yes, I've already queued them up for the next merge window. I wasn't
sure if they were appropriate for 4.15 so late in the cycle. If you
think they are, I can send another pull request for 4.15.

https://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git/log/?h=alpha-next

Thanks,
Matt

[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

[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: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote:
>>
>> Thanks for the quick reply!
>>
>> I tried the patch on top of master, but unfortunately the corruption
>> still occurs.
>
> You might try replacing in sbdma_add_rcvbuffer()
>
> sb_new = netdev_alloc_skb(dev, size);
>
> by
>
> sb_new = alloc_skb(size, GFP_ATOMIC);
>
> Maybe the device does not like having a frame spanning 2 pages.

No such luck. I also gave changing the page size from 16K to 4K a shot
without success.

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet  wrote:
> On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote:
>>
>> Thanks for the quick reply!
>>
>> I tried the patch on top of master, but unfortunately the corruption
>> still occurs.
>
> You might try replacing in sbdma_add_rcvbuffer()
>
> sb_new = netdev_alloc_skb(dev, size);
>
> by
>
> sb_new = alloc_skb(size, GFP_ATOMIC);
>
> Maybe the device does not like having a frame spanning 2 pages.

No such luck. I also gave changing the page size from 16K to 4K a shot
without success.

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Fri, Dec 8, 2017 at 5:52 AM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Fri, 2017-12-08 at 05:42 -0800, Eric Dumazet wrote:
>> On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner <matts...@gmail.com>
>> wrote:
>> > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner <matts...@gmail.com>
>> > wrote:
>> > > On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner <matts...@gmail.com>
>> > > wrote:
>> > > > On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
>> > > > corruption on the first file read.
>> > > >
>> > > > To demonstrate, I downloaded five identical copies of the gcc-
>> > > > 5.4.0
>> > > > source tarball. On the NFS server, they hash to the same value:
>> > > >
>> > > > server distfiles # md5sum gcc-5.4.0.tar.bz2*
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>> > > >
>> > > > On the MIPS system (the NFS client):
>> > > >
>> > > > bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
>> > > > 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> > > > bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> > > > 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>> > > >
>> > > > The first file read will contain some corruption, and it is
>> > > > persistent until...
>> > > >
>> > > > bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
>> > > > bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>> > > >
>> > > > the caches are dropped, at which point it reads back properly.
>> > > >
>> > > > Note that the corruption is different across reboots, both in
>> > > > the size
>> > > > of the corruption and the location. I saw 1900~ and 1400~ byte
>> > > > sequences corrupted on separate occasions, which don't
>> > > > correspond to
>> > > > the system's 16kB page size.
>> > > >
>> > > > I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
>> > > > today). All exhibit this behavior with differing frequencies.
>> > > > Earlier
>> > > > kernels seem to reproduce the issue less often, while more
>> > > > recent
>> > > > kernels reliably exhibit the problem every boot.
>> > > >
>> > > > How can I further debug this?
>> > >
>> > > I think I was wrong about the statement about kernels v3.19 to
>> > > 4.11-rc1+. I found out I couldn't reproduce with 4.7-rc1 and then
>> > > bisected to 4cd13c21b207e80ddb1144c576500098f2d5f882 ("softirq:
>> > > Let
>> > > ksoftirqd do its job"). Still reproduces with current tip of
>> > > Linus'
>> > > tree.
>> > >
>> > > Any ideas? The board's ethernet is an uncommon device supported
>> > > by
>> > > CONFIG_SB1250_MAC. Something about the ethernet driver maybe?
>> >
>> > With the patch reverted on master (reverts cleanly), NFS corruption
>> > no
>> > longer happens.
>>
>> Hi Matt.
>>
>> Thanks for bisecting.
>>
>> Patch simply exposes an existing bug more often by changing the way
>> driver functions are scheduled.
>>
>> Which is probably a good thing.
>>
>> sbmac_intr() looks extremely suspicious to me.
>>
>> A NAPI driver hard interrupt should simply schedule NAPI.
>>
>> Apparently, if sbmac_intr() can not grab NAPIF_STATE_SCHED bit, it
>> directly calls sbdma_rx_process() from
>> hard interrupt context.
>>
>> Insane really.
>
> Please try this fix (not compiled on my x86 laptop, and I had no coffee
> yet, so it might have some trivial errors)

Thanks for the quick reply!

I tried the patch on top of master, but unfortunately the corruption
still occurs.

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Fri, Dec 8, 2017 at 5:52 AM, Eric Dumazet  wrote:
> On Fri, 2017-12-08 at 05:42 -0800, Eric Dumazet wrote:
>> On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner 
>> wrote:
>> > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner 
>> > wrote:
>> > > On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner 
>> > > wrote:
>> > > > On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
>> > > > corruption on the first file read.
>> > > >
>> > > > To demonstrate, I downloaded five identical copies of the gcc-
>> > > > 5.4.0
>> > > > source tarball. On the NFS server, they hash to the same value:
>> > > >
>> > > > server distfiles # md5sum gcc-5.4.0.tar.bz2*
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>> > > >
>> > > > On the MIPS system (the NFS client):
>> > > >
>> > > > bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
>> > > > 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> > > > bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> > > > 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>> > > >
>> > > > The first file read will contain some corruption, and it is
>> > > > persistent until...
>> > > >
>> > > > bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
>> > > > bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> > > > 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>> > > >
>> > > > the caches are dropped, at which point it reads back properly.
>> > > >
>> > > > Note that the corruption is different across reboots, both in
>> > > > the size
>> > > > of the corruption and the location. I saw 1900~ and 1400~ byte
>> > > > sequences corrupted on separate occasions, which don't
>> > > > correspond to
>> > > > the system's 16kB page size.
>> > > >
>> > > > I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
>> > > > today). All exhibit this behavior with differing frequencies.
>> > > > Earlier
>> > > > kernels seem to reproduce the issue less often, while more
>> > > > recent
>> > > > kernels reliably exhibit the problem every boot.
>> > > >
>> > > > How can I further debug this?
>> > >
>> > > I think I was wrong about the statement about kernels v3.19 to
>> > > 4.11-rc1+. I found out I couldn't reproduce with 4.7-rc1 and then
>> > > bisected to 4cd13c21b207e80ddb1144c576500098f2d5f882 ("softirq:
>> > > Let
>> > > ksoftirqd do its job"). Still reproduces with current tip of
>> > > Linus'
>> > > tree.
>> > >
>> > > Any ideas? The board's ethernet is an uncommon device supported
>> > > by
>> > > CONFIG_SB1250_MAC. Something about the ethernet driver maybe?
>> >
>> > With the patch reverted on master (reverts cleanly), NFS corruption
>> > no
>> > longer happens.
>>
>> Hi Matt.
>>
>> Thanks for bisecting.
>>
>> Patch simply exposes an existing bug more often by changing the way
>> driver functions are scheduled.
>>
>> Which is probably a good thing.
>>
>> sbmac_intr() looks extremely suspicious to me.
>>
>> A NAPI driver hard interrupt should simply schedule NAPI.
>>
>> Apparently, if sbmac_intr() can not grab NAPIF_STATE_SCHED bit, it
>> directly calls sbdma_rx_process() from
>> hard interrupt context.
>>
>> Insane really.
>
> Please try this fix (not compiled on my x86 laptop, and I had no coffee
> yet, so it might have some trivial errors)

Thanks for the quick reply!

I tried the patch on top of master, but unfortunately the corruption
still occurs.

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner <matts...@gmail.com> wrote:
> On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner <matts...@gmail.com> wrote:
>> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
>> corruption on the first file read.
>>
>> To demonstrate, I downloaded five identical copies of the gcc-5.4.0
>> source tarball. On the NFS server, they hash to the same value:
>>
>> server distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> On the MIPS system (the NFS client):
>>
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
>> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> The first file read will contain some corruption, and it is persistent 
>> until...
>>
>> bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> the caches are dropped, at which point it reads back properly.
>>
>> Note that the corruption is different across reboots, both in the size
>> of the corruption and the location. I saw 1900~ and 1400~ byte
>> sequences corrupted on separate occasions, which don't correspond to
>> the system's 16kB page size.
>>
>> I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
>> today). All exhibit this behavior with differing frequencies. Earlier
>> kernels seem to reproduce the issue less often, while more recent
>> kernels reliably exhibit the problem every boot.
>>
>> How can I further debug this?
>
> I think I was wrong about the statement about kernels v3.19 to
> 4.11-rc1+. I found out I couldn't reproduce with 4.7-rc1 and then
> bisected to 4cd13c21b207e80ddb1144c576500098f2d5f882 ("softirq: Let
> ksoftirqd do its job"). Still reproduces with current tip of Linus'
> tree.
>
> Any ideas? The board's ethernet is an uncommon device supported by
> CONFIG_SB1250_MAC. Something about the ethernet driver maybe?

With the patch reverted on master (reverts cleanly), NFS corruption no
longer happens.

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner  wrote:
> On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner  wrote:
>> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
>> corruption on the first file read.
>>
>> To demonstrate, I downloaded five identical copies of the gcc-5.4.0
>> source tarball. On the NFS server, they hash to the same value:
>>
>> server distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> On the MIPS system (the NFS client):
>>
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
>> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> The first file read will contain some corruption, and it is persistent 
>> until...
>>
>> bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> the caches are dropped, at which point it reads back properly.
>>
>> Note that the corruption is different across reboots, both in the size
>> of the corruption and the location. I saw 1900~ and 1400~ byte
>> sequences corrupted on separate occasions, which don't correspond to
>> the system's 16kB page size.
>>
>> I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
>> today). All exhibit this behavior with differing frequencies. Earlier
>> kernels seem to reproduce the issue less often, while more recent
>> kernels reliably exhibit the problem every boot.
>>
>> How can I further debug this?
>
> I think I was wrong about the statement about kernels v3.19 to
> 4.11-rc1+. I found out I couldn't reproduce with 4.7-rc1 and then
> bisected to 4cd13c21b207e80ddb1144c576500098f2d5f882 ("softirq: Let
> ksoftirqd do its job"). Still reproduces with current tip of Linus'
> tree.
>
> Any ideas? The board's ethernet is an uncommon device supported by
> CONFIG_SB1250_MAC. Something about the ethernet driver maybe?

With the patch reverted on master (reverts cleanly), NFS corruption no
longer happens.

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner <matts...@gmail.com> wrote:
> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
> corruption on the first file read.
>
> To demonstrate, I downloaded five identical copies of the gcc-5.4.0
> source tarball. On the NFS server, they hash to the same value:
>
> server distfiles # md5sum gcc-5.4.0.tar.bz2*
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>
> On the MIPS system (the NFS client):
>
> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>
> The first file read will contain some corruption, and it is persistent 
> until...
>
> bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>
> the caches are dropped, at which point it reads back properly.
>
> Note that the corruption is different across reboots, both in the size
> of the corruption and the location. I saw 1900~ and 1400~ byte
> sequences corrupted on separate occasions, which don't correspond to
> the system's 16kB page size.
>
> I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
> today). All exhibit this behavior with differing frequencies. Earlier
> kernels seem to reproduce the issue less often, while more recent
> kernels reliably exhibit the problem every boot.
>
> How can I further debug this?

I think I was wrong about the statement about kernels v3.19 to
4.11-rc1+. I found out I couldn't reproduce with 4.7-rc1 and then
bisected to 4cd13c21b207e80ddb1144c576500098f2d5f882 ("softirq: Let
ksoftirqd do its job"). Still reproduces with current tip of Linus'
tree.

Any ideas? The board's ethernet is an uncommon device supported by
CONFIG_SB1250_MAC. Something about the ethernet driver maybe?

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner  wrote:
> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
> corruption on the first file read.
>
> To demonstrate, I downloaded five identical copies of the gcc-5.4.0
> source tarball. On the NFS server, they hash to the same value:
>
> server distfiles # md5sum gcc-5.4.0.tar.bz2*
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>
> On the MIPS system (the NFS client):
>
> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>
> The first file read will contain some corruption, and it is persistent 
> until...
>
> bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>
> the caches are dropped, at which point it reads back properly.
>
> Note that the corruption is different across reboots, both in the size
> of the corruption and the location. I saw 1900~ and 1400~ byte
> sequences corrupted on separate occasions, which don't correspond to
> the system's 16kB page size.
>
> I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
> today). All exhibit this behavior with differing frequencies. Earlier
> kernels seem to reproduce the issue less often, while more recent
> kernels reliably exhibit the problem every boot.
>
> How can I further debug this?

I think I was wrong about the statement about kernels v3.19 to
4.11-rc1+. I found out I couldn't reproduce with 4.7-rc1 and then
bisected to 4cd13c21b207e80ddb1144c576500098f2d5f882 ("softirq: Let
ksoftirqd do its job"). Still reproduces with current tip of Linus'
tree.

Any ideas? The board's ethernet is an uncommon device supported by
CONFIG_SB1250_MAC. Something about the ethernet driver maybe?

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull my alpha git tree. It contains some small clean up patches I've
neglected, and some build improvements from Ben Hutchings.

Thanks,
Matt


The following changes since commit dd689a68bc3551ad7bdff2c881fede5f0bd12cfa:

 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha (2017-08-30 
14:54:24 -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 d9e3cb2f9ed91020b780ee662bdec692a3f276c9:

 alpha: math-emu: Fix modular build (2017-09-04 12:04:34 -0700)


Ben Hutchings (2):
 alpha: Restore symbol versions for symbols exported from assembly
 alpha: math-emu: Fix modular build

Dan Carpenter (1):
 alpha: silence a buffer overflow warning

Geliang Tang (1):
 alpha: use kobj_to_dev()

Julia Cartwright (1):
 alpha: marvel: make use of raw_spinlock variants

Krzysztof Kozlowski (1):
 alpha: defconfig: Cleanup from old Kconfig options

Masahiro Yamada (1):
 alpha: squash lines for immediate return

Sergei Trofimovich (1):
 alpha: cleanup: remove __NR_sys_epoll_*, leave __NR_epoll_*

Shyam Saini (1):
 alpha: kernel: Use vma_pages()

Tobias Klauser (1):
 alpha: use generic fb.h

arch/alpha/defconfig|  2 --
arch/alpha/include/asm/Kbuild   |  1 +
arch/alpha/include/asm/asm-prototypes.h | 18 ++
arch/alpha/include/asm/core_marvel.h|  2 +-
arch/alpha/include/asm/fb.h | 13 -
arch/alpha/include/uapi/asm/unistd.h|  5 -
arch/alpha/kernel/core_marvel.c |  2 +-
arch/alpha/kernel/pci-noop.c|  6 +-
arch/alpha/kernel/pci-sysfs.c   |  7 +++
arch/alpha/kernel/pci.c |  6 +-
arch/alpha/kernel/setup.c   |  5 +++--
arch/alpha/kernel/smc37c669.c   |  7 ++-
arch/alpha/kernel/sys_marvel.c  | 12 ++--
arch/alpha/kernel/traps.c   |  2 ++
arch/alpha/math-emu/math.c  |  1 +
15 files changed, 40 insertions(+), 49 deletions(-)
create mode 100644 arch/alpha/include/asm/asm-prototypes.h
delete mode 100644 arch/alpha/include/asm/fb.h


signature.asc
Description: Digital signature

[PULL] alpha.git

[Matt Turner]

Hi Linus,

Please pull my alpha git tree. It contains some small clean up patches I've
neglected, and some build improvements from Ben Hutchings.

Thanks,
Matt


The following changes since commit dd689a68bc3551ad7bdff2c881fede5f0bd12cfa:

 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha (2017-08-30 
14:54:24 -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 d9e3cb2f9ed91020b780ee662bdec692a3f276c9:

 alpha: math-emu: Fix modular build (2017-09-04 12:04:34 -0700)


Ben Hutchings (2):
 alpha: Restore symbol versions for symbols exported from assembly
 alpha: math-emu: Fix modular build

Dan Carpenter (1):
 alpha: silence a buffer overflow warning

Geliang Tang (1):
 alpha: use kobj_to_dev()

Julia Cartwright (1):
 alpha: marvel: make use of raw_spinlock variants

Krzysztof Kozlowski (1):
 alpha: defconfig: Cleanup from old Kconfig options

Masahiro Yamada (1):
 alpha: squash lines for immediate return

Sergei Trofimovich (1):
 alpha: cleanup: remove __NR_sys_epoll_*, leave __NR_epoll_*

Shyam Saini (1):
 alpha: kernel: Use vma_pages()

Tobias Klauser (1):
 alpha: use generic fb.h

arch/alpha/defconfig|  2 --
arch/alpha/include/asm/Kbuild   |  1 +
arch/alpha/include/asm/asm-prototypes.h | 18 ++
arch/alpha/include/asm/core_marvel.h|  2 +-
arch/alpha/include/asm/fb.h | 13 -
arch/alpha/include/uapi/asm/unistd.h|  5 -
arch/alpha/kernel/core_marvel.c |  2 +-
arch/alpha/kernel/pci-noop.c|  6 +-
arch/alpha/kernel/pci-sysfs.c   |  7 +++
arch/alpha/kernel/pci.c |  6 +-
arch/alpha/kernel/setup.c   |  5 +++--
arch/alpha/kernel/smc37c669.c   |  7 ++-
arch/alpha/kernel/sys_marvel.c  | 12 ++--
arch/alpha/kernel/traps.c   |  2 ++
arch/alpha/math-emu/math.c  |  1 +
15 files changed, 40 insertions(+), 49 deletions(-)
create mode 100644 arch/alpha/include/asm/asm-prototypes.h
delete mode 100644 arch/alpha/include/asm/fb.h


signature.asc
Description: Digital signature

[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

[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

[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

[PATCH] alpha: Fix section mismatches

[Matt Turner]

Signed-off-by: Matt Turner 
---
 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

[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 
---
 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

Re: is alpha jensen support dead?

[Matt Turner]

On Sun, May 21, 2017 at 1:58 AM, Christoph Hellwig  wrote:
> Hi all,
>
> it seems like the Alpha Jense build (the only one using pci-noop.c)
> and thus being a different build than all the later PCI capable
> system has been broken since at least:
>
> commit 6aca0503847f6329460b15b3ab2b0e30bb752793
> Author: Christian Borntraeger 
> Date:   Tue Feb 2 21:46:33 2016 -0800
>
> alpha/dma: use common noop dma ops
>
> which switches pci-noop.c to use generic code, but fat fingered a symbol
> and didn't wire up the Kconfig.
>
> Is there any value in keeping it alive?  Especially as there probably
> isn't any build coverage..
>
> Btw, how well is alpha working these days?  It looks like there hasn't
> been any maintainer activity for about two years.

I haven't had time for alpha stuff in quite a while.

I've never even had a Jensen, so it's never been important to me personally.

Re: is alpha jensen support dead?

[Matt Turner]

On Sun, May 21, 2017 at 1:58 AM, Christoph Hellwig  wrote:
> Hi all,
>
> it seems like the Alpha Jense build (the only one using pci-noop.c)
> and thus being a different build than all the later PCI capable
> system has been broken since at least:
>
> commit 6aca0503847f6329460b15b3ab2b0e30bb752793
> Author: Christian Borntraeger 
> Date:   Tue Feb 2 21:46:33 2016 -0800
>
> alpha/dma: use common noop dma ops
>
> which switches pci-noop.c to use generic code, but fat fingered a symbol
> and didn't wire up the Kconfig.
>
> Is there any value in keeping it alive?  Especially as there probably
> isn't any build coverage..
>
> Btw, how well is alpha working these days?  It looks like there hasn't
> been any maintainer activity for about two years.

I haven't had time for alpha stuff in quite a while.

I've never even had a Jensen, so it's never been important to me personally.

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Mon, Mar 13, 2017 at 2:47 AM, James Hogan <james.ho...@imgtec.com> wrote:
> On Sun, Mar 12, 2017 at 06:43:47PM -0700, Matt Turner wrote:
>> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
>> corruption on the first file read.
>>
>> To demonstrate, I downloaded five identical copies of the gcc-5.4.0
>> source tarball. On the NFS server, they hash to the same value:
>>
>> server distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> On the MIPS system (the NFS client):
>>
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
>> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> The first file read will contain some corruption, and it is persistent 
>> until...
>>
>> bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> the caches are dropped, at which point it reads back properly.
>>
>> Note that the corruption is different across reboots, both in the size
>> of the corruption and the location. I saw 1900~ and 1400~ byte
>> sequences corrupted on separate occasions, which don't correspond to
>> the system's 16kB page size.
>>
>> I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
>> today). All exhibit this behavior with differing frequencies. Earlier
>> kernels seem to reproduce the issue less often, while more recent
>> kernels reliably exhibit the problem every boot.
>>
>> How can I further debug this?
>
> It smells a bit like a DMA / caching issue.
>
> Can you provide a full kernel log. That might provide some information
> about caching that might be relevant (e.g. does dcache have aliases?).

Thanks for the reply. Please find attached dmesg from a clean boot
(which reproduced the problem).


dmesg
Description: Binary data

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On Mon, Mar 13, 2017 at 2:47 AM, James Hogan  wrote:
> On Sun, Mar 12, 2017 at 06:43:47PM -0700, Matt Turner wrote:
>> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
>> corruption on the first file read.
>>
>> To demonstrate, I downloaded five identical copies of the gcc-5.4.0
>> source tarball. On the NFS server, they hash to the same value:
>>
>> server distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> On the MIPS system (the NFS client):
>>
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
>> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> The first file read will contain some corruption, and it is persistent 
>> until...
>>
>> bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
>> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
>> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>>
>> the caches are dropped, at which point it reads back properly.
>>
>> Note that the corruption is different across reboots, both in the size
>> of the corruption and the location. I saw 1900~ and 1400~ byte
>> sequences corrupted on separate occasions, which don't correspond to
>> the system's 16kB page size.
>>
>> I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
>> today). All exhibit this behavior with differing frequencies. Earlier
>> kernels seem to reproduce the issue less often, while more recent
>> kernels reliably exhibit the problem every boot.
>>
>> How can I further debug this?
>
> It smells a bit like a DMA / caching issue.
>
> Can you provide a full kernel log. That might provide some information
> about caching that might be relevant (e.g. does dcache have aliases?).

Thanks for the reply. Please find attached dmesg from a clean boot
(which reproduced the problem).


dmesg
Description: Binary data

NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
corruption on the first file read.

To demonstrate, I downloaded five identical copies of the gcc-5.4.0
source tarball. On the NFS server, they hash to the same value:

server distfiles # md5sum gcc-5.4.0.tar.bz2*
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4

On the MIPS system (the NFS client):

bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4

The first file read will contain some corruption, and it is persistent until...

bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4

the caches are dropped, at which point it reads back properly.

Note that the corruption is different across reboots, both in the size
of the corruption and the location. I saw 1900~ and 1400~ byte
sequences corrupted on separate occasions, which don't correspond to
the system's 16kB page size.

I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
today). All exhibit this behavior with differing frequencies. Earlier
kernels seem to reproduce the issue less often, while more recent
kernels reliably exhibit the problem every boot.

How can I further debug this?

NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

[Matt Turner]

On a Broadcom BCM91250a MIPS system I can reliably trigger NFS
corruption on the first file read.

To demonstrate, I downloaded five identical copies of the gcc-5.4.0
source tarball. On the NFS server, they hash to the same value:

server distfiles # md5sum gcc-5.4.0.tar.bz2*
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4

On the MIPS system (the NFS client):

bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4

The first file read will contain some corruption, and it is persistent until...

bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4

the caches are dropped, at which point it reads back properly.

Note that the corruption is different across reboots, both in the size
of the corruption and the location. I saw 1900~ and 1400~ byte
sequences corrupted on separate occasions, which don't correspond to
the system's 16kB page size.

I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
today). All exhibit this behavior with differing frequencies. Earlier
kernels seem to reproduce the issue less often, while more recent
kernels reliably exhibit the problem every boot.

How can I further debug this?

Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures

[Matt Turner]

On Thu, Feb 2, 2017 at 12:12 AM, James Bottomley
 wrote:
> On Tue, 2017-01-31 at 16:26 -0800, Andrew Morton wrote:
>> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller 
>> wrote:
>>
>> > The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
>> > implemented for PowerPC only. This trivial patch adds support for
>> > this syscall for all other architectures.
>>
>> Seems reasonable.  I guess.  Why is this needed?
>
> I don't think it is other than for PPC.  If you're not variable endian
> (which is only PPC to date), then you should know a priori what endian
> you are from the #defines in userspace.

MIPS as well, but it seems strange to require the kernel to tell you
your endianness, when you can easily determine it yourself. Unless
there's something about this I don't understand.

Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures

[Matt Turner]

On Thu, Feb 2, 2017 at 12:12 AM, James Bottomley
 wrote:
> On Tue, 2017-01-31 at 16:26 -0800, Andrew Morton wrote:
>> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller 
>> wrote:
>>
>> > The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
>> > implemented for PowerPC only. This trivial patch adds support for
>> > this syscall for all other architectures.
>>
>> Seems reasonable.  I guess.  Why is this needed?
>
> I don't think it is other than for PPC.  If you're not variable endian
> (which is only PPC to date), then you should know a priori what endian
> you are from the #defines in userspace.

MIPS as well, but it seems strange to require the kernel to tell you
your endianness, when you can easily determine it yourself. Unless
there's something about this I don't understand.

Re: [PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

On Sat, Dec 3, 2016 at 1:52 AM, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Sat, 03 Dec 2016, Matt Turner <matts...@gmail.com> wrote:
>> From these instructions, users assume that /sys/class/drm/card0/error
>> contains all the information a developer needs to diagnose and fix a GPU
>> hang.
>>
>> In fact it doesn't, and we have no tools for solving them (other than
>> stabbing in the dark). Most of the time the error state itself isn't
>> even useful because it just shows a hang on a PIPE_CONTROL or similar.
>>
>> Until a time when the error state contains enough information to
>> actually solve a hang, stop telling users to file unsolvable bugs, and
>> instead rely on users who know where and how to file a good bug report
>> to find their own way there.
>>
>> Signed-off-by: Matt Turner <matts...@gmail.com>
>> ---
>> Maybe now's a good time to discuss what *would* be useful to put in the
>> error state for debugging hangs. The currently executing shader program
>> would be a great place to start.
>
> I'm wondering why we're getting this patch now, and my guess is that
> it's because we have been reassigning the related bugs to Mesa more
> actively lately. Is that the case?

No, it's simply because I spent a week going through Bugzilla and
realized how incomplete an unactionable the majority of GPU hang
reports are.

Asking users to report bugs, but not telling them what actually
constitutes a bug report, is a recipe for a lot of wasted developer
time.

I suspect we could improve the usefulness of the reports by directing
users to a webpage that gave a few suggestions (tell us what you were
doing when the hang occurred would be an obvious one) about filing a
bug and then provided a link to Bugzilla. Or even configured Bugzilla
to have a default template that requested various bits of information.

> IIUC the bug reports are useful for us when it's a kernel bug, but less
> useful for you when it's a Mesa bug. And you'd rather have fewer
> incoming bugs that you think are unsolvable with the information at
> hand.
>
> Sounds like a bug workflow issue between drm/i915 and Mesa to be ironed
> out.

Indeed. I'd rather have the information provided in a bug report to
actually solve it. I hope having access to the shader program will
make many more reports useful.

I am also happy to see that there's now a sunset to the GPU hang message.

Re: [PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

On Sat, Dec 3, 2016 at 1:52 AM, Jani Nikula  wrote:
> On Sat, 03 Dec 2016, Matt Turner  wrote:
>> From these instructions, users assume that /sys/class/drm/card0/error
>> contains all the information a developer needs to diagnose and fix a GPU
>> hang.
>>
>> In fact it doesn't, and we have no tools for solving them (other than
>> stabbing in the dark). Most of the time the error state itself isn't
>> even useful because it just shows a hang on a PIPE_CONTROL or similar.
>>
>> Until a time when the error state contains enough information to
>> actually solve a hang, stop telling users to file unsolvable bugs, and
>> instead rely on users who know where and how to file a good bug report
>> to find their own way there.
>>
>> Signed-off-by: Matt Turner 
>> ---
>> Maybe now's a good time to discuss what *would* be useful to put in the
>> error state for debugging hangs. The currently executing shader program
>> would be a great place to start.
>
> I'm wondering why we're getting this patch now, and my guess is that
> it's because we have been reassigning the related bugs to Mesa more
> actively lately. Is that the case?

No, it's simply because I spent a week going through Bugzilla and
realized how incomplete an unactionable the majority of GPU hang
reports are.

Asking users to report bugs, but not telling them what actually
constitutes a bug report, is a recipe for a lot of wasted developer
time.

I suspect we could improve the usefulness of the reports by directing
users to a webpage that gave a few suggestions (tell us what you were
doing when the hang occurred would be an obvious one) about filing a
bug and then provided a link to Bugzilla. Or even configured Bugzilla
to have a default template that requested various bits of information.

> IIUC the bug reports are useful for us when it's a kernel bug, but less
> useful for you when it's a Mesa bug. And you'd rather have fewer
> incoming bugs that you think are unsolvable with the information at
> hand.
>
> Sounds like a bug workflow issue between drm/i915 and Mesa to be ironed
> out.

Indeed. I'd rather have the information provided in a bug report to
actually solve it. I hope having access to the shader program will
make many more reports useful.

I am also happy to see that there's now a sunset to the GPU hang message.

Re: [PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

On Fri, Dec 2, 2016 at 5:03 PM, Matt Turner <matts...@gmail.com> wrote:
> From these instructions, users assume that /sys/class/drm/card0/error
> contains all the information a developer needs to diagnose and fix a GPU
> hang.
>
> In fact it doesn't, and we have no tools for solving them (other than
> stabbing in the dark). Most of the time the error state itself isn't
> even useful because it just shows a hang on a PIPE_CONTROL or similar.
>
> Until a time when the error state contains enough information to
> actually solve a hang, stop telling users to file unsolvable bugs, and
> instead rely on users who know where and how to file a good bug report
> to find their own way there.
>
> Signed-off-by: Matt Turner <matts...@gmail.com>
> ---
> Maybe now's a good time to discuss what *would* be useful to put in the
> error state for debugging hangs. The currently executing shader program
> would be a great place to start.

Looks like Ben had a patch:

https://cgit.freedesktop.org/~bwidawsk/drm-intel/commit/?h=extra_error_objs=711da2570cd3302d0cb9f2489a101e4a7c966a6c

Re: [PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

On Fri, Dec 2, 2016 at 5:03 PM, Matt Turner  wrote:
> From these instructions, users assume that /sys/class/drm/card0/error
> contains all the information a developer needs to diagnose and fix a GPU
> hang.
>
> In fact it doesn't, and we have no tools for solving them (other than
> stabbing in the dark). Most of the time the error state itself isn't
> even useful because it just shows a hang on a PIPE_CONTROL or similar.
>
> Until a time when the error state contains enough information to
> actually solve a hang, stop telling users to file unsolvable bugs, and
> instead rely on users who know where and how to file a good bug report
> to find their own way there.
>
> Signed-off-by: Matt Turner 
> ---
> Maybe now's a good time to discuss what *would* be useful to put in the
> error state for debugging hangs. The currently executing shader program
> would be a great place to start.

Looks like Ben had a patch:

https://cgit.freedesktop.org/~bwidawsk/drm-intel/commit/?h=extra_error_objs=711da2570cd3302d0cb9f2489a101e4a7c966a6c

[PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

>From these instructions, users assume that /sys/class/drm/card0/error
contains all the information a developer needs to diagnose and fix a GPU
hang.

In fact it doesn't, and we have no tools for solving them (other than
stabbing in the dark). Most of the time the error state itself isn't
even useful because it just shows a hang on a PIPE_CONTROL or similar.

Until a time when the error state contains enough information to
actually solve a hang, stop telling users to file unsolvable bugs, and
instead rely on users who know where and how to file a good bug report
to find their own way there.

Signed-off-by: Matt Turner <matts...@gmail.com>
---
Maybe now's a good time to discuss what *would* be useful to put in the
error state for debugging hangs. The currently executing shader program
would be a great place to start.

 drivers/gpu/drm/i915/i915_gpu_error.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 334f15d..8ddca7b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1431,7 +1431,6 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
  u32 engine_mask,
  const char *error_msg)
 {
-   static bool warned;
struct drm_i915_error_state *error;
unsigned long flags;
 
@@ -1475,16 +1474,6 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
i915_error_state_free(>ref);
return;
}
-
-   if (!warned) {
-   DRM_INFO("GPU hangs can indicate a bug anywhere in the entire 
gfx stack, including userspace.\n");
-   DRM_INFO("Please file a _new_ bug report on 
bugs.freedesktop.org against DRI -> DRM/Intel\n");
-   DRM_INFO("drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.\n");
-   DRM_INFO("The gpu crash dump is required to analyze gpu hangs, 
so please always attach it.\n");
-   DRM_INFO("GPU crash dump saved to 
/sys/class/drm/card%d/error\n",
-dev_priv->drm.primary->index);
-   warned = true;
-   }
 }
 
 void i915_error_state_get(struct drm_device *dev,
-- 
2.7.3

[PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

>From these instructions, users assume that /sys/class/drm/card0/error
contains all the information a developer needs to diagnose and fix a GPU
hang.

In fact it doesn't, and we have no tools for solving them (other than
stabbing in the dark). Most of the time the error state itself isn't
even useful because it just shows a hang on a PIPE_CONTROL or similar.

Until a time when the error state contains enough information to
actually solve a hang, stop telling users to file unsolvable bugs, and
instead rely on users who know where and how to file a good bug report
to find their own way there.

Signed-off-by: Matt Turner 
---
Maybe now's a good time to discuss what *would* be useful to put in the
error state for debugging hangs. The currently executing shader program
would be a great place to start.

 drivers/gpu/drm/i915/i915_gpu_error.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 334f15d..8ddca7b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1431,7 +1431,6 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
  u32 engine_mask,
  const char *error_msg)
 {
-   static bool warned;
struct drm_i915_error_state *error;
unsigned long flags;
 
@@ -1475,16 +1474,6 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
i915_error_state_free(>ref);
return;
}
-
-   if (!warned) {
-   DRM_INFO("GPU hangs can indicate a bug anywhere in the entire 
gfx stack, including userspace.\n");
-   DRM_INFO("Please file a _new_ bug report on 
bugs.freedesktop.org against DRI -> DRM/Intel\n");
-   DRM_INFO("drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.\n");
-   DRM_INFO("The gpu crash dump is required to analyze gpu hangs, 
so please always attach it.\n");
-   DRM_INFO("GPU crash dump saved to 
/sys/class/drm/card%d/error\n",
-dev_priv->drm.primary->index);
-   warned = true;
-   }
 }
 
 void i915_error_state_get(struct drm_device *dev,
-- 
2.7.3

Re: [RFC PATCH 7/9] alpha: allocate sys_membarrier system call number

[Matt Turner]

On Thu, Aug 27, 2015 at 10:56 AM, Mathieu Desnoyers
 wrote:
> [ Untested on this architecture. To try it out: fetch linux-next/akpm,
>   apply this patch, build/run a membarrier-enabled kernel, and do make
>   kselftest. ]
>
> Signed-off-by: Mathieu Desnoyers 
> CC: Andrew Morton 
> CC: linux-...@vger.kernel.org
> CC: Richard Henderson 
> CC: Ivan Kokshaysky 
> CC: Matt Turner 
> CC: linux-al...@vger.kernel.org
> ---
>  arch/alpha/include/uapi/asm/unistd.h | 1 +
>  arch/alpha/kernel/systbls.S  | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/arch/alpha/include/uapi/asm/unistd.h 
> b/arch/alpha/include/uapi/asm/unistd.h
> index aa33bf5..7725619 100644
> --- a/arch/alpha/include/uapi/asm/unistd.h
> +++ b/arch/alpha/include/uapi/asm/unistd.h
> @@ -475,5 +475,6 @@
>  #define __NR_getrandom 511
>  #define __NR_memfd_create  512
>  #define __NR_execveat  513
> +#define __NR_membarrier514

NR_SYSCALLS in arch/alpha/include/asm/unistd.h needs to be updated as well.

>
>  #endif /* _UAPI_ALPHA_UNISTD_H */
> diff --git a/arch/alpha/kernel/systbls.S b/arch/alpha/kernel/systbls.S
> index 9b62e3f..1ea64f4 100644
> --- a/arch/alpha/kernel/systbls.S
> +++ b/arch/alpha/kernel/systbls.S
> @@ -532,6 +532,7 @@ sys_call_table:
> .quad sys_getrandom
> .quad sys_memfd_create
> .quad sys_execveat
> +   .quad sys_membarrier
>
> .size sys_call_table, . - sys_call_table
> .type sys_call_table, @object
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 7/9] alpha: allocate sys_membarrier system call number

[Matt Turner]

On Thu, Aug 27, 2015 at 10:56 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
 [ Untested on this architecture. To try it out: fetch linux-next/akpm,
   apply this patch, build/run a membarrier-enabled kernel, and do make
   kselftest. ]

 Signed-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com
 CC: Andrew Morton a...@linux-foundation.org
 CC: linux-...@vger.kernel.org
 CC: Richard Henderson r...@twiddle.net
 CC: Ivan Kokshaysky i...@jurassic.park.msu.ru
 CC: Matt Turner matts...@gmail.com
 CC: linux-al...@vger.kernel.org
 ---
  arch/alpha/include/uapi/asm/unistd.h | 1 +
  arch/alpha/kernel/systbls.S  | 1 +
  2 files changed, 2 insertions(+)

 diff --git a/arch/alpha/include/uapi/asm/unistd.h 
 b/arch/alpha/include/uapi/asm/unistd.h
 index aa33bf5..7725619 100644
 --- a/arch/alpha/include/uapi/asm/unistd.h
 +++ b/arch/alpha/include/uapi/asm/unistd.h
 @@ -475,5 +475,6 @@
  #define __NR_getrandom 511
  #define __NR_memfd_create  512
  #define __NR_execveat  513
 +#define __NR_membarrier514

NR_SYSCALLS in arch/alpha/include/asm/unistd.h needs to be updated as well.


  #endif /* _UAPI_ALPHA_UNISTD_H */
 diff --git a/arch/alpha/kernel/systbls.S b/arch/alpha/kernel/systbls.S
 index 9b62e3f..1ea64f4 100644
 --- a/arch/alpha/kernel/systbls.S
 +++ b/arch/alpha/kernel/systbls.S
 @@ -532,6 +532,7 @@ sys_call_table:
 .quad sys_getrandom
 .quad sys_memfd_create
 .quad sys_execveat
 +   .quad sys_membarrier

 .size sys_call_table, . - sys_call_table
 .type sys_call_table, @object
 --
 1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] alpha: select CONFIG_ARCH_USE_CMPXCHG_LOCKREF.

[Matt Turner]

On Alpha we have spinlocks that are 32b in size and an efficient
cmpxchg64 implementation, so we qualify to make use of cmpxchg backed
lockrefs. Select the ARCH_USE_CMPXCHG_LOCKREF Kconfig symbol and provide
a trivial implementation of arch_spin_value_unlocked to satisfy the
lockref code.

Using Linus' simple testcase from
http://article.gmane.org/gmane.linux.file-systems/77466 on a dual CPU
ES47 system I see around an 8% gain:

N   Min   MaxMedian   Avg  Stddev
x  30   6194580   6295654   6272504   6272514   17694.232
+  30   6731164   6786334   6767982   6764274   13738.863
Difference at 95.0% confidence
491760 +/- 8188.17
7.83992% +/- 0.130541%
(Student's t, pooled s = 15840.5)

Signed-off-by: Matt Turner 
---
 arch/alpha/Kconfig| 1 +
 arch/alpha/include/asm/spinlock.h | 5 +
 2 files changed, 6 insertions(+)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index bf9e9d3..f515a4d 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -3,6 +3,7 @@ config ALPHA
default y
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
+   select ARCH_USE_CMPXCHG_LOCKREF
select HAVE_AOUT
select HAVE_IDE
select HAVE_OPROFILE
diff --git a/arch/alpha/include/asm/spinlock.h 
b/arch/alpha/include/asm/spinlock.h
index 37b570d..fed9c6f 100644
--- a/arch/alpha/include/asm/spinlock.h
+++ b/arch/alpha/include/asm/spinlock.h
@@ -16,6 +16,11 @@
 #define arch_spin_unlock_wait(x) \
do { cpu_relax(); } while ((x)->lock)
 
+static inline int arch_spin_value_unlocked(arch_spinlock_t lock)
+{
+return lock.lock == 0;
+}
+
 static inline void arch_spin_unlock(arch_spinlock_t * lock)
 {
mb();
-- 
2.3.6

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

[PATCH] alpha: select CONFIG_ARCH_USE_CMPXCHG_LOCKREF.

[Matt Turner]

On Alpha we have spinlocks that are 32b in size and an efficient
cmpxchg64 implementation, so we qualify to make use of cmpxchg backed
lockrefs. Select the ARCH_USE_CMPXCHG_LOCKREF Kconfig symbol and provide
a trivial implementation of arch_spin_value_unlocked to satisfy the
lockref code.

Using Linus' simple testcase from
http://article.gmane.org/gmane.linux.file-systems/77466 on a dual CPU
ES47 system I see around an 8% gain:

N   Min   MaxMedian   Avg  Stddev
x  30   6194580   6295654   6272504   6272514   17694.232
+  30   6731164   6786334   6767982   6764274   13738.863
Difference at 95.0% confidence
491760 +/- 8188.17
7.83992% +/- 0.130541%
(Student's t, pooled s = 15840.5)

Signed-off-by: Matt Turner matts...@gmail.com
---
 arch/alpha/Kconfig| 1 +
 arch/alpha/include/asm/spinlock.h | 5 +
 2 files changed, 6 insertions(+)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index bf9e9d3..f515a4d 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -3,6 +3,7 @@ config ALPHA
default y
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
+   select ARCH_USE_CMPXCHG_LOCKREF
select HAVE_AOUT
select HAVE_IDE
select HAVE_OPROFILE
diff --git a/arch/alpha/include/asm/spinlock.h 
b/arch/alpha/include/asm/spinlock.h
index 37b570d..fed9c6f 100644
--- a/arch/alpha/include/asm/spinlock.h
+++ b/arch/alpha/include/asm/spinlock.h
@@ -16,6 +16,11 @@
 #define arch_spin_unlock_wait(x) \
do { cpu_relax(); } while ((x)-lock)
 
+static inline int arch_spin_value_unlocked(arch_spinlock_t lock)
+{
+return lock.lock == 0;
+}
+
 static inline void arch_spin_unlock(arch_spinlock_t * lock)
 {
mb();
-- 
2.3.6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/15] alpha: don't use module_init for non-modular core code

[Matt Turner]

On Thu, May 28, 2015 at 5:48 PM, Paul Gortmaker
 wrote:
> The srm console is always built in.  It will never be modular,
> so using module_init as an alias for __initcall is rather
> misleading.
>
> Fix this up now, so that we can relocate module_init from
> init.h into module.h in the future.  If we don't do this, we'd
> have to add module.h to obviously non-modular code, and that
> would be a worse thing.
>
> Direct use of __initcall is discouraged, vs prioritized ones.
> Use of device_initcall is consistent with what __initcall
> maps onto, and hence does not change the init order, making the
> impact of this change zero.   Should someone with real hardware
> for boot testing want to change it later to arch_initcall or
> console_initcall, they can do that at a later date.
>
> Cc: Richard Henderson 
> Reviewed-by: Richard Henderson 
> Cc: Ivan Kokshaysky 
> Cc: Matt Turner 
> Cc: linux-al...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 
> ---

I included this in my pull request to Linus that went upstream
yesterday. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/15] alpha: don't use module_init for non-modular core code

[Matt Turner]

On Thu, May 28, 2015 at 5:48 PM, Paul Gortmaker
paul.gortma...@windriver.com wrote:
 The srm console is always built in.  It will never be modular,
 so using module_init as an alias for __initcall is rather
 misleading.

 Fix this up now, so that we can relocate module_init from
 init.h into module.h in the future.  If we don't do this, we'd
 have to add module.h to obviously non-modular code, and that
 would be a worse thing.

 Direct use of __initcall is discouraged, vs prioritized ones.
 Use of device_initcall is consistent with what __initcall
 maps onto, and hence does not change the init order, making the
 impact of this change zero.   Should someone with real hardware
 for boot testing want to change it later to arch_initcall or
 console_initcall, they can do that at a later date.

 Cc: Richard Henderson r...@twiddle.net
 Reviewed-by: Richard Henderson r...@twiddle.net
 Cc: Ivan Kokshaysky i...@jurassic.park.msu.ru
 Cc: Matt Turner matts...@gmail.com
 Cc: linux-al...@vger.kernel.org
 Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
 ---

I included this in my pull request to Linus that went upstream
yesterday. Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arch: alpha: kernel: remove deprecated call to pci_get_slot

[Matt Turner]

On Thu, Feb 5, 2015 at 1:17 PM, Pierre Chevalier
 wrote:
> According to Documentation/PCI/pci.txt, pci_get_slot has been
> superseded by pci_get_domain_bus_and_slot.
>
> Signed-off-by: Pierre Chevalier 
> ---
>  arch/alpha/kernel/sys_miata.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/alpha/kernel/sys_miata.c b/arch/alpha/kernel/sys_miata.c
> index d5b9776..7b98b40 100644
> --- a/arch/alpha/kernel/sys_miata.c
> +++ b/arch/alpha/kernel/sys_miata.c
> @@ -182,7 +182,8 @@ miata_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
>
> if((slot == 7) && (PCI_FUNC(dev->devfn) == 3)) {
> u8 irq=0;
> -   struct pci_dev *pdev = pci_get_slot(dev->bus, dev->devfn & 
> ~7);
> +   struct pci_dev *pdev =
> +   pci_get_domain_bus_and_slot(dev->bus, dev->devfn & 
> ~7);

Given that pci_get_domain_bus_and_slot takes three arguments, I don't
think this compiles.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arch: alpha: kernel: remove deprecated call to pci_get_slot

[Matt Turner]

On Thu, Feb 5, 2015 at 1:17 PM, Pierre Chevalier
pierrechevalie...@gmail.com wrote:
 According to Documentation/PCI/pci.txt, pci_get_slot has been
 superseded by pci_get_domain_bus_and_slot.

 Signed-off-by: Pierre Chevalier pierrechevalie...@gmail.com
 ---
  arch/alpha/kernel/sys_miata.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/arch/alpha/kernel/sys_miata.c b/arch/alpha/kernel/sys_miata.c
 index d5b9776..7b98b40 100644
 --- a/arch/alpha/kernel/sys_miata.c
 +++ b/arch/alpha/kernel/sys_miata.c
 @@ -182,7 +182,8 @@ miata_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)

 if((slot == 7)  (PCI_FUNC(dev-devfn) == 3)) {
 u8 irq=0;
 -   struct pci_dev *pdev = pci_get_slot(dev-bus, dev-devfn  
 ~7);
 +   struct pci_dev *pdev =
 +   pci_get_domain_bus_and_slot(dev-bus, dev-devfn  
 ~7);

Given that pci_get_domain_bus_and_slot takes three arguments, I don't
think this compiles.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alpha: Wire up missing syscalls

[Matt Turner]

On Tue, May 12, 2015 at 1:59 AM, Michael Cree  wrote:
> On Sun, May 10, 2015 at 02:33:36AM +0800, Chen Gang wrote:
>> The related warnings:
>>
>> CALLscripts/checksyscalls.sh
>>   :1238:2: warning: #warning syscall seccomp not implemented [-Wcpp]
>>   :1241:2: warning: #warning syscall getrandom not implemented [-Wcpp]
>>   :1244:2: warning: #warning syscall memfd_create not implemented 
>> [-Wcpp]
>>   :1247:2: warning: #warning syscall bpf not implemented [-Wcpp]
>>   :1250:2: warning: #warning syscall execveat not implemented [-Wcpp]
>
> Chen: Have you tested the syscalls you have wired up?
>
> I have a suspicion that more is required to wire up the seccomp
> syscall.  At least some of the other older architectures had to
> implement some extra arch dependent support to implement the seccomp
> syscall.  I don't know whether this is necessary or not on Alpha so
> was wondering if this has been considered?
>
> Matt:  are you still feeding Alpha patches to Linus?  I suspect there
> might be a few other patches other than this one submitted to
> linux-alpha that should be applied.

I haven't been for a while, but I do want to get back to it. I have a
bunch of patches marked that I need to collect.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alpha: Wire up missing syscalls

[Matt Turner]

On Tue, May 12, 2015 at 1:59 AM, Michael Cree mc...@orcon.net.nz wrote:
 On Sun, May 10, 2015 at 02:33:36AM +0800, Chen Gang wrote:
 The related warnings:

 CALLscripts/checksyscalls.sh
   stdin:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp]
   stdin:1241:2: warning: #warning syscall getrandom not implemented [-Wcpp]
   stdin:1244:2: warning: #warning syscall memfd_create not implemented 
 [-Wcpp]
   stdin:1247:2: warning: #warning syscall bpf not implemented [-Wcpp]
   stdin:1250:2: warning: #warning syscall execveat not implemented [-Wcpp]

 Chen: Have you tested the syscalls you have wired up?

 I have a suspicion that more is required to wire up the seccomp
 syscall.  At least some of the other older architectures had to
 implement some extra arch dependent support to implement the seccomp
 syscall.  I don't know whether this is necessary or not on Alpha so
 was wondering if this has been considered?

 Matt:  are you still feeding Alpha patches to Linus?  I suspect there
 might be a few other patches other than this one submitted to
 linux-alpha that should be applied.

I haven't been for a while, but I do want to get back to it. I have a
bunch of patches marked that I need to collect.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] llist: Fix missing lockless_dereference()

[Matt Turner]

On Sat, Feb 7, 2015 at 2:30 PM, Mathieu Desnoyers
 wrote:
> - Original Message -
>> From: "Greg KH" 
>> To: "Mathieu Desnoyers" 
>> Cc: "Huang Ying" , linux-kernel@vger.kernel.org, "Paul 
>> McKenney" ,
>> "David Howells" , "Pranith Kumar" 
>> , sta...@vger.kernel.org
>> Sent: Saturday, February 7, 2015 5:16:25 PM
>> Subject: Re: [PATCH] llist: Fix missing lockless_dereference()
>>
>> On Fri, Feb 06, 2015 at 09:08:21PM -0500, Mathieu Desnoyers wrote:
>> > A lockless_dereference() appears to be missing in llist_del_first().
>> > It should only matter for Alpha in practice.
>>
>> Meta-comment, do we really care about Alpha anymore?  Is it still
>> consered an "active" arch we support?  I haven't seen a single
>> alpha-related stable patch in _years_ if at all, which implies to me
>> that no one is even using it.
>>
>> Not that stable patches for architectures are a valid reference for how
>> much they are used, but it does give me a good indication of what arches
>> have users that actually care about a modern (i.e. within the past 5
>> years) kernel.
>
> Good question. Adding the Alpha maintainers to the CC.
>
> Thanks,
>
> Mathieu

Hello,

Yes, Gentoo has a maintained Alpha port. We care about having modern
kernels (though I have not personally had a lot of time to work on
that recently)

Thanks,
Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] llist: Fix missing lockless_dereference()

[Matt Turner]

On Sat, Feb 7, 2015 at 2:30 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
 - Original Message -
 From: Greg KH gre...@linuxfoundation.org
 To: Mathieu Desnoyers mathieu.desnoy...@efficios.com
 Cc: Huang Ying ying.hu...@intel.com, linux-kernel@vger.kernel.org, Paul 
 McKenney paul...@linux.vnet.ibm.com,
 David Howells dhowe...@redhat.com, Pranith Kumar 
 bobby.pr...@gmail.com, sta...@vger.kernel.org
 Sent: Saturday, February 7, 2015 5:16:25 PM
 Subject: Re: [PATCH] llist: Fix missing lockless_dereference()

 On Fri, Feb 06, 2015 at 09:08:21PM -0500, Mathieu Desnoyers wrote:
  A lockless_dereference() appears to be missing in llist_del_first().
  It should only matter for Alpha in practice.

 Meta-comment, do we really care about Alpha anymore?  Is it still
 consered an active arch we support?  I haven't seen a single
 alpha-related stable patch in _years_ if at all, which implies to me
 that no one is even using it.

 Not that stable patches for architectures are a valid reference for how
 much they are used, but it does give me a good indication of what arches
 have users that actually care about a modern (i.e. within the past 5
 years) kernel.

 Good question. Adding the Alpha maintainers to the CC.

 Thanks,

 Mathieu

Hello,

Yes, Gentoo has a maintained Alpha port. We care about having modern
kernels (though I have not personally had a lot of time to work on
that recently)

Thanks,
Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] alpha: Wire up sched_setattr, sched_getattr, and renameat2 syscalls.

[Matt Turner]

From: Michael Cree 

Signed-off-by: Michael Cree 
Signed-off-by: Matt Turner 
---
 arch/alpha/include/asm/unistd.h  | 2 +-
 arch/alpha/include/uapi/asm/unistd.h | 3 +++
 arch/alpha/kernel/systbls.S  | 3 +++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/include/asm/unistd.h b/arch/alpha/include/asm/unistd.h
index f2c9440..c509d30 100644
--- a/arch/alpha/include/asm/unistd.h
+++ b/arch/alpha/include/asm/unistd.h
@@ -3,7 +3,7 @@
 
 #include 
 
-#define NR_SYSCALLS508
+#define NR_SYSCALLS511
 
 #define __ARCH_WANT_OLD_READDIR
 #define __ARCH_WANT_STAT64
diff --git a/arch/alpha/include/uapi/asm/unistd.h 
b/arch/alpha/include/uapi/asm/unistd.h
index 53ae7bb..d214a035 100644
--- a/arch/alpha/include/uapi/asm/unistd.h
+++ b/arch/alpha/include/uapi/asm/unistd.h
@@ -469,5 +469,8 @@
 #define __NR_process_vm_writev 505
 #define __NR_kcmp  506
 #define __NR_finit_module  507
+#define __NR_sched_setattr 508
+#define __NR_sched_getattr 509
+#define __NR_renameat2 510
 
 #endif /* _UAPI_ALPHA_UNISTD_H */
diff --git a/arch/alpha/kernel/systbls.S b/arch/alpha/kernel/systbls.S
index dca9b3f..2478971 100644
--- a/arch/alpha/kernel/systbls.S
+++ b/arch/alpha/kernel/systbls.S
@@ -526,6 +526,9 @@ sys_call_table:
.quad sys_process_vm_writev /* 505 */
.quad sys_kcmp
.quad sys_finit_module
+   .quad sys_sched_setattr
+   .quad sys_sched_getattr
+   .quad sys_renameat2 /* 510 */
 
.size sys_call_table, . - sys_call_table
.type sys_call_table, @object
-- 
1.8.5.5

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

[PATCH 2/2] alpha: io: implement relaxed accessor macros for writes

[Matt Turner]

From: Will Deacon 

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O writes with weaker barrier semantics than the
non-relaxed variants.

This patch implements these write macros for Alpha, in the same vein as
the relaxed read macros, which are already implemented.

Acked-by: Richard Henderson 
Cc: Ivan Kokshaysky 
Signed-off-by: Will Deacon 
Signed-off-by: Matt Turner 
---
 arch/alpha/include/asm/io.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index 5ebab58..f05bdb4 100644
--- a/arch/alpha/include/asm/io.h
+++ b/arch/alpha/include/asm/io.h
@@ -500,10 +500,14 @@ extern inline void writeq(u64 b, volatile void __iomem 
*addr)
 #define outb_p outb
 #define outw_p outw
 #define outl_p outl
-#define readb_relaxed(addr) __raw_readb(addr)
-#define readw_relaxed(addr) __raw_readw(addr)
-#define readl_relaxed(addr) __raw_readl(addr)
-#define readq_relaxed(addr) __raw_readq(addr)
+#define readb_relaxed(addr)__raw_readb(addr)
+#define readw_relaxed(addr)__raw_readw(addr)
+#define readl_relaxed(addr)__raw_readl(addr)
+#define readq_relaxed(addr)__raw_readq(addr)
+#define writeb_relaxed(b, addr)__raw_writeb(b, addr)
+#define writew_relaxed(b, addr)__raw_writew(b, addr)
+#define writel_relaxed(b, addr)__raw_writel(b, addr)
+#define writeq_relaxed(b, addr)__raw_writeq(b, addr)
 
 #define mmiowb()
 
-- 
1.8.5.5

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

[PATCH 2/2] alpha: io: implement relaxed accessor macros for writes

[Matt Turner]

From: Will Deacon will.dea...@arm.com

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O writes with weaker barrier semantics than the
non-relaxed variants.

This patch implements these write macros for Alpha, in the same vein as
the relaxed read macros, which are already implemented.

Acked-by: Richard Henderson r...@twiddle.net
Cc: Ivan Kokshaysky i...@jurassic.park.msu.ru
Signed-off-by: Will Deacon will.dea...@arm.com
Signed-off-by: Matt Turner matts...@gmail.com
---
 arch/alpha/include/asm/io.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index 5ebab58..f05bdb4 100644
--- a/arch/alpha/include/asm/io.h
+++ b/arch/alpha/include/asm/io.h
@@ -500,10 +500,14 @@ extern inline void writeq(u64 b, volatile void __iomem 
*addr)
 #define outb_p outb
 #define outw_p outw
 #define outl_p outl
-#define readb_relaxed(addr) __raw_readb(addr)
-#define readw_relaxed(addr) __raw_readw(addr)
-#define readl_relaxed(addr) __raw_readl(addr)
-#define readq_relaxed(addr) __raw_readq(addr)
+#define readb_relaxed(addr)__raw_readb(addr)
+#define readw_relaxed(addr)__raw_readw(addr)
+#define readl_relaxed(addr)__raw_readl(addr)
+#define readq_relaxed(addr)__raw_readq(addr)
+#define writeb_relaxed(b, addr)__raw_writeb(b, addr)
+#define writew_relaxed(b, addr)__raw_writew(b, addr)
+#define writel_relaxed(b, addr)__raw_writel(b, addr)
+#define writeq_relaxed(b, addr)__raw_writeq(b, addr)
 
 #define mmiowb()
 
-- 
1.8.5.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] alpha: Wire up sched_setattr, sched_getattr, and renameat2 syscalls.

[Matt Turner]

From: Michael Cree mc...@orcon.net.nz

Signed-off-by: Michael Cree mc...@orcon.net.nz
Signed-off-by: Matt Turner matts...@gmail.com
---
 arch/alpha/include/asm/unistd.h  | 2 +-
 arch/alpha/include/uapi/asm/unistd.h | 3 +++
 arch/alpha/kernel/systbls.S  | 3 +++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/include/asm/unistd.h b/arch/alpha/include/asm/unistd.h
index f2c9440..c509d30 100644
--- a/arch/alpha/include/asm/unistd.h
+++ b/arch/alpha/include/asm/unistd.h
@@ -3,7 +3,7 @@
 
 #include uapi/asm/unistd.h
 
-#define NR_SYSCALLS508
+#define NR_SYSCALLS511
 
 #define __ARCH_WANT_OLD_READDIR
 #define __ARCH_WANT_STAT64
diff --git a/arch/alpha/include/uapi/asm/unistd.h 
b/arch/alpha/include/uapi/asm/unistd.h
index 53ae7bb..d214a035 100644
--- a/arch/alpha/include/uapi/asm/unistd.h
+++ b/arch/alpha/include/uapi/asm/unistd.h
@@ -469,5 +469,8 @@
 #define __NR_process_vm_writev 505
 #define __NR_kcmp  506
 #define __NR_finit_module  507
+#define __NR_sched_setattr 508
+#define __NR_sched_getattr 509
+#define __NR_renameat2 510
 
 #endif /* _UAPI_ALPHA_UNISTD_H */
diff --git a/arch/alpha/kernel/systbls.S b/arch/alpha/kernel/systbls.S
index dca9b3f..2478971 100644
--- a/arch/alpha/kernel/systbls.S
+++ b/arch/alpha/kernel/systbls.S
@@ -526,6 +526,9 @@ sys_call_table:
.quad sys_process_vm_writev /* 505 */
.quad sys_kcmp
.quad sys_finit_module
+   .quad sys_sched_setattr
+   .quad sys_sched_getattr
+   .quad sys_renameat2 /* 510 */
 
.size sys_call_table, . - sys_call_table
.type sys_call_table, @object
-- 
1.8.5.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/1] audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL

[Matt Turner]

On Tue, Feb 25, 2014 at 1:16 AM, AKASHI Takahiro
 wrote:
> Currently AUDITSYSCALL has a long list of architecture depencency:
>depends on AUDIT && (X86 || PARISC || PPC || S390 || IA64 || UML ||
> SPARC64 || SUPERH || (ARM && AEABI && !OABI_COMPAT) || ALPHA)
> The purpose of this patch is to replace it with HAVE_ARCH_AUDITSYSCALL
> for simplicity.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  arch/alpha/Kconfig |1 +
>  arch/arm/Kconfig   |1 +
>  arch/ia64/Kconfig  |1 +
>  arch/parisc/Kconfig|1 +
>  arch/powerpc/Kconfig   |1 +
>  arch/s390/Kconfig  |1 +
>  arch/sh/Kconfig|1 +
>  arch/sparc/Kconfig |1 +
>  arch/um/Kconfig.common |1 +
>  arch/x86/Kconfig   |1 +
>  init/Kconfig   |5 -
>  11 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
> index f6c6b34..b7ff9a3 100644
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -22,6 +22,7 @@ config ALPHA
> select GENERIC_SMP_IDLE_THREAD
> select GENERIC_STRNCPY_FROM_USER
> select GENERIC_STRNLEN_USER
> +   select HAVE_ARCH_AUDITSYSCALL
> select HAVE_MOD_ARCH_SPECIFIC
> select MODULES_USE_ELF_RELA
> select ODD_RT_SIGACTION

Thanks.

Acked-by: Matt Turner 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/1] audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL

[Matt Turner]

On Tue, Feb 25, 2014 at 1:16 AM, AKASHI Takahiro
takahiro.aka...@linaro.org wrote:
 Currently AUDITSYSCALL has a long list of architecture depencency:
depends on AUDIT  (X86 || PARISC || PPC || S390 || IA64 || UML ||
 SPARC64 || SUPERH || (ARM  AEABI  !OABI_COMPAT) || ALPHA)
 The purpose of this patch is to replace it with HAVE_ARCH_AUDITSYSCALL
 for simplicity.

 Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org
 ---
  arch/alpha/Kconfig |1 +
  arch/arm/Kconfig   |1 +
  arch/ia64/Kconfig  |1 +
  arch/parisc/Kconfig|1 +
  arch/powerpc/Kconfig   |1 +
  arch/s390/Kconfig  |1 +
  arch/sh/Kconfig|1 +
  arch/sparc/Kconfig |1 +
  arch/um/Kconfig.common |1 +
  arch/x86/Kconfig   |1 +
  init/Kconfig   |5 -
  11 files changed, 14 insertions(+), 1 deletion(-)

 diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
 index f6c6b34..b7ff9a3 100644
 --- a/arch/alpha/Kconfig
 +++ b/arch/alpha/Kconfig
 @@ -22,6 +22,7 @@ config ALPHA
 select GENERIC_SMP_IDLE_THREAD
 select GENERIC_STRNCPY_FROM_USER
 select GENERIC_STRNLEN_USER
 +   select HAVE_ARCH_AUDITSYSCALL
 select HAVE_MOD_ARCH_SPECIFIC
 select MODULES_USE_ELF_RELA
 select ODD_RT_SIGACTION

Thanks.

Acked-by: Matt Turner matts...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 4/4] qrwlock: Use smp_store_release() in write_unlock()

[Matt Turner]

On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra  wrote:
> On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
>> >Peter,
>> >
>> >I found out that the build failure was caused by the fact that the
>> >__native_word() macro (used internally by compiletime_assert_atomic())
>> >allows only a size of 4 or 8 for x86-64. The data type that I used is a
>> >byte. Is there a reason why byte and short are not considered native?
>>
>> It seems likely it was implemented like that since there was no existing
>> need; long can be relied on as the largest native type, so this should
>> suffice and works here:
>
> There's Alphas that cannot actually atomically adres a byte; I do not
> konw if Linux cares about them, but if it does, we cannot in fact rely
> on this in generic primitives like this.

That's right, and thanks for the heads-up. Alpha can only address 4
and 8 bytes atomically. (LDL_L, LDQ_L, STL_C, STQ_C).

The Byte-Word extension in EV56 doesn't add new atomics, so in fact no
Alphas can address < 4 bytes atomically.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 4/4] qrwlock: Use smp_store_release() in write_unlock()

[Matt Turner]

On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra pet...@infradead.org wrote:
 On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
 Peter,
 
 I found out that the build failure was caused by the fact that the
 __native_word() macro (used internally by compiletime_assert_atomic())
 allows only a size of 4 or 8 for x86-64. The data type that I used is a
 byte. Is there a reason why byte and short are not considered native?

 It seems likely it was implemented like that since there was no existing
 need; long can be relied on as the largest native type, so this should
 suffice and works here:

 There's Alphas that cannot actually atomically adres a byte; I do not
 konw if Linux cares about them, but if it does, we cannot in fact rely
 on this in generic primitives like this.

That's right, and thanks for the heads-up. Alpha can only address 4
and 8 bytes atomically. (LDL_L, LDQ_L, STL_C, STQ_C).

The Byte-Word extension in EV56 doesn't add new atomics, so in fact no
Alphas can address  4 bytes atomically.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/10] alpha: select ARCH_MIGHT_HAVE_PC_SERIO

[Matt Turner]

Acked-by: Matt Turner 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/