Re: "adapter resource shortage"?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I've been working over the mpt(4) driver in 5.x heavily of late in an
> effort to make it more robust in the face of errors and the like.  My
> findings are that this error message comes from the scsipi layer of
> the scsi stack and the 1 second delays you're seeing are the scsipi
> subsystem freezing activity to the peripheral card in question so as
> to give it time to drain its transaction queues.

That's approximately what I thought.

> My guess is that you don't want to use the hammer of breaking this
> congestion control mechanism in the upper layers to fix a driver
> problem.

I'd rather not, but it's got one major advantage, that being that I'm
confident I can implement it.

I certainly could add printfs to find out where the
XS_RESOURCE_SHORTAGE is coming from.

> [...]
> I'm surprised you're seeing so many of these errors.  I wonder if the
> scsi bus you're using is having termination issues or if the drives
> themselves are going south.

Strikes me as unlikely, especially the former; the bus in question does
not actually exist - they're SAS, not real SCSI bus.

> How does the entire thing probe?  Are the drives negotiating a
> synchronous transfer speed?

Cut down to just the branch of the tree leading to the sd devices:

mainbus0 (root)
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
ppb1 at pci0 dev 2 function 0: vendor 0x1022 product 0x7450 (rev. 0x13)
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled
mpt0 at pci2 dev 3 function 0: vendor 0x1000 product 0x0050
mpt0: interrupting at ioapic2 pin 0
mpt0: Phy 0: Link Rate 3.0 Gbps
mpt0: Phy 1: Link Rate 3.0 Gbps
mpt0: Phy 2: Link Rate 3.0 Gbps
mpt0: Phy 3: Link Rate 3.0 Gbps
scsibus0 at mpt0: 108 targets, 8 luns per target
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <SEAGATE, ST973401LSUN72G, 0556> disk fixed
sd0: 70007 MB, 14089 cyl, 24 head, 424 sec, 512 bytes/sect x 143374738 sectors
sd0: async, 8-bit transfers, tagged queueing
sd1 at scsibus0 target 1 lun 0: <SEAGATE, ST973401LSUN72G, 0556> disk fixed
sd1: 70007 MB, 14089 cyl, 24 head, 424 sec, 512 bytes/sect x 143374738 sectors
sd1: async, 8-bit transfers, tagged queueing
sd2 at scsibus0 target 2 lun 0: <SEAGATE, ST973401LSUN72G, 0556> disk fixed
sd2: 70007 MB, 14089 cyl, 24 head, 424 sec, 512 bytes/sect x 143374738 sectors
sd2: async, 8-bit transfers, tagged queueing
sd3 at scsibus0 target 3 lun 0: <SEAGATE, ST973401LSUN72G, 0556> disk fixed
sd3: 70007 MB, 14089 cyl, 24 head, 424 sec, 512 bytes/sect x 143374738 sectors
sd3: async, 8-bit transfers, tagged queueing

I can of course supply full boot-time messages if desired.

One thing that I suspect is unlikely to be relevant, but might be - CPU
0 does report

cpu0 at mainbus0 apid 0: AMD 686-class, 2592MHz, id 0x20f12
cpu0: erratum 89 present
cpu0: WARNING: errata present, BIOS upgrade may be
cpu0: WARNING: necessary to ensure reliable operation

Oddly enough, the other three don't, even though as far as I can tell
they're two identical dual-core CPUs.  This latter leads me to wonder
if the erratum may be related to interrupt handling, which could
concievably be related to this....

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B