[Kernel-packages] [Bug 1607325] Re: Ubuntu 16.04 running on z13 hardware is unable to configure blue ridge

[Joseph Salisbury]

** Tags added: kernel-da-key

** Tags added: performing-bisect

** Changed in: linux (Ubuntu)
   Status: New => In Progress

** Changed in: linux (Ubuntu)
   Importance: Undecided => High

** Changed in: linux (Ubuntu)
 Assignee: Skipper Bug Screeners (skipper-screen-team) => Joseph Salisbury 
(jsalisbury)

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

Title:
  Ubuntu 16.04 running on z13 hardware is unable to configure blue ridge

Status in linux package in Ubuntu:
  In Progress

Bug description:
  Problem Description
  ===
  system Z Ubuntu 16.04 LTS can not correctly configured DS8870 2107 LUNs.
   
  ---uname output---
  Linux ilabg3 4.4.0-33-generic #52-Ubuntu SMP Fri Jul 22 19:17:00 UTC 2016 
s390x s390x s390x GNU/Linux
   
  ---Additional Hardware Info---
  Z13 system using 16G FCP adapters to attach to FC fabric and IBM Blue ridge

   Machine Type = Z13 S390

  Steps to Reproduce
  
  The initial kernel is 4.4.0-24-generic and all blue ridge devices can be 
configured normally.
  After we upgrade kernel to 4.4.0-33 and reload BR code all BR devices can not 
be detect.

  System log show:
  [ 2645.893763] scsi 0:0:7:0: RAID  IBM  2810XIV-LUN-0 
PQ: 0 ANSI: 5
  [ 2645.895269] sysfs: cannot create duplicate filename 
'/bus/scsi/devices/0:0:7:0'
  [ 2645.895310] [ cut here ]
  [ 2645.895311] WARNING: at /build/linux-o03cxz/linux-4.4.0/fs/sysfs/dir.c:31
  [ 2645.895312] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd 
grace fscache qeth_l3 qeth ccwgroup vmur ib_iser rdma_cm iw_cm ib_cm ib_sa 
ib_mad ib_core sunrpc ib_addr iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi btrfs zlib_deflate raid10 raid456 async_memcpy 
async_raid6_recov async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 
raid0 linear dm_round_robin ghash_s390 prng aes_s390 des_s390 des_generic 
sha512_s390 sha256_s390 sha1_s390 sha_common zfcp dasd_eckd_mod qdio 
scsi_transport_fc dasd_fba_mod dasd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua 
dm_multipath
  [ 2645.895338] CPU: 1 PID: 4008 Comm: sh Tainted: GW   
4.4.0-33-generic #52-Ubuntu
  [ 2645.895339] task: dfe436b0 ti: 7b97c000 task.ti: 
7b97c000
  [ 2645.895340] Krnl PSW : 0704d0018000 003a361c 
(sysfs_warn_dup+0x7c/0x98)
  [ 2645.895350]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 
EA:3
 Krnl GPRS: 00cf7039 00cd9f3c 0043 
ef4d18a0
  [ 2645.895351]003a3618  7a49a000 
707b9178
  [ 2645.895352]00c1d0e0 ee71a780 0001 
ee71a780
  [ 2645.895353]e9554b60 7ebdf000 003a3618 
7b97f9b8
  [ 2645.895361] Krnl Code: 003a360c: c020002f33e7  larl
%r2,989dda
003a3612: c0e5fff6befb  brasl   
%r14,27b408
   #003a3618: a7f40001  brc 
15,3a361a
   >003a361c: b904002d  lgr %r2,%r13
003a3620: ebbff0a4  lmg 
%r11,%r15,160(%r15)
003a3626: c0f4fffa5995  brcl
15,2ee950
003a362c: a739  lghi%r3,0
003a3630: a7f4ffec  brc 
15,3a3608
  [ 2645.895370] Call Trace:
  [ 2645.895372] ([<003a3618>] sysfs_warn_dup+0x78/0x98)
  [ 2645.895374]  [<003a3b30>] sysfs_do_create_link_sd.isra.0+0xf8/0x108
  [ 2645.895378]  [<005c4044>] bus_add_device+0x13c/0x230
  [ 2645.895379]  [<005c1758>] device_add+0x398/0x680
  [ 2645.895385]  [<005f7a34>] scsi_sysfs_add_sdev+0xcc/0x2a8
  [ 2645.895386]  [<005f4210>] scsi_probe_and_add_lun+0xcc0/0xe18
  [ 2645.895387]  [<005f4c5a>] __scsi_scan_target+0xba/0x268
  [ 2645.895389]  [<005f4f0a>] scsi_scan_target+0x102/0x120
  [ 2645.895401]  [<03ff801095f6>] zfcp_unit_scsi_scan+0x7e/0x90 [zfcp]
  [ 2645.895404]  [<03ff80109948>] zfcp_unit_add+0x168/0x1f0 [zfcp]
  [ 2645.895407]  [<03ff80108564>] zfcp_sysfs_unit_add_store+0x54/0x70 
[zfcp]
  [ 2645.895408]  [<003a1d9a>] kernfs_fop_write+0x13a/0x190
  [ 2645.895413]  [<0030fcac>] vfs_write+0x94/0x1a0
  [ 2645.895414]  [<003109be>] SyS_write+0x66/0xd8
  [ 2645.895417]  [<007b86c6>] system_call+0xd6/0x264
  [ 2645.895418]  [<03ffb10df6e8>] 0x3ffb10df6e8
  [ 2645.895419] Last Breaking-Event-Address:
  [ 2645.895420]  [<003a3618>] sysfs_warn_dup+0x78/0x98
  [ 2645.895421] ---[ end trace a9b757385c995a64 ]---
  [ 2645.895535] scsi 0:0:7:0: failed to add device: -17

  == Comment: #1 - XIANG ZHANG  -

[Kernel-packages] [Bug 1586418] Re: exercising ptys causes a kernel oops

[Colin Ian King]

I've exhaustively exercised this and cannot reproduce the issue with the
-proposed 4.4.0-34-generic #53 kernel. Marking it as verification-done

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

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

Title:
  exercising ptys causes a kernel oops

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  [SRU JUSTIFICATION][TRUSTY][WILY][XENIAL]

  Running stress-ng --pty 1 with a very low vmalloc memory available can
  trip an oops.  This can be generally only be reproduced when memory is
  under a high amount of pressure.  I was able to reproduce reliably by
  forcefully injecting vmalloc to return NULL when the stress-ng pty was
  running.

  [FIX]
  Upstream commit 5353ed8deedee9e5acb9f896e9032158f5d998de ("devpts: fix null 
pointer dereference on failed memory allocation"). This needs backporting to 
Yakkey, Xenial, Wily and Trusty because of changes in variable names.

  [TEST]
  Forcefully inject vmalloc to return NULL when running the pty stressor. 
Without the fix, an oops can be tripped, with the fix, no issues occur.

  --

  running: "stress-ng --pty 1" and this occurs in less than 1 second:

  [   67.753230] alloc_vmap_area: 9 callbacks suppressed
  [   67.753233] vmap allocation for size 16384 failed: use vmalloc= to 
increase size.
  [   67.753235] vmalloc: allocation failure: 8844 bytes
  [   67.753237] stress-ng-pty: page allocation failure: order:0, mode:0x24000c2
  [   67.753240] CPU: 2 PID: 2150 Comm: stress-ng-pty Not tainted 
4.4.0-23-generic #41-Ubuntu
  [   67.753241] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
  [   67.753243]  c1abf967 0832d3cc 0286 f2497c8c c139fe1f c19ce22c 
0001 f2497cbc
  [   67.753248]  c1177396 c19cc624 f506b5f0  024000c2 f2497cd0 
c19ce22c f2497ca4
  [   67.753252]  0832d3cc 228c  f2497cec c11ad2ff 024000c2 
 c19ce22c
  [   67.753256] Call Trace:
  [   67.753264]  [] dump_stack+0x58/0x79
  [   67.753267]  [] warn_alloc_failed+0xd6/0x110
  [   67.753272]  [] __vmalloc_node_range+0x1ef/0x210
  [   67.753276]  [] ? tty_get_pgrp+0x40/0x40
  [   67.753278]  [] __vmalloc_node+0x66/0x70
  [   67.753280]  [] ? n_tty_open+0x16/0xc0
  [   67.753283]  [] vmalloc+0x38/0x40
  [   67.753284]  [] ? n_tty_open+0x16/0xc0
  [   67.753290]  [] n_tty_open+0x16/0xc0
  [   67.753293]  [] tty_ldisc_open.isra.2+0x28/0x60
  [   67.753295]  [] tty_ldisc_setup+0x1c/0x70
  [   67.753297]  [] tty_init_dev+0x7c/0x180
  [   67.753301]  [] ? devpts_new_index+0xf1/0x120
  [   67.753303]  [] ptmx_open+0x75/0x160
  [   67.753306]  [] chrdev_open+0xa4/0x180
  [   67.753310]  [] do_dentry_open+0x1ec/0x300
  [   67.753312]  [] ? cdev_put+0x20/0x20
  [   67.753314]  [] vfs_open+0x4f/0x60
  [   67.753316]  [] path_openat+0x509/0x1140
  [   67.753318]  [] ? putname+0x54/0x60
  [   67.753321]  [] do_filp_open+0x68/0xe0
  [   67.753324]  [] ? __alloc_fd+0x36/0x150
  [   67.753326]  [] do_sys_open+0x128/0x2b0
  [   67.753329]  [] SyS_open+0x22/0x30
  [   67.753332]  [] do_fast_syscall_32+0x8d/0x150
  [   67.753336]  [] sysenter_past_esp+0x3d/0x61
  [   67.753338] Mem-Info:
  [   67.753342] active_anon:5790 inactive_anon:1203 isolated_anon:0
  active_file:30258 inactive_file:14843 isolated_file:0
  unevictable:856 dirty:46 writeback:0 unstable:0
  slab_reclaimable:4643 slab_unreclaimable:5952
  mapped:5271 shmem:1380 pagetables:193 bounce:0
  free:166082 free_pcp:1176 free_cma:0
  [   67.753349] DMA free:9616kB min:788kB low:984kB high:1180kB 
active_anon:288kB inactive_anon:112kB active_file:2436kB inactive_file:1216kB 
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB 
managed:15916kB mlocked:0kB dirty:4kB writeback:0kB mapped:396kB shmem:108kB 
slab_reclaimable:268kB slab_unreclaimable:428kB kernel_stack:24kB 
pagetables:8kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
  [   67.753350] lowmem_reserve[]: 0 818 949 949
  [   67.753357] Normal free:567248kB min:41608kB low:52008kB high:62412kB 
active_anon:18440kB inactive_anon:2992kB active_file:101312kB 
inactive_file:47608kB unevictable:3164kB isolated(anon):0kB isolated(file):0kB 
present:897016kB managed:872588kB mlocked:3164kB dirty:180kB writeback:0kB 
mapped:16216kB shmem:3620kB slab_reclaimable:18304kB slab_unreclaimable:23380kB 
kernel_stack:

[Kernel-packages] [Bug 1572712] Re: console hung during Ubuntu 16.04 netboot install 4.4.0-12-generic [soft lockup]

[Steve Langasek]

http://ports.ubuntu.com/ubuntu-ports/dists/xenial-updates/main
/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/
includes the 4.4.0-31 kernel build, as listed in
.

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

Title:
  console hung during Ubuntu 16.04 netboot install 4.4.0-12-generic
  [soft lockup]

Status in linux package in Ubuntu:
  New

Bug description:
  Canonical,

  FYI and reference only at this time.

  Details:
  ---Problem Description---
  IPMI Console gets hung for 15 to 30 mins, can not traverse when trying to 
install 
  latest copy of Ubuntu 16.04 on Habanero from 
http://ports.ubuntu.com/ubuntu-ports/dists/xenial/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux
  which is 4.4.0-12-generic 
   [   36.803240] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! 
[swapper/2:0]
   
  ---uname output---
  4.4.0-12-generic 
   
  ---Additional Hardware Info---
  TN71-BP012  

   
  Machine Type = TN71-BP012  
   
  ---System Hang---
   we have to wait for 15 to 30 mins to regain the console access.

   
  ---Steps to Reproduce---
  use IPMI console for  petitboot on habanero, configure IP to a network 
device, make sure you have internet outbound BSO authenticated. 
  on petit shell run following commands 
  cd /tmp;
  wget 
http://ports.ubuntu.com/ubuntu-ports/dists/xenial/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux
 ;
  wget 
http://ports.ubuntu.com/ubuntu-ports/dists/xenial/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/initrd.gz
 ;
  kexec -l /tmp/vmlinux  -i /tmp/initrd.gz  ;
  kexec -e ;

   
  Stack trace output:
   [   36.803240] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! 
[swapper/2:0]
  [   36.803425] Modules linked in: hid_generic(E) ast(E) i2c_algo_bit(E) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) ttm
  ) usb_storage(E)
  [   36.803436] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GE   
4.4.0-12-generic #28-Ubuntu
  [   36.803438] task: c03c8fe8e7b0 ti: c03c9753 task.ti: 
c03c9753
  [   36.803440] NIP: c0010a24 LR: c0010a24 CTR: 
c060c2f0
  [   36.803442] REGS: c03c97533510 TRAP: 0901   Tainted: GE
(4.4.0-12-generic)
  [   36.803443] MSR: 90019033   CR: 28002824  
XER: 
  [   36.803448] CFAR: c060c330 SOFTE: 1 
  [   36.803448] GPR00: c00db8b4 c03c97533790 c15a3b00 
0900 
  [   36.803448] GPR04: c03c8fef6e00 0001  
03ff 
  [   36.803448] GPR08:  c03ffb064605 0001 
0004 
  [   36.803448] GPR12: c060c2f0 cfb41300 
  [   36.803460] NIP [c0010a24] arch_local_irq_restore+0x74/0x90
  [   36.803462] LR [c0010a24] arch_local_irq_restore+0x74/0x90
  [   36.803463] Call Trace:
  [   36.803465] [c03c97533790] [c014b184] mod_timer+0x154/0x300 
(unreliable)
  [   36.803468] [c03c975337b0] [c00db8b4] queue_work_on+0x74/0xf0
  [   36.803471] [c03c975337f0] [c060c334] 
cursor_timer_handler+0x44/0x80
  [   36.803474] [c03c97533820] [c0149ebc] call_timer_fn+0x5c/0x1c0
  [   36.803476] [c03c975338b0] [c014a37c] 
run_timer_softirq+0x31c/0x3f0
  [   36.803480] [c03c97533980] [c00beaf8] __do_softirq+0x188/0x3e0
  [   36.803483] [c03c97533a70] [c00befc8] irq_exit+0xc8/0x100
  [   36.803487] [c03c97533a90] [c001f954] timer_interrupt+0xa4/0xe0
  [   36.803490] [c03c97533ac0] [c0002714] 
decrementer_common+0x114/0x180
  [   36.803494] --- interrupt: 901 at arch_local_irq_restore+0x74/0x90
  [   36.803494] LR = arch_local_irq_restore+0x74/0x90
  [   36.803497] [c03c97533db0] [c03ffc49d678] 0xc03ffc49d678 
(unreliable)
  [   36.803502] [c03c97533dd0] [c0900708] 
cpuidle_enter_state+0x1a8/0x410
  [   36.803504] [c03c97533e30] [c0119898] call_cpuidle+0x78/0xd0
  [   36.803506] [c03c97533e70] [c0119c6c] 
cpu_startup_entry+0x37c/0x490
  [   36.803509] [c03c97533f30] [c004565c] 
start_secondary+0x33c/0x360
  [   36.803511] [c03c97533f90] [c0008b6c] 
start_secondary_prolog+0x10/0x14
  [   36.803512] Instruction dump:
  [   36.803514] 994d02ca 2fa3 409e0024 e92d0020 61298000 7d210164 38210020 
e8010010 
  [   36.803517] 7c0803a6 4e800020 6042 4bff17ad <6000> 4be4 
6042 e92d0020 
  [   57.811232] INFO: rcu_sched self-detected stall on CPU
  [   57.811236]  2-...: (1 GPs behind) idle=913/2/0 softirq=1849/1979 fqs=5229 
  [   57.811238]   (t=5250 jiffies g=-114 c=-115 q=1)
  [   57.811242] Task dump f

[Kernel-packages] [Bug 1579984] Re: Dell dock MAC Address pass through doesn't work in Ubuntu

[Tim Gardner]

https://lists.ubuntu.com/archives/kernel-team/2016-July/079355.html

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

** Changed in: linux (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Phidias (phidias-chiang)

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

Title:
  Dell dock MAC Address pass through doesn't work in Ubuntu

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress

Bug description:
  Dell systems with Type-C ports support a feature called "MAC address" pass 
through.
  This feature allows systems to set a persistent system MAC address to be used 
with the TB15, WD15 and Type-C ethernet adapter.

  More information is available here:
  http://www.dell.com/support/article/us/en/19/SLN301147/en

  This function works by a system specific MAC address (referred to as
  an auxiliary mac address) being programmed in the factory.  When the
  driver for the type-c ethernet (in dock or dongle) is loaded the MAC
  address is supposed to be overridden with this value.

  To enable this in Linux a kernel patch is needed.
  This has been submitted http://patchwork.ozlabs.org/patch/631759/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579984/+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 1579984] Re: Dell dock MAC Address pass through doesn't work in Ubuntu

[Tim Gardner]

Merged for 4.8

** Changed in: linux (Ubuntu)
   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/1579984

Title:
  Dell dock MAC Address pass through doesn't work in Ubuntu

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress

Bug description:
  Dell systems with Type-C ports support a feature called "MAC address" pass 
through.
  This feature allows systems to set a persistent system MAC address to be used 
with the TB15, WD15 and Type-C ethernet adapter.

  More information is available here:
  http://www.dell.com/support/article/us/en/19/SLN301147/en

  This function works by a system specific MAC address (referred to as
  an auxiliary mac address) being programmed in the factory.  When the
  driver for the type-c ethernet (in dock or dongle) is loaded the MAC
  address is supposed to be overridden with this value.

  To enable this in Linux a kernel patch is needed.
  This has been submitted http://patchwork.ozlabs.org/patch/631759/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579984/+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 1603719] Re: [regression] NFS client: access problems after updating to kernel 4.4.0-31-generic

[Bryan Quigley]

Verified working with both -33 and -34 kernels

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

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

Title:
  [regression] NFS client: access problems after updating to kernel
  4.4.0-31-generic

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  SRU Justification

  Impact: A regression in xenial causes automatic mounting of exported
  submounts of an nfs mount to fail.

  Fix: Change nfs to use sget_userns instead of sget, bypassing a
  capability check that is not necessary for nfs.

  Regression Potential: The behavior after the fix is functionally
  equivalent to upstream, so this is unlikely to cause regressions.

  ---

  I am denied access to the subfilesystems exported by my nfs server
  (the top level filesystem itself is unaffected).

  The client is reporting that I do not have the necessary permissions.
  However, all was fine until the day before yesterday.

  When I revert my client to 4.4.0-28, everything is in working order again. I 
assume the permission problem is really a bug in kernel 4.4.0-31.
  ---
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  jurgen 1743 F pulseaudio
  CurrentDesktop: Unity
  DistroRelease: Ubuntu 16.04
  HibernationDevice: RESUME=UUID=569da237-3a37-4fe3-b885-83213aae8b52
  InstallationDate: Installed on 2016-04-07 (101 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Beta amd64 (20160405)
  IwConfig:
   lono wireless extensions.

   enp4s0no wireless extensions.
  MachineType: MICRO-STAR INTERNATIONAL CO.,LTD MS-7514
  NonfreeKernelModules: nvidia
  Package: linux (not installed)
  ProcFB:

  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-31-generic 
root=UUID=f6f6bd51-4d4f-4547-b615-90319625d909 ro quiet splash
  ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-31-generic N/A
   linux-backports-modules-4.4.0-31-generic  N/A
   linux-firmware1.157.2
  RfKill:

  Tags:  xenial
  Uname: Linux 4.4.0-31-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 05/28/2008
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V1.1
  dmi.board.asset.tag: To Be Filled By O.E.M.
  dmi.board.name: MS-7514
  dmi.board.vendor: MICRO-STAR INTERNATIONAL CO.,LTD
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: MICRO-STAR INTERNATIONAL CO.,LTD
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV1.1:bd05/28/2008:svnMICRO-STARINTERNATIONALCO.,LTD:pnMS-7514:pvr1.0:rvnMICRO-STARINTERNATIONALCO.,LTD:rnMS-7514:rvr1.0:cvnMICRO-STARINTERNATIONALCO.,LTD:ct3:cvr1.0:
  dmi.product.name: MS-7514
  dmi.product.version: 1.0
  dmi.sys.vendor: MICRO-STAR INTERNATIONAL CO.,LTD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1603719/+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 1573062] Re: memory_stress_ng failing for IBM Power S812LC(TN71-BP012) for 16.04

[Mike Rushton]

Output of 4.7 mainline kernel testing failure

** Attachment added: "4.7.0-040700-generic-201607241632.log from 4.7 testing 
failure"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1573062/+attachment/4708872/+files/4.7.0-040700-generic-201607241632.log

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

Title:
  memory_stress_ng failing for IBM Power S812LC(TN71-BP012) for 16.04

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:
  memory_stress_ng, as part of server certification is failing for IBM
  Power S812LC(TN71-BP012) in bare metal mode. Failing in this case is
  defined by the test locking up the server in an unrecoverable state
  which only a reboot will fix.

  I will be attaching screen and kern logs for the failures and a
  successful run on 14.04 on the same server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1573062/+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 1573062] Re: memory_stress_ng failing for IBM Power S812LC(TN71-BP012) for 16.04

[Mike Rushton]

mainline kernel 4.7 failed.


** Attachment added: "kern.log from 4.7 testing failure"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1573062/+attachment/4708871/+files/kern.log

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

Title:
  memory_stress_ng failing for IBM Power S812LC(TN71-BP012) for 16.04

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:
  memory_stress_ng, as part of server certification is failing for IBM
  Power S812LC(TN71-BP012) in bare metal mode. Failing in this case is
  defined by the test locking up the server in an unrecoverable state
  which only a reboot will fix.

  I will be attaching screen and kern logs for the failures and a
  successful run on 14.04 on the same server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1573062/+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 1416659] Re: Ubuntu can't detect bluetooth device of Lenovo s400u

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: bluez (Ubuntu)
   Status: New => Confirmed

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

Title:
  Ubuntu can't detect bluetooth device of Lenovo s400u

Status in bluez package in Ubuntu:
  Confirmed

Bug description:
  As reported in this question:
  https://answers.launchpad.net/ubuntu/+question/250942, Ubuntu 14.04.1
  LTS with kernel 3.18.4-031804-generic can't detect bluetooth device
  of Lenovo s400u.

  
  root@galindro-nb:~# lsb_release -rd
  Description:  Ubuntu 14.04.1 LTS
  Release:  14.04

  
  root@galindro-nb:~# dmesg | grep Blue
  [   17.753263] Bluetooth: Core ver 2.19
  [   17.753288] Bluetooth: HCI device and connection manager initialized
  [   17.753296] Bluetooth: HCI socket layer initialized
  [   17.753300] Bluetooth: L2CAP socket layer initialized
  [   17.753308] Bluetooth: SCO socket layer initialized
  [   17.761037] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
  [   17.761042] Bluetooth: BNEP filters: protocol multicast
  [   17.761051] Bluetooth: BNEP socket layer initialized
  [   17.788967] Bluetooth: RFCOMM TTY layer initialized
  [   17.788980] Bluetooth: RFCOMM socket layer initialized
  [   17.788986] Bluetooth: RFCOMM ver 1.11

  
  root@galindro-nb:~# hcitool scan
  Device is not available: No such device

  
  root@galindro-nb:/tmp# hcitool dev
  Devices:

  
  *** IMPORTANT thing about lsusb.log attached file ***

 The device displayed in this line: Bus 001 Device 003: ID 045e:0745
  Microsoft Corp. Nano Transceiver v1.0 for Bluetooth , isn't the
  ultrabook built-in bluetooth. It is a Microsoft wireless mouse that
  has a micro usb bluetooth adaptor. This hardware is working very well.

  The problem is with Lenovo S400U built-in bluetooth that isn't
  reconized by Ubuntu 14.04 LTS.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: bluez 4.101-0ubuntu13
  Uname: Linux 3.18.4-031804-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.3
  Architecture: amd64
  Date: Sat Jan 31 10:05:28 2015
  ExecutablePath: /usr/sbin/bluetoothd
  InstallationDate: Installed on 2014-06-29 (215 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  InterestingModules: rfcomm bnep bluetooth
  MachineType: LENOVO VIUS3
  ProcEnviron:
   PATH=(custom, no user)
   TERM=linux
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.18.4-031804-generic 
root=UUID=56329ea0-54a8-4c9e-baf2-e8b2980b224d ro quiet splash vt.handoff=7
  SourcePackage: bluez
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 02/21/2013
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 6DCN92WW(V8.06)
  dmi.board.asset.tag: No Asset Tag
  dmi.board.name: INVALID
  dmi.board.vendor: LENOVO
  dmi.board.version: 3194WIN8 STD SGL
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo IdeaPad S400U
  dmi.modalias: 
dmi:bvnLENOVO:bvr6DCN92WW(V8.06):bd02/21/2013:svnLENOVO:pnVIUS3:pvrLenovoIdeaPadS400U:rvnLENOVO:rnINVALID:rvr3194WIN8STDSGL:cvnLENOVO:ct10:cvrLenovoIdeaPadS400U:
  dmi.product.name: VIUS3
  dmi.product.version: Lenovo IdeaPad S400U
  dmi.sys.vendor: LENOVO
  hciconfig:
   
  syslog:
   <30>1 2015-01-31T10:02:56.875155-02:00 galindro-nb bluetoothd 3934 - -  
Bluetooth daemon 4.101
   <27>1 2015-01-31T10:02:56.876598-02:00 galindro-nb bluetoothd 3934 - -  
Unable to get on D-Bus
   <30>1 2015-01-31T10:04:58.601387-02:00 galindro-nb bluetoothd 3990 - -  
Bluetooth daemon 4.101
   <27>1 2015-01-31T10:04:58.602835-02:00 galindro-nb bluetoothd 3990 - -  
Unable to get on D-Bus

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1416659/+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 1362180] Re: can't connect my mouse

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: bluez (Ubuntu)
   Status: New => Confirmed

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

Title:
  can't connect my mouse

Status in bluez package in Ubuntu:
  Confirmed

Bug description:
  the mouse is Navigator 905BT (Genius), the laptop is Acer Aspire
  E1-731. i'm using Kubuntu 14.04 (64-bit). the os just won't see the
  mouse. the mouse works fine though in windows. i tried the latest
  fedora, no luck.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1362180/+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 1606960] kernel01 (s390x.zVM) - tests ran: 23, failed: 1

