Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754845AbdFWStT (ORCPT ); Fri, 23 Jun 2017 14:49:19 -0400 Received: from mail-oi0-f45.google.com ([209.85.218.45]:35337 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754549AbdFWStS (ORCPT ); Fri, 23 Jun 2017 14:49:18 -0400 Subject: Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 To: Al Viro Cc: LKML , Thorsten Leemhuis References: <69187aa4-611f-b08a-8d14-b8fa47b4c464@lwfinger.net> <1588557c-2706-0c0e-3387-4ae65d0b5790@lwfinger.net> <20170621212257.GN10672@ZenIV.linux.org.uk> <5f4b9fa4-262a-31b1-32ba-a2f6e789b3d6@lwfinger.net> <20170621213415.GO10672@ZenIV.linux.org.uk> <655d304e-e455-6e0c-56e1-f127653ea13c@lwfinger.net> <20170622141203.GP10672@ZenIV.linux.org.uk> <7bbd4c87-e8ff-5f83-8c4c-e205872083bf@lwfinger.net> <20170622192515.GQ10672@ZenIV.linux.org.uk> From: Larry Finger Message-ID: <2346c306-8e26-94cb-3c63-b866a7f4625d@lwfinger.net> Date: Fri, 23 Jun 2017 13:49:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170622192515.GQ10672@ZenIV.linux.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2713 Lines: 55 On 06/22/2017 02:25 PM, Al Viro wrote: > On Thu, Jun 22, 2017 at 09:19:58AM -0500, Larry Finger wrote: > >>> Ugh... MintPPC appears to be dead. On KVM with Debian userland (either >>> jessie or wheezy - no difference in result) booting the commit in >>> question with your .config oopses as soon as pata_macio is initialized, >>> due to the bug in "treewide: Move dma_ops from struct dev_archdata into >>> struct device", and after cherry-picking your own fix for that (commit >>> 46f401c4297a "powerpc/pmac: Fix crash in dma-mapping.h with NULL dma_ops") >>> the result boots just fine. >>> >>> Again, that happens both for Debian 8 and Debian 7 userlands, so unless >>> Mint had been doing something very odd there, I would question the accuracy >>> of your bisect... > >> Any chance that real hardware differs from KVM emulation? > > For that one? Bloody unlikely; udev could, theoretically, hit different codepaths > due to different devices being observed, etc., but changes in that commit are > not in the areas that would be easy to get wrong in emulator. > >> All I know at this >> point is that commit f2ed8beb with 46f401c4 backported boots OK and commit >> 3448890c with the same backport fails. >> >> I will try loading jessie and see what happens. > > I would recheck which kernels are being booted - I had screwed that up during long > bisects often enough... > > BTW, could you try to check what happens if you kill the > if (__builtin_constant_p(n) && (n <= 8)) > bits in raw_copy_{to,from}_user()? The usefulness of those (in __copy_from_user() > originally) had always been dubious and the things are simpler without them. > If _that_ turns out to cure breakage, I would be very surprised, though. > Sorry I was gone so long. Installing jessie on this box resulted in a crash on boot. Lubuntu 14.04 yielded a desktop with a functioning cursor, but nothing else. Finally, Ubuntu 12.04 resulted in a working system. I hate Unity, but I guess I'm stuck for now. I know how easy it is to screw up a long bisection by booting the wrong kernel. To help that problem and to work around the yaconf/yboot nonsense on the MAC, my /etc/yaconf has always had generic kernel stanzas with only default, old, and original kernels mentioned. From there I use a local script to finish a kernel installation by moving the default links to the old ones and creating the new default links pointing to the current kernel. With those long-tested scripts, I'm sure that I am booting the one I want. With the new installation, kernel 4.12-rc6 failed, as did 3448890c with the backported 46f401c4 added. Replacing "if (__builtin_constant_p(n) && (n <= 8))" with "if (0)" had no effect. Larry