Replace dual copyright with a plain BSD style copyright assigned
to LSI Logic. This is still within the intents of express consent
from LSI.
MFC after: 2 days
specifically allows for (via 'BSD Style' licensing) source && binary
redistribution.
Pointy hat to: Matt, for not getting this done ahead of time.
MFC after: 2 days
the minimum of either physmem or KVA. But.. btoc() casts the address
to (unsigned int). This is NOT GOOD on 64 bit machines and on alpha and
ia64, this results in a buffer limit of around 500K (not megs). This
causes extreme disk access problems on alpha and ia64. Since this cast
is simply to ensure that it is unsigned, use 'vm_offset_t' instead. This
is available because it is already defined in types.h.
Alpha has been suffering from this for ages. It always felt like the
caching wasn't working, and unfortunately it turned out that way. :-(
idle. What was there before was surprisingly ALMOST correct.
Peter and I fried our brains on this for a couple of hours figuring out
what this actually means in the context of multiple threads.
Reviewed by: peter@freebsd.org
- If either of proc or kse are NULL during thread_exit(), then
the kernel is going to fault because parts of the function
assume they aren't NULL. Instead, just assert they aren't NULL
(as well as the kse group) and assume they are in all of the
code. It doesn't make sense for them to be NULL here anyways.
- Move the PROC_UNLOCK(p) up above clearing td_proc, etc. since
otherwise we will panic if the proc's lock is contested.
Submitted by: jhb@freebsd.org
circumstances. The problem was only reported with -stable, but it's
obviously wrong in -current also. MFC is forthcoming.
Submitted by: doconnor@dsoft.com.au
this was quite broken, it never was updated for metadata support.
The a.out kld file support was never really used, as it wasn't necessary.
You could always load elf kld's, even in an a.out kernel.
kld's anywhere, and it was always possible to load ELF kld's even in an
a.out kernel. There is no reason for this to exist anymore, and a.out
kld support has been suffering serious bitrot over the years. They have
not been fully functional for quite some time.
alive!" message right as the scsi probe messages happen. This is a bit
nasty, but it seems to work. At the point that we unlock the AP's, briefly
wait till they are all done while we hold the console on their behalf.
ECONNABORTED. Make this happen in the non-blocking case as well.
The previous behavior was to return EAGAIN, which (a) is not
consistent with the blocking case and (b) causes the application
to think the socket is still valid.
PR: bin/42100
Reviewed by: freebsd-net
MFC after: 3 days
own namespace pollution/compatibility cruft.
Removed the main part of the pollution. All clients have been converted
to either not depend on getting old locking interfaces from this new
locking header, or usual case to get it from another header (typically
vnode.h, where declaring old loccking interfaces is less bogus because
vnode.h uses them internally).
automatically once opt_foo.h is in SRCS, modulo some carelessness in
removing garbage in stale versions of opt_foo.h (touch(1) should not
be used to create opt_foo.h in kmod.mk or elsewhere).
Cleaned up nearby rule for creating opt_ddb.h.
are implemented here instead of depending on namespace pollution in
<sys/lock.h>. Fixed nearby include messes (1 disordered include and 1
unused include).
Recent version of ACPI CA returns the package object which contains
object reference elements if the elements are named objects.
We need to be careful when you use acpi_ForeachPackageObject() in new
code...
We are having panics with the driver under stress with jumbo frames.
Unfortunately we didnot catch it during our regular test cycle.
I am going to MFC the backout immediately.
log the start and end of periods during which mtx_lock() is waiting
to acquire a sleep mutex. The log message includes the file and
line of both the waiter and the holder.
Reviewed by: jhb, jake
- Add an ACPI PCI-PCI bridge driver (the previous driver just handled
Host-PCI bridges) that is a PCI driver that is a subclass of the generic
PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and
pci_route_interrupt.
- The probe routine only succeeds if our parent is an ACPI PCI bus which
we test for by seeing if we can read our ACPI_HANDLE as an ivar.
- The attach routine saves a copy of our handle and calls the new
acpi_pcib_attach_common() function described below.
- The read_ivar routine handles normal PCI-PCI bridge ivars and adds an
ivar to return the ACPI_HANDLE of the bus this bridge represents.
- The route_interrupt routine fetches the _PRT (PCI Interrupt Routing
Table) from the bridge device's softc and passes it off to
acpi_pcib_route_interrupt() to route the interrupt.
- Split the old ACPI Host-PCI bridge driver into two pieces. Part of
the attach routine and most of the route_interrupt routine remain in
acpi_pcib.c and are shared by both ACPI PCI bridge drivers.
- The attach routine verifies the PCI bridge is present, reads in
the _PRT for the bridge, and attaches the child PCI bus.
- The route_interrupt routine uses the passed in _PRT to route a PCI
interrupt.
The rest of the driver is the ACPI Host-PCI bridge specific bits that
live in acpi_pcib_acpi.c.
- We no longer duplicate pcib_maxslots but use it directly.
- The driver now uses the pcib devclass instead of its own devclass.
This means that PCI busses are now only children of pcib devices.
- Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar
of the child bus.
- Fetch the _PRT for routing PCI interrupts directly from our softc
instead of walking the devclass to find ourself and then fetch our
own softc.
With this change and the new ACPI PCI bus driver, ACPI can now properly
route interrupts for devices behind PCI-PCI bridges. That is, the
Itanium2 with like 10 PCI busses can now boot ok and route all the PCI
interrupts. Hopefully this will also fix problems people are having with
CardBus bridges behind PCI-PCI bridges not properly routing interrupts
when ACPI is used.
Tested on: i386, ia64
driver. This driver overrides the probe, attach, and read_ivar methods.
If the parent bridge is an ACPI PCI bridge, then the probe routine will
match, otherwise it will fail. It tests this by seeing if it can get
the ACPI_HANDLE ivar from the bridge device.
In the attach routine, it uses pci_add_children() to add all the child
devices (but with a slightly larger ivar so it can store ACPI_HANDLE's
for child devices) and then walks through the ACPI namespace below the
bus device to cache ACPI_HANDLE's for all child devices present in the
namespace. It does this by comparing the pci slot and function to the
address encoded in _ADR of the devices in the ACPI namespace.
The read_ivar routine passes most requests off to pci_read_ivar()
and adds a new request so that the ACPI_HANDLE for a child device can
be read.
To add proper power support the power methods can be overridden as well,
but that is not currently implemented. Also, there are cases where a
device may show in the ACPI namespace as a PCI device that the PCI probe
does not find. Currently such devices are ignored.
Tested on: i386, ia64
OOP speak, you would mark these as 'protected' members. Specifically:
- Make the pcib_softc struct public so it can be used by subclasses.
- Make pcib_{read,write}_ivar(), pcib_alloc_resource(), pcib_maxslots(),
and pcib_{read,write}_config() globals that can be used by subclasses.
- Make the pcib devclass a global variable.
- Move most of the pcib_attach() function into a global
pcib_attach_common() function that can be called by the attach routines
of subclasses.
Tested on: i386, alpha, sparc64, ia64
- Make the pci devclass a global variable.
- Add child devices in pci_attach() instead of pci_probe(). Change
pci_probe() to just check for a valid bus number from the associated
bridge and return -1000 if successful. This allows subclasses of the
PCI bus driver to override the generic driver.
- Move the code to load the vendor data into its own public function.
Really though, doing this at attach is just plain wrong. This should
really be done in the module load routine instead. As a side effect,
the 'busno' variable in pci_attach() is now no longer static (minor
bug that was harmless so far.)
- Change pci_add_children() to take an extra argument that is the size of
the device info structure passed to pci_read_device() and make it public
so subclasses of the PCI bus can call it in their attach routines.
- Move the bits to attach a probed PCI child to a PCI bus into a global
pci_add_child() function. This will allow subclasses that can detect
a PCI device not found in the normal PCI probe to add those devices in
their own attach routine. (I have seen this in the ACPI tree on my
laptop for example.) As a side effect, change the static function
pci_add_resources() to get the busno, slot, and func from the passed
in dinfo structure instead of requiring them as function arguments.
Tested on: i386, alpha, ia64, sparc64
LNK device (interrupt source provider sort of) is present before using it,
but the code actually tested the status (_STA) of the PCI bridge device
doing the routing, not the actual LNK device. Fix it to check the status
of the LNK device.
Change _BSD_CLK_TCK_ and _BSD_CLOCKS_PER_SEC_ to match stathz. This
should result in bug for bug compatibility in staticly linked
programs and dynamicly linked programs should see an immediate
correction.
firewall logging on and off when at elevated securelevel(8). It would
be nice to be able to only lock these at securelevel >= 3, like rules
are, but there is no such functionality at present. I don't see reason
to be adding features to securelevel(8) with MAC being merged into 5.0.
PR: kern/39396
Reviewed by: luigi
MFC after: 1 week
pmap_zero_page() and pmap_zero_page_area() were modified to accept
a struct vm_page * instead of a physical address, vm_page_zero_fill()
and vm_page_zero_fill_area() have served no purpose.
a pointer to a symbol is given and we have to find the containing symbol
table. We do this by bounds checking. For some strange reason (ie I
haven't found the root cause) the first test succeeded for said symbol,
implying that the symbol came from the .dynsym table. In reality however
the symbol actually resided in the .symtab table. Needless to say that
all that was returned was junk.
The upper bounds check was: (symptr - baseptr) < symtab_size
This has been rewritten to: symptr < (baseptr + symtab_size)
As a side-effect, slightly more optimal (and still correct :-) code can
be generated on ia64.
