summaryrefslogtreecommitdiffstats
path: root/sys/sparc64
Commit message (Collapse)AuthorAgeFilesLines
* MFC r313194:kib2017-02-111-2/+0
| | | | Define the vm_ooffset_t and vm_pindex_t types as machine-independend.
* MFC 307332,312086: Drop support for using mmap() with /dev/kmem.jhb2017-01-181-1/+1
| | | | | | | | | | | | | | | | | | | 307332: Drop support for using mmap() with /dev/kmem. Using the device pager with /dev/kmem is not stable since KVA mappings are transient, but the device pager caches the PA associated with a given offset forever. Interestingly, mips' implementation of memmap() already refused requests for /dev/kmem. Note that kvm_read/kvm_write do not use mmap, but use read and write on /dev/kmem, so this should not affect libkvm users. 312086: Trim a few comments on platforms that did not implement mmap of /dev/kmem. After r307332, no platforms implement mmap for /dev/kmem, so the lack of it for these platforms is no longer unique.
* MFC r305213,305319,305398alc2016-10-011-1/+14
| | | | | | | | | | | | As an optimization to the machine-independent layer, change the machine- dependent pmap_ts_referenced() so that it updates the page's dirty field if a modified bit is found while counting reference bits. This opportunistic update can be performed at low cost and can eliminate the need for some future calls to pmap_is_modified() by the machine- independent layer. Replace the number 4 in sparc64's pmap_ts_referenced() by PMAP_TS_REFERENCED_MAX, like we've done elsewhere, e.g., amd64.
* MFC r303891, r303892:pfg2016-09-081-3/+3
| | | | | | | | sys: replace comma with semicolon when pertinent. Uses of commas instead of a semicolons can easily go undetected. The comma can serve as a statement separator but this shouldn't be abused when statements are meant to be standalone.
* Remove GENERIC-NODEBUG kernel configurations, missed duringgjb2016-07-141-38/+0
| | | | | | | | | the stable/11 branch. This is a direct commit to stable/11. Approved by: re (kib) Sponsored by: The FreeBSD Foundation
* - Remove debugging from GENERIC* kernel configurationsgjb2016-07-081-9/+0
| | | | | | | | | - Enable MALLOC_PRODUCTION - Default dumpdev=NO - Remove UPDATING entry regarding debugging features Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
* Update comments for the MD functions managing contexts for newkib2016-06-161-3/+3
| | | | | | | | | | | | | | | | threads, to make it less confusing and using modern kernel terms. Rename the functions to reflect current use of the functions, instead of the historic KSE conventions: cpu_set_fork_handler -> cpu_fork_kthread_handler (for kthreads) cpu_set_upcall -> cpu_copy_thread (for forks) cpu_set_upcall_kse -> cpu_set_upcall (for new threads creation) Reviewed by: jhb (previous version) Sponsored by: The FreeBSD Foundation MFC after: 1 week Approved by: re (hrs) Differential revision: https://reviews.freebsd.org/D6731
* Add macro to convert errno and use it when appropriate.dchagin2016-05-221-7/+1
| | | | MFC after: 1 week
* Add new bus methods for mapping resources.jhb2016-05-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a pair of bus methods that can be used to "map" resources for direct CPU access using bus_space(9). bus_map_resource() creates a mapping and bus_unmap_resource() releases a previously created mapping. Mappings are described by 'struct resource_map' object. Pointers to these objects can be passed as the first argument to the bus_space wrapper API used for bus resources. Drivers that wish to map all of a resource using default settings (for example, using uncacheable memory attributes) do not need to change. However, drivers that wish to use non-default settings can now do so without jumping through hoops. First, an RF_UNMAPPED flag is added to request that a resource is not implicitly mapped with the default settings when it is activated. This permits other activation steps (such as enabling I/O or memory decoding in a device's PCI command register) to be taken without creating a mapping. Right now the AGP drivers don't set RF_ACTIVE to avoid using up a large amount of KVA to map the AGP aperture on 32-bit platforms. Once RF_UNMAPPED is supported on all platforms that support AGP this can be changed to using RF_UNMAPPED with RF_ACTIVE instead. Second, bus_map_resource accepts an optional structure that defines additional settings for a given mapping. For example, a driver can now request to map only a subset of a resource instead of the entire range. The AGP driver could also use this to only map the first page of the aperture (IIRC, it calls pmap_mapdev() directly to map the first page currently). I will also eventually change the PCI-PCI bridge driver to request mappings of the subset of the I/O window resource on its parent side to create mappings for child devices rather than passing child resources directly up to nexus to be mapped. This also permits bridges that do address translation to request suitable mappings from a resource on the "upper" side of the bus when mapping resources on the "lower" side of the bus. Another attribute that can be specified is an alternate memory attribute for memory-mapped resources. This can be used to request a Write-Combining mapping of a PCI BAR in an MI fashion. (Currently the drivers that do this call pmap_change_attr() directly for x86 only.) Note that this commit only adds the MI framework. Each platform needs to add support for handling RF_UNMAPPED and thew new bus_map/unmap_resource methods. Generally speaking, any drivers that are calling rman_set_bustag() and rman_set_bushandle() need to be updated. Discussed on: arch Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D5237
* Use OF_prop_free instead of direct call to free(9)gonzo2016-05-189-28/+28
| | | | Reviewed by: marius
* sys/sparc64: minor spelling fixes.pfg2016-05-042-2/+2
| | | | Only affects comments: no functional change.
* Move 'device pci' for the PCI bus driver to the MI NOTES file.jhb2016-04-291-1/+0
| | | | | The PCI bus was already listed in all of the MD NOTES files and the driver should at least compile on all platforms.
* Add a bus_null_rescan() method that always fails with an error.jhb2016-04-271-1/+1
| | | | | Use this in place of kobj_error_method to disable BUS_RESCAN() on PCI drivers that do not use the "standard" scanning algorithm.
* Add a pcib_attach_child() method to manage adding the child "pci" device.jhb2016-04-271-2/+1
| | | | | | | | | | | | This allows the PCI-PCI bridge driver to save a reference to the child device in its softc. Note that this required moving the "pci" device creation out of acpi_pcib_attach(). Instead, acpi_pcib_attach() is renamed to acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI interrupt routing table. Differential Revision: https://reviews.freebsd.org/D6021
* Implement a PCI bus rescan method.jhb2016-04-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Rescanning a PCI bus uses the following steps: - Fetch the current set of child devices and save it in the 'devlist' array. - Allocate a parallel array 'unchanged' initalized with NULL pointers. - Scan the bus checking each slot (and each function on slots with a multifunction device). - If a valid function is found, look for a matching device in the 'devlist' array. If a device is found, save the pointer in the 'unchanged' array. If a device is not found, add a new device. - After the scan has finished, walk the 'devlist' array deleting any devices that do not have a matching pointer in the 'unchanged' array. - Finally, fetch an updated set of child devices and explicitly attach any devices that are not present in the 'unchanged' array. This builds on the previous changes to move subclass data management into pci_alloc_devinfo(), pci_child_added(), and bus_child_deleted(). Subclasses of the PCI bus use custom rescan logic explicitly override the rescan method to disable rescans. Differential Revision: https://reviews.freebsd.org/D6018
* Use our nitems() macro when param.h is available.pfg2016-04-203-5/+4
| | | | | | Replacements specific to arm, mips, pc98, powerpc and sparc64. Discussed in: freebsd-current
* sparc64: for pointers replace 0 with NULL.pfg2016-04-151-1/+1
| | | | | | These are mostly cosmetical, no functional change. Found with devel/coccinelle.
* Add a new PCI bus interface method to alloc the ivars (dinfo) for a device.jhb2016-04-151-4/+15
| | | | | | | | | | | | | | The ACPI and OFW PCI bus drivers as well as CardBus override this to allocate the larger ivars to hold additional info beyond the stock PCI ivars. This removes the need to pass the size to functions like pci_add_iov_child() and pci_read_device() simplifying IOV and bus rescanning implementations. As a result of this and earlier changes, the ACPI PCI bus driver no longer needs its own device_attach and pci_create_iov_child methods but can use the methods in the stock PCI bus driver instead. Differential Revision: https://reviews.freebsd.org/D5891
* Cleanup unnecessary semicolons from the kernel.pfg2016-04-101-2/+2
| | | | Found with devel/coccinelle.
* Since r296250 it is no longer possible for devices to use bus spacemarius2016-04-101-1/+1
| | | | | | | | | | | | | | | | addresses exceeding 32 bit, so bump BUS_SPACE_MAXADDR to 64 bit. The whole situation is sub par, though; prior to r296250 and despite what their names imply, BUS_SPACE_MAX* were primarily, even almost exclusively used for bus_dma(9). Now these macros also have a vital role for bus_space(9). However, it does not necessarily hold that both bus DMA and space addresses universally have the same limits per platform. As for sparc64, 64 bit clearly is beyond what can be addressed via the various IOMMUs. With this change in place, we now rely on the parent bus DMA tags of the host-to-foo drivers causing the child tags to be capped as necessary. PR: 207998
* Convert pci_delete_child() to a bus_child_deleted() method.jhb2016-04-061-0/+12
| | | | | | | | | | | | | | | | | | | | Instead of providing a wrapper around device_delete_child() that the PCI bus and child bus drivers must call explicitly, move the bulk of the logic from pci_delete_child() into a bus_child_deleted() method (pci_child_deleted()). This allows PCI devices to be safely deleted via device_delete_child(). - Add a bus_child_deleted method to the ACPI PCI bus which clears the device_t associated with the corresponding ACPI handle in addition to the normal PCI bus cleanup. - Change cardbus_detach_card to call device_delete_children() and move CardBus-specific delete logic into a new cardbus_child_deleted() method. - Use device_delete_child() instead of pci_delete_child() in the SRIOV code. - Add a bus_child_deleted method to the OpenFirmware PCI bus drivers which frees the OpenFirmware device info for each PCI device. Reviewed by: imp Tested on: amd64 (CardBus and PCI-e hotplug) Differential Revision: https://reviews.freebsd.org/D5831
* Fix the resource_list_print_type() calls to use uintmax_t.jhibbits2016-03-227-13/+13
| | | | Missed a bunch from r297000.
* Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.jhibbits2016-03-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some architectures, u_long isn't large enough for resource definitions. Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but type `long' is only 32-bit. This extends rman's resources to uintmax_t. With this change, any resource can feasibly be placed anywhere in physical memory (within the constraints of the driver). Why uintmax_t and not something machine dependent, or uint64_t? Though it's possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on 32-bit architectures. 64-bit architectures should have plenty of RAM to absorb the increase on resource sizes if and when this occurs, and the number of resources on memory-constrained systems should be sufficiently small as to not pose a drastic overhead. That being said, uintmax_t was chosen for source clarity. If it's specified as uint64_t, all printf()-like calls would either need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t aren't horrible, but it would also bake into the API for resource_list_print_type() either a hidden assumption that entries get cast to uintmax_t for printing, or these calls would need the PRI*64 macros. Since source code is meant to be read more often than written, I chose the clearest path of simply using uintmax_t. Tested on a PowerPC p5020-based board, which places all device resources in 0xfxxxxxxxx, and has 8GB RAM. Regression tested on qemu-system-i386 Regression tested on qemu-system-mips (malta profile) Tested PAE and devinfo on virtualbox (live CD) Special thanks to bz for his testing on ARM. Reviewed By: bz, jhb (previous) Relnotes: Yes Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D4544
* Correct the memory rman ranges to be to BUS_SPACE_MAXADDRjhibbits2016-03-011-1/+1
| | | | | | | | | | | | | Summary: As part of the migration of rman_res_t to be typed to uintmax_t, memory ranges must be clamped appropriately for the bus, to prevent completely bogus addresses from being used. This is extracted from D4544. Reviewed By: cem Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5134
* As <machine/pmap.h> is included from <vm/pmap.h>, there is no need toskra2016-02-223-3/+0
| | | | | | | include it explicitly when <vm/pmap.h> is already included. Reviewed by: alc, kib Differential Revision: https://reviews.freebsd.org/D5373
* Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.jhibbits2016-02-208-8/+8
| | | | | | | | | | | This simplifies checking for default resource range for bus_alloc_resource(), and improves readability. This is part of, and related to, the migration of rman_res_t from u_long to uintmax_t. Discussed with: jhb Suggested by: marcel
* Introduce bus_get_bus_tag() methodzbb2016-02-181-0/+9
| | | | | | | | | | | | | | | | | | | Provide bus_get_bus_tag() for sparc64, powerpc, arm, arm64 and mips nexus and its children in order to return a platform specific default tag. This is required to ensure generic correctness of the bus_space tag. It is especially needed for arches where child bus tag does not match the parent bus tag. This solves the problem with ppc architecture where the PCI bus tag differs from parent bus tag which is big-endian. This commit is a part of the following patch: https://reviews.freebsd.org/D4879 Submitted by: Marcin Mazurek <mma@semihalf.com> Obtained from: Semihalf Sponsored by: Annapurna Labs Reviewed by: jhibbits, mmel Differential Revision: https://reviews.freebsd.org/D4879
* POSIX states that #include <signal.h> shall make both mcontext_t andkib2016-02-121-5/+5
| | | | | | | | | | | | | | | | | | | | ucontext_t available. Our code even has XXX comment about this. Add a bit of compliance by moving struct __ucontext definition into sys/_ucontext.h and including it into signal.h and sys/ucontext.h. Several machine/ucontext.h headers were changed to use namespace-safe types (like uint64_t->__uint64_t) to not depend on sys/types.h. struct __stack_t from sys/signal.h is made always visible in private namespace to satisfy sys/_ucontext.h requirements. Apparently mips _types.h pollutes global namespace with f_register_t type definition. This commit does not try to fix the issue. PR: 207079 Reported and tested by: Ting-Wei Lan <lantw44@gmail.com> Sponsored by: The FreeBSD Foundation MFC after: 2 weeks
* Include sys/_task.h into uma_int.h, so that taskqueue.h isn't aglebius2016-02-091-1/+0
| | | | | | requirement for uma_int.h. Suggested by: jhb
* Fix build.br2016-02-041-0/+1
|
* Convert ss_sp in stack_t and sigstack to void *.jhb2016-01-271-1/+1
| | | | | | | | | | | | POSIX requires these members to be of type void * rather than the char * inherited from 4BSD. NetBSD and OpenBSD both changed their fields to void * back in 1998. No new build failures were reported via an exp-run. PR: 206503 (exp-run) Reviewed by: kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D5092
* Convert rman to use rman_res_t instead of u_longjhibbits2016-01-2713-30/+30
| | | | | | | | | | | | | | | | | | | | Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
* Add an atomic_fetchadd_64() wrapper on sparc64.jhb2016-01-221-0/+1
| | | | Reviewed by: marius
* Implement vsyscall hack. Prior to 2.13 glibc uses vsyscalldchagin2016-01-091-0/+1
| | | | | | | | | instead of vdso. An upcoming linux_base-c6 needs it. Differential Revision: https://reviews.freebsd.org/D1090 Reviewed by: kib, trasz MFC after: 1 week
* Make using the #address-cells property on the interrupt parent in devicenwhitehorn2016-01-021-0/+3
| | | | | | | tree parsing opt-out rather than opt-in. All FDT-based systems as well as PowerPC systems with real Open Firmware use the CHRP-derived binding that includes it, which makes SPARC the odd man out here. Making it opt-out avoids astonishment on new platform bring up.
* Make the 'env' directive described in config(5) work on all architectures,ian2016-01-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | providing compiled-in static environment data that is used instead of any data passed in from a boot loader. Previously 'env' worked only on i386 and arm xscale systems, because it required the MD startup code to examine the global envmode variable and decide whether to use static_env or an environment obtained from the boot loader, and set the global kern_envp accordingly. Most startup code wasn't doing so. Making things even more complex, some mips startup code uses an alternate scheme that involves calling init_static_kenv() to pass an empty buffer and its size, then uses a series of kern_setenv() calls to populate that buffer. Now all MD startup code calls init_static_kenv(), and that routine provides a single point where envmode is checked and the decision is made whether to use the compiled-in static_kenv or the values provided by the MD code. The routine also continues to serve its original purpose for mips; if a non-zero buffer size is passed the routine installs the empty buffer ready to accept kern_setenv() values. Now if the size is zero, the provided buffer full of existing env data is installed. A NULL pointer can be passed if the boot loader provides no env data; this allows the static env to be installed if envmode is set to do so. Most of the work here is a near-mechanical change to call the init function instead of directly setting kern_envp. A notable exception is in xen/pv.c; that code was originally installing a buffer full of preformatted env data along with its non-zero size (like mips code does), which would have allowed kern_setenv() calls to wipe out the preformatted data. Now it passes a zero for the size so that the buffer of data it installs is treated as non-writeable.
* Change the - hopefully - last piece of ktr(9) to use PCPU_GET(cpuid)marius2015-12-301-1/+1
| | | | instead of the MD module ID for KTR_CPU.
* - (Ab)use udivx for dividing the u_int pc_cpuid when implementingmarius2015-12-305-89/+68
| | | | | | | | | | | | | | | | | | | | | CPU_ISSET(), CPU_SET etc. in sparc64 asm. This approach has the benefit of not clobbering %y, allowing to revert r222827 and partially r222828. - In r222828, CATR() already was changed to use the equivalent of PCPU_GET(cpuid) instead of the MD module ID for KTR_CPU, so belatedly also catch up with the C side of ktr(9). Originally, in r203838 CATR() was moved away from directly reading the module ID or equivalent as that became impractical with other CPU types than USI/II supported. With r222828 in place, per-CPU data generally is set up soon enough, though, that employing PCPU things in ktr(9) also for use during early stages works. - Unfortunately, an exception to the latter is the ktr(9) use in pmap_bootstrap(), which actually is run so early that even checking for bootverbose being set via the loader doesn't work. Consequently, replace the ktr(9) use in pmap_bootstrap() with OF_printf(9) and put it under #ifdef DIAGNOSTIC instead. MFC after: 3 days
* Adapt CATR() to r283283.marius2015-12-301-3/+3
|
* Remove sv_prepsyscall, sv_sigsize and sv_sigtbl members of the structkib2015-11-281-3/+0
| | | | | | | | | | | | | | | | sysent. sv_prepsyscall is unused. sv_sigsize and sv_sigtbl translate signal number from the FreeBSD namespace into the ABI domain. It is only utilized on i386 for iBCS2 binaries. The issue with this approach is that signals for iBCS2 were delivered with the FreeBSD signal frame layout, which does not follow iBCS2. The same note is true for any other potential user if sv_sigtbl. In other words, if ABI needs signal number translation, it really needs custom sv_sendsig method instead. Sponsored by: The FreeBSD Foundation
* Add support to libkvm for reading vmcores from other architectures.jhb2015-11-271-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add a kvaddr_type to represent kernel virtual addresses instead of unsigned long. - Add a struct kvm_nlist which is a stripped down version of struct nlist that uses kvaddr_t for n_value. - Add a kvm_native() routine that returns true if an open kvm descriptor is for a native kernel and memory image. - Add a kvm_open2() function similar to kvm_openfiles(). It drops the unused 'swapfile' argument and adds a new function pointer argument for a symbol resolving function. Native kernels still use _fdnlist() from libc to resolve symbols if a resolver function is not supplied, but cross kernels require a resolver. - Add a kvm_nlist2() function similar to kvm_nlist() except that it uses struct kvm_nlist instead of struct nlist. - Add a kvm_read2() function similar to kvm_read() except that it uses kvaddr_t instead of unsigned long for the kernel virtual address. - Add a new kvm_arch switch of routines needed by a vmcore backend. Each backend is responsible for implementing kvm_read2() for a given vmcore format. - Use libelf to read headers from ELF kernels and cores (except for powerpc cores). - Add internal helper routines for the common page offset hash table used by the minidump backends. - Port all of the existing kvm backends to implement a kvm_arch switch and to be cross-friendly by using private constants instead of ones that vary by platform (e.g. PAGE_SIZE). Static assertions are present when a given backend is compiled natively to ensure the private constants match the real ones. - Enable all of the existing vmcore backends on all platforms. This means that libkvm on any platform should be able to perform KVA translation and read data from a vmcore of any platform. Tested on: amd64, i386, sparc64 (marius) Differential Revision: https://reviews.freebsd.org/D3341
* Fix whitespace on addition of IPSEC optionemaste2015-11-261-1/+1
|
* Merge from r290547:marius2015-11-213-32/+32
| | | | | | | | | | | Since r289279 bufinit() uses mp_ncpus so adapt to what x86 does and set this variable already in cpu_mp_setmaxid(). While at it, rename cpu_cpuid_prop() to cpu_portid_prop() as well as the MD cpuid variable to portid to avoid confusion with the MI use of "cpuid" and make some variable static/global in order to reduce stack usage. PR: 204685
* - Unbreak dumpsys(9) on sparc64 after r276772marius2015-11-162-25/+7
| | | | | | - While at it, arrange #ifndefs in kern_dump.c more intelligently; it's rather confusing to have multiple competing and/or unused functions in the kernel.
* Fix an alignment check that is wrong in half the busdma implementations.ian2015-11-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This will enable the elimination of a workaround in the USB driver that artifically allocates buffers twice as big as they need to be (which actually saves memory for very small buffers on the buggy platforms). When deciding how to allocate a dma buffer, armv4, armv6, mips, and x86/iommu all correctly check for the tag alignment <= maxsize as enabling simple uma/malloc based allocation. Powerpc, sparc64, x86/bounce, and arm64/bounce were all checking for alignment < maxsize; on those platforms when alignment was equal to the max size it would fall back to page-based allocators even for very small buffers. This change makes all platforms use the <= check. It should be noted that on all platforms other than arm[v6] and mips, this check is relying on undocumented behavior in malloc(9) that if you allocate a block of a given size it will be aligned to the next larger power-of-2 boundary. There is nothing in the malloc(9) man page that makes that explicit promise (but the busdma code has been relying on this behavior all along so I guess it works). Arm and mips code uses the allocator in kern/subr_busdma_buffalloc.c, which does explicitly implement this promise about size and alignment. Other platforms probably should switch to the aligned allocator.
* Add support for weak symbols to the kernel linkers. It means thatkib2015-09-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | linkers no longer raise an error when undefined weak symbols are found, but relocate as if the symbol value was 0. Note that we do not repeat the mistake of userspace dynamic linker of making the symbol lookup prefer non-weak symbol definition over the weak one, if both are available. In fact, kernel linker uses the first definition found, and ignores duplicates. Signature of the elf_lookup() and elf_obj_lookup() functions changed to split result/error code and the symbol address returned. Otherwise, it is impossible to return zero address as the symbol value, to MD relocation code. This explains the mechanical changes in elf_machdep.c sources. The powerpc64 R_PPC_JMP_SLOT handler did not checked error from the lookup() call, the patch leaves the code as is (untested). Reported by: glebius Sponsored by: The FreeBSD Foundation MFC after: 1 week
* - Sanity check that the parent ranges given in the "ranges" propertymarius2015-09-131-11/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | of PCI-EBus-bridges actually match the BARs as specified in and required by [1, p. 113 f.]. Doing so earlier would have simplified diagnosing a bug in QEMU/OpenBIOS getting the mapping of child addresses wrong, which still needs to be fixed there. In theory, we could try to change the BARs accordingly if we hit this problem. However, at least with real machines changing the decoding likely won't work, especially if the PCI-EBus-bridge is beneath an APB one. So implementing such functionality generally is rather pointless. - Actually change the allocation type of EBus resources if they change from SYS_RES_MEMORY to SYS_RES_IOPORT when mapping them to PCI ranges in ebus_alloc_resource() and passing them up to bus_activate_resource(9). This may happen with the QEMU/OpenBIOS PCI-EBus-bridge but not real ones. Still, this is only cleans up the code and the result of resource allocation and activation is unchanged. - Change the remainder of printf(9) to device_printf(9) calls and canonicalize their wording. MFC after: 1 week Peripheral Component Interconnect Input Output Controller, Part No.: 802-7837-01, Sun Microelectronics, March 1997 [1]
* Merge r286374 from x86:marius2015-09-131-9/+11
| | | | | | | | Formally pair store_rel(&smp_started) with load_acq(&smp_started). Similarly to x86, this change is mostly a NOP due to the kernel being run in total store order. MFC after: 1 week
* - Factor out the common and generic parts of the sparc64 host-PCI-bridgemarius2015-09-1211-966/+614
| | | | | | | | | | | | drivers into the revived sys/sparc64/pci/ofw_pci.c, previously already serving a similar purpose. This has been done with sun4v in mind, which explains a) the otherwise not that obvious scheme employed and b) why reusing sys/powerpc/ofw/ofw_pci.c was even lesser an option. - Add a workaround for QEMU once again not emulating real machines, in this case by not providing the OFW_PCI_CS_MEM64 range. [1] Submitted by: jhb [1] MFC after: 1 week
* Add stack_save_td_running(), a function to trace the kernel stack of amarkj2015-09-111-0/+7
| | | | | | | | | | | | | | | | | running thread. It is currently implemented only on amd64 and i386; on these architectures, it is implemented by raising an NMI on the CPU on which the target thread is currently running. Unlike stack_save_td(), it may fail, for example if the thread is running in user mode. This change also modifies the kern.proc.kstack sysctl to use this function, so that stacks of running threads are shown in the output of "procstat -kk". This is handy for debugging threads that are stuck in a busy loop. Reviewed by: bdrewery, jhb, kib Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D3256
OpenPOWER on IntegriCloud