Re: linux 4.6 FTBFS on alpha

2016-05-04 Thread Helge Deller 
On 05.05.2016 03:17, Ben Hutchings wrote:
> There's a silly type error in an alpha-specific module that now breaks
> the build:
> 
> /«PKGBUILDDIR»/fs/binfmt_em86.c: In function 'load_em86':
> /«PKGBUILDDIR»/fs/binfmt_em86.c:73:35: error: passing argument 2 of 
> 'copy_strings_kernel' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>retval = copy_strings_kernel(1, _arg, bprm);
>^
> In file included from /«PKGBUILDDIR»/fs/binfmt_em86.c:14:0:
> /«PKGBUILDDIR»/include/linux/binfmts.h:116:12: note: expected 'const char * 
> const*' but argument is of type 'char **'
>  extern int copy_strings_kernel(int argc, const char *const *argv,
> ^
> /«PKGBUILDDIR»/fs/binfmt_em86.c:77:34: error: passing argument 2 of 
> 'copy_strings_kernel' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   retval = copy_strings_kernel(1, _name, bprm);
>   ^
> In file included from /«PKGBUILDDIR»/fs/binfmt_em86.c:14:0:
> /«PKGBUILDDIR»/include/linux/binfmts.h:116:12: note: expected 'const char * 
> const*' but argument is of type 'char **'
>  extern int copy_strings_kernel(int argc, const char *const *argv,
> ^
> 
> The conversion is safe but the C standard says it requires a cast.
> This can easily be fixed by adding the cast, but I also wonder why we
> still build this module.  Even the Kconfig text says it's redundant
> with binfmt_misc.  What do you think?

I don't know if it being used, but it seems that systemd takes care 
of autoloading binfmt_misc automatically, so IMHO I agree that it should
be safe to simply disable binfmt_em86 from the debian alpha kernel.

Question to the alpha kernel maintainers: Maybe binfmt_em86 
should simply be dropped from the kernel source completely?  

Helge

Re: linux 4.6 FTBFS on hppa

2016-05-04 Thread Helge Deller 
Hi Ben,

On 05.05.2016 03:29, Ben Hutchings wrote:
> Building linux 4.6~rc5-1~exp1 on hppa failed with:
> 
> hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x51c): cannot reach 
> register_net_sysctl
> net/built-in.o: In function `sysctl_core_init':
> net/core/sysctl_net_core.o:(.init.text+0x51c): relocation truncated to fit: 
> R_PARISC_PCREL22F against symbol `register_net_sysctl' defined in 
> .text.register_net_sysctl section in net/built-in.o
> hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x3298): cannot reach 
> register_net_sysctl
> net/built-in.o: In function `ip_static_sysctl_init':
> (.init.text+0x3298): relocation truncated to fit: R_PARISC_PCREL22F against 
> symbol `register_net_sysctl' defined in .text.register_net_sysctl section in 
> net/built-in.o
> hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x3404): cannot reach 
> register_net_sysctl
> net/built-in.o: In function `ipfrag_init':
> (.init.text+0x3404): relocation truncated to fit: R_PARISC_PCREL22F against 
> symbol `register_net_sysctl' defined in .text.register_net_sysctl section in 
> net/built-in.o
> hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x4c50): cannot reach 
> register_net_sysctl
> net/built-in.o: In function `sysctl_ipv4_init':
> net/ipv4/sysctl_net_ipv4.o:(.init.text+0x4c50): relocation truncated to fit: 
> R_PARISC_PCREL22F against symbol `register_net_sysctl' defined in 
> .text.register_net_sysctl section in net/built-in.o
> hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x4c88): cannot reach 
> unregister_net_sysctl_table
> net/ipv4/sysctl_net_ipv4.o:(.init.text+0x4c88): relocation truncated to fit: 
> R_PARISC_PCREL22F against symbol `unregister_net_sysctl_table' defined in 
> .text.unregister_net_sysctl_table section in net/built-in.o
> hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x8b74): cannot reach 
> register_net_sysctl
> net/built-in.o: In function `ipv6_frag_init':
> (.init.text+0x8b74): relocation truncated to fit: R_PARISC_PCREL22F against 
> symbol `register_net_sysctl' defined in .text.register_net_sysctl section in 
> net/built-in.o
> hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x8c5c): cannot reach 
> unregister_net_sysctl_table
> net/built-in.o: In function `ipv6_frag_init':
> (.init.text+0x8c5c): relocation truncated to fit: R_PARISC_PCREL22F against 
> symbol `unregister_net_sysctl_table' defined in 
> .text.unregister_net_sysctl_table section in net/built-in.o
> 
> It looks like we need to enable CONFIG_MLONGCALLS again (or change some
> built-in things to modules, but I doubt there is much to be gained
> there).

Since 4.6~rc3-1~exp1 built successfully, I'm wondering if maybe something 
changed in the generic debian configs (or in the upstream kernel source)
which could have led to this breakage?

> It was previously disabled as you requested in bug #733897.

Yes, but I tend to think that you are probably right to simply turn 
CONFIG_MLONGCALLS back on again.
I do have kernel patches queued for kernel 4.7 which enable FTRACE support,
and those will require CONFIG_MLONGCALLS most likely anyway then.
Furthermore I just checked and I'm building my own test kernels usually with
CONFIG_MLONGCALLS too, so in the long run we will probably not be able
without this option.

Can you turn CONFIG_MLONGCALLS back on for the next upload?

Helge

linux 4.6 FTBFS on hppa

2016-05-04 Thread Ben Hutchings 
Building linux 4.6~rc5-1~exp1 on hppa failed with:

hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x51c): cannot reach 
register_net_sysctl
net/built-in.o: In function `sysctl_core_init':
net/core/sysctl_net_core.o:(.init.text+0x51c): relocation truncated to fit: 
R_PARISC_PCREL22F against symbol `register_net_sysctl' defined in 
.text.register_net_sysctl section in net/built-in.o
hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x3298): cannot reach 
register_net_sysctl
net/built-in.o: In function `ip_static_sysctl_init':
(.init.text+0x3298): relocation truncated to fit: R_PARISC_PCREL22F against 
symbol `register_net_sysctl' defined in .text.register_net_sysctl section in 
net/built-in.o
hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x3404): cannot reach 
register_net_sysctl
net/built-in.o: In function `ipfrag_init':
(.init.text+0x3404): relocation truncated to fit: R_PARISC_PCREL22F against 
symbol `register_net_sysctl' defined in .text.register_net_sysctl section in 
net/built-in.o
hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x4c50): cannot reach 
register_net_sysctl
net/built-in.o: In function `sysctl_ipv4_init':
net/ipv4/sysctl_net_ipv4.o:(.init.text+0x4c50): relocation truncated to fit: 
R_PARISC_PCREL22F against symbol `register_net_sysctl' defined in 
.text.register_net_sysctl section in net/built-in.o
hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x4c88): cannot reach 
unregister_net_sysctl_table
net/ipv4/sysctl_net_ipv4.o:(.init.text+0x4c88): relocation truncated to fit: 
R_PARISC_PCREL22F against symbol `unregister_net_sysctl_table' defined in 
.text.unregister_net_sysctl_table section in net/built-in.o
hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x8b74): cannot reach 
register_net_sysctl
net/built-in.o: In function `ipv6_frag_init':
(.init.text+0x8b74): relocation truncated to fit: R_PARISC_PCREL22F against 
symbol `register_net_sysctl' defined in .text.register_net_sysctl section in 
net/built-in.o
hppa64-linux-gnu-ld: net/built-in.o(.init.text+0x8c5c): cannot reach 
unregister_net_sysctl_table
net/built-in.o: In function `ipv6_frag_init':
(.init.text+0x8c5c): relocation truncated to fit: R_PARISC_PCREL22F against 
symbol `unregister_net_sysctl_table' defined in 
.text.unregister_net_sysctl_table section in net/built-in.o