[Brad Figg]

tests ran:  23, failed: 1;
  
http://kernel.ubuntu.com/testing/4.4.0-34.53/kernel01__4.4.0-34.53__2016-07-28_16-36-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] s2lp3 (s390x.LPAR) - tests ran: 1, failed: 1

[Brad Figg]

tests ran:   1, failed: 1;
  
http://kernel.ubuntu.com/testing/4.4.0-30.49/s2lp3__4.4.0-30.49__2016-07-28_16-33-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] s2lp6g001 (s390x.zKVM) - tests ran: 1, failed: 1

[Brad Figg]

tests ran:   1, failed: 1;
  
http://kernel.ubuntu.com/testing/4.4.0-31.50/s2lp6g001__4.4.0-31.50__2016-07-28_16-35-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] s2lp6g001 (s390x.zKVM) - tests ran: 19, failed: 17

[Brad Figg]

tests ran:  19, failed: 17;
  
http://kernel.ubuntu.com/testing/4.4.0-31.50/s2lp6g001__4.4.0-31.50__2016-07-28_16-27-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] s2lp3 (s390x.LPAR) - tests ran: 19, failed: 17

[Brad Figg]

tests ran:  19, failed: 17;
  
http://kernel.ubuntu.com/testing/4.4.0-30.49/s2lp3__4.4.0-30.49__2016-07-28_16-27-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] kernel01 (s390x.zVM) - tests ran: 5, failed: 4

[Brad Figg]

tests ran:   5, failed: 4;
  
http://kernel.ubuntu.com/testing/4.4.0-34.53/kernel01__4.4.0-34.53__2016-07-28_16-21-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1590655] Re: [Hyper-V] storvsc messages for CD-ROM medium not present tray closed

[Joshua R. Poulson]

Acknowledged, we will verify and revert.

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

Title:
  [Hyper-V] storvsc messages for CD-ROM medium not present tray closed

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  In Progress
Status in linux source package in Vivid:
  Won't Fix
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  The below can be seen with any distribution running on a Generation 2
  VM.

  There is a verified patch for this, however it has been scheduled only for 
the 4.8 scsi-queue.
  As it a small patch which has been verified by KY and also accepted in the 
patch queue, will you be able to include this as part of the 16.04 rebase to 
4.6, and as well for 14.04 and 15.10?

  Patch can be found at https://patchwork.kernel.org/patch/9131929/

  Description of problem:
  When starting and shutting down a Gen2 VM, at least 20-30 messages are 
recorded for storvsc with the below sample:
  [storvsc] Sense Key : Not Ready [current]
  [storvsc] Add. Sense: Medium not present - tray closed

  Steps to Reproduce:
  1. create a Generation2 VM
  2. start VM and observe the system logs
  3. multiple messages for the cd-rom are recorded from storvsc

  Actual results:
  even without a CD-ROM unit attached, the messages would appear.
  Having an ISO attached or not would still produce the same messages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1590655/+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 1566302] Re: Ubuntu 16.04: Suspend freezes the system after upgrade to linux image 4.4.0-16

[Gregory Brancq]

I just tested the suspend to ram (sorry I misunderstood this option in my own 
language), it works.
The tip is that if the laptop is on the dockstation and I suspend it to ram, 
after wakeup I have to unplug and replug it, to bypass the black screen.

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

Title:
  Ubuntu 16.04: Suspend freezes the system after upgrade to linux image
  4.4.0-16

Status in linux package in Ubuntu:
  Won't Fix

Bug description:
  I'm using ubuntu 16.04 on a XPS 15 9550.

  Suspend/resume worked flawlessly with linux image 4.4.0-15, and after
  standard upgrade yesterday (5/04/2016) which installed image 4.4.0-16,
  the system freezes when attempting a suspend. I get  no response from
  the system (nor keyboard, nor screen, nor touchpad), but it gets very
  hot, so that it must be running something.

  Booting with 4.4.0-15 makes the suspend to work perfectly.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-extra-4.4.0-16-generic 4.4.0-16.32
  ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6
  Uname: Linux 4.4.0-15-generic x86_64
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  macias 1770 F pulseaudio
  CurrentDesktop: X-Cinnamon
  Date: Tue Apr  5 14:56:17 2016
  HibernationDevice: RESUME=UUID=4180adfa-3852-4a96-86b4-f3696448c743
  InstallationDate: Installed on 2016-03-07 (28 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160304)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 04f3:21d5 Elan Microelectronics Corp. 
   Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp. 
   Bus 001 Device 004: ID 1bcf:2b95 Sunplus Innovation Technology Inc. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. XPS 15 9550
  ProcEnviron:
   LANGUAGE=es_ES
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=es_ES.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-15-generic.efi.signed 
root=UUID=673f4658-75f8-4c01-bcd8-0af860269699 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-15-generic N/A
   linux-backports-modules-4.4.0-15-generic  N/A
   linux-firmware1.157
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/25/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.01.19
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.01.19:bd01/25/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1566302/+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 1583357] Re: [Hyper-V] Rebase Hyper-V to 4.6 kernel

[Joshua R. Poulson]

Acknowledged, we will verify and revert.

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

Title:
  [Hyper-V] Rebase Hyper-V to 4.6 kernel

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  Please rebase Hyper-V support to the final v4.6 upstream kernel.

  The following files comprise Hyper-V support in the upstream kernel:
  arch/x86/kernel/cpu/mshyperv.c
  arch/x86/include/asm/mshyperv.h
  arch/x86/include/uapi/asm/hyperv.h
  include/linux/hyperv.h
  drivers/hv/channel.c
  drivers/hv/channel_mgmt.c
  drivers/hv/connection.c
  drivers/hv/hv_balloon.c
  drivers/hv/hv.c
  drivers/hv/hv_fcopy.c
  drivers/hv/hv_kvp.c
  drivers/hv/hv_snapshot.c
  drivers/hv/hv_util.c
  drivers/hv/hv_utils_transport.c
  drivers/hv/hv_utils_transport.h
  drivers/hv/hyperv_vmbus.h
  drivers/hv/ring_buffer.c
  drivers/hv/vmbus_drv.c
  tools/hv/hv_fcopy_daemon.c
  tools/hv/hv_get_dhcp_info.sh
  tools/hv/hv_get_dns_info.sh
  tools/hv/hv_kvp_daemon.c
  tools/hv/hv_set_ifconfig.sh
  tools/hv/hv_vss_daemon.c
  tools/hv/lsvmbus
  drivers/input/serio/hyperv-keyboard.c
  drivers/net/hyperv/hyperv_net.h
  drivers/net/hyperv/netvsc.c
  drivers/net/hyperv/netvsc_drv.c
  drivers/net/hyperv/rndis_filter.c
  drivers/scsi/storvsc_drv.c
  drivers/hid/hid-hyperv.c
  drivers/pci/host/pci-hyperv.c
  drivers/video/fbdev/hyperv_fb.c

  While I know a number of post-4.4 commits are already committed, I am
  including all of the commits from 4.4 to 4.6 for reference:

  mshyperv.c : commit 1e2ae9ec072f3b7887f456426bc2cf23b80f661a : 
x86/hyperv: Avoid reporting bogus NMI status for Gen2 instances
  mshyperv.c : commit 1b74dde7c47c19a73ea3e9fac95ac27b5d3d50c5 : x86/cpu: 
Convert printk(KERN_ ...) to pr_(...)
  hyperv.h : commit 45870a441361d1c05a5f767c4ece2f6e30e0da9c : Drivers: hv: 
ring_buffer: remove stray smp_read_barrier_depends()
  hyperv.h : commit e8d6ca023efce3bd80050dcd9e708ee3cf8babd4 : Drivers: hv: 
vmbus: define the new offer type for Hyper-V socket (hvsock)
  hyperv.h : commit 5c23a1a5c60b0f472cfa61cd7d8279f8aaeb5b64 : Drivers: hv: 
vmbus: define a new VMBus message type for hvsock
  hyperv.h : commit 499e8401a515d04daa986b995da710d2b9737764 : Drivers: hv: 
vmbus: add a per-channel rescind callback
  hyperv.h : commit 3c75354d043ad546148d6992e40033ecaefc5ea5 : Drivers: hv: 
vmbus: add a helper function to set a channel's pending send size
  hyperv.h : commit 8981da320a11217589aa3c50f9e891bcdef07ece : Drivers: hv: 
vmbus: add a hvsock flag in struct hv_driver
  hyperv.h : commit b9830d120cbe155863399f25eaef6aa8353e767f : Drivers: hv: 
util: Pass the channel information during the init call
  channel.c : commit 63d55b2aeb5e4faa170316fee73c3c47ea9268c7 : Drivers: 
hv: vmbus: serialize process_chn_event() and vmbus_close_internal()
  channel.c : commit 5c23a1a5c60b0f472cfa61cd7d8279f8aaeb5b64 : Drivers: 
hv: vmbus: define a new VMBus message type for hvsock
  channel.c : commit fe760e4d64fe5c17c39e86c410d41f6587ee88bc : Drivers: 
hv: vmbus: Give control over how the ring access is serialized
  channel.c : commit 8599846d73997cdbccf63f23394d871cfad1e5e6 : Drivers: 
hv: vmbus: Fix a Host signaling bug
  channel_mgmt.c : commit fe760e4d64fe5c17c39e86c410d41f6587ee88bc : 
Drivers: hv: vmbus: Give control over how the ring access is serialized
  channel_mgmt.c : commit 79fd8e706637a5c7c41f9498fe0fbfb437abfdc8 : 
Drivers: hv: vmbus: avoid infinite loop in init_vp_index()
  channel_mgmt.c : commit 75ff3a8a9168df750b5bd0589e897a6c0517a9f1 : 
Drivers: hv: vmbus: avoid wait_for_completion() on crash
  channel_mgmt.c : commit 5c23a1a5c60b0f472cfa61cd7d8279f8aaeb5b64 : 
Drivers: hv: vmbus: define a new VMBus message type for hvsock
  connection.c : commit d6f591e339d23f434efda11917da511870891472 : Drivers: 
hv: vmbus: channge vmbus_connection.channel_lock to mutex
  connection.c : commit 75ff3a8a9168df750b5bd0589e897a6c0517a9f1 : Drivers: 
hv: vmbus: avoid wait_for_completion() on crash
  connection.c : commit 1b807e1011af46a595ba46c75ad5e20ad7177af7 : Drivers: 
hv: vmbus: Cleanup vmbus_set_event()
  hv.c : commit a108393dbf764efb2405f21ca759806c65b8bc16 : drivers:hv: 
Export the API to invoke a hypercall on Hyper-V
  hv.c : commit c35b82ef0294ae5052120615f5cfcef17c5a6bf7 : drivers/hv: 
correct tsc page sequence invalid value
  hv.c : commit 9220e39b5c900c67ddcb517d52fe52d90fb5e3c8 : Drivers: hv: 
vmbus: fix build warning
  hv.c : commit d81274aae61c0a045cd0f34191c51fa64ba58bc4 : Drivers: hv: 
vmbus: Support handling messages on multiple CPUs
  hv.c : commit 3ccb4fd8f492f99aece21acc1bd6142275f26236 : Drivers: hv: 
vmbus: don't manipulate with clocksources on crash
  hv_fcopy.c : commit 3cace4a616108539e2730f8dc21a636474395e0f : Drivers: 
hv: utils: run polling cal

[Kernel-packages] [Bug 1605344] Re: Regression caused by `fuse: Add support for pid namespaces` in 4.4.0-6.21

[Ubuntu Foundations Team Bug Bot]

** Tags added: patch

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

Title:
  Regression caused by `fuse: Add support for pid namespaces` in
  4.4.0-6.21

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

Bug description:
  SRU Justification

  Impact: The pid namespace support in fuse refuses requests from any
  process whose pid does not map into the pid namespace of the fuse
  userspace process. This has caused a regression for at least one user.

  Fix: Permit requests from processes whose pid does not map. Fill in
  the pid value in the fuse request with 0.

  Regression potential: A fuse filesystem not prepared to handle a pid
  of 0 in fuse requests might have problems. However such a filesystem
  would also receive pid values which aren't valid for its namespace
  when used across pid namespaces in this manner with upstream kernels,
  so this isn't a major concern.

  ---

  The discussion starts at
  http://thread.gmane.org/gmane.linux.kernel.cgroups/15960/focus=2269876

  Commit in the tree is:

  commit a166e6726c6e12e28ac8489ff4e2faff7065a856
  Author: Seth Forshee 
  Date:   Wed Jul 2 16:29:19 2014 -0500

  UBUNTU: SAUCE: fuse: Add support for pid namespaces

  Description of the issue(copied from my report of lkml):

  This patch caused a regression in our major container use case with
  FUSE in Ubuntu 16.04, as patch was checked in as Ubuntu Sauce in
  Ubuntu 4.4.0-6.21 kernel.

  The use case is:
  1. Create a Docker container.
  2. Inside the container, start the FUSE backend, and mounted fs.
  3. Following step 2 in the container, create a loopback device to map
  a file in the mounted fuse to create a block device, which will be
  available to the whole system.

  It works well before this commit.

  The use case is broken because no matter which namespace losetup runs,
  the real request from loopback device seems always come from init ns,
  thus it will be in different ns running fuse backend. So the request
  will got denied, because the ns running fuse won't able to see the
  things from higher level(level 0 in fact) pid namespace.
  ---
  ApportVersion: 2.14.1-0ubuntu3.21
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: linux (not installed)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature:

  Tags:  trusty
  Uname: Linux 4.4.6 x86_64
  UnreportableReason: The running kernel is not an Ubuntu kernel
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1605344/+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 1607374] Re: Cannot mount proc in unprivileged containers if /proc/xen is mounted

[Ubuntu Foundations Team Bug Bot]

** Tags added: patch

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

Title:
  Cannot mount proc in unprivileged containers if /proc/xen is mounted

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

Bug description:
  SRU Justification

  Impact: The xenfs filesystem is traditionally mounted at /proc/xen in
  xen guests. This directory doesn't use the special "create proc
  mountpoint" interface and thus fails the permanently empty test in
  fs_fully_visible(). This causes mounting of proc to fail in user
  namespace containers.

  Fix: Use the special proc interface to make this a "permanently empty"
  directory.

  Regression potential: This change will make it impossible to create
  files within /proc/xen, but since the directory is only ever used as a
  mount point this should not cause any problems.

  Original bug report and testing results can be found at
  https://github.com/lxc/lxd/issues/2238.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1607374/+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 1574342] Re: Ship arcstat.py and arc_summary.py with zfsutils-linux

[Eric Desrochers]

Debdiff for Xenial (16.04)

** Patch added: "Debdiff for Xenial (16.04)"
   
https://bugs.launchpad.net/ubuntu/xenial/+source/zfs-linux/+bug/1574342/+attachment/4708833/+files/lp574342_xenial.debdiff

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

Title:
  Ship arcstat.py and arc_summary.py with zfsutils-linux

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

Bug description:
  [Impact]

  zfsutils-linux missing some important tools.

  Python3 compatible scripts : arc_summary.py, arcstat.py and
  dbufstat.py found in src_code/cmd/ are not taken into account during
  compilation.

  * arc_summary.py : Provides a summary of the statistics
  https://github.com/zfsonlinux/zfs/blob/master/cmd/arc_summary

  * arcstat.py : Print out ZFS ARC Statistics exported via kstat(1)
  https://github.com/zfsonlinux/zfs/tree/master/cmd/arcstat

  * dbufstat.py: Print out statistics for all cached dmu buffers
  https://github.com/zfsonlinux/zfs/blob/master/cmd/dbufstat

  [Test Case]

  # rmadison zfsutils-linux
  ...
   zfsutils-linux | 0.6.5.6-0ubuntu10  | xenial-updates
  ...

  # List contents of a deb package.
  $ dpkg -c zfsutils-linux_0.6.5.6-0ubuntu10_amd64.deb | egrep 
"arcstat|arc_summary|dbufstat"

  # You will notice there are not present.

  [Regression Potential]

  None expected, debian package[1] has already made the change to build
  the python scripts.

  [1]
  Package: zfsutils-linux
  Source: zfs-linux
  Version: 0.6.5.7-1
  Architecture: amd64
  Maintainer: Debian ZFS on Linux maintainers 


  # List contents of a deb package.
  $ dpkg -c zfsutils-linux_0.6.5.7-1_amd64.deb | egrep -i "arc|dbufstat"
  -rwxr-xr-x root/root 40751 2016-05-31 03:40 ./bin/arc_summary.py
  -rwxr-xr-x root/root 13057 2016-05-31 03:40 ./bin/arcstat.py
  -rwxr-xr-x root/root 18718 2016-05-31 03:40 ./bin/dbufstat.py

  [Other Info]

  * This is based on the following Debian commits :

  Debian git commits
  ===
  commit 730989397063955d60a1845003cfb7433eba1e52
  Author: Aron Xu 
  Date: Tue Apr 26 17:01:29 2016 +0800

  Add dh-python to b-d

  --

  commit 814413118fb88de3ce596a87a8a011f50c225fdd
  Author: Aron Xu 
  Date: Sun Nov 22 15:44:16 2015 +0800

  Add python related dependencies
  ===

  * Despite what Debian did by adding theses script under /bin.
    I'll add them under /usr/sbin, which is more appropriate.

  * Unfortunately manpage for theses 3 program seems limited.
    There is none in Debian nor git upstream repo.

  The only manpage I found is for arcstat online :

  http://linux.die.net/man/1/arcstat

  [Original Description]

  arcstat.py and arc_summary.py are valuable tools to determine ZFS' ARC
  usage, it is not obvious why they are not included in zfsutils-linux.
  As ubuntu-minimal already depends on python3 it should be safe to
  assume python is available, or am I mistaken here?

  arcstat.py gives an iostat-like overview about ARC reads, hit rate, current 
and target size in regular intervals:
  # ./arcstat.py 1
  time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz c
  19:22:33 0 0  0 00 00 00   2.0G  7.8G
  19:22:34 3 0  0 00 00 00   2.0G  7.8G
  19:22:3521 0  0 00 00 00   2.0G  7.8G
  ^C

  arc_summary.py shows a more detailed overview of the current ARC status and 
ZFS tunables:
  # ./arc_summary.py

  
  ZFS Subsystem Report  Sun Apr 24 19:23:25 2016
  ARC Summary: (HEALTHY)
   Memory Throttle Count:   0

  ARC Misc:
   Deleted: 46
   Mutex Misses:0
   Evict Skips: 0

  ARC Size: 25.10%  1.95GiB
   Target Size: (Adaptive)  100.00% 7.78GiB
   Min Size (Hard Limit):   0.40%   32.00   MiB
   Max Size (High Water):   248:1   7.78GiB

  ARC Size Breakdown:
   Recently Used Cache Size:50.00%  3.89GiB
   Frequently Used Cache Size:  50.00%  3.89GiB

  ARC Hash Breakdown:
   Elements Max:32.31k
   Elements Current:99.78%  32.24k
   Collisions:  40.54k
   Chain Max:   3
   Chains:  240

  ARC Total accesses:   4.54m
   Cache Hit Ratio: 99.39%  4.51m
   Cache Miss Ratio:0.61%   27.74k
   Actual Hit Ratio:98.76%  4.48m

   Data Demand Efficiency:  99.73%  3.23m
   Data Prefetch Efficiency:11.32%  6.41k

   CACHE HITS BY CACHE LIST:

[Kernel-packages] [Bug 1606960] s2lp3 (s390x.LPAR) - tests ran: 5, failed: 5

[Brad Figg]

tests ran:   5, failed: 5;
  
http://kernel.ubuntu.com/testing/4.4.0-30.49/s2lp3__4.4.0-30.49__2016-07-28_16-15-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] s2lp6g001 (s390x.zKVM) - tests ran: 10, failed: 10

[Brad Figg]

tests ran:  10, failed: 10;
  
http://kernel.ubuntu.com/testing/4.4.0-31.50/s2lp6g001__4.4.0-31.50__2016-07-28_16-09-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] s2lp6g001 (s390x.zKVM) - tests ran: 23, failed: 23

[Brad Figg]

tests ran:  23, failed: 23;
  
http://kernel.ubuntu.com/testing/4.4.0-31.50/s2lp6g001__4.4.0-31.50__2016-07-28_16-21-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] s2lp3 (s390x.LPAR) - tests ran: 10, failed: 10

[Brad Figg]

tests ran:  10, failed: 10;
  
http://kernel.ubuntu.com/testing/4.4.0-30.49/s2lp3__4.4.0-30.49__2016-07-28_16-10-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] s2lp6g001 (s390x.zKVM) - tests ran: 5, failed: 5

[Brad Figg]

tests ran:   5, failed: 5;
  
http://kernel.ubuntu.com/testing/4.4.0-31.50/s2lp6g001__4.4.0-31.50__2016-07-28_16-15-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] s2lp3 (s390x.LPAR) - tests ran: 23, failed: 23

[Brad Figg]

tests ran:  23, failed: 23;
  
http://kernel.ubuntu.com/testing/4.4.0-30.49/s2lp3__4.4.0-30.49__2016-07-28_16-21-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1606960] kernel01 (s390x.zVM) - tests ran: 10, failed: 2

[Brad Figg]

tests ran:  10, failed: 2;
  
http://kernel.ubuntu.com/testing/4.4.0-34.53/kernel01__4.4.0-34.53__2016-07-28_16-10-00/results-index.html

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1572712] Re: console hung during Ubuntu 16.04 netboot install 4.4.0-12-generic [soft lockup]

[Tim Gardner]

The netboot image is regenerated whenever debian-installer changes,
i.e., when the kernel is updated.

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

Title:
  console hung during Ubuntu 16.04 netboot install 4.4.0-12-generic
  [soft lockup]

Status in linux package in Ubuntu:
  New

Bug description:
  Canonical,

  FYI and reference only at this time.

  Details:
  ---Problem Description---
  IPMI Console gets hung for 15 to 30 mins, can not traverse when trying to 
install 
  latest copy of Ubuntu 16.04 on Habanero from 
http://ports.ubuntu.com/ubuntu-ports/dists/xenial/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux
  which is 4.4.0-12-generic 
   [   36.803240] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! 
[swapper/2:0]
   
  ---uname output---
  4.4.0-12-generic 
   
  ---Additional Hardware Info---
  TN71-BP012  

   
  Machine Type = TN71-BP012  
   
  ---System Hang---
   we have to wait for 15 to 30 mins to regain the console access.

   
  ---Steps to Reproduce---
  use IPMI console for  petitboot on habanero, configure IP to a network 
device, make sure you have internet outbound BSO authenticated. 
  on petit shell run following commands 
  cd /tmp;
  wget 
http://ports.ubuntu.com/ubuntu-ports/dists/xenial/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux
 ;
  wget 
http://ports.ubuntu.com/ubuntu-ports/dists/xenial/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/initrd.gz
 ;
  kexec -l /tmp/vmlinux  -i /tmp/initrd.gz  ;
  kexec -e ;

   
  Stack trace output:
   [   36.803240] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! 
[swapper/2:0]
  [   36.803425] Modules linked in: hid_generic(E) ast(E) i2c_algo_bit(E) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) ttm
  ) usb_storage(E)
  [   36.803436] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GE   
4.4.0-12-generic #28-Ubuntu
  [   36.803438] task: c03c8fe8e7b0 ti: c03c9753 task.ti: 
c03c9753
  [   36.803440] NIP: c0010a24 LR: c0010a24 CTR: 
c060c2f0
  [   36.803442] REGS: c03c97533510 TRAP: 0901   Tainted: GE
(4.4.0-12-generic)
  [   36.803443] MSR: 90019033   CR: 28002824  
XER: 
  [   36.803448] CFAR: c060c330 SOFTE: 1 
  [   36.803448] GPR00: c00db8b4 c03c97533790 c15a3b00 
0900 
  [   36.803448] GPR04: c03c8fef6e00 0001  
03ff 
  [   36.803448] GPR08:  c03ffb064605 0001 
0004 
  [   36.803448] GPR12: c060c2f0 cfb41300 
  [   36.803460] NIP [c0010a24] arch_local_irq_restore+0x74/0x90
  [   36.803462] LR [c0010a24] arch_local_irq_restore+0x74/0x90
  [   36.803463] Call Trace:
  [   36.803465] [c03c97533790] [c014b184] mod_timer+0x154/0x300 
(unreliable)
  [   36.803468] [c03c975337b0] [c00db8b4] queue_work_on+0x74/0xf0
  [   36.803471] [c03c975337f0] [c060c334] 
cursor_timer_handler+0x44/0x80
  [   36.803474] [c03c97533820] [c0149ebc] call_timer_fn+0x5c/0x1c0
  [   36.803476] [c03c975338b0] [c014a37c] 
run_timer_softirq+0x31c/0x3f0
  [   36.803480] [c03c97533980] [c00beaf8] __do_softirq+0x188/0x3e0
  [   36.803483] [c03c97533a70] [c00befc8] irq_exit+0xc8/0x100
  [   36.803487] [c03c97533a90] [c001f954] timer_interrupt+0xa4/0xe0
  [   36.803490] [c03c97533ac0] [c0002714] 
decrementer_common+0x114/0x180
  [   36.803494] --- interrupt: 901 at arch_local_irq_restore+0x74/0x90
  [   36.803494] LR = arch_local_irq_restore+0x74/0x90
  [   36.803497] [c03c97533db0] [c03ffc49d678] 0xc03ffc49d678 
(unreliable)
  [   36.803502] [c03c97533dd0] [c0900708] 
cpuidle_enter_state+0x1a8/0x410
  [   36.803504] [c03c97533e30] [c0119898] call_cpuidle+0x78/0xd0
  [   36.803506] [c03c97533e70] [c0119c6c] 
cpu_startup_entry+0x37c/0x490
  [   36.803509] [c03c97533f30] [c004565c] 
start_secondary+0x33c/0x360
  [   36.803511] [c03c97533f90] [c0008b6c] 
start_secondary_prolog+0x10/0x14
  [   36.803512] Instruction dump:
  [   36.803514] 994d02ca 2fa3 409e0024 e92d0020 61298000 7d210164 38210020 
e8010010 
  [   36.803517] 7c0803a6 4e800020 6042 4bff17ad <6000> 4be4 
6042 e92d0020 
  [   57.811232] INFO: rcu_sched self-detected stall on CPU
  [   57.811236]  2-...: (1 GPs behind) idle=913/2/0 softirq=1849/1979 fqs=5229 
  [   57.811238]   (t=5250 jiffies g=-114 c=-115 q=1)
  [   57.811242] Task dump for CPU 2:
  [   57.811243] swapper/2   R  running task0 0  1 
0x0804
  [   57.811246] Call Trace:
  [   57.811248] [c03c97532fe0] [c00fb8c0] 
sched_show_task

[Kernel-packages] [Bug 1574342] Re: Ship arcstat.py and arc_summary.py with zfsutils-linux

