- Fix the MP Table pci bridge drivers to not probe the configuration table
unless we actually have one. Machines using a default configuration do
not have such a table.
- Only allow default configuration types of 5 (ISA + PCI) and 6 (EISA +
PCI) as the others are not likely to work. Types 1 through 4 use an
external APIC (probably with 80486 processors) which we certainly do not
support, and type 7 uses an MCA bus which has not been tested with the
new MP Table code.
- Correct the fact that the single I/O APIC in a default configuration has
an ID of 2, not 0.
- Fix off by one errors in setting the bus types from the default_data[]
arrays for default configurations.
- Explicitly configure each of the 16 interrupt pins on the sole I/O APIC
when using a default configuration. This is especially helpful for type
6 (EISA + PCI) since the EISA interrupts need to have their polarity
programmed based on the values in the ELCR.
Much thanks to the submitter and tester who endured several rounds of
testing to get this fixed.
MFC after: 1 week
Tested by: Georg Schwarz georg dot schwarz at freenet dot de
complementing the existing special case of a not existing /dev prefix
with the recognition of an already existing /dev prefix.
This implicitly solves the following two issues related to working on
GEOM devices /dev/foo/bar (which have the GEOM provider name "foo/bar")
with the expected commands like "bsdlabel /dev/foo/bar":
1. the error "Geom not found" when trying to write or edit the BSD
label (because previously the incorrect GEOM name "bar" instead of
"foo/bar" was derived from "/dev/foo/bar").
2. the multiple times reported "magically introduced" partition offset
of 63 blocks and the resulting errors like "partition extends past
end of unit" and "partition c doesn't start at 0!".
This implicitly resulted because bsdlabel(8) determines the "MBR
offset" via GEOM and (intentionally) silently falls back to an offset
of 0 if it could not be queried (which is the case if the name was
incorrectly derived).
Usually (at least on PCs) the offset for the first slice is 63 blocks
and bsdlabel(8) automatically subtracts them from the absolute
offsets in the read on-disk BSD label, resulting in the display of an
effective offset of 0. If the GEOM query fails, the assumed offset of
0 is subtracted and an incorrect effective offset of 63 is displayed
and tried to be worked upon.
Reviewed by: pjd
MFC after: 1 week
list for the valid flag values. This way, if VFS_UNMOUNT(9) supports
more flags in the future, adding a single list item is going to be
easy and all the flags are going to be in one place.
cuts to the chase and fills in a provided s/g list. This is meant to optimize
out the cost of the callback since the callback doesn't serve much purpose for
mbufs since mbuf loads will never be deferred. This is just for amd64 and
i386 at the moment, other arches will be coming shortly.
queue and (possibly) unlocking the containing object from
vm_page_alloc() to vm_page_select_cache(). Recent optimizations to
vm_map_pmap_enter() (see vm_map.c revisions 1.362 and 1.363) and
pmap_enter_quick() have resulted in panic()s because vm_page_alloc()
mistakenly unlocked objects that had not been locked by
vm_page_select_cache().
Reported by: Peter Holm and Kris Kennaway
from 4.x kernel config files. User's wishing to upgrade from 4.x to 6
will need to go through 5.x, or grab this script from there. These
scripts will remain in RELENG_5...
'fts_number' to remember number of blocks.
This makes du(1) 64bit-clean.
This work is part of the BigDisk project:
http://www.FreeBSD.org/projects/bigdisk/
Discussed on: arch@
MFC after: 5 days
make utilities like du(1) 64bit-clean.
When this field is used, one cannot use 'fts_number' and 'fts_pointer'
fields.
This commit doesn't break API nor ABI.
This work is part of the BigDisk project:
http://www.FreeBSD.org/projects/bigdisk/
Discussed on: arch@
MFC after: 5 days
