Date: Sun, 18 Jan 2015 20:31:47 -0800 From: Kevin Oberman <rkoberman@gmail.com> To: Bigby James <bigby.james@dimthoughts.com> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: Re: Lenovo T520: Present (-STABLE) vs. Future (-CURRENT) ACPI Support Message-ID: <CAN6yY1uWV%2BRJbHpEobpoeRzvnZmSf6taVpdVE7Jaa%2B%2BHNz5phQ@mail.gmail.com> In-Reply-To: <20150118232836.GA1494@workbox.Home> References: <20141226165731.GA28169@workbox.Home> <20150118232836.GA1494@workbox.Home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 18, 2015 at 3:28 PM, Bigby James <bigby.james@dimthoughts.com> wrote: > So as part of setting up a Poudriere build server I decided to run a > buildworld > on my machines and, as per John Baldwin's request, I merged r270516 from > HEAD > with r277351 from STABLE. I can confirm Kevin Oberman's findings---things > are > working fine so far. I got to learn a thing or two about FreeBSD > development > and some of the basics of using Subversion. Thanks a lot for the pointers, > folks. So what are the chances of getting this merged into STABLE so > myself and > others don't have to MFC every update? > First, if you use subversion, you won't need to merge the patches every update. As long as those files are not updated, there is no action required. If any of them are, you will be notified of the conflict during the update and you can then resolve it. As intel_opregion.c is pretty stable, I hope it will be MFCed before any other MFCs happen. I will also mention that I did update my system today and the kernel build failed if I did a parallel build (-jN). The failure was in the "depend" stage, so it failed rather quickly. I did two builds with -j6 and two without. Both builds with -j6 failed and both without it succeeded. So something is not quite right and, since I have seen no other reports and it fails while in drm2/i915, it seems very likely it is related to the patch. Of course, it is possible that I messed up the merge, but it seems unlikely that a bad merge would cause this failure. This would indicate a race, possibly triggered by the changes. It could also be hardware dependent. Races can be a real challenge to track down. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1uWV%2BRJbHpEobpoeRzvnZmSf6taVpdVE7Jaa%2B%2BHNz5phQ>