It looks like we need to enable CONFIG_MLONGCALLS again (or change some
built-in things to modules, but I doubt there is much to be gained
there).

It was previously disabled as you requested in bug #733897.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.


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

linux 4.6 FTBFS on alpha

2016-05-04 Thread Ben Hutchings 
There's a silly type error in an alpha-specific module that now breaks
the build:

/«PKGBUILDDIR»/fs/binfmt_em86.c: In function 'load_em86':
/«PKGBUILDDIR»/fs/binfmt_em86.c:73:35: error: passing argument 2 of 
'copy_strings_kernel' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   retval = copy_strings_kernel(1, _arg, bprm);
   ^
In file included from /«PKGBUILDDIR»/fs/binfmt_em86.c:14:0:
/«PKGBUILDDIR»/include/linux/binfmts.h:116:12: note: expected 'const char * 
const*' but argument is of type 'char **'
 extern int copy_strings_kernel(int argc, const char *const *argv,
^
/«PKGBUILDDIR»/fs/binfmt_em86.c:77:34: error: passing argument 2 of 
'copy_strings_kernel' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  retval = copy_strings_kernel(1, _name, bprm);
  ^
In file included from /«PKGBUILDDIR»/fs/binfmt_em86.c:14:0:
/«PKGBUILDDIR»/include/linux/binfmts.h:116:12: note: expected 'const char * 
const*' but argument is of type 'char **'
 extern int copy_strings_kernel(int argc, const char *const *argv,
^

The conversion is safe but the C standard says it requires a cast.
This can easily be fixed by adding the cast, but I also wonder why we
still build this module.  Even the Kconfig text says it's redundant
with binfmt_misc.  What do you think?

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.


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

Bug#821442: linux-image-4.6.0-rc3-amd64 fails as well but in a different way

2016-05-04 Thread Norbert Kiesel 
Further update: I just booted into linux-image-4.6.0-rc5-amd64 and that
also works correctly with docker.

On Wed, Apr 27, 2016 at 1:08 PM, Norbert Kiesel  wrote:

> I just installed linux-image-4.6.0-rc3-amd64 from experimental.  With this
> kernel, I can run `docker start`, and I get a bash root prompt using
> `docker exec -it  bash`.  However, the shell then hangs: I can
> edit the line, but even w/o entering anything and just hitting  the
> shell locks up.
>
> /var/log/messages shows:
>
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.528976] [ cut here
> ]
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529019] WARNING: CPU: 3 PID: 468
> at /build/linux-aGlcVo/linux-4.6~rc3/net/wireless/sme.c:850
> wl_notify_roaming_status+0xb6/0x130 [wl]
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529021] Modules linked in:
> veth(E) fuse(E) xt_CHECKSUM(E) iptable_mangle(E) ipt_REJECT(E)
> nf_reject_ipv4(E) xt_tcpudp(E) tun(E) ebtable_filter(E) ebtables(E)
> ip6table_filter(E) ip6_tables(E) xt_conntrack(E) ipt_MASQUERADE(E)
> nf_nat_masquerade_ipv4(E) iptable_nat(E) nf_conntrack_ipv4(E)
> nf_defrag_ipv4(E) nf_nat_ipv4(E) xt_addrtype(E) iptable_filter(E)
> ip_tables(E) x_tables(E) br_netfilter(E) nf_nat(E) nf_conntrack(E)
> overlay(E) bridge(E) stp(E) llc(E) binfmt_misc(E) intel_rapl(E)
> x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E)
> irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E)
> wl(POE) jitterentropy_rng(E) hmac(E) drbg(E) ansi_cprng(E) iTCO_wdt(E)
> iTCO_vendor_support(E) amdkfd(E) dcdbas(E) aesni_intel(E) aes_x86_64(E)
> lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) radeon(E)
> dell_smm_hwmon(E) joydev(E) sg(E) evdev(E) cfg80211(E)
> snd_hda_codec_realtek(E) ttm(E) serio_raw(E) snd_hda_codec_generic(E)
> pcspkr(E) i915(E) i2c_i801(E) snd_hda_codec_hdmi(E) wmi(E) snd_hda_intel(E)
> battery(E) 8250_fintek(E) snd_hda_codec(E) elan_i2c(E) snd_hda_core(E)
> snd_hwdep(E) drm_kms_helper(E) dell_smo8800(E) snd_pcm(E) drm(E)
> snd_timer(E) dell_rbtn(E) dw_dmac(E) i2c_designware_platform(E) snd(E)
> dw_dmac_core(E) i2c_designware_core(E) soundcore(E) i2c_algo_bit(E)
> video(E) lpc_ich(E) rfkill(E) mei_me(E) shpchp(E) tpm_tis(E) mfd_core(E)
> ie31200_edac(E) ac(E) mei(E) tpm(E) edac_core(E) button(E) processor(E)
> parport_pc(E) ppdev(E) lp(E) parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E)
> mbcache(E) btrfs(E) crc32c_generic(E) xor(E) raid6_pq(E) md_mod(E)
> sd_mod(E) hid_generic(E) usbhid(E) crc32c_intel(E) ahci(E) libahci(E)
> libata(E) psmouse(E) scsi_mod(E) xhci_pci(E) ehci_pci(E) sdhci_pci(E)
> xhci_hcd(E) ehci_hcd(E) e1000e(E) ptp(E) usbcore(E) pps_core(E)
> usb_common(E) thermal(E) sdhci_acpi(E) sdhci(E) mmc_core(E) i2c_hid(E)
> hid(E) fjes(E)
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529090] CPU: 3 PID: 468 Comm:
> wl_event_handle Tainted: P   OE   4.6.0-rc3-amd64 #1 Debian
> 4.6~rc3-1~exp1
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529091] Hardware name: Dell Inc.
> Precision M4800/0WJNC2, BIOS A14 05/19/2015
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529093]  0286
> 8ce2ddb2 81310e95 
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529095]  
> 8107a4ee 880805d54700 8807d8a61614
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529096]  880805d54f1a
> 88080925a000 880805d54af8 81ab21a0
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529098] Call Trace:
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529104]  [] ?
> dump_stack+0x5c/0x77
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529107]  [] ?
> __warn+0xbe/0xe0
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529134]  [] ?
> wl_notify_roaming_status+0xb6/0x130 [wl]
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529158]  [] ?
> wl_event_handler+0x58/0x1a0 [wl]
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529182]  [] ?
> wl_notify_scan_status+0x310/0x310 [wl]
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529184]  [] ?
> kthread+0xcd/0xf0
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529187]  [] ?
> ret_from_fork+0x22/0x40
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529189]  [] ?
> kthread_create_on_node+0x190/0x190
> Apr 27 12:09:48 lt-nkiesel kernel: [  214.529190] ---[ end trace
> f6e95ef4cd43b7be ]---
>
>
> However, I see similar problems when running the 4.4 kernel, so this might
> not be related to the "shell hanging" problem.
>

