Is anybody working on implementing the ath9k wireless driver?
Just curious. I have reserved a huge chunk of my hard drive on my laptop - in
anticipation of FreeBSD supporting that device. Using a linux distro in the
mean time.
==
"What did you do?" the man holding the flashlight asked.
"
On Tue, 23 Mar 2010 20:49, Carlos A. M. dos Santos wrote:
In Message-Id:
On Tue, Mar 23, 2010 at 8:39 PM, jhell wrote:
On Mon, 22 Mar 2010 15:42, deischen@ wrote:
[ Some CC's stripped ]
On Mon, 22 Mar 2010, M. Warner Losh wrote:
P.S. I think that there's much traction to the idea of m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24.03.2010 01:49, Carlos A. M. dos Santos wrote:
> On Tue, Mar 23, 2010 at 8:39 PM, jhell wrote:
>>
>> On Mon, 22 Mar 2010 15:42, deischen@ wrote:
>>>
>>> [ Some CC's stripped ]
>>>
>>> On Mon, 22 Mar 2010, M. Warner Losh wrote:
>>>
P.S. I th
On Tue, Mar 23, 2010 at 8:39 PM, jhell wrote:
>
> On Mon, 22 Mar 2010 15:42, deischen@ wrote:
>>
>> [ Some CC's stripped ]
>>
>> On Mon, 22 Mar 2010, M. Warner Losh wrote:
>>
>>> P.S. I think that there's much traction to the idea of moving from
>>> COMPAT_FREEBSDx to some other variable called,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It looks like the stack somehow mangled before entering strlen()? I'm
somehow confused with this...
Cheers,
- --
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG
On Tue, 23 Mar 2010 06:40, alexbestms@ wrote:
Pegasus Mc Cleaft schrieb am 2010-03-23:
-Original Message-
2. i wasn't able to reproduce your `make -V MACHINE_CPU
-DCPUTYPE=native`
examples. for me `make` prints the same no matter what CPUTYPE is
set to:
otaku% make -V MACHINE_CPU -D
On Mon, 22 Mar 2010 15:42, deischen@ wrote:
[ Some CC's stripped ]
On Mon, 22 Mar 2010, M. Warner Losh wrote:
P.S. I think that there's much traction to the idea of moving from
COMPAT_FREEBSDx to some other variable called, for example,
COMPAT_FREEBSD_BACK_TO=x, which will give compatibility
Scot Hetzel schrieb am 2010-03-23:
> On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best
> wrote:
> > i don't think conf/112997 and the issue where gcc segfaults are
> > directly
> > related to each other:
> > 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E
> >-mtune=native
> > /
It probably bears repeating that the tree will be unstable for the next
few days while a number of large commits hit the tree. These were held
off during the release process to make life easier in case portmgr had
to do tag-slips.
Image processing libraries, xorg, kde, and gnome are scheduled to
On Tue, Mar 23, 2010 at 11:19 AM, Scot Hetzel wrote:
> On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best wrote:
>> i don't think conf/112997 and the issue where gcc segfaults are directly
>> related to each other:
>>
>> 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E
>> -mtune=nat
On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best wrote:
> i don't think conf/112997 and the issue where gcc segfaults are directly
> related to each other:
>
> 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native
> /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtu
On Mar 23, 2010, at 7:05 AM, Nathan Whitehorn wrote:
>> On Mar 22, 2010, at 10:52 AM, David O'Brien wrote:
>>
>>> / On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote:
> />>>/ I certainly agree.. can it be changed please?
> />>/ />>/ I've waited a while to see what other opinions wo
On Monday 22 March 2010 4:48:19 pm Marcel Moolenaar wrote:
>
> On Mar 22, 2010, at 10:52 AM, David O'Brien wrote:
>
> > On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote:
> >> I certainly agree.. can it be changed please?
> >
> > I've waited a while to see what other opinions would
On Mar 22, 2010, at 10:52 AM, David O'Brien wrote:
/ On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote:
/>>>/ I certainly agree.. can it be changed please?
/>>/
/>>/ I've waited a while to see what other opinions would be expressed on this
/>>/ topic. I believe there is suffici
Pegasus Mc Cleaft schrieb am 2010-03-23:
> -Original Message-
> >2. i wasn't able to reproduce your `make -V MACHINE_CPU
> >-DCPUTYPE=native`
> >examples. for me `make` prints the same no matter what CPUTYPE is
> >set to:
> >otaku% make -V MACHINE_CPU -DCPUTYPE=native
> >amd64 sse2 sse
> >
-Original Message-
From: Pegasus Mc Cleaft [mailto:k...@mthelicon.com]
Sent: 23 March 2010 09:57
To: 'Alexander Best'
Subject: RE: build failures after stdlib update
-Original Message-
>2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native`
>examples. for me `
i don't think conf/112997 and the issue where gcc segfaults are directly
related to each other:
1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native
/dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//'` to determine
gcc's idea of the appropriate -mtune value.
In message <20100322233607.gb1...@garage.freebsd.pl>, Pawel Jakub Dawidek write
s:
>A class is suppose to interact with other classes only via GEOM, so I
>think it should be safe to choose g_up/g_down threads for each class
>individually, for example:
>
> /dev/ad0s1a (DEV)
> |
>
:The whole point of the discussion, sans PHK's interlude, is to reduce the
context switches and indirection, not to increase it. But if you can show
decreased latency/higher-iops benefits of increasing it, more power to you. I
would think that the results of DFly's experiment with
parallelism
19 matches
Mail list logo
