xhci: Not enough bandwidth for new device state

[Waldemar Brodkorb]

Hi,

I am getting these messages from a Debian 9.3 system using
Linux 4.9.x:
[  547.352746] usb 3-5.2: 3:1: usb_set_interface failed (-28)
[  548.352865] usb 3-5.3: Not enough bandwidth for new device state.
[  548.352868] usb 3-5.3: Not enough bandwidth for altsetting 1

I have connected a 7-Port USB 3.0 Hub to my machine.
I have 6 different Headsets and USB Soundcards connected to the HUB.

As soon as I start a C++ application which opens all ALSA devices
I get these errors and the USB stopps working correctly.

I think the maximum count of USB sound devices, which behave stable
is three or four. 

Is this some miscalculation of the Linux kernel regarding the USB
bandwidth usage? How I can determine how much bandwidth the USB
sound card driver preallocates?

Or are five USB soundcards really too much for an USB 3.0 bus?

Thanks in advance for any advise,
 best regards
   Waldemar

xhci: Not enough bandwidth for new device state

[Waldemar Brodkorb]

Hi,

I am getting these messages from a Debian 9.3 system using
Linux 4.9.x:
[  547.352746] usb 3-5.2: 3:1: usb_set_interface failed (-28)
[  548.352865] usb 3-5.3: Not enough bandwidth for new device state.
[  548.352868] usb 3-5.3: Not enough bandwidth for altsetting 1

I have connected a 7-Port USB 3.0 Hub to my machine.
I have 6 different Headsets and USB Soundcards connected to the HUB.

As soon as I start a C++ application which opens all ALSA devices
I get these errors and the USB stopps working correctly.

I think the maximum count of USB sound devices, which behave stable
is three or four. 

Is this some miscalculation of the Linux kernel regarding the USB
bandwidth usage? How I can determine how much bandwidth the USB
sound card driver preallocates?

Or are five USB soundcards really too much for an USB 3.0 bus?

Thanks in advance for any advise,
 best regards
   Waldemar

[PATCH] h8300: fix defconfig for edosk2674

[Waldemar Brodkorb]

This patch is required to create an uImage which
boot on Hitachi edosk2674 into a shell. (tested with sash)
The patch was tested with 4.4/4.9 LTS kernel. It seems >4.13
contains a regression, which does not allow to boot Linux on
the device anymore.

Signed-off-by: Waldemar Brodkorb <w...@openadk.org>
---
 arch/h8300/Kconfig.cpu | 4 
 arch/h8300/configs/edosk2674_defconfig | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/h8300/Kconfig.cpu b/arch/h8300/Kconfig.cpu
index 8d0ff20c749a..1d2ccd1ad556 100644
--- a/arch/h8300/Kconfig.cpu
+++ b/arch/h8300/Kconfig.cpu
@@ -96,4 +96,8 @@ config OFFSET
 hex "Load offset"
default 0
 
+config RAMBASE
+   hex "RAM base address"
+   default 0x40
+
 endmenu
diff --git a/arch/h8300/configs/edosk2674_defconfig 
b/arch/h8300/configs/edosk2674_defconfig
index 29fda12d5da9..0cc040040292 100644
--- a/arch/h8300/configs/edosk2674_defconfig
+++ b/arch/h8300/configs/edosk2674_defconfig
@@ -18,7 +18,7 @@ CONFIG_EMBEDDED=y
 CONFIG_SLOB=y
 # CONFIG_BLOCK is not set
 CONFIG_H8S_SIM=y
-CONFIG_H8300_BUILTIN_DTB="h8s_sim"
+CONFIG_H8300_BUILTIN_DTB="edosk2674"
 # CONFIG_BINFMT_SCRIPT is not set
 CONFIG_BINFMT_FLAT=y
 # CONFIG_COREDUMP is not set
-- 
2.11.0

[PATCH] h8300: fix defconfig for edosk2674

[Waldemar Brodkorb]

This patch is required to create an uImage which
boot on Hitachi edosk2674 into a shell. (tested with sash)
The patch was tested with 4.4/4.9 LTS kernel. It seems >4.13
contains a regression, which does not allow to boot Linux on
the device anymore.

Signed-off-by: Waldemar Brodkorb 
---
 arch/h8300/Kconfig.cpu | 4 
 arch/h8300/configs/edosk2674_defconfig | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/h8300/Kconfig.cpu b/arch/h8300/Kconfig.cpu
index 8d0ff20c749a..1d2ccd1ad556 100644
--- a/arch/h8300/Kconfig.cpu
+++ b/arch/h8300/Kconfig.cpu
@@ -96,4 +96,8 @@ config OFFSET
 hex "Load offset"
default 0
 
+config RAMBASE
+   hex "RAM base address"
+   default 0x40
+
 endmenu
diff --git a/arch/h8300/configs/edosk2674_defconfig 
b/arch/h8300/configs/edosk2674_defconfig
index 29fda12d5da9..0cc040040292 100644
--- a/arch/h8300/configs/edosk2674_defconfig
+++ b/arch/h8300/configs/edosk2674_defconfig
@@ -18,7 +18,7 @@ CONFIG_EMBEDDED=y
 CONFIG_SLOB=y
 # CONFIG_BLOCK is not set
 CONFIG_H8S_SIM=y
-CONFIG_H8300_BUILTIN_DTB="h8s_sim"
+CONFIG_H8300_BUILTIN_DTB="edosk2674"
 # CONFIG_BINFMT_SCRIPT is not set
 CONFIG_BINFMT_FLAT=y
 # CONFIG_COREDUMP is not set
-- 
2.11.0

h8300 for edosk2674 device

[Waldemar Brodkorb]

Hi,

the attached kernel config errors out with:
/usr/bin/make -f ./scripts/Makefile.build obj=arch/h8300/boot
arch/h8300/boot/uImage.bin
  
/home/wbx/h8300/toolchain_hitachi-edosk2674_uclibc-ng/usr/bin/h8300-openadk-linux-uclibc-objcopy
-Obinary vmlinux arch/h8300/boot/vmlinux.bin
  /bin/bash ./scripts/mkuboot.sh -A h8300 -O linux -C none  -T
kernel -a  -e 0x -n 'Linux-4.11.5-1' -d
arch/h8300/boot/vmlinux.bin arch/h8300/boot/uImage.bin
Usage: /home/wbx/h8300/host_x86_64-linux-gnu/usr/bin/mkimage -l
image
  -l ==> list image header information
   /home/wbx/h8300/host_x86_64-linux-gnu/usr/bin/mkimage [-x] -A
arch -O os -T type -C comp -a addr -e ep -n name -d
data_file[:data_file...] image
  -A ==> set architecture to 'arch'
  -O ==> set operating system to 'os'
  -T ==> set image type to 'type'
  -C ==> set compression type 'comp'
  -a ==> set load address to 'addr' (hex)
  -e ==> set entry point to 'ep' (hex)
  -n ==> set image name to 'name'
  -d ==> use image data from 'datafile'
  -x ==> set XIP (execute in place)
   /home/wbx/h8300/host_x86_64-linux-gnu/usr/bin/mkimage [-D
dtc_options] [-f fit-image.its|-F] fit-image
  -D => set options for device tree compiler
  -f => input filename for FIT source
Signing / verified boot options: [-k keydir] [-K dtb] [ -c
] [-r]
  -k => set directory containing private keys
  -K => write public keys to this .dtb file
  -c => add comment in signature node
  -F => re-sign existing FIT image
  -r => mark keys used as 'required' in dtb
   /home/wbx/h8300/host_x86_64-linux-gnu/usr/bin/mkimage

Kernel 4.11.5 is tried to cross-compiled. The -a parameter to
mkimage is empty. What is the correct value?

I tried to use following patch, but the resulting kernel does not
boot on my device:
diff -Nur linux-4.9.20.orig/arch/h8300/Kconfig.cpu
linux-4.9.20/arch/h8300/Kconfig.cpu
--- linux-4.9.20.orig/arch/h8300/Kconfig.cpu2017-03-31
10:32:02.0 +0200
+++ linux-4.9.20/arch/h8300/Kconfig.cpu 2017-04-04
08:10:00.132205323 +0200
@@ -96,4 +96,8 @@
 hex "Load offset"
default 0
 
+config RAMBASE
+   hex "RAM base address"
+   default 0x40
+
 endmenu

Any ideas?

best regards
 Waldemar
#
# Automatically generated file; DO NOT EDIT.
# Linux/h8300 4.11.5 Kernel Configuration
#
CONFIG_H8300=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_NO_IOPORT_MAP=y
CONFIG_GENERIC_CSUM=y
CONFIG_HZ=100
CONFIG_NR_CPUS=1
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="openadk"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=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 is not set
# CONFIG_HIGH_RES_TIMERS is not set

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

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD 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_EXPERT=y
# CONFIG_UID16 is not set
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
# CONFIG_SYSFS_SYSCALL is not set
# CONFIG_SYSCTL_SYSCALL is not set
# CONFIG_POSIX_TIMERS is not set
# CONFIG_KALLSYMS is not set
CONFIG_PRINTK=y
# CONFIG_BUG is not set
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_MEMBARRIER is not set
CONFIG_EMBEDDED=y
# CONFIG_PC104 is not set

#
# Kernel Performance Events And Counters
#
# 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_FREELIST_RANDOM is not set
# CONFIG_MMAP_ALLOW_UNINITIALIZED is not set
# CONFIG_SYSTEM_DATA_VERIFICATION is not 

h8300 for edosk2674 device

[Waldemar Brodkorb]

Hi,

the attached kernel config errors out with:
/usr/bin/make -f ./scripts/Makefile.build obj=arch/h8300/boot
arch/h8300/boot/uImage.bin
  
/home/wbx/h8300/toolchain_hitachi-edosk2674_uclibc-ng/usr/bin/h8300-openadk-linux-uclibc-objcopy
-Obinary vmlinux arch/h8300/boot/vmlinux.bin
  /bin/bash ./scripts/mkuboot.sh -A h8300 -O linux -C none  -T
kernel -a  -e 0x -n 'Linux-4.11.5-1' -d
arch/h8300/boot/vmlinux.bin arch/h8300/boot/uImage.bin
Usage: /home/wbx/h8300/host_x86_64-linux-gnu/usr/bin/mkimage -l
image
  -l ==> list image header information
   /home/wbx/h8300/host_x86_64-linux-gnu/usr/bin/mkimage [-x] -A
arch -O os -T type -C comp -a addr -e ep -n name -d
data_file[:data_file...] image
  -A ==> set architecture to 'arch'
  -O ==> set operating system to 'os'
  -T ==> set image type to 'type'
  -C ==> set compression type 'comp'
  -a ==> set load address to 'addr' (hex)
  -e ==> set entry point to 'ep' (hex)
  -n ==> set image name to 'name'
  -d ==> use image data from 'datafile'
  -x ==> set XIP (execute in place)
   /home/wbx/h8300/host_x86_64-linux-gnu/usr/bin/mkimage [-D
dtc_options] [-f fit-image.its|-F] fit-image
  -D => set options for device tree compiler
  -f => input filename for FIT source
Signing / verified boot options: [-k keydir] [-K dtb] [ -c
] [-r]
  -k => set directory containing private keys
  -K => write public keys to this .dtb file
  -c => add comment in signature node
  -F => re-sign existing FIT image
  -r => mark keys used as 'required' in dtb
   /home/wbx/h8300/host_x86_64-linux-gnu/usr/bin/mkimage

Kernel 4.11.5 is tried to cross-compiled. The -a parameter to
mkimage is empty. What is the correct value?

I tried to use following patch, but the resulting kernel does not
boot on my device:
diff -Nur linux-4.9.20.orig/arch/h8300/Kconfig.cpu
linux-4.9.20/arch/h8300/Kconfig.cpu
--- linux-4.9.20.orig/arch/h8300/Kconfig.cpu2017-03-31
10:32:02.0 +0200
+++ linux-4.9.20/arch/h8300/Kconfig.cpu 2017-04-04
08:10:00.132205323 +0200
@@ -96,4 +96,8 @@
 hex "Load offset"
default 0
 
+config RAMBASE
+   hex "RAM base address"
+   default 0x40
+
 endmenu

Any ideas?

best regards
 Waldemar
#
# Automatically generated file; DO NOT EDIT.
# Linux/h8300 4.11.5 Kernel Configuration
#
CONFIG_H8300=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_NO_IOPORT_MAP=y
CONFIG_GENERIC_CSUM=y
CONFIG_HZ=100
CONFIG_NR_CPUS=1
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="openadk"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=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 is not set
# CONFIG_HIGH_RES_TIMERS is not set

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

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD 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_EXPERT=y
# CONFIG_UID16 is not set
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
# CONFIG_SYSFS_SYSCALL is not set
# CONFIG_SYSCTL_SYSCALL is not set
# CONFIG_POSIX_TIMERS is not set
# CONFIG_KALLSYMS is not set
CONFIG_PRINTK=y
# CONFIG_BUG is not set
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_MEMBARRIER is not set
CONFIG_EMBEDDED=y
# CONFIG_PC104 is not set

#
# Kernel Performance Events And Counters
#
# 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_FREELIST_RANDOM is not set
# CONFIG_MMAP_ALLOW_UNINITIALIZED is not set
# CONFIG_SYSTEM_DATA_VERIFICATION is not 

Re: sparc64 gcc 7.1 compile error

[Waldemar Brodkorb]

Hi David,
David Miller wrote,

> From: Waldemar Brodkorb <w...@openadk.org>
> Date: Mon, 5 Jun 2017 11:19:41 +0200
> 
> > I get a compile/linking error with gcc 7.1 when targeting qemu system
> > sparc64.
> 
> This should fix the problem, please let me know if it works for you:

