cases the registers are not correctly set on resume.
This solves the problem of USB failing after resuming a machine.
Submitted by: mike+fbsd@medianstrip.net
PR: 18261
Promise Ultra100 / Fasttrak100
HighPoint HPT370 controllers (fx Abit KA7-100 onboard ctrl, Abit HotRod 100)
Intel ICH2 (Intel 815E based motherboards)
So far I can read >90MB/s on the Promise and the HPT370.
I can write >64MB/s on the promise and >50MB/s on the HPT370 so it seems
writing is still done in ATA66 mode :(
The ICH2 support is untested as of yet...
modules to depend on modules in the same file (uhub depends on usb) or
even on themselves (usb on usb, makes the define in usb_port.h a lot
less convoluted).
Use ANSI prototypes.
the scratch RAM for data normally found in the SEEPROM (presumably in the
event that the SEEPROM is unavailable or can't be read). This code causes
a spontaneous reboot on monster.osd.bsdi.com, which has an embedded aic7880
controller. The problem appears to happen either when it writes to the
SCBPTR port and then reads from the SCB_CONTROL port. Somewhere during
the inb/outb operations, the system has a heart attack and restarts.
This code looks very suspicious, particularly since it has unconditionalized
debug mesages such as "Got here!" and "And it even worked!". With this
block #ifdef'ed out, the machine boots and runs properly. I stronly suggest
that it stay #ifdef'ed out until it's properly tested.
opens if the reference count is not decremented on close.
Note that this may result in the reference count being corrupted
on full duplex devices (due to mismatching opens/closes), but the
code doesn't use the reference count for anything on full duplex
devices.
2. Offer half duplex with both playback and record on channel 1 or
full duplex with playback always on channel 2 as a compile-time option.
3. 16 bit record output is byte swapped for some dumb reason. Report the _BE
AFMTs for recording.
if you kldload this driver, all the subordinate devices are probed/attached
as expected. But this is not the case when the driver is statically compiled
into the kernel. Since I do most of my testing with modules, I failed to
notice this. I'm not sure if it's intended behavior or not. I think it may
be, but it seems a little counter-intuitive.
16 bit samples have some sort of choppiness, the nature of which
is not completely clear, but it clearly has something to do with
dma buffer synchronization. But at least channel 1 makes noise now.
appears to be the correct length, but quality of output has not yet
been tested. Also, full duplex audio (that is, playback on channel 1)
does not yet work. Two constants and I am there!
Obtained from: major hints from ALSA
with LEDs on some cards being stomped on when clearing the "jabber disable"
bit. Using DC_SETBIT() has an unwanted side effect of setting a write enable
bit in the watchdog timer register which we really want to be cleared when
we do a write.
changes is that there's now a Solaris port of this driver, so some things
in the core version had to change (not much, but some).
In order, from the top.....:
A lot of error strings are gathered in one place at the head of the file.
This caused me to rewrite them to look consistent (with respect to
things like 'Port 0x%' and 'Target %d' and 'Loop ID 0x%x'.
The major mailbox function, isp_mboxcmd, now takes a third argument,
which is a mask that selectively says whether mailbox command failures
will be logged. This will substantially reduce a lot of spurious noise
from the driver.
At the first run through isp_reset we used to try and get the current
running firmware's revision by issuing a mailbox command. This would
invariably fail on alpha's with anything but a Qlogic 1040 since SRM
doesn't *start* the f/w on these cards. Instead, we now see whether we're
sitting ROM state before trying to get a running BIOS loaded f/w version.
All CFGPRINTF/PRINTF/IDPRINTF macros have been replaced with calls to
isp_prt. There are seperate print levels that can be independently
set (see ispvar.h), which include debugging, etc.
All SYS_DELAY macros are now USEC_DELAY macros. RQUEST_QUEUE_LEN and
RESULT_QUEUE_LEN now take ispsoftc as a parameter- the Fibre Channel
cards and the Ultra2/Ultra3 cards can have 16 bit request queue entry
indices, so we can make a 1024 entry index for them instead of the
256 entries we've had until now.
A major change it to fix isp_fclink_test to actually only wait the
delay of time specified in the microsecond argument being passed.
The problem has always been that a call to isp_mboxcmd to get he
current firmware state takes an unknown (sometimes long) amount of
time- this is if the firmware is busy doing PLOGIs while we ask
it what's up. So, up until now, the usdelay argument has been
a joke. The net effect has been that if you boot without being plugged
into a good loop or into a switch, you hang. Massively annonying, and
hard to fix because the actual time delta was impossible to know
from just guessing. Now, using the new GET_NANOTIME macros, a precise
and measured amount of USEC_DELAY calls are done so that only the
specified usecdelay is allowed to pass. This means that if the initial
startup of the firmware if followed by a call from isp_freebsd.c:isp_attach
to isp_control(isp, ISP_FCLINK_TEST, &tdelay) where tdelay is 2 * 1000000,
no more than two seconds will actually elapse before we leave concluding
that the cable is unhooked. Jeez. About time....
Change the ispscsicmd entry point to isp_start, and the XS_CMD_DONE
macro to a call to the platform supplied isp_done (sane naming).
Limit our size of request queue completions we'll look at at interrupt
time. Since we've increased the size of the Request Queue (and the
size of the Response Queue proportionally), let's not create an
interrupt stack overflow by having to keep a max completion list
(forw links are not an option because this is common code with
some platforms that don't have link space in their XS_T structures).
A limit of 32 is not unreasonable- I doubt there'd be even this many
request queue completions at a time- remember, most boards now use
fast posting for normal command completion instead of filling out
response queue entries.
In the isp_mboxcmd cleanup, also create an array of command
names so that "ABOUT FIRMWARE" can be printed instead of "CMD #8".
Remove the isp_lostcmd function- it's been deprecated for a while.
Remove isp_dumpregs- the ISP_DUMPREGS goes to the specific bus
register dump fucntion.
Various other cleanups.
isp_prt calls. We now use an argument to the ISPCTL_FCLINK_TEST
call. We change all IDPRINTF macros to isp_prt calls. We add
the isp_prt function here.
quite a bit so that all of the ports have a similar set of required
macros/definitions (and in similar places in the isp_<platform>.h
file).
Some new macros/functions added- Mailbox Acquire/Relase macros,
NANOTIME macros, SNPRINTf and STRNCAT. MemoryBarrier beomes
MEMORYBARRIER with much stronger types.
isp2100_fw_statename as an INLINE (now a function in isp.c). Remove
isp2100_pdb_statename (unused). Redo all ISP_SCSI_XFER_T as XS_T types.
Change all RQUEST_QUEUE_LEN/RESULT_QUEUE_LEN macros to take a parameter.
Add isp_print_bytes function.
Disable "cache line streaming" for aic7890/91 Rev A chips. I
have never seen these chips fail using this feature, but
some of Adaptec's regression tests have.
Explicitly set "cache line streaming" to on for aic7896/97
chips. This was happening before, but this documents the
fact that these chips will not function correctly without
CACHETHEEN set.
aic7xxx.h:
Add new bug types.
Fix a typo in a comment.
aic7xxx.reg:
Add a definition for the SHVALID bit in SSTAT3 for Ultra2/3
chips. This bit inicates whether the bottom most (current)
element in the S/G fifo has exhausted its data count.
aic7xxx.seq:
Be more careful in how we turn off the secondary DMA channel.
Being less careful may hang the PCI bus arbitor that negotiates
between the two DMA engines.
Remove an unecessary and incorrect flag set operation in
the overrun case.
On Ultra2/3 controllers, clear the dma FIFO before starting
to handle an overrun. We don't want any residual bytes from
the beginning of the overrun to cause the code that shuts
down the DMA engine from hanging because the FIFO is not
(and never will be) empty.
If the data fifo is empty by the time we notice that a
read transaction has completed, there is no need to
hit the flush bit on aic7890/91 hardware that will not
perform an auto-flush. Skip some cycles by short circuiting
the manual flush code in this case.
When transitioning out of data phase, make sure that we
have the next S/G element loaded for the following
reconnect if there is more work to do. The code
would do this in most cases before, but there was
a small window where the current S/G element could
be exhausted before our fetch of the next S/G element
completed. Since the S/G fetch is already initiated
at this point, it makes sense to just wait for the
segment to arrive instead of incuring even more latency
by canceling the fetch and initiating it later.
Fast path the end of data phase handling for the last
S/G segment. In the general case, we might have
worked ahead a bit by stuffing the S/G FIFO with
additional segments. If we stop before using them
all, we need to fixup our location in the S/G stream.
Since we can't work past the last S/G segment, no
fixups are ever required if we stop somewhere in
that final segment.
Fix a little buglet in the target mode dma bug handler.
We were employing the workaround in all cases instead
of only for the chips that require it.
Fix the cause of SCB timeouts and possible "lost data"
during read operations on the aic7890. When sending
a data on any Ultra2/3 controller, the final segment
must be marked as such so the FIFO will be flushed and
cleaned up correctly when the transfer is ended. We
failed to do this for the CDB transfer and so, if
the target immediately transfered from command to data
phase without an intervening disconnection, the first
segment transferred would be any residual bytes from
the cdb transfer. The Ultra160 controllers for some
reason were not affected by this problem.
Many Thanks to Tor Egge for bringing the aic7890 problem
to my attention, providing analysis, as well as a mechanism
to reproduce the problem.
stored at a different location in the PCI space, so adjust accordingly.
Also, when using more than two smart controllers in one machine, the
disks were assigned the wrong drive number; fix this as well.
the 12.4.11 firmware with a few changes to the link handling code merged
in from the 12.4.13 release. I'm doing this because the 12.4.13 firmware
doesn't seem to handle 10/100 link settings properly on 1000baseT cards.
Note that the revision codes still identify the firmware as 12.4.13
because both ti_fw2.h and ti_fw.h have to have the same revision values,
and I wanted to keep the 12.4.13 firmware for Tigon 1 cards.
It's nice to have firmware source.