Re: Linux 4.6 kernel package fixes

2016-05-04 Thread Ben Hutchings 
On Thu, 2016-05-05 at 00:07 +0200, Lukas Wunner wrote:
> Hi Ben,
> 
> I upgraded to tag debian/4.6_rc5-1_exp1 today and wanted to provide some
> quick feedback. First of all it's good to no longer have linux-tools
> separately, thanks for doing this.
> 
> 
> On first build I got messages like this because config.h is only generated
> later in the build and the target install-usbip failed:
> 
> sed: can't read debian/build/build-tools/tools/usb/usbip/config.h: No such 
> file or directory
>
> After invoking "make -f debian/rules binary-arch" a second time the package
> was built without a hitch because config.h was now there.

Ah, I see the problem.  dpkg-buildpackage invokes the build target
before binary{,-arch,-indep}, so this isn't a problem for auto-builds.

> In rules.d/tools/lib/lockdep/Makefile, ln -s fails for liblockdep.so
> because the symlink already exists. Either this should be ln -sf or
> the command is superfluous.

It's not superfluous, and it normally works.  You'll have to explain
what commands you're using that cause it to fail.

> About this issue I mentioned in my Linux 4.5 e-mail in February:
> 
> On Thu, Feb 25, 2016 at 09:41:28PM +, Ben Hutchings wrote:
> > 
> > On Thu, 2016-02-25 at 16:16 +0100, Lukas Wunner wrote:
> > > 
> > > --- 
> > > a/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch
> > > +++ 
> > > b/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch
> > > @@ -13,11 +13,7 @@ a version of the script which is directly derived from 
> > > the driver.
> > >  
> > >  --- a/drivers/media/usb/dvb-usb/Kconfig
> > >  +++ b/drivers/media/usb/dvb-usb/Kconfig
> > > -@@ -227,10 +227,10 @@ config DVB_USB_OPERA1
> > > - 
> > > - config DVB_USB_AF9005
> > > - tristate "Afatech AF9005 DVB-T USB1.1 support"
> > > --depends on BROKEN
> > > +@@ -236,6 +236,7 @@ config DVB_USB_AF9005
> > >   depends on DVB_USB
> > >   select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
> > >   select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
> > This file is also patched by debian/patches/debian/dfsg/drivers-media-
> > dvb-dvb-usb-af9005-disable.patch when building the 'orig' tarball.
> So this patch adds "depends on BROKEN":
> debian/patches/debian/dfsg/drivers-media-dvb-dvb-usb-af9005-disable.patch
> 
> And this patch subsequently removes it:
> debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch
> 
> Forgive me for being dense but what is the motivation for this?

