On 08/19/2012 10:29 PM, Stefan Lippers-Hollmann wrote: > Hi > > On Sunday 19 August 2012, Stefan Lippers-Hollmann wrote: >> On Sunday 19 August 2012, Avi Kivity wrote: >> > On 08/19/2012 05:24 PM, Avi Kivity wrote: >> > > On 08/19/2012 05:21 PM, Stefan Lippers-Hollmann wrote: >> > >> >> > >>> Can you please double-check? >> > >> >> > >> I've asked the user to recheck, and he can reproduce it reliably on >> > >> his i5-2300 (x86_64 kernel) and now also a Core2 T5600 (i386 kernel) >> > >> system, using the same encrypted USB HDD in both cases. >> > >> The USB disk fails on 3.5.2+queue-3.5 with both systems and over >> > >> several reboots, while it works with 3.5.2+queue-3.5 and only this >> > >> patch reverted. >> > > >> > > It must be some unrelated miscompile. >> > > >> > > Please ask the user to restest both points with CONFIG_KVM disabled. >> > >> > Actually, that will prove nothing. Not sure how to proceed with this. >> >> I've asked him nevertheless, no problems with 3.5.2+queue-3.5 and >> CONFIG_KVM (and its depending config symbols) disabled. > […] > > I've now asked the user to test a kernel built from current linux.git > HEAD (v3.6-rc2-124-g6dab7ed), which -even though it includes the > original b246dd5df139501b974bd6b28f7815e53b3a792f- doesn't expose any > problems in that regard. The problem seems to be limited to > 3.5.2+queue-3.5, where it fails reliably.
I'm thouroughly confused. Maybe it's some subtle memory corruption caused by changes in the module size. Is the user building kvm as modules or built-in? What happens if he prevents the modules from loading? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
