Re: Strange performance issue with grep -r -i as non-root user
On Sat, Mar 05, 2011 at 09:04:50PM -1000, Clifton Royston wrote: > On Sat, Mar 05, 2011 at 07:07:20PM -0800, Jeremy Chadwick wrote: > ... > > $ unset LANG > > - Result: still 80x slower with -i > > $ unset LANG LC_COLLATE > > - Result: still 80x slower with -i > > $ unset LANG LC_CTYPE > > - Result: normal/fast. > > $ unset LC_CTYPE > > - Result: still 80x slower with -i > > $ unset LC_CTYPE LC_COLLATE > > - Result: still 80x slower with -i > > $ unset LC_COLLATE > > - Result: still 80x slower with -i > > > > So the LANG + LC_CTYPE combo when used together are what cause this. > > Doesn't the above say that having either one set does it? You're correct -- I phrased this incorrectly, my apologies. > I would guess it's probably that either one requires the 8.x > grep -i to make a conversion function call for each char (or perhaps > line) of input to ensure the proper upper/lower case conversion rules > are followed. A colleague of mine (who I wish I would have asked first) knew of this quirk with grep (apparently some other utilities behave oddly as well with LANG/LC_CTYPE; he mentioned less as another example), stating that a locale can induce very long delays like this solely due to the amount of processing needed to scan through lists of certain characters which are not always linear in order (thus multiple scans are needed). With ASCII this appears to be significantly easier given that uppercase range from 0x41-0x5a and lowercase from 0x61-0x7a. There's significantly less "stuff" to do in this situation. His statement, despite vague/no technical reference details, does make sense to me. I should also state (I forget if I did already) that the delays seen weren't actually "in" read(2) -- truss -d shows the amount of time that passes between syscalls. The delays I was seeing were *between* read(2) calls, which acts as a further indicator that some code internal to grep (or libc) was spinning/churning much more heavily when a locale was used. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange performance issue with grep -r -i as non-root user
On Sat, Mar 05, 2011 at 07:07:20PM -0800, Jeremy Chadwick wrote: ... > $ unset LANG > - Result: still 80x slower with -i > $ unset LANG LC_COLLATE > - Result: still 80x slower with -i > $ unset LANG LC_CTYPE > - Result: normal/fast. > $ unset LC_CTYPE > - Result: still 80x slower with -i > $ unset LC_CTYPE LC_COLLATE > - Result: still 80x slower with -i > $ unset LC_COLLATE > - Result: still 80x slower with -i > > So the LANG + LC_CTYPE combo when used together are what cause this. Doesn't the above say that having either one set does it? I would guess it's probably that either one requires the 8.x grep -i to make a conversion function call for each char (or perhaps line) of input to ensure the proper upper/lower case conversion rules are followed. -- Clifton -- Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange performance issue with grep -r -i as non-root user
On Sat, Mar 05, 2011 at 09:46:04PM -0500, Gary Palmer wrote:
> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote:
> > This is a strange one, and the more I started debugging it (starting
> > with truss, comparing fast vs. slow results, where all that appears
> > different is read() operations are taking a lot longer -- I haven't had
> > time to check with ktrace yet), the more strange it got: that's when I
> > found out the behaviour changes depending on if you're a user or root.
> >
> > Easy to reproduce:
> >
> > - grep -r string /usr/src, as non-root, is fast
> > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i
> > - grep -r string /usr/src, as root, is fast
> > - grep -r -i string /usr/src, as root, is fast
>
> This is a stab in the dark, but are there any differences in your
> shell environment variables between root and non-root? Specifically
> LANG or LC_ style variables. I ran into issues in the past with grep
> being horrendously slow and traced it to LANG or LC_* in the environment
> causing a much longer code path than without the settings.
Bingo -- you found it, Gary. Thank you very much. I hadn't thought of
LANG/LC_* variables but I did think of dotfile or shell differences, but
didn't test them thoroughly.
My dotfiles do make use of LANG/LC_CTYPE/LC_COLLATE:
export LANG="en_GB.UTF-8"
export LC_CTYPE="en_GB.UTF-8"
export LC_COLLATE="C"
Testing on System #1:
$ unset LANG LC_CTYPE LC_COLLATE
$ for i in {0..9}; do /usr/bin/time -h grep -r PAE /usr/src/sys/dev > /dev/null
; done
0.18s real 0.11s user 0.06s sys
0.15s real 0.09s user 0.05s sys
0.12s real 0.06s user 0.05s sys
0.12s real 0.06s user 0.05s sys
0.12s real 0.07s user 0.04s sys
0.12s real 0.08s user 0.03s sys
0.12s real 0.08s user 0.03s sys
0.12s real 0.07s user 0.04s sys
0.12s real 0.08s user 0.03s sys
0.12s real 0.07s user 0.04s sys
$ for i in {0..9}; do /usr/bin/time -h grep -r -i PAE /usr/src/sys/dev >
/dev/null ; done
0.13s real 0.11s user 0.02s sys
0.13s real 0.10s user 0.03s sys
0.13s real 0.08s user 0.05s sys
0.13s real 0.09s user 0.04s sys
0.13s real 0.08s user 0.05s sys
0.13s real 0.11s user 0.02s sys
0.13s real 0.10s user 0.03s sys
0.13s real 0.11s user 0.02s sys
0.13s real 0.09s user 0.03s sys
0.13s real 0.08s user 0.05s sys
I wanted to track it down to a specific variable or combo:
$ unset LANG
- Result: still 80x slower with -i
$ unset LANG LC_COLLATE
- Result: still 80x slower with -i
$ unset LANG LC_CTYPE
- Result: normal/fast.
$ unset LC_CTYPE
- Result: still 80x slower with -i
$ unset LC_CTYPE LC_COLLATE
- Result: still 80x slower with -i
$ unset LC_COLLATE
- Result: still 80x slower with -i
So the LANG + LC_CTYPE combo when used together are what cause this.
I'm not sure what's going on with locale, but given the nasty
side-effects it should probably be documented somewhere; maybe in
setlocale(3)? Unsure.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange performance issue with grep -r -i as non-root user
On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: > This is a strange one, and the more I started debugging it (starting > with truss, comparing fast vs. slow results, where all that appears > different is read() operations are taking a lot longer -- I haven't had > time to check with ktrace yet), the more strange it got: that's when I > found out the behaviour changes depending on if you're a user or root. > > Easy to reproduce: > > - grep -r string /usr/src, as non-root, is fast > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i > - grep -r string /usr/src, as root, is fast > - grep -r -i string /usr/src, as root, is fast This is a stab in the dark, but are there any differences in your shell environment variables between root and non-root? Specifically LANG or LC_ style variables. I ran into issues in the past with grep being horrendously slow and traced it to LANG or LC_* in the environment causing a much longer code path than without the settings. Regards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange performance issue with grep -r -i as non-root user
On 5 March 2011 21:05, Jeremy Chadwick wrote: > On Sat, Mar 05, 2011 at 08:49:46PM -0500, ill...@gmail.com wrote: >> On 5 March 2011 20:43, Jeremy Chadwick wrote: >> > On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote: >> >> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: >> >> > This is a strange one, and the more I started debugging it (starting >> >> > with truss, comparing fast vs. slow results, where all that appears >> >> > different is read() operations are taking a lot longer -- I haven't had >> >> > time to check with ktrace yet), the more strange it got: that's when I >> >> > found out the behaviour changes depending on if you're a user or root. >> >> > >> >> > Easy to reproduce: >> >> > >> >> > - grep -r string /usr/src, as non-root, is fast >> >> > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i >> >> >> >> From your results below, I think you mean *80* x slower! >> > >> > Oops; yes, typo on my part. I was never any good at math either! ;-) >> > >> >> > - grep -r string /usr/src, as root, is fast >> >> > - grep -r -i string /usr/src, as root, is fast >> >> >> >> I can not reproduce this on 7.3-RELEASE-p4; I get consistent results >> >> between root and non-root, with -i being only marginally slower (about >> >> 15%) for each; results below. >> > >> > Your results look more or less like what I see on the 4th system (the >> > 7.0-STABLE one). I believe the speed difference there (and on your >> > system) is justified, as I would imagine strcasecmp() a tiny bit slower >> > than strcmp(). But an 80x slowdown is completely unacceptable, >> > especially given the conditions. >> > >> > My first thought was "compiler optimisation bug?", which I suppose could >> > still be the case, but I don't know how root vs. non-root would change >> > that behaviour, not to mention only when -i was specified. >> > >> > Using 'truss -d' it looks like the slowdown is happening on read(2), >> > which makes me very concerned, as it could indicate something odd going >> > on with CAM? Sadly I cannot (for many reasons) get rid of ahci.ko on >> > any of those 3 systems, so I can't compare stock ata(4) to ahci.ko >> > easily on the same system. >> > >> >> On my 8.2-RELEASE system using ahci (built into the custom >> kernel) I don't notice your observed slowdown, so unless ahci >> is radically different on -STABLE I doubt it's the cause. > > There are two versions of AHCI available in FreeBSD: ahci.ko (which is > AHCI<->CAM) and ataahci.ko (which is AHCI support under ata(4) natively > and does not use CAM). Which of the two are you using? I have device ahci in my kernel, ataahci, not. > sysctl -a | grep ahci dev.ahci.0.%desc: ATI IXP600 AHCI SATA controller dev.ahci.0.%driver: ahci dev.ahci.0.%location: slot=18 function=0 handle=\_SB_.PCI0.SATA dev.ahci.0.%pnpinfo: vendor=0x1002 device=0x4380 subvendor=0x1179 subdevice=0xff68 class=0x01018f dev.ahci.0.%parent: pci0 dev.ahcich.0.%desc: AHCI channel dev.ahcich.0.%driver: ahcich dev.ahcich.0.%location: channel=0 dev.ahcich.0.%parent: ahci0 dev.ahcich.1.%desc: AHCI channel dev.ahcich.1.%driver: ahcich dev.ahcich.1.%location: channel=1 dev.ahcich.1.%parent: ahci0 dev.ahcich.2.%desc: AHCI channel dev.ahcich.2.%driver: ahcich dev.ahcich.2.%location: channel=2 dev.ahcich.2.%parent: ahci0 dev.ahcich.3.%desc: AHCI channel dev.ahcich.3.%driver: ahcich dev.ahcich.3.%location: channel=3 dev.ahcich.3.%parent: ahci0 HTH -- -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Question about packages installed via `pkg_add -r`
On Sat, Mar 05, 2011 at 08:46:47PM -0500, ill...@gmail.com wrote: > On 5 March 2011 20:14, Yue Wu wrote: > > On Sat, Mar 05, 2011 at 08:02:47PM -0500, ill...@gmail.com wrote: > >> On 5 March 2011 20:00, Yue Wu wrote: > >> > Hello, sorry for poor English, I will try to explan clearer with my > >> > best. > >> > > >> > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: > >> >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > >> >> > >> >> > I'm trying to use package instead of ports these day, but a few > >> >> > questions have: > >> >> > > >> >> > 1. How to reserve packages that fetched via `pkg_add -r`? > >> >> > > >> >> > 2. How to know if there are updates for packages, and how to update? > >> >> > >> >> For (1), do you mean 'preserve', as in save a copy? If so, then > >> >> 'portmaster -b [...]' will save a backup copy of installed packages. > >> > > >> > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a > >> > installed package, so it will preserve it by packing up the files from a > >> > installed package, why not preserve it just when fetching with `pkg_add > >> > -r`? I think it's the best way, I don't like the portmaster way to do it > >> > after. > >> > >> from man 1 pkg_add: > >> > >> -K, --keep > >> Keep any downloaded package in PKGDIR if it is defined or in > >> cur- > >> rent directory by default. > >> > > > > Thanks, sorry for no attentively reading ;p > > > > Another question arises after checking the pkg 'pkg_add' saves, why the > > pkg doesn't have a version appended to its name, it's hard to know the > > version the pkg downloaded... > > Without digging in too deeply (I use ports, so I'm not the > _most_ knowledgeable on packages) I believe it has to > do with the fact that the packages are symlinked to non- > versioned names on the distribution server(s), probably > to simplify fetching. The packages themselves should > have the version information in their metadata somewhere, > which might be possible to rename via script. > > I apologise if that isn't helpful. Thank you for info, I got the reason :) ports with portmaster makes pkg installation mangement be much more flexiable and more friendly than package by pkg_add -r on FreeBSD, except that ports take much more time and resource. After trying with packages, I think I have to stick to ports. -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange performance issue with grep -r -i as non-root user
On Sat, Mar 05, 2011 at 08:49:46PM -0500, ill...@gmail.com wrote: > On 5 March 2011 20:43, Jeremy Chadwick wrote: > > On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote: > >> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: > >> > This is a strange one, and the more I started debugging it (starting > >> > with truss, comparing fast vs. slow results, where all that appears > >> > different is read() operations are taking a lot longer -- I haven't had > >> > time to check with ktrace yet), the more strange it got: that's when I > >> > found out the behaviour changes depending on if you're a user or root. > >> > > >> > Easy to reproduce: > >> > > >> > - grep -r string /usr/src, as non-root, is fast > >> > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i > >> > >> From your results below, I think you mean *80* x slower! > > > > Oops; yes, typo on my part. I was never any good at math either! ;-) > > > >> > - grep -r string /usr/src, as root, is fast > >> > - grep -r -i string /usr/src, as root, is fast > >> > >> I can not reproduce this on 7.3-RELEASE-p4; I get consistent results > >> between root and non-root, with -i being only marginally slower (about > >> 15%) for each; results below. > > > > Your results look more or less like what I see on the 4th system (the > > 7.0-STABLE one). I believe the speed difference there (and on your > > system) is justified, as I would imagine strcasecmp() a tiny bit slower > > than strcmp(). But an 80x slowdown is completely unacceptable, > > especially given the conditions. > > > > My first thought was "compiler optimisation bug?", which I suppose could > > still be the case, but I don't know how root vs. non-root would change > > that behaviour, not to mention only when -i was specified. > > > > Using 'truss -d' it looks like the slowdown is happening on read(2), > > which makes me very concerned, as it could indicate something odd going > > on with CAM? Sadly I cannot (for many reasons) get rid of ahci.ko on > > any of those 3 systems, so I can't compare stock ata(4) to ahci.ko > > easily on the same system. > > > > On my 8.2-RELEASE system using ahci (built into the custom > kernel) I don't notice your observed slowdown, so unless ahci > is radically different on -STABLE I doubt it's the cause. There are two versions of AHCI available in FreeBSD: ahci.ko (which is AHCI<->CAM) and ataahci.ko (which is AHCI support under ata(4) natively and does not use CAM). Which of the two are you using? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Question about packages installed via `pkg_add -r`
On 5 March 2011 20:14, Yue Wu wrote: > On Sat, Mar 05, 2011 at 08:02:47PM -0500, ill...@gmail.com wrote: >> On 5 March 2011 20:00, Yue Wu wrote: >> > Hello, sorry for poor English, I will try to explan clearer with my >> > best. >> > >> > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: >> >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: >> >> >> >> > I'm trying to use package instead of ports these day, but a few >> >> > questions have: >> >> > >> >> > 1. How to reserve packages that fetched via `pkg_add -r`? >> >> > >> >> > 2. How to know if there are updates for packages, and how to update? >> >> >> >> For (1), do you mean 'preserve', as in save a copy? If so, then >> >> 'portmaster -b [...]' will save a backup copy of installed packages. >> > >> > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a >> > installed package, so it will preserve it by packing up the files from a >> > installed package, why not preserve it just when fetching with `pkg_add >> > -r`? I think it's the best way, I don't like the portmaster way to do it >> > after. >> >> from man 1 pkg_add: >> >> -K, --keep >> Keep any downloaded package in PKGDIR if it is defined or in >> cur- >> rent directory by default. >> > > Thanks, sorry for no attentively reading ;p > > Another question arises after checking the pkg 'pkg_add' saves, why the > pkg doesn't have a version appended to its name, it's hard to know the > version the pkg downloaded... Without digging in too deeply (I use ports, so I'm not the _most_ knowledgeable on packages) I believe it has to do with the fact that the packages are symlinked to non- versioned names on the distribution server(s), probably to simplify fetching. The packages themselves should have the version information in their metadata somewhere, which might be possible to rename via script. I apologise if that isn't helpful. -- -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange performance issue with grep -r -i as non-root user
On 5 March 2011 20:43, Jeremy Chadwick wrote: > On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote: >> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: >> > This is a strange one, and the more I started debugging it (starting >> > with truss, comparing fast vs. slow results, where all that appears >> > different is read() operations are taking a lot longer -- I haven't had >> > time to check with ktrace yet), the more strange it got: that's when I >> > found out the behaviour changes depending on if you're a user or root. >> > >> > Easy to reproduce: >> > >> > - grep -r string /usr/src, as non-root, is fast >> > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i >> >> From your results below, I think you mean *80* x slower! > > Oops; yes, typo on my part. I was never any good at math either! ;-) > >> > - grep -r string /usr/src, as root, is fast >> > - grep -r -i string /usr/src, as root, is fast >> >> I can not reproduce this on 7.3-RELEASE-p4; I get consistent results >> between root and non-root, with -i being only marginally slower (about >> 15%) for each; results below. > > Your results look more or less like what I see on the 4th system (the > 7.0-STABLE one). I believe the speed difference there (and on your > system) is justified, as I would imagine strcasecmp() a tiny bit slower > than strcmp(). But an 80x slowdown is completely unacceptable, > especially given the conditions. > > My first thought was "compiler optimisation bug?", which I suppose could > still be the case, but I don't know how root vs. non-root would change > that behaviour, not to mention only when -i was specified. > > Using 'truss -d' it looks like the slowdown is happening on read(2), > which makes me very concerned, as it could indicate something odd going > on with CAM? Sadly I cannot (for many reasons) get rid of ahci.ko on > any of those 3 systems, so I can't compare stock ata(4) to ahci.ko > easily on the same system. > On my 8.2-RELEASE system using ahci (built into the custom kernel) I don't notice your observed slowdown, so unless ahci is radically different on -STABLE I doubt it's the cause. -- -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange performance issue with grep -r -i as non-root user
On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote: > On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: > > This is a strange one, and the more I started debugging it (starting > > with truss, comparing fast vs. slow results, where all that appears > > different is read() operations are taking a lot longer -- I haven't had > > time to check with ktrace yet), the more strange it got: that's when I > > found out the behaviour changes depending on if you're a user or root. > > > > Easy to reproduce: > > > > - grep -r string /usr/src, as non-root, is fast > > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i > > From your results below, I think you mean *80* x slower! Oops; yes, typo on my part. I was never any good at math either! ;-) > > - grep -r string /usr/src, as root, is fast > > - grep -r -i string /usr/src, as root, is fast > > I can not reproduce this on 7.3-RELEASE-p4; I get consistent results > between root and non-root, with -i being only marginally slower (about > 15%) for each; results below. Your results look more or less like what I see on the 4th system (the 7.0-STABLE one). I believe the speed difference there (and on your system) is justified, as I would imagine strcasecmp() a tiny bit slower than strcmp(). But an 80x slowdown is completely unacceptable, especially given the conditions. My first thought was "compiler optimisation bug?", which I suppose could still be the case, but I don't know how root vs. non-root would change that behaviour, not to mention only when -i was specified. Using 'truss -d' it looks like the slowdown is happening on read(2), which makes me very concerned, as it could indicate something odd going on with CAM? Sadly I cannot (for many reasons) get rid of ahci.ko on any of those 3 systems, so I can't compare stock ata(4) to ahci.ko easily on the same system. ktrace is next, but I have other things to do during the next few hours, then I can spend some cycles on this. > Just to satisfy my peace of mind, can you do 'which grep' and 'sudo sh > -c "which grep"' as jdc to make sure it's not path-related weirdness? It's definitely not path weirdness, which is why I pointed out that the greps on all the systems are identical. Here's a more detailed version: * System #1 $ which grep ; grep --version | head -1 ; sudo sh -c 'which grep ; grep --version | head -1' ; ls -l `which grep` /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD -r-xr-xr-x9 root wheel 86936 1 Mar 00:22 /usr/bin/grep * System #2 $ which grep ; grep --version | head -1 ; sudo sh -c 'which grep ; grep --version | head -1' ; ls -l `which grep` /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD -r-xr-xr-x9 root wheel 86936 25 Feb 00:13 /usr/bin/grep * System #3 $ which grep ; grep --version | head -1 ; sudo sh -c 'which grep ; grep --version | head -1' ; ls -l `which grep` /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD -r-xr-xr-x9 root wheel 86936 20 Oct 02:14 /usr/bin/grep * System #4 (the one without the issue) $ which grep ; grep --version | head -1 ; sudo sh -c 'which grep ; grep --version | head -1' ; ls -l `which grep` /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD -r-xr-xr-x9 root wheel 76728 19 Apr 2008 /usr/bin/grep The file size difference should be expected given that it's a significantly older system, and i386 as well. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Question about packages installed via `pkg_add -r`
On Sat, Mar 05, 2011 at 08:02:47PM -0500, ill...@gmail.com wrote: > On 5 March 2011 20:00, Yue Wu wrote: > > Hello, sorry for poor English, I will try to explan clearer with my > > best. > > > > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: > >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > >> > >> > I'm trying to use package instead of ports these day, but a few > >> > questions have: > >> > > >> > 1. How to reserve packages that fetched via `pkg_add -r`? > >> > > >> > 2. How to know if there are updates for packages, and how to update? > >> > >> For (1), do you mean 'preserve', as in save a copy? If so, then > >> 'portmaster -b [...]' will save a backup copy of installed packages. > > > > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a > > installed package, so it will preserve it by packing up the files from a > > installed package, why not preserve it just when fetching with `pkg_add > > -r`? I think it's the best way, I don't like the portmaster way to do it > > after. > > from man 1 pkg_add: > > -K, --keep > Keep any downloaded package in PKGDIR if it is defined or in cur- > rent directory by default. > Thanks, sorry for no attentively reading ;p Another question arises after checking the pkg 'pkg_add' saves, why the pkg doesn't have a version appended to its name, it's hard to know the version the pkg downloaded... -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Question about packages installed via `pkg_add -r`
On 5 March 2011 20:00, Yue Wu wrote: > Hello, sorry for poor English, I will try to explan clearer with my > best. > > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: >> >> > I'm trying to use package instead of ports these day, but a few >> > questions have: >> > >> > 1. How to reserve packages that fetched via `pkg_add -r`? >> > >> > 2. How to know if there are updates for packages, and how to update? >> >> For (1), do you mean 'preserve', as in save a copy? If so, then >> 'portmaster -b [...]' will save a backup copy of installed packages. > > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a > installed package, so it will preserve it by packing up the files from a > installed package, why not preserve it just when fetching with `pkg_add > -r`? I think it's the best way, I don't like the portmaster way to do it > after. from man 1 pkg_add: -K, --keep Keep any downloaded package in PKGDIR if it is defined or in cur- rent directory by default. -- -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange performance issue with grep -r -i as non-root user
On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote:
> This is a strange one, and the more I started debugging it (starting
> with truss, comparing fast vs. slow results, where all that appears
> different is read() operations are taking a lot longer -- I haven't had
> time to check with ktrace yet), the more strange it got: that's when I
> found out the behaviour changes depending on if you're a user or root.
>
> Easy to reproduce:
>
> - grep -r string /usr/src, as non-root, is fast
> - grep -r -i string /usr/src, as non-root, is 8x slower than without -i
From your results below, I think you mean *80* x slower!
> - grep -r string /usr/src, as root, is fast
> - grep -r -i string /usr/src, as root, is fast
I can not reproduce this on 7.3-RELEASE-p4; I get consistent results
between root and non-root, with -i being only marginally slower (about
15%) for each; results below.
Just to satisfy my peace of mind, can you do 'which grep' and 'sudo sh
-c "which grep"' as jdc to make sure it's not path-related weirdness?
-- Clifton
[cliftonr@oz ~]$ id
uid=1001(cliftonr) gid=1001(cliftonr)
groups=1001(cliftonr),0(wheel),1002(svn-user),1000(users)
[cliftonr@oz ~]$ for i in {0..9}; do /usr/bin/time -h /usr/bin/grep -r \
PAE /usr/src/sys/dev > /dev/null; done
12.10s real 0.16s user 0.21s sys
0.20s real 0.12s user 0.08s sys
...
[cliftonr@oz ~]$ for i in {0..9}; do /usr/bin/time -h /usr/bin/grep -r \
PAE /usr/src/sys/dev > /dev/null; done
0.20s real 0.11s user 0.09s sys
0.20s real 0.13s user 0.06s sys
0.20s real 0.12s user 0.08s sys
0.20s real 0.12s user 0.07s sys
0.20s real 0.14s user 0.06s sys
0.20s real 0.15s user 0.05s sys
0.20s real 0.12s user 0.08s sys
0.20s real 0.09s user 0.11s sys
0.20s real 0.14s user 0.06s sys
0.20s real 0.12s user 0.07s sys
[cliftonr@oz ~]$ for i in {0..9}; do /usr/bin/time -h /usr/bin/grep -r \
-i PAE /usr/src/sys/dev > /dev/null; done
0.23s real 0.14s user 0.08s sys
0.23s real 0.15s user 0.07s sys
0.23s real 0.18s user 0.05s sys
0.23s real 0.14s user 0.08s sys
0.23s real 0.19s user 0.03s sys
0.23s real 0.18s user 0.04s sys
0.23s real 0.14s user 0.08s sys
0.23s real 0.13s user 0.09s sys
0.23s real 0.16s user 0.06s sys
0.22s real 0.17s user 0.05s sys
[cliftonr@oz ~]$ sudo -v
[cliftonr@oz ~]$ for i in {0..9}; do sudo /usr/bin/time -h \
/usr/bin/grep -r PAE /usr/src/sys/dev > /dev/null; done
0.20s real 0.18s user 0.02s sys
0.20s real 0.10s user 0.10s sys
0.20s real 0.14s user 0.06s sys
0.20s real 0.13s user 0.06s sys
0.20s real 0.12s user 0.08s sys
0.20s real 0.12s user 0.07s sys
0.20s real 0.12s user 0.08s sys
0.20s real 0.12s user 0.08s sys
0.20s real 0.16s user 0.03s sys
0.20s real 0.15s user 0.05s sys
[cliftonr@oz ~]$ for i in {0..9}; do sudo /usr/bin/time -h \
/usr/bin/grep -r -i PAE /usr/src/sys/dev > /dev/null; done
0.23s real 0.17s user 0.05s sys
0.23s real 0.16s user 0.06s sys
0.23s real 0.17s user 0.05s sys
0.23s real 0.17s user 0.06s sys
0.23s real 0.17s user 0.06s sys
0.23s real 0.18s user 0.05s sys
0.23s real 0.17s user 0.05s sys
0.23s real 0.14s user 0.08s sys
0.23s real 0.15s user 0.08s sys
0.22s real 0.13s user 0.09s sys
[cliftonr@oz ~]$ which grep
/usr/bin/grep
[cliftonr@oz ~]$ sudo sh -c "which grep"
/usr/bin/grep
--
Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net
President - I and I Computing * http://www.iandicomputing.com/
Custom programming, network design, systems and network consulting services
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/m
Re: Question about packages installed via `pkg_add -r`
Hello, sorry for poor English, I will try to explan clearer with my best. On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: > On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > > > I'm trying to use package instead of ports these day, but a few > > questions have: > > > > 1. How to reserve packages that fetched via `pkg_add -r`? > > > > 2. How to know if there are updates for packages, and how to update? > > For (1), do you mean 'preserve', as in save a copy? If so, then > 'portmaster -b [...]' will save a backup copy of installed packages. Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a installed package, so it will preserve it by packing up the files from a installed package, why not preserve it just when fetching with `pkg_add -r`? I think it's the best way, I don't like the portmaster way to do it after. > > There may be a better way, but one way to deal with (2) is to have an > up-to-date ports tree. Then 'pkg_version -vL=' will show you which of > your ports are out of date. Then 'portmaster -PP [...]' will force > package use for updates. > > If you have an up-to-date ports tree, then I think that > > portmaster -abPP > > will update all of your ports, using packages, and save a backup copy > of the installed versions. I'm trying to avoid to touch the port tree, it has 700+ MB... On Sat, Mar 05, 2011 at 12:43:21PM -0800, Doug Barton wrote: > On 03/05/2011 07:48, Greg Byshenk wrote: > > On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > > > >> I'm trying to use package instead of ports these day, but a few > >> questions have: > >> > >> 1. How to reserve packages that fetched via `pkg_add -r`? > > Not sure what you're asking here, can you clarify? Sorry, Greg has guessed it right ;p > >> 2. How to know if there are updates for packages, and how to update? > > > > There may be a better way, but one way to deal with (2) is to have an > > up-to-date ports tree. Then 'pkg_version -vL=' will show you which of > > your ports are out of date. Then 'portmaster -PP [...]' will force > > package use for updates. > > > > If you have an up-to-date ports tree, then I think that > > > > portmaster -abPP > > The -PP option has to be by itself on the command line, or you can use > --packages-only. > > However portmaster doesn't need a ports tree to operate on packages > only. You can use the --index-only --packages-only options and it'll > work just fine. You'll want to read the man page before getting started. > Is it the only way? As I said above, I don't like portmaster's way, I thought there might be a cmd package-update just like freebsd-update, but seems it doesn't, even doesn't have a KISS way to know if there are updates for packages. -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Strange performance issue with grep -r -i as non-root user
This is a strange one, and the more I started debugging it (starting
with truss, comparing fast vs. slow results, where all that appears
different is read() operations are taking a lot longer -- I haven't had
time to check with ktrace yet), the more strange it got: that's when I
found out the behaviour changes depending on if you're a user or root.
Easy to reproduce:
- grep -r string /usr/src, as non-root, is fast
- grep -r -i string /usr/src, as non-root, is 8x slower than without -i
- grep -r string /usr/src, as root, is fast
- grep -r -i string /usr/src, as root, is fast
$ id
uid=1000(jdc) gid=1000(users) groups=1000(users),0(wheel)
$ for i in {0..9}; do /usr/bin/time -h grep -r PAE /usr/src/sys/dev > /dev/null
; done
0.17s real 0.11s user 0.05s sys
0.12s real 0.06s user 0.05s sys
0.12s real 0.09s user 0.02s sys
0.12s real 0.07s user 0.04s sys
0.12s real 0.10s user 0.01s sys
0.12s real 0.08s user 0.03s sys
0.12s real 0.07s user 0.04s sys
0.12s real 0.10s user 0.01s sys
0.12s real 0.06s user 0.05s sys
0.12s real 0.07s user 0.04s sys
$ for i in {0..9}; do /usr/bin/time -h grep -r -i PAE /usr/src/sys/dev >
/dev/null ; done
8.85s real 8.78s user 0.05s sys
8.80s real 8.76s user 0.00s sys
8.82s real 8.77s user 0.01s sys
8.81s real 8.75s user 0.02s sys
^Ctime: command terminated abnormally
$ for i in {0..9}; do sudo /usr/bin/time -h grep -r PAE /usr/src/sys/dev >
/dev/null ; done
0.19s real 0.11s user 0.08s sys
0.11s real 0.09s user 0.02s sys
0.11s real 0.09s user 0.02s sys
0.11s real 0.07s user 0.04s sys
0.11s real 0.09s user 0.02s sys
0.11s real 0.08s user 0.02s sys
0.11s real 0.07s user 0.04s sys
0.11s real 0.08s user 0.02s sys
0.11s real 0.07s user 0.04s sys
0.11s real 0.07s user 0.04s sys
$ for i in {0..9}; do sudo /usr/bin/time -h grep -r -i PAE /usr/src/sys/dev >
/dev/null ; done
0.19s real 0.10s user 0.08s sys
0.16s real 0.10s user 0.05s sys
0.13s real 0.08s user 0.05s sys
0.13s real 0.09s user 0.03s sys
0.13s real 0.11s user 0.02s sys
0.13s real 0.10s user 0.03s sys
0.13s real 0.11s user 0.02s sys
0.13s real 0.09s user 0.04s sys
0.13s real 0.09s user 0.03s sys
0.13s real 0.09s user 0.04s sys
I can reproduce the issue on 3 different physical machines, with a 4th
being completely immune to it (the machine runs a very old 7.0-STABLE,
uses i386, and does not use ahci.ko (AHCI->CAM)). It's reproducible at
any time (e.g. unrelated to disk I/O), and is unrelated to system
uptime.
All machines are using UFS2+softupdates for their /usr filesystem, which
is where /usr/src lives.
All machines use base system gcc and base system grep, which all appear
to be gcc version 4.2.1 20070719 and grep (GNU grep) 2.5.1-FreeBSD.
Hardware in the machines is slightly different (some with faster CPUs
than others, and some use SSDs instead of mechanical HDDs), but the
SATA controllers/etc. are all the same (ICH9R).
When reading part of the uname string, please trust me when I say that
the kernel build time is basically synonymous when with src-all was
csup'd. :-)
* System #1: FreeBSD 8.2-STABLE #0: Tue Mar 1 00:17:25 PST 2011 amd64
Supermicro X7SBA, 8GB ECC RAM
3:43pm up 1 day, 9:12, 2 users, load averages: 0.06, 0.02, 0.00
ada0: ATA-7 SATA 2.x device
Filesystem 1024-blocksUsed Avail Capacity Mounted on
/dev/ada0s1f 8395622 3376560 434741444%/usr
make.conf contains: CPUTYPE?=core2
* System #2: FreeBSD 8.2-STABLE #0: Thu Feb 24 22:06:45 PST 2011 amd64
Supermicro PDSMi+, 8GB ECC RAM
3:43pm up 8 days, 15:26, 1 user, load averages: 0.00, 0.00, 0.00
ada0: ATA-8 SATA 2.x device
Filesystem 1024-blocksUsed Avail Capacity Mounted on
/dev/ada0s1f 217798292 2761536 197612894 1%/usr
make.conf contains: CPUTYPE?=core2
* System #3: FreeBSD 8.1-STABLE #0: Wed Oct 20 00:54:42 PDT 2010 amd64
Supermicro PDSMi+, 8GB ECC RAM
Re: NFS client over udp
> Rick, > I have good news. I upgraded to 8.2-stable and i ran all four > different tests (nfs client new and old and over udp and tcp) and > found that there is no leak in either. ALl of them behave almost the > same, i couldn't find any difference. The speed i achieved on 1Gb link > is 52Mb/s. The only difference is that i can't umount new nfs client > even if there are no processes using this mount point. Thanks for help > Kirill > Ok, sounds good, although I have no idea what might have plugged the leak. (I looked at the revision log for clnt_dg.c and udp_usrreq.c and I couldn't spot anything that might have fixed an mbuf leak.) As for the "can't unmount", I assume that it reports the mount pt as busy? (I've never seen this for the exp. client, so I have no idea what the cause might be for this. Possibly some "failure" code path that lacks a vput()/vrele() that I've never exercised?) Anyhow, good to hear about the above, rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Change in behavior to stat(1)
On 03/04/2011 11:05, Jilles Tjoelker wrote:
On Mon, Feb 28, 2011 at 11:15:39AM -0600, Stephen Montgomery-Smith wrote:
I had a little script that would remove broken links. I used to do it
like this:
if ! stat -L $link> /dev/null; then rm $link; fi
But recently (some time in February according to the CVS records) stat
was changed so that stat -L would use lstat(2) if the link is broken.
So I had to change it to
if stat -L $link | awk '{print $3}' | grep l> /dev/null;
then rm $link; fi
but it is a lot less elegant.
What is the proper accepted way to remove broken links?
A better answer to your original question was already given, but for
that command, isn't it sufficient to do
if ! [ -e $link ]; then rm $link; fi
All test(1)'s primaries that test things about files follow symlinks,
except for -h/-L.
I'd do '[ -e "$link" ] || unlink $link' but Jilles is definitely right
that simply using 'test -e' is the way to go.
Stephen, sorry to hear that the change in behavior to stat(1) was
troubling to you. A little bit of the history might be useful. I
originally imported stat(1) from NetBSD in 2002, but did not keep up
with the improvements that NetBSD made to it. I recently found time to
catch up with the work that they've done, and the change to the behavior
of readlink seemed like a useful one so I brought it over. hopefully it
won't cause too many more problems. :)
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: service(8) doesn't list dhcpd startscript
On 03/04/2011 14:51, Miroslav Lachman wrote: Hilko Meyer wrote: Hi, today I played a bit with service(8) and I noticed that it doesn't properly detects the isc-dhcpd-startscript. System is 7.3-RELEASE-p4. 'service -l' lists isc-dhcpd but 'service -e' doesn't lists it: | hilti@kirk:~> service -l | grep dhcp | isc-dhcpd | hilti@kirk:~> service -e | grep dhcp | hilti@kirk:~> /usr/local/etc/rc.d/isc-dhcpd rcvar | # dhcpd | dhcpd_enable=YES It works for me on newer version of the FreeBSD (7.4-RELEASE) and with newer dhcpd (isc-dhcp41-server-4.1.2_2,1) ~/# service -l | grep dhcp isc-dhcpd isc-dhcpd6 ~/# service -e | grep dhcp /usr/local/etc/rc.d/isc-dhcpd /usr/local/etc/rc.d/isc-dhcpd6 ~/# /usr/local/etc/rc.d/isc-dhcpd rcvar # dhcpd dhcpd_enable=YES So you can compare rc scripts for those two versions or compare changes in service between these two FreeBSD releases. I'm glad to hear that Miroslav was able to make it work. I looked at the code and it's pretty simple, so I'm not sure why it would fail. Hilko, if you can add -x to the end of the #!/bin/sh line in /usr/sbin/service it might give you more of an idea of what's going on. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Question about packages installed via `pkg_add -r`
On 03/05/2011 07:48, Greg Byshenk wrote: On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: I'm trying to use package instead of ports these day, but a few questions have: 1. How to reserve packages that fetched via `pkg_add -r`? Not sure what you're asking here, can you clarify? 2. How to know if there are updates for packages, and how to update? There may be a better way, but one way to deal with (2) is to have an up-to-date ports tree. Then 'pkg_version -vL=' will show you which of your ports are out of date. Then 'portmaster -PP [...]' will force package use for updates. If you have an up-to-date ports tree, then I think that portmaster -abPP The -PP option has to be by itself on the command line, or you can use --packages-only. However portmaster doesn't need a ports tree to operate on packages only. You can use the --index-only --packages-only options and it'll work just fine. You'll want to read the man page before getting started. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Question about packages installed via `pkg_add -r`
On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > I'm trying to use package instead of ports these day, but a few > questions have: > > 1. How to reserve packages that fetched via `pkg_add -r`? > > 2. How to know if there are updates for packages, and how to update? For (1), do you mean 'preserve', as in save a copy? If so, then 'portmaster -b [...]' will save a backup copy of installed packages. There may be a better way, but one way to deal with (2) is to have an up-to-date ports tree. Then 'pkg_version -vL=' will show you which of your ports are out of date. Then 'portmaster -PP [...]' will force package use for updates. If you have an up-to-date ports tree, then I think that portmaster -abPP will update all of your ports, using packages, and save a backup copy of the installed versions. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ath(4) panic + stuck beacon issue
I'm the ath maintainer now it seems. "stuck beacon" means a lot of things. Debugging it is going to mean better understanding what is going on in your environment that's being handled incorrectly. A lot of the reasons I've seen stuck beacons creep up is because the radio environment gets periodically noisy and the driver handles that very badly. Step 1 is compiling your kernel with: options ATH_DEBUG options AH_DEBUG options ATH_DIAGAPI Then the next thing to do is to enable calibration debugging: sysctl hw.ath.hal.debug=0x8 That'll spit out some debugging every 30 seconds that reports the noise floor that the card is calibrating against. Then you can try repeating that with the longcal interval tweaked up to say 1 second (it defaults to 30), to see if it's fluctuating: sysctl hw.ath.longcal=1 There's some other things which can help but I need to finish porting some diagnostic code to the ath code in -HEAD. If you feel adventurous, you could try running the -HEAD if_ath code under RELENG_8. I do this as a module for my testing. There's been some changes which MAY make the AR5416 behave better. The AR9280 unfortunately requires some more work. I'm in the process right now of porting over some code from Linux ath9k to try and fix TX stability issues. If it works for you then great, but it's going to be hit and miss. The (more) technical reasons: * The "stuck beacon" can be a variety of reasons, some of which are touched on the madwifi site. But non-RF issues aside (ie, DMA timing, busy bus, etc), almost all of the issues are due to a noisy environment where the card just gets into a state where it thinks it can't transmit. Buying me a card would be nice :) but since it's very likely environmental related, I'd have to somehow determine and reproduce that problem. I've got some diagnostic tools here which log things like channel TX/RX/busy status which helps determine this stuff, but I just don't have the time right now to port all of that over and fix up things for 11n. Sorry. :( * Specifically, ath cards have very sensitive RX. The periodic noise floor calibration sets the CCA threshold for "when the air is too busy to transmit!" which is based on what the calibrated NF level is. (Ie, it establishes what the median noise floor is over successive 30 second samples, then uses this as the CCA threshold.) This can become quite low (lower than -90dBm on the AR5416/AR9160, down to lower than -100dBm on the AR9280.) But if noise then appears that's above a low-set CCA threshold, the radio thinks it can't transmit and it resets with "stuck beacon." The default CCA threshold is higher than what it calibrates down to over time, so that's why you (generally) see the radio work fine for a few minutes before resetting. * I've discovered some AR9280 based cards have different methods of calibrating TX power. We handle the "older" method, but not the "newer" method. It turns out this AR9280 card I have here has the "newer" method. Since there's no easy way for the average user to know what they have (without inspecting the EEPROM contents to see what the manufacturer did), it'll raise its ugly head as "it works for me!" for some, and "it doesn't work stable for me!" for others. * The AR5416 support in ath9k is in no way verified, stable or tested. So it's possible that improvements I bring over from ath9k to fix AR9280 and AR9285 issues will break previous 11n family chips (AR5416/AR9160.) I'm trying to be mindful of this and test where I can, but it's not easy. HTH, Adrian On 28 February 2011 00:01, Jeremy Chadwick wrote: > I have a crash report to provide (for RELENG_8 dated 2010/02/12), but > I'd like to know who's maintaining ath(4) at this point in time. > > I also need to discuss a commonly-reported issue with AR5416 and/or > AR9280 cards (e.g. D-Link DWA-552 running in 802.11g mode w/ WEP) > spitting out "stuck beacon" errors, which are what I was trying to > resolve when the kernel crashed. (I induced the crash, but I'm not sure > exactly why/how). > > Given that the issue has existed for years now... > > http://www.daemonforums.org/showthread.php?t=3388 > http://forums.freebsd.org/showthread.php?t=5983 > http://forum.pfsense.org/index.php?topic=21374.0 > http://forum.pfsense.org/index.php?topic=32041.0 > > http://www.broadbandreports.com/forum/r25070916-FreeBSD-MIPS-dev-Adrian-Chad-on-stuck-beacon-issue > http://forums.freebsd.org/showthread.php?t=22112 (recent & thorough!) > > ...and "bintval 1000" does not solve it, let's work together to find a > solution. If you need hardware I will be more than happy to buy you > (brand new) cards which you can keep. If you have beta/test drivers > and/or can provide *thorough* debugging instructions, I will be more > than happy to do what I can. > > I'll also point out the Linux madwifi folks have an *entire page* > dedicated to this problem, which is quite interesting: > > http://madwifi-project.org/wiki/StuckBeacon > > If a workaround or solution
Question about packages installed via `pkg_add -r`
Hi, list, I'm trying to use package instead of ports these day, but a few questions have: 1. How to reserve packages that fetched via `pkg_add -r`? 2. How to know if there are updates for packages, and how to update? -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Linker set issues with ath(4) HALs
On 2011-Mar-05 11:48:54 +0200, Kostik Belousov wrote:
>On Sat, Mar 05, 2011 at 07:50:05PM +1100, Peter Jeremy wrote:
>> I have a Atheros AR5424 and so, based on the 8.2-STABLE i386 NOTES
>> and some rummaging in the sources, I tried to build a kernel with:
>>
>> device ath # Atheros pci/cardbus NIC's
>> device ath_ar5212 # HAL for Atheros AR5212 and derived
>> chips
>> device ath_rate_sample # SampleRate tx rate control for ath
...
>> These symbols do not appear in any other .o files, though there are a
>> variety of other __{start,stop}_set_* symbols - all of which show up
>> as 'A' (absolule) values in the final kernel.
>>
>> My questions are:
>> How are these linker set references resolved? I can't find anything
>> that defines these symbols - either in .o files or in ldscript files.
...
>Linker synthesizes the symbols assuming the following two conditions are
>met:
>- the symbols are referenced;
>- there exists an ELF section named `set_ah_rfs'.
>It assigns the (relocated) start of the section to __start_,
>and end to __stop_.
Thank you for that. Looking through the output of 'objdump -h' showed
that it was user error: When using "device ath_ar", it looks like
you need to include a "device ath_rf" as well. After a closer
look at my dmesg and available options, I've add "device ath_rf2425"
and things seem much happier.
--
Peter Jeremy
pgpI70wFRMecY.pgp
Description: PGP signature
Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!)
Hello, Steven. You wrote 5 марта 2011 г., 3:06:32: > Silly question but have you checked your ram for issues, we had a machine > with seemingly unexplained problems and hangs and it turned out to be > a duff stick of ram which wasn't being chip killed. Yes, two full days (48h) of memtest86+ -- no problems... -- // Black Lion AKA Lev Serebryakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Linker set issues with ath(4) HALs
On Sat, Mar 05, 2011 at 07:50:05PM +1100, Peter Jeremy wrote:
> I have a Atheros AR5424 and so, based on the 8.2-STABLE i386 NOTES
> and some rummaging in the sources, I tried to build a kernel with:
>
> deviceath # Atheros pci/cardbus NIC's
> deviceath_ar5212 # HAL for Atheros AR5212 and derived
> chips
> deviceath_rate_sample # SampleRate tx rate control for ath
>
> and this died during the kernel linking with:
> linking kernel.debug
> ah.o(.text+0x23c): In function `ath_hal_rfprobe':
> /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to
> `__start_set_ah_rf
> s'
> ah.o(.text+0x241):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference
> to `__stop_set_ah_rfs'
> ah.o(.text+0x25a):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference
> to `__stop_set_ah_rfs'
>
> Following a suggestion by a friend, I changed that to:
>
> deviceath # Atheros pci/cardbus NIC's
> options AH_SUPPORT_AR5416
> deviceath_hal # Atheros HAL
> deviceath_rate_sample # SampleRate tx rate control for ath
>
> and it worked. Normally, I would leave it at that but I'd like to
> understand what is actually going on...
>
> In both cases, ah.o contains the following 4 references:
> U __start_set_ah_chips
> U __start_set_ah_rfs
> U __stop_set_ah_chips
> U __stop_set_ah_rfs
> generated by:
> /* linker set of registered chips */
> OS_SET_DECLARE(ah_chips, struct ath_hal_chip);
> /* linker set of registered RF backends */
> OS_SET_DECLARE(ah_rfs, struct ath_hal_rf);
>
> These symbols do not appear in any other .o files, though there are a
> variety of other __{start,stop}_set_* symbols - all of which show up
> as 'A' (absolule) values in the final kernel.
>
> My questions are:
> How are these linker set references resolved? I can't find anything
> that defines these symbols - either in .o files or in ldscript files.
>
> In the first case, there are 2 pairs of undefined linker set variables
> but the linker only reports one pair as unresolved. Why don't both
> sets show up as resolved or unresolved? Why does using the generic
> "ath_hal", rather than the hardware-specific HAL fix the problem?
Linker synthesizes the symbols assuming the following two conditions are
met:
- the symbols are referenced;
- there exists an ELF section named `set_ah_rfs'.
It assigns the (relocated) start of the section to __start_,
and end to __stop_.
Most likely, omitting the option causes some SET_ENTRY() macro, which put
a symbol into linker set, to be ommitted. Then, no section is created
and linker does not synthesizes the missed symbols.
pgp26WSwRNadH.pgp
Description: PGP signature
Linker set issues with ath(4) HALs
I have a Atheros AR5424 and so, based on the 8.2-STABLE i386 NOTES
and some rummaging in the sources, I tried to build a kernel with:
device ath # Atheros pci/cardbus NIC's
device ath_ar5212 # HAL for Atheros AR5212 and derived chips
device ath_rate_sample # SampleRate tx rate control for ath
and this died during the kernel linking with:
linking kernel.debug
ah.o(.text+0x23c): In function `ath_hal_rfprobe':
/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rf
s'
ah.o(.text+0x241):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to
`__stop_set_ah_rfs'
ah.o(.text+0x25a):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to
`__stop_set_ah_rfs'
Following a suggestion by a friend, I changed that to:
device ath # Atheros pci/cardbus NIC's
options AH_SUPPORT_AR5416
device ath_hal # Atheros HAL
device ath_rate_sample # SampleRate tx rate control for ath
and it worked. Normally, I would leave it at that but I'd like to
understand what is actually going on...
In both cases, ah.o contains the following 4 references:
U __start_set_ah_chips
U __start_set_ah_rfs
U __stop_set_ah_chips
U __stop_set_ah_rfs
generated by:
/* linker set of registered chips */
OS_SET_DECLARE(ah_chips, struct ath_hal_chip);
/* linker set of registered RF backends */
OS_SET_DECLARE(ah_rfs, struct ath_hal_rf);
These symbols do not appear in any other .o files, though there are a
variety of other __{start,stop}_set_* symbols - all of which show up
as 'A' (absolule) values in the final kernel.
My questions are:
How are these linker set references resolved? I can't find anything
that defines these symbols - either in .o files or in ldscript files.
In the first case, there are 2 pairs of undefined linker set variables
but the linker only reports one pair as unresolved. Why don't both
sets show up as resolved or unresolved? Why does using the generic
"ath_hal", rather than the hardware-specific HAL fix the problem?
--
Peter Jeremy
pgpL0aiDu3NMN.pgp
Description: PGP signature