[Eric Desrochers]

Debdiff for Yakkety (16.10)

** Patch added: "Debdiff for Yakkety (16.10)"
   
https://bugs.launchpad.net/ubuntu/xenial/+source/zfs-linux/+bug/1574342/+attachment/4708820/+files/lp1574342_yakkety.debdiff

** Tags added: patch sts

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

Title:
  Ship arcstat.py and arc_summary.py with zfsutils-linux

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

Bug description:
  [Impact]

  zfsutils-linux missing some important tools.

  Python3 compatible scripts : arc_summary.py, arcstat.py and
  dbufstat.py found in src_code/cmd/ are not taken into account during
  compilation.

  * arc_summary.py : Provides a summary of the statistics
  https://github.com/zfsonlinux/zfs/blob/master/cmd/arc_summary

  * arcstat.py : Print out ZFS ARC Statistics exported via kstat(1)
  https://github.com/zfsonlinux/zfs/tree/master/cmd/arcstat

  * dbufstat.py: Print out statistics for all cached dmu buffers
  https://github.com/zfsonlinux/zfs/blob/master/cmd/dbufstat

  [Test Case]

  # rmadison zfsutils-linux
  ...
   zfsutils-linux | 0.6.5.6-0ubuntu10  | xenial-updates
  ...

  # List contents of a deb package.
  $ dpkg -c zfsutils-linux_0.6.5.6-0ubuntu10_amd64.deb | egrep 
"arcstat|arc_summary|dbufstat"

  # You will notice there are not present.

  [Regression Potential]

  None expected, debian package[1] has already made the change to build
  the python scripts.

  [1]
  Package: zfsutils-linux
  Source: zfs-linux
  Version: 0.6.5.7-1
  Architecture: amd64
  Maintainer: Debian ZFS on Linux maintainers 


  # List contents of a deb package.
  $ dpkg -c zfsutils-linux_0.6.5.7-1_amd64.deb | egrep -i "arc|dbufstat"
  -rwxr-xr-x root/root 40751 2016-05-31 03:40 ./bin/arc_summary.py
  -rwxr-xr-x root/root 13057 2016-05-31 03:40 ./bin/arcstat.py
  -rwxr-xr-x root/root 18718 2016-05-31 03:40 ./bin/dbufstat.py

  [Other Info]

  * This is based on the following Debian commits :

  Debian git commits
  ===
  commit 730989397063955d60a1845003cfb7433eba1e52
  Author: Aron Xu 
  Date: Tue Apr 26 17:01:29 2016 +0800

  Add dh-python to b-d

  --

  commit 814413118fb88de3ce596a87a8a011f50c225fdd
  Author: Aron Xu 
  Date: Sun Nov 22 15:44:16 2015 +0800

  Add python related dependencies
  ===

  * Despite what Debian did by adding theses script under /bin.
    I'll add them under /usr/sbin, which is more appropriate.

  * Unfortunately manpage for theses 3 program seems limited.
    There is none in Debian nor git upstream repo.

  The only manpage I found is for arcstat online :

  http://linux.die.net/man/1/arcstat

  [Original Description]

  arcstat.py and arc_summary.py are valuable tools to determine ZFS' ARC
  usage, it is not obvious why they are not included in zfsutils-linux.
  As ubuntu-minimal already depends on python3 it should be safe to
  assume python is available, or am I mistaken here?

  arcstat.py gives an iostat-like overview about ARC reads, hit rate, current 
and target size in regular intervals:
  # ./arcstat.py 1
  time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz c
  19:22:33 0 0  0 00 00 00   2.0G  7.8G
  19:22:34 3 0  0 00 00 00   2.0G  7.8G
  19:22:3521 0  0 00 00 00   2.0G  7.8G
  ^C

  arc_summary.py shows a more detailed overview of the current ARC status and 
ZFS tunables:
  # ./arc_summary.py

  
  ZFS Subsystem Report  Sun Apr 24 19:23:25 2016
  ARC Summary: (HEALTHY)
   Memory Throttle Count:   0

  ARC Misc:
   Deleted: 46
   Mutex Misses:0
   Evict Skips: 0

  ARC Size: 25.10%  1.95GiB
   Target Size: (Adaptive)  100.00% 7.78GiB
   Min Size (Hard Limit):   0.40%   32.00   MiB
   Max Size (High Water):   248:1   7.78GiB

  ARC Size Breakdown:
   Recently Used Cache Size:50.00%  3.89GiB
   Frequently Used Cache Size:  50.00%  3.89GiB

  ARC Hash Breakdown:
   Elements Max:32.31k
   Elements Current:99.78%  32.24k
   Collisions:  40.54k
   Chain Max:   3
   Chains:  240

  ARC Total accesses:   4.54m
   Cache Hit Ratio: 99.39%  4.51m
   Cache Miss Ratio:0.61%   27.74k
   Actual Hit Ratio:98.76%  4.48m

   Data Demand Efficiency:  99.73%  3.23m
   Data Prefetch Efficiency:11.32%  6.41k

[Kernel-packages] [Bug 1491729] Re: dkms: add module build ordering for ZFS on Linux

[Launchpad Bug Tracker]

This bug was fixed in the package dkms - 2.2.0.3-1.1ubuntu5.14.04.7

---
dkms (2.2.0.3-1.1ubuntu5.14.04.7) trusty; urgency=medium

  * Build Linux modules in a specific order (LP: #1491729)
- Add POST_BUILD directive, and implement a BUILD_DEPENDS directive that
  instructs `dkms autoinstall` to build Linux modules in a specific order to
  ensure ZFS to build after SPL.
- Force the installation of a module if it is listed in
  /usr/share/dkms/modules_to_force_install

 -- Colin Ian King   Fri, 24 Jun 2016 16:43:12
+0100

** Changed in: dkms (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

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

Title:
  dkms: add module build ordering for ZFS on Linux

Status in dkms package in Ubuntu:
  Fix Released
Status in dkms source package in Trusty:
  Fix Released
Status in dkms source package in Wily:
  Fix Released

Bug description:
  updated: SRU request, trusty (24th June, 2016)

  (updated now from a FFe to a SRU for Wily)(old)
  SRU request, Wily.

  [IMPACT]
  Without this, we can have incorrect ordering which causes DKMS build failures 
for multiple kernel module projects, such as ZFS (where ZFS requires the ZFS 
support module spl to be built first).

  [TEST CASE]
  Install Wily zfs, occasionally the build ordering will be zfs and the spl, 
and the zfs DKMS build will fail because spl is not yet built. With the fix, 
build ordering for zfs will always occur in spl, then zfs order because it uses 
the new BUILD_DEPENDS directive.
  Note: The upload will trigger the testing of all DKMS modules, so it'll get 
an adequate beating by britney (according to Martin Pitt).

  [REGRESSION POTENTIAL]
  DKMS package builds will fail.

  ---
  Feature Freeze Exception Request:

  build ordering to build ZFS on Linux (ZoL) is required, the motivating
  case is for ordering such as modules such as zfs -> spl

  Without this, we can have incorrect ordering which causes DKMS build
  failures for multiple kernel module projects, such as ZFS (where ZFS
  requires the ZFS support module spl to be built first).

  Pull in fixes from the ZFS on Linux project that enable this ordering
  to DKMS.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1491729/+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 1543461] Re: linux: intermittent ADT test failures on ppc64el

[Tyler Hicks]

The (1) onexec test problem is tracked in bug #1528230. Please use this
bug to track the (2) exec_qual test failure or problem.

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

Title:
  linux: intermittent ADT test failures on ppc64el

Status in QA Regression Testing:
  New
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  The linux internal test suites fail intermittently (1/3 approx) as
  below:

  [...]
test_parser_testsuite (__main__.ApparmorTestsuites)
Run parser regression tests ... ok
test_regression_testsuite (__main__.ApparmorTestsuites)
Run kernel regression tests ... FAIL
test_stress_parser_testsuite (__main__.ApparmorTestsuites)
Run parser stress test ... ok
  [...]
==
FAIL: test_regression_testsuite (__main__.ApparmorTestsuites)
Run kernel regression tests
--
Traceback (most recent call last):
  File "./test-apparmor.py", line 1589, in test_regression_testsuite
self.assertEquals(expected, rc, result + report)
AssertionError: Got exit code 2, expected 0

To manage notifications about this bug go to:
https://bugs.launchpad.net/qa-regression-testing/+bug/1543461/+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 1528230] Re: [ADT test failure] linux: ubuntu_qrt_apparmor.test-apparmor.py -- ONEXEC - check current 'unconfined' != expected

[Tyler Hicks]

This fix was released in yakkety via 2.10.95-4ubuntu2.

** Changed in: apparmor (Ubuntu)
   Status: New => Fix Released

** Changed in: apparmor (Ubuntu)
   Importance: Undecided => Medium

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

** Changed in: apparmor (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: apparmor (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: apparmor (Ubuntu Xenial)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

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

** Changed in: linux (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: qa-regression-testing
   Status: New => Invalid

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

Title:
  [ADT test failure] linux: ubuntu_qrt_apparmor.test-apparmor.py --
  ONEXEC - check current 'unconfined' != expected

Status in AppArmor:
  Fix Committed
Status in QA Regression Testing:
  Invalid
Status in apparmor package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in apparmor source package in Xenial:
  In Progress
Status in linux source package in Xenial:
  Invalid

Bug description:
  New ADT test failure in Vivid:

    running onexec
    ONEXEC - check current 'unconfined' != expected 
'/tmp/testlibIUFsmN/source/vivid/apparmor-2.9.1/tests/regression/apparmor/onexec'
    Fatal Error (onexec): Unable to run test sub-executable

  Full log:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-vivid/vivid/ppc64el/l/linux/20151218_175610@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1528230/+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 1606960] Re: linux: 4.4.0-34.53 -proposed tracker

[Brad Figg]

** Changed in: kernel-sru-workflow/automated-testing
   Status: New => Confirmed

** Changed in: kernel-sru-workflow/certification-testing
   Status: New => Confirmed

** Changed in: kernel-sru-workflow/promote-to-proposed
   Status: In Progress => Fix Released

** Changed in: kernel-sru-workflow/regression-testing
   Status: New => Confirmed

** Changed in: kernel-sru-workflow/security-signoff
   Status: New => Confirmed

** Changed in: kernel-sru-workflow/verification-testing
   Status: New => Confirmed

** Changed in: kernel-sru-workflow/automated-testing
   Status: Confirmed => Incomplete

** Description changed:

  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.
  
  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  
  -- swm properties --
  derivative-trackers-created: true
  phase: Uploaded
+ kernel-stable-phase:Promoted to proposed
+ kernel-stable-phase-changed:Thursday, 28. July 2016 16:03 UTC

** Description changed:

  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.
  
  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  
  -- swm properties --
  derivative-trackers-created: true
- phase: Uploaded
- kernel-stable-phase:Promoted to proposed
- kernel-stable-phase-changed:Thursday, 28. July 2016 16:03 UTC
+ phase: Promoted to proposed
+ proposed-announcement-sent: true
+ proposed-testing-requested: true

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

Title:
  linux: 4.4.0-34.53 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Incomplete
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Confirmed
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New

Bug description:
  This bug is for tracking the 4.4.0-34.53 upload package. This bug will
  contain status and testing results related to that upload.

  For an explanation of the tasks and the associated workflow see:
  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  derivative-trackers-created: true
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1606960/+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 1528230] Re: [ADT test failure] linux: ubuntu_qrt_apparmor.test-apparmor.py -- ONEXEC - check current 'unconfined' != expected

[Tyler Hicks]

I think this was likely a problem (race condition) in the upstream test
itself. I think I've been able to eliminate any races in the test with
upstream commits r3488 and r3489.

** Also affects: apparmor
   Importance: Undecided
   Status: New

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

** Changed in: apparmor
   Status: New => Fix Committed

** Changed in: apparmor
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

** Changed in: apparmor
   Importance: Undecided => Medium

** Changed in: apparmor
Milestone: None => 2.11

** Also affects: apparmor (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Xenial)
   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/1528230

Title:
  [ADT test failure] linux: ubuntu_qrt_apparmor.test-apparmor.py --
  ONEXEC - check current 'unconfined' != expected

Status in AppArmor:
  Fix Committed
Status in QA Regression Testing:
  Invalid
Status in apparmor package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in apparmor source package in Xenial:
  In Progress
Status in linux source package in Xenial:
  Invalid

Bug description:
  New ADT test failure in Vivid:

    running onexec
    ONEXEC - check current 'unconfined' != expected 
'/tmp/testlibIUFsmN/source/vivid/apparmor-2.9.1/tests/regression/apparmor/onexec'
    Fatal Error (onexec): Unable to run test sub-executable

  Full log:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-vivid/vivid/ppc64el/l/linux/20151218_175610@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1528230/+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 1607404] Re: Xenial update to v4.4.16 stable release

[Tim Gardner]

** Description changed:

+ SRU Justification
  
- SRU Justification
+ Impact:
+    The upstream process for stable tree updates is quite similar
+    in scope to the Ubuntu SRU process, e.g., each patch has to
+    demonstrably fix a bug, and each patch is vetted by upstream
+    by originating either directly from a mainline/stable Linux tree or
+    a minimally backported form of that patch. The v4.4.16 upstream stable
+    patch set is now available. It should be included in the Ubuntu
+    kernel as well.
  
- Impact:
-The upstream process for stable tree updates is quite similar
-in scope to the Ubuntu SRU process, e.g., each patch has to
-demonstrably fix a bug, and each patch is vetted by upstream
-by originating either directly from a mainline/stable Linux tree or
-a minimally backported form of that patch. The v4.4.16 upstream stable
-patch set is now available. It should be included in the Ubuntu
-kernel as well.
+    git://git.kernel.org/
  
-git://git.kernel.org/
+ TEST CASE: TBD
  
- TEST CASE: TBD
+    The following patches from the v4.4.16 stable release shall be
+ applied:
  
-The following patches from the v4.4.16 stable release shall be
- applied:
+ mac80211: fix fast_tx header alignment
+ mac80211: mesh: flush mesh paths unconditionally
+ mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL
+ mac80211: Fix mesh estab_plinks counting in STA removal case
+ EDAC, sb_edac: Fix rank lookup on Broadwell
+ IB/cm: Fix a recently introduced locking bug
+ IB/mlx4: Properly initialize GRH TClass and FlowLabel in AHs
+ powerpc/pseries: Fix IBM_ARCH_VEC_NRCORES_OFFSET since POWER8NVL was added
+ powerpc/tm: Always reclaim in start_thread() for exec() class syscalls
+ usb: dwc2: fix regression on big-endian PowerPC/ARM systems
+ USB: EHCI: declare hostpc register as zero-length array
+ usb: common: otg-fsm: add license to usb-otg-fsm
+ mnt: fs_fully_visible test the proper mount for MNT_LOCKED
+ mnt: Account for MS_RDONLY in fs_fully_visible
+ mnt: If fs_fully_visible fails call put_filesystem.
+ of: fix autoloading due to broken modalias with no 'compatible'
+ of: irq: fix of_irq_get[_byname]() kernel-doc
+ locking/ww_mutex: Report recursive ww_mutex locking early
+ locking/qspinlock: Fix spin_unlock_wait() some more
+ locking/static_key: Fix concurrent static_key_slow_inc()
+ x86, build: copy ldlinux.c32 to image.iso
+ kprobes/x86: Clear TF bit in fault on single-stepping
+ x86/amd_nb: Fix boot crash on non-AMD systems
+ Revert "gpiolib: Split GPIO flags parsing and GPIO configuration"
+ uvc: Forward compat ioctls to their handlers directly
+ thermal: cpu_cooling: fix improper order during initialization
+ writeback: use higher precision calculation in domain_dirty_limits()
+ nfsd4/rpc: move backchannel create logic into rpc code
+ nfsd: Always lock state exclusively.
+ nfsd: Extend the mutex holding region around in nfsd4_process_open2()
+ posix_acl: Add set_posix_acl
+ nfsd: check permissions when setting ACLs
+ make nfs_atomic_open() call d_drop() on all ->open_context() errors.
+ NFS: Fix another OPEN_DOWNGRADE bug
+ ARM: imx6ul: Fix Micrel PHY mask
+ ARM: 8578/1: mm: ensure pmd_present only checks the valid bit
+ ARM: 8579/1: mm: Fix definition of pmd_mknotpresent
+ MIPS: KVM: Fix modular KVM under QEMU
+ mm: Export migrate_page_move_mapping and migrate_page_copy
+ UBIFS: Implement ->migratepage()
+ sched/fair: Fix cfs_rq avg tracking underflow
+ packet: Use symmetric hash for PACKET_FANOUT_HASH.
+ net_sched: fix mirrored packets checksum
+ cdc_ncm: workaround for EM7455 "silent" data interface
+ ipv6: Fix mem leak in rt6i_pcpu
+ ARCv2: Check for LL-SC livelock only if LLSC is enabled
+ ARCv2: LLSC: software backoff is NOT needed starting HS2.1c
+ kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES
+ KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.
+ HID: elo: kill not flush the work
+ HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands
+ tracing: Handle NULL formats in hold_module_trace_bprintk_format()
+ base: make module_create_drivers_dir race-free
+ iommu/arm-smmu: Wire up map_sg for arm-smmu-v3
+ iommu/vt-d: Enable QI on all IOMMUs before setting root entry
+ iommu/amd: Fix unity mapping initialization race
+ drm/mgag200: Black screen fix for G200e rev 4
+ ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg()
+ arm64: Rework valid_user_regs
+ vfs: add d_real_inode() helper
+ af_unix: fix hard linked sockets on overlay
+ btrfs: account for non-CoW'd blocks in btrfs_abort_transaction
+ drm/radeon: fix asic initialization for virtualized environments
+ drm/amdgpu/gfx7: fix broken condition check
+ ubi: Make recover_peb power cut aware
+ drm/amdkfd: unbind only existing processes
+ drm/amdkfd: destroy dbgmgr in notifier release
+ drm/dp/mst: Always clear proposed vcpi table for port.
+ drm/n

[Kernel-packages] [Bug 1548009] Re: ZFS pools should be automatically scrubbed

[Tim Bishop]

Could /usr/lib/zfs-linux/scrub not just give the full path to zpool
instead? Then PATH wouldn't need modifying at all.

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

Title:
  ZFS pools should be automatically scrubbed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

  Xenial shipped with a cron job to automatically scrub ZFS pools, as
  desired by many users and as implemented by mdadm for traditional Linux
  software RAID.  Unfortunately, this cron job does not work, because it needs 
a PATH line for /sbin, where the zpool utility lives.

  Given the existence of the cron job and various discussions on IRC, etc.,
  users expect that scrubs are happening, when they are not.  This means ZFS
  is not pre-emptively checking for (and correcting) corruption. The odds of
  disk corruption are admittedly very low, but violating users' expectations
  of data safety, especially when they've gone out of their way to use a
  filesystem which touts data safety, is bad.

  [Test Case]

  $ truncate -s 1G test.img
  $ sudo zpool create test `pwd`/test.img
  $ sudo zpool status test

  $ sudo vi /etc/cron.d/zfsutils-linux
  Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes
  (modifying the date range if it's not currently the 8th through the 14th
  and the "-eq 0" check if it's not currently a Sunday).

  $ grep zfs /var/log/cron.log
  Verify in /var/log/cron.log that the job ran.

  $ sudo zpool status test

  Expected results:
scan: scrub repaired 0 in ... on 

  Actual results:
scan: none requested

  Then, add the PATH line, update the time rules in the cron job, and repeat
  the test. Now it will work.

  - OR -

  The best test case is to leave the cron job file untouched, install the
  patched package, wait for the second Sunday of the month, and verify with
  zpool status that a scrub ran.  I did this, on Xenial, with the package I
  built.  The debdiff is in comment #11 and was accepted to Yakkety.

  If someone can get this in -proposed before the 14th, I'll gladly install
  the actual package from -proposed and make sure it runs correctly on the
  14th.

  [Regression Potential]

  The patch only touches the cron.d file, which has only one cron job in it.
  This cron job is completely broken (inoperative) at the moment, so the
  regression potential is very low.


  
  ORIGINAL, PRE-SRU, DESCRIPTION:

  mdadm automatically checks MD arrays. ZFS should automatically scrub
  pools too. Scrubbing a pool allows ZFS to detect on-disk corruption
  and (when the pool has redundancy) correct it. Note that ZFS does not
  blindly assume the other copy is correct; it will only overwrite bad
  data with data that is known to be good (i.e. it passes the checksum).

  I've attached a debdiff which accomplishes this. It builds and
  installs cleanly.

  The meat of it is the scrub script I've been using on production
  systems, both servers and laptops, and recommending in my Ubuntu root-
  on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool
  is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot
  of disk load which could theoretically lead to another failure. We
  should save that disk load for resilvering. 2) Performance is already
  less on a degraded pool and scrubbing can make that worse, even though
  scrubs are throttled. Arguably, I might be being too conservative
  here, but the marginal benefit of scrubbing a *degraded* pool is
  pretty minimal as pools should not be left degraded for very long.

  The cron.d in this patch scrubs on the second Sunday of the month.
  mdadm scrubs on the first Sunday of the month. This way, if a system
  has both MD and ZFS pools, the load doesn't all happen at the same
  time. If the system doesn't have both types, it shouldn't really
  matter which week. If you'd rather make it the same week as MD, I see
  no problem with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+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 796588] Re: Fine-grained network mediation

[Jamie Strandboge]

FYI, this is a requirement for snapd, but it was deprioritized in favor
of namespace stacking in support of LXD, upstreaming and other work in
support of snappy (eg, gsettings mediation). A lot of work was done to
support this, but the soonest it would be delivered given current
priorities is 17.04.

Note, I'm only giving the current status, not setting the priority for
this, but this feature is very high on the list and in the queue.

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

Title:
  Fine-grained network mediation

Status in AppArmor:
  In Progress
Status in apparmor package in Ubuntu:
  Triaged
Status in linux package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: apparmor

  This is a wishlist item / feature request.

  Increase the granularity of network restrictions to allow
  specification of which ports or ranges of ports can or can't be used
  by an application.  This functionality is available in systrace if
  either the example or code would be of help:

  http://en.wikipedia.org/wiki/Systrace

  http://www.systrace.org/

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/796588/+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 1572801] Re: Ubuntu 16.04 Unity desktop uses much more ram than Ubuntu 15.10

[warren]

Maybe this will help, Bugzilla Gnome-Shell memory leak bugs:
Bug 735705  Summary -Memory usage of gnome-shell increasing to X GiB (heap)
https://bugzilla.gnome.org/show_bug.cgi?id=735705 
Bug 709451 -gnome-shell memory leaks 
https://bugzilla.gnome.org/show_bug.cgi?id=709451
Bug 701230 - Summary:   Memory usage grows rapidly, never decreases 
https://bugzilla.gnome.org/show_bug.cgi?id=701230

Bug List related to gnome-shell memory leaks:
https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=leak&list_id=82997&order=changeddate%20DESC%2Cpriority%2Cbug_severity&product=gnome-shell&query_based_on=&query_format=specific

** Bug watch added: GNOME Bug Tracker #735705
   https://bugzilla.gnome.org/show_bug.cgi?id=735705

** Bug watch added: GNOME Bug Tracker #709451
   https://bugzilla.gnome.org/show_bug.cgi?id=709451

** Bug watch added: GNOME Bug Tracker #701230
   https://bugzilla.gnome.org/show_bug.cgi?id=701230

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

Title:
  Ubuntu 16.04 Unity desktop uses much more ram than Ubuntu 15.10

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  Confirmed

Bug description:
  Ubuntu 16.04 64bit ISO number 20160420.1
  unity version 7.4.0+16.04.20160415-0ubuntu1
  Ubuntu 16.04 64bit ram usage has increase dramatically over Ubuntu 15.10
  Ubuntu 16.04 ram roughly 1 GB Ubuntu15.10 can be tuned to 420, 450 MB
  Ubuntu 16.04 with unity uses 1GB whereas Kubuntu 16.04 is using 420MB live usb

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: unity 7.4.0+16.04.20160415-0ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
  Uname: Linux 4.4.0-21-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  CasperVersion: 1.376
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: compiz
  CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
  CompositorUnredirectFSW: true
  CurrentDesktop: Unity
  Date: Thu Apr 21 01:44:22 2016
  DistUpgraded: Fresh install
  DistroCodename: xenial
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics 
Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller])
 Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor 
Integrated Graphics Controller [1043:8534]
  GsettingsChanges:
   b'org.compiz.core' b'outputs' b"['1920x1080+0+0']"
   b'org.compiz.core' b'active-plugins' b"['core', 'composite', 'opengl', 
'place', 'regex', 'resize', 'session', 'snap', 'vpswitch', 'wall', 'animation', 
'commands', 'compiztoolbox', 'copytex', 'fade', 'grid', 'imgpng', 'mousepoll', 
'move', 'scale', 'unitymtgrabhandles', 'workarounds', 'expo', 'ezoom', 
'unityshell']"
   b'org.gnome.desktop.interface' b'gtk-im-module' b"'gtk-im-context-simple'"
   b'org.gnome.desktop.interface' b'scaling-factor' b'uint32 1'
  LiveMediaBuild: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
  MachineType: ASUS All Series
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz.efi 
file=/cdrom/preseed/username.seed boot=casper quiet splash --- 
cdrom-detect/try-usb=true noprompt
  SourcePackage: unity
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/03/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 2004
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: Z87-PLUS
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: Asset-1234567890
  dmi.chassis.type: 3
  dmi.chassis.vendor: Chassis Manufacture
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr2004:bd06/03/2014:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ87-PLUS:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
  dmi.product.name: All Series
  dmi.product.version: System Version
  dmi.sys.vendor: ASUS
  version.compiz: compiz 1:0.9.12.2+16.04.20160415-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.67-1
  version.libgl1-mesa-dri: libgl1-mesa-dri 11.2.0-1ubuntu2
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 11.2.0-1ubuntu2
  version.xserver-xorg-core: xserver-xorg-core 2:1.18.3-1ubuntu2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160325-1ubuntu1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.12-1build2
  xserver.bootTime: Thu Apr 21 01:37:17 2016
  xser

[Kernel-packages] [Bug 1586418] Re: exercising ptys causes a kernel oops

[Colin Ian King]

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Colin Ian King (colin-king)

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => Medium

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

