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.
Testing by: fjoe
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
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.
PR: 28418, 25958
Tested by: jkh, Christopher Masto <chris@netmonger.net>
MFC after: 2 weeks
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.
PR: 28418, 25958
Tested by: jkh, Christopher Masto <chris@netmonger.net>
MFC after: 2 weeks
the .mc file used for /etc/mail/submit.cf. By default,
/etc/mail/freebsd.submit.mc is installed and used.
Requested by: fenner
Submitted by: ume
MFC after: 1 week
it with FreeBSD/alpha.
Pictures of DS20L will be available soon at
http://people.freebsd.org/~wilko/Alpha-gallery/
Along with pictures of a ES80 'Marvel' EV7 box (which we don't support
yet :-P )
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.
MFC after: 1 week
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.
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>
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.
MFC after: 1 week
