be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
caused by bad interaction of sbp2_free() and sbp2_abort().
sbp2_abort() requires that its argument ORB is on the
"active" list, and it puts it onto the freelist - sometimes.
So we had 2 causes of corruption:
-removing the ORB from a list which it isn't on
-free()ing recycleable items on the ORB freelist
-minor cosmetics
various orders depending how the upper level driver is flushing it's queue's.
This prevents the deadlocks I was seeing before with >8k writes.
XXX: Still not completely there as > 64k copies trigger bugs and the page
table support still needs to be written to break those down.
accept ranges as well as single addresses. Still need to go through any key
areas and remove the malloc's and replace these with some sort of pooling
instead.
1. Reduce debugging level to sane levels
2. Fix bugs in alloc_data_map related to allocing whole bytes of bitmap at
a time.
At this point the driver is functional. It talks to a local drive here and
can label/newfs. Performance is...lacking at the moment as its chewing cpu
heavily (probably due to the number of memcpy's) and will be the next area
attacked.
support up to the max ohci descriptor segments. Then attempt to fill it in
via a load. Use the number of segments filled in as the basis for figuring
out how many descriptors to supply to the ohci DMA engine.
XXX: Still needs to account for requests which because of splits may overflow
the 6 dma descriptors available today. For now this fixes cases where a
single 512 byte write was getting split into 2 dma segments from 1 incoming
iov request
isochronous reception routine for IEEE 1394 OHCI (fwohci). The
transmission part is under construction.
The minimum configuration options for this feature are:
# IEEE 1394 (i.LINK)
fwohci* at pci? dev ? function ?
pseudo-device fwiso 1