Yes, that works fine for me. Thanks again for the fast help,

best regards
 Waldemar

Re: sparc64 gcc 7.1 compile error

[Waldemar Brodkorb]

Hi David,
David Miller wrote,

> From: Waldemar Brodkorb 
> Date: Mon, 5 Jun 2017 11:19:41 +0200
> 
> > I get a compile/linking error with gcc 7.1 when targeting qemu system
> > sparc64.
> 
> This should fix the problem, please let me know if it works for you:

Yes, that works fine for me. Thanks again for the fast help,

best regards
 Waldemar

sparc64 gcc 7.1 compile error

[Waldemar Brodkorb]

Hi,

I get a compile/linking error with gcc 7.1 when targeting qemu system
sparc64.

+ objects='arch/sparc/kernel/head_64.o  init/built-in.o
--start-group  usr/built-in.o  arch/sparc/built-in.o
kernel/built-in.o  certs/built-in.o  mm/built-in.o  fs/built-in.o
ipc/built-in.o  security/built-in.o  crypto/built-in.o
block/built-in.o  lib/lib.a  arch/sparc/prom/lib.a
arch/sparc/lib/lib.a  lib/built-in.o  arch/sparc/prom/built-in.o
arch/sparc/lib/built-in.o  drivers/built-in.o  sound/built-in.o
firmware/built-in.o  net/built-in.o  virt/built-in.o
--end-group   '
+
/home/wbx/openadk/toolchain_qemu-sparc64_glibc_v9/usr/bin/sparc64-openadk-linux-gnu-ld
-m elf64_sparc --build-id -o vmlinux -T
./arch/sparc/kernel/vmlinux.lds arch/sparc/kernel/head_64.o
init/built-in.o --start-group usr/built-in.o arch/sparc/built-in.o
kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o
ipc/built-in.o security/built-in.o crypto/built-in.o
block/built-in.o lib/lib.a arch/sparc/prom/lib.a
arch/sparc/lib/lib.a lib/built-in.o arch/sparc/prom/built-in.o
arch/sparc/lib/built-in.o drivers/built-in.o sound/built-in.o
firmware/built-in.o net/built-in.o virt/built-in.o --end-group
ipc/built-in.o: In function `mq_attr_ok':
mqueue.c:(.text+0x6154): undefined reference to `__multi3'

I tried with Linux 4.11.3, Linus master and David Miller's SPARC
tree from today with the same result. The failing config is attached.

Any ideas?

best regards
 Waldemar

#
# Automatically generated file; DO NOT EDIT.
# Linux/sparc64 4.12.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_SPARC=y
# CONFIG_SPARC32 is not set
CONFIG_SPARC64=y
CONFIG_ARCH_DEFCONFIG="arch/sparc/configs/sparc64_defconfig"
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ARCH_ATU=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_IOMMU_HELPER=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_AUDIT_ARCH=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_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_DEFAULT_HOSTNAME="openadk"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE 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_SPARSE_IRQ=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 is not set
# CONFIG_HIGH_RES_TIMERS 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

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
CONFIG_RCU_NEED_SEGCBLIST=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD 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 is not set
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
# CONFIG_SYSFS_SYSCALL is not set
# CONFIG_SYSCTL_SYSCALL is not set
# CONFIG_POSIX_TIMERS is not set
# CONFIG_KALLSYMS is not set
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
# CONFIG_BUG is not set
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_USERFAULTFD is not set
CONFIG_PCI_QUIRKS=y
# CONFIG_MEMBARRIER 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_FREELIST_RANDOM is not set
# CONFIG_SYSTEM_DATA_VERIFICATION is not set
# CONFIG_PROFILING is not set

sparc64 gcc 7.1 compile error

[Waldemar Brodkorb]

Hi,

I get a compile/linking error with gcc 7.1 when targeting qemu system
sparc64.

+ objects='arch/sparc/kernel/head_64.o  init/built-in.o
--start-group  usr/built-in.o  arch/sparc/built-in.o
kernel/built-in.o  certs/built-in.o  mm/built-in.o  fs/built-in.o
ipc/built-in.o  security/built-in.o  crypto/built-in.o
block/built-in.o  lib/lib.a  arch/sparc/prom/lib.a
arch/sparc/lib/lib.a  lib/built-in.o  arch/sparc/prom/built-in.o
arch/sparc/lib/built-in.o  drivers/built-in.o  sound/built-in.o
firmware/built-in.o  net/built-in.o  virt/built-in.o
--end-group   '
+
/home/wbx/openadk/toolchain_qemu-sparc64_glibc_v9/usr/bin/sparc64-openadk-linux-gnu-ld
-m elf64_sparc --build-id -o vmlinux -T
./arch/sparc/kernel/vmlinux.lds arch/sparc/kernel/head_64.o
init/built-in.o --start-group usr/built-in.o arch/sparc/built-in.o
kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o
ipc/built-in.o security/built-in.o crypto/built-in.o
block/built-in.o lib/lib.a arch/sparc/prom/lib.a
arch/sparc/lib/lib.a lib/built-in.o arch/sparc/prom/built-in.o
arch/sparc/lib/built-in.o drivers/built-in.o sound/built-in.o
firmware/built-in.o net/built-in.o virt/built-in.o --end-group
ipc/built-in.o: In function `mq_attr_ok':
mqueue.c:(.text+0x6154): undefined reference to `__multi3'

I tried with Linux 4.11.3, Linus master and David Miller's SPARC
tree from today with the same result. The failing config is attached.

Any ideas?

best regards
 Waldemar

#
# Automatically generated file; DO NOT EDIT.
# Linux/sparc64 4.12.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_SPARC=y
# CONFIG_SPARC32 is not set
CONFIG_SPARC64=y
CONFIG_ARCH_DEFCONFIG="arch/sparc/configs/sparc64_defconfig"
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ARCH_ATU=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_IOMMU_HELPER=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_AUDIT_ARCH=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_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_DEFAULT_HOSTNAME="openadk"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE 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_SPARSE_IRQ=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 is not set
# CONFIG_HIGH_RES_TIMERS 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

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
CONFIG_RCU_NEED_SEGCBLIST=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD 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 is not set
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
# CONFIG_SYSFS_SYSCALL is not set
# CONFIG_SYSCTL_SYSCALL is not set
# CONFIG_POSIX_TIMERS is not set
# CONFIG_KALLSYMS is not set
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
# CONFIG_BUG is not set
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_USERFAULTFD is not set
CONFIG_PCI_QUIRKS=y
# CONFIG_MEMBARRIER 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_FREELIST_RANDOM is not set
# CONFIG_SYSTEM_DATA_VERIFICATION is not set
# CONFIG_PROFILING is not set

Re: sparc gcc 7.1 compile issue

[Waldemar Brodkorb]

Hi Adrian,
John Paul Adrian Glaubitz wrote,

> On 06/02/2017 07:28 PM, David Miller wrote:
> >> Isn't a bug in the kernel if an application is able to crash to the point
> >> that the machine has to be hard-rebooted?
> > 
> > It can be a bug in the compiler too and not necessarily the kernel's
> > fault which is what I think is happening in your case.
> 
> So, in your point of view it's perfectly fine if an application is able
> to crash the whole kernel with just user privileges?
> 
> Shouldn't the kernel be able to cope with that?

I think he means your kernel you are running might be miscompiled
with gcc 7.1.

What kernel version you are running? Which compiler you used to
generate the running kernel? If it is gcc 7.1, what is if you try to
reproduce the crash with the same kernel version compiled with gcc
6.3?
Wouldn't this show if it is a compiler or kernel bug?

best regards
 Waldemar

Re: sparc gcc 7.1 compile issue

[Waldemar Brodkorb]

Hi Adrian,
John Paul Adrian Glaubitz wrote,

> On 06/02/2017 07:28 PM, David Miller wrote:
> >> Isn't a bug in the kernel if an application is able to crash to the point
> >> that the machine has to be hard-rebooted?
> > 
> > It can be a bug in the compiler too and not necessarily the kernel's
> > fault which is what I think is happening in your case.
> 
> So, in your point of view it's perfectly fine if an application is able
> to crash the whole kernel with just user privileges?
> 
> Shouldn't the kernel be able to cope with that?

I think he means your kernel you are running might be miscompiled
with gcc 7.1.

What kernel version you are running? Which compiler you used to
generate the running kernel? If it is gcc 7.1, what is if you try to
reproduce the crash with the same kernel version compiled with gcc
6.3?
Wouldn't this show if it is a compiler or kernel bug?

best regards
 Waldemar

Re: sparc gcc 7.1 compile issue

[Waldemar Brodkorb]

Hi David,

thank you very much.

best regards
 Waldemar

Re: sparc gcc 7.1 compile issue

[Waldemar Brodkorb]

Hi David,

thank you very much.

best regards
 Waldemar

sparc gcc 7.1 compile issue

[Waldemar Brodkorb]

Hi,

when compiling a kernel (4.11.3) for sparc with gcc 7.1 and 
attached config I get following error:

/usr/bin/make -f ./scripts/Makefile.build obj=arch/sparc/mm
  
/home/wbx/openadk/toolchain_qemu-sparc_uclibc-ng_v8/usr/bin/sparc-openadk-linux-uclibc-gcc
 -Wp,-MD,arch/sparc/mm/.init_32.o.d  -nostdinc -isystem 
/home/wbx/openadk/toolchain_qemu-sparc_uclibc-ng_v8/usr/lib/gcc/sparc-openadk-linux-uclibc/7.1.0/include
 -I./arch/sparc/include -I./arch/sparc/include/generated/uapi 
-I./arch/sparc/include/generated  -I./include -I./arch/sparc/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h 
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs 
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration 
-Wno-format-security -std=gnu89 -fno-PIE -m32 -mcpu=v8 -pipe -mno-fpu 
-fcall-used-g5 -fcall-used-g7 -Wa,-Av8 -fno-delete-null-pointer-checks 
-Wno-frame-address -Os -Wno-maybe-uninitialized 
--param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -Wframe-larger-than=1024 
-fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable 
-fomit-frame-pointer -fno-var-tracking-assignments 
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow 
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes 
-Werror=date-time -Werror=incompatible-pointer-types -Werror
-DKBUILD_BASENAME='"init_32"'  -DKBUILD_MODNAME='"init_32"' -c -o 
arch/sparc/mm/init_32.o arch/sparc/mm/init_32.c
In file included from ./include/linux/string.h:18:0,
 from ./include/linux/bitmap.h:8,
 from ./include/linux/cpumask.h:11,
 from ./arch/sparc/include/asm/smp_32.h:14,
 from ./arch/sparc/include/asm/smp.h:6,
 from ./arch/sparc/include/asm/switch_to_32.h:4,
 from ./arch/sparc/include/asm/switch_to.h:6,
 from ./arch/sparc/include/asm/ptrace.h:118,
 from ./arch/sparc/include/asm/thread_info_32.h:18,
 from ./arch/sparc/include/asm/thread_info.h:6,
 from ./include/linux/thread_info.h:25,
 from ./include/asm-generic/preempt.h:4,
 from ./arch/sparc/include/generated/asm/preempt.h:1,
 from ./include/linux/preempt.h:80,
 from ./include/linux/spinlock.h:50,
 from ./include/linux/seqlock.h:35,
 from ./include/linux/time.h:5,
 from ./include/linux/stat.h:18,
 from ./include/linux/module.h:10,
 from arch/sparc/mm/init_32.c:10:
arch/sparc/mm/init_32.c: In function 'mem_init':
./arch/sparc/include/asm/string.h:17:29: error: '__builtin_memset' writing 4096 
bytes into a region of size 4 overflows the destination 
[-Werror=stringop-overflow=]
 #define memset(s, c, count) __builtin_memset(s, c, count)
 ^
arch/sparc/mm/init_32.c:293:2: note: in expansion of macro 'memset'
  memset((void *)_zero_page, 0, PAGE_SIZE);
  ^~
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target 'arch/sparc/mm/init_32.o' failed
make[8]: *** [arch/sparc/mm/init_32.o] Error 1
scripts/Makefile.build:553: recipe for target 'arch/sparc/mm' failed
make[7]: *** [arch/sparc/mm] Error 2
Makefile:1002: recipe for target 'arch/sparc' failed
make[6]: *** [arch/sparc] Error 2
/home/wbx/openadk/mk/kernel-build.mk:77: recipe for target 
'/home/wbx/openadk/build_qemu-sparc_uclibc-ng_v8/linux/vmlinux' failed
make[5]: *** [/home/wbx/openadk/build_qemu-sparc_uclibc-ng_v8/linux/vmlinux] 
Error 2
Makefile:177: recipe for target 'sparc-compile' failed
make[4]: *** [sparc-compile] Error 2
mk/build.mk:218: recipe for target 'target/compile' failed
make[3]: *** [target/compile] Error 2
/home/wbx/openadk/mk/build.mk:170: recipe for target 'world' failed
make[2]: *** [world] Error 2

How can this be fixed? 

best regards
 Waldemar
#
# Automatically generated file; DO NOT EDIT.
# Linux/sparc 4.11.3 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_SPARC=y
CONFIG_SPARC32=y
# CONFIG_SPARC64 is not set
CONFIG_ARCH_DEFCONFIG="arch/sparc/configs/sparc32_defconfig"
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_AUDIT_ARCH=y
CONFIG_MMU=y
CONFIG_HIGHMEM=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_DEFAULT_HOSTNAME="openadk"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y

sparc gcc 7.1 compile issue

[Waldemar Brodkorb]

Hi,

when compiling a kernel (4.11.3) for sparc with gcc 7.1 and 
attached config I get following error:

