Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Sep 2005 00:25:54 +0100
From:      Joao Barros <joao.barros@gmail.com>
To:        John Baldwin <jhb@freebsd.org>, Scott Long <scottl@samsco.org>,  Warner Losh <imp@freebsd.org>
Cc:        freebsd-current@freebsd.org, Mike Tancsa <mike@sentex.net>
Subject:   Re: 6.0-CURRENT SNAP004 hangs on amr (patch)
Message-ID:  <70e8236f05091016251510408c@mail.gmail.com>
In-Reply-To: <70e8236f0509051350e020f76@mail.gmail.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On 9/5/05, Joao Barros <joao.barros@gmail.com> wrote:
> On 9/5/05, Joao Barros <joao.barros@gmail.com> wrote:
> > On 9/4/05, Joao Barros <joao.barros@gmail.com> wrote:
> > > On 8/8/05, John Baldwin <jhb@freebsd.org> 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: <mass storage, SCSI> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70e8236f05091016251510408c>