ULTRAENB->FAST20
Add a missing ahc_run_done_queue if a BRKADDRINT occurs. This should never
happen (haven't heard of one happening), but it was still a bug.
Brought the ordered tag sending code up into the tag code to be clearer.
If we decide we should send an ordered tag, only do so for the target that
timed out instead of all targets.
Initialize the STAILQ in ahc_serach__qinfifo. This was causing a panic
during some recovery operations.
Remove the unused varable maxtarget.
free.
When we clear SCSIRATE, also clear the FAST20 bit in SXFRCTL0. This also
allowed me to clean up some of the ULTRA code.
ULTRAENB->FAST20 to follow the convention in the Adaptec data books.
Fix the data-overrun code to set both stcnt and hcnt otherwise, the transfer
will just hang until we get a timeout.
Add implicit support for the NOOP message. I've never heard of the driver
issueing a reject for one, but its silly to reject NOOP and who knows how a
device might react.
In the dma routine, check SDONE before cleaing SDMAEN. The data books mention
SDONE possibly being cleared when SDMAEN is reset. Clients of dma now need
to check if SINDEX is cleared to know if a phasemis occured.
Fix some comments to be correct.
diff output, and replace them with "(password)". The diffs get
mailed to root, which in many cases is forwarded across the
Internet. A patient sniffer could acquire the entire "master.passwd"
file by saving all the diffs. With this fix, you still see that the
password changed, but you don't see the details.
Unless somebody talks me out of it, I am going to merge this into -2.2
in 48 hours.
from last time. Some people have pointed out that there were some odd
side-effects in the changes I made. Two things are different:
- sc_print_addr() will print 'foodev0:' (i.e. sd0:, st0:, cd0:, etc...)
if the device name is known. If it's not known, it'll use a longer
notation. This shortens error messages back to a sane length.
- Added a small function called sc_print_init() to set the sc_printing
flag so that sc_print_addr() will know that we want it to print a
linefeed. Used this in scsi_device_attach() to restore proper carriage
return printing behavior which I broke.
Remaining bogons: the NCR SCSI driver prints out information while the
device-specific attach routine is running with its own linefeeds. This
breaks up the individual messages emitted by the subdriver modules and
causes at least one message to appear on a line by itself without a
device spec prefix. I'm not sure of the correct way to fix this, and
I don't have any NCR SCSI hardware to test with anyway.
There's probably more, but I gather that a rewrite of the SCSI subsystem
is pending anyway, so I'll leave the rest to Those Who Know More About
This Than I (tm).
Submitted by: Bruce Murphy <packrat@iinet.net.au>
Add '-a' audible flag, so terminal will beep upon receipt of a reply
packet. Useful for debugging ethernet runs, among other things.
complained so it cannot be entirely bad :-)
I include the email that probably explains it for people who already know:
> >Compiling with -O3 inlines functions. However the function that is being
> >inlined in makeinfo.c (add_word_args()) is a vararg function and must not be
> >inlined.
> >
> >The code in question is K&R style, and AFIK, there is no way for the compiler
> >to determine that the function uses vararg. Either change the code to use
> >prototypes, or use stdarg, or add a directive to prevent inlining.
>
> Not declaring a varargs function as varargs before it is used gives
> undefined behaviour.
>
> However, in practice the bug is probably in FreeBSD's <varargs.h>, which
> doesn't use gcc's __builtin_next_arg(). gcc should notice that it is
> used and not inline functions that have it. <stdarg.h.> uses it, but I
> think there's another gcc builtin that it should be using.
Patch attached. The ellipsis causes gcc to flag this as a varargs function,
and the name "__builtin_va_alist" is special cased in gcc to hide the last
argument in the arglist.
Reviewed by: bde & phk
Submitted by: jlemon@americantv.com (Jonathan Lemon)
The PS/2 mouse device responds to a reset command with a sequence of
ACK(fa), RESULT(aa) and ID(00). Most PS/2 mice immediately returns
ACK, but spend sometime before sending RESULT. The Armada takes time
before ACK; extra delay is necessary before the call to read ACK.
The problem was reported in comp.unix.bsd.freebsd.misc and the patch
was tested by the reporter. No PR was filed, by the way.
