Searched hist:250 (Results 1 - 25 of 72) sorted by relevance

123

/freebsd-10.0-release/sys/sparc64/include/
H A Dmcntl.h207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
H A Dasi.hdiff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
diff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
H A Dcache.hdiff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
diff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
/freebsd-10.0-release/usr.bin/setchannel/
H A DMakefile165023 Sat Dec 09 00:27:45 MST 2006 grog Set channel utility for Hauuapuge PVR-250 and PVR-350.

This s part of an import of the PVR-250 driver. Originally it was
calleed pvr250-setchannel, but it seems better to improve this program
to work for any tuner card, so I'm starting with a more generic name.
That shouldn't mislead anybody: currently the program only works with
the (yet to be committed) cxm driver.

Contributed by: John Wehle <john\@feith.com>
165023 Sat Dec 09 00:27:45 MST 2006 grog Set channel utility for Hauuapuge PVR-250 and PVR-350.

This s part of an import of the PVR-250 driver. Originally it was
calleed pvr250-setchannel, but it seems better to improve this program
to work for any tuner card, so I'm starting with a more generic name.
That shouldn't mislead anybody: currently the program only works with
the (yet to be committed) cxm driver.

Contributed by: John Wehle <john\@feith.com>
H A Dsetchannel.1165023 Sat Dec 09 00:27:45 MST 2006 grog Set channel utility for Hauuapuge PVR-250 and PVR-350.

This s part of an import of the PVR-250 driver. Originally it was
calleed pvr250-setchannel, but it seems better to improve this program
to work for any tuner card, so I'm starting with a more generic name.
That shouldn't mislead anybody: currently the program only works with
the (yet to be committed) cxm driver.

Contributed by: John Wehle <john\@feith.com>
165023 Sat Dec 09 00:27:45 MST 2006 grog Set channel utility for Hauuapuge PVR-250 and PVR-350.

This s part of an import of the PVR-250 driver. Originally it was
calleed pvr250-setchannel, but it seems better to improve this program
to work for any tuner card, so I'm starting with a more generic name.
That shouldn't mislead anybody: currently the program only works with
the (yet to be committed) cxm driver.

Contributed by: John Wehle <john\@feith.com>
H A Dsetchannel.c165023 Sat Dec 09 00:27:45 MST 2006 grog Set channel utility for Hauuapuge PVR-250 and PVR-350.

This s part of an import of the PVR-250 driver. Originally it was
calleed pvr250-setchannel, but it seems better to improve this program
to work for any tuner card, so I'm starting with a more generic name.
That shouldn't mislead anybody: currently the program only works with
the (yet to be committed) cxm driver.

Contributed by: John Wehle <john\@feith.com>
165023 Sat Dec 09 00:27:45 MST 2006 grog Set channel utility for Hauuapuge PVR-250 and PVR-350.

This s part of an import of the PVR-250 driver. Originally it was
calleed pvr250-setchannel, but it seems better to improve this program
to work for any tuner card, so I'm starting with a more generic name.
That shouldn't mislead anybody: currently the program only works with
the (yet to be committed) cxm driver.

Contributed by: John Wehle <john\@feith.com>
/freebsd-10.0-release/share/man/man9/
H A Dconfig_intrhook.9162638 Mon Sep 25 18:12:13 MDT 2006 imp Document config_intrhook.

MFC After: 250 millifortnights
/freebsd-10.0-release/sys/sparc64/sparc64/
H A Dzeus.c207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
H A Didentcpu.cdiff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
diff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
H A Dcheetah.cdiff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
diff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
H A Dcache.cdiff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
diff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
H A Dmp_locore.Sdiff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
diff 207537 Sun May 02 17:49:27 MDT 2010 marius Add support for SPARC64 V (and where it already makes sense for other
HAL/Fujitsu) CPUs. For the most part this consists of fleshing out the
MMU and cache handling, it doesn't add pmap optimizations possible with
these CPU, yet, though.
With these changes FreeBSD runs stable on Fujitsu Siemens PRIMEPOWER 250
and likely also other models based on SPARC64 V like 450, 650 and 850.
Thanks go to Michael Moll for providing access to a PRIMEPOWER 250.
/freebsd-10.0-release/sys/conf/
H A Dldscript.powerpcdiff 38215 Mon Aug 10 05:53:59 MDT 1998 dfr Lots of changes, including:

