dumpdev. this occurs when we try to set the dumpdev to a device
with no driver loaded. this fixes PR#34872.
in sys_swapctl, if bdevsw_lookup() fails, set dumpdev = NODEV
before calling cpu_dumpconf(). (this also fixes PR#34872.)
XXX: cpu_dumpconf() should probably be changed to take a dumpdev
XXX: and return an error in such cases, but that is a much more
XXX: intrusive change.
XXX2: this is only run-tested on sparc64 and compile tested on a
XXX2: couple of platforms.
Fix PR port-sparc64/34863.
This also caused warning on old NetBSD environments (with GNU awk) like
awk: cmd. line:80: warning: escape sequence `\#' treated as plain `#'
at an odd address (0xd9) and noted "8 bit" in rtl81x9reg.h.
XXX: FreeBSD and OpenBSD also use CSR_WRITE_1() to write RTK_GTXSTART
XXX: for 8169 even though there is a "16 bits" comment at GTXSTART macro.
XXX: Which is correct?
used to manage network interfaces.
Add four sub-actions to fulfill generic needs for now, until a more
carefully defined usage of the interface is documented: get, set,
getpriv, and setpriv.
vnodes were synced and processed backwards. This meant that the last
accessed node was processed first and the earlierst last.
An extra benefit is the removal of the ugly hack from the Berkly days on
LFS.
In the proces, i've also replaced the various variations hand written loops
by the TAILQ_FOREACH() macro's.
I can't think of a good way to avoid race condition between writeback and
DMA write against descriptors if cachelinesize > sizeof(struct rtk_desc)...
Anyway, now re(4) is functional on O2 (and probably other mips ports).
NetBSD/alpha and NetBSD/sparc. This fixes PR#34751.
The problem most likely started to show in gcc4 and is caused by the use of
a casting to an uint32_t pointer that is later copied from using memcpy.
Gcc detects the copying of 4 bytes from an uint32_t pointer and decides to
just replace it with an aligned copy causing the trap.
Fix provided by Izumi Tsutsui and ok'd by Martin.
INTPTR_IS_LONG, not INTPTR_IS_ULONG -- the latter is unused in
other parts of lint's code. This stops vax's lint from complaining
about conversion of integer constants to 'unsigned long' in function
argument lists, via a proper define of INT_RSIZE in common/inittyp.c.
sh3 defined this to 0, so was actually not affected, but better to
eradicate the typo there as well.
- make DMA descripter members volatile
Now re(4) works on sgimips O2.
XXX: Still re(4) sometimes stalls on NFS load on sgimips,
XXX: but I'm not sure it's sgimips specific or not.
Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.
To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.
The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.
Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.
These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)
The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.
This work was funded by the Champaign-Urbana Community Wireless Network
Project.