/usr/bin/make -f ./scripts/Makefile.build obj=arch/sparc/mm
  
/home/wbx/openadk/toolchain_qemu-sparc_uclibc-ng_v8/usr/bin/sparc-openadk-linux-uclibc-gcc
 -Wp,-MD,arch/sparc/mm/.init_32.o.d  -nostdinc -isystem 
/home/wbx/openadk/toolchain_qemu-sparc_uclibc-ng_v8/usr/lib/gcc/sparc-openadk-linux-uclibc/7.1.0/include
 -I./arch/sparc/include -I./arch/sparc/include/generated/uapi 
-I./arch/sparc/include/generated  -I./include -I./arch/sparc/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h 
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs 
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration 
-Wno-format-security -std=gnu89 -fno-PIE -m32 -mcpu=v8 -pipe -mno-fpu 
-fcall-used-g5 -fcall-used-g7 -Wa,-Av8 -fno-delete-null-pointer-checks 
-Wno-frame-address -Os -Wno-maybe-uninitialized 
--param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -Wframe-larger-than=1024 
-fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable 
-fomit-frame-pointer -fno-var-tracking-assignments 
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow 
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes 
-Werror=date-time -Werror=incompatible-pointer-types -Werror
-DKBUILD_BASENAME='"init_32"'  -DKBUILD_MODNAME='"init_32"' -c -o 
arch/sparc/mm/init_32.o arch/sparc/mm/init_32.c
In file included from ./include/linux/string.h:18:0,
 from ./include/linux/bitmap.h:8,
 from ./include/linux/cpumask.h:11,
 from ./arch/sparc/include/asm/smp_32.h:14,
 from ./arch/sparc/include/asm/smp.h:6,
 from ./arch/sparc/include/asm/switch_to_32.h:4,
 from ./arch/sparc/include/asm/switch_to.h:6,
 from ./arch/sparc/include/asm/ptrace.h:118,
 from ./arch/sparc/include/asm/thread_info_32.h:18,
 from ./arch/sparc/include/asm/thread_info.h:6,
 from ./include/linux/thread_info.h:25,
 from ./include/asm-generic/preempt.h:4,
 from ./arch/sparc/include/generated/asm/preempt.h:1,
 from ./include/linux/preempt.h:80,
 from ./include/linux/spinlock.h:50,
 from ./include/linux/seqlock.h:35,
 from ./include/linux/time.h:5,
 from ./include/linux/stat.h:18,
 from ./include/linux/module.h:10,
 from arch/sparc/mm/init_32.c:10:
arch/sparc/mm/init_32.c: In function 'mem_init':
./arch/sparc/include/asm/string.h:17:29: error: '__builtin_memset' writing 4096 
bytes into a region of size 4 overflows the destination 
[-Werror=stringop-overflow=]
 #define memset(s, c, count) __builtin_memset(s, c, count)
 ^
arch/sparc/mm/init_32.c:293:2: note: in expansion of macro 'memset'
  memset((void *)_zero_page, 0, PAGE_SIZE);
  ^~
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target 'arch/sparc/mm/init_32.o' failed
make[8]: *** [arch/sparc/mm/init_32.o] Error 1
scripts/Makefile.build:553: recipe for target 'arch/sparc/mm' failed
make[7]: *** [arch/sparc/mm] Error 2
Makefile:1002: recipe for target 'arch/sparc' failed
make[6]: *** [arch/sparc] Error 2
/home/wbx/openadk/mk/kernel-build.mk:77: recipe for target 
'/home/wbx/openadk/build_qemu-sparc_uclibc-ng_v8/linux/vmlinux' failed
make[5]: *** [/home/wbx/openadk/build_qemu-sparc_uclibc-ng_v8/linux/vmlinux] 
Error 2
Makefile:177: recipe for target 'sparc-compile' failed
make[4]: *** [sparc-compile] Error 2
mk/build.mk:218: recipe for target 'target/compile' failed
make[3]: *** [target/compile] Error 2
/home/wbx/openadk/mk/build.mk:170: recipe for target 'world' failed
make[2]: *** [world] Error 2

How can this be fixed? 

best regards
 Waldemar
#
# Automatically generated file; DO NOT EDIT.
# Linux/sparc 4.11.3 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_SPARC=y
CONFIG_SPARC32=y
# CONFIG_SPARC64 is not set
CONFIG_ARCH_DEFCONFIG="arch/sparc/configs/sparc32_defconfig"
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_AUDIT_ARCH=y
CONFIG_MMU=y
CONFIG_HIGHMEM=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_DEFAULT_HOSTNAME="openadk"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y

objective rules for architecture removal

[Waldemar Brodkorb]

Hi Linus,

are there any objective rules for removal of architecture support from
the Linux kernel tree?

I recognized this week that avr32 support was removed recently.
https://lkml.org/lkml/2017/3/1/694

The major reasons are:
 - end-of-life for hardware
 - no upstream gcc (very old)
 - no users or distribution supporting it
 - shared driver code with ARM architecture

AVR32 has a working distribution (https://openadk.org) and some users.
A year ago Mario Haustein from Technical University Chemnitz submitted some
patches to OpenADK for better AVR32 support. They have approx. 100 devices in 
use. 
And I donated a NGW100 board to one of the u-boot maintainers to keep u-boot
support solid. 

It is possible to use gcc 4.4.7 with some patches, which was used a long time
in OpenWrt avr32 port:
https://cgit.openadk.org/cgi/cgit/openadk.git/tree/toolchain/gcc/patches/4.4.7

I always loved that Linux kernel does support many architectures and keep 
supporting
all of them. Any chance to rethink about the removal?

Couldn't be the shared drivers be separated, so that the ARM drivers get there 
new improvements? It is a naive assumption from an embedded Linux hacker
trying to keep uClibc and all it's architecture support alive. 
(https://uclibc-ng.org)

best regards
 Waldemar

objective rules for architecture removal

[Waldemar Brodkorb]

Hi Linus,

are there any objective rules for removal of architecture support from
the Linux kernel tree?

I recognized this week that avr32 support was removed recently.
https://lkml.org/lkml/2017/3/1/694

The major reasons are:
 - end-of-life for hardware
 - no upstream gcc (very old)
 - no users or distribution supporting it
 - shared driver code with ARM architecture

AVR32 has a working distribution (https://openadk.org) and some users.
A year ago Mario Haustein from Technical University Chemnitz submitted some
patches to OpenADK for better AVR32 support. They have approx. 100 devices in 
use. 
And I donated a NGW100 board to one of the u-boot maintainers to keep u-boot
support solid. 

It is possible to use gcc 4.4.7 with some patches, which was used a long time
in OpenWrt avr32 port:
https://cgit.openadk.org/cgi/cgit/openadk.git/tree/toolchain/gcc/patches/4.4.7

I always loved that Linux kernel does support many architectures and keep 
supporting
all of them. Any chance to rethink about the removal?

Couldn't be the shared drivers be separated, so that the ARM drivers get there 
new improvements? It is a naive assumption from an embedded Linux hacker
trying to keep uClibc and all it's architecture support alive. 
(https://uclibc-ng.org)

best regards
 Waldemar

Re: regression for m68k/coldfire

[Waldemar Brodkorb]

Hi,
Laurent Vivier wrote,

> Le 03/02/2017 à 01:35, John Paul Adrian Glaubitz a écrit :
> > On 02/03/2017 01:10 AM, Greg Ungerer wrote:
> >> This is a limitation in the FEC support in QEMU.
> >> This works on real ColdFire hardware (which do support the
> >> FEC MIB stats registers from offset 0x200 - so not 5272).
> >> I sent this patch to the qemu dev list a couple of weeks
> >> back which fixes qemu:
> >>
> >>  http://lists.gnu.org/archive/html/qemu-devel/2017-01/msg01781.html
> >>
> >> I do not believe it has been picked up by QEMU mainline yet
> >> (I will probably have to resend and push a little to get that done).
> > 
> > QEMU upstream can sometimes take a while before they are merging patches,
> > but usually it helps containing the maintainer of this part of the
> > source tree directly.
> > 
> > Unfortunately, mcf5208 is currently unmaintained [1]:
> > 
> > mcf5208
> > S: Orphan
> > F: hw/m68k/mcf5208.c
> > F: hw/m68k/mcf_intc.c
> > F: hw/char/mcf_uart.c
> > F: hw/net/mcf_fec.c
> > 
> > But you can try getting into touch with Laurent Vivier who is the
> > new maintainer of the m68k target. I have CC'ed him.
> > 
> > Adrian
> > 
> >> [1] http://git.qemu.org/?p=qemu.git;a=blob;f=MAINTAINERS
> > 
> 
> Use scripts/get_maintainer.pl on your patch to find the people.
> 
> This patch is on the network part, so you should cc:
> Jason Wang  (odd fixer:Network devices)
> 
> If you cc me, you add more chances to have a review ;)

I tried the patch on top of 2.8.0 qemu release and it works for me
with Linux Kernel 4.9.
Thanks for the hint and patch!
I hope Greg's patch get included in the next qemu release.

Btw: Laurent, are you m68k with mmu support are going to be included
upstream? I always carry an old binary for any m68k with mmu testing.

best regards
 Waldemar

Re: regression for m68k/coldfire

[Waldemar Brodkorb]

Hi,
Laurent Vivier wrote,

> Le 03/02/2017 à 01:35, John Paul Adrian Glaubitz a écrit :
> > On 02/03/2017 01:10 AM, Greg Ungerer wrote:
> >> This is a limitation in the FEC support in QEMU.
> >> This works on real ColdFire hardware (which do support the
> >> FEC MIB stats registers from offset 0x200 - so not 5272).
> >> I sent this patch to the qemu dev list a couple of weeks
> >> back which fixes qemu:
> >>
> >>  http://lists.gnu.org/archive/html/qemu-devel/2017-01/msg01781.html
> >>
> >> I do not believe it has been picked up by QEMU mainline yet
> >> (I will probably have to resend and push a little to get that done).
> > 
> > QEMU upstream can sometimes take a while before they are merging patches,
> > but usually it helps containing the maintainer of this part of the
> > source tree directly.
> > 
> > Unfortunately, mcf5208 is currently unmaintained [1]:
> > 
> > mcf5208
> > S: Orphan
> > F: hw/m68k/mcf5208.c
> > F: hw/m68k/mcf_intc.c
> > F: hw/char/mcf_uart.c
> > F: hw/net/mcf_fec.c
> > 
> > But you can try getting into touch with Laurent Vivier who is the
> > new maintainer of the m68k target. I have CC'ed him.
> > 
> > Adrian
> > 
> >> [1] http://git.qemu.org/?p=qemu.git;a=blob;f=MAINTAINERS
> > 
> 
> Use scripts/get_maintainer.pl on your patch to find the people.
> 
> This patch is on the network part, so you should cc:
> Jason Wang  (odd fixer:Network devices)
> 
> If you cc me, you add more chances to have a review ;)

I tried the patch on top of 2.8.0 qemu release and it works for me
with Linux Kernel 4.9.
Thanks for the hint and patch!
I hope Greg's patch get included in the next qemu release.

Btw: Laurent, are you m68k with mmu support are going to be included
upstream? I always carry an old binary for any m68k with mmu testing.

best regards
 Waldemar

regression for m68k/coldfire

[Waldemar Brodkorb]

Hi,

your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux
booting in qemu-system-m68k:

qemu-system-m68k -nographic -M mcf5208evb -cpu m5208 -kernel 
qemu-m68k-mcf5208-initramfspiggyback-kernel

[0.00] Linux version 4.9.6-1 (wbx@vopenadk) (gcc version
5.4.0 (GCC) ) #2 Thu Feb 2 21:08:59 CET 2017
[0.00] uClinux with CPU COLDFIRE(m520x)
[0.00] COLDFIRE port done by Greg Ungerer, g...@snapgear.com
[0.00] Flat model support (C) 1998,1999 Kenneth Albanowski,
D. Jeff Dionne
[0.00] Built 1 zonelists in Zone order, mobility grouping
on.  Total pages: 16320
[0.00] Kernel command line: console=ttyS0,115200 ro
rootfstype=tmpfs
[0.00] PID hash table entries: 512 (order: -2, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 3,
65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 2, 32768
bytes)
[0.00] Memory: 127920K/131072K available (1292K kernel code,
96K rwdata, 216K rodata, 560K init, 179K bss, 3152K reserved, 0K
cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x4000 - 0x4400   (   1 KiB)
[0.00] kmap: 0x - 0x   (4095 MiB)
[0.00] vmalloc : 0x - 0x   (4095 MiB)
[0.00] lowmem  : 0x4000 - 0x4800   ( 128 MiB)
[0.00]   .init : 0x401b2000 - 0x4023e000   ( 560 KiB)
[0.00]   .text : 0x4002 - 0x40163350   (1293 KiB)
[0.00]   .data : 0x40163350 - 0x401b1640   ( 313 KiB)
[0.00]   .bss  : 0x4023e000 - 0x4026af04   ( 180 KiB)
[0.00] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1,
Nodes=8
[0.00] NR_IRQS:256
[0.00] clocksource: pit: mask: 0x max_cycles:
0x, max_idle_ns: 3669622406313 ns
[0.02] Calibrating delay loop... 238.38 BogoMIPS
(lpj=1191936)
[0.08] pid_max: default: 4096 minimum: 301
[0.08] Mount-cache hash table entries: 2048 (order: 0, 8192
bytes)
[0.08] Mountpoint-cache hash table entries: 2048 (order: 0,
8192 bytes)
[0.16] clocksource: jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 1911260446275 ns
[0.17] NET: Registered protocol family 16
[0.20] pps_core: LinuxPPS API ver. 1 registered
[0.20] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti 
[0.20] PTP clock support registered
[0.22] clocksource: Switched to clocksource pit
[0.23] NET: Registered protocol family 2
[0.24] TCP established hash table entries: 2048 (order: 0,
8192 bytes)
[0.24] TCP bind hash table entries: 2048 (order: 0, 8192
bytes)
[0.24] TCP: Hash tables configured (established 2048 bind
2048)
[0.24] UDP hash table entries: 512 (order: 0, 8192 bytes)
[0.24] UDP-Lite hash table entries: 512 (order: 0, 8192
bytes)
[0.25] NET: Registered protocol family 1
[2.56] random: fast init done
[3.40] futex hash table entries: 16 (order: -6, 192 bytes)
[3.40] workingset: timestamp_bits=27 max_order=14
bucket_order=0
[3.46] ColdFire internal UART serial driver
[3.47] mcfuart.0: ttyS0 at MMIO 0xfc06 (irq = 90,
base_baud = 208) is a ColdFire UART
[3.50] console [ttyS0] enabled
[3.50] mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91,
base_baud = 208) is a ColdFire UART
[3.51] mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92,
base_baud = 208) is a ColdFire UART
qemu: hardware error: mcf_fec_read: Bad address 0x200

CPU #0:
D0 = 0200   A0 = 4780fdec   F0 =  (   0)
D1 = 4780ff94   A1 = 401703de   F1 =  (   0)
D2 = 46dbb000   A2 = 4780f800   F2 =  (   0)
D3 = 4019d612   A3 = fc030200   F3 =  (   0)
D4 =    A4 = 4019d608   F4 =  (   0)
D5 = 40043f7a   A5 = 400222a0   F5 =  (   0)
D6 = 400df204   A6 = 4783de78   F6 =  (   0)
D7 = 401701c0   A7 = 4783de28   F7 =  (   0)
PC = 400e5ff2   SR = 2009 -N--C FPRESULT =0
Aborted
wbx@vopenadk:~/m68k/openadk$ 
wbx@vopenadk:~/m68k/openadk$ qemu-system-m68k --version
QEMU emulator version 2.8.0
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project
developers

Any ideas how to fix it?

best regards
 Waldemar

regression for m68k/coldfire

[Waldemar Brodkorb]

Hi,

your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux
booting in qemu-system-m68k:

qemu-system-m68k -nographic -M mcf5208evb -cpu m5208 -kernel 
qemu-m68k-mcf5208-initramfspiggyback-kernel

[0.00] Linux version 4.9.6-1 (wbx@vopenadk) (gcc version
5.4.0 (GCC) ) #2 Thu Feb 2 21:08:59 CET 2017
[0.00] uClinux with CPU COLDFIRE(m520x)
[0.00] COLDFIRE port done by Greg Ungerer, g...@snapgear.com
[0.00] Flat model support (C) 1998,1999 Kenneth Albanowski,
D. Jeff Dionne
[0.00] Built 1 zonelists in Zone order, mobility grouping
on.  Total pages: 16320
[0.00] Kernel command line: console=ttyS0,115200 ro
rootfstype=tmpfs
[0.00] PID hash table entries: 512 (order: -2, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 3,
65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 2, 32768
bytes)
[0.00] Memory: 127920K/131072K available (1292K kernel code,
96K rwdata, 216K rodata, 560K init, 179K bss, 3152K reserved, 0K
cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x4000 - 0x4400   (   1 KiB)
[0.00] kmap: 0x - 0x   (4095 MiB)
[0.00] vmalloc : 0x - 0x   (4095 MiB)
[0.00] lowmem  : 0x4000 - 0x4800   ( 128 MiB)
[0.00]   .init : 0x401b2000 - 0x4023e000   ( 560 KiB)
[0.00]   .text : 0x4002 - 0x40163350   (1293 KiB)
[0.00]   .data : 0x40163350 - 0x401b1640   ( 313 KiB)
[0.00]   .bss  : 0x4023e000 - 0x4026af04   ( 180 KiB)
[0.00] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1,
Nodes=8
[0.00] NR_IRQS:256
[0.00] clocksource: pit: mask: 0x max_cycles:
0x, max_idle_ns: 3669622406313 ns
[0.02] Calibrating delay loop... 238.38 BogoMIPS
(lpj=1191936)
[0.08] pid_max: default: 4096 minimum: 301
[0.08] Mount-cache hash table entries: 2048 (order: 0, 8192
bytes)
[0.08] Mountpoint-cache hash table entries: 2048 (order: 0,
8192 bytes)
[0.16] clocksource: jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 1911260446275 ns
[0.17] NET: Registered protocol family 16
[0.20] pps_core: LinuxPPS API ver. 1 registered
[0.20] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti 
[0.20] PTP clock support registered
[0.22] clocksource: Switched to clocksource pit
[0.23] NET: Registered protocol family 2
[0.24] TCP established hash table entries: 2048 (order: 0,
8192 bytes)
[0.24] TCP bind hash table entries: 2048 (order: 0, 8192
bytes)
[0.24] TCP: Hash tables configured (established 2048 bind
2048)
[0.24] UDP hash table entries: 512 (order: 0, 8192 bytes)
[0.24] UDP-Lite hash table entries: 512 (order: 0, 8192
bytes)
[0.25] NET: Registered protocol family 1
[2.56] random: fast init done
[3.40] futex hash table entries: 16 (order: -6, 192 bytes)
[3.40] workingset: timestamp_bits=27 max_order=14
bucket_order=0
[3.46] ColdFire internal UART serial driver
[3.47] mcfuart.0: ttyS0 at MMIO 0xfc06 (irq = 90,
base_baud = 208) is a ColdFire UART
[3.50] console [ttyS0] enabled
[3.50] mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91,
base_baud = 208) is a ColdFire UART
[3.51] mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92,
base_baud = 208) is a ColdFire UART
qemu: hardware error: mcf_fec_read: Bad address 0x200

CPU #0:
D0 = 0200   A0 = 4780fdec   F0 =  (   0)
D1 = 4780ff94   A1 = 401703de   F1 =  (   0)
D2 = 46dbb000   A2 = 4780f800   F2 =  (   0)
D3 = 4019d612   A3 = fc030200   F3 =  (   0)
D4 =    A4 = 4019d608   F4 =  (   0)
D5 = 40043f7a   A5 = 400222a0   F5 =  (   0)
D6 = 400df204   A6 = 4783de78   F6 =  (   0)
D7 = 401701c0   A7 = 4783de28   F7 =  (   0)
PC = 400e5ff2   SR = 2009 -N--C FPRESULT =0
Aborted
wbx@vopenadk:~/m68k/openadk$ 
wbx@vopenadk:~/m68k/openadk$ qemu-system-m68k --version
QEMU emulator version 2.8.0
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project
developers

Any ideas how to fix it?

best regards
 Waldemar

regression for cris architecture

[Waldemar Brodkorb]

Hi,

I am regulary running some tests with qemu-system-cris, but getting following
stacktraces on boot now (with 4.8.6, 4.7.9 worked fine):

[7.260691] Unable to handle kernel NULL pointer dereference
[7.260919] Linux 4.8.6-1 #4 Sun Nov 6 17:48:18 CET 2016
[7.260955] Oops: 
[7.260999] CPU: 0  
[7.261064] ERP: c0024b82 SRP: c0024b7a  CCS: 0e00a008 USP: af9dfd24 MOF: 
e79a1af9
[7.261110]  r0:   r1:    r2: c020091a  r3: c004da14
[7.261161]  r4: c0084714  r5: c04522b4   r6: c00441f2  r7: c004351a
[7.261214]  r8: c00435c2  r9: c1e5fdc0  r10: c1e5fdbc r11: 
[7.261265] r12: c00b6ee0 r13: c1e5fdc4 oR10: c1e5fdbc acr: c1e5fdc0
[7.261286]  sp: c1e5fd50
[7.261311]Data MMU Cause: 0117
[7.261334] Instruction MMU Cause: 3aaca017
[7.261379] Process mkdir (pid: 26, stackpage=c1f0f440)
[7.261439]
[7.261439] Stack from af9dfd24:
[7.261439]
[7.261516] 0004 0012
[7.261567] 0001 
[7.261591]  0001
[7.261615] 41ed 0010
[7.261644]
[7.261644]
[7.261683]  
[7.261707]  
[7.261729]  
[7.261754] 2000
[7.261762]
[7.261774]  
[7.261797]  08583b00
[7.261822] 0002 3ab1bbe0
[7.261850] 3ab0c238 3aac93b2
[7.261895]
[7.261895] Call Trace:
[7.262003] Stack from c1e5fc54:
[7.262003]
[7.262021] c1e5fd50 c00047b8
[7.262049] af9dfd24 c1e5fd9c
[7.262077] 3aaca017 c000553e
[7.262105] c1e5fdc0 e79a1af9
[7.262128]
[7.262128]c0042a70
[7.262155] c01c00c4 
[7.262181] c1e5fd50 c1e401b4
[7.262208] c00048da 
[7.262233] c1e5fd50
[7.262241]
[7.262256] c1f0f440 
[7.262281] c0004f9c 00c02008
[7.262306]  
[7.262331] c020091a c004da14
[7.262355]
[7.262355] Call Trace: [] show_stack+0x0/0x8c
[7.263279] [] show_registers+0x14e/0x1c6
[7.263314] [] printk+0x0/0x2c
[7.263345] [] die_if_kernel+0x6c/0x96
[7.263383] [] do_page_fault+0x2c6/0x34a
[7.263417] [] __put_page+0x0/0x40
[7.263464] [] simple_readpage+0x0/0x72
[7.263500] [] pagecache_get_page+0x0/0x1c6
[7.263532] [] unlock_page+0x0/0x3c
[7.263563] [] __lock_page+0x0/0x74
[7.263598] [] down_read+0x0/0x12
[7.263635] [] find_vma+0x12/0x54
[7.263665] [] up_read+0xc/0x12
[7.263696] [] do_page_fault+0x1c4/0x34a
[7.263731] [] d_mmu_refill+0x10a/0x112
[7.263761] [] __put_page+0x0/0x40
[7.263793] [] simple_readpage+0x0/0x72
[7.263827] [] pagecache_get_page+0x0/0x1c6
[7.263859] [] unlock_page+0x0/0x3c
[7.263890] [] __lock_page+0x0/0x74
[7.263925] [] memset+0xf6/0x138
[7.263961] [] __wake_up_bit+0x1c/0x44
[7.263996] [] __wake_up_bit+0x24/0x44
[7.264029] [] unlock_page+0x34/0x3c
[7.264060] [] simple_readpage+0x6a/0x72
[7.264095] [] do_read_cache_page+0xaa/0x252
[7.264125] [] page_get_link+0x0/0xcc
[7.264154] [] path_put+0x0/0x24
[7.264187] [] read_cache_page+0x18/0x20
[7.264218] [] page_get_link+0x80/0xcc
[7.264250] [] trailing_symlink+0x12a/0x184
[7.264281] [] link_path_walk+0x0/0x358
[7.264311] [] path_lookupat+0x84/0xe8
[7.264341] [] path_lookupat+0x0/0xe8
[7.264372] [] user_path_at_empty+0x0/0x3e
[7.264404] [] vfs_getattr_nosec+0x0/0x32
[7.264436] [] filename_lookup+0x5c/0xa6
[7.264469] [] getname_flags+0x22/0x170
[7.264500] [] user_path_at_empty+0x32/0x3e
[7.264533] [] vfs_fstatat+0x4a/0x88
[7.264566] [] vfs_stat+0x14/0x1a
[7.264630] [] SyS_stat64+0x16/0x32
[7.264662] [] filename_create+0x0/0xf4
[7.264694] [] SyS_mkdirat+0x3e/0xa6
[7.264725] [] SyS_mkdir+0x14/0x1a
[7.264756] [] _syscall_traced+0x22/0x2a
[7.264773]
[7.264773] Code: 09 00 2e a6 0c e1 ef 2b 10 e1 ef 1b (60) fa ef 06 12 30 4c 
d2 2e d6 41 c2
[7.265174] ---[ end trace 7fbf74436dc80fa8 ]---
..


I bisected it and the error occurs since commit:
commit 599d0c954f91d0689c9bb421b5bc04ea02437a41
Author: Mel Gorman 
Date:   Thu Jul 28 15:45:31 2016 -0700

mm, vmscan: move LRU lists to node

Any idea how to fix this?

best regards
 Waldemar

regression for cris architecture

[Waldemar Brodkorb]

Hi,

I am regulary running some tests with qemu-system-cris, but getting following
stacktraces on boot now (with 4.8.6, 4.7.9 worked fine):

[7.260691] Unable to handle kernel NULL pointer dereference
[7.260919] Linux 4.8.6-1 #4 Sun Nov 6 17:48:18 CET 2016
[7.260955] Oops: 
[7.260999] CPU: 0  
[7.261064] ERP: c0024b82 SRP: c0024b7a  CCS: 0e00a008 USP: af9dfd24 MOF: 
e79a1af9
[7.261110]  r0:   r1:    r2: c020091a  r3: c004da14
[7.261161]  r4: c0084714  r5: c04522b4   r6: c00441f2  r7: c004351a
[7.261214]  r8: c00435c2  r9: c1e5fdc0  r10: c1e5fdbc r11: 
[7.261265] r12: c00b6ee0 r13: c1e5fdc4 oR10: c1e5fdbc acr: c1e5fdc0
[7.261286]  sp: c1e5fd50
[7.261311]Data MMU Cause: 0117
[7.261334] Instruction MMU Cause: 3aaca017
[7.261379] Process mkdir (pid: 26, stackpage=c1f0f440)
[7.261439]
[7.261439] Stack from af9dfd24:
[7.261439]
[7.261516] 0004 0012
[7.261567] 0001 
[7.261591]  0001
[7.261615] 41ed 0010
[7.261644]
[7.261644]
[7.261683]  
[7.261707]  
[7.261729]  
[7.261754] 2000
[7.261762]
[7.261774]  
[7.261797]  08583b00
[7.261822] 0002 3ab1bbe0
[7.261850] 3ab0c238 3aac93b2
[7.261895]
[7.261895] Call Trace:
[7.262003] Stack from c1e5fc54:
[7.262003]
[7.262021] c1e5fd50 c00047b8
[7.262049] af9dfd24 c1e5fd9c
[7.262077] 3aaca017 c000553e
[7.262105] c1e5fdc0 e79a1af9
[7.262128]
[7.262128]c0042a70
[7.262155] c01c00c4 
[7.262181] c1e5fd50 c1e401b4
[7.262208] c00048da 
[7.262233] c1e5fd50
[7.262241]
[7.262256] c1f0f440 
[7.262281] c0004f9c 00c02008
[7.262306]  
[7.262331] c020091a c004da14
[7.262355]
[7.262355] Call Trace: [] show_stack+0x0/0x8c
[7.263279] [] show_registers+0x14e/0x1c6
[7.263314] [] printk+0x0/0x2c
[7.263345] [] die_if_kernel+0x6c/0x96
[7.263383] [] do_page_fault+0x2c6/0x34a
[7.263417] [] __put_page+0x0/0x40
[7.263464] [] simple_readpage+0x0/0x72
[7.263500] [] pagecache_get_page+0x0/0x1c6
[7.263532] [] unlock_page+0x0/0x3c
[7.263563] [] __lock_page+0x0/0x74
[7.263598] [] down_read+0x0/0x12
[7.263635] [] find_vma+0x12/0x54
[7.263665] [] up_read+0xc/0x12
[7.263696] [] do_page_fault+0x1c4/0x34a
[7.263731] [] d_mmu_refill+0x10a/0x112
[7.263761] [] __put_page+0x0/0x40
[7.263793] [] simple_readpage+0x0/0x72
[7.263827] [] pagecache_get_page+0x0/0x1c6
[7.263859] [] unlock_page+0x0/0x3c
[7.263890] [] __lock_page+0x0/0x74
[7.263925] [] memset+0xf6/0x138
[7.263961] [] __wake_up_bit+0x1c/0x44
[7.263996] [] __wake_up_bit+0x24/0x44
[7.264029] [] unlock_page+0x34/0x3c
[7.264060] [] simple_readpage+0x6a/0x72
[7.264095] [] do_read_cache_page+0xaa/0x252
[7.264125] [] page_get_link+0x0/0xcc
[7.264154] [] path_put+0x0/0x24
[7.264187] [] read_cache_page+0x18/0x20
[7.264218] [] page_get_link+0x80/0xcc
[7.264250] [] trailing_symlink+0x12a/0x184
[7.264281] [] link_path_walk+0x0/0x358
[7.264311] [] path_lookupat+0x84/0xe8
[7.264341] [] path_lookupat+0x0/0xe8
[7.264372] [] user_path_at_empty+0x0/0x3e
[7.264404] [] vfs_getattr_nosec+0x0/0x32
[7.264436] [] filename_lookup+0x5c/0xa6
[7.264469] [] getname_flags+0x22/0x170
[7.264500] [] user_path_at_empty+0x32/0x3e
[7.264533] [] vfs_fstatat+0x4a/0x88
[7.264566] [] vfs_stat+0x14/0x1a
[7.264630] [] SyS_stat64+0x16/0x32
[7.264662] [] filename_create+0x0/0xf4
[7.264694] [] SyS_mkdirat+0x3e/0xa6
[7.264725] [] SyS_mkdir+0x14/0x1a
[7.264756] [] _syscall_traced+0x22/0x2a
[7.264773]
[7.264773] Code: 09 00 2e a6 0c e1 ef 2b 10 e1 ef 1b (60) fa ef 06 12 30 4c 
d2 2e d6 41 c2
[7.265174] ---[ end trace 7fbf74436dc80fa8 ]---
..


I bisected it and the error occurs since commit:
commit 599d0c954f91d0689c9bb421b5bc04ea02437a41
Author: Mel Gorman 
Date:   Thu Jul 28 15:45:31 2016 -0700

mm, vmscan: move LRU lists to node

Any idea how to fix this?

best regards
 Waldemar

Re: qemu m68k/mcf5208: problem with signal handler

[Waldemar Brodkorb]

Hi Greg,
Greg Ungerer wrote,

> >>What do you think? Is it a Kernel bug or a C library problem?
> 
> What version of linux kernel?

4.5.3

> What version of gcc?

4.9.3
 
> This sounds a lot like the problem I fixed in linux commit a9551799
> ("m68k: Use conventional function parameters for do_sigreturn").
> 
> Definitely try that first.

Jackpot. Thanks a lot. This works!
May be some candidate for LTS kernels.

best regards
 Waldemar

Re: qemu m68k/mcf5208: problem with signal handler

[Waldemar Brodkorb]

Hi Greg,
Greg Ungerer wrote,

> >>What do you think? Is it a Kernel bug or a C library problem?
> 
> What version of linux kernel?

4.5.3

> What version of gcc?

4.9.3
 
> This sounds a lot like the problem I fixed in linux commit a9551799
> ("m68k: Use conventional function parameters for do_sigreturn").
> 
> Definitely try that first.

Jackpot. Thanks a lot. This works!
May be some candidate for LTS kernels.

best regards
 Waldemar

Re: qemu m68k/mcf5208: problem with signal handler

[Waldemar Brodkorb]

Hi,

forgot to add Greg in CC.
And sorry for the whitespace fuckup in the example code.

Waldemar Brodkorb wrote,

> Dear kernel hackers,
> 
> I have a problem with the signal handling under qemu-system-m68k
> emulating coldfire mcf5208 evalboard. Following example code
> provided by Busybox maintainer Denys Vlasenko
> shows the problem when running on qemu:

[ .. ]

