Bug#917206: linux-image-4.9.0-8-amd64: NULL ptr dereference in xhci_hub_control [xhci_hcd] with USB Mass Storage (Kingston)

[Cyril Brulebois]

Hi Christoph,

Christoph Pfister  (2019-01-02):
> tl;dr: This is a regression introduced in Debian 9.6
> (linux/4.9.130-2); it is caused by [1] and fixed by [2]. Please fix :)
> 
> I'm taking the liberty to hijack this bug because I'm experiencing the
> same issue [3] when powering off a usb3 hdd. The oops is easy to
> reproduce; I've tested the following versions of
> linux-image-4.9.0-8-amd64:
> 
> - 4.9.110-3+deb9u6: works
> - 4.9.130-2 (current stretch): affected
> - 4.9.135-1 (stretch-proposed-updates): affected
> - 4.9.130-2 + manually applying [2]: works

No worries (from my point of view) with hijacking the bug report, esp.
with all the nice pointers! Thanks for tracking that down. :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processed: reassign 914491 to src:linux

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 914491 src:linux 4.18.20-1
Bug #914491 [linux-image-4.18.0-3-amd64] linux-image-4.18.0-3-amd64: Please 
revert the STIBP patch from 4.18.20
Warning: Unknown package 'linux-image-4.18.0-3-amd64'
Bug reassigned from package 'linux-image-4.18.0-3-amd64' to 'src:linux'.
No longer marked as found in versions linux/4.18.20-1.
Ignoring request to alter fixed versions of bug #914491 to the same values 
previously set
Bug #914491 [src:linux] linux-image-4.18.0-3-amd64: Please revert the STIBP 
patch from 4.18.20
Marked as found in versions linux/4.18.20-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
914491: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914491
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: [PATCH v2] deb-pkg: generate correct build dependencies

[Masahiro Yamada]

Hi Riku,



On Wed, Jan 2, 2019 at 6:28 PM  wrote:
>
> From: Riku Voipio 
>
> bison/flex is now needed always for building for kconfig. Some build
> dependencies depend on kernel configuration, enable them as needed:
>
> - libelf-dev when UNWINDER_ORC is set
> - libssl-dev for SYSTEM_TRUSTED_KEYRING
>
> Since the libssl-dev is needed for extract_cert binary, denote with
> :native to install the libssl-dev for the build machines architecture,
> rather than for the architecture of the kernel being built.
>
> Tested-by: Manivannan Sadhasivam 
> Signed-off-by: Riku Voipio 
> ---
> v2: commit message updated
> ---


$ make defconfig && make bindeb-pkg

worked for me, but

$ make allnoconfig && make bindeb-pkg

failed with

dpkg-checkbuilddeps: error: Unmet build dependencies: flex


I do not know why.



The relevant line in debian/control looks as follows,
but I am not sure if trailing commas are causing the problem.



Build-Depends: bc, kmod, cpio, bison, flex , ,















>  scripts/package/mkdebian | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
> index edcad61fe3cd..c858abf4569e 100755
> --- a/scripts/package/mkdebian
> +++ b/scripts/package/mkdebian
> @@ -134,6 +134,8 @@ fi
>
>  mkdir -p debian/
>  echo $debarch > debian/arch
> +extra_build_depends=", $(if_enabled_echo UNWINDER_ORC libelf-dev)"
> +extra_build_depends="$extra_build_depends, $(if_enabled_echo 
> SYSTEM_TRUSTED_KEYRING libssl-dev:native)"
>
>  # Generate a simple changelog template
>  cat < debian/changelog
> @@ -170,7 +172,7 @@ Source: $sourcename
>  Section: kernel
>  Priority: optional
>  Maintainer: $maintainer
> -Build-Depends: bc, kmod, cpio
> +Build-Depends: bc, kmod, cpio, bison, flex $extra_build_depends
>  Homepage: http://www.kernel.org/
>
>  Package: $packagename
> --
> 2.19.2
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2] deb-pkg: generate correct build dependencies

[maximilian attems]

On Wed, Jan 02, 2019 at 07:48:12PM +, Ben Hutchings wrote:
> On Wed, 2019-01-02 at 11:23 +0200, riku.voi...@linaro.org wrote:
> > From: Riku Voipio 
> > 
> > bison/flex is now needed always for building for kconfig. Some build
> > dependencies depend on kernel configuration, enable them as needed:
> > 
> > - libelf-dev when UNWINDER_ORC is set
> > - libssl-dev for SYSTEM_TRUSTED_KEYRING
> > 
> > Since the libssl-dev is needed for extract_cert binary, denote with
> > :native to install the libssl-dev for the build machines
> > architecture,
> > rather than for the architecture of the kernel being built.
> > 
> > Tested-by: Manivannan Sadhasivam 
> > Signed-off-by: Riku Voipio 
> 
> Reviewed-by: Ben Hutchings 

Acked-by: maximilian attems 
 
> > ---
> > v2: commit message updated
> > ---
> >  scripts/package/mkdebian | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
> > index edcad61fe3cd..c858abf4569e 100755
> > --- a/scripts/package/mkdebian
> > +++ b/scripts/package/mkdebian
> > @@ -134,6 +134,8 @@ fi
> >  
> >  mkdir -p debian/
> >  echo $debarch > debian/arch
> > +extra_build_depends=", $(if_enabled_echo UNWINDER_ORC libelf-dev)"
> > +extra_build_depends="$extra_build_depends, $(if_enabled_echo 
> > SYSTEM_TRUSTED_KEYRING libssl-dev:native)"
> >  
> >  # Generate a simple changelog template
> >  cat < debian/changelog
> > @@ -170,7 +172,7 @@ Source: $sourcename
> >  Section: kernel
> >  Priority: optional
> >  Maintainer: $maintainer
> > -Build-Depends: bc, kmod, cpio
> > +Build-Depends: bc, kmod, cpio, bison, flex $extra_build_depends
> >  Homepage: http://www.kernel.org/
> >  
> >  Package: $packagename
> -- 
> Ben Hutchings
> Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
> 
> 

Re: [PATCH v2] deb-pkg: generate correct build dependencies

[Ben Hutchings]

On Wed, 2019-01-02 at 11:23 +0200, riku.voi...@linaro.org wrote:
> From: Riku Voipio 
> 
> bison/flex is now needed always for building for kconfig. Some build
> dependencies depend on kernel configuration, enable them as needed:
> 
> - libelf-dev when UNWINDER_ORC is set
> - libssl-dev for SYSTEM_TRUSTED_KEYRING
> 
> Since the libssl-dev is needed for extract_cert binary, denote with
> :native to install the libssl-dev for the build machines
> architecture,
> rather than for the architecture of the kernel being built.
> 
> Tested-by: Manivannan Sadhasivam 
> Signed-off-by: Riku Voipio 

