Re: [PATCH] hwmon: applesmc: avoid overlong udelay()
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
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
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
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)
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
Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage)
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, &args);
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
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
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
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
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
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
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, &ctx))
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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, &msr);
-#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
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
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&m=151491969711913&w=2 > https://marc.info/?l=linux-alpha&m=151491960011839&w=2 > https://marc.info/?l=linux-alpha&m=151491963911901&w=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
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?
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?
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?
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?
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
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
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
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.
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?
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?
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?
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
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.
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.
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&id=711da2570cd3302d0cb9f2489a101e4a7c966a6c
[PATCH] drm/i915: Remove instructions to file a bug report.
>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(&error->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
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/
[PATCH] alpha: select CONFIG_ARCH_USE_CMPXCHG_LOCKREF.
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/
Re: [PATCH 06/15] alpha: don't use module_init for non-modular core code
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] arch: alpha: kernel: remove deprecated call to pci_get_slot
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] alpha: Wire up missing syscalls
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] llist: Fix missing lockless_dereference()
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/
[PATCH 1/2] alpha: Wire up sched_setattr, sched_getattr, and renameat2 syscalls.
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
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/
Re: [PATCH v2 1/1] audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL
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 v8 4/4] qrwlock: Use smp_store_release() in write_unlock()
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 01/10] alpha: select ARCH_MIGHT_HAVE_PC_SERIO
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: [alpha PATCH] enable syscall audit function at alpha architecture
On Mon, Dec 9, 2013 at 6:24 PM, 蔡正龙 wrote:
> Enable system-call auditing support at alpha architecture
>
> Signed-off-by: Zhenglong.cai
>
> arch/alpha/Kconfig |3 +++
> arch/alpha/include/asm/ptrace.h |5 +
> arch/alpha/include/asm/thread_info.h |2 ++
> arch/alpha/kernel/Makefile |1 +
> arch/alpha/kernel/entry.S|6 +-
> arch/alpha/kernel/ptrace.c |4
> 6 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
> index d39dc9b..f23ab8b 100644
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -16,6 +16,7 @@ config ALPHA
> select ARCH_WANT_IPC_PARSE_VERSION
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> + select AUDIT_ARCH
> select GENERIC_CLOCKEVENTS
> select GENERIC_SMP_IDLE_THREAD
> select GENERIC_STRNCPY_FROM_USER
> @@ -76,6 +77,8 @@ config GENERIC_ISA_DMA
> source "init/Kconfig"
> source "kernel/Kconfig.freezer"
>
> +config AUDIT_ARCH
> + bool
>
> menu "System setup"
>
> diff --git a/arch/alpha/include/asm/ptrace.h
> b/arch/alpha/include/asm/ptrace.h
> index 2112850..9047c2f 100644
> --- a/arch/alpha/include/asm/ptrace.h
> +++ b/arch/alpha/include/asm/ptrace.h
> @@ -19,4 +19,9 @@
>
> #define force_successful_syscall_return() (current_pt_regs()->r0 = 0)
>
> +static inline unsigned long regs_return_value(struct pt_regs *regs)
> +{
> + return regs->r0;
> +}
> +
> #endif
> diff --git a/arch/alpha/include/asm/thread_info.h
> b/arch/alpha/include/asm/thread_info.h
> index 453597b..3d6ce6d 100644
> --- a/arch/alpha/include/asm/thread_info.h
> +++ b/arch/alpha/include/asm/thread_info.h
> @@ -70,6 +70,7 @@ register struct thread_info *__current_thread_info
> __asm__("$8");
> #define TIF_NOTIFY_RESUME 1 /* callback before returning to user
> */
> #define TIF_SIGPENDING 2 /* signal pending */
> #define TIF_NEED_RESCHED 3 /* rescheduling necessary */
> +#define TIF_SYSCALL_AUDIT 4 /* syscall audit active */
> #define TIF_DIE_IF_KERNEL 9 /* dik recursion lock */
> #define TIF_MEMDIE 13 /* is terminating due to OOM killer */
>
> @@ -77,6 +78,7 @@ register struct thread_info *__current_thread_info
> __asm__("$8");
> #define _TIF_SIGPENDING(1< #define _TIF_NEED_RESCHED (1< #define _TIF_NOTIFY_RESUME (1< +#define _TIF_SYSCALL_AUDIT (1<
> /* Work to do on interrupt/exception return. */
> #define _TIF_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED | \
> diff --git a/arch/alpha/kernel/Makefile b/arch/alpha/kernel/Makefile
> index 0d54650..3ecac01 100644
> --- a/arch/alpha/kernel/Makefile
> +++ b/arch/alpha/kernel/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_SRM_ENV) += srm_env.o
> obj-$(CONFIG_MODULES) += module.o
> obj-$(CONFIG_PERF_EVENTS) += perf_event.o
> obj-$(CONFIG_RTC_DRV_ALPHA) += rtc.o
> +obj-$(CONFIG_AUDIT)+= audit.o
>
> ifdef CONFIG_ALPHA_GENERIC
>
> diff --git a/arch/alpha/kernel/entry.S b/arch/alpha/kernel/entry.S
> index a969b95..98703d9 100644
> --- a/arch/alpha/kernel/entry.S
> +++ b/arch/alpha/kernel/entry.S
> @@ -465,7 +465,11 @@ entSys:
> .cfi_rel_offset $16, SP_OFF+24
> .cfi_rel_offset $17, SP_OFF+32
> .cfi_rel_offset $18, SP_OFF+40
> - blbs$3, strace
> +#ifdef CONFIG_AUDITSYSCALL
> + lda $6, _TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT
> + and $3, $6, $3
> +#endif
> + bne $3, strace
> beq $4, 1f
> ldq $27, 0($5)
> 1: jsr $26, ($27), alpha_ni_syscall
> diff --git a/arch/alpha/kernel/ptrace.c b/arch/alpha/kernel/ptrace.c
> index 2a4a80f..86d8351 100644
> --- a/arch/alpha/kernel/ptrace.c
> +++ b/arch/alpha/kernel/ptrace.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -316,15 +317,18 @@ long arch_ptrace(struct task_struct *child, long
> request,
> asmlinkage unsigned long syscall_trace_enter(void)
> {
> unsigned long ret = 0;
> + struct pt_regs *regs = current_pt_regs();
> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
> tracehook_report_syscall_entry(current_pt_regs()))
> ret = -1UL;
> + audit_syscall_entry(AUDIT_ARCH_ALPHA, regs->r0, regs->r16, regs->r17,
> regs->r18, regs->r19);
Looks like this line was wrapped. No problem, I'll fix it before applying it.
Thanks for the patch. This should allow pam support on alpha, which is
pretty cool.
I'll test and add it to my tree if all goes well.
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 2/7] alpha: Eliminate compiler warning from memset macro
On Tue, Jul 16, 2013 at 10:04 AM, Richard Henderson wrote: > Compiling with GCC 4.8 yields several instances of > > crypto/vmac.c: In function ‘vmac_final’: > crypto/vmac.c:616:9: warning: value computed is not used [-Wunused-value] > memset(&mac, 0, sizeof(vmac_t)); > ^ > arch/alpha/include/asm/string.h:31:25: note: in definition of macro ‘memset’ > ? __builtin_memset((s),0,(n)) \ > ^ > Converting the macro to an inline function eliminates this problem. > > Signed-off-by: Richard Henderson > --- On IRC we found out that this breaks the breaks kernel build with gcc-3.4 with "sorry, unimplemented: inlining failed in call to 'memset': recursive inlining" message on some file. I'll drop this patch for now. -- 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 05/10] alpha: Primitive support for CPU power down.
On Tue, Jul 16, 2013 at 10:34 AM, Richard Henderson wrote:
> Use WTINT to wait for the next interrupt. Squash the WTINT call
> if the PALcode doesn't support it (e.g. MILO). No attempt is yet
> made to skip clock ticks during normal scheduling in order to stay
> in power down mode longer.
The architecture reference manual says
> The counter, PCC, may increment at a lower rate or may stop entirely
> during wtint execution. This side effect is implementation dependent.
Is that anything to worry about?
>
> Signed-off-by: Richard Henderson
> ---
> arch/alpha/include/asm/pal.h | 1 +
> arch/alpha/include/uapi/asm/pal.h | 1 +
> arch/alpha/kernel/process.c | 15 +++
> arch/alpha/kernel/traps.c | 12
> 4 files changed, 29 insertions(+)
>
> diff --git a/arch/alpha/include/asm/pal.h b/arch/alpha/include/asm/pal.h
> index 6fcd2b5..e78ec9b 100644
> --- a/arch/alpha/include/asm/pal.h
> +++ b/arch/alpha/include/asm/pal.h
> @@ -89,6 +89,7 @@ __CALL_PAL_W1(wrmces, unsigned long);
> __CALL_PAL_RW2(wrperfmon, unsigned long, unsigned long, unsigned long);
> __CALL_PAL_W1(wrusp, unsigned long);
> __CALL_PAL_W1(wrvptptr, unsigned long);
> +__CALL_PAL_RW1(wtint, unsigned long, unsigned long);
>
> /*
> * TB routines..
> diff --git a/arch/alpha/include/uapi/asm/pal.h
> b/arch/alpha/include/uapi/asm/pal.h
> index 3c0ce08..dfc8140 100644
> --- a/arch/alpha/include/uapi/asm/pal.h
> +++ b/arch/alpha/include/uapi/asm/pal.h
> @@ -46,6 +46,7 @@
> #define PAL_rdusp 58
> #define PAL_whami 60
> #define PAL_retsys 61
> +#define PAL_wtint 62
> #define PAL_rti63
>
>
> diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
> index f2360a7..3130f13 100644
> --- a/arch/alpha/kernel/process.c
> +++ b/arch/alpha/kernel/process.c
> @@ -46,6 +46,21 @@
> void (*pm_power_off)(void) = machine_power_off;
> EXPORT_SYMBOL(pm_power_off);
>
> +/*
> + * Sleep the CPU.
> + * EV6, LCA45 and QEMU know how to power down, skipping N timer interrupts.
> + */
> +void arch_cpu_idle(void)
> +{
> + wtint(0);
> + local_irq_enable();
> +}
> +
> +void arch_cpu_idle_dead(void)
> +{
> + wtint(INT_MAX);
> +}
> +
> struct halt_info {
> int mode;
> char *restart_cmd;
> diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
> index affccb9..991f6c3 100644
> --- a/arch/alpha/kernel/traps.c
> +++ b/arch/alpha/kernel/traps.c
> @@ -243,6 +243,18 @@ do_entIF(unsigned long type, struct pt_regs *regs)
>(const char *)(data[1] | (long)data[2] << 32),
>data[0]);
> }
> + if (type == 4) {
> + /* If CALL_PAL WTINT is not supported by the PALcode,
> + "emulate" it by overwriting the insn. */
The pseudo-code for WTINT contains an IF(implemented) check, where the
ELSE case just does v0 <- 0. So is overwriting with nop just an
optimization to avoid the (expensive) PAL call? If it is, could we
clarify the comment?
> + unsigned int *pinsn
> + = (unsigned int *) regs->pc - 1;
> + if (*pinsn == PAL_wtint) {
> + *pinsn = 0x47e01400; /* mov 0,$0 */
> + imb();
> + regs->r0 = 0;
> + return;
> + }
> + }
> die_if_kernel((type == 1 ? "Kernel Bug" : "Instruction
> fault"),
> regs, type, NULL);
> }
> --
> 1.8.1.4
>
--
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 0/7] Minor Alpha updates for 3.11
On Tue, Jul 16, 2013 at 10:04 AM, Richard Henderson wrote: > Here's a set of minor updates for arch/alpha that should not > be controversial. Patches 1-5 and 7 (with the typo fixed) are Reviewed-and-Tested-by: Matt Turner I don't know enough patch 6 to make any kind of meaningful review, so it's Acked-by: Matt Turner I've got five patches in a for-linus branch on kernel.org that I was planning to send a pull request for soon. Would you like me to add these to that branch? 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 31/45] alpha/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
On Sun, Jun 23, 2013 at 6:45 AM, Srivatsa S. Bhat wrote: > Once stop_machine() is gone from the CPU offline path, we won't be able > to depend on disabling preemption to prevent CPUs from going offline > from under us. > > Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going > offline, while invoking from atomic context. > > Also, remove the non-ASCII character present in this file! It's not non-ASCII. It's a page break. -- 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: spinlock: don't perform memory access in locked critical section
On Mon, May 6, 2013 at 1:01 PM, Will Deacon wrote: > The Alpha Architecture Reference Manual states that any memory access > performed between an LD_xL and a STx_C instruction may cause the > store-conditional to fail unconditionally and, as such, `no useful > program should do this'. > > Linux is a useful program, so fix up the Alpha spinlock implementation > to use logical operations rather than load-address instructions for > generating immediates. > > Cc: Richard Henderson > Cc: Ivan Kokshaysky > Cc: Matt Turner > Signed-off-by: Will Deacon > --- > arch/alpha/include/asm/spinlock.h | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/alpha/include/asm/spinlock.h > b/arch/alpha/include/asm/spinlock.h > index 3bba21e..0c357cd 100644 > --- a/arch/alpha/include/asm/spinlock.h > +++ b/arch/alpha/include/asm/spinlock.h > @@ -29,7 +29,7 @@ static inline void arch_spin_lock(arch_spinlock_t * lock) > __asm__ __volatile__( > "1: ldl_l %0,%1\n" > " bne %0,2f\n" > - " lda %0,1\n" > + " mov 1,%0\n" > " stl_c %0,%1\n" > " beq %0,2f\n" > " mb\n" > @@ -86,7 +86,7 @@ static inline void arch_write_lock(arch_rwlock_t *lock) > __asm__ __volatile__( > "1: ldl_l %1,%0\n" > " bne %1,6f\n" > - " lda %1,1\n" > + " mov 1,%1\n" > " stl_c %1,%0\n" > " beq %1,6f\n" > " mb\n" > @@ -106,7 +106,7 @@ static inline int arch_read_trylock(arch_rwlock_t * lock) > > __asm__ __volatile__( > "1: ldl_l %1,%0\n" > - " lda %2,0\n" > + " mov 0,%2\n" > " blbs%1,2f\n" > " subl%1,2,%2\n" > " stl_c %2,%0\n" > @@ -128,9 +128,9 @@ static inline int arch_write_trylock(arch_rwlock_t * lock) > > __asm__ __volatile__( > "1: ldl_l %1,%0\n" > - " lda %2,0\n" > + " mov 0,%2\n" > " bne %1,2f\n" > - " lda %2,1\n" > + " mov 1,%2\n" > " stl_c %2,%0\n" > " beq %2,6f\n" > "2: mb\n" > -- > 1.8.2.2 I'm not sure of the interpretation that LDA counts as a memory access. The manual says it's Ra <- Rbv + SEXT(disp). It's not touching memory that I can see. Does this fix a known problem or is it just something that you noticed? 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] alpha: makefile: don't enforce small data model for kernel builds
On Mon, Mar 25, 2013 at 1:06 PM, Michael Cree wrote: > On 26/03/2013, at 4:09 AM, Tobias Klausmann wrote: >> >> On Mon, 25 Mar 2013, Will Deacon wrote: >>> >>> Any news on these? I've included an updated version of the first patch, >>> with >>> the Tested-by-tag and a tweaked commit message below. >> >> >> As a data point, I tried vanilla 3.8.4 on the weekend. With my >> usual config on a UP1500, it will fail at build time with >> relocation errors. If I remove -msmall-data (or replace it with >> ~big~), the machine hangs hard immediatly after aboot telling me >> it's starting it. > > > You probably want the "alpha: Add irongate_io to to PCI bus resources" patch > posted by Matt Turner in the linux-alpha forum. Looks like it has not been > sent to Linus. > > If Matt does not respond in the next day or two I'll collect patches and > send them on to Linus. Yes, please do. I haven't powered on an alpha in a few months. 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: [GIT PULL] Disintegrate UAPI for alpha [ver #2]
On Sat, Dec 1, 2012 at 7:00 PM, Michael Cree wrote: > On Tue, Oct 09, 2012 at 10:15:08AM +0100, David Howells wrote: >> Can you merge the following branch into the alpha tree please. >> >> This is to complete part of the UAPI disintegration for which the preparatory >> patches were pulled recently. > > I think the alpha-next tree is currently inactive so nothing has happened > regarding your merge request. > > Any chance you could send it directly to Linus? > > (A conflict has arisen in arch/alpha/include/asm/Kbuild against Linus' > tree but that is easily resolved.) > > FWIW you can have my Acked-By but it would be better if one of the > official Alpha maintainers acknowledged it. 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 024/104] arch/alpha: remove depends on CONFIG_EXPERIMENTAL
On Mon, Nov 5, 2012 at 3:03 PM, Kees Cook wrote: > The CONFIG_EXPERIMENTAL config item has not carried much meaning for a > while now and is almost always enabled by default. As agreed during the > Linux kernel summit, remove it from any "depends on" lines in Kconfigs. > > CC: Richard Henderson > CC: Ivan Kokshaysky > CC: Matt Turner > CC: Thomas Gleixner > CC: "Michael S. Tsirkin" > CC: Anna-Maria Gleixner > CC: Andrew Morton > Signed-off-by: Kees Cook > --- > arch/alpha/Kconfig |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig > index 5dd7f5d..65ec1c8 100644 > --- a/arch/alpha/Kconfig > +++ b/arch/alpha/Kconfig > @@ -557,8 +557,7 @@ config NR_CPUS >with working support have a maximum of 4 CPUs. > > config ARCH_DISCONTIGMEM_ENABLE > - bool "Discontiguous Memory Support (EXPERIMENTAL)" > - depends on EXPERIMENTAL > + bool "Discontiguous Memory Support" > help > Say Y to support efficient handling of discontiguous physical > memory, > for architectures which are either NUMA (Non-Uniform Memory Access) > -- > 1.7.9.5 > 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 V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).
On Sat, Aug 11, 2012 at 2:32 AM, Huacai Chen wrote: > Signed-off-by: Huacai Chen > Signed-off-by: Hongliang Tao > Signed-off-by: Hua Yan > Cc: dri-de...@lists.freedesktop.org > --- > include/drm/drm_sarea.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h > index ee5389d..1d1a858 100644 > --- a/include/drm/drm_sarea.h > +++ b/include/drm/drm_sarea.h > @@ -37,6 +37,8 @@ > /* SAREA area needs to be at least a page */ > #if defined(__alpha__) > #define SAREA_MAX 0x2000U > +#elif defined(__mips__) > +#define SAREA_MAX 0x4000U > #elif defined(__ia64__) > #define SAREA_MAX 0x1U /* 64kB */ > #else > -- > 1.7.7.3 SAREA is a DRI-1 concept. The Radeon drivers you're using is DRI-2, so what do you need this for? All the DRI-1 drivers have been removed from Mesa, so I think the answer is nothing. -- 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/
