John Baldwin [Mon, 15 Apr 2002 19:16:37 +0000 (19:16 +0000)]
Use bus_addr_t instead of u_int for local variables that are derived from
the per-channel bus_addr_t offset. Also, cast the offset to (long long)
and use %#llx instead of %#x to fix printf warnings on architectures where
sizeof(bus_addr_t) != sizeof(int).
Peter Wemm [Mon, 15 Apr 2002 16:07:52 +0000 (16:07 +0000)]
Fix an "oops!" that turned out to be mostly harmless (but gave a warning).
I did this right on the sparc64. Store the direct mapped addresses in
the correct variables.
Peter Wemm [Mon, 15 Apr 2002 16:00:03 +0000 (16:00 +0000)]
Pass vm_page_t instead of physical addresses to pmap_zero_page[_area]()
and pmap_copy_page(). This gets rid of a couple more physical addresses
in upper layers, with the eventual aim of supporting PAE and dealing with
the physical addressing mostly within pmap. (We will need either 64 bit
physical addresses or page indexes, possibly both depending on the
circumstances. Leaving this to pmap itself gives more flexibilitly.)
Reviewed by: jake
Tested on: i386, ia64 and (I believe) sparc64. (my alpha was hosed)
Apply the change as a continuous slew rather than as a series of
discrete steps and make it possible to adjust arbitraryly huge
amounts of time in either direction.
In practice this is done by hooking into the same once-per-second
loop as the NTP PLL and setting a suitable frequency offset deducting
the amount slewed from the remainder. If the remaining delta is
larger than 1 second we slew at 5000PPM (5msec/sec), for a delta
less than a second we slew at 500PPM (500usec/sec) and for the last
one second period we will slew at whatever rate (less than 500PPM)
it takes to eliminate the delta entirely.
The old implementation stepped the clock a number of microseconds
every HZ to acheive the same effect, using the same rates of change.
Eliminate the global variables tickadj, tickdelta and timedelta and
their various use and initializations.
This removes the most significant obstacle to running timecounter and
NTP housekeeping from a timeout rather than hardclock.
Take the "tickadj" element out of struct clockinfo. Our adjtime(2)
implementation is being changed and the very concept of tickadj will
no longer be meaningful.
Basic OpenFirmware disk driver. It will attach to anything in OpenFirmware
that declares itself to be a disk, which may be the wrong thing to do in
the long term but it works well enough to attach to emulated disks in the
PowerPC simulator in gdb now that they have the proper device_type
property.
Jeff Roberson [Mon, 15 Apr 2002 05:24:01 +0000 (05:24 +0000)]
Finish adding support code for sysctl kern.mprof. This dumps some malloc
information related to bucket size effeciency. Three things are printed on
each row:
Size is the size the user actually asked for rounded to 16 bytes.
Requests is the number of times this size was asked for.
Real Size is the size we actually handed out.
At the end the total memory used and total waste is displayed. Currently my
system displays about 33% wasted memory.
The intent of this code is to gather statistics for tuning the malloc bucket
sizes. It is not intended to be run with INVARIANTS and it is not entirely
mp safe. It can be enabled via 'options MALLOC_PROFILE' which was commited
earlier.
Jeff Roberson [Mon, 15 Apr 2002 04:05:53 +0000 (04:05 +0000)]
Remove malloc_type's ks_limit.
Updated the kmemzones logic such that the ks_size bitmap can be used as an
index into it to report the size of the zone used.
Create the kern.malloc sysctl which replaces the kvm mechanism to report
similar data. This will provide an easy place for statistics aggregation if
malloc_type statistics become per cpu data.
Add some code ifdef'd under MALLOC_PROFILING to facilitate a tool for sizing
the malloc buckets.
Jeff Roberson [Mon, 15 Apr 2002 03:35:35 +0000 (03:35 +0000)]
Don't peak into the malloc_type structure for limits. The desired vnodes
check should be sufficient. This is required for the pending removal of
malloc_type limits.
David E. O'Brien [Mon, 15 Apr 2002 03:15:40 +0000 (03:15 +0000)]
Turn off collect2.
collect2 was added based on the need of -frepo. However, -frepo is currently
broken on -CURRENT (Gcc 2.95.4 20020320 [FreeBSD] / ld 2.12.0 [FreeBSD]
2002-04-10). It is also broken on RELENG_4 (Gcc 2.95.3 20010315 / ld
2.11.2 20010719), so there is no need to MFC collect2 there yet. I have
a feeling the brokeness is due to the wide difference between the libiberty
bits of Gcc 2.95 and the later ld.
Dike out most of the NIS code and replace it with calls to libypclnt.
Rework pam_sm_chauthtok() so it (mostly?) works.
The standard pw stuff still needs to move into a library somewhere.
Tom Rhodes [Mon, 15 Apr 2002 02:05:06 +0000 (02:05 +0000)]
a.out.5 states that nobody seems to agree on what bss stands for. This is
incorrect, however, as Dennis Ritchie states ``Actually the acronym is "block
started by symbol." It was a pseudo-op in FAP (Fortran Assembly Program), an
assembler for the IBM <models> machines. It identified its label and set
aside space for a given number of words.''
PR: 34088
Submitted by: Martin Faxer <gmh003532@brfmasthugget.se>
MFC after: 2 days
Skip zombies. Add an option (-z) to revert to the historical behaviour
of trying to kill zombies (which has no effect except emit a few error
messages)
David Malone [Sun, 14 Apr 2002 20:19:13 +0000 (20:19 +0000)]
Make the MTRR code a bit more defensive - this should help people
trying to run X on some Athlon systems where the BIOS does odd things
(mines an ASUS A7A266, but it seems to also help on other systems).
Here's a description of the problem and my fix:
The problem with the old MTRR code is that it only expects
to find documented values in the bytes of MTRR registers.
To convert the MTRR byte into a FreeBSD "Memory Range Type"
(mrt) it uses the byte value and looks it up in an array.
If the value is not in range then the mrt value ends up
containing random junk.
This isn't an immediate problem. The mrt value is only used
later when rewriting the MTRR registers. When we finally
go to write a value back again, the function i686_mtrrtype()
searches for the junk value and returns -1 when it fails
to find it. This is converted to a byte (0xff) and written
back to the register, causing a GPF as 0xff is an illegal
value for a MTRR byte.
To work around this problem I've added a new mrt flag
MDF_UNKNOWN. We set this when we read a MTRR byte which
we do not understand. If we try to convert a MDF_UNKNOWN
back into a MTRR value, then the new function, i686_mrt2mtrr,
just returns the old value of the MTRR byte. This leaves
the memory range type unchanged.
I have seen one side effect of the fix, which is that ACPI calls
after X has been run seem to hang my machine. As running X would
previously panic the machine, this is still an improvement ;-)
I'd like to MFC this before the 4.6 code freeze - please let me
know if it causes any problems.
David Malone [Sun, 14 Apr 2002 20:13:08 +0000 (20:13 +0000)]
Make the MTRR code a bit more defensive - this should help people
trying to run X on some Athlon systems where the BIOS does odd things
(mines an ASUS A7A266, but it seems to also help on other systems).
Here's a description of the problem and my fix:
The problem with the old MTRR code is that it only expects
to find documented values in the bytes of MTRR registers.
To convert the MTRR byte into a FreeBSD "Memory Range Type"
(mrt) it uses the byte value and looks it up in an array.
If the value is not in range then the mrt value ends up
containing random junk.
This isn't an immediate problem. The mrt value is only used
later when rewriting the MTRR registers. When we finally
go to write a value back again, the function i686_mtrrtype()
searches for the junk value and returns -1 when it fails
to find it. This is converted to a byte (0xff) and written
back to the register, causing a GPF as 0xff is an illegal
value for a MTRR byte.
To work around this problem I've added a new mrt flag
MDF_UNKNOWN. We set this when we read a MTRR byte which
we do not understand. If we try to convert a MDF_UNKNOWN
back into a MTRR value, then the new function, i686_mrt2mtrr,
just returns the old value of the MTRR byte. This leaves
the memory range type unchanged.
I'd like to merge this before the 4.6 code freeze, so if people
can test this with XFree 4 that would be very useful.
Provide a new make.conf knob, SENDMAIL_SUBMIT_MC to allow users to pick
the .mc file used for /etc/mail/submit.cf. By default,
/etc/mail/freebsd.submit.mc is installed and used.
Use 'struct callout' instead of 'struct callout_handle' to avoid
exhausting the kernel timeout table. Perform the usual gymnastics to
avoid race conditions between node shutdown and timeouts occurring.
Also fix a bug in handling ack delays < PPTP_MIN_ACK_DELAY. Before,
we were ack'ing immediately. Instead, just impose a minimum ack delay
time, like the name of the macro implies.
Jeff Roberson [Sun, 14 Apr 2002 13:47:10 +0000 (13:47 +0000)]
Fix a witness warning when expanding a hash table. We were allocating the new
hash while holding the lock on a zone. Fix this by doing the allocation
seperately from the actual hash expansion.
The lock is dropped before the allocation and reacquired before the expansion.
The expansion code checks to see if we lost the race and frees the new hash
if we do. We really never will lose this race because the hash expansion is
single threaded via the timeout mechanism.
Remove the hard-coded limit of 3 bytes for EUC encodings.
Satoshi NIIMI-san kindly explained that EUC does not limit the byte length to
any arbitrary number.
We now set the limit to the maximum octet length of the codeset and it is
locale-specific.
Submitted by: Yong-Jhen Hong <winard@ms11.url.com.tw>
John Hay [Sun, 14 Apr 2002 10:39:59 +0000 (10:39 +0000)]
Fix the play / record rate setting so that it actually works.
The extra microphone channel capability is part of the "normal" ac97
capabilities and not an extended ac97 capability. Now recording on
codecs without a seperate mic channel works.
projects / FreeBSD / FreeBSD.git / log