Reviewed-by: Ben Hutchings 

> ---
> v2: commit message updated
> ---
>  scripts/package/mkdebian | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
> index edcad61fe3cd..c858abf4569e 100755
> --- a/scripts/package/mkdebian
> +++ b/scripts/package/mkdebian
> @@ -134,6 +134,8 @@ fi
>  
>  mkdir -p debian/
>  echo $debarch > debian/arch
> +extra_build_depends=", $(if_enabled_echo UNWINDER_ORC libelf-dev)"
> +extra_build_depends="$extra_build_depends, $(if_enabled_echo 
> SYSTEM_TRUSTED_KEYRING libssl-dev:native)"
>  
>  # Generate a simple changelog template
>  cat < debian/changelog
> @@ -170,7 +172,7 @@ Source: $sourcename
>  Section: kernel
>  Priority: optional
>  Maintainer: $maintainer
> -Build-Depends: bc, kmod, cpio
> +Build-Depends: bc, kmod, cpio, bison, flex $extra_build_depends
>  Homepage: http://www.kernel.org/
>  
>  Package: $packagename
-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer




signature.asc
Description: This is a digitally signed message part

Bug#916670: cryptsetup: ERROR: Couldn't resolve device rootfs

[Ben Hutchings]

Control: tag -1 unreproducible

On Wed, 2019-01-02 at 05:41 +0300, pavel piankov wrote:
> > update-initramfs: Generating /boot/initrd.img-4.18.0-3-amd64
> > cryptsetup: ERROR: Couldn't resolve device rootfs
> > ^^^
> 
> this is due 
> rootfs / rootfs rw 0 0
> line in /etc/mtab
> remove it and the problem no more.

/etc/mtab is supposed to be a symlink to /proc/self/mounts.  I don't
know why it isn't on your system, but that's not a kernel bug.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer




signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#916670: cryptsetup: ERROR: Couldn't resolve device rootfs

[Debian Bug Tracking System]

Processing control commands:

> tag -1 unreproducible
Bug #916670 [src:linux] cryptsetup: ERROR: Couldn't resolve device rootfs
Added tag(s) unreproducible.

-- 
916670: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916670
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#918042: WoL does not work on r8169 (regression since 4.18)

[Marc Haber]

Package: src:linux
Version: 4.20-1~exp1
Severity: normal

Hi,

I frequently send my desktop PC to sleep (suspend-to-ram) and wake it up
from remote when I need to access it. To do so, I use a script on a
banana pi which ends up calling etherwake 54:04:a6:82:21:00. This
has worked reliably up to the last 4.18 release, including the Debian
kernel linux-image-4.18.0-3-amd64 version 4.18.20-2.

In 4.19, this ceased to work and has remained that way up to the kernel
I am reporting this issue on, linux-image-4.20.0-trunk-amd64 version
4.20-1~exp1. I have observed this behavior also on my "own", locally
built kernels of various 4.19 releases and also 4.20. Sorry, I didn't
try any Debian 4.19 kernels, I decided to pursue this issue further
after the regression was also present in 4.20.

I am prepared to try kernel patches or follow other hints in debugging
this. I acknowledge that this is most probably an upstream issue, but I
don't have enough kernel foo to investigate this on an upstream level
(and frankly, I am afraid of doing a bisect between 4.18 and 4.19).

Any hints will be appreciated.

-- Package-specific info:
** Version:
Linux version 4.20.0-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.20-1~exp1 (2018-12-24)

** Command line:
BOOT_IMAGE=/vmlinuz-4.20.0-trunk-amd64 root=/dev/mapper/root ro splash 
console=ttyS0,57600n8 quiet

** Not tainted

