Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
cards. These use an ACEX EP1K30 programmable logic device (PLD)
as the PCMCIA->PCI bridge. There's no documentation available on
how Symbol has this configured; the magic bits are based on
modifications to the Linux orinoco driver by Tobias Hoffmann.
He, in turn, figured out the magic from the Windows driver.
This does mean we have undocuemnted hex constants; sigh.
I also moved commented bridge chip info to right before the appropriate
bridge attachment. The massive comment at the top of the file was
becoming illegible.
|
|
not set yet this is a NOOP (noticed some time ago by fgs@).
Call wi_cor_reset() from wi_watchdog() so we do a soft reset of the
card. Currently, we only reset Symbol cards but should probably
reset all but Lucent cards with very old firmware revisions.
|
|
also reclaim resources on failures and etc
|
|
|
|
|
|
|
|
ok millert@
|
|
|
|
|
|
|
|
First cut at osiop driver (LSI Logic/Symbios/NCR 53C710). For hppa
only at the moment.
Functional for the most part, but there are known problems:
1) SCSI_CHECK/REQUEST_SENSE not handled at all - simply returns a
zero'ed scsi_sense_data buffer. As a result all osiop sc_link's are
created with the ADEV_NODOORLOCK quirk to suppress PREVENT_ALLOW
commands from being issued (and failing) during probe.
2) Sync negotiation (wide is not supported on this chip) needs to be
validated due to some ominous comments in the source about being valid
only for the 33Mhz Zeus board.
3) Probe message needs fixing/completion to issue useful info. See 2).
4) Timeout/hangs occur under heavy load, e.g. make builds.
From NetBSD.
ok mickey@
|
|
ok henning@, deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
supported by the card
|
|
|
|
|
|
Replaced some Latin 1 symbols with Latin 2. -moj
|
|
Replaced some Latin 1 symbols with Latin 5. -moj
|
|
|
|
ok miod@
|
|
from Scott Parish <srp at srparish dot net> via PR/3052.
|
|
thanks.
|
|
Thanks to Clarie Wouter (rimshot at pandora point be)
|
|
|
|
Re-work the SBP2 data manipulation to support concurrent node accesses.
(That data manipulation MUST go into SBP2 code, eventually)
|
|
node_id changes, following a BusReset (happens when you add/remove a device
to/from the FireWire chain).
Re-work the ORB management to support concurrent node accesses.
|
|
65535 bytes blocks silently broke. So limit ourself to 32k blocks, for now.
That mistake gave us the false impression that huge transfers were fast.
They usually resulted of 0-byte transfers. Fast indeed :-(
Now, we have real data going through.
|
|
So just ignore, and continue the auto-configuration.
|
|
|
|
That new key will be used for Request handlers to discriminate the requests
by nodes. Key3 will also get the lenght field specifier... (may still change)
Add an implementation for a BusReset callback that will be called whenever
a node's node_id changes.
This will allow us to work with more than one device at the same time...
|
|
|
|
|
|
from dev/ic/wdc.c; from NetBSD.
ok miod@ deraadt@
|
|
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.
|
|
ok costa@
|
|
ok costa@
|
|
there anyway, all code is in the particular bus adapter's source
|
|
|
|
|