hosts. IPv6 is probably still broken, and, actually, the lookup table
for mask values should be kept in network byte order, not host byte order
and the corresponding change to the srtconfig ioctl interface made.
But at least this works.
* page out vnode objects
* drain kmem/kernel_map
As long as there is a reasonable memory hardlimit (>600kB or so),
a rump kernel can now survive file system metadata access for an
arbitrary size file system (provided, of course, that the file
system does not use wired kernel memory for metadata ...).
Data handling still needs a little give&take finetuning. The
general problem is that a single vm object can easily be the owner
of all vm pages in a rump kernel. now, if a thread wants to allocate
memory while holding that object locked, there's very little the
pagedaemon can do to avoid deadlock. but I think the problem can
be solved by making an object release a page when it wants to
allocate a page if a) the system is short on memory and b) too many
pages belong to the object. that still doesn't take care of the
pathological situation where 1000 threads hold an object with 1
page of memory locked and try to allocate more. but then again,
running 1000 threads with <1MB of memory is an unlikely scenario.
and ultimately, I call upon the fundamental interaction which is
the basis of why any operating works: luck.
if size 0 and starting after the text segments, if no data segment was
found. Unbreaks sbrk on platforms where all loaded segments are
executable (PR 43817). The cast of executable segments after data
segments is left out for now.
we are short of memory.
There are still some funnies left to iron out. For example, with
a certain file system / memory size configuration it's still not
possible to create enough files to make the file system run out of
inodes before the kernel runs out of memory. Also, with some other
configurations disk access slows down gargantually (though i'm sure
there are >0 buffers available). Anyway, it ~works for now and
it's by no means worse than what it was before.
not doing it for cosmetic value or out of angst. See, PIC_PROLOGUE
on i386 uses the "1" label internally. Now, everything would be
fine and dandy for the first 551245 calls to random. After that
p+q is negative and the jump is taken. However, it is taken into
the middle of PIC_PROLOGUE instead of where upon superficial
examination we assumed we are jumping. This causes wrong(tm) things
to happen and "ret" triggers a jump into hyperspace.
(no, I did not see that coming)
number currently attached. Deals with a SNAFU in my commit earlier
today which would cause softints established early to lack a
softint context on non-bootstrap CPUs.
queueing at the scsipi midlayer, and if the midlayer is not requested to
enable tagged queueing, the midlayer will only queue one command to the
adapter driver for each device. The SmartArray adapter is capable of
handling multiple commands, and in the rather common case where there is
no battery backup and no write cache, doing single write commands is very
slow. The SmartArray adapter runs much better when several commands can
be issued to a device.
This has been observed and discussed in several list threads, notably:
http://mail-index.NetBSD.org/netbsd-users/2008/10/01/msg002083.htmlhttp://mail-index.NetBSD.org/tech-kern/2008/11/30/msg003704.html
This also addresses PR kern/39686.
To enable tagged queueing, the adapter driver responds to the midlayer
request to set the transfer mode. However, the SmartArray does not respond
to the SCSI INQUIRY command with an ANSII field of 2 or more, so the
scsipi midlayer will ignore the CmdQue bit in the flags3 field of the
inquiry data. This fix will patch the inquiry data so set the ANSII field
to 2, and responds to the midlayer request to set the transfer mode by
requesting tagged queueing.
In addition, the original port of the driver did not set up the adapter
parameters correctly as mentioned in the second list thread mentioned
above. The adapt_openings is the total number of commands that the
adapter will accept rather than the number of commands divided by the
number of logical drives. Also, the adapt_max_periph is the maximum number
of commands which can be queued per peripheral device, not the number of
logical drives [which in the case of a single logical drive limited the
number of commands queued to 1].
I'm also suppressing an error message for invalid commands if the error
was due to the SCSI_SYNCHRONIZE_CACHE_10 command, since that command is
not supported by the SmartArray adapter, but used with wapbl(4) meta-data
journaling. Setting the ANSII version to 2 to allow enabling tagged queueing
also enables the use of the SCSI_SYNCHRONIZE_CACHE_10 command.
structure itself and allocating the backing page directly from the
hypervisor.
* initial write to a large tmpfs file is almost 2x faster
* truncating the file to 0 length after write is over 50% faster
* rewrite of the file is just slightly faster (indicating that
kmem does a good job with caching, as expected)
don't use ACPI on BIOS which advertise release years <= 2000. This
can be changed by setting option ACPI_BLACKLIST_YEAR=0 or by setting
acpi_force_load=1.
still matches more boards that just the one with the problem.
Interrupts from the SATA controllers on my MSI K8N Neo3 boards
(which both versions of this quirk matched) are broken when ACPI
is disabled. My board does not exhibit AE_AML_INFINITE_LOOP
problems.
If we want to avoid manually specifying RB_MD2 in boothowto on
pgoyette@'s board, we're going to have to find another way; perhaps
with the DMI strings available from pmf(9).
Anyhow, some boards needing RB_MD2 during boot(8) is in my opinion
better than others needing to set acpi_force_load in ddb or gdb.
