[Kernel-packages] [Bug 1597267] Re: ThinkPad X260 connecting external DisplayPort hangs system
Current xenial linux-image-4.4.0-62-generic remains broken, with dmesg WARNs on CRTC clocks and then system hangs when switching user sessions (which invokes some gnome-session xrandr setup). Lost the exact dmesg on the system hang. Current mainline 4.8.x (4.8.17-040817-generic) continues to behave nicely, although there's occasionally some delays when docking/undocking before the xrandr configuration updates. The 4.8 kernel is also included in the 16.04.02 HWE release, and a quick test with linux-image-4.8.0-36-generic seems to also behave reasonably well. I would tentatively consider this issue fixed in 16.04.02, although I still need to test with xserver-xorg-hwe-16.04. Will also test with the newest mainline 4.10 release when I have the chance. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597267 Title: ThinkPad X260 connecting external DisplayPort hangs system Status in linux package in Ubuntu: Incomplete Bug description: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. I have attached a journalctl log from running 4.7.0-040700rc5-generic and connecting the DP monitor while in a text console, before switching to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The first warnings come immediately when connecting, and others when switching consoles and logging in. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-28-generic 4.4.0-28.47 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Uname: Linux 4.4.0-28-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: terom 1903 F pulseaudio CurrentDesktop: Unity Date: Wed Jun 29 13:03:18 2016 InstallationDate: Installed on 2016-06-26 (2 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) MachineType: LENOVO 20F6007RGE ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-28-generic root=UUID=6636a3bb-262e-4ab2-ae81-d9388e3f7684 ro rootflags=subvol=@ quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-28-generic N/A linux-backports-modules-4.4.0-28-generic N/A linux-firmware1.157.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/01/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R02ET48W (1.21 ) dmi.board.asset.tag: Not Available dmi.board.name: 20F6007RGE dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR02ET48W(1.21):bd06/01/2016:svnLENOVO:pn20F6007RGE:pvrThinkPadX260:rvnLENOVO:rn20F6007RGE:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20F6007RGE dmi.product.version: ThinkPad X260 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597267/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1597267] Re: ThinkPad X260 connecting external DisplayPort hangs system
I've had good enough experiences with mainline 4.8.15 at this point that I would consider this bug fixed in linux 4.8.x; it's still not perfect (have to typically play around with xrandr and maybe undock/dock), but external 4k DP monitor via a ThinkPad dock works fairly reliably now. OTOH I was unable to get any DP video output at all with mainline Linux 4.9... -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597267 Title: ThinkPad X260 connecting external DisplayPort hangs system Status in linux package in Ubuntu: Triaged Bug description: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. I have attached a journalctl log from running 4.7.0-040700rc5-generic and connecting the DP monitor while in a text console, before switching to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The first warnings come immediately when connecting, and others when switching consoles and logging in. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-28-generic 4.4.0-28.47 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Uname: Linux 4.4.0-28-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: terom 1903 F pulseaudio CurrentDesktop: Unity Date: Wed Jun 29 13:03:18 2016 InstallationDate: Installed on 2016-06-26 (2 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) MachineType: LENOVO 20F6007RGE ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-28-generic root=UUID=6636a3bb-262e-4ab2-ae81-d9388e3f7684 ro rootflags=subvol=@ quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-28-generic N/A linux-backports-modules-4.4.0-28-generic N/A linux-firmware1.157.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/01/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R02ET48W (1.21 ) dmi.board.asset.tag: Not Available dmi.board.name: 20F6007RGE dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR02ET48W(1.21):bd06/01/2016:svnLENOVO:pn20F6007RGE:pvrThinkPadX260:rvnLENOVO:rn20F6007RGE:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20F6007RGE dmi.product.version: ThinkPad X260 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597267/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1597267] Re: ThinkPad X260 connecting external DisplayPort hangs system
I've been running the 4.8.x mainline release kernels recently, and had some success with 4k DP connected to the dock. It doesn't always work, but a reboot fixes it, until it breaks again. I'd appreciate advice for debugging this, it's pretty reproducible, but typically when it happens I don't exactly have the time to start debugging it, and just reboot. With recent 4.8.10 kernels the symptom is usually that xrandr does indeed detect and configure the display, but the monitor does not get any signal and remains black. This is accompanied with the following dmesg: marras 23 11:43:46 tehobari kernel: Linux version 4.8.10-040810-generic (kernel@tangerine) (gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #20161121053 marras 24 10:23:00 tehobari kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up marras 24 10:23:00 tehobari kernel: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit marras 24 10:23:00 tehobari kernel: [drm] RC6 on marras 24 10:23:00 tehobari kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to get link status marras 24 10:23:00 tehobari kernel: thinkpad_acpi: EC reports that Thermal Table has changed marras 24 10:23:00 tehobari kernel: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit marras 24 10:23:00 tehobari kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up marras 24 10:23:00 tehobari kernel: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit marras 24 10:23:00 tehobari kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up marras 24 10:23:00 tehobari kernel: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit marras 24 10:23:00 tehobari kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up marras 24 10:23:00 tehobari kernel: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit marras 24 10:23:00 tehobari kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up marras 24 10:23:00 tehobari kernel: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit marras 24 10:23:00 tehobari kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up marras 24 10:23:00 tehobari kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting marras 24 10:23:00 tehobari kernel: [drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns Once this happens, AFAIK nothing short of a reboot will restore 4k DP output on the dock. When I tried to fall back to the integrated miniDP output, I was able to get a 1080p image, but no 4k image. I upgraded to 4.8.11 having the following changelog entry: "drm/i915: Refresh that status of MST capable connectors in ->detect()". Now I'm no longer seeing the dmesg entries, but I still have occasional issues with the DP output not working reliabily... not had a chance to figure those out yet. Here's some random bits of kernel dmesgs for 4.8.6, thrown in for good measure: marras 08 18:37:04 tehobari kernel: Linux version 4.8.6-040806-generic (kernel@tangerine) (gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #201610310831 SMP Mon Oct 31 12:33:48 UTC 2016 marras 08 18:37:04 tehobari kernel: [drm] Finished loading i915/skl_dmc_ver1_26.bin (v1.26) marras 08 18:37:04 tehobari kernel: [drm] Finished loading i915/skl_dmc_ver1_26.bin (v1.26) marras 09 17:49:12 tehobari kernel: [ cut here ] marras 09 17:49:12 tehobari kernel: WARNING: CPU: 1 PID: 10699 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:14305 skl_max_scale.part.120+0x75/0x80 [i915] marras 09 17:49:12 tehobari kernel: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) marras 09 18:10:29 tehobari kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training marras 09 18:10:30 tehobari kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization marras 09 19:18:58 tehobari kernel: [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22 marras 09 19:18:58 tehobari kernel: [drm] RC6 on marras 09 20:08:28 tehobari kernel: [ cut here ] marras 09 20:08:28 tehobari kernel: WARNING: CPU: 3 PID: 10699 at /home/kernel/COD/linux/drivers/gpu/drm/drm_modeset_lock.c:343 drm_modeset_lock+0xd1/0xe0 [dr m] -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597267 Title: ThinkPad X260 connecting external DisplayPort hangs system Status in linux package in Ubuntu: Triaged Bug description: Running Ubuntu
[Kernel-packages] [Bug 1597267] Re: ThinkPad X260 connecting external DisplayPort hangs system
I've been having more luck with the newer 4.7 and 4.8 kernels, and using a 4k monitor on the integrated DP connector mostly works okay at 60Hz. Haven't really noticed any difference in stability with the xorg.conf.d/20-intel.conf settings in https://github.com/linuxenko /ubuntu-skylake-i915-video-fix. I also tried with `Option "DRI" "false"`. Currently running 4.8.0-040800rc5-generic together with yakkety linux- firmware 1.160: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-=-=- ii linux-firmware1.160 all Firmware for Linux kernel drivers ii linux-image-4.8.0-040800rc5-gener 4.8.0-040800rc5.20160 amd64 Linux kernel image for version 4.8.0 on 64 bit x86 SMP Still getting warnings in dmesg when connecting a DP monitor: [ ...] Linux version 4.8.0-040800rc5-generic (kernel@tangerine) (gcc version 6.2.0 20160830 (Ubuntu 6.2.0-2ubuntu11) ) #201609041832 SMP Sun Sep 4 22:34:01 UTC 2016 [ 330.453739] [ cut here ] [ 330.453793] WARNING: CPU: 0 PID: 5134 at /home/kernel/COD/linux/drivers/gpu/drm/drm_irq.c:1215 drm_wait_one_vblank+0x16b/0x1b0 [drm] [ 330.453796] vblank not available on crtc 0, ret=-22 [ 330.453798] Modules linked in: uas usb_storage hid_lenovo usbhid hid ctr ccm pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) rfcomm fuse ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack br_netfilter bridge stp llc bnep snd_hda_codec_hdmi ext4 jbd2 arc4 snd_hda_codec_realtek snd_hda_codec_generic iwlmvm mac80211 fscrypto intel_rapl mbcache x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf joydev serio_raw iwlwifi cfg80211 rtsx_pci_ms memstick option usb_wwan usbserial btusb btrtl cdc_ether btbcm usbnet btintel mii bluetooth sg crc16 snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_sst_match [ 330.453921] snd_soc_core snd_compress snd_pcm_dmaengine snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm thinkpad_acpi nvram rfkill battery ac snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd evdev tpm_tis tpm_tis_core tpm soundcore mei_me mei shpchp intel_pch_thermal parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq algif_skcipher af_alg dm_crypt dm_mod sd_mod rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd i915 psmouse xhci_pci rtsx_pci xhci_hcd mfd_core ahci i2c_algo_bit usbcore libahci drm_kms_helper e1000e syscopyarea libata usb_common sysfillrect sysimgblt fb_sys_fops ptp pps_core drm scsi_mod thermal wmi video fjes button [ 330.454049] CPU: 0 PID: 5134 Comm: Xorg Tainted: GW OE 4.8.0-040800rc5-generic #201609041832 [ 330.454052] Hardware name: LENOVO 20F6007RGE/20F6007RGE, BIOS R02ET48W (1.21 ) 06/01/2016 [ 330.454057] 0286 0d9272e2 b2541064 9487a2e239c8 [ 330.454068] b227f6ee 9487c7f3 9487a2e23a20 [ 330.454076] 9487c85a1600 9487c7f303d8 9487c7f3 [ 330.454085] Call Trace: [ 330.454099] [] ? dump_stack+0x5c/0x78 [ 330.454108] [] ? __warn+0xbe/0xe0 [ 330.454117] [] ? warn_slowpath_fmt+0x5f/0x80 [ 330.454155] [] ? drm_vblank_get+0x76/0xc0 [drm] [ 330.454192] [] ? drm_wait_one_vblank+0x16b/0x1b0 [drm] [ 330.454286] [] ? chv_write32+0x3c0/0x3c0 [i915] [ 330.454344] [] ? skl_wm_flush_pipe+0xcd/0x100 [i915] [ 330.454400] [] ? skl_update_wm+0x42b/0x6c0 [i915] [ 330.454493] [] ? haswell_crtc_enable+0x798/0x860 [i915] [ 330.454584] [] ? intel_atomic_commit_tail+0x84f/0x10a0 [i915] [ 330.454671] [] ? intel_prepare_plane_fb+0x100/0x2b0 [i915] [ 330.454698] [] ? drm_atomic_helper_setup_commit+0x252/0x320 [drm_kms_helper] [ 330.454784] [] ? intel_atomic_commit+0x442/0x560 [i915] [ 330.454843] [] ? drm_atomic_set_crtc_for_connector+0x92/0xf0 [drm] [ 330.454870] [] ? drm_atomic_helper_set_config+0x79/0xb0 [drm_kms_helper] [ 330.454919] [] ? drm_mode_set_config_internal+0x61/0x110 [drm] [ 330.454969] [] ? drm_mode_setcrtc+0x42b/0x560 [drm] [ 330.455004] [] ? drm_ioctl+0x2ab/0x460 [drm] [ 330.455051] [] ? drm_mode_setplane+0x1c0/0x1c0 [drm] [ 330.455059] [] ? do_vfs_ioctl+0x9f/0x640 [ 330.455069] [] ? recalc_sigpending+0x17/0x50 [ 330.455078] [] ? __set_task_blocked+0x3d/0x90 [
[Kernel-packages] [Bug 1567417] Re: WARN_ON(!wm_changed) skl_update_other_pipe_wm+0x16c/0x180 [i915_bpo]
You can try the mainline 4.8-rc builds here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc4/ -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1567417 Title: WARN_ON(!wm_changed) skl_update_other_pipe_wm+0x16c/0x180 [i915_bpo] Status in linux package in Ubuntu: Confirmed Bug description: Hi, I'm using a new Skylake Thinkpad T460s with and external monitor connected via Displayport and Ubuntu 16.04 and the latest kernel as of today: Linux test 4.4.0-17-generic #33-Ubuntu SMP Tue Mar 29 17:17:28 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux X will from time to time lock up when the computer is left idle for a long time and both displays (laptop and external) go to sleep and then woken up. Apr 7 08:00:49 test kernel: [9.950929] [ cut here ] Apr 7 08:00:49 test kernel: [9.950950] WARNING: CPU: 0 PID: 214 at /build/linux-YiIlnA/linux-4.4.0/ubuntu/i915/intel_pm.c:3572 skl_update_other_pipe_wm+0x16c/0x180 [i915_bpo]() Apr 7 08:00:49 test kernel: [9.950951] WARN_ON(!wm_changed) Apr 7 08:00:49 test kernel: [9.950972] Modules linked in: btusb btrtl btbcm btintel bluetooth binfmt_misc nls_iso8859_1 arc4 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine dw_dmac_core snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm thinkpad_acpi intel_rapl x86_pkg_temp_thermal nvram intel_powerclamp snd_seq_midi coretemp snd_seq_midi_event snd_rawmidi iwlmvm snd_seq joydev snd_seq_device input_leds mac80211 snd_timer serio_raw snd rtsx_pci_ms memstick soundcore iwlwifi cfg80211 mei_me mei tpm_crb mac_hid shpchp kvm_intel kvm irqbypass parport_pc ppdev lp parport autofs4 drbg ansi_cprng algif_skcipher af_alg hid_microsoft dm_crypt hid_generic usbhid hid rtsx_pci_sdmmc crct10dif_pclmul crc32_pclmul i915_bpo aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd intel_ips i2c_algo_bit drm_kms_helper e1000e syscop yarea sysfillrect psmouse sysimgblt ptp fb_sys_fops pps_core drm nvme rtsx_pci wmi video fjes Apr 7 08:00:49 test kernel: [9.950980] CPU: 0 PID: 214 Comm: plymouthd Not tainted 4.4.0-17-generic #33-Ubuntu Apr 7 08:00:49 test kernel: [9.950981] Hardware name: LENOVO 20F9CTO1WW/20F9CTO1WW, BIOS N1CET40W (1.08 ) 03/09/2016 Apr 7 08:00:49 test kernel: [9.950982] 0286 39cb6999 880502bc3618 813e8123 Apr 7 08:00:49 test kernel: [9.950983] 880502bc3660 c0343c70 880502bc3650 8107fe12 Apr 7 08:00:49 test kernel: [9.950984] 880502da8000 880501f79d9c 880502dab000 880508186b78 Apr 7 08:00:49 test kernel: [9.950984] Call Trace: Apr 7 08:00:49 test kernel: [9.950988] [] dump_stack+0x63/0x90 Apr 7 08:00:49 test kernel: [9.950990] [] warn_slowpath_common+0x82/0xc0 Apr 7 08:00:49 test kernel: [9.950991] [] warn_slowpath_fmt+0x5c/0x80 Apr 7 08:00:49 test kernel: [9.951002] [] skl_update_other_pipe_wm+0x16c/0x180 [i915_bpo] Apr 7 08:00:49 test kernel: [9.951010] [] skl_update_wm+0x186/0x5f0 [i915_bpo] Apr 7 08:00:49 test kernel: [9.951023] [] ? intel_ddi_enable_transcoder_func+0x17f/0x260 [i915_bpo] Apr 7 08:00:49 test kernel: [9.951034] [] intel_update_watermarks+0x1e/0x30 [i915_bpo] Apr 7 08:00:49 test kernel: [9.951048] [] haswell_crtc_enable+0x321/0x8c0 [i915_bpo] Apr 7 08:00:49 test kernel: [9.951061] [] ? intel_finish_crtc_commit+0xe/0x10 [i915_bpo] Apr 7 08:00:49 test kernel: [9.951072] [] ? drm_atomic_helper_commit_planes_on_crtc+0x154/0x270 [drm_kms_helper] Apr 7 08:00:49 test kernel: [9.951085] [] intel_atomic_commit+0x5dd/0xdb0 [i915_bpo] Apr 7 08:00:49 test kernel: [9.951101] [] ? drm_atomic_check_only+0x18e/0x590 [drm] Apr 7 08:00:49 test kernel: [9.951109] [] drm_atomic_commit+0x37/0x60 [drm] Apr 7 08:00:49 test kernel: [9.951113] [] restore_fbdev_mode+0x22f/0x260 [drm_kms_helper] Apr 7 08:00:49 test kernel: [9.951121] [] ? drm_modeset_lock_all_ctx+0x9a/0xb0 [drm] Apr 7 08:00:49 test kernel: [9.951125] [] drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper] Apr 7 08:00:49 test kernel: [9.951128] [] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] Apr 7 08:00:49 test kernel: [9.951131] [] drm_fb_helper_hotplug_event+0xd2/0x120 [drm_kms_helper] Apr 7 08:00:49 test kernel: [9.951134] [] drm_fb_helper_restore_fbdev_mode_unlocked+0x56/0x80 [drm_kms_helper] Apr 7 08:00:49 test kernel: [9.951136] [] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] Apr 7 08:00:49 test kernel: [9.951150] [] intel_fbdev_set_par+0x1a/0x60 [i915_bpo] Apr 7 08:00:49 test
[Kernel-packages] [Bug 1597267] Re: ThinkPad X260 connecting external DisplayPort hangs system
I found a couple existing bugs in the freedesktop.org tracker that might be related, all marked as fixed in recent nightlies: https://bugs.freedesktop.org/show_bug.cgi?id=96714 https://bugs.freedesktop.org/show_bug.cgi?id=95498 https://bugs.freedesktop.org/show_bug.cgi?id=94822 https://bugs.freedesktop.org/show_bug.cgi?id=89055 There's also some indications this may be related to 4k monitors as well; my original crash with the ThinkPad Dock and Ubuntu's 4.4.0 kernel was a FullHD monitor, later tests with 4.6 and 4.7 were all with a 4k DP 1.2 monitor. I'll have to test again with the dock and a non-4k monitor once I get my hands on it. ** Bug watch added: freedesktop.org Bugzilla #96714 https://bugs.freedesktop.org/show_bug.cgi?id=96714 ** Bug watch added: freedesktop.org Bugzilla #95498 https://bugs.freedesktop.org/show_bug.cgi?id=95498 ** Bug watch added: freedesktop.org Bugzilla #94822 https://bugs.freedesktop.org/show_bug.cgi?id=94822 ** Bug watch added: freedesktop.org Bugzilla #89055 https://bugs.freedesktop.org/show_bug.cgi?id=89055 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597267 Title: ThinkPad X260 connecting external DisplayPort hangs system Status in linux package in Ubuntu: Triaged Bug description: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. I have attached a journalctl log from running 4.7.0-040700rc5-generic and connecting the DP monitor while in a text console, before switching to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The first warnings come immediately when connecting, and others when switching consoles and logging in. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-28-generic 4.4.0-28.47 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Uname: Linux 4.4.0-28-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: terom 1903 F pulseaudio CurrentDesktop: Unity Date: Wed Jun 29 13:03:18 2016 InstallationDate: Installed on 2016-06-26 (2 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) MachineType: LENOVO 20F6007RGE ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-28-generic root=UUID=6636a3bb-262e-4ab2-ae81-d9388e3f7684 ro rootflags=subvol=@ quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-28-generic N/A linux-backports-modules-4.4.0-28-generic N/A linux-firmware1.157.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/01/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R02ET48W (1.21 ) dmi.board.asset.tag: Not Available dmi.board.name: 20F6007RGE dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR02ET48W(1.21):bd06/01/2016:svnLENOVO:pn20F6007RGE:pvrThinkPadX260:rvnLENOVO:rn20F6007RGE:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20F6007RGE dmi.product.version: ThinkPad X260 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597267/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1597267] Re: ThinkPad X260 connecting external DisplayPort hangs system
I can confirm that linux-image 4.7.0-994-generic_4.7.0-994.201607052202 from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel- nightly/2016-07-06/ behaves much better. DP hotplug/unplug behaves correctly across text console, VT switch to lightdm and login into Unity. There's still some WARNs in dmesg (attached) when connecting the external DP monitor, but nothing crashes, and my 4k desktop appears to function correctly: [drm:skl_set_cdclk [i915]] *ERROR* failed to inform PCU about cdclk change WARNING: CPU: 1 PID: 929 at /home/kernel/COD/linux/drivers/gpu/drm/drm_irq.c:1218 drm_wait_one_vblank+0x16f/0x1b0 [drm] vblank not available on crtc 0, ret=-22 [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Confirmed to still crash with http://kernel.ubuntu.com/~kernel- ppa/mainline/v4.7-rc6-yakkety/ ** Attachment added: "Linux version 4.7.0-994-generic (kernel@tangerine) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1) ) #201607052202 SMP Wed Jul 6 02:04:37 UTC 2016" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597267/+attachment/4696230/+files/ubuntu1604-linux47drm994-dp.dmesg -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597267 Title: ThinkPad X260 connecting external DisplayPort hangs system Status in linux package in Ubuntu: Incomplete Bug description: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. I have attached a journalctl log from running 4.7.0-040700rc5-generic and connecting the DP monitor while in a text console, before switching to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The first warnings come immediately when connecting, and others when switching consoles and logging in. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-28-generic 4.4.0-28.47 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Uname: Linux 4.4.0-28-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: terom 1903 F pulseaudio CurrentDesktop: Unity Date: Wed Jun 29 13:03:18 2016 InstallationDate: Installed on 2016-06-26 (2 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) MachineType: LENOVO 20F6007RGE ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-28-generic root=UUID=6636a3bb-262e-4ab2-ae81-d9388e3f7684 ro rootflags=subvol=@ quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-28-generic N/A linux-backports-modules-4.4.0-28-generic N/A linux-firmware1.157.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/01/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R02ET48W (1.21 ) dmi.board.asset.tag: Not Available dmi.board.name: 20F6007RGE dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR02ET48W(1.21):bd06/01/2016:svnLENOVO:pn20F6007RGE:pvrThinkPadX260:rvnLENOVO:rn20F6007RGE:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20F6007RGE dmi.product.version: ThinkPad X260 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597267/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1597267] Re: ThinkPad X260 connecting external DisplayPort hangs system
And no upgrades or prior working versions, this is a fresh Ubuntu 16.04 install on a newly purchased X260 laptop. ** Description changed: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. - I have attached a journalctl log from running 4.4.0-28-generic and - connecting the DP monitor while in a text console, before switching to - the graphical console and logging in. The system hangs after a series + I have attached a journalctl log from running 4.7.0-040700rc5-generic + and connecting the DP monitor while in a text console, before switching + to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] - 2016-06-29T12:54:52+0300 tehobari kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] + kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The first warnings come immediately when connecting, and others when switching consoles and logging in. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-28-generic 4.4.0-28.47 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Uname: Linux 4.4.0-28-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: terom 1903 F pulseaudio CurrentDesktop: Unity Date: Wed Jun 29 13:03:18 2016 InstallationDate: Installed on 2016-06-26 (2 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) MachineType: LENOVO 20F6007RGE ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-28-generic root=UUID=6636a3bb-262e-4ab2-ae81-d9388e3f7684 ro rootflags=subvol=@ quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-28-generic N/A linux-backports-modules-4.4.0-28-generic N/A linux-firmware1.157.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/01/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R02ET48W (1.21 ) dmi.board.asset.tag: Not Available dmi.board.name: 20F6007RGE dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR02ET48W(1.21):bd06/01/2016:svnLENOVO:pn20F6007RGE:pvrThinkPadX260:rvnLENOVO:rn20F6007RGE:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20F6007RGE dmi.product.version: ThinkPad X260 dmi.sys.vendor: LENOVO -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597267 Title: ThinkPad X260 connecting external DisplayPort hangs system Status in linux package in Ubuntu: Confirmed Bug description: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. I have attached a journalctl log from running 4.7.0-040700rc5-generic and connecting the DP monitor while in a text console, before switching to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] kernel: WARNING: CPU: 3 PID: 4418
[Kernel-packages] [Bug 1597267] Re: ThinkPad X260 connecting external DisplayPort hangs system
As per the description, I have tested this with 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. In fact, the journal output I attached was from the 4.7 kernel, I renamed the attachment accordingly: ubuntu16-04_linux4.7.0-040700rc5 -generic_dp-hang.log ** Tags added: kernel-bug-exists-upstream ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597267 Title: ThinkPad X260 connecting external DisplayPort hangs system Status in linux package in Ubuntu: Confirmed Bug description: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. I have attached a journalctl log from running 4.7.0-040700rc5-generic and connecting the DP monitor while in a text console, before switching to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The first warnings come immediately when connecting, and others when switching consoles and logging in. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-28-generic 4.4.0-28.47 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Uname: Linux 4.4.0-28-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: terom 1903 F pulseaudio CurrentDesktop: Unity Date: Wed Jun 29 13:03:18 2016 InstallationDate: Installed on 2016-06-26 (2 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) MachineType: LENOVO 20F6007RGE ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-28-generic root=UUID=6636a3bb-262e-4ab2-ae81-d9388e3f7684 ro rootflags=subvol=@ quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-28-generic N/A linux-backports-modules-4.4.0-28-generic N/A linux-firmware1.157.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/01/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R02ET48W (1.21 ) dmi.board.asset.tag: Not Available dmi.board.name: 20F6007RGE dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR02ET48W(1.21):bd06/01/2016:svnLENOVO:pn20F6007RGE:pvrThinkPadX260:rvnLENOVO:rn20F6007RGE:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20F6007RGE dmi.product.version: ThinkPad X260 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597267/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1597267] Re: ThinkPad X260 connecting external DisplayPort hangs system
Note that compared to #1559308 , connecting the same monitor via the HDMI port on the laptop running 4.4.0-28-generic does seem to work fine: There's still some stuff in dmesg when using HDMI as well: snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128 snd_hda_codec_hdmi hdaudioC0D2: HDMI: invalid ELD data byte 0 [ cut here ] WARNING: CPU: 1 PID: 1080 at /build/linux-BvkamA/linux-4.4.0/ubuntu/i915/intel_pm.c:3586 skl_update_other_pipe_wm+0x16c/0x180 [i915_bpo]() WARN_ON(!wm_changed) Modules linked in: ctr ccm rfcomm bnep arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core intel_rapl x86_pkg_temp_thermal snd_soc_sst_ipc intel_powerclamp coretemp snd_soc_sst_dsp snd_hda_codec_hdmi snd_soc_core kvm_intel snd_compress ac97_bus snd_pcm_dmaengine snd_hda_codec_realtek kvm dw_dmac_core snd_hda_codec_generic input_leds snd_hda_intel irqbypass iwlmvm uvcvideo snd_hda_codec videobuf2_vmalloc videobuf2_memops mac80211 snd_hda_core videobuf2_v4l2 videobuf2_core v4l2_common snd_hwdep joydev serio_raw snd_pcm videodev btusb media btrtl thinkpad_acpi cdc_ether btbcm option iwlwifi nvram usbnet usb_wwan usbserial btintel mii rtsx_pci_ms snd_seq_midi bluetooth memstick snd_seq_midi_event cfg80211 snd_rawmidi mei_me mei snd_seq shpchp snd_seq_device snd_timer snd soundcore mac_hid parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq drbg ansi_cprng algif_skcipher af_alg dm_crypt rtsx_pci_sdmmc i915_bpo crct10dif_pclmul crc32_pclmul aesni_intel intel_ips i2c_algo_bit aes_x86_64 drm_kms_helper lrw gf128mul glue_helper ablk_helper syscopyarea cryptd sysfillrect sysimgblt fb_sys_fops e1000e ahci drm psmouse ptp rtsx_pci pps_core libahci wmi video fjes CPU: 1 PID: 1080 Comm: Xorg Not tainted 4.4.0-28-generic #47-Ubuntu Hardware name: LENOVO 20F6007RGE/20F6007RGE, BIOS R02ET48W (1.21 ) 06/01/2016 0286 9c6cf672 88040dfa39a8 813eb1a3 88040dfa39f0 c0373c98 88040dfa39e0 81081102 88040fc7c000 880409629d9c 88040fc7b000 880409020b78 Call Trace: [] dump_stack+0x63/0x90 [] warn_slowpath_common+0x82/0xc0 [] warn_slowpath_fmt+0x5c/0x80 [] skl_update_other_pipe_wm+0x16c/0x180 [i915_bpo] [] skl_update_wm+0x186/0x5f0 [i915_bpo] [] ? intel_display_power_put+0xd0/0x130 [i915_bpo] [] intel_update_watermarks+0x1e/0x30 [i915_bpo] [] intel_atomic_commit+0x485/0xdc0 [i915_bpo] [] ? drm_atomic_check_only+0x18e/0x590 [drm] [] drm_atomic_commit+0x37/0x60 [drm] [] drm_atomic_helper_set_config+0x76/0xb0 [drm_kms_helper] [] ? drm_modeset_lock_all_ctx+0x9a/0xb0 [drm] [] drm_mode_set_config_internal+0x62/0x100 [drm] [] drm_mode_setcrtc+0x3d2/0x4f0 [drm] [] drm_ioctl+0x152/0x540 [drm] [] ? drm_mode_setplane+0x1b0/0x1b0 [drm] [] do_vfs_ioctl+0x29f/0x490 [] ? __sys_recvmsg+0x80/0x90 [] SyS_ioctl+0x79/0x90 [] entry_SYSCALL_64_fastpath+0x16/0x71 ---[ end trace a13f8ffdea74aa69 ]--- -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597267 Title: ThinkPad X260 connecting external DisplayPort hangs system Status in linux package in Ubuntu: Confirmed Bug description: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. I have attached a journalctl log from running 4.4.0-28-generic and connecting the DP monitor while in a text console, before switching to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] 2016-06-29T12:54:52+0300 tehobari kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The first warnings come immediately when connecting, and others when switching consoles and logging in. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-28-generic 4.4.0-28.47 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Uname: Linux 4.4.0-28-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0:
[Kernel-packages] [Bug 1597267] [NEW] ThinkPad X260 connecting external DisplayPort hangs system
Public bug reported: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. I have attached a journalctl log from running 4.4.0-28-generic and connecting the DP monitor while in a text console, before switching to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] 2016-06-29T12:54:52+0300 tehobari kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The first warnings come immediately when connecting, and others when switching consoles and logging in. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-28-generic 4.4.0-28.47 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Uname: Linux 4.4.0-28-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: terom 1903 F pulseaudio CurrentDesktop: Unity Date: Wed Jun 29 13:03:18 2016 InstallationDate: Installed on 2016-06-26 (2 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) MachineType: LENOVO 20F6007RGE ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-28-generic root=UUID=6636a3bb-262e-4ab2-ae81-d9388e3f7684 ro rootflags=subvol=@ quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-28-generic N/A linux-backports-modules-4.4.0-28-generic N/A linux-firmware1.157.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/01/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R02ET48W (1.21 ) dmi.board.asset.tag: Not Available dmi.board.name: 20F6007RGE dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR02ET48W(1.21):bd06/01/2016:svnLENOVO:pn20F6007RGE:pvrThinkPadX260:rvnLENOVO:rn20F6007RGE:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20F6007RGE dmi.product.version: ThinkPad X260 dmi.sys.vendor: LENOVO ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: amd64 apport-bug xenial ** Attachment added: "ubuntu1604-linux44-dp1.log" https://bugs.launchpad.net/bugs/1597267/+attachment/4692147/+files/ubuntu1604-linux44-dp1.log -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597267 Title: ThinkPad X260 connecting external DisplayPort hangs system Status in linux package in Ubuntu: Confirmed Bug description: Running Ubuntu 16.04 on a Lenovo ThinkPad X260 with Intel Skylake HD Graphics 520, connecting an external monitor to the DisplayPort connector causes the system to quickly hang. The system stops responding to network pings, cannot switch consoles, and needs a hard reboot. The external monitor does work when using a text console, and does not always hang in the LightDM login screen, but starting up a desktop session will always hang. This originally happened using a ThinkPad dock, and I tested it further using an external DP monitor. This happens on 4.4.0-28-generic as well as mainline 4.6.3-040603-generic and 4.7.0-040700rc5-generic; they all hang in a similar fashion. I have attached a journalctl log from running 4.4.0-28-generic and connecting the DP monitor while in a text console, before switching to the graphical console and logging in. The system hangs after a series of: kernel: WARNING: CPU: 3 PID: 2319 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x15d/0x170 [i915] 2016-06-29T12:54:52+0300 tehobari kernel: WARNING: CPU: 3 PID: 4418 at /home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:13957 skl_max_scale.part.108+0x69/0x70 [i915] kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The first warnings come immediately when connecting, and others when switching consoles and logging in. ProblemType: Bug
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
Yes, I can confirm that the trusty-proposed 3.13.0-38 kernel resolves
this issue. The dnsmasq-tftp transfer succeeds in my test environment
without any of the symptoms that were present with the trusty-
updates/security kernels between -30 and -37, nor do I notice any
regressions in my (IPv4) ipvs ruleset.
$ uname -a
Linux catcp2-test 3.13.0-38-generic #65-Ubuntu SMP Thu Oct 9 11:36:50 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
$ apt-cache policy linux-image-generic
linux-image-generic:
Installed: 3.13.0.38.45
Candidate: 3.13.0.38.45
Version table:
*** 3.13.0.38.45 0
50 http://fi.archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64
Packages
100 /var/lib/dpkg/status
...
** Tags removed: verification-needed-trusty
** Tags added: verification-done-trusty
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Fix Released
Status in “linux” source package in Trusty:
Fix Committed
Status in “linux” source package in Utopic:
Fix Released
Bug description:
SRU Justificaton:
[Impact]
Users of ipvs may encounter dropped packets and message such as:
[70325.516724] IPv6 header not found
[Fix]
Commit eb90b0c734ad793d5f5bf230a9e9a4dcc48df8aa.
[Regression Potential]
This changes NFPROTO_IPV4 to NFPROTO_IPV6 as we'd expect this nf_hook_ops
struct to be in the code.
--
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
ACK
3.13.0-35-generic #62~lp1349768v5v201408250842 appears to resolve the
issue completely on my actual test setup as well. No TFTP stalls,
dnsmasq EPERM errors or dmesg errors, and ftrace doesn't show any calls
to ipv6_find_hdr.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
In Progress
Status in “linux” source package in Trusty:
In Progress
Status in “linux” source package in Utopic:
In Progress
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse:
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
NAK
Unfortunately no, the 3.13.0-35-generic #62~lp1349768v4v201408220857
from above continues to exhibit the same issues with my actual test
setup. Same thing with the ./lp1349768.sh testcase.
The 0041-ipvs-fix-ipv4-issues-in-ip_vs_out.patch in the lp1349768v4
build is a different patch, though?
The resulting ftrace that correlates with dnsmasq sendto() getting stuck
is still the same:
dnsmasq-1447 [000] 1272.430975: ipv6_find_hdr
-ip_vs_out_icmp_v6.isra.21
dnsmasq-1447 [000] 1272.430983: stack trace
= ip_vs_out.part.22
= ip_vs_local_reply6
= nf_iterate
= nf_hook_slow
= __ip_local_out
= ip_local_out
= ip_send_skb
= udp_send_skb
= udp_sendmsg
= inet_sendmsg
= sock_sendmsg
= SYSC_sendto
= SyS_sendto
= tracesys
Is there something I can use to confirm that the booted kernel image
actually has the correct nf_hook_ops.pf set? The fix seems pretty
obvious, so I was expecting it to work...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
In Progress
Status in “linux” source package in Trusty:
In Progress
Status in “linux” source package in Utopic:
In Progress
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs),
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
NAK
Linux 3.13.0-35-generic #62~lp1349768v3v201408191448 still exhibits the
same symptoms (stalled dnsmasq-tftp transfer and IPv6 header not found
messages). Unloading the ip_vs module clears the issue.
I'll attempt to work out a minimal reproducer.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Status in “linux” source package in Trusty:
In Progress
Status in “linux” source package in Utopic:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
Attached is a small script to setup dnsmasq-tftp and ipvs to reproduce
the dnsmasq-tftp stall. The strace at the end should start showing
sendto() = EPERM errors after running the curl tftp://.../ command given
as an example from a remote host.
The exact contents of the ipvs rules don't seem to matter.
The dnsmasq-tftp stall issue appears to happen with all the ubuntu-
installer/amd64/linux versions that I've tried, with the exact block
within the TFTP stream where it stalls changing betwen different
versions but remaining consistent between runs.
With the current netboot.tar.gz it appers to happen at block 600:
d4fc2ba26cad96f4360cb36f04c26b2f50dceee9413c206431148b87e4958909
/srv/tftp/ubuntu-installer/amd64/linux
With the original ubuntu-installer netboot.tar.gz version (from sometime
early June) I've been using it happens at block 311:
bdebc6c7bbd873bf5ad2480d90c2523da49cca8da5a0f4cb40adb7d1aeafb821
/srv/tftp/lp1349768/linux
Curiously, however, testing this setup on the 3.13.0-34-generic kernel
the dmesg error (IPv6 header not found) does NOT show up... may be
some other facters at play as well there?
** Attachment added: minimal testcase for LP#1349768 on Ubuntu 14.04
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768/+attachment/4182427/+files/lp1349768.sh
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Status in “linux” source package in Trusty:
In Progress
Status in “linux” source package in Utopic:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
ACK
I can confirm that this issue is no longer present with the Linux
3.13.0-33-generic #58~lp1349768v2v201407300928 kernel as installed from
above. Rebooting into the given kernel results in dnsmasq-tftp transfers
working fine, and no related dmesg errors occur.
Apologies for the delay. I was away, and had to reproduce this in a test
environment first.
Do tell me if you would still like a minimal reproducer to track down
the issue further, and I can work on getting something like that up.
AFAICT it would involve dnsmasq with enable-tftp/tftp-root and a
libvirt-qemu domain with boot dev='network' , requesting the ubuntu-
installer amd64 linux kernel over TFTP, with the ip_vs modules loaded
and a trivial ipvs ruleset applied on the server.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Status in “linux” source package in Trusty:
In Progress
Status in “linux” source package in Utopic:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again,
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
The utopic kernel appears to be affected as well. Booting the same
Ubuntu 14.04 machine into the Linux 3.16.0-6-generic #11-Ubuntu kernel
installed from
https://launchpad.net/ubuntu/+source/linux/3.16.0-6.11/+build/6217368
gives identical symptoms, i.e. dnsmasq-tftp stalls, dmesg reports IPv6
header not found, stracing dnsmasq shows sendto() giving EPERM, and
unloading ip_vs allows the stalled tftp transfer to continue.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Status in “linux” source package in Trusty:
In Progress
Status in “linux” source package in Utopic:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
NACK
The same faulty behaviour persists with linux-
image-3.13.0-33-generic=3.13.0-33.58~lp1349768v201407290941 (uname
3.13.0-33-generic #58~lp1349768v201407290941).
I do not notice any difference; identical symptoms. `rmmod ip_vs_rr
ip_vs` continues to immediately resolve the fault.
Note that my configuration also includes openvswitch. The tftp stall
continues to happen when flushing the ipvs ruleset, only unloading the
ip_vs module resolves it. However, only re-loading the ip_vs_rr module
does not trigger the stall, but loading the ipvs ruleset does. My IPVS
ruleset consists of only four TCP Masq forwards.
Using ktrace to try and get a rough stack trace, I was able to observe
the following sequences:
dnsmasq-5012 [001] 2060.572946: ipv6_find_hdr
-ip_vs_out.part.23
dnsmasq-5012 [001] 2060.572955: stack trace
= ip_vs_local_reply6
= nf_iterate
= nf_hook_slow
= __ip_local_out
= ip_local_out
= ip_send_skb
= udp_send_skb
= udp_sendmsg
= inet_sendmsg
= sock_sendmsg
= SYSC_sendto
= SyS_sendto
= tracesys
dnsmasq-5012 [001] 2060.572956: ipv6_find_hdr
-ip_vs_out_icmp_v6.isra.22
dnsmasq-5012 [001] 2060.572963: stack trace
= ip_vs_out.part.23
= ip_vs_local_reply6
= nf_iterate
= nf_hook_slow
= __ip_local_out
= ip_local_out
= ip_send_skb
= udp_send_skb
= udp_sendmsg
= inet_sendmsg
= sock_sendmsg
= SYSC_sendto
= SyS_sendto
= tracesys
with the first sequence being repeated for every packet (?) and the
second, slightly different, sequence corresponding per the timestamp to
the dmesg:
[ 2060.572964] IPv6 header not found
This is with a my full iptables rulset loaded, but my OUTPUT DROP rules
counters do not indicate any matches. The ftrace output seems to be
identical with the iptables ruleset flushed.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Fix Released
Status in “linux” source package in Trusty:
In Progress
Status in “linux” source package in Utopic:
Fix Released
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17,
[Kernel-packages] [Bug 1349768] [NEW] kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
Public bug reported:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the Loading
/linux TFTP transfer, with the transfer stalling roughly ~1000
blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself - the
stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does
NOT seem to happen with 3.13.0-29 which I was using up until now.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: biosdevname (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
New
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
apport information
** Tags added: apport-collected trusty
** Description changed:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the Loading
/linux TFTP transfer, with the transfer stalling roughly ~1000
blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself - the
stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
- This seems to happen reproducibly on boot with -32 and -30. This does
- NOT seem to happen with 3.13.0-29 which I was using up until now.
+ This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
+ ---
+ AlsaDevices:
+ total 0
+ crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
+ crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
+ AplayDevices: Error: [Errno 2] No such file or directory
+ ApportVersion: 2.14.1-0ubuntu3.2
+ Architecture: amd64
+ ArecordDevices: Error: [Errno 2] No such file or directory
+ AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
+ CRDA: Error: [Errno 2] No such file or directory
+ DistroRelease: Ubuntu 14.04
+ HibernationDevice: RESUME=/dev/mapper/catcp2-swap
+ InstallationDate: Installed on 2014-06-03 (56 days ago)
+ InstallationMedia: Ubuntu-Server 14.04 LTS Trusty Tahr - Release amd64
(20140416.2)
+ MachineType: Dell Inc. PowerEdge R410
+ Package:
[Kernel-packages] [Bug 1349768] ProcCpuinfo.txt
apport information
** Attachment added: ProcCpuinfo.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165030/+files/ProcCpuinfo.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice:
[Kernel-packages] [Bug 1349768] UdevDb.txt
apport information
** Attachment added: UdevDb.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165033/+files/UdevDb.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice:
[Kernel-packages] [Bug 1349768] Lspci.txt
apport information
** Attachment added: Lspci.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165028/+files/Lspci.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice:
[Kernel-packages] [Bug 1349768] WifiSyslog.txt
apport information
** Attachment added: WifiSyslog.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165035/+files/WifiSyslog.txt
** Changed in: linux (Ubuntu)
Status: Incomplete = Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
[Kernel-packages] [Bug 1349768] ProcModules.txt
apport information
** Attachment added: ProcModules.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165032/+files/ProcModules.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice:
[Kernel-packages] [Bug 1349768] Dependencies.txt
apport information
** Attachment added: Dependencies.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165026/+files/Dependencies.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice:
[Kernel-packages] [Bug 1349768] UdevLog.txt
apport information
** Attachment added: UdevLog.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165034/+files/UdevLog.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice:
[Kernel-packages] [Bug 1349768] IwConfig.txt
apport information
** Attachment added: IwConfig.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165027/+files/IwConfig.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice:
[Kernel-packages] [Bug 1349768] Re: kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket sendto() EPERM errors
Reported apport-collect information against package linux-
image-3.13.0-32-generic, reproducing the dnsmasq-tftp issue with a
remote client pxebooting and stalling.
The CurrentDmesg contains the symptom message at 1214.740931
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such
[Kernel-packages] [Bug 1349768] ProcInterrupts.txt
apport information
** Attachment added: ProcInterrupts.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165031/+files/ProcInterrupts.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice:
[Kernel-packages] [Bug 1349768] Lsusb.txt
apport information
** Attachment added: Lsusb.txt
https://bugs.launchpad.net/bugs/1349768/+attachment/4165029/+files/Lsusb.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1349768
Title:
kernel 3.13.0-32 ipvs IPv6 header not found related to UDP socket
sendto() EPERM errors
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
I have an Ubuntu 14.04 host that I am using as both a keepalived/ipvs
loadbalancer and dnsmasq server for pxebooting servers.
After updating linux-image 3.13.0-29.53 - 3.13.0-32.57 I noticed that
dnsmasq-tftp stopped working. pxeboot clients would hang on the
Loading /linux TFTP transfer, with the transfer stalling roughly
~1000 blocks into the transfer:
10:30:51.011728 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.011924 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
10:30:51.012012 IP 10.1.1.2.43540 10.1.12.1.49165: UDP, length 1412
10:30:51.012183 IP 10.1.12.1.49165 10.1.1.2.43540: UDP, length 4
stracing dnsmasq I noticed something very odd: sendto() on the
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) would suddenly start
persistently returning EPERM in mid-transfer, even when dnsmasq
continued to periodically retry:
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249834})
recvfrom(17, \0\4\3\352, 4096, 0, NULL, NULL) = 4
lseek(16, 1410816, SEEK_SET) = 1410816
read(16,
\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32\221X+\v...,
1408) = 1408
sendto(17,
\0\3\3\353\25\306\345f\2{\r\4)W\276\32\336q\252_\230q\213\341U\354\25\374k7\243\32...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = 1412
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 1 (in [17],
left {0, 249839})
recvfrom(17, \0\4\3\353, 4096, 0, NULL, NULL) = 4
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
select(18, [4 5 6 7 8 9 10 11 12 15 17], [], [], {0, 25}) = 0 (Timeout)
lseek(16, 1412224, SEEK_SET) = 1412224
read(16, *\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277\221\\\307\372...,
1408) = 1408
sendto(17, \0\3\3\354*\360
C\363l\320:\256~\307\236\26P\323\274%\260\362\341\232\r\243\370\224\277...,
1412, 0, {sa_family=AF_INET, sin_port=htons(49165),
sin_addr=inet_addr(10.1.11.3)}, 16) = -1 EPERM (Operation not permitted)
This was with all iptables rules unloaded (so no OUTPUT -j DENY) and
apparmor profiles torn down.
I also noticed the following dmesgs appearing at roughly similar times
to the tftp transfers getting stuck (although not coinciding exactly
with the stall):
[70325.516724] IPv6 header not found
The error pointed to ipvs (which I am using on the same host as an IPv4 NAT
loadbalancer):
http://archive.linuxvirtualserver.org/html/lvs-devel/2012-08/msg00018.html
http://comments.gmane.org/gmane.comp.linux.lvs.devel/3614
I then tore down the ipvs rules (service keepalived stop) and unloaded
the modules (rmmod ip_vs_rr ip_vs), and the issue resolved itself -
the stalled dnsmasq-tftp transfer resumed!
This seems to be reproducible, i.e. modprobing ip_vs and starting
keepalived will cause dnsmasq-tftp to stall again, and
stopping/unloading will resume.
This seems to happen reproducibly on boot with -32 and -30. This does NOT
seem to happen with 3.13.0-29 which I was using up until now.
---
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Jul 29 13:43 seq
crw-rw 1 root audio 116, 33 Jul 29 13:43 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 14.04
HibernationDevice:
[Kernel-packages] [Bug 1285727] [NEW] linux-image-3.11.0-17-generic omits iwlwifi-7260-7.ucode firmware
Public bug reported: The latest precise-updates linux-image seems to omit the required iwlwifi-7260-7.ucode firwmware 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83) $ dpkg -l linux-image-3.11* ii linux-image-3.11.0-14-generic 3.11.0-14.21~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP ii linux-image-3.11.0-15-generic 3.11.0-15.25~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP ii linux-image-3.11.0-17-generic 3.11.0-17.31~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP $ dpkg -S iwlwifi-7260 linux-image-3.11.0-15-generic: /lib/firmware/3.11.0-15-generic/iwlwifi-7260-7.ucode linux-image-3.11.0-14-generic: /lib/firmware/3.11.0-14-generic/iwlwifi-7260-7.ucode $ dmesg # failed iwlwifi on latest 3.11.0-17 (no iw phy present) [0.00] Linux version 3.11.0-17-generic (buildd@toyol) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #31~precise1-Ubuntu SMP Tue Feb 4 21:25:43 UTC 2014 (Ubuntu 3.11 .0-17.31~precise1-generic 3.11.10.3) ... [ 17.770121] iwlwifi :03:00.0: request for firmware file 'iwlwifi-7260-7.ucode' failed. [ 17.770127] iwlwifi :03:00.0: no suitable firmware found! $ dmesg # succesfful 3.11.0-15 boot (iw phy0 present) [0.00] Linux version 3.11.0-15-generic (buildd@allspice) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 (Ubuntu 3.11.0-15.25~precise1-generic 3.11.10) ... [ 49.046204] iwlwifi :03:00.0: loaded firmware version 22.0.7.0 op_mode iwlmvm [ 49.120558] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1285727 Title: linux-image-3.11.0-17-generic omits iwlwifi-7260-7.ucode firmware Status in “linux” package in Ubuntu: New Bug description: The latest precise-updates linux-image seems to omit the required iwlwifi-7260-7.ucode firwmware 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83) $ dpkg -l linux-image-3.11* ii linux-image-3.11.0-14-generic 3.11.0-14.21~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP ii linux-image-3.11.0-15-generic 3.11.0-15.25~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP ii linux-image-3.11.0-17-generic 3.11.0-17.31~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP $ dpkg -S iwlwifi-7260 linux-image-3.11.0-15-generic: /lib/firmware/3.11.0-15-generic/iwlwifi-7260-7.ucode linux-image-3.11.0-14-generic: /lib/firmware/3.11.0-14-generic/iwlwifi-7260-7.ucode $ dmesg # failed iwlwifi on latest 3.11.0-17 (no iw phy present) [0.00] Linux version 3.11.0-17-generic (buildd@toyol) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #31~precise1-Ubuntu SMP Tue Feb 4 21:25:43 UTC 2014 (Ubuntu 3.11 .0-17.31~precise1-generic 3.11.10.3) ... [ 17.770121] iwlwifi :03:00.0: request for firmware file 'iwlwifi-7260-7.ucode' failed. [ 17.770127] iwlwifi :03:00.0: no suitable firmware found! $ dmesg # succesfful 3.11.0-15 boot (iw phy0 present) [0.00] Linux version 3.11.0-15-generic (buildd@allspice) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 (Ubuntu 3.11.0-15.25~precise1-generic 3.11.10) ... [ 49.046204] iwlwifi :03:00.0: loaded firmware version 22.0.7.0 op_mode iwlmvm [ 49.120558] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1285727/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1285727] Re: linux-image-3.11.0-17-generic omits iwlwifi-7260-7.ucode firmware
*** This bug is a duplicate of bug 1281964 *** https://bugs.launchpad.net/bugs/1281964 Workaroud: Boot with Shift held down, and select older 3.11.0-15 linux version in grub. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1285727 Title: linux-image-3.11.0-17-generic omits iwlwifi-7260-7.ucode firmware Status in “linux” package in Ubuntu: New Bug description: The latest precise-updates linux-image seems to omit the required iwlwifi-7260-7.ucode firwmware 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83) $ dpkg -l linux-image-3.11* ii linux-image-3.11.0-14-generic 3.11.0-14.21~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP ii linux-image-3.11.0-15-generic 3.11.0-15.25~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP ii linux-image-3.11.0-17-generic 3.11.0-17.31~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP $ dpkg -S iwlwifi-7260 linux-image-3.11.0-15-generic: /lib/firmware/3.11.0-15-generic/iwlwifi-7260-7.ucode linux-image-3.11.0-14-generic: /lib/firmware/3.11.0-14-generic/iwlwifi-7260-7.ucode $ dmesg # failed iwlwifi on latest 3.11.0-17 (no iw phy present) [0.00] Linux version 3.11.0-17-generic (buildd@toyol) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #31~precise1-Ubuntu SMP Tue Feb 4 21:25:43 UTC 2014 (Ubuntu 3.11 .0-17.31~precise1-generic 3.11.10.3) ... [ 17.770121] iwlwifi :03:00.0: request for firmware file 'iwlwifi-7260-7.ucode' failed. [ 17.770127] iwlwifi :03:00.0: no suitable firmware found! $ dmesg # succesfful 3.11.0-15 boot (iw phy0 present) [0.00] Linux version 3.11.0-15-generic (buildd@allspice) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 (Ubuntu 3.11.0-15.25~precise1-generic 3.11.10) ... [ 49.046204] iwlwifi :03:00.0: loaded firmware version 22.0.7.0 op_mode iwlmvm [ 49.120558] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1285727/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1285727] Re: linux-image-3.11.0-17-generic omits iwlwifi-7260-7.ucode firmware
*** This bug is a duplicate of bug 1281964 *** https://bugs.launchpad.net/bugs/1281964 Confirm that updating to linux-firmware 1.79.10 from precise-updates resolves this, giving me a functional phy0 on 3.11.0-17-generic. $ apt-cache policy linux-firmware linux-firmware: Installed: 1.79.10 Candidate: 1.79.10 Version table: *** 1.79.10 0 500 http://fi.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages 100 /var/lib/dpkg/status 1.79 0 500 http://fi.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages $ dmesg | grep iw [ 21.900148] iwlwifi :03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 21.900534] iwlwifi :03:00.0: irq 62 for MSI/MSI-X [ 22.597407] iwlwifi :03:00.0: loaded firmware version 22.1.7.0 op_mode iwlmvm [ 23.421577] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 [ 23.421915] iwlwifi :03:00.0: L1 Enabled; Disabling L0S [ 23.422293] iwlwifi :03:00.0: L1 Enabled; Disabling L0S [ 23.733900] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' [ 26.266427] iwlwifi :03:00.0: L1 Enabled; Disabling L0S [ 26.266872] iwlwifi :03:00.0: L1 Enabled; Disabling L0S -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1285727 Title: linux-image-3.11.0-17-generic omits iwlwifi-7260-7.ucode firmware Status in “linux” package in Ubuntu: New Bug description: The latest precise-updates linux-image seems to omit the required iwlwifi-7260-7.ucode firwmware 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83) $ dpkg -l linux-image-3.11* ii linux-image-3.11.0-14-generic 3.11.0-14.21~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP ii linux-image-3.11.0-15-generic 3.11.0-15.25~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP ii linux-image-3.11.0-17-generic 3.11.0-17.31~precise1 Linux kernel image for version 3.11.0 on 64 bit x86 SMP $ dpkg -S iwlwifi-7260 linux-image-3.11.0-15-generic: /lib/firmware/3.11.0-15-generic/iwlwifi-7260-7.ucode linux-image-3.11.0-14-generic: /lib/firmware/3.11.0-14-generic/iwlwifi-7260-7.ucode $ dmesg # failed iwlwifi on latest 3.11.0-17 (no iw phy present) [0.00] Linux version 3.11.0-17-generic (buildd@toyol) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #31~precise1-Ubuntu SMP Tue Feb 4 21:25:43 UTC 2014 (Ubuntu 3.11 .0-17.31~precise1-generic 3.11.10.3) ... [ 17.770121] iwlwifi :03:00.0: request for firmware file 'iwlwifi-7260-7.ucode' failed. [ 17.770127] iwlwifi :03:00.0: no suitable firmware found! $ dmesg # succesfful 3.11.0-15 boot (iw phy0 present) [0.00] Linux version 3.11.0-15-generic (buildd@allspice) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 (Ubuntu 3.11.0-15.25~precise1-generic 3.11.10) ... [ 49.046204] iwlwifi :03:00.0: loaded firmware version 22.0.7.0 op_mode iwlmvm [ 49.120558] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1285727/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
