Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds
On 18/03/2013, at 10:48 AM, Will Deacon wrote: Due to all of the goodness being packed into today's kernels, the resulting image isn't as slim as it once was. In light of this, don't pass -msmall-data to the tools, which results in link failures due to impossible relocations when compiling anything but the most trivial configurations. I think many of us have been using -mlarge-data when compiling with gcc-4.6 or later so maybe it is time to get the change upstream. The interesting thing is that the kernel still compiles fine with gcc-4.5 and the relocation errors only appear if compiling with gcc-4.6 or later. I had asked before on this forum what had changed with gcc-4.6 that results in the extra usage of the small data area but never got an answer. I am still curious to know. BTW, the phrase "to the tools" in the commit message makes me think immediately of the tools directory (containing perf, etc.) which is not what is intended. Matt: Are you able to collect up this and the other patches of Will and get them sent to Linus? Cheers Michael. -- 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/8] mm: use vm_unmapped_area() on alpha architecture
On 9/01/2013, at 2:28 PM, Michel Lespinasse wrote: Update the alpha arch_get_unmapped_area function to make use of vm_unmapped_area() instead of implementing a brute force search. Signed-off-by: Michel Lespinasse 'Tis running fine on my alpha. Tested-by: Michael Cree Cheers Michael. -- 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: perf: fix out-of-bounds array access triggered from raw event
On Tue, Sep 10, 2013 at 10:58:12AM +0100, Will Deacon wrote:
> Vince's perf fuzzer uncovered the following issue on Alpha:
>
> Unable to handle kernel paging request at virtual address fbfe4e46a0e8
> CPU 0 perf_fuzzer(1278): Oops 0
> pc = [] ra = [] ps = 0007Not tainted
> pc is at alpha_perf_event_set_period+0x60/0xf0
> ra is at alpha_pmu_enable+0x1a4/0x1c0
> v0 = t0 = 000f t1 = fc007b3f5800
> t2 = fbff275faa94 t3 = c9b9bd89 t4 = fbfe4e46a098
> t5 = 0020 t6 = fbfe4e46a0b8 t7 = fc007f4c8000
> s0 = s1 = fc0001b0c018 s2 = fc0001b0c020
> s3 = fc007b3f5800 s4 = 0001 s5 = c9b9bd85
> s6 = 0001
> a0 = 0006 a1 = fc007b3f5908 a2 = fbfe4e46a098
> a3 = 0005000108c0 a4 = a5 =
> t8 = 0001 t9 = 0001 t10= 27829f6f
> t11= 0020 pv = fc31fb60 at = fc950900
> gp = fc940900 sp = fc007f4cbca8
> Disabling lock debugging due to kernel taint
> Trace:
> [] alpha_pmu_enable+0x1a4/0x1c0
> [] perf_pmu_enable+0x48/0x60
> [] __perf_install_in_context+0x15c/0x230
> [] remote_function+0x80/0xa0
> [] __perf_install_in_context+0x0/0x230
> [] smp_call_function_single+0x1b4/0x1d0
> [] task_function_call+0x60/0x80
> [] __perf_install_in_context+0x0/0x230
> [] task_function_call+0x34/0x80
> [] perf_install_in_context+0x9c/0x150
> [] __perf_install_in_context+0x0/0x230
> [] SYSC_perf_event_open+0x360/0xac0
> [] entSys+0xa4/0xc0
>
> This is due to the raw event encoding being used as an index directly
> into the ev67_mapping array, rather than being validated against the
> ev67_pmc_event_type enumeration instead. Unlike other architectures,
> which allow raw events to propagate into the hardware counters with
> little interference, the limited number of events on Alpha and the
> strict event <-> counter relationships mean that raw events actually
> correspond to the Linux-specific Alpha events, rather than anything
> defined by the architecture.
>
> This patch adds a new callback to alpha_pmu_t for validating the raw
> event encoding with the Linux event types for the PMU, preventing the
> out-of-bounds array access.
>
> Cc: Peter Zijlstra
> Cc: Michael Cree
> Cc: Matt Turner
> Signed-off-by: Will Deacon
Acked-by: Michael Cree
Cheers
Michael.
> ---
> arch/alpha/kernel/perf_event.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/alpha/kernel/perf_event.c b/arch/alpha/kernel/perf_event.c
> index d821b17..c52e7f0 100644
> --- a/arch/alpha/kernel/perf_event.c
> +++ b/arch/alpha/kernel/perf_event.c
> @@ -83,6 +83,8 @@ struct alpha_pmu_t {
> long pmc_left[3];
>/* Subroutine for allocation of PMCs. Enforces constraints. */
> int (*check_constraints)(struct perf_event **, unsigned long *, int);
> + /* Subroutine for checking validity of a raw event for this PMU. */
> + int (*raw_event_valid)(u64 config);
> };
>
> /*
> @@ -203,6 +205,12 @@ success:
> }
>
>
> +static int ev67_raw_event_valid(u64 config)
> +{
> + return config >= EV67_CYCLES && config < EV67_LAST_ET;
> +};
> +
> +
> static const struct alpha_pmu_t ev67_pmu = {
> .event_map = ev67_perfmon_event_map,
> .max_events = ARRAY_SIZE(ev67_perfmon_event_map),
> @@ -211,7 +219,8 @@ static const struct alpha_pmu_t ev67_pmu = {
> .pmc_count_mask = {EV67_PCTR_0_COUNT_MASK, EV67_PCTR_1_COUNT_MASK, 0},
> .pmc_max_period = {(1UL<<20) - 1, (1UL<<20) - 1, 0},
> .pmc_left = {16, 4, 0},
> - .check_constraints = ev67_check_constraints
> + .check_constraints = ev67_check_constraints,
> + .raw_event_valid = ev67_raw_event_valid,
> };
>
>
> @@ -609,7 +618,9 @@ static int __hw_perf_event_init(struct perf_event *event)
> } else if (attr->type == PERF_TYPE_HW_CACHE) {
> return -EOPNOTSUPP;
> } else if (attr->type == PERF_TYPE_RAW) {
> - ev = attr->config & 0xff;
> + if (!alpha_pmu->raw_event_valid(attr->config))
> + return -EINVAL;
> + ev = attr->config;
> } else {
> return -EOPNOTSUPP;
> }
> --
> 1.8.3.2
>
--
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 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. Cheers Michael. -- 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: Using __int128 on 64-bit architectures
On Sun, Apr 21, 2013 at 07:35:31PM +1000, Stephen Rothwell wrote: > On Sun, 21 Apr 2013 05:29:28 +0100 (BST) "Maciej W. Rozycki" > wrote: > > > > Hmm, nobody has replied, so just FYI such widening multiplication is > > available in all 64-bit MIPS hardware and GCC has supported it since 4.4 > > or mid 2008 (older versions used a libgcc __multi3 helper, not quite so > > efficient as you can imagine). > > i.e. for gcc 4.6.3, 64 bit powerpc calls out to __multi3 > > The same is true for sparc64. Likewise, with gcc-4.6.3, alpha calls out to __multi3. Cheers Michael. -- 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 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. Cheers Michael. -- 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] repeated Oops
On Mon, Mar 25, 2013 at 07:13:35AM -0500, Bob Tracy wrote: > Getting lots of these since attempting to upgrade past 3.8.0-rc7. I > *don't* think it's a kernel issue at this point, because while older > kernels (found an old 3.5.0-rc4 setup from about a year ago in my archives) > seem to take longer to reach this point, they'll eventually die exactly the > same way. Presumably the older kernel has worked reliably at some stage? > In other words, either my old hardware is starting to go bye-bye, > or something critical in userspace (libraries?) is horribly broken since the > last round of package updates (Debian unstable for alpha). Recently updated Debian unstable has been working fine on my Alphas including a PWS. I have not seen the kernel paging request problems for some time now; I saw them in the past when linking huge libraries that exercised virtual memory when running kernels older than about 3.2.23. How about the Debian supplied generic kernel? That should work (except that the radeon module may not load leaving the console in a VGA mode). Testing a stable kernel is probably a good idea at this stage. > (System currently powered-down. Will open the case later and go looking > for clogged/bad cooling fans, cat fur, etc.) Good idea. Check motherboard is well seated into I/O board. Check memory is all well seated. Doing that got me some extra life out of my PWS! Good luck! Cheers Michael. > The process running at the time will vary, but the commonality I've > noticed is "lots of disk I/O". Examples: cpio, applying the 3.9.0-rc1 > kernel patch (approx. 40 MB uncompressed), running "git pull" on a local > kernel source repository where v3.8 was the most recent tag, the final link > of vmlinux on a kernel build, and so forth. > > Reminder: this is a DEC Alpha system (PWS 433au). > > Unable to handle kernel paging request at virtual address 0010 > cpio(4445): Oops 0 > pc = [] ra = [] ps = 0007Not tainted > pc is at process_mcheck_info+0x4c/0x320 > ra is at cia_machine_check+0x9c/0xb0 > v0 = 0004 t0 = 0630 t1 = 0630 > t2 = 0001 t3 = fc00 t4 = fc00425ede38 > t5 = fc00425ee000 t6 = 00245b15 t7 = fc0042dbc000 > s0 = s1 = fc9ce258 s2 = fc00422b2498 > s3 = fc0042dbfb68 s4 = 0002 s5 = 0002 > s6 = 0002 > a0 = 0630 a1 = a2 = fc8aeb4c > a3 = a4 = fc0042dbfb68 a5 = fc0042dbfb58 > t8 = 0001 t9 = 00245b15 t10= fc00422b23b8 > t11= 00245b15 pv = fc315cd0 at = fc0042dbf878 > gp = fca0d0d8 sp = fc0042dbf8a0 > Disabling lock debugging due to kernel taint > Trace: > [] cia_machine_check+0x9c/0xb0 > [] ext3_get_blocks_handle+0xe0/0xd00 > [] do_entInt+0x180/0x1e0 > [] mempool_alloc_slab+0x24/0x40 > [] ret_from_sys_call+0x0/0x10 > [] mempool_alloc+0x50/0x170 > [] do_mpage_readpage+0x344/0x7e0 > [] __constant_c_memset+0x0/0x50 > [] loop+0x8/0x10 > [] mpage_readpages+0xf8/0x1c0 > [] ext3_get_block+0x0/0x170 > [] radix_tree_insert+0x1ac/0x2f0 > [] add_to_page_cache_locked+0xb0/0x180 > [] mpage_readpages+0xc8/0x1c0 > [] ext3_get_block+0x0/0x170 > [] ext3_readpages+0x2c/0x40 > [] journal_stop+0x160/0x300 > [] security_file_open+0xa4/0xb0 > [] __do_page_cache_readahead+0x1fc/0x320 > [] ra_submit+0x38/0x50 > [] generic_file_aio_read+0x51c/0x800 > [] do_sync_read+0x9c/0x110 > [] vfs_read+0xb4/0x1c0 > [] security_file_permission+0xd8/0x110 > [] rw_verify_area+0x64/0x120 > [] vfs_read+0x84/0x1c0 > [] SyS_read+0x6c/0xc0 > [] entSys+0xa4/0xc0 > > Code: a75e a53e0008 a55e0010 23de0020 6bfa8001 a55d0158 > 261dffea > > Thanks in advance for an assist in figuring out what's going on here. > > --Bob -- 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 06:35:07PM -0500, Rob Landley wrote: > On 07/16/2013 12:04:33 PM, Richard Henderson wrote: > >Here's a set of minor updates for arch/alpha that should not > >be controversial. > > I also note that I had to do this to get busybox to build against > uClibc: > -#define __NR_umount 22 > +#define __NR_umount2 22 > -#define __NR_oldumount 321 > +#define __NR_umount 321 I anticipate that this will likely break userspace. busybox should be fixed to test for __NR_oldumount and then call the correct functions, namely oldumount and umount if __NR_oldumount is defined and umount and umount2 if it is not defined. Cheers Michael. -- 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 00/10] Alpha support for QEMU
On Tue, Jul 16, 2013 at 10:34:08AM -0700, Richard Henderson wrote: > The series seems pretty stable under QEMU, but I have no real hardware > on which to test -- the whole reason I'm interested in QEMU of course. > So I'm hoping that someone will notice this and help me out with testing. Tested the patch series applied against 3.10.1 on a 3-CPU ES45. System came up fine but I noticed date was wrong and had been reset back to the start of the epoch (Jan 1 1970). Appears it is not reading hardware clock correctly on boot. I manually set the clock to the correct time but noticed it is running slow, indeed in a period of 60s the system clock incremented by 21s (+/-1s) so would appear clock is running slow by a factor given by the number of CPUs. Cheers Michael -- 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 00/10] Alpha support for QEMU
On Thu, Jul 18, 2013 at 06:38:14AM -0700, Richard Henderson wrote: > On 07/17/2013 06:14 PM, Michael Cree wrote: > > Tested the patch series applied against 3.10.1 on a 3-CPU ES45. System came > > up fine but I noticed date was wrong and had been reset back to the start > > of the epoch (Jan 1 1970). Appears it is not reading hardware clock > > correctly on boot. > > Please scan the dmesg for the "Using epoch 2000 for rtc year 13" line, > and compare vs a similar message on the previous kernel. The kernel without the patch set has the "Using epoch 2000" line and the kernel with the patch set is missing the "Using epoch 2000" line. The differences in config between the two kernels are: diff /boot/config-3.10.1-titan-p1+ /boot/config-3.10.1-titan-rth2+ 25c25 < CONFIG_LOCALVERSION="-titan-p1" --- > CONFIG_LOCALVERSION="-titan-rth2" 44c44,53 < CONFIG_GENERIC_CMOS_UPDATE=y --- > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y > > # > # Timers subsystem > # > CONFIG_HZ_PERIODIC=y > # CONFIG_NO_HZ_IDLE is not set > # CONFIG_NO_HZ is not set > # CONFIG_HIGH_RES_TIMERS is not set 253a263 > # CONFIG_ALPHA_QEMU is not set 277a288,293 > # CONFIG_HZ_32 is not set > # CONFIG_HZ_64 is not set > # CONFIG_HZ_128 is not set > # CONFIG_HZ_256 is not set > CONFIG_HZ_1024=y > # CONFIG_HZ_1200 is not set > > I manually set the clock to the correct time but noticed it is running slow, > > indeed in a period of 60s the system clock incremented by 21s (+/-1s) so > > would appear clock is running slow by a factor given by the number of CPUs. > > That's curious. I wonder if somehow I botched the smp changes, and I'm > not getting the timer interrupt either (1) enabled or (2) registered on > the secondary cpus... > > Perhaps /proc/interrupts will confirm or deny this? On the kernel without the patch set the dummy-RTC timer interrupt received 30876 interrupts in a 30s period which is within measurement uncertainty of the expected 30*1024 = 30720 interrupts. On the kernel with the patch set the dummy-RTC timer interrupt received 14419 interrupts on CPU-1, 13935 interrupts on CPU-2 and 2619 interrupts on CPU-3 over a 30s period. Cheers Michael. -- 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 00/10] Alpha support for QEMU
On Thu, Jul 18, 2013 at 03:04:25PM -0700, Richard Henderson wrote: > On 07/18/2013 02:28 PM, Michael Cree wrote: > > On the kernel without the patch set the dummy-RTC timer interrupt received > > 30876 interrupts in a 30s period which is within measurement uncertainty of > > the expected 30*1024 = 30720 interrupts. > > > > On the kernel with the patch set the dummy-RTC timer interrupt received > > 14419 > > interrupts on CPU-1, 13935 interrupts on CPU-2 and 2619 interrupts on CPU-3 > > over a 30s period. > > Grr. Naturally, the old kernel obfuscates which timers are being delivered > where. So a direct comparison doesn't appear possible. But those separated > numbers seem uncomfortably low. > > I've just pushed a new branch to > > git://github.com/rth7680/linux.git axp-qemu-7 > > Please try that with CONFIG_ALPHA_WTINT disabled. I'd like to eliminate that > as a source of uncertainty for your system. Running that axp-qemu-7 branch with RTC_DRV_ALPHA on and ALPHA_WTINT off still results in a rather slow clock. (Does start up with correct time now that I have RTC_DRV_ALPHA selected.) Over a 30s period still get too few timer interrupts: 843, 28805 and 1434 interrupts on the CPUs. Cheers Michael -- 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 Mon, Jul 22, 2013 at 09:31:41PM -0500, Rob Landley wrote: > On 07/16/2013 07:03:47 PM, Michael Cree wrote: > >On Tue, Jul 16, 2013 at 06:35:07PM -0500, Rob Landley wrote: > >> On 07/16/2013 12:04:33 PM, Richard Henderson wrote: > >> >Here's a set of minor updates for arch/alpha that should not > >> >be controversial. > >> > >> I also note that I had to do this to get busybox to build against > >> uClibc: > >> -#define __NR_umount22 > >> +#define __NR_umount2 22 > >> -#define __NR_oldumount321 > >> +#define __NR_umount 321 > > > >I anticipate that this will likely break userspace. > > Haven't seen it so far. It's the same semantics all the other > targets have. Haven't built the whole of linux from scratch against > it yet though. (Most of my package builds are native and I'm still > tweaking my build environment to get a native toolchain built.) [snip] > I.E. nobody's tried to build busybox umount for Alpha (except me) > for thirteen years. That appears false to me. Busybox builds OK on Debian-Ports [1], and it looks like in the build log that umount is built. A search in Debian busybox sources does not return any hits for __NR_umount or __NR_umount2, but does for umount2 which are library calls (admittedly ones that are just wrappers for the kernel syscall). I also don't see any Debian patches in busybox that change behaviour of busybox specifically for Alpha. But IIRC Debian links against glibc even for the installer where busybox is used. So maybe the problem is in uClibc? Yes, a quick look at the source shows that uClibc does not test __NR_oldumount so presumably does not compile correct umount and umount2 library calls on Alpha. Maybe it's the case noone has compiled uClibc on Alpha until now? > There are way more busybox installations out there than even > _emulated_ alpha systems, and this is trivial to fix with a local > patch to the kernel. So I'll just do that. Your idea of the > "correct" thing to do to "fix" this seems entirely backwards to me. I wondered if your proposal will break glibc as glibc checks for __NR_oldumount and does different things based on that. But maybe your fix will not adversely affect glibc (I did not look particularly closely to see if so), but even so, there is no guarantee that other software does not directly access the oldumount syscall when compiled on Alpha, and your change would likely break any such software. Cheers Michael [1] http://buildd.debian-ports.org/status/package.php?p=busybox -- 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 23, 2013 at 07:20:22AM -0800, Richard Henderson wrote: > On 07/22/2013 07:25 PM, Michael Cree wrote: > > I wondered if your proposal will break glibc as glibc checks for > > __NR_oldumount and does different things based on that. But maybe your > > fix will not adversely affect glibc (I did not look particularly closely > > to see if so), but even so, there is no guarantee that other software does > > not directly access the oldumount syscall when compiled on Alpha, and your > > change would likely break any such software. > > It won't break glibc. While there are conditionals for oldumount, > they do pretty much exactly the umount/umount2 dance you'd expect. That's good to hear. > I'm for the patch, because anything that makes us match x86 more > closely has got to be a good thing from a portability standpoint. OK, but I think that behoves us to make an effort to check user space applications are compliant with the change. Fortunately we can easily scheck the vast majority of opensource programs now that Debian provides a web interface for searching the source code of all their packages. Searching for NR_umount finds the following packages that compile on Alpha: eglibc dietlibc uclibc qemu radare linux-tools ns3 skyeye (and a few others that are not buildable on Alpha and tons of hits for every version of the linux kernel that result from every arch directory therein...) I'm happy to take a closer look at them and submit a patch to their upstreams if need be. Cheers Michael. -- 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 RFT linux-next] alpha: dma-mapping: support debug_dma_mapping_error
On Thu, Nov 15, 2012 at 10:49:28AM -0700, Shuah Khan wrote:
> On Fri, 2012-10-26 at 10:32 -0600, Shuah Khan wrote:
> > Add support for debug_dma_mapping_error() call to avoid warning from
> > debug_dma_unmap() interface when it checks for mapping error checked
> > status. Without this patch, device driver failed to check map error
> > warning is generated.
> >
> > Signed-off-by: Shuah Khan
> > ---
> > arch/alpha/include/asm/dma-mapping.h |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/alpha/include/asm/dma-mapping.h
> > b/arch/alpha/include/asm/dma-mapping.h
> > index dfa32f0..b4d483b 100644
> > --- a/arch/alpha/include/asm/dma-mapping.h
> > +++ b/arch/alpha/include/asm/dma-mapping.h
> > @@ -32,6 +32,7 @@ static inline void dma_free_attrs(struct device *dev,
> > size_t size,
> >
> > static inline int dma_mapping_error(struct device *dev, dma_addr_t
> > dma_addr)
> > {
> > + debug_dma_mapping_error(dev, dma_addr);
> > return get_dma_ops(dev)->mapping_error(dev, dma_addr);
> > }
> >
>
> Marek,
>
> This is for alpha to go through your tree.
Given that this does not appear to be upstream yet I'll take it through
the Alpha tree.
Cheers
Michael.
--
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: [BUG] net/core/sock.c won't compile on alpha
On 23/08/2012, at 12:14 AM, Bob Tracy wrote: Kernel version 3.6.0-rc2, and probably -rc1 as well. I get the following compile-time error on alpha architecture: (...) CC net/core/sock.o net/core/sock.c:274:36: error: initializer element is not constant Try v3.6-rc3. It should be fixed now. Cheers Michael. -- 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: Add missing RCU idle APIs on idle loop
On 23/08/12 04:23, Frederic Weisbecker wrote: > In the old times, the whole idle task was considered > as an RCU quiescent state. But as RCU became more and > more successful overtime, some RCU read side critical > section have been added even in the code of some > architectures idle tasks, for tracing for example. Fantastic! It fixes RCU CPU stalls that we were seeing on the SMP kernel when built for generic Alpha. A build of glibc and running its test suite reliably triggers RCU CPU stalls when running a kernel built for generic Alpha. I have just built glibc and ran its test suite twice with no RCU CPU stalls with this patch against a 3.5.2 kernel! Nice. Very nice. I see the stable queue is CCed but I note the patch does not apply cleanly to the 3.2.y kernel. It would be nice to have a backport of the patches for the 3.2 stable kernel. So feel free to add: Tested-by: Michael Cree Cheers Michael. -- 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 00/11] rcu: Add missing RCU idle APIs on idle loop v2
On 25/08/12 13:19, Ben Hutchings wrote: > On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote: >> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote: >>> Hi, >>> >>> Changes since v1: >>> >>> - Fixed preempt handling in alpha idle loop >>> - added ack from Geert >>> - fixed stable email address, sorry :-/ >>> >>> This time I built tested everywhere but: h8300 (compiler internal error), >>> and mn10300, parisc, score (cross compilers not available in >>> ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/) >>> >>> For testing, you can pull from: >>> >>> git://github.com/fweisbec/linux-dynticks.git >>> rcu/idle-fix-v2 >>> >>> Thanks. >> >> I have queued these on -rcu branch rcu/idle: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git >> >> This problem has been in place since 3.3, so it is hard to argue that >> it is a regression for this merge window. I have therefore queued it >> for 3.7. > > I don't follow that; I would expect any serious bug fix (serious enough > for a stable update) to be acceptable for 3.6 at this point. > > If the regression occurred in 3.3, then the cc lines should be something > like: > > Cc: # 3.3+ > > and not the current: > > Cc: 3.2.x.. The Alpha patches fix an even earlier regression resulting in RCU CPU stalls on an SMP kernel built for generic Alpha (which includes the current Debian 3.2-alpha-smp kernel) and renders the kernel pretty much unuseable. I've only tested the two alpha patches together but maybe just the first patch (1/11 alpha: Fix preemption handling in idle loop) might be needed to fix the problem in 3.2. I'll test and let you know. Cheers Michael. -- 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 00/11] rcu: Add missing RCU idle APIs on idle loop v2
On 26/08/12 04:18, Paul E. McKenney wrote: > On Sat, Aug 25, 2012 at 03:16:49PM +0200, Frederic Weisbecker wrote: >> On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote: >>> On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote: On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote: > On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote: >> Hi, >> >> Changes since v1: >> >> - Fixed preempt handling in alpha idle loop >> - added ack from Geert >> - fixed stable email address, sorry :-/ >> >> This time I built tested everywhere but: h8300 (compiler internal error), >> and mn10300, parisc, score (cross compilers not available in >> ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/) >> >> For testing, you can pull from: >> >> git://github.com/fweisbec/linux-dynticks.git >> rcu/idle-fix-v2 >> >> Thanks. > > I have queued these on -rcu branch rcu/idle: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > > This problem has been in place since 3.3, so it is hard to argue that > it is a regression for this merge window. I have therefore queued it > for 3.7. I don't follow that; I would expect any serious bug fix (serious enough for a stable update) to be acceptable for 3.6 at this point. >>> >>> OK, if any of the arch maintainers wishes to submit the patch to 3.6, >>> they are free to do so -- just let me know and I will drop the patch from >>> my tree. >>> >>> That said, all this does is cause spurious warnings to be printed, so >>> not sure it really qualifies as serious. But I am happy to leave that >>> decision with the individual arch maintainers -- it is their arch, >>> after all, so their decision. >> >> Couldn't that cause hung tasks due to long lasting synchronize_rcu() ? > > In theory, definitely. In practice, they haven't been running into it, > or they would be reporting hangs. I am hereby reporting that RCU CPU stall warnings and hung tasks are being experienced on SMP kernels built for generic Alpha. This problem dates back quite a few kernel releases. The discussed patches appear to fix the problem. A backport to the 3.2 kernel, of at least the Alpha patches, would be very much appreciated! :-) Cheers Michael. -- 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: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
On 03/08/12 03:02, Fengguang Wu wrote:
> On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
>> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
>> wrote:
Here is the line in sock.i:
struct static_key memalloc_socks = ((struct static_key) { .enabled =
((atomic_t) { (0) }) });
>>>
>>> The above line contains two compound literals. It also uses a designated
>>> initializer to initialize the field enabled. A compound literal is not a
>>> constant expression.
>>
>> Seeing the same thing on ia64 building next-20120726. Same fix works
>> for me ... so I'll steal this whole changelog and attributes.
>
> I got the same error for alpha, the same fix applies.
Just trying this patch on Alpha against v3.6-rc1 and it leads to new
compilation errors, namely:
init/init_task.c:12: error: braced-group within expression allowed only
inside a function
init/init_task.c:13: error: braced-group within expression allowed only
inside a function
init/init_task.c:16: error: braced-group within expression allowed only
inside a function
init/init_task.c:16: error: braced-group within expression allowed only
inside a function
make[1]: *** [init/init_task.o] Error 1
> ---
> From: Mel Gorman
> Subject: [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the
> casts
>
> The following build error occurred during an alpha build:
>
> net/core/sock.c:274:36: error: initializer element is not constant
>
> Dave Anglin says:
>> Here is the line in sock.i:
>>
>> struct static_key memalloc_socks = ((struct static_key) { .enabled =
>> ((atomic_t) { (0) }) });
>
> The above line contains two compound literals. It also uses a designated
> initializer to initialize the field enabled. A compound literal is not a
> constant expression.
>
> The location of the above statement isn't fully clear, but if a compound
> literal occurs outside the body of a function, the initializer list must
> consist of constant expressions.
>
> Reported-by: Fengguang Wu
> Signed-off-by: Mel Gorman
> Cc:
> ---
> arch/alpha/include/asm/atomic.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux.orig/arch/alpha/include/asm/atomic.h2012-05-24
> 19:03:06.0 +0800
> +++ linux/arch/alpha/include/asm/atomic.h 2012-08-02 23:01:02.243224220
> +0800
> @@ -14,8 +14,8 @@
> */
>
>
> -#define ATOMIC_INIT(i) ( (atomic_t) { (i) } )
> -#define ATOMIC64_INIT(i) ( (atomic64_t) { (i) } )
> +#define ATOMIC_INIT(i) ( { (i) } )
> +#define ATOMIC64_INIT(i) ( { (i) } )
>
> #define atomic_read(v) (*(volatile int *)&(v)->counter)
> #define atomic64_read(v) (*(volatile long *)&(v)->counter)
Cheers
Michael.
--
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: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
On 12/08/12 14:10, Fengguang Wu wrote:
> On Sun, Aug 12, 2012 at 01:33:09PM +1200, Michael Cree wrote:
>> On 03/08/12 03:02, Fengguang Wu wrote:
>>> On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
>>>> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
>>>> wrote:
>>>>>> Here is the line in sock.i:
>>>>>>
>>>>>> struct static_key memalloc_socks = ((struct static_key) { .enabled =
>>>>>> ((atomic_t) { (0) }) });
>>>>>
>>>>> The above line contains two compound literals. It also uses a designated
>>>>> initializer to initialize the field enabled. A compound literal is not a
>>>>> constant expression.
>>>>
>>>> Seeing the same thing on ia64 building next-20120726. Same fix works
>>>> for me ... so I'll steal this whole changelog and attributes.
>>>
>>> I got the same error for alpha, the same fix applies.
>>
>> Just trying this patch on Alpha against v3.6-rc1 and it leads to new
>> compilation errors, namely:
>>
>> init/init_task.c:12: error: braced-group within expression allowed only
>> inside a function
>> init/init_task.c:13: error: braced-group within expression allowed only
>> inside a function
>> init/init_task.c:16: error: braced-group within expression allowed only
>> inside a function
>> init/init_task.c:16: error: braced-group within expression allowed only
>> inside a function
>> make[1]: *** [init/init_task.o] Error 1
>
> Sorry! This will actually compile:
>
> -#define ATOMIC_INIT(i) ( { (i) } )
> +#define ATOMIC_INIT(i) { (i) }
Thanks, it now compiles correctly. I'm currently collecting Alpha
patches to send on to Linus so will include this one.
Cheers
Michael.
--
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 1/1] task_work: Add local_irq_enable() into task_work_run()
On Sat 13 October 2012 14:09:36 Linus Torvalds wrote: > On Sat, Oct 13, 2012 at 1:03 AM, Oleg Nesterov wrote: > > arch/alpha and probably some other architectures call > > do_notify_resume()->task_work_run() with irqs disabled. > > I'm going to ignore this patch because I *hope* it is unnecessary > after the pull from Al that I just did. > > But if that turns out to be not the case, please holler. Torsten, you > seem to be the one who reported this, can you check the current git > tree? I thought I might step in and run some tests. Current git compiled for SMP generic Alpha and running on a 3-CPU ES45. I have just managed to compile and run the test of eglibc without any RCU CPU task lockups!! This is the first time in a couple or so years that I have seen a build of eglibc complete under an SMP kernel built for generic Alpha. So, Al, you have made my day! Any chance that we could have the fixes backported to the stable queue, in particular to the 3,2 kernel? We should then be able to run the Debian built SMP kernel on the autobuilders at Debian-Ports rather than having to run a specially built kernel or a UP kernel. BTW, the WARNING: at kernel/softirq.c:139 __local_bh_enable+0xe8/0x110() still occurs when bringing up the CPUs. Actually it happens twice now. I've attached my dmesg dump should you wish to check. Cheers Michael. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.6.0-generic-10664-g4e21fc1 (mjc@electro) (gcc version 4.5.4 (Debian 4.5.4-1+alpha) ) #1 SMP Sat Oct 13 19:29:26 NZDT 2012 [0.00] Booting GENERIC on Titan variation Privateer using machine vector PRIVATEER from SRM [0.00] Major Options: SMP VERBOSE_MCHECK MAGIC_SYSRQ [0.00] Command line: ro root=/dev/sdb3 console=ttyS0 [0.00] memcluster 0, usage 1, start0, end 630 [0.00] memcluster 1, usage 0, start 630, end 524279 [0.00] memcluster 2, usage 1, start 524279, end 524288 [0.00] freeing pages 630:2048 [0.00] freeing pages 3961:524279 [0.00] reserving pages 3961:3969 [0.00] SMP: 3 CPUs probed -- cpu_present_mask = 7 [0.00] On node 0 totalpages: 524279 [0.00] free_area_init_node: node 0, pgdat fc0001e7b100, node_mem_map fc0001f02000 [0.00] DMA zone: 3584 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 520695 pages, LIFO batch:15 [0.00] PERCPU: Embedded 5 pages/cpu @fc0003b14000 s9216 r8192 d23552 u40960 [0.00] pcpu-alloc: s9216 r8192 d23552 u40960 alloc=5*8192 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 520695 [0.00] Kernel command line: ro root=/dev/sdb3 console=ttyS0 [0.00] PID hash table entries: 4096 (order: 2, 32768 bytes) [0.00] Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes) [0.00] Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes) [0.00] Memory: 4134648k/4194232k available (4616k kernel code, 54544k reserved, 8571k data, 400k init) [0.00] SLUB: Genslabs=16, HWalign=64, Order=0-3, MinObjects=0, CPUs=3, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=3. [0.00] NR_IRQS:32784 [0.00] Using epoch = 2000 [0.00] Console: colour dummy device 80x25 [0.00] console [ttyS0] enabled [1.896483] Calibrating delay loop... 2492.28 BogoMIPS (lpj=1216512) [1.980467] pid_max: default: 32768 minimum: 301 [2.035155] Mount-cache hash table entries: 512 [2.090819] Initializing cgroup subsys cpuacct [2.145506] Initializing cgroup subsys devices [2.198241] Initializing cgroup subsys freezer [2.250975] SMP starting up secondaries. [2.298826] Performance events: Supported CPU type! [2.375975] Brought up 3 CPUs [2.412108] SMP: Total of 3 processors activated (7471.73 BogoMIPS). [2.488279] [ cut here ] [2.488279] [ cut here ] [2.488279] WARNING: at kernel/softirq.c:139 __local_bh_enable+0xe8/0x110() [2.488279] Modules linked in: [2.488279] fc00ff123b60 fc0001e597e8 fc0001041848 0200 [2.488279]fc0001e817e8 fc0001e7db85 0001 0040 [2.488279]fc00010426d8 fc0001edbaa0 fc0001645940 fc000164c040 [2.488279]fc000106ca00 fc0001eb0cc0 fc000101bd38 0001 [2.488279]0001 fc000101617c 0001 [2.488279]0001 fc00016348d8 0002 fc00ff097bd0 [2.488279] Trace: [2.488279] [] __local_bh_enable+0xe8/0x110 [2.488279] [] irq_enter+0x68/0x90 [2.488279] [] sche
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Bob Tracy wrote: That was quick :-). Backing out the sysctl_check.c diff gives me a working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though. Michael Cree: could you try backing out the diff below from your 2.6.24-rc3 tree and see if things are now working for you? Yes (conference is now over). I backed out the sysctl_check patch from 2.6.24-rc3 and, indeed, got a working kernel. The working kernel (was probably 2.6.24-rc3 less sysctl_check patch, but might have been a 2.6.23 variant) has the following in /sys/block alpha:~# ls -l /sys/block/ total 0 drwxr-xr-x 5 root root 0 2007-12-08 08:55 fd0 drwxr-xr-x 6 root root 0 2007-12-08 08:55 hde drwxr-xr-x 5 root root 0 2007-12-08 08:55 hdf drwxr-xr-x 10 root root 0 2007-12-08 08:55 sda drwxr-xr-x 9 root root 0 2007-12-08 08:55 sdb alpha:~# ls -l /sys/block/sda total 0 -r--r--r-- 1 root root 8192 2007-12-08 08:55 capability -r--r--r-- 1 root root 8192 2007-12-08 08:55 dev lrwxrwxrwx 1 root root0 2007-12-08 08:55 device -> ../../devices/pci0001:01/0001:01:06.0/host0/target0:0:1/0:0:1:0 drwxr-xr-x 2 root root0 2007-12-08 08:55 holders drwxr-xr-x 3 root root0 2007-12-08 08:55 queue -r--r--r-- 1 root root 8192 2007-12-08 08:55 range -r--r--r-- 1 root root 8192 2007-12-08 08:55 removable drwxr-xr-x 3 root root0 2007-12-08 08:55 sda1 drwxr-xr-x 3 root root0 2007-12-08 08:55 sda2 drwxr-xr-x 3 root root0 2007-12-08 08:55 sda3 drwxr-xr-x 3 root root0 2007-12-08 08:55 sda4 drwxr-xr-x 3 root root0 2007-12-08 08:55 sda5 -r--r--r-- 1 root root 8192 2007-12-08 08:55 size drwxr-xr-x 2 root root0 2007-12-08 08:55 slaves -r--r--r-- 1 root root 8192 2007-12-08 08:55 stat lrwxrwxrwx 1 root root0 2007-12-08 08:55 subsystem -> ../../block --w--- 1 root root 8192 2007-12-08 08:55 uevent alpha:~# grep . /sys/block/sda/*/dev /sys/block/sda/sda1/dev:8:1 /sys/block/sda/sda2/dev:8:2 /sys/block/sda/sda3/dev:8:3 /sys/block/sda/sda4/dev:8:4 /sys/block/sda/sda5/dev:8:5 The broken kernel (2.6.24-rc3) has the following in /sys/block alpha:~# ls -l /sys/block/ total 0 drwxr-xr-x 5 root root 0 Dec 8 09:22 fd0 drwxr-xr-x 6 root root 0 Dec 8 09:22 hde drwxr-xr-x 5 root root 0 Dec 8 09:23 hdf drwxr-xr-x 10 root root 0 Dec 8 09:22 sda drwxr-xr-x 9 root root 0 Dec 8 09:23 sdb alpha:~# ls -l /sys/block/sda total 0 -r--r--r-- 1 root root 8192 Dec 8 09:22 capability -r--r--r-- 1 root root 8192 Dec 8 09:22 dev lrwxrwxrwx 1 root root0 Dec 8 09:23 device -> ../../devices/pci0001:01/0001:01:06.0/host0/target0:0:1/0:0:1:0 drwxr-xr-x 2 root root0 Dec 8 09:22 holders drwxr-xr-x 3 root root0 Dec 8 09:22 queue -r--r--r-- 1 root root 8192 Dec 8 09:22 range -r--r--r-- 1 root root 8192 Dec 8 09:22 removable drwxr-xr-x 3 root root0 Dec 8 09:22 sda1 drwxr-xr-x 3 root root0 Dec 8 09:22 sda2 drwxr-xr-x 3 root root0 Dec 8 09:22 sda3 drwxr-xr-x 3 root root0 Dec 8 09:22 sda4 drwxr-xr-x 3 root root0 Dec 8 09:22 sda5 -r--r--r-- 1 root root 8192 Dec 8 09:22 size drwxr-xr-x 2 root root0 Dec 8 09:22 slaves -r--r--r-- 1 root root 8192 Dec 8 09:22 stat lrwxrwxrwx 1 root root0 Dec 8 09:22 subsystem -> ../../block --w--- 1 root root 8192 Dec 8 09:22 uevent alpha:~# grep . /sys/block/sda/*/dev /sys/block/sda/sda1/dev:8:1 /sys/block/sda/sda2/dev:8:2 /sys/block/sda/sda3/dev:8:3 /sys/block/sda/sda4/dev:8:4 /sys/block/sda/sda5/dev:8:5 I failed to spot any difference (other than the formatting of the dates) between the two! Cheers Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Kay Sievers wrote: On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote: Kay Sievers wrote: Is the udev daemon (still) running while it fails? Yes, and there's something else I forgot to mention that may be significant... For the bad case, in addition to udevd, "ps -ef" shows a "sh -e /lib/udev/net.agent" running with a PPID of 1. This process doesn't exit until I reboot. If this is normal under the circumstances, please disregard. Does SysRq-T show where it hangs? Ummm... No. I didn't have the CONFIG_MAGIC_SYSRQ flag set, so I set it, and recompiled the kernel. Guess what - now the system comes up normally without any problem. The block devices appear in /dev. To recap: without CONFIG_MAGIC_SYSRQ on the 2.6.24-rc3 kernel the missing block devices error in /dev occurs and the init scripts fall over on startup, and with CONFIG_MAGIC_SYSRQ the system comes up normally. To answer the earlier questions about distro, and udev version, my system is similar to Bob's, except that I am running Debian testing/lenny which comes with udev version 114 (dpkg reports udev version 0.114-2). I am running an EV67 variant CPU. I do not run an initramfs - I have the necessary drivers for the various discs compiled into the kernel and use the root kernel option to point to the required root partition. When running the broken kernel udev is running (according to 'ps') and executing /sbin/udevtrigger manually generates a number of errors of the form: scsi_id[]: scsi_id: unable to access '/block' The missing /dev/* entries do not appear. Cheerz Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Bob Tracy wrote: Andrew Morton wrote: Could be something change in sysfs. Please double-check the config options, make sure that something important didn't get disabled. Here's hoping someone else is seeing this or can replicate it in the meantime. Snap. 2.6.24-rc2 works fine. 2.6.24-rc3 boots on Alpha but once /dev is populated no partitions of the scsi sub-system are seen. Looks like ide sub-system similarly affected. Managed to get boot log. Follows below (with output of various /proc info). Cheerz Michael. Linux version 2.6.24-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.3 20071019 (prerelease) (Debian 4.1.2-17)) #1 Mon Nov 26 19:28:58 NZDT 2007 Booting on Tsunami variation Monet using machine vector Monet from SRM Major Options: EV67 LEGACY_START VERBOSE_MCHECK Command line: ro root=/dev/sda3 console=ttyS0 memcluster 0, usage 1, start0, end 215 memcluster 1, usage 0, start 215, end 131062 memcluster 2, usage 1, start 131062, end 131072 freeing pages 215:384 freeing pages 930:131062 reserving pages 930:932 4096K Bcache detected; load hit latency 21 cycles, load miss latency 127 cycles Console graphics on hose 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130167 Kernel command line: ro root=/dev/sda3 console=ttyS0 PID hash table entries: 4096 (order: 12, 32768 bytes) Using epoch = 2000 Turning on RTC interrupts. Console: colour VGA+ 80x25 console [ttyS0] enabled Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 6, 524288 bytes) Memory: 1030896k/1048496k available (2786k kernel code, 15216k reserved, 370k data, 168k init) Mount-cache hash table entries: 512 net_namespace: 120 bytes NET: Registered protocol family 16 PCI: Bridge: 0001:01:08.0 IO window: 8000-8fff MEM window: 0900-090f PREFETCH window: disabled. SMC37c669 Super I/O Controller found @ 0x3f0 Linux Plug and Play Support v0.97 (c) Adam Belay SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 8192 (order: 3, 65536 bytes) TCP established hash table entries: 32768 (order: 6, 524288 bytes) TCP bind hash table entries: 32768 (order: 5, 262144 bytes) TCP: Hash tables configured (established 32768 bind 32768) TCP reno registered srm_env: version 0.0.6 loaded successfully io scheduler noop registered io scheduler cfq registered (default) tridentfb: Trident framebuffer 0.7.8-NEWAPI initializing isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found rtc: SRM (post-2000) epoch (2000) detected Real Time Clock Driver v1.12ac Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Floppy drive(s): fd0 is 2.88M FDC 0 is a post-1991 82077 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx CY82C693: IDE controller (0x1080:0xc693 rev 0x00) at PCI slot :00:07.1 CY82C693: not 100% native mode: will probe irqs later CY82C693U driver v0.34 99-13-12 Andreas S. Krebs ([EMAIL PROTECTED]) ide0: BM-DMA at 0x8400-0x8407, BIOS settings: hda:pio, hdb:pio CY82C693: port 0x01f0 already claimed by ide0 ALI15X3: IDE controller (0x10b9:0x5228 rev 0xc6) at PCI slot 0001:02:09.1 ALI15X3: 100% native mode on irq 28 ide1: BM-DMA at 0x28410-0x28417, BIOS settings: hdc:DMA, hdd:DMA ide2: BM-DMA at 0x28418-0x2841f, BIOS settings: hde:pio, hdf:pio hdf: LITE-ON DVDRW SOHW-1653S, ATAPI CD/DVD-ROM drive hde: ST3200822A, ATA DISK drive ide2 at 0x28438-0x2843f,0x2844e on irq 28 hde: max request size: 512KiB hde: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(100) hde: cache flushes supported hde: hde1 qla1280: QLA1040 found on PCI bus 1, dev 6 scsi(0:0): Resetting SCSI BUS scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter Firmware version: 7.65.06, Driver version 3.26 serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice scsi 0:0:1:0: Direct-Access SEAGATE ST336706LW 0109 PQ: 0 ANSI: 3 scsi(0:0:1:0): Sync: period 10, offset 12, Wide input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 atkbd.c: keyboard reset failed on isa0060/serio1 TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 scsi: waiting for bus probes to complete ... sd 0:0:1:0: [sda] 71687370 512-byte hardware sectors (36704 MB) sd 0:0:1:0: [sda] Write Protect is off sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA sd 0:0:1:0: [sda] 71687370 512-byte hardware sectors (36704 MB) sd 0:0:1:0: [sda] Write Protect is off sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA s
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
On 1/12/2007, at 11:42 AM, Andrew Morton wrote: On Sat, 01 Dec 2007 11:30:01 +1300 Michael Cree <[EMAIL PROTECTED]> wrote: Bob Tracy wrote: Andrew Morton wrote: Could be something change in sysfs. Please double-check the config options, make sure that something important didn't get disabled. Here's hoping someone else is seeing this or can replicate it in the meantime. Snap. 2.6.24-rc2 works fine. 2.6.24-rc3 boots on Alpha but once /dev is populated no partitions of the scsi sub-system are seen. Looks like ide sub-system similarly affected. [snip] eth0: Digital DS21142/43 Tulip rev 65 at Port 0x29400, 08:00:2b:87:4c:b0, IRQ 45. Linux video capture interface: v2.00 scsi_id[402]: scsi_id: unable to access '/block' I guess this is where things go bad. Yes, that is what I thought too. scsi_id is part of udev. Perhaps some sysfs nodes aren't being created correctly. Random guess: what is your setting of CONFIG_SCSI_SCAN_ASYNC and what happens if you invert it? Is set to Y. Changed it to N and recompiled kernel and restarted. No change. Same problems remain. I now realise that not only SCSI drive device nodes are not appearing in /dev, but all disc nodes are not appearing. In my case all of fd0, hde (IDE disc), hdf (CD/DVD), sda (SCSI disc), sdb (SATA disc), sdc (memory card reader), and their accompanying partition nodes, do not get made in /dev. I'm not familiar with sysfs so don't know what what I should be looking for in particular, but I did have a quick noisy around /sys and noted that the above mentioned devices are all appearing at /sys/ block with what appeared to be sensible information in the subdirectories thereof. Sorry, but it is unlikely that I'll be able to look further into this problem at the moment as I am running a conference this week and the storm is about to hit... Cheers Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Generic kernel fails to boot on Alpha bisected to b38d08f3181c
A kernel built for generic UP Alpha had been noted to fail to boot for quite some time (since the release of 3.18). The kernel either locks up before printing any messages to the console or just falls back into the SRM with a HALT instruction again before any messages are printed to the console. A work around is to either use a kernel built for generic SMP or to build a machine specific kernel as these boot correctly. Because there were other compile errors at the time it proved difficult to bisect, but we are continuing to get complaints about it as it renders the Debian Alpha installer somewhat useless, so I returned to trying to find the problem and managed to bisect it to: commit b38d08f3181c5025a7ce84646494cc4748492a3b Author: Tejun Heo Date: Tue Sep 2 14:46:02 2014 -0400 percpu: restructure locking Any suggestions as to what might be the problem and a fix? Cheers, Michael.
Re: Generic kernel fails to boot on Alpha bisected to b38d08f3181c
On Thu, Dec 13, 2018 at 08:07:24AM -0800, Tejun Heo wrote:
> Hello, Michael.
>
> On Thu, Dec 13, 2018 at 09:26:12PM +1300, Michael Cree wrote:
> > A kernel built for generic UP Alpha had been noted to fail to boot
> > for quite some time (since the release of 3.18). The kernel either
> > locks up before printing any messages to the console or just falls
> > back into the SRM with a HALT instruction again before any messages
> > are printed to the console. A work around is to either use a kernel
> > built for generic SMP or to build a machine specific kernel as these
> > boot correctly.
> >
> > Because there were other compile errors at the time it proved
> > difficult to bisect, but we are continuing to get complaints about
> > it as it renders the Debian Alpha installer somewhat useless, so I
> > returned to trying to find the problem and managed to bisect it to:
> >
> > commit b38d08f3181c5025a7ce84646494cc4748492a3b
> > Author: Tejun Heo
> > Date: Tue Sep 2 14:46:02 2014 -0400
> >
> > percpu: restructure locking
> >
> > Any suggestions as to what might be the problem and a fix?
>
> So, the only thing I can think of is that it's calling
> spin_unlock_irq() while irq handling isn't set up yet. Can you please
> try the followings?
>
> 1. Convert all spin_[un]lock_irq() to
>spin_lock_irqsave/unlock_irqrestore().
Yes, that's it. With the attached patch the kernel boots.
Cheers
Michael.
>From e08cf3c714184d8fe168fffcd7d15732924deb1e Mon Sep 17 00:00:00 2001
From: Michael Cree
Date: Fri, 14 Dec 2018 17:24:31 +1300
Subject: [PATCH] percpu: convert spin_lock_irq to spin_lock_irqsave.
Bisection lead to commit b38d08f3181c ("percpu: restructure
locking") as being the cause of lockups at initial boot on
the kernel built for generic Alpha.
On a suggestion by Tejun Heo that:
So, the only thing I can think of is that it's calling
spin_unlock_irq() while irq handling isn't set up yet.
Can you please try the followings?
1. Convert all spin_[un]lock_irq() to
spin_lock_irqsave/unlock_irqrestore().
---
mm/percpu-km.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/percpu-km.c b/mm/percpu-km.c
index 38de70ab1a0d..0f643dc2dc65 100644
--- a/mm/percpu-km.c
+++ b/mm/percpu-km.c
@@ -50,6 +50,7 @@ static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp)
const int nr_pages = pcpu_group_sizes[0] >> PAGE_SHIFT;
struct pcpu_chunk *chunk;
struct page *pages;
+ unsigned long flags;
int i;
chunk = pcpu_alloc_chunk(gfp);
@@ -68,9 +69,9 @@ static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp)
chunk->data = pages;
chunk->base_addr = page_address(pages) - pcpu_group_offsets[0];
- spin_lock_irq(&pcpu_lock);
+ spin_lock_irqsave(&pcpu_lock, flags);
pcpu_chunk_populated(chunk, 0, nr_pages, false);
- spin_unlock_irq(&pcpu_lock);
+ spin_unlock_irqrestore(&pcpu_lock, flags);
pcpu_stats_chunk_alloc();
trace_percpu_create_chunk(chunk->base_addr);
--
2.11.0
Re: [PATCH] include/asm/cmpxchg.h: Remove duplicate header
On Fri, Nov 02, 2018 at 08:56:37PM +0530, Brajeswar Ghosh wrote: > Remove asm/xchg.h which is included more than once > > Signed-off-by: Brajeswar Ghosh > --- > arch/alpha/include/asm/cmpxchg.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/alpha/include/asm/cmpxchg.h > b/arch/alpha/include/asm/cmpxchg.h > index 6c7c39452471..bcbdac0744f9 100644 > --- a/arch/alpha/include/asm/cmpxchg.h > +++ b/arch/alpha/include/asm/cmpxchg.h > @@ -36,7 +36,6 @@ > #undef cmpxchg > #define xchg(type, args...) __xchg ##type(args) > #define cmpxchg(type, args...) __cmpxchg ##type(args) > -#include It's amazing the number of times we get a patch to remove that. Instead of just automatically removing a second include of a header file, why don't you take a closer look to see what it actually does? Cheers, Michael.
Re: [PATCH 2/2] alpha: Add sched_set/getattr and renameat2 syscalls
On Wed, Jul 30, 2014 at 11:42:32AM -1000, Richard Henderson wrote: > Signed-off-by: Richard Henderson > --- > 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(-) I thought Matt had already sent my patch to do just that to Linus. Cheers Michael. -- 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 1/2] alpha: Remove "strange" OSF/1 fork semantics
On Wed, Jul 30, 2014 at 11:42:31AM -1000, Richard Henderson wrote: > The assignment to regs->r20 kills the original tls_val input > to the clone syscall, which means that clone can no longer be > restarted with the original inputs. > > We could, perhaps, retain this result for true fork, but OSF/1 > compatibility is no longer important. Note that glibc has never > used the r20 result value, instead always testing r0 vs 0 to > determine the child/parent status. > > This failure can be seen in the glibc nptl/tst-eintr* tests. > > Reported-by: Michael Cree > Signed-off-by: Richard Henderson The glibc nptl/tst-eintr3 test now works successfully on the SMP system with the patched kernel. In addition builds of openjdk-6 or openjdk-7 use to always fail because javac would randomly lock up at some point. A test build of openjdk-6 has just built successfully to completion with the patched kernel. I am not able to test whether OSF/1 compatibility is adversely affected. Tested-by: Michael Cree Cheers Michael. -- 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/
Bug: retry of clone() on Alpha can result in zeroed process thread pointer
I am seeing a bug in clone() on the Alpha architecture. Reported to Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755397 The test suite of glibc sometimes fails in the nptl/tst-eintr3 test with a segmentation fault. I have tracked it down to the thread pointer returned by the rduniq PALcall is occasionally zero when it should point to the TLS. I have only ever seen this occur when running a SMP kernel. Running strace on nptl/tst-eintr3 reveals that the clone() syscall is retried by the kernel if an ERESTARTNOINTR error occurs. At $syscall_error in arch/alpha/kernel/entry.S the kernel handles the error and in doing that it writes to 72(sp) which is where the value of the a3 CPU register on entry to the kernel is stored. Then the kernel retries the clone() function. But the alpha specific code for copy_thread() in arch/alpha/kernel/process.c does not use the passed a3 cpu register (the argument tls), instead it goes to the saved stack to get the value of the a3 register, which on the second call to clone() has been modified to no longer be the value of the a3 cpu register on entry to the kernel. And a latent bomb is laid for userspace in the form of an incorrect process unique value (which is the thread pointer) in the PCB. Am I correct in my analysis and, if so, can we get a fix for this please. Cheers Michael. -- 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: Bug: retry of clone() on Alpha can result in zeroed process thread pointer
On Thu, Jul 24, 2014 at 08:19:52AM -1000, Richard Henderson wrote:
> On 07/22/2014 10:52 PM, Michael Cree wrote:
> > Running strace on nptl/tst-eintr3 reveals that the clone() syscall
> > is retried by the kernel if an ERESTARTNOINTR error occurs. At
> > $syscall_error in arch/alpha/kernel/entry.S the kernel handles the
> > error and in doing that it writes to 72(sp) which is where the value
> > of the a3 CPU register on entry to the kernel is stored. Then the
> > kernel retries the clone() function. But the alpha specific code
> > for copy_thread() in arch/alpha/kernel/process.c does not use the
> > passed a3 cpu register (the argument tls), instead it goes to the
> > saved stack to get the value of the a3 register, which on the
> > second call to clone() has been modified to no longer be the value
> > of the a3 cpu register on entry to the kernel. And a latent bomb
> > is laid for userspace in the form of an incorrect process unique
> > value (which is the thread pointer) in the PCB.
> >
> > Am I correct in my analysis and, if so, can we get a fix for this
> > please.
>
> Well... let me start with the assumption that we can't possibly restart
> unless
> the syscall fails with -ERESTART*.
>
> Before we clobber 72($sp), $syscall_error saves the old value in $19. This is
> the r19 parameter to do_work_pending, and is passed all the way down to
> syscall_restart where we do restore the original value of a3 for
> ERESTARTNOINTR.
>
> So if there's a path that leads to restart, but doesn't save a3 before
> clobbering, I don't see it. Do you have an strace dump that shows this?
Yes. This is an example of a run of nptl/tst-eintr3 that fails after
cutting off quite a bit of stuff at the start to get to the relevant
section:
clone(child_stack=0x2000121eae0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x2000121f2c0, tls=0x2000121f8e0, child_tidptr=0x2000121f2c0) =
? ERESTARTNOINTR (To be restarted)
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=20086, si_uid=1000} ---
write(1, ".", 1.)= 1
sigreturn() (mask []) = -1 ERRNO_312 (Unknown error 312)
clone(child_stack=0x2000121eae0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x2000121f2c0, tls=0, child_tidptr=0x2000121f2c0) = 20089
+++ killed by SIGSEGV +++
Note that the retry of clone() has zero for the tls argument.
Examining the resultant core dump reveals that tst-eintr3 segfaulted
when trying to access a thread local variable and that register v0,
used in calculating the TLS location and set up by the rduniq PALcall,
is zero.
Cheers
Michael.
--
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 3.12 117/133] alpha: fix broken network checksum
On Tue, Feb 04, 2014 at 01:08:38PM -0800, Greg Kroah-Hartman wrote: > 3.12-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Mikulas Patocka > > commit 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd upstream. > > The patch 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 breaks networking on > alpha (there is a follow-up fix 5cfe8f1ba5eebe6f4b6e5858cdb1a5be4f3272a6, > but networking is still broken even with the second patch). I wonder whether that follow-up (partial) fix mentioned (5cfe8f1ba5eebe6f4b6e5858cdb1a5be4f3272a6) should be pulled into 3.12 stable too? Cheers Michael. -- 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: bit fields && data tearing
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote: > On 09/04/2014 05:59 PM, Peter Hurley wrote: > > I have no idea how prevalent the ev56 is compared to the ev5. > > Still we're talking about a chip that came out in 1996. > > Ah yes, I stand corrected. According to Wikipedia, the affected CPUs > were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164 with no > suffix (EV5). However, we're still talking about museum pieces here. Yes, that is correct, EV56 is the first Alpha CPU to have the byte-word extension (BWX) CPU instructions. It would not worry me if the kernel decided to assume atomic aligned scalar accesses for all arches, thus terminating support for Alphas without BWX. The X server, ever since the libpciaccess change, does not work on Alphas without BWX. Debian Alpha (pretty much up to date at Debian-Ports) is still compiled for all Alphas, i.e., without BWX. The last attempt to start compiling Debian Alpha with BWX, about three years ago when Alpha was kicked out to Debian-Ports resulted in a couple or so complaints so got nowhere. It's frustrating supporting the lowest common demoninator as many of the bugs specific to Alpha can be resolved by recompiling with the BWX. The kernel no longer supporting Alphas without BWX might just be the incentive we need to switch Debian Alpha to compiling with BWX. Cheers Michael. -- 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: bit fields && data tearing
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote: > Second, in the body of the document: > > "The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these > older CPUs _do not provide_ atomic one-byte and two-byte loads and stores." Let's be clear here, the pre-EV56 Alpha CPUs do provide an atomic one-byte and two-byte load and store; it's just that one must use locked load and store sequences to achieve atomicity. The point, I think, is that the pre-EV56 Alpha CPUs provide non-atomic one-byte and two-byte load and stores as the norm, and that is the problem. Cheers Michael. -- 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: bit fields && data tearing
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote: > On 09/05/2014 01:14 PM, Peter Hurley wrote: > > > > Here's how I read the two statements. > > > > First, the commit message: > > > > "It [this commit] documents that CPUs [supported by the Linux kernel] > > _must provide_ atomic one-byte and two-byte naturally aligned loads and > > stores." > > > > Second, in the body of the document: > > > > "The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these > > older CPUs _do not provide_ atomic one-byte and two-byte loads and stores." > > > > Does this apply in general or only to SMP configurations? I guess > non-SMP configurations would still have problems if interrupted in the > wrong place... Yes. Cheers Michael. -- 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: bit fields && data tearing
On Fri, Sep 05, 2014 at 05:12:28PM -0400, Peter Hurley wrote: > On 09/05/2014 04:39 PM, Michael Cree wrote: > > On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote: > >> Second, in the body of the document: > >> > >> "The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these > >> older CPUs _do not provide_ atomic one-byte and two-byte loads and stores." > > > > Let's be clear here, the pre-EV56 Alpha CPUs do provide an atomic > > one-byte and two-byte load and store; it's just that one must use > > locked load and store sequences to achieve atomicity. The point, > > I think, is that the pre-EV56 Alpha CPUs provide non-atomic one-byte > > and two-byte load and stores as the norm, and that is the problem. > > I'm all for an Alpha expert to jump in here and meet the criteria; > which is that byte stores cannot corrupt adjacent storage (nor can > aligned short stores). > > To my mind, a quick look at Documentation/circular-buffers.txt will > pretty much convince anyone that trying to differentiate by execution > context is undoable. > > If someone wants to make Alphas do cmpxchg loops for every byte store, > then ok. Or any other solution that doesn't require subsystem code > changes. I am not suggesting that anyone do that work. I'm certainly not going to do it. All I was pointing out is that the claim that "_do not provide_" made above with emphasis is, strictly interpreted, not true, thus should not be committed to the documentation without further clarification. Cheers Michael. -- 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 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. Cheers Michael. -- 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 07, 2015 at 10:30:44PM +, Mathieu Desnoyers wrote: > > 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. What could one anticipate to be the symptoms of such a missing lockless_dereference()? The Alpha kernel is behaving pretty well provided one builds a machine specific kernel and UP. When running an SMP kernel some packages (most notably the java runtime, but there are a few others) occasionally lock up in a pthread call --- could be a problem in libc rather then the kernel. > > Meta-comment, do we really care about Alpha anymore? Is it still > > consered an "active" arch we support? There are a few of us still running recent kernels on Alpha. I am maintaining the unofficial Debian alpha port at debian-ports, and the Debian popcon shows about 10 installations of Debian Alpha. Cheers Michael. -- 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 Sun, Feb 08, 2015 at 08:59:41AM +0800, Greg KH wrote: > On Sun, Feb 08, 2015 at 01:47:29PM +1300, Michael Cree wrote: > > On Sat, Feb 07, 2015 at 10:30:44PM +, Mathieu Desnoyers wrote: > > > > 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. > > > > What could one anticipate to be the symptoms of such a missing > > lockless_dereference()? > > > > The Alpha kernel is behaving pretty well provided one builds a machine > > specific kernel and UP. When running an SMP kernel some packages > > (most notably the java runtime, but there are a few others) occasionally > > lock up in a pthread call --- could be a problem in libc rather then the > > kernel. > > Hm, if only UP alpha needs to be supported, odds are we could rip a lot > of odd stuff out of the kernel that deals with memory barriers and other > nasty locking things that the Alpha requires. > > Would that be ok? Or is someone somewhere going to want to be running a > SMP kernel on Alpha in the future? I am running an SMP kernel on a 3-cpu Alpha system; it mostly works just fine. I was just noting that there is something up with java---it locks up occassionally in a pthread call, and there are a few other packages that occasionally fail in test suites when being built under an SMP kernel but always pass when built under an UP kernel which suggests there is a little buglet somewhere in the SMP code, either in the kernel or in libc. Running an SMP system for the Debian Alpha build daemon at debian-ports is really useful for keeping up with the other architectures. Cheers Michael. -- 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 Sun, Feb 08, 2015 at 04:25:46AM +, Mathieu Desnoyers wrote: > > From: "Michael Cree" > > The Alpha kernel is behaving pretty well provided one builds a machine > > specific kernel and UP. When running an SMP kernel some packages > > (most notably the java runtime, but there are a few others) occasionally > > lock up in a pthread call --- could be a problem in libc rather then the > > kernel. > > Are those lockups always occasional, or you have ways to reproduce them > frequently with stress-tests ? They are occasional but a build of openjdk-7 bootstrapping from itself is very likely to end up with a locked up javac process. I've just set such a build going with the openjdk-7 build-dependencies and some extra debug packages installed in the build chroot to see if I can get a useful backtrace. Will be tomorrow morning when I look as I am now heading off for the night. Cheers Michael. -- 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 00/15] arch: synchronize syscall tables in preparation for y2038
On Thu, Jan 10, 2019 at 11:42:32PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers wrote:
> >
> > On Thu, 10 Jan 2019, Arnd Bergmann wrote:
> >
> > > - Add system calls that have not yet been integrated into all
> > > architectures but that we definitely want there.
> >
> > glibc has a note that alpha lacks statfs64, any plans for that?
>
> Good catch, I missed that because all other 64-bit architectures
> have a statfs() call with 64-bit fields. I see that it also has an
> osf_statfs64 structure and system call with lots of padding and some
> oddly sized fields: f_type, f_flags and f_namemax are only 16 bits
> wide, the rest is all 64-bit.
>
> Adding the regular statfs64() should be easy enough, we just need to
> decide which layout to use:
>
> a) use the currently unused 'struct statfs64' as provided by the
> alpha uapi headers, which has a 32-bit __statfs_word but
> 64-bit f_blocks, f_bfree, f_bavail, f_files, and f_ffree.
>
> b) copy asm-generic/statfs.h to the alpha asm/statfs.h and
> change statfs64 to have the regular layout that we use
> on all other 64-bit architectures, using all 64-bit fields.
>
> The other open question for alpha (as mentioned in one of the
> patches I sent) would be whether to add get{eg,eu,g,p,pp,u}id()
> with the regular calling conventions.
I would be interested in seeing those provided on Alpha. There are
a handful of projects choosing to sidestep glibc for these syscalls
and they break on Alpha. Such projects are never keen to include
special assembler code (because the extant syscalls on Alpha are not
C ABI compliant) to support a legacy arch.
Cheers
Michael.
Re: Question about DEC Alpha memory ordering
On Tue, Feb 14, 2017 at 12:35:58PM +0100, Andrea Parri wrote:
> On Mon, Feb 13, 2017 at 01:24:36PM -0800, Paul E. McKenney wrote:
> >
> >
> > C auto/C-LB-LRW+OB-Ov
> > (*
> > * Result: Maybe
> > * P0-P1 rf OB-Ov: Never->Maybe: Note lack of C11 guarantee, control
> > dependency
> > * P1 Ov,LRW: Note lack of C11 guarantee, control dependency
> > *)
> > {
> > }
> >
> > P0(int *u0, int *x1)
> > {
> > r1 = READ_ONCE(*u0);
> > smp_mb();
> > WRITE_ONCE(*x1, 1);
> > }
> >
> >
> > P1(int *u0, int *x1)
> > {
> > r1 = READ_ONCE(*x1);
> > WRITE_ONCE(*u0, r1);
> > }
> >
> > exists
> > (0:r1=1 /\ 1:r1=1)
> >
>
> The (automatically generated) module for this test is at
>
>http://retis.sssup.it/~a.parri/lkmm/C-LB-LRW+OB-Ov.tgz ;
>
> the test is run by cat-ing /sys/kernel/litmus/p_count: this will execute
> the thread bodies for "runs * size" iterations; results can be sentisive
> to the "stride" and "affinity increment" parameters (c.f., the Makefile);
> statistics for each experiments are printed on stdout.
This is the test run on a 3-cpu ES45 with the settings in the Makefile:
Test auto/LB-LRW+OB-Ov Allowed
Histogram (2 states)
5913093 :> 0:r1=0; 1:r1=0;
4086907 :> 0:r1=0; 1:r1=1;
No
Witnesses
Positive: 0 Negative: 1000
Condition exists (0:r1=1 /\ 1:r1=1) is NOT validated
Observation auto/LB-LRW+OB-Ov Never 0 1000
Time auto/LB-LRW+OB-Ov 9.570
Hash=200258693ffc841829310726a4a0b7e3
How do we interpret these results?
Cheers
Michael.
Re: Question about DEC Alpha memory ordering
Hi Paul, On Mon, Feb 13, 2017 at 11:09:31AM -0800, Paul E. McKenney wrote: > On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote: > > On 2/13/17 1:39 PM, Paul E. McKenney wrote: > > > can real DEC Alpha hardware end up with both instances of "r1" > > > having the value 1? > > > > I thought this question reminded me of something, so I found this: > > > https://www.kernel.org/doc/Documentation/memory-barriers.txt > > > > and I pasted in the content - David Howells is one of the authors and > > maybe that is why the question sort of reminded me. > > > > Maybe someone has an update but this is what was said then. > > Well, thank you for pointing me to this, but my question was intended to > check whether or not the words I helped to write in memory-barriers.txt > are in fact accurate. So if you have an SMP DEC Alpha system that you > could provide remote access to, that would be very helpful! I'm that guy with an SMP Alpha system who met you at Linux Conference Australia after your talk on memory barriers. I meant to get back to you but tracking down a kernel bug and now a binutils/glibc bug has got the better of my time. Feel free to email me personally to arrange remote access to an SMP Alpha system, preferrably with a GPG signed message. Cheers Michael.
Alpha Kernel Regression [was Re: BRSGP relocation truncations in linking kernel for Alpha.]
On Tue, Oct 25, 2016 at 09:26:38PM +1300, Michael Cree wrote: > And while I mention libc I am seeing (rather rare) random segfaults > in programs such as cp, tar, install and dpkg ever since the upgrade > to glibc 2.23 (or maybe it was 2.24). I am struggling to get a > backtrace because it only happens very occassionally (but often enough > that it is almost impossible for a build and install of large software > packages such as libreoffice to complete without failure at some > random point) and when I rerun the failing program manually it then > always works. I'll keep trying to narrow this one down. It's not glibc. Downgrading to previously known working versions does not solve the random segfaults. But downgrading the kernel does fix the problem on Alpha. Noted that 4.6 is good but 4.6.7 is bad so bisected the 4.6.y stable kernel branch to get the first bad commit as 0784672d05684de901fc2aa56150d7ea9a475a2d, i.e.: commit 0784672d05684de901fc2aa56150d7ea9a475a2d Author: Chen Feng Date: Fri May 20 16:59:02 2016 -0700 mm/compaction.c: fix zoneindex in kcompactd() commit 6cd9dc3e75078ef646076fa63adfb9b85ced0b66 upstream. While testing the kcompactd in my platform 3G MEM only DMA ZONE. I found the kcompactd never wakeup. It seems the zoneindex has already minus 1 before. So the traverse here should be <=. It fixes a regression where kswapd could previously compact, but kcompactd not. Not a crash fix though. Cheers Michael.
Re: Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage)
On Thu, Jun 11, 2020 at 09:23:52PM -0700, Matt Turner wrote: > Since I noticed earlier that using maxcpus=1 on a 2-CPU system > prevented the system from hanging, I tried disabling CONFIG_SMP on my > 1-CPU system as well. In doing so, I discovered that the RCU torture > module (RCU_TORTURE_TEST) triggers some null pointer dereferences on > Alpha when CONFIG_SMP is set, but works successfully when CONFIG_SMP > is unset. > > That seems likely to be a symptom of the same underlying problem that > started this thread, don't you think? If so, I'll focus my attention > on that. I wonder if that is related to user space segfaults we are now seeing on SMP systems but not UP systems while building Alpha debian-ports. It's happening in the test-suites of builds of certain software (such as autogen and guile) but they always build successfully with the test suite passing on a UP system. When investigating I seem to recall it was a NULL (or near NULL) pointer dereference but couldn't make any sense of how it might have got into such an obviously wrong state. Cheers, Michael.
Re: [BUG] alpha: module xxx: Unknown relocation: 1
On Wed, Apr 12, 2017 at 07:57:52AM +0200, Helge Deller wrote:
> On 12.04.2017 04:59, Bob Tracy wrote:
> > Bottom line is, no kernel I've built since 4.9 can load a module. All
> > attempts to load a module result in the error message emitted by
> > "arch/alpha/kernel/module.c" as follows:
> >
> > module XXX: Unknown relocation: 1
> >
>
> I assume it's due this commmit "modversions: treat symbol CRCs as 32 bit
> quantities":
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71810db27c1c853b335675bee335d893bc3d324b
>
> For parisc this patch solves it:
> parisc: support R_PARISC_SECREL32 relocation in modules
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5f655322b1ba4bd46e26e307d04098f9c84df764
>
> > module XXX: Unknown relocation: 1
>
> For alpha it seems you need to add similar code to handle R_ALPHA_REFLONG
> to apply_relocate_add() in arch/alpha/kernel/module.c
Would the attached patch fix it? Untested because I don't see the
above issue.
Cheers
Michael.
diff --git a/arch/alpha/kernel/module.c b/arch/alpha/kernel/module.c
index 936bc8f89a67..47632fa8c24e 100644
--- a/arch/alpha/kernel/module.c
+++ b/arch/alpha/kernel/module.c
@@ -181,6 +181,9 @@ apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
switch (r_type) {
case R_ALPHA_NONE:
break;
+ case R_ALPHA_REFLONG:
+ *(u32 *)location = value;
+ break;
case R_ALPHA_REFQUAD:
/* BUG() can produce misaligned relocations. */
((u32 *)location)[0] = value;
Re: [PATCH 1/8] signal/alpha: Document a conflict with SI_USER for SIGTRAP
On Fri, Jul 14, 2017 at 05:59:06AM -0500, Eric W. Biederman wrote: > in which cases the oddities will happen let alone test them. Plus at > least for ia64 and alpha those architectures don't appear to be > receiving updates for new syscalls, and no new hardware is being built > so I don't know how much longer they will last. > > That is building for alpha gives: > > CALL > > /home/eric/projects/linux/linux-exit-cleanups/scripts/checksyscalls.sh > > :1239:2: warning: #warning syscall seccomp not implemented [-Wcpp] > > :1248:2: warning: #warning syscall bpf not implemented [-Wcpp] > > :1299:2: warning: #warning syscall userfaultfd not implemented > > [-Wcpp] > > :1302:2: warning: #warning syscall membarrier not implemented [-Wcpp] > > :1305:2: warning: #warning syscall mlock2 not implemented [-Wcpp] > > :1308:2: warning: #warning syscall copy_file_range not implemented > > [-Wcpp] > > :1311:2: warning: #warning syscall preadv2 not implemented [-Wcpp] > > :1314:2: warning: #warning syscall pwritev2 not implemented [-Wcpp] > > :1317:2: warning: #warning syscall pkey_mprotect not implemented > > [-Wcpp] > > :1320:2: warning: #warning syscall pkey_alloc not implemented [-Wcpp] > > :1323:2: warning: #warning syscall pkey_free not implemented [-Wcpp] > > :1326:2: warning: #warning syscall statx not implemented [-Wcpp] Patches to wire up most of those syscalls on Alpha was posted recently along with others to fix module loading, etc., but unfortunately they do not appear to have been applied during the merge window... Cheers, Michael.
[PATCH] alpha: Implement CPU vulnerabilities sysfs functions.
Implement the CPU vulnerabilty show functions for meltdown, spectre_v1
and spectre_v2 on Alpha.
Tests on XP1000 (EV67/667MHz) and ES45 (EV68CB/1.25GHz) show them
to be vulnerable to Meltdown and Spectre V1. In the case of
Meltdown I saw a 1 to 2% success rate in reading bytes on the
XP1000 and 50 to 60% success rate on the ES45. (This compares to
99.97% success reported for Intel CPUs.) Report EV6 and later
CPUs as vulnerable.
Tests on PWS600au (EV56/600MHz) for Spectre V1 attack were
unsuccessful (though I did not try particularly hard) so mark EV4
through to EV56 as not vulnerable.
Signed-off-by: Michael Cree
---
arch/alpha/Kconfig | 1 +
arch/alpha/kernel/Makefile | 2 +-
arch/alpha/kernel/bugs.c | 45 +
3 files changed, 47 insertions(+), 1 deletion(-)
create mode 100644 arch/alpha/kernel/bugs.c
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index e96adcbcab41..b2022885ced8 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -18,6 +18,7 @@ config ALPHA
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select AUDIT_ARCH
select GENERIC_CLOCKEVENTS
+ select GENERIC_CPU_VULNERABILITIES
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/arch/alpha/kernel/Makefile b/arch/alpha/kernel/Makefile
index bf7b41fa7b01..5a74581bf0ee 100644
--- a/arch/alpha/kernel/Makefile
+++ b/arch/alpha/kernel/Makefile
@@ -9,7 +9,7 @@ ccflags-y := -Wno-sign-compare
obj-y:= entry.o traps.o process.o osf_sys.o irq.o \
irq_alpha.o signal.o setup.o ptrace.o time.o \
- systbls.o err_common.o io.o
+ systbls.o err_common.o io.o bugs.o
obj-$(CONFIG_VGA_HOSE) += console.o
obj-$(CONFIG_SMP) += smp.o
diff --git a/arch/alpha/kernel/bugs.c b/arch/alpha/kernel/bugs.c
new file mode 100644
index ..08cc10d7fa17
--- /dev/null
+++ b/arch/alpha/kernel/bugs.c
@@ -0,0 +1,45 @@
+
+#include
+#include
+
+
+#ifdef CONFIG_SYSFS
+
+static int cpu_is_ev6_or_later(void)
+{
+ struct percpu_struct *cpu;
+unsigned long cputype;
+
+cpu = (struct percpu_struct *)((char *)hwrpb +
hwrpb->processor_offset);
+cputype = cpu->type & 0x;
+/* Include all of EV6, EV67, EV68, EV7, EV79 and EV69. */
+return (cputype == EV6_CPU) || ((cputype >= EV67_CPU) && (cputype <=
EV69_CPU));
+}
+
+ssize_t cpu_show_meltdown(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (cpu_is_ev6_or_later())
+ return sprintf(buf, "Vulnerable\n");
+ else
+ return sprintf(buf, "Not affected\n");
+}
+
+ssize_t cpu_show_spectre_v1(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ if (cpu_is_ev6_or_later())
+ return sprintf(buf, "Vulnerable\n");
+ else
+ return sprintf(buf, "Not affected\n");
+}
+
+ssize_t cpu_show_spectre_v2(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (cpu_is_ev6_or_later())
+ return sprintf(buf, "Vulnerable\n");
+ else
+ return sprintf(buf, "Not affected\n");
+}
+#endif
--
2.11.0
Re: [PATCH] alpha: fix crash if pthread_create races with signal delivery
On Tue, Jan 02, 2018 at 02:01:34PM -0500, Mikulas Patocka wrote: > On alpha, a process will crash if it attempts to start a thread and a > signal is delivered at the same time. The crash can be reproduced with > this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html > > The reason for the crash is this: > * we call the clone syscall > * we go to the function copy_process > * copy process calls copy_thread_tls, it is a wrapper around copy_thread > * copy_thread sets the tls pointer: childti->pcb.unique = regs->r20 > * copy_thread sets regs->r20 to zero > * we go back to copy_process > * copy process checks "if (signal_pending(current))" and returns > -ERESTARTNOINTR > * the clone syscall is restarted, but this time, regs->r20 is zero, so > the new thread is created with zero tls pointer > * the new thread crashes in start_thread when attempting to access tls > > The comment in the code says that setting the register r20 is some > compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so > we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug > by zeroing regs->r20 only if CLONE_SETTLS is not set. This bug was identified some three years ago; it triggers a failure in the glibc nptl/tst-eintr3 test. See: https://marc.info/?l=linux-alpha&m=140610647213217&w=2 and a fix was proposed by RTH, namely: https://marc.info/?l=linux-alpha&m=140675667715872&w=2 but was never included in the kernel because someone objected to breaking the ability to run OSF/1 executables. That patch also deleted the line to set childregs->r20 to 1 which I mark below. > > Signed-off-by: Mikulas Patocka > Cc: sta...@vger.kernel.org > > --- > arch/alpha/kernel/process.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: linux-stable/arch/alpha/kernel/process.c > === > --- linux-stable.orig/arch/alpha/kernel/process.c 2017-12-31 > 17:42:12.0 +0100 > +++ linux-stable/arch/alpha/kernel/process.c 2018-01-02 18:06:24.0 > +0100 > @@ -265,12 +265,13 @@ copy_thread(unsigned long clone_flags, u > application calling fork. */ > if (clone_flags & CLONE_SETTLS) > childti->pcb.unique = regs->r20; > + else > + regs->r20 = 0; /* OSF/1 has some strange fork() semantics. */ > childti->pcb.usp = usp ?: rdusp(); > *childregs = *regs; > childregs->r0 = 0; > childregs->r19 = 0; > childregs->r20 = 1; /* OSF/1 has some strange fork() semantics. */ This line. Is it not also problematic? Cheers Michael. > - regs->r20 = 0; > stack = ((struct switch_stack *) regs) - 1; > *childstack = *stack; > childstack->r26 = (unsigned long) ret_from_fork; > -- > To unsubscribe from this list: send the line "unsubscribe linux-alpha" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] alpha: support R_ALPHA_REFLONG relocations for module loading
Since commit 71810db27c1c853b33 (modversions: treat symbol CRCs
as 32 bit quantities) R_ALPHA_REFLONG relocations can be required
to load modules. This implements it.
Tested-by: Bob Tracy
Signed-off-by: Michael Cree
---
arch/alpha/kernel/module.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/alpha/kernel/module.c b/arch/alpha/kernel/module.c
index 936bc8f89a67..47632fa8c24e 100644
--- a/arch/alpha/kernel/module.c
+++ b/arch/alpha/kernel/module.c
@@ -181,6 +181,9 @@ apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
switch (r_type) {
case R_ALPHA_NONE:
break;
+ case R_ALPHA_REFLONG:
+ *(u32 *)location = value;
+ break;
case R_ALPHA_REFQUAD:
/* BUG() can produce misaligned relocations. */
((u32 *)location)[0] = value;
--
2.11.0
Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables
On Thu, Sep 28, 2017 at 08:43:54AM -0700, Paul E. McKenney wrote: > On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote: > > On Thu, Sep 28, 2017 at 10:38:01AM +0200, Peter Zijlstra wrote: > > > On Wed, Sep 27, 2017 at 04:49:28PM +0100, Will Deacon wrote: > > > > In many cases, page tables can be accessed concurrently by either > > > > another > > > > CPU (due to things like fast gup) or by the hardware page table walker > > > > itself, which may set access/dirty bits. In such cases, it is important > > > > to use READ_ONCE/WRITE_ONCE when accessing page table entries so that > > > > entries cannot be torn, merged or subject to apparent loss of coherence. > > > > > > In fact, we should use lockless_dereference() for many of them. Yes > > > Alpha is the only one that cares about the difference between that and > > > READ_ONCE() and they do have the extra barrier, but if we're going to do > > > this, we might as well do it 'right' :-) > > > > I know this sounds daft, but I think one of the big reasons why > > lockless_dereference() doesn't get an awful lot of use is because it's > > such a mouthful! Why don't we just move the smp_read_barrier_depends() > > into READ_ONCE? Would anybody actually care about the potential impact on > > Alpha (which, frankly, is treading on thin ice given the low adoption of > > lockless_dereference())? > > This is my cue to ask my usual question... ;-) > > Are people still running mainline kernels on Alpha? (Added Alpha folks.) Yes. I run two Alpha build daemons that build the unofficial debian-alpha port. Debian popcon reports nine machines running Alpha, which are likely to be running the 4.12.y kernel which is currently in debian-alpha, (and presumably soon to be 4.13.y which is now built on Alpha in experimental). Cheers Michael
