Hello folks,
Yesterday I had a panic on my laptop. Unfortunately the SU+J was not
able to recovery the file system, the error was something like :
Unknown error: Help!
Could not find directory 9854215
And it went to the single user mode, I needed to fsck_ufs manually to
recover the disk. What af
Hello,
I'm not sure if this is right list, but has anything recently changed which
could
explain why cmake c++ project (http://sourceforge.net/projects/gemrb/)
started to fail upon linking stage (looking like libstdc++ is not included
/usr/include/c++/4.2/)?
It works normally if passed gcc48 as
Apart from it, clang looks _very_ c++ capable, as in building
boost and rebuilding os (itself) normally, so it doesn't look broken
from this point.
Just after some rebuild of OS (1-2 weeks ago?) This on git project
started to fail upon linking.
--
View this message in context:
http://freebsd
On Tue, 2013-03-26 at 11:35 -0700, Unga wrote:
> Hi all
>
>
> I have a heavily threaded C application, developed on an Intel Core i5 laptop
> (2 cores) running FreeBSD 8.1-RELEASE.
>
> When this application compile and run on another Intel Core i7 laptop (4
> cores) running FreeBSD 9.1-RELEASE
On Wed, Mar 27, 2013 at 08:06:10AM -0600, Ian Lepore wrote:
> On Tue, 2013-03-26 at 11:35 -0700, Unga wrote:
> > Hi all
> >
> >
> > I have a heavily threaded C application, developed on an Intel Core i5
> > laptop (2 cores) running FreeBSD 8.1-RELEASE.
> >
> > When this application compile and
- Original Message -
> From: Ian Lepore
> To: Unga
> Cc: "freebsd-stable@freebsd.org"
> Sent: Wednesday, March 27, 2013 2:06 PM
> Subject: Re: FreeBSD 9.1 excessive memory allocations
>
> On Tue, 2013-03-26 at 11:35 -0700, Unga wrote:
>> Hi all
>>
>>
>> I have a heavily threaded
On Wed, 27 Mar 2013 19:33:46 +0100, Unga wrote:
- Original Message -
From: Ian Lepore
To: Unga
Cc: "freebsd-stable@freebsd.org"
Sent: Wednesday, March 27, 2013 2:06 PM
Subject: Re: FreeBSD 9.1 excessive memory allocations
On Tue, 2013-03-26 at 11:35 -0700, Unga wrote:
Hi all
On Wed, 2013-03-27 at 11:33 -0700, Unga wrote:
>
> - Original Message -
>
> > From: Ian Lepore
> > To: Unga
> > Cc: "freebsd-stable@freebsd.org"
> > Sent: Wednesday, March 27, 2013 2:06 PM
> > Subject: Re: FreeBSD 9.1 excessive memory allocations
> >
> > On Tue, 2013-03-26 at 11:35 -0
Hi.
Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
stack, using only some controller drivers of old ata(4) by having
`options ATA_CAM` enabled in all kernels by default. I have a wish to
drop non-ATA_CAM ata(4) code, unused since that time from the head
branch to allow
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
> Hi.
>
> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> stack, using only some controller drivers of old ata(4) by having
> `options ATA_CAM` enabled in all kernels by default. I have a wish to
> drop no
On 27.03.2013 23:32, Steve Kargl wrote:
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
Hi.
Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
stack, using only some controller drivers of old ata(4) by having
`options ATA_CAM` enabled in all kernels by defau
On Wed, Mar 27, 2013 at 2:32 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
> > Hi.
> >
> > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> > stack, using only some controller drivers of old at
On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote:
> On 27.03.2013 23:32, Steve Kargl wrote:
> > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
> >> Hi.
> >>
> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> >> stack, using only some contr
On 28.03.2013 00:05, Steve Kargl wrote:
On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote:
On 27.03.2013 23:32, Steve Kargl wrote:
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
Hi.
Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
stack, u
On Thu, Mar 28, 2013 at 12:22:11AM +0200, Alexander Motin wrote:
> On 28.03.2013 00:05, Steve Kargl wrote:
> >
> > Last time I tested the new one, and this was several months
> > ago, the system (a Dell Latitude D530 laptop) would not boot.
>
> Probably we should just fix that. Any more info?
>
On 27/03/2013, at 18:43, David Demelier wrote:
> Yesterday I had a panic on my laptop. Unfortunately the SU+J was not
> able to recovery the file system, the error was something like :
>
> Unknown error: Help!
> Could not find directory 9854215
>
> And it went to the single user mode, I needed
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim down the CAM stack a bit first; it makes
embedding it on the smaller devices really freaking painful.
Thanks,
adrian
_
While looking into an issue with security/heimdal I found that v1.5.2 of
heimdal has been in HEAD for 11 months and has had 2 small fixes in that
time. Now that I look at it these two fixes should probably be
duplicated to the port as well.
This update has yet to be copied down to stable or relen
>
> I think you may be reading too much into the malloc manpage. When it
> mentions the use of per-thread small-object caches to avoid locking it's
> talking about performance, not thread safety. Allocations of all sizes
> are thread-safe, the library just assumes that huge allocations are ra
Quoth Unga :
>
> > I think you may be reading too much into the malloc manpage.� When it
> > mentions the use of per-thread small-object caches to avoid locking it's
> > talking about performance, not thread safety.� Allocations of all sizes
> > are thread-safe, the library just assumes that huge
20 matches
Mail list logo