From owner-freebsd-stable@FreeBSD.ORG Fri Jun 21 04:54:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3DE99B2F for ; Fri, 21 Jun 2013 04:54:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 0898B1950 for ; Fri, 21 Jun 2013 04:54:45 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id va7so8006803obc.27 for ; Thu, 20 Jun 2013 21:54:45 -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=CwQ8xrAXvot+LZVMthrKE8mdRZjRzOOJwdhWh14glOg=; b=qiRNKzE9SvrTaQ2E6PwoIo3SES6Keu9f+9ZBFXOEmlRKePIBu0au7Gg38od95TLy0Y 62uc74ZlTcnJPKJQ1d22sbnJDTu2F+g0JC/s/bffDZ7DcLfoapYhrfvb6urZjDIkj+LL V/nnF5xtAbSDgCZEh7OlbIGWStWYVHREj+4FtHuD7XTwJMWL/7d25DNVsITNiced8hlM 46SAxenbt9p+4oVa95MhzYHr7oOWyFYnr7XF54NrJJxXcuAHvkRAA/2GyEw5mT/XFwl1 aiRs3+yt25LuCoYrPz3KIMyFFhHSVgK16QpYW5sEY9r2zc7GQXJHZ7VkEbwwdZPqaBGX CVvQ== MIME-Version: 1.0 X-Received: by 10.182.242.45 with SMTP id wn13mr2831236obc.30.1371790485547; Thu, 20 Jun 2013 21:54:45 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Thu, 20 Jun 2013 21:54:45 -0700 (PDT) In-Reply-To: References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> Date: Thu, 20 Jun 2013 21:54:45 -0700 X-Google-Sender-Auth: 1UCIzJ3mHKHHNDg8k-ItJqNN_bM Message-ID: Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Kevin Oberman To: Bengt Ahlgren Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , Michiel Boland , FreeBSD Stable 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: Fri, 21 Jun 2013 04:54:46 -0000 On Thu, Jun 20, 2013 at 4:55 PM, Bengt Ahlgren wrote: > Konstantin Belousov writes: > > > On Mon, Jun 17, 2013 at 09:16:56PM +0200, Michiel Boland wrote: > >> On 06/16/2013 17:11, Michiel Boland wrote: > >> > Hi. Recently I switched to WITH_NEW_XORG, primarily because the > >> > stock X server > >> > with Intel driver has some issues that make it unusable for me. > >> > > >> > The new X server and Intel driver works extremely well, so kudos > >> > to whoever made > >> > this possible. > >> > > >> > Unfortunately, I am now experiencing random hangs on shutdown. On > >> > shutdown the > >> > system randomly freezes after > >> > > >> > [...] syslogd: exiting on signal 15 > >> > > >> > I would then expect to see 'Waiting (max 60 seconds) for system > >> > process 'XXX' to > >> > stop messages, but these never arrive. > >> > >> So it turns out that init hangs because vga_txtmouse (draw_txtmouse in > fact) is > >> hogging the clock swi. The routine is waiting for a vertical retrace > which never > >> arrives. (The new intel driver can't return to text console, so the > screen just > >> goes blank when X exits.) > >> > >> Some workarounds: > >> > >> - don't run moused (i.e. disable it in rc.conf and devd.conf) > >> instead run the X server in combination with hald > >> > >> - do run moused, but then either > >> > >> - unplug the mouse before shutting down > >> > >> - build a kernel with VGA_NO_FONT_LOADING > >> > >> Of course the long-term fix is to remove the possibly infinite loop in > >> draw_txtmouse. > >> > >> Thanks to Konstantin for his patience in helping me track this down. > > > > The following patch, although a hack, should fix the issue. > > Michiel tested it. > > > > 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 > > @@ -207,6 +207,8 @@ static void intel_fbdev_destroy(struct drm_device > *dev, > > } > > } > > > > +extern int sc_txtmouse_no_retrace_wait; > > + > > int intel_fbdev_init(struct drm_device *dev) > > { > > struct intel_fbdev *ifbdev; > > @@ -229,6 +231,7 @@ int intel_fbdev_init(struct drm_device *dev) > > > > drm_fb_helper_single_add_all_connectors(&ifbdev->helper); > > drm_fb_helper_initial_config(&ifbdev->helper, 32); > > + sc_txtmouse_no_retrace_wait = 1; > > return 0; > > } > > > > 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 > > @@ -395,6 +395,8 @@ vga_txtblink(scr_stat *scp, int at, int flip) > > { > > } > > > > +int sc_txtmouse_no_retrace_wait; > > + > > #ifndef SC_NO_CUTPASTE > > > > static void > > @@ -445,7 +447,9 @@ draw_txtmouse(scr_stat *scp, int x, int y) > > #if 1 > > /* wait for vertical retrace to avoid jitter on some videocards */ > > crtc_addr = scp->sc->adp->va_crtc_addr; > > - while (!(inb(crtc_addr + 6) & 0x08)) /* idle */ ; > > + while (!sc_txtmouse_no_retrace_wait && > > + !(inb(crtc_addr + 6) & 0x08)) > > + /* idle */ ; > > #endif > > c = scp->sc->mouse_char; > > vidd_load_font(scp->sc->adp, 0, 32, 8, font_buf, c, 4); > > This patch fixes the shutdown hangs after KMS is initialised for me (on > a Thinkpad X201 w recent 9-STABLE)! Thanks! > > 9.1-REL does not hang, however. Don't know whether this is interesting, > but I bisected 9-STABLE to find out where the problem started (kernel > only together with 9.1-REL userland). 9-STABLE up to and including > r246775 works as it should, but starting with r246785, it hangs on > shutdown. See (yes, it is mouse related!): > > http://svnweb.freebsd.org/base?view=revision&revision=246785 > > Just to be clear: These hangs _only_ occur if KMS gets initialised. > When testing this, I booted, started kdm, and then chose shutdown in the > kdm menu. moused was running. > > Bengt > See *251961* to see the work-around and an explanation of what it worked around. This goes away when return to console mode is available with KMS. The problem is as old as KMS support, but 246785triggered it most of the time when it was occasional before that. It's a race issue. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com