Title:
  exercising ptys causes a kernel oops

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  [SRU JUSTIFICATION][TRUSTY][WILY][XENIAL]

  Running stress-ng --pty 1 with a very low vmalloc memory available can
  trip an oops.  This can be generally only be reproduced when memory is
  under a high amount of pressure.  I was able to reproduce reliably by
  forcefully injecting vmalloc to return NULL when the stress-ng pty was
  running.

  [FIX]
  Upstream commit 5353ed8deedee9e5acb9f896e9032158f5d998de ("devpts: fix null 
pointer dereference on failed memory allocation"). This needs backporting to 
Yakkey, Xenial, Wily and Trusty because of changes in variable names.

  [TEST]
  Forcefully inject vmalloc to return NULL when running the pty stressor. 
Without the fix, an oops can be tripped, with the fix, no issues occur.

  --

  running: "stress-ng --pty 1" and this occurs in less than 1 second:

  [   67.753230] alloc_vmap_area: 9 callbacks suppressed
  [   67.753233] vmap allocation for size 16384 failed: use vmalloc= to 
increase size.
  [   67.753235] vmalloc: allocation failure: 8844 bytes
  [   67.753237] stress-ng-pty: page allocation failure: order:0, mode:0x24000c2
  [   67.753240] CPU: 2 PID: 2150 Comm: stress-ng-pty Not tainted 
4.4.0-23-generic #41-Ubuntu
  [   67.753241] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
  [   67.753243]  c1abf967 0832d3cc 0286 f2497c8c c139fe1f c19ce22c 
0001 f2497cbc
  [   67.753248]  c1177396 c19cc624 f506b5f0  024000c2 f2497cd0 
c19ce22c f2497ca4
  [   67.753252]  0832d3cc 228c  f2497cec c11ad2ff 024000c2 
 c19ce22c
  [   67.753256] Call Trace:
  [   67.753264]  [] dump_stack+0x58/0x79
  [   67.753267]  [] warn_alloc_failed+0xd6/0x110
  [   67.753272]  [] __vmalloc_node_range+0x1ef/0x210
  [   67.753276]  [] ? tty_get_pgrp+0x40/0x40
  [   67.753278]  [] __vmalloc_node+0x66/0x70
  [   67.753280]  [] ? n_tty_open+0x16/0xc0
  [   67.753283]  [] vmalloc+0x38/0x40
  [   67.753284]  [] ? n_tty_open+0x16/0xc0
  [   67.753290]  [] n_tty_open+0x16/0xc0
  [   67.753293]  [] tty_ldisc_open.isra.2+0x28/0x60
  [   67.753295]  [] tty_ldisc_setup+0x1c/0x70
  [   67.753297]  [] tty_init_dev+0x7c/0x180
  [   67.753301]  [] ? devpts_new_index+0xf1/0x120
  [   67.753303]  [] ptmx_open+0x75/0x160
  [   67.753306]  [] chrdev_open+0xa4/0x180
  [   67.753310]  [] do_dentry_open+0x1ec/0x300
  [   67.753312]  [] ? cdev_put+0x20/0x20
  [   67.753314]  [] vfs_open+0x4f/0x60
  [   67.753316]  [] path_openat+0x509/0x1140
  [   67.753318]  [] ? putname+0x54/0x60
  [   67.753321]  [] do_filp_open+0x68/0xe0
  [   67.753324]  [] ? __alloc_fd+0x36/0x150
  [   67.753326]  [] do_sys_open+0x128/0x2b0
  [   67.753329]  [] SyS_open+0x22/0x30
  [   67.753332]  [] do_fast_syscall_32+0x8d/0x150
  [   67.753336]  [] sysenter_past_esp+0x3d/0x61
  [   67.753338] Mem-Info:
  [   67.753342] active_anon:5790 inactive_anon:1203 isolated_anon:0
  active_file:30258 inactive_file:14843 isolated_file:0
  unevictable:856 dirty:46 writeback:0 unstable:0
  slab_reclaimable:4643 slab_unreclaimable:5952
  mapped:5271 shmem:1380 pagetables:193 bounce:0
  free:166082 free_pcp:1176 free_cma:0
  [   67.753349] DMA free:9616kB min:788kB low:984kB high:1180kB 
active_anon:288kB inactive_anon:112kB active_file:2436kB inactive_file:1216kB 
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB 
managed:15916kB mlocked:0kB dirty:4kB writeback:0kB mapped:396kB shmem:108kB 
slab_reclaimable:268kB slab_unreclaimable:428kB kernel_stack:24kB 
pagetables:8kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
  [   67.753350] lowmem_reserve[]: 0 818 949 949
  [   67.753357] Normal free:567248kB min:41608kB low:52008kB high:62412kB 
active_anon:18440kB inactive_anon:2992kB active_file:101312kB 
inactive_file:47608kB unevictable:3164kB isolated(anon):0kB isolated(file):0kB 
present:897016kB managed:872588kB mlocked:3164kB dirty:180kB writeback:0kB 
mapped:16216kB shmem:3620kB slab_reclaimable:18304kB slab_unreclaimable:23380kB 
kernel_stack:1568kB pagetables:688kB unstable:0kB bounce:0kB free_pcp:373

[Kernel-packages] [Bug 1498667] Re: [Toshiba P50W-B00F] Touchscreen no longer working

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  [Toshiba P50W-B00F] Touchscreen no longer working

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  Sometime in the last month or so my touchscreen stopped working on my
  Toshiba P50W. The dmesg log shows it constantly reconnecting to it:

  [  556.407964] usb 1-4: new full-speed USB device number 119 using xhci_hcd
  [  556.538341] usb 1-4: New USB device found, idVendor=04f3, idProduct=0381
  [  556.538347] usb 1-4: New USB device strings: Mfr=4, Product=14, 
SerialNumber=0
  [  556.538349] usb 1-4: Product: Touchscreen
  [  556.538351] usb 1-4: Manufacturer: ELAN
  [  556.538505] usb 1-4: ep 0x2 - rounding interval to 64 microframes, ep desc 
says 80 microframes
  [  556.547788] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:04F3:0381.04A1/input/input2374
  [  556.600478] hid-multitouch 0003:04F3:0381.04A1: input,hiddev0,hidraw4: USB 
HID v1.10 Device [ELAN Touchscreen] on usb-:00:14.0-4/input0
  [  556.600584] usb 1-4: USB disconnect, device number 119

  [  556.860456] usb 1-4: new full-speed USB device number 120 using xhci_hcd
  [  556.990494] usb 1-4: New USB device found, idVendor=04f3, idProduct=0381
  [  556.990500] usb 1-4: New USB device strings: Mfr=4, Product=14, 
SerialNumber=0
  [  556.990503] usb 1-4: Product: Touchscreen
  [  556.990506] usb 1-4: Manufacturer: ELAN
  [  556.990755] usb 1-4: ep 0x2 - rounding interval to 64 microframes, ep desc 
says 80 microframes
  [  557.001248] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:04F3:0381.04A2/input/input2376
  [  557.002517] hid-multitouch 0003:04F3:0381.04A2: input,hiddev0,hidraw4: USB 
HID v1.10 Device [ELAN Touchscreen] on usb-:00:14.0-4/input0
  [  557.013831] usb 1-4: USB disconnect, device number 120

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: linux-image-4.2.0-11-generic 4.2.0-11.13
  ProcVersionSignature: Ubuntu 4.2.0-11.13-generic 4.2.1
  Uname: Linux 4.2.0-11-generic x86_64
  ApportVersion: 2.18.1-0ubuntu1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  bob2041 F pulseaudio
   /dev/snd/controlC0:  bob2041 F pulseaudio
  CurrentDesktop: Unity
  Date: Wed Sep 23 09:46:25 2015
  HibernationDevice: RESUME=UUID=5033984a-21af-482d-a1fd-c075e818cd12
  InstallationDate: Installed on 2013-12-26 (635 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 
(20131016.1)
  MachineType: TOSHIBA Satellite P50W-B
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-11-generic 
root=UUID=885f0f10-b818-4eb4-8ff4-d067e16bef2f ro quiet splash nomdmonddf 
nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw 
vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.2.0-11-generic N/A
   linux-backports-modules-4.2.0-11-generic  N/A
   linux-firmware1.148
  SourcePackage: linux
  UpgradeStatus: Upgraded to wily on 2013-12-26 (635 days ago)
  dmi.bios.date: 08/08/2014
  dmi.bios.vendor: INSYDE Corp.
  dmi.bios.version: 1.40
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: Type2 - Board Product Name1
  dmi.board.vendor: Type2 - Board Vendor Name1
  dmi.board.version: Type2 - Board Version
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: OEM Chassis ManuFacturer
  dmi.chassis.version: OEM Chassis Version
  dmi.modalias: 
dmi:bvnINSYDECorp.:bvr1.40:bd08/08/2014:svnTOSHIBA:pnSatelliteP50W-B:pvrPSVP2A-00F002:rvnType2-BoardVendorName1:rnType2-BoardProductName1:rvrType2-BoardVersion:cvnOEMChassisManuFacturer:ct10:cvrOEMChassisVersion:
  dmi.product.name: Satellite P50W-B
  dmi.product.version: PSVP2A-00F002
  dmi.sys.vendor: TOSHIBA

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1498667/+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.launchp

[Kernel-packages] [Bug 1597573] Re: Network installer fails to detect network on AMD Overdrive (ARM64)

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  Network installer fails to detect network on AMD Overdrive (ARM64)

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

Bug description:
  Kernel: 4.4.0-21.37 (xenial)

  Installer fails to detect the XGBE network interface on AMD Overdrive,
  making it impossible to proceed with the network installer.

  Checking the kernel udeb modules, we're missing amd-xgbe as part of
  nic-modules.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597573/+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 1599068] Re: Add support for Intel 8265 Bluetooth ([8087:0A2B])

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  Add support for Intel 8265 Bluetooth ([8087:0A2B])

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  Backport supports for Intel 8265 Bluetooth from upstream

  The support is introduced in v4.7 so yakkety doesn't need this
  backport

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1599068/+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 1602579] Re: the system hangs in the dma driver when reboot or shutdown on a baytrail-m laptop

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  the system hangs in the dma driver when reboot or shutdown on a
  baytrail-m laptop

Status in HWE Next:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  1. System got hang on reboot of installation phase 1;
  2. Power off system by long-press power button, then power on system again.
  3. System got hang on power off of installation phase 2.

  The hang issue blocked the installation. Can not finish the
  installation procession.

  This bug is for tracking purposes; please do not triage.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1602579/+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 1583357] Re: [Hyper-V] Rebase Hyper-V to 4.6 kernel

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  [Hyper-V] Rebase Hyper-V to 4.6 kernel

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  Please rebase Hyper-V support to the final v4.6 upstream kernel.

  The following files comprise Hyper-V support in the upstream kernel:
  arch/x86/kernel/cpu/mshyperv.c
  arch/x86/include/asm/mshyperv.h
  arch/x86/include/uapi/asm/hyperv.h
  include/linux/hyperv.h
  drivers/hv/channel.c
  drivers/hv/channel_mgmt.c
  drivers/hv/connection.c
  drivers/hv/hv_balloon.c
  drivers/hv/hv.c
  drivers/hv/hv_fcopy.c
  drivers/hv/hv_kvp.c
  drivers/hv/hv_snapshot.c
  drivers/hv/hv_util.c
  drivers/hv/hv_utils_transport.c
  drivers/hv/hv_utils_transport.h
  drivers/hv/hyperv_vmbus.h
  drivers/hv/ring_buffer.c
  drivers/hv/vmbus_drv.c
  tools/hv/hv_fcopy_daemon.c
  tools/hv/hv_get_dhcp_info.sh
  tools/hv/hv_get_dns_info.sh
  tools/hv/hv_kvp_daemon.c
  tools/hv/hv_set_ifconfig.sh
  tools/hv/hv_vss_daemon.c
  tools/hv/lsvmbus
  drivers/input/serio/hyperv-keyboard.c
  drivers/net/hyperv/hyperv_net.h
  drivers/net/hyperv/netvsc.c
  drivers/net/hyperv/netvsc_drv.c
  drivers/net/hyperv/rndis_filter.c
  drivers/scsi/storvsc_drv.c
  drivers/hid/hid-hyperv.c
  drivers/pci/host/pci-hyperv.c
  drivers/video/fbdev/hyperv_fb.c

  While I know a number of post-4.4 commits are already committed, I am
  including all of the commits from 4.4 to 4.6 for reference:

  mshyperv.c : commit 1e2ae9ec072f3b7887f456426bc2cf23b80f661a : 
x86/hyperv: Avoid reporting bogus NMI status for Gen2 instances
  mshyperv.c : commit 1b74dde7c47c19a73ea3e9fac95ac27b5d3d50c5 : x86/cpu: 
Convert printk(KERN_ ...) to pr_(...)
  hyperv.h : commit 45870a441361d1c05a5f767c4ece2f6e30e0da9c : Drivers: hv: 
ring_buffer: remove stray smp_read_barrier_depends()
  hyperv.h : commit e8d6ca023efce3bd80050dcd9e708ee3cf8babd4 : Drivers: hv: 
vmbus: define the new offer type for Hyper-V socket (hvsock)
  hyperv.h : commit 5c23a1a5c60b0f472cfa61cd7d8279f8aaeb5b64 : Drivers: hv: 
vmbus: define a new VMBus message type for hvsock
  hyperv.h : commit 499e8401a515d04daa986b995da710d2b9737764 : Drivers: hv: 
vmbus: add a per-channel rescind callback
  hyperv.h : commit 3c75354d043ad546148d6992e40033ecaefc5ea5 : Drivers: hv: 
vmbus: add a helper function to set a channel's pending send size
  hyperv.h : commit 8981da320a11217589aa3c50f9e891bcdef07ece : Drivers: hv: 
vmbus: add a hvsock flag in struct hv_driver
  hyperv.h : commit b9830d120cbe155863399f25eaef6aa8353e767f : Drivers: hv: 
util: Pass the channel information during the init call
  channel.c : commit 63d55b2aeb5e4faa170316fee73c3c47ea9268c7 : Drivers: 
hv: vmbus: serialize process_chn_event() and vmbus_close_internal()
  channel.c : commit 5c23a1a5c60b0f472cfa61cd7d8279f8aaeb5b64 : Drivers: 
hv: vmbus: define a new VMBus message type for hvsock
  channel.c : commit fe760e4d64fe5c17c39e86c410d41f6587ee88bc : Drivers: 
hv: vmbus: Give control over how the ring access is serialized
  channel.c : commit 8599846d73997cdbccf63f23394d871cfad1e5e6 : Drivers: 
hv: vmbus: Fix a Host signaling bug
  channel_mgmt.c : commit fe760e4d64fe5c17c39e86c410d41f6587ee88bc : 
Drivers: hv: vmbus: Give control over how the ring access is serialized
  channel_mgmt.c : commit 79fd8e706637a5c7c41f9498fe0fbfb437abfdc8 : 
Drivers: hv: vmbus: avoid infinite loop in init_vp_index()
  channel_mgmt.c : commit 75ff3a8a9168df750b5bd0589e897a6c0517a9f1 : 
Drivers: hv: vmbus: avoid wait_for_completion() on crash
  channel_mgmt.c : commit 5c23a1a5c60b0f472cfa61cd7d8279f8aaeb5b64 : 
Drivers: hv: vmbus: define a new VMBus message type for hvsock
  connection.c : commit d6f591e339d23f434efda11917da511870891472 : Drivers: 
hv: vmbus: channge vmbus_connection.channel_lock to mutex
  connection.c : commit 75ff3a8a9168df750b5bd0589e897a6c0517a9f1 : Drivers: 
hv: vmbus: avoid wait_for_completion() on crash
  connection.c : commit 1b807e1011af46a595ba46c75ad5e20ad7177af7 : Drivers: 
hv: vmbus: Cleanup vmbus_set_event()
  hv.c : commit a108393dbf764efb2405f21ca759806c65b8bc16 : drivers:hv: 
Export the API to invoke a hypercall on Hyper-V
  hv.c : commit c35b82ef0294ae5052120615f5cfcef17c5a6bf7 : drivers/hv: 
corr

[Kernel-packages] [Bug 1603483] Re: [Xenial] Include Huawei PCIe SSD hio kernel driver

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  [Xenial] Include Huawei PCIe SSD hio kernel driver

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  == SRU Justification ==
  Huawei servers, including Huawei PCIe SSD's require the hio driver which is 
currently not included in our kernels.  We would like to carry this driver in 
our kernels for Xenial and newer in order to support platforms with these 
drives.

  == Source ==
  
http://support.huawei.com/enterprisesearch/ebgSearch#sp.keyword=HUAWEI%20ES3000%20V2%20Driver%20SRC

  == Testing ==
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1603483/+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 1597574] Re: Config: missing AMD Seattle platform support

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  Config: missing AMD Seattle platform support

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

Bug description:
  Kernel: 4.4.0-28.47

  debian.master/config/config.common.ubuntu: # CONFIG_ARCH_SEATTLE is
  not set

  The AMD Seattle SoC is used by the AMD Overdrive board and LeMaker
  Cello.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597574/+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 1599379] Re: Baytrail-I got black screen with HDMI output

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  Baytrail-I got black screen with HDMI output

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  This issue happens with 4.0+ kernels. Bisecting shows following commit
  cause the issue:

  commit d2182a660808d9053a605e3ebc8c46a323ec6e5d
  Author: Ville Syrjälä 
  Date: Fri Jan 9 14:21:14 2015 +0200

  drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHV

  The issue has been reported to upstream [1] and the fix has been
  merged.

  Although the commit fff7660 fixes the issue, it still misses to probe
  HDMI port in some circumstance, therefore there's another commit
  (already merged):

  commit a5aac5ab876ad95b7f5e8d862afb07248ee9cae2
  Author: Ville Syrjälä 
  CommitDate: Fri Jun 10 10:40:54 2016 +0300

  drm/i915: Check VBT for port presence in addition to the strap on
  VLV/CHV

  [1]: https://bugs.freedesktop.org/show_bug.cgi?id=96288

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1599379/+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 1597971] Re: kernel: signal return with invalid floating-point control

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  kernel: signal return with invalid floating-point control

Status in Linux:
  New
Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  Please backport:
  commit bcf4dd5f9ee096bd1510f838dd4750c35df4e38b
  Author: Martin Schwidefsky 
  Date:   Mon Jun 27 17:06:45 2016 +0200

  s390: fix test_fp_ctl inline assembly contraints
  
  The test_fp_ctl function is used to test if a given value is a valid
  floating-point control. The inline assembly in test_fp_ctl uses an
  incorrect constraint for the 'orig_fpc' variable. If the compiler
  chooses the same register for 'fpc' and 'orig_fpc' the test_fp_ctl()
  function always returns true. This allows user space to trigger
  kernel oopses with invalid floating-point control values on the
  signal stack.
  
  This problem has been introduced with git commit 4725c86055f5bbdcdf
  "s390: fix save and restore of the floating-point-control register"
  
  Cc: sta...@vger.kernel.org # v3.13+
  Reviewed-by: Heiko Carstens 
  Signed-off-by: Martin Schwidefsky 

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1597971/+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 1604344] Re: changelog: add CVEs as first class citizens

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-vivid

** Tags added: verification-needed-xenial

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

Title:
  changelog: add CVEs as first class citizens

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Precise:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  We no longer use bugs routinely for CVEs so pull the CVE number up as
  a bug number rather than letting the fixes all fall into misc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1604344/+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 1597867] Re: thunderx nics fail to establish link

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  thunderx nics fail to establish link

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  When connected to certain switches, Cavium ThunderX nodes will occasionally 
fail to establish a link. On one setup (using a Cisco 10G switch), we're seeing 
a failure rate of about 20%.

  Manually reloading the driver modules - or rebooting - is required to
  recover.

  A fix is now available in linux-next that greatly reduces (though it
  doesn't 100% eliminate) the frequency of occurrences (2% vs. 20%, in
  my case). Investigation continues to identify a resolution for the
  remaining cases.

  [Test Case]
  Connect Cavium ThunderX systems to a known bad switch, and put them in a 
reboot loop. In my test, I use the maas cli to release/acquire/deploy systems, 
and wait for a node to enter the deployment failure state.

  [Regression Risk]
  The fix is upstream, and internal to a specific driver only used on Cavium 
ThunderX systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597867/+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 1590655] Re: [Hyper-V] storvsc messages for CD-ROM medium not present tray closed

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  [Hyper-V] storvsc messages for CD-ROM medium not present tray closed

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  In Progress
Status in linux source package in Vivid:
  Won't Fix
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  The below can be seen with any distribution running on a Generation 2
  VM.

  There is a verified patch for this, however it has been scheduled only for 
the 4.8 scsi-queue.
  As it a small patch which has been verified by KY and also accepted in the 
patch queue, will you be able to include this as part of the 16.04 rebase to 
4.6, and as well for 14.04 and 15.10?

  Patch can be found at https://patchwork.kernel.org/patch/9131929/

  Description of problem:
  When starting and shutting down a Gen2 VM, at least 20-30 messages are 
recorded for storvsc with the below sample:
  [storvsc] Sense Key : Not Ready [current]
  [storvsc] Add. Sense: Medium not present - tray closed

  Steps to Reproduce:
  1. create a Generation2 VM
  2. start VM and observe the system logs
  3. multiple messages for the cd-rom are recorded from storvsc

  Actual results:
  even without a CD-ROM unit attached, the messages would appear.
  Having an ISO attached or not would still produce the same messages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1590655/+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 1599109] Re: [i915_bpo] Rebase driver to v4.7-rc6 + gen9 workarounds + KBP PCH support

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  [i915_bpo] Rebase driver to v4.7-rc6 + gen9 workarounds + KBP PCH
  support

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  i915_bpo driver should sync with v4.7-rc6 to better support
  SKL/KBL/BXT:

  - KBL enabled upstream, meaning v4.7 is first release they add fixes to
  - display power well support on BXT
  - fixes issues on certain machines not resuming properly from S3

  in addition to that, backport gen9 workarounds from drm-intel-next-
  queued:

  d1b4eefdea6d63a drm/i915/gen9: Add WaFbcHighMemBwCorruptionAvoidance
  031cd8c85aefad3 drm/i195/fbc: Add WaFbcNukeOnHostModify
  303d4ea522e8672 drm/i915/gen9: Add WaFbcWakeMemOn
  0f78dee6f06a939 drm/i915/gen9: Add WaFbcTurnOffFbcWatermark
  066d462888514af drm/i915/kbl: Add WaClearSlmSpaceAtContextSwitch
  71dce58c8e90872 drm/i915/skl: Extend WaDisableChickenBitTSGBarrierAckFor
  590e8ff04bc0182 drm/i915/gen9: Add WaEnableChickenDCPR
  954337aa96a31f6 drm/i915/kbl: Add WaDisableSbeCacheDispatchPortSharing
  4de5d7ccbccc88d drm/i915/kbl: Add WaDisableGafsUnitClkGating
  0b2d0934edceff9 drm/i915/kbl: Add WaForGAMHang
  44fff99ff25f1dd drm/i915/skl: Add WAC6entrylatency
  6fc29133eafb9eb drm/i915/gen9: Add WaDisableSkipCaching
  ad2bdb44b19529b drm/i915: Add WaInsertDummyPushConstP for bxt and kbl
  c0b730d572ea00d drm/i915/kbl: Add WaDisableDynamicCreditSharing
  8aeb7f624fbf8a6 drm/i915/kbl: Add WaDisableGamClockGating
  b033bb6d5d3a0e5 drm/i915/gen9: Enable must set chicken bits in config0 reg
  fe90581987cd5fa drm/i915/kbl: Add WaDisableLSQCROPERFforOCL
  17e0adf079a3bf2 drm/i915/edp: Add WaKVMNotificationOnConfigChange:bdw
  9498dba7b4ffe40 drm/i915/kbl: Add WaDisableSDEUnitClockGating
  8401d42fd5adf70 drm/i915/kbl: Add WaDisableFenceDestinationToSLM for A0
  e587f6cb0af140f drm/i915/kbl: Add WaEnableGapsTsvCreditFix
  bbaefe72a00c93c drm/i915: Mimic skl with WaForceEnableNonCoherent
  5b0e3659296cc4a drm/i915/gen9: Always apply WaForceContextSaveRestoreNonCohe
  6e4f10c33a8bd0d drm/i915/kbl: Add WaSkipStolenMemoryFirstPage for A0
  c033a37cd42c1b5 drm/i915/kbl: Add REVID macro
  e5f81d65ac5a040 drm/i915/kbl: Init gen9 workarounds
  eee8efb02a0f928 drm/i915/skl: Add WaDisableGafsUnitClkGating
  6bb6285582e0cf9 drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateCl

  and another fix to support Kabypoint PCH (fixes blank screen issues on
  such hw):

  22dea0be50b2eb0 drm/i915: Introduce Kabypoint PCH for Kabylake H/DT.

  We should also revert a commit that causes flickering on at least one
  Skylake laptop model, until it's properly fixed:

  https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599109/+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 1604344] Re: changelog: add CVEs as first class citizens

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!

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

Title:
  changelog: add CVEs as first class citizens

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Precise:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  We no longer use bugs routinely for CVEs so pull the CVE number up as
  a bug number rather than letting the fixes all fall into misc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1604344/+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 1597564] Re: the kernel hangs when reboot or shutdown on a lenovo baytrail-m based machine

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-vivid

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

Title:
  the kernel hangs when reboot or shutdown on a lenovo baytrail-m based
  machine

Status in HWE Next:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed

Bug description:
  1. System got hang on reboot of installation phase 1;
  2. Power off system by long-press power button, then power on system again.
  3. System got hang on power off of installation phase 2.

  The hang issue blocked the installation. Can not finish the
  installation procession.

  This bug is for tracking purposes; please do not triage.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1597564/+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 1555338] Re: Linux netfilter IPT_SO_SET_REPLACE memory corruption

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
precise' to 'verification-done-precise'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-precise

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

Title:
  Linux netfilter IPT_SO_SET_REPLACE memory corruption

Status in linux package in Ubuntu:
  Fix Released
Status in linux-armadaxp package in Ubuntu:
  Invalid
Status in linux-flo package in Ubuntu:
  New
Status in linux-goldfish package in Ubuntu:
  New
Status in linux-keystone package in Ubuntu:
  Invalid
Status in linux-lts-quantal package in Ubuntu:
  Invalid
Status in linux-lts-raring package in Ubuntu:
  Invalid
Status in linux-lts-saucy package in Ubuntu:
  Invalid
Status in linux-lts-trusty package in Ubuntu:
  Invalid
Status in linux-lts-utopic package in Ubuntu:
  Invalid
Status in linux-lts-vivid package in Ubuntu:
  Invalid
Status in linux-lts-wily package in Ubuntu:
  Invalid
Status in linux-lts-xenial package in Ubuntu:
  Invalid
Status in linux-mako package in Ubuntu:
  New
Status in linux-manta package in Ubuntu:
  Invalid
Status in linux-raspi2 package in Ubuntu:
  Fix Released
Status in linux-snapdragon package in Ubuntu:
  Fix Released
Status in linux-ti-omap4 package in Ubuntu:
  Invalid
Status in linux source package in Precise:
  Fix Released
Status in linux-armadaxp source package in Precise:
  Fix Released
Status in linux-flo source package in Precise:
  Invalid
