On Fri, 2013-07-19 at 22:31 -0700, Josh Triplett wrote: > Package: src:linux > Version: 3.10.1-1 > Severity: normal > > On boot, before the prompt for my disk encryption passphrase, I get a > hang for several seconds. dmesg says: > > [ 1.207889] mei_me 0000:00:16.0: setting latency timer to 64 > [ 1.207961] mei_me 0000:00:16.0: irq 40 for MSI/MSI-X > [ 1.232899] mei_me 0000:00:16.0: wait hw ready failed. status = 0x0 > [ 8.223861] mei_me 0000:00:16.0: wating for mei start failed > [ 8.223935] mei_me 0000:00:16.0: HBM haven't started > [ 8.224002] mei_me 0000:00:16.0: link layer initialization failed. > [ 8.224072] mei_me 0000:00:16.0: init hw failure. > [ 8.224391] mei_me 0000:00:16.0: initialization failed. > > CONFIG_INTEL_MEI and CONFIG_INTEL_MEI_ME are both tristate, so why not > build them as a module?
These enabled a single module before 3.10 (with INTEL_MEI_ME being a bool), and no-one noticed the change. > It's also a bug that the mei-me module delays boot for several seconds > on hardware without an ME, but that seems like a separate bug. There seem to be several different possible failure modes; here it fails rather faster: [ 0.484475] mei_me 0000:00:16.0: setting latency timer to 64 [ 0.484508] mei_me 0000:00:16.0: irq 42 for MSI/MSI-X [ 0.509073] mei_me 0000:00:16.0: wait hw ready failed. status = 0x0 [ 0.509133] mei_me 0000:00:16.0: version message writet failed [ 0.509184] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING [ 0.537061] mei_me 0000:00:16.0: wait hw ready failed. status = 0x0 [ 0.537115] mei_me 0000:00:16.0: version message writet failed [ 0.537165] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING Changing it back to a module will still result in it being auto-loaded, though you can at least blacklist it as a workaround. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings.
signature.asc
Description: This is a digitally signed message part
