Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp606654ybb; Wed, 1 Apr 2020 06:28:07 -0700 (PDT) X-Google-Smtp-Source: APiQypIiIfyNwhjI0x7LLJLxc5msa8qbPxOcEQdx6ccDV2BYsOEEBDNXHX4E29J62IejwkUp+s3f X-Received: by 2002:aca:f585:: with SMTP id t127mr2802979oih.38.1585747686928; Wed, 01 Apr 2020 06:28:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585747686; cv=none; d=google.com; s=arc-20160816; b=rcCdOQnBqqgRrco/RtoixGVoZ6LOft69f4/GApB6dp6bDCJRVg2bv/fkWI5odBxcDw tow6ZaSKqVQ6PSQCZe/iXTqVfW9Qb3SjS8uA7PrLbtyDZDSCYZ9fY607ChADX6mEcpYA vO8jeLbnCFzJAqyN7RswJyWrhNA4Y23xBaWOXYHe2t/G0jbGc2UilVGwEHcuT3bOgLC9 A88yTeHOStkVR7dSoBX11lRNxjYfKbXy8+cHU67LT4FON95SLNQ3qDdZXNK4jrMJRzs3 T6VwiJJYjNOZ5m3R6qT0pvVdCHAd+ILwKGinaiF8vbk7lTGt5PYrJ+e6BT+TvQkbQBD/ UZzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=gn0gMMvY+flUfYWqYy8QjJkFzSvzEw90kbfFcUTtZCc=; b=Wp7ZgYkIw27xM2ZcNpeCLhiTsUlx0mwo4XS6Xn8m5IemULH62FmHaSIanp8cMjhMPB On0NzjGsfEBzELdBOxZBuwJWui+DQn+7SjUUBqSA8VEIJrXeWqY9Izt5nc5shiI+xyRv e9vc/ZHY4nkhP26pzzfCD+LjQofdIjtDnjAuDHcB6cC2qzoRNcRbOsvEKNSKYlZXxaSR a63D1UWVt8JYDgcINqQe/DQiqyntPtbG5u+DzkTa+ygnGJEJAsWprE19PKbyL7UcgAG4 /jLVhFReAoyLbWJ+0bNzgtvstmk7jgbXpkxH2akxE7VPu9u4mJbwTwphY1BukaRDsf0E yUSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d12si797472oom.31.2020.04.01.06.27.52; Wed, 01 Apr 2020 06:28:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732640AbgDAN0W (ORCPT + 99 others); Wed, 1 Apr 2020 09:26:22 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:43290 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732166AbgDAN0V (ORCPT ); Wed, 1 Apr 2020 09:26:21 -0400 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23992512AbgDAN0QR3HMl (ORCPT ); Wed, 1 Apr 2020 15:26:16 +0200 Date: Wed, 1 Apr 2020 14:26:16 +0100 (BST) From: "Maciej W. Rozycki" To: David Laight cc: Thomas Gleixner , "hpa@zytor.com" , Andrew Cooper , LKML , Ingo Molnar , Borislav Petkov , "x86@kernel.org" , Jan Kiszka , James Morris , David Howells , Matthew Garrett , Josh Boyer , Zhenzhong Duan , Steve Wahl , Mike Travis , Dimitri Sivanich , Arnd Bergmann , "Peter Zijlstra (Intel)" , Giovanni Gherdovich , "Rafael J. Wysocki" , Len Brown , Kees Cook , Martin Molnar , Pingfan Liu , "jailhouse-dev@googlegroups.com" Subject: RE: [PATCH] x86/smpboot: Remove 486-isms from the modern AP boot path In-Reply-To: <23147db6f0c548259357babfc22a87d3@AcuMS.aculab.com> Message-ID: References: <20200325101431.12341-1-andrew.cooper3@citrix.com> <601E644A-B046-4030-B3BD-280ABF15BF53@zytor.com> <87r1xgxzy6.fsf@nanos.tec.linutronix.de> <23147db6f0c548259357babfc22a87d3@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 Apr 2020, David Laight wrote: > > Even though we supported them by spec I believe we never actually ran MP > > on any 486 SMP system (Alan Cox might be able to straighten me out on > > this); none that I know of implemented the MPS even though actual hardware > > might have used the APIC architecture. Compaq had its competing solution > > for 486 and newer SMP, actually deployed, the name of which I long forgot. > > We never supported it due to the lack of documentation combined with the > > lack of enough incentive for someone to reverse-engineer it. > > I also remember one of those Compaq dual 486 boxes. > We must have has SVR4/Unixware running on it. > > I suspect that any such systems would also be too slow and not have > enough memory to actually run anything recent. For reasons mentioned above I cannot speak about 486 SMP systems. However I have a nice Dolch PAC 60 machine, which is a somewhat rugged luggable computer with an embedded LCD display and a detachable keyboard, built around a pure EISA 486 baseboard (wiring to an external display is also supported). Its original purpose was an FDDI network sniffer with a DOS application meant to assist a field engineer with fault isolation, and as you may know FDDI used to have rings up to ~100km/60mi in length, so people often had to travel quite a distance to get a problem tracked down. It used to boot current Linux with somewhat dated userland until its PSU, an industrial unit, failed a couple years back, taking the hard disk with itself due to an overvoltage condition (its +12V output went up to +18V). I failed to repair the PSU (I suspect a fault in the transformer causing its windings to short-circuit intermittently, and only the +5V output is regulated with the remaining ones expected to maintain fixed correlation), which the box has been designed around, making it difficult to be replaced with a different PSU. However I have since managed to track down and install a compatible replacement PSU from the same manufacturer whose only difference are slightly higher power ratings, and I have a replacement hard disk for it too, so I plan to get it back in service soon. With 16MiB originally installed the machine is somewhat little usable with current Linux indeed, however the baseboard supports up to 512MiB of RAM and suitable modules are still available for purchase, even brand new ones. Once expanded so that constant swapping stops I expect the machine to perform quite well, as the performance of the CPU/RAM didn't seem to be a problem with this machine. We actually keep supporting slower systems in the non-x86 ports. And as I say, the userland is not (much of) our business and can be matched to actual hardware; not everyone needs a heavyweight graphical environment with all the bells and whistles burning machine cycles. Again, FWIW, Maciej