The orig tarball should have minimal changes from the upstream source
for DFSG compliance.  In the upstream source, the firmware for this
driver is built-in, so when we delete the firmware (done by
debian/patches/debian/dfsg/files-1) the driver can't be built.  This
first patch, applied when building the orig tarball, documents that
breakage.

The second patch, applied when unpacking the source package, is a
bigger change that fixes the driver by adding the ability to load
firmware from a separate file.

> I keep bringing this up because it breaks my workflow: I use
> "quilt pop -a" to remove all debian patches before rebasing
> or switching branches, and later use "quilt push -a" when I
> actually want to compile. I can work around this by keeping
> a modified version of the second above-mentioned patch in
> my tree but I'm wondering if it might be possible to just not
> add the "depends on BROKEN" in the first place?

You seem to be asking us to make the orig tarball the same as the
upstream git tag.

In order to do that, we'll need to get those changes upstream in some
way.  That probably will happen eventually, but it hasn't been a high
priority.  Maybe you're the one to do that?

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.

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

Linux 4.6 kernel package fixes

2016-05-04 Thread Lukas Wunner 
Hi Ben,

I upgraded to tag debian/4.6_rc5-1_exp1 today and wanted to provide some
quick feedback. First of all it's good to no longer have linux-tools
separately, thanks for doing this.


On first build I got messages like this because config.h is only generated
later in the build and the target install-usbip failed:

sed: can't read debian/build/build-tools/tools/usb/usbip/config.h: No such file 
or directory

After invoking "make -f debian/rules binary-arch" a second time the package
was built without a hitch because config.h was now there.


In rules.d/tools/lib/lockdep/Makefile, ln -s fails for liblockdep.so
because the symlink already exists. Either this should be ln -sf or
the command is superfluous.


About this issue I mentioned in my Linux 4.5 e-mail in February:

On Thu, Feb 25, 2016 at 09:41:28PM +, Ben Hutchings wrote:
> On Thu, 2016-02-25 at 16:16 +0100, Lukas Wunner wrote:
> > --- 
> > a/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch
> > +++ 
> > b/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch
> > @@ -13,11 +13,7 @@ a version of the script which is directly derived from 
> > the driver.
> >  
> >  --- a/drivers/media/usb/dvb-usb/Kconfig
> >  +++ b/drivers/media/usb/dvb-usb/Kconfig
> > -@@ -227,10 +227,10 @@ config DVB_USB_OPERA1
> > - 
> > - config DVB_USB_AF9005
> > -   tristate "Afatech AF9005 DVB-T USB1.1 support"
> > --  depends on BROKEN
> > +@@ -236,6 +236,7 @@ config DVB_USB_AF9005
> >     depends on DVB_USB
> >     select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
> >     select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
> 
> This file is also patched by debian/patches/debian/dfsg/drivers-media-
> dvb-dvb-usb-af9005-disable.patch when building the 'orig' tarball.

So this patch adds "depends on BROKEN":
debian/patches/debian/dfsg/drivers-media-dvb-dvb-usb-af9005-disable.patch

And this patch subsequently removes it:
debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch

Forgive me for being dense but what is the motivation for this?

I keep bringing this up because it breaks my workflow: I use
"quilt pop -a" to remove all debian patches before rebasing
or switching branches, and later use "quilt push -a" when I
actually want to compile. I can work around this by keeping
a modified version of the second above-mentioned patch in
my tree but I'm wondering if it might be possible to just not
add the "depends on BROKEN" in the first place?

Thanks,

Lukas

Bug#823146: linux-image-4.5.0-0.bpo.1-amd64: Kernel 4.5 fails to boot on AMD A6 APU

2016-05-04 Thread Ben Hutchings 
On Wed, 2016-05-04 at 08:42 +0200, CJP wrote:
> > 
> > Of course.  It looks like we can do that by reverting the change that
> > caused this regression.  Please test whether the attached patch fixes
> > the problem, following the instructions at:
> > 
> > https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
> > 
> Yes, it fixes the problem, even without my modprobe.blacklist argument.
> 
> Some notes:
> 
> test-patches asked me for a flavour; I entered amd64.
> 
> When installing the linux-image package, I got this error:
> update-initramfs: Generating /boot/initrd.img-4.5.0-0.bpo.1-amd64
> W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for
> module r8169
> W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-1.fw for
> module r8169
> W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-2.fw for
> module r8169
> W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-1.fw for
> module r8169
> I ignored it, since I probably won't need WiFi during early start-up.

These are actually for Ethernet controllers not wifi.

> When fully booted with this kernel, I tested my WiFi and it still works.
> 
> lsmod shows now that the sp5100_tco module is loaded.
> 
> dmesg contains the following line:
> [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.5.0-0.bpo.1-amd64
> root=UUID=cab2c5d5-4664-4105-bcbd-fcb860cc035d ro quiet
> (so it is version 4.5, without the blacklist argument)
> 
> dmesg does not show the ACPI error lines that were generated by the
> faulty 4.5.
> 
> dmesg | grep sp5100_tco returns the following:
> [   31.700531] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
> [   31.700640] sp5100_tco: PCI Revision ID: 0x13
> [   31.700709] sp5100_tco: failed to find MMIO address, giving up.
> 
> I hope this is what you expected. To me, it looks like the problem is
> fixed.

That looks right - the driver is now failing in a harmless way.

Thanks for testing.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.

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

Bug#822839: marked as done (linux-image-4.5.0-1-amd64: Suspend to RAM keeps CPU running)

2016-05-04 Thread Debian Bug Tracking System 
Your message dated Wed, 04 May 2016 22:26:12 +0100
with message-id <1462397172.1563.31.ca...@decadent.org.uk>
and subject line Re: Bug#822839: linux-image-4.5.0-1-amd64: Suspend to RAM 
keeps CPU running
has caused the Debian Bug report #822839,
regarding linux-image-4.5.0-1-amd64: Suspend to RAM keeps CPU running
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.)


