El día Thursday, October 21, 2010 a las 08:44:32PM +0200, Paul B Mahol escribió:
> On 10/21/10, Matthias Apitz wrote:
> > El dia Thursday, October 21, 2010 a las 08:35:09PM +0200, Paul B Mahol
> > escribio:
> >
> >> > # cd /usr/src
> >> > # make buildkernel KERNCONF=GENERIC
> >> >
> >> > does not
El día Friday, October 22, 2010 a las 09:14:03AM +0200, Matthias Apitz escribió:
> # make
> Warning: Object directory not changed from original
> /usr/src/sys/modules/alc
> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc -I. -I@ -I@/contrib/altq -finli
> ne-limit=800
Alexander Best wrote:
> the current implementation (kern.cam.power_down) uses a singe "sleep"
> operation, whereas the patch by oliver uses "flush" and "standby immediate".
Sleep is just more aggressive. It puts device into deeper sleep state. I
don't think it is important from wearing point of vi
On Thu, 21.10.2010 at 21:50:26 +0200, Erik Cederstrand wrote:
> Den 21/10/2010 kl. 19.57 skrev Ulrich Spörlein:
> > On Mon, 11.10.2010 at 11:35:42 +0200, Erik Cederstrand wrote:
> >> I'm beginning to think that it should at least be optional. Removing e.g.
> >> build times, mtimes and path to OBJD
On Fri Oct 22 10, Alexander Motin wrote:
> Alexander Best wrote:
> > the current implementation (kern.cam.power_down) uses a singe "sleep"
> > operation, whereas the patch by oliver uses "flush" and "standby immediate".
>
> Sleep is just more aggressive. It puts device into deeper sleep state. I
>
On Friday 22 October 2010 00:32:54 Paul Wootton wrote:
> Actually, the green series does spin all the way down, well at least
> the drive I have does.
> Here is the output from one of my drives, that I do not think has
> long left to live.
>
> === START OF INFORMATION SECTION ===
> Model Family:
On Fri, 22 Oct 2010 12:07:36 +0200
Tijl Coosemans wrote:
> FreeBSD frequently accesses hard disks (log files, flushing dirty
> memory pages every 30s,...) and laptop drives tend to have aggressive
> power saving settings by default. That's why your load cycle is so
> high.
I'm not sure the APM v
Hello everyone,
At EuroBSDCon I was talking with some committers active in the area of
Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC
4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed
implementation called libcompiler_rt. See:
http://compiler-r
* Ed Schouten , 20101022 16:30:
> - Rebuild all your software (yes, I know it's unfortunate).
Right after I sent this, I thought I'd better clarify this. You don't
need to rebuild your software. This change will not break the existing
ABI. This step is just mentioned here,
When mounting a devfs filesystem on top of a directory in an NFS
filesystem under 8.1-RELEASE-p1 r213075M, the following lock order
reversal is reported:
lock order reversal:
1st 0xc264bbdc nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1058
2nd 0xc264bce8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c
On Fri, Oct 22, 2010 at 01:46:54PM -0400, Linda Messerschmidt wrote:
> When mounting a devfs filesystem on top of a directory in an NFS
> filesystem under 8.1-RELEASE-p1 r213075M, the following lock order
> reversal is reported:
>
> lock order reversal:
> 1st 0xc264bbdc nfs (nfs) @ /usr/src/sys/k
On Fri, Oct 22, 2010 at 2:47 PM, Kostik Belousov wrote:
> The LORs are believed to be harmless.
OK, I won't worry about it. I did check the list on
sources.zabbadoz.net and didn't see any for nfs & devfs or nfs &
syncer, so I just wanted to be sure. :)
Thanks!
__
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/22/2010 11:47 AM, Kostik Belousov wrote:
| The LORs are believed to be harmless.
IMO the problem with that line of reasoning is that while any individual
LOR may be harmless there are so many harmless ones that it leads to
people either ignor
13 matches
Mail list logo
