currently operating in a tagged mode. The SIM driver should determine
if a device is in tag mode by looking at the CAM_TAG_ACTION_VALID flag
in the ccb header. If the flag is set, the tag_action field is either
a SCSI II tag message (simple, ordered, head) or CAM_TAG_ACTION_NONE
to specify that no tagging should be performed.
bogus comment to proper place.
This should fix the hangs people are seeing under very heavy load, at
least it does for me. Please let me know if you continue to have
problems.
tested both in the kernel and in userland. Also, fix a couple of printf
warnings that show up when CAMDEBUG is defined.
Reviewed by: imp
Partially submitted by: imp
hung up when you send tags to them too quickly. (CAM is able to recover
from the problem, but this just avoids it altogether.)
Reviewed by: gibbs
Reported by: Bret Ford <bford@uop.cs.uop.edu>
and: Martin Renters <martin@tdc.on.ca>
release goes out the door. We know there's a bug in the devstat
implementation in the wd driver, but bde and msmith haven't been able to
fix it yet.
So, disable the printf to avoid confusing/worrying people.
Suggested by: msmith
independent elf loader and have access to kld modules. Jordan and I were
not sure how to create boot floppies, and the things we tried just made
SRM laugh in our faces - but it was upset at boot1 which was not touched
by these changes. Essentially this has been untested. :-(
What this does is to steal the last three slots from the nine spare longs
in the bootinfo_v1 struct to pass the module base pointer through.
The startup code now to set up and fills in the module and environment
structures, hopefully close enough to the i386 layout to be able to use
the same kernel code. We now pass though the updated end of the kernel
space used, rather than _end. (like the i386).
If this does not work, it needs to be beaten into shape pronto. Otherwise
it should be backed out before 3.0.
Pre-approved in principle by: dfr
one error recovery action oustanding for a given peripheral.
This is bad for several reasons. The first problem is that the error
recovery actions would likely be to fix the same problem. (e.g., we
queue 5 CCBs to a disk, and the first one comes back with 0x04,0x02. We
start error recovery, and the second one comes back with the same status.
Then the third one comes back, and so on. Each one causes the drive to get
nailed with a start unit, when we really only need one.)
The other problem is that we only have space to store one CCB while we're
doing error recovery. The subsequent error recovery actions that got
started were over-writing the CCBs from previous error recovery actions,
but we still tried to call the done routine N times for N error recovery
actions. Each call to dadone() was done with the same CCB, though. So on
the second one, we got a "biodone: buffer not busy" panic, since the buffer
in question had already been through biodone().
In any case, this fixes things so that any any given time, there's only one
error recovery action outstanding for any given peripheral driver.
Reviewed by: gibbs
Reported by: Philippe Regnauld <regnauld@deepo.prosa.dk>
[ Philippe wins the "bug finder of the week" award ]
sequence of things:
- spin up a disk
- send an async event to refresh the inquiry data
- run through xpt_scan_lun() to re-probe the device
- eventually finish the probe, but panic in xpt_done() because the
periph pointer wasn't set.
Reviewed by: gibbs
Reported by: Philippe Regnauld <regnauld@deepo.prosa.dk>
but when i_effnlink was added to support soft updates, there was only
room for 4 spares. The number of spares was not reduced, so the inode
size became 260 (on i386's), or 512 after rounding up by malloc().
Use one spare field in `struct dinode' instead of the 5th spare field
in the inode and reduced to 4 spares in the inode so that the size is
256 again.
Changed the types of the spares in the inode from int to u_int32_t
so that the inode size has more chance of being <= 256 under other
arches, and downdated ext2fs to match (it was broken to use ints
before rev.1.1).
