| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Verified by: md5
|
|
|
|
| |
Spotted by: FlexeLint.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and predictable way, and I apologize if I have gotten it wrong anywhere,
getting prior review on a patch like this is not feasible, considering
the number of people involved and hardware availability etc.)
If struct disklabel is the messenger: kill the messenger.
Inside struct disk we had a struct disklabel which disk drivers used to
communicate certain metrics to the disklayer above (GEOM or the disk
mini-layer). This commit changes this communication to use four
explicit fields instead.
Amongst the benefits is that the fields do not get overwritten by
wrong or bogus on-disk disklabels.
Once that is clear, <sys/disk.h> which is included in the drivers
no longer need to pull <sys/disklabel.h> and <sys/diskslice.h> in,
the few places that needs them, have gotten explicit #includes for
them.
The disklabel inside struct disk is now only for internal use in
the disk mini-layer, so instead of embedding it, we malloc it as
we need it.
This concludes (modulus any mistakes) the series of disklabel related
commits.
I belive it all amounts to a NOP for all the rest of you :-)
Sponsored by: DARPA & NAI Labs.
|
| |
|
|
|
|
| |
again.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
|
|
|
|
|
|
|
|
|
| |
the upcoming 7.4 family (7xxx controllers).
- improved error reporting and handling
- more diagnostic output
- add extra command packet definitions
- merge sources again with -stable
|
|
|
|
| |
TWE_SHUTDOWN_NOTIFICATION is defined, the other two are never used.
|
|
|
|
| |
also don't use ANSI string concatenation.
|
|
|
|
| |
Reviewed by: peter
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
|
|
|
|
|
| |
Inspired by: OpenBSD
MFC After: 1 week
|
|
|
|
|
|
|
|
| |
- Rework of twe_report_request to use the command status value rather
than the flags register. (Joel Jacobson @ 3ware)
- Update to match some changes in -current vs. stable.
MFC in: 1 week
|
|
|
|
| |
instead of the underlying drivers.
|
|
|
|
|
|
|
| |
Move duplicate code for printing the status of the dump and checking
for abort into a separate function.
Pointy hat to: me
|
|
|
|
|
|
|
| |
If any other key is pressed, print a message stating that control-c
is how to abort.
Reviewed by: peter
|
|
|
|
|
|
|
| |
I could find. I have no doubt missed a couple.
Interrupt entropy harvesting is still conditional on the
kern.random.sys.harvest_interrupt sysctl.
|
|
|
|
| |
Submitted by: Joel Jacobson <jake@3ware.com>
|
| |
|
|
|
|
|
|
|
| |
- standardise error reporting for commands
- simplify the driver-to-controller bio transfer
- add bio in/out accounting
- correctly preserve the command ID in twe_ioctl (thanks to joel@3ware)
|
|
|
|
|
| |
put the bio back, otherwise we'll drop it when we bail. This was
causing bio lossage under load, leading to eventual system lockup.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Layout reorganisation to enhance portability. The driver now has
a relatively MI 'core' and a FreeBSD-specific layer over the top.
Since the NetBSD people have already done their own port, this is
largely just to help me with the BSD/OS port.
- Request ID allocation changed to improve performance (I'd been
considering switching to this approach after having failed to come
up with a better way to dynamically allocate request IDs, and seeing
Andy Doran use it in the NetBSD port of the driver convinced me
that I was wasting my time doing it any other way). Now we just
allocate all the requests up front.
- Maximum request count bumped back to 255 after characterisation
of a firmware issue (off-by-one causing it to crash with 256
outstanding commands).
- Control interface implemented. This allows 3ware's '3dm' utility to
talk to the controller. 3dm will be available from 3ware shortly.
- Controller soft-reset feature added; if the controller signals a
firmware or protocol error, the controller will be reset and all
outstanding commands will be retried.
|
| |
|
|
|
|
|
| |
to 50. This has been reported to avoid the problems that many users have
been experiencing with crashing the card firmware during rebuilds.
|
|
|
|
| |
drive is at, so don't print the 'unknown' value, just say nothing.
|
|
controllers.
|