[REGRESSION][BISECTED] 5.9-rc4 disables console on radeon

[Mikael Pettersson]

Starting with linux-5.9-rc4, the Dell monitor on my desktop PC goes
black during boot
when the kernel activates the framebuffer console, except for this
error message shown
in the center of the screen:

"Dell U2412M
 The current input timing is not supported by the monitor display. Please
 change your input timing to 1920x1200@60Hz or any other monitor
 listed timing as per the monitor specifications.
 "

The monitor remains black until I reboot.

All kernels up to and including 5.9-rc3 were Ok.  A git bisect identified

# first bad commit: [fc8c70526bd30733ea8667adb8b8ffebea30a8ed]
drm/radeon: Prefer lower feedback dividers

as the culprit, and reverting that from -rc4 makes the console work again.

Adding a bit of debugging code to that function shows:

avivo_get_fb_ref_div: fb_div_new 136 fb_div_old 137
avivo_get_fb_ref_div: fb_div_new 142 fb_div_old 143
avivo_get_fb_ref_div: fb_div_new 136 fb_div_old 137
avivo_get_fb_ref_div: fb_div_new 119 fb_div_old 120
avivo_get_fb_ref_div: fb_div_new 136 fb_div_old 137

during boot, where "new" is what the commit above changed the code to compute,
and "old" is the value computed by the working code from rc3.

The graphics card is a Radeon HD6450 silent model:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] (prog-if 00
[VGA controller])

Re: [PATCH 09/16] sparc64: use the generic get_user_pages_fast code

[Mikael Pettersson]

For the record the futex test case OOPSes a 5.3-rc3 kernel running on
a Sun Blade 2500 (2 x USIIIi).  This system runs a custom distro with
a custom toolchain (gcc-8.3 based), so I doubt it's a distro problem.

On Sat, Aug 10, 2019 at 9:17 AM Christoph Hellwig  wrote:
>
> There isn't really a way to use an arch-specific get_user_pages_fast
> in mainline, you'd need to revert the whole series.  As a relatively
> quick workaround you can just remove the
>
> select HAVE_FAST_GUP if SPARC64
>
> line from arch/sparc/Kconfig

Re: [5.0-rc5 regression] "scsi: kill off the legacy IO path" causes 5 minute delay during boot on Sun Blade 2500

[Mikael Pettersson]

On Sun, Feb 10, 2019 at 5:05 PM Jens Axboe  wrote:
>
> On 2/10/19 8:44 AM, James Bottomley wrote:
> > On Sun, 2019-02-10 at 10:17 +0100, Mikael Pettersson wrote:
> >> On Sat, Feb 9, 2019 at 7:19 PM James Bottomley
> >>  wrote:
> > [...]
> >>> I think the reason for this is that the block mq path doesn't feed
> >>> the kernel entropy pool correctly, hence the need to install an
> >>> entropy gatherer for systems that don't have other good random
> >>> number sources.
> >>
> >> That does sound plausible, I admit I didn't even consider the
> >> possibility that the old block I/O path also was an entropy source.
> >
> > In theory, the new one should be as well since the rotational entropy
> > collector is on the SCSI completion path.   I'd seen the same problem
> > but had assumed it was something someone had done to our internal
> > entropy pool and thus hadn't bisected it.
>
> The difference is that the old stack included ADD_RANDOM by default,
> so this check:
>
> if (blk_queue_add_random(q))
> add_disk_randomness(req->rq_disk);
>
> in scsi_end_request() would be true, and we'd add the randomness. For
> sd, it seems to set it just fine for non-rotational drives. Could this
> be because other devices don't? Maybe the below makes a difference.
>
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 6d65ac584eba..60e029911755 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1881,6 +1881,7 @@ struct request_queue *scsi_mq_alloc_queue(struct 
> scsi_device *sdev)
> sdev->request_queue->queuedata = sdev;
> __scsi_init_queue(sdev->host, sdev->request_queue);
> blk_queue_flag_set(QUEUE_FLAG_SCSI_PASSTHROUGH, sdev->request_queue);
> +   blk_queue_flag_set(QUEUE_FLAG_ADD_RANDOM, sdev->request_queue);
> return sdev->request_queue;
>  }

This patch eliminates my 5 minute boot-up delay problem.

/Mikael

Re: [5.0-rc5 regression] "scsi: kill off the legacy IO path" causes 5 minute delay during boot on Sun Blade 2500

[Mikael Pettersson]

On Sat, Feb 9, 2019 at 7:19 PM James Bottomley
 wrote:
>
> On Sat, 2019-02-09 at 18:04 +0100, Mikael Pettersson wrote:
> > 4.20 and earlier kernels boot fine on my Sun Blade 2500 (UltraSPARC
> > IIIi), but the 5.0-rc kernels consistently experience a 5 minute
> > delay
> > late during boot, after enabling networking but before allowing user
> > logins.  E.g. 5.0-rc5 dmesg has:
> >
> > [Fri Feb  8 17:13:17 2019] random: dbus-daemon: uninitialized urandom
> > read (12 bytes read)
> > [Fri Feb  8 17:18:14 2019] random: crng init done
>
> I've had the same problem on several of my test systems.  Are you sure
> it's not this bug report:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087
>
> ?
>
> The solution for me was to install the haveged package which does
> active entropy gathering during boot and can make /dev/urandom
> available much earlier.

Thanks for the hint, I'll look into using haveged on this machine.

>
> > During this interval the machine answers pings but won't allow user
> > logins either on the console or over the network.
> >
> > A git bisect identified commit
> > f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6
> > Author: Jens Axboe 
> > Date:   Thu Nov 1 16:36:27 2018 -0600
> >
> > scsi: kill off the legacy IO path
> >
> > as the point where this 5m delay was introduced.
>
> I think the reason for this is that the block mq path doesn't feed the
> kernel entropy pool correctly, hence the need to install an entropy
> gatherer for systems that don't have other good random number sources.

That does sound plausible, I admit I didn't even consider the possibility that
the old block I/O path also was an entropy source.

/Mikael

[5.0-rc5 regression] "scsi: kill off the legacy IO path" causes 5 minute delay during boot on Sun Blade 2500

[Mikael Pettersson]

4.20 and earlier kernels boot fine on my Sun Blade 2500 (UltraSPARC
IIIi), but the 5.0-rc kernels consistently experience a 5 minute delay
late during boot, after enabling networking but before allowing user
logins.  E.g. 5.0-rc5 dmesg has:

[Fri Feb  8 17:13:17 2019] random: dbus-daemon: uninitialized urandom
read (12 bytes read)
[Fri Feb  8 17:18:14 2019] random: crng init done

During this interval the machine answers pings but won't allow user
logins either on the console or over the network.

A git bisect identified commit f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6
Author: Jens Axboe 
Date:   Thu Nov 1 16:36:27 2018 -0600

scsi: kill off the legacy IO path

as the point where this 5m delay was introduced.

My older kernels all have CONFIG_SCSI_MQ_DEFAULT=N, which the above
commit effectively forces to Y.
Rebuilding 4.20 with CONFIG_SCSI_MQ_DEFAULT=Y also triggers the 5m
delay behaviour.

I haven't seen this behaviour on my x86-64 boxes, so presumably it's
related to the sparc64 kernel or this machine's SCSI adapter.

.config and dmesg below.

/Mikael

#
# Automatically generated file; DO NOT EDIT.
# Linux/sparc64 4.20.0 Kernel Configuration
#

#
# Compiler: gcc (GCC) 7.4.1 20181227
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70401
CONFIG_CLANG_VERSION=0
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION="-blkmq"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_PREFLOW_FASTEOI=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_SPARSE_IRQ=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_PSI is not set
# CONFIG_CPU_ISOLATION is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_RDMA is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_NAMESPACES is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
# CONFIG_SYSFS_SYSCALL is not set
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
# CONFIG_AIO is not set
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_MEMBARRIER is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_BPF_SYSCALL is not set
# CONFIG_USERFAULTFD is not set
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
# CONFIG_PC104 is not set

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLAB_MERGE_DEFAULT=y
# CONFIG_SLAB_FREELIST_RANDOM is not set
# CONFIG_SLAB_FREELIST_HARDENED is not set
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_PROFILING is not set
CONFIG_64BIT=y
CONFIG_SPARC=y
CONFIG_SPARC64=y
CONFIG_ARCH_DEFCONFIG="arch/sparc/configs/sparc64_defconfig"
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_CPU_BIG_ENDIAN=y
CONFIG_ARCH_ATU=y
CONFIG_STACKTRACE_SUPPOR

Re: [PATCH] mm: disable `vm.max_map_count' sysctl limit

[Mikael Pettersson]

On Mon, Nov 27, 2017 at 6:25 PM, Andi Kleen  wrote:
> It's an arbitrary scaling limit on the how many mappings the process
> has. The more memory you have the bigger a problem it is. We've
> ran into this problem too on larger systems.
>
> The reason the limit was there originally because it allows a DoS
> attack against the kernel by filling all unswappable memory up with VMAs.
>
> The old limit was designed for much smaller systems than we have
> today.
>
> There needs to be some limit, but it should be on the number of memory
> pinned by the VMAs, and needs to scale with the available memory,
> so that large systems are not penalized.

Fully agreed.  One problem with the current limit is that number of VMAs
is only weakly related to the amount of memory one has mapped, and is
also prone to grow due to memory fragmentation.  I've seen processes
differ by 3X number of VMAs, even though they ran the same code and
had similar memory sizes; they only differed on how long they had been
running and which servers they ran on (and how long those had been up).

> Unfortunately just making it part of the existing mlock limit could
> break some existing setups which max out the mlock limit with something
> else. Maybe we need a new rlimit for this?
>
> -Andi

Re: [PATCH] mm: disable `vm.max_map_count' sysctl limit

[Mikael Pettersson]

On Mon, Nov 27, 2017 at 5:22 PM, Matthew Wilcox  wrote:
>> Could you be more explicit about _why_ we need to remove this tunable?
>> I am not saying I disagree, the removal simplifies the code but I do not
>> really see any justification here.
>
> I imagine he started seeing random syscalls failing with ENOMEM and
> eventually tracked it down to this stupid limit we used to need.

Exactly, except the origin (mmap() failing) was hidden behind layers upon layers
of user-space memory management code (not ours), which just said "failed to
allocate N bytes" (with N about 0.001% of the free RAM).  And it
wasn't reproducible.

Re: [PATCH] mm: disable `vm.max_map_count' sysctl limit

[Mikael Pettersson]

On Mon, Nov 27, 2017 at 11:12 AM, Michal Hocko  wrote:
> > I've kept the kernel tunable to not break the API towards user-space,
> > but it's a no-op now.  Also the distinction between split_vma() and
> > __split_vma() disappears, so they are merged.
>
> Could you be more explicit about _why_ we need to remove this tunable?
> I am not saying I disagree, the removal simplifies the code but I do not
> really see any justification here.

In principle you don't "need" to, as those that know about it can bump it
to some insanely high value and get on with life.  Meanwhile those that don't
(and I was one of them until fairly recently, and I'm no newcomer to Unix or
Linux) get to scratch their heads and wonder why the kernel says ENOMEM
when one has loads of free RAM.

But what _is_ the justification for having this arbitrary limit?
There might have
been historical reasons, but at least ELF core dumps are no longer a problem.

/Mikael

[PATCH] mm: disable `vm.max_map_count' sysctl limit

[Mikael Pettersson]

The `vm.max_map_count' sysctl limit is IMO useless and confusing, so
this patch disables it.

- Old ELF had a limit of 64K segments, making core dumps from processes
  with more mappings than that problematic, but that was fixed in March
  2010 ("elf coredump: add extended numbering support").

- There are no internal data structures sized by this limit, making it
  entirely artificial.

- When viewed as a limit on memory consumption, it is ineffective since
  the number of mappings does not correspond directly to the amount of
  memory consumed, since each mapping is variable-length.

- Reaching the limit causes various memory management system calls to
  fail with ENOMEM, which is a lie.  Combined with the unpredictability
  of the number of mappings in a process, especially when non-trivial
  memory management or heavy file mapping is used, it can be difficult
  to reproduce these events and debug them.  It's also confusing to get
  ENOMEM when you know you have lots of free RAM.

This limit was apparently introduced in the 2.1.80 kernel (first as a
compile-time constant, later changed to a sysctl), but I haven't been
able to find any description for it in Git or the LKML archives, so I
don't know what the original motivation was.

I've kept the kernel tunable to not break the API towards user-space,
but it's a no-op now.  Also the distinction between split_vma() and
__split_vma() disappears, so they are merged.

Tested on x86_64 with Fedora 26 user-space.  Also built an ARM NOMMU
kernel to make sure NOMMU compiles and links cleanly.

Signed-off-by: Mikael Pettersson 
---
 Documentation/sysctl/vm.txt   | 17 +-
 Documentation/vm/ksm.txt  |  4 
 Documentation/vm/remap_file_pages.txt |  4 
 fs/binfmt_elf.c   |  4 
 include/linux/mm.h| 23 ---
 kernel/sysctl.c   |  3 +++
 mm/madvise.c  | 12 ++
 mm/mmap.c | 42 ++-
 mm/mremap.c   |  7 --
 mm/nommu.c|  3 ---
 mm/util.c |  1 -
 11 files changed, 13 insertions(+), 107 deletions(-)

diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index b920423f88cb..0fcb511d07e6 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -35,7 +35,7 @@ Currently, these files are in /proc/sys/vm:
 - laptop_mode
 - legacy_va_layout
 - lowmem_reserve_ratio
-- max_map_count
+- max_map_count (unused, kept for backwards compatibility)
 - memory_failure_early_kill
 - memory_failure_recovery
 - min_free_kbytes
@@ -400,21 +400,6 @@ The minimum value is 1 (1/1 -> 100%).
 
 ==
 
-max_map_count:
-
-This file contains the maximum number of memory map areas a process
-may have. Memory map areas are used as a side-effect of calling
-malloc, directly by mmap, mprotect, and madvise, and also when loading
-shared libraries.
-
-While most applications need less than a thousand maps, certain
-programs, particularly malloc debuggers, may consume lots of them,
-e.g., up to one or two maps per allocation.
-
-The default value is 65536.
-
-=
-
 memory_failure_early_kill:
 
 Control how to kill processes when uncorrected memory error (typically
diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
index 6686bd267dc9..4a917f88cb11 100644
--- a/Documentation/vm/ksm.txt
+++ b/Documentation/vm/ksm.txt
@@ -38,10 +38,6 @@ the range for whenever the KSM daemon is started; even if 
the range
 cannot contain any pages which KSM could actually merge; even if
 MADV_UNMERGEABLE is applied to a range which was never MADV_MERGEABLE.
 
-If a region of memory must be split into at least one new MADV_MERGEABLE
-or MADV_UNMERGEABLE region, the madvise may return ENOMEM if the process
-will exceed vm.max_map_count (see Documentation/sysctl/vm.txt).
-
 Like other madvise calls, they are intended for use on mapped areas of
 the user address space: they will report ENOMEM if the specified range
 includes unmapped gaps (though working on the intervening mapped areas),
diff --git a/Documentation/vm/remap_file_pages.txt 
b/Documentation/vm/remap_file_pages.txt
index f609142f406a..85985a89f05d 100644
--- a/Documentation/vm/remap_file_pages.txt
+++ b/Documentation/vm/remap_file_pages.txt
@@ -21,7 +21,3 @@ systems are widely available.
 The syscall is deprecated and replaced it with an emulation now. The
 emulation creates new VMAs instead of nonlinear mappings. It's going to
 work slower for rare users of remap_file_pages() but ABI is preserved.
-
-One side effect of emulation (apart from performance) is that user can hit
-vm.max_map_count limit more easily due to additional VMAs. See comment for
-DEFAULT_MAX_MAP_COUN

Re: Possible gcc 4.8.5 bug about RELOC_HIDE marcro

[Mikael Pettersson]

Jia He writes:
 > I tried to build kernel 4.14-rc1 on a arm64 server in distro centos 7.3. 
 > The gcc version is 4.8.5

I have no input on the specifics of the issue, but please note that gcc-4.8
is no longer supported or maintained by upstream.  Even gcc-4.9 is EOL, and
gcc-5 will be EOL:d inn a week or so.  Also I'll note that gcc-4.8 is still
fairly early wrt to arm64 support, so bugs may be expected.

In short, please retry with gcc-6.4 or gcc-7.2.

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

[Mikael Pettersson]

David Miller writes:
 > From: Mikael Pettersson 
 > Date: Thu, 3 Aug 2017 22:02:57 +0200
 > 
 > > With that in place the kernel booted fine.
 > > When I then ran the `poll' strace test binary, the OOPS was replaced by:
 > > 
 > > [  140.589913] _copy_from_user(fff000123c8dfa7c,   (null), 240) 
 > > res 240
 > > [  140.753162] _copy_from_user(fff000123c8dfa7c, f7e4a000, 8) res 8
 > > [  140.824155] _copy_from_user(fff000123c8dfa7c, f7e49ff8, 16) res 
 > > 18442240552407530112
 > > 
 > > That last `res' doesn't look good.
 > 
 > Please test this patch:
 > 
 > diff --git a/arch/sparc/lib/U3memcpy.S b/arch/sparc/lib/U3memcpy.S
 > index 54f9870..5a8cb37 100644
 > --- a/arch/sparc/lib/U3memcpy.S
 > +++ b/arch/sparc/lib/U3memcpy.S
 > @@ -145,13 +145,13 @@ ENDPROC(U3_retl_o2_plus_GS_plus_0x08)
 >  ENTRY(U3_retl_o2_and_7_plus_GS)
 >  and %o2, 7, %o2
 >  retl
 > - add%o2, GLOBAL_SPARE, %o2
 > + add%o2, GLOBAL_SPARE, %o0
 >  ENDPROC(U3_retl_o2_and_7_plus_GS)
 >  ENTRY(U3_retl_o2_and_7_plus_GS_plus_8)
 >  add GLOBAL_SPARE, 8, GLOBAL_SPARE
 >  and %o2, 7, %o2
 >  retl
 > - add%o2, GLOBAL_SPARE, %o2
 > + add%o2, GLOBAL_SPARE, %o0
 >  ENDPROC(U3_retl_o2_and_7_plus_GS_plus_8)
 >  #endif
 >  

Backing out my debugging patch and adding this one instead
gave me a working kernel that doesn't OOPS.  Thanks.

Tested-by: Mikael Pettersson 

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

[Mikael Pettersson]

Sam Ravnborg writes:
 > On Tue, Aug 01, 2017 at 10:58:29PM +0200, Sam Ravnborg wrote:
 > > Hi Mikael.
 > > 
 > > I think this translates to the following code
 > > from linux/uaccess.h
 > > 
 > > first part is the inlined _copy_from_user()
 > > 
 > > > 
 > > > (gdb) x/10i do_sys_poll+0x80-16
 > > >0x516ed0 :  brz  %o0, 0x5170fc 
 > > if (unlikely(res))
 > > 
 > > >0x516ed4 :  mov  %o0, %o2
 > > >0x516ed8 :  sub  %i4, %o0, %i4
 > > >0x516edc :  clr  %o1
 > > >0x516ee0 :  call  0x7570b8 
 > > >0x516ee4 :  add  %l3, %i4, %o0
 > > memset(to + (n - res), 0, res);
 > 
 > And memset calls down to bzero, where %o0=buf, %o1=len
 > 
 > %o0 = 0xc
 > %o1 = 0xfff000123c897a80
 > %o2 = 0x0
 > %o3 = 0xc
 > 
 > So from this we know that:
 > res = 0xfff000123c897a80
 > to + (n - 0xfff000123c897a80)) = 0xc
 > 
 > The value "fff000123c897a80" really looks like a constructed address
 > from somewhere in the strace code, and where this constructed address
 > is used to provoke some unusual behaviour.
 > The "fff0" part may be a sparc thing.
 > 
 > So far the analysis seems to match the intial conclusion that
 > we in this special case try to zero out the remaining memory
 > based on the return value of raw_copy_from_user.
 > And therefore we use the return value (res) which triggers the oops.
 > 
 > So rather than manipulating with the assembler code as suggested
 > in the previous mail this simpler patch could be tested:
 > 
 > diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
 > index acdd6f915a8d..13d299ff1f21 100644
 > --- a/include/linux/uaccess.h
 > +++ b/include/linux/uaccess.h
 > @@ -115,7 +115,7 @@ _copy_from_user(void *to, const void __user *from, 
 > unsigned long n)
 >  res = raw_copy_from_user(to, from, n);
 >  }
 >  if (unlikely(res))
 > -memset(to + (n - res), 0, res);
 > +void: /*memset(to + (n - res), 0, res);*/
 >  return res;
 >  }
 >  #else
 > 
 > 
 > It would be good to know if this makes the opps go away.
 > 
 > And maybe you could try to print the parameters
 > supplied to _copy_from_user in case memset would be called,
 > so we have an idea what error path is taken.
 > 
 > I have tried to dechiper U3memcpy.S - but that is non-trivial.
 > So it would be good with a bit more data to verify the theory.

I applied the following:

--- linux-4.13-rc3/include/linux/uaccess.h.~1~  2017-08-01 08:49:48.397819726 
+0200
+++ linux-4.13-rc3/include/linux/uaccess.h  2017-08-03 21:33:11.009634421 
+0200
@@ -4,6 +4,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define VERIFY_READ 0
 #define VERIFY_WRITE 1
@@ -115,7 +117,9 @@ _copy_from_user(void *to, const void __u
res = raw_copy_from_user(to, from, n);
}
if (unlikely(res))
-   memset(to + (n - res), 0, res);
+   {
+   printk_ratelimited("_copy_from_user(%p, %p, %lu) res %lu\n", 
to, from, n, res);
+   }
return res;
 }
 #else

With that in place the kernel booted fine.
When I then ran the `poll' strace test binary, the OOPS was replaced by:

[  140.589913] _copy_from_user(fff000123c8dfa7c,   (null), 240) res 240
[  140.753162] _copy_from_user(fff000123c8dfa7c, f7e4a000, 8) res 8
[  140.824155] _copy_from_user(fff000123c8dfa7c, f7e49ff8, 16) res 
18442240552407530112