-- 
822839: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822839
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 4.5.1-1
Severity: normal

With 4.4.0-1-amd64, suspend to RAM works 9 times out of 10.
(Sometimes the machine boots afresh instead of just waking up.)

With 4.5.0-1-amd64, the first (and up to now only) try looked
normal (screen off, LED blinking), but a few minutes later I noticed
that the backpack was getting really hot.
Checking I found that the fan was running at maximum, because
(I guess) the CPU was still running at top speed.

Opening the laptop didn't wake it up, neither did pressing the
power key; I had to remove the battery to turn it off and let
it cool down.

JFI: linux-image-4.4.0-1-amd64=4.4.6-1; but most linux-image
versions do STR (to 90% ;) fine.


-- Package-specific info:
** Kernel log: boot messages should be attached
Hrm, since systemd the /var/log/dmesg file isn't filled anymore...
so all the dmesg.* files are from 2014, sorry.

** Model information
sys_vendor: LENOVO
product_name: 20B2000PGE
product_version: ThinkPad Edge E545
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: HRET24WW (1.12)
board_vendor: LENOVO
board_name: 20B2000PGE
board_version: Not Available

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Complex [1022:1410]
Subsystem: Lenovo Family 15h (Models 10h-1fh) Processor Root Complex 
[17aa:510a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR-  [disabled]
Capabilities: 
Kernel driver in use: radeon
Kernel modules: radeon

00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity 
HDMI Audio Controller [1002:9902]
Subsystem: Lenovo Trinity HDMI Audio Controller [17aa:510a]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Port [1022:1414] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Port [1022:1415] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Port [1022:1417] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI 
Controller [1022:7814] (rev 09) (prog-if 30 [XHCI])
Subsystem: Lenovo FCH USB XHCI Controller [17aa:510a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B-

Bug#823444: linux-image-4.5.0-0.bpo.1-amd64: breaks kwin (abort with fatal error) on Thinkpad T560

2016-05-04 Thread Ben Hutchings 
On Wed, 2016-05-04 at 21:38 +0200, Maria wrote:
> Package: src:linux
> Version: 4.5.1-1~bpo8+1
> Severity: important
> 
> Dear Ben,
> 
> I didn't find the error among the list of over 1500 packages shown to
> me, sorry. This is an addendum to error #823156 which I wrote
> initially on this topic. And the title of #819272 sounded similar.
> I actually reinstalled Debian on a USB 3 Harddisk to test wether the
> problem still occurs with the Firmware (firmware-misc-nonfree,
> firmware-intel-sound, firmware-iwlwifi).

The firmware-iwlwifi version is too old; you'll need the version in
jessie-backports.

>  But I still get stuck at the console. 
> Kwin still refuses to load and aborts with the same fatal error.

You didn't say what the error is.

Which version of xserver-xorg-video-intel do you have?  You may need
the version from jessie-backports.

>  I actually started with the install of the new header files and
> kernel. As I had the same effect I started with installing the
> firmware-misc-nonfree.
> Then I installed the other two. But there was no change. Just an
> error of failing to load some Kernel module, which was too fast to
> see. I hope it is in the logs below. 

I don't see it, unfortunately.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.

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

Bug#819077: marked as done (linux-image-4.4.0-1-amd64: virtual consoles become unavailable and cause display problems)

2016-05-04 Thread Debian Bug Tracking System 
Your message dated Wed, 4 May 2016 22:32:58 +0200
with message-id <572a5c7a.3000...@gmail.com>
and subject line Re: Bug#819077: linux-image-4.4.0-1-amd64: virtual consoles 
become unavailable and cause display problems
has caused the Debian Bug report #819077,
regarding linux-image-4.4.0-1-amd64: virtual consoles become unavailable and 
cause display problems
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.)


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

Dear Maintainer,

Since the update to 4.4.0-1 i've been regularly encountering a problem where
virtual consoles (available by pressing Ctrl + Alt + F1..6) "freeze up" after
working in the X session for some time. Namely, one of two things happen:

* Sometimes every virtual console shows no login prompt, but only an unmoving,
unblinking cursor. This seems to only happen if I am not logged into any text
console.
* Sometimes the same image will show up for all consoles (no matter which one I
switch to), which is a frozen image from one of them. This can happen whether
I'm logged in on one of the ttys or not.

The consoles then react to no input. I can switch back to the X session by
pressing Ctrl+Alt+F7 and back to text consoles again. The X session continues
to work normally, but usually there are various display glitches, like some
windows not rendering properly. In one case all GTK+ programs stopped showing
text (Qt programs continued to work).

So far I've only established that it happens after about 20-30 minutes of
actively working in the X session, but it isn't bound to any program in
particular. I haven't seen it trigger while working in a virtual console, even
if the X session is running, unless I first switch to the X session.

This never happened under previous kernel versions I've used (4.1, 4.2, 4.3).
Previous kernel versions were affected by another bug though [1], although it
never caused any problems other than an error message and an occasional little
display glitch. That bug no longer occurs for me under 4.4.0, but now this much
more serious bug does.

At this moment the bug has already been triggered. dmesg shows no messages
other than what's attached. Although bbswitch is loaded, I haven't run any
program with optirun/primusrun since reboot.

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



-- Package-specific info:
** Version:
Linux version 4.4.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 5.3.1 
20160307 (Debian 5.3.1-11) ) #1 SMP Debian 4.4.6-1 (2016-03-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.4.0-1-amd64 
root=UUID=808626fe-93c8-4f70-a04f-e8e9922c2737 ro quiet splash

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[   13.772072] ath: Regpair used: 0x60
[   13.906499] intel_rapl: Found RAPL domain package
[   13.906501] intel_rapl: Found RAPL domain core
[   13.906503] intel_rapl: Found RAPL domain uncore
[   13.906512] intel_rapl: RAPL package 0 domain package locked by BIOS
[   14.021854] ACPI: Video Device [PEGP] (multi-head: yes  rom: yes  post: no)
[   14.022672] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/LNXVIDEO:00/input/input14
[   14.023744] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   14.028162] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input15
[   14.028256] [drm] Initialized i915 1.6.0 20151010 for :00:02.0 on minor 0
[   14.028433] ACPI Warning: SystemIO range 
0xF040-0xF05F conflicts with OpRegion 
0xF040-0xF04F (\SMB0) (20150930/utaddress-254)
[   14.028438] ACPI Warning: SystemIO range 
0xF040-0xF05F conflicts with OpRegion 
0xF040-0xF04F (\_SB_.PCI0.SBUS.SMBI) 
(20150930/utaddress-254)
[   14.028440] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[   14.063700] input: PC Speaker as /devices/platform/pcspkr/input/input16
[   14.099522] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input13
[   14.099614] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1b.0/sound/card0/input17
[   14.147935] Console: switching to colour frame buffer device 170x48
[   14.151023] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   14.151369] ieee80211 phy0: Atheros AR9485 Rev:1 mem=0xc9c0, 
irq=17
[   14.152116] i915

