summaryrefslogtreecommitdiffstats
path: root/sys/sparc64
Commit message (Collapse)AuthorAgeFilesLines
* Minor sync to alpha and i386:jhb2004-12-301-1/+4
| | | | | - Add ADAPTIVE_GIANT and AHC_REG_PRETTY_PRINT. - Indent SMP to match other options.
* Identify USIIIi processors.scottl2004-12-242-0/+4
| | | | | Submitted by: Gavin Atkinson PR: 75468
* Modify pmap_enter_quick() so that it expects the page queues to be lockedalc2004-12-231-2/+0
| | | | | | | | | | | on entry and it assumes the responsibility for releasing the page queues lock if it must sleep. Remove a bogus comment from pmap_enter_quick(). Using the first change, modify vm_map_pmap_enter() so that the page queues lock is acquired and released once, rather than each time that a page is mapped.
* In the common case, pmap_enter_quick() completes without sleeping.alc2004-12-151-0/+8
| | | | | | | | | | | | | | | | | | In such cases, the busying of the page and the unlocking of the containing object by vm_map_pmap_enter() and vm_fault_prefault() is unnecessary overhead. To eliminate this overhead, this change modifies pmap_enter_quick() so that it expects the object to be locked on entry and it assumes the responsibility for busying the page and unlocking the object if it must sleep. Note: alpha, amd64, i386 and ia64 are the only implementations optimized by this change; arm, powerpc, and sparc64 still conservatively busy the page and unlock the object within every pmap_enter_quick() call. Additionally, this change is the first case where we synchronize access to the page's PG_BUSY flag and busy field using the containing object's lock rather than the global page queues lock. (Modifications to the page's PG_BUSY flag and busy field have asserted both locks for several weeks, enabling an incremental transition.)
* Pass VM_ALLOC_NOBUSY to vm_page_grab() so that we don't have to callalc2004-12-111-2/+1
| | | | | vm_page_flag_clear(PG_BUSY). The object lock is held the entire time. Thus, whether or not the PG_BUSY flag is set is invisible to others.
* PNP BIOS devices are fundamentally different than ISA PNP devices.imp2004-12-071-1/+1
| | | | | | | These devices should be probed first because they are at fixed locations and cannot be turned off. ISA PNP devices, on the other hand, can be turned off and often can be flexible in the resources they use. Probe them last, as always.
* Change gdb_cpu_setreg() to not take the value to which to set themarcel2004-12-012-2/+2
| | | | | | | | | | | | | | | | | | | | | specified register, but a pointer to the in-memory representation of that value. The reason for this is twofold: 1. Not all registers can be represented by a register_t. In particular FP registers fall in that category. Passing the new register value by reference instead of by value makes this point moot. 2. When we receive a G or P packet, both are for writing a register, the packet will have the register value in target-byte order and in the memory representation (modulo the fact that bytes are sent as 2 printable hexadecimal numbers of course). We only need to decode the packet to have a pointer to the register value. This change fixes the bug of extracting the register value of the P packet as a hexadecimal number instead of as a bit array. The quick (and dirty) fix to bswap the register value in gdb_cpu_setreg() as it has been added on i386 and amd64 can therefore be removed and has in fact been that. Tested on: alpha, amd64, i386, ia64, sparc64
* Don't include sys/user.h merely for its side-effect of recursivelydas2004-11-275-6/+4
| | | | including other headers.
* Remove references to U area and garbage collect includes.das2004-11-201-2/+0
| | | | Reviewed by: arch@
* Remove UAREA_PAGES.das2004-11-201-1/+0
| | | | Reviewed by: arch@
* U areas are going away, so don't allocate one for process 0.das2004-11-201-3/+0
| | | | Reviewed by: arch@
* Add a front-end for the `rtc' device which is a MC146818 compatiblemarius2004-11-173-0/+185
| | | | | | | | clock found on the ISA bus (some USIIe, USIIi and USIIIi models) and EBus (USIII models) instead of a MK48Txx clock. Testet by: Matthew T. Lager" <freebsd@trinetworks.com> on Sun Fire V100, Xavier Beaudouin <kiwi@oav.net> on Netra X1 (initial version)
* o sparc64/isa/isa.c:marius2004-11-171-112/+186
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c etc. that UARTs are the only relevant ISA devices on sparc64 turned out to be false. While there are sparc64 models where UARTs are the only devices on the ISA bus there are in fact also low-cost models where all devices traditionally found on the EBus are hooked up to the ISA bus. There are also models that use a mix between EBus and ISA devices with things like an AT keyboard controller and other rather interesting devices that we might want to support in the futute hook up to the ISA bus. In order to not need to add sparc64 specific device_identify methods to all of the respective ISA drivers and also not add OFW specific code to the common ISA code make the sparc64 ISA bus code fake up PnP devices so most ISA drivers probe their devices without further changes. Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE 1275-1994 for the properties of most of the ISA devices which would allow to obtain the vendor and logical IDs from their properties. So we we just use a simple table which maps the name properties to PnP IDs. This could be done in a more sophisticated way but I courrently don't see the need for this. [1] - Add the children with fully mapped and specified resources (in the OFW sense) similar to what is done in the EBus code for the IRQ resources of the children as adjusting the resources and the resource list entries respectively in isa_alloc_resource() as done perviously causes trouble with drivers which use rman_get_start(), pass-through or allocate and release resources multiple times, etc. Adjusting the resources might be better off in a bus_activate_resource method but the common ISA code currently doesn't allow for an isa_activate_resource(). [2] With this change: - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires real ISADMA code but it currently only consists of stubs on sparc64). - atkbdc(4) and atkbdc(4) attach, no further testing done. - fdc(4) itself attaches but causes a hang while attaching fd0 also when is DMA disabled, further work in fdc(4) is required here as e.g. fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports more than one floppy drive at all). All of these drivers previously caused panics in the sparc64 ISA code. - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and declare one global variable which isn't used outside of isa.c static. o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile: - Remove the code for registering the UARTs on the ISA bus from the sparc64 uart_cpu_identify() again and rely on probing them via PnP. Original idea by: tmm [1] No objections by: tmm [1], [2]
* Shorten the description of the mk48txx driver to just say that it supportsmarius2004-11-172-2/+2
| | | | MK48Txx clocks, there are now to many models supported to list them all here.
* o Sync with the NetBSD mk48txx driver (the result simplyfies some changesmarius2004-11-174-44/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | I have in mind for the genclock interface): - Recognize the MK48T18 as well (differs from the MK48T08 only in packaging options and voltages). - Allow MD code to provide functions for reading/writing NVRAM/RTC locations. If passed NULL, the old behaviour using bus_space_{read,write}_1() is used. Otherwise, all access to the chip goes via the MD functions. This is necessary for mvmeppc boards where the mk48txx NVRAM/RTC is not directly addressable. - Cleanup MI mk48txx(4) todclock driver: - Prepare mk48txxvar.h and leave only register definitions in mk48txxreg.h. - Define struct mk48txx_softc as usual devices and allocate necessary members in it. - Change mk48txx_attach() to only take a device_t. o While converting the sparc64 eeprom driver to the above changes: - Remove some dead code and stale comments. - Use the NVRAM size provided by the mk48txx driver instead of hardcoding it as suggested by a comment. - Add a comment about why it doesn't make much sense to read the hostid directly from the NVRAM except for displaying it when attaching. - Don't print the hostid if it reads all zero because it's stored elsewhere.
* Catch up with version 600000 of config(8), quotes around device namesmarius2004-11-172-17/+17
| | | | containing digits are no longer required.
* Fix paths after repocopies done by scottltrhodes2004-11-101-2/+2
| | | | | Reviewed by: marius OK'ed by: scottl
* Correct a typo in the previous revision.alc2004-11-081-1/+1
|
* Introduce two new options, "CPU private" and "no wait", to sf_buf_alloc().alc2004-11-081-3/+5
| | | | | | Change the spelling of the "catch" option to be consistent with the new options. Implement the "no wait" option. An implementation of the "CPU private" for i386 will be committed at a later date.
* The synchronization provided by vm object locking has eliminated thealc2004-11-031-1/+0
| | | | | | | | | | | | | | | | | need for most calls to vm_page_busy(). Specifically, most calls to vm_page_busy() occur immediately prior to a call to vm_page_remove(). In such cases, the containing vm object is locked across both calls. Consequently, the setting of the vm page's PG_BUSY flag is not even visible to other threads that are following the synchronization protocol. This change (1) eliminates the calls to vm_page_busy() that immediately precede a call to vm_page_remove() or functions, such as vm_page_free() and vm_page_rename(), that call it and (2) relaxes the requirement in vm_page_remove() that the vm page's PG_BUSY flag is set. Now, the vm page's PG_BUSY flag is set only when the vm object lock is released while the vm page is still in transition. Typically, this is when it is undergoing I/O.
* Reduce annoying SCSI probing delay from 15 to 5 seconds in all GENRIC kernels.andre2004-11-021-1/+1
| | | | Discussed on: -current
* - Change the ddb paging "support" to use a variable (db_lines_per_page) tojhb2004-11-011-1/+1
| | | | | | | | | | | | | | | | | control the number of lines per page rather than a constant. The variable can be examined and changed in ddb as '$lines'. Setting the variable to 0 will effectively turn off paging. - Change db_putchar() to force out pending whitespace before outputting newlines and carriage returns so that one can rub out content on the current line via '\r \r' type strings. - Change the simple pager to rub out the --More-- prompt explicitly when the routine exits. - Add some aliases to the simple pager to make it more compatible with more(1): 'e' and 'j' do a single line. 'd' does half a page, and 'f' does a full page. MFC after: 1 month Inspired by: kris
* Device driver for onboard CS4231 audio controller which is foundyongari2004-10-253-1/+181
| | | | | | | | | | | | | | | on UltraSPARC workstations. The driver is based on OpenBSD's SBus cs4231 driver and heavily modified to incorporate into sound(4) infrastructure. Due to the lack of APCDMA documentation, the DMA code of SBus cs4231 came from OpenBSD's driver. The driver runs without Giant lock and supports both SBus and EBus based CS4231 audio controller. Special thanks to marius for providing feedbacks during the driver writing. His feedback made it possible to write hiccup free playback code under high system loads. Approved by: jake (mentor) Reviewed by: marius (initial version) Tested by: marius, kwm, Julian C. Dunn(jdunn AT opentrend DOT net)
* Flush the register windows before we start changing the context.kensmith2004-10-091-0/+2
| | | | | Submitted by: Andrew Belashov <bel (at) orel.ru> (slightly modified) Reviewed by: jake
* Port NetBSD auxio driver. The driver was modified to use led(4) and canyongari2004-10-092-0/+2
| | | | | | | | | | | be used to announce various system activity. The auxio device provides auxiliary I/O functions and is found on various SBus/EBus UltraSPARC models. At present, only front panel LED is controlled by this driver. Approved by: jake (mentor) Reviewed by: joerg Tested by: joerg
* This along with v1.6 of counter.c fixes some timecounter issues onkensmith2004-09-301-0/+19
| | | | | | | | | | | | | | | MP machines (hopefully). CPU timers are OK on UP machines but we don't keep the timers in sync on MP machines so if the CPU's timer is chosen as the primary timecounter it's possible for time to not be monotonically increasing because different CPU's counters may be used at different times. But the CPU's counters are otherwise one of the higher quality counters available. So, on UP machines we'll use a relatively high quality value but on MP machines we'll use a quality that should prevent the CPU's counters from being chosen. Requested by: green (who did the first version of the patch) Reviewed by: marius, green MFC after: 1 week
* Set the tc_quality field of the struct before calling tc_init(), sincekensmith2004-09-301-0/+2
| | | | | | | | | | | the structure space had been obtained from malloc() its contents is random garbage. The choice of value being set is part of a larger effort to solve some timecounter issues on MP machines (while working on that we noticed this problem). Noticed by: marius Reviewed by: marius, green MFC after: 3 days
* We seem to have occasions where sending an IPI takes significantlykensmith2004-09-291-1/+1
| | | | | | | | | | | longer than 'normal'. The cause is still being tracked down but in the meantime there are machines where raising IPI_RETRIES does help - it's not just a case of the machine staying locked up longer and then panic-ing anyway. Several helpful folks on sparc64@ tried a patch that helped figure out what to raise this number to. Discussed on: sparc64@ MFC after: 3 days
* Add an assertion that the pcb_nsaved field of the pcb be less thankensmith2004-09-281-0/+2
| | | | | | | | | MAXWIN to the register window manipulation functions - rwindow_load() calls rwindow_save() so this one addition should take care of both. This should help find places that pcb_nsaved doesn't get initialized properly. Suggested by: jake
* Some minor print/panic message cleanups.kensmith2004-09-271-3/+3
|
* Initialize the count of saved register windows to 0 in the pcb createdkensmith2004-09-271-0/+1
| | | | | | | | | | | for the new thread. The rest of the fields in the pcb wind up being written to before they're read as a normal part of the pcb usage but this field may be read upon return to userland, having it be uninitialized garbage is bad. Submitted by: Andrew Belashov (bel at orel dot ru) Reviewed by: jake MFC after: 3 days
* - Add support for "paging" in stack trace output. That is, when you dojhb2004-09-201-6/+9
| | | | | | | | | | | | | a stack trace from ddb, the output will pause with a '--More--' prompt every 18 lines. If you hit Enter, it will print another line and prompt again. If you hit space it will output another page and then prompt. If you hit 'q' or 'x' it will abort the rest of the stack trace. - Fix the sparc64 userland stack trace to honor the total count of lines to print. This is useful if your trace happens to walk back onto 0xdeadc0de and gets stuck in an endless loop. MFC after: 1 month Tested on: i386, alpha, sparc64
* Better fix the busdma problem exposed by ATA. With the CMD 646 formarcel2004-09-101-1/+5
| | | | | | | | | | example the maximum segment size is 64K while the boundary is set to 8K due to controller limitations. It is impossible to NOT cross the boundary for any segment size that's larger than the boundary. So, once we inherited the boundary from the parent tag, make sure to reduce the maximum segment size to the boundary if it was larger. MT5 candidate.
* sparc64 is not ready for PREEMPTION, so turn it off for now.scottl2004-09-091-1/+1
|
* Fix a problem with tag->boundary inheritence that has existed since day onescottl2004-09-081-6/+5
| | | | | | | | | | | | | | and was propagated to nearly every platform. The boundary of the child needs to consider the boundary of the parent and pick the minimum of the two, not the maximum. However, if either is 0 then pick the appropriate one. This bug was exposed by a recent change to ATA, which should now be fixed by this change. The alignment and maxsegsz tag attributes likely also need a similar review in the near future. This is a MT5 candidate. Reviewed by: marcel Submitted by: sos (in part)
* Switch the default scheduler to 4BSD to match what will go into RELENG_5 soon.scottl2004-09-071-1/+3
| | | | | | | It can be switched back once 5.3 is tested and released. Also turn on PREEMPTION as many of the stability problems with it have been fixed. MT5: 3 days.
* Refactor a bunch of scheduler code to give basically the same behaviourjulian2004-09-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | but with slightly cleaned up interfaces. The KSE structure has become the same as the "per thread scheduler private data" structure. In order to not make the diffs too great one is #defined as the other at this time. The KSE (or td_sched) structure is now allocated per thread and has no allocation code of its own. Concurrency for a KSEGRP is now kept track of via a simple pair of counters rather than using KSE structures as tokens. Since the KSE structure is different in each scheduler, kern_switch.c is now included at the end of each scheduler. Nothing outside the scheduler knows the contents of the KSE (aka td_sched) structure. The fields in the ksegrp structure that are to do with the scheduler's queueing mechanisms are now moved to the kg_sched structure. (per ksegrp scheduler private data structure). In other words how the scheduler queues and keeps track of threads is no-one's business except the scheduler's. This should allow people to write experimental schedulers with completely different internal structuring. A scheduler call sched_set_concurrency(kg, N) has been added that notifies teh scheduler that no more than N threads from that ksegrp should be allowed to be on concurrently scheduled. This is also used to enforce 'fainess' at this time so that a ksegrp with 10000 threads can not swamp a the run queue and force out a process with 1 thread, since the current code will not set the concurrency above NCPU, and both schedulers will not allow more than that many onto the system run queue at a time. Each scheduler should eventualy develop their own methods to do this now that they are effectively separated. Rejig libthr's kernel interface to follow the same code paths as linkse for scope system threads. This has slightly hurt libthr's performance but I will work to recover as much of it as I can. Thread exit code has been cleaned up greatly. exit and exec code now transitions a process back to 'standard non-threaded mode' before taking the next step. Reviewed by: scottl, peter MFC after: 1 week
* Remove an unneeded argument..julian2004-08-311-1/+1
| | | | | | | | | The removed argument could trivially be derived from the remaining one. That in turn should be the same as curthread, but it is possible that curthread could be expensive to derive on some syste,s so leave it as an argument. Having both proc and thread as an argumen tjust gives an opportunity for them to get out sync. MFC after: 3 days
* Remove sched_free_thread() which was only usedjulian2004-08-311-6/+0
| | | | | | | | in diagnostics. It has outlived its usefulness and has started causing panics for people who turn on DIAGNOSTIC, in what is otherwise good code. MFC after: 2 days
* Move the kernel-specific logic to adjust frompc from MI to MD. Formarcel2004-08-271-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | these two reasons: 1. On ia64 a function pointer does not hold the address of the first instruction of a functions implementation. It holds the address of a function descriptor. Hence the user(), btrap(), eintr() and bintr() prototypes are wrong for getting the actual code address. 2. The logic forces interrupt, trap and exception entry points to be layed-out contiguously. This can not be achieved on ia64 and is generally just bad programming. The MCOUNT_FROMPC_USER macro is used to set the frompc argument to some kernel address which represents any frompc that falls outside the kernel text range. The macro can expand to ~0U to bail out in that case. The MCOUNT_FROMPC_INTR macro is used to set the frompc argument to some kernel address to represent a call to a trap or interrupt handler. This to avoid that the trap or interrupt handler appear to be called from everywhere in the call graph. The macro can expand to ~0U to prevent adjusting frompc. Note that the argument is selfpc, not frompc. This commit defines the macros on all architectures equivalently to the original code in sys/libkern/mcount.c. People can take it from here... Compile-tested on: alpha, amd64, i386, ia64 and sparc64 Boot-tested on: i386
* Always compile PFIL_HOOKS into the kernel and remove the associated kernelandre2004-08-271-1/+0
| | | | | | | | | | | compile option. All FreeBSD packet filters now use the PFIL_HOOKS API and thus it becomes a standard part of the network stack. If no hooks are connected the entire packet filter hooks section and related activities are jumped over. This removes any performance impact if no hooks are active. Both OpenBSD and DragonFlyBSD have integrated PFIL_HOOKS permanently as well.
* Properly free the temporary sf_buf in uiomove_fromphys() if a copyin oralc2004-08-211-1/+4
| | | | | | copyout fails. Obtained from: DragonFlyBSD
* - Sync whitespace and comments with i386 GENERIC.marius2004-08-161-53/+65
| | | | | | | | | | | - Add some commented out NICs from i386 GENERIC. Most of them look like they would work but I'm not sure if they are endian-clean and can't test. There was a report that sk(4) works on sparc64 but it doesn't look like it would because it doesn't use busdma. - Improve some of the descriptions of sparc64 specific devices. There's no functional change, i.e. no added or deleted uncommented devices or options, in this commit.
* Try to catch up with reality:marius2004-08-161-30/+38
| | | | | | | | | | | - Chase the split of pcm(4). This unbreaks LINT compiles. - sc(4) basically works and a lot of its options should be supported. - Add the creator and ofw_console drivers. - vinum(4) should work, at least its module was turned on for sparc64 a while ago. - Don't build sio(4). Its EBus front-end was removed a while ago and the ISA one hardly works. Use uart(4) instead, it's not perfect yet but works much better.
* Instead of "OpenFirmware", "openfirmware", etc. use the official spellingmarius2004-08-165-9/+9
| | | | | | "Open Firmware" from IEEE 1275 and OpenFirmware.org (no pun intended). Ok'ed by: tmm
* Correct some uses of the wrong members of the *min()/*max()-familiy, e.g.marius2004-08-153-5/+5
| | | | | | min() on unsigned long. None of these are believed to have been fatal though. Reviewed by: tmm
* - Make OF_getetheraddr() honour the "local-mac-address?" system configmarius2004-08-142-12/+11
| | | | | | | | | | | | | | | variable. If set to "true" OF_getetheraddr() will now return the unique MAC address stored in the "local-mac-address" property of the device's OFW node if present and the host address/system default MAC address if the node doesn't doesn't have such a property. If set to "false" the host address will be returned for all devices like before this change. This brings the behaviour of device drivers for NICs with OFW support/ FCode, i.e. dc(4) for on-board DM9102A on Sun machines, gem(4) and hme(4), regarding "local-mac-address?" in line with NetBSD and Solaris. The man pages of the respective drivers will be updated separately to reflect this change. - Remove OF_getetheraddr2() which was used as a stopgap in dc(4). Its functionality is now part of OF_getetheraddr().
* Add pmap locking to pmap_remove_all().alc2004-08-131-0/+2
|
* - Introduce an ofw_bus kobj-interface for retrieving the OFW node and amarius2004-08-1225-527/+398
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subset ("compatible", "device_type", "model" and "name") of the standard properties in drivers for devices on Open Firmware supported busses. The standard properties "reg", "interrupts" und "address" are not covered by this interface because they are only of interest in the respective bridge code. There's a remaining standard property "status" which is unclear how to support properly but which also isn't used in FreeBSD at present. This ofw_bus kobj-interface allows to replace the various (ebus_get_node(), ofw_pci_get_node(), etc.) and partially inconsistent (central_get_type() vs. sbus_get_device_type(), etc.) existing IVAR ones with a common one. This in turn allows to simplify and remove code-duplication in drivers for devices that can hang off of more than one OFW supported bus. - Convert the sparc64 Central, EBus, FHC, PCI and SBus bus drivers and the drivers for their children to use the ofw_bus kobj-interface. The IVAR- interfaces of the Central, EBus and FHC are entirely replaced by this. The PCI bus driver used its own kobj-interface and now also uses the ofw_bus one. The IVARs special to the SBus, e.g. for retrieving the burst size, remain. Beware: this causes an ABI-breakage for modules of drivers which used the IVAR-interfaces, i.e. esp(4), hme(4), isp(4) and uart(4), which need to be recompiled. The style-inconsistencies introduced in some of the bus drivers will be fixed by tmm@ in a generic clean-up of the respective drivers later (he requested to add the changes in the "new" style). - Convert the powerpc MacIO bus driver and the drivers for its children to use the ofw_bus kobj-interface. This invloves removing the IVARs related to the "reg" property which were unused and a leftover from the NetBSD origini of the code. There's no ABI-breakage caused by this because none of these driver are currently built as modules. There are other powerpc bus drivers which can be converted to the ofw_bus kobj-interface, e.g. the PCI bus driver, which should be done together with converting powerpc to use the OFW PCI code from sparc64. - Make the SBus and FHC front-end of zs(4) and the sparc64 eeprom(4) take advantage of the ofw_bus kobj-interface and simplify them a bit. Reviewed by: grehan, tmm Approved by: re (scottl) Discussed with: tmm Tested with: Sun AX1105, AXe, Ultra 2, Ultra 60; PPC cross-build on i386
* Add __elfN(dump_thread). This function is called from __elfN(coredump)marcel2004-08-111-0/+8
| | | | | | | | | to allow dumping per-thread machine specific notes. On ia64 we use this function to flush the dirty registers onto the backingstore before we write out the PRSTATUS notes. Tested on: alpha, amd64, i386, ia64 & sparc64 Not tested on: arm, powerpc
OpenPOWER on IntegriCloud