[Kernel-packages] [Bug 1807250] Re: At some point in the 18.04 cycle, /sys/bus/iio has disappeared from my system

[Nish Aravamudan]

I just tried booting into 4.15.0-20 as the release pocket has it still
and it also failed to work. So now I'm wondering if/when it did work. I
will try and narrow it down in the next few days.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1807250

Title:
  At some point in the 18.04 cycle, /sys/bus/iio has disappeared from my
  system

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have a Yoga 900-13ISK and a Thinkpad T470s. Both have had working
  screen rotation in the past. However, I noticed today while supporting
  a user in #ubuntu, neither do now. No icon in the Gnome menu and:

  # G_MESSAGES_DEBUG=all iio-sensor-proxy 
  ** (process:14877): DEBUG: 12:31:21.603: Could not find any supported sensors

  Indeed, /sys/bus/iio does not exist! I believe this is distinct from
  LP: #1792813, as I have just tested mainline 4.19 and it also does not
  work.

  I am working on getting more data, including testing older kernels
  from 18.04, but it might take me some time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1807250/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1807250] Re: At some point in the 18.04 cycle, /sys/bus/iio has disappeared from my system

[Nish Aravamudan]

Right, I understand fully what the bot is asking for, but it's not
exactly relevant here. We are seeing (on at least two systems) a lack of
IIO device discovery. If I modprobe all the iio modules, I do get a
/sys/bus/iio, but no devices in it. So it feels like something is
missing, but I don't know where.

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1807250

Title:
  At some point in the 18.04 cycle, /sys/bus/iio has disappeared from my
  system

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have a Yoga 900-13ISK and a Thinkpad T470s. Both have had working
  screen rotation in the past. However, I noticed today while supporting
  a user in #ubuntu, neither do now. No icon in the Gnome menu and:

  # G_MESSAGES_DEBUG=all iio-sensor-proxy 
  ** (process:14877): DEBUG: 12:31:21.603: Could not find any supported sensors

  Indeed, /sys/bus/iio does not exist! I believe this is distinct from
  LP: #1792813, as I have just tested mainline 4.19 and it also does not
  work.

  I am working on getting more data, including testing older kernels
  from 18.04, but it might take me some time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1807250/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1807250] [NEW] At some point in the 18.04 cycle, /sys/bus/iio has disappeared from my system

[Nish Aravamudan]

Public bug reported:

I have a Yoga 900-13ISK and a Thinkpad T470s. Both have had working
screen rotation in the past. However, I noticed today while supporting a
user in #ubuntu, neither do now. No icon in the Gnome menu and:

# G_MESSAGES_DEBUG=all iio-sensor-proxy 
** (process:14877): DEBUG: 12:31:21.603: Could not find any supported sensors

Indeed, /sys/bus/iio does not exist! I believe this is distinct from LP:
#1792813, as I have just tested mainline 4.19 and it also does not work.

I am working on getting more data, including testing older kernels from
18.04, but it might take me some time.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1807250

Title:
  At some point in the 18.04 cycle, /sys/bus/iio has disappeared from my
  system

Status in linux package in Ubuntu:
  New

Bug description:
  I have a Yoga 900-13ISK and a Thinkpad T470s. Both have had working
  screen rotation in the past. However, I noticed today while supporting
  a user in #ubuntu, neither do now. No icon in the Gnome menu and:

  # G_MESSAGES_DEBUG=all iio-sensor-proxy 
  ** (process:14877): DEBUG: 12:31:21.603: Could not find any supported sensors

  Indeed, /sys/bus/iio does not exist! I believe this is distinct from
  LP: #1792813, as I have just tested mainline 4.19 and it also does not
  work.

  I am working on getting more data, including testing older kernels
  from 18.04, but it might take me some time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1807250/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1706946] Re: Sync crash 7.1.9-1 (main) from Debian unstable (main)

[Nish Aravamudan]

$ syncpackage -b 1706946 -s rbalint -f crash
syncpackage: Source crash -> artful/Proposed: current version 7.1.8-1ubuntu2, 
new version 7.1.9-1
syncpackage: New changes:
crash (7.1.9-1) unstable; urgency=medium

  * Patch from Balint Reczey : Build crash on all Linux
architectures (Closes: #763856, #757450)

  * Patch from Balint Reczey : Continuous integration
tests can fail due to missing packages for the running kernel and missing
*-updates packages (Closes: #869367)

  * Fixes to address three gcc-7.0.1 compiler warnings that are generated when
building with "make warn".  The warning types are "[-Wnonnull]" in
filesys.c, and "[-Wformat-overflow=]" in kernel.c and cmdline.c.

  * Fix for the PPC64 "mach -o" option to update the OPAL console buffer size
from 256K to 1MB, based upon the latest skiboot firmware source.

  * Fix for the "mod -[sS]" option to prevent the erroneous reassignment of
one or more symbol values of a kernel module.  Without the patch, when
loading a kernel module, a message may indicate "mod: : last
symbol:  is not _MODULE_END_?" may be displayed, and one
or more symbols may be reassigned an incorrect symbol value.  If none of
the erroneous symbol value reassignments are beyond the end of the
module's address space, then there will be no message.

  * Linux 4.10 commit 401721ecd1dcb0a428aa5d6832ee05ffbdbffbbe finally exports
the x86_64 "phys_base" value in the VMCOREINFO note, so utilize it
whenever it exists.

  * Implemented a new "log -a" option that dumps the audit logs remaining in
kernel audit buffers that have not been copied out to the user-space audit
daemon.

  * Fix for the "kmem " option and the "search" command in x86_64
kernels that contain, or have backports of, kernel commit
7c1da8d0d046174a4188b5729d7579abf3d29427, titled "crypto: sha - SHA1
transform x86_64 AVX2", which introduced an "_end" text symbol.  Without
the patch, if a base kernel symbol address that is larger than the "_end"
text symbol is passed to "kmem ", its symbol/filename information
will not be displayed.  Also, when the "search" command scans the
__START_KERNEL_map region that contains kernel text and static data, the
search will be truncated to stop at the "_end" text symbol address.

  * Enhancement for the determination of the ARM64 "kimage_voffset" value in
Linux 4.6 and later kernels if an ELF format dumpfile does not contain its
value in a VMCOREINFO note, or when running against live systems using
/dev/mem, /proc/kcore, or an older version of /dev/crash.

  * Optimization of the "kmem -f " and "kmem " options to
significantly reduce the amount of time to complete the buddy allocator
free-list scan for the target address.  On very large memory systems, the
patch may reduce the time spent by several orders of magnitude.

  * Fix for a compilation error if glibc-2.25 or later has been installed on
the host build machine.  Without the patch, the build fails with the error
message "amd64-linux-nat.c:496:1: error: conflicting types for
'ps_get_thread_area'".

  * Fix for the "list -[hH]" options if a list_head.next pointer is
encountered that contains an invalid NULL pointer.  Without the patch, the
"list -[hH]" options would complete/continue as if the NULL were a
legitimate end-of-list indicator, and no error would be reported.

  * Provide basic Huge Page usage as part of "kmem -i" output, showing the
total amount of memory allocated for huge pages, and the amount of the
total that is free.

  * Fix for the determination of the x86_64 "phys_base" value when it is not
passed in the VMCOREINFO data of ELF vmcores.  Without the patch, it is
possible that the base address of the vmalloc region is unknown and
initialized to an incorrect default address during the very early stages
of initialization, which causes the parsing of the PT_LOAD segments for
the START_KERNEL_map region to fail.

  * Fix for the "dis" command to detect duplicate symbols in the case of a
"symbol+offset" argument where the duplicates are contiguous in the symbol
list.  In addition, reject "symbol+offset" arguments if the resultant
address goes beyond the end of the function.

  * Fix for the "set scope" option if the kernel was configured with
CONFIG_RANDOMIZE_BASE.  Without the patch, the command fails with the
message "set: gdb cannot find text block for address: ".  This
also affects extension modules that call gdb_set_crash_scope() when
running with KASLR kernels.

  * Fix for the extensions/trace.c extension module to account for Linux 4.7
kernel commit 9b94a8fba501f38368aef6ac1b30e7335252a220, which changed the
ring_buffer_per_cpu.nr_pages member from an int to a long.  Without the
patch, the trace.so extension module fails to load on big-endian machines,

[Kernel-packages] [Bug 1667245] Re: ISST-LTE:pVM:roselp4:ubuntu 17.04: kdump failed after memory DLPAR

[Nish Aravamudan]

How is this supposed to work generally. On DLPAR, kdump needs to be
reloaded -- does that the mean the kdump.service should be watching for
dlpar events?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1667245

Title:
  ISST-LTE:pVM:roselp4:ubuntu 17.04: kdump failed after memory DLPAR

Status in The Ubuntu-power-systems project:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  After a memory DLPAR removal, kdump doesn't work:

   Starting Kernel crash dump capture service...
  [   67.714593] kdump-tools[3850]: Starting kdump-tools:  * running 
makedumpfile -c -d 31 /proc/vmcore /var/crash/201702230005/dump-incomplete
  Copying data   : [  2.1 %] -/usr/sbin/kdump-config: line 
639:  3897 Bus error   makedumpfile $MAKEDUMP_ARGS $vmcore_file 
$KDUMP_CORETEMP
  [   72.314140] kdump-tools[3850]:  * kdump-tools: makedumpfile failed, 
falling back to 'cp'
  [   73.693881] kdump-tools[3850]: cp: error reading '/proc/vmcore': Bad 
address
  [   73.704152] kdump-tools[3850]:  * kdump-tools: failed to save vmcore in 
/var/crash/201702230005
  [   73.823643] kdump-tools[3850]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/201702230005/dmesg.201702230005
  [   73.973813] kdump-tools[3850]: The kernel version is not supported.
  [   73.974078] kdump-tools[3850]: The makedumpfile operation may be 
incomplete.
  [   73.983506] kdump-tools[3850]: The dmesg log is saved to 
/var/crash/201702230005/dmesg.201702230005.
  [   73.983752] kdump-tools[3850]: makedumpfile Completed.
  [   73.983998] kdump-tools[3850]:  * kdump-tools: saved dmesg content in 
/var/crash/201702230005
  [   74.104555] kdump-tools[3850]: Thu, 23 Feb 2017 00:05:15 -0600
  [   74.233502] kdump-tools[3850]: Failed to read reboot parameter file: No 
such file or directory
  [   74.233782] kdump-tools[3850]: Rebooting.
  [   86.629777] reboot: Restarting system

  
  The kdump service should be restarted after the memory DLPAR operation.
   
  C
  ---uname output---
  Linux roselp4 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:00:06 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = lpar 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
  1. config kdump on roselp4
  2. do a memory DLPAR removal operation
  3. trigger kdump

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1667245/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1680349] Re: Ubuntu 17.04: Kdump fails to capture dump on Firestone NV when machine crashes while running stress-ng.

[Nish Aravamudan]

I believe this request should be routed to the kernel team (setting of a
kernel default value for POWER systems)?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1680349

Title:
  Ubuntu 17.04: Kdump fails to capture dump on Firestone NV when machine
  crashes while running stress-ng.

Status in The Ubuntu-power-systems project:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - PAVITHRA R. PRAKASH <> - 2017-03-10 02:43:10 ==
  ---Problem Description---

  Ubuntu 17.04: Kdump fails to capture dump on Firestone NV when machine
  crashes while running stress-ng. Machine hangs.

  ---Steps to Reproduce---

  1. Configure kdump.
  2. Install stress-ng
  # apt-get install stress-ng
  3. Run stress-ng
  # stress-ng - a 0

  
  Logs:
  
  root@ltc-firep3:~# kdump-config load
  Modified cmdline:root=UUID=8b0d5b99-6087-4f40-82ea-375c83a4c139 ro quiet 
splash irqpoll nr_cpus=1 nousb systemd.unit=kdump-tools.service 
ata_piix.prefer_ms_hyperv=0 elfcorehdr=155200K 
   * loaded kdump kernel
  root@ltc-firep3:~# kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_SYSCTL: kernel.panic_on_oops=1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.10.0-11-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.10.0-11-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=8b0d5b99-6087-4f40-82ea-375c83a4c139 ro quiet splash 
irqpoll nr_cpus=1 nousb systemd.unit=kdump-tools.service 
ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img 
/var/lib/kdump/vmlinuz
  root@ltc-firep3:~# stress-ng -a 0
  stress-ng: info:  [3900] defaulting to a 86400 second run per stressor
  stress-ng: info:  [3900] dispatching hogs: 160 af-alg, 160 affinity, 160 aio, 
160 aiol, 160 apparmor, 160 atomic, 160 bigheap, 160 brk, 160 bsearch, 160 
cache, 160 cap, 160 chdir, 160 chmod, 160 chown, 160 chroot, 160 clock, 160 
clone, 160 context, 160 copy-file, 160 cpu, 160 cpu-online, 160 crypt, 160 
daemon, 160 dccp, 160 dentry, 160 dir, 160 dirdeep, 160 dnotify, 160 dup, 160 
epoll, 160 eventfd, 160 exec, 160 fallocate, 160 fanotify, 160 fault, 160 
fcntl, 160 fiemap, 160 fifo, 160 filename, 160 flock, 160 fork, 160 fp-error, 
160 fstat, 160 full, 160 futex, 160 get, 160 getdent, 160 getrandom, 160 
handle, 160 hdd, 160 heapsort, 160 hsearch, 160 icache, 160 icmp-flood, 160 
inotify, 160 io, 160 iomix, 160 ioprio, 160 itimer, 160 kcmp, 160 key, 160 
kill, 160 klog, 160 lease, 160 link, 160 locka, 160 lockbus, 160 lockf, 160 
lockofd, 160 longjmp, 160 lsearch, 160 madvise, 160 malloc, 160 matrix, 160 
membarrier, 160 memcpy, 160 memfd, 160 mergesort, 160 mincore, 160 mknod, 160 
mlock, 1
 60 mmap, 160 mmapfork, 160 mmapmany, 160 mq, 160 mremap, 160 msg, 160 msync, 
160 netlink-proc, 160 nice, 160 nop, 160 null, 160 numa, 160 oom-pipe, 160 
opcode, 160 open, 160 personality, 160 pipe, 160 poll, 160 procfs, 160 pthread, 
160 ptrace, 160 pty, 160 qsort, 160 quota, 160 rdrand, 160 readahead, 160 
remap, 160 rename, 160 resources, 160 rlimit, 160 rmap, 160 rtc, 160 
schedpolicy, 160 sctp, 160 seal, 160 seccomp, 160 seek, 160 sem, 160 sem-sysv, 
160 sendfile, 160 shm, 160 shm-sysv, 160 sigfd, 160 sigfpe, 160 sigpending, 160 
sigq, 160 sigsegv, 160 sigsuspend, 160 sleep, 160 sock, 160 sockfd, 160 
sockpair, 160 spawn, 160 splice, 160 stack, 160 stackmmap, 160 str, 160 stream, 
160 switch, 160 symlink, 160 sync-file, 160 sysfs, 160 sysinfo, 160 tee, 160 
timer, 160 timerfd, 160 tlb-shootdown, 160 tmpfs, 160 tsc, 160 tsearch, 160 
udp, 160 udp-flood, 160 unshare, 160 urandom, 160 userfaultfd, 160 utime, 160 
vecmath, 160 vfork, 160 vforkmany, 160 vm, 160 vm-rw, 160 vm-splice, 160 wait, 1
 60 wcs, 160 xattr, 160 yield, 160 zero, 160 zlib, 160 zombie
  stress-ng: info:  [3900] cache allocate: using built-in defaults as unable to 
determine cache details
  stress-ng: info:  [3900] cache allocate: default cache size: 2048K
  stress-ng: info:  [3907] stress-ng-atomic: this stressor is not implemented 
on this system: ppc64le Linux 4.10.0-11-generic
  stress-ng: info:  [3955] stress-ng-exec: running as root, won't run test.
  stress-ng: info:  [3999] stress-ng-icache: this stressor is not implemented 
on this system: ppc64le Linux 4.10.0-11-generic
  stress-ng: info:  [4040] stress-ng-lockbus: this stressor is not implemented 
on this system: ppc64le Linux 4.10.0-11-generic
  stress-ng: info:  [4313] stress-ng-numa: system has 2 of a maximum 256 memory 
NUMA nodes
  stress-ng: info:  [4455] stress-ng-rdrand: this stressor is not implemented 
on this system: ppc64le Linux 4.10.0-11-generic
  stress-ng: fail:  [4558] stress-ng-rtc: ioctl RTC_ALRM_READ failed, errno=22 
(Invalid argument)
  stress-ng: fail:  [4017] stress-ng-key: 

[Kernel-packages] [Bug 1681909] Re: Ubuntu 17.04: dump is not captured in remote host when kdump over ssh is configured on firestone.

[Nish Aravamudan]

I don't see any fundamental issue with providing a NET_WAIT_TIME
variable (probably should be namespaced to KDUMP_) in the kdump config
file, but:

1) this seems like a hack to work around slow hardware, right?