Processed: found 822396 in glibc/2.22-7

2016-05-04 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> found 822396 glibc/2.22-7
Bug #822396 [src:linux,src:glibc]  and  conflict needs to 
be resolved
Bug #822378 [src:linux,src:glibc]  and  conflict needs to 
be resolved
Bug #822393 [src:linux,src:glibc]  and  conflict needs to 
be resolved
Marked as found in versions glibc/2.22-7.
Marked as found in versions glibc/2.22-7.
Marked as found in versions glibc/2.22-7.
> thanks
Stopping processing here.

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

Processed: found 822396 in linux/4.5.1-1

2016-05-04 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> found 822396 linux/4.5.1-1
Bug #822396 [src:linux,src:glibc]  and  conflict needs to 
be resolved
Bug #822378 [src:linux,src:glibc]  and  conflict needs to 
be resolved
Bug #822393 [src:linux,src:glibc]  and  conflict needs to 
be resolved
Marked as found in versions linux/4.5.1-1.
Marked as found in versions linux/4.5.1-1.
Marked as found in versions linux/4.5.1-1.
> thanks
Stopping processing here.

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

Bug#823444: linux-image-4.5.0-0.bpo.1-amd64: breaks kwin (abort with fatal error) on Thinkpad T560

2016-05-04 Thread Maria 
Package: src:linux
Version: 4.5.1-1~bpo8+1
Severity: important

Dear Ben,

I didn't find the error among the list of over 1500 packages shown to me, 
sorry. This is an addendum to error #823156 which I wrote initially on this 
topic. And the title of #819272 sounded similar.
I actually reinstalled Debian on a USB 3 Harddisk to test wether the problem 
still occurs with the Firmware (firmware-misc-nonfree, firmware-intel-sound, 
firmware-iwlwifi). But I still get stuck at the console. 
Kwin still refuses to load and aborts with the same fatal error. I actually 
started with the install of the new header files and kernel. As I had the same 
effect I started with installing the firmware-misc-nonfree.
Then I installed the other two. But there was no change. Just an error of 
failing to load some Kernel module, which was too fast to see. I hope it is in 
the logs below. 

Thanks for your work.
Maria



-- Package-specific info:
** Version:
Linux version 4.5.0-0.bpo.1-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.5.1-1~bpo8+1 (2016-04-20)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.5.0-0.bpo.1-amd64 
root=UUID=4fdaf978-e312-4fbc-b8e9-858f4a4934c0 ro quiet

** Tainted: E (8192)
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[   10.939238] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input13
[   10.939319] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[   10.939398] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[   11.014402] iTCO_vendor_support: vendor-support=0
[   11.281309] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   11.281453] iTCO_wdt: Found a Intel PCH TCO device (Version=4, 
TCOBASE=0x0400)
[   11.281682] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   11.431640] usbcore: registered new interface driver btusb
[   11.433059] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[   11.440063] Bluetooth: hci0: Device revision is 5
[   11.440073] Bluetooth: hci0: Secure boot is enabled
[   11.440078] Bluetooth: hci0: OTP lock is enabled
[   11.440083] Bluetooth: hci0: API lock is enabled
[   11.440087] Bluetooth: hci0: Debug lock is disabled
[   11.440093] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[   11.440925] AVX2 version of gcm_enc/dec engaged.
[   11.440933] AES CTR mode by8 optimization enabled
[   11.490734] bluetooth hci0: firmware: failed to load intel/ibt-11-5.sfi (-2)
[   11.490765] bluetooth hci0: Direct firmware load for intel/ibt-11-5.sfi 
failed with error -2
[   11.490768] Bluetooth: hci0: Failed to load Intel firmware file (-2)
[   11.654093] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[   11.661198] Bluetooth: hci0: Device revision is 5
[   11.661203] Bluetooth: hci0: Secure boot is enabled
[   11.661205] Bluetooth: hci0: OTP lock is enabled
[   11.661207] Bluetooth: hci0: API lock is enabled
[   11.661208] Bluetooth: hci0: Debug lock is disabled
[   11.661211] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[   11.661228] bluetooth hci0: firmware: failed to load intel/ibt-11-5.sfi (-2)
[   11.661284] bluetooth hci0: Direct firmware load for intel/ibt-11-5.sfi 
failed with error -2
[   11.661288] Bluetooth: hci0: Failed to load Intel firmware file (-2)
[   11.751913] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   11.774531] Intel(R) Wireless WiFi driver for Linux
[   11.774535] Copyright(c) 2003- 2015 Intel Corporation
[   11.774893] iwlwifi :04:00.0: enabling device ( -> 0002)
[   11.777258] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-20.ucode (-2)
[   11.777336] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-20.ucode failed with error -2
[   11.777359] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-19.ucode (-2)
[   11.777439] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-19.ucode failed with error -2
[   11.777460] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-18.ucode (-2)
[   11.777536] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-18.ucode failed with error -2
[   11.777556] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-17.ucode (-2)
[   11.777631] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-17.ucode failed with error -2
[   11.777651] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-16.ucode (-2)
[   11.35] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-16.ucode failed with error -2
[   11.54] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-15.ucode (-2)
[   11.777829] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-15.ucode failed with error -2
[   11.777848] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-14.ucode (-2)
[   11.777921] iwlwifi :04:00.0: Direct firmware load for

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

