Bug#767261: [Pkg-xen-devel] Bug#767261: xen-hypervisor-4.4-amd64: host lockup when DomU network iface is down
On Thu, 2014-11-06 at 11:06 -0500, Gedalya wrote: I suspect we will need to backport some xen-netback patch or other. I've put some feelers out to see if any of the upstream devs have any hints... OK so if it's just a matter of changing a kernel on one box, I can perhaps try to build a 3.18 this weekend I think these commits, which are in v3.18-rc3, are probably the ones: ecf08d2 xen-netback: reintroduce guest Rx stall detection f48da8b xen-netback: fix unlimited guest Rx internal queue and carrier flapping bc96f64 xen-netback: make feature-rx-notify mandatory I'll investigate a backport/check if they are destined for stable@. 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/1415348718.31613.14.ca...@hellion.org.uk
Re: [ANNOUNCE] Linux 3.16.y.z extended stable support
On Thu, Oct 30, 2014 at 06:17:01PM +, Luis Henriques wrote:
The Ubuntu kernel team is pleased to announce that we will be
providing extended stable support for the Linux 3.16 kernel until
April 2016 as a third party effort maintained on our infrastructure.
The team will pick up stable maintenance where Greg KH left off with
v3.16.7 [1]. Thank you, Greg.
In addition to the Ubuntu 14.10 Utopic Unicorn release, the Debian 8
Jessie release will also be based on this kernel [2]. Since the
regular support for Jessie will go beyond April 2016, after this
date Ben Hutchings (or myself) will continue the Linux 3.16 kernel
maintenance.
Our linux-3.16.y{-queue,-review} stable branches will fork from
v3.16.7
and will be published here:
git://kernel.ubuntu.com/ubuntu/linux.git
We will use the same stable request/review workflow and follow the
standard upstream stable kernel rules. More details are available
here [3].
In addition, I would like to announce a change in the kernel numbering
scheme that we will be using: we are adding the string '-ckt'
('Canonical Kernel Team') to the kernel version. So, for example,
kernel '3.16.7.1' becomes '3.16.7-ckt1'.
Note that this change applies *only* to the 3.16 kernel, although in
the future we may consider doing it for other kernels we are currently
maintaining.
Cheers,
--
Luís
We welcome any feedback and contribution to this effort. We will be
posting the first review cycle patch set in a week or two.
[1] https://lkml.org/lkml/2014/10/30/583
[2] https://lists.debian.org/debian-kernel/2014/07/msg00413.html
[3] http://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Cheers,
--
Luís Henriques
Ubuntu Kernel Team, Canonical Ltd.
--
kernel-team mailing list
kernel-t...@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
--
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/20141107104328.GC8365@hercules
Bug#768443: linux-image-3.16.0-4-amd64: Wifi does not connect after kernel upgrade
Package: src:linux Version: 3.16.7-2 Severity: normal Dear Maintainer, Wifi does not connect with kernel 3.16-3 or newer. Wifi is on, and available networks are shown in the Network Manager, but it fails to connect. Kernel 3.16-3, 3.16-0.4 and 3.17-1 are affected. The problem disappears if I reboot with the old kernel 3.16-2, and wifi works as usual. My wireless device is Intel(R) Dual Band Wireless N 7260, and the driver in use is firmware-iwlwifi 0.43. Dmesg log is [ 61.901357] cfg80211: Calling CRDA to update world regulatory domain [ 61.973953] cfg80211: World regulatory domain updated: [ 61.973958] cfg80211: DFS Master region: unset [ 61.973960] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 61.973962] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 61.973964] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 61.973966] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [ 61.973968] cfg80211: (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 mBm), (N/A) [ 61.973969] cfg80211: (525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 61.973971] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 61.973973] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 61.973975] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) [ 65.653540] wlan0: authenticate with 24:de:c6:85:9d:51 [ 65.660053] wlan0: direct probe to 24:de:c6:85:9d:51 (try 1/3) [ 65.865067] wlan0: direct probe to 24:de:c6:85:9d:51 (try 2/3) [ 66.068618] wlan0: direct probe to 24:de:c6:85:9d:51 (try 3/3) [ 66.271234] wlan0: authentication with 24:de:c6:85:9d:51 timed out [ 66.436104] wlan0: authenticate with 00:0b:86:a8:40:a2 [ 66.441948] wlan0: send auth to 00:0b:86:a8:40:a2 (try 1/3) [ 66.443912] wlan0: authenticated [ 66.444116] iwlwifi :03:00.0 wlan0: disabling HT as WMM/QoS is not supported by the AP [ 66.444122] iwlwifi :03:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP [ 66.447178] wlan0: associate with 00:0b:86:a8:40:a2 (try 1/3) [ 66.517413] wlan0: associate with 00:0b:86:a8:40:a2 (try 2/3) [ 66.526295] wlan0: RX AssocResp from 00:0b:86:a8:40:a2 (capab=0x431 status=0 aid=4) [ 66.528890] wlan0: associated [ 86.888138] wlan0: deauthenticating from 00:0b:86:a8:40:a2 by local choice (Reason: 3=DEAUTH_LEAVING) -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=5e07d851-95a4-4505-949e-7021fea40924 ro i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 i915.semaphores=1 nohpet nmi_watchdog=0 init=/bin/systemd ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [3.905599] thinkpad_acpi: radio switch found; radios are enabled [3.905741] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver [3.905747] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... [3.908884] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [3.909425] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [3.912738] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input5 [3.928610] [drm] VBT doesn't support DRRS [4.030580] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [4.047464] fbcon: inteldrmfb (fb0) is primary device [4.070037] Adding 9764860k swap on /dev/sda7. Priority:-1 extents:1 across:9764860k FS [4.108349] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' [4.120028] AVX2 version of gcm_enc/dec engaged. [4.122460] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) [4.127233] iTCO_vendor_support: vendor-support=0 [4.127902] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [4.127937] iTCO_wdt: Found a Lynx Point_LP TCO device (Version=2, TCOBASE=0x1860) [4.128002] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [4.167553] alg: No test for crc32 (crc32-pclmul) [4.207645] cfg80211: World regulatory domain updated: [4.207647] cfg80211: DFS Master region: unset [4.207647] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [4.207649] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [4.207650] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [4.207651] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [4.207652] cfg80211: (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 mBm), (N/A) [
Bug#768452: linux-image-3.16-3-amd64: system locks up every one or two days since upgrade to kernel 3.16
Package: src:linux Version: 3.16.5-1 Severity: important Dear Maintainer, since I have upgraded my system to kernel 3.16 it freezes every one or two days. Neither keyboard nor network access work. Even sysrq keys do not work anymore. I have to power off the machine. The freeze always seems to happen during the nightly backup session (rsnapshot connecting via ssh from a backup server), at least these are the last log messages I get: Nov 07 05:43:52 grappa sshd[2860]: Accepted publickey for root from 172.18.1.1 port 34726 ssh2: RSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx Nov 07 05:43:52 grappa sshd[2860]: pam_unix(sshd:session): session opened for user root by (uid=0) Nov 07 05:43:52 grappa systemd-logind[891]: New session 1966 of user root. Nov 07 05:43:52 grappa systemd[2870]: pam_unix(systemd-user:session): session opened for user root by (uid=0) Nov 07 05:43:52 grappa systemd[2870]: Starting Paths. Nov 07 05:43:52 grappa systemd[2870]: Reached target Paths. Nov 07 05:43:52 grappa systemd[2870]: Starting Timers. Nov 07 05:43:52 grappa systemd[2870]: Reached target Timers. Nov 07 05:43:52 grappa systemd[2870]: Starting Sockets. Nov 07 05:43:52 grappa systemd[2870]: Reached target Sockets. Nov 07 05:43:52 grappa systemd[2870]: Starting Basic System. Nov 07 05:43:52 grappa systemd[2870]: Reached target Basic System. Nov 07 05:43:52 grappa systemd[2870]: Starting Default. Nov 07 05:43:52 grappa systemd[2870]: Reached target Default. Nov 07 05:43:52 grappa systemd[2870]: Startup finished in 7ms. Regards Uwe -- Package-specific info: ** Version: Linux version 3.16-3-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-12) ) #1 SMP Debian 3.16.5-1 (2014-10-10) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16-3-amd64 root=UUID=---- ro quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [ 10.964342] usb 7-4: New USB device found, idVendor=0424, idProduct=2514 [ 10.964347] usb 7-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 10.964638] hub 7-4:1.0: USB hub found [ 10.964708] hub 7-4:1.0: 4 ports detected [ 10.980199] input: HP WMI hotkeys as /devices/virtual/input/input11 [ 11.094389] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 11.094421] iTCO_wdt: Found a ICH9 TCO device (Version=2, TCOBASE=0xf860) [ 11.094476] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 11.336041] usb 8-6: new high-speed USB device number 3 using ehci-pci [ 11.371056] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input4 [ 11.377183] sdb: unknown partition table [ 11.404821] Adding 1959892k swap on /dev/sda10. Priority:-1 extents:1 across:1959892k FS [ 11.485695] usb 8-6: New USB device found, idVendor=0bda, idProduct=0111 [ 11.485700] usb 8-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 11.485703] usb 8-6: Product: USB2.0-CRW [ 11.485706] usb 8-6: Manufacturer: Generic [ 11.485708] usb 8-6: SerialNumber: 2002153705700 [ 11.545068] media: Linux media interface: v0.10 [ 11.564525] Linux video capture interface: v2.00 [ 11.574275] usb-storage 8-6:1.0: USB Mass Storage device detected [ 11.574335] scsi4 : usb-storage 8-6:1.0 [ 11.574399] usbcore: registered new interface driver usb-storage [ 11.584017] sdb: unknown partition table [ 11.670878] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: errors=remount-ro [ 11.699174] usbcore: registered new interface driver snd-usb-audio [ 11.874584] uvcvideo: Found UVC 1.00 device Webcam C170 (046d:082b) [ 11.880101] input: Webcam C170 as /devices/pci:00/:00:1a.7/usb7/7-1/7-1:1.0/input/input12 [ 11.880179] usbcore: registered new interface driver uvcvideo [ 11.880180] USB Video Class driver (1.1.1) [ 11.928050] usb 4-1: new full-speed USB device number 2 using uhci_hcd [ 12.090059] usb 4-1: New USB device found, idVendor=0430, idProduct=100e [ 12.090064] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 12.093101] hub 4-1:1.0: USB hub found [ 12.095048] hub 4-1:1.0: 4 ports detected [ 12.300244] usb 7-4.2: new low-speed USB device number 4 using ehci-pci [ 12.396348] usb 7-4.2: New USB device found, idVendor=046d, idProduct=c016 [ 12.396354] usb 7-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 12.396357] usb 7-4.2: Product: Optical USB Mouse [ 12.396359] usb 7-4.2: Manufacturer: Logitech [ 12.477052] usb 4-1.4: new full-speed USB device number 3 using uhci_hcd [ 12.565277] hidraw: raw HID events driver (C) Jiri Kosina [ 12.568555] usbcore: registered new interface driver usbhid [ 12.568557] usbhid: USB HID core driver [ 12.578586] scsi 4:0:0:0: Direct-Access Generic- Compact Flash1.00 PQ: 0 ANSI: 0 CCS [ 12.579671] input: Logitech Optical USB Mouse as
Processed: Re: Bug#622394: systemd: nfs-common and rpcbind unit files to fix systemd NFS issues properly
Processing control commands: tags 622394 + unreproducible Bug #622394 [nfs-common] nfs-common: breaks systemd - dependency cycle in require-start leads to removal of critical jobs Ignoring request to alter tags of bug #622394 to the same tags previously set -- 622394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622394 748074: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748074 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.b748074.14153705969856.transcr...@bugs.debian.org
Processed: Re: Bug#622394: systemd: nfs-common and rpcbind unit files to fix systemd NFS issues properly
Processing control commands: tags 622394 + unreproducible Bug #622394 [nfs-common] nfs-common: breaks systemd - dependency cycle in require-start leads to removal of critical jobs Added tag(s) unreproducible. -- 622394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622394 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.b622394.14153705969847.transcr...@bugs.debian.org
Bug#622394: systemd: nfs-common and rpcbind unit files to fix systemd NFS issues properly
Control: tags 622394 + unreproducible On Wed, 14 May 2014 at 11:15:19 +1200, Matthew Grant wrote: When running under systemd: o NFS mounts from /etc/fstab do not work. o NFS exports also fail due to rpcbind not starting before nfs-common and nfs- kernel-server I think both of these might have been fixed by some combination of fixing #510528, and changes in systemd v214 improving support for rcS? Test case: * two jessie VMs, server and client, in 192.168.122.x subnet * install nfs-kernel-server on server * /etc/exports on server: /srv 192.168.122.0/255.255.255.0(rw,sync) * mkdir /srv/hello on server * reboot server, it works, no sequencing issues seen in journalctl -b * /etc/fstab on client: 192.168.122.215:/srv /srv nfs _netdev,defaults 0 0 * reboot client, it works, no sequencing issues seen in journalctl -b * client has /srv/hello as desired Having native systemd units would of course be nice, and native systemd units for all rcS services seem like a good release goal for jessie+1, but it seems #622394 (and #748074) might not need to be RC for jessie. I have some natively systemd-ized versions of Matthew's systemd units (with enhancements for simpler tmpfiles handling than Riku's debdiff, more correct dependencies, and /etc/default handling) but so far they are untested. I'll try to test them on these VMs later. Regards, S -- 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/20141107142953.ga3...@reptile.pseudorandom.co.uk
Re: [ANNOUNCE] Linux 3.16.y.z extended stable support
On Fri, Nov 07, 2014 at 10:43:28AM +, Luis Henriques wrote:
On Thu, Oct 30, 2014 at 06:17:01PM +, Luis Henriques wrote:
The Ubuntu kernel team is pleased to announce that we will be
providing extended stable support for the Linux 3.16 kernel until
April 2016 as a third party effort maintained on our infrastructure.
The team will pick up stable maintenance where Greg KH left off with
v3.16.7 [1]. Thank you, Greg.
In addition to the Ubuntu 14.10 Utopic Unicorn release, the Debian 8
Jessie release will also be based on this kernel [2]. Since the
regular support for Jessie will go beyond April 2016, after this
date Ben Hutchings (or myself) will continue the Linux 3.16 kernel
maintenance.
Our linux-3.16.y{-queue,-review} stable branches will fork from
v3.16.7
and will be published here:
git://kernel.ubuntu.com/ubuntu/linux.git
We will use the same stable request/review workflow and follow the
standard upstream stable kernel rules. More details are available
here [3].
In addition, I would like to announce a change in the kernel numbering
scheme that we will be using: we are adding the string '-ckt'
('Canonical Kernel Team') to the kernel version. So, for example,
kernel '3.16.7.1' becomes '3.16.7-ckt1'.
Thank you for doing this.
greg k-h
--
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/20141107161632.gb12...@kroah.com
Processed: Re: Bug#768452: linux-image-3.16-3-amd64: system locks up every one or two days since upgrade to kernel 3.16
Processing commands for cont...@bugs.debian.org: found 768452 3.16.3-2 Bug #768452 [src:linux] linux-image-3.16-3-amd64: system locks up every one or two days since upgrade to kernel 3.16 Marked as found in versions linux/3.16.3-2. End of message, stopping processing here. Please contact me if you need assistance. -- 768452: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768452 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.141537914215380.transcr...@bugs.debian.org
Bug#751398: marked as done (linux-image-3.14-1-686-pae: kernel switches off cooling on HP Compaq nx8220)
Your message dated Fri, 7 Nov 2014 18:12:50 +0100 with message-id 20141107171250.gd23...@ibr.ch and subject line Re: Bug#751398: linux-image-3.14-1-686-pae: kernel switches off cooling on HP Compaq nx8220 has caused the Debian Bug report #751398, regarding linux-image-3.14-1-686-pae: kernel switches off cooling on HP Compaq nx8220 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.) -- 751398: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751398 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: src:linux Version: 3.14.4-1 Severity: important Dear Maintainer, kernel 3.14 switches off cooling on my laptop. The fans do not start even when the temperature reported by acpi raises above 100 °C (I've stopped there to not damage the hardware). There is no fan controlling software like lm-sensors/fancontrol installed. Booting with kernel 3.2 fixes the problem, fans work normal and start to work at about 50 to 60 °C. Regards Uwe -- Package-specific info: ** Version: Linux version 3.14-1-686-pae (debian-kernel@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-21) ) #1 SMP Debian 3.14.4-1 (2014-05-13) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.14-1-686-pae root=UUID=32077a82-12e5-4f22-a606-1dd16fcd68c1 ro quiet ** Not tainted ** Kernel log: [6.881925] radeon :01:00.0: radeon: using MSI. [6.881957] [drm] radeon: irq initialized. [6.881974] [drm] Loading R300 Microcode [6.918172] radeon :01:00.0: firmware: direct-loading firmware radeon/R300_cp.bin [6.918525] [drm] radeon: ring at 0xA0001000 [6.918553] [drm] ring test succeeded in 0 usecs [6.918849] [drm] ib test succeeded in 0 usecs [6.920600] [drm] Panel ID String: LPL [6.920606] [drm] Panel Size 1680x1050 [6.941407] [drm] radeon legacy LVDS backlight initialized [6.941413] [drm] Radeon Display Connectors [6.941418] [drm] Connector 0: [6.941422] [drm] VGA-1 [6.941429] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 [6.941432] [drm] Encoders: [6.941437] [drm] CRT1: INTERNAL_DAC1 [6.941441] [drm] Connector 1: [6.941445] [drm] DVI-D-1 [6.941448] [drm] HPD1 [6.941454] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 [6.941457] [drm] Encoders: [6.941461] [drm] DFP1: INTERNAL_TMDS1 [6.941465] [drm] Connector 2: [6.941469] [drm] LVDS-1 [6.941475] [drm] DDC: 0x68 0x68 0x68 0x68 0x68 0x68 0x68 0x68 [6.941478] [drm] Encoders: [6.941482] [drm] LCD1: INTERNAL_LVDS [6.941486] [drm] Connector 3: [6.941490] [drm] SVIDEO-1 [6.941493] [drm] Encoders: [6.941496] [drm] TV1: INTERNAL_DAC2 [7.012097] [drm] fb mappable at 0xC00C [7.012100] [drm] vram apper at 0xC000 [7.012102] [drm] size 7057408 [7.012103] [drm] fb depth is 24 [7.012105] [drm]pitch is 6720 [7.012291] fbcon: radeondrmfb (fb0) is primary device [7.035649] input: HP WMI hotkeys as /devices/virtual/input/input14 [7.061201] Console: switching to colour frame buffer device 210x65 [7.085861] radeon :01:00.0: fb0: radeondrmfb frame buffer device [7.085864] radeon :01:00.0: registered panic notifier [7.087335] [drm] Initialized radeon 2.37.0 20080528 for :01:00.0 on minor 0 [7.320066] intel8x0_measure_ac97_clock: measured 55416 usecs (2670 samples) [7.320076] intel8x0: clocking to 48000 [7.404869] psmouse serio4: synaptics: Touchpad model: 1, fw: 6.2, id: 0x25a0b1, caps: 0xa04793/0x30/0x0, board id: 71, fw id: 35334 [7.404886] psmouse serio4: synaptics: serio: Synaptics pass-through port at isa0060/serio4/input0 [7.444144] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input12 [8.259747] cfg80211: World regulatory domain updated: [8.259757] cfg80211: DFS Master region: unset [8.259762] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [8.259769] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm) [8.259774] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm) [8.259780] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm) [8.259785] cfg80211: (517 KHz - 525 KHz @ 8 KHz), (N/A, 2000 mBm) [8.259790] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm) [8.259795] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm) [9.381183] Adding 979960k swap on /dev/sda2. Priority:-1 extents:1 across:979960k [
Bug#763155: linux-image-3.16.0-4-686-pae: Probably resolved in 3.16.0-4-686
Package: src:linux Followup-For: Bug #763155 Hello, Successfully running 3.16.0-4-686-pae right now. Either the problem is gone, or it doesn't occur on every boot. (Different EEEpc model, though) -- Package-specific info: ** Version: Linux version 3.16.0-4-686-pae (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-686-pae root=UUID=aa89f4fe-2436-40c9-b83b-1feb9e644084 ro quiet splash pciehp.pciehp_force=1 resume=UUID=afcf3a0f-4df7-4a4a-b221-73709c3dbd27 i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.semaphores=1 video.use_native_backlight=0 ** Not tainted ** Kernel log: [ 2921.017954] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 2921.017974] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement) [ 2921.017983] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) [ 2921.032449] cfg80211: Calling CRDA to update world regulatory domain [ 2921.104218] cfg80211: World regulatory domain updated: [ 2921.104230] cfg80211: DFS Master region: unset [ 2921.104237] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 2921.104248] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 2921.104257] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 2921.104265] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [ 2921.104274] cfg80211: (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 mBm), (N/A) [ 2921.104284] cfg80211: (525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 2921.104293] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 2921.104301] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 2921.104310] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) [ 2921.148124] wlan0: authenticate with 00:03:52:e4:31:54 [ 2921.148297] wlan0: send auth to 00:03:52:e4:31:54 (try 1/3) [ 2921.149565] wlan0: authenticated [ 2921.152087] wlan0: associate with 00:03:52:e4:31:54 (try 1/3) [ 2921.153909] wlan0: RX AssocResp from 00:03:52:e4:31:54 (capab=0xc31 status=0 aid=3) [ 2921.154466] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated [ 2921.154488] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement) [ 2921.154503] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) [ 2921.154547] wlan0: associated [ 2921.154765] cfg80211: Calling CRDA for country: DE [ 2921.176122] cfg80211: Regulatory domain changed to country: DE [ 2921.176131] cfg80211: DFS Master region: ETSI [ 2921.176136] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 2921.176145] cfg80211: (240 KHz - 2483500 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 2921.176153] cfg80211: (515 KHz - 525 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 2921.176161] cfg80211: (525 KHz - 535 KHz @ 8 KHz), (N/A, 2000 mBm), (0 s) [ 2921.176169] cfg80211: (547 KHz - 5725000 KHz @ 8 KHz), (N/A, 2698 mBm), (0 s) [ 2921.176176] cfg80211: (5724 KHz - 6588 KHz @ 216 KHz), (N/A, 4000 mBm), (N/A) [ 2934.028136] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 2934.028157] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement) [ 2934.028166] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) [ 2934.041662] cfg80211: Calling CRDA to update world regulatory domain [ 2934.143891] cfg80211: World regulatory domain updated: [ 2934.143902] cfg80211: DFS Master region: unset [ 2934.143907] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 2934.143916] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 2934.143924] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 2934.143931] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [ 2934.143939] cfg80211: (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 mBm), (N/A) [ 2934.143946] cfg80211: (525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 2934.143954] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 2934.143962] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 2934.143969] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) [ 2934.750435] wlan0: authenticate with 00:03:52:e4:30:f4 [ 2934.752361] wlan0: send auth to 00:03:52:e4:30:f4 (try 1/3) [ 2934.756115] wlan0: authenticated [ 2934.760082] wlan0: associate with 00:03:52:e4:30:f4 (try 1/3) [ 2934.762131] wlan0: RX AssocResp from 00:03:52:e4:30:f4 (capab=0xc31 status=0 aid=1) [
Bug#622394: systemd: nfs-common and rpcbind unit files to fix systemd NFS issues properly
(Please keep the bug in Cc when replying to a bug, so it goes into the bug record for other developers to refer to.) On 07/11/14 14:57, Chris Butler wrote: I think both of these might have been fixed by some combination of fixing #510528, and changes in systemd v214 improving support for rcS? Not sure that's the case. The systems where I was seeing the problem are running: ii nfs-common 1:1.2.8-9 ii systemd 215-5+b1 [...] It seemed like systemd had no idea that it needed to start the NFS client services before mounting NFS filesystems, and was instead running the two jobs in parallel. It happened to work 9 times out of 10 (I guess if the services started up quickly enough), but not always. Your fstab says: #shalom:/src/media/src nfs noauto,defaults,user,exec 0 0 #shalom:/home /media/home nfs noauto,defaults,user,exec 0 0 #en-gedi:/home /srv/home nfs noauto,async,_netdev,soft,intr,defaults,exec0 0 I notice in particular that /media/src and /media/home do not have _netdev in the options field. That's probably why systemd can't tell they are network devices (although, arguably, it should be able to guess that by hard-coding knowledge that nfs is a networked filesystem - there's been some discussion of that on the systemd mailing list). Are your boot problems always with /media/src and /media/home, and never with /srv/home? I'll try removing _netdev from my client VM's fstab and trying again. S -- 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/545d2095.9030...@debian.org
Bug#622394: systemd: nfs-common and rpcbind unit files to fix systemd NFS issues properly
On 07/11/14 19:42, Simon McVittie wrote: On 07/11/14 14:57, Chris Butler wrote: Not sure that's the case. The systems where I was seeing the problem are running: ii nfs-common 1:1.2.8-9 ii systemd 215-5+b1 Your fstab says: Sorry, I'm mixing up the various people reporting related but distinct symptoms. That was Matthew's fstab. For an attempt at more clarity, here are the distinct sets of symptoms that have been reported. Please correct me if I'm wrong on any of these. Bug A, reported by Alban Browaeys, present in 1:1.2.3-2: systemd[1]: Found ordering cycle on basic.target/start and an unbootable system. I believe newer systemd and/or nfs-common have probably fixed this, so #622394 should probably have been closed, and the other symptoms should probably have had distinct bug numbers. Bug M1, reported by Matthew Grant, present in 1:1.2.8-6: NFS mounts from /etc/fstab do not work. (What symptoms? What error messages?) This one might be related to NFS entries in /etc/fstab that don't have _netdev. Bug M2, reported by Matthew Grant, present in 1:1.2.8-6: NFS exports also fail due to rpcbind not starting before nfs-common and nfs- kernel-server. Bug C1, sort-of-reported by Chris Butler, present in 1:1.2.8-9: the boot order problem on NFS clients that mount remote filesystems on boot. This might be the same thing as M1. (Do you have _netdev in the options of the relevant mounts?) Bug C2, reported by Chris Butler, present in 1:1.2.8-9 with Matthew's systemd units added: 'tries to start statd before rpcbind'. I believe this is an omission in one of Matthew's systemd units, and I am about to test a version of nfs-common that should fix that bit. S -- 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/545d2a32.7080...@debian.org
Bug#768513: nfs-common: please use socket activation from newer upstream
Package: nfs-common Version: 1:1.2.8-6 Severity: wishlist Control: submitter -1 m...@mattgrant.net.nz Control: block -1 by 756900 On Wed, 14 May 2014 at 11:15:19 +1200, Matthew Grant wrote: All the NFS RPC daemons have port activation in latest nfs-utils upstream, and service files. Please consider using these as the socket activation saves haing to manually configure which NFS RPC daemons are needed. Opening a new bug for this feature request, since it isn't going to happen for Debian 8. It will be necessary to be a bit careful about this, since upstream seems to use nfs-utils.service for the start all the things service, whereas Debian uses (/etc/init.d/nfs-common, corresponding to) nfs-common.service. nfs-common.service could probably be an Alias for nfs-utils.service or something. S -- 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/20141108004806.ga7...@reptile.pseudorandom.co.uk
Processed: nfs-common: please use socket activation from newer upstream
Processing control commands: submitter -1 m...@mattgrant.net.nz Bug #768513 [nfs-common] nfs-common: please use socket activation from newer upstream Changed Bug submitter to 'm...@mattgrant.net.nz' from 'Simon McVittie s...@debian.org' block -1 by 756900 Bug #768513 [nfs-common] nfs-common: please use socket activation from newer upstream 768513 was not blocked by any bugs. 768513 was not blocking any bugs. Added blocking bug(s) of 768513: 756900 -- 768513: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768513 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.b.141540768811896.transcr...@bugs.debian.org
Bug#622394: systemd: nfs-common and rpcbind unit files to fix systemd NFS issues properly
I've now tried a version of nfs-common and rpcbind with systemd units similar to those that Matthew Grant attached to bugs #622394 and #748074. See attached for the patches I used. The short version is that I don't think those systemd units are either necessary or sufficient to fix the various issues reported in later mails to #622394; but if they're advantageous for whatever reason, I would suggest using my adjusted versions. (Riku: sorry, I did this rpcbind patch independently before seeing the one you attached to #748074. I think mine is a small improvement over yours, but I also think it might be a red herring in terms of solving this bug.) On 07/11/14 20:23, Simon McVittie wrote: Bug M1, reported by Matthew Grant, present in 1:1.2.8-6: NFS mounts from /etc/fstab do not work. (What symptoms? What error messages?) This one might be related to NFS entries in /etc/fstab that don't have _netdev. The symptom that *I* get on some boots is these messages in the NFS client's Journal/syslog (my test-case for NFS is mounting one machine's /srv onto the other machine's /srv): mount[309]: mount.nfs: Network is unreachable systemd[1]: srv.mount mount process exited, code=exited status=32 systemd[1]: Failed to mount /srv. systemd[1]: Dependency failed for Remote File Systems. systemd[1]: Unit srv.mount entered failed state. ... because systemd tries to mount /srv shortly before the DHCP client comes up, which isn't going to work well. Does that resemble what you get? The patched packages do not improve this; neither do they make it worse. systemd is meant to recognise network mounts in fstab automatically (it knows about cifs, smbfs, sshfs, ncpfs, ncp, nfs, nfs4, gfs, gfs2, glusterfs) so it should't be necessary to have _netdev in the options field, but perhaps that isn't working correctly for whatever reason? Or perhaps waiting for network-online.target is not necessarily sufficient with some network connectivity setups? (My test systems are using ifupdown and DHCP, not NetworkManager or systemd-networkd or anything.) Bug M2, reported by Matthew Grant, present in 1:1.2.8-6: NFS exports also fail due to rpcbind not starting before nfs-common and nfs- kernel-server. I have not been able to reproduce this, with or without native systemd units. One possible reason why this could happen sometimes is that /etc/init.d/rpcbind has Provides: rpcbind, which seems ... redundant. I would expect it to have Provides: $portmap in order to be ordered before nfs-common, which has Required-Start: $portmap. If that is in error, cloning an rpcbind bug would seem appropriate. Bug C1, sort-of-reported by Chris Butler, present in 1:1.2.8-9: the boot order problem on NFS clients that mount remote filesystems on boot. This might be the same thing as M1. (Do you have _netdev in the options of the relevant mounts?) It isn't completely clear to me what boot order problem this refers to, so I can't say whether I can reproduce it. Bug C2, reported by Chris Butler, present in 1:1.2.8-9 with Matthew's systemd units added: 'tries to start statd before rpcbind'. I believe this is an omission in one of Matthew's systemd units, and I am about to test a version of nfs-common that should fix that bit. I think this is the missing line, to be added to the Unit section: After=rpcbind.service time-sync.target (only rpcbind.service is directly relevant here, but it seems better to be correct) If I'm correct about that, then this part is a regression caused by Matthew's systemd units, and not a bug in the nfs-common package that currently exists in Debian. S diff -Nru nfs-utils-1.2.8/debian/control nfs-utils-1.2.8/debian/control --- nfs-utils-1.2.8/debian/control 2014-08-13 01:12:43.0 +0100 +++ nfs-utils-1.2.8/debian/control 2014-11-07 10:45:39.0 + @@ -3,7 +3,7 @@ Section: net Maintainer: Debian kernel team debian-kernel@lists.debian.org Uploaders: Anibal Monsalve Salazar ani...@debian.org, Ben Hutchings b...@decadent.org.uk, Steve Langasek vor...@debian.org -Build-Depends: debhelper (= 7), libwrap0-dev, libevent-dev, libnfsidmap-dev (= 0.24), libkrb5-dev, libblkid-dev, libkeyutils-dev, pkg-config, libldap2-dev, libcap-dev, libtirpc-dev (= 0.2.4-2~), libdevmapper-dev, dh-autoreconf, libmount-dev, libsqlite3-dev +Build-Depends: debhelper (= 7), libwrap0-dev, libevent-dev, libnfsidmap-dev (= 0.24), libkrb5-dev, libblkid-dev, libkeyutils-dev, pkg-config, libldap2-dev, libcap-dev, libtirpc-dev (= 0.2.4-2~), libdevmapper-dev, dh-autoreconf, libmount-dev, libsqlite3-dev, dh-systemd Standards-Version: 3.9.0 Homepage: http://nfs.sourceforge.net/ Vcs-Git: git://git.debian.org/kernel/nfs-utils.git diff -Nru nfs-utils-1.2.8/debian/nfs-common.service nfs-utils-1.2.8/debian/nfs-common.service --- nfs-utils-1.2.8/debian/nfs-common.service 1970-01-01 01:00:00.0 +0100 +++ nfs-utils-1.2.8/debian/nfs-common.service 2014-11-07 10:40:16.0 + @@ -0,0 +1,14 @@ +[Unit] +Description=NFS Common
Processed: tagging 622394
Processing commands for cont...@bugs.debian.org: tags 622394 - unreproducible Bug #622394 [nfs-common] nfs-common: breaks systemd - dependency cycle in require-start leads to removal of critical jobs Removed tag(s) unreproducible. thanks Stopping processing here. Please contact me if you need assistance. -- 622394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622394 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.141540794313847.transcr...@bugs.debian.org
Bug#622394: systemd: nfs-common and rpcbind unit files to fix systemd NFS issues properly
On Sat, 2014-11-08 at 00:37 +, Simon McVittie wrote: [...] On 07/11/14 20:23, Simon McVittie wrote: Bug M1, reported by Matthew Grant, present in 1:1.2.8-6: NFS mounts from /etc/fstab do not work. (What symptoms? What error messages?) This one might be related to NFS entries in /etc/fstab that don't have _netdev. The symptom that *I* get on some boots is these messages in the NFS client's Journal/syslog (my test-case for NFS is mounting one machine's /srv onto the other machine's /srv): mount[309]: mount.nfs: Network is unreachable systemd[1]: srv.mount mount process exited, code=exited status=32 systemd[1]: Failed to mount /srv. systemd[1]: Dependency failed for Remote File Systems. This line seems to indicate that /srv was a dependency for 'Remote File Systems', i.e. it has correctly been recognised as remote. systemd[1]: Unit srv.mount entered failed state. ... because systemd tries to mount /srv shortly before the DHCP client comes up, which isn't going to work well. Does that resemble what you get? The patched packages do not improve this; neither do they make it worse. systemd is meant to recognise network mounts in fstab automatically (it knows about cifs, smbfs, sshfs, ncpfs, ncp, nfs, nfs4, gfs, gfs2, glusterfs) so it should't be necessary to have _netdev in the options field, but perhaps that isn't working correctly for whatever reason? Or perhaps waiting for network-online.target is not necessarily sufficient with some network connectivity setups? (My test systems are using ifupdown and DHCP, not NetworkManager or systemd-networkd or anything.) But network-online.target doesn't seem to have any integration with ifupdown, i.e. there is no ifupdown-wait-online.service. Bug M2, reported by Matthew Grant, present in 1:1.2.8-6: NFS exports also fail due to rpcbind not starting before nfs-common and nfs- kernel-server. I have not been able to reproduce this, with or without native systemd units. One possible reason why this could happen sometimes is that /etc/init.d/rpcbind has Provides: rpcbind, which seems ... redundant. I would expect it to have Provides: $portmap in order to be ordered before nfs-common, which has Required-Start: $portmap. So would I. But this should result in breakage under sysvinit too. If that is in error, cloning an rpcbind bug would seem appropriate. [...] Yes. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#767261: [Pkg-xen-devel] Bug#767261: xen-hypervisor-4.4-amd64: host lockup when DomU network iface is down
On 11/07/2014 03:25 AM, Ian Campbell wrote: On Thu, 2014-11-06 at 11:06 -0500, Gedalya wrote: I suspect we will need to backport some xen-netback patch or other. I've put some feelers out to see if any of the upstream devs have any hints... OK so if it's just a matter of changing a kernel on one box, I can perhaps try to build a 3.18 this weekend I think these commits, which are in v3.18-rc3, are probably the ones: ecf08d2 xen-netback: reintroduce guest Rx stall detection f48da8b xen-netback: fix unlimited guest Rx internal queue and carrier flapping bc96f64 xen-netback: make feature-rx-notify mandatory I'll investigate a backport/check if they are destined for stable@. Ian. Tried to just frankenport xen-netback from 3.18 into 3.16, didn't work very well ;-) I'm running 3.18rc3+ now. Bombarding the downed interface by broadcast-pinging the network it's on causes the following [ 281.396014] vif vif-3-0 vif3.0: Guest Rx stalled [ 281.396080] breth1: port 3(vif3.0) entered disabled state and that's it. This is instead of the previously repeated 'draining TX queue' messages. Let's assume it won't crash, I'll let you know if this assumption turns out to be wrong. I'm kind of curious why this is preceded by [ 46.232475] vif vif-3-0 vif3.0: Guest Rx ready [ 46.232514] IPv6: ADDRCONF(NETDEV_CHANGE): vif3.0: link becomes ready And the host figures out it's down only when traffic comes and doesn't get through. I guess this might change if I run 3.18 in the guest too? -- 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/545daceb.7050...@gedalya.net
