On Tue, Nov 15, 2011, Marcel Moolenaar wrote:
>
> On Nov 15, 2011, at 1:14 PM, David Schultz wrote:
>
> > On Tue, Nov 15, 2011, Dimitry Andric wrote:
> >> Note all the final executables will use 'real' atomic operations. That
> >> is, unless you compile with CPUTYPE?=i386, and I wish you the bes
On Nov 15, 2011, at 1:14 PM, David Schultz wrote:
> On Tue, Nov 15, 2011, Dimitry Andric wrote:
>> Note all the final executables will use 'real' atomic operations. That
>> is, unless you compile with CPUTYPE?=i386, and I wish you the best of
>> luck in that case, you'll need it. :)
>
> I thoug
Author: rmacklem
Date: Wed Nov 16 05:05:13 2011
New Revision: 227549
URL: http://svn.freebsd.org/changeset/base/227549
Log:
MFC: r224604
Fix a LOR in the NFS client which could cause a deadlock.
This was reported to the mailing list freebsd-...@freebsd.org
on July 21, 2011 under the subjec
Author: mjacob
Date: Wed Nov 16 02:52:24 2011
New Revision: 227548
URL: http://svn.freebsd.org/changeset/base/227548
Log:
Was chasing down a failure to load f/w on a 2400. It turns out that the card
is actually broken, or needs a BIOS upgrade for 64 bit loads, but this
uncovered
a couple of
Author: bz
Date: Wed Nov 16 02:00:55 2011
New Revision: 227547
URL: http://svn.freebsd.org/changeset/base/227547
Log:
The maximum TSO frame size should be:
maximum IP datagram size (65535 bytes) +
Ethernet header size (14 bytes) +
2 * VLAN tag size (4 bytes) [1].
[1]
Author: obrien
Date: Tue Nov 15 23:46:25 2011
New Revision: 227545
URL: http://svn.freebsd.org/changeset/base/227545
Log:
MFC: r220954 & r221469: Note which of the built kernels is being installed.
PR: 156579
Modified:
stable/8/Makefile.inc1 (contents, props changed)
Directory Properties:
Author: rmacklem
Date: Tue Nov 15 23:35:43 2011
New Revision: 227543
URL: http://svn.freebsd.org/changeset/base/227543
Log:
Modify the new NFS client so that nfs_fsync() only calls ncl_flush()
for regular files. Since other file types don't write into the
buffer cache, calling ncl_flush() is
In response to this thread I've updated:
http://wiki.freebsd.org/TuningPowerConsumption
--HPS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebs
On Tue, Nov 15, 2011 at 1:22 PM, Hans Petter Selasky wrote:
> On Tuesday 15 November 2011 22:20:18 m...@freebsd.org wrote:
>> On Tue, Nov 15, 2011 at 1:02 PM, Hans Petter Selasky
> wrote:
>> > For USB compliant operation, the USB stack requires hz to be greater or
>> > equal to 250 hz, to put it
On Tuesday, November 15, 2011 4:52:02 pm Dimitry Andric wrote:
> On 2011-11-15 22:14, David Schultz wrote:
> > On Tue, Nov 15, 2011, Dimitry Andric wrote:
> >> Note all the final executables will use 'real' atomic operations. That
> >> is, unless you compile with CPUTYPE?=i386, and I wish you the
On 2011-11-15 22:14, David Schultz wrote:
> On Tue, Nov 15, 2011, Dimitry Andric wrote:
>> Note all the final executables will use 'real' atomic operations. That
>> is, unless you compile with CPUTYPE?=i386, and I wish you the best of
>> luck in that case, you'll need it. :)
>
> I thought we drop
On Tue, Nov 15, 2011 at 1:22 PM, Hans Petter Selasky wrote:
> On Tuesday 15 November 2011 22:20:18 m...@freebsd.org wrote:
>> On Tue, Nov 15, 2011 at 1:02 PM, Hans Petter Selasky
> wrote:
>> > For USB compliant operation, the USB stack requires hz to be greater or
>> > equal to 250 hz, to put it
On Nov 15, 2011, at 1:24 PM, Hans Petter Selasky wrote:
>>
>> ... and I also just remembered that I have seen recommendations that,
>> when FreeBSD is used as a virtual machine, hz should be set to 100 so
>> that the virtual interrupt overhead is reduced. Those two
>> recommendations are at odds
On Tuesday 15 November 2011 22:21:31 m...@freebsd.org wrote:
> On Tue, Nov 15, 2011 at 1:20 PM, wrote:
> > On Tue, Nov 15, 2011 at 1:02 PM, Hans Petter Selasky
wrote:
> >> For USB compliant operation, the USB stack requires hz to be greater or
> >> equal to 250 hz, to put it like that. Mostly a
On Tuesday 15 November 2011 22:20:18 m...@freebsd.org wrote:
> On Tue, Nov 15, 2011 at 1:02 PM, Hans Petter Selasky
wrote:
> > For USB compliant operation, the USB stack requires hz to be greater or
> > equal to 250 hz, to put it like that. Mostly a requirement in USB
> > gadget/device mode.
>
>
On Tue, Nov 15, 2011 at 1:20 PM, wrote:
> On Tue, Nov 15, 2011 at 1:02 PM, Hans Petter Selasky wrote:
>> For USB compliant operation, the USB stack requires hz to be greater or equal
>> to 250 hz, to put it like that. Mostly a requirement in USB gadget/device
>> mode.
>
> Really? That's news to
On Tue, Nov 15, 2011 at 1:02 PM, Hans Petter Selasky wrote:
> For USB compliant operation, the USB stack requires hz to be greater or equal
> to 250 hz, to put it like that. Mostly a requirement in USB gadget/device
> mode.
Really? That's news to me. Is that documented somewhere? I know we
sti
On Tue, Nov 15, 2011, Dimitry Andric wrote:
> Note all the final executables will use 'real' atomic operations. That
> is, unless you compile with CPUTYPE?=i386, and I wish you the best of
> luck in that case, you'll need it. :)
I thought we dropped support for anything less than a 486DX years ag
On Tuesday 15 November 2011 21:54:28 m...@freebsd.org wrote:
> Is there some reason these functions aren't asking for a delay in
> terms of milli- or microseconds, and converting to hz internally?
There is no strong reason for this except, that when everything is computed in
system ticks, there i
On Tuesday 15 November 2011 21:54:28 m...@freebsd.org wrote:
> On Tue, Nov 15, 2011 at 12:48 PM, Hans Petter Selasky
>
> wrote:
> > Author: hselasky
> > Date: Tue Nov 15 20:48:57 2011
> > New Revision: 227541
> > URL: http://svn.freebsd.org/changeset/base/227541
> >
> > Log:
> > Some brands of
On Tue, Nov 15, 2011 at 12:48 PM, Hans Petter Selasky
wrote:
> Author: hselasky
> Date: Tue Nov 15 20:48:57 2011
> New Revision: 227541
> URL: http://svn.freebsd.org/changeset/base/227541
>
> Log:
> Some brands of XHCI controllers needs more time to reset.
... and since there's no guarantee that
Author: hselasky
Date: Tue Nov 15 20:48:57 2011
New Revision: 227541
URL: http://svn.freebsd.org/changeset/base/227541
Log:
Some brands of XHCI controllers needs more time to reset.
Reported by: Jan Henrik Sylvester
MFC after:1 week
Modified:
head/sys/dev/usb/controller/xhci.c
Mo
On 2011-11-15 21:15, Dimitry Andric wrote:
> Author: dim
> Date: Tue Nov 15 20:15:58 2011
> New Revision: 227538
> URL: http://svn.freebsd.org/changeset/base/227538
>
> Log:
> LLVM uses atomic operations, which are not supported on i386 and GCC
> emits calls for them, rather than expanding the
Author: tuexen
Date: Tue Nov 15 20:41:50 2011
New Revision: 227540
URL: http://svn.freebsd.org/changeset/base/227540
Log:
Set the MTU of an path to an approriate value if the interface MTU
can't be determined.
MFC after: 3 days.
Modified:
head/sys/netinet/sctp_pcb.c
Modified: head/sys
Author: marius
Date: Tue Nov 15 20:17:18 2011
New Revision: 227539
URL: http://svn.freebsd.org/changeset/base/227539
Log:
Define curthread as an inline function that loads the thread pointer
directly from g7, the pcpu pointer. This guarantees correct behavior
when the thread migrates to a di
Author: dim
Date: Tue Nov 15 20:15:58 2011
New Revision: 227538
URL: http://svn.freebsd.org/changeset/base/227538
Log:
LLVM uses atomic operations, which are not supported on i386 and GCC
emits calls for them, rather than expanding them inline. Older FreeBSD
versions compile for i386 by def
Author: marius
Date: Tue Nov 15 20:11:03 2011
New Revision: 227537
URL: http://svn.freebsd.org/changeset/base/227537
Log:
As it turns out, r186347 actually is insufficient to avoid the use of the
curthread-accessing part of mtx_{,un}lock(9) when using a r210623-style
curthread implementation
Author: nwhitehorn
Date: Tue Nov 15 18:49:27 2011
New Revision: 227536
URL: http://svn.freebsd.org/changeset/base/227536
Log:
Further automate production release generation by naming files the right
things and generating checksums.
MFC after:1 week
Modified:
head/release/generate-r
Author: eadler (ports committer)
Date: Tue Nov 15 17:53:29 2011
New Revision: 227535
URL: http://svn.freebsd.org/changeset/base/227535
Log:
- add support for Titan VScom PCIex-800H
PR: kern/124128
Submitted by: Maxim Frolov (original)
Approved by: jhb
MFC after:1 week
Author: delphij
Date: Tue Nov 15 17:42:00 2011
New Revision: 227534
URL: http://svn.freebsd.org/changeset/base/227534
Log:
MFC r227409:
Do a dummy read to flush the interrupt ACK that we just performed,
ensuring that everything is really, truly consistent.
This fixes certain cases wh
Author: delphij
Date: Tue Nov 15 17:30:03 2011
New Revision: 227533
URL: http://svn.freebsd.org/changeset/base/227533
Log:
MFC r227409:
Do a dummy read to flush the interrupt ACK that we just performed,
ensuring that everything is really, truly consistent.
This fixes certain cases wh
Author: eadler (ports committer)
Date: Tue Nov 15 17:15:09 2011
New Revision: 227532
URL: http://svn.freebsd.org/changeset/base/227532
Log:
- add support for Broadcom 802.11bg/EDGE/GPRS CardBus (Serial)
- correct mislabeling of 0x432214e4 device
PR: kern/119606
Submitted by: J
Author: des
Date: Tue Nov 15 16:20:39 2011
New Revision: 227531
URL: http://svn.freebsd.org/changeset/base/227531
Log:
Add netcat (nc) to /rescue.
MFC after:3 weeks
Modified:
head/rescue/rescue/Makefile
Modified: head/rescue/rescue/Makefile
==
Author: kib
Date: Tue Nov 15 14:40:00 2011
New Revision: 227530
URL: http://svn.freebsd.org/changeset/base/227530
Log:
Update the device pager interface, while keeping the compatibility
layer for old KPI and KBI. New interface should be used together with
d_mmap_single cdevsw method.
D
Author: kib
Date: Tue Nov 15 14:09:53 2011
New Revision: 227529
URL: http://svn.freebsd.org/changeset/base/227529
Log:
Remove the condition that is always true.
Submitted by: alc
MFC after:1 week
Modified:
head/sys/vm/vm_pager.c
Modified: head/sys/vm/vm_pager.c
===
Author: glebius
Date: Tue Nov 15 12:59:07 2011
New Revision: 227528
URL: http://svn.freebsd.org/changeset/base/227528
Log:
On some laptops it is important to re-open /dev/psm after resume. moused(8)
was capable to do this upon SIGHUP for more than a decade. Automate this
via rc.resume in def
Author: pho
Date: Tue Nov 15 09:23:21 2011
New Revision: 227527
URL: http://svn.freebsd.org/changeset/base/227527
Log:
Removed extra PRELE() call.
MFC after:1 week
Modified:
head/sys/fs/pseudofs/pseudofs_vnops.c
Modified: head/sys/fs/pseudofs/pseudofs_vnops.c
===
37 matches
Mail list logo
