From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 18:05:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EBED8939 for ; Tue, 18 Jun 2013 18:05:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id B6FE21AF2 for ; Tue, 18 Jun 2013 18:05:43 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so4883915obc.6 for ; Tue, 18 Jun 2013 11:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iQZwmEgDLu3g4qoEQ1Td2PZ/7NCcwaYepTdtAo+sPI4=; b=h8Gx/C2kHVsXM7yW4dpIRyUlr1/ugOSV4k+z1UT7UJI35SL1xCgjRHjFhORmOjX+52 AIJVfVqWR3T+Yvstx9LQgr3sTbxgcLl8xcBbwO+e+XGD0dmbgPGPYnqvF5IVQdPhYdY5 4ur69+BnxH2HXW5AegqrQKCliZTrCAHbcik6Jg8h1pmRXNQy8wMy2kce4U5Key5lYn0k ksEaPKBLpm1iUkxCBN5tI4AVz5MdGj/L4k5+XoDAlC8F1211J/kVoNnDphPbpKfCVcMp nJsZ+A7P31IUsnMtQcrAFH0+d5ag1YZSVVjtddEjhExzjpduhazOY3cBbWZfYbc3vwMj HX3g== MIME-Version: 1.0 X-Received: by 10.182.66.46 with SMTP id c14mr12694084obt.33.1371578743265; Tue, 18 Jun 2013 11:05:43 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Tue, 18 Jun 2013 11:05:43 -0700 (PDT) In-Reply-To: <20130618144722.GA3446@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> <20130618144722.GA3446@icarus.home.lan> Date: Tue, 18 Jun 2013 11:05:43 -0700 X-Google-Sender-Auth: 1vpxMMC7IvkQtFeCqKAtVB2K1M0 Message-ID: Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Kevin Oberman To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Michiel Boland , "freebsd-stable@freebsd.org Stable" , Javad Kouhi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:05:44 -0000 On Tue, Jun 18, 2013 at 7:47 AM, Jeremy Chadwick wrote: > On Tue, Jun 18, 2013 at 07:00:30PM +0430, Javad Kouhi wrote: > > Thanks for the reply, seems that our source trees are not same, I got > this: > > > > % patch -p1 < /path/to/patch > > Hmm... Looks like a unified diff to me... > > The text leading up to this was: > > -------------------------- > > |diff --git a/sys/dev/drm2/i915/intel_fb.c b/sys/dev/drm2/i915/intel_fb.c > > |index 3cb3b78..e41a49f 100644 > > |--- a/sys/dev/drm2/i915/intel_fb.c > > |+++ b/sys/dev/drm2/i915/intel_fb.c > > -------------------------- > > Patching file sys/dev/drm2/i915/intel_fb.c using Plan A... > > Hunk #1 succeeded at 207 with fuzz 1. > > Hunk #2 failed at 231. > > 1 out of 2 hunks failed--saving rejects to > sys/dev/drm2/i915/intel_fb.c.rej > > Hmm... The next patch looks like a unified diff to me... > > The text leading up to this was: > > -------------------------- > > |diff --git a/sys/dev/syscons/scvgarndr.c b/sys/dev/syscons/scvgarndr.c > > |index 6e6663c..fc7f02f 100644 > > |--- a/sys/dev/syscons/scvgarndr.c > > |+++ b/sys/dev/syscons/scvgarndr.c > > -------------------------- > > Patching file sys/dev/syscons/scvgarndr.c using Plan A... > > Hunk #1 succeeded at 395. > > Hunk #2 failed at 447. > > 1 out of 2 hunks failed--saving rejects to > sys/dev/syscons/scvgarndr.c.rej > > done > > > > > > And the git way: > > > > % git apply /path/to/patch > > error: patch failed: sys/dev/drm2/i915/intel_fb.c:207 > > error: sys/dev/drm2/i915/intel_fb.c: patch does not apply > > error: patch failed: sys/dev/syscons/scvgarndr.c:445 > > error: sys/dev/syscons/scvgarndr.c: patch does not apply > > > > > > I have revision 251934 of -STABLE branch. (I updated my source tree > > about 3 hours ago using svn) > > I do not use git, I use svn, So I cannot help you with git "crap". > > Please revert your sys/dev/drm2/i915/intel_fb.c and > sys/dev/syscons/scvgarndr.c back to r251934 (or newer) before following > what I tell you below. > > The problem is either that: > > - The patch you were given is probably for a different FreeBSD release, > thus the code/line numbers/info in the code break the fuzzy logic > matching, > - You copy-pasted the diff and because of tabs vs. spaces botched it, > - git apply/patch/whatever is weird, > - Multitudes of other possibilities I do not care to go into. > > The hack kib@ gave you is not hard to manually add yourself. It's very > few lines of code. I'm very surprised you didn't try to manually add it > yourself. So I have done that for you. First, the proof -- this is > against r251939, by the way, but that shouldn't matter as nobody has > touched this between r251934 and r251939: > > $ svn info > Path: . > Working Copy Root Path: /home/jdc/work/src > URL: svn://svn.freebsd.org/base/stable/9 > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 251939 > Node Kind: directory > Schedule: normal > Last Changed Author: marius > Last Changed Rev: 251939 > Last Changed Date: 2013-06-18 07:20:14 -0700 (Tue, 18 Jun 2013) > > $ svn status > M sys/dev/drm2/i915/intel_fb.c > M sys/dev/syscons/scvgarndr.c > > The diff itself is available here: > > http://jdc.koitsu.org/freebsd/sysmouse_vsync.diff > > I've also attached it here in Email (assuming the mailing list doesn't > delete it). > > You should apply the patch using: > > cd /usr/src (or wherever your source is) > patch -p0 < sysmouse_vsync.diff > > Assuming use of svn, you can revert this patch by doing: > > cd /usr/src (or wherever your source is) > svn revert sys/dev/drm2/i915/intel_fb.c > svn revert sys/dev/syscons/scvgarndr.c > rm sys/dev/drm2/i915/intel_fb.c.orig > rm sys/dev/syscons/scvgarndr.c.orig > > There is probably some other "magical" way to do all of this, but as > anyone here knows, I do things manually because in general I do not > trust VCSes or the "magic" they do under the hood; I prefer to do things > that I know work. > > Good luck -- I cannot help with any other aspect to the issue. > After some testing, I now believe that there are two failure modes causing hangs on shutdown on Intel_KMS systems. Data is mostly empirical, but it looks pretty clear to me. Failure 1: Shutdown proceeds through a significant portion of the shutdown before hanging shortly before syncing disks. Shutdown has passed the point of most userland capability, so no real access is available. Failure2: Shutdown hangs almost instantly. All disk activity ends and the system (userland) is frozen. ping still works, so the net has not been shutdown and the kernel is still responsive. I suspect that this patch only fixes one of the issues, but time will tell. (I thought I was ready to go on testing this until this morning's security announcement and just finished rebuilding the kernels again.) In all cases, the reboot(8) and halt(8) commands seems to work fine, but won't cleanly shutdown daemons and the like, so this is not a desirable solution. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com