That last `res' doesn't look good.

/Mikael

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

[Mikael Pettersson]

David Miller writes:
 > From: Anatoly Pugachev 
 > Date: Tue, 1 Aug 2017 01:01:47 +0300
 > 
 > > I don't know how to run on a running kernel , but as I understood:
 > > 
 > > root@v215:strace# gzip -dc /boot/vmlinuz-4.12.0 > vmlinux
 > > root@v215:strace# gdb -q vmlinux
 > > Reading symbols from vmlinux...(no debugging symbols found)...done.
 > > (gdb) x/20i 0x49b294 - 16
 > 
 > Unfortunately you need to do this on the build kernel image before it
 > has been stripped of all of it's symbols.
 > 
 > Mikael, you built your kernels right?
 > 
 > Go into one of your OOPS's and extract the "RPC: " hex value, and run
 > the gdb command:
 > 
 > bash$ cd src/linux
 > bash$ gdb ./vmlinux
 > (gdb) x/10i 0x${RPC_HEX_VALUE} - 16
 > 
 > Thanks.

Ok, with 4.13-rc3 I got

[  240.085153] Unable to handle kernel NULL pointer dereference
[  240.142397] tsk->{mm,active_mm}->context = 044a
[  240.198531] tsk->{mm,active_mm}->pgd = fff23c784000
[  240.250112]   \|/  \|/
 "@'/ .. \`@"
 /_| \__/ |_\
\__U_/
[  240.374879] poll(724): Oops [#1]
[  240.400132] CPU: 0 PID: 724 Comm: poll Not tainted 4.13.0-rc3 #1
[  240.462002] task: fff000123cc71e00 task.stack: fff000123c894000
[  240.522717] TSTATE: 004411001605 TPC: 007570fc TNPC: 
00757110 Y: Not tainted
[  240.634921] TPC: <__bzero+0x20/0xc0>
[  240.664747] g0: fff000123c897081 g1:  g2:  
g3: 008ca100
[  240.762068] g4: fff000123cc71e00 g5: fff23ef44000 g6: fff000123c894000 
g7: 0008
[  240.859389] o0: 000c o1: fff000123c897a80 o2:  
o3: 000c
[  240.956718] o4: fff000123c897a7c o5: 00fb sp: fff000123c897181 
ret_pc: 00516ee0
[  241.058627] RPC: 
[  241.094166] l0: 0002 l1: 014000c0 l2: 03fe 
l3: fff000123c897a7c
[  241.191506] l4:  l5:  l6: 006d 
l7: ffea
[  241.288822] i0: f7d93ff8 i1: 0002 i2: fff000123c897e90 
i3: fff000123c897a70
[  241.386141] i4: 000fffedc3768590 i5: fff000123c897a70 i6: fff000123c8975e1 
i7: 005177f8
[  241.483468] I7: 
[  241.513292] Call Trace:
[  241.528265]  [005177f8] SyS_poll+0x74/0xd0
[  241.574140]  [004061b4] linux_sparc_syscall32+0x34/0x60
[  241.634847] Disabling lock debugging due to kernel taint
[  241.687555] Caller[005177f8]: SyS_poll+0x74/0xd0
[  241.740276] Caller[004061b4]: linux_sparc_syscall32+0x34/0x60
[  241.807855] Caller[00010a20]: 0x10a20
[  241.847983] Instruction DUMP:
[  241.847987]  c56a2000 
[  241.869824]  808a2003 
[  241.883651]  02480006 
[  241.897475] 
[  241.911207]  90022001 
[  241.925032]  808a2003 
[  241.938755]  1247fffd 
[  241.952484]  92226001 
[  241.966310]  808a2007 

so the RPC should be do_sys_poll+0x80 right?  Then gdb on the original vmlinux 
said:

(gdb) x/10i do_sys_poll+0x80-16
   0x516ed0 :  brz  %o0, 0x5170fc 
   0x516ed4 :  mov  %o0, %o2
   0x516ed8 :  sub  %i4, %o0, %i4
   0x516edc :  clr  %o1
   0x516ee0 :  call  0x7570b8 
   0x516ee4 :  add  %l3, %i4, %o0
   0x516ee8 :  b  %xcc, 0x5170b0 
   0x516eec :  mov  -14, %l7
   0x516ef0 :  mov  %l2, %o0
   0x516ef4 :  movleu  %xcc, %l0, %o0
(gdb)

/Mikael

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

[Mikael Pettersson]

Mikael Pettersson writes:
 > Anatoly Pugachev writes:
 >  > On Fri, Jul 28, 2017 at 11:45 AM, Mikael Pettersson
 >  >  wrote:
 >  > > It's an rpmbuild --rebuild of Fedora's strace-4.18-1.fc24.src.rpm, but 
 > according to the
 >  > > build log the following should do it:
 >  > >
 >  > > export CFLAGS='-O2 -g -pipe -Wall -Werror=format-security 
 > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
 > --param=ssp-buffer-size=4 -grecord-gcc-switches  -m32 -mcpu=ultrasparc'
 >  > > ./configure --build=sparcv9-unknown-linux-gnu 
 > --host=sparcv9-unknown-linux-gnu --program-prefix= 
 > --disable-dependency-tracking --prefix=/usr --exec-prefix=/u
 >  > > sr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
 > --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib 
 > --libexecdir=/usr/libexec --local
 >  > > statedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man 
 > --infodir=/usr/share/info
 >  > > make -j2
 >  > > make -j2 -k check VERBOSE=1
 >  > 
 >  > cant' reproduce it here on debian sparc64 LDOM:
 > 
 > DaveM was also unable to reproduce it.
 > 
 > I'll be investigating a possible kernel miscompile next.

I don't think it's a miscompile.

First I recompiled 4.13-rc2 with each of gcc-7, gcc-6, and gcc-5, each
bootstrapped and regtested from the head of the respective FSF GCC branch:
no change, kernel 4.11 works while kernels >= 4.12 OOPS.  So a miscompile
seems unlikely.

Then I ran a git bisect between v4.11 (good) and v4.12 (bad), booting
each kernel and trying the problematic strace test binaries.  That
identified the following as the first bad commit:

commit 31af2f36d50e3b9b2fb7f17aa430c11c91f946c4
Author: Al Viro 
Date:   Tue Mar 21 17:04:45 2017 -0400

sparc: switch to RAW_COPY_USER

... and drop zeroing in sparc32.

Signed-off-by: Al Viro 

That touches the CPU model specific assembly code in arch/sparc/lib/ for
copy_{to,from}_user and changes how it's wired into the rest of the kernel.
There's different code for different UltraSPARC and Niagara generations,
so if there is a bug in e.g. the USIII code, you won't see it on Niagara.

Unfortunately I don't see anything obviously wrong in Al's patch...

/Mikael

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

[Mikael Pettersson]

Anatoly Pugachev writes:
 > On Fri, Jul 28, 2017 at 11:45 AM, Mikael Pettersson
 >  wrote:
 > > It's an rpmbuild --rebuild of Fedora's strace-4.18-1.fc24.src.rpm, but 
 > > according to the
 > > build log the following should do it:
 > >
 > > export CFLAGS='-O2 -g -pipe -Wall -Werror=format-security 
 > > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
 > > --param=ssp-buffer-size=4 -grecord-gcc-switches  -m32 -mcpu=ultrasparc'
 > > ./configure --build=sparcv9-unknown-linux-gnu 
 > > --host=sparcv9-unknown-linux-gnu --program-prefix= 
 > > --disable-dependency-tracking --prefix=/usr --exec-prefix=/u
 > > sr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
 > > --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib 
 > > --libexecdir=/usr/libexec --local
 > > statedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man 
 > > --infodir=/usr/share/info
 > > make -j2
 > > make -j2 -k check VERBOSE=1
 > 
 > cant' reproduce it here on debian sparc64 LDOM:

DaveM was also unable to reproduce it.

I'll be investigating a possible kernel miscompile next.


 > 
 > used git version of strace ( https://github.com/strace/strace )
 > 
 > strace$ make -j24 check VERBOSE=1
 > ...
 > 
 > Testsuite summary for strace 4.18.0.134.805d
 > 
 > # TOTAL: 443
 > # PASS:  389
 > # SKIP:  40
 > # XFAIL: 0
 > # FAIL:  14
 > # XPASS: 0
 > # ERROR: 0
 > 
 > 
 > while in kernel logs (journalctl -k -f):
 > 
 > Jul 29 12:49:22 ttip kernel: mmap: remap_file_page (77341) uses
 > deprecated remap_file_pages() syscall. See
 > Documentation/vm/remap_file_pages.txt.
 > Jul 29 12:49:22 ttip kernel: capability: warning: `caps' uses
 > deprecated v2 capabilities in a way that may be insecure
 > Jul 29 12:49:22 ttip kernel: capability: warning: `caps' uses 32-bit
 > capabilities (legacy support in use)
 > Jul 29 12:49:22 ttip kernel: [ cut here ]
 > Jul 29 12:49:22 ttip kernel: WARNING: CPU: 18 PID: 78388 at
 > arch/sparc/kernel/sys_sparc32.c:150
 > compat_SyS_sparc_sigaction+0x3c/0x60
 > Jul 29 12:49:22 ttip kernel: Modules linked in: tcp_diag inet_diag
 > xfrm_user xfrm_algo nfnetlink netlink_diag xt_tcpudp xt_multiport
 > xt_conntrack tun iptable_filter iptable_nat nf_conntrack_ipv4
 > nf_defrag_ipv4 nf_nat_ipv4 xfs camellia_sparc64 des_sparc64
 > des_generic aes_sparc64 n2_rng md5_sparc64 rng_core flash
 > sha512_sparc64 sha256_sparc64 sha1_sparc64 nf_nat_pptp
 > nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat
 > nf_conntrack libcrc32c crc32c_generic ip_tables x_tables autofs4 ext4
 > crc16 mbcache jbd2 crc32c_sparc64
 > Jul 29 12:49:22 ttip kernel: CPU: 18 PID: 78388 Comm: sigaction Not
 > tainted 4.13.0-rc2-00220-g0a07b238e5f4 #376
 > Jul 29 12:49:22 ttip kernel: Call Trace:
 > Jul 29 12:49:22 ttip kernel:  [0046c074] __warn+0xb4/0xe0
 > Jul 29 12:49:22 ttip kernel:  [0046c120] warn_slowpath_null+0x20/0x40
 > Jul 29 12:49:22 ttip kernel:  [0044b7bc]
 > compat_SyS_sparc_sigaction+0x3c/0x60
 > Jul 29 12:49:22 ttip kernel:  [004061d4] 
 > linux_sparc_syscall32+0x34/0x60
 > Jul 29 12:49:22 ttip kernel: ---[ end trace 1ad5184278304e6d ]---
 > Jul 29 12:49:25 ttip kernel: pc[83378]: segfault at 7974 ip
 > 7974 (rpc 796c) sp ffdd9438 error
 > 30001 in pc[7001+2000]

-- 

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

[Mikael Pettersson]

David Miller writes:
 > From: Mikael Pettersson 
 > Date: Thu, 27 Jul 2017 21:45:25 +0200
 > 
 > > Attempting to build strace-4.18 as sparcv9 code and run its test suite
 > > on a sparc64 machine (Sun Blade 2500 w/ 2 x USIIIi in my case) fails
 > > reliably in three test cases (sched.gen, sched_xetattr.gen, and poll)
 > > because two test binaries (sched_xetattr and poll) OOPS the kernel and
 > > get killed.  Sample dmesg from 4.13-rc2:
 > > 
 > > [42912.270398] Unable to handle kernel NULL pointer dereference
 > > [42912.327717] tsk->{mm,active_mm}->context = 136a
 > > [42912.383789] tsk->{mm,active_mm}->pgd = fff227db4000
 > > [42912.435247]   \|/  \|/
 > >  "@'/ .. \`@"
 > >  /_| \__/ |_\
 > > \__U_/
 > > [42912.559982] sched_xetattr(21866): Oops [#1]
 > > [42912.597773] CPU: 0 PID: 21866 Comm: sched_xetattr Not tainted 
 > > 4.13.0-rc2 #1
 > > [42912.672138] task: fff229a5c380 task.stack: fff227dec000
 > > [42912.732876] TSTATE: 004411001603 TPC: 007570fc TNPC: 
 > > 00757110 Y: Not tainted
 > > [42912.845079] TPC: <__bzero+0x20/0xc0>
 > > [42912.874870] g0:  g1:  g2: 
 > > 0030 g3: 008ca100
 > > [42912.972120] g4: fff229a5c380 g5: fff23ef44000 g6: 
 > > fff227dec000 g7: 0030
 > > [42913.069446] o0: 0030 o1: fff227defe70 o2: 
 > >  o3: 0030
 > > [42913.166765] o4: fff227defe70 o5:  sp: 
 > > fff227def5c1 ret_pc: 00474fa4
 > > [42913.268664] RPC: 
 > 
 > This looks really strange.  It is a memset() call with the buffer pointer
 > and length arguments reversed.
 > 
 > What exact command did you give to configure and build strace-4.18 so that
 > I can try to reproduce this?

It's an rpmbuild --rebuild of Fedora's strace-4.18-1.fc24.src.rpm, but 
according to the
build log the following should do it:

export CFLAGS='-O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -grecord-gcc-switches  -m32 -mcpu=ultrasparc'
./configure --build=sparcv9-unknown-linux-gnu --host=sparcv9-unknown-linux-gnu 
--program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/u
sr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share 
--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --local
statedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man 
--infodir=/usr/share/info
make -j2
make -j2 -k check VERBOSE=1


/Mikael

strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

[Mikael Pettersson]

Attempting to build strace-4.18 as sparcv9 code and run its test suite
on a sparc64 machine (Sun Blade 2500 w/ 2 x USIIIi in my case) fails
reliably in three test cases (sched.gen, sched_xetattr.gen, and poll)
because two test binaries (sched_xetattr and poll) OOPS the kernel and
get killed.  Sample dmesg from 4.13-rc2:

[42912.270398] Unable to handle kernel NULL pointer dereference
[42912.327717] tsk->{mm,active_mm}->context = 136a
[42912.383789] tsk->{mm,active_mm}->pgd = fff227db4000
[42912.435247]   \|/  \|/
 "@'/ .. \`@"
 /_| \__/ |_\
\__U_/
[42912.559982] sched_xetattr(21866): Oops [#1]
[42912.597773] CPU: 0 PID: 21866 Comm: sched_xetattr Not tainted 4.13.0-rc2 #1
[42912.672138] task: fff229a5c380 task.stack: fff227dec000
[42912.732876] TSTATE: 004411001603 TPC: 007570fc TNPC: 
00757110 Y: Not tainted
[42912.845079] TPC: <__bzero+0x20/0xc0>
[42912.874870] g0:  g1:  g2: 0030 
g3: 008ca100
[42912.972120] g4: fff229a5c380 g5: fff23ef44000 g6: fff227dec000 
g7: 0030
[42913.069446] o0: 0030 o1: fff227defe70 o2:  
o3: 0030
[42913.166765] o4: fff227defe70 o5:  sp: fff227def5c1 
ret_pc: 00474fa4
[42913.268664] RPC: 
[42913.311046] l0: f7b6caa8 l1: cccd l2: ffc2e7d4 
l3: f7b6c888
[42913.408293] l4:  l5:  l6:  
l7: f7ba2000
[42913.505627] i0:  i1: f79f1ffc i2:  
i3: 
[42913.602940] i4: fff227defe70 i5: fff227defe70 i6: fff227def6a1 
i7: 004061b4
[42913.700268] I7: 
[42913.744966] Call Trace:
[42913.759938]  [004061b4] linux_sparc_syscall32+0x34/0x60
[42913.820656] Disabling lock debugging due to kernel taint
[42913.873374] Caller[004061b4]: linux_sparc_syscall32+0x34/0x60
[42913.940953] Caller[00010ed0]: 0x10ed0
[42913.981081] Instruction DUMP:
[42913.981085]  c56a2000 
[42914.002817]  808a2003 
[42914.016643]  02480006 
[42914.030363] 
[42914.044094]  90022001 
[42914.057816]  808a2003 
[42914.071539]  1247fffd 
[42914.085269]  92226001 
[42914.098992]  808a2007 

[42914.471525] Unable to handle kernel NULL pointer dereference
[42914.528830] tsk->{mm,active_mm}->context = 17cd
[42914.584862] tsk->{mm,active_mm}->pgd = fff227b78000
[42914.636319]   \|/  \|/
 "@'/ .. \`@"
 /_| \__/ |_\
\__U_/
[42914.761013] sched_xetattr(22483): Oops [#2]
[42914.798837] CPU: 0 PID: 22483 Comm: sched_xetattr Tainted: G  D 
4.13.0-rc2 #1
[42914.889222] task: fff000123c73bc00 task.stack: fff0001238998000
[42914.949915] TSTATE: 004411001603 TPC: 007570fc TNPC: 
00757110 Y: Tainted: G  D
[42915.078076] TPC: <__bzero+0x20/0xc0>
[42915.107875] g0:  g1:  g2: 0030 
g3: 008ca100
[42915.205205] g4: fff000123c73bc00 g5: fff23ef44000 g6: fff0001238998000 
g7: 0030
[42915.302532] o0: 0030 o1: fff000123899be70 o2:  
o3: 0030
[42915.399851] o4: fff000123899be70 o5:  sp: fff000123899b5c1 
ret_pc: 00474fa4
[42915.501731] RPC: 
[42915.544033] l0: f784caa8 l1: cccd l2: ff91c7d4 
l3: f784c888
[42915.641289] l4:  l5:  l6:  
l7: f7882000
[42915.738582] i0:  i1: f76d1ffc i2:  
i3: 
[42915.835827] i4: fff000123899be70 i5: fff000123899be70 i6: fff000123899b6a1 
i7: 004061b4
[42915.933160] I7: 
[42915.977822] Call Trace:
[42915.992698]  [004061b4] linux_sparc_syscall32+0x34/0x60
[42916.053335] Caller[004061b4]: linux_sparc_syscall32+0x34/0x60
[42916.120934] Caller[00010ed0]: 0x10ed0
[42916.161052] Instruction DUMP:
[42916.161056]  c56a2000 
[42916.182878]  808a2003 
[42916.196607]  02480006 
[42916.210330] 
[42916.224052]  90022001 
[42916.237781]  808a2003 
[42916.251502]  1247fffd 
[42916.265224]  92226001 
[42916.278955]  808a2007 

[42918.071476] [ cut here ]
[42918.115146] WARNING: CPU: 0 PID: 23177 at 
arch/sparc/kernel/sys_sparc32.c:150 compat_SyS_sparc_sigaction+0x34/0x4c
[42918.234167] Modules linked in: af_packet ipv6 hid_generic tg3 hwmon 
i2c_ali1535 ohci_pci ptp ohci_hcd evdev i2c_core pps_core flash sr_mod cdrom 
pata_ali libata
[42918.405845] CPU: 0 PID: 23177 Comm: sigaction Tainted: G  D 
4.13.0-rc2 #1
[42918.491645] Call Trace:
[42918.506518]  [00455b18] __warn+0xb4/0xc4
[42918.549976]  [004449e4] compat_SyS_spa

Re: v4.13-rc2: usb mouse stopped working?

[Mikael Pettersson]

Jiri Kosina writes:
 > On Mon, 24 Jul 2017, Pavel Machek wrote:
 > 
 > > On thinkpad x220, USB mouse stopped working in v4.13-rc2. v4.12 was
 > > ok, iirc.
 > > 
 > > Now, USB mouse is so common hw that I may have something wrong in my
 > > config...? But I did not change anything there.
 > 
 > Well, your particular USB mouse requires an always-poll quirk, so it's not 
 > *that* common; therefore ...
 > 
 > > In v4.9:
 > > 
 > > [   87.064408] input: Logitech USB Optical Mouse as
 > > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1.1/2-1.1.1.1:1.0/0003:046D:C05A.0005/input/input18
 > > [   87.065951] hid-generic 0003:046D:C05A.0005: input,hidraw0: USB HID
 > > v1.11 Mouse [Logitech USB Optical Mouse] on
 > > usb-:00:1d.0-1.1.1.1/input0
 > > pavel@duo:~$
 > > 
 > > v4.13-rc2:
 > > 
 > > [   87.886810] usb 2-1.1.1.1: new low-speed USB device number 10 using 
 > > ehci-pci
 > > [   88.019543] usb 2-1.1.1.1: New USB device found, idVendor=046d, 
 > > idProduct=c05a
 > > [   88.019561] usb 2-1.1.1.1: New USB device strings: Mfr=1, Product=2, 
 > > SerialNumber=0
 > > [   88.019572] usb 2-1.1.1.1: Product: USB Optical Mouse
 > > [   88.019581] usb 2-1.1.1.1: Manufacturer: Logitech
 > > [   88.027276] input: Logitech USB Optical Mouse as 
 > > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1.1/2-1.1.1.1:1.0/0003:046D:C05A.0005/input/input18
 > > [   88.027825] hid-generic 0003:046D:C05A.0005: input,hidraw1: USB HID
 > > v1.11 Mouse [Logitech USB Optical Mouse] on
 > > usb-:00:1d.0-1.1.1.1/input0
 > 
 > ... this is most likely caused by e399396a6b0, and fix for that is queued 
 > in hid.git as cf601774c9f ("HID: usbhid: fix "always poll" quirk"); I'm 
 > planning to send it to Linus' tomorrow, but if you can double-check that 
 > it does fix your issue as well, that'd be appreciated.

I had a similar problem (a Logitech USB Optical Mouse being completely dead
with 4.13-rc[12]), and cf601774c9f fixed it.

/Mikael

Re: 4.7-rc6, ext4, sparc64: Unable to handle kernel paging request at ...

[Mikael Pettersson]

Meelis Roos writes:
 > > > Just got this on bootup of my Sun T2000:
 > > >...
 > > > I have not seen it before, this includes 4.6.0 4.6.0-08907-g7639dad
 > > > 4.7.0-rc1-00094-g6b15d66 4.7.0-rc4-00014-g67016f6.
 > > >
 > > > It is not reproducible, did not appear on next reboot of the same
 > > > kernel.
 > > 
 > > mine T5120 boots ok 4.7.0-rc6, rootfs being on ext4 .
 > 
 > My T5120 and many other sparc64 machines also boot fine, most of them 
 > using ext4, others ext3 with ext4 driver.
 > 
 > However, I also got a very similar oops from T1000:
 > 
 > [   55.251101] Unable to handle kernel paging request at virtual address 
 > fe42a000
 > [   55.251348] tsk->{mm,active_mm}->context = 0083
 > [   55.251533] tsk->{mm,active_mm}->pgd = 8001f6224000
 > [   55.251719]   \|/  \|/
 >  "@'/ .. \`@"
 >  /_| \__/ |_\
 > \__U_/
 > [   55.252038] systemd-udevd(268): Oops [#1]
 > [   55.252274] CPU: 9 PID: 268 Comm: systemd-udevd Not tainted 4.7.0-rc6 #26
 > [   55.252367] task: 8001f6064380 ti: 8001f620c000 task.ti: 
 > 8001f620c000
 > [   55.252497] TSTATE: 000811001604 TPC: 00649380 TNPC: 
 > 00649384 Y: Not tainted
 > [   55.252651] TPC: <__radix_tree_lookup+0x60/0x1a0>
...

A few weeks ago I got a similar oops with 4.7.0-rc2 on a Sun Blade 2500 (dual 
USIIIi):

Jun 12 18:40:26 lauter kernel: Unable to handle kernel paging request at 
virtual address a000
Jun 12 18:40:26 lauter kernel: tsk->{mm,active_mm}->context = 17e3
Jun 12 18:40:26 lauter kernel: tsk->{mm,active_mm}->pgd = fff23edb8000
Jun 12 18:40:26 lauter kernel:   \|/  \|/
Jun 12 18:40:26 lauter kernel:   "@'/ .. \`@"
Jun 12 18:40:26 lauter kernel:   /_| \__/ |_\
Jun 12 18:40:26 lauter kernel:  \__U_/
Jun 12 18:40:26 lauter kernel: gnat1(19464): Oops [#1]
Jun 12 18:40:26 lauter kernel: CPU: 0 PID: 19464 Comm: gnat1 Not tainted 
4.7.0-rc2 #1
Jun 12 18:40:26 lauter kernel: task: fff23ebd1440 ti: fff000123c36 
task.ti: fff000123c36
Jun 12 18:40:27 lauter kernel: TSTATE: 11001604 TPC: 005db288 
TNPC: 005db28c Y: Not tainted
Jun 12 18:40:27 lauter kernel: TPC: <__radix_tree_lookup+0x44/0xd4>
Jun 12 18:40:27 lauter kernel: g0: 3000 g1: a6d9 g2: 
0001 g3: 
Jun 12 18:40:27 lauter kernel: g4: fff23ebd1440 g5: fff23ef7a000 g6: 
fff000123c36 g7: 
Jun 12 18:40:27 lauter kernel: o0: 000c o1: fff000123c363980 o2: 
fff000123c363988 o3: fff000123c363968
Jun 12 18:40:27 lauter kernel: o4: 0020 o5: fff23fffefc0 sp: 
fff000123c3630d1 ret_pc: fff232e42540
Jun 12 18:40:27 lauter kernel: RPC: <0xfff232e42540>
Jun 12 18:40:27 lauter kernel: l0: 024213ca l1:  l2: 
 l3: 
Jun 12 18:40:27 lauter kernel: l4:  l5:  l6: 
 l7: 
Jun 12 18:40:27 lauter kernel: i0: fff0001225e56900 i1: 0441 i2: 
 i3: 
Jun 12 18:40:27 lauter kernel: i4: a6d8 i5: fff232e42540 i6: 
fff000123c363191 i7: 004bf680
Jun 12 18:40:27 lauter kernel: I7: <__do_page_cache_readahead+0x78/0x200>
Jun 12 18:40:27 lauter kernel: Call Trace:
Jun 12 18:40:27 lauter kernel:  [004bf680] 
__do_page_cache_readahead+0x78/0x200
Jun 12 18:40:27 lauter kernel:  [004b5990] filemap_fault+0x164/0x4c4
Jun 12 18:40:27 lauter kernel:  [00562a84] ext4_filemap_fault+0x1c/0x38
Jun 12 18:40:27 lauter kernel:  [004d2c38] __do_fault+0x58/0xdc
Jun 12 18:40:27 lauter kernel:  [004d611c] handle_mm_fault+0x604/0xe5c
Jun 12 18:40:27 lauter kernel:  [00448288] do_sparc64_fault+0x228/0x684
Jun 12 18:40:27 lauter kernel:  [00407bcc] 
sparc64_realfault_common+0x10/0x20
Jun 12 18:40:28 lauter kernel: Disabling lock debugging due to kernel taint
Jun 12 18:40:28 lauter kernel: Caller[004bf680]: 
__do_page_cache_readahead+0x78/0x200
Jun 12 18:40:28 lauter kernel: Caller[004b5990]: 
filemap_fault+0x164/0x4c4
Jun 12 18:40:28 lauter kernel: Caller[00562a84]: 
ext4_filemap_fault+0x1c/0x38
Jun 12 18:40:28 lauter kernel: Caller[004d2c38]: __do_fault+0x58/0xdc
Jun 12 18:40:28 lauter kernel: Caller[004d611c]: 
handle_mm_fault+0x604/0xe5c
Jun 12 18:40:28 lauter kernel: Caller[00448288]: 
do_sparc64_fault+0x228/0x684
Jun 12 18:40:28 lauter kernel: Caller[00407bcc]: 
sparc64_realfault_common+0x10/0x20
Jun 12 18:40:28 lauter kernel: Caller[006ee248]: 
ip_options_compile+0x288/0x60c
Jun 12 18:40:28 lauter kernel: Instruction DUMP: 80a06001  0267fff2  b8087ffe 
 83365001  8208603f  84006004  83287003  8528b003

It's only happended that one time, so far.

Re: SIGSYS annoyance

[Mikael Pettersson]

Andy Lutomirski writes:
 > On Mon, Jun 6, 2016 at 9:03 AM, Kees Cook  wrote:
 > > On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski  
 > > wrote:
 > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1176099
 > >>
 > >> Should SIGSYS be delivered to the handler even if blocked?  What, if
 > >> anything, does POSIX say?  All I can find is in pthread_sigmask(3p):
 > >>
 > >> If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated
 > >> while they are blocked, the result is undefined, unless the signal was
 > >> generated by the action of another process, or by one of the functions
 > >> kill(), pthread_kill(), raise(), or sigqueue().
 > >>
 > >> It would be easy enough to change our behavior so that we deliver the
 > >> signal even if it's blocked or to at least add a flag so that users
 > >> can request that behavior.
 > >
 > > I had trouble following that bug. It sounded like glib just needed a
 > > way to define its signal mask, and that's what they ended up
 > > implementing?
 > >
 > > I think the current behavior is correct. SIGSYS is being generated by
 > > the running process (i.e. the seccomp filter) and if it has a handler
 > > but the signal is blocked, we should treat it as uncaught and kill. On
 > > the other hand, it could be seen like "raise", in which case the
 > > blocking should be ignored? Is there an active problem somewhere here?
 > > It seems like the referenced bug has been fixed already.
 > 
 > Agreed.
 > 
 > It could make sense to have a new sigaction flag SA_FORCE: when set,
 > if a non-default handler is installed, the signal is blocked, and the
 > signal is triggered synchronously (forced), then the handler will be
 > called.  But that isn't specific to seccomp.

Blocking a signal is a very deliberate act.  If some piece of code wants
to force-deliver it, it can unblock it first.  IOW, I don't see the need
for this SA_FORCE thing.

Re: fork on processes with lots of memory

[Mikael Pettersson]

Felix von Leitner writes:
 > > Dear Linux kernel devs,
 > 
 > > I talked to someone who uses large Linux based hardware to run a
 > > process with huge memory requirements (think 4 GB), and he told me that
 > > if they do a fork() syscall on that process, the whole system comes to
 > > standstill. And not just for a second or two. He said they measured a 45
 > > minute (!) delay before the system became responsive again.
 > 
 > I'm sorry, I meant 4 TB not 4 GB.
 > I'm not used to working with that kind of memory sizes.

Make sure you have >>4TB physical if you're going to fork from a process
with a 4TB virtual address space.  (I'm assuming it's not sparse, but all
actually being used.)

Disable transparent hugepages (THP).  The internal book-keeping mechanisms
have been known to run amok with large RAM sizes causing severe performance
issues.  Maybe 4.x kernels are better, I haven't checked.

If you're using explicit hugepages and these kinds of RAM sizes, don't
bother with RHEL 6 or 7 kernels -- they're broken.  Vanilla 4.x kernels work.

We're also in the TB range, though not quite 4TB, and fork()ing from inside
such processes definitely works for us.  We do disable THP since it kills us
otherwise.

 > 
 > > Their working theory is that all the pages need to be marked copy-on-write
 > > in both processes, and if you touch one page, a copy needs to be made,
 > > and than just takes a while if you have a billion pages.
 > 
 > > I was wondering if there is any advice for such situations from the
 > > memory management people on this list.
 > 
 > > In this case the fork was for an execve afterwards, but I was going to
 > > recommend fork to them for something else that can not be tricked around
 > > with vfork.
 > 
 > > Can anyone comment on whether the 45 minute number sounds like it could
 > > be real? When I heard it, I was flabberghasted. But the other person
 > > swore it was real. Can a fork cause this much of a delay? Is there a way
 > > to work around it?
 > 
 > > I was going to recommend the fork to create a boundary between the
 > > processes, so that you can recover from memory corruption in one
 > > process. In fact, after the fork I would want to munmap almost all of
 > > the shared pages anyway, but there is no way to tell fork that.
 > 
 > > Thanks,
 > 
 > > Felix
 > 
 > > PS: Please put me on Cc if you reply, I'm not subscribed to this mailing
 > > list.

-- 

Re: [4.3-rc1 regression] modular 8250 doesn't load

[Mikael Pettersson]

Greg Kroah-Hartman writes:
 > On Mon, Sep 14, 2015 at 02:12:43PM -0700, Greg Kroah-Hartman wrote:
 > > On Mon, Sep 14, 2015 at 10:42:24PM +0200, Mikael Pettersson wrote:
 > > > Greg Kroah-Hartman writes:
 > > >  > On Mon, Sep 14, 2015 at 08:06:21PM +0200, Mikael Pettersson wrote:
 > > >  > > Greg Kroah-Hartman writes:
 > > >  > >  > On Mon, Sep 14, 2015 at 07:08:10PM +0200, Mikael Pettersson 
 > > > wrote:
 > > >  > >  > > I have CONFIG_SERIAL_8250=m.  With 4.2 '/sbin/modprobe 8250' 
 > > > worked
 > > >  > >  > > and resulted in:
 > > >  > >  > > 
 > > >  > >  > > [   41.354550] Serial: 8250/16550 driver, 4 ports, IRQ sharing 
 > > > disabled
 > > >  > >  > > [   41.375156] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, 
 > > > base_baud = 115200) is a 16550A
 > > >  > >  > > 
 > > >  > >  > > With 4.3-rc1 however the command fails and logs the following:
 > > >  > >  > > 
 > > >  > >  > > [   34.140300] 8250_base: module license 'unspecified' taints 
 > > > kernel.
 > > >  > >  > 
 > > >  > >  > Oops, need to fix that.
 > > >  > >  > 
 > > >  > >  > > [   34.141846] Disabling lock debugging due to kernel taint
 > > >  > >  > > [   34.143388] 8250_base: Unknown symbol uart_insert_char (err 
 > > > 0)
 > > >  > >  > > [   34.144908] 8250_base: Unknown symbol 
 > > > uart_handle_dcd_change (err 0)
 > > >  > >  > > [   34.146439] 8250_base: Unknown symbol __pm_runtime_resume 
 > > > (err 0)
 > > >  > >  > > [   34.147901] 8250_base: Unknown symbol 
 > > > tty_termios_encode_baud_rate (err 0)
 > > >  > >  > > [   34.149354] 8250_base: Unknown symbol 
 > > > uart_handle_cts_change (err 0)
 > > >  > >  > > [   34.150798] 8250_base: Unknown symbol __pm_runtime_suspend 
 > > > (err 0)
 > > >  > >  > > [   34.152240] 8250_base: Unknown symbol nr_irqs (err 0)
 > > >  > >  > 
 > > >  > >  > Are you sure you did 'modprobe' and not 'insmod'?
 > > >  > > 
 > > >  > > Yes, I used modprobe.  I double-checked.
 > > >  > 
 > > >  > Then your build should have failed if these functions are not being
 > > >  > exported properly by your .config.  Most of these are in the 
 > > > serial_core
 > > >  > module, is that present/loaded?
 > > > 
 > > > Yes, serial_core is loaded.
 > > > 
 > > > uart_insert_char is EXPORT_SYMBOL_GPL, so could the missing license tag 
 > > > be preventing
 > > > 8250_core from binding to it?  (I haven't checked the other symbols but 
 > > > I assume they
 > > > are also _GPL.)
 > > 
 > > Ah, crap, yes, you are right.  You can test this with a simple:
 > >MODULE_LICENSE("GPL");
 > > line added to the 8250_base file.
 > 
 > Wait, 8250_base.c has a module license line.
 > 
 > Can you provide a full .config file?
 > 
 > thanks,
 > 
 > greg k-h

Here it is:

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UN

Re: [4.3-rc1 regression] modular 8250 doesn't load

[Mikael Pettersson]

Greg Kroah-Hartman writes:
 > On Mon, Sep 14, 2015 at 08:06:21PM +0200, Mikael Pettersson wrote:
 > > Greg Kroah-Hartman writes:
 > >  > On Mon, Sep 14, 2015 at 07:08:10PM +0200, Mikael Pettersson wrote:
 > >  > > I have CONFIG_SERIAL_8250=m.  With 4.2 '/sbin/modprobe 8250' worked
 > >  > > and resulted in:
 > >  > > 
 > >  > > [   41.354550] Serial: 8250/16550 driver, 4 ports, IRQ sharing 
 > > disabled
 > >  > > [   41.375156] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 
 > > 115200) is a 16550A
 > >  > > 
 > >  > > With 4.3-rc1 however the command fails and logs the following:
 > >  > > 
 > >  > > [   34.140300] 8250_base: module license 'unspecified' taints kernel.
 > >  > 
 > >  > Oops, need to fix that.
 > >  > 
 > >  > > [   34.141846] Disabling lock debugging due to kernel taint
 > >  > > [   34.143388] 8250_base: Unknown symbol uart_insert_char (err 0)
 > >  > > [   34.144908] 8250_base: Unknown symbol uart_handle_dcd_change (err 
 > > 0)
 > >  > > [   34.146439] 8250_base: Unknown symbol __pm_runtime_resume (err 0)
 > >  > > [   34.147901] 8250_base: Unknown symbol tty_termios_encode_baud_rate 
 > > (err 0)
 > >  > > [   34.149354] 8250_base: Unknown symbol uart_handle_cts_change (err 
 > > 0)
 > >  > > [   34.150798] 8250_base: Unknown symbol __pm_runtime_suspend (err 0)
 > >  > > [   34.152240] 8250_base: Unknown symbol nr_irqs (err 0)
 > >  > 
 > >  > Are you sure you did 'modprobe' and not 'insmod'?
 > > 
 > > Yes, I used modprobe.  I double-checked.
 > 
 > Then your build should have failed if these functions are not being
 > exported properly by your .config.  Most of these are in the serial_core
 > module, is that present/loaded?

Yes, serial_core is loaded.

uart_insert_char is EXPORT_SYMBOL_GPL, so could the missing license tag be 
preventing
8250_core from binding to it?  (I haven't checked the other symbols but I 
assume they
are also _GPL.)
--
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: [4.3-rc1 regression] modular 8250 doesn't load

[Mikael Pettersson]

Greg Kroah-Hartman writes:
 > On Mon, Sep 14, 2015 at 07:08:10PM +0200, Mikael Pettersson wrote:
 > > I have CONFIG_SERIAL_8250=m.  With 4.2 '/sbin/modprobe 8250' worked
 > > and resulted in:
 > > 
 > > [   41.354550] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
 > > [   41.375156] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 
 > > 115200) is a 16550A
 > > 
 > > With 4.3-rc1 however the command fails and logs the following:
 > > 
 > > [   34.140300] 8250_base: module license 'unspecified' taints kernel.
 > 
 > Oops, need to fix that.
 > 
 > > [   34.141846] Disabling lock debugging due to kernel taint
 > > [   34.143388] 8250_base: Unknown symbol uart_insert_char (err 0)
 > > [   34.144908] 8250_base: Unknown symbol uart_handle_dcd_change (err 0)
 > > [   34.146439] 8250_base: Unknown symbol __pm_runtime_resume (err 0)
 > > [   34.147901] 8250_base: Unknown symbol tty_termios_encode_baud_rate (err 
 > > 0)
 > > [   34.149354] 8250_base: Unknown symbol uart_handle_cts_change (err 0)
 > > [   34.150798] 8250_base: Unknown symbol __pm_runtime_suspend (err 0)
 > > [   34.152240] 8250_base: Unknown symbol nr_irqs (err 0)
 > 
 > Are you sure you did 'modprobe' and not 'insmod'?

Yes, I used modprobe.  I double-checked.

 > Peter, care to send a module license fix for this new module you
 > created?

/Mikael
--
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/

[4.3-rc1 regression] modular 8250 doesn't load

[Mikael Pettersson]

I have CONFIG_SERIAL_8250=m.  With 4.2 '/sbin/modprobe 8250' worked
and resulted in:

[   41.354550] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[   41.375156] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is 
a 16550A

With 4.3-rc1 however the command fails and logs the following:

[   34.140300] 8250_base: module license 'unspecified' taints kernel.
[   34.141846] Disabling lock debugging due to kernel taint
[   34.143388] 8250_base: Unknown symbol uart_insert_char (err 0)
[   34.144908] 8250_base: Unknown symbol uart_handle_dcd_change (err 0)
[   34.146439] 8250_base: Unknown symbol __pm_runtime_resume (err 0)
[   34.147901] 8250_base: Unknown symbol tty_termios_encode_baud_rate (err 0)
[   34.149354] 8250_base: Unknown symbol uart_handle_cts_change (err 0)
[   34.150798] 8250_base: Unknown symbol __pm_runtime_suspend (err 0)
[   34.152240] 8250_base: Unknown symbol nr_irqs (err 0)

Relevant .config fragments:

CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y

# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_SERIAL_8250=m
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
# CONFIG_SERIAL_8250_PNP is not set
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_FINTEK is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set

/Mikael
--
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: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard

[Mikael Pettersson]

Deucher, Alexander writes:
 > > -Original Message-
 > > From: Mikael Pettersson [mailto:mikpeli...@gmail.com]
 > > Sent: Monday, May 04, 2015 11:53 AM
 > > To: linux-kernel@vger.kernel.org
 > > Cc: Deucher, Alexander
 > > Subject: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the
 > > kernel hard
 > > 
 > > On my Ivy Bridge i7 mobo w/ Radeon graphics, the 4.1-rc2 kernel oopses
 > > hard,
 > > requiring a hard reset:
 > > 
 > > BUG: unable to handle kernel NULL pointer dereference at
 > > 0010
 > > IP: [] radeon_audio_detect+0x5b/0x150 [radeon]
 > > PGD 0
 > > Oops:  [#1] SMP
 > > Modules linked in: af_packet snd_hda_codec_generic snd_hda_intel
 > > snd_hda_controller snd_hda_codec snd_hwdep snd_hda_core snd_seq
 > > snd_seq_device snd_pcm radeon cfbfillrect cfbimgblt cfbcopyarea
 > > i2c_algo_bit backlight r8169 mii coretemp snd_timer drm_kms_helper ttm
 > > snd drm i2c_core xhci_pci xhci_hcd soundcore evdev firmware_class hwmon
 > > hid_generic usbhid hid ehci_pci ehci_hcd sr_mod cdrom usbcore
 > > usb_common ipv6
 > > CPU: 0 PID: 163 Comm: kworker/0:2 Not tainted 4.1.0-rc2 #1
 > > Hardware name: System manufacturer System Product Name/P8Z77-V LE
 > > PLUS, BIOS 0403 05/08/2012
 > > Workqueue: events output_poll_execute [drm_kms_helper]
 > > task: 8806012b1590 ti: 88003796 task.ti: 88003796
 > > RIP: 0010:[]  []
 > > radeon_audio_detect+0x5b/0x150 [radeon]
 > > RSP: 0018:880037963c78  EFLAGS: 00010246
 > > RAX: 880600c92da0 RBX: 880600cbb000 RCX: 0001
 > > RDX:  RSI:  RDI: 880037a3f600
 > > RBP: 880600c92da0 R08: 0001 R09: 0050
 > > R10: 0001 R11: 880603001a80 R12: 0001
 > > R13: 880600c924e0 R14: 880601f84000 R15: 0001
 > > FS:  () GS:88061ec0()
 > > knlGS:
 > > CS:  0010 DS:  ES:  CR0: 80050033
 > > CR2: 0010 CR3: 01478000 CR4: 001407f0
 > > Stack:
 > >  880600cbb000 0001 0001 880601f84000
 > >  a03e7d70 a03157ea 880601f84000 0002
 > >  880600baa200 880600cbb050 880600cbb000 880600e33800
 > > Call Trace:
 > >  [] ? radeon_dvi_detect+0x35a/0x4d0 [radeon]
 > >  [] ?
 > > drm_helper_probe_single_connector_modes_merge_bits+0x2e6/0x490
 > > [drm_kms_helper]
 > >  [] ?
 > > drm_fb_helper_probe_connector_modes.isra.5+0x48/0x70
 > > [drm_kms_helper]
 > >  [] ? drm_fb_helper_hotplug_event+0x55/0xe0
 > > [drm_kms_helper]
 > >  [] ? output_poll_execute+0x7c/0x1a0 [drm_kms_helper]
 > >  [] ? process_one_work+0x130/0x360
 > >  [] ? worker_thread+0x114/0x460
 > >  [] ? __schedule+0x20d/0x660
 > >  [] ? rescuer_thread+0x2f0/0x2f0
 > >  [] ? kthread+0xbc/0xe0
 > >  [] ? kthread_create_on_node+0x170/0x170
 > >  [] ? ret_from_fork+0x42/0x70
 > >  [] ? kthread_create_on_node+0x170/0x170
 > > Code: 8b 45 00 4c 8b ad 58 01 00 00 4c 8b 70 28 49 8b 85 00 01 00 00 48 85 
 > > c0 74
 > > 30 41 83 fc 01 74 38 48 8b 70 10 49 8b 96 c8 24 00 00 <48> 8b 4a 10 48 85 
 > > c9 74
 > > 0e 31 d2 4c 89 f7 ff d1 49 8b 85 00 01
 > > RIP  [] radeon_audio_detect+0x5b/0x150 [radeon]
 > >  RSP 
 > > CR2: 0010
 > > ---[ end trace 5b99e3870bfc7a92 ]---
 > > BUG: unable to handle kernel paging request at ffd8
 > > IP: [] kthread_data+0x7/0x10
 > > PGD 1479067 PUD 147b067 PMD 0
 > > Oops:  [#2] SMP
 > > Modules linked in: af_packet snd_hda_codec_generic snd_hda_intel
 > > snd_hda_controller snd_hda_codec snd_hwdep snd_hda_core snd_seq
 > > snd_seq_device snd_pcm radeon cfbfillrect cfbimgblt cfbcopyarea
 > > i2c_algo_bit backlight r8169 mii coretemp snd_timer drm_kms_helper ttm
 > > snd drm i2c_core xhci_pci xhci_hcd soundcore evdev firmware_class hwmon
 > > hid_generic usbhid hid ehci_pci ehci_hcd sr_mod cdrom usbcore
 > > usb_common ipv6
 > > CPU: 0 PID: 163 Comm: kworker/0:2 Tainted: G  D 4.1.0-rc2 #1
 > > Hardware name: System manufacturer System Product Name/P8Z77-V LE
 > > PLUS, BIOS 0403 05/08/2012
 > > task: 8806012b1590 ti: 88003796 task.ti: 88003796
 > > RIP: 0010:[]  [] kthread_data+0x7/0x10
 > > RSP: 0018:880037963a60  EFLAGS: 00010002
 > > RAX:  RBX:  RCX: 73c2bc6e
 > > RDX:  RSI:  RDI: 880601

[REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard

[Mikael Pettersson]

On my Ivy Bridge i7 mobo w/ Radeon graphics, the 4.1-rc2 kernel oopses hard,
requiring a hard reset:

BUG: unable to handle kernel NULL pointer dereference at 0010
IP: [] radeon_audio_detect+0x5b/0x150 [radeon]
PGD 0 
Oops:  [#1] SMP 
Modules linked in: af_packet snd_hda_codec_generic snd_hda_intel 
snd_hda_controller snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device 
snd_pcm radeon cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight r8169 
mii coretemp snd_timer drm_kms_helper ttm snd drm i2c_core xhci_pci xhci_hcd 
soundcore evdev firmware_class hwmon hid_generic usbhid hid ehci_pci ehci_hcd 
sr_mod cdrom usbcore usb_common ipv6
CPU: 0 PID: 163 Comm: kworker/0:2 Not tainted 4.1.0-rc2 #1
Hardware name: System manufacturer System Product Name/P8Z77-V LE PLUS, BIOS 
0403 05/08/2012
Workqueue: events output_poll_execute [drm_kms_helper]
task: 8806012b1590 ti: 88003796 task.ti: 88003796
RIP: 0010:[]  [] 
radeon_audio_detect+0x5b/0x150 [radeon]
RSP: 0018:880037963c78  EFLAGS: 00010246
RAX: 880600c92da0 RBX: 880600cbb000 RCX: 0001
RDX:  RSI:  RDI: 880037a3f600
RBP: 880600c92da0 R08: 0001 R09: 0050
R10: 0001 R11: 880603001a80 R12: 0001
R13: 880600c924e0 R14: 880601f84000 R15: 0001
FS:  () GS:88061ec0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0010 CR3: 01478000 CR4: 001407f0
Stack:
 880600cbb000 0001 0001 880601f84000
 a03e7d70 a03157ea 880601f84000 0002
 880600baa200 880600cbb050 880600cbb000 880600e33800
Call Trace:
 [] ? radeon_dvi_detect+0x35a/0x4d0 [radeon]
 [] ? 
drm_helper_probe_single_connector_modes_merge_bits+0x2e6/0x490 [drm_kms_helper]
 [] ? drm_fb_helper_probe_connector_modes.isra.5+0x48/0x70 
[drm_kms_helper]
 [] ? drm_fb_helper_hotplug_event+0x55/0xe0 [drm_kms_helper]
 [] ? output_poll_execute+0x7c/0x1a0 [drm_kms_helper]
 [] ? process_one_work+0x130/0x360
 [] ? worker_thread+0x114/0x460
 [] ? __schedule+0x20d/0x660
 [] ? rescuer_thread+0x2f0/0x2f0
 [] ? kthread+0xbc/0xe0
 [] ? kthread_create_on_node+0x170/0x170
 [] ? ret_from_fork+0x42/0x70
 [] ? kthread_create_on_node+0x170/0x170
Code: 8b 45 00 4c 8b ad 58 01 00 00 4c 8b 70 28 49 8b 85 00 01 00 00 48 85 c0 
74 30 41 83 fc 01 74 38 48 8b 70 10 49 8b 96 c8 24 00 00 <48> 8b 4a 10 48 85 c9 
74 0e 31 d2 4c 89 f7 ff d1 49 8b 85 00 01 
RIP  [] radeon_audio_detect+0x5b/0x150 [radeon]
 RSP 
CR2: 0010
---[ end trace 5b99e3870bfc7a92 ]---
BUG: unable to handle kernel paging request at ffd8
IP: [] kthread_data+0x7/0x10
PGD 1479067 PUD 147b067 PMD 0 
Oops:  [#2] SMP 
Modules linked in: af_packet snd_hda_codec_generic snd_hda_intel 
snd_hda_controller snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device 
snd_pcm radeon cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight r8169 
mii coretemp snd_timer drm_kms_helper ttm snd drm i2c_core xhci_pci xhci_hcd 
soundcore evdev firmware_class hwmon hid_generic usbhid hid ehci_pci ehci_hcd 
sr_mod cdrom usbcore usb_common ipv6
CPU: 0 PID: 163 Comm: kworker/0:2 Tainted: G  D 4.1.0-rc2 #1
Hardware name: System manufacturer System Product Name/P8Z77-V LE PLUS, BIOS 
0403 05/08/2012
task: 8806012b1590 ti: 88003796 task.ti: 88003796
RIP: 0010:[]  [] kthread_data+0x7/0x10
RSP: 0018:880037963a60  EFLAGS: 00010002
RAX:  RBX:  RCX: 73c2bc6e
RDX:  RSI:  RDI: 8806012b1590
RBP: 8806012b1590 R08: 0001 R09: 0001
R10: ea001804b800 R11: 001a R12: 8806012b1980
R13:  R14: 00014300 R15: 
FS:  () GS:88061ec0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0028 CR3: 01478000 CR4: 001407f0
Stack:
 81051068 88061ec14300 8134c203 
 880037964000 8806012b1878 880037963af8 
 880603188000 8806012b1590 8134c4aa 8800379637d8
Call Trace:
 [] ? wq_worker_sleeping+0x8/0x90
 [] ? __schedule+0x3e3/0x660
 [] ? schedule+0x2a/0x80
 [] ? do_exit+0x61e/0xa20
 [] ? oops_end+0x66/0xa0
 [] ? no_context+0x236/0x286
 [] ? page_fault+0x1f/0x30
 [] ? radeon_audio_detect+0x5b/0x150 [radeon]
 [] ? radeon_audio_detect+0xe2/0x150 [radeon]
 [] ? radeon_dvi_detect+0x35a/0x4d0 [radeon]
 [] ? 
drm_helper_probe_single_connector_modes_merge_bits+0x2e6/0x490 [drm_kms_helper]
 [] ? drm_fb_helper_probe_connector_modes.isra.5+0x48/0x70 
[drm_kms_helper]
 [] ? drm_fb_helper_hotplug_event+0x55/0xe0 [drm_kms_helper]
 [] ? output_poll_execute+0x7c/0x1a0 [drm_kms_helper]
 [] ? process_one_work+0x130/0x360
 [] ? worker_t

Re: [PATCH] seccomp.2: Add note about alarm(2) not being sufficient to limit runtime

[Mikael Pettersson]

Jann Horn writes:
 > On Wed, Mar 11, 2015 at 10:43:50PM +0100, Mikael Pettersson wrote:
 > > Jann Horn writes:
 > >  > Or should I throw this patch away and write a patch
 > >  > for the prctl() manpage instead that documents that
 > >  > being able to call sigreturn() implies being able to
 > >  > effectively call sigprocmask(), at least on some
 > >  > architectures like X86?
 > > 
 > > Well, that is the semantics of sigreturn().  It is essentially
 > > setcontext() [which includes the actions of sigprocmask()], but
 > > with restrictions on parameter placement (at least on x86).
 > > 
 > > You could introduce some setting to restrict that aspect for
 > > seccomp processes, but you can't change this for normal processes
 > > without breaking things.
 > 
 > Then I think it's probably better and easier to just document the existing
 > behavior? If a new setting would have to be introduced and developers would
 > need to be aware of that, it's probably easier to just tell everyone to use
 > SIGKILL.
 > 
 > Does this manpage patch look good?

LGTM

Acked-by: Mikael Pettersson 

 > 
 > ---
 >  man2/seccomp.2 | 25 +
 >  1 file changed, 25 insertions(+)
 > 
 > diff --git a/man2/seccomp.2 b/man2/seccomp.2
 > index 702ceb8..f762d07 100644
 > --- a/man2/seccomp.2
 > +++ b/man2/seccomp.2
 > @@ -64,6 +64,31 @@ Strict secure computing mode is useful for 
 > number-crunching
 >  applications that may need to execute untrusted byte code, perhaps
 >  obtained by reading from a pipe or socket.
 >  
 > +Note that although the calling thread can no longer call
 > +.BR sigprocmask (2),
 > +it can use
 > +.BR sigreturn (2)
 > +to block all signals apart from
 > +.BR SIGKILL
 > +and
 > +.BR SIGSTOP .
 > +Therefore, to reliably terminate it,
 > +.BR SIGKILL
 > +has to be used, meaning that e.g.
 > +.BR alarm (2)
 > +is not sufficient for restricting its runtime. Instead, use
 > +.BR timer_create (2)
 > +with
 > +.BR SIGEV_SIGNAL
 > +and
 > +.BR sigev_signo
 > +set to
 > +.BR SIGKILL
 > +or use
 > +.BR setrlimit (2)
 > +to set the hard limit for
 > +.BR RLIMIT_CPU .
 > +
 >  This operation is available only if the kernel is configured with
 >  .BR CONFIG_SECCOMP
 >  enabled.
 > -- 
 > 2.1.4

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

Re: [PATCH] Don't allow blocking of signals using sigreturn.

[Mikael Pettersson]

Andy Lutomirski writes:
 > On Wed, Mar 11, 2015 at 2:43 PM, Mikael Pettersson  
 > wrote:
 > > Jann Horn writes:
 > >  > Or should I throw this patch away and write a patch
 > >  > for the prctl() manpage instead that documents that
 > >  > being able to call sigreturn() implies being able to
 > >  > effectively call sigprocmask(), at least on some
 > >  > architectures like X86?
 > >
 > > Well, that is the semantics of sigreturn().  It is essentially
 > > setcontext() [which includes the actions of sigprocmask()], but
 > > with restrictions on parameter placement (at least on x86).
 > >
 > > You could introduce some setting to restrict that aspect for
 > > seccomp processes, but you can't change this for normal processes
 > > without breaking things.
 > 
 > Which leads to the interesting question: does anyone ever call
 > sigreturn with a different signal mask than the kernel put there
 > during signal delivery

Yes.  Either a sigfillset();sigdelset(SIGSEGV), or a copy of the
thread's sigmask from a previous sigframe.

 > or, even more strangely, with a totally made up
 > context?

Not "totally made up", but certainly with adjustments(*) made to
both GPRs and PC.  In a different piece of SW: FPU controls.

(*) Rolling back or force-committing a micro-transaction until
PC+GPRs represent the state at an original instruction boundary.
This was in a product using dynamic binary instrumentation.
--
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] Don't allow blocking of signals using sigreturn.

[Mikael Pettersson]

Jann Horn writes:
 > Or should I throw this patch away and write a patch
 > for the prctl() manpage instead that documents that
 > being able to call sigreturn() implies being able to
 > effectively call sigprocmask(), at least on some
 > architectures like X86?

Well, that is the semantics of sigreturn().  It is essentially
setcontext() [which includes the actions of sigprocmask()], but
with restrictions on parameter placement (at least on x86).

You could introduce some setting to restrict that aspect for
seccomp processes, but you can't change this for normal processes
without breaking things.
--
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: status of ia64 / hpsim

[Mikael Pettersson]

Tony Luck writes:
 > On Tue, Dec 30, 2014 at 7:50 AM, Christoph Hellwig  
 > wrote:
 > > IS the ia64 hpsim architecture still in use?  I noticed it because it
 > > has a fairly rudimentary SCSI driver under arch/ia64, which doesn't
 > > look very maintained.
 > 
 > Mikael was doing something with hpsim on the ski simulator back in Jan'14. 
 > Was
 > that something real, or just playing because it was there?

I was trying to set up an emulated platform for continuous GCC bootstrap and
regression testsuite runs, but something broke the ia64 kernel causing EXT4
file system errors in the emulated platform, so I had to scrap that idea.

I tried various ia64 kernel versions, compiling the ia64 kernel with older
GCCs, and compiling SKI with older host (x86_64) GCCs, but nothing worked.
With no known-good starting point there was no reasonable way for me to
debug the problem.

/Mikael
--
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] arm: Blacklist gcc 4.8.[012] and 4.9.0 with CONFIG_FRAME_POINTER

[Mikael Pettersson]

Peter Hurley writes:
 > On 10/11/2014 12:33 PM, Mikael Pettersson wrote:
 > > Peter Hurley writes:
 > >  > On 10/10/2014 12:36 PM, Russell King - ARM Linux wrote:
 > >  > > On Fri, Oct 10, 2014 at 12:26:14PM -0400, Peter Hurley wrote:
 > >  > >> gcc versions 4.8.[012] and 4.9.0 generates code that prematurely
 > >  > >> adjusts the stack pointer such that still-to-be-referenced locals
 > >  > >> are below the stack pointer, which allows them to be overwritten
 > >  > >> by interrupts.
 > >  > > 
 > >  > > I would much rather do this in asm-offsets.c, along side the other ARM
 > >  > > specific buggy compiler test(s).  I'm presently putting together such
 > >  > > a patch.
 > >  > > 
 > >  > > The information in the thread on linux-omap says only GCC 4.8.1 and
 > >  > > GCC 4.8.2.  Where do you get the other versions from?
 > >  > 
 > >  > The gcc PR linked in the commit message; see the "Known to fail" field.
 > > 
 > > The 4.8.0 release is broken, but the 4.9.0 one is not.  It's unfortunate,
 > > but "4.9.0" may refer to "the 4.9.0 release" or to "some point after trunk
 > > forked 4.8 branch up to and including the 4.9.0 release point".  In this
 > > case, it's the latter -- this can be inferred from the fact that the
 > > fix went into trunk in October 2013 while 4.9.0 was branched and released
 > > during the first half of 2014.
 > 
 > Is there a reasonably quick way to determine if a particular commit is
 > in a particular release of gcc?

If you want the process to be fully automatic and the answer to be
absolutely precise, then "no".

If you're willing to manually map GCC PR fixes to release versions,
and to have some false negatives (some GCCs having a certain fix
will be flagged as not having it), then "yes".

For this ARM bug, PR58854, we know that 4.8.[0-2] have the bug, but
4.7 and older, 4.8.3 and newer, and 4.9 and newer are Ok.

A problem is that a GCC that identifies itself as 4.8.3 may be
(a) a 4.8.3 pre-release (i.e., close to 4.8.2),
(b) a 4.8.3 release, or
(c) a 4.8.4 pre-release that's been patched to say 4.8.3 (Red Hat does this).

Case (a) may or may not have the fix (we can't easily(*) tell), but
cases (b) and (c) are Ok.  If you're willing to classify all three
as not having the fix (false negatives), then you want to test

#if (__GNUC__ == 4 && __GNUC_MINOR__ == 8 && __GNUC_PATCHLEVEL__ < 4)

for possibly broken versions.

A complication is that a bug has both starting and ending commits.
It's not uncommon for distros and others to backport changes, so a
compiler that claims to be e.g. 4.7.4 may include a backport of the
4.8 change that caused the bug you're trying to avoid.  There is no
easy way to detect this, unless you have a runtime test case for the
bug.  I'd ignore this case as "unfixable".

So I'd write the tests for vanilla upstream GCC only, and tell distro
users to complain to their distros if their kernels get miscompiled.

(*) __VERSION__ is defined like "4.8.3 20140515 (prerelease)" in
pre-releases but like "4.8.3" in ordinary releases, but this is not
something you can test for in the C preprocessor.  A configure-time
check could extract the date and compare that with the date the fix
went into that particular branch, but case (c) above make detecting
pre-releases a bit more complicated.

 > Starting from the mainline viewcvs revision page for this fix here,
 > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=204203
 > (which is the link from the PR for the fix), navigation to anywhere
 > else in the gcc tree is impossible. I can't even look at the Changelog.

https://gcc.gnu.org/viewcvs/gcc/
then descend trunk or branches as needed.

/Mikael
--
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] arm: Blacklist gcc 4.8.[012] and 4.9.0 with CONFIG_FRAME_POINTER

[Mikael Pettersson]

Peter Hurley writes:
 > On 10/10/2014 12:36 PM, Russell King - ARM Linux wrote:
 > > On Fri, Oct 10, 2014 at 12:26:14PM -0400, Peter Hurley wrote:
 > >> gcc versions 4.8.[012] and 4.9.0 generates code that prematurely
 > >> adjusts the stack pointer such that still-to-be-referenced locals
 > >> are below the stack pointer, which allows them to be overwritten
 > >> by interrupts.
 > > 
 > > I would much rather do this in asm-offsets.c, along side the other ARM
 > > specific buggy compiler test(s).  I'm presently putting together such
 > > a patch.
 > > 
 > > The information in the thread on linux-omap says only GCC 4.8.1 and
 > > GCC 4.8.2.  Where do you get the other versions from?
 > 
 > The gcc PR linked in the commit message; see the "Known to fail" field.

The 4.8.0 release is broken, but the 4.9.0 one is not.  It's unfortunate,
but "4.9.0" may refer to "the 4.9.0 release" or to "some point after trunk
forked 4.8 branch up to and including the 4.9.0 release point".  In this
case, it's the latter -- this can be inferred from the fact that the
fix went into trunk in October 2013 while 4.9.0 was branched and released
during the first half of 2014.
--
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: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

[Mikael Pettersson]

Michel Dänzer writes:
 > On 06.09.2014 01:49, Mikael Pettersson wrote:
 > > Michel Dänzer writes:
 > >   > On 30.08.2014 22:59, Mikael Pettersson wrote:
 > >   > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen 
 > > corruption
 > >   > > after a while in X + firefox.  This still occurs with yesterday's 
 > > HEAD
 > >   > > of Linus' repo.  3.16 and ealier kernels are fine.
 > >   > >
 > >   > > I ran a bisect, which identified:
 > >   > >
 > >   > > commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
 > >   > > Author: Michel Dänzer 
 > >   > > Date:   Thu Jul 31 18:43:49 2014 +0900
 > >   > >
 > >   > >  drm/radeon: Always flush the HDP cache before submitting a CS 
 > > to the GPU
 > >   > >
 > >   > > as the cause of my screen corruption.  Reverting this from 3.17-rc2
 > >   > > (which requires manual intervention due to subsequent changes in
 > >   > > radeon_ring_commit()) eliminates the screen corruption.
 > >   >
 > >   > Does the patch below help?
 > > 
 > > Tested, sorry no joy.  I first reconfirmed the screen corruption with 
 > > 3.17-rc3.
 > > I then applied this and rebuilt/rebooted, and after a few minutes X had a 
 > > hickup
 > > (screen went black, came back after a few seconds, but then no cursor or
 > > reaction to mouse events), but I was able to kill it via my 
 > > Terminate_Server
 > > key binding.
 > 
 > I was afraid so, thanks for testing it.
 > 
 > 
 > I can't see any other option than the patch below then. Can you confirm that 
 > this
 > fixes the screen corruption?

It does, thanks.

Tested-by: Mikael Pettersson 

 > 
 > 
 > diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
 > index 4c5ec44..b0098e7 100644
 > --- a/drivers/gpu/drm/radeon/r100.c
 > +++ b/drivers/gpu/drm/radeon/r100.c
 > @@ -821,6 +821,20 @@ u32 r100_get_vblank_counter(struct radeon_device *rdev, 
 > int crtc)
 >  return RREG32(RADEON_CRTC2_CRNT_FRAME);
 >  }
 >  
 > +/**
 > + * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
 > + * rdev: radeon device structure
 > + * ring: ring buffer struct for emitting packets
 > + */
 > +static void r100_ring_hdp_flush(struct radeon_device *rdev, struct 
 > radeon_ring *ring)
 > +{
 > +radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > +radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
 > +RADEON_HDP_READ_BUFFER_INVALIDATE);
 > +radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > +radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
 > +}
 > +
 >  /* Who ever call radeon_fence_emit should call ring_lock and ask
 >   * for enough space (today caller are ib schedule and buffer move) */
 >  void r100_fence_ring_emit(struct radeon_device *rdev,
 > @@ -1056,20 +1070,6 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
 >  (void)RREG32(RADEON_CP_RB_WPTR);
 >  }
 >  
 > -/**
 > - * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
 > - * rdev: radeon device structure
 > - * ring: ring buffer struct for emitting packets
 > - */
 > -void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring 
 > *ring)
 > -{
 > -radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > -radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
 > -RADEON_HDP_READ_BUFFER_INVALIDATE);
 > -radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > -radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
 > -}
 > -
 >  static void r100_cp_load_microcode(struct radeon_device *rdev)
 >  {
 >  const __be32 *fw_data;
 > diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
 > b/drivers/gpu/drm/radeon/radeon_asic.c
 > index abe..2dd5847 100644
 > --- a/drivers/gpu/drm/radeon/radeon_asic.c
 > +++ b/drivers/gpu/drm/radeon/radeon_asic.c
 > @@ -185,7 +185,6 @@ static struct radeon_asic_ring r100_gfx_ring = {
 >  .get_rptr = &r100_gfx_get_rptr,
 >  .get_wptr = &r100_gfx_get_wptr,
 >  .set_wptr = &r100_gfx_set_wptr,
 > -.hdp_flush = &r100_ring_hdp_flush,
 >  };
 >  
 >  static struct radeon_asic r100_asic = {
 > @@ -332,7 +331,6 @@ static struct radeon_asic_ring r300_gfx_ring = {
 >  .get_rptr = &r100_gfx_get_rptr,
 >  .get_wptr = &r100_gfx_get_wptr,
 >  .set_wptr = &r100_gfx_set_wptr,
 > -.hdp_flush = &r100_ring_hdp_flush,
 >  };
 >  
 >  static struct radeon_asic r300_asic = {
 > di

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

[Mikael Pettersson]

Michel Dänzer writes:
 > On 06.09.2014 01:49, Mikael Pettersson wrote:
 > > Michel Dänzer writes:
 > >   > On 30.08.2014 22:59, Mikael Pettersson wrote:
 > >   > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen 
 > > corruption
 > >   > > after a while in X + firefox.  This still occurs with yesterday's 
 > > HEAD
 > >   > > of Linus' repo.  3.16 and ealier kernels are fine.
 > >   > >
 > >   > > I ran a bisect, which identified:
 > >   > >
 > >   > > commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
 > >   > > Author: Michel Dänzer 
 > >   > > Date:   Thu Jul 31 18:43:49 2014 +0900
 > >   > >
 > >   > >  drm/radeon: Always flush the HDP cache before submitting a CS 
 > > to the GPU
 > >   > >
 > >   > > as the cause of my screen corruption.  Reverting this from 3.17-rc2
 > >   > > (which requires manual intervention due to subsequent changes in
 > >   > > radeon_ring_commit()) eliminates the screen corruption.
 > >   >
 > >   > Does the patch below help?
 > > 
 > > Tested, sorry no joy.  I first reconfirmed the screen corruption with 
 > > 3.17-rc3.
 > > I then applied this and rebuilt/rebooted, and after a few minutes X had a 
 > > hickup
 > > (screen went black, came back after a few seconds, but then no cursor or
 > > reaction to mouse events), but I was able to kill it via my 
 > > Terminate_Server
 > > key binding.
 > 
 > I was afraid so, thanks for testing it.
 > 
 > 
 > I can't see any other option than the patch below then. Can you confirm that 
 > this
 > fixes the screen corruption?

I'll test this on Friday evening when I'm back home and have access to the
affected machine.

/Mikael


 > 
 > 
 > diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
 > index 4c5ec44..b0098e7 100644
 > --- a/drivers/gpu/drm/radeon/r100.c
 > +++ b/drivers/gpu/drm/radeon/r100.c
 > @@ -821,6 +821,20 @@ u32 r100_get_vblank_counter(struct radeon_device *rdev, 
 > int crtc)
 >  return RREG32(RADEON_CRTC2_CRNT_FRAME);
 >  }
 >  
 > +/**
 > + * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
 > + * rdev: radeon device structure
 > + * ring: ring buffer struct for emitting packets
 > + */
 > +static void r100_ring_hdp_flush(struct radeon_device *rdev, struct 
 > radeon_ring *ring)
 > +{
 > +radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > +radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
 > +RADEON_HDP_READ_BUFFER_INVALIDATE);
 > +radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > +radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
 > +}
 > +
 >  /* Who ever call radeon_fence_emit should call ring_lock and ask
 >   * for enough space (today caller are ib schedule and buffer move) */
 >  void r100_fence_ring_emit(struct radeon_device *rdev,
 > @@ -1056,20 +1070,6 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
 >  (void)RREG32(RADEON_CP_RB_WPTR);
 >  }
 >  
 > -/**
 > - * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
 > - * rdev: radeon device structure
 > - * ring: ring buffer struct for emitting packets
 > - */
 > -void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring 
 > *ring)
 > -{
 > -radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > -radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
 > -RADEON_HDP_READ_BUFFER_INVALIDATE);
 > -radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > -radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
 > -}
 > -
 >  static void r100_cp_load_microcode(struct radeon_device *rdev)
 >  {
 >  const __be32 *fw_data;
 > diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
 > b/drivers/gpu/drm/radeon/radeon_asic.c
 > index abe..2dd5847 100644
 > --- a/drivers/gpu/drm/radeon/radeon_asic.c
 > +++ b/drivers/gpu/drm/radeon/radeon_asic.c
 > @@ -185,7 +185,6 @@ static struct radeon_asic_ring r100_gfx_ring = {
 >  .get_rptr = &r100_gfx_get_rptr,
 >  .get_wptr = &r100_gfx_get_wptr,
 >  .set_wptr = &r100_gfx_set_wptr,
 > -.hdp_flush = &r100_ring_hdp_flush,
 >  };
 >  
 >  static struct radeon_asic r100_asic = {
 > @@ -332,7 +331,6 @@ static struct radeon_asic_ring r300_gfx_ring = {
 >  .get_rptr = &r100_gfx_get_rptr,
 >  .get_wptr = &r100_gfx_get_wptr,
 >  .set_wptr = &r100_gfx_set_wptr,
 > -.hdp_flush = &r100_ring_hdp_flush,
 >  

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

[Mikael Pettersson]

Michel Dänzer writes:
 > On 30.08.2014 22:59, Mikael Pettersson wrote:
 > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
 > > after a while in X + firefox.  This still occurs with yesterday's HEAD
 > > of Linus' repo.  3.16 and ealier kernels are fine.
 > > 
 > > I ran a bisect, which identified:
 > > 
 > > commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
 > > Author: Michel Dänzer 
 > > Date:   Thu Jul 31 18:43:49 2014 +0900
 > > 
 > >  drm/radeon: Always flush the HDP cache before submitting a CS to the 
 > > GPU
 > > 
 > > as the cause of my screen corruption.  Reverting this from 3.17-rc2
 > > (which requires manual intervention due to subsequent changes in
 > > radeon_ring_commit()) eliminates the screen corruption.
 > 
 > Does the patch below help?

Tested, sorry no joy.  I first reconfirmed the screen corruption with 3.17-rc3.
I then applied this and rebuilt/rebooted, and after a few minutes X had a hickup
(screen went black, came back after a few seconds, but then no cursor or
reaction to mouse events), but I was able to kill it via my Terminate_Server
key binding.  The kernel log showed:

[ 1641.247760] radeon :01:00.0: ring 0 stalled for more than 1msec
[ 1641.247765] radeon :01:00.0: GPU lockup (waiting for 0x6241 
last fence id 0x6240 on ring 0)
[ 1641.247768] radeon :01:00.0: failed to get a new IB (-35)
[ 1641.247770] [drm:radeon_cs_ib_fill] *ERROR* Failed to get ib !
[ 1641.404052] Failed to wait GUI idle while programming pipes. Bad things 
might happen.
[ 1641.405075] radeon :01:00.0: Saved 859 dwords of commands on ring 0.
[ 1641.405084] radeon :01:00.0: (r300_asic_reset:394) RBBM_STATUS=0x80010140
[ 1641.910649] radeon :01:00.0: (r300_asic_reset:413) RBBM_STATUS=0x80010140
[ 1642.412182] radeon :01:00.0: (r300_asic_reset:425) RBBM_STATUS=0x0140
[ 1642.412218] radeon :01:00.0: GPU reset succeed
[ 1642.412220] radeon :01:00.0: GPU reset succeeded, trying to resume
[ 1642.412224] radeon :01:00.0: 88060274f800 unpin not necessary
[ 1642.626303] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
[ 1642.626325] [drm] PCIE GART of 512M enabled (table at 0xE004).
[ 1642.626328] radeon :01:00.0: WB enabled
[ 1642.626331] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0xc000 and cpu addr 0x8800d9b9f000
[ 1642.626375] [drm] radeon: ring at 0xC0001000
[ 1642.783220] [drm:r100_ring_test] *ERROR* radeon: ring test failed 
(scratch(0x15E8)=0xCAFEDEAD)
[ 1642.783222] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[ 1642.783224] radeon :01:00.0: failed initializing CP (-22).

With a revert of the HDP flush patch things are stable.

/Mikael

 > 
 > diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
 > index 4c5ec44..3ff9c53 100644
 > --- a/drivers/gpu/drm/radeon/r100.c
 > +++ b/drivers/gpu/drm/radeon/r100.c
 > @@ -1070,6 +1070,20 @@ void r100_ring_hdp_flush(struct radeon_device *rdev, 
 > struct radeon_ring *ring)
 >  radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
 >  }
 >  
 > +/**
 > + * r100_mmio_hdp_flush - flush Host Data Path via MMIO
 > + * rdev: radeon device structure
 > + */
 > +void r100_mmio_hdp_flush(struct radeon_device *rdev)
 > +{
 > +WREG32(RADEON_HOST_PATH_CNTL,
 > +   rdev->config.r100.hdp_cntl | RADEON_HDP_READ_BUFFER_INVALIDATE);
 > +(void)RREG32(RADEON_HOST_PATH_CNTL);
 > +WREG32(RADEON_HOST_PATH_CNTL,
 > +   rdev->config.r100.hdp_cntl);
 > +(void)RREG32(RADEON_HOST_PATH_CNTL);
 > +}
 > +
 >  static void r100_cp_load_microcode(struct radeon_device *rdev)
 >  {
 >  const __be32 *fw_data;
 > diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
 > b/drivers/gpu/drm/radeon/radeon_asic.c
 > index abe..c23a123 100644
 > --- a/drivers/gpu/drm/radeon/radeon_asic.c
 > +++ b/drivers/gpu/drm/radeon/radeon_asic.c
 > @@ -408,7 +408,7 @@ static struct radeon_asic r300_asic_pcie = {
 >  .resume = &r300_resume,
 >  .vga_set_state = &r100_vga_set_state,
 >  .asic_reset = &r300_asic_reset,
 > -.mmio_hdp_flush = NULL,
 > +.mmio_hdp_flush = r100_mmio_hdp_flush,
 >  .gui_idle = &r100_gui_idle,
 >  .mc_wait_for_idle = &r300_mc_wait_for_idle,
 >  .gart = {
 > diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
 > b/drivers/gpu/drm/radeon/radeon_asic.h
 > index 275a5dc..e9b1c35 100644
 > --- a/drivers/gpu/drm/radeon/radeon_asic.h
 > +++ b/drivers/gpu/drm/radeon/radeon_asic.h
 > @@ -150,6 +150,8 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
 > struct radeon_ring *ring);
 >  void r100_ring_hdp_flush(struct rade

Re: bit fields && data tearing

[Mikael Pettersson]

Benjamin Herrenschmidt writes:
 > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
 > 
 > > Apologies for hijacking this thread but I need to extend this discussion
 > > somewhat regarding what a compiler might do with adjacent fields in a 
 > > structure.
 > > 
 > > The tty subsystem defines a large aggregate structure, struct tty_struct.
 > > Importantly, several different locks apply to different fields within that
 > > structure; ie., a specific spinlock will be claimed before updating or 
 > > accessing
 > > certain fields while a different spinlock will be claimed before updating 
 > > or
 > > accessing certain _adjacent_ fields.
 > > 
 > > What is necessary and sufficient to prevent accidental false-sharing?
 > > The patch below was flagged as insufficient on ia64, and possibly ARM.
 > 
 > We expect native aligned scalar types to be accessed atomically (the
 > read/modify/write of a larger quantity that gcc does on some bitfield
 > cases has been flagged as a gcc bug, but shouldn't happen on normal
 > scalar types).
 > 
 > I am not 100% certain of "bool" here, I assume it's treated as a normal
 > scalar and thus atomic but if unsure, you can always use int.

Please use an aligned int or long.  Some machines cannot do atomic
accesses on sub-int/long quantities, so 'bool' may cause unexpected
rmw cycles on adjacent fields.

/Mikael

 > 
 > Another option is to use the atomic bitops and make these bits in a
 > bitmask but that is probably unnecessary if you have locks already.
 > 
 > Cheers,
 > Ben.
 > 
 > 
 > > Regards,
 > > Peter Hurley
 > > 
 > > --- >% ---
 > > Subject: [PATCH 21/26] tty: Convert tty_struct bitfield to bools
 > > 
 > > The stopped, hw_stopped, flow_stopped and packet bits are smp-unsafe
 > > and interrupt-unsafe. For example,
 > > 
 > > CPU 0 | CPU 1
 > >   |
 > > tty->flow_stopped = 1 | tty->hw_stopped = 0
 > > 
 > > One of these updates will be corrupted, as the bitwise operation
 > > on the bitfield is non-atomic.
 > > 
 > > Ensure each flag has a separate memory location, so concurrent
 > > updates do not corrupt orthogonal states.
 > > 
 > > Signed-off-by: Peter Hurley 
 > > ---
 > >  include/linux/tty.h | 5 -
 > >  1 file changed, 4 insertions(+), 1 deletion(-)
 > > 
 > > diff --git a/include/linux/tty.h b/include/linux/tty.h
 > > index 1c3316a..7cf61cb 100644
 > > --- a/include/linux/tty.h
 > > +++ b/include/linux/tty.h
 > > @@ -261,7 +261,10 @@ struct tty_struct {
 > >unsigned long flags;
 > >int count;
 > >struct winsize winsize; /* winsize_mutex */
 > > -  unsigned char stopped:1, hw_stopped:1, flow_stopped:1, packet:1;
 > > +  bool stopped;
 > > +  bool hw_stopped;
 > > +  bool flow_stopped;
 > > +  bool packet;
 > >unsigned char ctrl_status;  /* ctrl_lock */
 > >unsigned int receive_room;  /* Bytes free for queue */
 > >int flow_change;
 > 
 > 
 > --
 > 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/

-- 
--
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: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

[Mikael Pettersson]

Michel Dänzer writes:
 > On 30.08.2014 22:59, Mikael Pettersson wrote:
 > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
 > > after a while in X + firefox.  This still occurs with yesterday's HEAD
 > > of Linus' repo.  3.16 and ealier kernels are fine.
 > > 
 > > I ran a bisect, which identified:
 > > 
 > > commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
 > > Author: Michel Dänzer 
 > > Date:   Thu Jul 31 18:43:49 2014 +0900
 > > 
 > >  drm/radeon: Always flush the HDP cache before submitting a CS to the 
 > > GPU
 > > 
 > > as the cause of my screen corruption.  Reverting this from 3.17-rc2
 > > (which requires manual intervention due to subsequent changes in
 > > radeon_ring_commit()) eliminates the screen corruption.
 > 
 > Does the patch below help?

Thanks for the patch, I'll test it on Friday evening when I'm
back home and have access to the affected machine.


 > 
 > diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
 > index 4c5ec44..3ff9c53 100644
 > --- a/drivers/gpu/drm/radeon/r100.c
 > +++ b/drivers/gpu/drm/radeon/r100.c
 > @@ -1070,6 +1070,20 @@ void r100_ring_hdp_flush(struct radeon_device *rdev, 
 > struct radeon_ring *ring)
 >  radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
 >  }
 >  
 > +/**
 > + * r100_mmio_hdp_flush - flush Host Data Path via MMIO
 > + * rdev: radeon device structure
 > + */
 > +void r100_mmio_hdp_flush(struct radeon_device *rdev)
 > +{
 > +WREG32(RADEON_HOST_PATH_CNTL,
 > +   rdev->config.r100.hdp_cntl | RADEON_HDP_READ_BUFFER_INVALIDATE);
 > +(void)RREG32(RADEON_HOST_PATH_CNTL);
 > +WREG32(RADEON_HOST_PATH_CNTL,
 > +   rdev->config.r100.hdp_cntl);
 > +(void)RREG32(RADEON_HOST_PATH_CNTL);
 > +}
 > +
 >  static void r100_cp_load_microcode(struct radeon_device *rdev)
 >  {
 >  const __be32 *fw_data;
 > diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
 > b/drivers/gpu/drm/radeon/radeon_asic.c
 > index abe..c23a123 100644
 > --- a/drivers/gpu/drm/radeon/radeon_asic.c
 > +++ b/drivers/gpu/drm/radeon/radeon_asic.c
 > @@ -408,7 +408,7 @@ static struct radeon_asic r300_asic_pcie = {
 >  .resume = &r300_resume,
 >  .vga_set_state = &r100_vga_set_state,
 >  .asic_reset = &r300_asic_reset,
 > -.mmio_hdp_flush = NULL,
 > +.mmio_hdp_flush = r100_mmio_hdp_flush,
 >  .gui_idle = &r100_gui_idle,
 >  .mc_wait_for_idle = &r300_mc_wait_for_idle,
 >  .gart = {
 > diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
 > b/drivers/gpu/drm/radeon/radeon_asic.h
 > index 275a5dc..e9b1c35 100644
 > --- a/drivers/gpu/drm/radeon/radeon_asic.h
 > +++ b/drivers/gpu/drm/radeon/radeon_asic.h
 > @@ -150,6 +150,8 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
 > struct radeon_ring *ring);
 >  void r100_ring_hdp_flush(struct radeon_device *rdev,
 >   struct radeon_ring *ring);
 > +void r100_mmio_hdp_flush(struct radeon_device *rdev);
 > +
 >  /*
 >   * r200,rv250,rs300,rv280
 >   */
 > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
 > b/drivers/gpu/drm/radeon/radeon_gem.c
 > index bfd7e1b..3d0f564 100644
 > --- a/drivers/gpu/drm/radeon/radeon_gem.c
 > +++ b/drivers/gpu/drm/radeon/radeon_gem.c
 > @@ -368,6 +368,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
 > void *data,
 >  r = radeon_bo_wait(robj, &cur_placement, false);
 >  /* Flush HDP cache via MMIO if necessary */
 >  if (rdev->asic->mmio_hdp_flush &&
 > +!rdev->asic->ring[RADEON_RING_TYPE_GFX_INDEX]->hdp_flush &&
 >  radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
 >  robj->rdev->asic->mmio_hdp_flush(rdev);
 >  drm_gem_object_unreference_unlocked(gobj);
 > diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
 > b/drivers/gpu/drm/radeon/radeon_ring.c
 > index d656079..b82843b 100644
 > --- a/drivers/gpu/drm/radeon/radeon_ring.c
 > +++ b/drivers/gpu/drm/radeon/radeon_ring.c
 > @@ -188,7 +188,8 @@ void radeon_ring_commit(struct radeon_device *rdev, 
 > struct radeon_ring *ring,
 >  /* If we are emitting the HDP flush via the ring buffer, we need to
 >   * do it before padding.
 >   */
 > -if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush)
 > +if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush &&
 > +!rdev->asic->mmio_hdp_flush)
 >  rdev->asic->ring[ring->idx]->hdp_flush(rdev, ring);
 >  /* We pad to match fetch size */
 >  while (ring->wptr & ring->align_mask) {
 > 
 > 
 > 
 > -- 
 > Earthling Michel Dänzer|  http://www.amd.com
 > Libre software enthusiast  |Mesa and X developer

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

[BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

[Mikael Pettersson]

Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
after a while in X + firefox.  This still occurs with yesterday's HEAD
of Linus' repo.  3.16 and ealier kernels are fine.

I ran a bisect, which identified:

commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
Author: Michel Dänzer 
Date:   Thu Jul 31 18:43:49 2014 +0900

drm/radeon: Always flush the HDP cache before submitting a CS to the GPU

as the cause of my screen corruption.  Reverting this from 3.17-rc2
(which requires manual intervention due to subsequent changes in
radeon_ring_commit()) eliminates the screen corruption.

User-space is vanilla Fedora 19 / x86_64 with updates.  radeon_drv.so says:

[62.574] (II) LoadModule: "radeon"
[62.574] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so
[62.574] (II) Module radeon: vendor="X.Org Foundation"
[62.574]compiled for 1.14.0, module version = 7.1.99
[62.574]Module class: X.Org Video Driver
[62.574]ABI class: X.Org Video Driver, version 14.1
...
[62.585] (--) RADEON(0): Chipset: "ATI Radeon X550 (RV370) 5B63 (PCIE)" 
(ChipID = 0x5b63)

See also my original report to LKML:


/Mikael
--
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: rt_sigreturn rejects a substitute stack frame as invalid.

[Mikael Pettersson]

Steven Stewart-Gallus writes:
 > Hello,
 > 
 > I'm not totally sure that GLibc's setcontext is safe to use in a
 > signal handler. So, I decided I was going to play things safe and let
 > rt_sigreturn switch stacks for me instead. However, rt_sigreturn seems
 > to reject my substitute stack frame as invalid and I'm not sure why.

I did similar things at my previous work (doing dynamic binary
instrumentation and virtualization of user-space binaries; can't
share the code alas, it's proprietary), but my code operated
directly on top of the kernel/user-space API, using the actual
kernel/user-space data structures rather than glibc's fake ones.

If you're sure that it's the kernel's rt_sigreturn and not whatever
glibc runs before it that complains, then a simple way of debugging
this is to modify your kernel to printk some diagnostics whenever
rt_sigreturn decides to error out.

You may also want to check out the 'pth' package.
--
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] 3.17-rc1 radeon screen corruption and hang

[Mikael Pettersson]

On one of my machines, an Ivy Bridge desktop with a Radeon X550 (RV370)
graphics card, 3.17-rc1 causes random screen corruption with X running.
Eventually X stopped honoring mouse or keyboard clicks, and when I tried
to reboot it via an ssh login from another machine, it hanged hard.
3.16 and earlier kernels work perfectly.

After rebooting there was nothing interesting in /var/log/messages, but
Xorg.0.log.old showed the following:

(EE) [mi] EQ overflowing.  Additional events will be discarded until existing 
events are processed.
(EE) 
(EE) Backtrace:
(EE) 0: X (mieqEnqueue+0x22b) [0x57728b]
(EE) 1: X (QueuePointerEvents+0x52) [0x44db12]
(EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (_init+0x2c4d) 
[0x7f287fbf7b1d]
(EE) 3: X (DPMSSupported+0xe8) [0x486498]
(EE) 4: X (xf86SerialModemClearBits+0x230) [0x4aea80]
(EE) 5: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7f28859f2f8f]
(EE) 6: /lib64/libc.so.6 (ioctl+0x7) [0x7f28846f5eb7]
(EE) 7: /lib64/libdrm.so.2 (drmIoctl+0x34) [0x7f28857db6c4]
(EE) 8: /lib64/libdrm.so.2 (drmCommandWrite+0x1e) [0x7f28857dd84e]
(EE) 9: /lib64/libdrm_radeon.so.1 (_init+0x4c1) [0x7f288032e511]
(EE) 10: /lib64/libdrm_radeon.so.1 (_init+0x6c4) [0x7f288032e924]
(EE) 11: /usr/lib64/xorg/modules/drivers/radeon_drv.so (_init+0x1af29) 
[0x7f2880577f09]
(EE) 12: /usr/lib64/xorg/modules/libexa.so (exaMoveOutPixmap+0x1287) 
[0x7f287f8fe9a7]
(EE) 13: /usr/lib64/xorg/modules/libexa.so (exaMoveOutPixmap+0x3a12) 
[0x7f287f903852]
(EE) 14: /usr/lib64/xorg/modules/libexa.so (exaEnableDisableFBAccess+0x481a) 
[0x7f287f90deda]
(EE) 15: /usr/lib64/xorg/modules/libexa.so (exaEnableDisableFBAccess+0x15b4) 
[0x7f287f907cb4]
(EE) 16: X (DamageRegionAppend+0x592) [0x521a92]
(EE) 17: X (AddTraps+0x3b8a) [0x51e99a]
(EE) 18: X (SendErrorToClient+0x3f7) [0x437217]
(EE) 19: X (_init+0x3aa2) [0x429db2]
(EE) 20: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f288462ab45]
(EE) 21: X (_start+0x29) [0x426a21]
(EE) 22: ? (?+0x29) [0x29]

This repeated a number of times, and the last entry was prefixed by:

(EE) [mi] EQ overflow continuing.  1000 events have been dropped.
(EE) [mi] No further overflow reports will be reported until the clog is 
cleared.

User-space is Fedora 19 / x86_64 with latest updates.  No non-Fedora X drivers.

/Mikael
--
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 0/2] __vdso_findsym

[Mikael Pettersson]

Andy Lutomirski writes:
 > The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym.  This
 > implements __vdso_findsym.
 > 
 > This would make it easier for runtimes that don't otherwise implement
 > ELF loaders to use the vdso.
 > 
 > Thoughts?

I'm opposed to this based on the principle that the kernel should NOT
be a dumping ground for random code that user-space can and should
implement for itself.  As long as the vdso is correctly formatted ELF,
then parsing it is easy, and the kernel should not care at all if or
how user-space accesses it.

The fact that golang got it wrong is not an argument for moving this
functionality into the kernel.

/Mikael
--
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: rcu alignment warning tripping on m68k

[Mikael Pettersson]

Paul E. McKenney writes:
 > On Fri, May 30, 2014 at 11:29:41AM +1000, Greg Ungerer wrote:
 > > On 29/05/14 23:11, One Thousand Gnomes wrote:
 > > > On Thu, 29 May 2014 12:08:32 +1000
 > > > Greg Ungerer  wrote:
 > > > 
 > > >> Hi All,
 > > >>
 > > >> Inside kernel/rcy/tree.c in __call_rcu() it does an alignment check on
 > > >> the head pointer passed in. This trips on m68k systems, because they 
 > > >> only
 > > >> need alignment of 32bit quantities to 16bit boundaries.
 > > > 
 > > > __alignof perhaps ?
 > > 
 > > That might do. Change then becomes something like:
 > > 
 > > --- a/kernel/rcu/tree.c
 > > +++ b/kernel/rcu/tree.c
 > > @@ -2467,7 +2467,7 @@ __call_rcu(struct rcu_head *head, void 
 > > (*func)(struct rcu_
 > > unsigned long flags;
 > > struct rcu_data *rdp;
 > > 
 > > -   WARN_ON_ONCE((unsigned long)head & 0x3); /* Misaligned rcu_head! */
 > > +   WARN_ON_ONCE((unsigned long)head & (__alignof__(head) - 1)); /* 
 > > Misaligned rcu_head! */
 > 
 > Hmmm...  The purpose of the check is to reserve the low-order bits to
 > allow RCU to classify callbacks as being time-critical or not.  RCU
 > can probably live with a single bit, but if there is some architecture
 > out there that simply refuses to do alignment, I need to know about it.
 > 
 > (See "git show 0bb7b59d6e2b8" for more info.)
 > 
 > So how about this instead?
 > 
 >  -   WARN_ON_ONCE((unsigned long)head & 0x1); /* Misaligned rcu_head! */
 > 
 > (Trying to remember if I have seen Linux kernel code that uses both
 > the lower bits...)

As stated above, m68k-linux aligns to 16-bit boundaries by default, so you'd
get one bit but not necessarily more.  If you want more free low bits, why
not attach an explicit attribute aligned to the rcu_head type declaration?
--
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: Q: uniqueness of pthread_t

[Mikael Pettersson]

Ulrich Windl writes:
 > Hi!
 > 
 > I'm programming a little bit with pthreads in Linux. As I understand 
 > pthread_t is an opaque type (a pointer address?) that cannot be mapped to 
 > the kernel's TID easily. Anyway: Is it expected that when one thread 
 > terminates and another thread is created (in fact the same thread again), 
 > that the p_thread my be resused?

Wrong list, please try  instead.
--
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/

keyboard problems on Dell Latitude E6230

[Mikael Pettersson]

I'm having problems with the built-in keyboard on Dell Latitude E6230
laptops and Linux 3.12/3.13 kernels:

- sometimes the keyboard just keeps sending the same key code, as if
  the key was held down permanently; sometimes that can be cured by
  pressing ^C or something, but often only a reboot fixes it

- sometimes the keyboard just stops sending key codes; only a reboot
  fixes it

This issue has plagued me since Nov last year when I got my first E6230.
Last week I got a replacement machine, but it too has the same problems.

Since I haven't seen this problem with any other laptop under Linux for
the last 15 years or so, I have to conclude that there's some HW issue
with these machines that the Linux kernel doesn't handle.

Any ideas?
--
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/5] ia64 ski emulator patches

[Mikael Pettersson]

Mikael Pettersson writes:
 > Mikulas Patocka writes:
 >  > 
 >  > 
 >  > On Sat, 25 Jan 2014, Mikael Pettersson wrote:
 >  > 
 >  > > My ski patches are in 
 > <http://user.it.uu.se/~mikpe/linux/patches/ia64/ski-1.3.2/>
 >  > > for now.  I'll post the kernel patches to linux-ia64 @ vger in a few 
 > minutes.
 >  > > 
 >  > > /Mikael
 >  > 
 >  > Thanks for the patches.
 >  > 
 >  > Isn't this subject to races? - could it lock up if the signal happens 
 > just 
 >  > before the pause syscall?
 >  > 
 >  > +case SSC_HALT_LIGHT:
 >  > +  /* Sleep until SIGIO or SIGALRM is received; this relies on
 >  > +keyboard/ethernet input being detected via SIGIO, and the
 >  > +ITC now being emulated via setitimer() and SIGALRM.  */
 >  > +  pause ();
 >  > +  break;
 >  > +
 > 
 > Thanks for the review. You're right, the pause mustn't happen if
 > itc_itimer_fired == 1.  Let me ponder this for a while...

Ok, I've fixed this in two different ways: one patch which uses pselect,
and one patch which uses plain select + the self-pipe trick.  Both work
in limited testing, but the pselect one is much nicer and appears to have
a little less host CPU overhead, so that's the one I'm stress-testing now.

Both patches have been uploaded to the same place as before.

/Mikael
--
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/5] ia64 ski emulator patches

[Mikael Pettersson]

Mikulas Patocka writes:
 > 
 > 
 > On Sat, 25 Jan 2014, Mikael Pettersson wrote:
 > 
 > > My ski patches are in 
 > > <http://user.it.uu.se/~mikpe/linux/patches/ia64/ski-1.3.2/>
 > > for now.  I'll post the kernel patches to linux-ia64 @ vger in a few 
 > > minutes.
 > > 
 > > /Mikael
 > 
 > Thanks for the patches.
 > 
 > Isn't this subject to races? - could it lock up if the signal happens just 
 > before the pause syscall?
 > 
 > +case SSC_HALT_LIGHT:
 > +  /* Sleep until SIGIO or SIGALRM is received; this relies on
 > +keyboard/ethernet input being detected via SIGIO, and the
 > +ITC now being emulated via setitimer() and SIGALRM.  */
 > +  pause ();
 > +  break;
 > +

Thanks for the review. You're right, the pause mustn't happen if
itc_itimer_fired == 1.  Let me ponder this for a while...

/Mikael
--
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/5] ia64 ski emulator patches

[Mikael Pettersson]

Luck, Tony writes:
 > Mikulas:
 > >> Here I'm sending some ia64 patches to make it work in the ski emulator. 
 > >> This has been broken for a long time.
 > 
 > Thanks - There are questions from time to time on how to test ia64
 > for those people who do not have hardware.
 > 
 > Mikael:
 > > Thanks.  I've recently started running 3.x kernels on ia64 via ski,
 > > but I'm getting random kernel crashes with 3.13.  I'll give your
 > > patches a try shortly.
 > 
 > Let me know how that goes - I haven't used ski in a decade and
 > have quite forgotten how to set it up.

It seems my kernel crashes were due to using gcc-4.8.2 to compile ski,
going back to gcc-4.7.3 for ski, and gcc-4.3.6 for cross-compiling
the kernel, gives me a solid emulated system.

 > > I've written a few patches to improve other aspects of running the
 > > kernel on ski:
 > > - kernel patch to turn PAL_HALT_LIGHT into a new SSC_HALT_LIGHT,
 > >   and a corresponing ski patch to pause() on SSC_HALT_LIGHT; this
 > >   together with the fixed-frequency ITC patch allows ski to idle
 > >   with very low host CPU overhead when the guest kernel idles
 > > - kernel patch to bump the RAM size from 130MB to 2GB
 > >
 > > I'd be happy to share these patches if there's interest in them.
 > 
 > It seems that there are at least two of you out there - so I'm happy
 > to take kernel patches that make things better.  Not sure where the
 > ski patches go - is someone maintaining that?

The ski project on sourceforge seems dead, nothing have been posted
on its mailing list since 2008, and the web interface for browsing
the source repo is broken.  Red Hat, Gentoo, and Debian package ski
with a few common build fixes, but that's it.

/Mikael
--
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/5] ia64 ski emulator patches

[Mikael Pettersson]

Mikulas Patocka writes:
 > 
 > 
 > On Fri, 24 Jan 2014, Mikael Pettersson wrote:
 > 
 > > Mikulas Patocka writes:
 > >  > Hi
 > >  > 
 > >  > Here I'm sending some ia64 patches to make it work in the ski emulator. 
 > >  > This has been broken for a long time.
 > > 
 > > Thanks.  I've recently started running 3.x kernels on ia64 via ski,
 > > but I'm getting random kernel crashes with 3.13.  I'll give your
 > > patches a try shortly.
 > 
 > I also had some random page-table corruption when running recent kernels 
 > in ski. The problems occured when upgrading the whole Debian distribution. 
 > Kernel 2.6.8 was solid, new kernels caused problems, I don't know why.

What I've seen so far seems to indicate that gcc-4.8.2 miscompiles ski,
resulting in kernel oopses, and _possibly_ that gcc-4.7.3 miscompiles
the kernel.  Ski compiled by gcc-4.7.3 (on x86_64) running a kernel
compiled by gcc-4.3.6 seems to be a solid combination for me.

 > > I've written a few patches to improve other aspects of running the
 > > kernel on ski:
 > > - ski patch to use tun/tap networking (no need to run ski as root)
 > > - ski patch to implement a fixed-frequency ITC (the ITC is currently
 > >   highly variable, completely breaking basic timekeeping)
 > > - kernel patch to turn PAL_HALT_LIGHT into a new SSC_HALT_LIGHT,
 > >   and a corresponing ski patch to pause() on SSC_HALT_LIGHT; this
 > >   together with the fixed-frequency ITC patch allows ski to idle
 > >   with very low host CPU overhead when the guest kernel idles
 > > - kernel patch to bump the RAM size from 130MB to 2GB
 > > 
 > > I'd be happy to share these patches if there's interest in them.
 > > 
 > > /Mikael
 > 
 > I would be interested in them. I also patched that timekeeping issue in 
 > ski.

My ski patches are in 
<http://user.it.uu.se/~mikpe/linux/patches/ia64/ski-1.3.2/>
for now.  I'll post the kernel patches to linux-ia64 @ vger in a few minutes.

/Mikael
--
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/5] ia64 ski emulator patches

[Mikael Pettersson]

Mikulas Patocka writes:
 > 
 > 
 > On Fri, 24 Jan 2014, Mikael Pettersson wrote:
 > 
 > > Mikulas Patocka writes:
 > >  > Hi
 > >  > 
 > >  > Here I'm sending some ia64 patches to make it work in the ski emulator. 
 > >  > This has been broken for a long time.
 > > 
 > > Thanks.  I've recently started running 3.x kernels on ia64 via ski,
 > > but I'm getting random kernel crashes with 3.13.  I'll give your
 > > patches a try shortly.
 > 
 > BTW. does the kernel boot for you without that _STK_LIM_MAX change? For 
 > me, _STK_LIM_MAX was a showstopper, it wasn't able to spawn any userspace 
 > process without this patch.

Yes, everything works fine for me without your _STK_LIM_MAX change.
My ski VMs currently run 3.12 kernels with Fedora 9 user-space.

/Mikael
--
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/5] ia64 ski emulator patches

[Mikael Pettersson]

Mikulas Patocka writes:
 > Hi
 > 
 > Here I'm sending some ia64 patches to make it work in the ski emulator. 
 > This has been broken for a long time.

Thanks.  I've recently started running 3.x kernels on ia64 via ski,
but I'm getting random kernel crashes with 3.13.  I'll give your
patches a try shortly.

I've written a few patches to improve other aspects of running the
kernel on ski:
- ski patch to use tun/tap networking (no need to run ski as root)
- ski patch to implement a fixed-frequency ITC (the ITC is currently
  highly variable, completely breaking basic timekeeping)
- kernel patch to turn PAL_HALT_LIGHT into a new SSC_HALT_LIGHT,
  and a corresponing ski patch to pause() on SSC_HALT_LIGHT; this
  together with the fixed-frequency ITC patch allows ski to idle
  with very low host CPU overhead when the guest kernel idles
- kernel patch to bump the RAM size from 130MB to 2GB

I'd be happy to share these patches if there's interest in them.

/Mikael
--
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?] mtrr sanitizer fails on Latitude E6230

[Mikael Pettersson]

Yinghai Lu writes:
 > On Thu, Nov 7, 2013 at 12:25 AM, Mikael Pettersson  
 > wrote:
 > > Yinghai Lu writes:
 > >  > On Wed, Nov 6, 2013 at 1:16 AM, Mikael Pettersson 
 > >  wrote:
 > >  > > I recently got a Dell Latitude E6230 (Ivy Bridge i7-3540M) and 
 > > noticed that
 > >  > > the mtrr sanitizer failed on it:
 > >  > >
 > >  > > === snip ===
 > >  > > Linux version 3.12.0 (mikpe@barley) (gcc version 4.8.3 20131017 
 > > (prerelease) (GCC) ) #1 SMP Wed Nov 6 09:46:02 CET 2013
 > >  > > Command line: ro root=LABEL=/ resume=/dev/sda2 rd_NO_LUKS rd_NO_LVM 
 > > rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 
 > > KEYTABLE=sv-latin1
 > >  > ...
 > >  > gran_size: 8M  chunk_size: 64M num_reg: 9  lose cover RAM: 
 > > 6M
 > >  > ...
 > >  > > mtrr_cleanup: can not find optimal value
 > >  > > please specify mtrr_gran_size/mtrr_chunk_size
 > >  > > === snip ===
 > >  > >
 > >  > > For now I'm disabling the mtrr sanitizer in this machine's kernel.
 > >  >
 > >  > Can you try to boot with "mtrr_gran_size=8m mtrr_chunk_size=64m" ?
 > >
 > > That results in:
 > >
 > > reg 0, base: 0GB, range: 8GB, type WB
 > > reg 1, base: 8GB, range: 512MB, type WB
 > > reg 2, base: 3584MB, range: 512MB, type UC
 > > reg 3, base: 3520MB, range: 64MB, type UC
 > > reg 4, base: 3512MB, range: 8MB, type UC
 > > reg 5, base: 8688MB, range: 16MB, type UC
 > > reg 6, base: 8680MB, range: 8MB, type UC
 > > reg 7, base: 8678MB, range: 2MB, type UC
 > > total RAM covered: 8094M
 > >  gran_size: 8M  chunk_size: 64M num_reg: 9  lose cover RAM: 6M
 > > New variable MTRRs
 > > reg 0, base: 0GB, range: 2GB, type WB
 > > reg 1, base: 2GB, range: 1GB, type WB
 > > reg 2, base: 3GB, range: 256MB, type WB
 > > reg 3, base: 3328MB, range: 128MB, type WB
 > > reg 4, base: 3456MB, range: 64MB, type WB
 > > reg 5, base: 3512MB, range: 8MB, type UC
 > > reg 6, base: 4GB, range: 4GB, type WB
 > > reg 7, base: 8GB, range: 512MB, type WB
 > > reg 8, base: 8672MB, range: 32MB, type UC
 > > e820: update [mem 0xdb80-0x] usable ==> reserved
 > > e820: update [mem 0x21e00-0x21e5f] usable ==> reserved
 > ...
 > >> modified: [mem 0x00021e00-0x00021e5f] reserved
 > 
 > that is right, it throw 6M away.
 > 
 > Did you notice any slowness or speeding for x window?

I'm not noticing any change.  i915 kernel driver + xorg's intel driver.

 > What does /proc/mtrr look like after xwindow is started?

reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c000 ( 3072MB), size=  256MB, count=1: write-back
reg03: base=0x0d000 ( 3328MB), size=  128MB, count=1: write-back
reg04: base=0x0d800 ( 3456MB), size=   64MB, count=1: write-back
reg05: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable
reg06: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back
reg07: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg08: base=0x21e00 ( 8672MB), size=   32MB, count=1: uncachable

/Mikael
--
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?] mtrr sanitizer fails on Latitude E6230

[Mikael Pettersson]

Yinghai Lu writes:
 > On Wed, Nov 6, 2013 at 1:16 AM, Mikael Pettersson  
 > wrote:
 > > I recently got a Dell Latitude E6230 (Ivy Bridge i7-3540M) and noticed that
 > > the mtrr sanitizer failed on it:
 > >
 > > === snip ===
 > > Linux version 3.12.0 (mikpe@barley) (gcc version 4.8.3 20131017 
 > > (prerelease) (GCC) ) #1 SMP Wed Nov 6 09:46:02 CET 2013
 > > Command line: ro root=LABEL=/ resume=/dev/sda2 rd_NO_LUKS rd_NO_LVM 
 > > rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 
 > > KEYTABLE=sv-latin1
 > ...
 > gran_size: 8M  chunk_size: 64M num_reg: 9  lose cover RAM: 6M
 > ...
 > > mtrr_cleanup: can not find optimal value
 > > please specify mtrr_gran_size/mtrr_chunk_size
 > > === snip ===
 > >
 > > For now I'm disabling the mtrr sanitizer in this machine's kernel.
 > 
 > Can you try to boot with "mtrr_gran_size=8m mtrr_chunk_size=64m" ?

That results in:

Linux version 3.12.0-test (mikpe@barley) (gcc version 4.8.3 20131017 
(prerelease) (GCC) ) #1 SMP Thu Nov 7 09:12:14 CET 2013
Command line: mtrr_gran_size=8m mtrr_chunk_size=64m ro root=LABEL=/ 
resume=/dev/sda2 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 
SYSFONT=latarcyrheb-sun16 KEYTABLE=sv-latin1
KERNEL supported cpus:
  Intel GenuineIntel
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009d3ff] usable
BIOS-e820: [mem 0x0009d400-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0x1fff] usable
BIOS-e820: [mem 0x2000-0x201f] reserved
BIOS-e820: [mem 0x2020-0x40003fff] usable
BIOS-e820: [mem 0x40004000-0x40004fff] reserved
BIOS-e820: [mem 0x40005000-0xd5f09fff] usable
BIOS-e820: [mem 0xd5f0a000-0xd5ff] reserved
BIOS-e820: [mem 0xd600-0xd6751fff] usable
BIOS-e820: [mem 0xd6752000-0xd67f] reserved
BIOS-e820: [mem 0xd680-0xd6fb2fff] usable
BIOS-e820: [mem 0xd6fb3000-0xd6ff] ACPI data
BIOS-e820: [mem 0xd700-0xd86fbfff] usable
BIOS-e820: [mem 0xd86fc000-0xd87f] ACPI NVS
BIOS-e820: [mem 0xd880-0xd96d4fff] usable
BIOS-e820: [mem 0xd96d5000-0xda054fff] reserved
BIOS-e820: [mem 0xda055000-0xda097fff] ACPI NVS
BIOS-e820: [mem 0xda098000-0xdaadcfff] usable
BIOS-e820: [mem 0xdaadd000-0xdafe] reserved
BIOS-e820: [mem 0xdaff-0xdaff] usable
BIOS-e820: [mem 0xdb80-0xdf9f] reserved
BIOS-e820: [mem 0xf800-0xfbff] reserved
BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xff00-0x] reserved
BIOS-e820: [mem 0x0001-0x00021e5f] usable
NX (Execute Disable) protection: active
SMBIOS 2.7 present.
DMI: Dell Inc. Latitude E6230/0Y47PX, BIOS A11 08/27/2013
e820: update [mem 0x-0x0fff] usable ==> reserved
e820: remove [mem 0x000a-0x000f] usable
e820: last_pfn = 0x21e600 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C write-protect
  D-E7FFF uncachable
  E8000-F write-protect
MTRR variable ranges enabled:
  0 base 0 mask E write-back
  1 base 2 mask FE000 write-back
  2 base 0E000 mask FE000 uncachable
  3 base 0DC00 mask FFC00 uncachable
  4 base 0DB80 mask FFF80 uncachable
  5 base 21F00 mask FFF00 uncachable
  6 base 21E80 mask FFF80 uncachable
  7 base 21E60 mask FFFE0 uncachable
  8 disabled
  9 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 0GB, range: 8GB, type WB
reg 1, base: 8GB, range: 512MB, type WB
reg 2, base: 3584MB, range: 512MB, type UC
reg 3, base: 3520MB, range: 64MB, type UC
reg 4, base: 3512MB, range: 8MB, type UC
reg 5, base: 8688MB, range: 16MB, type UC
reg 6, base: 8680MB, range: 8MB, type UC
reg 7, base: 8678MB, range: 2MB, type UC
total RAM covered: 8094M
 gran_size: 8M  chunk_size: 64M num_reg: 9  lose cover RAM: 6M
New variable MTRRs
reg 0, base: 0GB, range: 2GB, type WB
reg 1, base: 2GB, range: 1GB, type WB
reg 2, base: 3GB, range: 256MB, type WB
reg 3, base: 3328MB, range: 128MB, type WB
reg 4, base: 3456MB, range: 64MB, type WB
reg 5, base: 3512MB, range: 8MB, type UC
reg 6, base: 4GB, range: 4GB, type WB
reg 7, base: 8GB, range: 512MB, 

Re: ARM audit, seccomp, etc are broken wrt OABI syscalls

[Mikael Pettersson]

Russell King - ARM Linux writes:
 > OABI compat was meant to allow a transition from OABI to EABI.  While
 > a lot of effort went in to the kernel side of that, which does allow
 > OABI based userspace to boot with an EABI kernel, and allows OABI built
 > test programs to run under an EABI kernel, actually being able to
 > migrate userland is far from trivial - and something that I've never
 > been able to do.  Hence, virtually all my long-running ARM machines
 > here are stuck with OABI, and I don't see that situation ever changing.

I did a live incremental upgrade from OABI to EABI on my systems years
ago.  What I did was to first patch my OABI glibc to look for .so files
in oabi/ subdirectories.  Then I moved all OABI .so files to oabi/
subdirectories, and deleted all OABI static .a libraries.  After that
it was "simply" a matter of rebuilding everything as EABI, in the right
order.  The main advantage over this compared to a bootstrap-from-scratch
(which I've done 4 times on different architectures) was that I had access
to fully functional utilities and build tools from the start.

I _might_ be able to locate the glibc patch I used; do you want it?

/Mikael
--
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?] mtrr sanitizer fails on Latitude E6230

[Mikael Pettersson]

I recently got a Dell Latitude E6230 (Ivy Bridge i7-3540M) and noticed that
the mtrr sanitizer failed on it:

=== snip ===
Linux version 3.12.0 (mikpe@barley) (gcc version 4.8.3 20131017 (prerelease) 
(GCC) ) #1 SMP Wed Nov 6 09:46:02 CET 2013
Command line: ro root=LABEL=/ resume=/dev/sda2 rd_NO_LUKS rd_NO_LVM rd_NO_MD 
rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=sv-latin1
KERNEL supported cpus:
  Intel GenuineIntel
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009d3ff] usable
BIOS-e820: [mem 0x0009d400-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0x1fff] usable
BIOS-e820: [mem 0x2000-0x201f] reserved
BIOS-e820: [mem 0x2020-0x40003fff] usable
BIOS-e820: [mem 0x40004000-0x40004fff] reserved
BIOS-e820: [mem 0x40005000-0xd5f09fff] usable
BIOS-e820: [mem 0xd5f0a000-0xd5ff] reserved
BIOS-e820: [mem 0xd600-0xd6751fff] usable
BIOS-e820: [mem 0xd6752000-0xd67f] reserved
BIOS-e820: [mem 0xd680-0xd6fb2fff] usable
BIOS-e820: [mem 0xd6fb3000-0xd6ff] ACPI data
BIOS-e820: [mem 0xd700-0xd86fbfff] usable
BIOS-e820: [mem 0xd86fc000-0xd87f] ACPI NVS
BIOS-e820: [mem 0xd880-0xd96d4fff] usable
BIOS-e820: [mem 0xd96d5000-0xda054fff] reserved
BIOS-e820: [mem 0xda055000-0xda097fff] ACPI NVS
BIOS-e820: [mem 0xda098000-0xdaadcfff] usable
BIOS-e820: [mem 0xdaadd000-0xdafe] reserved
BIOS-e820: [mem 0xdaff-0xdaff] usable
BIOS-e820: [mem 0xdb80-0xdf9f] reserved
BIOS-e820: [mem 0xf800-0xfbff] reserved
BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xff00-0x] reserved
BIOS-e820: [mem 0x0001-0x00021e5f] usable
NX (Execute Disable) protection: active
SMBIOS 2.7 present.
DMI: Dell Inc. Latitude E6230/0Y47PX, BIOS A11 08/27/2013
e820: update [mem 0x-0x0fff] usable ==> reserved
e820: remove [mem 0x000a-0x000f] usable
e820: last_pfn = 0x21e600 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C write-protect
  D-E7FFF uncachable
  E8000-F write-protect
MTRR variable ranges enabled:
  0 base 0 mask E write-back
  1 base 2 mask FE000 write-back
  2 base 0E000 mask FE000 uncachable
  3 base 0DC00 mask FFC00 uncachable
  4 base 0DB80 mask FFF80 uncachable
  5 base 21F00 mask FFF00 uncachable
  6 base 21E80 mask FFF80 uncachable
  7 base 21E60 mask FFFE0 uncachable
  8 disabled
  9 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 0GB, range: 8GB, type WB
reg 1, base: 8GB, range: 512MB, type WB
reg 2, base: 3584MB, range: 512MB, type UC
reg 3, base: 3520MB, range: 64MB, type UC
reg 4, base: 3512MB, range: 8MB, type UC
reg 5, base: 8688MB, range: 16MB, type UC
reg 6, base: 8680MB, range: 8MB, type UC
reg 7, base: 8678MB, range: 2MB, type UC
total RAM covered: 8094M
 gran_size: 64K chunk_size: 64K num_reg: 10 lose cover RAM: 
102M
 gran_size: 64K chunk_size: 128Knum_reg: 10 lose cover RAM: 
102M
 gran_size: 64K chunk_size: 256Knum_reg: 10 lose cover RAM: 
102M
 gran_size: 64K chunk_size: 512Knum_reg: 10 lose cover RAM: 
102M
 gran_size: 64K chunk_size: 1M  num_reg: 10 lose cover RAM: 102M
 gran_size: 64K chunk_size: 2M  num_reg: 10 lose cover RAM: 102M
 gran_size: 64K chunk_size: 4M  num_reg: 10 lose cover RAM: 102M
 gran_size: 64K chunk_size: 8M  num_reg: 10 lose cover RAM: 102M
 gran_size: 64K chunk_size: 16M num_reg: 10 lose cover RAM: 
38M
*BAD*gran_size: 64K chunk_size: 32M num_reg: 10 lose cover RAM: 
-16M
*BAD*gran_size: 64K chunk_size: 64M num_reg: 10 lose cover RAM: 
-16M
 gran_size: 64K chunk_size: 128Mnum_reg: 10 lose cover RAM: 
0G
 gran_size: 64K chunk_size: 256Mnum_reg: 10 lose cover RAM: 
0G
 gran_size: 64K chunk_size: 512Mnum_reg: 10 lose cover RAM: 
0G
 gran_size: 64K chunk_size: 1G  num_reg: 10 lose cover RAM: 0G
*BAD*gran_size: 64K chunk_size: 2G  num_reg: 10 lose cover RAM: -1G
 gran_size: 128Kchunk_size: 128Knum

Re: [PATCH] tty: Fix pty master read() after slave closes

[Mikael Pettersson]

Peter Hurley writes:
 > On 09/27/2013 01:27 PM, Peter Hurley wrote:
 > > Commit f95499c3030fe1bfad57745f2db1959c5b43dca8,
 > >n_tty: Don't wait for buffer work in read() loop
 > > creates a race window which can cause a pty master read()
 > > to miss the last pty slave write(s) and return -EIO instead,
 > > thus signalling the pty slave is closed. This can happen when
 > > the pty slave is written and immediately closed but before the
 > > tty buffer i/o loop receives the new input; the pty master
 > > read() is scheduled, sees its read buffer is empty and the
 > > pty slave has been closed, and exits.
 > >
 > > Because tty_flush_to_ldisc() has significant performance impact
 > > for parallel i/o, rather than revert the commit, special case this
 > > condition (ie., when the read buffer is empty and the 'other' pty
 > > has been closed) and, only then, wait for buffer work to complete
 > > before re-testing if the read buffer is still empty.
 > >
 > > As before, subsequent pty master reads return any available data
 > > until no more data is available, and then returns -EIO to
 > > indicate the pty slave has closed.
 > >
 > > Reported-by: Mikael Pettersson 
 > > Signed-off-by: Peter Hurley 
 > 
 > I tested this patch with the gcc ada ACATS testsuite and got this
 > summary so all seems ok with this patch.
 > 
 >  === acats Summary ===
 > # of expected passes 805
 > # of unexpected failures 0
 > 
 > ...
 > 
 >  === acats Summary ===
 > # of expected passes 772
 > # of unexpected failures 0
 > 
 > ...
 > 
 >  === acats Summary ===
 > # of expected passes 743
 > # of unexpected failures 0
 > 
 > Mikael,
 > 
 > I'd appreciate if you could re-test with this patch and
 > confirm the issue is fixed.

I did a big pile of gcc bootstrap + regression test runs today with
this patch, and everything looks good.  Thus:

Tested-by: Mikael Pettersson 

Thanks,

/Mikael
--
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/

[REGRESSION][BISECTED] 3.12-rc "n_tty: Don't wait for buffer work in read() loop" patch breaks gcc's testsuite

[Mikael Pettersson]

With 3.12-rc[12] I see unexpected failures in gcc's Ada acats testsuite, e.g.

=== acats tests ===
FAIL:   a83009b
FAIL:   c37209a
FAIL:   c45531e
FAIL:   c45614a
FAIL:   c67005d
FAIL:   c730a01
FAIL:   c74302b
FAIL:   cc3004a
FAIL:   cd2a24j
FAIL:   cd2a53a
FAIL:   cxa3001
FAIL:   cxf3a07
FAIL:   cxf3a08

=== acats Summary ===
# of expected passes2307
# of unexpected failures13
Native configuration is x86_64-unknown-linux-gnu

The exact failures vary from run to run, but some failures always occur on my
x86_64 machines, and all three open gcc branches (trunk, 4.8, 4.7) are affected.
With a 3.11 kernel the acats testsuite is always clean.

A bisection identified:

>From f95499c3030fe1bfad57745f2db1959c5b43dca8 Mon Sep 17 00:00:00 2001
From: Peter Hurley 
Date: Sat, 15 Jun 2013 13:14:29 +
Subject: n_tty: Don't wait for buffer work in read() loop

User-space read() can run concurrently with receiving from device;
waiting for receive_buf() to complete is not required.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 
---
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index fe1c399..a6eea30 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1724,7 +1724,6 @@ static inline int input_available_p(struct tty_struct 
*tty, int amt)
 {
struct n_tty_data *ldata = tty->disc_data;
 
-   tty_flush_to_ldisc(tty);
if (ldata->icanon && !L_EXTPROC(tty)) {
if (ldata->canon_head != ldata->read_tail)
return 1;

as the culprit.  Reverting that from 3.12-rc2 eliminates the acats failures
and brings the gcc testsuite results to what one gets with 3.11.

I can't pretend to understand exactly what goes wrong, suffice it to say that
the gcc testsuite harness uses a combination of shell, expect, and tcl.  I
suspect ptys are also involved.

To repeat, bootstrap a recent gcc 4.8 snapshot w/ ada in --enable-languages,
then run the test suite with "make -j6 -k check; make mail-report.log".
(Adjust -jN as appropriate, but -j6 is what I'm using on my quad-core i7s.)

Please consider reverting or fixing this patch.

/Mikael
--
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: [3.12-rc1 regression] [BISECTED] X fails to start on Latitude E6510 w/ NOUVEAU DRM driver

[Mikael Pettersson]

I wrote:
 > Dell Latitude E6510, CONFIG_DRM_NOUVEAU, 64-bit Fedora 17 user-space, Xorg 
 > drivers, and
 > 
 > 01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev 
 > a2).
 > 
 > With 3.11 X starts fine, with 3.12-rc1 it fails with the following in 
 > Xorg.0.log:
 > 
 > ...
 > [56.819] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
 > [56.842] (II) Module nouveau: vendor="X.Org Foundation"
 > [56.842]compiled for 1.12.2, module version = 0.0.16
 > [56.842]Module class: X.Org Video Driver
 > [56.842]ABI class: X.Org Video Driver, version 12.0
 > [56.842] (II) NOUVEAU driver 
 > [56.842] (II) NOUVEAU driver for NVIDIA chipset families :
 > [56.842]RIVA TNT(NV04)
 > [56.842]RIVA TNT2   (NV05)
 > [56.842]GeForce 256 (NV10)
 > [56.842]GeForce 2   (NV11, NV15)
 > [56.842]GeForce 4MX (NV17, NV18)
 > [56.842]GeForce 3   (NV20)
 > [56.842]GeForce 4Ti (NV25, NV28)
 > [56.842]GeForce FX  (NV3x)
 > [56.842]GeForce 6   (NV4x)
 > [56.842]GeForce 7   (G7x)
 > [56.842]GeForce 8   (G8x)
 > [56.842]GeForce GTX 200 (NVA0)
 > [56.842]GeForce GTX 400 (NVC0)
 > [56.842] (--) using VT number 7
 > 
 > [56.845] drmOpenDevice: node name is /dev/dri/card0
 > [56.845] drmOpenDevice: open result is 9, (OK)
 > [56.845] drmOpenByBusid: Searching for BusID pci::01:00.0
 > [56.845] drmOpenDevice: node name is /dev/dri/card0
 > [56.845] drmOpenDevice: open result is 9, (OK)
 > [56.845] drmOpenByBusid: drmOpenMinor returns 9
 > [56.845] drmOpenByBusid: drmGetBusid reports pci::01:00.0
 > [56.845] (EE) [drm] failed to open device
 > [56.845] (EE) No devices detected.
 > 
 > With 3.11 one instead sees:
 > 
 > ...
 > [33.879] drmOpenByBusid: drmOpenMinor returns 9
 > [33.879] drmOpenByBusid: drmGetBusid reports pci::01:00.0
 > [33.879] (II) [drm] nouveau interface version: 1.1.1
 > [33.879] (II) Loading sub module "dri"
 > ...
 > 
 > There are no messages in the kernel's log that indicate any problem.
 > 
 > stracing xinit shows:
 > 
 > 964   open("/dev/dri/card0", O_RDWR)= 9
 > 964   write(0, "[  1120.365] ", 13) = 13
 > 964   write(0, "drmOpenDevice: open result is 9,"..., 38) = 38
 > 964   write(0, "[  1120.365] ", 13) = 13
 > 964   write(0, "drmOpenByBusid: drmOpenMinor ret"..., 39) = 39
 > 964   ioctl(9, 0xc0106407, 0x7fffda0d4800) = 0
 > 964   ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0
 > 964   ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0
 > 964   write(0, "[  1120.365] ", 13) = 13
 > 964   write(0, "drmOpenByBusid: drmGetBusid repo"..., 53) = 53
 > 964   ioctl(9, 0xc0086420, 0x7fffda0d4870) = -1 EINVAL (Invalid argument)
 > 964   fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660, 
 > st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0, 
 > st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35, 
 > st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0
 > 964   fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660, 
 > st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0, 
 > st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35, 
 > st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0
 > 964   close(9)  = 0
 > 964   write(0, "[  1120.366] ", 13) = 13
 > 964   write(0, "(EE) [drm] failed to open device"..., 33) = 33
 > 
 > So it looks like that ioctl 0xc0086420 is the culprit.
 > 
 > Any ideas?  I may have time to try a bisection tomorrow.

The bisection identified:

>From 7c510133d93dd6f15ca040733ba7b2891ed61fd1 Mon Sep 17 00:00:00 2001
>From: Daniel Vetter 
>Date: Thu, 08 Aug 2013 13:41:21 +
>Subject: drm: mark context support as a legacy subsystem
>
>So after a lot of digging around in git histories it looks like this
>has only ever be used by dri1 render clients. Hence we can fully
>disable the entire thing for modesetting drivers and so greatly reduce
>the attack surface for potential exploits (or at least tools like
>trinity ...).
>
>Also add the drm_legacy prefix for functions which are called from
>common code. To further reduce the impact on common code also extract
>all the ctx release handling into a function (instead of only
>releasing individual handles) and make ctxbitmap_cleanup return void -
>it can never fail.
>
>Reviewed-by: Eric Anholt 
>Signed-off-by: Daniel Vetter 
>Signed-off-by: Dave Airlie 

as the culprit.  Reverting it from 3.12-rc1 allows X to start on this machine.

The issue seems driver dependent, as another Fedora 17 machine of mine
with Radeon graphics works fine with vanilla 3.12-rc1.
--
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  ht

[3.12-rc1 regression] X fails to start on Latitude E6510 w/ NOUVEAU DRM driver

[Mikael Pettersson]

Dell Latitude E6510, CONFIG_DRM_NOUVEAU, 64-bit Fedora 17 user-space, Xorg 
drivers, and

01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev 
a2).

With 3.11 X starts fine, with 3.12-rc1 it fails with the following in 
Xorg.0.log:

...
[56.819] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
[56.842] (II) Module nouveau: vendor="X.Org Foundation"
[56.842]compiled for 1.12.2, module version = 0.0.16
[56.842]Module class: X.Org Video Driver
[56.842]ABI class: X.Org Video Driver, version 12.0
[56.842] (II) NOUVEAU driver 
[56.842] (II) NOUVEAU driver for NVIDIA chipset families :
[56.842]RIVA TNT(NV04)
[56.842]RIVA TNT2   (NV05)
[56.842]GeForce 256 (NV10)
[56.842]GeForce 2   (NV11, NV15)
[56.842]GeForce 4MX (NV17, NV18)
[56.842]GeForce 3   (NV20)
[56.842]GeForce 4Ti (NV25, NV28)
[56.842]GeForce FX  (NV3x)
[56.842]GeForce 6   (NV4x)
[56.842]GeForce 7   (G7x)
[56.842]GeForce 8   (G8x)
[56.842]GeForce GTX 200 (NVA0)
[56.842]GeForce GTX 400 (NVC0)
[56.842] (--) using VT number 7

[56.845] drmOpenDevice: node name is /dev/dri/card0
[56.845] drmOpenDevice: open result is 9, (OK)
[56.845] drmOpenByBusid: Searching for BusID pci::01:00.0
[56.845] drmOpenDevice: node name is /dev/dri/card0
[56.845] drmOpenDevice: open result is 9, (OK)
[56.845] drmOpenByBusid: drmOpenMinor returns 9
[56.845] drmOpenByBusid: drmGetBusid reports pci::01:00.0
[56.845] (EE) [drm] failed to open device
[56.845] (EE) No devices detected.

With 3.11 one instead sees:

...
[33.879] drmOpenByBusid: drmOpenMinor returns 9
[33.879] drmOpenByBusid: drmGetBusid reports pci::01:00.0
[33.879] (II) [drm] nouveau interface version: 1.1.1
[33.879] (II) Loading sub module "dri"
...

There are no messages in the kernel's log that indicate any problem.

stracing xinit shows:

964   open("/dev/dri/card0", O_RDWR)= 9
964   write(0, "[  1120.365] ", 13) = 13
964   write(0, "drmOpenDevice: open result is 9,"..., 38) = 38
964   write(0, "[  1120.365] ", 13) = 13
964   write(0, "drmOpenByBusid: drmOpenMinor ret"..., 39) = 39
964   ioctl(9, 0xc0106407, 0x7fffda0d4800) = 0
964   ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0
964   ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0
964   write(0, "[  1120.365] ", 13) = 13
964   write(0, "drmOpenByBusid: drmGetBusid repo"..., 53) = 53
964   ioctl(9, 0xc0086420, 0x7fffda0d4870) = -1 EINVAL (Invalid argument)
964   fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660, 
st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0, 
st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35, 
st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0
964   fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660, 
st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0, 
st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35, 
st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0
964   close(9)  = 0
964   write(0, "[  1120.366] ", 13) = 13
964   write(0, "(EE) [drm] failed to open device"..., 33) = 33

So it looke like that ioctl 0xc0086420 is the culprit.

Any ideas?  I may have time to try a bisection tomorrow.
--
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: perf_event: rdpmc self-monitoring overhead issue

[Mikael Pettersson]

Vince Weaver writes:
 > On Fri, 30 Aug 2013, Stephane Eranian wrote:
 > > >
 > > You mean that the high cost in your first example comes from the fact
 > > that you are averaging over all the iterations and not n-1 (where 1 is
 > > the first). I don't see a flag in mmap() to fault it in immediately. But
 > > why not document, that programs should touch the page once before
 > > starting any timing measurements.
 > 
 > I was just curious why perfctr didn't need to do this, but possibly
 > I'm just missing the mmap page being touched.  Though the code is pretty
 > small and I'm not seeing any such access.

perfctr's ->mmap() actively inserts the counters page into the calling
process' mm, so it's available immediately.  The other model is to wait
for the first page fault on that page before inserting it; apparently
the other performance counter frameworks do that instead.
--
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/

[3.11-rc4] Possible problem with nouveau drm driver and interrupts on Dell Latitude E6510

[Mikael Pettersson]

My Latitude E6510 has the following graphics HW:

01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev 
a2) (prog-if 00 [VGA controller])
Subsystem: Dell Latitude E6510
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at e200 (32-bit, non-prefetchable) [size=16M]
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at e000 (64-bit, prefetchable) [size=32M]
I/O ports at 7000 [size=128]
Expansion ROM at e300 [disabled] [size=512K]
Capabilities: 
Kernel driver in use: nouveau

User-space is Fedora 17.  No proprietary drivers of any kind.

Up to the 3.11-rc2 kernel I never had any problems with it.

With 3.11-rc4 I've twice so far had the following problem:

0. X has been running for a while with fvwm, a couple of xterms, emacs, 
firefox, and xclock.

1. Suddenly text scrolling in xterm or emacs becomes extremely slow and grinds 
to a halt.
   Moving the mouse (which generates interrupts) resumes the scrolling, but 
then it stops
   again unless I keep moving the mouse.

2. At this time there are no kernel messages indicating problems.

3. If I exit X then the console behaves normally.

4. If I try to start X again it paints the background of my desktop and shows 
the mouse cursor,
   but nothing else comes up and it's unresponsive to mouse or keyboard input.
   I have to press C-A-D or the power button at this point.

5. After 1. above occurs, even a warm reboot isn't enough to make X work again. 
 A full
   power-cycled reboot is needed to bring the machine back to normal.

/Mikael
--
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: CONFIG_X86_PKG_TEMP_THERMAL causes #GP fault on Core i7-740QM breaking boot

[Mikael Pettersson]

Ortwin Glück writes:
 > Hi,
 > 
 > I think the bug is already fixed in this commit:
 > 
 > f3ed0a17f0292300b3caca32d823ecd32554a667
 > 
 > Thermal: x86 package temp thermal crash

Thanks.  Although I can see that patch in git, it's NOT present in either
the linux-3.11-rc2.tar.xz or the patch-3.11-rc2.xz files.  Which is strange
since the patch was committed 8 days ago, and -rc2 was released 2 days ago.

I'm assuming there was a mistake when preparing this -rc2 snapshot, but if
the -rc3 snapshot also differs from git I'll alert Linus.

/Mikael
--
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/

CONFIG_X86_PKG_TEMP_THERMAL causes #GP fault on Core i7-740QM breaking boot

[Mikael Pettersson]

3.11-rc1 and -rc2 refuse to boot on my Dell Latitude E6510 
(Intel Core i7-740QM processor) due to __rdmsr_on_cpu throwing
a #GP fault.

Being a laptop it doesn't have a good way to log early boot
messages, so the following was typed in by hand:

serio...
mousedev...
rtc_cmos...
general protection fault:  [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-rc2 #1
Hardware name: Dell Inc. Latitude E6510/0N5KHN, BIOS A09 05/26/2011
task: 814d1440 ti: 814c task.ti: 814c
RIP: 0010:[]  [] __rdmsr_on_cpu+0x25/0x40
RSP: :88012fc03f70  EFLAGS: 00010046
RAX:  RBX: 88012b083c80 RCX: 01b1
RDX:  RSI: 88012b083ce0 RDI: 88012b083cd8
RBP:  R08:  R09: 
R10:  R11:  R12: 88012fc03f78
R13: 814c1fd8 R14:  R15: 814c1fd8
FS:  () GS:88012fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 88012000 CR3: 014cc000 CR4: 07f0
Stack:
 8108b5fd 88012fc03f78 88012fc03f78 814c1fd8
  814c1fd8 81027272 
 81382677 814c1ea8    0202
Call Trace:
 
 [] ? generic_sml_call_function_single_interrupt+0xad/0x120
 [] ? smp_call_function_single_interrupt+0x22/0x40
 [] ? call_function_single_interrupt+0x67/0x70
 
 [] ? idle_notifier_register+0x10/0x10
 [] ? default_idle+0x15/0xb0
 [] ? cpu_startup_entry+0x7d/0x200
 [] ? start_kernel+0x346/0x351
 [] ? repair_env_strings+0x59/0x59
Code: 90 90 90 90 90 90 48 8b 47 10 48 8d 77 08 65 8b 14 25 1c b0 00 00 48 85 c0
 74 0e 48 63 d2 48 89 c6 48 03 34 d5 a0 11 52 81 8b 0f <0f> 32 48 c1 e2 20 89 c0
 48 09 c2 89 16 48 c1 ea 20 89 56 04 c3
RIP  [] __rdmsr_on_cpu+0x25/0x40
 RSP 
---[ end trace ... ]---
Kernel panic - not syncing: Fatal exception in interrupt

Looks like it's trying to read MSR 0x1B1, IA32_PACKAGE_THERM_STATUS,
and my i7-740QM doesn't like that.

Disabling CONFIG_X86_PKG_TEMP_THERMAL allows the kernel to boot again.

/Mikael
--
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: [3.11-rc1 regression] ext4_evict_inode triggers warn_slowpath_common on sparc64

[Mikael Pettersson]

Theodore Ts'o writes:
 > On Fri, Jul 19, 2013 at 07:29:25PM +0200, Mikael Pettersson wrote:
 > > I keep getting the following warning with 3.11-rc1 on sparc64:
 > > 
 > > [ cut here ]
 > > WARNING: CPU: 1 PID: 8174 at fs/ext4/inode.c:230 
 > > ext4_evict_inode+0x1f0/0x448()
 > > Modules linked in: sunrpc af_packet ipv6 hid_generic snd_ali5451 
 > > snd_ac97_codec snd_seq snd_seq_device snd_pcm tg3 snd_timer flash ohci_pci 
 > > hwmon snd soundcore ptp evdev sg i2c_ali1535 ohci_hcd pps_core 
 > > snd_page_alloc i2c_core ac97_bus sr_mod cdrom pata_ali libata
 > > CPU: 1 PID: 8174 Comm: xgcc Not tainted 3.11.0-rc1 #1
 > > Call Trace:
 > >  [004537b0] warn_slowpath_common+0x4c/0x64
 > >  [00540d78] ext4_evict_inode+0x1f0/0x448
 > >  [004f3938] evict+0xb8/0x190
 > >  [004e99bc] do_unlinkat+0xf4/0x160
 > >  [00406174] linux_sparc_syscall32+0x34/0x40
 > > ---[ end trace cd72b9e3e68d89e4 ]---
 > > 
 > > The Comm varies, but the call trace always looks like that.  Happens a 
 > > couple
 > > of times per day, so far.  No other ill effects observed.  Didn't happen 
 > > in 3.10
 > > or older kernels.
 > 
 > The fix, commit 822dbba33458cd6ad is already in Linus's tree, and will
 > be included in -rc2.
 > 
 > Note that this can cause memory corruption caused by a use-after-free.
 > I've not noticed a problem in my personal testing, but it's been
 > reported to me that with stress testing (using memory cgroups amonng
 > other things) and the system wedged when the machine was rebooted
 > after the tests were completed, and it only came back after the
 > watchdog timer fired.  The fix up was one of the first things which
 > Linus pulled after releasing -rc1, so you can merge 47188d39b5de to
 > get the fixes.

Thanks!  Installing -rc2 today..

/Mikael
--
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/

[3.11-rc1 regression] ext4_evict_inode triggers warn_slowpath_common on sparc64

[Mikael Pettersson]

I keep getting the following warning with 3.11-rc1 on sparc64:

[ cut here ]
WARNING: CPU: 1 PID: 8174 at fs/ext4/inode.c:230 ext4_evict_inode+0x1f0/0x448()
Modules linked in: sunrpc af_packet ipv6 hid_generic snd_ali5451 snd_ac97_codec 
snd_seq snd_seq_device snd_pcm tg3 snd_timer flash ohci_pci hwmon snd soundcore 
ptp evdev sg i2c_ali1535 ohci_hcd pps_core snd_page_alloc i2c_core ac97_bus 
sr_mod cdrom pata_ali libata
CPU: 1 PID: 8174 Comm: xgcc Not tainted 3.11.0-rc1 #1
Call Trace:
 [004537b0] warn_slowpath_common+0x4c/0x64
 [00540d78] ext4_evict_inode+0x1f0/0x448
 [004f3938] evict+0xb8/0x190
 [004e99bc] do_unlinkat+0xf4/0x160
 [00406174] linux_sparc_syscall32+0x34/0x40
---[ end trace cd72b9e3e68d89e4 ]---

The Comm varies, but the call trace always looks like that.  Happens a couple
of times per day, so far.  No other ill effects observed.  Didn't happen in 3.10
or older kernels.
--
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] lib: One less subtraction in binary search iterations.

[Mikael Pettersson]

Vineet Gupta writes:
 > On 07/09/2013 09:21 AM, Wedson Almeida Filho wrote:
 > > On Sat, Jul 6, 2013 at 9:59 PM, Joe Perches  wrote:
 > >>
 > >> Not correct.
 > >>
 > >>>   while (start < end) {
 > >>> - size_t mid = start + (end - start) / 2;
 > >>> + size_t mid = (start + end) / 2;
 > >>
 > >> size_t start = 0x8000;
 > >> size_t end   = 0x8001;
 > > 
 > > Good point, they aren't equivalent in all cases.
 > > 
 > > For the overflow to happen though, we need an array with at least
 > > N/2+1 entries, where N is the address space size. The array wouldn't
 > > fit in addressable memory if the element size is greater than 1, so
 > > this can only really happen when the element size is 1. Even then, it
 > > would require the kernel range to be greater than half of all
 > > addressable memory, and allow an allocation taking that much memory. I
 > > don't know all architectures where linux runs, but I don't think such
 > > configuration is likely to exist.
 > > 
 > 
 > It does. In ARC port (arch/arc), the untranslated address space starts at
 > 0x8000_ and this is where kernel is linked at. So all ARC kernel 
 > addresses
 > (code/data) lie in that range. This means you don't need special corner case 
 > for
 > this trip on ARC - it will break rightaway - unless I'm missing something.

start and end aren't addresses but array indices relative to 'base'.
So even on ARC you should be safe, as long as no array has SIZE_MAX/2
or more elements.

I'm however far from convinced this micro-optimization is worth the
obvious source code quality reduction.  Surely the eliminated subtraction
is in the noise compared to the multiplies, indirect function calls,
and memory dereferences (in the cmp functions)?

It should be possible to eliminate the multiplies, since no array can
cross the -1/0 address boundary.  But even that is questionable: does
anyone have perf data showing that bsearch performance is a problem?
--
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] tty/vt: Return EBUSY if deallocating VT1 and it is busy

[Mikael Pettersson]

Ross Lagerwall writes:
 > Commit 421b40a6286e ("tty/vt: Fix vc_deallocate() lock order") changed
 > the behavior when deallocating VT 1.  Previously if trying to
 > deallocate VT1 and it is busy, we would return EBUSY.  The commit
 > changed this to return 0 (success).
 > 
 > This commit restores the old behavior.
 > 
 > Signed-off-by: Ross Lagerwall 

This solves the VT blanking regression I've seen with the 3.10-rc
kernels.

Tested-by: Mikael Pettersson 

 > ---
 > On 06/14/2013 05:35 PM, Greg KH wrote:
 > > p.s. In the future, please cc: the people who handled the patch you are
 > > asking about, otherwise stuff like this often gets missed in the noise
 > > of lkml.
 > 
 > Yes, sorry about that.  I only remembered after I sent the email.
 > 
 >  drivers/tty/vt/vt_ioctl.c | 5 +
 >  1 file changed, 1 insertion(+), 4 deletions(-)
 > 
 > diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
 > index fc2c06c..2bd78e2 100644
 > --- a/drivers/tty/vt/vt_ioctl.c
 > +++ b/drivers/tty/vt/vt_ioctl.c
 > @@ -289,13 +289,10 @@ static int vt_disallocate(unsigned int vc_num)
 >  struct vc_data *vc = NULL;
 >  int ret = 0;
 >  
 > -if (!vc_num)
 > -return 0;
 > -
 >  console_lock();
 >  if (VT_BUSY(vc_num))
 >  ret = -EBUSY;
 > -else
 > +else if (vc_num)
 >  vc = vc_deallocate(vc_num);
 >  console_unlock();
 >  
 > -- 
 > 1.8.3.1
 > 
 > --
 > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 > the body of a message to majord...@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html
 > Please read the FAQ at  http://www.tux.org/lkml/
 > 
--
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] tty: Fix transient pty write() EIO

[Mikael Pettersson]

Peter Hurley writes:
 > Commit 699390354da6c258b65bf8fa79cfd5feaede50b6
 > ('pty: Ignore slave pty close() if never successfully opened')
 > introduced a bug with ptys whereby a write() in parallel with an
 > open() on an existing pty could mistakenly indicate an I/O error.
 > 
 > Only indicate an I/O error if the condition on open() actually exists.
 > 
 > Reported-by: Markus Trippelsdorf 
 > Signed-off-by: Peter Hurley 

I've tested this for two days on 3.9.0 (where the bug reproduces
easily for me, for some reason I can't seem to trigger it with
3.10-rc5), and with the patch I no longer see the bug.

Tested-by: Mikael Pettersson 

 > ---
 >  drivers/tty/pty.c | 13 +
 >  1 file changed, 5 insertions(+), 8 deletions(-)
 > 
 > diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
 > index 9c2f1bc..dd08d3d 100644
 > --- a/drivers/tty/pty.c
 > +++ b/drivers/tty/pty.c
 > @@ -238,14 +238,9 @@ static void pty_flush_buffer(struct tty_struct *tty)
 >  
 >  static int pty_open(struct tty_struct *tty, struct file *filp)
 >  {
 > -int retval = -ENODEV;
 > -
 >  if (!tty || !tty->link)
 > -goto out;
 > -
 > -set_bit(TTY_IO_ERROR, &tty->flags);
 > +return -ENODEV;
 >  
 > -retval = -EIO;
 >  if (test_bit(TTY_OTHER_CLOSED, &tty->flags))
 >  goto out;
 >  if (test_bit(TTY_PTY_LOCK, &tty->link->flags))
 > @@ -256,9 +251,11 @@ static int pty_open(struct tty_struct *tty, struct file 
 > *filp)
 >  clear_bit(TTY_IO_ERROR, &tty->flags);
 >  clear_bit(TTY_OTHER_CLOSED, &tty->link->flags);
 >  set_bit(TTY_THROTTLED, &tty->flags);
 > -retval = 0;
 > +return 0;
 > +
 >  out:
 > -return retval;
 > +set_bit(TTY_IO_ERROR, &tty->flags);
 > +return -EIO;
 >  }
 >  
 >  static void pty_set_termios(struct tty_struct *tty,
 > -- 
 > 1.8.1.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: Strange intermittent EIO error when writing to stdout since v3.8.0

[Mikael Pettersson]

Peter Hurley writes:
 > Based on the other reports from Mikael and David, I suspect this problem
 > may have to do with my commit 699390354da6c258b65bf8fa79cfd5feaede50b6:
 > 
 >pty: Ignore slave pty close() if never successfully opened
 > 
 > This commit poisons the pty under certain error conditions that may
 > occur from parallel open()s (or parallel close() with pending write()).
 > 
 > It's unclear to me which error condition is triggered and how user-space
 > got an open file descriptor but that seems the most likely. Is the problem
 > reproducible enough that a debug patch would likely trigger?

In my case the problem occurred frequently enough that I've been forced
to change my build procedures to avoid it.  I'd welcome a debug patch.
--
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: Strange intermittent EIO error when writing to stdout since v3.8.0

[Mikael Pettersson]

Markus Trippelsdorf writes:
 > Since v3.8.0 several people reported intermittent IO errors that happen
 > during high system load while using "emerge" under Gentoo:
 > ...
 >   File "/usr/lib64/portage/pym/portage/util/_eventloop/EventLoop.py", line 
 > 260, in iteration
 > if not x.callback(f, event, *x.args):
 >   File "/usr/lib64/portage/pym/portage/util/_async/PipeLogger.py", line 99, 
 > in _output_handler
 > stdout_buf[os.write(stdout_fd, stdout_buf):]
 >   File "/usr/lib64/portage/pym/portage/__init__.py", line 246, in __call__
 > rval = self._func(*wrapped_args, **wrapped_kwargs)
 > OSError: [Errno 5] Input/output error
 > 
 > Basically 'emerge' just writes the build output to stdout in a loop:
 > ...
 > def _output_handler(self, fd, event):
 > 
 >background = self.background
 >stdout_fd = self.stdout_fd
 >log_file = self._log_file 
 > 
 >while True:
 >buf = self._read_buf(fd, event)
 > 
 >if buf is None:
 ># not a POLLIN event, EAGAIN, etc...
 >break
 > 
 >if not buf:
 ># EOF
 >self._unregister()
 >self.wait()
 >break
 > 
 >else:
 >if not background and stdout_fd is not None:
 >failures = 0
 >stdout_buf = buf
 >while stdout_buf:
 >try:
 >stdout_buf = \
 >
 > stdout_buf[os.write(stdout_fd, stdout_buf):]
 >except OSError as e:
 >if e.errno != errno.EAGAIN:
 >raise
 >  ...
 > 
 > see: https://bugs.gentoo.org/show_bug.cgi?id=459674
 > 
 > (A similar issue also happens when building Firefox since v3.8.0. But
 > because Firefox's build process doesn't raise an exception it just dies
 > at random points without giving a clue.)
 > 
 > Now the question is: Could this be a kernel bug? Maybe in the TTY layer?
 > 
 > Unfortunately the issue is not easily reproducible and a git-bisect is
 > out of the question.

I'm seeing a similar regression.  I do a lot of gcc bootstraps and regression
test suite runs, and for the bootstraps I do

make -jN bootstrap |& tee build-log

(tcsh syntax, adjust as appropriate for your preferred shell) to get a complete
log for later inspection in case of error.  N is typically the number of cores
or threads on the machine, e.g. -j8 on my Core-i7 IVB.

Up to the 3.7 kernel this never had any problems.  Starting with the 3.8 kernel,
or possibly 3.9-rc1, this usually dies at some random point with an EIO.

I haven't had time to bisect it.

/Mikael
--
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: Linux 3.10-rc4

[Mikael Pettersson]

Randy Dunlap writes:
 > On 06/02/13 01:45, Linus Torvalds wrote:
 > > 
 > > Another week, another -rc. But this time (at least for now) only as a git 
 > > tree - for people actually using the tar-balls and patches, I apologize, 
 > > but I'm a complete moron, and didn't install kup, its perl dependencies, 
 > > and my kup release scripts on the pixel before the trip.
 > > 
 > > And while I can read and write email, and git is fine with just a few 
 > > (flaky) kB/s internet throughput I have access to right now, installing 
 > > the perl packages etc seems to be a pipe dream.
 > > 
 > > I suspect nobody actually uses the tar-balls and patches, since git is so 
 > > much more convenient and efficient, so hopefully nobody cares. But I'll 
 > > rectify the lack eventually. Hopefully within a day or two, as my "yum 
 > > update" actually completes. And if not in a day or two, then when I get 
 > > back home a few days later.
 > 
 > I still use tarballs and patches, fwiw.

As do I.  For this one time the lack of a patch file is no big deal, but
please don't discontinue them permanently.

/Mikael
--
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: A bug about system call on ARM

[Mikael Pettersson]

Wang, Yalin writes:
 > Hi  
 > 
 > I have download the latest linux kernel code  3.9.4
 > And Compare with  3.4.0 kernel .
 > 
 > It seems there is no change for this part ,
 > So it will still happen .
 > Does anyone know who is responsible for  arm arch part kernel code ?

A quick look in MAINTAINNERS would have told you:

ARM PORT
...
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)

Please direct ARM-specific questions to that list.
--
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: X86 fpu registers in a signal handler's ucontext

[Mikael Pettersson]

Warlich, Christof writes:
 > richard -rw- weinberger  writes:
 > > Are you telling us that Ubuntu shipped the wrong header file?
 > 
 > Hmm - at least I still don't know how to get the right definition
 > of uc_mcontext (with eglibc-2.13 on Ubuntu 11.10) ...
 > 
 > If I include both signal.h and asm-generic/ucontext.h, gcc reports
 > this error:
 > 
 > /usr/include/asm-generic/ucontext.h:4:8: error: redefinition of 'struct 
 > ucontext'
 > /usr/include/i386-linux-gnu/sys/ucontext.h:119:16: error: previous 
 > definition of 'struct ucontext'
 > 
 > Thus, signal.h obviously includes the wrong i386-linux-gnu/sys/ucontext.h
 > defining uc_mcontext to be of type mcontext_t.
 > 
 > So is it still me doing something wrong or or _did_ Ubuntu ship
 > the wrong header files?

#include 
#include 

has worked for my SIGFPE handlers on Linux for the last 10+ years on various 
distros
and target architectures.

Can we stop this thread now?  There is no _kernel_ issue here.
--
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: X86 fpu registers in a signal handler's ucontext

[Mikael Pettersson]

Warlich, Christof writes:
 > Mikael Pettersson  writes:
 > > Write to the fpstate ->mxcsr and ->swd fields in the sigaction handler's 
 > > uc_mcontext.
 > 
 > To me, "sigaction handler's uc_mcontext" sounds like userspace, which really 
 > confuses me:
 > Even in most recent glibc-2.17, uc_mcontext is of type mcontext_t, which us 
 > defined as:
 > 
 > typedef struct {
 >   gregset_t gregs;
 >   fpregset_t fpregs;
 > } mcontext_t;
 > 
 > typedef struct fpregset {
 > union {
 >  struct fpchip_state {
 >  int state[27];
 >  int status;
 >  } fpchip_state;
 >  struct fp_emul_space {
 >  char fp_emul[246];
 >  char fp_epad[2];
 >  } fp_emul_space;
 >  int f_fpregs[62];
 > } fp_reg_set;
 > long int f_wregs[33];
 > } fpregset_t;
 > 
 > So there is no fpstate whatsoever.

You're looking at the wrong header: glibc-2.17/sysdeps/i386/sys/ucontext.h is 
legacy SVR4.
Instead look at glibc-2.17/sysdeps/unix/sysv/linux/x86/sys/ucontext.h.

(If the old one got installed on your system then something there is seriously 
wrong.)

The only quirk is that to access ->mxcsr on 32-bit you have to check if the 
high half of
->status contains FXSR_MAGIC and if so you need to cast that pointer to struct 
_fpstate*.
--
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: X86 fpu registers in a signal handler's ucontext

[Mikael Pettersson]

Warlich, Christof writes:
 > Andi Kleen  writes:
 > > The FP registers are restored lazily, but the state for this is kept in
 > > the kernel.
 > 
 > I'm not sure if I understand "lazily" in this context: Do you mean that FP
 > registers _are_ restored within the kernel, but _not_ from a (possibly 
 > modified)
 > ucontext of a userspace signal handler? If so, do you know a reason why the 
 > GP
 > registers are so nicely restored from userspace, but not the FP registers?
 >  
 > > One easy way may be to catch the FPU exception too and clear from there?
 > 
 > Hmm - I _do_ catch SIGFPE in my userspace signal handler, but I obviously
 > can't clear the FP exceptions from there. This, together with your answer
 > so far, makes me conclude that there may be no way to achieve my goal from
 > userspace, right :-(?

Write to the fpstate ->mxcsr and ->swd fields in the sigaction handler's 
uc_mcontext.
--
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] [PPC64] 3.9-rc3 crashes really early during boot on G5

[Mikael Pettersson]

Kernels up to an including 3.8.0 work Ok on my old dual-CPU G5, but
3.9-rc3 refuses to boot.  After selecting it in yaboot's menu I see

Please wait, loading kernel
Elf64 kernel loaded
Loading ramdisk
ramdisk loaded

Invalid memory access at SRR0: .0380 SRR1: 9000.00081000

and then I'm dropped into some primitive open firmware monitor.
This is 100% repeatable.

.config appended below.

/Mikael

#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 3.9.0-rc3 Kernel Configuration
#
CONFIG_PPC64=y

#
# Processor support
#
CONFIG_PPC_BOOK3S_64=y
# CONFIG_PPC_BOOK3E_64 is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_CELL_CPU is not set
CONFIG_POWER4_CPU=y
# CONFIG_POWER5_CPU is not set
# CONFIG_POWER6_CPU is not set
# CONFIG_POWER7_CPU is not set
CONFIG_PPC_BOOK3S=y
CONFIG_POWER3=y
CONFIG_POWER4=y
# CONFIG_TUNE_CELL is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
# CONFIG_VSX is not set
# CONFIG_PPC_ICSWX is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_64=y
CONFIG_PPC_MM_SLICES=y
CONFIG_PPC_HAVE_PMU_SUPPORT=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
# CONFIG_PPC_DOORBELL is not set
CONFIG_64BIT=y
CONFIG_WORD_SIZE=64
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NR_IRQS=256
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
# CONFIG_PPC_UDBG_16550 is not set
CONFIG_GENERIC_TBSYNC=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_EPAPR_BOOT is not set
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_FHANDLE=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set
CONFIG_GENERIC_TIME_VSYSCALL_OLD=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
# CONFIG_AIO is not set
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_JUMP_LABEL=y
# CONFIG_HA

Re: [PATCH 02/11] ARM: samsung: fix assembly syntax for new gas

[Mikael Pettersson]

Russell King - ARM Linux writes:
 > On Thu, Feb 14, 2013 at 02:49:18PM +0100, Arnd Bergmann wrote:
 > > Recent assembler versions complain about extraneous
 > > whitespace inside [] brackets. This fixes all of
 > > these instances for the samsung platforms. We should
 > > backport this to all kernels that might need to
 > > be built with new binutils.
 > 
 > I hope that's also been reported as a bug to the binutils people.

See PR gas/14887, a post binutils-2.23.1 regression which seems
to be fixed on trunk but not on 2.23 branch.
--
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: container-of Implementation

[Mikael Pettersson]

Schrober writes:
 > Hi,
 > 
 > I wondered why the container_of implementation is so complicated.
 > 
 > #define container_of(ptr, type, member) ({   \
 >  const typeof( ((type *)0)->member ) *__mptr = (ptr);\
 >  (type *)( (char *)__mptr - offsetof(type,member) );})
 > 
 > isn't the __mptr not unnecessary? Why not following version?
 > 
 > #define container_of(ptr, type, member) \
 > ((type *)((char *)(ptr) - offsetof(type, member)))

Compile-time type checking.  The first version requires ptr to be
assignment-compatible with the type of the struct member, the second
version accepts random junk for ptr.
--
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/3] kcmp: enable the kcmp syscall when C/R is enabled

[Mikael Pettersson]

Alexander Kartashov writes:
 > --- a/arch/arm/kernel/calls.S
 > +++ b/arch/arm/kernel/calls.S
 > @@ -387,7 +387,7 @@
 >  /* 375 */   CALL(sys_setns)
 >  CALL(sys_process_vm_readv)
 >  CALL(sys_process_vm_writev)
 > -CALL(sys_ni_syscall)/* reserved for sys_kcmp */
 > +CALL(sys_kcmp)  /* reserved for sys_kcmp */

The /* reserved for sys_kcmp */ comment is now obsolete and should be removed.
--
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: [3.7.0 regression] rt2x00lib_probe_dev: Error - Failed to initialize hw

[Mikael Pettersson]

Gertjan van Wingerde writes:
 > Mikael, Devendra,
 > 
 > On Mon, Dec 17, 2012 at 1:59 PM, devendra.aaru  
 > wrote:
 > > On Mon, Dec 17, 2012 at 7:22 AM, Mikael Pettersson  wrote:
 > >> devendra.aaru writes:
 > >>  > On Mon, Dec 17, 2012 at 5:51 AM, Mikael Pettersson  
 > >> wrote:
 > >>  > > I just updated an old 1st gen AMD64 laptop from kernel 3.6.0 to 
 > >> 3.7.0,
 > >>  > > Fedora 15 user-space, and was greeted by the following kernel 
 > >> warning:
 > >>  > >
 > >>  > > WARNING: at net/wireless/core.c:389 wiphy_register+0x5c3/0x600 
 > >> [cfg80211]()
...
 > This is caused by the introduction of interface combinations. Helmut
 > Schaa has already submitted a patch to fix this, but this has
 > unfortunately not ended up in 3.7. I'm confident it will end up in one
 > of the upcoming 3.7.x stable releases.
 > 
 > See http://marc.info/?l=linux-wireless&m=135478723823922&w=2 for the
 > patch submitted by Helmut.

That patch fixes the problem.  Thanks.

/Mikael
--
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: [3.7.0 regression] rt2x00lib_probe_dev: Error - Failed to initialize hw

[Mikael Pettersson]

devendra.aaru writes:
 > On Mon, Dec 17, 2012 at 5:51 AM, Mikael Pettersson  wrote:
 > > I just updated an old 1st gen AMD64 laptop from kernel 3.6.0 to 3.7.0,
 > > Fedora 15 user-space, and was greeted by the following kernel warning:
 > >
 > > WARNING: at net/wireless/core.c:389 wiphy_register+0x5c3/0x600 [cfg80211]()
 > 
 > I am seeing this line actually when i do vim +389 net/wireless/core.c.
 > 
 > u16 all_iftypes = 0;
 > 
 > its good if you tell us the top sha1 of yours?

It's the plain linux-3.7.tar.xz from kernel.org, no git involved.
Lines 389-390 of net/wireless/core.c are:

if (WARN_ON(c->max_interfaces < 2))
return -EINVAL;

/Mikael

 > 
 > 
 > > Hardware name: SAM#451B
 > > Modules linked in: rt2500pci(+) snd_mpu401_uart rt2x00pci snd_rawmidi 
 > > rt2x00lib sg snd_seq_device mac80211 cfg80211 amd64_agp agpgart snd 
 > > eeprom_93cx6 soundcore via_rhine mii evdev ipv6 ehci_hcd uhci_hcd sr_mod 
 > > cdrom usbcore usb_common
 > > Pid: 378, comm: modprobe Not tainted 3.7.0 #1
 > > Call Trace:
 > >  [] ? warn_slowpath_common+0x79/0xc0
 > >  [] ? wiphy_register+0x5c3/0x600 [cfg80211]
 > >  [] ? __kmalloc+0xef/0x170
 > >  [] ? ieee80211_register_hw+0x347/0x6d0 [mac80211]
 > >  [] ? rt2x00lib_probe_dev+0x53d/0x720 [rt2x00lib]
 > >  [] ? rt2x00pci_probe+0x168/0x2e4 [rt2x00pci]
 > >  [] ? pci_device_probe+0xd0/0x170
 > >  [] ? driver_probe_device+0x64/0x210
 > >  [] ? __driver_attach+0x93/0xa0
 > >  [] ? driver_probe_device+0x210/0x210
 > >  [] ? bus_for_each_dev+0x45/0x80
 > >  [] ? bus_add_driver+0x178/0x250
 > >  [] ? driver_register+0x6e/0x170
 > >  [] ? notifier_call_chain+0x44/0x60
 > >  [] ? 0xa0195fff
 > >  [] ? do_one_initcall+0x11a/0x160
 > >  [] ? sys_init_module+0x76/0x1c0
 > >  [] ? system_call_fastpath+0x16/0x1b
 > > ---[ end trace f8413f27de31929d ]---
 > > phy0 -> rt2x00lib_probe_dev: Error - Failed to initialize hw.
 > > rt2500pci: probe of :00:0c.0 failed with error -22
 > >
 > > Rebooting into 3.6.0 shows no such error, booting 3.7.0 again shows the 
 > > error,
 > > so it's completely reproducible.
 > >
 > 
 > there are lots of WARN_ON's btw, :) may be one of them triggered, but
 > please tell us the top sha1 of yours, so that the wireless dev's can
 > easily see whats' happening with the rt2x00 to trigger this :)
 > 
 > 
 > > lspci -v for the device in question:
 > >
 > > 00:0c.0 Network controller: Ralink corp. RT2500 802.11g (rev 01)
 > > Subsystem: Micro-Star International Co., Ltd. Unknown 802.11g 
 > > mini-PCI Adapter
 > > Flags: bus master, slow devsel, latency 64, IRQ 18
 > > Memory at d000 (32-bit, non-prefetchable) [size=8K]
 > > Capabilities: [40] Power Management version 2
 > > Kernel driver in use: rt2500pci
 > > Kernel modules: rt2500pci
 > >
 > > I've never actually used or configured this device (the laptop is always
 > > on wired ethernet), but thought you should know about this possible driver
 > > regression.
 > >
 > > /Mikael
 > > --
 > > 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/
 > 
--
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/

[3.7.0 regression] rt2x00lib_probe_dev: Error - Failed to initialize hw

[Mikael Pettersson]

I just updated an old 1st gen AMD64 laptop from kernel 3.6.0 to 3.7.0,
Fedora 15 user-space, and was greeted by the following kernel warning:

WARNING: at net/wireless/core.c:389 wiphy_register+0x5c3/0x600 [cfg80211]()
Hardware name: SAM#451B
Modules linked in: rt2500pci(+) snd_mpu401_uart rt2x00pci snd_rawmidi rt2x00lib 
sg snd_seq_device mac80211 cfg80211 amd64_agp agpgart snd eeprom_93cx6 
soundcore via_rhine mii evdev ipv6 ehci_hcd uhci_hcd sr_mod cdrom usbcore 
usb_common
Pid: 378, comm: modprobe Not tainted 3.7.0 #1
Call Trace:
 [] ? warn_slowpath_common+0x79/0xc0
 [] ? wiphy_register+0x5c3/0x600 [cfg80211]
 [] ? __kmalloc+0xef/0x170
 [] ? ieee80211_register_hw+0x347/0x6d0 [mac80211]
 [] ? rt2x00lib_probe_dev+0x53d/0x720 [rt2x00lib]
 [] ? rt2x00pci_probe+0x168/0x2e4 [rt2x00pci]
 [] ? pci_device_probe+0xd0/0x170
 [] ? driver_probe_device+0x64/0x210
 [] ? __driver_attach+0x93/0xa0
 [] ? driver_probe_device+0x210/0x210
 [] ? bus_for_each_dev+0x45/0x80
 [] ? bus_add_driver+0x178/0x250
 [] ? driver_register+0x6e/0x170
 [] ? notifier_call_chain+0x44/0x60
 [] ? 0xa0195fff
 [] ? do_one_initcall+0x11a/0x160
 [] ? sys_init_module+0x76/0x1c0
 [] ? system_call_fastpath+0x16/0x1b
---[ end trace f8413f27de31929d ]---
phy0 -> rt2x00lib_probe_dev: Error - Failed to initialize hw.
rt2500pci: probe of :00:0c.0 failed with error -22

Rebooting into 3.6.0 shows no such error, booting 3.7.0 again shows the error,
so it's completely reproducible.

lspci -v for the device in question:

00:0c.0 Network controller: Ralink corp. RT2500 802.11g (rev 01)
Subsystem: Micro-Star International Co., Ltd. Unknown 802.11g mini-PCI 
Adapter
Flags: bus master, slow devsel, latency 64, IRQ 18
Memory at d000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Kernel driver in use: rt2500pci
Kernel modules: rt2500pci

I've never actually used or configured this device (the laptop is always
on wired ethernet), but thought you should know about this possible driver
regression.

/Mikael
--
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: [3.7-rc5/rc6 regression] "drm/nvc0/disp: fix regression in vblank semaphore release" broke nouveau driver and mplayer

[Mikael Pettersson]

Marcin Slusarz writes:
 > On Sat, Nov 17, 2012 at 08:35:18PM +0100, Mikael Pettersson wrote:
 > > mplayer worked fine on my Dell Latitude E6510 (nVidia GT218 [NVS 3100M] 
 > > graphics)
 > > up to and including kernel 3.7-rc4. However, with 3.7-rc5 or -rc6, any 
 > > attempt to
 > > run mplayer just blanks the screen, shows some stray white pixels in the 
 > > upper left
 > > corner, kills the X server, and spews the following errors from the kernel:
 > 
 > Fix was already posted and should be merged soon.
 > 
 > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=7a259e65569bd7593ad541c84982027969ec9c45

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

[3.7-rc5/rc6 regression] "drm/nvc0/disp: fix regression in vblank semaphore release" broke nouveau driver and mplayer

[Mikael Pettersson]

mplayer worked fine on my Dell Latitude E6510 (nVidia GT218 [NVS 3100M] 
graphics)
up to and including kernel 3.7-rc4. However, with 3.7-rc5 or -rc6, any attempt 
to
run mplayer just blanks the screen, shows some stray white pixels in the upper 
left
corner, kills the X server, and spews the following errors from the kernel:

nouveau E[  PGRAPH][:01:00.0] TRAP_M2MF NOTIFY
nouveau E[  PGRAPH][:01:00.0] TRAP_M2MF 00304041 43e0  06000434
nouveau  [  PGRAPH][:01:00.0]  TRAP
nouveau E[  PGRAPH][:01:00.0] ch 2 [0x001fb44000] subc 3 class 0x5039 mthd 
0x0328 data 0x
nouveau E[ PFB][:01:00.0] trapped read at 0x002001a020 on channel 
0x0001fb44 SEMAPHORE_BG/PFIFO_READ/00 reason: PAGE_NOT_PRESENT
nouveau  [   PFIFO][:01:00.0] CACHE_ERROR - Ch 2/4 Mthd 0x0068 Data 
0x
nouveau E[  PGRAPH][:01:00.0] TRAP_DISPATCH (unknown 0x0004)
nouveau  [  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb44000] subc 3 class 0x mthd 
0x0860 data 0x
nouveau E[ PFB][:01:00.0] trapped read at 0x002001a024 on channel 
0x0001fb44 PFIFO/PFIFO_READ/SEMAPHORE reason: PAGE_NOT_PRESENT
nouveau  [  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb44000] subc 3 class 0x mthd 
0x0860 data 0x
nouveau  [  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb44000] subc 3 class 0x mthd 
0x0860 data 0x
nouveau  [  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS

(this bit repeats itself for 700+ lines)

nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb44000] subc 3 class 0x mthd 
0x0860 data 0x
nouveau  [  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb44000] subc 5 class 0x mthd 
0x0860 data 0x
nouveau  [  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS

(this bit repeats itself for 30+ lines)

nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb44000] subc 5 class 0x mthd 
0x03c4 data 0x4000
nouveau  [  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb44000] subc 5 class 0x mthd 
0x03c8 data 0x
nouveau E[ PFB][:01:00.0] trapped write at 0x00 on channel 
0x0001fb44 PGRAPH/DISPATCH/GRCTX reason: DMAOBJ_LIMIT
nouveau E[  PGRAPH][:01:00.0] TRAP_DISPATCH (unknown 0x0004)
nouveau  [  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb44000] subc 5 class 0x mthd 
0x03cc data 0x4000
nouveau E[ PFB][:01:00.0] trapped write at 0x000420 on channel 
0x0001fb44 PGRAPH/DISPATCH/GRCTX reason: DMAOBJ_LIMIT
nouveau  [  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb44000] subc 3 class 0x502d mthd 
0x0860 data 0x
nouveau E[ PFB][:01:00.0] trapped write at 0x02b000 on channel 
0x0001fcb0 PGRAPH/DISPATCH/GRCTX reason: DMAOBJ_LIMIT

The error is 100% repeatable.

git bisect identified the following culprit:

11d92561c81be2f4a7af37f035e1af294b960abe is the first bad commit
commit 11d92561c81be2f4a7af37f035e1af294b960abe
Author: Kelly Doran 
Date:   Wed Nov 7 10:02:04 2012 +1000

drm/nvc0/disp: fix regression in vblank semaphore release

Signed-off-by: Kelly Doran 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Ben Skeggs 

:04 04 e539bc754b029da133f89f3bcf5bf31495cb07c5 
4e779444a976c40cb07aafefc8e6e7b1e64f092c M  drivers

I've confirmed that reverting this from -rc5 and -rc6 allows mplayer to work 
again.

User-space is Fedora 15 x86_64 w/ final updates, plus 
mplayer-1.0-0.129.20110917svn from rpmfusion.
There are no binary-only or otherwise out-of-tree kernel or X drivers anywhere 
on the machine.

Please revert or fix this breakage before kernel 3.7.0 final.

/Mikael
--
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: Hardcoded instruction causes certain features to fail on ARM platfrom due to endianness

[Mikael Pettersson]

Yangfei (Felix) writes:
 > Hi all,
 > 
 > I found that hardcoded instruction in inline asm can cause certains 
 > certain features fail to work on ARM platform due to endianness.
 > As an example, consider the following code snippet of 
 > platform_do_lowpower function from arch/arm/mach-realview/hotplug.c:
 > / *
 >  * here's the WFI
 >  */
 > asm(".word  0xe320f003\n"
 > :
 > :
 > : "memory", "cc");
 > 
 > The instruction generated from this inline asm will not work on 
 > big-endian ARM platform, such as ARM BE-8 format. Instead, an exception will 
 > be generated.
 > 
 > Here the code should be:
 > / *
 >  * here's the WFI
 >  */
 > asm("WFI\n"
 > :
 > :
 > : "memory", "cc");
 > 
 > Seems the kernel doesn't support ARM BE-8 well. I don't know why this 
 > problem happens.
 > Can anyone tell me who owns this part? I can prepare a patch then. 
 > Thanks.

Questions regarding the ARM kernel should go to the linux-arm-kernel mailing 
list
(see the MAINTAINERS file), with an optional cc: to the regular LKML.

BE-8 is, if I recall correctly, ARMv7's broken format where code and data have
different endianess.  GAS supports an ".inst" directive which is like ".word"
except the data is assumed to be code.  This matters for disassembly, and may
also be required for BE-8.

That is, just s/.word/.inst/g above and report back if that works or not.
--
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: Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

[Mikael Pettersson]

Ard Biesheuvel writes:
 > This patch adds support for the PROT_FINAL flag to
 > the mmap() and mprotect() syscalls.
 > 
 > The PROT_FINAL flag indicates that the requested set
 > of protection bits should be final, i.e., it shall
 > not be allowed for a subsequent mprotect call to
 > set protection bits that were not set already.
 > 
 > This is mainly intended for the dynamic linker,
 > which sets up the address space on behalf of
 > dynamic binaries. By using this flag, it can
 > prevent exploited code from remapping read-only
 > executable code or data sections read-write.

I can see why you might think this is a good idea, but I don't
like it for several reasons:

- If .text is mapped non-writable and final, how would a debugger
  (or any ptrace-using monitor-like application) plant a large
  number of breakpoints in a target process? Breakpoint registers
  aren't enough because (a) they're few in number, and (b) not
  all CPUs have them.

- You're proposing to give one component (the dynamic linker/
  loader) absolute power to impose new policies on all
  applications. How would an application that _deliberately_
  does something the new policies don't allow tell the dynamic
  linker or kernel to get out of its way?

This clearly changes the de-facto ABIs, and as such I think
it needs much more detailed analysis than what you've done
here.

At the very least I think this change should be opt-in, but
that would require a kernel option or sysctl, or some config
file for the user-space dynamic linker/loader.
--
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: CONFIG_EXPERT is a booby trap

[Mikael Pettersson]

Tim Shepard writes:
 > This weekend I finally figured out why the keyboard in my MacBook Pro
 > stopped working between 3.4 and 3.5.
 > 
 > When I turned on CONFIG_EXPERT it turned off CONFIG_HID_APPLE.  There
 > was no warning that selecting "Configure standard kernel features" will
 > invisibly turn off needed things elsewhere in the configuration tree.
 > 
 > Something needs to be fixed, but it's not obvious that any simple change
 > will work without causing other troubles.

"diff" the before and after .config files.  That's alerted me to unexpected
changes (not just "where did CONFIG_${foo} go?" but also "wtf is CONFIG_${bar}
doing there?") on numerous occasions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sata_promise: fix hardreset lockdep error

[Mikael Pettersson]

sata_promise's pdc_hard_reset_port() needs to serialize because it
flips a port-specific bit in controller register that's shared by
all ports. The code takes the ata host lock for this, but that's
broken because an interrupt may arrive on our irq during the hard
reset sequence, and that too will take the ata host lock. With
lockdep enabled a big nasty warning is seen.

Fixed by adding private state to the ata host structure, containing
a second lock used only for serializing the hard reset sequences.
This eliminated the lockdep warnings both on my test rig and on
the original reporter's machine.

Signed-off-by: Mikael Pettersson 
Tested-by: Adko Branil 
Cc: sta...@vger.kernel.org
---
This bug affects 2.6.32 and newer kernels.

 drivers/ata/sata_promise.c |   15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff -rupN linux-3.6-rc5/drivers/ata/sata_promise.c 
linux-3.6-rc5.sata_promise-hardreset-lockdep-fix/drivers/ata/sata_promise.c
--- linux-3.6-rc5/drivers/ata/sata_promise.c2012-09-09 16:31:11.0 
+0200
+++ linux-3.6-rc5.sata_promise-hardreset-lockdep-fix/drivers/ata/sata_promise.c 
2012-09-09 16:36:38.0 +0200
@@ -147,6 +147,10 @@ struct pdc_port_priv {
dma_addr_t  pkt_dma;
 };
 
+struct pdc_host_priv {
+   spinlock_t hard_reset_lock;
+};
+
 static int pdc_sata_scr_read(struct ata_link *link, unsigned int sc_reg, u32 
*val);
 static int pdc_sata_scr_write(struct ata_link *link, unsigned int sc_reg, u32 
val);
 static int pdc_ata_init_one(struct pci_dev *pdev, const struct pci_device_id 
*ent);
@@ -801,9 +805,10 @@ static void pdc_hard_reset_port(struct a
void __iomem *host_mmio = ap->host->iomap[PDC_MMIO_BAR];
void __iomem *pcictl_b1_mmio = host_mmio + PDC_PCI_CTL + 1;
unsigned int ata_no = pdc_ata_port_to_ata_no(ap);
+   struct pdc_host_priv *hpriv = ap->host->private_data;
u8 tmp;
 
-   spin_lock(&ap->host->lock);
+   spin_lock(&hpriv->hard_reset_lock);
 
tmp = readb(pcictl_b1_mmio);
tmp &= ~(0x10 << ata_no);
@@ -814,7 +819,7 @@ static void pdc_hard_reset_port(struct a
writeb(tmp, pcictl_b1_mmio);
readb(pcictl_b1_mmio); /* flush */
 
-   spin_unlock(&ap->host->lock);
+   spin_unlock(&hpriv->hard_reset_lock);
 }
 
 static int pdc_sata_hardreset(struct ata_link *link, unsigned int *class,
@@ -1182,6 +1187,7 @@ static int pdc_ata_init_one(struct pci_d
const struct ata_port_info *pi = &pdc_port_info[ent->driver_data];
const struct ata_port_info *ppi[PDC_MAX_PORTS];
struct ata_host *host;
+   struct pdc_host_priv *hpriv;
void __iomem *host_mmio;
int n_ports, i, rc;
int is_sataii_tx4;
@@ -1218,6 +1224,11 @@ static int pdc_ata_init_one(struct pci_d
dev_err(&pdev->dev, "failed to allocate host\n");
return -ENOMEM;
}
+   hpriv = devm_kzalloc(&pdev->dev, sizeof *hpriv, GFP_KERNEL);
+   if (!hpriv)
+   return -ENOMEM;
+   spin_lock_init(&hpriv->hard_reset_lock);
+   host->private_data = hpriv;
host->iomap = pcim_iomap_table(pdev);
 
is_sataii_tx4 = pdc_is_sataii_tx4(pi->flags);
--
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: HDD problem, software bug, bios bug, or hardware ?

[Mikael Pettersson]

Adko Branil writes:
 > After updating bios no more crashes happened, i tested it many times
 > on heavy HDD IO loads, with many kernels (including CONFIG_PREEMPT
 > kernels). But now if enable "Cool'n' Quiet" option in bios, 
 > CONFIG_PREEMPT_VOLUNTARY kernel with passed "nosmp" at boot time,
 > crashes during boot process with kernel panic, while  CONFIG_PREEMPT
 > kernlel without "nosmp" works fine  - but it is another story i think,
 > should not be related with the crashes when it was old bios, and i
 > think it is probably "nosmp" the reason. (i have never changed cpu
 > frequency of this cpu at all) When "Cool'n' Quiet" is disabled, the
 > system works perfectly adequately with all kind of kernels i tried.
 > Except that this warning message in dmesg still appears (if it is
 > problem at all). I put here this message for "nosmp" case as well,
 > kernel is 3.5.2:
 > 
 > [    1.912494] =
 > [    1.912494] [ INFO: inconsistent lock state ]
 > [    1.912494] 3.5.2 #4 Not tainted
 > [    1.912494] -
 > [    1.912494] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
 > [    1.912494] swapper/0/1 [HC1[1]:SC1[1]:HE0:SE0] takes:
 > [    1.912494]  (&(&host->lock)->rlock){?.+...}, at: [] 
 > ata_bmdma_interrupt+0x27/0x1d0
 > [    1.912494] {HARDIRQ-ON-W} state was registered at:
 > [    1.912494]   [] __lock_acquire+0x61b/0x1af0
 > [    1.912494]   [] lock_acquire+0x8a/0x110
 > [    1.912494]   [] _raw_spin_lock+0x31/0x40
 > [    1.912494]   [] pdc_sata_hardreset+0x85/0x100

Please try the patch below, which implements the fix I described a
week ago. It's for 3.6-rc4 but should work in any recent kernel.
Without this patch one of my test machines always throws a lockdep
warning involving pdc_sata_hardreset and pdc_interrupt during bootup,
but with the patch the warning is gone, as expected.

If it works for you I'll add your Tested-by: and submit it properly.

/Mikael

--- linux-3.6-rc4/drivers/ata/sata_promise.c.~1~2012-09-08 
12:18:24.0 +0200
+++ linux-3.6-rc4/drivers/ata/sata_promise.c2012-09-08 17:55:49.0 
+0200
@@ -147,6 +147,10 @@ struct pdc_port_priv {
dma_addr_t  pkt_dma;
 };
 
+struct pdc_host_priv {
+   spinlock_t hard_reset_lock;
+};
+
 static int pdc_sata_scr_read(struct ata_link *link, unsigned int sc_reg, u32 
*val);
 static int pdc_sata_scr_write(struct ata_link *link, unsigned int sc_reg, u32 
val);
 static int pdc_ata_init_one(struct pci_dev *pdev, const struct pci_device_id 
*ent);
@@ -801,9 +805,10 @@ static void pdc_hard_reset_port(struct a
void __iomem *host_mmio = ap->host->iomap[PDC_MMIO_BAR];
void __iomem *pcictl_b1_mmio = host_mmio + PDC_PCI_CTL + 1;
unsigned int ata_no = pdc_ata_port_to_ata_no(ap);
+   struct pdc_host_priv *hpriv = ap->host->private_data;
u8 tmp;
 
-   spin_lock(&ap->host->lock);
+   spin_lock(&hpriv->hard_reset_lock);
 
tmp = readb(pcictl_b1_mmio);
tmp &= ~(0x10 << ata_no);
@@ -814,7 +819,7 @@ static void pdc_hard_reset_port(struct a
writeb(tmp, pcictl_b1_mmio);
readb(pcictl_b1_mmio); /* flush */
 
-   spin_unlock(&ap->host->lock);
+   spin_unlock(&hpriv->hard_reset_lock);
 }
 
 static int pdc_sata_hardreset(struct ata_link *link, unsigned int *class,
@@ -1182,6 +1187,7 @@ static int pdc_ata_init_one(struct pci_d
const struct ata_port_info *pi = &pdc_port_info[ent->driver_data];
const struct ata_port_info *ppi[PDC_MAX_PORTS];
struct ata_host *host;
+   struct pdc_host_priv *hpriv;
void __iomem *host_mmio;
int n_ports, i, rc;
int is_sataii_tx4;
@@ -1218,6 +1224,11 @@ static int pdc_ata_init_one(struct pci_d
dev_err(&pdev->dev, "failed to allocate host\n");
return -ENOMEM;
}
+   hpriv = devm_kzalloc(&pdev->dev, sizeof *hpriv, GFP_KERNEL);
+   if (!hpriv)
+   return -ENOMEM;
+   spin_lock_init(&hpriv->hard_reset_lock);
+   host->private_data = hpriv;
host->iomap = pcim_iomap_table(pdev);
 
is_sataii_tx4 = pdc_is_sataii_tx4(pi->flags);
--
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: HDD problem, software bug, bios bug, or hardware ?

[Mikael Pettersson]

Adko Branil writes:
 > >Right near the end there's a lockdep warning about a deadlock
 > 
 > >between sata_promise's hardreset thing and the machine getting a
 > >ata_bmdma_interrupt.
 > 
 > >But since I don't know this code, it would be nice if you could take a
 > >look at it.
 > 
 > I picked up 3 more dmesg after rebooting, and 2 more oopses.
 >  I will put here just pieces from dmesgs about these locks, they differs 
 > slightly each-other:
 > 
 > ***
 > 1.
 > 
 > 
 > [    1.859215] input: AT Translated Set 2 keyboard as 
 > /devices/platform/i8042/serio0/input/input1
 > [    1.943678] 
 > [    1.943679] =
 > [    1.943680] [ INFO: inconsistent lock state ]
 > [    1.943682] 3.5.2 #4 Not tainted
 > [    1.943683] -
 > [    1.943684] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
 > [    1.943686] swapper/1/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
 > [    1.943687]  (&(&host->lock)->rlock){?.+...}, at: [] 
 > ata_bmdma_interrupt+0x27/0x1d0
 > [    1.943695] {HARDIRQ-ON-W} state was registered at:
 > [    1.943696]   [] __lock_acquire+0x61b/0x1af0
 > [    1.943701]   [] lock_acquire+0x8a/0x110
 > [    1.943703]   [] _raw_spin_lock+0x31/0x40
 > [    1.943708]   [] pdc_sata_hardreset+0x85/0x100
 > [    1.943711]   [] ata_do_reset+0x3a/0x90
 > [    1.943713]   [] ata_eh_reset+0x372/0xe00
 > [    1.943716]   [] ata_eh_recover+0x2a5/0x13d0
 > [    1.943718]   [] ata_do_eh+0x4d/0xb0
 > [    1.943721]   [] ata_sff_error_handler+0xca/0x120
 > [    1.943723]   [] pdc_error_handler+0x24/0x30
 > [    1.943725]   [] ata_scsi_port_error_handler+0x47c/0x800
 > [    1.943728]   [] ata_scsi_error+0x9e/0xd0
 > [    1.943730]   [] scsi_error_handler+0xf8/0x500
 > [    1.943734]   [] kthread+0xae/0xc0
 > [    1.943737]   [] kernel_thread_helper+0x4/0x10
 > [    1.943740] irq event stamp: 51304
 > [    1.943741] hardirqs last  enabled at (51301): [] 
 > default_idle+0x5d/0x1b0
 > [    1.943745] hardirqs last disabled at (51302): [] 
 > common_interrupt+0x67/0x6c
 > [    1.943748] softirqs last  enabled at (51304): [] 
 > _local_bh_enable+0x13/0x20
 > [    1.943752] softirqs last disabled at (51303): [] 
 > irq_enter+0x75/0x90
 > [    1.943754] 
 > [    1.943754] other info that might help us debug this:
 > [    1.943755]  Possible unsafe locking scenario:
 > [    1.943755] 
 > [    1.943755]    CPU0
 > [    1.943755]    
 > [    1.943756]   lock(&(&host->lock)->rlock);
 > [    1.943757]   
 > [    1.943758] lock(&(&host->lock)->rlock);

I was initially able to reproduce the lockdep warning, and wrote
a crude test patch, but now I can't seem to reproduce the warning
with or without that patch, so I'm not sure what to make of it.

pdc_hard_reset_port needs to serialize because hard reset has to flip
a port-specific bit in a controller register that's shared by all ports,
so it takes the host lock. But now an interrupt occurs during the hard
reset, and pdc_interrupt also has to take the host lock. (I don't know
why the interrupt occurs, hotplug events are supposed to have been masked
by ->freeze before ->hardreset. It might come from a different device,
my test machine has multiple ATA controllers from different vendors,
and some of them do share IRQ.)

Jeff: ->hardreset is called with the host lock NOT held, right?

I think I'll have to introduce a new private lock just for serializing
pdc_hard_reset_port. Expect a patch next weekend (I'll be away from
my Promise test equipment until then.)

/Mikael
--
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: [3.6-rc3 regression] sata_mv cannot get optional clkdev breaking boot on QNAP TS-119P+

[Mikael Pettersson]

Andrew Lunn writes:
 > On Sat, Aug 25, 2012 at 03:01:33PM +0200, Mikael Pettersson wrote:
 > > My Kirkwood-based QNAP TS-119P+ boots fine with the 3.5 kernel.  With
 > > 3.6-rc2 and 3.6-rc3 however sata_mv complains:
 > > 
 > > sata_mv sata_mv.0: cannot get optional clkdev
 > > sata_mv sata_mv.0: slots 32 ports 2
 > > 
 > > and then the kernel grinds to a halt with no further messages.
 > > 
 > > Full boot log from 3.6-rc3 appended below.  .config available upon
 > > request, but this is a non-DT kernel.
 > 
 > Hi Mikael
 > 
 > This is a known issue. See:
 > 
 > http://comments.gmane.org/gmane.linux.ports.arm.kernel/181989
 > 
 > There are patches being developed to fix this. I hope we can push them
 > to an RC soon.

Thanks for the pointer.  Aaro Koskinen's suggestion of passing
coherent_pool=1M to the kernel allowed it to boot successfully.
I'll use that workaround for now.

/Mikael
--
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/

[3.6-rc3 regression] sata_mv cannot get optional clkdev breaking boot on QNAP TS-119P+

[Mikael Pettersson]

My Kirkwood-based QNAP TS-119P+ boots fine with the 3.5 kernel.  With
3.6-rc2 and 3.6-rc3 however sata_mv complains:

sata_mv sata_mv.0: cannot get optional clkdev
sata_mv sata_mv.0: slots 32 ports 2

and then the kernel grinds to a halt with no further messages.

Full boot log from 3.6-rc3 appended below.  .config available upon
request, but this is a non-DT kernel.

/Mikael

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Linux version 3.6.0-rc3 (mikpe@hallertau) (gcc version 4.6.4 20120706 
(prerelease) (GCC) ) #1 Sat Aug 25 14:43:24 CEST 2012
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: QNAP TS-119/TS-219
Ignoring unrecognised tag 0x41000403
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
Kernel command line: console=ttyS0,115200n8 ro root=/dev/sda1
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512MB = 512MB total
Memory: 515884k/515884k available, 8404k reserved, 0K highmem
Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
vmalloc : 0xe080 - 0xff00   ( 488 MB)
lowmem  : 0xc000 - 0xe000   ( 512 MB)
modules : 0xbf00 - 0xc000   (  16 MB)
  .text : 0xc0008000 - 0xc0366000   (3448 kB)
  .init : 0xc0366000 - 0xc03844b8   ( 122 kB)
  .data : 0xc0386000 - 0xc03b32a0   ( 181 kB)
   .bss : 0xc03b32c4 - 0xc03c67c0   (  78 kB)
NR_IRQS:114
sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
Console: colour dummy device 80x30
Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048)
pid_max: default: 32768 minimum: 301
Security Framework initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x2961e8 - 0x296224
devtmpfs: initialized
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Kirkwood: MV88F6282-Rev-A0, TCLK=2.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
Kirkwood PCIe port 0: 
link down, ignoring
bio: create slab  at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource orion_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
msgmni has been set to 1007
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
serial8250.1: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
loop: module loaded
sata_mv sata_mv.0: cannot get optional clkdev
sata_mv sata_mv.0: slots 32 ports 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: [PATCH 00/36] AArch64 Linux kernel port

[Mikael Pettersson]

Catalin Marinas writes:
 > Compilation requires a new aarch64-none-linux-gnu-
 > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).

Where are the corresponding binutils patches?  Without those it's
impossible for people outside ARM to build the toolchain and kernel.

/Mikael
--
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] 2.6.25-rc3 hangs in early boot on Sun Ultra5

[Mikael Pettersson]

Mikael Pettersson writes:
 > Booting 2.6.25-rc3 on my Ultra5 causes a hang before or as
 > the console is switched over to the framebuffer. The console
 > output is (extrapolated from dmesg in -rc2 and handwritten
 > notes, as I don't have a serial cable to my U5):
 > 
 > PROMLIB: Sun IEEE Boot Prom 'OBP 3.25.3 2000/06/29 14:12'
 > PROMLIB: Root node compatible: 
 > *** the following line can't be seen in dmesg after rc2 has booted
 > console [earlyprom0] enabled
 > Linux version 2.6.25-rc3 ([EMAIL PROTECTED]) (gcc version 4.2.3) #1 Mon Feb 
 > 25 18:49:41 CET 2008
 > ARCH: SUN4U
 > Ethernet address: 08:00:20:fd:ec:1f
 > [0002-f840] page_structs=262144 node=0 entry=0/0
 > [0002-f880] page_structs=262144 node=0 entry=1/0
 > [0002-f8c0] page_structs=262144 node=0 entry=2/0
 > [0002-f8000100] page_structs=262144 node=0 entry=3/0
 > OF stdout device is: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/SUNW,[EMAIL 
 > PROTECTED]
 > PROM: Built device tree with 46617 bytes of memory.
 > On node 0 totalpages: 32299
 >   Normal zone: 335 pages used for memmap
 >   Normal zone: 0 pages reserved
 >   Normal zone: 31964 pages, LIFO batch:7
 >   Movable zone: 0 pages used for memmap
 > Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 31964
 > Kernel command line: ro root=/dev/sda5
 > PID hash table entries: 1024 (order: 10, 8192 bytes)
 > clocksource: mult[28000] shift[16]
 > clockevent: mult[] shift[32]
 > Console: colour dummy device 80x25
 > *** the following line can't be seen in dmesg after rc2 has booted
 > console handover: boot [earlyprom0] -> real [tty0]
 > 
 > At this point rc3 hangs hard and won't even respond to sysrq.
 > 
 > Another difference is that with rc2 the first few lines of kernel
 > output while the console is still in OF mode either aren't shown
 > or disappear quickly since the switch to the framebuffer occurs
 > within a fraction of a second after the kernel has been loaded.
 > With rc3 the kernel output (the text shown above) in the OF-mode
 > console is very very slow.
 > 
 > (I should have quoted my .config here but I forgot to bring it.
 > It's exactly the same in rc2 and rc3, however.)
 > 
 > I'll try some rc2->rc3 bisecting later.

Minor update: rc2-git7 has the slow initial console behaviour,
but successfully switches to the framebuffer. rc2-git8 however
hangs in the console handover. So I'll bisect git7->git8 next.

/Mikael
--
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/

[BUG] 2.6.25-rc3 hangs in early boot on Sun Ultra5

[Mikael Pettersson]

Booting 2.6.25-rc3 on my Ultra5 causes a hang before or as
the console is switched over to the framebuffer. The console
output is (extrapolated from dmesg in -rc2 and handwritten
notes, as I don't have a serial cable to my U5):

PROMLIB: Sun IEEE Boot Prom 'OBP 3.25.3 2000/06/29 14:12'
PROMLIB: Root node compatible: 
*** the following line can't be seen in dmesg after rc2 has booted
console [earlyprom0] enabled
Linux version 2.6.25-rc3 ([EMAIL PROTECTED]) (gcc version 4.2.3) #1 Mon Feb 25 
18:49:41 CET 2008
ARCH: SUN4U
Ethernet address: 08:00:20:fd:ec:1f
[0002-f840] page_structs=262144 node=0 entry=0/0
[0002-f880] page_structs=262144 node=0 entry=1/0
[0002-f8c0] page_structs=262144 node=0 entry=2/0
[0002-f8000100] page_structs=262144 node=0 entry=3/0
OF stdout device is: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/SUNW,[EMAIL 
PROTECTED]
PROM: Built device tree with 46617 bytes of memory.
On node 0 totalpages: 32299
  Normal zone: 335 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 31964 pages, LIFO batch:7
  Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 31964
Kernel command line: ro root=/dev/sda5
PID hash table entries: 1024 (order: 10, 8192 bytes)
clocksource: mult[28000] shift[16]
clockevent: mult[] shift[32]
Console: colour dummy device 80x25
*** the following line can't be seen in dmesg after rc2 has booted
console handover: boot [earlyprom0] -> real [tty0]

At this point rc3 hangs hard and won't even respond to sysrq.

Another difference is that with rc2 the first few lines of kernel
output while the console is still in OF mode either aren't shown
or disappear quickly since the switch to the framebuffer occurs
within a fraction of a second after the kernel has been loaded.
With rc3 the kernel output (the text shown above) in the OF-mode
console is very very slow.

(I should have quoted my .config here but I forgot to bring it.
It's exactly the same in rc2 and rc3, however.)

I'll try some rc2->rc3 bisecting later.

/Mikael
--
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.25-rc2-git8 fails to boot on 486 due to TSC breakage

[Mikael Pettersson]

Ingo Molnar writes:
 > 
 > * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
 > 
 > > Please fix it in both places.  Using XOR instead of AND-NOT is a bug, 
 > > plain and simple.
 > 
 > yes, i already fixed that when i added Mikael's patch and it's all 
 > queued up.

Ok. For reference and for LKML viewers, this is what
the final patch should be:

diff -rupN linux-2.6.25-rc3/arch/x86/kernel/cpu/common.c 
linux-2.6.25-rc3.x86-apply-cleared_cpu_caps-correctly/arch/x86/kernel/cpu/common.c
--- linux-2.6.25-rc3/arch/x86/kernel/cpu/common.c   2008-02-25 
09:29:03.0 +0100
+++ 
linux-2.6.25-rc3.x86-apply-cleared_cpu_caps-correctly/arch/x86/kernel/cpu/common.c
  2008-02-25 09:44:11.0 +0100
@@ -504,7 +504,7 @@ void __cpuinit identify_cpu(struct cpuin
 
/* Clear all flags overriden by options */
for (i = 0; i < NCAPINTS; i++)
-   c->x86_capability[i] ^= cleared_cpu_caps[i];
+   c->x86_capability[i] &= ~cleared_cpu_caps[i];
 
/* Init Machine Check Exception if available. */
mcheck_init(c);
diff -rupN linux-2.6.25-rc3/arch/x86/kernel/setup_64.c 
linux-2.6.25-rc3.x86-apply-cleared_cpu_caps-correctly/arch/x86/kernel/setup_64.c
--- linux-2.6.25-rc3/arch/x86/kernel/setup_64.c 2008-02-25 09:29:03.0 
+0100
+++ 
linux-2.6.25-rc3.x86-apply-cleared_cpu_caps-correctly/arch/x86/kernel/setup_64.c
2008-02-25 09:44:57.0 +0100
@@ -1021,7 +1021,7 @@ void __cpuinit identify_cpu(struct cpuin
 
/* Clear all flags overriden by options */
for (i = 0; i < NCAPINTS; i++)
-   c->x86_capability[i] ^= cleared_cpu_caps[i];
+   c->x86_capability[i] &= ~cleared_cpu_caps[i];
 
 #ifdef CONFIG_X86_MCE
mcheck_init(c);
--
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.25-rc2-git8 fails to boot on 486 due to TSC breakage

[Mikael Pettersson]

Mikael Pettersson writes:
 > Ingo Molnar writes:
 >  > 
 >  > * Mikael Pettersson <[EMAIL PROTECTED]> wrote:
 >  > 
 >  > > The kernel for this 486 has CONFIG_M486=y and CONFIG_M586TSC=n, but 
 >  > > the 2.6.25 kernels still try to access the TSC. Here's the oops from 
 >  > > 2.6.25-rc2-git8:
 >  > 
 >  > hm, could you send me the full .config you used?
 > 
 > I've put it here:
 > <http://user.it.uu.se/~mikpe/linux/tmp/config-2.6.24-git8>
 > 
 > Meanwhile, I've traced the breakage to 2.6.24-git8.
 > 
 > 2.6.24-git8 changed include/asm-x86/tsc.h:get_cycles() to call
 > rdtscll() even if CONFIG_X86_TSC isn't set. The call is protected
 > by a cpu_has_tsc test, but starting with 2.6.24-git8 cpu_has_tsc
 > is non-zero on this machine, which is very very wrong.
 > 
 > Diffing dmesg between git7 and git8 doesn't sched any light since
 > git8 also removed the printouts of the x86 caps as they were being
 > initialised and updated. I'm currently adding those printouts back
 > in the hope of seeing where and when the caps get broken.

That turned out to be very illuminating:

--- dmesg-2.6.24-git7   2008-02-24 18:01:25.295851000 +0100
+++ dmesg-2.6.24-git8   2008-02-24 18:01:25.530358000 +0100
...
 CPU: After generic identify, caps: 0003    
   
 
 CPU: After all inits, caps: 0003     
  
+CPU: After applying cleared_cpu_caps, caps: 0013   
    

Notice how the TSC cap bit goes from Off to On.

(The first two lines are printout loops from -git7 forward-ported
to -git8, the third line is the same printout loop added just after
the xor-with-cleared_cpu_caps[] loop.)

Here's how the breakage occurs:
1. arch/x86/kernel/tsc_32.c:tsc_init() sees !cpu_has_tsc,
   so bails and calls setup_clear_cpu_cap(X86_FEATURE_TSC).
2. include/asm-x86/cpufeature.h:setup_clear_cpu_cap(bit) clears
   the bit in boot_cpu_data and sets it in cleared_cpu_caps
3. arch/x86/kernel/cpu/common.c:identify_cpu() XORs all caps
   in with cleared_cpu_caps
   HOWEVER, at this point c->x86_capability correctly has TSC
   Off, cleared_cpu_caps has TSC On, so the XOR incorrectly
   sets TSC to On in c->x86_capability, with disastrous results.

The real bug is that clearing bits with XOR only works if the
bits are known to be 1 prior to the XOR, and that's not true here.

A simple fix is to convert the XOR to AND-NOT instead. The following
patch does that, and allows my 486 to boot 2.6.25-rc kernels again.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
---
There's a similar XOR loop in arch/x86/kernel/setup_64.c.
I haven't seen it fail yet, but perhaps it should be changed
too, for robustness and symmetry.

--- linux-2.6.25-rc2-git8/arch/x86/kernel/cpu/common.c.~1~  2008-02-24 
17:42:56.0 +0100
+++ linux-2.6.25-rc2-git8/arch/x86/kernel/cpu/common.c  2008-02-24 
17:44:06.0 +0100
@@ -504,7 +504,7 @@ void __cpuinit identify_cpu(struct cpuin
 
/* Clear all flags overriden by options */
for (i = 0; i < NCAPINTS; i++)
-   c->x86_capability[i] ^= cleared_cpu_caps[i];
+   c->x86_capability[i] &= ~cleared_cpu_caps[i];
 
/* Init Machine Check Exception if available. */
mcheck_init(c);
--
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.25-rc2-git8 fails to boot on 486 due to TSC breakage

[Mikael Pettersson]

Ingo Molnar writes:
 > 
 > * Mikael Pettersson <[EMAIL PROTECTED]> wrote:
 > 
 > > The kernel for this 486 has CONFIG_M486=y and CONFIG_M586TSC=n, but 
 > > the 2.6.25 kernels still try to access the TSC. Here's the oops from 
 > > 2.6.25-rc2-git8:
 > 
 > hm, could you send me the full .config you used?

I've put it here:
<http://user.it.uu.se/~mikpe/linux/tmp/config-2.6.24-git8>

Meanwhile, I've traced the breakage to 2.6.24-git8.

2.6.24-git8 changed include/asm-x86/tsc.h:get_cycles() to call
rdtscll() even if CONFIG_X86_TSC isn't set. The call is protected
by a cpu_has_tsc test, but starting with 2.6.24-git8 cpu_has_tsc
is non-zero on this machine, which is very very wrong.

Diffing dmesg between git7 and git8 doesn't sched any light since
git8 also removed the printouts of the x86 caps as they were being
initialised and updated. I'm currently adding those printouts back
in the hope of seeing where and when the caps get broken.
--
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/

[BUG] 2.6.25-rc2-git8 fails to boot on 486 due to TSC breakage

[Mikael Pettersson]

The kernel for this 486 has CONFIG_M486=y and CONFIG_M586TSC=n,
but the 2.6.25 kernels still try to access the TSC. Here's the
oops from 2.6.25-rc2-git8:

Pid: 0, comm: swapper Not tainted (2.6.25-rc2-git8 #1)
EIP: 0060:[] EFLAGS: 00010002 CPU: 0
EIP is at native_read_tsc+0x6/0x10
EAX: 8ce6 EBX: c19f8620 ECX: c19f8620 EDX: 00300100
ESI: 00300100 EDI: 0001 EBP: c19f7578 ESP: c02a7eec
 DS: 007b ES: 007b FS:  GS:  SS: 0068
Process swapper (pid: 0, ti=c02a6000 task=c028d300 task.ti=c02a6000)
Stack: c01b37e5  1000 8ce6  c19f7578  c019a2e7 
   c02e05cc c02e05cc c01da229 0016 c01da302 1000 0001 c029d4e0 
   c02e05cc 0050 c01dee35  c02e05cc c01dfc18 c02e0580 c1834ca0 
Call Trace:
 [] add_timer_randomness+0x115/0x170
 [] __blk_end_request+0x17/0x50
 [] __ide_end_request+0x39/0xe0
 [] ide_end_request+0x32/0x50
 [] task_end_request+0x25/0x70
 [] task_in_intr+0xd8/0xe0
 [] ide_intr+0x7a/0x1a0
 [] task_in_intr+0x0/0xe0
 [] run_timer_softirq+0x12/0x150
 [] handle_IRQ_event+0x30/0x70
 [] handle_level_irq+0x42/0x90
 [] do_IRQ+0x41/0x70
 [] common_interrupt+0x23/0x30
 [] arm_timer+0xa0/0x2b0
 [] default_idle+0x3d/0x60
 [] default_idle+0x0/0x60
 [] cpu_idle+0x20/0x70
 [] start_kernel+0x1e3/0x260
 ===
Code: 90 90 90 90 90 b8 8e 21 00 00 e9 a6 28 0a 00 8d b6 00 00 00 00 e6 ed c3 
90 90 90 90 90 90 90 90 9 
EIP: [] native_read_tsc+0x6/0x10 SS:ESP 0068:c02a7eec
Kernel panic - not syncing: Fatal exception in interrupt

This bug is also seen with 2.6.25-rc1.
Kernels up to and including 2.6.24 did not have this bug.
--
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: [PATCH] Make sysctl a separate filesystem

[Mikael Pettersson]

Al Viro writes:
 > On Fri, Feb 15, 2008 at 12:35:23PM +0100, Mikael Pettersson wrote:
 > > Andi Kleen writes:
 > >  > Pavel Emelyanov <[EMAIL PROTECTED]> writes:
 > >  > >this subdir;
 > >  > > 3. sysctl inodes are now smaller than the procfs ones.
 > >  > 
 > >  > That's always a good thing.
 > >  > 
 > >  > > Note: update your initscripts to mount sysctl filesystem 
 > >  > > right after the proc is mounted in order not to lose your
 > >  > > /etc/sysctl.conf configuration (and optionally fstab).
 > >  > 
 > >  > That will break about everybody's init scripts I suspect.
 > >  > 
 > >  > I think you would need to go through some deprecation
 > >  > period for this at least, with printks warning people
 > >  > to fix their init scripts.
 > >  > 
 > >  > Or better find some way to do the mount automatically.
 > > 
 > > Doing it automatically is the only acceptable way, IMO.
 > 
 > When and where?

I don't really care, as long as existing user-space doesn't get broken.
--
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/