** Kernel log:
[  225.803103] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
[  225.803252] sd 1:0:0:0: [sda] Stopping disk
[  225.805950] sd 4:0:0:0: [sdb] Stopping disk
[  225.810535] sd 5:0:0:0: [sdc] Synchronizing SCSI cache
[  225.810750] sd 5:0:0:0: [sdc] Stopping disk
[  229.997427] ACPI: EC: interrupt blocked
[  230.015575] ACPI: Preparing to enter system sleep state S3
[  230.017796] ACPI: EC: event blocked
[  230.017797] ACPI: EC: EC stopped
[  230.017798] PM: Saving platform NVS memory
[  230.017802] Disabling non-boot CPUs ...
[  230.031585] IRQ 17: no longer affine to CPU1
[  230.031600] IRQ 19: no longer affine to CPU1
[  230.032656] smpboot: CPU 1 is now offline
[  230.052563] smpboot: CPU 2 is now offline
[  230.083457] IRQ 24: no longer affine to CPU3
[  230.083479] IRQ 37: no longer affine to CPU3
[  230.084506] smpboot: CPU 3 is now offline
[  230.107073] IRQ 33: no longer affine to CPU4
[  230.108097] smpboot: CPU 4 is now offline
[  230.131161] IRQ 29: no longer affine to CPU5
[  230.131171] IRQ 34: no longer affine to CPU5
[  230.132203] smpboot: CPU 5 is now offline
[  230.137594] ACPI: Low-level resume complete
[  230.137631] ACPI: EC: EC started
[  230.137632] PM: Restoring platform NVS memory
[  230.137646] PCI-DMA: Resuming GART IOMMU
[  230.137647] PCI-DMA: Restoring GART aperture settings
[  230.137652] LVT offset 1 assigned for vector 0x400
[  230.137662] LVT offset 1 assigned
[  230.137908] microcode: CPU0: new patch_level=0x01dc
[  230.137935] Enabling non-boot CPUs ...
[  230.137974] x86: Booting SMP configuration:
[  230.137975] smpboot: Booting Node 0 Processor 1 APIC 0x1
[  230.140530] TSC synchronization [CPU#0 -> CPU#1]:
[  230.140531] Measured 4350120160 cycles TSC warp between CPUs, turning off 
TSC clock.
[  230.140533] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[  230.140536] TSC found unstable after boot, most likely due to broken BIOS. 
Use 'tsc=unstable'.
[  230.140537] sched_clock: Marking unstable (230135957339, 
2389616)<-(230439424037, -29477)
[  231.493902] process: Switch to broadcast mode on CPU1
[  231.494117]  cache: parent cpu1 should not be sleeping
[  231.494207] microcode: CPU1: patch_level=0x01dc
[  231.494380] clocksource: Switched to clocksource hpet
[  230.138878] CPU1 is up
[  230.138902] smpboot: Booting Node 0 Processor 2 APIC 0x2
[  230.142346] process: Switch to broadcast mode on CPU2
[  230.142346]  cache: parent cpu2 should not be sleeping
[  230.142346] microcode: CPU2: patch_level=0x01dc
[  230.142346] CPU2 is up
[  230.142346] smpboot: Booting Node 0 Processor 3 APIC 0x3
[  230.142346] process: Switch to broadcast mode on CPU3
[  230.142346]  cache: parent cpu3 should not be sleeping
[  230.142346] microcode: CPU3: patch_level=0x01dc
[  230.142346] CPU3 is up
[  230.142346] smpboot: Booting Node 0 Processor 4 APIC 0x4
[  230.142346] process: Switch to broadcast mode on CPU4
[  230.142346]  cache: parent cpu4 should not be sleeping
[  230.142346] microcode: CPU4: patch_level=0x01dc
[  230.142346] CPU4 is up
[  230.142346] smpboot: Booting Node 0 Processor 5 APIC 0x5
[  230.142346] process: Switch to broadcast mode on CPU5
[  230.142869]  cache: parent cpu5 should not be sleeping
[  230.142970] microcode: CPU5: patch_level=0x01dc
[  230.143185] CPU5 is up
[  230.149748] ACPI: Waking up from system sleep state S3
[  230.258927] ACPI: EC: interrupt unblocked
[  231.495557] ACPI: EC: event unblocked
[  231.496009] usb usb2: root hub lost power or was reset
[  231.496011] usb usb4: root hub lost power or w

Re: hardening-check can detect whether kernel is protected or not

[Mikhail Morfikov]

On 02/01/2019 17:48, Yves-Alexis Perez wrote:
> On Wed, 2019-01-02 at 17:37 +0100, Mikhail Morfikov wrote:
>> I have one question. Let's say I set the kernel options that are described
>> here[1]. Do I have to use DEB_BUILD_MAINT_OPTIONS or set any additional flags
>> in the debian/rules file to get some extra protection? Does the
>> DEB_BUILD_MAINT_OPTIONS variable do something in the case of building the
>> linux kernel?
> 
> No, DEB_BUILD_MAINT_OPTIONS is not used for that. If you want to tune the
> kernel configuration you need to follow the kernel handbook (
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.3
> )
> 
> Most of the kernel options recommended on the KSPP page are either enabled or
> not relevant for a distribution kernel. There are some left which would be
> nice to have (like some gcc plugins) and unsupported for now, but that's all.
> 
Thanks for the info.




signature.asc
Description: OpenPGP digital signature

Re: hardening-check can detect whether kernel is protected or not

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2019-01-02 at 17:37 +0100, Mikhail Morfikov wrote:
> I have one question. Let's say I set the kernel options that are described 
> here[1]. Do I have to use DEB_BUILD_MAINT_OPTIONS or set any additional flags
> in the debian/rules file to get some extra protection? Does the 
> DEB_BUILD_MAINT_OPTIONS variable do something in the case of building the 
> linux kernel?

No, DEB_BUILD_MAINT_OPTIONS is not used for that. If you want to tune the
kernel configuration you need to follow the kernel handbook (
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.3
)

Most of the kernel options recommended on the KSPP page are either enabled or
not relevant for a distribution kernel. There are some left which would be
nice to have (like some gcc plugins) and unsupported for now, but that's all.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlws628ACgkQ3rYcyPpX
RFuq7wgAjwEGti43/zBpdxYSodwujnyh5CGN9k2KDpKtd4UtEJRP9+jWOT3eFuo3
8lKN+nojE7DuxYSJmW9NgXV95DNh1mx191ADRs3brbtV30dSoVP46EfypD/w4rVR
u2QJEEZueQiR7y1qE1nqfhuNY+OTSTlgeYsHbOQ4S5hyn7Yvu3gUf3QXaMOVybnu
+7sbfc62mnXuvwywYU2H891SSjjDd4yf0YUkr1uWWdhWHMvzBulEsj6s8b0QBvWq
DPJAGKd/CUp66R8DVyfY68G7rCam+lrX4DeK3gpPR1npFyIptMdXin64vXRhkaJr
1vZ0ct5r2p8GB0Un7371YEJOIvaQGw==
=1cPi
-END PGP SIGNATURE-

Processed: bug 918036 is forwarded to https://lore.kernel.org/lkml/20181106054212.GA31768@nautica/

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 918036 https://lore.kernel.org/lkml/20181106054212.GA31768@nautica/
Bug #918036 [src:linux] linux: uptime after reboot wrong (kvm-clock related?)
Set Bug forwarded-to-address to 
'https://lore.kernel.org/lkml/20181106054212.GA31768@nautica/'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
918036: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918036
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 918036

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 918036 + upstream
Bug #918036 [src:linux] linux: uptime after reboot wrong (kvm-clock related?)
Added tag(s) upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
918036: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918036
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)

[Salvatore Bonaccorso]

Hi Thorsten,

