Re: Runaway intr, not flash related
On 8/15/10, Doug Barton wrote: > On 08/14/2010 09:54, b. f. wrote: >>> My "runaway intr" problem with flash has been continuing all >>> along, but since no one has been interested in helping with it I >>> haven't reported it for a while. However, today, for the first >>> time, it happened when I had not run flash at all since I booted. >>> >>> My system: Dell D620, C2D, i386, SMP, r210908 >>> >>> swi4: clock is the culprit again this time, but when flash >>> triggers this problem I sometimes see hdac as the culprit, FYI. > The problem happens MOST often when I'm viewing a flash video, but it > can also happen other times. Interestingly, what often happens is that > everything is fine while I'm viewing the video, but intr runs away after > I close the window. I was sort of surprised by this myself, but now I > have verified it numerous times. > > It happens without running flash (as I pointed out in this message) and > last night I was able to trigger it several times without running X at all. > > The usual device that runs away is the clock, but sometimes (about 1 in > 20) it's hdac. > What were you doing when you triggered the interrupt problem without running X? Was there a lot of network, audio device, or disk activity at the time? Are these failures without X consistently reproducible, or unpredictable? Can you remember the revision number of the last version of -CURRENT that didn't have these problems? b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Runaway intr, not flash related
On 08/14/2010 20:30, Doug Barton wrote: I'm still using powerd, and it seems to be working as expected. Sorry, I should have added here that I've also tried running WITHOUT powerd, and the runaway intr problem still happens. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Runaway intr, not flash related
On 08/14/2010 09:54, b. f. wrote: My "runaway intr" problem with flash has been continuing all along, but since no one has been interested in helping with it I haven't reported it for a while. However, today, for the first time, it happened when I had not run flash at all since I booted. My system: Dell D620, C2D, i386, SMP, r210908 swi4: clock is the culprit again this time, but when flash triggers this problem I sometimes see hdac as the culprit, FYI. I wouldn't say that no one is interested in helping. Yes, that was perhaps too strongly worded, sorry. What I meant to say was something more along the lines of, "Since I've tried everything that everyone has suggested so far, and none of it has helped, and no new suggestions have magically appeared, but I'm still having the same problem " (And I think you've received a few more suggestions than your other recent message to freebsd-developers suggests.) For my part, I find it a bit difficult to track the status of your interrupt problem, and the interactivity problem, which may or may not be related. Sorry that I'm making your life difficult. :) I have actually tried to report stuff that people have asked for, but I'll give you the full status update here. Before I answer all your questions below though, I wanted to say something about why I don't think it's hardware related (although none of this is conclusive, and I agree I could be wrong). The problem happens MOST often when I'm viewing a flash video, but it can also happen other times. Interestingly, what often happens is that everything is fine while I'm viewing the video, but intr runs away after I close the window. I was sort of surprised by this myself, but now I have verified it numerous times. It happens without running flash (as I pointed out in this message) and last night I was able to trigger it several times without running X at all. It DOESN'T happen with loads that produce a lot more heat than my typical desktop workloads (like say, make -j2 buildworld). The usual device that runs away is the clock, but sometimes (about 1 in 20) it's hdac. Back to flash, for a while I couldn't get it to work at all from the browser, but the hulu desktop binary worked great. Right now, the hulu desktop app causes the runaway almost immediately, but flash is working great in the browser. To me this sounds a lot like software, not hardware. --Have you ruled out any contribution from overheating, like I think you were experiencing before with this machine? I think so, yes. I've been keeping a very close eye on the heat, and blowing out the heat sink a lot more often. Also, see above about the fact that higher-heat loads don't make the problem happen more often. At one point, you were following some of mav@'s suggestions for power-saving, but then you posted a configuration that suggested that you had abandoned some of these settings and returned to the defaults. Right, the problem was happening with those settings, and I wanted to make sure that those weren't the cause. I didn't experience any more heat problems with the defaults, so I left it alone. So are you running hot, or being throttled now? No, and yes. :) I'm still using powerd, and it seems to be working as expected. Have you tried running at a kern.hz< 1000, with throttling disabled, to see if that ameliorates the problem? That's how I was running with the settings mav suggested. I just tried reducing back to 100, but didn't adjust the throttling settings. We'll see how that works. --What graphics driver are you using? For X, the nv driver from xorg. When I was on the console last night I was using the xterm console driver. You were using x11/nvidia-driver, but then after the kib@ and alc@'s vm changes that led to problems with that driver, I thought you were using x11-drivers/xf86-video-nv -- is that still the case? Does switching drivers seem to influence the frequency or severity of the problems? I've tried numerous versions of the nvidia driver over the last several months, with various locking patches to make them work on -current, and they introduce their own problems (generally freeze ups, or random panics, as I've reported previously). Therefore I haven't been using the nvidia driver at all recently. --When do you experience these problems? Do they ever occur when you are _not_ running X? Yes. Have you tried temporarily disabling your usb and network devices, to see if they are contributing to the problem? I haven't tried the usb driver, but I have tried using a different network card (and turning off the built-in version with the hardware switch), no help there. Are you able to watch flash videos from local media, as opposed to those from a remote site, without problems? I haven't tried that, but I will, thanks. --Did you follow mav@'s suggestion to use something other than your hpet for the eventcounter and timecounter? The possible use of the hpet is one of the main d
Re: Official request: Please make GNU grep the default
My $0.02 may not be worth much, but ... On Aug 14, 2010, at 9:55 PM, Doug Barton wrote: I was hoping to avoid commenting on this, but my feeling (and I would be glad to be wrong about it) from reading the responses is that there is a fair degree of knee-jerk reaction to what seems to be "There's big bad dougb picking on some poor innocent developer again!" going on here; and criticizing MY development skills either A) makes you feel better, B) makes you think that you're dishing out to me a little of what you think I'm dishing out to Gabor, or both. Well fine, hope you're feeling good about yourself, and you made me feel really small and bad. Good on you. Meanwhile, substitute my stupid way of doing things and defective programming skills for any other workload of your choice. Are you really going to tell me you've never had to grep a 20,000 line file? Are you really going to tell me that you've never had to grep something the size of the FreeBSD source and/or ports trees for all the instances of $FOO? And you didn't answer either of the questions I had in the post you responded to, so let me make it easier for you. Our default grep should be significantly slower than the old grep because: I think that new grep which is times slower than the old grep is still in the acceptable range. Doug Why not perform a run or two with portmaster and bsdgrep with profiling, and send Gabor those results? It would certainly help pinpoint the slowdown, and you would have something to point to to say "X in bsdgrep is slow, so we should switch back to GNU grep until that's fixed" rather than just "bsdgrep is slow, fix it". Like most people here, I agree that such a performance difference is rather unacceptable for a production system, but since this is -current, fixing the performance issue should be done rather than casting the whole thing aside until it's up to par. There are 28 messages in this thread already, with no consensus in sight. - Justin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On 15 August 2010 13:55, Doug Barton wrote: > Our default grep should be significantly slower than the old grep because: > > I think that new grep which is times slower than the old grep is still > in the acceptable range. I think that new grep which is 1000 times slower than the old grep is still in the acceptable range. Can we drop this now. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
TIMEOUT (was: Re: Official request: Please make GNU grep the default)
Hi all, Over the past 18 hours, I've received 22 emails in this thread. In email number 5, sent a mere 25 minutes after the thread started, gabor@ said that he agreed that the performance penalty in BSD grep compared to GNU grep was excessive and that he was going to revert back to having GNU grep as the default. Why are we still discussing this? If and when gabor@ (or someone else) has improved BSD grep performance and thinks that it's time to flip the switch back again, I'm sure there will be ample opportunity for everybody to run their favourite grep benchmarks, report numbers, and discuss the performance differences before BSD grep is (re-)made the default. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On 08/14/2010 19:02, Randy Bush wrote: I think that new grep which is times slower than the old grep is still in the acceptable range. you are forcing more time to be spent on the mailing list than working the code. Not my intention at all, but I feel your pain. I really thought this was a slam dunk or I wouldn't have even brought it up. and many of us have to care about the license issue. But you're covered on the license issue. The code is in the base already, and no one is suggesting removing it (as Warner pointed out earlier today). What I REALLY don't want to see happen here is a "religious fervor about the license is more important than performance" situation. If I wanted that kind of drama I'd use linux. (OTOH religious fervor about proving me wrong is almost as amusing as it is unfortunate, but that doesn't negatively impact our users.) Meanwhile, I'm pretty confident this is my last post on the issue of changing the default. I've said everything I wanted to say, and obviously it's not as clear cut as I thought it was. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
> I think that new grep which is times slower than the old grep is > still in the acceptable range. you are forcing more time to be spent on the mailing list than working the code. and many of us have to care about the license issue. randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
nvidia-driver not work
Hello all I installed the FreeBSD/amd64 8.0 and updated to 9-CURRENT with csup Following... # cp /usr/share/examples/cvsup/standard-supfile /root && cd /root && sed -ie 's/CHANGE_THIS/cvsup.de/g' standard-supfile && sed -ie 's/CHANGE_THIS/./g' standard-supfile && csup -g -L 2 /root/standard-supfile Downloaded files... # cd /usr/src && make buildworld All good, now, i compiled the kernel with my conf # cd /usr/src/sys/amd64/conf && mdkir /root/kernels && cp GENERIC /root/kernels/SPACE && ee /root/kernels/SPACE && ln -s /root/kernels/SPACE && cd /usr/src && make buildkernel KERNCONF=SPACE && make installkernel KERNCONF=SPACE This is my kernel http://pastebin.com/1NpvzNp6 $ dmesg (cut) panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759 cpuid = 0 Uptime: 3m35s Dump failed. Partition too small. Automatic reboot in 15 seconds - press a key on the console to abort panic: bufwrite: buffer is not busy??? cpuid = 0 Uptime: 3m35s Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0: Sat Aug 14 19:58:17 WEST 2010 t...@x0term.lan:/usr/obj/usr/src/sys/SPACE amd64 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3015.07-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Family = f Model = 43 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 4294967296 (4096 MB) vgapci0: port 0xec00-0xec7f mem 0xfd00-0xfdff,0xf000-0xf7ff,0xfa00-0xfbff irq 21 at device 0.0 on pci2 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] I compiled to nvidia-driver next to install kernel, and i charge to this, here good, work, but i try $ startx with Driver "nvidia" on xorg.conf and the pc is not responding, screen is black. With nv and vesa work. I dont understand this -> Dump failed. Partition too small. -> My root partition has got a 435GB only ocupated 17GB and swap 512MB Can help me? This is a primary failed to nvidia-driver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On 08/14/2010 18:34, Steve Kargl wrote: On Sat, Aug 14, 2010 at 06:12:34PM -0700, Doug Barton wrote: Sophisticated users who DO care about performance and/or DO use grep in interesting and creative ways will put up with the breakage for a while, then switch their make.conf to use GNU grep, usually silently. Therefore they stop providing ANY test data at all, never mind useful. Whereas switching the default back to GNU grep ... until the performance is acceptably comparable ... *guarantees* neither unsophisticated nor sophosticated user will test BSD grep. ... except for those who are already highly motivated to do so. It seems that you are letting a poor design decision with respect to portmaster impair others contribution to FreeBSD. I was hoping to avoid commenting on this, but my feeling (and I would be glad to be wrong about it) from reading the responses is that there is a fair degree of knee-jerk reaction to what seems to be "There's big bad dougb picking on some poor innocent developer again!" going on here; and criticizing MY development skills either A) makes you feel better, B) makes you think that you're dishing out to me a little of what you think I'm dishing out to Gabor, or both. Well fine, hope you're feeling good about yourself, and you made me feel really small and bad. Good on you. Meanwhile, substitute my stupid way of doing things and defective programming skills for any other workload of your choice. Are you really going to tell me you've never had to grep a 20,000 line file? Are you really going to tell me that you've never had to grep something the size of the FreeBSD source and/or ports trees for all the instances of $FOO? And you didn't answer either of the questions I had in the post you responded to, so let me make it easier for you. Our default grep should be significantly slower than the old grep because: I think that new grep which is times slower than the old grep is still in the acceptable range. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On Sat, Aug 14, 2010 at 06:12:34PM -0700, Doug Barton wrote: > > Sophisticated users who DO care about performance and/or DO use grep in > interesting and creative ways will put up with the breakage for a while, > then switch their make.conf to use GNU grep, usually silently. Therefore > they stop providing ANY test data at all, never mind useful. > Whereas switching the default back to GNU grep *guarantees* neither unsophisticated nor sophosticated user will test BSD grep. It seems that you are letting a poor design decision with respect to portmaster impair others contribution to FreeBSD. I suspect that you could have added a USE_GREP knob to the port infrastructure and updated your port to use ports/textproc/gnugrep in the time that you have used to post and reply here. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On 08/14/2010 09:10, Gabor Kovesdan wrote: > Em 2010.08.13. 10:52, Roman Divacky escreveu: >> what about optimizing BSD grep instead? >> > [... picking one mail from the many that suggest this ...] ... and responding to your message for the same reason ... :) [Snipping the bit about why it's a hard problem not likely to be solved in the next few weeks.] > If you can make suggestions to make BSD grep faster without touching the > regex library please do it and if we can get a performance that is > acceptable, we can reconsider leaving it the default if nobody objects. > I'll check Sean's suggestions and make some measures how much does that > help. As I posted to you privately, the results I got with JUST Sean's patch on the test case I posted previously were: GNU grep Elapsed time: 2 seconds BSD grep Elapsed time: 31 seconds With the more complete patch you provided me privately I was able to shave one more second off the BSD grep case. So that's a lot better than the 47 seconds it was previously, but still a long way to go. I also have a new test case script which actually IS something that portmaster does, and in fact is the ugliest and most difficult search that it has to perform, finding an installed port based on grep'ing +CONTENTS files for an ORIGIN pattern: http://people.freebsd.org/~dougb/grep-time-trial-2.sh.txt Typical times for me, with 489 ports: GNU grep Elapsed time: 3 seconds BSD grep Elapsed time: 17 seconds (And before anyone bothers to reply saying "Use pkg_info -O for that" I'll save you the trouble. My version is from 10-20% faster. Not sure why, don't really care.) :) For those whose line of reasoning was, "But this is -current, so it's ok for things to be screwed up" my response is, only to a point. In the real world, people who don't care about performance and/or don't use grep in interesting and imaginative ways aren't going to mind BSD grep as the default, but also don't provide really useful test cases. "It works fine up to the 80'th percentile" has already been demonstrated by various pointyhat runs, etc. Sophisticated users who DO care about performance and/or DO use grep in interesting and creative ways will put up with the breakage for a while, then switch their make.conf to use GNU grep, usually silently. Therefore they stop providing ANY test data at all, never mind useful. However, given the very small number of people who actually test -current in the first place, the population I am really concerned about is the group of people who casually try -current, see that "It's really slow sometimes," don't/can't figure out why, and then get discouraged and just stop using -current at all. Now you might reply, "Great! Good riddance to those dilettantes!" However I believe rather strongly that we want to make the -current environment MORE friendly to users, even casual users. Who do you think is actually going to test "What will become 9.0-RELEASE" if we don't? OTOH, leaving it in, but switching the default gives those who are highly motivated to test and/or improve it a very easy way to do so, without causing problems for anyone else. It also makes it that much easier to make it the default again when it IS ready for prime time. Meanwhile, in response to everyone else, a simple question. How many TIMES (not percentages, multiples) slower is it Ok for BSD grep to be in comparison to GNU grep and stay the default? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
Ivan, I know that you mean this at least semi-humorously, however I'm going to provide a dead-serious reply below. On 08/14/2010 16:04, Ivan Voras wrote: > On 13.8.2010 11:34, Doug Barton wrote: > >> To be fair, I didn't notice a performance difference either until I >> started revamping this code that calls my parse_index() for every single >> installed port. Given a 22,042 line INDEX file, that's enough to add up >> to something noticeable. > > Wouldn't this might, just might, be an indication that one of the > following is true: > > 1) writing complex performance-sensitive utilities in shell code simply > sucks because it's too sensitive to issues like borderline behaviours of > utilities As someone who used to make a pretty good living writing highly performance-oriented CGI applications in perl I would agree with you here to some extent. The original version of what could reasonably be called an antecedent to what is now portmaster was 102 lines, but only 49 were actual code (the rest were comments or whitespace). The current behemoth (my dev version that is) is 3,702 lines, 3,069 of which is actual code. So yes, there is an element of insanity here (and yes, the current code is under-commented, for those keeping score at home). > 2) implementing complex data structures that might save you reparsing on > the order of complexity of O(npkg * nlines) is too demanding in shell > code and this means it's not exactly the best tool for the job Again, partial agreement. One of the reasons I resisted INDEX support for so long was that my original idea of it was to do exactly what you suggest here, parse it once then look up the data internally. However even though I _can_ do this in shell it actually makes the performance worse since now I've got his huge memory footprint to pass around every time portmaster calls itself recursively (which for those who don't know is portmaster's entire model of operation). BUT, none of that is germane to my actual argument. I was very careful to NOT say, "BSD grep is slow, which screws up portmaster, so the default has to change." What I said was, "BSD grep is anywhere from 6 to 15 TIMES slower than GNU grep in all cases, so the default needs to change." If you insist on applying that directly to portmaster, I will say that implementing it in shell is a very conscious design tradeoff. If I hadn't already observed the hilarity ensuing around portupgrade/ruby updates, and I was sitting down today to design a "ports management tool" from scratch, I'd use perl, no question. Even without its own db everything that portmaster does could be done more easily and faster in perl. However, even granting THIS point the fact remains that the previous status quo was 1) a text file data store with a known, (mostly) easy to parse structure, and 2) an easy to use, fast tool to access that data with. Your line of reasoning boils down to, "You shouldn't object to the new tool being slower because you are doing things you shouldn't have been doing with the old tool in the first place." Even IF I were willing to grant you that point inre portmaster (I'm not, but let's just say ...) are you willing to tell every user of grep for every other purpose (including all the many places it's used in the base, like /etc, /etc/rc.d, the build ), "You have to put up with a slow grep because ?" Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On 13.8.2010 11:34, Doug Barton wrote: > On 08/13/2010 02:08, Gabor Kovesdan wrote: >> Ok, I'll take care of this soon, and make GNU grep default, again with a >> knob to build BSD grep. I agree with you that we cannot allow such a big >> performance drawback but I my measures only showed significant >> differences for very big searches and I didn't imagine that it could add >> up to such a big diference. > > To be fair, I didn't notice a performance difference either until I > started revamping this code that calls my parse_index() for every single > installed port. Given a 22,042 line INDEX file, that's enough to add up > to something noticeable. Wouldn't this might, just might, be an indication that one of the following is true: 1) writing complex performance-sensitive utilities in shell code simply sucks because it's too sensitive to issues like borderline behaviours of utilities 2) implementing complex data structures that might save you reparsing on the order of complexity of O(npkg * nlines) is too demanding in shell code and this means it's not exactly the best tool for the job ? This post brought to you by The Legue for Retiring Shell Scripts Longer Than 100 Lines - our motto is "Fighting against the tide - why not?" :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
In message: <4c66c0a4.3000...@freebsd.org> Gabor Kovesdan writes: : Yes, I'm sorry for my slow reaction, I got a flu some time ago and : that prevented me from fixing the bugs earlier. I have several fixes : in my working copy, which are being discussed with my : mentor. Probably, today or tomorrow they will be committed. I don't see a huge issue with it being default for a while, so your slowness due to flu is OK, imho. This is -current after all, and bumps in the road are to be expected. Reverting to gnu-grep being default is likely good until you can resolve the issues that you've talked about in other posts. IMHO, it's unlikely additional testing and exposure will, at this time, give you any new information. Once things have been tuned up, problems fixed, etc, it would likely make sense to try this again (with special attention to the issues raised this time, since there's good reason to believe people will try them first thing if the switch is thrown back to default again). I hope you're leaving it in the tree as an option, however, since BSD grep is good enough for many users of grep. They have been using it for years and years without hassle as a port because their grep needs are simple, and performance requirements modest. For these folks, license is the deciding factor. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic: Kernel page fault with ath0_com_lock held, r211295
On Sat, Aug 14, 2010 at 19:43, David Wolfskill wrote: > On Sat, Aug 14, 2010 at 07:05:40PM +0200, Bernhard Schmidt wrote: >> ... >> > OK; I reverted by doing this: >> > >> > g1-46(9.0-C)[1] cd /usr/src >> > g1-46(9.0-C)[2] svn merge -c -211295 file:///svn/freebsd/src/base/head >> > --- Reverse-merging r211295 into 'sys': >> > U sys/net80211/ieee80211_node.c >> > U sys/net80211/ieee80211_sta.c >> > g1-46(9.0-C)[3] >> > >> > I then re-built the kernel and rebooted (with the ath(4) card inserted): >> > [..] >> > I think that qualifies as "working". >> >> Indeed, please try attached patch. > > Patch applied cleanly; rebuilt kernel; rebooted OK: Thanks, I've committed a 'slightly' different version. Drivers which aren't using the ratectl framework should be unaffected by any changes regarding ratectl in the future. Sorry for the noise. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic: Kernel page fault with ath0_com_lock held, r211295
On Sat, Aug 14, 2010 at 07:05:40PM +0200, Bernhard Schmidt wrote: > ... > > OK; I reverted by doing this: > > > > g1-46(9.0-C)[1] cd /usr/src > > g1-46(9.0-C)[2] svn merge -c -211295 file:///svn/freebsd/src/base/head > > --- Reverse-merging r211295 into 'sys': > > U sys/net80211/ieee80211_node.c > > U sys/net80211/ieee80211_sta.c > > g1-46(9.0-C)[3] > > > > I then re-built the kernel and rebooted (with the ath(4) card inserted): > > [..] > > I think that qualifies as "working". > > Indeed, please try attached patch. Patch applied cleanly; rebuilt kernel; rebooted OK: g1-219(9.0-C)[1] uname -a FreeBSD g1-219.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #91 r211295M: Sat Aug 14 10:22:11 PDT 2010 r...@g1-219.catwhisker.org.:/usr/obj/usr/src/sys/CANARY i386 g1-219(9.0-C)[2] ifconfig xl0: flags=8802 metric 0 mtu 1500 options=80009 ether 00:08:74:e9:c9:41 media: Ethernet autoselect (none) status: no carrier fwe0: flags=8802 metric 0 mtu 1500 options=8 ether 42:4f:c0:2c:30:41 ch 1 dma -1 fwip0: flags=8802 metric 0 mtu 1500 lladdr 42.4f.c0.0.7.2c.30.41.a.2.ff.fe.0.0.0.0 iwi0: flags=8843 metric 0 mtu 2290 ether 00:0e:35:aa:11:ca media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated plip0: flags=8810 metric 0 mtu 1500 ipfw0: flags=8801 metric 0 mtu 65536 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 nd6 options=21 ath0: flags=8843 metric 0 mtu 2290 ether 00:40:96:a7:a7:01 media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: associated wlan1: flags=8843 metric 0 mtu 1500 ether 00:0e:35:aa:11:ca media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 5 (2432 MHz 11g) country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF txpower 0 bmiss 24 scanvalid 60 protmode CTS wme roaming MANUAL bintval 0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:40:96:a7:a7:01 inet 172.17.1.219 netmask 0x broadcast 172.17.255.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b status: associated ssid lmdhw-net channel 6 (2437 MHz 11b) bssid 00:60:1d:f1:ed:d3 regdomain FCC indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpower 23 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 wme burst g1-219(9.0-C)[3] Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpUWJtj4coXo.pgp Description: PGP signature
Re: Panic: Kernel page fault with ath0_com_lock held, r211295
On Sat, Aug 14, 2010 at 18:47, David Wolfskill wrote: > On Sun, Aug 15, 2010 at 12:07:13AM +0800, Adrian Chadd wrote: >> You should be able to revert the ath changes reasonably easy. >> >> Would you mind doing that and see if that fixes or contributes to the >> problem? > > OK; I reverted by doing this: > > g1-46(9.0-C)[1] cd /usr/src > g1-46(9.0-C)[2] svn merge -c -211295 file:///svn/freebsd/src/base/head > --- Reverse-merging r211295 into 'sys': > U sys/net80211/ieee80211_node.c > U sys/net80211/ieee80211_sta.c > g1-46(9.0-C)[3] > > I then re-built the kernel and rebooted (with the ath(4) card inserted): > [..] > I think that qualifies as "working". Indeed, please try attached patch. -- Bernhard ratectl_node_init.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On 2010-08-14 17:53, Andrey Chernov wrote: > From my point of > view importing of the latest GNU grep instead would have more benefits. Unfortunately GNU grep switched to GPLv3 as of version 2.5.3. The last GPLv2 version of grep is 2.5.1, which is already in our tree. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Runaway intr, not flash related
>My "runaway intr" problem with flash has been continuing all along, but >since no one has been interested in helping with it I haven't reported >it for a while. However, today, for the first time, it happened when I >had not run flash at all since I booted. > >My system: >Dell D620, C2D, i386, SMP, r210908 > >swi4: clock is the culprit again this time, but when flash triggers this >problem I sometimes see hdac as the culprit, FYI. I wouldn't say that no one is interested in helping. (And I think you've received a few more suggestions than your other recent message to freebsd-developers suggests.) For my part, I find it a bit difficult to track the status of your interrupt problem, and the interactivity problem, which may or may not be related. --Have you ruled out any contribution from overheating, like I think you were experiencing before with this machine? At one point, you were following some of mav@'s suggestions for power-saving, but then you posted a configuration that suggested that you had abandoned some of these settings and returned to the defaults. So are you running hot, or being throttled now? Have you tried running at a kern.hz < 1000, with throttling disabled, to see if that ameliorates the problem? --What graphics driver are you using? You were using x11/nvidia-driver, but then after the kib@ and alc@'s vm changes that led to problems with that driver, I thought you were using x11-drivers/xf86-video-nv -- is that still the case? Does switching drivers seem to influence the frequency or severity of the problems? --When do you experience these problems? Do they ever occur when you are _not_ running X? Have you tried temporarily disabling your usb and network devices, to see if they are contributing to the problem? Are you able to watch flash videos from local media, as opposed to those from a remote site, without problems? --Did you follow mav@'s suggestion to use something other than your hpet for the eventcounter and timecounter? The possible use of the hpet is one of the main differences between the new and old timing code, and you reported some problems with your hpet earlier. --Did you follow attilio@'s suggestion to obtain scheduling traces for the interactivity problem, as described in src/tools/sched/schedgraph.py? b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic: Kernel page fault with ath0_com_lock held, r211295
On Sun, Aug 15, 2010 at 12:07:13AM +0800, Adrian Chadd wrote: > You should be able to revert the ath changes reasonably easy. > > Would you mind doing that and see if that fixes or contributes to the problem? OK; I reverted by doing this: g1-46(9.0-C)[1] cd /usr/src g1-46(9.0-C)[2] svn merge -c -211295 file:///svn/freebsd/src/base/head --- Reverse-merging r211295 into 'sys': Usys/net80211/ieee80211_node.c Usys/net80211/ieee80211_sta.c g1-46(9.0-C)[3] I then re-built the kernel and rebooted (with the ath(4) card inserted): g1-219(9.0-C)[1] uname -a FreeBSD g1-219.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #90 r211295M: Sat Aug 14 09:30:55 PDT 2010 r...@g1-46.catwhisker.org.:/usr/obj/usr/src/sys/CANARY i386 g1-219(9.0-C)[2] ifconfig xl0: flags=8802 metric 0 mtu 1500 options=80009 ether 00:08:74:e9:c9:41 media: Ethernet autoselect (none) status: no carrier fwe0: flags=8802 metric 0 mtu 1500 options=8 ether 42:4f:c0:2c:30:41 ch 1 dma -1 fwip0: flags=8802 metric 0 mtu 1500 lladdr 42.4f.c0.0.7.2c.30.41.a.2.ff.fe.0.0.0.0 iwi0: flags=8843 metric 0 mtu 2290 ether 00:0e:35:aa:11:ca media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated plip0: flags=8810 metric 0 mtu 1500 ipfw0: flags=8801 metric 0 mtu 65536 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 nd6 options=21 ath0: flags=8843 metric 0 mtu 2290 ether 00:40:96:a7:a7:01 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan1: flags=8843 metric 0 mtu 1500 ether 00:0e:35:aa:11:ca media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 5 (2432 MHz 11g) country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF txpower 0 bmiss 24 scanvalid 60 protmode CTS wme roaming MANUAL bintval 0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:40:96:a7:a7:01 inet 172.17.1.219 netmask 0x broadcast 172.17.255.255 media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11g status: associated ssid lmdhw-net channel 11 (2462 MHz 11g) bssid 08:10:75:08:8c:1c regdomain FCC indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpower 21 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst g1-219(9.0-C)[3] I think that qualifies as "working". Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp5NRPlpbfHS.pgp Description: PGP signature
Re: Panic: Kernel page fault with ath0_com_lock held, r211295
You should be able to revert the ath changes reasonably easy. Would you mind doing that and see if that fixes or contributes to the problem? Thanks, Adrian On 14 August 2010 23:29, David Wolfskill wrote: > Previously built @r211278; just build r211295 this morning, and didn't > quite pass the smoke test. I'll attach core.txt; here are highlights: > > FreeBSD localhost 9.0-CURRENT FreeBSD 9.0-CURRENT #89 r211295: Sat Aug 14 > 07:34:56 PDT 2010 r...@g1-219.catwhisker.org.:/usr/obj/usr/src/sys/CANARY > i386 > ... > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex ath0_com_lock (ath0_com_lock) r = 0 (0xc896e014) locked > @ /usr/src/sys/net80211/ieee80211_scan.c:957 > KDB: stack backtrace: > db_trace_self_wrapper(c0cb0eda,c53b9aa0,c08d93e5,3bd,0,...) at 0xc04da736 = > db_trace_self_wrapper+0x26 > kdb_backtrace(3bd,0,,c0f47aac,c53b9ad8,...) at 0xc08c4319 = > kdb_backtrace+0x29 > _witness_debugger(c0cb3689,c53b9aec,4,1,0,...) at 0xc08d93e5 = > _witness_debugger+0x25 > witness_warn(5,0,c0ceadbf,c08d0229,c0e04de0,...) at 0xc08da8ee = > witness_warn+0x1fe > trap(c53b9b78) at 0xc0bd9835 = trap+0x195 > calltrap() at 0xc0bc0b9c = calltrap+0x6 > --- trap 0xc, eip = 0xc0962604, esp = 0xc53b9bb8, ebp = 0xc53b9bd8 --- > amrr_node_init(c8d3c000,c7d18d2e,c7d18d3f,1,c8d37800,...) at 0xc0962604 = > amrr_node_init+0x84 > ieee80211_sta_join(c8cac000,c896e320,c7d18d00,1,c896e000,...) at 0xc0985c07 = > ieee80211_sta_join+0x1f7 > sta_pick_bss(c8996800,c8cac000,c0cc54c4,3bd,246,...) at 0xc0993853 = > sta_pick_bss+0x113 > scan_task(c8996800,1,c0cb27d9,53,c53b9cd8,...) at 0xc099102b = scan_task+0x4bb > taskqueue_run(c894e880,c894e898,0,c0ccee5e,0,...) at 0xc08d09d3 = > taskqueue_run+0xc3 > taskqueue_thread_loop(c896e074,c53b9d28,c0ca8b19,343,c0e04de0,...) at > 0xc08d119e = taskqueue_thread_loop+0x6e > fork_exit(c08d1130,c896e074,c53b9d28) at 0xc0867348 = fork_exit+0xb8 > fork_trampoline() at 0xc0bc0c14 = fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc53b9d60, ebp = 0 --- > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0962604 > stack pointer = 0x28:0xc53b9bb8 > frame pointer = 0x28:0xc53b9bd8 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (ath0 taskq) > panic: from debugger > cpuid = 0 > KDB: stack backtrace: > Uptime: 35s > Physical memory: 2031 MB > Dumping 94 MB: 79 63 47 31 15 > ... > Loaded symbols for /boot/kernel/tmpfs.ko > #0 doadump () at pcpu.h:231 > 231 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:231 > #1 0xc089166e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xc0891942 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:590 > #3 0xc04d8037 in db_panic (addr=Could not find the frame base for "db_panic". > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xc04d8661 in db_command (last_cmdp=0xc0de6a5c, cmd_table=0x0, dopager=1) > at /usr/src/sys/ddb/db_command.c:445 > #5 0xc04d87ba in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #6 0xc04da6dd in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 > #7 0xc08c407e in kdb_trap (type=12, code=0, tf=0xc53b9b78) > at /usr/src/sys/kern/subr_kdb.c:535 > #8 0xc0bd931f in trap_fatal (frame=0xc53b9b78, eva=0) > at /usr/src/sys/i386/i386/trap.c:936 > #9 0xc0bd9843 in trap (frame=0xc53b9b78) at /usr/src/sys/i386/i386/trap.c:326 > #10 0xc0bc0b9c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #11 0xc0962604 in amrr_node_init (ni=0xc8d3c000) > at /usr/src/sys/net80211/ieee80211_amrr.c:152 > #12 0xc0985c07 in ieee80211_sta_join (vap=0xc8cac000, chan=0xc896e320, > se=0xc7d18d00) at ieee80211_ratectl.h:80 > #13 0xc0993853 in sta_pick_bss (ss=0xc8996800, vap=0xc8cac000) > at /usr/src/sys/net80211/ieee80211_scan_sta.c:1244 > #14 0xc099102b in scan_task (arg=0xc8996800, pending=1) > at /usr/src/sys/net80211/ieee80211_scan.c:986 > #15 0xc08d09d3 in taskqueue_run (queue=0xc894e880, tpp=0xc53b9cd8) > at /usr/src/sys/kern/subr_taskqueue.c:240 > #16 0xc08d119e in taskqueue_thread_loop (arg=0xc896e074) > at /usr/src/sys/kern/subr_taskqueue.c:365 > #17 0xc0867348 in fork_exit (callout=0xc08d1130 , > arg=0xc896e074, frame=0xc53b9d28) at /usr/src/sys/kern/kern_fork.c:843 > #18 0xc0bc0c14 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:273 > > > I see that r211295 is fairly recent, but that there were some > ath(4)-related commits subsequent (r211299; r211303). While I admit > but sketchy knowlegde of the code, I don't see anything glaringly > obvious there. > > I'm certainly willing to test, but I have some
Re: Official request: Please make GNU grep the default
Em 2010.08.14. 17:53, Andrey Chernov escreveu: On Fri, Aug 13, 2010 at 01:43:16AM -0700, Doug Barton wrote: Gabor, I hope at this point it goes without saying that I have a lot of respect I am Nth on this. Although I do a lot of l10n work in the beautefull less bureocracy FreeBSD time and very appreciate what Gabor did, the problem is in other area: BSD grep simple not ready for wide testers circle and needs to be polished further. I talk not about it speed alone but about all its bugs revealed right after import. Let few ethusiast who have spare time for experiments run at at now. What we need is rock stable grep, and changing regex library for speed don't add anything here. From my point of view importing of the latest GNU grep instead would have more benefits. And we need to pend BSD grep with all its can of bugs for a while, until faster regex will be imported (disadvantages must be balanced with somewhat sweet). It is not my final verdict and we'll can return to it after all serious bugs will be eliminated. Right now we'll have f.e. numerous report agaist wrong greeping dirs which are unacceptable for any development system including even non-production one like -current. Yes, I'm sorry for my slow reaction, I got a flu some time ago and that prevented me from fixing the bugs earlier. I have several fixes in my working copy, which are being discussed with my mentor. Probably, today or tomorrow they will be committed. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
Em 2010.08.13. 10:52, Roman Divacky escreveu: what about optimizing BSD grep instead? [... picking one mail from the many that suggest this ...] The problem is that optimization is not that trivial. I think the bottleneck is the regex library because: 1, BSD grep is so simple. There may be optimization opportunities and they may help but not that much. But if someone can check the code and make some suggestions, of course, I'll track those down and try to get more of it. 2, GNU grep uses internal optimizations to get that performance. I think it's a wrong approach because the regex library itself should be optimized instead to keep BSD grep clean and simple and to provide the same efficiency for all utilities that are linked to the regex library. Our libc-regex is definitely need to be replaced at some point in the future but that's a more complex item. See the following references: http://wiki.freebsd.org/BSDgrep http://wiki.freebsd.org/Regex If you can make suggestions to make BSD grep faster without touching the regex library please do it and if we can get a performance that is acceptable, we can reconsider leaving it the default if nobody objects. I'll check Sean's suggestions and make some measures how much does that help. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic: Kernel page fault with ath0_com_lock held, r211295
On Sun, Aug 15, 2010 at 12:07:13AM +0800, Adrian Chadd wrote: > You should be able to revert the ath changes reasonably easy. > > Would you mind doing that and see if that fixes or contributes to the problem? Will do; I'll report back when I have information to report -- probably within 30 minutes. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpl8Bj7IMES7.pgp Description: PGP signature
Re: Official request: Please make GNU grep the default
On Fri, Aug 13, 2010 at 01:43:16AM -0700, Doug Barton wrote: > Gabor, > > I hope at this point it goes without saying that I have a lot of respect I am Nth on this. Although I do a lot of l10n work in the beautefull less bureocracy FreeBSD time and very appreciate what Gabor did, the problem is in other area: BSD grep simple not ready for wide testers circle and needs to be polished further. I talk not about it speed alone but about all its bugs revealed right after import. Let few ethusiast who have spare time for experiments run at at now. What we need is rock stable grep, and changing regex library for speed don't add anything here. From my point of view importing of the latest GNU grep instead would have more benefits. And we need to pend BSD grep with all its can of bugs for a while, until faster regex will be imported (disadvantages must be balanced with somewhat sweet). It is not my final verdict and we'll can return to it after all serious bugs will be eliminated. Right now we'll have f.e. numerous report agaist wrong greeping dirs which are unacceptable for any development system including even non-production one like -current. -- http://ache.pp.ru/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] if_ath updates - ar5416 (macbook pro, etc)
Hi, I've committed a couple more small AR9160 related fixes. Please test if_ath if you're using AR9160 in any mode (hostap, adhoc, station) and provide some feedback. Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On Sat, Aug 14, 2010 at 06:23:55PM +0300, Daniel Braniss wrote: > > On Sat, 14 Aug 2010, Julian H. Stacey wrote: > > > > >> why would you want to lock a file for reading anyways? > > > > > > Does current bsdgrep read lock by default ? > > > If so, it would be better off by default, enabled by an option. > > > 8.0-RELEASE man grep (gnu) does not mention locking. > > > > bsdgrep in -current does lock via the call to fgetc(). That is why I > > suggested using flockfile/getchar_unlocked+/funlockfile instead. Other > > unlocked functions would also be useful, i.e., feof_unlocked(). > > Avoiding fgetc() does not completely solve the speed issue, yet it > > certainly helps. > > > > Just for reference: older bsdgrep used fgetln(). > > let me rephrase the question: > why would you want to lock a file for reading anyways?? > > there is no real benefit that I can see in locking a file for searching > a pattern. On a single file the overhead is irrelevant, but for 'grep -r?' Locked is not a file, but FILE. It is a measure to establish consistency in the stdio structures in the multithreaded environment, and not a file-system level lock of any kind. See the description of the flockfile() in the SUSv4. On the other hand, the overhead of locking in !mt process for FILE in our libc should be unmeasurable. pgp4rUts486ny.pgp Description: PGP signature
Re: Official request: Please make GNU grep the default
> On Sat, 14 Aug 2010, Julian H. Stacey wrote: > > >> why would you want to lock a file for reading anyways? > > > > Does current bsdgrep read lock by default ? > > If so, it would be better off by default, enabled by an option. > > 8.0-RELEASE man grep (gnu) does not mention locking. > > bsdgrep in -current does lock via the call to fgetc(). That is why I > suggested using flockfile/getchar_unlocked+/funlockfile instead. Other > unlocked functions would also be useful, i.e., feof_unlocked(). > Avoiding fgetc() does not completely solve the speed issue, yet it > certainly helps. > > Just for reference: older bsdgrep used fgetln(). let me rephrase the question: why would you want to lock a file for reading anyways?? there is no real benefit that I can see in locking a file for searching a pattern. On a single file the overhead is irrelevant, but for 'grep -r?' cheers, danny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: if_alc trouble
On Sat, 14 Aug 2010, Ian FREISLICH wrote: Pyun YongHyeon wrote: I'm working on it but I was not able to reproduce the issue on my AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132 is the only controller that shows this issue and I vaguely remember a couple of users reported the issue. I'll update PR 148772 if I manage to find some clue. I have the same problem with the alc on my compaq mini. Perhaps it is related to the PHY mismatch. For some reason they coupled a GE PHY with a FE controller. I need to stop my switch advertising 1000M for the laptop to autonegotiate the link speed. Acer Aspire One D250 has the same chip and problem (8.1-stable): alc0: port 0x2000-0x207f mem 0x5500-0x5503 irq 18 at device 0.0 on pci3 alc0: 15872 Tx FIFO, 15360 Rx FIFO alc0: Using 1 MSI message(s). miibus0: on alc0 atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto alc0: Ethernet address: 00:23:5a:80:d8:7a alc0: [FILTER] Forcing it to a fixed speed works: ifconfig_alc0="SYNCDHCP media 100baseTX" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On Sat, 14 Aug 2010, Julian H. Stacey wrote: why would you want to lock a file for reading anyways? Does current bsdgrep read lock by default ? If so, it would be better off by default, enabled by an option. 8.0-RELEASE man grep (gnu) does not mention locking. bsdgrep in -current does lock via the call to fgetc(). That is why I suggested using flockfile/getchar_unlocked+/funlockfile instead. Other unlocked functions would also be useful, i.e., feof_unlocked(). Avoiding fgetc() does not completely solve the speed issue, yet it certainly helps. Just for reference: older bsdgrep used fgetln(). Sean -- s...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On 14-08-2010 4:35, Sam Fourman Jr. wrote: > >> BSD grep > >> Elapsed time: 47 seconds > > > > what about optimizing BSD grep instead? > > I think this is reasonable, leave BSD grep default for a few more weeks, and > work on performance enhancements. I agree that changing the default back > for a RELEASE is probably a good idea, but the exposure to wider testing > while focusing on performance, can't hurt much can it? I agree, keep bsdgrep as default for a while and focus on the performance problems. This is CURRENT after all, and 9.0 isn't anywhere near release yet (afaik). -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: if_alc trouble
Kurt Jaeger wrote: > Hi! > > > Pyun YongHyeon wrote: > > > I'm working on it but I was not able to reproduce the issue on my > > > AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132 > > > is the only controller that shows this issue and I vaguely remember > > > a couple of users reported the issue. > > > I'll update PR 148772 if I manage to find some clue. > > > > I have the same problem with the alc on my compaq mini. Perhaps > > it is related to the PHY mismatch. For some reason they coupled a > > GE PHY with a FE controller. I need to stop my switch advertising > > 1000M for the laptop to autonegotiate the link speed. > > I had it on a 10/100 hub, still observed the problem. I meant that the problem is the wierd PHY/MAC arangement on this chip, not what it's plugged into. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
> why would you want to lock a file for reading anyways? Does current bsdgrep read lock by default ? If so, it would be better off by default, enabled by an option. 8.0-RELEASE man grep (gnu) does not mention locking. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
>> BSD grep >> Elapsed time: 47 seconds > > what about optimizing BSD grep instead? I think this is reasonable, leave BSD grep default for a few more weeks, and work on performance enhancements. I agree that changing the default back for a RELEASE is probably a good idea, but the exposure to wider testing while focusing on performance, can't hurt much can it? -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
> This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > --56599777-398594934-1281714095=:35204 > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Fri, 13 Aug 2010, Gabor Kovesdan wrote: > > > Em 2010.08.13. 10:43, Doug Barton escreveu: > >> My reason is simple, performance. While doing some portmaster work > >> recently I was regression testing some changes I made to the --index* > >> options and noticed that things were dramatically slower than the > >> last time I tested those features. Thinking that I had made a > >> programming mistake I dug into my code, and while the regexps that I > >> was using could be tuned for slightly better performance the problem > >> was not in my code. I then installed textproc/gnugrep to compare, > >> and the differences were very dramatic using a highly pessimized test > >> case (finding a match on the last line of INDEX). The script I used > >> to test is at http://people.freebsd.org/~dougb/grep-time-trial.sh.txt > >> and a typical result was: > >> > >> GNU grep > >> Elapsed time: 2 seconds > >> > >> BSD grep > >> Elapsed time: 47 seconds > >> > > Ok, I'll take care of this soon, and make GNU grep default, again with > > a knob to build BSD grep. I agree with you that we cannot allow such a > > big performance drawback but I my measures only showed significant > > differences for very big searches and I didn't imagine that it could > > add up to such a big diference. I'm sorry for the bad decision I took > > making it default. > > This should trim some time off BSD grep. It removes the lock/unlock for > each fgetc() by locking/unlocking the file once. stdio can be slow. > > You probably want to replace flockfile() with ftrylockfile() if threads > will be involved at some point (threading or making a libgrep that may > be used in a threaded process). why would you want to lock a file for reading anyways? BTW, back in the jurasic age, ATT/Bell had this poster: Reach out and GREP someone! danny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: if_alc trouble
Hi! > Pyun YongHyeon wrote: > > I'm working on it but I was not able to reproduce the issue on my > > AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132 > > is the only controller that shows this issue and I vaguely remember > > a couple of users reported the issue. > > I'll update PR 148772 if I manage to find some clue. > > I have the same problem with the alc on my compaq mini. Perhaps > it is related to the PHY mismatch. For some reason they coupled a > GE PHY with a FE controller. I need to stop my switch advertising > 1000M for the laptop to autonegotiate the link speed. I had it on a 10/100 hub, still observed the problem. -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: if_alc trouble
Pyun YongHyeon wrote: > I'm working on it but I was not able to reproduce the issue on my > AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132 > is the only controller that shows this issue and I vaguely remember > a couple of users reported the issue. > I'll update PR 148772 if I manage to find some clue. I have the same problem with the alc on my compaq mini. Perhaps it is related to the PHY mismatch. For some reason they coupled a GE PHY with a FE controller. I need to stop my switch advertising 1000M for the laptop to autonegotiate the link speed. alc0: port 0xec80-0xecff mem 0xfebc-0xfebf irq 17 at device 0.0 on pci2 alc0: 15872 Tx FIFO, 15360 Rx FIFO alc0: Using 1 MSI message(s). miibus0: on alc0 atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto alc0: Ethernet address: 00:25:b3:7e:b7:2d alc0: [FILTER] Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
