From owner-svn-src-all@freebsd.org Thu Nov 30 14:40:04 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9810E5D03B; Thu, 30 Nov 2017 14:40:04 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 345E66659B; Thu, 30 Nov 2017 14:40:03 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from hermann ([85.182.2.234]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lqn7e-1eyglV3CMc-00eMTz; Thu, 30 Nov 2017 15:39:55 +0100 Date: Thu, 30 Nov 2017 15:39:51 +0100 From: "Hartmann, O." To: Hans Petter Selasky Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326376 - head/sys/kern Message-ID: <20171130153946.0288b55f@hermann> In-Reply-To: <201711292328.vATNSeOM046518@repo.freebsd.org> References: <201711292328.vATNSeOM046518@repo.freebsd.org> Organization: walstatt.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:pVJvg19BtTNWQxq5b7ihf1eHJr56AY+tQrCQv4Xk5heTzU0lJ+2 alnFMypmF03J8YtWYLVdlFoQ678Kw5N+PhktGk2SZraL67Hu+0WaQLDRs9WGnR3tsmGcG7Y CD5kV50w7bbyeBGXXEIxzpdmPMiYqc+nPiMP5xVdTJ8mB00ddGRp6t9Mr5wn6m7rMcQYDai hLpg6sEerVU2gYEDXk/EA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ouz9tjgZBo8=:rn2PtBkj95014nvGg2Cl3Y DsGsfDRtP94Zz8UU7jhB1jlqmosoZpDexIJBJqkaQ/CTnMlSQoA0rv3s3BEsalniu9UJNFDP+ gdtTE0yEEPziUsqZQT+iCKhYffGKTylWXmNIqhG8DgoAfG8l8n2K30iqUY39wM6A1pLC1z+67 Hi4YhjRxQZO/wcLEMnplmLvDlQKZHKOQUSvGgLocw24hhKTpmxzJiEQp/KBeec1eIuSszDcYe hEAaSUnZDRDg/lwxqucYFXVH+QE1OvSPWzf2H9ciZvqbvRbFXvjhAhHdsXFcrBSYvbzrLvAc+ QGfC109K9OUhDlPQWcb0nmQa0ImLqJ06yc2BQi9XSvE7HXJfz9Lx81mJ6f8nXlX0XIf44FS8j gmZ2LphBZadwIA+qb0o/fpP+8O+e4MH7H2eCKlH3pJyn9QPK7qJ2zOU09I1Qw+A3KT9ZYX4RH LZdU9J+nl34mIimnUFayQc17TuJ1kpyUKRTY5gEi1VzX4l7V497V8ZK437BNgX2h/gOhfufTr 05WnXKh1OOX4UnYxtL41tTL39KcwRnGIbnRgiDmWMMtiPQ/vaVU39kiy4fjFaZQp2ult2lCLB FhX29woENa0YkD6ZDwTQN1tOzvs8iGyAFr+WxLs/K1X5NzIXZKad8LvpSIDn2m0SDB9BH0SLv yC8SJm4KEVq35+4wEUtgwXNn4QcCoCvvu7xTIZ4pnCLNrvl6ta9KxgZ/ofSKmnMCsED6rZqsR nFP5L125JQQJF9U7cCpmOl3DIjwVSGyy1jTTC6ffqk80/vJnvQfiIBf8WII3wpFDhwBpGHkAP iIDlJiK3EtHjb84Wz6v/Pd65d99YfvN4k7hnS58ZHKE4ZnfX8c= X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 14:40:04 -0000 On Wed, 29 Nov 2017 23:28:40 +0000 (UTC) Hans Petter Selasky wrote: > Author: hselasky > Date: Wed Nov 29 23:28:40 2017 > New Revision: 326376 > URL: https://svnweb.freebsd.org/changeset/base/326376 >=20 > Log: > The sched_add() function is not only used when the thread is > initially started, but also by the turnstiles to mark a thread as > runnable for all locks, for instance sleepqueues do: > setrunnable()->sched_wakeup()->sched_add() > =20 > In r326218 code was added to allow booting from non-zero CPU numbers > by setting the ts_cpu field inside the ULE scheduler's sched_add() > function. This had an undesired side-effect that prior sched_pin() > and sched_bind() calls got disregarded. This patch fixes the > initialization of the ts_cpu field for the ULE scheduler to only > happen once when the initial thread is constructed during system > init. Forking will then later on ensure that a valid ts_cpu value > gets copied to all children. > =20 > Reviewed by: jhb, kib > Discussed with: nwhitehorn > MFC after: 1 month > Differential revision: https://reviews.freebsd.org/D13298 > Sponsored by: Mellanox Technologies >=20 > Modified: > head/sys/kern/sched_ule.c >=20 > Modified: head/sys/kern/sched_ule.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/sys/kern/sched_ule.c Wed Nov 29 21:16:14 2017 > (r326375) +++ head/sys/kern/sched_ule.c Wed Nov 29 23:28:40 > 2017 (r326376) @@ -1405,7 +1405,6 @@ sched_setup(void *dummy) > =20 > /* Add thread0's load since it's running. */ > TDQ_LOCK(tdq); > - td_get_sched(&thread0)->ts_cpu =3D curcpu; /* Something valid > to start */ thread0.td_lock =3D TDQ_LOCKPTR(TDQ_SELF()); > tdq_load_add(tdq, &thread0); > tdq->tdq_lowpri =3D thread0.td_priority; > @@ -1642,6 +1641,7 @@ schedinit(void) > ts0->ts_ltick =3D ticks; > ts0->ts_ftick =3D ticks; > ts0->ts_slice =3D 0; > + ts0->ts_cpu =3D curcpu; /* set valid CPU number */ > } > =20 > /* > @@ -2453,7 +2453,6 @@ sched_add(struct thread *td, int flags) > * Pick the destination cpu and if it isn't ours transfer to > the > * target cpu. > */ > - td_get_sched(td)->ts_cpu =3D curcpu; /* Pick something valid > to start */ cpu =3D sched_pickcpu(td, flags); > tdq =3D sched_setcpu(td, cpu, flags); > tdq_add(tdq, td, flags); > _______________________________________________ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to > "svn-src-head-unsubscribe@freebsd.org" With that patch commited, I was able to boot at least a single user kernel (r326394). The kernel immedaitely crashes when trying to start X11 (the laptop is a Intel haswell i5 4200M type CPU, Lenovo E540, the Optimus nVidia GPU is not used, i915kms.ko loaded). The binary world is now r326394, the kernel successfuly running is r325893. Anything > r326218 is failing! And it is even worse for me. On the three crashed servers I'm unable to boot any(!) kernel. All three system boot off Samsung SSD, two 850 Pro (256GB), on server is with an older Samsung 830 Pro, 128 GB. Any kernel on those boxes booting off after they have been corrupted,=20 r326394 GENERIC and the custom kernels adjusted to each machine, is booting and then getting stuck at a certain point after initializing USB. Forever. They seem active a kind of, since pluggin/unpluggin devices is reported. A weird thing is, I have installed different kernels from a packages built on the remaining machine, droped at /boot/kernel.SOMENAME. The loader doesn't give me those additional kernels: when exting the loader menu with option 3 and typing: load /boot/kernel.GENERIC/kernel at the loader prompt (OK ), I get something like no filename provided or similar. Huh? What the ... is this meaning? When investigating the filesystem with this minimalistic Current from 21.11.2017 (USB flash image), the folger boot/kernel.GENERIC/ is well populated and the GENERIC kernel is also there and seem well. What happened here? =46rom another post I got the idea that the "patch" N. Whitehorn corrupted or destroyed SSDs - so how can this be fixed or: how can I check whether the SSD system has been destroyed? For the record: after a after-the-book update of r32635X (single user booted new kernel), a kernel crash occured while installing world. After that, I was presented a halted BTX loader screen on all those SSD driven systems. On two of the systems I have on ZFS volumes a complete /usr/obj. With the CURRENT images provided I can not even installworld/installkernel this world nor rebuild it with the proper fixes. Please advice how to perform a installworld/installkernel. Somewhere FreeBSD must have some desaster recovery image not crippled and evacuated of the compiler suite. Kind regards and thanks in advance, oh=20