check this message:
http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031216.html
run /usr/src/tools/tools/net80211/wlandebug/wlandebug -i ath0 power and
see if one of the hosts on your wlan has powersaving turned on.
stops forever was not one of my symptoms though, so your
mode
ath0: [00:18:de:85:d0:5e] power save mode on, 1 sta's in ps mode
ath0: [00:18:de:85:d0:5e] power save mode off, 0 sta's in ps mode
ping times are all now consistantly under a ms and throughput it good.
On Sat, 11 Nov 2006, Lamont Granquist wrote:
i've got an ath0 issue similar to this one
On Wed, 29 Nov 2006, Sam Leffler wrote:
Is there some reason you are not just sniffing the air? Assuming
packets are being deferred because the medium is busy you might see a
reason. Otherwise it appears (though it's impossible to tell from what
you've shown so far) that the packets are
haven't tried -current
On Tue, 28 Nov 2006, Lamont Granquist wrote:
On Wed, 15 Nov 2006, Sam Leffler wrote:
Snapshots are rarely useful; try running athstats 1 and correlate what
you see with pauses. Another possible reason for deferred operation is
something else in the system blocking
On Wed, 15 Nov 2006, Sam Leffler wrote:
Snapshots are rarely useful; try running athstats 1 and correlate what
you see with pauses. Another possible reason for deferred operation is
something else in the system blocking the taskq threads; that's a bit
trickier to diagnose.
also, athtest 1
On Wed, 15 Nov 2006, Sam Leffler wrote:
Snapshots are rarely useful; try running athstats 1 and correlate what
you see with pauses. Another possible reason for deferred operation is
something else in the system blocking the taskq threads; that's a bit
trickier to diagnose.
I threw in some
i did the same thing with running:
while(1)
echo foo
sleep 1
end
in a window ssh'd into the machine with the ath0 driver, but with the
kernel recompiled with ATH_DEBUG and sysctl dev.ath.0.debug=0x --
there should be packets sent every second while doing this.
i saw the same
On Sun, 12 Nov 2006, Sam Leffler wrote:
If tx stops in ap mode you need to figure out whether the h/w tx q is
stalled or something else above is blocking outbound traffic. The
usual things to check are:
1. are there resources in the driver to send a packet (e.g. buffers on
the queue); if the
i've got an ath0 issue similar to this one:
http://lists.freebsd.org/pipermail/freebsd-stable/2006-July/027050.html
this is on 6.2-PRERELEASE from Nov 3
FreeBSD warez.scriptkiddie.org 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Fri
Nov 3 09:00:14 PST 2006 [EMAIL
On Tue, 30 Apr 2002, Mike Meyer wrote:
What's missed here is that running an old kernel and a new userland is
more likely to screw things up.
In fact this is now broken if you try to build -current on a -stable box.
You can't run the -current userland on a -stable kernel to do an install
I previously posted a patch to fix this UDP-in-jail bug which I believe
may have compromised the security of the jail. This patch shouldn't do
that.
It:
1. preserves the jail check in in_pcbconnect()
2. preserves the laddr+lport check in the beginning of in_pcbbind()
3. modifies no code
So, whats the easist way to recover from a clobbered boot manager in
FreeBSD? I kind of naively assumed that this would be easy to do from an
installation CDROM (4.3-RELEASE) but I failed to get it to work. Going
Configure-Fdisk in sysinstall didn't work for me.
To Unsubscribe: send mail to
All my 4.3 and 4.4 boxen have problems with the only lookback address
being valid is 127.0.0.1 instead of the entire /8.
My ifconfig looks like:
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
Is 5.0 going to let ntpd run without root permissions?
Having ntpd running as root scares the living fuck out of me since it
lends itself to attacks involving single packets and spoofed source
addresses (and in particular spoofing the tier 1 and 2 time daemon source
addresses to bypass firewall
I just tried xine 0.4.3 from ports with captain_css 0.1.2 and it failed to
work. Tried again with xine 0.5.0.rc2 and it also failed to work. I'm
runing a post-4.3 cvsup on a K7M+K7T/900 with creative labs dxr3s
DVD-CDROM and Asus TNT2 ultra and Monster MX300 (Aureal Vortex). It just
freezes
On Mon, 23 Jul 2001, A. L. Meyers wrote:
It seems to me that it would be in the very best interest of
FreeBSD to apply whatever quality controls are appropriate to
ensure that stable means what it says.
You're checking out the head of a development tree. It will never
be stable in your
On Fri, 13 Jul 2001, Bruce Burden wrote:
Some SCSI drive manufacturers ship their drives
with WCE enabled. Other SCSI drive manufacturers, who are more
concerned with data integrity as opposed to performance figures, will
ship their drives with WCE disabled.
Well, i think it is, i'm actually not too sure exactly how fast dogshit is
in the first place. But in doing a simple untar on a fat32 partition
using both 4-stable a couple days after release and a recently updated
4-stable as of yesterday (5/10) it goes about 20-30 times slower than an
untar
I've got a K7T900 in a Asus K7M (100MHz FSB) and 4.3 works fine.
I keep getting errors about not being able to build some rc4 file when i
do a buildkernel, but that's probably not hardware related...
On Mon, 7 May 2001, Jordan Hubbard wrote:
Odd. What sort of LISP environment are you
19 matches
Mail list logo
