element access instead of C bitfield (hello, BCPL).
- XXX Some TURBOchannel framebuffers might need shutdownhooks(). It
seems not necessarily hardware sprite cursor images are re-initialized
by DECstation PROMs upon exits from kernel.
- XXX It'd be an arguable point to allow user programs to change the
shade of gray freely for pixel value 0 and 1.
starts running can occur on both DMA in and DMA out. I missed the little comment
in the Mach driver for the DMA out case. Also, only ignore the interrupt if the
TC is non-zero (to match the Mach driver).
is written. This significantly reduces, if not eliminates, the problem reported in
PR#5510. It stops the problem on my 5000/200, and two other people have verified that
it fixes the problem on their 5000/200s. I'm waiting for confirmation from the PR
originator before closing the PR.
- returned EOPNOTSUPP rather than -1.
- no check for negative offset.
many of these fix potential security problems in these drivers.
XXX XXX XXX
the d_mmap cdev routine should be changed to have a prototype like:
paddr_t (*d_mmap) __P((dev_t, off_t, int));
by someone!
assigned to unsigned short variable.
- XXX PMAG-DV is supposed to emit virtical retrace interrupt, which can be
used for colormap/cursor update just like other TURBOchannel framebuffers.
bit/pixel format, not planer format. Assign MSB for cursor mask and
LSB for cursor image, where 10 means mask color and 11 for image color.
Image bit order of Bt431 and Bt459 are opposite to MIPS/Alpha processors
while IMS G332 and DC503 (PCC) are indentical.
- Assume that cursor images are 32 pixel padded as ULTRIX/DU ws interface
do. It's natural to X server.
- XXX Vast majority of codes are duplicated between mfb<->tfb and cfb<->sfb.
Code sharing might be achieved in the context of TGA/SFB+ merge.
N.B., Digital UNIX never supports neither PMAG-AA (mfb) nor PMAG-BA (cfb)
for TC Alphas. PMAG-DV (xcfb) is Personal DECstation built in. All should
be good for console, but need much works for cursor/colormap completeness.
struct scsipi_adapter; they were not used.
Add a scsipi_ioctl entry point to struct scsipi_adapter. This will be
used to issue ioctl commands to the host adapters.
Inspired by PR #6090, from Matt Jacob.
as with user-land programs, include files are installed by each directory
in the tree that has includes to install. (This allows more flexibility
as to what gets installed, makes 'partial installs' easier, and gives us
more options as to which machines' includes get installed at any given
time.) The old SYS_INCLUDES={symlinks,copies} behaviours are _both_
still supported, though at least one bug in the 'symlinks' case is
fixed by this change. Include files can't be build before installation,
so directories that have includes as targets (e.g. dev/pci) have to move
those targets into a different Makefile.
problem was. A collision between a select and reselect would leave TC
non-zero from the command-out DMA count, which could later be considered
a fatal condition, causing a reboot. The message for that error was
only displayed with DEBUG. Fixed by clearing TC on a reselect. The
non-zero TC detection won't occur in this case, so unconditionally
display the message if it occurs.
Workaround for another problem that resulted from an "Illegal Command"
status from the 53c94 which would get ignored and result in a timeout
(which also reboots the system). Added the missing check for the
illegal command status, and add the workaround of resending the "accept
message" command to the 53c94. Correct fix will be to determine why the
message wasn't sent in the first place. Abort if the resending the
command doesn't work.
Correctly detect a spurious interrupt and ignore it. This was taken
from a newer Mach driver, but did not get the check converted for the
design difference between the current NetBSD driver and the Mach driver.
does a "restore data pointers" when reselected after disconnecting in
the middle of a DMA transfer). The driver needs a different way to know
which script to continue the DMA transfer. The message-in for the "restore
data pointers" loses the original "resume" script, and the driver would
attempt to continue the DMA transfer at the beginning of the current DMA
chunk, rather than at the point the disconnect occured. The result was a
spurious console message, and a trashed filesystem.
(currently only CD-ROM drives on i386). The sys/dev/scsipi system provides 2
busses to which devices can attach (scsibus and atapibus). This needed to
change some include files and structure names in the low level scsi drivers.
* hoist code to deal with fragments of a 16-byte chunk outside
main copy loop.
* over 98% of dynamic calls are 2-byte-algnied but not 4-byte-aligned
(due to 14-byte Ether headers). kernel bcopy is poorly tune for this.
Replace bcopy() with inline code tuned to minimize accesses
to DMA buffers, which aren't uncached on mips.
Tested on 5000/240 (3MAXPLUS) and 3000/700 (sandpiper) (mjacob@feral.com)
re-enabled with ASC_IOASIC_BOUNCE.
All DMA buffered processing is now done in the bus-specific DMA routines
in asc_ioasic.c and asc_tc.c.
Disable several informational messages dealing with non-empty FIFO conditions,
but allow enabling with ASC_DIAGNOSTIC for troubleshooting.
* Move clockvar.h (header file for generic clock code) to sys/dev/dec.
* Move if_le_dec.c with DEC padded LANCE-dma (pmax/pmax, ioasic, vax 3400)
to sys/dev/dec. Remove from sys/dev/tc.
* Declare attribute le_dec_subr in /sys/dev/dec/files.dec,
use if_le_dec.c when it's defined.
* Move IOCTL asic declaration from pmax and Alpha MD machine
files to sys/dev/tc/files.tc.
* move TurboChannel and ioasic if_le attachments from pmax and Alpha machine
config files to /sys/dev/tc/files.tc. Add le_dec_subr attribute.
* Add if_le_dec attribute to if_le_ibus (pmax ds3100 pmax) LANCE attachment.
after synch negotation during device probes, the 53C94 stops with the target
reqesting more command data. The fifo appears to still contain a couple of
bytes, so transfer them. If the target still wants command data after that,
do a transfer pad. The target seems to function normally after this. A
much better solution thant simply rebooting!
Also fix a problem when compiling with DIAGNOSTIC - a mismatch between using
DIAGNOSTIC and MACH_DIAGNOSTIC caused the compile to fail.
Try to start another target and a device disconnects.
nisimura