On Wed, Jan 02, 2019 at 04:08:23PM +, Thorsten Glaser wrote:
> Package: src:linux
> Version: 4.19.13-1
> Severity: normal
> 
> I’ve just rebooted this VM and get:
> 
> root@ci-busyapps:~ # uptime
>  16:06:57 up 58 days, 21:22,  1 user,  load average: 0.62, 0.98, 0.46
> 
> In syslog, I see this:
> 
> Jan  2 15:55:01 ci-busyapps CRON[3287]: (root) CMD (command -v debian-sa1 > 
> /dev/null && debian-sa1 1 1)
> Jan  2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection 
> rate 1/60s for (smtp:172.26.1.40) at Jan  2 15:52:51
> Jan  2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection 
> count 1 for (smtp:172.26.1.40) at Jan  2 15:52:51
> Jan  2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max cache size 1 
> at Jan  2 15:52:51
> Jan  2 15:57:20 ci-busyapps sensord: sensord stopped
> Jan  2 15:58:05 ci-busyapps dhclient[1031]: DHCPREQUEST of 172.26.1.40 on 
> eth0 to 172.26.100.2 port 67
> Jan  2 15:58:05 ci-busyapps dhclient[1031]: DHCPACK of 172.26.1.40 from 
> 172.26.100.2
> Jan  2 15:58:05 ci-busyapps dhclient[1031]: bound to 172.26.1.40 -- renewal 
> in 19447 seconds.
> Jan  2 15:59:04 ci-busyapps shutdown[7314]: shutting down for system reboot
> Jan  2 15:59:05 ci-busyapps init: Switching to runlevel: 6
> Jan  2 15:59:09 ci-busyapps jenkins: jenkins: client (pid 1579) exited with 
> 143 status 
> Jan  2 15:59:10 ci-busyapps ntpd[1608]: ntp engine exiting
> Jan  2 15:59:10 ci-busyapps ntpd[1607]: Terminating
> Jan  2 15:59:10 ci-busyapps postfix/master[22032]: terminating on signal 15
> Jan  2 15:59:18 ci-busyapps syslogd: exiting on signal 15
> Jan  2 16:00:47 ci-busyapps syslogd (GNU inetutils 1.9.4): restart
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] Linux version 
> 4.19.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 8.2.0 (Debian 
> 8.2.0-13)) #1 SMP Debian 4.19.13-1 (2018-12-30)
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] Command line: 
> BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 
> root=/dev/mapper/vg--ci--busyapps-lv--root ro net.ifnames=0 kaslr nomodeset
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] x86/fpu: x87 FPU will use 
> FXSAVE
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-provided physical RAM 
> map:
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
> 0x-0x0009fbff] usable
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
> 0x0009fc00-0x0009] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
> 0x000f-0x000f] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
> 0x0010-0xdfffdfff] usable
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
> 0xdfffe000-0xdfff] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
> 0xfeffc000-0xfeff] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
> 0xfffc-0x] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
> 0x0001-0x00021fff] usable
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] NX (Execute Disable) 
> protection: active
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] SMBIOS 2.4 present.
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] DMI: Bochs Bochs, BIOS 
> Bochs 01/01/2011
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] Hypervisor detected: KVM
> Jan  2 16:00:47 ci-busyapps vmunix: [0.00] kvm-clock: Using msrs 
> 4b564d01 and 4b564d00
> Jan  2 16:00:47 ci-busyapps vmunix: [5087690.332663] kvm-clock: cpu 0, msr 
> 3ffd7001, primary cpu clock
> Jan  2 16:00:47 ci-busyapps vmunix: [5087690.332663] clocksource: kvm-clock: 
> mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 
> ns
> Jan  2 16:00:47 ci-busyapps vmunix: [5087690.332665] tsc: Detected 3064.488 
> MHz processor

As a datapoint: This sounds familiar in the sense that it was reported
earlier https://lore.kernel.org/lkml/20181106054212.GA31768@nautica/ .

Regards,
Salvatore

Re: hardening-check can detect whether kernel is protected or not

[Mikhail Morfikov]

On 02/01/2019 15:28, Yves-Alexis Perez wrote> the kernel is not a standard ELF 
binary, so you can't really run hardening-
> check on it and expect sound results.
> 
> Yes, the kernel has some protection/hardening (see for example the work done
> by the Kernel Self Protection Project).
I have one question. Let's say I set the kernel options that are described 
here[1]. Do I have to use DEB_BUILD_MAINT_OPTIONS or set any additional flags
in the debian/rules file to get some extra protection? Does the 
DEB_BUILD_MAINT_OPTIONS variable do something in the case of building the 
linux kernel?

[1] 
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings



signature.asc
Description: OpenPGP digital signature

Bug#917206: marked as done (linux-image-4.9.0-8-amd64: NULL ptr dereference in xhci_hub_control [xhci_hcd] with USB Mass Storage (Kingston))

[Debian Bug Tracking System]

Your message dated Wed, 2 Jan 2019 17:24:12 +0100
with message-id <20190102162412.GA13145@eldamar.local>
and subject line Re: Bug#917206: linux-image-4.9.0-8-amd64: NULL ptr 
dereference in xhci_hub_control [xhci_hcd] with USB Mass Storage (Kingston)
has caused the Debian Bug report #917206,
regarding linux-image-4.9.0-8-amd64: NULL ptr dereference in xhci_hub_control 
[xhci_hcd] with USB Mass Storage (Kingston)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
917206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917206
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 4.9.135-1
Severity: important

Hi kernel team,

I've reproduced this kernel BUG a few times already, with simple
operations on various USB devices like brand new Kingston DataTraveler
3.0 (8, 16 or 32GB):

[ 1992.998316] BUG: unable to handle kernel NULL pointer dereference at 
001c
[ 1992.998372] IP: [] xhci_hub_control+0x19cf/0x1c10 
[xhci_hcd]


Steps to reproduce:
 - plug a USB device either on an port of the laptop's base, or on the
   USB3 port on the laptop;
 - zero out the /dev/sd? that pops up when the USB device is inserted,
   to make sure any preexisting partitioning is no factor (did that on
   the full device first time, then decided to only wipe out the
   beginning of the block device);
 - partprobe to make extra sure;
 - create a partition table with fdisk (not sure I did anything
   specific here, can double check, probably went for the default);
 - create a single partition with all free space;
 - assign type 'b' (W95 FAT32) to it;
 - use mkfs.vfat -F 32 on the new block device.

At this point, said block device appears in Xfce's file manager, Thunar.
With or without having copied a few files to it, clicking the “eject”
button is sufficient to trigger this BUG. When that happens, input
devices work for a few seconds but it isn't possible to get much done;
an already-running dmesg -w wouldn't show any traces. Only an UEFI
glitch at reboot time would make half a screen appear with a fuzzied
trace…

Here's a capture obtained through netconsole, enabled a bit before
triggering the crash:

[ 1745.198739] console [netcon_ext0] disabled
[ 1745.198753] console [netcon0] disabled
[ 1748.295633] netpoll: netconsole: local port 6665
[ 1748.295637] netpoll: netconsole: local IPv4 address 0.0.0.0
[ 1748.295639] netpoll: netconsole: interface 'eth0'
[ 1748.295640] netpoll: netconsole: remote port 
[ 1748.295642] netpoll: netconsole: remote IPv4 address 192.168.0.1
[ 1748.295644] netpoll: netconsole: remote ethernet address 
d8:cb:8a:98:29:59
[ 1748.295647] netpoll: netconsole: local IP 192.168.0.21
[ 1748.295702] console [netcon0] enabled
[ 1748.295704] netconsole: network logging started
[ 1799.971353] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
[ 1800.002355] usb 2-2: New USB device found, idVendor=0951, idProduct=1666
[ 1800.002373] usb 2-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 1800.002380] usb 2-2: Product: DataTraveler 3.0
[ 1800.002386] usb 2-2: Manufacturer: Kingston
[ 1800.002392] usb 2-2: SerialNumber: 60A44C413BF2F270B62830FF
[ 1800.017208] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 1800.017367] scsi host3: usb-storage 2-2:1.0
[ 1801.020259] scsi 3:0:0:0: Direct-Access Kingston DataTraveler 3.0
  PQ: 0 ANSI: 6