Status in linux-goldfish source package in Precise:
  Invalid
Status in linux-keystone source package in Precise:
  Invalid
Status in linux-lts-quantal source package in Precise:
  Invalid
Status in linux-lts-raring source package in Precise:
  Invalid
Status in linux-lts-saucy source package in Precise:
  Invalid
Status in linux-lts-trusty source package in Precise:
  Fix Released
Status in linux-lts-utopic source package in Precise:
  Invalid
Status in linux-lts-vivid source package in Precise:
  Invalid
Status in linux-lts-wily source package in Precise:
  Invalid
Status in linux-lts-xenial source package in Precise:
  Invalid
Status in linux-mako source package in Precise:
  Invalid
Status in linux-manta source package in Precise:
  Invalid
Status in linux-raspi2 source package in Precise:
  Invalid
Status in linux-snapdragon source package in Precise:
  Invalid
Status in linux-ti-omap4 source package in Precise:
  Fix Released
Status in linux source package in Trusty:
  Fix Released
Status in linux-armadaxp source package in Trusty:
  Invalid
Status in linux-flo source package in Trusty:
  Invalid
Status in linux-goldfish source package in Trusty:
  Invalid
Status in linux-keystone source package in Trusty:
  Fix Released
Status in linux-lts-quantal source package in Trusty:
  Invalid
Status in linux-lts-raring source package in Trusty:
  Invalid
Status in linux-lts-saucy source package in Trusty:
  Invalid
Status in linux-lts-trusty source package in Trusty:
  Invalid
Status in linux-lts-utopic source package in Trusty:
  Fix Released
Status in linux-lts-vivid source package in Trusty:
  Fix Released
Status in linux-lts-wily source package in Trusty:
  Fix Released
Status in linux-lts-xenial source package in Trusty:
  Fix Released
Status in linux-mako source package in Trusty:
  Invalid
Status in linux-manta source package in Trusty:
  Invalid
Status in linux-raspi2 source package in Trusty:
  Invalid
Status in linux-snapdragon source package in Trusty:
  Invalid
Status in linux-ti-omap4 source package in Trusty:
  Invalid
Status in linux source package in Vivid:
  Fix Released
Status in linux-armadaxp source package in Vivid:
  Invalid
Status in linux-flo source package in Vivid:
  New
Status in linux-goldfish source package in Vivid:
  New
Status in linux-keystone source package in Vivid:
  Invalid
Status in linux-lts-quantal source package in Vivid:
  New
Status in linux-lts-raring source package in Vivid:
  New
Status in linux-lts-saucy source package in Vivid:
  New
Status in linux-lts-trusty source package in Vivid:
  New
Status in linux-lts-utopic source package in Vivid:
  Invalid
Status in linux-lts-vivid source package in Vivid:
  New
Status in linux-lts-wily source package in Vivid:
  New
Status in linux-lts-xenial source package in Vivid:
  New
Status in linux-mako source package in Vivid:
  New
Status in linux-manta source package in Vivid:
  New
Status in linux-raspi2 source package in Vivid:
  New
Status in linux-snapdragon source package in Vivid:
  New
Status in linux-ti-omap4 source package

[Kernel-packages] [Bug 1586418] Re: exercising ptys causes a kernel oops

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!

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

Title:
  exercising ptys causes a kernel oops

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  [SRU JUSTIFICATION][TRUSTY][WILY][XENIAL]

  Running stress-ng --pty 1 with a very low vmalloc memory available can
  trip an oops.  This can be generally only be reproduced when memory is
  under a high amount of pressure.  I was able to reproduce reliably by
  forcefully injecting vmalloc to return NULL when the stress-ng pty was
  running.

  [FIX]
  Upstream commit 5353ed8deedee9e5acb9f896e9032158f5d998de ("devpts: fix null 
pointer dereference on failed memory allocation"). This needs backporting to 
Yakkey, Xenial, Wily and Trusty because of changes in variable names.

  [TEST]
  Forcefully inject vmalloc to return NULL when running the pty stressor. 
Without the fix, an oops can be tripped, with the fix, no issues occur.

  --

  running: "stress-ng --pty 1" and this occurs in less than 1 second:

  [   67.753230] alloc_vmap_area: 9 callbacks suppressed
  [   67.753233] vmap allocation for size 16384 failed: use vmalloc= to 
increase size.
  [   67.753235] vmalloc: allocation failure: 8844 bytes
  [   67.753237] stress-ng-pty: page allocation failure: order:0, mode:0x24000c2
  [   67.753240] CPU: 2 PID: 2150 Comm: stress-ng-pty Not tainted 
4.4.0-23-generic #41-Ubuntu
  [   67.753241] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
  [   67.753243]  c1abf967 0832d3cc 0286 f2497c8c c139fe1f c19ce22c 
0001 f2497cbc
  [   67.753248]  c1177396 c19cc624 f506b5f0  024000c2 f2497cd0 
c19ce22c f2497ca4
  [   67.753252]  0832d3cc 228c  f2497cec c11ad2ff 024000c2 
 c19ce22c
  [   67.753256] Call Trace:
  [   67.753264]  [] dump_stack+0x58/0x79
  [   67.753267]  [] warn_alloc_failed+0xd6/0x110
  [   67.753272]  [] __vmalloc_node_range+0x1ef/0x210
  [   67.753276]  [] ? tty_get_pgrp+0x40/0x40
  [   67.753278]  [] __vmalloc_node+0x66/0x70
  [   67.753280]  [] ? n_tty_open+0x16/0xc0
  [   67.753283]  [] vmalloc+0x38/0x40
  [   67.753284]  [] ? n_tty_open+0x16/0xc0
  [   67.753290]  [] n_tty_open+0x16/0xc0
  [   67.753293]  [] tty_ldisc_open.isra.2+0x28/0x60
  [   67.753295]  [] tty_ldisc_setup+0x1c/0x70
  [   67.753297]  [] tty_init_dev+0x7c/0x180
  [   67.753301]  [] ? devpts_new_index+0xf1/0x120
  [   67.753303]  [] ptmx_open+0x75/0x160
  [   67.753306]  [] chrdev_open+0xa4/0x180
  [   67.753310]  [] do_dentry_open+0x1ec/0x300
  [   67.753312]  [] ? cdev_put+0x20/0x20
  [   67.753314]  [] vfs_open+0x4f/0x60
  [   67.753316]  [] path_openat+0x509/0x1140
  [   67.753318]  [] ? putname+0x54/0x60
  [   67.753321]  [] do_filp_open+0x68/0xe0
  [   67.753324]  [] ? __alloc_fd+0x36/0x150
  [   67.753326]  [] do_sys_open+0x128/0x2b0
  [   67.753329]  [] SyS_open+0x22/0x30
  [   67.753332]  [] do_fast_syscall_32+0x8d/0x150
  [   67.753336]  [] sysenter_past_esp+0x3d/0x61
  [   67.753338] Mem-Info:
  [   67.753342] active_anon:5790 inactive_anon:1203 isolated_anon:0
  active_file:30258 inactive_file:14843 isolated_file:0
  unevictable:856 dirty:46 writeback:0 unstable:0
  slab_reclaimable:4643 slab_unreclaimable:5952
  mapped:5271 shmem:1380 pagetables:193 bounce:0
  free:166082 free_pcp:1176 free_cma:0
  [   67.753349] DMA free:9616kB min:788kB low:984kB high:1180kB 
active_anon:288kB inactive_anon:112kB active_file:2436kB inactive_file:1216kB 
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB 
managed:15916kB mlocked:0kB dirty:4kB writeback:0kB mapped:396kB shmem:108kB 
slab_reclaimable:268kB slab_unreclaimable:428kB kernel_stack:24kB 
pagetables:8kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
  [   67.753350] lowmem_reserve[]: 0 818 949 949
  [   67.753357] Normal free:567248kB min:41608kB low:52008kB high:62412kB 
active_anon:18440kB inactive_anon:2992kB active

[Kernel-packages] [Bug 1574102] Re: Regression (constant vibration of device) in xpad driver in Ubuntu 16.04

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  Regression (constant vibration of device) in xpad driver in Ubuntu
  16.04

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

Bug description:
  Since upgrading to 16.04, I cannot launch Saints Row 2 or 3 from Steam
  without constant vibration from my Xbox360 controller. The symptoms
  are the same as outlined in https://github.com/paroj/xpad/issues/27.
  (I believe that github user submits xpad patches to upstream.) If I
  compile the f23507b version from that git repo, the problem resolves.
  This was not an issue on 15.10.

  Fix commit:
  https://github.com/paroj/xpad/commit/ef9e5b156c4b0042a75897697a792e7b1c5fde4b

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-21-generic 4.4.0-21.37
  ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
  Uname: Linux 4.4.0-21-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_modeset nvidia
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  neil   2398 F pulseaudio
   /dev/snd/controlC2:  neil   2398 F pulseaudio
   /dev/snd/controlC0:  neil   2398 F pulseaudio
  CurrentDesktop: Unity
  Date: Sat Apr 23 20:48:46 2016
  InstallationDate: Installed on 2015-10-23 (183 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
  MachineType: MSI MS-7721
  ProcFB:

  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-21-generic 
root=UUID=a3f3cb16-7fb4-411c-9649-b40f12c5ff51 ro quiet splash
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-21-generic N/A
   linux-backports-modules-4.4.0-21-generic  N/A
   linux-firmware1.157
  RfKill:

  SourcePackage: linux
  UpgradeStatus: Upgraded to xenial on 2016-04-22 (1 days ago)
  dmi.bios.date: 12/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V30.6
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: A55M-E35 (MS-7721)
  dmi.board.vendor: MSI
  dmi.board.version: 6.0
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: MSI
  dmi.chassis.version: 6.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV30.6:bd12/15/2014:svnMSI:pnMS-7721:pvr6.0:rvnMSI:rnA55M-E35(MS-7721):rvr6.0:cvnMSI:ct3:cvr6.0:
  dmi.product.name: MS-7721
  dmi.product.version: 6.0
  dmi.sys.vendor: MSI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574102/+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 1595803] Re: [i915_bpo][SKL] Display core init/uninit updates

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-vivid

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

Title:
  [i915_bpo][SKL] Display core init/uninit updates

Status in HWE Next:
  In Progress
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Vivid:
  Fix Committed

Bug description:
  At the moment, our i915_bpo driver on Vivid (kernel version:
  Ubuntu-3.19.0-62.70) lacks certain patches which fix the display core
  init/uninit sequence esp. handling dmc firmware loading and runtime-
  pm. Following patches from v4.5-rc1 address these issues on SKL.

  * e8ca932 drm/i915: Extract a intel_power_well_enable() function
  * dcddab3 drm/i915: Extract a intel_power_well_disable() function
  * 0a9d2be drm/i915/skl: Making DC6 entry is the last call in suspend flow.
  * 18a04a7 drm/i915: Kill intel_runtime_pm_disable()
  * ebae38d drm/i915/gen9: csr_init after runtime pm enable
  * 01a6908 drm/i915: use correct power domain for csr loading
  * bffbcd9 drm/i915/gen9: Don't try to load garbage dmc firmware on resume
  * ca1283d drm/i915/skl: Removed assert for csr-fw-loading check during 
disabling dc6
  * 56fcfd6 drm/i915: fix the power well ID for always on wells
  * fc17f22 drm/i915: fix lookup_power_well for power wells without any domain
  * 2f693e2 drm/i915: Make turning on/off PW1 and Misc I/O part of the 
init/fini sequences

  These patches also fix OEM bug related to audio not working after
  suspend by close/open lid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1595803/+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 1599347] Re: [yakkety] d-i does not support (ehci_msm) Qualcomm On-Chip EHCI Host Controller

[Seth Forshee]

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

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  [yakkety] d-i does not support (ehci_msm) Qualcomm  On-Chip EHCI Host
  Controller

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

Bug description:
  D-I does not detect USB devices on servers that have On-Chip EHCI Host
  Controller (ehci_msm), as a results install to USB devices fail.
  Adding ehci-msm to d-i/modules/usb-modules fixes this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599347/+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 1599257] Re: sync spl 0.6.5.6-0ubuntu4 changes into Xenial kernel source

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  sync spl  0.6.5.6-0ubuntu4 changes into Xenial kernel source

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  [SRU JUSTIFICATION][XENIAL]

  Update spl to 0.6.5.6-0ubuntu4. Sync delta in spl to kernel.

  [FIX]

  Auto generated sync, addresses bugs:

  LP: #1599219 SRU: spl-linux: xenial: apply fix Fix do_div() types in 
condvar:timeout
  Upstream spl fix 2a552736b7fc2bcb810cc520abd2ff9e229a9904 ("Fix do_div() 
types in condvar:timeout"), https://github.com/zfsonlinux/spl.git

  LP: #1599221 SRU: spl-linux: backport dep8 adt fixes from Yakkety
  Since Xenial is an LTS, it makes sense to backport fixes to the adt 
testing that have landed in Yakkety in 0.6.5.7-0ubuntu4 and 0.6.5.7-0ubuntu3

  [REGRESSION POTENTIAL]
  Minimal, this delta just updates the spl splat test module (which is just 
used for regression testing), no core spl functionality is changed.  The sync 
also pulls in some redhat spec files that landed in spl since the last sync, 
this are not used either but are included by the automated sync scripts.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599257/+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 1548009] Re: ZFS pools should be automatically scrubbed

[Andy Whitcroft]

Hello Richard, or anyone else affected,

Accepted zfs-linux into xenial-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/zfs-
linux/0.6.5.6-0ubuntu11 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: zfs-linux (Ubuntu Xenial)
   Status: In Progress => Fix Committed

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

Title:
  ZFS pools should be automatically scrubbed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

  Xenial shipped with a cron job to automatically scrub ZFS pools, as
  desired by many users and as implemented by mdadm for traditional Linux
  software RAID.  Unfortunately, this cron job does not work, because it needs 
a PATH line for /sbin, where the zpool utility lives.

  Given the existence of the cron job and various discussions on IRC, etc.,
  users expect that scrubs are happening, when they are not.  This means ZFS
  is not pre-emptively checking for (and correcting) corruption. The odds of
  disk corruption are admittedly very low, but violating users' expectations
  of data safety, especially when they've gone out of their way to use a
  filesystem which touts data safety, is bad.

  [Test Case]

  $ truncate -s 1G test.img
  $ sudo zpool create test `pwd`/test.img
  $ sudo zpool status test

  $ sudo vi /etc/cron.d/zfsutils-linux
  Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes
  (modifying the date range if it's not currently the 8th through the 14th
  and the "-eq 0" check if it's not currently a Sunday).

  $ grep zfs /var/log/cron.log
  Verify in /var/log/cron.log that the job ran.

  $ sudo zpool status test

  Expected results:
scan: scrub repaired 0 in ... on 

  Actual results:
scan: none requested

  Then, add the PATH line, update the time rules in the cron job, and repeat
  the test. Now it will work.

  - OR -

  The best test case is to leave the cron job file untouched, install the
  patched package, wait for the second Sunday of the month, and verify with
  zpool status that a scrub ran.  I did this, on Xenial, with the package I
  built.  The debdiff is in comment #11 and was accepted to Yakkety.

  If someone can get this in -proposed before the 14th, I'll gladly install
  the actual package from -proposed and make sure it runs correctly on the
  14th.

  [Regression Potential]

  The patch only touches the cron.d file, which has only one cron job in it.
  This cron job is completely broken (inoperative) at the moment, so the
  regression potential is very low.


  
  ORIGINAL, PRE-SRU, DESCRIPTION:

  mdadm automatically checks MD arrays. ZFS should automatically scrub
  pools too. Scrubbing a pool allows ZFS to detect on-disk corruption
  and (when the pool has redundancy) correct it. Note that ZFS does not
  blindly assume the other copy is correct; it will only overwrite bad
  data with data that is known to be good (i.e. it passes the checksum).

  I've attached a debdiff which accomplishes this. It builds and
  installs cleanly.

  The meat of it is the scrub script I've been using on production
  systems, both servers and laptops, and recommending in my Ubuntu root-
  on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool
  is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot
  of disk load which could theoretically lead to another failure. We
  should save that disk load for resilvering. 2) Performance is already
  less on a degraded pool and scrubbing can make that worse, even though
  scrubs are throttled. Arguably, I might be being too conservative
  here, but the marginal benefit of scrubbing a *degraded* pool is
  pretty minimal as pools should not be left degraded for very long.

  The cron.d in this patch scrubs on the second Sunday of the month.
  mdadm scrubs on the first Sunday of the month. This way, if a system
  has both MD and ZFS pools, the load doesn't all happen at the same
  time. If the system doesn't have both types, it shouldn't really
  matter which

[Kernel-packages] [Bug 1586418] Re: exercising ptys causes a kernel oops

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-vivid

** Tags added: verification-needed-xenial

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

Title:
  exercising ptys causes a kernel oops

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  [SRU JUSTIFICATION][TRUSTY][WILY][XENIAL]

  Running stress-ng --pty 1 with a very low vmalloc memory available can
  trip an oops.  This can be generally only be reproduced when memory is
  under a high amount of pressure.  I was able to reproduce reliably by
  forcefully injecting vmalloc to return NULL when the stress-ng pty was
  running.

  [FIX]
  Upstream commit 5353ed8deedee9e5acb9f896e9032158f5d998de ("devpts: fix null 
pointer dereference on failed memory allocation"). This needs backporting to 
Yakkey, Xenial, Wily and Trusty because of changes in variable names.

  [TEST]
  Forcefully inject vmalloc to return NULL when running the pty stressor. 
Without the fix, an oops can be tripped, with the fix, no issues occur.

  --

  running: "stress-ng --pty 1" and this occurs in less than 1 second:

  [   67.753230] alloc_vmap_area: 9 callbacks suppressed
  [   67.753233] vmap allocation for size 16384 failed: use vmalloc= to 
increase size.
  [   67.753235] vmalloc: allocation failure: 8844 bytes
  [   67.753237] stress-ng-pty: page allocation failure: order:0, mode:0x24000c2
  [   67.753240] CPU: 2 PID: 2150 Comm: stress-ng-pty Not tainted 
4.4.0-23-generic #41-Ubuntu
  [   67.753241] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
  [   67.753243]  c1abf967 0832d3cc 0286 f2497c8c c139fe1f c19ce22c 
0001 f2497cbc
  [   67.753248]  c1177396 c19cc624 f506b5f0  024000c2 f2497cd0 
c19ce22c f2497ca4
  [   67.753252]  0832d3cc 228c  f2497cec c11ad2ff 024000c2 
 c19ce22c
  [   67.753256] Call Trace:
  [   67.753264]  [] dump_stack+0x58/0x79
  [   67.753267]  [] warn_alloc_failed+0xd6/0x110
  [   67.753272]  [] __vmalloc_node_range+0x1ef/0x210
  [   67.753276]  [] ? tty_get_pgrp+0x40/0x40
  [   67.753278]  [] __vmalloc_node+0x66/0x70
  [   67.753280]  [] ? n_tty_open+0x16/0xc0
  [   67.753283]  [] vmalloc+0x38/0x40
  [   67.753284]  [] ? n_tty_open+0x16/0xc0
  [   67.753290]  [] n_tty_open+0x16/0xc0
  [   67.753293]  [] tty_ldisc_open.isra.2+0x28/0x60
  [   67.753295]  [] tty_ldisc_setup+0x1c/0x70
  [   67.753297]  [] tty_init_dev+0x7c/0x180
  [   67.753301]  [] ? devpts_new_index+0xf1/0x120
  [   67.753303]  [] ptmx_open+0x75/0x160
  [   67.753306]  [] chrdev_open+0xa4/0x180
  [   67.753310]  [] do_dentry_open+0x1ec/0x300
  [   67.753312]  [] ? cdev_put+0x20/0x20
  [   67.753314]  [] vfs_open+0x4f/0x60
  [   67.753316]  [] path_openat+0x509/0x1140
  [   67.753318]  [] ? putname+0x54/0x60
  [   67.753321]  [] do_filp_open+0x68/0xe0
  [   67.753324]  [] ? __alloc_fd+0x36/0x150
  [   67.753326]  [] do_sys_open+0x128/0x2b0
  [   67.753329]  [] SyS_open+0x22/0x30
  [   67.753332]  [] do_fast_syscall_32+0x8d/0x150
  [   67.753336]  [] sysenter_past_esp+0x3d/0x61
  [   67.753338] Mem-Info:
  [   67.753342] active_anon:5790 inactive_anon:1203 isolated_anon:0
  active_file:30258 inactive_file:14843 isolated_file:0
  unevictable:856 dirty:46 writeback:0 unstable:0
  slab_reclaimable:4643 slab_unreclaimable:5952
  mapped:5271 shmem:1380 pagetables:193 bounce:0
  free:166082 free_pcp:1176 free_cma:0
  [   67.753349] DMA free:9616kB min:788kB low:984kB high:1180kB 
active_anon:288kB inactive_anon:112kB active_file:2436kB inactive_file:1216kB 
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB 
managed:15916kB mlocked:0kB dirty:4kB writeback:0kB mapped:396kB shmem:108kB 
slab_reclaimable:268kB slab_unreclaimable:428kB kernel_stack:24kB 
pagetables:8kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
  [   67.753350] lowmem_reserve[]: 0 818 949 949
  [   67.753357] Normal free:567248kB m

[Kernel-packages] [Bug 1583738] Re: arm64: statically link rtc-efi

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-vivid

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

Title:
  arm64: statically link rtc-efi

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  [Impact]
  The rtc-hctosys driver currently fails to set the system clock on arm64/efi 
platforms because rtc-efi is built as a module.

  [Test Case]
  if dmesg | grep -q 'rtc-efi: setting system clock'; then
PASS
  else
FAIL
  fi

  [Regression Risk]
  This is just a config change, and one that we used to ship in utopic and 
trusty w/ no known regressions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1583738/+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 1599250] Re: Hotplug device addition issue - missing patches on Xenial kernel

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  Hotplug device addition issue - missing patches on Xenial kernel

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

Bug description:
  == Comment: #0 - Guilherme Guaglianoni Piccoli - 2016-06-29 18:09:04 ==
  When performing hotplug device addition to LPAR/guest with Ubuntu 16.04 
(kernel 4.4.0-28) we can observe a kernel oops if device makes use of 64-bit 
DDW DMA. The following stack trace was observed with QLogic NIC (bnx2x driver):

  
  [  131.52] --- interrupt: 300 at enable_ddw+0x254/0x7c0
 LR = enable_ddw+0x238/0x7c0
  [  131.52] [c001fbc67480] [c0089b88] 
dma_set_mask_pSeriesLP+0x208/0x290
  [  131.52] [c001fbc67510] [c00246b8] dma_set_mask+0x58/0xf0
  [  131.52] [c001fbc67540] [d387a654] bnx2x_init_one+0x504/0x10f0 
[bnx2x]
  [  131.52] [c001fbc67620] [c05e4eac] local_pci_probe+0x6c/0x140
  [  131.52] [c001fbc676b0] [c05e5d58] pci_device_probe+0x168/0x200
  [  131.52] [c001fbc67710] [c06d2530] 
driver_probe_device+0x1f0/0x610
  [  131.52] [c001fbc677a0] [c06d2a6c] __driver_attach+0x11c/0x120
  [  131.52] [c001fbc677e0] [c06ceeac] bus_for_each_dev+0x9c/0x110
  [  131.52] [c001fbc67830] [c06d198c] driver_attach+0x3c/0x60
  [  131.52] [c001fbc67860] [c06d1278] bus_add_driver+0x2d8/0x390
  [  131.52] [c001fbc678f0] [c06d39dc] driver_register+0x9c/0x180
  [  131.52] [c001fbc67960] [c05e401c] 
__pci_register_driver+0x6c/0x90

  
  This issue is solved upstream, by the following 3 patches (SHA-1 from Linus 
tree):

  c2078d9ef60 ("Revert \"powerpc/eeh: Fix crash in eeh_add_device_early() on 
Cell\"")
  8445a87f709 ("powerpc/iommu: Remove the dependency on EEH struct in DDW 
mechanism")
  8a934efe943 ("powerpc/pseries: Fix PCI config address for DDW")

  
  So, we want to request the addition of these fixes in Ubuntu Xenial kernel.
  Besides, an old and obsolete non-upstream patch related to this issue can be 
removed (SHA-1 from Ubuntu xenial tree):

  623aabd5d68 ("UBUNTU: SAUCE: powerpc/eeh: Validate arch in
  eeh_add_device_early()")

  
  Thanks,

  Guilherme

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599250/+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 1599562] Re: linux: Homogenize changelog format across releases

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!

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

Title:
  linux: Homogenize changelog format across releases

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Precise:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  Kernel changelogs should have the same format across all releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599562/+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 1603975] Re: thinkpad yoga 260 wacom touchscreen not working

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  thinkpad yoga 260 wacom touchscreen not working

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  Users of Lenovo Thinkpad Yoga 260 laptops can't use the touchscreen if it has 
been deactivated from Windows beforehand.

  [Fix]
  d4a9689 HID: wacom: Support switching from vendor-defined device mode on G9 
and G11
  967143a HID: wacom: Initialize hid_data.inputmode to -1
  b107ac0 HID: wacom: break out parsing of device and registering of input

  
  d4a9689 is the actual fix and the two others make this a clean cherry-pick.

  [Test Case]
  On a Lenovo Thinkpad Yoga 260, try using the touchscreen.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-31-generic 4.4.0-31.50
  ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
  Uname: Linux 4.4.0-31-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  arges  2392 F pulseaudio
  CurrentDesktop: Unity
  Date: Mon Jul 18 07:20:48 2016
  HibernationDevice: RESUME=UUID=0e49e62b-8bc0-48ef-8e7c-bcce9770d74b
  InstallationDate: Installed on 2016-07-16 (1 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  MachineType: LENOVO 20FD0004US
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-31-generic.efi.signed 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-31-generic N/A
   linux-backports-modules-4.4.0-31-generic  N/A
   linux-firmware1.157.2
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/16/2015
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N1GET35W (1.12 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20FD0004US
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrN1GET35W(1.12):bd11/16/2015:svnLENOVO:pn20FD0004US:pvrThinkPadYoga260:rvnLENOVO:rn20FD0004US:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
  dmi.product.name: 20FD0004US
  dmi.product.version: ThinkPad Yoga 260
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1603975/+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 1599562] Re: linux: Homogenize changelog format across releases

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
precise' to 'verification-done-precise'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-precise

** Tags added: verification-needed-vivid

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

Title:
  linux: Homogenize changelog format across releases

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Precise:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Wily:
  Won't Fix
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  Kernel changelogs should have the same format across all releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599562/+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 1596871] Re: [Bug] Legacy audio couldn't work after S3 resume on Kabylake

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  [Bug] Legacy audio couldn't work after S3 resume on Kabylake

Status in intel:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  Issue: Legacy audio couldn't play sound after S3 resume.
  the following error message exist in S3 resume:
