Hi All, I've rebased rawhide to the 3.3-rc1 release this afternoon. Overall, not too bad. Aside from a kmemleak issue that prevented booted (patch provided by Catalin already) and a lockdep spew from radeon it booted fine on my machine. There were a few patches we hit that I have questions on. If you're in CC, keep reading below. Matthew, we're carrying revert-efi-rtclock.patch which reverts upstream commit "x86: Serialize EFI time accesses on rtc_lock (ef68c8f87ed1)". However, upstream doesn't have that reverted and I don't see anything in particular that discusses a problem with it. Should we still be carrying this (I think yes) and why didn't upstream revert? Also for Matthew, I left CONFIG_EFI_STUB turned off. It wasn't clear to me if this would make a kernel that would only boot as an EFI executable or if it would do that while still being general purpose. I'll look into this more, but I thought you should weigh in before we switch that on anyway. Dave, block-stray-block-put-after-teardown.patch was added for a supposed problem in the elevator stuff. I've left it commented out of the spec right now because upstream removed the ops member from the elevator_queue struct entirely with commit 22f746e235a5cb. Given they directly access e->type.ops now, I'm not sure this is needed any longer? Dennis, Jon, The arm configs are a WAG. Also, arm-omap-dt-compat.patch didn't apply cleanly so I dropped the application but left it in the tree. It would be really helpful if people were building/working with rawhide first, then backporting to f15 or whatever ARM is using so that we aren't left taking random guesses at what to do. John L, I disabled with_backports like we discussed last week. I'll let you do your thing with compat-wireless when you find time. Oleg, the utrace patch doesn't apply to 3.3 any longer. I've left it unapplied until someone gets a chance to rebase it. For anyone else that might know... the GMA500 driver "moved" from staging to drivers/video/drm/. I say "moved" because the DRM_PSB thing is still sitting in staging. I'll look into this more Monday, but if anyone knows offhand why we now have 2 drivers and which we should enable, please do speak up. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