[ 1801.021997] sd 3:0:0:0: Attached scsi generic sg1 type 0
[ 1801.022211] sd 3:0:0:0: [sdb] 30218842 512-byte logical blocks: (15.5 
GB/14.4 GiB)
[ 1801.022788] sd 3:0:0:0: [sdb] Write Protect is off
[ 1801.022819] sd 3:0:0:0: [sdb] Mode Sense: 4f 00 00 00
[ 1801.023312] sd 3:0:0:0: [sdb] Write cache: disabled, read cache: 
enabled, doesn't support DPO or FUA
[ 1801.026302]  sdb: sdb1
[ 1801.027383] sd 3:0:0:0: [sdb] Attached SCSI removable disk
[ 1884.87] device eth0 left promiscuous mode
[ 1901.864615]  sdb: sdb1
[ 1939.154007] usb 2-2: USB disconnect, device number 4
[ 1941.618308] usb 2-2: new SuperSpeed USB device number 5 using xhci_hcd
[ 1941.649852] usb 2-2: New USB device found, idVendor=0951, idProduct=1666
[ 1941.649863] usb 2-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 1941.649866] usb 2-2: Product: DataTraveler 3.0
[ 1941.649869] usb 2-2: Manufacturer: Kingston
[ 1941.649872] usb 2-2: SerialNumber: 60A44C413BF2F270B62830FF
[ 1941.659124] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 1941.659303]

Bug#917206: linux-image-4.9.0-8-amd64: NULL ptr dereference in xhci_hub_control [xhci_hcd] with USB Mass Storage (Kingston)

[Salvatore Bonaccorso]

Source: linux
Source-Version: 4.9.144-1

Hi Christoph,

On Wed, Jan 02, 2019 at 12:29:02PM +0100, Christoph Pfister wrote:
> found 917206 4.9.130-2
> thanks
> 
> tl;dr: This is a regression introduced in Debian 9.6
> (linux/4.9.130-2); it is caused by [1] and fixed by [2]. Please fix :)
> 
> I'm taking the liberty to hijack this bug because I'm experiencing the
> same issue [3] when powering off a usb3 hdd. The oops is easy to
> reproduce; I've tested the following versions of
> linux-image-4.9.0-8-amd64:
> 
> - 4.9.110-3+deb9u6: works
> - 4.9.130-2 (current stretch): affected
> - 4.9.135-1 (stretch-proposed-updates): affected
> - 4.9.130-2 + manually applying [2]: works

So this should be fixed in 4.9.136 upstrean and the change included in
the 4.9.144-1 upload which is pending in stable-new, and thus the next
increment for stretch-proposed-updates and the next point release.

Thanks for your triaging work and pin-pointing the fix!

Regards,
Salvatore

Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)

[Thorsten Glaser]

Package: src:linux
Version: 4.19.13-1
Severity: normal

I’ve just rebooted this VM and get:

root@ci-busyapps:~ # uptime
 16:06:57 up 58 days, 21:22,  1 user,  load average: 0.62, 0.98, 0.46

In syslog, I see this:

Jan  2 15:55:01 ci-busyapps CRON[3287]: (root) CMD (command -v debian-sa1 > 
/dev/null && debian-sa1 1 1)
Jan  2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection 
rate 1/60s for (smtp:172.26.1.40) at Jan  2 15:52:51
Jan  2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection 
count 1 for (smtp:172.26.1.40) at Jan  2 15:52:51
Jan  2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max cache size 1 
at Jan  2 15:52:51
Jan  2 15:57:20 ci-busyapps sensord: sensord stopped
Jan  2 15:58:05 ci-busyapps dhclient[1031]: DHCPREQUEST of 172.26.1.40 on eth0 
to 172.26.100.2 port 67
Jan  2 15:58:05 ci-busyapps dhclient[1031]: DHCPACK of 172.26.1.40 from 
172.26.100.2
Jan  2 15:58:05 ci-busyapps dhclient[1031]: bound to 172.26.1.40 -- renewal in 
19447 seconds.
Jan  2 15:59:04 ci-busyapps shutdown[7314]: shutting down for system reboot
Jan  2 15:59:05 ci-busyapps init: Switching to runlevel: 6
Jan  2 15:59:09 ci-busyapps jenkins: jenkins: client (pid 1579) exited with 143 
status 
Jan  2 15:59:10 ci-busyapps ntpd[1608]: ntp engine exiting
Jan  2 15:59:10 ci-busyapps ntpd[1607]: Terminating
Jan  2 15:59:10 ci-busyapps postfix/master[22032]: terminating on signal 15
Jan  2 15:59:18 ci-busyapps syslogd: exiting on signal 15
Jan  2 16:00:47 ci-busyapps syslogd (GNU inetutils 1.9.4): restart
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] Linux version 4.19.0-1-amd64 
(debian-kernel@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP 
Debian 4.19.13-1 (2018-12-30)
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 
root=/dev/mapper/vg--ci--busyapps-lv--root ro net.ifnames=0 kaslr nomodeset
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] x86/fpu: x87 FPU will use 
FXSAVE
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-provided physical RAM 
map:
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x-0x0009fbff] usable
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x0009fc00-0x0009] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x000f-0x000f] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x0010-0xdfffdfff] usable
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0xdfffe000-0xdfff] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0xfeffc000-0xfeff] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0xfffc-0x] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x0001-0x00021fff] usable
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] NX (Execute Disable) 
protection: active
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] SMBIOS 2.4 present.
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] DMI: Bochs Bochs, BIOS Bochs 
01/01/2011
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] Hypervisor detected: KVM
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] kvm-clock: Using msrs 
4b564d01 and 4b564d00
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.332663] kvm-clock: cpu 0, msr 
3ffd7001, primary cpu clock
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.332663] clocksource: kvm-clock: 
mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.332665] tsc: Detected 3064.488 MHz 
processor
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334831] e820: update [mem 
0x-0x0fff] usable ==> reserved
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334833] e820: remove [mem 
0x000a-0x000f] usable
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334837] last_pfn = 0x22 
max_arch_pfn = 0x4
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334862] MTRR default type: 
write-back
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334863] MTRR fixed ranges enabled:
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334864]   0-9 write-back
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334865]   A-B uncachable
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334866]   C-F write-protect
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334866] MTRR variable ranges 
enabled:
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334867]   0 base 00E000 mask 
FFE000 uncachable
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334868]   1 disabled
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334868]   2 disabled
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334869]   3 disabled
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334869]   4 disabled
Jan  2 16:00:47 ci-busyapps vmunix:

