6.0-CURRENT SNAP004 hangs on amr (patch)

[Scott Long]

M. Warner Losh wrote:
> 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.
> 
> Warner

This will likely affect any intelligent I/O controller that is designed 
in this manner.  This would include certain network controllers.

Scott