* Support for AlphaStation 200, 250, 255, 400
* Untested support for UDB, Multia, AXPpci33 (Noname)
* Support for Personal Workstation 433a/433au, 500a/500au, 600a/600au (Miata)
* Some minor fixes and improvements to interrupt handling.

Submitted by: Andrew Gallatin <gallatin@cs.duke.edu> (AS200, Miata)
Obtained from: NetBSD (some code for AS200, Miata, Noname)
H A Dldscript.powerpc64diff 38215 Mon Aug 10 05:53:59 MDT 1998 dfr Lots of changes, including:

* Support for AlphaStation 200, 250, 255, 400
* Untested support for UDB, Multia, AXPpci33 (Noname)
* Support for Personal Workstation 433a/433au, 500a/500au, 600a/600au (Miata)
* Some minor fixes and improvements to interrupt handling.

Submitted by: Andrew Gallatin <gallatin@cs.duke.edu> (AS200, Miata)
Obtained from: NetBSD (some code for AS200, Miata, Noname)
/freebsd-10.0-release/sys/dev/agp/
H A Dagp_amd64.cdiff 152435 Mon Nov 14 19:54:20 MST 2005 jkim 0xb1881106 seems to be an AGP bridge and some BIOSes incorrectly handle
the bridge. Therefore, we give the same treatment as we did for nForce3-250
and ULi chipsets. VIA AGPv3 code was copied from agp_via.c.
diff 150645 Tue Sep 27 18:57:50 MDT 2005 jkim - Add a work-around for nForce3-250. Aperture base address encoded in misc.
control register and AGP bridge seems to be inconsistent with some BIOS.
Instead of relying on BIOS settings, we just take the initial aperture size
and encode them for both miscellaneous control register and AGP bridge.
Some idea was borrowed from agp_nvidia.c.

- Add preliminary ULi M1689 chipset support. The idea was taken from Linux
because hardware and documentation are unavailable. Not tested.

- Add more VIA chipset PCI IDs taken from Linux driver.

Approved by: anholt (mentor)
Tested by: Adam Gregoire <ebola at psychoholics dot org>
Ganael Laplanche <ganael.laplanche at martymac dot com>
K Wieland <kwieland at wustl dot edu>
diff 144809 Fri Apr 08 16:04:39 MDT 2005 obrien Add nForce3-250.
H A Dagpreg.hdiff 150645 Tue Sep 27 18:57:50 MDT 2005 jkim - Add a work-around for nForce3-250. Aperture base address encoded in misc.
control register and AGP bridge seems to be inconsistent with some BIOS.
Instead of relying on BIOS settings, we just take the initial aperture size
and encode them for both miscellaneous control register and AGP bridge.
Some idea was borrowed from agp_nvidia.c.

- Add preliminary ULi M1689 chipset support. The idea was taken from Linux
because hardware and documentation are unavailable. Not tested.

- Add more VIA chipset PCI IDs taken from Linux driver.

Approved by: anholt (mentor)
Tested by: Adam Gregoire <ebola at psychoholics dot org>
Ganael Laplanche <ganael.laplanche at martymac dot com>
K Wieland <kwieland at wustl dot edu>
/freebsd-10.0-release/games/fortune/datfiles/
H A Dmurphy-o60992 Sun May 28 02:41:02 MDT 2000 hoek Quoting submitter:

This is a recent conversion of an old IBM Mainframe application
to the fortune datafile format.

The "laws" were extracted from a S/370 Assembler program on a SHARE tape.
The comments in the program:

*---------------------------------------------------------------------*
* 'MURPHY' THE OLE PHILOSOPHER 18 AUGUST 1988 *
* *
* MURPHY WAS FOUND ON A JES2 TAPE OF ALL PLACES WITH ABOUT *
* 500 OR SO SAYINGS. GOT ANOTHER 250 FROM AN UNKNOWN SOURCE *
* AND HAVE ADDED ABOUT 100 OR SO MYSELF. *
* *
[list of changes omitted]
* *
* JIM MARSHALL, CAPT, USAF *
* (301) 688-6829 *
* *
*---------------------------------------------------------------------*

Fortunes that a sufficiently twisted mind could perceive as offensive
have been moved to murphy-o. Thanks to the submitter for reviewing
these fortunes.