snd_hda_intel :00:14.3: azx_get_response timeout, switching to 
single_cmd mode: last cmd=0x206f2f00

  Backport the following commits from upstream kernel could fix this issue:
  eb399d3 ALSA: hda - Skip ELD notification during PM process
  ec75a94 ALSA: hda - hdmi add wmb barrier for audio component
  790b415 ALSA: hda - hdmi defer to register acomp eld notifier

  please backport these patches to 16.04 kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/intel/+bug/1596871/+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 1593124] Re: Add proper palm detection support for MS Precision Touchpad

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  Add proper  palm detection support for MS Precision Touchpad

Status in HWE Next:
  Confirmed
Status in HWE Next xenial series:
  Confirmed
Status in Linux:
  Unknown
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  Sometimes touchpad doesn't work properly after palm is rejected. The
  pointer either jumping around (described on bugzilla[1]) or doesn't
  move at all (in our cases).

  This problem is introduced with commit:
  25a84db15b3f3a24d3ea7d2baf90693bcff34b0c (HID: multitouch: enable palm
  rejection if device implements confidence usage), by reverting it the
  touchpad can work properly.

  We also contacted with Synaptics, and they provided a workaround to
  fix this issue. Not sure if the workaround will be upstreamed and
  needs to keep co-working with them.

  Commit 25a84db applies to Xenial and Yakkety so only these two release
  were affected.

  The maintainer has provided a patch set to fix this issue and add
  proper palm detection support and the patch set has been merged. We
  also need to introduce this feature to Vivid at OEM's demands.

  [1]: https://bugzilla.kernel.org/show_bug.cgi?id=112791

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1593124/+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 1603719] Re: [regression] NFS client: access problems after updating to kernel 4.4.0-31-generic

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  [regression] NFS client: access problems after updating to kernel
  4.4.0-31-generic

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  SRU Justification

  Impact: A regression in xenial causes automatic mounting of exported
  submounts of an nfs mount to fail.

  Fix: Change nfs to use sget_userns instead of sget, bypassing a
  capability check that is not necessary for nfs.

  Regression Potential: The behavior after the fix is functionally
  equivalent to upstream, so this is unlikely to cause regressions.

  ---

  I am denied access to the subfilesystems exported by my nfs server
  (the top level filesystem itself is unaffected).

  The client is reporting that I do not have the necessary permissions.
  However, all was fine until the day before yesterday.

  When I revert my client to 4.4.0-28, everything is in working order again. I 
assume the permission problem is really a bug in kernel 4.4.0-31.
  ---
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  jurgen 1743 F pulseaudio
  CurrentDesktop: Unity
  DistroRelease: Ubuntu 16.04
  HibernationDevice: RESUME=UUID=569da237-3a37-4fe3-b885-83213aae8b52
  InstallationDate: Installed on 2016-04-07 (101 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Beta amd64 (20160405)
  IwConfig:
   lono wireless extensions.

   enp4s0no wireless extensions.
  MachineType: MICRO-STAR INTERNATIONAL CO.,LTD MS-7514
  NonfreeKernelModules: nvidia
  Package: linux (not installed)
  ProcFB:

  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-31-generic 
root=UUID=f6f6bd51-4d4f-4547-b615-90319625d909 ro quiet splash
  ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-31-generic N/A
   linux-backports-modules-4.4.0-31-generic  N/A
   linux-firmware1.157.2
  RfKill:

  Tags:  xenial
  Uname: Linux 4.4.0-31-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 05/28/2008
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V1.1
  dmi.board.asset.tag: To Be Filled By O.E.M.
  dmi.board.name: MS-7514
  dmi.board.vendor: MICRO-STAR INTERNATIONAL CO.,LTD
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: MICRO-STAR INTERNATIONAL CO.,LTD
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV1.1:bd05/28/2008:svnMICRO-STARINTERNATIONALCO.,LTD:pnMS-7514:pvr1.0:rvnMICRO-STARINTERNATIONALCO.,LTD:rnMS-7514:rvr1.0:cvnMICRO-STARINTERNATIONALCO.,LTD:ct3:cvr1.0:
  dmi.product.name: MS-7514
  dmi.product.version: 1.0
  dmi.sys.vendor: MICRO-STAR INTERNATIONAL CO.,LTD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1603719/+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 1601831] Re: qeth: delete napi struct when removing a qeth device

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!

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

Title:
  qeth: delete napi struct when removing a qeth device

Status in Linux:
  New
Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Precise:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  == Comment: #0 - Hendrik Brueckner  - 2016-07-08 
10:59:08 ==
  Please backport:
  commit 7831b4ff0d926e0deeaabef9db8800ed069a2757
  Author: Ursula Braun 
  Date:   Mon Jul 4 14:07:16 2016 +0200

  qeth: delete napi struct when removing a qeth device
  
  A qeth_card contains a napi_struct linked to the net_device during
  device probing. This struct must be deleted when removing the qeth
  device, otherwise Panic on oops can occur when qeth devices are
  repeatedly removed and added.
  
  Fixes: a1c3ed4c9ca ("qeth: NAPI support for l2 and l3 discipline")
  Cc: sta...@vger.kernel.org # v2.6.37+
  Signed-off-by: Ursula Braun 
  Tested-by: Alexander Klein 
  Signed-off-by: David S. Miller 

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1601831/+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 1600124] Re: Adjust KBL PCI-ID's

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  Adjust KBL PCI-ID's

Status in libdrm package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in mesa package in Ubuntu:
  New
Status in xserver-xorg-video-intel package in Ubuntu:
  Fix Released
Status in libdrm source package in Xenial:
  New
Status in linux source package in Xenial:
  Fix Committed
Status in mesa source package in Xenial:
  New
Status in xserver-xorg-video-intel source package in Xenial:
  New

Bug description:
  Current list of KBL PCI-ID's is incomplete, there are a few that are
  should not be listed and few that are missing. To fix this, adjust the
  list in kernel/libdrm/mesa/ddx to match upstream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1600124/+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 1601831] Re: qeth: delete napi struct when removing a qeth device

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  qeth: delete napi struct when removing a qeth device

Status in Linux:
  New
Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Precise:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  == Comment: #0 - Hendrik Brueckner  - 2016-07-08 
10:59:08 ==
  Please backport:
  commit 7831b4ff0d926e0deeaabef9db8800ed069a2757
  Author: Ursula Braun 
  Date:   Mon Jul 4 14:07:16 2016 +0200

  qeth: delete napi struct when removing a qeth device
  
  A qeth_card contains a napi_struct linked to the net_device during
  device probing. This struct must be deleted when removing the qeth
  device, otherwise Panic on oops can occur when qeth devices are
  repeatedly removed and added.
  
  Fixes: a1c3ed4c9ca ("qeth: NAPI support for l2 and l3 discipline")
  Cc: sta...@vger.kernel.org # v2.6.37+
  Signed-off-by: Ursula Braun 
  Tested-by: Alexander Klein 
  Signed-off-by: David S. Miller 

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1601831/+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 1601831] Re: qeth: delete napi struct when removing a qeth device

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
precise' to 'verification-done-precise'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-precise

** Tags added: verification-needed-vivid

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

Title:
  qeth: delete napi struct when removing a qeth device

Status in Linux:
  New
Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Precise:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  == Comment: #0 - Hendrik Brueckner  - 2016-07-08 
10:59:08 ==
  Please backport:
  commit 7831b4ff0d926e0deeaabef9db8800ed069a2757
  Author: Ursula Braun 
  Date:   Mon Jul 4 14:07:16 2016 +0200

  qeth: delete napi struct when removing a qeth device
  
  A qeth_card contains a napi_struct linked to the net_device during
  device probing. This struct must be deleted when removing the qeth
  device, otherwise Panic on oops can occur when qeth devices are
  repeatedly removed and added.
  
  Fixes: a1c3ed4c9ca ("qeth: NAPI support for l2 and l3 discipline")
  Cc: sta...@vger.kernel.org # v2.6.37+
  Signed-off-by: Ursula Braun 
  Tested-by: Alexander Klein 
  Signed-off-by: David S. Miller 

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1601831/+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 1606147] Re: [APL][SAUCE] Slow system response time due to a monitor bug

[Seth Forshee]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

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

Title:
  [APL][SAUCE] Slow system response time due to a monitor bug

Status in HWE Next:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

  We've found a bug on some Apollo Lake system makes it runs very slow.
  From upstream it is caused by following reason:

  "Monitored cached line may not wake up from mwait on certain Goldmont
  based CPUs. This patch will avoid calling
  current_set_polling_and_test() and thereby not set the TIF_ flag. The
  result is that we'll always send IPIs for wakeups."

  [Fix]

  Upstream already provided a workaround[1] to fix this problem. This
  patches haven't been merged in latest(v4.7) release but already in
  linux-next.

  To fix this issue in Xenial it also needs another commit introduces
  macros use in the workaround:

  commit 970442c599b22ccd644ebfe94d1d303bf6f87c05
  Author: Dave Hansen 
  Date:   Thu Jun 2 17:19:27 2016 -0700

  x86/cpu/intel: Introduce macros for Intel family numbers

  This workaround checks CPU families and certain features, so no
  further regressions is expected

  [1]: https://lkml.org/lkml/2016/7/6/469

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1606147/+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 1548009] Re: ZFS pools should be automatically scrubbed

[Andy Whitcroft]

Ok, comparing this to other users of /etc/cron.d it does seem to be a
common idiom used there.  To update the path to exactly the above form.
So this is not making things any worse.  I am inclined to let this go on
that basis given it is already in yakkety.

/etc/cron.d/anacron:PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
/etc/cron.d/certbot:PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
/etc/cron.d/popularity-contest:PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin


** Changed in: zfs-linux (Ubuntu Xenial)
   Status: Incomplete => In Progress

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

Title:
  ZFS pools should be automatically scrubbed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

  Xenial shipped with a cron job to automatically scrub ZFS pools, as
  desired by many users and as implemented by mdadm for traditional Linux
  software RAID.  Unfortunately, this cron job does not work, because it needs 
a PATH line for /sbin, where the zpool utility lives.

  Given the existence of the cron job and various discussions on IRC, etc.,
  users expect that scrubs are happening, when they are not.  This means ZFS
  is not pre-emptively checking for (and correcting) corruption. The odds of
  disk corruption are admittedly very low, but violating users' expectations
  of data safety, especially when they've gone out of their way to use a
  filesystem which touts data safety, is bad.

  [Test Case]

  $ truncate -s 1G test.img
  $ sudo zpool create test `pwd`/test.img
  $ sudo zpool status test

  $ sudo vi /etc/cron.d/zfsutils-linux
  Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes
  (modifying the date range if it's not currently the 8th through the 14th
  and the "-eq 0" check if it's not currently a Sunday).

  $ grep zfs /var/log/cron.log
  Verify in /var/log/cron.log that the job ran.

  $ sudo zpool status test

  Expected results:
scan: scrub repaired 0 in ... on 

  Actual results:
scan: none requested

  Then, add the PATH line, update the time rules in the cron job, and repeat
  the test. Now it will work.

  - OR -

  The best test case is to leave the cron job file untouched, install the
  patched package, wait for the second Sunday of the month, and verify with
  zpool status that a scrub ran.  I did this, on Xenial, with the package I
  built.  The debdiff is in comment #11 and was accepted to Yakkety.

  If someone can get this in -proposed before the 14th, I'll gladly install
  the actual package from -proposed and make sure it runs correctly on the
  14th.

  [Regression Potential]

  The patch only touches the cron.d file, which has only one cron job in it.
  This cron job is completely broken (inoperative) at the moment, so the
  regression potential is very low.


  
  ORIGINAL, PRE-SRU, DESCRIPTION:

  mdadm automatically checks MD arrays. ZFS should automatically scrub
  pools too. Scrubbing a pool allows ZFS to detect on-disk corruption
  and (when the pool has redundancy) correct it. Note that ZFS does not
  blindly assume the other copy is correct; it will only overwrite bad
  data with data that is known to be good (i.e. it passes the checksum).

  I've attached a debdiff which accomplishes this. It builds and
  installs cleanly.

  The meat of it is the scrub script I've been using on production
  systems, both servers and laptops, and recommending in my Ubuntu root-
  on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool
  is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot
  of disk load which could theoretically lead to another failure. We
  should save that disk load for resilvering. 2) Performance is already
  less on a degraded pool and scrubbing can make that worse, even though
  scrubs are throttled. Arguably, I might be being too conservative
  here, but the marginal benefit of scrubbing a *degraded* pool is
  pretty minimal as pools should not be left degraded for very long.

  The cron.d in this patch scrubs on the second Sunday of the month.
  mdadm scrubs on the first Sunday of the month. This way, if a system
  has both MD and ZFS pools, the load doesn't all happen at the same
  time. If the system doesn't have both types, it shouldn't really
  matter which week. If you'd rather make it the same week as MD, I see
  no problem with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+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 1607355] Re: Task (usually mongod) blocked more 120 seconds (lock-ups) in juju on lxc/lxd + zfs

[Rafael David Tinoco]

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

** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Rafael David Tinoco (inaddy)

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

Title:
  Task (usually mongod) blocked more 120 seconds (lock-ups) in juju on
  lxc/lxd + zfs

Status in linux package in Ubuntu:
  In Progress

Bug description:
  I was able to reproduce this 2 or 3 times last 2 days. I have the
  following setup:

  Containers for Trusty/kilo service machines:

  inaddy@workstation:~$ lxc-ls  | grep tk
  tkcephmon01  RUNNING 0 -  192.168.65.52 -
  tkcephmon02  RUNNING 0 -  192.168.65.51 -
  tkcephmon03  RUNNING 0 -  192.168.65.48 -
  tkcinder RUNNING 0 -  192.168.65.49 -
  tkdash   RUNNING 0 -  192.168.65.50 -
  tkglance RUNNING 0 -  192.168.65.53 -
  tkjuju   RUNNING 0 -  192.168.65.15 -
  tkkeystone   RUNNING 0 -  192.168.65.54 -
  tkmysql  RUNNING 0 -  192.168.65.55 -
  tknova   RUNNING 0 -  192.168.65.56 -
  tkrabbit RUNNING 0 -  192.168.65.57 -
  tkswiftproxy RUNNING 0 -  192.168.65.58 -

  And compute nodes + neutrongw as kvm guests:

  inaddy@workstation:~$ virsh list --all | grep tk
   21tkcompute01running
   22tkcompute02running
   23tkcompute03running
   24tkneutrongwrunning

  All my LXC containers are on top of ZFS:

  Linux workstation 4.4.0-32-generic #51-Ubuntu SMP Tue Jul 19 18:09:07
  UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

  And my KVM guests are on top of ext4 + 1.2 raid0 stripped volume.

  I'm getting the lockups bellow (usually for mongod, from tkjuju
  container, the juju controller). After the first lockup appears
  (schedule timeout coming from zfs sync logic most likely), JuJu
  controller starts giving me errors on "update-status". From "juju
  status":

  glance/0error  idle1.25.6  10  9292/tcp   
tkglance   hook failed: "update-status"
  keystone/0  error  idle1.25.6  11 
tkkeystone hook failed: "update-status"
  mysql/0 error  idle1.25.6  12 
tkmysqlhook failed: "config-changed"
  neutron-api/0   error  idle1.25.6  4   9696/tcp   
tkneutrongwhook failed: "update-status"
  nova-compute/0  error  idle1.25.6  1  
tkcompute01hook failed: "update-status"
  nova-compute/1  error  idle1.25.6  2  
tkcompute02hook failed: "update-status"
  nova-compute/2  error  idle1.25.6  3  
tkcompute03hook failed: "update-status"

  Lockups:

  [105601.816578] INFO: task mongod:14480 blocked for more than 120 seconds.
  [105601.816583]   Tainted: P   O4.4.0-32-generic #51-Ubuntu
  [105601.816584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
  [105601.816586] mongod  D 88010ec47ba8 0 14480  16855 
0x0100
  [105601.816590]  88010ec47ba8 57992eeb 880108e5ee00 
880108e58dc0
  [105601.816592]  88010ec48000 88081ecd6d00 7fff 
8182a600
  [105601.816594]  88010ec47d08 88010ec47bc0 81829e05 

  [105601.816596] Call Trace:
  [105601.816603]  [] ? bit_wait+0x60/0x60
  [105601.816606]  [] schedule+0x35/0x80
  [105601.816608]  [] schedule_timeout+0x1b5/0x270
  [105601.816612]  [] ? find_get_pages_tag+0x109/0x190
  [105601.816614]  [] ? bit_wait+0x60/0x60
  [105601.816616]  [] io_schedule_timeout+0xa4/0x110
  [105601.816618]  [] bit_wait_io+0x1b/0x70
  [105601.816620]  [] __wait_on_bit+0x5d/0x90
  [105601.816622]  [] wait_on_page_bit+0xcb/0xf0
  [105601.816625]  [] ? autoremove_wake_function+0x40/0x40
  [105601.816628]  [] __filemap_fdatawait_range+0xf3/0x160
  [105601.816630]  [] filemap_fdatawait_range+0x14/0x30
  [105601.816632]  [] filemap_write_and_wait_range+0x3f/0x70
  [105601.816682]  [] zpl_fsync+0x38/0x90 [zfs]
  [105601.816685]  [] vfs_fsync_range+0x4b/0xb0
  [105601.816687]  [] SyS_msync+0x17e/0x1f0
  [105601.816689]  [] entry_SYSCALL_64_fastpath+0x16/0x71
  [117121.961545] INFO: task txg_sync:4589 blocked for more than 120 seconds.
  [117121.961549]   Tainted: P   O4.4.0-32-generic #51-Ubuntu
  [117121.961550] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
  [117121.96

[Kernel-packages] [Bug 1548009] Re: ZFS pools should be automatically scrubbed

[Michael Terry]

I get not wanting unnecessary PATHs...  But is /usr/local really
considered a security issue?  It's in /usr...

It's part of the standard PATH for the root user.  And if an admin has
installed tools in /usr/local, wouldn't they expect them to be used?

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

Title:
  ZFS pools should be automatically scrubbed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Incomplete

Bug description:
  [Impact]

  Xenial shipped with a cron job to automatically scrub ZFS pools, as
  desired by many users and as implemented by mdadm for traditional Linux
  software RAID.  Unfortunately, this cron job does not work, because it needs 
a PATH line for /sbin, where the zpool utility lives.

  Given the existence of the cron job and various discussions on IRC, etc.,
  users expect that scrubs are happening, when they are not.  This means ZFS
  is not pre-emptively checking for (and correcting) corruption. The odds of
  disk corruption are admittedly very low, but violating users' expectations
  of data safety, especially when they've gone out of their way to use a
  filesystem which touts data safety, is bad.

  [Test Case]

  $ truncate -s 1G test.img
  $ sudo zpool create test `pwd`/test.img
  $ sudo zpool status test

  $ sudo vi /etc/cron.d/zfsutils-linux
  Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes
  (modifying the date range if it's not currently the 8th through the 14th
  and the "-eq 0" check if it's not currently a Sunday).

  $ grep zfs /var/log/cron.log
  Verify in /var/log/cron.log that the job ran.

  $ sudo zpool status test

  Expected results:
scan: scrub repaired 0 in ... on 

  Actual results:
scan: none requested

  Then, add the PATH line, update the time rules in the cron job, and repeat
  the test. Now it will work.

  - OR -

  The best test case is to leave the cron job file untouched, install the
  patched package, wait for the second Sunday of the month, and verify with
  zpool status that a scrub ran.  I did this, on Xenial, with the package I
  built.  The debdiff is in comment #11 and was accepted to Yakkety.

  If someone can get this in -proposed before the 14th, I'll gladly install
  the actual package from -proposed and make sure it runs correctly on the
  14th.

  [Regression Potential]

  The patch only touches the cron.d file, which has only one cron job in it.
  This cron job is completely broken (inoperative) at the moment, so the
  regression potential is very low.


  
  ORIGINAL, PRE-SRU, DESCRIPTION:

  mdadm automatically checks MD arrays. ZFS should automatically scrub
  pools too. Scrubbing a pool allows ZFS to detect on-disk corruption
  and (when the pool has redundancy) correct it. Note that ZFS does not
  blindly assume the other copy is correct; it will only overwrite bad
  data with data that is known to be good (i.e. it passes the checksum).

  I've attached a debdiff which accomplishes this. It builds and
  installs cleanly.

  The meat of it is the scrub script I've been using on production
  systems, both servers and laptops, and recommending in my Ubuntu root-
  on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool
  is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot
  of disk load which could theoretically lead to another failure. We
  should save that disk load for resilvering. 2) Performance is already
  less on a degraded pool and scrubbing can make that worse, even though
  scrubs are throttled. Arguably, I might be being too conservative
  here, but the marginal benefit of scrubbing a *degraded* pool is
  pretty minimal as pools should not be left degraded for very long.

  The cron.d in this patch scrubs on the second Sunday of the month.
  mdadm scrubs on the first Sunday of the month. This way, if a system
  has both MD and ZFS pools, the load doesn't all happen at the same
  time. If the system doesn't have both types, it shouldn't really
  matter which week. If you'd rather make it the same week as MD, I see
  no problem with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+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 1548009] Re: ZFS pools should be automatically scrubbed

[Mark Wilkinson]

Would it not make more sense to have /usr/lib/zfs-linux/scrub set the
PATH that it requires in order to find the zpool command?

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

Title:
  ZFS pools should be automatically scrubbed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Incomplete

Bug description:
  [Impact]

  Xenial shipped with a cron job to automatically scrub ZFS pools, as
  desired by many users and as implemented by mdadm for traditional Linux
  software RAID.  Unfortunately, this cron job does not work, because it needs 
a PATH line for /sbin, where the zpool utility lives.

  Given the existence of the cron job and various discussions on IRC, etc.,
  users expect that scrubs are happening, when they are not.  This means ZFS
  is not pre-emptively checking for (and correcting) corruption. The odds of
  disk corruption are admittedly very low, but violating users' expectations
  of data safety, especially when they've gone out of their way to use a
  filesystem which touts data safety, is bad.

  [Test Case]

  $ truncate -s 1G test.img
  $ sudo zpool create test `pwd`/test.img
  $ sudo zpool status test

  $ sudo vi /etc/cron.d/zfsutils-linux
  Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes
  (modifying the date range if it's not currently the 8th through the 14th
  and the "-eq 0" check if it's not currently a Sunday).

  $ grep zfs /var/log/cron.log
  Verify in /var/log/cron.log that the job ran.

  $ sudo zpool status test

  Expected results:
scan: scrub repaired 0 in ... on 

  Actual results:
scan: none requested

  Then, add the PATH line, update the time rules in the cron job, and repeat
  the test. Now it will work.

  - OR -

  The best test case is to leave the cron job file untouched, install the
  patched package, wait for the second Sunday of the month, and verify with
  zpool status that a scrub ran.  I did this, on Xenial, with the package I
  built.  The debdiff is in comment #11 and was accepted to Yakkety.

  If someone can get this in -proposed before the 14th, I'll gladly install
  the actual package from -proposed and make sure it runs correctly on the
  14th.

  [Regression Potential]

  The patch only touches the cron.d file, which has only one cron job in it.
  This cron job is completely broken (inoperative) at the moment, so the
  regression potential is very low.


  
  ORIGINAL, PRE-SRU, DESCRIPTION:

  mdadm automatically checks MD arrays. ZFS should automatically scrub
  pools too. Scrubbing a pool allows ZFS to detect on-disk corruption
  and (when the pool has redundancy) correct it. Note that ZFS does not
  blindly assume the other copy is correct; it will only overwrite bad
  data with data that is known to be good (i.e. it passes the checksum).

  I've attached a debdiff which accomplishes this. It builds and
  installs cleanly.

  The meat of it is the scrub script I've been using on production
  systems, both servers and laptops, and recommending in my Ubuntu root-
  on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool
  is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot
  of disk load which could theoretically lead to another failure. We
  should save that disk load for resilvering. 2) Performance is already
  less on a degraded pool and scrubbing can make that worse, even though
  scrubs are throttled. Arguably, I might be being too conservative
  here, but the marginal benefit of scrubbing a *degraded* pool is
  pretty minimal as pools should not be left degraded for very long.

  The cron.d in this patch scrubs on the second Sunday of the month.
  mdadm scrubs on the first Sunday of the month. This way, if a system
  has both MD and ZFS pools, the load doesn't all happen at the same
  time. If the system doesn't have both types, it shouldn't really
  matter which week. If you'd rather make it the same week as MD, I see
  no problem with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+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 1548009] Re: ZFS pools should be automatically scrubbed

[Colin Ian King]

/usr/local/bin and /usr/local/sbin are not required for anything zfs
specific, so given that they are redundant they should not be added to
the PATH. Plus the security issue as mentioned above.

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

Title:
  ZFS pools should be automatically scrubbed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Incomplete

Bug description:
  [Impact]

  Xenial shipped with a cron job to automatically scrub ZFS pools, as
  desired by many users and as implemented by mdadm for traditional Linux
  software RAID.  Unfortunately, this cron job does not work, because it needs 