Re: hardening-check can detect whether kernel is protected or not

[Ian Campbell]

On Wed, 2019-01-02 at 03:08 +0100, Mikhail Morfikov wrote:
> Also how to get "not stripped" instead of "stripped" kernel?

It is available as the file `vmlinux` at the root of the source tree
after building, if you still have access to that.

There is also the `linux-image-$(uname -r)-dbg` packages which contains
./usr/lib/debug/boot/vmlinux-$(uname -r)` which I think (but am not
entirely sure) is that same binary.

That said, Yves-Alexis is correct that despite being an ELF binary the
kernel is in some ways a bit of a special case, so one shouldn't
necessarily expect tools intended for normal userspace ELF files to
DTRT with it.

Ian.

Re: hardening-check can detect whether kernel is protected or not

[Mikhail Morfikov]

On 02/01/2019 16:08, Ian Campbell wrote:
> It is available as the file `vmlinux` at the root of the source tree
> after building, if you still have access to that.
Yes, it is.

> That said, Yves-Alexis is correct that despite being an ELF binary the
> kernel is in some ways a bit of a special case, so one shouldn't
> necessarily expect tools intended for normal userspace ELF files to
> DTRT with it.
Thanks for the info.





signature.asc
Description: OpenPGP digital signature

Re: hardening-check can detect whether kernel is protected or not

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2019-01-02 at 03:08 +0100, Mikhail Morfikov wrote:
> So does the kernel is protected or not? If yes, why hardening-check can't 
> detect it?
> Also how to get "not stripped" instead of "stripped" kernel?

Hi,

the kernel is not a standard ELF binary, so you can't really run hardening-
check on it and expect sound results.

Yes, the kernel has some protection/hardening (see for example the work done
by the Kernel Self Protection Project).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwsyqUACgkQ3rYcyPpX
RFtdiAgAvD9bj/rTlhbHMOkSQQbgoAcpksqIFJQ9HaCMVjDwb6RWc3Dz0IQItJnu
nj2tLZ6An8LJXo5oAoMTCBvBvWGt4/NsedYdVa1Q/610llWJqHg/VfMR4TZaoN8J
0ZWCGD2qwAMx5MZYJ7GQYlXqRpBp+aRvdHd3+DlDo7O+vEKuoQb0bXYolqkgnV4L
UQGgtbCjVfE7V3/pmfBOMBk6ZhpxilLROmFTtL5abtNh81T6P+sOaFKfOjRcufE3
Tmb7qqK9IRJLL48WUtwX5mXyWl/TOTaig23ESfwWOvmCy1pGvh4fERpY9k3W9Y2T
D9iXxQ4nN6yBUu9PXxs76h/IglBEVg==
=ORnQ
-END PGP SIGNATURE-

Processed: Re: linux-image-4.9.0-8-amd64: NULL ptr dereference in xhci_hub_control [xhci_hcd] with USB Mass Storage (Kingston)

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 917206 4.9.130-2
Bug #917206 [src:linux] linux-image-4.9.0-8-amd64: NULL ptr dereference in 
xhci_hub_control [xhci_hcd] with USB Mass Storage (Kingston)
Marked as found in versions linux/4.9.130-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
917206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917206
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#917206: linux-image-4.9.0-8-amd64: NULL ptr dereference in xhci_hub_control [xhci_hcd] with USB Mass Storage (Kingston)

[Christoph Pfister]

found 917206 4.9.130-2
thanks

tl;dr: This is a regression introduced in Debian 9.6
(linux/4.9.130-2); it is caused by [1] and fixed by [2]. Please fix :)

I'm taking the liberty to hijack this bug because I'm experiencing the
same issue [3] when powering off a usb3 hdd. The oops is easy to
reproduce; I've tested the following versions of
linux-image-4.9.0-8-amd64:

- 4.9.110-3+deb9u6: works
- 4.9.130-2 (current stretch): affected
- 4.9.135-1 (stretch-proposed-updates): affected
- 4.9.130-2 + manually applying [2]: works

Thanks,

Christoph


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/usb/host?h=linux-4.9.y&id=2679c2231bc3fb260f74e1faf7d6810427b1fc6e

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/usb/host?h=linux-4.9.y&id=52f305530ab6e5915b5e5ee0cb9525df42f2b691

[3]

kernel: usb 7-2: USB disconnect, device number 4
kernel: BUG: unable to handle kernel NULL pointer dereference at
001c
kernel: IP: [] xhci_hub_control+0x1a13/0x1c50 [xhci_hcd]
kernel: PGD 0
kernel:
kernel: Oops:  [#1] SMP
kernel: Modules linked in: cpufreq_powersave cpufreq_userspace
cpufreq_conservative nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter
ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
iptable_filter edac_mce_amd edac_core kvm_amd
kernel:  glue_helper lrw gf128mul ablk_helper cryptd ahci libahci
xhci_pci xhci_hcd i2c_piix4 ohci_hcd libata ehci_pci ehci_hcd scsi_mod
usbcore usb_common r8169 mii
kernel: CPU: 0 PID: 138 Comm: kworker/0:3 Not tainted 4.9.0-8-amd64 #1
Debian 4.9.130-2
kernel: Hardware name: Gigabyte Technology Co., Ltd. To be filled by
O.E.M./F2A88XM-HD3, BIOS F7 07/09/2014
kernel: Workqueue: usb_hub_wq hub_event [usbcore]
kernel: task: 8e3435468100 task.stack: ae9040928000
kernel: RIP: 0010:[]  []
xhci_hub_control+0x1a13/0x1c50 [xhci_hcd]
kernel: RSP: 0018:ae904092ba90  EFLAGS: 00010086
kernel: RAX: 8e3435552000 RBX: 8e34354dc000 RCX: 
kernel: RDX: 0060 RSI: 1261 RDI: 8e34354ba284
kernel: RBP: ffed R08: 0008 R09: 0001
kernel: R10: 0001 R11: 0212 R12: 0001
kernel: R13: 8e34354ba000 R14: 8e34354ba284 R15: 0002
kernel: FS:  () GS:8e343ec0()
knlGS:
kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 001c CR3: 0001365a4000 CR4: 000406f0
kernel: Stack:
kernel:  00ff90625600 c6542f720005 0002 8e34
kernel:  0005  8e34354ba238 907e
kernel:  8e343ac00302 4092bba0 8e3435d28e40 8e343561
kernel: Call Trace:
kernel:  [] ? mempolicy_nodemask_intersects+0x10/0x70
kernel:  [] ? ep_poll_callback+0x106/0x230
kernel:  [] ? usb_hcd_submit_urb+0x2aa/0xaf0 [usbcore]
kernel:  [] ? lock_timer_base+0x74/0x90
kernel:  [] ? __internal_add_timer+0x1a/0x50
kernel:  [] ? add_timer+0x110/0x270
kernel:  [] ? usb_start_wait_urb+0x6d/0x170 [usbcore]
kernel:  [] ? usb_release_interface_cache+0x32/0x50 [usbcore]
kernel:  [] ? usb_control_msg+0xdd/0x140 [usbcore]
kernel:  [] ? device_release+0x30/0x90
kernel:  [] ? set_port_feature+0x44/0x50 [usbcore]
kernel:  [] ? hub_port_disable+0xc9/0x140 [usbcore]
kernel:  [] ? hub_event+0xd8b/0x15c0 [usbcore]
kernel:  [] ? __switch_to_asm+0x34/0x70
kernel:  [] ? __switch_to_asm+0x40/0x70
kernel:  [] ? process_one_work+0x18a/0x420
kernel:  [] ? worker_thread+0x4d/0x490
kernel:  [] ? process_one_work+0x420/0x420
kernel:  [] ? kthread+0xd9/0xf0
kernel:  [] ? kthread_park+0x60/0x60
kernel:  [] ? ret_from_fork+0x44/0x70
kernel: Code: e9 49 f8 ff ff 45 31 e4 eb 11 49 83 c4 01 49 81 fc 00 01
00 00 0f 84 c3 f2 ff ff 4b 8b 84 e5 08 04 00 00 48 85 c0 74 e2 48 8b
08 <83> 79 1c 04 40 0f 96 c6 83 bb a0 00 00 00 3f 0f 9f c1 40 38 ce
kernel: RIP  [] xhci_hub_control+0x1a13/0x1c50 [xhci_hcd]
kernel:  RSP 
kernel: CR2: 001c
kernel: ---[ end trace 8be8c1ab53920c10 ]---

[PATCH v2] deb-pkg: generate correct build dependencies

[riku . voipio]

From: Riku Voipio 

bison/flex is now needed always for building for kconfig. Some build
dependencies depend on kernel configuration, enable them as needed:

- libelf-dev when UNWINDER_ORC is set
- libssl-dev for SYSTEM_TRUSTED_KEYRING

Since the libssl-dev is needed for extract_cert binary, denote with
:native to install the libssl-dev for the build machines architecture,
rather than for the architecture of the kernel being built.

Tested-by: Manivannan Sadhasivam 
Signed-off-by: Riku Voipio 
---
v2: commit message updated
---
 scripts/package/mkdebian | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
index edcad61fe3cd..c858abf4569e 100755
--- a/scripts/package/mkdebian
+++ b/scripts/package/mkdebian
@@ -134,6 +134,8 @@ fi
 
 mkdir -p debian/
 echo $debarch > debian/arch
+extra_build_depends=", $(if_enabled_echo UNWINDER_ORC libelf-dev)"
+extra_build_depends="$extra_build_depends, $(if_enabled_echo 
SYSTEM_TRUSTED_KEYRING libssl-dev:native)"
 
 # Generate a simple changelog template
 cat < debian/changelog
@@ -170,7 +172,7 @@ Source: $sourcename
 Section: kernel
 Priority: optional
 Maintainer: $maintainer
-Build-Depends: bc, kmod, cpio
+Build-Depends: bc, kmod, cpio, bison, flex $extra_build_depends
 Homepage: http://www.kernel.org/
 
 Package: $packagename
-- 
2.19.2

Bug#918009: firmware-amd-graphics: please add amdgpu firmware for kaveri

[Abderrahim Kitouni]

Package: firmware-amd-graphics
Version: 20181218-1
Severity: important

Dear Maintainer,

Kaveri APUs, along with other SI and CIK parts, still uses the radeon driver
by default. They can also use the amdgpu driver by setting some options.

In linux 4.19 at least, the amdgpu driver doesn't load the firmware in
radeon/kaveri* anymore, and expect it to be found in amdgpu/kaveri* instead.

Looking at the linux-firmware repository, it seems that the firmware is
different. For instance:

$ sha1sum */kaveri_pfp.bin 
bddd0dda7153a549602b2b339c7f2de507815bc8  amdgpu/kaveri_pfp.bin
d0033d1be4f137d7ec96c9ab2b4a2976d6b4c9f3  radeon/kaveri_pfp.bin


I think other hardware from those families deserve the same treatment. If I'm
not mistaken, this includes bonaire, hainan, hawaii, kabini, mullins, oland,
tahiti and cape verde.


Cheers,

Abderrahim

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.132

-- no debconf information

Bug#886292: [n...@nyet.org: Re: Bug#887045: iwlwifi: TX_STATUS_FAIL_DEST_PS at iwlwifi/mvm/tx.c:1363 using hostapd]

[Salvatore Bonaccorso]

- Forwarded message from Nye Liu  -

Unfortunately, the bug is not fixed in 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1
(2018-12-22) x86_64 GNU/Linux

[297269.085315] WARNING: CPU: 1 PID: 451 at
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1431 iwl_mvm_rx_tx_cmd+0x1e6/0x650
[iwlmvm]
[297269.085321] Modules linked in: ufs qnx4 hfsplus hfs minix ntfs vfat msdos
fat jfs xfs ext4 mbcache jbd2 fscrypto ecb dm_mod ctr ccm fuse xt_CHECKSUM tun
ipt_REJECT nf_reject_ipv4 sctp ipt_MASQUERADE nf_conntrack_netlink xfr
m_user xfrm_algo xt_addrtype br_netfilter ebtable_filter devlink ebtables
iptable_nat sit tunnel4 ip_tunnel sch_sfq cls_fw sch_htb nft_chain_route_ipv6
xt_conntrack ip6t_REJECT nf_reject_ipv6 nft_chain_route_ipv4 xt_multiport x
t_dscp xt_mark nft_counter nft_chain_nat_ipv4 nf_nat_ipv4 xt_nat nf_nat
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_tcpudp nft_compat nf_tables
nfnetlink binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_gene
ric bridge stp llc intel_rapl arc4 x86_pkg_temp_thermal intel_powerclamp
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul iwlmvm
[297269.085414] btusb ghash_clmulni_intel btrtl btbcm btintel intel_cstate
mac80211 intel_uncore bluetooth intel_rapl_perf sg pcspkr snd_hda_intel i915
iTCO_wdt iwlwifi iTCO_vendor_support snd_hda_codec jitterentropy_rng joyde
v snd_hda_core cfg80211 snd_hwdep snd_pcm_oss evdev snd_mixer_oss drbg usblp
ansi_cprng drm_kms_helper ecdh_generic mei_me snd_pcm mei rfkill snd_timer
crc16 drm snd soundcore video acpi_pad button pcc_cpufreq squashfs loop nct
6775 hwmon_vid coretemp parport_pc ppdev lp parport ip_tables x_tables autofs4
btrfs xor zstd_decompress zstd_compress xxhash raid6_pq libcrc32c
crc32c_generic hid_generic usbhid hid sd_mod uas usb_storage crc32c_intel
aesni_in
tel ahci xhci_pci nvme libahci xhci_hcd aes_x86_64 crypto_simd cryptd
glue_helper libata i2c_i801 e1000e igb usbcore scsi_mod nvme_core
[297269.085518] i2c_algo_bit dca usb_common
[297269.085530] CPU: 1 PID: 451 Comm: irq/136-iwlwifi Tainted: G W
4.19.0-1-amd64 #1 Debian 4.19.12-1
[297269.085535] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./H270M-ITX/ac, BIOS P2.00 03/29/2017
[297269.085554] RIP: 0010:iwl_mvm_rx_tx_cmd+0x1e6/0x650 [iwlmvm]
[297269.085560] Code: b6 6c 24 0a 48 8b 5c 24 28 c6 44 24 13 00 41 8d 45 ff 66
89 44 24 10 48 8d 44 24 28 48 39 c3 0f 85 ef 00 00 00 e9 72 02 00 00 <0f> 0b
81 4b 28 00 01 00 00 45 31 f6 49 8b 47 10 48 8b b0 d0 03 00
[297269.085565] RSP: 0018:af7b01e4fd38 EFLAGS: 00010246
[297269.085571] RAX: 8f03e68a8d01 RBX: 8f01981b5900 RCX:
00173bcd
[297269.085576] RDX: 00173bcc RSI: 8f041eea6600 RDI:
f603509a2a00
[297269.085580] RBP: 8f01983c5000 R08: 8f01981b5930 R09:
c0efa022
[297269.085584] R10: 8f4f7240 R11: 00be R12:
8f041a5ec866
[297269.085588] R13: 0088 R14: 05be R15:
8f04194b9548
[297269.085594] FS: () GS:8f041ee8()
knlGS:
[297269.085599] CS: 0010 DS:  ES:  CR0: 80050033
[297269.085603] CR2: 7f11fd302a70 CR3: 0003f500a006 CR4:
003606e0
[297269.085607] DR0:  DR1:  DR2:

[297269.085612] DR3:  DR6: fffe0ff0 DR7:
0400
[297269.085615] Call Trace:
[297269.085636] iwl_pcie_rx_handle+0x239/0x860 [iwlwifi]
[297269.085654] iwl_pcie_irq_handler+0x183/0x6b0 [iwlwifi]
[297269.085662] ? irq_finalize_oneshot.part.43+0x100/0x100
[297269.085669] irq_thread_fn+0x1f/0x60
[297269.085675] irq_thread+0xe7/0x170
[297269.085682] ? irq_forced_thread_fn+0x70/0x70
[297269.085689] ? irq_thread_check_affinity+0xd0/0xd0
[297269.085694] kthread+0x112/0x130
[297269.085700] ? kthread_bind+0x30/0x30
[297269.085709] ret_from_fork+0x35/0x40
[297269.085715] ---[ end trace 46da582480566ecd ]---
[399944.920816] iwlwifi :03:00.0: Queue 8 is active on fifo 3 and stuck
for 1 ms. SW [180, 181] HW [180, 181] FH TRB=0x080309067
[399944.920877] iwlwifi :03:00.0: Microcode SW error detected. Restarting
0x200.
[399944.921007] iwlwifi :03:00.0: Start IWL Error Log Dump:
[399944.921013] iwlwifi :03:00.0: Status: 0x0100, count: 6
[399944.921018] iwlwifi :03:00.0: Loaded firmware version: 29.1044073957.0
[399944.921025] iwlwifi :03:00.0: 0x0084 | NMI_INTERRUPT_UNKNOWN
[399944.921030] iwlwifi :03:00.0: 0x02E0 | trm_hw_status0
[399944.921036] iwlwifi :03:00.0: 0x | trm_hw_status1
[399944.921041] iwlwifi :03:00.0: 0x00043D54 | branchlink2
[399944.921046] iwlwifi :03:00.0: 0x0004AFA6 | interruptlink1
[399944.921051] iwlwifi :03:00.0: 0x0004AFA6 | interruptlink2
[399944.921056] iwlwifi :03:00.0: 0x | data1
[399944.921061] iwlwifi :03:00.0: 0x0080 | data2
[399944.921066] iwlwifi :03:00.0: 0x0703 | data3
[399944.921071] iwlwifi :03:00.0: 0x | beacon time
[399944.921076] iwlwifi :03:00.0: 0

Processed: unarchiving 886292

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> unarchive 886292
Bug #886292 {Done: Ben Hutchings } [src:linux] (no 
subject)
Unarchived Bug 886292
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
886292: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886292
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: reopening 886292

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reopen 886292
Bug #886292 {Done: Ben Hutchings } [src:linux] (no 
subject)
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions linux/4.18.8-1 and linux/4.19~rc3-1~exp1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
886292: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886292
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: reopening 887045

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reopen 887045
Bug #887045 {Done: Ben Hutchings } [src:linux] iwlwifi: 
TX_STATUS_FAIL_DEST_PS at iwlwifi/mvm/tx.c:1363 using hostapd
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions linux/4.19~rc3-1~exp1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
887045: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887045
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems