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
1. Clean up some debugging and trigger some on only extreme debugging needs
2. Comment alloc data mapping a bit better and fix some of the bugs here
(note..there still are some so for now the free method is never called while
I track these down)
3. Fix the copying logic in data_resp. It was calculating negative offsets
which blew up memcpy.
At this point I can probe, inquire and get through the findroot steps of a
boot:
sd0 at scsibus0 target 0 lun 0: <Maxtor, 1394 storage, 60> disk fixed
sd0: mode sense (4) returned nonsense; using fictitious geometry
sd0: 76293 MB, 76293 cyl, 64 head, 32 sec, 512 bytes/sect x 156250000 sectors
sd0: mode sense (4) returned nonsense; using fictitious geometry
sd0: no disk label
findroot: can't open dev sd0a (6)
NOTE: This will panic my machine right now with a simple disklabel -r sd0.
Also, since the free mappings routines are if (0)'d out at the moment do not
use this code for anything except experiments and then only on a machine
you don't mind panic'ing.
Fixing the mapping routines will be the next step and then finally chasing
down the proper mode sense these drives understand.
There are a number of issues here for anyone trying to use this today:
1. On my test drive the command engine on the drive seems to stall after the
inquire is done. So the mode sense times out for a long time before
aborting. This obviously needs to be tracked down and fixed.
However it does do a proper inquire:
scsibus0 at sbpscsi0: 1 target, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <Maxtor, 1394 storage, 60> disk fixed
2. This code is quite ugly in places as debug code was added to test things.
Definitly needs cleanup/documention in places where it's using command
structures. The structure for alloc'ing orbs, running them through the
command engine and getting state back is mostly set but implementation needs
an overhaul in places.
3. For testing I use the following config options:
fwohci* at cardbus? dev ? function ? # IEEE1394 Controller
fw* at fwbus?
options FW_DEBUG
options FWNODE_DEBUG
options P1212_DEBUG
options SBP2_DEBUG
options SBPSCSI_DEBUG
fwnode* at fwbus?
sbpscsi* at fwnode?
scsibus* at sbpscsi?
Also, add unit location fields to the ROM image. The p1212 spec requires
unit locations if you have 2 or more unit directories which is the case for
ipv4 and ipv6 compiled into a kernel.
filling in unit location in the rom.
XXX: This all is really too welded together. The if_fw code should be
decoupled from this and simply be handed a method by which it can provide
the config rom back to the main code.
been tested on i386. It does not have any interface for useland to
get isochoronous stream. The isochoronous acquisition interface
should be determined.
- fwohci_arrq_input: Do not return if next packet is in the buffer,
or the next packet cannot be received until the next receive interrupt.
- fwohci_uid_collect: XXX change M_WAITOK to M_NOWAIT for now, since there is
no lock but only one instance must be allowed here.
split fwohci_uid_req() and retry to get uid.
XXX need timer to wait some moment between retries...
- Add DELAY(10) for wait loop.
- split fwohci_buf_stop() into _stop_tx() and _stop_rx() because receiver
should not be stopped at bus-reset.
- split fwohci_buf_input() into _input() and _input_ppb() to improve
performance slightly.
Clean up one bug in a DPRINTF in arrs_input which could panic on some packets.
Gut the ack/response functionality and clean it up so all packets get checked
correctly and the abuf struct isn't used once the ab_cb has happened (there
still could be ack packets waiting to be processed at that time).
Finally, add some documentation explaining read/write/inreg and their
purpose/argument calling.
my time shortage):
- Use 8 column for basic indent.
- Use 4 space for 2nd level indent.
- Use tab instead of 8 spaces.
- Don't put space before function call operator. That's unary operator.
- Wrap lines so that it fits in 80 columns.
Move interrupt routine to simply updating state flags and ack'ing interrupts
Move main processing into kthread
Change IPL level to IPL_BIO and try not to hold splbio very much if at all.
Add baseline support for attaching/detaching/updating fwnode's.
Start adding higher level API which isn't tied to if_fw/mbuf's
saves about 2.2MB under /usr/include/dev/. Discussed on tech-kern@
recently.
I HOPE to get the list right. The headers I left in are ones
used for MI tools and those whose usage I discovered by grep over tree sources.
Feel free to put needed includes back in if you encounter anything which
should not be removed from lists.
Use Global UID register as is, it should be initialized by firmware.
If it is not initialized (i.e. 0), try to read GUID ROM if exists.
On my VAIO PCG-N505AS, the version register says it implement GUID ROM,
but reading GUID ROM returns all zero bytes. I'm not sure where the bug is.
