[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS: cvs.openbsd.org: src
- To: source-changes_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org
- Subject: CVS: cvs.openbsd.org: src
- From: Kenneth R Westerback <krw_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org>
- Date: Sun, 22 Dec 2002 17:42:33 -0700 (MST)
Module name: src
Changes by: krw_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org 2002/12/22 17:42:33
sys/dev/ic : siop.c
Fix complete botch in handling of 'openings'.
Assign a fixed value (SIOP_NTAGS) to the openings field in the
adapter's template sc_link, rather than incrementing the value as
cbd's are allocated. The template value is the one copied into each
device's sc_link structure as it is created.
Incrementing the value meant that each new device got a larger value
for openings. The total number of openings claimed by devices on a
bus soon exceeded the number of cbd's available. e.g. after 5
devices there would be 132 allocated cbd's, but the total number of
openings claimed by devices would be 300.
A heavy i/o load on an adapter with multiple devices could have
caused the upper scsi layer to try to queue more i/o's than the
driver had cbd's to store them in. Such i/o's would fail with EIO if
they were started with SCSI_NOSLEEP (e.g. sdstart()) or were not
queued within the specified retry limit. I/o's for devices 'later'
on the bus would be more likely to trigger this behaviour, due to
their inflated openings values.
This is good candidate for -stable.
Visit your host, monkey.org