2) it can't be automatically deduced, afaict. Or do you want to have 30s
delays (potentially) on all POWER machines?

3) I'm not 100% familiar with the 'upstream' of kdump-tools -- is this
something that we'd need to carry forever in the Debian/Ubuntu
packaging?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1681909

Title:
  Ubuntu 17.04: dump is not captured in remote host when kdump over ssh
  is configured on firestone.

Status in The Ubuntu-power-systems project:
  New
Status in makedumpfile package in Ubuntu:
  New

Bug description:
  == Comment: #0 - PAVITHRA R. PRAKASH  - 2017-03-07 
05:00:29 ==
  ---Problem Description---

  Ubuntu 17.04: dump is not captured in remote host when kdump over ssh
  is configured on firestone.

  ---Steps to Reproduce---

  1. Configure kdump.
  2. Check whether kdump is operational using ?# kdump-config show?.
  3. Install ?kernel-debuginfo? and ?kernel-debuginfo-common? rpms.
  4. Setup password less ssh connection, generate rsa key.
  # ssh-keygen -t rsa
  5. verify id_rsa and id_rsa.pub are created under /root/.ssh/
  6. Edit /etc/default/kdump-tools and add below entries.
  SSH="ubuntu@9.114.15.239"
  SSH_KEY=/root/.ssh/id_rsa
  7. Propagate RSA key.
  # kdump-config propagate
  8. Restart kdump service.
  # kdump-config load
  9. Trigger Crash using below commands.
  # echo "1" > /proc/sys/kernel/sysrq
  # echo "c" > /proc/sysrq-trigger
  10. Verify dump is available in remote server in configured path.

  Machine details
  ===

  $ ipmitool -I lanplus -H  9.47.70.3 -U ADMIN -P admin sol activate

  $ ssh ubuntu@9.47.70.29

  PW: shriya101

  
  Attaching logs

  == Comment: #1 - PAVITHRA R. PRAKASH  -
  2017-03-07 05:01:42 ==

  
  == Comment: #5 - PAVITHRA R. PRAKASH  - 2017-03-07 
23:19:46 ==
  Hi, 

  Attaching the logs.

  Network info:

  root@ltc-firep3:~# hwinfo --network
  36: None 00.0: 10700 Loopback   
[Created at net.126]
Unique ID: ZsBS.GQNx7L4uPNA
SysFS ID: /class/net/lo
Hardware Class: network interface
Model: "Loopback network interface"
Device File: lo
Link detected: yes
Config Status: cfg=new, avail=yes, need=no, active=unknown

  37: None 00.0: 10701 Ethernet
[Created at net.126]
Unique ID: 2lHw.ndpeucax6V1
Parent ID: mIXc.aXC4wIvegH8
SysFS ID: /class/net/enP33p3s0f2
SysFS Device Link: 
/devices/pci0021:00/0021:00:00.0/0021:01:00.0/0021:02:01.0/0021:03:00.2
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "tg3"
Driver Modules: "tg3"
Device File: enP33p3s0f2
HW Address: 98:be:94:03:18:4a
Permanent HW Address: 98:be:94:03:18:4a
Link detected: no
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #15 (Ethernet controller)

  38: None 00.0: 10701 Ethernet
[Created at net.126]
Unique ID: 7Onn.ndpeucax6V1
Parent ID: sx0U.aXC4wIvegH8
SysFS ID: /class/net/enP33p3s0f0
SysFS Device Link: 
/devices/pci0021:00/0021:00:00.0/0021:01:00.0/0021:02:01.0/0021:03:00.0
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "tg3"
Driver Modules: "tg3"
Device File: enP33p3s0f0
HW Address: 98:be:94:03:18:48
Permanent HW Address: 98:be:94:03:18:48
Link detected: yes
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #16 (Ethernet controller)

  39: None 00.0: 10701 Ethernet
[Created at net.126]
Unique ID: VwX_.ndpeucax6V1
Parent ID: DUng.aXC4wIvegH8
SysFS ID: /class/net/enP33p3s0f3
SysFS Device Link: 
/devices/pci0021:00/0021:00:00.0/0021:01:00.0/0021:02:01.0/0021:03:00.3
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "tg3"
Driver Modules: "tg3"
Device File: enP33p3s0f3
HW Address: 98:be:94:03:18:4b
Permanent HW Address: 98:be:94:03:18:4b
Link detected: no
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #25 (Ethernet controller)

  40: None 00.0: 10701 Ethernet
[Created at net.126]
Unique ID: bZ1s.ndpeucax6V1
Parent ID: J7HY.aXC4wIvegH8
SysFS ID: /class/net/enP33p3s0f1
SysFS Device Link: 
/devices/pci0021:00/0021:00:00.0/0021:01:00.0/0021:02:01.0/0021:03:00.1
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "tg3"
Driver Modules: "tg3"
Device File: enP33p3s0f1
HW Address: 98:be:94:03:18:49
Permanent HW Address: 98:be:94:03:18:49
Link detected: no
Config Status: cfg=new, avail=yes, need=no, active=unknown
 

[Kernel-packages] [Bug 1687273] Re: Shared folder randomly not mounted

[Nish Aravamudan]

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1687273

Title:
  Shared folder randomly not mounted

Status in cifs-utils package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  New

Bug description:
  Hello Everybody,

  since last update from ubuntu 16.04.2, last night, my servers are
  randomly not able to read and write from shared folders. I got this
  message:

  lsof: WARNING: can't stat() cifs file system /mnt/record
    Output information may be incomplete.
  lsof: WARNING: can't stat() cifs file system /mnt/record
    Output information may be incomplete.
  lsof: WARNING: can't stat() cifs file system /mnt/record
    Output information may be incomplete.
  ...
  rsync: ERROR: cannot stat destination "/mnt/record/": Host is down (112)
  rsync error: errors selecting input/output files, dirs (code 3) at 
main.c(652) [Receiver=3.1.1]

  This comes from my cron script.

  When I type df -h it takes sometimes very long to get the list. And it
  also can be that the mounted share is disconnected and I have to mount
  -a (what also takes long) again.

  My fstab have this command:

  //address /mnt/storage cifs
  
auto,nofail,iocharset=utf8,rw,credentials=/path/.smb,uid=1000,gid=1000,file_mode=0660,dir_mode=0770
  0 0

  My update list from last night was this:

  linux-image-4.4.0-75-generic:amd64 (4.4.0-75.96, automatic)
  linux-image-extra-4.4.0-75-generic:amd64 (4.4.0-75.96, automatic)
  linux-headers-4.4.0-75-generic:amd64 (4.4.0-75.96, automatic)
  linux-headers-4.4.0-75:amd64 (4.4.0-75.96, automatic)
  Upgrade: libdns-export162:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.5, 
1:9.10.3.dfsg.P4-8ubuntu1.6)
  linux-headers-generic:amd64 (4.4.0.72.78, 4.4.0.75.81)
  linux-libc-dev:amd64 (4.4.0-72.93, 4.4.0-75.96)
  mysql-client-5.7:amd64 (5.7.17-0ubuntu0.16.04.2, 5.7.18-0ubuntu0.16.04.1)
  libapt-inst2.0:amd64 (1.2.19, 1.2.20)
  mysql-server-5.7:amd64 (5.7.17-0ubuntu0.16.04.2, 5.7.18-0ubuntu0.16.04.1)
  libsystemd0:amd64 (229-4ubuntu16, 229-4ubuntu17)
  linux-image-generic:amd64 (4.4.0.72.78, 4.4.0.75.81)
  apt:amd64 (1.2.19, 1.2.20)
  mysql-server:amd64 (5.7.17-0ubuntu0.16.04.2, 5.7.18-0ubuntu0.16.04.1)
  udev:amd64 (229-4ubuntu16, 229-4ubuntu17)
  libapt-pkg5.0:amd64 (1.2.19, 1.2.20)
  libudev1:amd64 (229-4ubuntu16, 229-4ubuntu17)
  cifs-utils:amd64 (2:6.4-1ubuntu1, 2:6.4-1ubuntu1.1)
  dpkg:amd64 (1.18.4ubuntu1.1, 1.18.4ubuntu1.2)
  mysql-client-core-5.7:amd64 (5.7.17-0ubuntu0.16.04.2, 5.7.18-0ubuntu0.16.04.1)
  libisc-export160:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.5, 
1:9.10.3.dfsg.P4-8ubuntu1.6)
  linux-virtual:amd64 (4.4.0.72.78, 4.4.0.75.81)
  systemd-sysv:amd64 (229-4ubuntu16, 229-4ubuntu17)
  distro-info-data:amd64 (0.28ubuntu0.2, 0.28ubuntu0.3)
  systemd:amd64 (229-4ubuntu16, 229-4ubuntu17)
  mysql-common:amd64 (5.7.17-0ubuntu0.16.04.2, 5.7.18-0ubuntu0.16.04.1)
  apt-utils:amd64 (1.2.19, 1.2.20)
  libmysqlclient20:amd64 (5.7.17-0ubuntu0.16.04.2, 5.7.18-0ubuntu0.16.04.1)
  linux-headers-virtual:amd64 (4.4.0.72.78, 4.4.0.75.81)
  linux-image-extra-virtual:amd64 (4.4.0.72.78, 4.4.0.75.81)
  thermald:amd64 (1.5-2ubuntu3, 1.5-2ubuntu4)
  qemu-guest-agent:amd64 (1:2.5+dfsg-5ubuntu10.10, 1:2.5+dfsg-5ubuntu10.11)
  libfreetype6:amd64 (2.6.1-0.1ubuntu2.1, 2.6.1-0.1ubuntu2.2)
  linux-image-virtual:amd64 (4.4.0.72.78, 4.4.0.75.81)
  libdpkg-perl:amd64 (1.18.4ubuntu1.1, 1.18.4ubuntu1.2)
  mysql-server-core-5.7:amd64 (5.7.17-0ubuntu0.16.04.2, 5.7.18-0ubuntu0.16.04.1)
  libxslt1.1:amd64 (1.1.28-2.1, 1.1.28-2.1ubuntu0.1)
  dpkg-dev:amd64 (1.18.4ubuntu1.1, 1.18.4ubuntu1.2)

  I saw that somebody else has the same problem:

  https://askubuntu.com/questions/910058/updates-broke-cifs-smb-mounts-
  in-16-04

  I had to remove the latest kernel update, after that it works.

  Regards

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1687273/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1654011] Re: iscsi target not DKMS compiling for kernel 4.4.0-57

[Nish Aravamudan]

*** This bug is a duplicate of bug 1612627 ***
https://bugs.launchpad.net/bugs/1612627

** This bug has been marked a duplicate of bug 1612627
   iscsitarget-dkms 1.4.20.3+svn499-0ubuntu2.1 fails to build on 
linux-generic-lts-xenial kernel

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1654011

Title:
  iscsi target not DKMS compiling for kernel 4.4.0-57

Status in iscsitarget package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  The following extra packages will be installed:
dkms fakeroot libfakeroot
  Suggested packages:
dpkg-dev debhelper iscsitarget
  The following NEW packages will be installed:
dkms fakeroot iscsitarget-dkms libfakeroot
  0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
  Need to get 146 kB/210 kB of archives.
  After this operation, 1,139 kB of additional disk space will be used.
  Preparing to unpack .../dkms_2.2.0.3-1.1ubuntu5.14.04.9_all.deb ...
  Unpacking dkms (2.2.0.3-1.1ubuntu5.14.04.9) ...
  Selecting previously unselected package libfakeroot:amd64.
  Preparing to unpack .../libfakeroot_1.20-3ubuntu2_amd64.deb ...
  Unpacking libfakeroot:amd64 (1.20-3ubuntu2) ...
  Selecting previously unselected package fakeroot.
  Preparing to unpack .../fakeroot_1.20-3ubuntu2_amd64.deb ...
  Unpacking fakeroot (1.20-3ubuntu2) ...
  Selecting previously unselected package iscsitarget-dkms.
  Preparing to unpack .../iscsitarget-dkms_1.4.20.3+svn499-0ubuntu2.1_all.deb 
...
  Unpacking iscsitarget-dkms (1.4.20.3+svn499-0ubuntu2.1) ...
  Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
  Setting up dkms (2.2.0.3-1.1ubuntu5.14.04.9) ...
  Setting up libfakeroot:amd64 (1.20-3ubuntu2) ...
  Setting up fakeroot (1.20-3ubuntu2) ...
  update-alternatives: using /usr/bin/fakeroot-sysv to provide 
/usr/bin/fakeroot (fakeroot) in auto mode
  Setting up iscsitarget-dkms (1.4.20.3+svn499-0ubuntu2.1) ...

  Creating symlink /var/lib/dkms/iscsitarget/1.4.20.3+svn499/source ->
   /usr/src/iscsitarget-1.4.20.3+svn499

  DKMS: add completed.

  Kernel preparation unnecessary for this kernel.  Skipping...

  Building module:
  cleaning build area
  make KERNELRELEASE=4.4.0-57-generic -C /lib/modules/4.4.0-57-generic/build 
M=/var/lib/dkms/iscsitarget/1.4.20.3+svn499/build(bad exit status: 2)
  ERROR: Cannot create report: [Errno 17] File exists: 
'/var/crash/iscsitarget-dkms.0.crash'
  Error! Bad return status for module build on kernel: 4.4.0-57-generic (x86_64)
  Consult /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/make.log for more 
information.

  
  #cat /var/crash/iscsitarget-dkms.0.crash

  ProblemType: Package
  DKMSBuildLog:
   DKMS make.log for iscsitarget-1.4.20.3+svn499 for kernel 4.4.0-57-generic 
(x86_64)
   Tue Jan  3 11:33:44 MSK 2017
   make: Entering directory `/usr/src/linux-headers-4.4.0-57-generic'
 LD  /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/built-in.o
 LD  /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/built-in.o
 CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/tio.o
 CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/iscsi.o
 CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/nthread.o
   /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/nthread.c: In 
function ‘forward_iov’:
   /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/nthread.c:94:6: 
warning: assignment discards ‘const’ qualifier from pointer target type 
[enabled by default]
 iov = msg->msg_iter.iov;
 ^
   /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/nthread.c: In 
function ‘close_conn’:
   /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/nthread.c:676:32: 
warning: assignment from incompatible pointer type [enabled by default]
 conn->sock->sk->sk_data_ready = target->nthread_info.old_data_ready;
   ^
   /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/nthread.c: In 
function ‘do_recv’:
   /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/nthread.c:154:1: 
warning: the frame size of 1128 bytes is larger than 1024 bytes 
[-Wframe-larger-than=]
}
^
 CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/wthread.o
 CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/config.o
 CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/digest.o
 CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/conn.o
   /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/conn.c: In function 
‘iet_socket_bind’:
   /var/lib/dkms/iscsitarget/1.4.20.3+svn499/build/kernel/conn.c:137:38: 
warning: assignment from incompatible pointer type [enabled by default]
 target->nthread_info.old_data_ready = 

[Kernel-packages] [Bug 1382490] Re: Broadcom Bluetooth [413c:8143] does not work at all

[Nish Aravamudan]

@chih: Was helping a user in #ubuntu today with the same device ID
(413c:8143). But I think I'm a bit confused by this, I'm looking at the
upstream source and I see:

$ grep 413c drivers/bluetooth/btusb.c 
{ USB_DEVICE(0x413c, 0x8197) },
{ USB_DEVICE(0x413c, 0x8126), .driver_info = BTUSB_WRONG_SCO_MTU },
{ USB_DEVICE(0x413c, 0x8152), .driver_info = BTUSB_WRONG_SCO_MTU },
{ USB_DEVICE(0x413c, 0x8156), .driver_info = BTUSB_WRONG_SCO_MTU },

I don't see 0x8143 product Id listed as a matching USB device? So even
if a user were to have the correct firmware in place (the user on
#ubuntu did, afaict), btusb won't match. Is this really an upstream bug?

Thanks,
Nish

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1382490

Title:
  Broadcom Bluetooth [413c:8143] does not work at all

Status in HWE Next:
  Won't Fix
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  CID: 201307-13942 Dell Latitude E5540

  The Bluetooth can't find any devices.
  Error message could be found in dmesg:
  [   98.149145] Bluetooth: can't load firmware, may not work correctly

  Note that sometimes it works, but if you disable and re-enable it with
  the wifi slider (let it reload the firmware), it will stop working.

  Steps:
  1. Install 14.04.1 + update (3.13.0-37) + proprietary Broadcom driver
  2. Try to pair with any other Bluetooth device.

  Expected result:
  * Bluetooth works well as expected.

  Actual result:
  * Nothing can be detected.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.13.0-37-generic 3.13.0-37.64
  ProcVersionSignature: Ubuntu 3.13.0-37.64-generic 3.13.11.7
  Uname: Linux 3.13.0-37-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.14.1-0ubuntu3.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  ubuntu 1542 F pulseaudio
   /dev/snd/controlC0:  ubuntu 1542 F pulseaudio
  CurrentDesktop: Unity
  Date: Fri Oct 17 04:14:55 2014
  HibernationDevice: RESUME=UUID=b150a530-b9dc-40f0-b867-a29dfbf5b499
  InstallationDate: Installed on 2014-10-17 (0 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  MachineType: Dell Inc. Latitude E5540
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-37-generic.efi.signed 
root=UUID=7a7e4c31-030c-4e00-af99-14797716597e ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.13.0-37-generic N/A
   linux-backports-modules-3.13.0-37-generic  N/A
   linux-firmware 1.127.7
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/19/2013
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A01
  dmi.board.name: 0V19JF
  dmi.board.vendor: Dell Inc.
  dmi.board.version: X02
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA01:bd09/19/2013:svnDellInc.:pnLatitudeE5540:pvr01:rvnDellInc.:rn0V19JF:rvrX02:cvnDellInc.:ct9:cvr:
  dmi.product.name: Latitude E5540
  dmi.product.version: 01
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1382490/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1065400] Re: Support for loading Broadcom bluetooth firmware

[Nish Aravamudan]

It seems like 14.04.0/1's kernel would still need this backport -- 3.13
base and the upstream fix went into 3.14.

** Also affects: linux (Ubuntu Trusty)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1065400

Title:
  Support for loading Broadcom bluetooth firmware

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Precise:
  Fix Released
Status in linux source package in Quantal:
  Fix Released
Status in linux source package in Raring:
  Fix Released
Status in linux source package in Saucy:
  Fix Released
Status in linux source package in Trusty:
  New

Bug description:
  Broadcom bluetooth chips require a tool called patchram uploader [1]
  to load firmware. This applies to at least BCM20702 and BCM43142.
  Although some of the devices have an OTPROM that contains required
  firmware, but it is found that these devices would not have HFP/HSP
  support unless a upgraded firmware is loaded via patchram uploader.

  This tool requires hci device to do the firmware loading, but this may
  cause some race condition between patchram tool and bluetoothd or
  something that also works on hci interface.

  Also it needs some hooks to make firmware loads after bootup, s3,  s4,
  rfkill, and device hotplug events. Implement this loader in kernel
  module would make things more easier.

  [1] http://marc.info/?l=linux-bluetooth=132039175324993=2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065400/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1628284] Re: yakkety: daily powerpc server ISO fails to find cdrom during install in a VM

[Nish Aravamudan]

Hi Tim,

Discussed this with Josh Powers and it seems at least this particular
issue is now fixed, sorry for the delay on my end.

-Nish

** Changed in: linux (Ubuntu Yakkety)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1628284

Title:
  yakkety: daily powerpc server ISO fails to find cdrom during install
  in a VM

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  xenial daily ISO successfully installs using the same method on the
  same system, but yakkety reports:

  Sep 27 21:13:14 cdrom-detect: Searching for Ubuntu installation media...
  Sep 27 21:13:18 cdrom-detect: Devices: ''
  Sep 27 21:13:23 cdrom-detect: Devices: ''
  Sep 27 21:13:24 kernel: [  154.649279] random: crng init done
  Sep 27 21:13:28 cdrom-detect: Devices: ''
  Sep 27 21:13:33 cdrom-detect: Devices: ''
  Sep 27 21:13:38 cdrom-detect: Devices: ''
  Sep 27 21:13:43 cdrom-detect: Devices: ''
  Sep 27 21:13:48 cdrom-detect: Devices: ''
  Sep 27 21:13:53 cdrom-detect: Devices: ''
  Sep 27 21:13:58 cdrom-detect: Devices: ''
  Sep 27 21:14:06 cdrom-detect: CDROM-detect failed; unmounting CD just to be 
sure
  Sep 27 21:14:06 main-menu[267]: WARNING **: Configuring 'cdrom-detect' failed 
with error code 1
  Sep 27 21:14:06 main-menu[267]: WARNING **: Menu item 'cdrom-detect' failed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1628284] Re: yakkety: daily powerpc server ISO fails to find cdrom during install in a VM

[Nish Aravamudan]

uname -a from the installer shell:

Linux (none) 4.8.0-17-generic #19-Ubuntu SMP Sun Sep 25 05:58:36 UTC
2016 ppc64 GNU/Linux

We blocked release of the powerpc iso for beta2 because of this bug in
#ubuntu-release, so there is no beta-2 image :)

For the net boot iso, (maybe because of the virtualized nic?) no network
device is found and errors out there too.

Note this is trivially reproducible on a ppc64le host with:

qemu-system-ppc64 -enable-kvm -machine pseries,accel=kvm,usb=off -cpu
host -smp cores=2,threads=1 -m 8G -no-reboot -device spapr-vscsi
-display none -nographic -cdrom yakkety-server-powerpc.iso -drive
file=/path/to/qcow/file,cache=unsafe -net nic -net user -boot dc

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1628284

Title:
  yakkety: daily powerpc server ISO fails to find cdrom during install
  in a VM

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Yakkety:
  In Progress

Bug description:
  xenial daily ISO successfully installs using the same method on the
  same system, but yakkety reports:

  Sep 27 21:13:14 cdrom-detect: Searching for Ubuntu installation media...
  Sep 27 21:13:18 cdrom-detect: Devices: ''
  Sep 27 21:13:23 cdrom-detect: Devices: ''
  Sep 27 21:13:24 kernel: [  154.649279] random: crng init done
  Sep 27 21:13:28 cdrom-detect: Devices: ''
  Sep 27 21:13:33 cdrom-detect: Devices: ''
  Sep 27 21:13:38 cdrom-detect: Devices: ''
  Sep 27 21:13:43 cdrom-detect: Devices: ''
  Sep 27 21:13:48 cdrom-detect: Devices: ''
  Sep 27 21:13:53 cdrom-detect: Devices: ''
  Sep 27 21:13:58 cdrom-detect: Devices: ''
  Sep 27 21:14:06 cdrom-detect: CDROM-detect failed; unmounting CD just to be 
sure
  Sep 27 21:14:06 main-menu[267]: WARNING **: Configuring 'cdrom-detect' failed 
with error code 1
  Sep 27 21:14:06 main-menu[267]: WARNING **: Menu item 'cdrom-detect' failed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1628284] Re: yakkety: daily powerpc server ISO fails to find cdrom during install in a VM

[Nish Aravamudan]

I'm not able to run apport-collect from the installer shell.

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1628284

Title:
  yakkety: daily powerpc server ISO fails to find cdrom during install
  in a VM

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  xenial daily ISO successfully installs using the same method on the
  same system, but yakkety reports:

  Sep 27 21:13:14 cdrom-detect: Searching for Ubuntu installation media...
  Sep 27 21:13:18 cdrom-detect: Devices: ''
  Sep 27 21:13:23 cdrom-detect: Devices: ''
  Sep 27 21:13:24 kernel: [  154.649279] random: crng init done
  Sep 27 21:13:28 cdrom-detect: Devices: ''
  Sep 27 21:13:33 cdrom-detect: Devices: ''
  Sep 27 21:13:38 cdrom-detect: Devices: ''
  Sep 27 21:13:43 cdrom-detect: Devices: ''
  Sep 27 21:13:48 cdrom-detect: Devices: ''
  Sep 27 21:13:53 cdrom-detect: Devices: ''
  Sep 27 21:13:58 cdrom-detect: Devices: ''
  Sep 27 21:14:06 cdrom-detect: CDROM-detect failed; unmounting CD just to be 
sure
  Sep 27 21:14:06 main-menu[267]: WARNING **: Configuring 'cdrom-detect' failed 
with error code 1
  Sep 27 21:14:06 main-menu[267]: WARNING **: Menu item 'cdrom-detect' failed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1628284] [NEW] yakkety: daily powerpc server ISO fails to find cdrom during install in a VM

[Nish Aravamudan]

Public bug reported:

xenial daily ISO successfully installs using the same method on the same
system, but yakkety reports:

Sep 27 21:13:14 cdrom-detect: Searching for Ubuntu installation media...
Sep 27 21:13:18 cdrom-detect: Devices: ''
Sep 27 21:13:23 cdrom-detect: Devices: ''
Sep 27 21:13:24 kernel: [  154.649279] random: crng init done
Sep 27 21:13:28 cdrom-detect: Devices: ''
Sep 27 21:13:33 cdrom-detect: Devices: ''
Sep 27 21:13:38 cdrom-detect: Devices: ''
Sep 27 21:13:43 cdrom-detect: Devices: ''
Sep 27 21:13:48 cdrom-detect: Devices: ''
Sep 27 21:13:53 cdrom-detect: Devices: ''
Sep 27 21:13:58 cdrom-detect: Devices: ''
Sep 27 21:14:06 cdrom-detect: CDROM-detect failed; unmounting CD just to be sure
Sep 27 21:14:06 main-menu[267]: WARNING **: Configuring 'cdrom-detect' failed 
with error code 1
Sep 27 21:14:06 main-menu[267]: WARNING **: Menu item 'cdrom-detect' failed.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1628284

Title:
  yakkety: daily powerpc server ISO fails to find cdrom during install
  in a VM

Status in linux package in Ubuntu:
  New

Bug description:
  xenial daily ISO successfully installs using the same method on the
  same system, but yakkety reports:

  Sep 27 21:13:14 cdrom-detect: Searching for Ubuntu installation media...
  Sep 27 21:13:18 cdrom-detect: Devices: ''
  Sep 27 21:13:23 cdrom-detect: Devices: ''
  Sep 27 21:13:24 kernel: [  154.649279] random: crng init done
  Sep 27 21:13:28 cdrom-detect: Devices: ''
  Sep 27 21:13:33 cdrom-detect: Devices: ''
  Sep 27 21:13:38 cdrom-detect: Devices: ''
  Sep 27 21:13:43 cdrom-detect: Devices: ''
  Sep 27 21:13:48 cdrom-detect: Devices: ''
  Sep 27 21:13:53 cdrom-detect: Devices: ''
  Sep 27 21:13:58 cdrom-detect: Devices: ''
  Sep 27 21:14:06 cdrom-detect: CDROM-detect failed; unmounting CD just to be 
sure
  Sep 27 21:14:06 main-menu[267]: WARNING **: Configuring 'cdrom-detect' failed 
with error code 1
  Sep 27 21:14:06 main-menu[267]: WARNING **: Menu item 'cdrom-detect' failed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1376771] Re: DisplayLink Attached Display Adapter and Monitor Not Recognized

[Nish Aravamudan]

Re-tested in 16.10, and the displaylink driver does work, but is much
much laggier than in 16.04. Not yet had a chance to debug that.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1376771

Title:
  DisplayLink Attached Display Adapter and Monitor Not Recognized

Status in linux package in Ubuntu:
  Triaged

Bug description:
  DisplayLink Plug and Play Universal docking Station
  DELL
  Model: D3000
  MFG: ACP075US
  SN: 1309017059

  All ports on the device are recocognized and function correctly except
  the display adapter.

  Description:  Ubuntu Utopic Unicorn (development branch)
  Release:  14.10

  This problem also exists under trusty. 14.04

  My intention is to drive 2 external monitors with this device.
  This specific device has no issues under Windows 8.1

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: linux-image-3.16.0-20-generic 3.16.0-20.27
  ProcVersionSignature: Ubuntu 3.16.0-20.27-generic 3.16.3
  Uname: Linux 3.16.0-20-generic x86_64
  ApportVersion: 2.14.7-0ubuntu2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  gesker 2140 F pulseaudio
  CurrentDesktop: Unity
  Date: Thu Oct  2 08:54:53 2014
  HibernationDevice: RESUME=UUID=8d719d41-d691-447b-8dd0-29bbdd631465
  InstallationDate: Installed on 2014-08-24 (38 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  MachineType: System76, Inc. Gazelle Professional
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-3.16.0-20-generic 
root=UUID=5dc9a0a5-84ba-495e-b644-8d11f37bece5 ro rootflags=subvol=@ quiet 
splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.16.0-20-generic N/A
   linux-backports-modules-3.16.0-20-generic  N/A
   linux-firmware 1.134
  SourcePackage: linux
  UpgradeStatus: Upgraded to utopic on 2014-09-26 (5 days ago)
  dmi.bios.date: 05/16/2012
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: Gazelle Professional
  dmi.board.vendor: System76, Inc.
  dmi.board.version: gazp7
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: No Enclosure
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd05/16/2012:svnSystem76,Inc.:pnGazelleProfessional:pvrgazp7:rvnSystem76,Inc.:rnGazelleProfessional:rvrgazp7:cvnNoEnclosure:ct9:cvrN/A:
  dmi.product.name: Gazelle Professional
  dmi.product.version: gazp7
  dmi.sys.vendor: System76, Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1376771/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1376771] Re: DisplayLink Attached Display Adapter and Monitor Not Recognized

[Nish Aravamudan]

Not sure if this will really help here, but I have a D3100 and I was
able to drive two monitors using
http://www.displaylink.com/downloads/ubuntu on 16.04. 16.10 again breaks
it since the out-of-tree driver doesn't build against the later kernels
(or so it seems). I wonder if this is something worth packaging into
Ubuntu proper (or contacting DisplayLink about).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1376771

Title:
  DisplayLink Attached Display Adapter and Monitor Not Recognized

Status in linux package in Ubuntu:
  Triaged

Bug description:
  DisplayLink Plug and Play Universal docking Station
  DELL
  Model: D3000
  MFG: ACP075US
  SN: 1309017059

  All ports on the device are recocognized and function correctly except
  the display adapter.

  Description:  Ubuntu Utopic Unicorn (development branch)
  Release:  14.10

  This problem also exists under trusty. 14.04

  My intention is to drive 2 external monitors with this device.
  This specific device has no issues under Windows 8.1

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: linux-image-3.16.0-20-generic 3.16.0-20.27
  ProcVersionSignature: Ubuntu 3.16.0-20.27-generic 3.16.3
  Uname: Linux 3.16.0-20-generic x86_64
  ApportVersion: 2.14.7-0ubuntu2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  gesker 2140 F pulseaudio
  CurrentDesktop: Unity
  Date: Thu Oct  2 08:54:53 2014
  HibernationDevice: RESUME=UUID=8d719d41-d691-447b-8dd0-29bbdd631465
  InstallationDate: Installed on 2014-08-24 (38 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  MachineType: System76, Inc. Gazelle Professional
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-3.16.0-20-generic 
root=UUID=5dc9a0a5-84ba-495e-b644-8d11f37bece5 ro rootflags=subvol=@ quiet 
splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.16.0-20-generic N/A
   linux-backports-modules-3.16.0-20-generic  N/A
   linux-firmware 1.134
  SourcePackage: linux
  UpgradeStatus: Upgraded to utopic on 2014-09-26 (5 days ago)
  dmi.bios.date: 05/16/2012
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: Gazelle Professional
  dmi.board.vendor: System76, Inc.
  dmi.board.version: gazp7
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: No Enclosure
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd05/16/2012:svnSystem76,Inc.:pnGazelleProfessional:pvrgazp7:rvnSystem76,Inc.:rnGazelleProfessional:rvrgazp7:cvnNoEnclosure:ct9:cvrN/A:
  dmi.product.name: Gazelle Professional
  dmi.product.version: gazp7
  dmi.sys.vendor: System76, Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1376771/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1433906] Re: Acer, Inc ID 5986:055a is useless after 14.04.2 installed.

[Nish Aravamudan]

To clarify to everyone possibly affected by this bug, and in reviewing
the thread @Henrik provided, it seems like the upstream community
(linux-uvc) has reviewed the patch and asked for some modifications
(April 27, 2016). So that is why the patch has not made its way into
Ubuntu kernels yet, as it's not yet fixed upstream.

@Henrik, do you have any update on that side of things? Thank you for
helping make Linux & Ubuntu better!

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-utopic in Ubuntu.
https://bugs.launchpad.net/bugs/1433906

Title:
  Acer, Inc ID 5986:055a is useless after 14.04.2 installed.

Status in HWE Next:
  Won't Fix
Status in linux-lts-utopic package in Ubuntu:
  Triaged
Status in linux-lts-vivid package in Ubuntu:
  Triaged
Status in linux-lts-wily package in Ubuntu:
  Confirmed
Status in linux-lts-xenial package in Ubuntu:
  Confirmed
Status in linux package in Arch Linux:
  New
Status in Fedora:
  Unknown

Bug description:
  CID : 201411-16166 Lenovo E450 (I+A) with 14.04.2 (utopic)
  CID : 201408-15472 Lenovo E555 (A+A) with 14.04.2 (utopic)

  Steps:
  1. Install 14.04.2 on E450 or E555.
  2. Log in system and open a terminal.
  3. $ gst-launch-0.10 v4l2src ! xvimagesink

  Expected result:
  Camara is activated

  Actual result:
  $  gst-launch-0.10 v4l2src ! xvimagesink
  Setting pipeline to PAUSED ...
  ERROR: Pipeline doesn't want to pause.
  ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Cannot 
identify device '/dev/video0'.
  Additional debug info:
  v4l2_calls.c(497): gst_v4l2_open (): 
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
  system error: No such file or directory
  Setting pipeline to NULL ...
  Freeing pipeline ...

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.16.0-30-generic 3.16.0-30.40~14.04.1 [modified: 
boot/vmlinuz-3.16.0-30-generic]
  ProcVersionSignature: Ubuntu 3.16.0-30.40~14.04.1-generic 3.16.7-ckt3
  Uname: Linux 3.16.0-30-generic x86_64
  NonfreeKernelModules: fglrx
  ApportVersion: 2.14.1-0ubuntu3.7
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Thu Mar 19 02:21:31 2015
  InstallationDate: Installed on 2015-03-16 (2 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  SourcePackage: linux-lts-utopic
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1433906/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1573231] Re: Kernel Panic on EC2 After Upgrading from 14.04 to 16.04 via do-release-upgrade -d

[Nish Aravamudan]

@Joe, based upon the identified commit, I wonder if it would be worth
testing backports of follow-on fixes specifically for that commit?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b5d5f27d938fb6fc8d3202704e699d2694a02da6
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=63d1e995be455ae9196270eb4b789de21afd42ed
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b5d5f27d938fb6fc8d3202704e699d2694a02da6

Not sure if all of them are necessary but the second one esp. might be
relevant as it changes the divisor.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1573231

Title:
  Kernel Panic on EC2 After Upgrading from 14.04 to 16.04 via do-
  release-upgrade -d

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Yakkety:
  In Progress

Bug description:
  [0.00] Initializing cgroup subsys cpuset
  [0.00] Initializing cgroup subsys cpu
  [0.00] Initializing cgroup subsys cpuacct
  [0.00] Linux version 4.4.0-21-generic (buildd@lgw01-21) (gcc version 
5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) ) #37-Ubuntu SMP Mon Apr 18 18:33:37 
UTC 2016 (Ubuntu 4.4.0-21.37-generic 4.4.6)
  [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic 
root=UUID=8ea401db-b84b-4cd6-a628-d72f30bbf1e5 ro console=tty1 console=ttyS0
  [0.00] KERNEL supported cpus:
  [0.00]   Intel GenuineIntel
  [0.00]   AMD AuthenticAMD
  [0.00]   Centaur CentaurHauls
  [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
  [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point 
registers'
  [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
  [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
  [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 
bytes, using 'standard' format.
  [0.00] x86/fpu: Using 'eager' FPU context switches.
  [0.00] e820: BIOS-provided physical RAM map:
  [0.00] BIOS-e820: [mem 0x-0x0009dfff] usable
  [0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
  [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
  [0.00] BIOS-e820: [mem 0x0010-0xefff] usable
  [0.00] BIOS-e820: [mem 0xfc00-0x] reserved
  [0.00] BIOS-e820: [mem 0x0001-0x0001efff] usable
  [0.00] NX (Execute Disable) protection: active
  [0.00] SMBIOS 2.4 present.
  [0.00] Hypervisor detected: Xen
  [0.00] Xen version 4.2.
  [0.00] Netfront and the Xen platform PCI driver have been compiled 
for this kernel: unplug emulated NICs.
  [0.00] Blkfront and the Xen platform PCI driver have been compiled 
for this kernel: unplug emulated disks.
  [0.00] You might have to change the root device
  [0.00] from /dev/hd[a-d] to /dev/xvd[a-d]
  [0.00] in your root= kernel command line option
  [0.00] e820: last_pfn = 0x1f max_arch_pfn = 0x4
  [0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
  [0.00] e820: last_pfn = 0xf max_arch_pfn = 0x4
  [0.00] found SMP MP-table at [mem 0x000fbba0-0x000fbbaf] mapped at 
[880fbba0]
  [0.00] Scanning 1 areas for low memory corruption
  [0.00] RAMDISK: [mem 0x3407e000-0x36036fff]
  [0.00] ACPI: Early table checksum verification disabled
  [0.00] ACPI: RSDP 0x000EA020 24 (v02 Xen   )
  [0.00] ACPI: XSDT 0xFC00F5A0 54 (v01 XenHVM  
 HVML )
  [0.00] ACPI: FACP 0xFC00F260 F4 (v04 XenHVM  
 HVML )
  [0.00] ACPI: DSDT 0xFC0035E0 00BBF6 (v02 XenHVM  
 INTL 20090123)
  [0.00] ACPI: FACS 0xFC0035A0 40
  [0.00] ACPI: FACS 0xFC0035A0 40
  [0.00] ACPI: APIC 0xFC00F360 D8 (v02 XenHVM  
 HVML )
  [0.00] ACPI: HPET 0xFC00F4B0 38 (v01 XenHVM  
 HVML )
  [0.00] ACPI: WAET 0xFC00F4F0 28 (v01 XenHVM  
 HVML )
  [0.00] ACPI: SSDT 0xFC00F520 31 (v02 XenHVM  
 INTL 20090123)
  [0.00] ACPI: SSDT 0xFC00F560 31 (v02 XenHVM  
 INTL 20090123)
  [0.00] No NUMA configuration found
  [0.00] Faking a node at [mem 0x-0x0001efff]
  [0.00] NODE_DATA(0) allocated [mem 0x1efff7000-0x1efffbfff]
  [0.00] Zone ranges:
  [0.00]   DMA  

[Kernel-packages] [Bug 1573231] Re: Kernel Panic on EC2 After Upgrading from 14.04 to 16.04 via do-release-upgrade -d

[Nish Aravamudan]

Err, apologies Joe, it does seem like upon more careful reading of the
bug report, the second mentioned commit (comment #18) specifically
introduced the regression? That seems unlikely at best given it's
contents, rights? That is, if the divisor was zero after that commit, it
was zero before it, too, unless there's another division going on that's
implicit.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1573231

Title:
  Kernel Panic on EC2 After Upgrading from 14.04 to 16.04 via do-
  release-upgrade -d

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Yakkety:
  In Progress

Bug description:
  [0.00] Initializing cgroup subsys cpuset
  [0.00] Initializing cgroup subsys cpu
  [0.00] Initializing cgroup subsys cpuacct
  [0.00] Linux version 4.4.0-21-generic (buildd@lgw01-21) (gcc version 
5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) ) #37-Ubuntu SMP Mon Apr 18 18:33:37 
UTC 2016 (Ubuntu 4.4.0-21.37-generic 4.4.6)
  [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic 
root=UUID=8ea401db-b84b-4cd6-a628-d72f30bbf1e5 ro console=tty1 console=ttyS0
  [0.00] KERNEL supported cpus:
  [0.00]   Intel GenuineIntel
  [0.00]   AMD AuthenticAMD
  [0.00]   Centaur CentaurHauls
  [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
  [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point 
registers'
  [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
  [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
  [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 
bytes, using 'standard' format.
  [0.00] x86/fpu: Using 'eager' FPU context switches.
  [0.00] e820: BIOS-provided physical RAM map:
  [0.00] BIOS-e820: [mem 0x-0x0009dfff] usable
  [0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
  [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
  [0.00] BIOS-e820: [mem 0x0010-0xefff] usable
  [0.00] BIOS-e820: [mem 0xfc00-0x] reserved
  [0.00] BIOS-e820: [mem 0x0001-0x0001efff] usable
  [0.00] NX (Execute Disable) protection: active
  [0.00] SMBIOS 2.4 present.
  [0.00] Hypervisor detected: Xen
  [0.00] Xen version 4.2.
  [0.00] Netfront and the Xen platform PCI driver have been compiled 
for this kernel: unplug emulated NICs.
  [0.00] Blkfront and the Xen platform PCI driver have been compiled 
for this kernel: unplug emulated disks.
  [0.00] You might have to change the root device
  [0.00] from /dev/hd[a-d] to /dev/xvd[a-d]
  [0.00] in your root= kernel command line option
  [0.00] e820: last_pfn = 0x1f max_arch_pfn = 0x4
  [0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
  [0.00] e820: last_pfn = 0xf max_arch_pfn = 0x4
  [0.00] found SMP MP-table at [mem 0x000fbba0-0x000fbbaf] mapped at 
[880fbba0]
  [0.00] Scanning 1 areas for low memory corruption
  [0.00] RAMDISK: [mem 0x3407e000-0x36036fff]
  [0.00] ACPI: Early table checksum verification disabled
  [0.00] ACPI: RSDP 0x000EA020 24 (v02 Xen   )
  [0.00] ACPI: XSDT 0xFC00F5A0 54 (v01 XenHVM  
 HVML )
  [0.00] ACPI: FACP 0xFC00F260 F4 (v04 XenHVM  
 HVML )
  [0.00] ACPI: DSDT 0xFC0035E0 00BBF6 (v02 XenHVM  
 INTL 20090123)
  [0.00] ACPI: FACS 0xFC0035A0 40
  [0.00] ACPI: FACS 0xFC0035A0 40
  [0.00] ACPI: APIC 0xFC00F360 D8 (v02 XenHVM  
 HVML )
  [0.00] ACPI: HPET 0xFC00F4B0 38 (v01 XenHVM  
 HVML )
  [0.00] ACPI: WAET 0xFC00F4F0 28 (v01 XenHVM  
 HVML )
  [0.00] ACPI: SSDT 0xFC00F520 31 (v02 XenHVM  
 INTL 20090123)
  [0.00] ACPI: SSDT 0xFC00F560 31 (v02 XenHVM  
 INTL 20090123)
  [0.00] No NUMA configuration found
  [0.00] Faking a node at [mem 0x-0x0001efff]
  [0.00] NODE_DATA(0) allocated [mem 0x1efff7000-0x1efffbfff]
  [0.00] Zone ranges:
  [0.00]   DMA  [mem 0x1000-0x00ff]
  [0.00]   DMA32[mem 0x0100-0x]
  [0.00]   Normal   [mem 0x0001-0x0001efff]
  [0.00]   Device   empty
  [

Re: [Kernel-packages] [Bug 1567539] Re: Failure to dump with trusty+3.16 on ppc64el

[Nish Aravamudan]

On 13.04.2016 [23:44:39 -], Dave Chiluk wrote:
> So it looks like this crashkernel argument is not resulting in any reserved 
> memory.
> The correct crashkernel argument should look like this.
> crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M@32M
> 
> Additionally my earlier failures here were the result of no reserved
> memory being allocated due to the way crashkernel parses the @32M.

Totally my fault, I glossed that on reading, there is only one offset
allowed, aiui, as only one of the above cases ever applies to a given
execution. And the offset should not need to be different for differnt
values (as the pre-allocated memory you are presumably bumping into is
at the same location in all cases).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1567539

Title:
  Failure to dump with trusty+3.16 on ppc64el

Status in makedumpfile package in Ubuntu:
  Confirmed

Bug description:
  Test case
  # sudo apt-get install linux-crashdump

  set USE_KDUMP=1 in /etc/default/kdump-tools

  # sudo shutdown -r now

  echo 1 | sudo tee /proc/sys/kernel/sysrq
  echo c | sudo tee /proc/sysrq-trigger

  It looks like there was insufficient memory devoted to the crash
  kernel.  The defaults were used, and the kernel had 256G of ram, and
  only 2.6G were in use at the time of inducing the crash.

  Console log 

  [  290.509423] SysRq : Trigger a crash
  [  290.509526] Unable to handle kernel paging request for data at address 
0x
  [  290.509606] Faulting instruction address: 0xc05d9c94
  [  290.509672] Oops: Kernel access of bad area, sig: 11 [#1]
  [  290.509723] SMP NR_CPUS=2048 NUMA PowerNV
  [  290.509776] Modules linked in: ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad 
ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt 
rtc_generic i2c_opal powernv_rng uio_pdrv_genirq ipmi_powernv ipmi_msghandler 
uio mlx4_en vxlan ses enclosure mlx4_core ipr
  [  290.510178] CPU: 121 PID: 2976 Comm: tee Not tainted 3.16.0-69-generic 
#89~14.04.1-Ubuntu
  [  290.510254] task: c01fdccf4a80 ti: c01fdcd58000 task.ti: 
c01fdcd58000
  [  290.510330] NIP: c05d9c94 LR: c05dad0c CTR: 
c05d9c60
  [  290.510406] REGS: c01fdcd5b9d0 TRAP: 0300   Not tainted  
(3.16.0-69-generic)
  [  290.510480] MSR: 90009033   CR: 28004024  
XER: 2000
  [  290.510671] CFAR: c0009368 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05dad0c c01fdcd5bc50 c13d7d00 0063
  GPR04: c6548540 c6558da8 00016fa0 c1596218
  GPR08: c0e37d00  0001 00016fa0
  GPR12: c05d9c60 c7bc4100  
  GPR16:    
  GPR20:   100094d8 100094c0
  GPR24: 0001 100094d8 0004 
  GPR28: c130f6c0 0063 c12ed7a0 c130fa80
  [  290.511676] NIP [c05d9c94] sysrq_handle_crash+0x34/0x50
  [  290.511742] LR [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511793] Call Trace:
  [  290.511820] [c01fdcd5bc50] [c01fdcd5bcb0] 0xc01fdcd5bcb0 
(unreliable)
  [  290.511911] [c01fdcd5bc70] [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511988] [c01fdcd5bd10] [c05db4dc] 
write_sysrq_trigger+0x7c/0xa0
  [  290.512078] [c01fdcd5bd40] [c032e1d0] proc_reg_write+0xb0/0x110
  [  290.512155] [c01fdcd5bd90] [c02a47ec] vfs_write+0xdc/0x260
  [  290.512231] [c01fdcd5bde0] [c02a558c] SyS_write+0x6c/0x110
  [  290.512308] [c01fdcd5be30] [c000a1d8] system_call+0x38/0xd0
  [  290.512383] Instruction dump:
  [  290.512421] 3842e0a0 7c0802a6 f8010010 f821ffe1 6000 6000 3d42001b 
392a006c
  [  290.512546] 3941 9149 7c0004ac 3920 <9949> 38210020 
e8010010 7c0803a6
  [  290.512674] ---[ end trace ba4afa55b8a163cd ]---
  [  290.512735]
  [  290.513754] Sending IPI to other CPUs
  [  290.514897] IPI complete
  [0.00] OPAL V3 detected !
  [0.00] Using PowerNV machine description
  [0.00] Page sizes from device-tree:
  [0.00] base_shift=12: shift=12, sllp=0x, avpnm=0x, 
tlbiel=1, penc=0
  [0.00] base_shift=12: shift=16, sllp=0x, avpnm=0x, 
tlbiel=1, penc=7
  [0.00] base_shift=12: shift=24, sllp=0x, avpnm=0x, 
tlbiel=1, penc=56
  [0.00] base_shift=16: shift=16, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=1
  [0.00] base_shift=16: shift=24, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=8
  [0.00] base_shift=24: shift=24, sllp=0x0100, 

Re: [Kernel-packages] [Bug 1567539] Re: Failure to dump with trusty+3.16 on ppc64el

[Nish Aravamudan]

On 12.04.2016 [21:13:40 -], Dave Chiluk wrote:
> With 
> ubuntu@modoc:~$ cat /proc/cmdline
> root=/dev/mapper/mpath0-part2 ro console=hvc0 
> crashkernel=2G-4G:320M@32M,4G-32G:512M@32M,32G-64G:1024M@32M,64G-128G:2048M@32M,128G-:4096M@32M
> 
> I get the following console log
> [  191.833046] SysRq : Trigger a crash
> [  191.833117] Unable to handle kernel paging request for data at address 
> 0x
> [  191.833123] Faulting instruction address: 0xc05eeb94
> [  191.83
> 
> That is it.  I will continue testing.

This is over the IPMI console? Sorry I should have been more explicit,
but is it possible to provide the full logs from before the crash is
attempted? (dmesg is fine).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1567539

Title:
  Failure to dump with trusty+3.16 on ppc64el

Status in makedumpfile package in Ubuntu:
  Confirmed

Bug description:
  Test case
  # sudo apt-get install linux-crashdump

  set USE_KDUMP=1 in /etc/default/kdump-tools

  # sudo shutdown -r now

  echo 1 | sudo tee /proc/sys/kernel/sysrq
  echo c | sudo tee /proc/sysrq-trigger

  It looks like there was insufficient memory devoted to the crash
  kernel.  The defaults were used, and the kernel had 256G of ram, and
  only 2.6G were in use at the time of inducing the crash.

  Console log 

  [  290.509423] SysRq : Trigger a crash
  [  290.509526] Unable to handle kernel paging request for data at address 
0x
  [  290.509606] Faulting instruction address: 0xc05d9c94
  [  290.509672] Oops: Kernel access of bad area, sig: 11 [#1]
  [  290.509723] SMP NR_CPUS=2048 NUMA PowerNV
  [  290.509776] Modules linked in: ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad 
ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt 
rtc_generic i2c_opal powernv_rng uio_pdrv_genirq ipmi_powernv ipmi_msghandler 
uio mlx4_en vxlan ses enclosure mlx4_core ipr
  [  290.510178] CPU: 121 PID: 2976 Comm: tee Not tainted 3.16.0-69-generic 
#89~14.04.1-Ubuntu
  [  290.510254] task: c01fdccf4a80 ti: c01fdcd58000 task.ti: 
c01fdcd58000
  [  290.510330] NIP: c05d9c94 LR: c05dad0c CTR: 
c05d9c60
  [  290.510406] REGS: c01fdcd5b9d0 TRAP: 0300   Not tainted  
(3.16.0-69-generic)
  [  290.510480] MSR: 90009033   CR: 28004024  
XER: 2000
  [  290.510671] CFAR: c0009368 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05dad0c c01fdcd5bc50 c13d7d00 0063
  GPR04: c6548540 c6558da8 00016fa0 c1596218
  GPR08: c0e37d00  0001 00016fa0
  GPR12: c05d9c60 c7bc4100  
  GPR16:    
  GPR20:   100094d8 100094c0
  GPR24: 0001 100094d8 0004 
  GPR28: c130f6c0 0063 c12ed7a0 c130fa80
  [  290.511676] NIP [c05d9c94] sysrq_handle_crash+0x34/0x50
  [  290.511742] LR [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511793] Call Trace:
  [  290.511820] [c01fdcd5bc50] [c01fdcd5bcb0] 0xc01fdcd5bcb0 
(unreliable)
  [  290.511911] [c01fdcd5bc70] [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511988] [c01fdcd5bd10] [c05db4dc] 
write_sysrq_trigger+0x7c/0xa0
  [  290.512078] [c01fdcd5bd40] [c032e1d0] proc_reg_write+0xb0/0x110
  [  290.512155] [c01fdcd5bd90] [c02a47ec] vfs_write+0xdc/0x260
  [  290.512231] [c01fdcd5bde0] [c02a558c] SyS_write+0x6c/0x110
  [  290.512308] [c01fdcd5be30] [c000a1d8] system_call+0x38/0xd0
  [  290.512383] Instruction dump:
  [  290.512421] 3842e0a0 7c0802a6 f8010010 f821ffe1 6000 6000 3d42001b 
392a006c
  [  290.512546] 3941 9149 7c0004ac 3920 <9949> 38210020 
e8010010 7c0803a6
  [  290.512674] ---[ end trace ba4afa55b8a163cd ]---
  [  290.512735]
  [  290.513754] Sending IPI to other CPUs
  [  290.514897] IPI complete
  [0.00] OPAL V3 detected !
  [0.00] Using PowerNV machine description
  [0.00] Page sizes from device-tree:
  [0.00] base_shift=12: shift=12, sllp=0x, avpnm=0x, 
tlbiel=1, penc=0
  [0.00] base_shift=12: shift=16, sllp=0x, avpnm=0x, 
tlbiel=1, penc=7
  [0.00] base_shift=12: shift=24, sllp=0x, avpnm=0x, 
tlbiel=1, penc=56
  [0.00] base_shift=16: shift=16, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=1
  [0.00] base_shift=16: shift=24, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=8
  [0.00] base_shift=24: shift=24, sllp=0x0100, avpnm=0x0001, 
tlbiel=0, penc=0
  [0.00] 

Re: [Kernel-packages] [Bug 1567539] Re: Failure to dump with trusty+3.16 on ppc64el

[Nish Aravamudan]

On 12.04.2016 [19:53:57 -], Dave Chiluk wrote:
> I can confirm that the following settings for crashkernel on powernv result 
> in the following console log.
> crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M

If I read that correctly, it failed to kdump at all? Can you provide the
dmesg before you trigger the crash?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1567539

Title:
  Failure to dump with trusty+3.16 on ppc64el

Status in makedumpfile package in Ubuntu:
  Confirmed

Bug description:
  Test case
  # sudo apt-get install linux-crashdump

  set USE_KDUMP=1 in /etc/default/kdump-tools

  # sudo shutdown -r now

  echo 1 | sudo tee /proc/sys/kernel/sysrq
  echo c | sudo tee /proc/sysrq-trigger

  It looks like there was insufficient memory devoted to the crash
  kernel.  The defaults were used, and the kernel had 256G of ram, and
  only 2.6G were in use at the time of inducing the crash.

  Console log 

  [  290.509423] SysRq : Trigger a crash
  [  290.509526] Unable to handle kernel paging request for data at address 
0x
  [  290.509606] Faulting instruction address: 0xc05d9c94
  [  290.509672] Oops: Kernel access of bad area, sig: 11 [#1]
  [  290.509723] SMP NR_CPUS=2048 NUMA PowerNV
  [  290.509776] Modules linked in: ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad 
ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt 
rtc_generic i2c_opal powernv_rng uio_pdrv_genirq ipmi_powernv ipmi_msghandler 
uio mlx4_en vxlan ses enclosure mlx4_core ipr
  [  290.510178] CPU: 121 PID: 2976 Comm: tee Not tainted 3.16.0-69-generic 
#89~14.04.1-Ubuntu
  [  290.510254] task: c01fdccf4a80 ti: c01fdcd58000 task.ti: 
c01fdcd58000
  [  290.510330] NIP: c05d9c94 LR: c05dad0c CTR: 
c05d9c60
  [  290.510406] REGS: c01fdcd5b9d0 TRAP: 0300   Not tainted  
(3.16.0-69-generic)
  [  290.510480] MSR: 90009033   CR: 28004024  
XER: 2000
  [  290.510671] CFAR: c0009368 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05dad0c c01fdcd5bc50 c13d7d00 0063
  GPR04: c6548540 c6558da8 00016fa0 c1596218
  GPR08: c0e37d00  0001 00016fa0
  GPR12: c05d9c60 c7bc4100  
  GPR16:    
  GPR20:   100094d8 100094c0
  GPR24: 0001 100094d8 0004 
  GPR28: c130f6c0 0063 c12ed7a0 c130fa80
  [  290.511676] NIP [c05d9c94] sysrq_handle_crash+0x34/0x50
  [  290.511742] LR [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511793] Call Trace:
  [  290.511820] [c01fdcd5bc50] [c01fdcd5bcb0] 0xc01fdcd5bcb0 
(unreliable)
  [  290.511911] [c01fdcd5bc70] [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511988] [c01fdcd5bd10] [c05db4dc] 
write_sysrq_trigger+0x7c/0xa0
  [  290.512078] [c01fdcd5bd40] [c032e1d0] proc_reg_write+0xb0/0x110
  [  290.512155] [c01fdcd5bd90] [c02a47ec] vfs_write+0xdc/0x260
  [  290.512231] [c01fdcd5bde0] [c02a558c] SyS_write+0x6c/0x110
  [  290.512308] [c01fdcd5be30] [c000a1d8] system_call+0x38/0xd0
  [  290.512383] Instruction dump:
  [  290.512421] 3842e0a0 7c0802a6 f8010010 f821ffe1 6000 6000 3d42001b 
392a006c
  [  290.512546] 3941 9149 7c0004ac 3920 <9949> 38210020 
e8010010 7c0803a6
  [  290.512674] ---[ end trace ba4afa55b8a163cd ]---
  [  290.512735]
  [  290.513754] Sending IPI to other CPUs
  [  290.514897] IPI complete
  [0.00] OPAL V3 detected !
  [0.00] Using PowerNV machine description
  [0.00] Page sizes from device-tree:
  [0.00] base_shift=12: shift=12, sllp=0x, avpnm=0x, 
tlbiel=1, penc=0
  [0.00] base_shift=12: shift=16, sllp=0x, avpnm=0x, 
tlbiel=1, penc=7
  [0.00] base_shift=12: shift=24, sllp=0x, avpnm=0x, 
tlbiel=1, penc=56
  [0.00] base_shift=16: shift=16, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=1
  [0.00] base_shift=16: shift=24, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=8
  [0.00] base_shift=24: shift=24, sllp=0x0100, avpnm=0x0001, 
tlbiel=0, penc=0
  [0.00] base_shift=34: shift=34, sllp=0x0120, avpnm=0x07ff, 
tlbiel=0, penc=3
  [0.00] Using 1TB segments
  [0.00] kvm_cma: CMA: failed to reserve 128 MiB
  [0.00] Found initrd at 0xc973:0xcafd9bd6
  [0.00] bootconsole [udbg0] enabled
  [0.00] CPU maps initialized for 8 threads per core
   -> 

Re: [Kernel-packages] [Bug 1567539] Re: Failure to dump with trusty+3.16 on ppc64el

[Nish Aravamudan]

On 12.04.2016 [18:51:36 -], Dave Chiluk wrote:
> I received another update from the end user.  
> "A fresh 14.04.4 DVD Ubuntu install with updates (3.16.0-69 kernel) in a 
> diskful setup (no NFS, no aufs, 1T swap disk) also fails to kdump, either 
> hangs or OOMS."  
> 
> My understanding is that it OOMS on too little crashkernel assignment,
> hangs if enough crashkernel is provided.

Is the end user willing to test if relocation is sufficient to fix the
problem (appending @32M or so, iirc, so crashkernel=@32M).

What was "enough" for their environment?

Does providing the suggested value earlier
(crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M)
succeed?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1567539

Title:
  Failure to dump with trusty+3.16 on ppc64el

Status in makedumpfile package in Ubuntu:
  Confirmed

Bug description:
  Test case
  # sudo apt-get install linux-crashdump

  set USE_KDUMP=1 in /etc/default/kdump-tools

  # sudo shutdown -r now

  echo 1 | sudo tee /proc/sys/kernel/sysrq
  echo c | sudo tee /proc/sysrq-trigger

  It looks like there was insufficient memory devoted to the crash
  kernel.  The defaults were used, and the kernel had 256G of ram, and
  only 2.6G were in use at the time of inducing the crash.

  Console log 

  [  290.509423] SysRq : Trigger a crash
  [  290.509526] Unable to handle kernel paging request for data at address 
0x
  [  290.509606] Faulting instruction address: 0xc05d9c94
  [  290.509672] Oops: Kernel access of bad area, sig: 11 [#1]
  [  290.509723] SMP NR_CPUS=2048 NUMA PowerNV
  [  290.509776] Modules linked in: ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad 
ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt 
rtc_generic i2c_opal powernv_rng uio_pdrv_genirq ipmi_powernv ipmi_msghandler 
uio mlx4_en vxlan ses enclosure mlx4_core ipr
  [  290.510178] CPU: 121 PID: 2976 Comm: tee Not tainted 3.16.0-69-generic 
#89~14.04.1-Ubuntu
  [  290.510254] task: c01fdccf4a80 ti: c01fdcd58000 task.ti: 
c01fdcd58000
  [  290.510330] NIP: c05d9c94 LR: c05dad0c CTR: 
c05d9c60
  [  290.510406] REGS: c01fdcd5b9d0 TRAP: 0300   Not tainted  
(3.16.0-69-generic)
  [  290.510480] MSR: 90009033   CR: 28004024  
XER: 2000
  [  290.510671] CFAR: c0009368 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05dad0c c01fdcd5bc50 c13d7d00 0063
  GPR04: c6548540 c6558da8 00016fa0 c1596218
  GPR08: c0e37d00  0001 00016fa0
  GPR12: c05d9c60 c7bc4100  
  GPR16:    
  GPR20:   100094d8 100094c0
  GPR24: 0001 100094d8 0004 
  GPR28: c130f6c0 0063 c12ed7a0 c130fa80
  [  290.511676] NIP [c05d9c94] sysrq_handle_crash+0x34/0x50
  [  290.511742] LR [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511793] Call Trace:
  [  290.511820] [c01fdcd5bc50] [c01fdcd5bcb0] 0xc01fdcd5bcb0 
(unreliable)
  [  290.511911] [c01fdcd5bc70] [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511988] [c01fdcd5bd10] [c05db4dc] 
write_sysrq_trigger+0x7c/0xa0
  [  290.512078] [c01fdcd5bd40] [c032e1d0] proc_reg_write+0xb0/0x110
  [  290.512155] [c01fdcd5bd90] [c02a47ec] vfs_write+0xdc/0x260
  [  290.512231] [c01fdcd5bde0] [c02a558c] SyS_write+0x6c/0x110
  [  290.512308] [c01fdcd5be30] [c000a1d8] system_call+0x38/0xd0
  [  290.512383] Instruction dump:
  [  290.512421] 3842e0a0 7c0802a6 f8010010 f821ffe1 6000 6000 3d42001b 
392a006c
  [  290.512546] 3941 9149 7c0004ac 3920 <9949> 38210020 
e8010010 7c0803a6
  [  290.512674] ---[ end trace ba4afa55b8a163cd ]---
  [  290.512735]
  [  290.513754] Sending IPI to other CPUs
  [  290.514897] IPI complete
  [0.00] OPAL V3 detected !
  [0.00] Using PowerNV machine description
  [0.00] Page sizes from device-tree:
  [0.00] base_shift=12: shift=12, sllp=0x, avpnm=0x, 
tlbiel=1, penc=0
  [0.00] base_shift=12: shift=16, sllp=0x, avpnm=0x, 
tlbiel=1, penc=7
  [0.00] base_shift=12: shift=24, sllp=0x, avpnm=0x, 
tlbiel=1, penc=56
  [0.00] base_shift=16: shift=16, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=1
  [0.00] base_shift=16: shift=24, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=8
  [0.00] base_shift=24: shift=24, sllp=0x0100, avpnm=0x0001, 
tlbiel=0, penc=0
  [0.00] 

Re: [Kernel-packages] [Bug 1567539] Re: Failure to dump with trusty+3.16 on ppc64el

[Nish Aravamudan]

On 08.04.2016 [11:04:47 -], Louis Bouchard wrote:
> Hello,
> 
> Regarding nr_cpus=1, the equivalent maxcpus=1 is set in the kexec
> command (at least on default installs) :

Yep, you're right, sorry!

> Maybe disabling SMP alltogether by setting maxcpus=0 could be considered
> but that shouldn't change much aside from not reserving any SMP data
> structure. To Be Tested.

Agreed, shouldn't be necessary for this bug.

> Regarding kvm_cma_resv_ratio=0, this will  avoid the error message but
> it has on bearing on the current situation. It failed to allocated it so
> the memory was not in use.

Right, for correctness, though.

> 256Gb of RAM doesn't mean that 128Mb needs to be increased. Here is the
> output of free on a 128Gb system right after a kernel panic :

On Power, yes it does. Were you on a Power system for the below?

Here are the "official" Ubuntu recommendations
(https://wiki.ubuntu.com/ppc64el/Recommendations):

crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-
128G:2048M,128G-:4096M

This is based upon actual testing on Power by IBM, iirc. Power's memory
consumption pattern is very different than x86.

Based upon your meminfo output, you were on x86, which is not relevant
to this issue.

Note the above is architecture-specific -- is it possible to modify
kexec-tools to suppor a per-arch crashkernel= default?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1567539

Title:
  Failure to dump with trusty+3.16 on ppc64el

Status in makedumpfile package in Ubuntu:
  New

Bug description:
  Test case
  # sudo apt-get install linux-crashdump

  set USE_KDUMP=1 in /etc/default/kdump-tools

  # sudo shutdown -r now

  echo 1 | sudo tee /proc/sys/kernel/sysrq
  echo c | sudo tee /proc/sysrq-trigger

  It looks like there was insufficient memory devoted to the crash
  kernel.  The defaults were used, and the kernel had 256G of ram, and
  only 2.6G were in use at the time of inducing the crash.

  Console log 

  [  290.509423] SysRq : Trigger a crash
  [  290.509526] Unable to handle kernel paging request for data at address 
0x
  [  290.509606] Faulting instruction address: 0xc05d9c94
  [  290.509672] Oops: Kernel access of bad area, sig: 11 [#1]
  [  290.509723] SMP NR_CPUS=2048 NUMA PowerNV
  [  290.509776] Modules linked in: ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad 
ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt 
rtc_generic i2c_opal powernv_rng uio_pdrv_genirq ipmi_powernv ipmi_msghandler 
uio mlx4_en vxlan ses enclosure mlx4_core ipr
  [  290.510178] CPU: 121 PID: 2976 Comm: tee Not tainted 3.16.0-69-generic 
#89~14.04.1-Ubuntu
  [  290.510254] task: c01fdccf4a80 ti: c01fdcd58000 task.ti: 
c01fdcd58000
  [  290.510330] NIP: c05d9c94 LR: c05dad0c CTR: 
c05d9c60
  [  290.510406] REGS: c01fdcd5b9d0 TRAP: 0300   Not tainted  
(3.16.0-69-generic)
  [  290.510480] MSR: 90009033   CR: 28004024  
XER: 2000
  [  290.510671] CFAR: c0009368 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05dad0c c01fdcd5bc50 c13d7d00 0063
  GPR04: c6548540 c6558da8 00016fa0 c1596218
  GPR08: c0e37d00  0001 00016fa0
  GPR12: c05d9c60 c7bc4100  
  GPR16:    
  GPR20:   100094d8 100094c0
  GPR24: 0001 100094d8 0004 
  GPR28: c130f6c0 0063 c12ed7a0 c130fa80
  [  290.511676] NIP [c05d9c94] sysrq_handle_crash+0x34/0x50
  [  290.511742] LR [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511793] Call Trace:
  [  290.511820] [c01fdcd5bc50] [c01fdcd5bcb0] 0xc01fdcd5bcb0 
(unreliable)
  [  290.511911] [c01fdcd5bc70] [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511988] [c01fdcd5bd10] [c05db4dc] 
write_sysrq_trigger+0x7c/0xa0
  [  290.512078] [c01fdcd5bd40] [c032e1d0] proc_reg_write+0xb0/0x110
  [  290.512155] [c01fdcd5bd90] [c02a47ec] vfs_write+0xdc/0x260
  [  290.512231] [c01fdcd5bde0] [c02a558c] SyS_write+0x6c/0x110
  [  290.512308] [c01fdcd5be30] [c000a1d8] system_call+0x38/0xd0
  [  290.512383] Instruction dump:
  [  290.512421] 3842e0a0 7c0802a6 f8010010 f821ffe1 6000 6000 3d42001b 
392a006c
  [  290.512546] 3941 9149 7c0004ac 3920 <9949> 38210020 
e8010010 7c0803a6
  [  290.512674] ---[ end trace ba4afa55b8a163cd ]---
  [  290.512735]
  [  290.513754] Sending IPI to other CPUs
  [  290.514897] IPI complete
  [0.00] OPAL V3 detected !
  [0.00] 

Re: [Kernel-packages] [Bug 1567539] Re: Failure to dump with trusty+3.16 on ppc64el

[Nish Aravamudan]

On 07.04.2016 [17:18:58 -], Dave Chiluk wrote:
> According to 
> https://wiki.ubuntu.com/ppc64el/Recommendations#Crash_Kernel_recommendations
> 
> it looks like the following should be used.
> crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
> 
> These should be made as defaults for crash on ppc64 at the very least.

FYI, the default actually comes from src:kexec-tools:

cat debian/kexec-tools.grub 
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:128M"

which, in and of itself, seems odd as if you only install kexec-tools,
you've now reserved some system memory for kdump.

And if you remove/purge kexec-tools, crashkernel= seems to stick around
:)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1567539

Title:
  Failure to dump with trusty+3.16 on ppc64el

Status in makedumpfile package in Ubuntu:
  New

Bug description:
  Test case
  # sudo apt-get install linux-crashdump

  set USE_KDUMP=1 in /etc/default/kdump-tools

  # sudo shutdown -r now

  echo 1 | sudo tee /proc/sys/kernel/sysrq
  echo c | sudo tee /proc/sysrq-trigger

  It looks like there was insufficient memory devoted to the crash
  kernel.  The defaults were used, and the kernel had 256G of ram, and
  only 2.6G were in use at the time of inducing the crash.

  Console log 

  [  290.509423] SysRq : Trigger a crash
  [  290.509526] Unable to handle kernel paging request for data at address 
0x
  [  290.509606] Faulting instruction address: 0xc05d9c94
  [  290.509672] Oops: Kernel access of bad area, sig: 11 [#1]
  [  290.509723] SMP NR_CPUS=2048 NUMA PowerNV
  [  290.509776] Modules linked in: ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad 
ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt 
rtc_generic i2c_opal powernv_rng uio_pdrv_genirq ipmi_powernv ipmi_msghandler 
uio mlx4_en vxlan ses enclosure mlx4_core ipr
  [  290.510178] CPU: 121 PID: 2976 Comm: tee Not tainted 3.16.0-69-generic 
#89~14.04.1-Ubuntu
  [  290.510254] task: c01fdccf4a80 ti: c01fdcd58000 task.ti: 
c01fdcd58000
  [  290.510330] NIP: c05d9c94 LR: c05dad0c CTR: 
c05d9c60
  [  290.510406] REGS: c01fdcd5b9d0 TRAP: 0300   Not tainted  
(3.16.0-69-generic)
  [  290.510480] MSR: 90009033   CR: 28004024  
XER: 2000
  [  290.510671] CFAR: c0009368 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05dad0c c01fdcd5bc50 c13d7d00 0063
  GPR04: c6548540 c6558da8 00016fa0 c1596218
  GPR08: c0e37d00  0001 00016fa0
  GPR12: c05d9c60 c7bc4100  
  GPR16:    
  GPR20:   100094d8 100094c0
  GPR24: 0001 100094d8 0004 
  GPR28: c130f6c0 0063 c12ed7a0 c130fa80
  [  290.511676] NIP [c05d9c94] sysrq_handle_crash+0x34/0x50
  [  290.511742] LR [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511793] Call Trace:
  [  290.511820] [c01fdcd5bc50] [c01fdcd5bcb0] 0xc01fdcd5bcb0 
(unreliable)
  [  290.511911] [c01fdcd5bc70] [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511988] [c01fdcd5bd10] [c05db4dc] 
write_sysrq_trigger+0x7c/0xa0
  [  290.512078] [c01fdcd5bd40] [c032e1d0] proc_reg_write+0xb0/0x110
  [  290.512155] [c01fdcd5bd90] [c02a47ec] vfs_write+0xdc/0x260
  [  290.512231] [c01fdcd5bde0] [c02a558c] SyS_write+0x6c/0x110
  [  290.512308] [c01fdcd5be30] [c000a1d8] system_call+0x38/0xd0
  [  290.512383] Instruction dump:
  [  290.512421] 3842e0a0 7c0802a6 f8010010 f821ffe1 6000 6000 3d42001b 
392a006c
  [  290.512546] 3941 9149 7c0004ac 3920 <9949> 38210020 
e8010010 7c0803a6
  [  290.512674] ---[ end trace ba4afa55b8a163cd ]---
  [  290.512735]
  [  290.513754] Sending IPI to other CPUs
  [  290.514897] IPI complete
  [0.00] OPAL V3 detected !
  [0.00] Using PowerNV machine description
  [0.00] Page sizes from device-tree:
  [0.00] base_shift=12: shift=12, sllp=0x, avpnm=0x, 
tlbiel=1, penc=0
  [0.00] base_shift=12: shift=16, sllp=0x, avpnm=0x, 
tlbiel=1, penc=7
  [0.00] base_shift=12: shift=24, sllp=0x, avpnm=0x, 
tlbiel=1, penc=56
  [0.00] base_shift=16: shift=16, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=1
  [0.00] base_shift=16: shift=24, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=8
  [0.00] base_shift=24: shift=24, sllp=0x0100, avpnm=0x0001, 
tlbiel=0, penc=0
  [

[Kernel-packages] [Bug 1567539] Re: Failure to dump with trusty+3.16 on ppc64el

[Nish Aravamudan]

Couple of thoughts, which we probably should get IBM's advice on:

I believe this is using: crashkernel=384M-:128M

128M reserved seems too small for so much memory, tbh.

Also, I see that all the CPUs are on in the crashkernel, when
realistically only 1 CPU is needed (and there have been issues in the
past with SMP in the kdump kernel, iirc).

Finally, 'kvm_cma: CMA: failed to reserve 128 MiB' probably indicates we
should pass kvm_cma_resv_ratio=0 to the kdump kernel (we're never going
to run guests in the kdump environment).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1567539

Title:
  Failure to dump with trusty+3.16 on ppc64el

Status in makedumpfile package in Ubuntu:
  New

Bug description:
  Test case
  # sudo apt-get install linux-crashdump

  set USE_KDUMP=1 in /etc/default/kdump-tools

  # sudo shutdown -r now

  echo 1 | sudo tee /proc/sys/kernel/sysrq
  echo c | sudo tee /proc/sysrq-trigger

  It looks like there was insufficient memory devoted to the crash
  kernel.  The defaults were used, and the kernel had 256G of ram, and
  only 2.6G were in use at the time of inducing the crash.

  Console log 

  [  290.509423] SysRq : Trigger a crash
  [  290.509526] Unable to handle kernel paging request for data at address 
0x
  [  290.509606] Faulting instruction address: 0xc05d9c94
  [  290.509672] Oops: Kernel access of bad area, sig: 11 [#1]
  [  290.509723] SMP NR_CPUS=2048 NUMA PowerNV
  [  290.509776] Modules linked in: ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad 
ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt 
rtc_generic i2c_opal powernv_rng uio_pdrv_genirq ipmi_powernv ipmi_msghandler 
uio mlx4_en vxlan ses enclosure mlx4_core ipr
  [  290.510178] CPU: 121 PID: 2976 Comm: tee Not tainted 3.16.0-69-generic 
#89~14.04.1-Ubuntu
  [  290.510254] task: c01fdccf4a80 ti: c01fdcd58000 task.ti: 
c01fdcd58000
  [  290.510330] NIP: c05d9c94 LR: c05dad0c CTR: 
c05d9c60
  [  290.510406] REGS: c01fdcd5b9d0 TRAP: 0300   Not tainted  
(3.16.0-69-generic)
  [  290.510480] MSR: 90009033   CR: 28004024  
XER: 2000
  [  290.510671] CFAR: c0009368 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05dad0c c01fdcd5bc50 c13d7d00 0063
  GPR04: c6548540 c6558da8 00016fa0 c1596218
  GPR08: c0e37d00  0001 00016fa0
  GPR12: c05d9c60 c7bc4100  
  GPR16:    
  GPR20:   100094d8 100094c0
  GPR24: 0001 100094d8 0004 
  GPR28: c130f6c0 0063 c12ed7a0 c130fa80
  [  290.511676] NIP [c05d9c94] sysrq_handle_crash+0x34/0x50
  [  290.511742] LR [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511793] Call Trace:
  [  290.511820] [c01fdcd5bc50] [c01fdcd5bcb0] 0xc01fdcd5bcb0 
(unreliable)
  [  290.511911] [c01fdcd5bc70] [c05dad0c] __handle_sysrq+0xec/0x280
  [  290.511988] [c01fdcd5bd10] [c05db4dc] 
write_sysrq_trigger+0x7c/0xa0
  [  290.512078] [c01fdcd5bd40] [c032e1d0] proc_reg_write+0xb0/0x110
  [  290.512155] [c01fdcd5bd90] [c02a47ec] vfs_write+0xdc/0x260
  [  290.512231] [c01fdcd5bde0] [c02a558c] SyS_write+0x6c/0x110
  [  290.512308] [c01fdcd5be30] [c000a1d8] system_call+0x38/0xd0
  [  290.512383] Instruction dump:
  [  290.512421] 3842e0a0 7c0802a6 f8010010 f821ffe1 6000 6000 3d42001b 
392a006c
  [  290.512546] 3941 9149 7c0004ac 3920 <9949> 38210020 
e8010010 7c0803a6
  [  290.512674] ---[ end trace ba4afa55b8a163cd ]---
  [  290.512735]
  [  290.513754] Sending IPI to other CPUs
  [  290.514897] IPI complete
  [0.00] OPAL V3 detected !
  [0.00] Using PowerNV machine description
  [0.00] Page sizes from device-tree:
  [0.00] base_shift=12: shift=12, sllp=0x, avpnm=0x, 
tlbiel=1, penc=0
  [0.00] base_shift=12: shift=16, sllp=0x, avpnm=0x, 
tlbiel=1, penc=7
  [0.00] base_shift=12: shift=24, sllp=0x, avpnm=0x, 
tlbiel=1, penc=56
  [0.00] base_shift=16: shift=16, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=1
  [0.00] base_shift=16: shift=24, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=8
  [0.00] base_shift=24: shift=24, sllp=0x0100, avpnm=0x0001, 
tlbiel=0, penc=0
  [0.00] base_shift=34: shift=34, sllp=0x0120, avpnm=0x07ff, 
tlbiel=0, penc=3
  [0.00] Using 1TB segments
  [0.00] kvm_cma: CMA: failed to reserve 128 MiB
  [

[Kernel-packages] [Bug 1392176] Re: mounts cgroups unconditionally which causes undesired effects with cpu hotplug

[Nish Aravamudan]

Breno,

Was your test done with a cgmanager with the -M flag passed?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1392176

Title:
  mounts cgroups unconditionally which causes undesired effects with cpu
  hotplug

Status in cgmanager package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - Preeti U. Murthy preeti.mur...@in.ibm.com - 2014-10-20 
04:40:12 ==
  ---Problem Description---
  Systemd mounts cgroups explicitly every boot. Since the user had no say in 
it, undesired consequences are observed in reaction to cpu hotplug operations.  
Here is how.

  Systemd moves the tasks to the cgroup mounted by it. This cgroup 
automatically becomes the child of the root cgroup which is present by default. 
The children cgroups are not expected to remember their configured cpusets 
after hotplug operations in the kernel. Hence when cpus are taken offline and 
brought back online they are no longer used for load balancing of tasks and 
hence remain unused. 
 This is an undesired consequence because the user had not even asked for 
cgroups to be mounted, yet is not able to use the full capacity of the system.

  Only when the user himself creates cgroup hierarchies, should he be
  exposed to the side effects of cpu hotplug on cpusets. Else all online
  cpus must be made available to him which is not happening since
  systemd mounts cgroups on every boot.

  Hence please revert this feature or provide an explaination as to why this is 
being done.
   
  ---uname output---
  Linux tul181p1 3.16.0-18-generic #25-Ubuntu SMP Fri Sep 26 02:39:53 UTC 2014 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = Tuleta 8286-42A 
   ---Debugger---
  A debugger was configured, however the system did not enter into the debugger
   
  ---Steps to Reproduce---
   $ taskset -p $$
  $ 0-127
  $ echo 0  /sys/devices/system/cpu/cpu7/online
  $ taskset -p $$
  $ 0-6,8-127
  $ echo 1  /sys/devices/system/cpu/cpu7/online
  $ taskset -p $$
  $ 0-6,8-127
   
   
  Userspace tool common name: systemd 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: systemd_208-8ubuntu8_ppc64el.deb

  Userspace tool obtained from project website:   208-8ubuntu8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1392176/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Re: mounts cgroups unconditionally which causes undesired effects with cpu hotplug

[Nish Aravamudan]

Serge,

That should only be true for unified hierarchy. In legacy hierarchy,
effective_cpus follows cpus, I think?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1392176

Title:
  mounts cgroups unconditionally which causes undesired effects with cpu
  hotplug

Status in cgmanager package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - Preeti U. Murthy preeti.mur...@in.ibm.com - 2014-10-20 
04:40:12 ==
  ---Problem Description---
  Systemd mounts cgroups explicitly every boot. Since the user had no say in 
it, undesired consequences are observed in reaction to cpu hotplug operations.  
Here is how.

  Systemd moves the tasks to the cgroup mounted by it. This cgroup 
automatically becomes the child of the root cgroup which is present by default. 
The children cgroups are not expected to remember their configured cpusets 
after hotplug operations in the kernel. Hence when cpus are taken offline and 
brought back online they are no longer used for load balancing of tasks and 
hence remain unused. 
 This is an undesired consequence because the user had not even asked for 
cgroups to be mounted, yet is not able to use the full capacity of the system.

  Only when the user himself creates cgroup hierarchies, should he be
  exposed to the side effects of cpu hotplug on cpusets. Else all online
  cpus must be made available to him which is not happening since
  systemd mounts cgroups on every boot.

  Hence please revert this feature or provide an explaination as to why this is 
being done.
   
  ---uname output---
  Linux tul181p1 3.16.0-18-generic #25-Ubuntu SMP Fri Sep 26 02:39:53 UTC 2014 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = Tuleta 8286-42A 
   ---Debugger---
  A debugger was configured, however the system did not enter into the debugger
   
  ---Steps to Reproduce---
   $ taskset -p $$
  $ 0-127
  $ echo 0  /sys/devices/system/cpu/cpu7/online
  $ taskset -p $$
  $ 0-6,8-127
  $ echo 1  /sys/devices/system/cpu/cpu7/online
  $ taskset -p $$
  $ 0-6,8-127
   
   
  Userspace tool common name: systemd 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: systemd_208-8ubuntu8_ppc64el.deb

  Userspace tool obtained from project website:   208-8ubuntu8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1392176/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1332063] Re: Support memoryless nodes in Ubuntu kernel

[Nish Aravamudan]

I verified that the performance is the equivalent of upstream with
3.13.0-32-generic. There is still work to be done upstream but this gets
us quite a bit further.

** Tags removed: verification-needed-trusty
** Tags added: verification-done-trusty

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1332063

Title:
  Support memoryless nodes in Ubuntu kernel

Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux” source package in Trusty:
  Fix Committed
Status in “linux” source package in Utopic:
  Fix Released

Bug description:
  Several patches have gone upstream recently that improve powerpc's
  handling of memoryless nodes. These can be present in guests, but more
  importantly can be seen in Power8 host/PowerNV systems due to the
  manufacturing population of DIMMs.

  Upstream commits:

  81c98869faa5f3a9457c93efef908ef476326b31 (kthread: ensure locality of
  task_struct allocations)

  844e4d66f4ec3b6b6d3bcfcfba3ade2b962771e2 (slub: search partial list on
  numa_mem_id(), instead of numa_node_id())

  8c272261194dfda11cc046fbe808e052f6f284eb (powerpc/numa: Enable
  USE_PERCPU_NUMA_NODE_ID)

  64bb80d87f01ec01c76863b61b457e0904387f2f (powerpc/numa: Enable
  CONFIG_HAVE_MEMORYLESS_NODES)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1332063/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1332063] Re: Support memoryless nodes in Ubuntu kernel

[Nish Aravamudan]

I verified that the performance is the equivalent of upstream with
3.13.0-32-generic. There is still work to be done upstream but this gets
us quite a bit further.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1332063

Title:
  Support memoryless nodes in Ubuntu kernel

Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux” source package in Trusty:
  Fix Committed
Status in “linux” source package in Utopic:
  Fix Released

Bug description:
  Several patches have gone upstream recently that improve powerpc's
  handling of memoryless nodes. These can be present in guests, but more
  importantly can be seen in Power8 host/PowerNV systems due to the
  manufacturing population of DIMMs.

  Upstream commits:

  81c98869faa5f3a9457c93efef908ef476326b31 (kthread: ensure locality of
  task_struct allocations)

  844e4d66f4ec3b6b6d3bcfcfba3ade2b962771e2 (slub: search partial list on
  numa_mem_id(), instead of numa_node_id())

  8c272261194dfda11cc046fbe808e052f6f284eb (powerpc/numa: Enable
  USE_PERCPU_NUMA_NODE_ID)

  64bb80d87f01ec01c76863b61b457e0904387f2f (powerpc/numa: Enable
  CONFIG_HAVE_MEMORYLESS_NODES)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1332063/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1328251] Re: libhugetlbfs tests fail on powerpc/ppc64el

[Nish Aravamudan]

Hi Tim,

Note that the referenced commit only makes it so that if you don't back
a PowerKVM guest with hugepages, hugepages do not (falsely) appear to be
supported. In such an environment the message referenced in this bug
report will still be displayed as it should -- hugepages aren't
supported in such a guest.

To run the libhugetlbfs test suite in a PowerKVM guest, you must back
the guest with hugepages in the host and then allocate hugepages in the
guest as appropriate.

Thanks,
Nish

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1328251

Title:
  libhugetlbfs tests fail on powerpc/ppc64el

Status in “linux” package in Ubuntu:
  Fix Released
Status in “linux” source package in Trusty:
  In Progress
Status in “linux” source package in Utopic:
  Fix Released

Bug description:
  The test provided for libhugetlbfs along with ubuntu_beta release
  fail.

  Steps to recreate:
  

  1. apt-get install libhugetlb
  2. cd /usr/lib/libhugetlbs
  3. ./run_tests.py

  ./run_tests.py
  Unable to find available page sizes, are you sure hugetlbfs
  is mounted and there are available huge pages?

  We see the above message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328251/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp