Okay... I can't help but think I made a mistake somewhere in the bisecting process, but it seems to have isolated fd4b5fa6e3487d15ede746f92601af008b2abbc0 as the bad commit
$ git bisect log # bad: [6d4f0a79e5a307b6fd3ee3cc5bbb2fcb701b09db] UBUNTU: Ubuntu-4.4.0-57.78 # good: [40a98f0e91bcc062babd017732cbf7cb20cf39fd] UBUNTU: Ubuntu-4.4.0-51.72 git bisect start 'Ubuntu-4.4.0-57.78' 'Ubuntu-4.4.0-51.72' # bad: [cd29d2303e86529c089b1c292480c05e7a24bd16] drm/i915: Respect alternate_ddc_pin for all DDI ports git bisect bad cd29d2303e86529c089b1c292480c05e7a24bd16 # bad: [617dec606ff9e43e64a06daef83e17da0035340a] drm/exynos: fix error handling in exynos_drm_subdrv_open git bisect bad 617dec606ff9e43e64a06daef83e17da0035340a # bad: [0dbd2050197ea4dd59f8957b72981cb7d2cfab1c] usb: gadget: function: u_ether: don't starve tx request queue git bisect bad 0dbd2050197ea4dd59f8957b72981cb7d2cfab1c # bad: [f3f9de1bd9a63b633946226ba23392ad44e2badf] i2c: core: fix NULL pointer dereference under race condition git bisect bad f3f9de1bd9a63b633946226ba23392ad44e2badf # good: [a0678a6643bf688bccce3c298a4a110af10988fc] ipv6: correctly add local routes when lo goes up git bisect good a0678a6643bf688bccce3c298a4a110af10988fc # good: [a0ae41d8ee0549161174a39d60f7316b67a87cae] Bluetooth: btusb: Add support for 0cf3:e009 git bisect good a0ae41d8ee0549161174a39d60f7316b67a87cae # good: [d5d9494d2092a7e571dee635ca254075912355c1] thinkpad_acpi: Add support for HKEY version 0x200 git bisect good d5d9494d2092a7e571dee635ca254075912355c1 # bad: [a6e674fa25854a7dafc59555d508855ea8fe3eaa] i2c: xgene: Avoid dma_buffer overrun git bisect bad a6e674fa25854a7dafc59555d508855ea8fe3eaa # bad: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts git bisect bad fd4b5fa6e3487d15ede746f92601af008b2abbc0 # first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts >From a layman perspective, it doesn't seem like that could possibly cause the >bug. I guess one quick way forward, rather than repeat the whole bisecting process, is to completely reset the repository, bring it up to date, verify the bug still exists, and then revert this specific commit and see if the bug goes away. -- 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/1652348 Title: initrd dhcp fails / ignores valid response Status in linux package in Ubuntu: Incomplete Bug description: Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced that is breaking dhcp booting in the initrd environment. This is stopping instances that use iscsi storage from being able to connect. Over serial console it outputs: IP-Config: no response after 2 secs - giving up IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP IP-Config: no response after 3 secs - giving up with increasing delays until it fails. At which point a simple ipconfig -t dhcp -d "ens2f0" works. The console output is slightly garbled but should give you an idea: (initramfs) ipconfig -t dhcp -[ 728.379793] ixgbe 0000:13:00.0 ens2f0: changing MTU from 1500 to 9000 d "ens2f0" IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP IP-Config: ens2f0 guessed broadcast address 10.0.1.255 IP-Config: ens2f0 complete (dhcp from 169.254.169.254): addres[ 728.980448] ixgbe 0000:13:00.0 ens2f0: detected SFP+: 3 s: 10.0.1.56 broadcast: 10.0.1.255 netmask: 255.255.255.0 gateway: 10.0.1.1 [ 729.148410] ixgbe 0000:13:00.0 ens2f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX dns0 : 169.254.169.254 dns1 : 0.0.0.0 rootserver: 169.254.169.254 rootpath: filename : /ipxe.efi tcpdumps show that dhcp requests are being received from the host, and responses sent, but not accepted by the host. When the ipconfig command is issued manually, an identical dhcp request and response happens, only this time it is accepted. It doesn't appear to be that the messages are being sent and received incorrectly, just silently ignored by ipconfig. I was seeing this behaviour earlier this year, which I was able to fix by specifying "ip=dhcp" as a kernel parameter. About a month ago that was identified as causing us other problems (long story) and we dropped it, at which point we discovered the original bug was no longer an issue. Putting "ip=dhcp" back on with this kernel no longer fixes the problem. I've compared the two initrds and effectively the only thing that has changed between the two is the kernel components. I'm going to try and track back through kernel versions to see if I can find which version the fix happened in to maybe provide some additional context. I'll also attach copies of the initrds, packet captures etc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652348/+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