The copyright issues were considered before approval.

PR: misc/8519
Submitted by: Cy Schubert (misc/8519)
Approved by: The Fortune Teller
H A Dmurphy60992 Sun May 28 02:41:02 MDT 2000 hoek Quoting submitter:

This is a recent conversion of an old IBM Mainframe application
to the fortune datafile format.

The "laws" were extracted from a S/370 Assembler program on a SHARE tape.
The comments in the program:

*---------------------------------------------------------------------*
* 'MURPHY' THE OLE PHILOSOPHER 18 AUGUST 1988 *
* *
* MURPHY WAS FOUND ON A JES2 TAPE OF ALL PLACES WITH ABOUT *
* 500 OR SO SAYINGS. GOT ANOTHER 250 FROM AN UNKNOWN SOURCE *
* AND HAVE ADDED ABOUT 100 OR SO MYSELF. *
* *
[list of changes omitted]
* *
* JIM MARSHALL, CAPT, USAF *
* (301) 688-6829 *
* *
*---------------------------------------------------------------------*

Fortunes that a sufficiently twisted mind could perceive as offensive
have been moved to murphy-o. Thanks to the submitter for reviewing
these fortunes.

The copyright issues were considered before approval.

PR: misc/8519
Submitted by: Cy Schubert (misc/8519)
Approved by: The Fortune Teller
/freebsd-10.0-release/lib/libstand/
H A Dbootp.cdiff 185643 Fri Dec 05 15:18:27 MST 2008 luigi Some libstand/bootp.c extension (written by Danny Braniss, slightly
revised/modified by me) to store dhcp options into kenv variables,
so the information is available to the boot loader and can be used
to customize the boot process.

The change is totally unintrusive, essentially made of a single
function to be called while parsing a dhcp response, and a couple
of tables to classify options. The values extracted from dhcp
options are stored in the kenv environment in one of these forms:

+ options whose name and type is known are saved as
dhcp.name = value (string, or number/ip addresses lists)

+ unknown options are assumed to be strings and saved as
dhcp.option-NNN = "value"

+ options listed as '__INDIR' and sent on the wire as e.g.
option unknown-252 "some.name=the actual value"
are saved as
some.name = "the actual value"

+ options listed as '__ILIST' and sent on the wire as e.g.
option unknown-249 "a.b=foo bar; c.d= 123; e.f=done"
are saved as multiple values
a.b="foo bar"
c.d="123"
e.f="done"

As you can see there is quite a bit of flexibility on what can
be passed to the loader or the kernel.

For the time being the vendor-specific table is mostly disabled,
because there is no standard set of options for FreeBSD, and I don't
know all the pxe-specific vendor options.

Also, applications using libstand may live in memory-constrained
environments, so it makes sense to keep these tables as small as
possible, especially considering that one can generate arbitrary
name=value pairs using site-specific options of type __INDIR or
__ILIST (there are 4 __ILIST and 5 __INDIR in the table, numbered
246..249 and 250..254).

Actually, considering that probably 75% of the standard dhcp options
are totally useless, it might make sense to remove them as well.

Submitted by: Danny Braniss
MFC after: 4 weeks
/freebsd-10.0-release/sys/i386/i386/
H A Delan-mmcr.cdiff 109327 Wed Jan 15 18:15:33 MST 2003 phk Add machdep.elan_freq sysctl which can be used to set the CPU clock
frequency in Hz. The default is still 33.333 MHz. Please notice
that the number is round to a multiple of four internally so it may
not read back exactly the same as written.

Add compile time ELAN_XTAL option to override the 33.333 MHz default.

Add compile time ELAN_PPS option to enable code for high precision
(250 nanoseconds) timestamping of external signals.
diff 102935 Wed Sep 04 17:52:17 MDT 2002 phk On the ElanSC520 CPU use general purpose timer#2 as timecounter.

This is a vast improvement over the i8254, since it is a simple
memory load rather than a comples sequence of interrupt blocking,
multiple input/output instructions, and wrap-around detection.

I have not bothered to time the fundamental timecounter get routine,
but gettimeofday(2) is 10% faster with the ELAN timecounte.

The downside is that HZ=100 is not enough, 150 or more recommended,
I use 250 myself.
/freebsd-10.0-release/usr.bin/tail/
H A Dforward.cdiff 140101 Wed Jan 12 02:06:31 MST 2005 brian Don't reprint file names unnecessarily.

