Em 2010.08.09. 21:34, Gennady Proskurin escreveu:
I see misbehaviour of new bsd grep in freebsd on tmpfs when grepping dirs.
For example (on tmpfs /tmp):
mkdir /tmp/qwe
grep something /tmp/qwe
(grep hangs)
Thank you for the report, I'm already aware of the issue and preparing a
On 10 August 2010 15:51, Adrian Chadd adrian.ch...@gmail.com wrote:
Hi everyone,
I'm committing some updates to the if_ath and ath_hal code.
I've just committed updates to the AR5416 register setup values. I'd
appreciate some testing by AR5416 users - eg macbook pro users - to
ensure this
Is there an easy way to check which chip is present as the startup doesnt
seem to mention it?
igb0: Intel(R) PRO/1000 Network Connection version - 1.9.5 port 0xec00-0xec1f mem
0xfade-0xfadf,0xfadc-0xfadd,0xfad9c000-0xfad9 irq 28 at device 0.0 on pci1
igb0: Using MSIX
Thanks Jeremy, from that we get:-
i...@pci0:1:0:0:class=0x02 card=0x060015d9 chip=0x10c98086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
class = network
subclass = ethernet
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1
Steven Hartland wrote:
Thanks Jeremy, from that we get:-
i...@pci0:1:0:0:class=0x02 card=0x060015d9 chip=0x10c98086
rev=0x01 hdr=0x00
i...@pci0:1:0:1:class=0x02 card=0x060015d9 chip=0x10c98086
rev=0x01 hdr=0x00
The important thing is the chip ID: 0x10c98086
Hi everyone,
I'm committing some updates to the if_ath and ath_hal code.
I've just committed updates to the AR5416 register setup values. I'd
appreciate some testing by AR5416 users - eg macbook pro users - to
ensure this hasn't broken functionality.
Thanks,
Adrian
On Tue, Aug 10, 2010 at 10:30:21AM +0100, Steven Hartland wrote:
Is there an easy way to check which chip is present as the startup doesnt
seem to mention it?
Not during start-up, but once the machine is running (including in
single-user), you can do:
pciconf -lvc
And look for device igb0.
On Tue, Aug 10, 2010 at 11:23:26AM +0100, Steven Hartland wrote:
Thanks Jeremy, from that we get:-
i...@pci0:1:0:0:class=0x02 card=0x060015d9 chip=0x10c98086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
class = network
subclass = ethernet
cap 01[40] =
Guys, I'm interested if anyone of you can reproduce my problem with
apache22 port on CURRENT before I eventually send PR.
# uname -a
FreeBSD serwer.obsysa.net 9.0-CURRENT FreeBSD 9.0-CURRENT #8: Mon
Aug 9 19:51:38 CEST 2010
nc...@serwer.obsysa.net:/usr/obj/usr/src/sys/ATHLON9
W dniu 2010-08-10 14:40, Ilya A. Arhipov pisze:
pls show:
pkg_info -xL apache | grep mod_cache
# pkg_info -xL apache | grep mod_cache
/usr/local/share/doc/apache22/mod/mod_cache.html.ja.utf8
/usr/local/share/doc/apache22/mod/mod_cache.html.ko.euc-kr
W dniu 2010-08-10 15:46, Ilya A. Arhipov pisze:
hm, u see it ?
if !defined(WITH_THREADS)
WITHOUT_MODULES+= mem_cache
show all Makefile.options
mod_cache != mod_mem_cache
Makefile.options:
AUTH_BASIC Enable mod_auth_basic ON \
AUTH_DIGEST Enable mod_auth_digest ON \
W dniu 2010-08-10 14:40, Ilya A. Arhipov pisze:
pls show:
pkg_info -xL apache | grep mod_cache
# pkg_info -xL apache | grep mod_cache
/usr/local/share/doc/apache22/mod/mod_cache.html.ja.utf8
/usr/local/share/doc/apache22/mod/mod_cache.html.ko.euc-kr
Hi,
This is i386 -current as of 2010-08-04.
It was building the toolchain for amd64 when it happened.
I'll keep the vmcore around, so I can dig more into it
if someone tells me what to do.
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the
On 2010-08-10 17:23, Ilya A. Arhipov wrote:
make config and add
[x] THREADS Enable threads support in APR :)
and deinstall reinstall
10.08.10, 18:07, Bartosz Stecad...@kkip.pl:
Arrgh! My mistake - I showed generic
/usr/ports/www/apache22/Makefile.options instead of
Bartosz Stec ad...@kkip.pl writes:
# /usr/local/etc/rc.d/apache22 start
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 68 of
/usr/local/etc/apache22/httpd.conf: Cannot load
/usr/local/libexec/apache22/mod_cache.so into server: Cannot open
On Tue, Aug 10, 2010 at 03:57:22AM -0700, Jeremy Chadwick wrote:
On Tue, Aug 10, 2010 at 11:23:26AM +0100, Steven Hartland wrote:
Thanks Jeremy, from that we get:-
i...@pci0:1:0:0:class=0x02 card=0x060015d9 chip=0x10c98086
rev=0x01 hdr=0x00
vendor = 'Intel
Hi,
This bit me as well. Some experimentation showed that a few apache
functions are now compiled in, rather than being modules. Don't know
why.
Editing httpd.conf to remove the items that were no longer modules
restored service.
==ml
On Tue, Aug 10, 2010 at 05:52:43PM +0200, Bartosz Stec
Em 2010.08.10. 19:45, Anonymous escreveu:
Seems like APACHE_MODULES is incorrectly populated.
$ make -V APACHE_MODULES BATCH= GREP=${LOCALBASE-/usr/local}/bin/grep |
fgrep cache
...cache disk_cache file_cache...
$ make -V APACHE_MODULES BATCH= | fgrep cache
...disk_cache
Hello Stablers Heads,
Based on the parts of the script with the additions for tracking source
using git(1) I set out to add support for mercurial hg(1) and ended up
cleaning some of the script while making some of those additions.
This works exactly as before but a little more correct and with
On 2010-08-10 23:12, Gabor Kovesdan wrote:
Em 2010.08.10. 19:45, Anonymous escreveu:
Seems like APACHE_MODULES is incorrectly populated.
$ make -V APACHE_MODULES BATCH=
GREP=${LOCALBASE-/usr/local}/bin/grep | fgrep cache
...cache disk_cache file_cache...
$ make -V APACHE_MODULES
TB --- 2010-08-10 22:50:19 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-10 22:50:19 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2010-08-10 22:50:19 - cleaning the object tree
TB --- 2010-08-10 22:50:42 - cvsupping the source tree
TB --- 2010-08-10 22:50:42 -
TB --- 2010-08-10 22:57:51 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-10 22:57:51 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-08-10 22:57:51 - cleaning the object tree
TB --- 2010-08-10 22:58:07 - cvsupping the source tree
TB --- 2010-08-10 22:58:07 -
On 08/10/2010 03:58, Adrian Chadd wrote:
On 10 August 2010 15:51, Adrian Chadd adrian.ch...@gmail.com wrote:
Hi everyone,
I'm committing some updates to the if_ath and ath_hal code.
I've just committed updates to the AR5416 register setup values. I'd
appreciate some testing by AR5416 users
On 08/10/2010 19:48, jhell wrote:
On 08/10/2010 03:58, Adrian Chadd wrote:
On 10 August 2010 15:51, Adrian Chadd adrian.ch...@gmail.com wrote:
Hi everyone,
I'm committing some updates to the if_ath and ath_hal code.
I've just committed updates to the AR5416 register setup values. I'd
On 08/10/2010 19:32, Anonymous wrote:
jhell jh...@dataix.net writes:
* Adjust the paths that are checked for binaries to be of only
/usr/local/bin and /usr/bin. /bin is highly unlikely to hold svn(1),
git(1) or hg(1).
Please, look at conf/146828. That script shouldn't blindly assume
On 08/10/2010 17:34, jhell wrote:
I also meant to CC dougb@ on this as I believe he had something to do
with the original commits of the git(1) portions and possibly other parts.
I have specifically sworn off any further contact with that file. I have
no idea why screwing around with what
(a copy for current@)
jhell jh...@dataix.net writes:
* Adjust the paths that are checked for binaries to be of only
/usr/local/bin and /usr/bin. /bin is highly unlikely to hold svn(1),
git(1) or hg(1).
Please, look at conf/146828. That script shouldn't blindly assume where
user installs his
On 08/10/2010 20:39, Doug Barton wrote:
On 08/10/2010 17:34, jhell wrote:
I also meant to CC dougb@ on this as I believe he had something to do
with the original commits of the git(1) portions and possibly other parts.
I have specifically sworn off any further contact with that file. I have
Anonymous swel...@gmail.com writes:
jhell jh...@dataix.net writes:
And that would be to identify non-conforming ports using non-standard
locations. Though the option is available to look in a non-standard
You're confusing default and standard value. LOCALBASE has a default for
/usr/local.
jhell jh...@dataix.net writes:
On 08/10/2010 19:32, Anonymous wrote:
jhell jh...@dataix.net writes:
* Adjust the paths that are checked for binaries to be of only
/usr/local/bin and /usr/bin. /bin is highly unlikely to hold svn(1),
git(1) or hg(1).
Please, look at conf/146828. That
On 8/10/2010 5:12 PM, Gabor Kovesdan wrote:
Em 2010.08.10. 19:45, Anonymous escreveu:
Seems like APACHE_MODULES is incorrectly populated.
$ make -V APACHE_MODULES BATCH= GREP=${LOCALBASE-/usr/local}/bin/grep
| fgrep cache
...cache disk_cache file_cache...
$ make -V APACHE_MODULES BATCH= |
On 11 August 2010 07:48, jhell jh...@dataix.net wrote:
I have applied the following (r211136) to my local stable/8 branch and
has proven to be an improvement with no drawbacks.
Ah, the calibration scheduling change. Cool!
As for the rest I can not vouch for unless you give me a specific
On 08/10/2010 22:38, Adrian Chadd wrote:
On 11 August 2010 07:48, jhell jh...@dataix.net wrote:
I have applied the following (r211136) to my local stable/8 branch and
has proven to be an improvement with no drawbacks.
Ah, the calibration scheduling change. Cool!
As for the rest I can
On 11 August 2010 11:48, jhell jh...@dataix.net wrote:
I have attached a dump_all_config_desc for this device in case anyone
can identify it. Linksys WUSB54G
Check out this:
http://www.qbik.ch/usb/devices/search_res.php?pattern=802.11
ugen3.3: product 0x2234 vendor 0x1915 at usbus3, cfg=0
On 08/10/2010 21:50, Anonymous wrote:
Anonymous swel...@gmail.com writes:
jhell jh...@dataix.net writes:
And that would be to identify non-conforming ports using non-standard
locations. Though the option is available to look in a non-standard
You're confusing default and standard value.
On 08/11/2010 00:11, Adrian Chadd wrote:
On 11 August 2010 11:48, jhell jh...@dataix.net wrote:
I have attached a dump_all_config_desc for this device in case anyone
can identify it. Linksys WUSB54G
Check out this:
http://www.qbik.ch/usb/devices/search_res.php?pattern=802.11
...
ugen3.3: product 0x2234 vendor 0x1915 at usbus3, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON
That vendor:product combination is in the above list.
It looks like it's this:
http://linuxwireless.org/en/users/Drivers/zd1211rw
Are you sure about that? I don't see a Linksys WUSB54G revision
37 matches
Mail list logo