2016-05-04 Thread Juho 

Any news?

--
Juho

Bug#823434: Crash in wheezy-backports kernels on skb_release_data

2016-05-04 Thread James Oakley 
Package: linux-image-3.16.0-0.bpo.4-amd64
Version: multiple

We're seeing a crash once or twice a week across multiple machines running 
various versions of the wheezy-backports 3.16 kernel. Here is an excerpt from 
one of the dumps we captured. Unfortunately, the top was cut off due to the 
screen size, but the most important stuff appears to be intact:

task: 880199212b60 ti: 88019922 task.ti: 88019922
RIP: 0010:[]  [] skb_release_data+0xe3/0x110
RSP: 0018:88031fae3c20  EFLAGS: 00010202
RAX: 0001 RBX: 8802b1c448c0 RCX: b1c44800
RDX: 0060 RSI: fe01 RDI: 0101010101010101
RBP: 0001 R08: 880318d3d798 R09: 0002
R10: 8802d5f75e00 R11: 001b R12: 8802d5f75e00
R13: 003b R14: 8802a69fca10 R15: 8802ef350100
FS:  () GS:88031fae() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: ff600400 CR3: 01813000 CR4: 07e0
Stack:
  4f00 8802d5f75e00  8140b817
  4f00 8802d5f75e00 81456058 0014
  004f0010 058eb1c44800 8802fc4a 0010
Call Trace:
 
 [] ? consume_skb+0x27/0x80
 [] ? ip_fragment+0x5b8/0x880
 [] ? skb_set_owner_w+0x50/0x50
 [] ? ip_finish_output+0x53c/0x840
 [] ? __netif_receive_skb_core+0x533/0x750
 [] ? read_tsc+0x5/0x20
 [] ? netif_receive_skb_internal+0x1f/0x90
 [] ? dev_gro_receive+0x1df/0x2e0
 [] ? napi_gro_receive+0x27/0xe0
 [] ? bnx2_poll_work+0x7e4/0x1230 [bnx2]
 [] ? bnx2_poll_msix+0x2d/0xb0 [bnx2]
 [] ? net_rx_action+0x140/0x240
 [] ? __do_softirq+0xf1/0x290
 [] ? irq_exit+0x95/0xa0
 [] ? do_IRQ+0x52/0xe0
 [] ? common_interrupt+0x6d/0x6d
 
 [] ? cpuidle_enter_state+0x4f/0xc0
 [] ? cpuidle_enter_state+0x48/0xc0
 [] ? cpu_startup_entry+0x2f8/0x400
 [] ? start_secondary+0x20f/0x2d0
Code: 8b 9c 24 cc 00 00 00 49 03 9c 24 d0 00 00 00 48 8b 7b 08 48 85 ff 75 13 
5b 5d 4c 89 e7 41 5c e9 a4 fe ff ff 0f 1f 40 00 48 89 ef <48> 8b 2f e8 75 00 00 
00 48 85 ed 75 f0 48 c7 43 08 00 00 00 00
RIP  [] skb_release_data_0xe3/0x110
 RSP 
