if the total sectors reported (via disklabel or otherwise) is smaller
than 2^32, but numBlocksHi is set, zero it out instead.
tested by myself and christos, should fix reports of weirdness seen.
From FreeBSD, via OpenBSD, with some minor adaptations.
No comments, no objections on tech-kern@.
The driver was tested on a Dell M710. Access was kindly provided by
Uwe Toenjes, whom I thank for this.
See also http://mail-index.netbsd.org/tech-kern/2010/12/01/msg009478.html
The macros for PAGE_SIZE were fixed with the previous patch (if_bnxreg.h
splitting, rev 1.11).
From OpenBSD. Their commit log reads:
bnx(4) is a bit special. The chip itself is capable of swapping endianess
so there is no need for htoleXX calls. The only thing needed is the correct
layout of the DMA-ed structures. Additionally it uses PAGE_SIZE but assumed
that it is always 4k. Fix the macros that failed to respect that so that it
works on 8k PAGE_SIZE systems. This makes bnx(4) work on sparc64.
llrint() and llrintf(). Code copied from round(), roundf() and
rint() and modified for return values. Its possible this may not
do the right things in edge cases, but if so its likely to have
the same issues as the existing round(), roundf() and rint().
All this used by vax (only), and should allow xnest to complete
build.
- if_bnxreg.h: general register values, flags... for bnx(4), that can
be included in other drivers
- if_bnxvar.h: PCI or device specific code (device state data, debug
macros etc.), which should remain private to bnx(4)
No comments, no objections on current-users@.
See discussion:
http://mail-index.netbsd.org/current-users/2010/12/01/msg014926.html
Put real data into file systems before resizing: the test data
was randomly generated and is in pairs of files each a power-of-two and
power-of-two plus one bytes to hopefully catch block and frag issues.
Each test fills (nearly) the file system with test data. If shrinking,
it removes enough data so that the shrunken file system will be large enough
to accomodate the data. (It's done this way to hopefully ensure some or
most of the data will need to be moved when shrinking). The files are
then checked with MD5 against the known list. This particular method
was chosen to reduce the amount of data checked in while still retaining
reproducibility.
There are more tests to come; since resize_ffs(8) currently does not
support ffsv2 or byteswapped file systems, only a couple token expected-fail
test cases for those were added. Also, only 8:1 blocksize:fragsize
combinations are currently tested.
CVS: ----------------------------------------------------------------------
CVS: CVSROOT cvs.NetBSD.org:/cvsroot
CVS: please use "PR category/123" to have the commitmsg appended to PR 123
CVS:
CVS: Please evaluate your changes and consider the following.
CVS: Abort checkin if you answer no.
CVS: => For all changes:
CVS: Do the changed files compile?
CVS: Has the change been tested?
CVS: => If you are not completely familiar with the changed components:
CVS: Has the change been posted for review?
CVS: Have you allowed enough time for feedback?
CVS: => If the change is major:
CVS: => If the change adds files to, or removes files from $DESTDIR:
CVS: => If you are changing a library or kernel interface:
CVS: Have you successfully run "./build.sh release"?