PR: 75028
Submitted by: mteterin at 250-217 dot customer dot cloud9 dot net
MFC after: 7 days
diff 29402 Sun Sep 14 17:02:13 MDT 1997 phk In these days, waiting one full second for more to appear is far too long.
Let's try 250ms.
/freebsd-10.0-release/etc/
H A Ddisktabdiff 82703 Fri Aug 31 20:49:22 MDT 2001 murray Add an entry for the Zip 250.

PR: i386/29639
Submitted by: David Yeske <dyeske@yahoo.com>
/freebsd-10.0-release/sys/dev/usb/
H A Dusb_debug.hdiff 241987 Wed Oct 24 05:33:04 MDT 2012 hselasky Make several timing parameters of the USB enumeration sequence tuneable.
Also update the port reset time from 250ms to 50ms. Some USB devices
have a hard limit in hardware at 222ms for the port reset time and will
not enumerate unless this delay is closer to the usb.org defined value.
This patch can fix enumeration with some USB devices.

Tested by: Guido van Rooij
Submitted by: Nick Hibma
MFC after: 1 week
/freebsd-10.0-release/sys/ufs/ufs/
H A Dquota.hdiff 234483 Fri Apr 20 05:16:50 MDT 2012 mckusick This update uses the MNT_VNODE_FOREACH_ACTIVE interface that loops
over just the active vnodes associated with a mount point to replace
MNT_VNODE_FOREACH_ALL in the vfs_msync, ffs_sync_lazy, and qsync
routines.

The vfs_msync routine is run every 30 seconds for every writably
mounted filesystem. It ensures that any files mmap'ed from the
filesystem with modified pages have those pages queued to be
written back to the file from which they are mapped.

The ffs_lazy_sync and qsync routines are run every 30 seconds for
every writably mounted UFS/FFS filesystem. The ffs_lazy_sync routine
ensures that any files that have been accessed in the previous
30 seconds have had their access times queued for updating in the
filesystem. The qsync routine ensures that any files with modified
quotas have those quotas queued to be written back to their
associated quota file.

In a system configured with 250,000 vnodes, less than 1000 are
typically active at any point in time. Prior to this change all
250,000 vnodes would be locked and inspected twice every minute
by the syncer. For UFS/FFS filesystems they would be locked and
inspected six times every minute (twice by each of these three
routines since each of these routines does its own pass over the
vnodes associated with a mount point). With this change the syncer
now locks and inspects only the tiny set of vnodes that are active.

Reviewed by: kib
Tested by: Peter Holm
MFC after: 2 weeks
diff 234483 Fri Apr 20 05:16:50 MDT 2012 mckusick This update uses the MNT_VNODE_FOREACH_ACTIVE interface that loops
over just the active vnodes associated with a mount point to replace
MNT_VNODE_FOREACH_ALL in the vfs_msync, ffs_sync_lazy, and qsync
routines.

The vfs_msync routine is run every 30 seconds for every writably
mounted filesystem. It ensures that any files mmap'ed from the
filesystem with modified pages have those pages queued to be
written back to the file from which they are mapped.

The ffs_lazy_sync and qsync routines are run every 30 seconds for
every writably mounted UFS/FFS filesystem. The ffs_lazy_sync routine
ensures that any files that have been accessed in the previous
30 seconds have had their access times queued for updating in the
filesystem. The qsync routine ensures that any files with modified
quotas have those quotas queued to be written back to their
associated quota file.

In a system configured with 250,000 vnodes, less than 1000 are
typically active at any point in time. Prior to this change all
250,000 vnodes would be locked and inspected twice every minute
by the syncer. For UFS/FFS filesystems they would be locked and
inspected six times every minute (twice by each of these three
routines since each of these routines does its own pass over the
vnodes associated with a mount point). With this change the syncer
now locks and inspects only the tiny set of vnodes that are active.

Reviewed by: kib
Tested by: Peter Holm
MFC after: 2 weeks
/freebsd-10.0-release/share/man/man4/
H A Dumass.4diff 58659 Mon Mar 27 07:02:01 MST 2000 n_hibma USB Zip 250 drives are now supported

Obtained from: Anders Andersson <anders@sanyusan.se>

Completed in 256 milliseconds

123