[ end trace 35ec23bf75ec9349 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: 0x0 from 0x8100 (relocation range: 
0x8000-0x9fff)

Some sleuthing led me to https://lkml.org/lkml/2016/1/6/627 which doesn't look 
exactly the same, but may be related, particularly since we are routing between 
networks with a variety of MTU values, and fragmentation is common. The fix for 
that is at 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=9207f9d45b0ad071baa128e846d7e7ed85016df3

--
James Oakley
james.oak...@multapplied.net

Bug#822839: linux-image-4.5.0-1-amd64: Suspend to RAM keeps CPU running

2016-05-04 Thread Philipp Marek 
Seems to work with 4.5.0-2-amd64 again, though I ran straight into 
https://bugzilla.kernel.org/show_bug.cgi?id=114201 ...


Thanks for the quick answer!

Processed: your mail

2016-05-04 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> tags 823224 upstream
Bug #823224 [src:linux] ld: arch/powerpc/lib/crtsavres.o: No such file: No such 
file or directory
Ignoring request to alter tags of bug #823224 to the same tags previously set
> forwarded 823224 https://bugzilla.kernel.org/show_bug.cgi?id=11143
Bug #823224 [src:linux] ld: arch/powerpc/lib/crtsavres.o: No such file: No such 
file or directory
Set Bug forwarded-to-address to 
'https://bugzilla.kernel.org/show_bug.cgi?id=11143'.
>
End of message, stopping processing here.

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

Bug#823402: firmware-iwlwifi: Direct firmware load for iwlwifi-7265D-19.ucode failed with error -2

2016-05-04 Thread Marc F. Neininger 
Package: firmware-iwlwifi
Version: 20160110-1
Severity: important
Tags: upstream

Dear Maintainer,


   * What led up to the situation?
- the actual kernel (4.5.0-1) would like to work with the files iwlwifi-
7265D-18 / 19 / 20 .ucode.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
- the problem is not urgent as the kernel uses an older firmware but reports
the missing firmware files.

   * What outcome did you expect instead?
- could you please package newer firmware versions into firmware-iwlwifi for
the 7265D?

Thanks for your attention and thanks for packaging.

Marc



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.125

-- no debconf information

Bug#822666: linux-headers-3.16.0-4-amd64: deprecated syntax in linux-headers Makefile

2016-05-04 Thread Julien Cristau 
On Sat, Apr 30, 2016 at 22:14:09 +0200, Ben Hutchings wrote:

> I request a judgement from the SRM whether this bug is suitable for a
> stable update.  The change is pretty small:
> 
> --- a/debian/rules.real
> +++ b/debian/rules.real
> @@ -311,7 +311,9 @@ install-headers_$(ARCH)_$(FEATURESET)_$(FLAVOUR): 
> $(STAMPS_DIR)/build_$(ARCH)_$(
>   @echo 'all:' >> $(DIR)/Makefile
>   @echo ' @$$(MAKE) $$(MAKEARGS) $$(cmd)' >> $(DIR)/Makefile
>   @echo 'Makefile:;' >> $(DIR)/Makefile
> - @echo '$$(cmd) %/: all' >> $(DIR)/Makefile
> + @echo '$$(cmd): all' >> $(DIR)/Makefile
> + @echo ' @:' >> $(DIR)/Makefile
> + @echo '%/: all' >> $(DIR)/Makefile
>   @echo ' @:' >> $(DIR)/Makefile
>  
>   dh_link /usr/lib/$(PACKAGE_NAME_KBUILD)/scripts $(BASE_DIR)/scripts
> --- END ---
> 
Feel free to include this change as part of a regular stable kernel update.

Cheers,
Julien

Bug#794266: rtc-s35390a: the big mess or inconsistencies during startup

2016-05-04 Thread Uwe Kleine-König 
Hello,

there was a bug reported against the Debian kernel that seems related to
the rtc-s35390a driver/chip. See https://bugs.debian.org/794266.

I looked a bit into the driver now, and there are several problems. As I
don't have access to such a chip I just want to tell what I found and
how I think it should be tackled.

 - The rtc-s35390a chip's alarm uses only minute, hour and dow.
   The .read_alarm callback (s35390a_read_alarm()) returns -EINVAL if
   the alarm is not enabled. I think it should just set alm->enabled = 0
   in this case. Further it only sets alm->time.tm_wday,
   alm->time.tm_hour and alm->time.tm_min which isn't handled in a sane
   way by __rtc_read_alarm. Maybe rtc_read_alarm_internal should better
   initialize all fields of alarm->time to -1 instead of 0?

 - During startup we saw:

[2.257418] rtc rtc0: invalid alarm value: 1900-1-29 1193031:57:16

   I don't see how this big hour value can be found, looking at the
   driver it sets alm->time.tm_hour at most to

bcd2bin(reg & 0x3f) + 12

   where reg is a char. Then in __rtc_read_alarm we get into the missing
   = day case (because it doesn't handle an initialized wday).
   So it must be rtc_time64_to_tm that returns that big hour, probably
   because rtc_tm_to_time64(>time) is < 0 which rtc_time64_to_tm
   cannot handle?

So the action items are:

  - let rtc_read_alarm_internal initialize alarm->time to 9*{-1} (or fix
s35390a_read_alarm to set the uninitialized values to -1).
  - let s35390a_read_alarm set alm->pending and alm->enabled.
  - teach __rtc_read_alarm to handle mday = -1 but wday >= 0.
  - tell hw-engineers not to use read-to-clear events (use a big clue
stick).
  - debug rtc_tm_to_time64 + rtc_time64_to_tm for dates < 1970
(or clamp t_alm in __rtc_read_alarm to >= 0?)

Any volunteers?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Bug#823146: linux-image-4.5.0-0.bpo.1-amd64: Kernel 4.5 fails to boot on AMD A6 APU

2016-05-04 Thread CJP 
> Of course.  It looks like we can do that by reverting the change that
> caused this regression.  Please test whether the attached patch fixes
> the problem, following the instructions at:
> 
> https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
> 

Yes, it fixes the problem, even without my modprobe.blacklist argument.

Some notes:

test-patches asked me for a flavour; I entered amd64.

When installing the linux-image package, I got this error:
update-initramfs: Generating /boot/initrd.img-4.5.0-0.bpo.1-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-1.fw for
module r8169
I ignored it, since I probably won't need WiFi during early start-up.
When fully booted with this kernel, I tested my WiFi and it still works.

lsmod shows now that the sp5100_tco module is loaded.

dmesg contains the following line:
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.5.0-0.bpo.1-amd64
root=UUID=cab2c5d5-4664-4105-bcbd-fcb860cc035d ro quiet
(so it is version 4.5, without the blacklist argument)

dmesg does not show the ACPI error lines that were generated by the
faulty 4.5.

dmesg | grep sp5100_tco returns the following:
[   31.700531] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
[   31.700640] sp5100_tco: PCI Revision ID: 0x13
[   31.700709] sp5100_tco: failed to find MMIO address, giving up.

I hope this is what you expected. To me, it looks like the problem is
fixed.

CJP