a PATH line for /sbin, where the zpool utility lives.

  Given the existence of the cron job and various discussions on IRC, etc.,
  users expect that scrubs are happening, when they are not.  This means ZFS
  is not pre-emptively checking for (and correcting) corruption. The odds of
  disk corruption are admittedly very low, but violating users' expectations
  of data safety, especially when they've gone out of their way to use a
  filesystem which touts data safety, is bad.

  [Test Case]

  $ truncate -s 1G test.img
  $ sudo zpool create test `pwd`/test.img
  $ sudo zpool status test

  $ sudo vi /etc/cron.d/zfsutils-linux
  Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes
  (modifying the date range if it's not currently the 8th through the 14th
  and the "-eq 0" check if it's not currently a Sunday).

  $ grep zfs /var/log/cron.log
  Verify in /var/log/cron.log that the job ran.

  $ sudo zpool status test

  Expected results:
scan: scrub repaired 0 in ... on 

  Actual results:
scan: none requested

  Then, add the PATH line, update the time rules in the cron job, and repeat
  the test. Now it will work.

  - OR -

  The best test case is to leave the cron job file untouched, install the
  patched package, wait for the second Sunday of the month, and verify with
  zpool status that a scrub ran.  I did this, on Xenial, with the package I
  built.  The debdiff is in comment #11 and was accepted to Yakkety.

  If someone can get this in -proposed before the 14th, I'll gladly install
  the actual package from -proposed and make sure it runs correctly on the
  14th.

  [Regression Potential]

  The patch only touches the cron.d file, which has only one cron job in it.
  This cron job is completely broken (inoperative) at the moment, so the
  regression potential is very low.


  
  ORIGINAL, PRE-SRU, DESCRIPTION:

  mdadm automatically checks MD arrays. ZFS should automatically scrub
  pools too. Scrubbing a pool allows ZFS to detect on-disk corruption
  and (when the pool has redundancy) correct it. Note that ZFS does not
  blindly assume the other copy is correct; it will only overwrite bad
  data with data that is known to be good (i.e. it passes the checksum).

  I've attached a debdiff which accomplishes this. It builds and
  installs cleanly.

  The meat of it is the scrub script I've been using on production
  systems, both servers and laptops, and recommending in my Ubuntu root-
  on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool
  is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot
  of disk load which could theoretically lead to another failure. We
  should save that disk load for resilvering. 2) Performance is already
  less on a degraded pool and scrubbing can make that worse, even though
  scrubs are throttled. Arguably, I might be being too conservative
  here, but the marginal benefit of scrubbing a *degraded* pool is
  pretty minimal as pools should not be left degraded for very long.

  The cron.d in this patch scrubs on the second Sunday of the month.
  mdadm scrubs on the first Sunday of the month. This way, if a system
  has both MD and ZFS pools, the load doesn't all happen at the same
  time. If the system doesn't have both types, it shouldn't really
  matter which week. If you'd rather make it the same week as MD, I see
  no problem with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+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 1568729] Re: divide error: 0000 [#1] SMP in task_numa_migrate - handle_mm_fault

[chrone]

Just happened two days ago on Trusty 14.04.4 with Linux 4.4.0-31 on one
of Ceph Jewel OSD server. It ran fine for 8 days though and suddenly the
CPU load spiked to 600.

The server is from SuperMicro SuperStorage Server SSG-6048R-E1CR36L with these 
following specs:
2x Intel Xeon E5-2630 v3 @ 2.4GHz 16C/32T
128GB DDR3 ECC
2x 80GB Intel SSD S3500 series for OS Drive in mdraid1 mode
2x 800GB Intel PCIe SSD S3700 series for Ceph OSD Journal
36x 6TB Samsung NAS 7200rpm SAS drives for Ceph OSDs
4x 10GbE SFP+ Intel 82599ES ethernet with LACP bonding mode

The apport-collect log is attached. Hope this helps.

/chrone

** Attachment added: "ubuntu trusty hwe lts xenial - ceph jewel osd - 
apport-collect.zip"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1568729/+attachment/4708813/+files/ubuntu%20trusty%20hwe%20lts%20xenial%20-%20ceph%20jewel%20osd%20-%20apport-collect.zip

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

Title:
  divide error:  [#1] SMP in task_numa_migrate - handle_mm_fault

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

Bug description:
  While running qemu 2.5 on a trusty host running 4.4.0-15.31~14.04.1
  the host system has crashed (load > 200) 3 times in the last 3 days.

  Always with this stack trace:

  Apr  9 19:01:09 cnode9.0 kernel: [197071.195577] divide error:  [#1] SMP 
  Apr  9 19:01:09 cnode9.0 kernel: [197071.195633] Modules linked in: vhost_net 
vhost macvtap macvlan arc4 md4 nls_utf8 ci
  fs nfnetlink_queue nfnetlink xt_CHECKSUM xt_nat iptable_nat nf_nat_ipv4 
xt_NFQUEUE xt_CLASSIFY ip6table_mangle sch_sfq sch_htb veth dccp_diag
   dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag 
ebtable_filter ebtables nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_fil
  ter ip6_tables iptable_mangle xt_CT iptable_raw xt_tcpudp nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack iptable_filter ip_tables x_tables dum
  my bridge stp llc ipmi_ssif ipmi_devintf intel_rapl x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel kvm dcdbas irqbypass crct10dif_p
  clmul crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper 
ablk_helper cryptd joydev input_leds nf_nat_ftp sb_edac nf_conntrack_ftp e
  dac_core cdc_ether nf_nat_pptp usbnet nf_conntrack_pptp mii nf_nat_proto_gre 
lpc_ich nf_nat_sip ioatdma nf_nat nf_conntrack_sip nfsd ipmi_si 
  8250_fintek nf_conntrack_proto_gre ipmi_msghandler acpi_pad wmi shpchp 
nf_conntrack acpi_power_meter mac_hid auth_rpcgss nfs_acl bonding nfs 
  lp lockd parport grace sunrpc fscache tcp_htcp xfs btrfs hid_generic usbhid 
hid raid10 raid456 async_raid6_recov async_memcpy async_pq async_
  xor async_tx xor ixgbe raid6_pq libcrc32c igb vxlan raid1 i2c_algo_bit 
ip6_udp_tunnel dca udp_tunnel ahci raid0 ptp libahci megaraid_sas mult
  ipath pps_core mdio linear fjes
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197014] CPU: 13 PID: 3147726 Comm: 
ceph-osd Not tainted 4.4.0-15-generic #31~14
  .04.1-Ubuntu
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197085] Hardware name: Dell Inc. 
PowerEdge R720/0XH7F2, BIOS 2.5.2 01/28/2015
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197154] task: 88252be1ee00 ti: 
8824fc0d4000 task.ti: 8824fc0d4000
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197221] RIP: 
0010:[]  [] task_numa_find_cpu+0x238/0x700
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197300] RSP: :8824fc0d7ba8  
EFLAGS: 00010257
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197340] RAX:  RBX: 
8824fc0d7c48 RCX: 
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197406] RDX:  RSI: 
88479f18 RDI: 884782a47600
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197473] RBP: 8824fc0d7c10 R08: 
000102eea157 R09: 01a8
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197540] R10: 0002404b R11: 
023f R12: 88238093
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197606] R13: 0008 R14: 
008c R15: 0124
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197673] FS:  7f19aab5b700() 
GS:88479f18() knlGS:
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197741] CS:  0010 DS:  ES:  
CR0: 80050033
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197782] CR2: 25469600 CR3: 
0023846bc000 CR4: 000426e0
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197848] Stack:
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197880]  817425fb 
8829af3e9e00 00f6 88252be1ee00
  Apr  9 19:01:09 cnode9.0 kernel: [197071.197965]  008d 
0225 00016d40 008d
  Apr  9 19:01:09 cnode9.0 kernel: [197071.198047]  88252be1ee00 
01ad 8824fc0d7c48 00e1
  Apr  9 19:01:09 cnode9.0 kernel: [197071.198132] Call Trace:
  Apr  9 19:01:09 cnode

[Kernel-packages] [Bug 1607404] [NEW] Xenial update to v4.4.16 stable release

[Tim Gardner]

Public bug reported:


SRU Justification

Impact:
   The upstream process for stable tree updates is quite similar
   in scope to the Ubuntu SRU process, e.g., each patch has to
   demonstrably fix a bug, and each patch is vetted by upstream
   by originating either directly from a mainline/stable Linux tree or
   a minimally backported form of that patch. The v4.4.16 upstream stable
   patch set is now available. It should be included in the Ubuntu
   kernel as well.

   git://git.kernel.org/

TEST CASE: TBD

   The following patches from the v4.4.16 stable release shall be
applied:

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

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


** Tags: kernel-stable-tracking-bug

** Tags added: kernel-stable-tracking-bug

** Also affects: linux (Ubuntu Xenial)
   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/1607404

Title:
  Xenial update to v4.4.16 stable release

Status in linux package in Ubuntu:
  New
Status in linux source package in Xenial:
  New

Bug description:
  
  SRU Justification

  Impact:
 The upstream process for stable tree updates is quite similar
 in scope to the Ubuntu SRU process, e.g., each patch has to
 demonstrably fix a bug, and each patch is vetted by upstream
 by originating either directly from a mainline/stable Linux tree or
 a minimally backported form of that patch. The v4.4.16 upstream stable
 patch set is now available. It should be included in the Ubuntu
 kernel as well.

 git://git.kernel.org/

  TEST CASE: TBD

 The following patches from the v4.4.16 stable release shall be
  applied:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1607404/+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 1548009] Re: ZFS pools should be automatically scrubbed

[Colin Ian King]

This should be rejected for Xenial and reverted for Yakkety and a more
minimal path used.

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

Title:
  ZFS pools should be automatically scrubbed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Incomplete

Bug description:
  [Impact]

  Xenial shipped with a cron job to automatically scrub ZFS pools, as
  desired by many users and as implemented by mdadm for traditional Linux
  software RAID.  Unfortunately, this cron job does not work, because it needs 
a PATH line for /sbin, where the zpool utility lives.

  Given the existence of the cron job and various discussions on IRC, etc.,
  users expect that scrubs are happening, when they are not.  This means ZFS
  is not pre-emptively checking for (and correcting) corruption. The odds of
  disk corruption are admittedly very low, but violating users' expectations
  of data safety, especially when they've gone out of their way to use a
  filesystem which touts data safety, is bad.

  [Test Case]

  $ truncate -s 1G test.img
  $ sudo zpool create test `pwd`/test.img
  $ sudo zpool status test

  $ sudo vi /etc/cron.d/zfsutils-linux
  Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes
  (modifying the date range if it's not currently the 8th through the 14th
  and the "-eq 0" check if it's not currently a Sunday).

  $ grep zfs /var/log/cron.log
  Verify in /var/log/cron.log that the job ran.

  $ sudo zpool status test

  Expected results:
scan: scrub repaired 0 in ... on 

  Actual results:
scan: none requested

  Then, add the PATH line, update the time rules in the cron job, and repeat
  the test. Now it will work.

  - OR -

  The best test case is to leave the cron job file untouched, install the
  patched package, wait for the second Sunday of the month, and verify with
  zpool status that a scrub ran.  I did this, on Xenial, with the package I
  built.  The debdiff is in comment #11 and was accepted to Yakkety.

  If someone can get this in -proposed before the 14th, I'll gladly install
  the actual package from -proposed and make sure it runs correctly on the
  14th.

  [Regression Potential]

  The patch only touches the cron.d file, which has only one cron job in it.
  This cron job is completely broken (inoperative) at the moment, so the
  regression potential is very low.


  
  ORIGINAL, PRE-SRU, DESCRIPTION:

  mdadm automatically checks MD arrays. ZFS should automatically scrub
  pools too. Scrubbing a pool allows ZFS to detect on-disk corruption
  and (when the pool has redundancy) correct it. Note that ZFS does not
  blindly assume the other copy is correct; it will only overwrite bad
  data with data that is known to be good (i.e. it passes the checksum).

  I've attached a debdiff which accomplishes this. It builds and
  installs cleanly.

  The meat of it is the scrub script I've been using on production
  systems, both servers and laptops, and recommending in my Ubuntu root-
  on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool
  is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot
  of disk load which could theoretically lead to another failure. We
  should save that disk load for resilvering. 2) Performance is already
  less on a degraded pool and scrubbing can make that worse, even though
  scrubs are throttled. Arguably, I might be being too conservative
  here, but the marginal benefit of scrubbing a *degraded* pool is
  pretty minimal as pools should not be left degraded for very long.

  The cron.d in this patch scrubs on the second Sunday of the month.
  mdadm scrubs on the first Sunday of the month. This way, if a system
  has both MD and ZFS pools, the load doesn't all happen at the same
  time. If the system doesn't have both types, it shouldn't really
  matter which week. If you'd rather make it the same week as MD, I see
  no problem with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+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 1597908] Re: linux-kernel: Freeing IRQ from IRQ context

[Keith Busch]

Kamil,

For your issue, this is potentially a bug specific to the 4.5 driver. We
used to poll once a second, which would hide legacy irq issues during
initialization, but 4.5 removed it. A patch[*] to 4.6 removed all use of
legacy interrupts, and should have been applied to 4.5 stable (they were
cc'ed on the mailing list).

 *
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=a5229050b69cfffb690b546c357ca5a60434c0c8

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

Title:
  linux-kernel: Freeing IRQ from IRQ context

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

Bug description:
  It looks like the Ubuntu 16.04 took the nvme driver from 4.5 kernel,
  but is missing some critical block updates that it was depending on.
  Specifically this one moving the timeout handler to a work queue
  instead of a irq context timer task:

  
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=287922eb0b186e2a5bf54fdd04b734c25c90035c

  This mismatch causes lots of warnings and errors during recovery from
  failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597908/+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 1548009] Re: ZFS pools should be automatically scrubbed

[Andy Whitcroft]

This patch adds /usr/local/bin and /usr/local/sbin to the path.  Given
the utilities in use are all official binaries this seems unexpected and
a potential security risk.

** Changed in: zfs-linux (Ubuntu Xenial)
   Status: New => Incomplete

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

Title:
  ZFS pools should be automatically scrubbed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Incomplete

Bug description:
  [Impact]

  Xenial shipped with a cron job to automatically scrub ZFS pools, as
  desired by many users and as implemented by mdadm for traditional Linux
  software RAID.  Unfortunately, this cron job does not work, because it needs 
a PATH line for /sbin, where the zpool utility lives.

  Given the existence of the cron job and various discussions on IRC, etc.,
  users expect that scrubs are happening, when they are not.  This means ZFS
  is not pre-emptively checking for (and correcting) corruption. The odds of
  disk corruption are admittedly very low, but violating users' expectations
  of data safety, especially when they've gone out of their way to use a
  filesystem which touts data safety, is bad.

  [Test Case]

  $ truncate -s 1G test.img
  $ sudo zpool create test `pwd`/test.img
  $ sudo zpool status test

  $ sudo vi /etc/cron.d/zfsutils-linux
  Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes
  (modifying the date range if it's not currently the 8th through the 14th
  and the "-eq 0" check if it's not currently a Sunday).

  $ grep zfs /var/log/cron.log
  Verify in /var/log/cron.log that the job ran.

  $ sudo zpool status test

  Expected results:
scan: scrub repaired 0 in ... on 

  Actual results:
scan: none requested

  Then, add the PATH line, update the time rules in the cron job, and repeat
  the test. Now it will work.

  - OR -

  The best test case is to leave the cron job file untouched, install the
  patched package, wait for the second Sunday of the month, and verify with
  zpool status that a scrub ran.  I did this, on Xenial, with the package I
  built.  The debdiff is in comment #11 and was accepted to Yakkety.

  If someone can get this in -proposed before the 14th, I'll gladly install
  the actual package from -proposed and make sure it runs correctly on the
  14th.

  [Regression Potential]

  The patch only touches the cron.d file, which has only one cron job in it.
  This cron job is completely broken (inoperative) at the moment, so the
  regression potential is very low.


  
  ORIGINAL, PRE-SRU, DESCRIPTION:

  mdadm automatically checks MD arrays. ZFS should automatically scrub
  pools too. Scrubbing a pool allows ZFS to detect on-disk corruption
  and (when the pool has redundancy) correct it. Note that ZFS does not
  blindly assume the other copy is correct; it will only overwrite bad
  data with data that is known to be good (i.e. it passes the checksum).

  I've attached a debdiff which accomplishes this. It builds and
  installs cleanly.

  The meat of it is the scrub script I've been using on production
  systems, both servers and laptops, and recommending in my Ubuntu root-
  on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool
  is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot
  of disk load which could theoretically lead to another failure. We
  should save that disk load for resilvering. 2) Performance is already
  less on a degraded pool and scrubbing can make that worse, even though
  scrubs are throttled. Arguably, I might be being too conservative
  here, but the marginal benefit of scrubbing a *degraded* pool is
  pretty minimal as pools should not be left degraded for very long.

  The cron.d in this patch scrubs on the second Sunday of the month.
  mdadm scrubs on the first Sunday of the month. This way, if a system
  has both MD and ZFS pools, the load doesn't all happen at the same
  time. If the system doesn't have both types, it shouldn't really
  matter which week. If you'd rather make it the same week as MD, I see
  no problem with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+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 1597908] Re: linux-kernel: Freeing IRQ from IRQ context

[Keith Busch]

Hi Kamil,

It looks like the kernel issue is resolved. Your drive just appears to
be in a bad state and the driver reacts accordingly.

I think this launchpad's issue is resolved and should request the fix go
forward.

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

Title:
  linux-kernel: Freeing IRQ from IRQ context

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

Bug description:
  It looks like the Ubuntu 16.04 took the nvme driver from 4.5 kernel,
  but is missing some critical block updates that it was depending on.
  Specifically this one moving the timeout handler to a work queue
  instead of a irq context timer task:

  
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=287922eb0b186e2a5bf54fdd04b734c25c90035c

  This mismatch causes lots of warnings and errors during recovery from
  failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597908/+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 1607390] [NEW] bluetooth not working

[Mohamed]

Public bug reported:

I've recently installed ubuntu 16.04 LTS twice -and i discovered that
the problem was from the tool katoolin so i didn't install it- after i
installed ubuntu the bluetooth didn't work for me.

P.S:the bluetooth was working when my laptop was ubuntu 15.04

when i turn bluetooth on to connect my mouse the switch was on but it
said that

Bluetooth is disabled

i entered the command

sudo rfkill unblock bluetooth

it worked but didn't connect to the mouse even after the next restart
i also tried to editing the file /etc/rc.local (putting sudo rfkill unblock 
bluetooth before last line and restarting)

and i've tried **sudo hciconfig hci0 reset** with output

> Can't init device hci0: Connection timed out (110)

my lsusb; rfkill list output:

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 1bcf:2883 Sunplus Innovation Technology Inc.
Bus 001 Device 014: ID 04ca:3005 Lite-On Technology Corp.
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 04d9:1503 Holtek Semiconductor, Inc. Keyboard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

0: asus-wlan: Wireless LAN
  Soft blocked: no
  Hard blocked: no
 1: asus-bluetooth: Bluetooth
  Soft blocked: no
  Hard blocked: no
 11: hci0: Bluetooth
  Soft blocked: no
 Hard blocked: no

and output of **dmesg | grep -Ei 'ath3k|blue'**

[1.727681] usb 1-1.1: Product: Bluetooth USB Host Controller
[   34.157120] Bluetooth: Core ver 2.21
[   34.157135] Bluetooth: HCI device and connection manager initialized
[   34.157138] Bluetooth: HCI socket layer initialized
[   34.157140] Bluetooth: L2CAP socket layer initialized
[   34.157145] Bluetooth: SCO socket layer initialized
[   35.604410] usbcore: registered new interface driver ath3k
[   51.744300] usb 1-1.1: Product: Bluetooth USB Host Controller
[   53.810045] Bluetooth: hci0 command 0x0c25 tx timeout
[   55.814079] Bluetooth: hci0 command 0x0c38 tx timeout
[   57.818111] Bluetooth: hci0 command 0x0c39 tx timeout
[   59.822149] Bluetooth: hci0 command 0x0c05 tx timeout
[   66.997548] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   66.997552] Bluetooth: BNEP filters: protocol multicast
[   66.997556] Bluetooth: BNEP socket layer initialized
[  195.105902] usb 1-1.1: Product: Bluetooth USB Host Controller
[  195.328480] Bluetooth: RFCOMM TTY layer initialized
[  195.328488] Bluetooth: RFCOMM socket layer initialized
[  195.328495] Bluetooth: RFCOMM ver 1.11
[  199.131870] Bluetooth: hci0 command 0x1009 tx timeout
[  276.169130] usb 1-1.1: Product: Bluetooth USB Host Controller
[  294.258992] Bluetooth: hci0 command 0x1005 tx timeout
[  296.263065] Bluetooth: hci0 command 0x0c23 tx timeout
[  298.267076] Bluetooth: hci0 command 0x0c14 tx timeout
[  306.361529] usb 1-1.1: Product: Bluetooth USB Host Controller
[  346.417970] Bluetooth: hci0 command 0x0c56 tx timeout
[  348.421916] Bluetooth: hci0 command 0x0c45 tx timeout
[  350.425782] Bluetooth: hci0 command 0x0c58 tx timeout
[  352.429744] Bluetooth: hci0 command 0x1004 tx timeout
[  366.099802] usb 1-1.1: Product: Bluetooth USB Host Controller
[  368.145218] Bluetooth: hci0 command 0x1001 tx timeout
[  370.149130] Bluetooth: hci0 command 0x1009 tx timeout
[  410.346611] usb 1-1.1: Product: Bluetooth USB Host Controller
[  421.612041] Bluetooth: hci0 command 0x0c23 tx timeout
[  423.616060] Bluetooth: hci0 command 0x0c14 tx timeout
[  425.620018] Bluetooth: hci0 command 0x0c25 tx timeout
[  427.623984] Bluetooth: hci0 command 0x0c38 tx timeout
[  442.650168] usb 1-1.1: Product: Bluetooth USB Host Controller
[  444.727752] Bluetooth: hci0 command 0x0c52 tx timeout
[  446.731800] Bluetooth: hci0 command 0x0c45 tx timeout
[  448.735743] Bluetooth: hci0 command 0x0c58 tx timeout
[  450.739762] Bluetooth: hci0 command 0x1004 tx timeout
[ 4000.639722] usb 1-1.1: Product: Bluetooth USB Host Controller
[ 4011.801141] Bluetooth: hci0 command 0x2002 tx timeout
[ 4013.805106] Bluetooth: hci0 command 0x2003 tx timeout
[ 4015.809139] Bluetooth: hci0 command 0x201c tx timeout
[ 4017.813098] Bluetooth: hci0 command 0x1002 tx timeout
[ 4019.817109] Bluetooth: hci0 command tx timeout
[ 4031.611130] usb 1-1.1: Product: Bluetooth USB Host Controller
[ 4073.072544] Bluetooth: hci0 command 0x0c39 tx timeout
[ 4075.076588] Bluetooth: hci0 command 0x0c05 tx timeout
[ 4077.080593] Bluetooth: hci0 command 0x0c16 tx timeout
[ 4079.084502] Bluetooth: hci0 command 0x2002 tx timeout
[ 4081.088484] 

[Kernel-packages] [Bug 1548009] Re: ZFS pools should be automatically scrubbed

[Michael Terry]

I've uploaded the patch to xenial-proposed too.  Thanks!

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

Title:
  ZFS pools should be automatically scrubbed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  New

Bug description:
  [Impact]

  Xenial shipped with a cron job to automatically scrub ZFS pools, as
  desired by many users and as implemented by mdadm for traditional Linux
  software RAID.  Unfortunately, this cron job does not work, because it needs 
a PATH line for /sbin, where the zpool utility lives.

  Given the existence of the cron job and various discussions on IRC, etc.,
  users expect that scrubs are happening, when they are not.  This means ZFS
  is not pre-emptively checking for (and correcting) corruption. The odds of
  disk corruption are admittedly very low, but violating users' expectations
  of data safety, especially when they've gone out of their way to use a
  filesystem which touts data safety, is bad.

  [Test Case]

  $ truncate -s 1G test.img
  $ sudo zpool create test `pwd`/test.img
  $ sudo zpool status test

  $ sudo vi /etc/cron.d/zfsutils-linux
  Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes
  (modifying the date range if it's not currently the 8th through the 14th
  and the "-eq 0" check if it's not currently a Sunday).

  $ grep zfs /var/log/cron.log
  Verify in /var/log/cron.log that the job ran.

  $ sudo zpool status test

  Expected results:
scan: scrub repaired 0 in ... on 

  Actual results:
scan: none requested

  Then, add the PATH line, update the time rules in the cron job, and repeat
  the test. Now it will work.

  - OR -

  The best test case is to leave the cron job file untouched, install the
  patched package, wait for the second Sunday of the month, and verify with
  zpool status that a scrub ran.  I did this, on Xenial, with the package I
  built.  The debdiff is in comment #11 and was accepted to Yakkety.

  If someone can get this in -proposed before the 14th, I'll gladly install
  the actual package from -proposed and make sure it runs correctly on the
  14th.

  [Regression Potential]

  The patch only touches the cron.d file, which has only one cron job in it.
  This cron job is completely broken (inoperative) at the moment, so the
  regression potential is very low.


  
  ORIGINAL, PRE-SRU, DESCRIPTION:

  mdadm automatically checks MD arrays. ZFS should automatically scrub
  pools too. Scrubbing a pool allows ZFS to detect on-disk corruption
  and (when the pool has redundancy) correct it. Note that ZFS does not
  blindly assume the other copy is correct; it will only overwrite bad
  data with data that is known to be good (i.e. it passes the checksum).

  I've attached a debdiff which accomplishes this. It builds and
  installs cleanly.

  The meat of it is the scrub script I've been using on production
  systems, both servers and laptops, and recommending in my Ubuntu root-
  on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool
  is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot
  of disk load which could theoretically lead to another failure. We
  should save that disk load for resilvering. 2) Performance is already
  less on a degraded pool and scrubbing can make that worse, even though
  scrubs are throttled. Arguably, I might be being too conservative
  here, but the marginal benefit of scrubbing a *degraded* pool is
  pretty minimal as pools should not be left degraded for very long.

  The cron.d in this patch scrubs on the second Sunday of the month.
  mdadm scrubs on the first Sunday of the month. This way, if a system
  has both MD and ZFS pools, the load doesn't all happen at the same
  time. If the system doesn't have both types, it shouldn't really
  matter which week. If you'd rather make it the same week as MD, I see
  no problem with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+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 1607387] Re: lm-sensors is throwing "ERROR: Can't get value of subfeature temp1_input: I/O error" for be2net driver

[Kevin W. Rudd]

** Summary changed:

- [LTCTest][Opal][FW860] Ubuntu: lm-sensors is throwing "ERROR: Can't get value 
of subfeature temp1_input: I/O error" for be2net driver
+ lm-sensors is throwing "ERROR: Can't get value of subfeature temp1_input: I/O 
error" for be2net driver

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

Title:
  lm-sensors is throwing "ERROR: Can't get value of subfeature
  temp1_input: I/O error" for be2net driver

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #17 - Guilherme Guaglianoni Piccoli - 2016-07-27 18:49:08 ==
  Temperature and fan information from hardware are normally available to 
userspace through hwmon sysfs abstraction. In case of be2net driver, all PCI 
devices "managed" by this driver have hwmon entries, which are filled in a 
delayed workqueue on driver, every 64 seconds.

  The issue we're seeing is that the hardware temperature queries to
  devices' fw are performed only in devices which interface is up - so,
  we end up having messages like below when using the "sensors" tool
  (from lm-sensors), for example:

  be2net-pci-50100
  Adapter: PCI adapter
  ERROR: Can't get value of subfeature temp1_input: I/O error
  temp1:N/A

  
  The following upstream commit addresses this issue:

  d3480615cf ("be2net: perform temperature query in adapter regardless of its 
interface state") 
  
[https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?id=d3480615cf00c6f615cdb61a9d03386574b93342]

  We would like Canonical to merge this commit in the Xenial kernel.

  Thanks in advance,

  
  Guilherme

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1607387/+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 1605843] Re: Kernel crashes from time to time when using ftrace

[Nikolay Borisov]

Original report of the exact same issue:
https://lkml.org/lkml/2016/5/13/327

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

