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).
1) The vnode pager wasn't properly tracking the file size due to
"size" being page rounded in some cases and not in others.
This sometimes resulted in corrupted files. First noticed by
Terry Lambert.
Fixed by changing the "size" pager_alloc parameter to be a 64bit
byte value (as opposed to a 32bit page index) and changing the
pagers and their callers to deal with this properly.
2) Fixed a bogus type cast in round_page() and trunc_page() that
caused some 64bit offsets and sizes to be scrambled. Removing
the cast required adding casts at a few dozen callers.
There may be problems with other bogus casts in close-by
macros. A quick check seemed to indicate that those were okay,
however.
