From owner-freebsd-bugs@FreeBSD.ORG  Wed Apr 15 17:41:10 2015
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Delivered-To: freebsd-bugs@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id CF20E5EE
 for <freebsd-bugs@FreeBSD.org>; Wed, 15 Apr 2015 17:41:10 +0000 (UTC)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
 [IPv6:2001:1900:2254:206a::16:76])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id B55ED357
 for <freebsd-bugs@FreeBSD.org>; Wed, 15 Apr 2015 17:41:10 +0000 (UTC)
Received: from bugs.freebsd.org ([127.0.1.118])
 by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3FHfAZn022402
 for <freebsd-bugs@FreeBSD.org>; Wed, 15 Apr 2015 17:41:10 GMT
 (envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-bugs@FreeBSD.org
Subject: [Bug 199321] Total MSI-X vector allocation limited to 191 vectors
Date: Wed, 15 Apr 2015 17:41:10 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 11.0-CURRENT
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: jhb@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-199321-8-Bh5JfSHZTl@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-199321-8@https.bugs.freebsd.org/bugzilla/>
References: <bug-199321-8@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-bugs@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Bug reports <freebsd-bugs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-bugs>,
 <mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs/>
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
 <mailto:freebsd-bugs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2015 17:41:10 -0000

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321

--- Comment #2 from John Baldwin <jhb@FreeBSD.org> ---
Yes, this is a known issue, but the solutions I have in mind aren't entirely
trivial.  The "best" solution in my mind is to flesh out the multi-pass
boot-time probe stuff more fully that I started so that we are able to
initialize things like timers early and then bring up the APs (and scheduler)
before most drivers probe.  This would allow drivers to properly spread their
interrupts across all CPUs from the start rather than having them all start off
on 0.  The hackish approach is to change individual drivers to defer setting up
interrupts until after SI_SUB_SMP via a custom SYSINIT.  That's not really
great long term of course but would work as a workaround on older systems.

-- 
You are receiving this mail because:
You are the assignee for the bug.