Title:
  Kernel crashes from time to time when using ftrace

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  While performing some tracing suing ftrace-cmd I came across the
  following OOPS:

  [  333.051723] invalid opcode:  [#1] SMP 
  [  333.051742] Modules linked in: drbg ansi_cprng ctr ccm xt_CHECKSUM 
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 
arc4 bridge stp llc ebtable_filter ebtables ath9k_htc ath9k_common ath9k_hw ath 
mac80211 cfg80211 binfmt_misc snd_hda_codec_hdmi dcdbas dell_smm_hwmon 
snd_hda_codec_realtek snd_hda_codec_generic intel_rapl uvcvideo snd_hda_intel 
x86_pkg_temp_thermal intel_powerclamp coretemp videobuf2_vmalloc snd_hda_codec 
videobuf2_memops input_leds videobuf2_v4l2 snd_usb_audio crct10dif_pclmul 
videobuf2_core snd_hda_core v4l2_common crc32_pclmul snd_usbmidi_lib videodev 
snd_hwdep aesni_intel media snd_pcm aes_x86_64 lrw gf128mul glue_helper 
ablk_helper cryptd snd_seq_midi snd_seq_midi_event snd_rawmidi serio_raw 
snd_seq snd_seq_device snd_timer lpc_ich snd ie31200_edac
  [  333.051972]  edac_core soundcore mei_me mei 8250_fintek mac_hid kvm_intel 
ip6t_REJECT nf_reject_ipv6 kvm nf_log_ipv6 irqbypass xt_hl ip6t_rt 
nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_log_ipv4 
nf_log_common xt_LOG xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns 
nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack 
iptable_filter ip_tables parport_pc x_tables ppdev lp parport autofs4 hid_apple 
raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor 
hid_generic usbhid hid raid6_pq libcrc32c raid1 raid0 multipath linear 
dm_mirror dm_region_hash dm_log i915 i2c_algo_bit drm_kms_helper psmouse 
syscopyarea sysfillrect sysimgblt fb_sys_fops e1000e ahci libahci drm ptp
  [  333.052206]  pps_core fjes video
  [  333.052216] CPU: 1 PID: 5616 Comm: trace-cmd Not tainted 4.4.0-31-generic 
#50-Ubuntu
  [  333.052235] Hardware name: Dell Inc. Precision T1650/0X9M3X, BIOS A15 
09/09/2013
  [  333.052254] task: 8804066b1b80 ti: 88040b474000 task.ti: 
88040b474000
  [  333.052272] RIP: 0010:[]  [] 
ftrace_stub+0x0/0x8
  [  333.052296] RSP: 0018:88040b477f00  EFLAGS: 00010286
  [  333.052309] RAX:  RBX: 8800d9a4ec00 RCX: 
88040b477f18
  [  333.052326] RDX: 2000 RSI: 0237d690 RDI: 
8800d9a4ec00
  [  333.052343] RBP: 88040b477f48 R08: 7f89df102cf8 R09: 
0021
  [  333.052360] R10: 000d R11: 0246 R12: 
8800d9a4ec00
  [  333.052377] R13: 0237d690 R14: 2000 R15: 
0237d690
  [  333.052395] FS:  7f89df50f700() GS:88041e24() 
knlGS:
  [  333.052414] CS:  0010 DS:  ES:  CR0: 80050033
  [  333.052428] CR2: 00a78d88 CR3: 0003c3542000 CR4: 
001406e0
  [  333.052445] Stack:
  [  333.052451]  8120d165 8120df35 7fff364487e5 

  [  333.052473]  eee5d05c   
0006
  [  333.052494]  0008 2000 8182db32 
0004
  [  333.052515] Call Trace:
  [  333.052525]  [] ? vfs_read+0x5/0x130
  [  333.052538]  [] ? SyS_read+0x55/0xc0
  [  333.052553]  [] entry_SYSCALL_64_fastpath+0x16/0x71
  [  333.052568] Code: 8b 44 24 48 48 8b 7c 24 70 48 8b 74 24 68 48 8b 54 24 60 
48 8b 4c 24 58 48 8b 44 24 50 48 8b 6c 24 20 48 81 c4 d0 00 00 00 e9 fd  ff 
ff 80 00 00 00 00 9c 55 ff 74 24 18 55 48 89 e5 ff 74 24 
  [  333.052685] RIP  [] ftrace_stub+0x0/0x8
  [  333.052700]  RSP 

  
  All code
  
 0: 8b 44 24 48 mov0x48(%rsp),%eax
 4: 48 8b 7c 24 70  mov0x70(%rsp),%rdi
 9: 48 8b 74 24 68  mov0x68(%rsp),%rsi
 e: 48 8b 54 24 60  mov0x60(%rsp),%rdx
13: 48 8b 4c 24 58  mov0x58(%rsp),%rcx
18: 48 8b 44 24 50  mov0x50(%rsp),%rax
1d: 48 8b 6c 24 20  mov0x20(%rsp),%rbp
22: 48 81 c4 d0 00 00 00add$0xd0,%rsp
29:*e9 fd ff ff ff  jmpq   0x2b <-- trapping 
instruction
2e: 80 00 00addb   $0x0,(%rax)
31: 00 00   add%al,(%rax)
33: 9c  pushfq 
34: 55  push   %rbp
35: ff 74 24 18 pushq  0x18(%rsp)
39: 55  push   %rbp
3a: 48 89 e5mov%rsp,%rbp
3d: ff  .byte 0xff
3e: 74 24   je 0x64

  Code starting with the faulting instruction
  ==

[Kernel-packages] [Bug 1607374] Re: Cannot mount proc in unprivileged containers if /proc/xen is mounted

[Seth Forshee]

** Patch added: 
"0001-UBUNTU-SAUCE-xenbus-Use-proc_create_mount_point-to-c.patch"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1607374/+attachment/4708767/+files/0001-UBUNTU-SAUCE-xenbus-Use-proc_create_mount_point-to-c.patch

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Seth Forshee (sforshee)

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

Title:
  Cannot mount proc in unprivileged containers if /proc/xen is mounted

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

Bug description:
  SRU Justification

  Impact: The xenfs filesystem is traditionally mounted at /proc/xen in
  xen guests. This directory doesn't use the special "create proc
  mountpoint" interface and thus fails the permanently empty test in
  fs_fully_visible(). This causes mounting of proc to fail in user
  namespace containers.

  Fix: Use the special proc interface to make this a "permanently empty"
  directory.

  Regression potential: This change will make it impossible to create
  files within /proc/xen, but since the directory is only ever used as a
  mount point this should not cause any problems.

  Original bug report and testing results can be found at
  https://github.com/lxc/lxd/issues/2238.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1607374/+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 1607387] [NEW] lm-sensors is throwing "ERROR: Can't get value of subfeature temp1_input: I/O error" for be2net driver

[bugproxy]

Public bug reported:

== Comment: #17 - Guilherme Guaglianoni Piccoli - 2016-07-27 18:49:08 ==
Temperature and fan information from hardware are normally available to 
userspace through hwmon sysfs abstraction. In case of be2net driver, all PCI 
devices "managed" by this driver have hwmon entries, which are filled in a 
delayed workqueue on driver, every 64 seconds.

The issue we're seeing is that the hardware temperature queries to
devices' fw are performed only in devices which interface is up - so, we
end up having messages like below when using the "sensors" tool (from
lm-sensors), for example:

be2net-pci-50100
Adapter: PCI adapter
ERROR: Can't get value of subfeature temp1_input: I/O error
temp1:N/A


The following upstream commit addresses this issue:

d3480615cf ("be2net: perform temperature query in adapter regardless of its 
interface state") 
[https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?id=d3480615cf00c6f615cdb61a9d03386574b93342]

We would like Canonical to merge this commit in the Xenial kernel.

Thanks in advance,


Guilherme

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Taco Screen team (taco-screen-team)
 Status: New


** Tags: architecture-ppc64le bugnameltc-143844 severity-high 
targetmilestone-inin16041

** Tags added: architecture-ppc64le bugnameltc-143844 severity-high
targetmilestone-inin16041

** Changed in: ubuntu
 Assignee: (unassigned) => Taco Screen team (taco-screen-team)

** Package changed: ubuntu => linux (Ubuntu)

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

Title:
  lm-sensors is throwing "ERROR: Can't get value of subfeature
  temp1_input: I/O error" for be2net driver

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #17 - Guilherme Guaglianoni Piccoli - 2016-07-27 18:49:08 ==
  Temperature and fan information from hardware are normally available to 
userspace through hwmon sysfs abstraction. In case of be2net driver, all PCI 
devices "managed" by this driver have hwmon entries, which are filled in a 
delayed workqueue on driver, every 64 seconds.

  The issue we're seeing is that the hardware temperature queries to
  devices' fw are performed only in devices which interface is up - so,
  we end up having messages like below when using the "sensors" tool
  (from lm-sensors), for example:

  be2net-pci-50100
  Adapter: PCI adapter
  ERROR: Can't get value of subfeature temp1_input: I/O error
  temp1:N/A

  
  The following upstream commit addresses this issue:

  d3480615cf ("be2net: perform temperature query in adapter regardless of its 
interface state") 
  
[https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?id=d3480615cf00c6f615cdb61a9d03386574b93342]

  We would like Canonical to merge this commit in the Xenial kernel.

  Thanks in advance,

  
  Guilherme

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1607387/+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 1607387] [NEW] [LTCTest][Opal][FW860] Ubuntu: lm-sensors is throwing "ERROR: Can't get value of subfeature temp1_input: I/O error" for be2net driver

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

== Comment: #17 - Guilherme Guaglianoni Piccoli - 2016-07-27 18:49:08 ==
Temperature and fan information from hardware are normally available to 
userspace through hwmon sysfs abstraction. In case of be2net driver, all PCI 
devices "managed" by this driver have hwmon entries, which are filled in a 
delayed workqueue on driver, every 64 seconds.

The issue we're seeing is that the hardware temperature queries to
devices' fw are performed only in devices which interface is up - so, we
end up having messages like below when using the "sensors" tool (from
lm-sensors), for example:

be2net-pci-50100
Adapter: PCI adapter
ERROR: Can't get value of subfeature temp1_input: I/O error
temp1:N/A


The following upstream commit addresses this issue:

d3480615cf ("be2net: perform temperature query in adapter regardless of its 
interface state") 
[https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?id=d3480615cf00c6f615cdb61a9d03386574b93342]

We would like Canonical to merge this commit in the Xenial kernel.

Thanks in advance,


Guilherme

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Taco Screen team (taco-screen-team)
 Status: New


** Tags: architecture-ppc64le bugnameltc-143844 severity-high 
targetmilestone-inin16041
-- 
[LTCTest][Opal][FW860] Ubuntu: lm-sensors is throwing "ERROR: Can't get value 
of subfeature temp1_input: I/O error" for be2net driver
https://bugs.launchpad.net/bugs/1607387
You received this bug notification because you are a member of Kernel Packages, 
which is subscribed to linux in Ubuntu.

-- 
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 1605344] Re: Regression caused by `fuse: Add support for pid namespaces` in 4.4.0-6.21

[Seth Forshee]

** Description changed:

+ SRU Justification
+ 
+ Impact: The pid namespace support in fuse refuses requests from any
+ process whose pid does not map into the pid namespace of the fuse
+ userspace process. This has caused a regression for at least one user.
+ 
+ Fix: Permit requests from processes whose pid does not map. Fill in the
+ pid value in the fuse request with 0.
+ 
+ Regression potential: A fuse filesystem not prepared to handle a pid of
+ 0 in fuse requests might have problems. However such a filesystem would
+ also receive pid values which aren't valid for its namespace when used
+ across pid namespaces in this manner with upstream kernels, so this
+ isn't a major concern.
+ 
+ ---
+ 
  The discussion starts at
  http://thread.gmane.org/gmane.linux.kernel.cgroups/15960/focus=2269876
  
  Commit in the tree is:
  
  commit a166e6726c6e12e28ac8489ff4e2faff7065a856
  Author: Seth Forshee 
  Date:   Wed Jul 2 16:29:19 2014 -0500
  
- UBUNTU: SAUCE: fuse: Add support for pid namespaces
+ UBUNTU: SAUCE: fuse: Add support for pid namespaces
  
  Description of the issue(copied from my report of lkml):
  
  This patch caused a regression in our major container use case with
  FUSE in Ubuntu 16.04, as patch was checked in as Ubuntu Sauce in
  Ubuntu 4.4.0-6.21 kernel.
  
  The use case is:
  1. Create a Docker container.
  2. Inside the container, start the FUSE backend, and mounted fs.
  3. Following step 2 in the container, create a loopback device to map
  a file in the mounted fuse to create a block device, which will be
  available to the whole system.
  
  It works well before this commit.
  
  The use case is broken because no matter which namespace losetup runs,
  the real request from loopback device seems always come from init ns,
  thus it will be in different ns running fuse backend. So the request
  will got denied, because the ns running fuse won't able to see the
  things from higher level(level 0 in fact) pid namespace.
- --- 
+ ---
  ApportVersion: 2.14.1-0ubuntu3.21
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: linux (not installed)
  ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  TERM=xterm-256color
+  PATH=(custom, no user)
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  ProcVersionSignature:
-  
+ 
  Tags:  trusty
  Uname: Linux 4.4.6 x86_64
  UnreportableReason: The running kernel is not an Ubuntu kernel
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
-  
+ 
  _MarkForUpload: True

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

Title:
  Regression caused by `fuse: Add support for pid namespaces` in
  4.4.0-6.21

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

Bug description:
  SRU Justification

  Impact: The pid namespace support in fuse refuses requests from any
  process whose pid does not map into the pid namespace of the fuse
  userspace process. This has caused a regression for at least one user.

  Fix: Permit requests from processes whose pid does not map. Fill in
  the pid value in the fuse request with 0.

  Regression potential: A fuse filesystem not prepared to handle a pid
  of 0 in fuse requests might have problems. However such a filesystem
  would also receive pid values which aren't valid for its namespace
  when used across pid namespaces in this manner with upstream kernels,
  so this isn't a major concern.

  ---

  The discussion starts at
  http://thread.gmane.org/gmane.linux.kernel.cgroups/15960/focus=2269876

  Commit in the tree is:

  commit a166e6726c6e12e28ac8489ff4e2faff7065a856
  Author: Seth Forshee 
  Date:   Wed Jul 2 16:29:19 2014 -0500

  UBUNTU: SAUCE: fuse: Add support for pid namespaces

  Description of the issue(copied from my report of lkml):

  This patch caused a regression in our major container use case with
  FUSE in Ubuntu 16.04, as patch was checked in as Ubuntu Sauce in
  Ubuntu 4.4.0-6.21 kernel.

  The use case is:
  1. Create a Docker container.
  2. Inside the container, start the FUSE backend, and mounted fs.
  3. Following step 2 in the container, create a loopback device to map
  a file in the mounted fuse to create a block device, which will be
  available to the whole system.

  It works well before this commit.

  The use case is broken because no matter which namespace losetup runs,
  the real request from loopback device seems always come from init ns,
  thus it will be in different ns running fuse backend. So the request
  will got denied, because the ns running fuse won't able to see the
  things from higher level(level 0 in fact) pid namespace.
  ---
  ApportVersion: 2.14.1-0ubuntu3.21
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: linux (not installed)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=

[Kernel-packages] [Bug 1605344] Re: Regression caused by `fuse: Add support for pid namespaces` in 4.4.0-6.21

[Seth Forshee]

** Patch added: 
"0001-UBUNTU-SAUCE-namespace-fuse-Permit-requests-from-oth.patch"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1605344/+attachment/4708792/+files/0001-UBUNTU-SAUCE-namespace-fuse-Permit-requests-from-oth.patch

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

Title:
  Regression caused by `fuse: Add support for pid namespaces` in
  4.4.0-6.21

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

Bug description:
  SRU Justification

  Impact: The pid namespace support in fuse refuses requests from any
  process whose pid does not map into the pid namespace of the fuse
  userspace process. This has caused a regression for at least one user.

  Fix: Permit requests from processes whose pid does not map. Fill in
  the pid value in the fuse request with 0.

  Regression potential: A fuse filesystem not prepared to handle a pid
  of 0 in fuse requests might have problems. However such a filesystem
  would also receive pid values which aren't valid for its namespace
  when used across pid namespaces in this manner with upstream kernels,
  so this isn't a major concern.

  ---

  The discussion starts at
  http://thread.gmane.org/gmane.linux.kernel.cgroups/15960/focus=2269876

  Commit in the tree is:

  commit a166e6726c6e12e28ac8489ff4e2faff7065a856
  Author: Seth Forshee 
  Date:   Wed Jul 2 16:29:19 2014 -0500

  UBUNTU: SAUCE: fuse: Add support for pid namespaces

  Description of the issue(copied from my report of lkml):

  This patch caused a regression in our major container use case with
  FUSE in Ubuntu 16.04, as patch was checked in as Ubuntu Sauce in
  Ubuntu 4.4.0-6.21 kernel.

  The use case is:
  1. Create a Docker container.
  2. Inside the container, start the FUSE backend, and mounted fs.
  3. Following step 2 in the container, create a loopback device to map
  a file in the mounted fuse to create a block device, which will be
  available to the whole system.

  It works well before this commit.

  The use case is broken because no matter which namespace losetup runs,
  the real request from loopback device seems always come from init ns,
  thus it will be in different ns running fuse backend. So the request
  will got denied, because the ns running fuse won't able to see the
  things from higher level(level 0 in fact) pid namespace.
  ---
  ApportVersion: 2.14.1-0ubuntu3.21
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: linux (not installed)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature:

  Tags:  trusty
  Uname: Linux 4.4.6 x86_64
  UnreportableReason: The running kernel is not an Ubuntu kernel
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1605344/+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 1566302] Re: Ubuntu 16.04: Suspend freezes the system after upgrade to linux image 4.4.0-16

[Gregory Brancq]

Hi,

I have the Lenovo T440p with integrated intel and nvidia, and I encounter the 
same symptoms than deb2014.
The log is also with  symbols.
It's ramdomly crashed with a black screen or works after hibernating no more 
than 2-3 times.
Moreover, it crashs every time I plug in to the dockstation.
I tried unsuccessfully several kernels.

@deb2014, you says that it's stable with suspend to ram. Could you tell
me the procedure to test?

Regards,
Greg

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

Title:
  Ubuntu 16.04: Suspend freezes the system after upgrade to linux image
  4.4.0-16

Status in linux package in Ubuntu:
  Won't Fix

Bug description:
  I'm using ubuntu 16.04 on a XPS 15 9550.

  Suspend/resume worked flawlessly with linux image 4.4.0-15, and after
  standard upgrade yesterday (5/04/2016) which installed image 4.4.0-16,
  the system freezes when attempting a suspend. I get  no response from
  the system (nor keyboard, nor screen, nor touchpad), but it gets very
  hot, so that it must be running something.

  Booting with 4.4.0-15 makes the suspend to work perfectly.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-extra-4.4.0-16-generic 4.4.0-16.32
  ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6
  Uname: Linux 4.4.0-15-generic x86_64
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  macias 1770 F pulseaudio
  CurrentDesktop: X-Cinnamon
  Date: Tue Apr  5 14:56:17 2016
  HibernationDevice: RESUME=UUID=4180adfa-3852-4a96-86b4-f3696448c743
  InstallationDate: Installed on 2016-03-07 (28 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160304)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 04f3:21d5 Elan Microelectronics Corp. 
   Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp. 
   Bus 001 Device 004: ID 1bcf:2b95 Sunplus Innovation Technology Inc. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. XPS 15 9550
  ProcEnviron:
   LANGUAGE=es_ES
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=es_ES.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-15-generic.efi.signed 
root=UUID=673f4658-75f8-4c01-bcd8-0af860269699 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-15-generic N/A
   linux-backports-modules-4.4.0-15-generic  N/A
   linux-firmware1.157
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/25/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.01.19
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.01.19:bd01/25/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1566302/+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 1607374] [NEW] Cannot mount proc in unprivileged containers if /proc/xen is mounted

[Seth Forshee]

Public bug reported:

SRU Justification

Impact: The xenfs filesystem is traditionally mounted at /proc/xen in
xen guests. This directory doesn't use the special "create proc
mountpoint" interface and thus fails the permanently empty test in
fs_fully_visible(). This causes mounting of proc to fail in user
namespace containers.

Fix: Use the special proc interface to make this a "permanently empty"
directory.

Regression potential: This change will make it impossible to create
files within /proc/xen, but since the directory is only ever used as a
mount point this should not cause any problems.

Original bug report and testing results can be found at
https://github.com/lxc/lxd/issues/2238.

** Affects: linux (Ubuntu)
 Importance: Medium
 Assignee: Seth Forshee (sforshee)
 Status: In Progress

** Affects: linux (Ubuntu Xenial)
 Importance: Medium
 Assignee: Seth Forshee (sforshee)
 Status: In Progress

** Also affects: linux (Ubuntu Xenial)
   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/1607374

Title:
  Cannot mount proc in unprivileged containers if /proc/xen is mounted

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

Bug description:
  SRU Justification

  Impact: The xenfs filesystem is traditionally mounted at /proc/xen in
  xen guests. This directory doesn't use the special "create proc
  mountpoint" interface and thus fails the permanently empty test in
  fs_fully_visible(). This causes mounting of proc to fail in user
  namespace containers.

  Fix: Use the special proc interface to make this a "permanently empty"
  directory.

  Regression potential: This change will make it impossible to create
  files within /proc/xen, but since the directory is only ever used as a
  mount point this should not cause any problems.

  Original bug report and testing results can be found at
  https://github.com/lxc/lxd/issues/2238.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1607374/+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 1605843] Re: Kernel crashes from time to time when using ftrace

[Nikolay Borisov]

I think the fix for this crash is this upstream commit:
8329e818f14926a6040df86b2668568bde342ebf

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

Title:
  Kernel crashes from time to time when using ftrace

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  While performing some tracing suing ftrace-cmd I came across the
  following OOPS:

  [  333.051723] invalid opcode:  [#1] SMP 
  [  333.051742] Modules linked in: drbg ansi_cprng ctr ccm xt_CHECKSUM 
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 
arc4 bridge stp llc ebtable_filter ebtables ath9k_htc ath9k_common ath9k_hw ath 
mac80211 cfg80211 binfmt_misc snd_hda_codec_hdmi dcdbas dell_smm_hwmon 
snd_hda_codec_realtek snd_hda_codec_generic intel_rapl uvcvideo snd_hda_intel 
x86_pkg_temp_thermal intel_powerclamp coretemp videobuf2_vmalloc snd_hda_codec 
videobuf2_memops input_leds videobuf2_v4l2 snd_usb_audio crct10dif_pclmul 
videobuf2_core snd_hda_core v4l2_common crc32_pclmul snd_usbmidi_lib videodev 
snd_hwdep aesni_intel media snd_pcm aes_x86_64 lrw gf128mul glue_helper 
ablk_helper cryptd snd_seq_midi snd_seq_midi_event snd_rawmidi serio_raw 
snd_seq snd_seq_device snd_timer lpc_ich snd ie31200_edac
  [  333.051972]  edac_core soundcore mei_me mei 8250_fintek mac_hid kvm_intel 
ip6t_REJECT nf_reject_ipv6 kvm nf_log_ipv6 irqbypass xt_hl ip6t_rt 
nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_log_ipv4 
nf_log_common xt_LOG xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns 
nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack 
iptable_filter ip_tables parport_pc x_tables ppdev lp parport autofs4 hid_apple 
raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor 
hid_generic usbhid hid raid6_pq libcrc32c raid1 raid0 multipath linear 
dm_mirror dm_region_hash dm_log i915 i2c_algo_bit drm_kms_helper psmouse 
syscopyarea sysfillrect sysimgblt fb_sys_fops e1000e ahci libahci drm ptp
  [  333.052206]  pps_core fjes video
  [  333.052216] CPU: 1 PID: 5616 Comm: trace-cmd Not tainted 4.4.0-31-generic 
#50-Ubuntu
  [  333.052235] Hardware name: Dell Inc. Precision T1650/0X9M3X, BIOS A15 
09/09/2013
  [  333.052254] task: 8804066b1b80 ti: 88040b474000 task.ti: 
88040b474000
  [  333.052272] RIP: 0010:[]  [] 
ftrace_stub+0x0/0x8
  [  333.052296] RSP: 0018:88040b477f00  EFLAGS: 00010286
  [  333.052309] RAX:  RBX: 8800d9a4ec00 RCX: 
88040b477f18
  [  333.052326] RDX: 2000 RSI: 0237d690 RDI: 
8800d9a4ec00
  [  333.052343] RBP: 88040b477f48 R08: 7f89df102cf8 R09: 
0021
  [  333.052360] R10: 000d R11: 0246 R12: 
8800d9a4ec00
  [  333.052377] R13: 0237d690 R14: 2000 R15: 
0237d690
  [  333.052395] FS:  7f89df50f700() GS:88041e24() 
knlGS:
  [  333.052414] CS:  0010 DS:  ES:  CR0: 80050033
  [  333.052428] CR2: 00a78d88 CR3: 0003c3542000 CR4: 
001406e0
  [  333.052445] Stack:
  [  333.052451]  8120d165 8120df35 7fff364487e5 

  [  333.052473]  eee5d05c   
0006
  [  333.052494]  0008 2000 8182db32 
0004
  [  333.052515] Call Trace:
  [  333.052525]  [] ? vfs_read+0x5/0x130
  [  333.052538]  [] ? SyS_read+0x55/0xc0
  [  333.052553]  [] entry_SYSCALL_64_fastpath+0x16/0x71
  [  333.052568] Code: 8b 44 24 48 48 8b 7c 24 70 48 8b 74 24 68 48 8b 54 24 60 
48 8b 4c 24 58 48 8b 44 24 50 48 8b 6c 24 20 48 81 c4 d0 00 00 00 e9 fd  ff 
ff 80 00 00 00 00 9c 55 ff 74 24 18 55 48 89 e5 ff 74 24 
  [  333.052685] RIP  [] ftrace_stub+0x0/0x8
  [  333.052700]  RSP 

  
  All code
  
 0: 8b 44 24 48 mov0x48(%rsp),%eax
 4: 48 8b 7c 24 70  mov0x70(%rsp),%rdi
 9: 48 8b 74 24 68  mov0x68(%rsp),%rsi
 e: 48 8b 54 24 60  mov0x60(%rsp),%rdx
13: 48 8b 4c 24 58  mov0x58(%rsp),%rcx
18: 48 8b 44 24 50  mov0x50(%rsp),%rax
1d: 48 8b 6c 24 20  mov0x20(%rsp),%rbp
22: 48 81 c4 d0 00 00 00add$0xd0,%rsp
29:*e9 fd ff ff ff  jmpq   0x2b <-- trapping 
instruction
2e: 80 00 00addb   $0x0,(%rax)
31: 00 00   add%al,(%rax)
33: 9c  pushfq 
34: 55  push   %rbp
35: ff 74 24 18 pushq  0x18(%rsp)
39: 55  push   %rbp
3a: 48 89 e5mov%rsp,%rbp
3d: ff  .byte 0xff
3e: 74 24   je 0x64

  Code starting with the faulting inst