Clean up some low level bootstrap code:
- stop using the evil 'struct trapframe' argument for mi_startup()
(formerly main()). There are much better ways of doing it.
- do not use prepare_usermode() - setregs() in execve() will do it
all for us as long as the p_md.md_regs pointer is set. (which is
now done in machdep.c rather than init_main.c. The Alpha port did it
this way all along and is much cleaner).
- collect all the magic %cr0 etc register settings into one place and
have the AP's call that instead of using magic numbers (!!) that keep
changing over and over again.
- Make it safe to call kthread_create() earlier, including during the
device probe sequence. It doesn't need the callback mechanism that
NetBSD's version uses.
- kthreads created this way are root-less as they exist before the root
filesystem is mounted. init(1) is set up so that it aquires the root
pointers prior to running. If other kthreads want filesystem acccess
we can make this code more generic.
- set all threads start times once we have decided what time it is.
- init uses a trampoline rather than the evil prepare_usermode() hack.
- kern_descrip.c has a couple of tweaks to deal with forking when there
is no rootdir or cwd etc.
- adjust the early SYSINIT() sequence so that a few prereqisites are in
place. eg: make sure the run queue is initialized before doing forks.
With this, the USB code can easily create a kthread to do the device
tree discovery. (I have tested it, it works nicely).
There are still some open issues before this is truely useful.
- tsleep() does not like working before the clock is running. It
sort-of tries to spin wait, but it can do more useful things now.
- stopping a kthread in kld code at unload time is "interesting" but
we have a solution for that.
The Alpha code needs no changes for this. It already uses pretty much the
same strategies, but a little cleaner.
understand exactly what it is about SMPng that tickles this bug. What I
do know is that the foo_init() routine in most drivers is often called
twice when an interface is brought up. One time is due to the ifconfig(8)
command calling the SIOCSIFFLAGS ioctl to set the IFF_UP flag, and another
is probably due to the kernel calling ifp->if_init at some point. In any
case, the SMPng changes seem to affect the timing of these two events in
such a way that there is a significant delay before any packets are sent
onto the wire after the interface is first brought up. This manifested
itself locally as an SMPng test machine which failed to obtain an address
via DHCP when booting up.
It looks like the second call to fxp_init() is happening faster now than
it did before, and I think it catches the chip while it's in the process
of dealing with the configuration command from the first call. Whatever
the case, a FXP_CSR_SCB_CNA interrupt event is now generated shortly after
the second fxp_init() call. (This interrupt is apparently never generated
by a non-SMPng kernel, so nobody noticed.)
There are two problems with this: first, fxp_intr() does not handle the
FXP_CSR_SCB_CNA interrupt event (it never tests for it or does anything
to deal with it), and second, the meaning of FXP_CSR_SCB_CNA is not
documented in the driver. (Apparently it means "command unit not active.")
Bad coder. No biscuit.
The fix is to have the FXP_CSR_SCB_CNA interrupt handled just like the
FXP_SCB_STATACK_CXTNO interrupt. This prevents the state machine for
the configuration/RX filter programming stuff from getting wedged for
several seconds and preventing packet transmission.
Noticed by: jhb
This is done by misusing the device minor a bit to encode the
track no there.
So to read track #4 just use /dev/acdNt4 where N is the device #.
The driver no automatically sets the blocksize (sectorsize) to
what the track is set to in the TOC.
This has the nice effect that you can now rip audioi tracks
by simply doing:
dd if=/dev/acdNt2 of=audiotrack2.raw bs=2352
it cant be much simpler than that :)
NOTE: the original acdNa & acdNc device still work as usual,
except the blocksize is set according to track0.
- stop using the evil 'struct trapframe' argument for mi_startup()
(formerly main()). There are much better ways of doing it.
- do not use prepare_usermode() - setregs() in execve() will do it
all for us as long as the p_md.md_regs pointer is set. (which is
now done in machdep.c rather than init_main.c. The Alpha port did it
this way all along and is much cleaner).
- collect all the magic %cr0 etc register settings into one place and
have the AP's call that instead of using magic numbers (!!) that keep
changing over and over again.
- Make it safe to call kthread_create() earlier, including during the
device probe sequence. It doesn't need the callback mechanism that
NetBSD's version uses.
- kthreads created this way are root-less as they exist before the root
filesystem is mounted. init(1) is set up so that it aquires the root
pointers prior to running. If other kthreads want filesystem acccess
we can make this code more generic.
- set all threads start times once we have decided what time it is.
- init uses a trampoline rather than the evil prepare_usermode() hack.
- kern_descrip.c has a couple of tweaks to deal with forking when there
is no rootdir or cwd etc.
- adjust the early SYSINIT() sequence so that a few prereqisites are in
place. eg: make sure the run queue is initialized before doing forks.
With this, the USB code can easily create a kthread to do the device
tree discovery. (I have tested it, it works nicely).
There are still some open issues before this is truely useful.
- tsleep() does not like working before the clock is running. It
sort-of tries to spin wait, but it can do more useful things now.
- stopping a kthread in kld code at unload time is "interesting" but
we have a solution for that.
The Alpha code needs no changes for this. It already uses pretty much the
same strategies, but a little cleaner.
identifier to the DHCP server. Now you can check for this string
in your dhcp configuration to decide whether you will hand out a
lease to the client or not.
control field compression. The ng_ppp(4) node correctly follows this
rule. However, PPPoE is an exception: when doing PPPoE *all* frames
are sent with address and control field compression.
Alter this node's behavior so that when an outgoing frame is received,
any leading address and control field bytes are removed. This makes
this node compatible with ng_ppp(4).
memory space needed by the raylink driver (in progress, nearing
completion).
This is a minorly cleaned up diff from Duncan to help him reduce the
diffs from stock FreeBSD.
Submitted by: Duncan Barclay <dmlb@ragnet.demon.co.uk>
from the SCSI id it has. (this avoids the confusing umass-sim32 device. It
should have been umass-sim0 all along (there is only one), and if it is
spoken to as a SCSI device the sim should be umass32.
Make the rescan actually work. We need to fill in a target and lun wildcard
and not the SCSI id of the SIM.
Add a seatbelt.
position, channel 1's dma position register must be quiescent. So
the driver will spl, pause the DMA, delay a bit and hold as still as
possible while snapping the picture.
I'm sure there HAS to be a better way to do this, but if there is, it's
not documented.
So far as I can tell, this fixes recording, which means the Solo is open
for business.
been done.
Don't allow multiple mount operations with MNT_UPDATE at the same
time on the same mount point. When the first mount operation
completed, MNT_UPDATE was cleared in the mount structure, causing
the second to complete as if it was a no-update mount operation
with the following bad side effects:
- mount structure inserted multiple times onto the mountlist
- vp->v_mountedhere incorrectly set, causing next namei
operation walking into the mountpoint to crash with
a locking against myself panic.
Plug a vnode leak in case vinvalbuf fails.
This allows ffs_fsync() to break out of a loop that might otherwise
be infinite on kernels compiled without the SOFTUPDATES option.
The observed symptom was a system hang at the first unmount attempt.
to be obeying the original spec as to what the numeric value means.
Temperature flags are unaffected- these are still the 'pseudo-thermometers'
and overtemp/undertemp warnings will be caught and translated to SES objects
here.
PR: 20475
extended attribute name used to store capabilities for binaries in
FFS.
o Uncomment CAP_SETPCAP because, unfortunately, it is useful when
developing and testing, as well as in practice for a system not
fully capability-enabled.
o Synch up prototypes with the implementation, reducing diffs and
making the patches for capabilities more accessible and less
dastardly.
Obtained from: TrustedBSD Project
and VOP_SETEXTATTR to simplify calling from in-kernel consumers,
such as capability code. Both accept a vnode (optionally locked,
with ioflg to indicate that), attribute name, and a buffer + buffer
length in UIO_SYSSPACE. Both authorize the call as a kernel request,
with cred set to NULL for the actual VOP_ calls.
Obtained from: TrustedBSD Project
related patches. These include:
* Mode page editting can be scripted. This involves two
things: first, if stdin is not a tty, changes are read from
stdin rather than invoking $EDITOR. Second, and more
importantly, not all modepage entries must be included in the
change set. This means that camcontrol can now gracefully handle
more intrusive editting from the $EDITOR, including removal or
rearrangement of lines. It also means that you can do stuff
like:
# echo "WCE: 1" | camcontrol modepage da3 -m 8 -e
# newfs /dev/da3
# echo "WCE: 0" | camcontrol modepage da3 -m 8 -e
* Range-checking on user-supplied input values. modeedit.c now
uses the field width specifiers to determine the maximum
allowable value for a field. If the user enters a value larger
than the maximum, it clips the value to the max and warns the
user. This also involved patching cam_cmdparse.c to be more
consistent with regards to the "count" parameter to arg_put
(previously is was the length of strings and 1 for all integral
types). The cam_cdbparse(3) man page was also updated to reflect
the revised semantics.
* In the process, I removed the 64 entry limit on mode pages (not
that we were even close to hitting that limit). This was a nice
side-effect of the other changes.
* Technically, the new mode editting functionality allows editting
of character array entries in mode pages (type 'c' or 'z'),
however since buff_encode doesn't grok them it is currently
useless.
* Camcontrol gained two new options related to mode pages: -l and
-b. The former lists all available mode pages for a given
device. The latter forces mode page display in binary format
(the default when no mode page definition was found in
scsi_modes).
* Added support for mode page names to scsi_modes. Allows names to
be displayed alongside mode numbers in the mode page
listing. Updated scsi_modes to use the new functionality. This
also adds the semicolon into the scsi_modes syntax as an
optional mode page definition terminator. This is needed to name
pages without providing a page format definition.
* Updated scsi_all.h to include a structure describing mode page
headers.
* Added $FreeBSD$ line to scsi_modes.
Inspired by: dwhite
Reviewed by: ken
passing a zero-valued timeout, the code would always sleep for one tick.
Change code to avoid calling tsleep if we have no intention of sleeping.
Bring in bugfix from sys_select.c, r1.60 which also applies here.
Modify error handling slightly; passing in an invalid fd will now result
in EBADF returned in the eventlist, while an attempt to change a knote
which does not exist will result in ENOENT being returned. Previously
such attempts would fail silently without notification.
Pointed out by: nicolas.leonard@animaths.com
Rick Reed (rr@yahoo-inc.com)
With more than 1 AP present, an AP could fail to properly release
the mp lock before waiting for smp_started to become nonzero.
With early startup of APs, the BSP could fail to properly release
the mp lock before waiting for smp_started to become nonzero.
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...
panicing and return a status so that we can decide whether to drop
into DDB or panic. If the status from isa_nmi is true, panic the
kernel based on machdep.panic_on_nmi, otherwise if DDB is
enabled, drop to DDB based on machdep.ddb_on_nmi.
Reviewed by: peter, phk
Don't allow cpu entries in the MP table to contain APIC IDs out of range.
Don't write outside array boundaries if an IO APIC entry in the MP table
contains an APIC ID out of range.
Assign APIC IDs for all IO APICs according to section 3.6.6 in the
Intel MP spec:
- If the current APIC ID on an IO APIC doesn't conflict with other
IO APICs or CPUs, that APIC ID should be used. The copy of the MP
table must be updated if the corresponding APIC ID in the MP table
is different.
- If the current APIC ID was in conflict with other units, the
corresponding APIC ID specified in the MP table is checked for conflict.
- If a conflict is still found then fall back to using a new unique ID.
The copy of the MP table must be updated.
- IDs out of range is considered to be in conflict.
During these operations, the IO_TO_ID array cannot be used, since any
conflict would have caused information loss. The array is then corrected,
since all APIC ID conflicts should have been resolved.
PR: 20312, 18919
to 0x600 via a 'rep movsw'. Once that was done, %cx was zero, so we could
simply use 'movb' to update the lower byte of %cx in preparation for
zeroing out the fake partition entry used to boot to other drives via F5.
Well, in the new boot0, we don't actually relocate ourselves, instead it
is easier to create the fake partition entry first and then just use it to
get the BIOS to load all of boot0 into memory at 0x600. However, since we
aren't doing the relocate code anymore, we don't know that %cx == 0 when
we hit the 'movb' to setup %cx for clearning the fake partition entry.
Thus, if %ch != 0 when the BIOS started boot0, then it would end up zeroing
a lot more memory than just 8 words. The solution is to do a word move of
$8 into %cx.
Debugging help from: David Wolfskill <dhw@whistle.com>
display control by apm -d.
- Remove APM_DEBUG to avoid re-build kernel with such a unspported optioin.
- Introduce new denug flag `debug.apm_debug' which can be controlled by
sysctl interface and loader by setting like "debug.apm_debug=1", you
will get debug messages from APM driver.
- Add some enhancements from linux on display control by apm -d. I'm
expecting that we can see some improvements on some laptops where
apm -d doesn't work correctly so far.
Reviewed by: -mobile and -current folks (no objection)
Suggested by: Susumu WAKABAYASHI <susumu@wakabaya.net>
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.
<stand.h>. Also, since bcache_strategy() used to not have a prototype,
arcdisk happily called bcache_strategy() with 6 parameters instead of 7,
leaving out the disk unit number, which is the 2nd parameter. Add in the
unit number to the bcache_strategy() call to fix this.
When this happens, we know for sure that the packet data was not
received by the peer. Therefore, back out any advancing of the
transmit sequence number so that we send the same data the next
time we transmit a packet, avoiding a guaranteed missed packet and
its resulting TCP transmit slowdown.
In most systems ip_output() probably never returns an error, and
so this problem is never seen. However, it is more likely to occur
with device drivers having short output queues (causing ENOBUFS to
be returned when they are full), not to mention low memory situations.
Moreover, because of this problem writers of slow devices were
required to make an unfortunate choice between (a) having a relatively
short output queue (with low latency but low TCP bandwidth because
of this problem) or (b) a long output queue (with high latency and
high TCP bandwidth). In my particular application (ISDN) it took
an output queue equal to ~5 seconds of transmission to avoid ENOBUFS.
A more reasonable output queue of 0.5 seconds resulted in only about
50% TCP throughput. With this patch full throughput was restored in
the latter case.
Reviewed by: freebsd-net
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.
usb, all in usb.ko. uhub depends on usb. The bug was that the preload
processing only adds a module to the list once it's internal dependencies
are resolved... Since it was not "seeing" the internal usb module it
believed that uhub had a missing dependency.
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.
sector 0 of a disk and boot0.5 is the `boot selector' which starts
from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock
of a slice.
The boot manager stuff was developed by me (kato) with Borland C++,
and then, translated into bcc in the ports collection by Nokubi-san.
After that, boot0 has been translated into gas with the .code16
directive by Takahashi-san (nyan) and boot0.5 has been rewritten in
gas by me.
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.
gcc's internal exit() prototypes and the (futile) hackery that we did to
try and avoid warnings. main() was renamed for similar reasons.
Remove an exit related hack from makesyscalls.sh.
!VFS_AIO case. Lots of things have hooks into here (kqueue, exit(),
sockets, etc), I elected to keep the external interfaces the same
rather than spread more #ifdefs around the kernel.
"kern/sys_generic.c:358: warning: cast discards qualifiers from pointer
target type"
The idea for using the uintptr_t intermediate cast for de-constifying
a pointer was hinted at by bde some time ago.
with an error condition such as EINTR, EWOULDBLOCK, and ERESTART,
are reported to the application, not silently conceal. This
behavior was copied from the {read,write}v() syscalls, and is
appropriate there but not here.
o Correct a bug in extattr_delete() wherein the LOCKLEAF flag is
passed to the wrong argument in namei(), resulting in some
unexpected errors during name resolution, and passing in an unlocked
vnode.
Obtained from: TrustedBSD Project
gif/faith/stf moved to 0xfN entries, since their previous location
is allocated to some other interfaces.
Also add the IFT_PVC, which is the ATM PVC subinterface from ALTQ.
This also syncs us up a bit to NetBSD again.
This change requires a total recompilation of all kmem users, as
itojun told me.
Next in line is synching to the IANI SMI list.
Approved by: itojun
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.
is not desired, then the user can register an EV_SIGNAL filter to
explicitly catch a signal event.
Change requested by: jayanth, ps, peter
"Why is kevent non-restartable after a signal?"
