[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: "adapter resource shortage"?
> 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
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:
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
Main Index |
Thread Index |