> You can generate a bootable image with latest buildroot, which shows the 
> issue:
> $ git clone git://git.buildroot.net/buildroot
> $ cd buildroot; make qemu_m68k_mcf5208_defconfig; make
> $ qemu-system-m68k -M mcf5208evb -cpu m5208 -kernel output/images/vmlinux 
> -nographic
> 
> Every command forked from busybox hush shell will lead into a segmentation 
> fault.
> 
> I added following printk to start investigating the problem:
> diff -Nur linux-4.5.3.orig/arch/m68k/kernel/signal.c 
> linux-4.5.3/arch/m68k/kernel/signal.c
> --- linux-4.5.3.orig/arch/m68k/kernel/signal.c2016-05-04 
> 23:50:38.0 +0200
> +++ linux-4.5.3/arch/m68k/kernel/signal.c 2016-05-09 04:24:53.885199544 
> +0200
> @@ -595,6 +595,7 @@
>  void __user *fp)
>  {
>   int fsize = frame_extra_sizes(formatvec >> 12);
> + printk("avoid broken signal handler...\n");
>   if (fsize < 0) {
>   /*
>* user process trying to return with weird frame format
> 
> But now the problem disappeared. :/
> 
> What do you think? Is it a Kernel bug or a C library problem?
> 
> Busybox hush otherwise works fine for other noMMU targets as stm32
> evalboard with cortex-m4. It also works in Qemu M68k emulating Q800
> full MMU system.
> 
> Thanks for any ideas,
>  Waldemar
> 
> http://lists.busybox.net/pipermail/busybox/2014-September/081659.html
> 

Re: qemu m68k/mcf5208: problem with signal handler

[Waldemar Brodkorb]

Hi,

forgot to add Greg in CC.
And sorry for the whitespace fuckup in the example code.

Waldemar Brodkorb wrote,

> Dear kernel hackers,
> 
> I have a problem with the signal handling under qemu-system-m68k
> emulating coldfire mcf5208 evalboard. Following example code
> provided by Busybox maintainer Denys Vlasenko
> shows the problem when running on qemu:

[ .. ]

> You can generate a bootable image with latest buildroot, which shows the 
> issue:
> $ git clone git://git.buildroot.net/buildroot
> $ cd buildroot; make qemu_m68k_mcf5208_defconfig; make
> $ qemu-system-m68k -M mcf5208evb -cpu m5208 -kernel output/images/vmlinux 
> -nographic
> 
> Every command forked from busybox hush shell will lead into a segmentation 
> fault.
> 
> I added following printk to start investigating the problem:
> diff -Nur linux-4.5.3.orig/arch/m68k/kernel/signal.c 
> linux-4.5.3/arch/m68k/kernel/signal.c
> --- linux-4.5.3.orig/arch/m68k/kernel/signal.c2016-05-04 
> 23:50:38.0 +0200
> +++ linux-4.5.3/arch/m68k/kernel/signal.c 2016-05-09 04:24:53.885199544 
> +0200
> @@ -595,6 +595,7 @@
>  void __user *fp)
>  {
>   int fsize = frame_extra_sizes(formatvec >> 12);
> + printk("avoid broken signal handler...\n");
>   if (fsize < 0) {
>   /*
>* user process trying to return with weird frame format
> 
> But now the problem disappeared. :/
> 
> What do you think? Is it a Kernel bug or a C library problem?
> 
> Busybox hush otherwise works fine for other noMMU targets as stm32
> evalboard with cortex-m4. It also works in Qemu M68k emulating Q800
> full MMU system.
> 
> Thanks for any ideas,
>  Waldemar
> 
> http://lists.busybox.net/pipermail/busybox/2014-September/081659.html
> 

qemu m68k/mcf5208: problem with signal handler

[Waldemar Brodkorb]

Dear kernel hackers,

I have a problem with the signal handling under qemu-system-m68k
emulating coldfire mcf5208 evalboard. Following example code
provided by Busybox maintainer Denys Vlasenko
shows the problem when running on qemu:

#include  

   
#include  

   
#include   

   
#include

   
static void sighandler(int sig) 

   
{   

   
write(1, "SIGNAL\n", 7);

   
}   

   
int main()  

   
{   

   
int pid;

   


   
write(1, "VFORK1\n", 7);

   
pid = vfork();  

   
if (pid == 0) { 

   
write(1, "EXIT1\n", 6); 

   
_exit(1);   

   
}   

   
wait(NULL); 

   
signal(SIGCHLD, sighandler);

   
write(1, "VFORK2\n", 7);

   
pid = vfork();  

   
if (pid == 0) { 

   
write(1, "EXIT2\n", 6); 

   
_exit(1);   

   
}   

   
wait(NULL); 

   
write(1, "EXIT\n", 5);  

   
return 0;

qemu m68k/mcf5208: problem with signal handler

[Waldemar Brodkorb]

Dear kernel hackers,

I have a problem with the signal handling under qemu-system-m68k
emulating coldfire mcf5208 evalboard. Following example code
provided by Busybox maintainer Denys Vlasenko
shows the problem when running on qemu:

#include  

   
#include  

   
#include   

   
#include

   
static void sighandler(int sig) 

   
{   

   
write(1, "SIGNAL\n", 7);

   
}   

   
int main()  

   
{   

   
int pid;

   


   
write(1, "VFORK1\n", 7);

   
pid = vfork();  

   
if (pid == 0) { 

   
write(1, "EXIT1\n", 6); 

   
_exit(1);   

   
}   

   
wait(NULL); 

   
signal(SIGCHLD, sighandler);

   
write(1, "VFORK2\n", 7);

   
pid = vfork();  

   
if (pid == 0) { 

   
write(1, "EXIT2\n", 6); 

   
_exit(1);   

   
}   

   
wait(NULL); 

   
write(1, "EXIT\n", 5);  

   
return 0;

Re: [uClinux-dev] m68k compile issue with 4.0.5

[Waldemar Brodkorb]

Hi Greg,
Greg Ungerer wrote,
> 
> I don't have any compile (or runtime) problems with m5208evb_defconfig
> on linux-4.0.5 either. That is close to what most people use with qemu.
> What .config are you using?

Are you sure the defconfig creates a bootable image?

I still need at least two patches.

http://cgit.openadk.org/cgi/cgit/openadk.git/tree/target/m68k/qemu-m68k/patches/4.0.5/qemu-coldfire.patch
Without this one I get black screen.

http://cgit.openadk.org/cgi/cgit/openadk.git/tree/target/m68k/qemu-m68k/patches/4.0.5/m68k-coldfire-fec.patch
Without this one I get 
qemu: hardware error: mcf_fec_read: Bad address 0x1c4
...
Abort

Networking still does not work for me after booting with the two
patches applied:
fec fec.0 (unnamed net_device) (uninitialized): MDIO read timeout
fec: probe of fec.0 failed with error -5

Any idea?

best regards
 Waldemar

--
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: m68k compile issue with 4.0.5

[Waldemar Brodkorb]

Hi Geert,
Geert Uytterhoeven wrote,

> Hi Waldemar,
> 
> On Mon, Jun 15, 2015 at 10:23 PM, Waldemar Brodkorb  wrote:
> > I am trying to build a M68K (Coldfire no-MMU) kernel for Qemu-system-m68k.
> > Any idea what change breaks the compile?
> 
> I tried a few m68knommu defconfigs, but can't reproduce it.
> 
> Is this a plain v4.0.5? I can't find the offending call to vma_fput().
> "git grep vma_fput" tells me there's no "vma_fput" in the kernel sources?

You are totally right. It is not plain vanilla, I am really sorry
about this ugly bug report. I normally use an option to disable any
external kernel patches, before reporting. I missed it this time.

I have experimented with aufs4 kernel patches lately.

You are allowed to kick my ass ;)

best regards
 Waldemar

--
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: m68k compile issue with 4.0.5

[Waldemar Brodkorb]

Hi Geert,
Geert Uytterhoeven wrote,

 Hi Waldemar,
 
 On Mon, Jun 15, 2015 at 10:23 PM, Waldemar Brodkorb w...@openadk.org wrote:
  I am trying to build a M68K (Coldfire no-MMU) kernel for Qemu-system-m68k.
  Any idea what change breaks the compile?
 
 I tried a few m68knommu defconfigs, but can't reproduce it.
 
 Is this a plain v4.0.5? I can't find the offending call to vma_fput().
 git grep vma_fput tells me there's no vma_fput in the kernel sources?

You are totally right. It is not plain vanilla, I am really sorry
about this ugly bug report. I normally use an option to disable any
external kernel patches, before reporting. I missed it this time.

I have experimented with aufs4 kernel patches lately.

You are allowed to kick my ass ;)

best regards
 Waldemar

--
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: [uClinux-dev] m68k compile issue with 4.0.5

[Waldemar Brodkorb]

Hi Greg,
Greg Ungerer wrote,
 
 I don't have any compile (or runtime) problems with m5208evb_defconfig
 on linux-4.0.5 either. That is close to what most people use with qemu.
 What .config are you using?

Are you sure the defconfig creates a bootable image?

I still need at least two patches.

http://cgit.openadk.org/cgi/cgit/openadk.git/tree/target/m68k/qemu-m68k/patches/4.0.5/qemu-coldfire.patch
Without this one I get black screen.

http://cgit.openadk.org/cgi/cgit/openadk.git/tree/target/m68k/qemu-m68k/patches/4.0.5/m68k-coldfire-fec.patch
Without this one I get 
qemu: hardware error: mcf_fec_read: Bad address 0x1c4
...
Abort

Networking still does not work for me after booting with the two
patches applied:
fec fec.0 (unnamed net_device) (uninitialized): MDIO read timeout
fec: probe of fec.0 failed with error -5

Any idea?

best regards
 Waldemar

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

m68k compile issue with 4.0.5

[Waldemar Brodkorb]

Hi,

I am trying to build a M68K (Coldfire no-MMU) kernel for Qemu-system-m68k.

With 4.0.4 everything is fine. With 4.0.5 I get following compile
error:
  adk-uclinux-gcc -Wp,-MD,mm/.nommu.o.d  -nostdinc -isystem
/home/wbx/m68k/toolchain_qemu-m68k_uclibc-ng_m68k_nommu/usr/lib/gcc/m68k-openadk-uclinux-uclibc/4.9.2/include
-I./arch/m68k/include -Iarch/m68k/include/generated/uapi
-Iarch/m68k/include/generated  -Iinclude -I./arch/m68k/include/uapi
-Iarch/m68k/include/generated/uapi -I./include/uapi
-Iinclude/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-std=gnu89 -mcpu=5208 -pipe -DUTS_SYSNAME=\"uClinux\" -D__uClinux__
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized
--param=allow-store-data-races=0 -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable
-fomit-frame-pointer -fno-var-tracking-assignments
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
-Werror=date-time -DCC_HAVE_ASM_GOTO-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(nommu)"
-D"KBUILD_MODNAME=KBUILD_STR(nommu)" -c -o mm/nommu.o mm/nommu.c
mm/nommu.c: In function 'delete_vma':
mm/nommu.c:861:3: error: implicit declaration of function 'vma_fput'
[-Werror=implicit-function-declaration]
   vma_fput(vma);
   ^
cc1: some warnings being treated as errors

Any idea what change breaks the compile?

best regards
 Waldemar


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

m68k compile issue with 4.0.5

[Waldemar Brodkorb]

Hi,

I am trying to build a M68K (Coldfire no-MMU) kernel for Qemu-system-m68k.

With 4.0.4 everything is fine. With 4.0.5 I get following compile
error:
  adk-uclinux-gcc -Wp,-MD,mm/.nommu.o.d  -nostdinc -isystem
/home/wbx/m68k/toolchain_qemu-m68k_uclibc-ng_m68k_nommu/usr/lib/gcc/m68k-openadk-uclinux-uclibc/4.9.2/include
-I./arch/m68k/include -Iarch/m68k/include/generated/uapi
-Iarch/m68k/include/generated  -Iinclude -I./arch/m68k/include/uapi
-Iarch/m68k/include/generated/uapi -I./include/uapi
-Iinclude/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-std=gnu89 -mcpu=5208 -pipe -DUTS_SYSNAME=\uClinux\ -D__uClinux__
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized
--param=allow-store-data-races=0 -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable
-fomit-frame-pointer -fno-var-tracking-assignments
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
-Werror=date-time -DCC_HAVE_ASM_GOTO-DKBUILD_STR(s)=#s
-DKBUILD_BASENAME=KBUILD_STR(nommu)
-DKBUILD_MODNAME=KBUILD_STR(nommu) -c -o mm/nommu.o mm/nommu.c
mm/nommu.c: In function 'delete_vma':
mm/nommu.c:861:3: error: implicit declaration of function 'vma_fput'
[-Werror=implicit-function-declaration]
   vma_fput(vma);
   ^
cc1: some warnings being treated as errors

Any idea what change breaks the compile?

best regards
 Waldemar


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

Re: [RFC PATCH 8/8] Revert "percpu: free percpu allocation info for uniprocessor system"

[Waldemar Brodkorb]

Hi Guenter,
Guenter Roeck wrote,

> On 09/21/2014 10:23 AM, Mikael Starvik wrote:
> >Thanks for all your work with CRIS! CRISv10 is alive but is currently used 
> >as small helper CPUs close to hardware blocks.
> >
> 
> You are welcome. Now it would be even better if we could get the upstream 
> code to work
> with qemu. Which leads to the questions - is CRISv32 alive, and is there a 
> chance
> to get there ? Also, if CRISv10 is alive, is there any interest or even 
> benefit to
> maintain it in the latest kernel ? Because if not, we might as well drop v10 
> support
> to simplify kernel maintenance.

Please do not drop crisv10 support.
Don't kill my foxboard lx cluster ;)

http://www.openadk.org/cris/cris1.jpg
http://www.openadk.org/cris/cris2.jpg

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

Re: [RFC PATCH 8/8] Revert percpu: free percpu allocation info for uniprocessor system

[Waldemar Brodkorb]

Hi Guenter,
Guenter Roeck wrote,

 On 09/21/2014 10:23 AM, Mikael Starvik wrote:
 Thanks for all your work with CRIS! CRISv10 is alive but is currently used 
 as small helper CPUs close to hardware blocks.
 
 
 You are welcome. Now it would be even better if we could get the upstream 
 code to work
 with qemu. Which leads to the questions - is CRISv32 alive, and is there a 
 chance
 to get there ? Also, if CRISv10 is alive, is there any interest or even 
 benefit to
 maintain it in the latest kernel ? Because if not, we might as well drop v10 
 support
 to simplify kernel maintenance.

Please do not drop crisv10 support.
Don't kill my foxboard lx cluster ;)

http://www.openadk.org/cris/cris1.jpg
http://www.openadk.org/cris/cris2.jpg

best regards, 
 Waldemar
 
--
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 v2] MIPS: rb532: fix reregistering of serial console

[Waldemar Brodkorb]

Runtime tested on Mikrotik RB532 board.
Thanks goes to Geert Uytterhoeven for the explanation of the problem.

"I'm afraid this is not gonna help. When the port is unregistered,
its type will be reset to PORT_UNKNOWN.
So before registering it again, its type must be set again the actual
serial driver, cfr. the change to of_serial.c."

Signed-off-by: Waldemar Brodkorb 
Reviewed-by: Florian Fainelli 
---
 arch/mips/rb532/devices.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c
index 3af00b2..ba61268 100644
--- a/arch/mips/rb532/devices.c
+++ b/arch/mips/rb532/devices.c
@@ -223,6 +223,7 @@ static struct platform_device rb532_wdt = {
 
 static struct plat_serial8250_port rb532_uart_res[] = {
{
+   .type   = PORT_16550A,
.membase= (char *)KSEG1ADDR(REGBASE + UART0BASE),
.irq= UART0_IRQ,
.regshift   = 2,
-- 
1.7.10.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/

[PATCH v2] MIPS: rb532: fix reregistering of serial console

[Waldemar Brodkorb]

Runtime tested on Mikrotik RB532 board.
Thanks goes to Geert Uytterhoeven for the explanation of the problem.

I'm afraid this is not gonna help. When the port is unregistered,
its type will be reset to PORT_UNKNOWN.
So before registering it again, its type must be set again the actual
serial driver, cfr. the change to of_serial.c.

Signed-off-by: Waldemar Brodkorb w...@openadk.org
Reviewed-by: Florian Fainelli flor...@openwrt.org
---
 arch/mips/rb532/devices.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c
index 3af00b2..ba61268 100644
--- a/arch/mips/rb532/devices.c
+++ b/arch/mips/rb532/devices.c
@@ -223,6 +223,7 @@ static struct platform_device rb532_wdt = {
 
 static struct plat_serial8250_port rb532_uart_res[] = {
{
+   .type   = PORT_16550A,
.membase= (char *)KSEG1ADDR(REGBASE + UART0BASE),
.irq= UART0_IRQ,
.regshift   = 2,
-- 
1.7.10.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/

[PATCH] fix reregistering of serial console

[Waldemar Brodkorb]

Runtime tested on Mikrotik RB532 board.
Thanks goes to Geert Uytterhoeven for the explanation of the problem.

"I'm afraid this is not gonna help. When the port is unregistered,
its type will be reset to PORT_UNKNOWN.
So before registering it again, its type must be set again the actual
serial driver, cfr. the change to of_serial.c."

Signed-off-by: Waldemar Brodkorb 
---
 arch/mips/rb532/devices.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c
index 3af00b2..ba61268 100644
--- a/arch/mips/rb532/devices.c
+++ b/arch/mips/rb532/devices.c
@@ -223,6 +223,7 @@ static struct platform_device rb532_wdt = {
 
 static struct plat_serial8250_port rb532_uart_res[] = {
{
+   .type   = PORT_16550A,
.membase= (char *)KSEG1ADDR(REGBASE + UART0BASE),
.irq= UART0_IRQ,
.regshift   = 2,
-- 
1.7.10.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/

[PATCH] fix reregistering of serial console

[Waldemar Brodkorb]

Runtime tested on Mikrotik RB532 board.
Thanks goes to Geert Uytterhoeven for the explanation of the problem.

I'm afraid this is not gonna help. When the port is unregistered,
its type will be reset to PORT_UNKNOWN.
So before registering it again, its type must be set again the actual
serial driver, cfr. the change to of_serial.c.

Signed-off-by: Waldemar Brodkorb w...@openadk.org
---
 arch/mips/rb532/devices.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c
index 3af00b2..ba61268 100644
--- a/arch/mips/rb532/devices.c
+++ b/arch/mips/rb532/devices.c
@@ -223,6 +223,7 @@ static struct platform_device rb532_wdt = {
 
 static struct plat_serial8250_port rb532_uart_res[] = {
{
+   .type   = PORT_16550A,
.membase= (char *)KSEG1ADDR(REGBASE + UART0BASE),
.irq= UART0_IRQ,
.regshift   = 2,
-- 
1.7.10.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: oops on cubox-i (v3.15-rc4)

[Waldemar Brodkorb]

Hi Again,
> > > > 
> > > > On Fri, May 09, 2014 at 04:44:38PM +0200, Waldemar Brodkorb wrote:
> > > > > Dear Kernel Hackers,
> > > > > 
> > > > > I am getting kernel oopses on my cubox-i (i2ultra) running
> > > > > Linux 3.15-rc4, when using the box as a samba server with 
> > > > > a local attached 8 GB usb stick. (it also happen with a smaller
> > > > > video on the micro-sd card)
> > > > > The oops happens while playing a movie (4 GB file) on a samba client 
> > > > > (macos x maverick macbook) via vlc (after 5-15 minutes). 
> > > > > 
> > > > > Both systems are connected to a gigabit ethernet switch.
> > > > > 
> > > > > The oops happens with ntfs-3g, ntfs, vfat and ext4 filesystem.

The problem is gone with rc7.
It seems just like a cold, after seven rc'ays it's gone.

Sorry for the noise.
best regards
Waldemar 
--
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: oops on cubox-i (v3.15-rc4)

[Waldemar Brodkorb]

Hi Again,

On Fri, May 09, 2014 at 04:44:38PM +0200, Waldemar Brodkorb wrote:
 Dear Kernel Hackers,
 
 I am getting kernel oopses on my cubox-i (i2ultra) running
 Linux 3.15-rc4, when using the box as a samba server with 
 a local attached 8 GB usb stick. (it also happen with a smaller
 video on the micro-sd card)
 The oops happens while playing a movie (4 GB file) on a samba client 
 (macos x maverick macbook) via vlc (after 5-15 minutes). 
 
 Both systems are connected to a gigabit ethernet switch.
 
 The oops happens with ntfs-3g, ntfs, vfat and ext4 filesystem.

The problem is gone with rc7.
It seems just like a cold, after seven rc'ays it's gone.

Sorry for the noise.
best regards
Waldemar 
--
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: oops on cubox-i (v3.15-rc4)

[Waldemar Brodkorb]

Hi Russell,
Russell King - ARM Linux wrote,

> > Can you get an oops from when it's on ext4?  It looks like this is going
> > through fuse which opens a whole can of unknown worms.
> 
> Waldemar mentioned ext4.
> 
> I don't think there's anything specific about it to the Cubox-i, and I'd
> also suggest that it's got nothing to do with ARM either - the iMX6 are
> PIPT data caches so there can't be any issues with D-cache aliasing with
> fuse.
> 
> It must be a bug in generic code.

I think this, too. I observed a crash in a similar configuration
with my Mikrotik RB532 (mips32). I just couldn't get a kernel Oops yet,
because I fighted against some PCI and serial output problems on
this device.
http://www.linux-mips.org/archives/linux-mips/2014-05/msg00124.html
http://www.linux-mips.org/archives/linux-mips/2014-05/msg00074.html
May be I can get an oops on Monday.
 
> > > > > Booting Linux on physical CPU 0x0
> > > > > Linux version 3.15.0-rc4 (wbx@kop-brodkorbw) (gcc version 4.8.2 (GCC) 
> > > > > ) #1 SMP Fri May 9 12:58:45 CEST 2014
> > > > > CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> > > > > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction 
> > > > > cache
> > > > > Machine model: SolidRun Cubox-i Dual/Quad
> > > > > Truncating RAM at 1000-4fff to -3f7f (vmalloc region 
> > > > > overlap).
> 
> Also worth noting that 1/4 of the RAM is not used because highmem is not
> enabled.  Also L2 cache is disabled (so it's running slower than it
> should...)

Thanks for the hint. I thought I only need HIGHMEM for cubox-i4pro
with 2 GB. Will enable it for my cubox-i2ultra.
 
best regards
 Waldemar
--
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: oops on cubox-i (v3.15-rc4)

[Waldemar Brodkorb]

Hi Russell,
Russell King - ARM Linux wrote,

  Can you get an oops from when it's on ext4?  It looks like this is going
  through fuse which opens a whole can of unknown worms.
 
 Waldemar mentioned ext4.
 
 I don't think there's anything specific about it to the Cubox-i, and I'd
 also suggest that it's got nothing to do with ARM either - the iMX6 are
 PIPT data caches so there can't be any issues with D-cache aliasing with
 fuse.
 
 It must be a bug in generic code.

I think this, too. I observed a crash in a similar configuration
with my Mikrotik RB532 (mips32). I just couldn't get a kernel Oops yet,
because I fighted against some PCI and serial output problems on
this device.
http://www.linux-mips.org/archives/linux-mips/2014-05/msg00124.html
http://www.linux-mips.org/archives/linux-mips/2014-05/msg00074.html
May be I can get an oops on Monday.
 
 Booting Linux on physical CPU 0x0
 Linux version 3.15.0-rc4 (wbx@kop-brodkorbw) (gcc version 4.8.2 (GCC) 
 ) #1 SMP Fri May 9 12:58:45 CEST 2014
 CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
 CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction 
 cache
 Machine model: SolidRun Cubox-i Dual/Quad
 Truncating RAM at 1000-4fff to -3f7f (vmalloc region 
 overlap).
 
 Also worth noting that 1/4 of the RAM is not used because highmem is not
 enabled.  Also L2 cache is disabled (so it's running slower than it
 should...)

Thanks for the hint. I thought I only need HIGHMEM for cubox-i4pro
with 2 GB. Will enable it for my cubox-i2ultra.
 
best regards
 Waldemar
--
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: serial console on rb532 disabled on boot (linux 3.15rc5)

[Waldemar Brodkorb]

Hi Geert,
Geert Uytterhoeven wrote,

> Hi Waldemar,
> 
> On Fri, May 16, 2014 at 3:49 PM, Waldemar Brodkorb  wrote:
> > I am trying to bootup my Mikrotik RB532 board with the latest
> > kernel, but my serial console is disabled after boot:
> > ..
> > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> > serial8250: ttyS0 at MMIO 0x0 (irq = 104, base_baud = 12499875) is a
> > 16550A
> > console [ttyS0] enabled
> > console [ttyS0] disabled
> >
> > I used git bisect to find the problematic commit:
> > commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
> > Author: Geert Uytterhoeven 
> > Date:   Fri Feb 28 14:21:32 2014 +0100
> >
> > serial_core: Unregister console in uart_remove_one_port()
> >
> > If the serial port being removed is used as a console, it must
> > also be
> > unregistered from the console subsystem using
> > unregister_console().
> >
> > uart_ops.release_port() will release resources (e.g. iounmap()
> > the serial
> > port registers), causing a crash on subsequent kernel output if
> > the console
> > is still registered.
> >
> > Signed-off-by: Geert Uytterhoeven 
> > Signed-off-by: Greg Kroah-Hartman 
> >
> > After reverting the change, everything is fine.
> 
> Does this patch help? https://lkml.org/lkml/2014/5/10/9

The second change in printk.c didn't help.
 
> I guess you're not using of_serial?

No, I am not.

> Your serial driver may need to set port.type too, if it doesn't already do so
> and the type is PORT_UNKNOWN on re-registration.

Tried following patch, but it didn't work:

diff -Nur linux-3.15-rc5.orig/arch/mips/rb532/serial.c
linux-3.15-rc5/arch/mips/rb532/serial.c
--- linux-3.15-rc5.orig/arch/mips/rb532/serial.c2014-05-09
22:10:52.0 +0200
+++ linux-3.15-rc5/arch/mips/rb532/serial.c 2014-05-19
20:35:08.0 +0200
@@ -37,7 +37,7 @@
 extern unsigned int idt_cpu_freq;
 
 static struct uart_port rb532_uart = {
-   .flags = UPF_BOOT_AUTOCONF,
+   .type = PORT_16550A,
.line = 0,
.irq = UART0_IRQ,
.iotype = UPIO_MEM,
diff -Nur linux-3.15-rc5.orig/kernel/printk/printk.c
linux-3.15-rc5/kernel/printk/printk.c
--- linux-3.15-rc5.orig/kernel/printk/printk.c  2014-05-09
22:10:52.0 +0200
+++ linux-3.15-rc5/kernel/printk/printk.c   2014-05-20
09:39:54.0 +0200
@@ -2413,6 +2413,7 @@
if (console_drivers != NULL && console->flags & CON_CONSDEV)
console_drivers->flags |= CON_CONSDEV;
 
+   console->flags &= ~CON_ENABLED;
console_unlock();
console_sysfs_notify();
return res;


best regards
Waldemar
--
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: serial console on rb532 disabled on boot (linux 3.15rc5)

[Waldemar Brodkorb]

Hi Geert,
Geert Uytterhoeven wrote,

 Hi Waldemar,
 
 On Fri, May 16, 2014 at 3:49 PM, Waldemar Brodkorb w...@openadk.org wrote:
  I am trying to bootup my Mikrotik RB532 board with the latest
  kernel, but my serial console is disabled after boot:
  ..
  Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
  serial8250: ttyS0 at MMIO 0x0 (irq = 104, base_baud = 12499875) is a
  16550A
  console [ttyS0] enabled
  console [ttyS0] disabled
 
  I used git bisect to find the problematic commit:
  commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
  Author: Geert Uytterhoeven geert+rene...@linux-m68k.org
  Date:   Fri Feb 28 14:21:32 2014 +0100
 
  serial_core: Unregister console in uart_remove_one_port()
 
  If the serial port being removed is used as a console, it must
  also be
  unregistered from the console subsystem using
  unregister_console().
 
  uart_ops.release_port() will release resources (e.g. iounmap()
  the serial
  port registers), causing a crash on subsequent kernel output if
  the console
  is still registered.
 
  Signed-off-by: Geert Uytterhoeven geert+rene...@linux-m68k.org
  Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 
  After reverting the change, everything is fine.
 
 Does this patch help? https://lkml.org/lkml/2014/5/10/9

The second change in printk.c didn't help.
 
 I guess you're not using of_serial?

No, I am not.

 Your serial driver may need to set port.type too, if it doesn't already do so
 and the type is PORT_UNKNOWN on re-registration.

Tried following patch, but it didn't work:

diff -Nur linux-3.15-rc5.orig/arch/mips/rb532/serial.c
linux-3.15-rc5/arch/mips/rb532/serial.c
--- linux-3.15-rc5.orig/arch/mips/rb532/serial.c2014-05-09
22:10:52.0 +0200
+++ linux-3.15-rc5/arch/mips/rb532/serial.c 2014-05-19
20:35:08.0 +0200
@@ -37,7 +37,7 @@
 extern unsigned int idt_cpu_freq;
 
 static struct uart_port rb532_uart = {
-   .flags = UPF_BOOT_AUTOCONF,
+   .type = PORT_16550A,
.line = 0,
.irq = UART0_IRQ,
.iotype = UPIO_MEM,
diff -Nur linux-3.15-rc5.orig/kernel/printk/printk.c
linux-3.15-rc5/kernel/printk/printk.c
--- linux-3.15-rc5.orig/kernel/printk/printk.c  2014-05-09
22:10:52.0 +0200
+++ linux-3.15-rc5/kernel/printk/printk.c   2014-05-20
09:39:54.0 +0200
@@ -2413,6 +2413,7 @@
if (console_drivers != NULL  console-flags  CON_CONSDEV)
console_drivers-flags |= CON_CONSDEV;
 
+   console-flags = ~CON_ENABLED;
console_unlock();
console_sysfs_notify();
return res;


best regards
Waldemar
--
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/

serial console on rb532 disabled on boot (linux 3.15rc5)

[Waldemar Brodkorb]

Hi Linux hackers,

I am trying to bootup my Mikrotik RB532 board with the latest
kernel, but my serial console is disabled after boot:
..
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 104, base_baud = 12499875) is a
16550A
console [ttyS0] enabled
console [ttyS0] disabled

I used git bisect to find the problematic commit:
commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
Author: Geert Uytterhoeven 
Date:   Fri Feb 28 14:21:32 2014 +0100

serial_core: Unregister console in uart_remove_one_port()

If the serial port being removed is used as a console, it must
also be
unregistered from the console subsystem using
unregister_console().

uart_ops.release_port() will release resources (e.g. iounmap()
the serial
port registers), causing a crash on subsequent kernel output if
the console
is still registered.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman 

After reverting the change, everything is fine.

I can provide a .config and dmesg if needed.

Thanks in advance
 Waldemar

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

serial console on rb532 disabled on boot (linux 3.15rc5)

[Waldemar Brodkorb]

Hi Linux hackers,

I am trying to bootup my Mikrotik RB532 board with the latest
kernel, but my serial console is disabled after boot:
..
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 104, base_baud = 12499875) is a
16550A
console [ttyS0] enabled
console [ttyS0] disabled

I used git bisect to find the problematic commit:
commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
Author: Geert Uytterhoeven geert+rene...@linux-m68k.org
Date:   Fri Feb 28 14:21:32 2014 +0100

serial_core: Unregister console in uart_remove_one_port()

If the serial port being removed is used as a console, it must
also be
unregistered from the console subsystem using
unregister_console().

uart_ops.release_port() will release resources (e.g. iounmap()
the serial
port registers), causing a crash on subsequent kernel output if
the console
is still registered.

Signed-off-by: Geert Uytterhoeven geert+rene...@linux-m68k.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

After reverting the change, everything is fine.

I can provide a .config and dmesg if needed.

Thanks in advance
 Waldemar

--
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: problem booting linux with qemu-system-arm -M spitz

[Waldemar Brodkorb]

Hi,
Andrea Adami wrote,

> On Wed, Sep 18, 2013 at 12:27 PM, Waldemar Brodkorb  wrote:
> > Hi Kernel hackers,
> >
> > I am trying to run Linux on Qemu/arm emulator with machine type
> > spitz. In the past this worked fine.
> > Now with Linux version 3.9.11 it does not boot anymore.
> > (blank screen, no kernel messages)
> >
> > I used git bisect to find the commit, which breaks the boot:
> > commit 4e8ee7de227e3ab9a72040b448ad728c5428a042
> > Author: Will Deacon 
> > Date:   Wed Nov 23 12:26:25 2011 +
> >
> > I am using Qemu 1.6.0 on a Debian/x86_64 host.
> >
> > Any help would be appreciated.
> >
> > Thanks in advance
> >  Waldemar
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> On real hardware I see the same breakage after 3.2.
> Marko diagnosed it and there is a pending patch:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/198444.html
> 
> There is indeed some MMU-related issue.
> Probably the function could be called elsewhere during machine init
> but I'm not so high in the food chain to dare to touch arm boot code
> ;)
> 
> Regards

Great! Thank you very much, this works fine.

best regards
 Waldemar
--
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/

problem booting linux with qemu-system-arm -M spitz

[Waldemar Brodkorb]

Hi Kernel hackers,

I am trying to run Linux on Qemu/arm emulator with machine type
spitz. In the past this worked fine.
Now with Linux version 3.9.11 it does not boot anymore. 
(blank screen, no kernel messages)

I used git bisect to find the commit, which breaks the boot:
commit 4e8ee7de227e3ab9a72040b448ad728c5428a042
Author: Will Deacon 
Date:   Wed Nov 23 12:26:25 2011 +

I am using Qemu 1.6.0 on a Debian/x86_64 host.

Any help would be appreciated.

Thanks in advance
 Waldemar
--
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/

problem booting linux with qemu-system-arm -M spitz

[Waldemar Brodkorb]

Hi Kernel hackers,

I am trying to run Linux on Qemu/arm emulator with machine type
spitz. In the past this worked fine.
Now with Linux version 3.9.11 it does not boot anymore. 
(blank screen, no kernel messages)

I used git bisect to find the commit, which breaks the boot:
commit 4e8ee7de227e3ab9a72040b448ad728c5428a042
Author: Will Deacon will.dea...@arm.com
Date:   Wed Nov 23 12:26:25 2011 +

I am using Qemu 1.6.0 on a Debian/x86_64 host.

Any help would be appreciated.

Thanks in advance
 Waldemar
--
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: problem booting linux with qemu-system-arm -M spitz

[Waldemar Brodkorb]

Hi,
Andrea Adami wrote,

 On Wed, Sep 18, 2013 at 12:27 PM, Waldemar Brodkorb w...@openadk.org wrote:
  Hi Kernel hackers,
 
  I am trying to run Linux on Qemu/arm emulator with machine type
  spitz. In the past this worked fine.
  Now with Linux version 3.9.11 it does not boot anymore.
  (blank screen, no kernel messages)
 
  I used git bisect to find the commit, which breaks the boot:
  commit 4e8ee7de227e3ab9a72040b448ad728c5428a042
  Author: Will Deacon will.dea...@arm.com
  Date:   Wed Nov 23 12:26:25 2011 +
 
  I am using Qemu 1.6.0 on a Debian/x86_64 host.
 
  Any help would be appreciated.
 
  Thanks in advance
   Waldemar
 
  ___
  linux-arm-kernel mailing list
  linux-arm-ker...@lists.infradead.org
  http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
 On real hardware I see the same breakage after 3.2.
 Marko diagnosed it and there is a pending patch:
 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/198444.html
 
 There is indeed some MMU-related issue.
 Probably the function could be called elsewhere during machine init
 but I'm not so high in the food chain to dare to touch arm boot code
 ;)
 
 Regards

Great! Thank you very much, this works fine.

best regards
 Waldemar
--
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: Pcmcia-Updates for Xircomcards?

[Waldemar Brodkorb]

Hello all,

* I wrote:

> My Hardware: 
> Toshiba Satellite Pro 4280 
> PCMCIA: Xircom RBEM56G-100 
>
> Linus said serial_cs is for both, old serial_cb & serial_cs.

Sorry, that was wrong. He said serial.o is the correct driver.

Thanks for all help, especially from Arjan van de Ven. 
Another script/program is necessary. 
Hotplug --> http://linux-hotplug.sourceforge.net

thanks a lot.
Waldemar

-- 
* Ein gutes Kryptographieprogramm: |  (o_  *
*   http://www.gnupg.org   |  //\  *
*   Linux rulez!;-)|  V_/_ *
* GnuPG-Key: 0xBE21BD90 | Tux: #155220 | ICQ: 64035650 *
-
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: Pcmcia-Updates for Xircomcards?

[Waldemar Brodkorb]

Hello all,

* I wrote:

 My Hardware: 
 Toshiba Satellite Pro 4280 
 PCMCIA: Xircom RBEM56G-100 

 Linus said serial_cs is for both, old serial_cb  serial_cs.

Sorry, that was wrong. He said serial.o is the correct driver.

Thanks for all help, especially from Arjan van de Ven. 
Another script/program is necessary. 
Hotplug -- http://linux-hotplug.sourceforge.net

thanks a lot.
Waldemar

-- 
* Ein gutes Kryptographieprogramm: |  (o_  *
*   http://www.gnupg.org   |  //\  *
*   Linux rulez!;-)|  V_/_ *
* GnuPG-Key: 0xBE21BD90 | Tux: #155220 | ICQ: 64035650 *
-
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/

Pcmcia-Updates for Xircomcards?

[Waldemar Brodkorb]

Hello David Hinds, Hello Kernelhackers,

sorry that I also directly contact you. 
But I'am very confused, at the moment.

My Hardware: 
Toshiba Satellite Pro 4280 
PCMCIA: Xircom RBEM56G-100 

When I use SuSE 7.1 and Kernel 2.4.2 (SuSE) the card 
is recognized and network works, also configured via DHCP.
(tulib_cb,serial_cb , perhaps from pcmcia-cs )

But now I want to use Kernel 2.4.3-ac12, because of the 
new module, which I've heard/read is better than the old drivers.

O.K., here what I done:
build yenta_socket,xircom_cb,serial_cs,pcmcia_core,..

Modified /etc/pcmcia/config:
device "xircom_cb"
  class "network" module "cb_enabler", "xircom_cb"

card "Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem"
  manfid 0x0105, 0x0103
  bind "xircom_cb" to 0, "serial_cs" to 1

Linus said serial_cs is for both, old serial_cb & serial_cs.

But when I start the notebook with the same /etc/init.d/pcmcia
I get this:
Apr 22 21:34:36 T50179768G kernel: PCI: Enabling device 14:00.1
( -> 0003)
Apr 22 21:34:36 T50179768G cardmgr[206]: initializing socket 0
Apr 22 21:34:36 T50179768G cardmgr[206]: socket 0: Xircom
CBEM56G-100 CardBus 10
/100 Ethernet + 56K Modem
Apr 22 21:34:36 T50179768G cardmgr[206]: executing: 'modprobe
cb_enabler'
Apr 22 21:34:36 T50179768G cardmgr[206]: executing: 'modprobe
xircom_cb'
Apr 22 21:34:36 T50179768G kernel: PCI: Setting latency timer of
device 14:00.0
to 64
Apr 22 21:34:36 T50179768G kernel: eth0: Xircom cardbus revision 3
at irq 11
Apr 22 21:34:36 T50179768G cardmgr[206]: executing: 'modprobe
serial_cs'
Apr 22 21:34:36 T50179768G kernel: Serial driver version 5.05a
(2001-03-20) with
 MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
 Apr 22 21:34:36 T50179768G kernel: ttyS00 at 0x03f8 (irq = 4) is a
 16550A
 Apr 22 21:34:36 T50179768G cardmgr[206]: executing: './network
 start xircom_cb'
 Apr 22 21:34:36 T50179768G kernel: serial_cs: ParseTuple: No more
 items
 Apr 22 21:34:36 T50179768G cardmgr[206]: + xircom_cb: error
 fetching interface i
 nformation: Device not found
 Apr 22 21:34:37 T50179768G cardmgr[206]: + /sbin/ifconfig xircom_cb
 up
 Apr 22 21:34:37 T50179768G cardmgr[206]: + xircom_cb: unknown
 interface: No such
  device
  Apr 22 21:34:37 T50179768G dhcpcd[1115]: dhcpStart: ioctl
  SIOCGIFHWADDR: No such
   device
   Apr 22 21:34:37 T50179768G cardmgr[206]: + /sbin/dhcpcd
   xircom_cb >/dev/null 2>
   &1
   Apr 22 21:34:37 T50179768G cardmgr[206]: executing: './serial
   start xircom_cb'
   Apr 22 21:34:37 T50179768G cardmgr[206]: + expr: syntax error
   Apr 22 21:34:37 T50179768G cardmgr[206]: + ./MAKEDEV xircom_cb
   Apr 22 21:34:37 T50179768G cardmgr[206]: + ./serial: ./MAKEDEV:
   No such file or
   directory
   Apr 22 21:34:37 T50179768G cardmgr[206]: + /dev/xircom_cb: No
   such file or direc
   tory


It is possible I missed something essential?

More information added below.

Would it a good idea to split pcmcia-cs package?
One for use with kernel 2.4, without client-modules
and one for kernel 2.2.x with all modules? 
Because of the different names and modules ?

-
pcmcia-cs 3.1.22 & 3.1.25 (same problem, cardmgr have the same
version number)

What to do?

thanks for any hints or help.

bye
Waldemar 

-- 
* A good website for linuxsoftware:|  (o_  *
*   http://www.freshmeat.net   |  //\  *
*   Linux rulez!;-)|  V_/_ *
* GnuPG-Key: 0xBE21BD90 | Tux: #155220 | ICQ: 64035650 *




00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, medium devsel, latency 64
Memory at e000 (32-bit, prefetchable) [size=128M]
Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 
(prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
Memory behind bridge: f000-f7ff

00:05.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
Flags: bus master, medium devsel, latency 0

00:05.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 
[Master])
Flags: bus master, medium devsel, latency 64
I/O ports at fff0 [size=16]

00:05.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 
[UHCI])
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at ff80 [size=32]

00:05.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03)
Flags: medium devsel, IRQ 9

00:07.0 Communication controller: Lucent Microelectronics 56k WinModem (rev 01)
Subsystem: Toshiba America Info Systems Internal V.90 Modem
Flags: bus master, medium devsel, latency 0, IRQ 3
Memory at ffefff00 (32-bit, non-prefetchable) [size=256]
I/O ports at 02f8 [size=8]
I/O ports at 1c00 [size=256]

Pcmcia-Updates for Xircomcards?

[Waldemar Brodkorb]

Hello David Hinds, Hello Kernelhackers,

sorry that I also directly contact you. 
But I'am very confused, at the moment.

My Hardware: 
Toshiba Satellite Pro 4280 
PCMCIA: Xircom RBEM56G-100 

When I use SuSE 7.1 and Kernel 2.4.2 (SuSE) the card 
is recognized and network works, also configured via DHCP.
(tulib_cb,serial_cb , perhaps from pcmcia-cs )

But now I want to use Kernel 2.4.3-ac12, because of the 
new module, which I've heard/read is better than the old drivers.

O.K., here what I done:
build yenta_socket,xircom_cb,serial_cs,pcmcia_core,..

Modified /etc/pcmcia/config:
device "xircom_cb"
  class "network" module "cb_enabler", "xircom_cb"

card "Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem"
  manfid 0x0105, 0x0103
  bind "xircom_cb" to 0, "serial_cs" to 1

Linus said serial_cs is for both, old serial_cb  serial_cs.

But when I start the notebook with the same /etc/init.d/pcmcia
I get this:
Apr 22 21:34:36 T50179768G kernel: PCI: Enabling device 14:00.1
( - 0003)
Apr 22 21:34:36 T50179768G cardmgr[206]: initializing socket 0
Apr 22 21:34:36 T50179768G cardmgr[206]: socket 0: Xircom
CBEM56G-100 CardBus 10
/100 Ethernet + 56K Modem
Apr 22 21:34:36 T50179768G cardmgr[206]: executing: 'modprobe
cb_enabler'
Apr 22 21:34:36 T50179768G cardmgr[206]: executing: 'modprobe
xircom_cb'
Apr 22 21:34:36 T50179768G kernel: PCI: Setting latency timer of
device 14:00.0
to 64
Apr 22 21:34:36 T50179768G kernel: eth0: Xircom cardbus revision 3
at irq 11
Apr 22 21:34:36 T50179768G cardmgr[206]: executing: 'modprobe
serial_cs'
Apr 22 21:34:36 T50179768G kernel: Serial driver version 5.05a
(2001-03-20) with
 MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
 Apr 22 21:34:36 T50179768G kernel: ttyS00 at 0x03f8 (irq = 4) is a
 16550A
 Apr 22 21:34:36 T50179768G cardmgr[206]: executing: './network
 start xircom_cb'
 Apr 22 21:34:36 T50179768G kernel: serial_cs: ParseTuple: No more
 items
 Apr 22 21:34:36 T50179768G cardmgr[206]: + xircom_cb: error
 fetching interface i
 nformation: Device not found
 Apr 22 21:34:37 T50179768G cardmgr[206]: + /sbin/ifconfig xircom_cb
 up
 Apr 22 21:34:37 T50179768G cardmgr[206]: + xircom_cb: unknown
 interface: No such
  device
  Apr 22 21:34:37 T50179768G dhcpcd[1115]: dhcpStart: ioctl
  SIOCGIFHWADDR: No such
   device
   Apr 22 21:34:37 T50179768G cardmgr[206]: + /sbin/dhcpcd
   xircom_cb /dev/null 2
   1
   Apr 22 21:34:37 T50179768G cardmgr[206]: executing: './serial
   start xircom_cb'
   Apr 22 21:34:37 T50179768G cardmgr[206]: + expr: syntax error
   Apr 22 21:34:37 T50179768G cardmgr[206]: + ./MAKEDEV xircom_cb
   Apr 22 21:34:37 T50179768G cardmgr[206]: + ./serial: ./MAKEDEV:
   No such file or
   directory
   Apr 22 21:34:37 T50179768G cardmgr[206]: + /dev/xircom_cb: No
   such file or direc
   tory


It is possible I missed something essential?

More information added below.

Would it a good idea to split pcmcia-cs package?
One for use with kernel 2.4, without client-modules
and one for kernel 2.2.x with all modules? 
Because of the different names and modules ?

-
pcmcia-cs 3.1.22  3.1.25 (same problem, cardmgr have the same
version number)

What to do?

thanks for any hints or help.

bye
Waldemar 

-- 
* A good website for linuxsoftware:|  (o_  *
*   http://www.freshmeat.net   |  //\  *
*   Linux rulez!;-)|  V_/_ *
* GnuPG-Key: 0xBE21BD90 | Tux: #155220 | ICQ: 64035650 *




00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, medium devsel, latency 64
Memory at e000 (32-bit, prefetchable) [size=128M]
Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 
(prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
Memory behind bridge: f000-f7ff

00:05.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
Flags: bus master, medium devsel, latency 0

00:05.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 
[Master])
Flags: bus master, medium devsel, latency 64
I/O ports at fff0 [size=16]

00:05.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 
[UHCI])
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at ff80 [size=32]

00:05.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03)
Flags: medium devsel, IRQ 9

00:07.0 Communication controller: Lucent Microelectronics 56k WinModem (rev 01)
Subsystem: Toshiba America Info Systems Internal V.90 Modem
Flags: bus master, medium devsel, latency 0, IRQ 3
Memory at ffefff00 (32-bit, non-prefetchable) [size=256]
I/O ports at 02f8 [size=8]
I/O ports at 1c00 [size=256]