6.0-CURRENT SNAP004 hangs on amr (patch)

M. Warner Losh imp at bsdimp.com
Sat Sep 10 20:31:55 PDT 2005

In message: <70e8236f05091016251510408c at mail.gmail.com>
            Joao Barros <joao.barros at gmail.com> writes:
: Looking at pciconf -l -v :
: pcib3 at pci2:0:0: class=0x060400 card=0x000000dc chip=0xb1548086 rev=0x00 hdr=0x01
:     vendor   = 'Intel Corporation'
:     device   = 'S21152BA,S21154AE/BE PCI to PCI Bridge'
:     class    = bridge
:     subclass = PCI-PCI
: none1 at pci2:1:0: class=0x010000 card=0x8493101e chip=0x12161077 rev=0x06 hdr=0x00
:     vendor   = 'QLogic Corporation'
:     device   = 'ISP12160 Dual Channel Ultra3 SCSI Processor'
:     class    = mass storage
:     subclass = SCSI
: amr0 at pci3:0:0:  class=0x010400 card=0x04931028 chip=0x1960101e rev=0x20 hdr=0x00
:     vendor   = 'American Megatrends Inc.'
:     device   = '80960RP i960RP Microprocessor'
:     class    = mass storage
:     subclass = 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.

One workaround less intrusive workaround would also be to add mass
storage devices to the list of devices that we don't power down by
default.  That would catch all the cases that have been found to have
issues, as far as I can recall.

Since these aren't functions in the same slot, it can be very hard to
know and recoginze this situation automatically.  How do you tell it
apart from two devices on the same bus?  You can't easily tell this.

I have a few ideas here, and will look into them.


More information about the freebsd-current mailing list