On a system with a large amount of ram (e.g. 2G), allocation of per-page
data structures (512K physical pages) could easily bust the initial kernel
page table (36M), and growth of kernel page table requires kptobj.
shared signal handling when there is shared signal handling being
used.
This removes the main objection to making the shared signal handling
a standard ability in rfork() and friends and 'unconditionalising'
this code. (i.e. the allocation of an extra 328 bytes per process).
Signal handling information remains in the U area until such a time as
it's reference count would be incremented to > 1. At that point a new
struct is malloc'd and maintained in KVM so that it can be shared between
the processes (threads) using it.
A function to check the reference count and move the struct back to the U
area when it drops back to 1 is also supplied. Signal information is
therefore now swapable for all processes that are not sharing that
information with other processes. THis should addres the concerns raised
by Garrett and others.
Submitted by: "Richard Seaman, Jr." <dick@tar.com>
to release the probe ccb before taking down the periph.
Also, don't do cdscheduling if you're not going to
attach the device after all.
Reviewed by: ken@freebsd.org
from sc, vt and sio drivers. Use instead a linker_set to collect them.
Staticize ??cngetc(), ??cnputc(), etc functions in sc and vt drivers.
We must still have siocngetc() and siocnputc() as globals because they
are directly referred to by i386-gdbstub.c :-(
Oked by: bde
already loaded and interpreted userconfig_script. Otherwise, when using
such kernel system would always block waiting for user input in UserConfig,
while the intention was to avoid this by having userconfig_script.
Reviewed by: msmith
that they might be about to blow their feet off if they have not been
reading their mail. I don't know if or how well this will work, but it's
worth a try.
It keeps returning queue full until we have reduced the number of tagged
openings to the minimum.
So, put in a quirk entry with the same work-around. This quirk entry is
only for the 9G Atlas III, once someone comes up with inquiry information
for the 18G version of that drive, we can quirk it as well.
Submitted by: "Johan Granlund" <johan@granlund.nu>
downward growing stacks more general.
Add (but don't activate) code to use the new stack facility
when running threads, (specifically the linux threads support).
This allows people to use both linux compiled linuxthreads, and also the
native FreeBSD linux-threads port.
The code is conditional on VM_STACK. Not using this will
produce the old heavily tested system.
Submitted by: Richard Seaman <dick@tar.com>
MNT_WAIT when we mean boolean `true' or check for that value not being
passed. There was no problem in practice because MNT_WAIT had the
magic value of 1.
and mx_setcfg() so that we can read the internal MII registers on the
MX98713 chip correctly. With these changes, media autoselection now
works correctly on the original 98713. All Macronix chips should now
be properly supported (unless there's a surprise waiting in the 98725).
Thanks to Ulf Zimmermann for providing a 98713 board.
list of devices which has been changed in UserConfig, without resorting
to reading /dev/kmem.
The data returned consist of series of struct isa_device and
char dev_name[8].
Ok'd by: jkh
the quirk that disables tagged queueing for those drives.
Also, silence a warning by disabling xpt_for_all_targets() and
xpt_for_all_periphs(). These two functions are not currently used, but
they should not be removed. They're part of a set of functions that
provide a way to execute a function for every {bus,target,device,periph} in
the system.
If anyone needs to use either function in the future, they can be
un-#ifdefed.
is enough to satisfy things like StarOffice. This is a hack, but doing
it properly would be a LOT of work, and would require extensive grovelling
around in the user address space to find the argv[].
Obtained from: Mostly from Andrzej Bialecki <abial@nask.pl>.
isolated to revision 33 PNIC chips is also present in revision 32 chips.
Cards with rev. 32 chips include the LinkSys LNE100TX and the Matrox
FastNIC 10/100. This accounts for all the cards that I have to test
with.
(I was never able to personally trip the bug on this chip rev, but today
one of the guys in the lab did it with the software they're working on
for their cellular IP project, which uses BPF and promiscuous mode
extensively.)
This commit enables the promiscuous mode software workaround code for
both revison 32 and revision 33 chips. It's possible all of the PNIC
chips suffer from this bug, but these are the only two revs where I
know for a fact it exists.
CAPACITY fail for a non-removable media device. There's a race
condition where the device entry is removed and then
xpt_release_ccb is called which attempts to give back the ccb
to a device that's now gone. In this bandaid release the ccb
early and then remember to not call xpt_release_ccb later.
- Special registers of IO-DATA device's RSA series are defined in
ic/rsa.h (new file).
Pointed out by: Bruce Evans <bde@zeta.org.au>
Submitted by: Takahashi Yoshihiro <nyan@wyvern.cc.kogakuin.ac.jp>
Noticed by: Carl Mascott <cmascott@world.std.com>
Don't write access time of a file more than once per day. (Its precision is
1 day anyway). Don't try to write access and creation time in nonwin95 case.
Suggested by: bde (long time ago).
used in device attach routines. At least for attaches at boot time,
actually waiting, or actually failing for malloc(..., M_NOWAIT), are
almost equally unlikely and harmless, but using M_WAITOK interferes
with automatic detection of bogus M_WAITOK's.
deltas, but it is possible since I had a few merge conflicts over the last
few days while this has been sitting ready to go.
(Part 1 was committed to the config files, but cvs aborted grrr..)
Approved by: core
I/O requests must be marked P_SYSTEM because if it isn't and the system
decides to swap it or (god forbid) kill it, the system stands a good
chance of locking up.
chip revisions. (A buggy taiwanese chip? I'm just shocked; shocked I tell
you.) So far I have only observed the anomalous behavior on board with
PCI revision 33 chips. At the moment, this seems to include only the
Netgear FA310-TX rev D1 boards with chips labeled NGMC169B. (Possibly this
means it's an 82c169B part from Lite-On.)
The bug only manifests itself in promiscuous mode, and usually only at
10Mbps half-duplex. (I have not observed the problem in full-duplex mode,
and I don't think it ever happens at 100Mbps.) The bug appears to be in
the receiver DMA engine. Normally, the chip is programmed with a linked
list of receiver descriptors, each with a receive buffer capable of holding
a complete full-sized ethernet frame. During periods of heavy traffic
(i.e. ping -c 100 -f 8100 <otherhost>), the receiver will sometimes appear
to upload its entire FIFO memory contents instead of just uploading the
desired received frame. The uploaded data will span several receive
buffers, in spite of the fact that the chip has been told to only use
one descriptor per frame, and appears to consist of previously transmitted
frames with the correct received frame appended to the end.
Unfortunately, there is no way to determine exactly how much data is
uploaded when this happens; the chip doesn't tell you anything except the
size of the desired received frame, and the amount of bogus data varies.
Sometimes, the desired frame is also split across multiple buffers.
The workaround is ugly and nasty. The driver assembles all of the data
from the bogus frames into a single buffer. The receive buffers are always
zeroed out, and we program the chip to always include the receive CRC
at the end of each frame. We therefore know that we can start from the
end of the buffer and scan back until we encounter a non-zero data byte,
and say conclusively that this is the end of the desired frame. We can
then subtract the frame length from this address to determine the real
start of the frame, and copy it into an mbuf and pass it on.
This is kludgy and time consuming, but it's better than dropping frames.
It's not too bad since the problem only happens at 10Mbps.
The workaround is only enabled for chips with PCI revision == 33. The
LinkSys LNE100TX and Matrox FastNIC 10/100 cards use a revision 32 chip
and work fine in promiscuous mode. Netgear support has confirmed that
they "have some previous knowledge of problems in promiscuous mode" but
didn't have a workaround. The people at Lite-On who would be able to
suggest a possible fix are on vacation. So, I decided to implement a
workaround of my own until I hear from them. I suppose this problem made
it through Netgear's QA department since Windows doesn't normally use
promiscuous mode, and if Windows doesn't need the feature than it can't
possibly be important, right? Grrr.
key? ( -- flag) \ check to see if there's a key to be read from input
ms ( u -- ) \ wait that many milliseconds
seconds ( -- u ) \ get number of seconds from midnight.
'words' now outputs the list page by page - this probably should go
through libstand's pager, but will have to wait for closer integration of
built-ins with Forth...
Submitted partially by: W Gerald Hicks <wghicks@bellsouth.net>
this has a problem with capture but i am not sure if it is related
to the mixer or what else.
But in the meantime, this is ok to listen to mpegs.
I also have a much simpler version of the driver in the works which
reuses a lot more of the existing "pcm" routines. Next year...
have all fields in network order, whereas ipfw expects some to be
in host order. This resulted in some incorrect matching, e.g. some
packets being identified as fragments, or bandwidth not being
correctly enforced.
NOTE: this only affects bridge+ipfw, normal ipfw usage was already
correct).
Reported-By: Dave Alden and others.
* Move the user stack from VM_MAXUSER_ADDRESS to a place below the 32bit
boundary (needed to support 32bit OSF programs). This should also save
one pagetable per process.
* Add cvtqlsv to the set of instructions handled by the floating point
software completion code.
* Disable all floating point exceptions by default.
* A minor change to execve to allow the OSF1 image activator to support
dynamic loading.
default for BINDIR. The default BINDIR of /usr/mdec can't be overridden
yet because libdisk still uses /usr/mdec and installing in /boot might
clobber the new boot blocks.
Don't install links to bootxx or xxboot.
Install boot1 and boot2 in 1 step.
Don't delete the boot.help source file on installing it when ${COPY} is
null.
"dying daemons" problem. (I thought this code was introduced in rev.1.80,
but it just relaxed the condition.)
Also, kill related "suggest more swap space" warning (also introduced in
1.80). It was confusing, to say the least...
Requested by: msmith
Not objected by: dg
There's something that's been bugging me for a while, so I decided to fix it.
FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least
in my opinion. The behavior change is such that:
1. Nothing changes when debugger_on_panic != 0.
2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the
machine will reboot. Also, if a trap occurs, the machine will
panic and reboot, unlike how it broke to DDB before. HOWEVER,
a trap inside DDB will not cause a panic, allowing full use
of DDB without having to worry about the machine being stuck
at a DDB prompt if something goes wrong during the day.
Patches for this behavior follow my signature, and it would
be a boon to anyone (like me) who uses DDB_UNATTENDED, but
actually wants the machine to panic on a trap (otherwise,
what's the use, if the machine causes a fatal trap rather than
a true panic, of debugger_on_panic?). The changes cause no
adverse behavior, but do involve two symbols becoming global
Submitted by: Brian Feldman <green@unixhelp.org>
kernel as a pseudo-device. The changes were:
- #ifdef DEBUG -> #ifdef VINUMDEBUG
- opt_vinum.h for holding above config variable
- Fixing up a few stray problems where DEBUG wasn't optional.
- config.c -> vinumconfig.c (there's already a config.o)
- Other *.c -> vinum*.c (wasn't strictly necessary, but done in case we end
up with something else conflicting later on and we might have to have yet
more repository copies of files).
- include file paths fixups.. (ie: get them all from the kernel tree
instead of partly from the kernel and partly from /usr/include/machine)
I've spoken with Greg about this.. I hope this doesn't mess him around
too much..
CPU_WT_ALLOC does not work correctly for K6-2s of model 8+ and
probably K6-3s (when they appear on the market soon). In addition,
print_AMD_info() incorrectly printfs write allocation's size. I've
fixed them, so they now Do The Right Thing, and added a
"NO_MEMORY_HOLE" option to easily allow 15-16mb range handling for us
K6 and K6-2 users.
Submitted by: Brian Feldman <green@unixhelp.org>
ISDN4BSD is the work of our brand-new comitter: Hellmuth Michaelis,
who has done a tremendous amount of work to bring us this far.
There are still some outstanding issues and files to bring into
the tree, and for now it will be needed to pick up all the extra
docs from the isdn4bsd release.
It is probably also a very good idea to subscribe to the isdn@freebsd.org
mailing list before you try this out.
These files correspond to release "beta Version 0.70.00 / December
1998" from Hellmuth.
last cleanup. Since the oid_arg2 field of struct sysctl_oid is not wide
enough to hold a long, the SYSCTL_LONG() macro has been modified to only
support exporting long variables by pointer instead of by value.
Reviewed by: bde
"I've been having a problem running the patches [committed to current]
installed with the COMPAT_LINUX_THREADS option along
with the VM_STACK patches I did. I'm not sure what
the problem is, since it seemed to work before.
In any event, the attached patch fixes the problem for
me. While I've had no report of problems from anyone
else, possibly it would be wise to commit the patch
until the problem is found.
Also, there was some left-over junk in the linux_misc.c
file from some earlier work I did. The attached patch
cleans that up too."
Submitted by: "Richard Seaman, Jr." <dick@tar.com>
in cyopen() were done in a different order than in sioopen(), partly
to (ab)use a side effect of comparam() and partly because I didn't
understand what the reset was doing (it flushes the fifos). This
turned out to be more than a cosmetic problem. Flushing the fifos
quite late is good for discarding input that arrived while the line
state was being initialized, and in the cy driver it also seems to
reduce a problem with input that arrived long ago during the previous
close (the UART loses sync too easily and for too long).
merge). This fixes at least hanging in revoke(2) when a somewhat
active slave pty is revoked. The hang made the window for the
null pointer bug in ufsspec_{read,write} much larger.
There are many other bugs in this area (revoke of an active fifo
at best leaks memory...).
may be revoked, so vnop routines must be careful about accessing
the vnode if they may have blocked.
Fixed marking for update after successfully reading or writing 0
bytes. In this case, POSIX.1 specifies marking if and only if the
requested count is nonzero, but rev.1.86 never marked.
change the original code but add an extra option "ALI_V" to check the
precise IDE port.(especially, secondary) Use the same option "ALI_V" on
the kernel config file to prevent generic DMA check causes wrong result.
(It seems buggy even on PIIX4 chipset, and I don't know when this bug start)
Should I add the option "ALI_V" into /sys/i386/conf/LINT ?
they use the same value in the VID register.
PR kern/9137: Matrox Mystique chip name typo error
Submitted by: Alex D. Chen <dhchen@Canvas.dorm7.nccu.edu.tw>
#include <ieeefp.h>
to access these functions instead of the i386 specific
#include <machine/floatingpoint.h>
Submitted by: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
will) get set for the devices that don't actually support
reserve/release (so we don't keep trying it).
Add softc storage and manage storing last I/O and CTL
commands that had errors (for correlative purposes).
In saclose clear the 'MOUNTED' bit if we either rewind or
unload (yes, this shouldn't be necessary since the next open
should catch whether a tape change occurred, but I'm having
some questions about that actually working so this is
safer for the moment). Oh, forgot to mention in previous
commit messages that some of the failures particularly at
close time cause the tape to be ejected (for the sake
of safety)- all this prior to redoing the state machine
(which is in progress) which will try and handle this better.
Complete the addition of the setmark support
(from Martin.Birgmeier@aon.at).
object are not page aligned). This should fix the mount_msdos panic after a
failed attemp to mount as ffs.
Reviewed By: Matthew Dillon <dillon@apollo.backplane.com>
Archie Cobbs <archie@whistle.com>
Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
capabilities are: AF, AB, cm, ho, me, cd. The code is hidden behind
-DTERM_EMU - should it cause any problems, you can remove this define
to get back the old behaviour.
You'll find some examples how to use it in src/share/examples/bootforth.
Reviewed by: jkh
there does not seem to be a problem with this.
PR: kern/8732
Analysis by: David G Andersen <danderse@cs.utah.edu>
Tested by: Alfred Perlstein <bright@hotjobs.com>
performed all sorts of sanity checks. The FreeBSD linux emulator returns
EINVAL in such a case.
Allowing signal 0 to be passed to kill will result in compatible behaviour.
PR: 9082
Submitted by: Marcel Moolenaar <marcel@scc.nl>
ethernet driver.
The BUGS section is still impressive, but the driver seems to work for
me now. Disclaimer: i haven't been able to test this under -current
so far (but it compiles, and the notebook it's intended for can now be
updated to -current more easy than before). Don't be afraid of the
many #ifdefs on __FreeBSD_version in the imported file; i want them in
the repository on the vendor-branch so other people can also manually
integrate it into older systems. I'll clean it up on the -current
branch in a followup commit. The vendor-banch version right now
supports systems back to 2.2R.
This driver should be layered upon ppc(4), but i currently have no
idea how to do this.
Eventually i'll further develop the driver to also support the more
modern RTL 8012 success, which seems to be present in a number of
cheap pocket ethernet adapters these days. Right now, i doubt it will
run with the 8012 without any changes.
Finally a big Thanks! to RealTek for promptly providing me with
documentation and with the source code for the 8012 pocket driver upon
request. I wish all vendors were that cooperative!.
linker sets don't work and thus neither does the kernel.
This should stop being a problem with an improved linker set mechanism in
the pipeline (see the bootloader) but for now this has to stay like this.
written even it the tape was opened readonly- 2 botches in deferred error
handling for FIXED LENGTH mode which caused panic && hand resp.). Fixed
a memory leak in sa_mount.
2) Fixed an annoying bug when turning of compression to actually reflect
this for future status calls.
3) Implement the MTIOCERRSTAT call where latched control and I/O residuals
and sense data are returned to the application asking for them.
This has the useful side-effect of ensuring that opt_smp.h is
always generated, so we can assume it will always be available.
Prompted by: Andrew Gallatin <gallatin@cs.duke.edu>
SCSI) the data returned for latched residual and error statistics.
Reserve space for LOG SENSE data which we'll get later. This area
in transition as the HP TapeAlert initiative is looked at.
The optimisation of only waiting before issuing new commands is
obviously invalid in general and it caused many errors in NIST-PCTS.
I think the errors were mostly for characters sent with the wrong
parity, etc., after a half complete tcsetattr().
Use microtime() instead of a magic loop count to limit the wait.
The wait is a busy-wait :-( and normally takes about 500 usec.
AcerLabs Aladdin-V. It makes the PCI probing work when system booting. I
will try to merge some additional funtion(i.e. wdc1 problem cause tons of
PR appear :<) ASAP if I could.
Remind me if something wrong after committing, thanks!
The Winbond chip always includes the CRC with every received frame,
and I can't find anything in the Winbond manual that indicates you can
program it not to do this.
Submitted by: "Richard Seaman, Jr." <lists@tar.com>
Obtained from: linux :-)
Code to allow Linux Threads to run under FreeBSD.
By default not enabled
This code is dependent on the conditional
COMPAT_LINUX_THREADS (suggested by Garret)
This is not yet a 'real' option but will be within some number of hours.
most of them).
Many thanks to Kevin Van Maren for the work here, Intel for lending us
a 450NX system to work this out on, and several other folks for testing
the patches. See the PR for an extensive discussion of the nature of
the problem and resolution.
PR: kern/8928
Submitted by: Kevin Van Maren <vanmaren@fast.cs.utah.edu>
- created internal names for fixed-size integral types, like __int32_t. They
will be used to make several headers self-sufficient.
- <stdlib.h> don't include <machine/types.h> anymore.
- created <sys/inttypes.h>, which can be used as <inttypes.h>.
- declaration of uoff_t and ufs_daddr_t moved to <sys/types.h>.
Reviewed by: bde
0x02000000. This error was causing the chip to always include the
ethernet CRC along with every received frame (the driver turns on
PN_NETCFG_NO_RXCRC, but it was frobbing the wrong bit).
almost works properly. Unfortunately, there is no way to flush
the rx fifo without resetting the channel, which also flushes the
tx fifo. We avoid resetting even when both fifos need to be flushed,
since resetting seems to cause the rx to lose sync if it is done
while data is arriving.
Reminded by: NIST-PCTS
Attempt to determine (at mount time if not done so already) via density code
whether a device should default to fixed mode or not. Attempts to set to
variable that fail will cause fixed to be selected.
Similarly, the '2 filemarks at EOM' quirk is now determined (or attempted to
be determined) via density code. Some as yet not entirely tested code for
coping with 2FM@EOD position is now also in place.
hardware is interrupt-driven to a fault and sending a BREAK requires
mode switching. Always running in the BREAK-capable mode as in PR 8318
would double the overhead for sending \0's.
Reminded by: PR 8318
Use the host message loop for any unknown message types instead of performing
a reject message in the sequencer. Pass reject messages to the host
message loop too which frees up a sequencer interrupt type slot.
Default to issuing a bus reset if initiator mode is enabled. It seems
that the reset scsi bus bit is not defined in the same location for
all aic78xx BIOSes, so attempting to honor this setting will have to
wait until I get more information on how to detect it.
Nuke some unused variables.
aborted prior to disabling our lun. This requires a second set of
links since we use the ones in the ccb_hdr during normal operations.
Nuke some unused variables.
and out of kernel address space (via the pass(4) and xpt(4) peripheral
drivers) to 64K (DFLTPHYS). Some controllers, like the Adaptec 1542,
don't support more than 64K transactions.
We plan on eventually having the capability of limiting this size based
on min(MAXPHYS, controller max), but since that capability isn't here yet,
limit things to the lowest common denominator.
Not tested on the if_sr, if_cx and if_ar drivers, but
expected to work just the same as it used to.
Any users of these drivers (or even better: donors
of hardware for them) please contact phk@freebsd.org
so we can test the next batch of changes to if_sppp.
reporting since this past summer. (I think Daniel O'Conner was the first.)
The problem appears to have been something like this:
- cdda2wav by default passes in a buffer that is close to the 128K MAXPHYS
limit.
- many times, the buffer is not page aligned
- vmapbuf() truncates the address, so that it is page aligned
- that causes the total size of the buffer to be greater than MAXPHYS,
which of course is a bad thing.
Here's a quote from the PR (kern/9067):
==================
In particular, note bp->b_bufsize = 0x0001f950 and bp->b_data = 0xf2219960
(which does not start on a page boundary). vunmapbuf() loops through all
the pages without any difficulty until addr reaches 0xf2239000, and then
the panic occurs. This seems to indicate that we are exceeding MAXPHYS
since we actually started from the middle of a page (the data is being
transfered to a non page aligned location).
To complete the description, note that the system call originates from
ReadCddaMMC12() (in scsi_cmds.c of cdda2wav) with a request to read 55
audio sectors of 2352 bytes (which is calculated to fall under MAXPHYS).
This in turn ends up calling scsi_send() (in scsi-bsd.c) which calls
cam_fill_csio() and cam_send_ccb(). This results in a CAMIOCOMMAND ioctl
with a ccb function code of XPT_SCSI_IO.
==================
The fix is to change the size check in cam_periph_mapmem() so that it is
like the one in minphys(). In particular, it is something like:
if ((buffer_length + (buf_ptr & PAGE_MASK)) > MAXPHYS)
buffer is too big
My fix is based on the one in the PR, but I cleaned up a fair number of
things in cam_periph_mapmem(). The checks for each buffer to be mapped
are now in a separate loop from the actual mapping operation. With the new
arrangement, we don't have to bother with unmapping any previously mapped
buffers if one of the checks fails.
Many thanks to James Liu for tracking this down. I'd appreciate it if some
vm-savvy folks would look this over. I believe this fix is correct, but I
could be wrong.
PR: kern/9067 (also, kern/8112)
Reviewed by: gibbs
Submitted by: "James T. Liu" <jtliu@phlebas.rockefeller.edu>
adjusted related casts to match (only in the kernel in this commit).
The pointer was only wanted in one place in kern_exec.c. Applications
should use the kern.ps_strings sysctl instead of PS_STRINGS, so they
shouldn't notice this change.
across the kernel -> application interface, and for the one sysctl where
they were passed and actually used (kern.ps_strings), the applications
want addresses represented as u_longs anyway (the other sysctl that
passed them, kern.usrstack, has never been used).
Agreed to by: dfr, phk
as well as several functional additions.
(1) dot3 MIB support.
(2) if_media selection method support.
(3) bridge support.
(4) new boards support. Supported boards are as follows.
[PC/AT]
* Fujitsu FMV-180 series
* Allied-Telesis RE2000 series
* Allied-Telesyn AT1700 series
* Gateway Communications G/Ether series
* UB networks Access/PC ISA series
* TDK/LANX LAC-AX series
* ICL EtherTeam16i series
* RATOC REX-5586/5587
[PC-98]
* Allied-Telesis RE1000 series
* Allied-Telesis RE1000Plus/ME1500 series
* Contec C-NET(9N)E series
* Contec C-NET(98)P2 series
* UB networks Access/PC N98C+ series
* TDK/LANX LAC-98 series(not tested)
Submitted by: seki@sysrap.cs.fujitsu.co.jp (Masahiro Sekiguchi) and
chi@bd.mbn.or.jp (Chiharu Shibata)
in rev.1.30 (just before FreeBSD-1.1R) to almost match corresponding
breakage in FreeBSD-1.x's diskerr(). FreeBSD-2.x's diskerr() never
had the breakage.
in target mode, but we are not completing the command.
Use a template of allowed bus arbitration phases to selectively and
dynamically enable/disable initiator or target (re)selection.
Properly handle timeouts for target role transactions - just go to the
bus free state and report the error to the peripheral driver.
Checkpoint support for the XPT_ABORT_CCB function code. This currently
handles the accept tio and immediate notify ccb types, but does not
handle the continue target I/O or SCSI I/O ccb types. This is enough
to handle dynamic target enable/disable events.
Clean up the SCSI reset code so that we perform at most 1 SCSI bus
reset at initialization, the reset requested by the XPT layer.
level so they can be reclaimed before attempting to disable our lun.
Correctly free descriptors. Add periph locking and spl protection
around open and close.
pointed this out, but I've not seen a manifestation of this.
o Check against 0x00 as well as 0xff for geometry register, as some clone
cards don't return 0xff. Vadim Mikhailov pointed this out in PR
8743 for his Dell SCSI Array controller working in AHA-1540
emulation mode. Note that this test is likely to go away in the
future in favor of a better one Justin has recommended.
memory address space rather than IO space.. reflect this when looking for the
interface revision register.
If this is not true for them all then we probably need some smarter code.
