(c) TNF
line from 4-clause UCB to 3-clause UCB license; in other words,
remove UCB's ad clause from the license TNF grants.
There is no point in TNF demanding that UCB's ad clause be followed
when even UCB doesn't demand it any longer.
Ok'd by board@ and agc@.
RAID5 sets with more than 3 drives. Still need to figure out why
the original changes were losing, but need the version in tree reliable
first!
Huge THANKS to Juergen Hannken-Illjes for helping track down
the changes that were causing the lossage.
code has copied the new kernel in place, so pass a copy of bootinfo
to the new kernel via "page tags".
Restructure the code to fill "page tags" to make it more generic and
more natural to use (especially in anticipation of ksyms support).
ExtremeRAID with NV cache) and "dumb" (3ware 6410) ld providers.
Instead, use the default buffer queue policy.
With the 3ware adapter, using the read priority strategy instead of FCFS,
for three extractions of pkgsrc, took 329 seconds instead of 331 -- but
with a dramatic improvement in perceived system response (latency for
I/O outside the main stream).
With the Mylex adapter, the improvement was dramatic: using read priority
instead of FCFS yielded an improvement from 381 seconds to 135 seconds!
There was a less-noticeable improvement in perceived latency as well.
The other disk drivers currently hard-wired to FCFS or another policy
should probably be changed as well.
leave 4 bytes for the Windows NT Drive Serial Number (DSN) at 440-443
(as mbr_sector.mbr_dsn).
Ensure that all the MBR & PBR code reserves space for mbr_sector.mbr_dsn.
Leave the bootsel magic number at 444-445 as mbr_sector.mbr_bootsel_magic
(instead of mbr_sector.mbr_bootsel.mbrbs_magic), but use 0xb5e1 (MBR_BS_MAGIC)
instead of 0xaa55 (MBR_MAGIC) to indicate that this change has occurred.
Rework MBR_BS_NEWMBR to mean "mbr_bootsel has moved to 400".
Modify fdisk(8) to automatically relocate the mbr_bootsel from 404 to 400
if mbr_bootsel_magic is the old value (0xaa55), and unset MBR_BS_NEWMBR
to flag that new mbr_bootsel code must be used if updating the MBR.
These changes fixes a problem where Windows 2000 or Windows XP would corrupt
the last 3 bytes + NUL of MBR partition 3's bootsel name if the bootsel name
was 5 characters long, replacing bytes 6-9 with the DSN.
Also, by explicitly reserving the space for the DSN we prevent problems in the
future if non bootsel MBR or PBR code had other information at bytes 440-443.
sufficient to clobber this nasty little bug. The behaviour observed
was a panic when doing a 'raidctl -f' on a component when DAGs were
in flight for the given RAID set. Unfortunatly, the faulty behaviour
was very intermittent, and it was difficult to not only reliably
reproduce the bug (nor determine when it was fixed!) but also to even
figure out what might be the cause of the problem.
The real issue was that ci_vp for the failed component was being
set to NULL in rf_FailDisk(), but with DAGs still in flight, some
of them were still expecting to use ci_vp to determine where to
read to/write from!
The fix is to call rf_SuspendNewRequestsAndWait() from rf_FailDisk()
to make sure the RAID set is quiet and all IOs have completed before
mucking with ci_vp and other data structures. rf_ResumeNewRequests()
is then used to continue on as usual.
Ensure that we don't use the first alternate superblock of a ffsv1
filesystem with 64k blocks (it is in the same place as an ffsv2 sb).
Fixes part of PR kern/24809
exactly the filename we wanted to lookup, so that file names differing
in case are refused right away
resolves the chdir part of PR kern/22835 by Rob Quinn (cd succeeded when
it was supposed to fail)
in the early boot phase.
Define prom_interpret() to be a simple form of the Openfirmware OF_interpret().
Re-arrange OLDMON code in prom_getidprom() to make it compile on sparc64.
previous version would easily make the low order bits oscillate between 0
and some other value.
Together with the previous change, this should make those
pmap_pinit: out of segments
panics even less likely.
We should really attempt a systematic search before panic()ing at the end.
This should fix PR #24754, as well as many of the hangs and process
aborts reported on port-macppc@ in the last weeks.
This error would cause the pmap's vsid never to be freed, and would
occasionnally free a valid vsid used by another pmap, sometimes the kernel's.
. add a related KASSERT() to avoid regression
abstracted by itry, ithrow, icatch et.al. macros
there is problem with these in stack setup for FreeBSD/ia64 at least,
and in general the rewritten explicit code is slighly more optimal
and smaller in size
the NetBSD code change is somewhat different to what was done in FreeBSD,
to improve readability of the code
If raidPtr->numFailures isn't initialized properly, then all sorts of
whacky things can happen, including incorrect DAGs being generated.
(Triggering this problem is a little esoteric, which is why this bug has
been in hiding for so long -- I only saw it after rebooting with a
degraded RAID 5 set that was autoconfigured, rebuilding the failed
componennt, and then failing the component while IO was happening to
the RAID set.)
also normalize function contents to resemble other filesystems,
and add a SMBVDEBUG() to ease eventual future debugging
partially based on FreeBSD rev. 1.29
fixes PR kern/23373 by Piotr Stolc
in smbfs_close(); it's necessary to overcome limitation of the current
directory lookup code
this fixes problem where ls wouldn't show newly created files, such as:
> touch a b c
> ls
>
problem and fix pointed out by YAMAMOTO Takashi
rf_dagutils.h... missed this one from yesterday. sorry folks :( ]
Change signature of rf_AllocBuffer() to take a dag_h and buffer size
instead of an PDA and an alloclist. This lets us do the vple dance
inside of rf_AllocBuffer().
Cleanup usage of rf_AllocIOBuffer() and use rf_AllocBuffer() instead.
Fix all uses of rf_AllocBuffer() to conform to the new way of doing
things.
not being at 8k - causes all sorts of problems, in particular with
ffsv1 filessytems with 64k blocks, and disks that are reformatted from
ffsv1 to ffsv2 (and v.v.). see also PR kern/24809
instead of an PDA and an alloclist. This lets us do the vple dance
inside of rf_AllocBuffer().
Cleanup usage of rf_AllocIOBuffer() and use rf_AllocBuffer() instead.
Fix all uses of rf_AllocBuffer() to conform to the new way of doing
things.
used in the event that we can't malloc a buffer of the appropriate
size in the traditional way. rf_AllocIOBuffer() and rf_FreeIOBuffer()
deal with allocating/freeing these structures. These buffers are
stored in a list on the 'iobuf' list. iobuf_count keeps track of how
many buffers are available, and numEmergencyBuffers is the effective
"high-water" mark for the freelist. The buffers allocated by
rf_AllocIOBuffer() are stripe-unit sized, which is the maximum
size requested by any of the callers.
Add an iobufs entry to RF_DagHeader_s. Use it for keeping track of
buffers that get allocated from the free-list.
Add a "generic list" pool (VoidPointerListElement Pool) for elements
used to maintain a list of allocated memory. [It is somewhat less
than ideal to add another little pool to handle this...]
Teach rf_AllocBuffer() to use the new rf_AllocIOBuffer(). Modify
other Mallocs to use rf_AllocIOBuffer(), and to update dag_h->iobufs as
appropriate.
Update rf_FreeDAG() to handle cleanup of dag_h->iobufs.
While here, add some missing pool_destroy() calls for a number of pools.
With these changes, it should (in theory) be possible to swap on
RAID 5 sets again. That said, I've not had any success there yet --
but the last issue I saw at least wasn't in RAIDframe. :-}
[There is room for this code to become a bit more consise, but I
wanted to do a checkpoint here with something known to work :) ]
