On Friday 28 October 2011 21:09:47 Pawel Jakub Dawidek wrote:
> On Fri, Oct 28, 2011 at 09:11:42AM +0200, Hans Petter Selasky wrote:
> > On Thursday 27 October 2011 20:51:15 Pawel Jakub Dawidek wrote:
> > > On Thu, Oct 27, 2011 at 08:42:09PM +0200, Hans Petter Selasky wrote:
> > > > This is the roo
I ran into a somewhat interesting snag while trying out FreeBSD 9 on
my laptop. I built a kernel from the RELENG_9 branch, and get a
"fatal trap 12" during the initialization sequence. For testing, I
rebuilt the same kernel from the CURRENT branch, with the same problem
-- this is the one that I'
On Mon, Oct 31, 2011 at 01:22:40AM -0700, Matt Mullins wrote:
M> I ran into a somewhat interesting snag while trying out FreeBSD 9 on
M> my laptop. I built a kernel from the RELENG_9 branch, and get a
M> "fatal trap 12" during the initialization sequence. For testing, I
M> rebuilt the same kernel
Hello.
When one can expect being able to have system
without base gcc installed? Since I enabled clang, and
I'm using gcc46 for ports, having base gcc is largely
pointless for me, but couldn't build system with clang only,
because of:
===> usr.bin/xlint/llib (all)
lint -cghapbx -Cposix /usr/sr
Hi!
Just wanted to say - in my case the AHCI timeouts (and therefor the
panics afterwards) were solved by updating the firmware of my SSDs.
[Corsair Force 3, 120GB, old firmware: 1.3, new firmware: 1.3.3]
Armin
On 10/28/11 01:19, Pegasus Mc Cleaft wrote:
If it's only one process, the machine
On 2011-10-31 10:53, Jakub Lach wrote:
When one can expect being able to have system
without base gcc installed?
There's quite some work to be done. The trickiest part is to get rid of
GNU libstdc++, which is sort of a symbiote with gcc.
Also, there are still some programs that hardcode ${CC}
Hi, thanks for reply.
> But seriously, building ports which
> have not explicitly been marked as being
> gcc 4.5 or 4.6 compatible is
> taking a chance. It might work, or break
> in various interesting ways.
Yes, I know. I'm just using small subset of ports
as well. Will probably try clang f
On Fri, Oct 28, 2011 at 4:55 AM, Alberto Villa wrote:
> On Thursday 27 October 2011 02:34:11 Mehmet Erol Sanliturk wrote:
> > In a message previously I mentioned the KDE4 problem for 8.2 amd64
> Release
> > , but that message even did not receive a single reply .
>
> Things just may get lost, sor
On Monday 31 October 2011 17:05:06 Mehmet Erol Sanliturk wrote:
> The problem caused by the messages is at least the time used to
generate
> them .
Some of these have been removed in the latest kdelibs4 port.
> Starting of KDE4 or its parts are taking a long time with respect to
other
> system
Hi.
Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So
I would like to present my results and request for testing and feedback.
The main changes:
- Improved locking and destruction process to fix crashes in many cases.
- Improved "automatic" configuration method to make it
Someone was seeing the same issue with the vmtools kmod. The only
thing that might make sense is that the page lock array is defined as
being a different size in your kmod as in the kernel itself so the
lock corresponding to the page you're locking differs between the two
files.
Cheers
On Fri, Oc
Hi all,
I'd like to merge the if_ath_tx code into -HEAD so it gets some wider
testing. This includes a couple of net80211 changes but it
overwhelmingly is if_ath driver changes.
The code is a bit messy and it's still a work in progress but I'd
rather tidy it up in -HEAD. Otherwise I'm stuck in th
On 10/31/2011 14:17, Adrian Chadd wrote:
> Hi all,
>
> I'd like to merge the if_ath_tx code into -HEAD so it gets some wider
> testing. This includes a couple of net80211 changes but it
> overwhelmingly is if_ath driver changes.
>
> The code is a bit messy and it's still a work in progress but I'
On Mon, 31 Oct 2011 14:17:28 -0700
Adrian Chadd wrote:
> Hi all,
>
> I'd like to merge the if_ath_tx code into -HEAD so it gets some wider
> testing. This includes a couple of net80211 changes but it
> overwhelmingly is if_ath driver changes.
>
> The code is a bit messy and it's still a work in
2011/10/28 :
> On Fri, Oct 28, 2011 at 8:37 AM, Ryan Stone wrote:
>> I'm seeing issues on a unicore systems running a derivative of FreeBSD
>> 8.2-RELEASE if something calls mem_range_attr_set. It turns out that
>> the root cause is a bug in smp_rendezvous_cpus. The first part of
>> smp_rendezv
On 31 October 2011 14:52, Doug Barton wrote:
>> The code is a bit messy and it's still a work in progress but I'd
>> rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate
>> situation of having to keep merging between the if_ath_tx branch and
>> -HEAD.
>
> Is this work that is planne
I'm getting an strange warning whem compiling with clang (from base) on RC1.
This warning doesn't appear with 8.X and clang from ports.
The warning is strange because ntohs is not int:
uint16_t
ntohs(uint16_t netshort);
Any insight would be appreciated, thanks in advance!
A
% gcc
On 10/31/2011 17:22, Adrian Chadd wrote:
> On 31 October 2011 14:52, Doug Barton wrote:
>
>>> The code is a bit messy and it's still a work in progress but I'd
>>> rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate
>>> situation of having to keep merging between the if_ath_tx bran
Hello,
First of all, many thanks. I am going to test your patch on 9.0-RC1, and
try to backport it to 8.2 (which is the main version I am currently
using at work, in the environment where I have a critical need for FC
multipath redundancy...)
Again, thanks for your efforts. I hope to be giving fe
It doesnt warn here. Can you check with "clang -E" what the ntohs()
is being expanded to and what the real prototype is?
On Mon, Oct 31, 2011 at 06:35:18PM -0600, Axel Gonzalez wrote:
>
> I'm getting an strange warning whem compiling with clang (from base) on RC1.
>
> This warning doesn't appear
20 matches
Mail list logo
