From owner-freebsd-bugs@FreeBSD.ORG Sun Apr 13 19:30:01 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA6563E9 for ; Sun, 13 Apr 2014 19:30:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 C79291CF6 for ; Sun, 13 Apr 2014 19:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3DJU1rO068583 for ; Sun, 13 Apr 2014 19:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3DJU1lj068582; Sun, 13 Apr 2014 19:30:01 GMT (envelope-from gnats) Date: Sun, 13 Apr 2014 19:30:01 GMT Message-Id: <201404131930.s3DJU1lj068582@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Yuri Zaporozhets Subject: Re: kern/188534: Revision 262226 of /sys/dev/pci/pci.c causes kernel hang on an Asus CUBX board X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Yuri Zaporozhets List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 19:30:01 -0000 The following reply was made to PR kern/188534; it has been noted by GNATS. From: Yuri Zaporozhets To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/188534: Revision 262226 of /sys/dev/pci/pci.c causes kernel hang on an Asus CUBX board Date: Sun, 13 Apr 2014 22:26:39 +0300 Hello, I just noticed that replacing flags = RF_ALIGNMENT_LOG2(mapsize); with flags = rman_make_alignment_flags(mapsize); fixes the problem and the kernel boots just fine. In these two cases the values for flags are obviously very different. Here is a table to compare (the case for my machine): slot bad flags (buggy) new flags (fine) ------------------------------------------------ 0x0 0x6800 0x1400 0x4 0x1000 0x800 0x4 0x1400 0xC00 0x4 0x1000 0x800 0x7 0xC00 0x800 0x7 0x800 0x400 0x7 0xC00 0x800 0x7 0x800 0x400 0x7 0x1000 0x800 0xA 0x3000 0x1000 0xA 0x1800 0xC00 0xA 0x4400 0x1400 0xB 0x6800 0x1400 0xD 0x3000 0x1000 0xD 0x1400 0xC00 0xD 0x5000 0x1400 If this is indeed a bug and not a design feature (I cannot be 100% sure since I haven't read the specifications or code thoroughly), then it looks quite serious, and presumably it may cause the crash not only on my particular machine configuration. -- Regards, Yuri