From owner-freebsd-current@FreeBSD.ORG Sat Sep 10 23:25:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28F6416A41F for ; Sat, 10 Sep 2005 23:25:57 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F4643D49 for ; Sat, 10 Sep 2005 23:25:55 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by wproxy.gmail.com with SMTP id i21so1402239wra for ; Sat, 10 Sep 2005 16:25:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iTbmPySVfT3wZi73mSpkfmM+CP47/bjyyfTPPjsRQpZ508Ht+JcMj2KXEtQ4PuO/nW4bITLTXh86Ke5o2DqEJFpzSQ5eSmimlOemZwFdjlrrIvFYdEueg7kQZqbG5hvINZh2lSvhTVxgZpD8BDvsaOgkLzagQSOjKgV/eQD2+bI= Received: by 10.54.41.41 with SMTP id o41mr1443587wro; Sat, 10 Sep 2005 16:25:54 -0700 (PDT) Received: by 10.54.38.21 with HTTP; Sat, 10 Sep 2005 16:25:54 -0700 (PDT) Message-ID: <70e8236f05091016251510408c@mail.gmail.com> Date: Sun, 11 Sep 2005 00:25:54 +0100 From: Joao Barros To: John Baldwin , Scott Long , Warner Losh In-Reply-To: <70e8236f0509051350e020f76@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <70e8236f05070208212e36c375@mail.gmail.com> <200507291318.24428.jhb@FreeBSD.org> <70e8236f050807192628b0405e@mail.gmail.com> <200508081311.51857.jhb@FreeBSD.org> <70e8236f05090321007f621845@mail.gmail.com> <70e8236f05090513381584dda0@mail.gmail.com> <70e8236f0509051350e020f76@mail.gmail.com> Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joao.barros@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2005 23:25:57 -0000 On 9/5/05, Joao Barros wrote: > On 9/5/05, Joao Barros wrote: > > On 9/4/05, Joao Barros wrote: > > > On 8/8/05, John Baldwin wrote: > > > > Ok, so I'm assuming that 5.4 works but RELENG_6 does not? Do you h= ave verbose > > > > dmesg's from both cases so that I can compare them? > > > > > > Ok, review: > > > FreeBSD5.4: kernel boots with amr installed > > > FreeBSD6.0: kernel doesn't boot with amr installed > > > As I think some commit in time between 5.4 and CURRENT(6.0) changed > > > something that prevents the kernel to boot with an amr installed, I'm > > > trying to pinpoint that change. > > > So far I've tested 5.4-STABLE-SNAP006-i386 which boots and back till > > > 6.0-CURRENT-SNAP001 which does not boot. > > > My next step will be to cvsup to specific times and start testing ker= nels :) > > > More feedback to come! > > > > And after some(many) hours of compiling I narrowed the gap to a > > working kernel from September 1, 2004 to a non working kernel from > > November 1, 2004. >=20 > Correction: November -> December >=20 > > And yes, more feeback to come. >=20 Eureka! I managed to narrow the gap to the commit responsible for the symptoms I've reported: imp 2004-11-10 00:41:39 UTC FreeBSD src repository Modified files: sys/dev/pci pci.c=20 Log: Make pci_do_powerstate default to 1 now that we've done the release to get more testing. This should help things a little. =20 Revision Changes Path 1.268 +2 -2 src/sys/dev/pci/pci.c Diff: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c.diff?r1= =3D1.267&r2=3D1.268&f=3Dh In pci.c one can read: enable these bits correctly. We'd like to do this all the time, but there are some peripherals that this causes problems with."); Well, I guess it's the case with this controller ;) I tried setting this ( hw.pci.do_powerstate ) tunable to 0 and voil=E1, 6.0 BETA 4 #2 booted with the amr installed. Still on pci.c one can also read: "Power down devices into D3 state when no driver attaches to them. Otherwise, leave the device in D0 state when no driver attaches." This controller just so happens to have a device that FreeBSD doesn't have support: kernel: pci2: at device 1.0 (no driver attached) Looking at pciconf -l -v : pcib3@pci2:0:0: class=3D0x060400 card=3D0x000000dc chip=3D0xb1548086 rev=3D= 0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'S21152BA,S21154AE/BE PCI to PCI Bridge' class =3D bridge subclass =3D PCI-PCI none1@pci2:1:0: class=3D0x010000 card=3D0x8493101e chip=3D0x12161077 rev=3D= 0x06 hdr=3D0x00 vendor =3D 'QLogic Corporation' device =3D 'ISP12160 Dual Channel Ultra3 SCSI Processor' class =3D mass storage subclass =3D SCSI amr0@pci3:0:0: class=3D0x010400 card=3D0x04931028 chip=3D0x1960101e rev=3D= 0x20 hdr=3D0x00 vendor =3D 'American Megatrends Inc.' device =3D '80960RP i960RP Microprocessor' class =3D mass storage subclass =3D RAID So, by not attaching a driver to pci2:1:0, the pci2:0:0 is disabled. Although the 'real' amr is assigned to pci3, the pci bridge on pci2:0:0 gets disabled thus killing the amr. I believe a workaround for this issue would be verifying before disabling the device, that no more that one device shares that particular pci slot. Comments? -- Joao Barros