This does seem to help, but with some very big caveats:
First, I was unable to test the -generic kernel because it lacked the mei and mei_me modules. I therefore did my testing with the -lowlatency version of the kernel.
Second, whether the disable_msi=1 kernel option was used or not, the system has frequently been coming up without access to the i350 Ethernet hardware. This isn't happening 100% of the time, but it is happening quite often -- maybe 90% of the time.
Finally, I'm seeing the following kernel errors when using dcmitool in-band:
This does seem to help, but with some very big caveats:
First, I was unable to test the -generic kernel because it lacked the mei and mei_me modules. I therefore did my testing with the -lowlatency version of the kernel.
Second, whether the disable_msi=1 kernel option was used or not, the system has frequently been coming up without access to the i350 Ethernet hardware. This isn't happening 100% of the time, but it is happening quite often -- maybe 90% of the time.
Finally, I'm seeing the following kernel errors when using dcmitool in-band:
[ 256.029897] BUG: scheduling while atomic: dcmitool/ 2056/0x00000002 temp_thermal intel_powerclamp snd coretemp soundcore kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel sb_edac ppdev lp aes_x86_64 ttm drm_kms_helper psmouse drm edac_core serio_raw joydev parport_pc mei_me parport lrw gf128mul glue_helper ablk_helper cryptd mei lpc_ich mac_hid igb i2c_algo_bit hid_generic isci dca e1000e usbhid libsas ptp hid ahci libahci pps_core scsi_transport_sas 17-lowlatency #37 Windmill- EP, BIOS F03_3A07 03/02/2012 e6d>] dump_stack+ 0x4d/0x6f eec>] __schedule_ bug+0x4c/ 0x5a 8de>] __schedule+ 0x6de/0x7f0 a19>] schedule+0x29/0x70 c39>] schedule_ timeout+ 0x279/0x320 cbb>] ? ttwu_stat+ 0x9b/0x110 e1c>] wait_for_ completion+ 0x9c/0x100 e90>] ? wake_up_ state+0x20/ 0x20 fda>] kthread_ stop+0x4a/ 0x130 f7d>] dcmi_transport_ close+0x6d/ 0x120 [dcmi] 6d9>] dcmi_disconnect +0x29/0x40 [dcmi] d0e>] dcmi_release+ 0x2e/0xa0 [dcmi] b13>] __fput+0xd3/0x250 cde>] ____fput+0xe/0x10 8f4>] task_work_ run+0xc4/ 0xe0 816>] do_exit+0x2a6/0xa90 8a4>] ? vtime_account_ user+0x54/ 0x60 07f>] do_group_ exit+0x3f/ 0xa0 0f4>] SyS_exit_ group+0x14/ 0x20 2ff>] tracesys+0xe1/0xe6
[ 256.029956] Modules linked in: dcmi(OF) snd_hda_codec_hdmi snd_hda_intel snd_hda_codec intel_rapl radeon snd_hwdep snd_pcm snd_page_alloc snd_timer x86_pkg_
[ 256.030019] CPU: 9 PID: 2056 Comm: dcmitool Tainted: GF W O 3.13.0-
[ 256.030022] Hardware name: Quanta Freedom/
[ 256.030025] ffff882c7fc34600 ffff881212f0bc50 ffffffff81715e6d 7fffffffffffffff
[ 256.030034] ffff881212f0bc60 ffffffff8170feec ffff881212f0bcc0 ffffffff817198de
[ 256.030041] ffff881209a76040 ffff881212f0bfd8 0000000000014600 0000000000014600
[ 256.030049] Call Trace:
[ 256.030058] [<ffffffff81715
[ 256.030064] [<ffffffff8170f
[ 256.030070] [<ffffffff81719
[ 256.030077] [<ffffffff81719
[ 256.030083] [<ffffffff81718
[ 256.030089] [<ffffffff81094
[ 256.030096] [<ffffffff8171a
[ 256.030103] [<ffffffff8109a
[ 256.030110] [<ffffffff8108b
[ 256.030118] [<ffffffffa0277
[ 256.030124] [<ffffffffa0277
[ 256.030130] [<ffffffffa0278
[ 256.030137] [<ffffffff811be
[ 256.030143] [<ffffffff811be
[ 256.030154] [<ffffffff81088
[ 256.030162] [<ffffffff8106a
[ 256.030169] [<ffffffff8109e
[ 256.030175] [<ffffffff8106b
[ 256.030180] [<ffffffff8106b
[ 256.030187] [<ffffffff81725
Once, the computer spontaneously rebooted a few seconds after I used dcmitool. I don't know if that's connected to the kernel error messages, though.