Bug#755249: IPv6 link non-functional after suspend
Package: src:linux Version: 3.14.12-1 Severity: important Hi! After suspend/resume the computer is unable to perform any IPv6 connection (no ping to fixed IP, no nc, no anything). tcpdump was unfortunately not helpfull in figuring out where exactly it breaks because, as soon as I start tcpdump, things work again. If I stop tcpdump after resume I can still reach all routed IPv6 addresses but only the local ones I have contacted while tcpdump running. Removing the interface and adding it again helps as well. Christoph -- Package-specific info: ** Version: Linux version 3.14-1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-4) ) #1 SMP Debian 3.14.12-1 (2014-07-11) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.14-1-amd64 root=/dev/mapper/ssd-root ro quiet rootdelay=2 ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [ 4017.392368] PM: early resume of devices complete after 0.097 msecs [ 4017.392667] r8169 :06:00.0: System wakeup disabled by ACPI [ 4017.407482] [drm] probing gen 2 caps for device 1022:9603 = 300d02/0 [ 4017.407486] [drm] PCIE gen 2 link speeds already enabled [ 4017.408227] serial 00:06: activated [ 4017.411290] [drm] PCIE GART of 1024M enabled (table at 0x00478000). [ 4017.411375] radeon :01:00.0: WB enabled [ 4017.411377] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x88049af11c00 [ 4017.411378] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x88049af11c04 [ 4017.411379] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x88049af11c08 [ 4017.411380] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x88049af11c0c [ 4017.411381] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0x88049af11c10 [ 4017.412156] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc90013735a18 [ 4017.556738] ata7.00: ACPI cmd ef/03:46:00:00:00:a0 (SET FEATURES) filtered out [ 4017.572711] ata7.00: configured for UDMA/33 [ 4017.579225] [drm] ring test on 0 succeeded in 1 usecs [ 4017.579228] [drm] ring test on 1 succeeded in 0 usecs [ 4017.579231] [drm] ring test on 2 succeeded in 0 usecs [ 4017.579298] [drm] ring test on 3 succeeded in 2 usecs [ 4017.579306] [drm] ring test on 4 succeeded in 1 usecs [ 4017.581956] r8169 :06:00.0 eth0: link down [ 4017.712104] ata5: SATA link down (SStatus 0 SControl 300) [ 4017.712132] ata2: SATA link down (SStatus 0 SControl 300) [ 4017.712157] ata4: SATA link down (SStatus 0 SControl 300) [ 4017.765000] br0: port 1(eth0) entered disabled state [ 4017.765068] [drm] ring test on 5 succeeded in 2 usecs [ 4017.765072] [drm] UVD initialized successfully. [ 4017.765681] [drm] ib test on ring 0 succeeded in 0 usecs [ 4017.765702] [drm] ib test on ring 1 succeeded in 0 usecs [ 4017.765722] [drm] ib test on ring 2 succeeded in 0 usecs [ 4017.765743] [drm] ib test on ring 3 succeeded in 0 usecs [ 4017.765763] [drm] ib test on ring 4 succeeded in 0 usecs [ 4017.784087] usb 1-4: reset high-speed USB device number 3 using ehci-pci [ 4017.884105] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 4017.886062] ata6.00: failed to get NCQ Send/Recv Log Emask 0x1 [ 4017.886289] ata6.00: failed to get NCQ Send/Recv Log Emask 0x1 [ 4017.886291] ata6.00: configured for UDMA/133 [ 4017.900172] sd 5:0:0:0: [sdc] Starting disk [ 4017.916305] [drm] ib test on ring 5 succeeded [ 4018.069640] firewire_core :02:00.0: rediscovered device fw0 [ 4018.384278] usb 1-4.1: reset low-speed USB device number 4 using ehci-pci [ 4018.924338] usb 1-4.4: reset low-speed USB device number 6 using ehci-pci [ 4019.228049] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4019.230434] ata3.00: configured for UDMA/133 [ 4019.244158] sd 2:0:0:0: [sdb] Starting disk [ 4019.340070] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4019.352019] ata1.00: configured for UDMA/133 [ 4019.368157] sd 0:0:0:0: [sda] Starting disk [ 4019.390838] PM: resume of devices complete after 1998.468 msecs [ 4019.391011] PM: Finishing wakeup. [ 4019.391012] Restarting tasks ... done. [ 4019.500092] usb 1-2: new high-speed USB device number 7 using ehci-pci [ 4019.538481] r8169 :06:00.0 eth0: link up [ 4019.539255] br0: port 1(eth0) entered forwarding state [ 4019.539277] br0: port 1(eth0) entered forwarding state [ 4019.707857] xhci_hcd :03:00.0: xHCI Host Controller [ 4019.707868] xhci_hcd :03:00.0: new USB bus registered, assigned bus number 2 [ 4019.812515] xhci_hcd :03:00.0: irq 45 for MSI/MSI-X [ 4019.812540] xhci_hcd :03:00.0: irq 46 for MSI/MSI-X [ 4019.812560] xhci_hcd :03:00.0: irq 47 for MSI/MSI-X [ 4019.812579] xhci_hcd :03:00.0: irq 48 for MSI/MSI-X [ 4019.812596] xhci_hcd :03:00.0: irq 49 for MSI/MSI-X [ 4019.812613] xhci_hcd
Re: Kernel version for jessie
On Fri, Jul 18, 2014 at 05:43:06PM +0100, Ben Hutchings wrote: On Thu, 2014-05-01 at 17:29 +0100, Ben Hutchings wrote: [...] The earlier we freeze the kernel, the more work will be required to backport fixes and hardware enablement during the jessie support period. So I think that 3.16 would be the best fit. It is also very unlikely that a PREEMPT_RT patchset will be available for 3.15 or 3.17, but there probably will be one for 3.16. I won't have time to take on maintenance of another longterm stable branch besides 3.2, so I think it is important that the version we use can be based on a longterm stable branch maintained by someone else. On that basis, I would like to propose to Greg K-H that his next longterm branch be based on 3.16. [...] I did talk to Greg about this, but as you probably all know by now, he selected 3.14 as there are other major users with earlier freeze dates than us. Ubuntu 14.10 is planned to use Linux 3.16, in which case Ubuntu will maintain a 3.16-stable branch (not blessed by kernel.org, but still following the same rules). So we have a choice between: Linux 3.14-stable - Supported by Greg for about 2 years after release (March 2014) - As an official kernel.org branch, it is likely to get some more testing and review, and more backports from upstream maintainers Linux 3.16-stable - Supported by Ubuntu kernel team for about 15-18 months after distro release (October 2014) - Will support more current hardware and need fewer driver backports Both of these will be supported until about the same time that wheezy reaches EOL, which is when I intend to stop maintaining 3.2-stable. At that point, I would be prepared to take over maintainership of either of the newer branches. There's not an obvious winner out of these two options, but we should choose fairly soon. Please speak up with arguments either way. I have a slight preference to 3.16 as it gets better MIPS hardware support (Loongson 3A, newer Octeon boards, etc.). That said it's not a really strong argument, as I will take advantage of the planned ABI break to backport these changes. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140719080943.ga12...@hall.aurel32.net
Re: Kernel version for jessie
Ben Hutchings b...@decadent.org.uk schrieb: Ubuntu 14.10 is planned to use Linux 3.16, in which case Ubuntu will maintain a 3.16-stable branch (not blessed by kernel.org, but still following the same rules). So we have a choice between: Linux 3.14-stable - Supported by Greg for about 2 years after release (March 2014) - As an official kernel.org branch, it is likely to get some more testing and review, and more backports from upstream maintainers Linux 3.16-stable - Supported by Ubuntu kernel team for about 15-18 months after distro release (October 2014) - Will support more current hardware and need fewer driver backports Both of these will be supported until about the same time that wheezy reaches EOL, which is when I intend to stop maintaining 3.2-stable. At that point, I would be prepared to take over maintainership of either of the newer branches. There's not an obvious winner out of these two options, but we should choose fairly soon. Please speak up with arguments either way. If there's a firm commitment by Canonical to maintain a 3.16 branch we should use that tree. This will provide the 32/64 bit UEFI changes from 3.15. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnlskel1.2ho@inutil.org
Re: Linux kernel ABI bump
On Fri, 2014-07-18 at 17:48 +0100, Ben Hutchings wrote: A kernel ABI bump is needed to enable: - [powerpc] CONFIG_PPC_TRANSACTIONAL_MEM - [powerpc/powerpc64] CONFIG_JUMP_LABEL - CONFIG_DYNAMIC_DEBUG I propose to make these changes with the next upload to unstable. If anyone else has an ABI-breaking change planned, we should try to get that done at the same time. The fix for the arm64 aufs FTBFS issue looks likely to require an ABI bump. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405765026.27009.3.ca...@dagon.hellion.org.uk
aufs3: remove include of linux/fs.h from linux/mm.h
This include is added by aufs3-mmap.patch but causes circular
dependencies on arm64 as seen with the Debian kernel packages in
http://buildd.debian-ports.org/status/fetch.php?pkg=linuxarch=arm64ver=3.14.12-1stamp=1405234443
which contains:
In file included from /«PKGBUILDDIR»/include/linux/mm.h:23:0,
from /«PKGBUILDDIR»/include/linux/pid_namespace.h:6,
from /«PKGBUILDDIR»/include/linux/ptrace.h:9,
from /«PKGBUILDDIR»/arch/arm64/include/asm/compat.h:26,
from /«PKGBUILDDIR»/arch/arm64/include/asm/stat.h:23,
from /«PKGBUILDDIR»/include/linux/stat.h:5,
from /«PKGBUILDDIR»/include/linux/module.h:10,
from /«PKGBUILDDIR»/init/main.c:15:
/«PKGBUILDDIR»/include/linux/fs.h:1575:64: warning: 'struct kstat' declared
inside parameter list [enabled by default]
int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
According to http://article.gmane.org/gmane.linux.ports.arm.kernel/342042
The added mm.h-fs.h looks like a mistake, it should not be there, and we have
in the past worked hard to separate mm.h, sched.h and fs.h from one another.
By turning the various additions to linux/mm.h into macros rather than static
inlines we can avoid the need for the additional includes. Convert all but the
vm?_pr_or_file functions which don't require additional includes and are a bit
trickier to turn into macros (due to having a return value).
Also take the opportunity to wrap the vmr_* macros in ifndef CONFIG_MMU
Signed-off-by: Ian Campbell i...@hellion.org.uk
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -18,9 +18,6 @@
#include linux/pfn.h
#include linux/bit_spinlock.h
#include linux/shrinker.h
-#include linux/dcache.h
-#include linux/file.h
-#include linux/fs.h
struct mempolicy;
struct anon_vma;
@@ -1170,6 +1167,7 @@
#endif
}
+#ifndef CONFIG_MMU
static inline struct file *vmr_do_pr_or_file(struct vm_region *region,
const char func[], int line)
{
@@ -1178,25 +1176,29 @@
return (f pr) ? pr : f;
}
-static inline void vmr_do_fput(struct vm_region *region,
- const char func[], int line)
-{
- struct file *f = region-vm_file, *pr = region-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- fput(f);
- if (f pr)
- fput(pr);
-}
+#define vmr_pr_or_file(region) vmr_do_pr_or_file(region, __func__, \
+ __LINE__)
-static inline void vma_do_file_update_time(struct vm_area_struct *vma,
- const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- file_update_time(f);
- if (f pr)
- file_update_time(pr);
-}
+#define vmr_fput(region) do { \
+ struct vm_region *_region = region; \
+ struct file *f = _region-vm_file, *pr = _region-vm_prfile;\
+ aufs_trace(f, pr, __func__, __LINE__, vmr_fput);\
+ fput(f);\
+ if (f pr)\
+ fput(pr); \
+} while(0);
+
+#endif
+
+#define vma_file_update_time(vma) {\
+ struct vm_area_struct *_vma = vma; \
+ struct file *f = _vma-vm_file, *pr = _vma-vm_prfile; \
+ aufs_trace(f, pr, __func__, __LINE__, \
+ vma_file_update_time); \
+ file_update_time(f);\
+ if (f pr)\
+ file_update_time(pr); \
+} while (0)
static inline struct file *vma_do_pr_or_file(struct vm_area_struct *vma,
const char func[], int line)
@@ -1206,35 +1208,26 @@
return (f pr) ? pr : f;
}
-static inline void vma_do_get_file(struct vm_area_struct *vma,
- const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- get_file(f);
- if (f pr)
- get_file(pr);
-}
+#define vma_pr_or_file(vma)vma_do_pr_or_file(vma, __func__, \
+__LINE__)
-static inline void vma_do_fput(struct vm_area_struct *vma,
- const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- fput(f);
- if (f pr)
- fput(pr);
-}
-
-#define vmr_pr_or_file(region)
aufs3: remove include of linux/fs.h from linux/mm.h
(resending since original post was rejected by aufs-users)
This include is added by aufs3-mmap.patch but causes circular
dependencies on arm64 as seen with the Debian kernel packages in
http://buildd.debian-ports.org/status/fetch.php?pkg=linuxarch=arm64ver=3.14.12-1stamp=1405234443
which contains:
In file included from /«PKGBUILDDIR»/include/linux/mm.h:23:0,
from /«PKGBUILDDIR»/include/linux/pid_namespace.h:6,
from /«PKGBUILDDIR»/include/linux/ptrace.h:9,
from /«PKGBUILDDIR»/arch/arm64/include/asm/compat.h:26,
from /«PKGBUILDDIR»/arch/arm64/include/asm/stat.h:23,
from /«PKGBUILDDIR»/include/linux/stat.h:5,
from /«PKGBUILDDIR»/include/linux/module.h:10,
from /«PKGBUILDDIR»/init/main.c:15:
/«PKGBUILDDIR»/include/linux/fs.h:1575:64: warning: 'struct kstat' declared
inside parameter list [enabled by default]
int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
According to http://article.gmane.org/gmane.linux.ports.arm.kernel/342042
The added mm.h-fs.h looks like a mistake, it should not be there, and we have
in the past worked hard to separate mm.h, sched.h and fs.h from one another.
By turning the various additions to linux/mm.h into macros rather than static
inlines we can avoid the need for the additional includes. Convert all but the
vm?_pr_or_file functions which don't require additional includes and are a bit
trickier to turn into macros (due to having a return value).
Also take the opportunity to wrap the vmr_* macros in ifndef CONFIG_MMU
Signed-off-by: Ian Campbell i...@hellion.org.uk
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -18,9 +18,6 @@
#include linux/pfn.h
#include linux/bit_spinlock.h
#include linux/shrinker.h
-#include linux/dcache.h
-#include linux/file.h
-#include linux/fs.h
struct mempolicy;
struct anon_vma;
@@ -1170,6 +1167,7 @@
#endif
}
+#ifndef CONFIG_MMU
static inline struct file *vmr_do_pr_or_file(struct vm_region *region,
const char func[], int line)
{
@@ -1178,25 +1176,29 @@
return (f pr) ? pr : f;
}
-static inline void vmr_do_fput(struct vm_region *region,
- const char func[], int line)
-{
- struct file *f = region-vm_file, *pr = region-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- fput(f);
- if (f pr)
- fput(pr);
-}
+#define vmr_pr_or_file(region) vmr_do_pr_or_file(region, __func__, \
+ __LINE__)
-static inline void vma_do_file_update_time(struct vm_area_struct *vma,
- const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- file_update_time(f);
- if (f pr)
- file_update_time(pr);
-}
+#define vmr_fput(region) do { \
+ struct vm_region *_region = region; \
+ struct file *f = _region-vm_file, *pr = _region-vm_prfile;\
+ aufs_trace(f, pr, __func__, __LINE__, vmr_fput);\
+ fput(f);\
+ if (f pr)\
+ fput(pr); \
+} while(0);
+
+#endif
+
+#define vma_file_update_time(vma) {\
+ struct vm_area_struct *_vma = vma; \
+ struct file *f = _vma-vm_file, *pr = _vma-vm_prfile; \
+ aufs_trace(f, pr, __func__, __LINE__, \
+ vma_file_update_time); \
+ file_update_time(f);\
+ if (f pr)\
+ file_update_time(pr); \
+} while (0)
static inline struct file *vma_do_pr_or_file(struct vm_area_struct *vma,
const char func[], int line)
@@ -1206,35 +1208,26 @@
return (f pr) ? pr : f;
}
-static inline void vma_do_get_file(struct vm_area_struct *vma,
- const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- get_file(f);
- if (f pr)
- get_file(pr);
-}
+#define vma_pr_or_file(vma)vma_do_pr_or_file(vma, __func__, \
+__LINE__)
-static inline void vma_do_fput(struct vm_area_struct *vma,
- const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- fput(f);
- if (f pr)
-
Bug#755288: linux-image-3.2.0-4-amd64: 4-ports Supermicro ether adapter (I350,igb) - NETDEV WATCHDOG detects errors and resets all ports.
Package: src:linux Version: 3.2.60-1+deb7u1 Severity: important Dear Maintainer, * What led up to the situation? Probably high network load. * What exactly did you do (or not do) that was effective (or ineffective)? Probably I copied large files via NFS. * What was the outcome of this action? Lost network connection. * What outcome did you expect instead? -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.60-1+deb7u1 ** Command line: placeholder root=/dev/mapper/vg0-storage1_rootfs ro pcie_aspm=off quiet pcie_aspm=off ** Tainted: WO (4608) * Taint on warning. * Out-of-tree module has been loaded. ** Kernel log: Jul 7 09:20:11 storage1 kernel: [ 4125.985342] [ cut here ] Jul 7 09:20:11 storage1 kernel: [ 4125.985350] WARNING: at /build/linux-baBndT/linux-3.2.60/net/sched/sch_generic.c:256 dev_watchdog+0xf2/0x151() Jul 7 09:20:11 storage1 kernel: [ 4125.985351] Hardware name: X10SL7-F Jul 7 09:20:11 storage1 kernel: [ 4125.985352] NETDEV WATCHDOG: eth3 (igb): transmit queue 7 timed out Jul 7 09:20:11 storage1 kernel: [ 4125.985353] Modules linked in: xt_physdev iptable_filter ip_tables x_tables xen_netback xen_blkback xen_gntdev xen_evtchn xenfs cpu freq_stats iscsi_trgt(O) cpufreq_userspace crc32c cpufreq_conservative cpufreq_powersave nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc bridge w83627ehf hwmon_vid b onding msr loop 8021q garp stp snd_hda_intel snd_hda_codec snd_hwdep coretemp snd_pcm snd_page_alloc snd_timer shpchp iTCO_wdt iTCO_vendor_support snd crc32c_intel gha sh_clmulni_intel joydev i2c_i801 acpi_cpufreq aesni_intel aes_x86_64 aes_generic cryptd evdev soundcore mperf pcspkr processor video button ext4 crc16 jbd2 mbcache dm_ mod sr_mod cdrom usb_storage usbhid hid sg sd_mod crc_t10dif ahci libahci xhci_hcd libata megaraid_sas mpt2sas raid_class fan scsi_transport_sas thermal thermal_sys sc si_mod igb i2c_algo_bit i2c_core ehci_hcd dca usbcore usb_common [last unloaded: scsi_wait_scan] Jul 7 09:20:11 storage1 kernel: [ 4125.985390] Pid: 0, comm: swapper/0 Tainted: G O 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u1 Jul 7 09:20:11 storage1 kernel: [ 4125.985391] Call Trace: Jul 7 09:20:11 storage1 kernel: [ 4125.985392] IRQ [81046cd9] ? warn_slowpath_common+0x78/0x8c Jul 7 09:20:11 storage1 kernel: [ 4125.985398] [81046d85] ? warn_slowpath_fmt+0x45/0x4a Jul 7 09:20:11 storage1 kernel: [ 4125.985401] [812a8169] ? netif_tx_lock+0x40/0x75 Jul 7 09:20:11 storage1 kernel: [ 4125.985404] [812a82d9] ? dev_watchdog+0xf2/0x151 Jul 7 09:20:11 storage1 kernel: [ 4125.985407] [810524f8] ? run_timer_softirq+0x19a/0x261 Jul 7 09:20:11 storage1 kernel: [ 4125.985409] [8109135c] ? handle_irq_event_percpu+0x15f/0x17d Jul 7 09:20:11 storage1 kernel: [ 4125.985411] [812a81e7] ? netif_tx_unlock+0x49/0x49 Jul 7 09:20:11 storage1 kernel: [ 4125.985413] [8104c36e] ? __do_softirq+0xb9/0x177 Jul 7 09:20:11 storage1 kernel: [ 4125.985416] [8121c9dd] ? __xen_evtchn_do_upcall+0x24a/0x287 Jul 7 09:20:11 storage1 kernel: [ 4125.985419] [813577ec] ? call_softirq+0x1c/0x30 Jul 7 09:20:11 storage1 kernel: [ 4125.985422] [8100fa21] ? do_softirq+0x3c/0x7b Jul 7 09:20:11 storage1 kernel: [ 4125.985424] [8104c5d6] ? irq_exit+0x3c/0x99 Jul 7 09:20:11 storage1 kernel: [ 4125.985426] [8121dd9d] ? xen_evtchn_do_upcall+0x27/0x32 Jul 7 09:20:11 storage1 kernel: [ 4125.985428] [8135783e] ? xen_do_hypervisor_callback+0x1e/0x30 Jul 7 09:20:11 storage1 kernel: [ 4125.985429] EOI [810013aa] ? hypercall_page+0x3aa/0x1000 Jul 7 09:20:11 storage1 kernel: [ 4125.985432] [810013aa] ? hypercall_page+0x3aa/0x1000 Jul 7 09:20:11 storage1 kernel: [ 4125.985434] [8100675a] ? xen_safe_halt+0xc/0x13 Jul 7 09:20:11 storage1 kernel: [ 4125.985436] [8101462c] ? default_idle+0x47/0x7f Jul 7 09:20:11 storage1 kernel: [ 4125.985438] [8100d24c] ? cpu_idle+0xaf/0xf2 Jul 7 09:20:11 storage1 kernel: [ 4125.985440] [816abb36] ? start_kernel+0x3b8/0x3c3 Jul 7 09:20:11 storage1 kernel: [ 4125.985443] [816ad4df] ? xen_start_kernel+0x412/0x418 Jul 7 09:20:11 storage1 kernel: [ 4125.985444] ---[ end trace ea51296b8fd7f0d8 ]--- Jul 7 09:20:11 storage1 kernel: [ 4125.985452] igb :07:00.1: eth3: Reset adapter Jul 7 09:20:11 storage1 kernel: [ 4126.017613] igb :07:00.2: eth4: Reset adapter Jul 7 09:20:11 storage1 kernel: [ 4126.017919] igb :07:00.3: eth5: Reset adapter Jul 7 09:20:11 storage1 kernel: [ 4126.018113] igb :07:00.0: eth2: Reset adapter Jul 7 09:20:11 storage1 kernel: [ 4126.027584] igb: eth2 NIC Link is Down Jul 7 09:20:11 storage1 kernel: [ 4126.093355] bonding: bond0: link status down for interface eth2, disabling it in 200 ms.
Bug#755310: Please enable CONFIG_R8192EE
Package: linux-image-3.16-rc5-amd64 Version: 3.16~rc5-1~exp1 Severity: wishlist Please enable CONFIG_R8192EE, the driver for the Realtek RTL8192EE 802.11 PCIe wireless network adapters. It is required to get the wifi working on my T440s laptop. I built the linux-image-3.16-rc5-amd64 kernel with this option and I can confirm it enabled the wifi. Thanks, Vincent -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761iti4hq@cecht.legt.fr
Re: aufs3: remove include of linux/fs.h from linux/mm.h
Hello Ian, Ian Campbell: This include is added by aufs3-mmap.patch but causes circular dependencies on arm64 as seen with the Debian kernel packages in ::: According to http://article.gmane.org/gmane.linux.ports.arm.kernel/342042 The added mm.h-fs.h looks like a mistake, it should not be there, and we= have in the past worked hard to separate mm.h, sched.h and fs.h from one anoth= er. Hmm, I didn't know such history... Anyway I agree mmap approach in aufs is ugly in the terms of its logic and looking. And I am afraid converting into macros looks still bad-looking. Do you think can we do this? - create a new file mm/aufs_mmap.c - move the inline funcs to the new file. - the calling macros are left in mm.h. - function delarations are added in mm.h. Also take the opportunity to wrap the vmr_* macros in ifndef CONFIG_MMU Is it necessary? struct vm_regin is defined regardless CONFIG_MMU, isn't it? J. R. Okajima -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/13295.1405791504@jrobl
Re: Linux kernel ABI bump
On Sat, 2014-07-19 at 11:17 +0100, Ian Campbell wrote: On Fri, 2014-07-18 at 17:48 +0100, Ben Hutchings wrote: A kernel ABI bump is needed to enable: - [powerpc] CONFIG_PPC_TRANSACTIONAL_MEM - [powerpc/powerpc64] CONFIG_JUMP_LABEL - CONFIG_DYNAMIC_DEBUG I propose to make these changes with the next upload to unstable. If anyone else has an ABI-breaking change planned, we should try to get that done at the same time. The fix for the arm64 aufs FTBFS issue looks likely to require an ABI bump. Right, good timing there. :-) Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Re: aufs3: remove include of linux/fs.h from linux/mm.h
On Sun, 2014-07-20 at 02:38 +0900, sf...@users.sourceforge.net wrote: Hello Ian, Ian Campbell: This include is added by aufs3-mmap.patch but causes circular dependencies on arm64 as seen with the Debian kernel packages in ::: According to http://article.gmane.org/gmane.linux.ports.arm.kernel/342042 The added mm.h-fs.h looks like a mistake, it should not be there, and we= have in the past worked hard to separate mm.h, sched.h and fs.h from one anoth= er. Hmm, I didn't know such history... Anyway I agree mmap approach in aufs is ugly in the terms of its logic and looking. And I am afraid converting into macros looks still bad-looking. Do you think can we do this? - create a new file mm/aufs_mmap.c - move the inline funcs to the new file. - the calling macros are left in mm.h. - function delarations are added in mm.h. That sounds like a plausible plan to me. Also take the opportunity to wrap the vmr_* macros in ifndef CONFIG_MMU Is it necessary? struct vm_regin is defined regardless CONFIG_MMU, isn't it? It is defined but not used except when !CONFIG_MMU and the comment preceding the definition confirms it is !MMU specifc. The type is only used in fs/proc/nommu.c, fs/proc/task_nommu.c and mm/nommu.c. The only users of the two vmr_* macros/inlines are in mm/nommu.c. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405798845.27009.30.ca...@dagon.hellion.org.uk
Bug#749325: Similar problem with ICH7
Hi, I'm a similar problem with another HDA Intel. These are the errors in my case: [7.663820] snd_hda_intel :00:1b.0: enabling device ( - 0002) [7.664648] snd_hda_intel :00:1b.0: irq 42 for MSI/MSI-X [7.723012] intel_rng: FWH not detected [7.766751] hda-intel :00:1b.0: no codecs initialized If I look for the module I get: snd_hda_intel 43768 0 snd_hda_codec 100159 1 snd_hda_intel snd_hwdep 13148 1 snd_hda_codec snd_pcm84566 2 snd_hda_codec,snd_hda_intel snd_timer 26614 1 snd_pcm snd61094 5 snd_hwdep,snd_timer,snd_pcm,snd_hda_codec,snd_hda_intel soundcore 13026 1 snd And finally I haven't any card: $ cat /proc/asound/cards --- no soundcards --- I've tried with newer kernels but the problem continues: - 3.15.5-1~exp1 - 3.16~rc5-1~exp1 Information about my card: $ lspci -nnvv 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 02) Subsystem: Toshiba America Info Systems Device [1179:0001] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 42 Region 0: Memory at 1 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee0300c Data: 41d1 Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- VC1:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=80 Status: NegoPending- InProgress- Capabilities: [130 v1] Root Complex Link Desc: PortNumber=0f ComponentID=02 EltType=Config Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+ Addr: fed1c000 Kernel driver in use: snd_hda_intel Regards,
Re: Kernel version for jessie
On Fri, 2014-07-18 at 22:19 +0100, Ian Campbell wrote: On Fri, 2014-07-18 at 17:43 +0100, Ben Hutchings wrote: On Thu, 2014-05-01 at 17:29 +0100, Ben Hutchings wrote: [...] The earlier we freeze the kernel, the more work will be required to backport fixes and hardware enablement during the jessie support period. So I think that 3.16 would be the best fit. It is also very unlikely that a PREEMPT_RT patchset will be available for 3.15 or 3.17, but there probably will be one for 3.16. I won't have time to take on maintenance of another longterm stable branch besides 3.2, so I think it is important that the version we use can be based on a longterm stable branch maintained by someone else. On that basis, I would like to propose to Greg K-H that his next longterm branch be based on 3.16. [...] I did talk to Greg about this, but as you probably all know by now, he selected 3.14 as there are other major users with earlier freeze dates than us. OOI who is it that is going to be basing on 3.14? I don't know specifically, but he implied that consumer electronics companies would be using it in a lot of products. Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Processed (with 1 errors): forcibly merging 522415 755182
Processing commands for cont...@bugs.debian.org:
forcemerge 522415 755182
Bug #522415 [firmware-nonfree] firmware-nonfree: please create a mother package
for all firmware
Unable to merge bugs because:
package of #755182 is 'src:firmware-nonfree' not 'firmware-nonfree'
Failed to forcibly merge 522415: Did not alter merged bugs
Debbugs::Control::set_merged('transcript', 'GLOB(0x25c26d0)',
'requester', 'Ben Hutchings b...@decadent.org.uk', 'request_addr',
'cont...@bugs.debian.org', 'request_msgid',
'1405817221-3041-bts-...@decadent.org.uk', 'request_subject', ...) called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 552
eval {...} called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 551
Debbugs::Control::Service::control_line('line', undef, 'clonebugs',
'HASH(0x25020b8)', 'limit', 'HASH(0x2501aa0)', 'common_control_options',
'ARRAY(0x2501ae8)', 'errors', ...) called at /usr/lib/debbugs/service line 474
thanks
Stopping processing here.
Please contact me if you need assistance.
--
522415: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522415
755182: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755182
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/handler.s.c.140581723111992.transcr...@bugs.debian.org
Re: Proposed aufs3 vs. arm64 fix
On Fri, 2014-07-18 at 22:35 +0100, Ian Campbell wrote:
[...]
-static inline void vmr_do_fput(struct vm_region *region,
-const char func[], int line)
-{
- struct file *f = region-vm_file, *pr = region-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- fput(f);
- if (f pr)
- fput(pr);
-}
+#define vmr_pr_or_file(region) vmr_do_pr_or_file(region,
__func__, \
+ __LINE__)
-static inline void vma_do_file_update_time(struct vm_area_struct *vma,
-const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- file_update_time(f);
- if (f pr)
- file_update_time(pr);
-}
+#define vmr_fput(_region) do {
\
+ struct vm_region *region = _region; \
Parentheses around _region.
+ struct file *f = region-vm_file, *pr = region-vm_prfile; \
+ aufs_trace(f, pr, __func__, __LINE__, vmr_fput);\
Last argument needs to be quoted (but this is #ifndef CONFIG_MMU... who
cares).
+ fput(f);\
+ if (f pr)\
+ fput(pr); \
+} while(0);
+
+#endif
+
+#define vma_file_update_time(_vma) { \
+ struct vm_area_struct *vma = _vma; \
[...]
Same for _vma (and in the other macros below).
Ben.
--
Ben Hutchings
Kids! Bringing about Armageddon can be dangerous. Do not attempt it in
your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'
signature.asc
Description: This is a digitally signed message part
Bug#755249: IPv6 link non-functional after suspend
On Sat, 2014-07-19 at 08:39 +0200, Christoph Egger wrote: Package: src:linux Version: 3.14.12-1 Severity: important Hi! After suspend/resume the computer is unable to perform any IPv6 connection (no ping to fixed IP, no nc, no anything). tcpdump was unfortunately not helpfull in figuring out where exactly it breaks because, as soon as I start tcpdump, things work again. If I stop tcpdump after resume I can still reach all routed IPv6 addresses but only the local ones I have contacted while tcpdump running. Removing the interface and adding it again helps as well. [...] IPv6 addresses are dropped when the interface is taken down. Do you have a script that does that on suspend? Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Processed: tagging 755249
Processing commands for cont...@bugs.debian.org: tags 755249 + moreinfo Bug #755249 [src:linux] IPv6 link non-functional after suspend Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 755249: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755249 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.140581785415362.transcr...@bugs.debian.org
Processed (with 1 errors): reassign 755182 to src:firmware-nonfree, forcibly merging 522415 755182
Processing commands for cont...@bugs.debian.org:
reassign 755182 src:firmware-nonfree
Bug #755182 [src:firmware-nonfree] firmware-nonfree: Please recommend other
non-free packages
Ignoring request to reassign bug #755182 to the same package
forcemerge 522415 755182
Bug #522415 [firmware-nonfree] firmware-nonfree: please create a mother package
for all firmware
Unable to merge bugs because:
package of #755182 is 'src:firmware-nonfree' not 'firmware-nonfree'
Failed to forcibly merge 522415: Did not alter merged bugs
Debbugs::Control::set_merged('transcript', 'GLOB(0x335bc68)',
'requester', 'Ben Hutchings b...@decadent.org.uk', 'request_addr',
'cont...@bugs.debian.org', 'request_msgid',
'1405818415-3500-bts-...@decadent.org.uk', 'request_subject', ...) called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 552
eval {...} called at
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 551
Debbugs::Control::Service::control_line('line', 'forcemerge 522415
755182', 'clonebugs', 'HASH(0x329b0b8)', 'limit', 'HASH(0x329aaa0)',
'common_control_options', 'ARRAY(0x329aae8)', 'errors', ...) called at
/usr/lib/debbugs/service line 474
thanks
Stopping processing here.
Please contact me if you need assistance.
--
522415: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522415
755182: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755182
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/handler.s.c.140581842319250.transcr...@bugs.debian.org
Processed: reassign 522415 to src:firmware-nonfree, forcibly merging 522415 755182
Processing commands for cont...@bugs.debian.org: reassign 522415 src:firmware-nonfree Bug #522415 [firmware-nonfree] firmware-nonfree: please create a mother package for all firmware Bug reassigned from package 'firmware-nonfree' to 'src:firmware-nonfree'. Ignoring request to alter found versions of bug #522415 to the same values previously set Ignoring request to alter fixed versions of bug #522415 to the same values previously set forcemerge 522415 755182 Bug #522415 [src:firmware-nonfree] firmware-nonfree: please create a mother package for all firmware Bug #522415 [src:firmware-nonfree] firmware-nonfree: please create a mother package for all firmware Marked as found in versions firmware-nonfree/0.43. Bug #755182 [src:firmware-nonfree] firmware-nonfree: Please recommend other non-free packages Merged 522415 755182 thanks Stopping processing here. Please contact me if you need assistance. -- 522415: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522415 755182: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755182 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.140581986926215.transcr...@bugs.debian.org
