Low Tx-Rx performance with 10Gb NICs
On Friday, 24 May 2013, Axel Fischer wrote: Additionally I noticed the following TCP errors with netstat -s ...: 1186 data packets (1717328 bytes) retransmitted 6847875 window update packets 2319 duplicate acks 25831 out-of-order packets (37403288 bytes) 3733 discarded due to memory problems (drops) 1186 segment rexmits in SACK recovery episodes 1717328 byte rexmits in SACK recovery episodes Looks like your data is flooding your memory buffers, have a look through https://calomel.org/freebsd_network_tuning.html -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Low Tx-Rx performance with 10Gb NICs
On 23 May 2013 19:00, Lino Sanfilippo lsan...@marvell.com wrote: Is there a known issue concerning high traffic on Tx and Rx paths? Are there any system settings I could adjust to get the expected performance? Any hints are very appreciated. check your ierrs and oerrs: netstat -s 1, I've noticed I'm getting ierrs on em chips, but none on fxp chips (connected to the same wire/switch); might be unrelated to yours, but worth a check... -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle)
On 19 January 2012 11:55, Julian H. Stacey j...@berklix.com wrote: Igor Mozolevsky wrote: On 19 January 2012 00:57, Dieter BSD dieter...@engineer.com wrote: Idea 2: Give it status. Set up a web page with PR fixing stats name/handle..total PRs fixed...fixed in last 12 months...average fixed/year Sheldon..150...9072 Leonard..131..11067 Howard...104...2052 Raj...80...8080 You mean something like: http://people.freebsd.org/~edwin/gnats/ ? Wow ! I hope that has a link from somewhere, or appearance in, the main tree. If so, I suggest add a back link. http://www.freebsd.org/support/bugreports.html - View PR Statistics link :-) -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 19 January 2012 16:35, Robert Huff roberth...@rcn.com wrote: Igor Mozolevsky writes: Wouldn't this discourage even more people from helping? Would this not separate people who have a genuine interest in contributing from tinker-monkeys? Did I miss a previous definition of tinker-monkey? Coders who attempt to repair or improve something in a way that lacks a plan, purpose, or enthusiasm, often to no useful effect. First coined by me in this thread :-) Cheers, -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 09:25, Andriy Gapon a...@freebsd.org wrote: on 18/01/2012 02:16 Igor Mozolevsky said the following: Seriously, WTF is the point of having a PR system that allows patches to be submitted??! When I submit a patch I fix *your* code (not yours personally, but you get my gist). Let me pretend that I don't get it. It is as much your code as it is mine if you are a user of FreeBSD. I just happen to have a commit bit at this point in time. Actually that is not true at all, it is in no way my code because there is absolutely nothing I can do to change it (evidently, even if I do submit patches ;-) )---I'm, at best, an involved bystander!.. No other project requires a non-committer to be so ridiculously persistent in order to get a patch through. There are about 5000 open PRs for FreeBSD base system, maybe more. There are only a few dozens of active FreeBSD developers. Maybe less for any given particular point in time (as opposed to a period of time). And dealing with PRs is not always exciting. Need I continue? Is that because there are so many bugs that need fixing or is it because PRs get ignored/become staled? From the preceding discussion it appears to be more of the latter than the former. While I appreciate the excitement in churning out new edge code, pretending that old bugs do not exist will not simply make them go away... In fact, given the large number of PRs (and thus presumably ones containing patches) what are the chances that some devs are trying to reinvent the wheel and write a fix that is already contained within the PR system? Equally, there's probably a large number of PRs that are simply not relevant any more... Throwing toys out of the pram because there's just too much stuff to do is really not the answer I'm afraid... -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 11:08, Andriy Gapon a...@freebsd.org wrote: on 18/01/2012 12:54 Igor Mozolevsky said the following: [snip] There are about 5000 open PRs for FreeBSD base system, maybe more. There are only a few dozens of active FreeBSD developers. Maybe less for any given particular point in time (as opposed to a period of time). And dealing with PRs is not always exciting. Need I continue? Is that because there are so many bugs that need fixing or is it because PRs get ignored/become staled? Sorry for saying the obvious, but it is because the PRs are fixed at slower rate than they are opened. That may be the case, but we are not talking about PRs as a whole, but PRs that already contain fixes... From the preceding discussion it appears to be more of the latter than the former. Impressions can be deceiving. Honestly, do you believe that all committers are willfully ignoring the PRs just to cause pain to the users? Or do you consider a possibility that there is an objective reason why the things are the way they are? I was not suggesting malice on behalf of the developers at all, what I was saying is that there is an *appearance* that developers prefer to write new and funky code in lieu of dealing with PRs. This is evidenced by people saying that one has to persistently nag to get the patch looked at/incorporated. Why should that be the case, when it isn't the case on other F/OSS projects? This might be another social problem is that the PR and the bug busting team do not have enough stick over devs... Throwing toys out of the pram because there's just too much stuff to do is really not the answer I'm afraid... So what's your suggestion? But, please, nothing involving other people spontaneously starting to do what you believe to be the right thing. For starters, what would be much more appreciated is for devs to be much more involved from the start once someone does submit the patch. I appreciate that people a fallible and from time to time are bound to forget that they have a PR with a patch assigned to them, but there's no reason why the PR handling system can't email reminders... The best way of dealing with too much on my plate, from personal experience, is to start tackling things one at a time... :-) -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 13:11, Eitan Adler li...@eitanadler.com wrote: On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: One way to encourage people to fix their code would be to prevent them from committing to -CURRENT once they pass a certain threshold of unattended patches. Of course then, committers will be whinging that they'd be resigning if they can't commit to -CURRENT, but quite frankly, why should anyone have the commit privilege if they can't be bothered to address the bugs, are those people just using the FreeBSD project to boost their CV (with great powers comes great responsibility!)? Wouldn't this discourage even more people from helping? Would this not separate people who have a genuine interest in contributing from tinker-monkeys? -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 17:06, Devin Teske devin.te...@fisglobal.com wrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Julian Elischer Sent: Tuesday, January 17, 2012 10:56 AM To: Mark Felder Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle [snip] Where I used to work (Devin Teske is now there) we used to use the 'stable' branch and rolll our own releases. the criticality of those systems was hard to over-emphasize. In 2005 we worked out we processed 1.5 trillion dollars of transactions on those systems. Got new stats. In 2011 we ran $1.61T USD through FreeBSD. Separately, we ran another $0.05T USD through Linux in the same year. Kinda says something about, doesn't it? Sorry to burst your bubble but this is utterly meaningless statistic. You show nothing but correlation and in no way a causation. Back in the days when the UK banks ran ATMs, c on Windows NT (I have no idea what they are running now) they went through a lot more value than that---means absolutely nothing... -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 17:30, Chris Rees utis...@gmail.com wrote: On 18 Jan 2012 17:12, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: Back in the days when the UK banks ran ATMs, c on Windows NT (I have no idea what they are running now) Well I've not seen any BSOD'd cashpoints around for a while, so I'd like to suggest they may have switched. That, or they found reboot after crash tick box... ;-) -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 18:27, Adam Vande More amvandem...@gmail.com wrote: I've suggested this before without much response, but since this thread seems to be encouraging repetition I'll give it another go. ;) I think a bounty system would be very effective(e.g. micro-donations of recent political campaigns) in getting many of these problems resolved. The main problem with a bounty system is getting people to pay since certain needs/desires lose their urgency over time. To address this, the system needs to be an escrow type setup where money is pooled until project is complete, then payment in full is given. This has a lot of problems in itself: people would just turn around and say that bugs will not get fixed unless they get hard cash for the fix, or FreeBSD might end up in the situation where devs get paid to fix the bugs they introduced, deliberately or innocently, essentially getting paid to fix their own sloppy code, which is not that great either. -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 17:56, Andriy Gapon a...@freebsd.org wrote: on 18/01/2012 19:13 Daniel Eischen said the following: someone who owns a branch... - If you cut release N.0, do not move -current to N+1. Keep -current at N for a while, prohibiting ABI changes, and any other risky changes. If a developer wants to do possibly disruptive work, they can do it from their own repo. I am totally against this. I was thinking about this and I'm with Andriy on this: such solution has no long term potential and will only serve to stagnate the innovation. This has been repeated over and over in this thread, but it's worth another mention, currently, there are effectively four tracks: 7.4, 8.2, 9.0 and -HEAD, which understandably poses a lot of difficulty for in terms of maintenance. Whatever historical reason for that is, I think a lot of people would agree that this needs changing in the near future to have a single -RELEASE branch and a single -HEAD branch, but with the understanding by the devs that just because -RELEASE has been cut, it doesn't mean that everyone, en mass, drops development on that and hops on the -HEAD bandwagon... -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 22:31, Mark Blackman m...@exonetric.com wrote: 10.0 - Nov 2013 I think 10.0 should be released based on feature-readiness and not on some arbitrary date... -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 22:53, Mark Blackman m...@exonetric.com wrote: On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote: On 18 January 2012 22:31, Mark Blackman m...@exonetric.com wrote: 10.0 - Nov 2013 I think 10.0 should be released based on feature-readiness and not on some arbitrary date… You can always redefine the feature-set to meet the date. :) Yes, but there's a difference between releasing because it's the right thing to do now vs releasing because it's about time... -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle)
On 19 January 2012 00:57, Dieter BSD dieter...@engineer.com wrote: Idea 2: Give it status. Set up a web page with PR fixing stats name/handle..total PRs fixed...fixed in last 12 months...average fixed/year Sheldon..150...9072 Leonard..131..11067 Howard...104...2052 Raj...80...8080 You mean something like: http://people.freebsd.org/~edwin/gnats/ ? ;-) -- Igor M :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 13:44, Ivan Voras ivo...@freebsd.org wrote: On 17/01/2012 07:32, Atom Smasher wrote: On Tue, 17 Jan 2012, richo wrote: This would be a different argument if all the devs were paid a salary. == what percentage of linux devs are on salary to develop linux? Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm Actually, you're misrepresenting the facts: according to the headline, 75% of the code came from paid developers, *not* 75% of developers are paid... See the difference?.. -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 14:20, Ivan Voras ivo...@freebsd.org wrote: On 17 January 2012 14:49, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: On 17 January 2012 13:44, Ivan Voras ivo...@freebsd.org wrote: On 17/01/2012 07:32, Atom Smasher wrote: what percentage of linux devs are on salary to develop linux? Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm Actually, you're misrepresenting the facts: according to the headline, 75% of the code came from paid developers, *not* 75% of developers are paid... See the difference?.. Yes, you're correct. Actually, I don't think it's cash that's the problem. I think it is more to do with the lack of common goal: the way that releases are perceived, at least by me, are that a bunch of people play in current then at some point someone decides to take a cut of the current branch and call it a release then work toward making that release passable as stable. To illustrate that, I cannot find anywhere on the .org website what core@ see the desirable features of 10.0 to be, or what the committers are working toward. It seems that the bazaar model of development is at its worst here: everyone is doing their own thing and at some point someone decides to call it a day and make a release, nobody cares for what they have already done, but only what they want to do in the future, non-committer patches go ignored (no, I don't have a reference) which discourages end-user contribution... I'm very happy to be shown wrong here, btw!.. -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 16:48, Freddie Cash fjwc...@gmail.com wrote: On Tue, Jan 17, 2012 at 7:32 AM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: Actually, I don't think it's cash that's the problem. I think it is more to do with the lack of common goal: the way that releases are perceived, at least by me, are that a bunch of people play in current then at some point someone decides to take a cut of the current branch and call it a release then work toward making that release passable as stable. To illustrate that, I cannot find anywhere on the .org website what core@ see the desirable features of 10.0 to be, or what the committers are working toward. That would be because, with the multi-year debacle that 5.0-RELEASE became while they worked on the features list for 5.0 (primarily SMPng), the FreeBSD Project has moved away from features-based releases and to time-based releases (although the exact timelines are not carved in stone). You won't find a list of features for the next release of FreeBSD. You'll just find a list of things that people are working on that may or may not be ready in time for the next release. The development is much closer to Ubuntu (release whatever is ready every 6 months) than to Debian (release everything when it's ready, even if it takes 2, 3, 4+ years to make it ready, while the current release grows stale). And this is the ridiculous bazaar situation that I was criticising. In contrast to Ubuntu, or other distribution on top of Linux, FreeBSD is a whole system. Even Ubuntu and such, take a collection of projects that have been developed with certain measurable goals. Yes, Ubuntu appears to be date-oriented distribution, but the software that Ubuntu incorporate into their releases is feature- and goal- oriented. FreeBSD, it seems, as I have pointed out, have no measurable goals within the project itself other than whatever looks like it has a potential to work on date X is going to be in our release. How can this be even considered to be serious?.. No serious manufacturer/producer says throw things in a mix and we'll stick to whatever passes as passable by date X... -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 15:39, Mark Felder f...@feld.me wrote: FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. I would guess that for folks like VMWare, the choice of their focus is essentially determined by their customers and not by them themselves. So if VMWare choose to focus more on Linux over FreeBSD it is simply indicative that VMWare's customers demand Linux support more that the FreeBSD one... Now, why is there more end-user demand for Linux than FreeBSD? I am guessing that is exactly what John K's original post was trying to address... -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 23:01, Adrian Chadd adr...@freebsd.org wrote: If you'd like to see: ... more frequent releases? then please step up and help with all the infrastructure needed to roll out test releases, including building _all_ the ports. A lot of people keep forgetting that a release is build all the ports for all the supported platforms. I don't know this so I'm asking: does fixing a port to work on a pending release involve substantial changes (as in functionality cf. cosmetic) to the core or just patching the port to work with the core? If latter, maybe it's worthwhile uncoupling the two (core OS and ports)? -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 00:00, Andriy Gapon a...@freebsd.org wrote: Just a note: the next best thing you can to _not_ have a patch committed is to just open a PR and stop at that. The best thing being not sharing the patch at all :-) [snip] Some things that help: - send a problem description and a patch (or a short description and a link to a PR) to a relevant mailing list - maintain a discussion of the patch if it arises - try to be interesting and keep the interested folks hooked - find some folks who recently committed stuff in the area of the patch and contact them directly - don't just wait for too long, remind about yourself and the patch, try different mailing lists/people - never give up - stay technical, never get bitter or overly emotional - don't refuse when offered a commit bit :-) Seriously, WTF is the point of having a PR system that allows patches to be submitted??! When I submit a patch I fix *your* code (not yours personally, but you get my gist). No other project requires a non-committer to be so ridiculously persistent in order to get a patch through. Such system is plainly wrong---it simply discourages people from sending this works for me(TM) fixes. The committers have to realise three things: they can and do write broken code now and then, most people who write patches to help the fBSD along don't have the time to become full time committers (otherwise they'd already be, right?), and there's only so many times one is willing to bang their head against a wall with no results---as Einstein pointed out Insanity: doing the same thing over and over again and expecting different results... I'm not saying that responding to reasonable requests from people who are in the process of testing and committing the patch, but expecting the end-users to chase committers to have a fix included is plainly wrong!.. -- Igor M. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 18 January 2012 01:11, Eitan Adler li...@eitanadler.com wrote: It takes time to review and test patches. There are a lot of people that think it only takes 30 seconds to download the patch, apply, and commit. This is just not true. I fully understand that and it is not what I was saying, what I was saying was about the patches that were being plainly ignored/allowed to go stale. What you said below is perfectly reasonable once a committer is actively involved in dealing with a patch, then I, and anyone else for that matter, would be very reasonably expected to be involved in the process and understands that someone else is working on the issue you've address. The problem, however, lies in the time between a patch is submitted and is picked up, if the latter ever occurs!.. That is where the discouragement occurs. [snip] And this assumes the patch was perfect, there really was a bug, and everyone thinks things through properly. The process take anywhere from half an hour for obvious fixes to multiple days in addition to the committer's work, school, and family obligations.. I hope I've address what you say here just above :-) and wholeheartedly agree with everything else you've said, but you are addressing the problem from a different angle: nobody is ever going to disagree that _once_ someone has picked up a patch it will take them time to get it through whatever steps necessary. But, as I said above, it's getting to *this* stage that is the lengthy and a disheartening process... [snip] If you have ideas to make this process easier or more efficient we are all eager to hear them. I am especially interested to know what *I* could do to help speed things along in areas I don't know well enough to commit to. The problem, which I suspect is very difficult to overcome in what I call the bazaar environment, is the enforcement. One way to encourage people to fix their code would be to prevent them from committing to -CURRENT once they pass a certain threshold of unattended patches. Of course then, committers will be whinging that they'd be resigning if they can't commit to -CURRENT, but quite frankly, why should anyone have the commit privilege if they can't be bothered to address the bugs, are those people just using the FreeBSD project to boost their CV (with great powers comes great responsibility!)? -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 02:25, richo ri...@psych0tik.net wrote: On 17/01/12 02:21 +, Igor Mozolevsky wrote: On 17 January 2012 01:02, richo ri...@psych0tik.net wrote: This would be a different argument if all the devs were paid a salary. Isn't this a bit of a cyclical argument: developers don't work because they are not paid a salary, the end-user base shrinks, BigCo doesn't want to pay for someone to put extra work in getting fBSD to do something that it can get elsewhere (eg Linux), fewer still developers work on fBSD, end-user base shrinks, BigCo is even more reluctant, even fewer Potentially, but it doesn't invalidate it, imo. I'm very aware that the code I produce for $WORK is very different to code I write in my own time. Code for $WORK is wrapped in test cases, clean, neat and well documented. code I write in my own time tends to be hackish, incomplete totally undocumented and ludicrously easy to break because I'm intrigued by implementing a single interesting figure that has my attention, or to see whether or not a concept is technically feasible. This is a shortcoming of mine that I should work to overcome, but I feel that the same thing would likely extend to other developers, though in most cases to a lesser degree. Without some other motivation most people naturally gravitate towards newer cool features, rather than doing the relatively boring maintenence and backporting. Are you not making a case for long and thin release cycle vs short and fat then? It's absolutely fine to have a branch (let's call that development) that is cool-and-funky and breaks in 70% of the cases so long as there is another branch (let's call it release) that is not-so-cool-and-funky, but only breaks in 1% of the cases, but is well documented, tested, c and have the developer satisfaction of not only having implemented something cool, but knowing that once that cool is stable enough, that feature is used in environments where stability and dependability matters? A cool feature that nobody can rely on is, quite frankly, junk; is it not? To be realistic, I think any serious developer should expect to spend 70% of their development time on maintenance, for a simple reason that if the software is not maintained to the standard that end-users find usable, they will simply switch, and the user-base to test your latest cool-and-funky gets smaller and smaller... Of course, one way to avoid the 70% being spent on maintenance is to write flawless software, but good luck with that! ;-) This goes back to one of the points that John K. made: who is the system for, the developers or the end users? A system for the latter will quite happily give enough playground for the former, but a system for the former, will never work for the latter. Which, I suppose, is why your $WORK demands a certain quality of code---one way or another their livelihood depends on it!.. -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 January 2012 01:02, richo ri...@psych0tik.net wrote: This would be a different argument if all the devs were paid a salary. Isn't this a bit of a cyclical argument: developers don't work because they are not paid a salary, the end-user base shrinks, BigCo doesn't want to pay for someone to put extra work in getting fBSD to do something that it can get elsewhere (eg Linux), fewer still developers work on fBSD, end-user base shrinks, BigCo is even more reluctant, even fewer -- Igor M. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysbench / fileio - Linux vs. FreeBSD
/usr/src : zfs with compression enabled /usr/src : 386.3MB/s Do I understand it well? It seems that zfs with compression enabled on /usr/src with 8KB block size and 16 threads performs 386.3MB/s which is about 6 times better than debian5? I am thinking about this image http://tech-blog.wooh.hu/~wooh/debian_vs_freebsd_io_16_seqwr.png Yes - on one run it even hit 500MB/s. I suspect, however, that the benchmark isn't accurate because it won't be writing typical data. Instead it's probably using a buffer that compresses very well. Hm.. My ZFS tests showed me the same results. With compression it's pretty fast. That's hardly a surprise - you take the source code, compress it into virtual non-existence leaving hardly anything to be written to the disk... Obviously if compression speed IO speed and the result of the compression is a significant reduction in size, you have a massive gain in writing that data to the disk. -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysbench / fileio - Linux vs. FreeBSD
On 5 June 2010 00:58, Adam PAPAI w...@wooh.hu wrote: How can I tune my disk to make it faster? Is it possible? What is the reason of the really slow I/O with more than 4 threads? What do you recommend me to do? Why is it damn slow with 8K blocksize? Does linux still have async disk writes by default? Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
GSoC 2010
Hello, Robert Watson I have considered your remarks to my proposal. Now I have some problems with GSoC site so I've decided to post my comment here. About choosing the best method for current hardware: I think that the best way to realise it is to use small userspace shared memory region where kernel can to load additional syscall stub during initialization. It may looks like this: write() stub: ... sub $0x0C, %esp movl $_fd, (%esp) movl $_buf, 0x4(%esp) movl $_len, 0x8(%esp) movl $4, %eax call shared stub address add $0x0C, %esp ... Depending on output of CPUID command during the initialization kernel will load certain shared stub. For newer processors it may be: shared stub: sysenter ret About my testing plans: I think it will be simple multi-threaded program that will call syscalls in the loop and measure them execution time with time-stamp counter (RDTSC). If all is fulfilled correctly regression should not to arise. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Spin down HDD after disk sync or before power off
2010/1/27 Oliver Fromme o...@lurza.secnetix.de: Second, you should make sure that ATA_STANDBY_IMMEDIATE is only used when a poweroff is requested, but not in other cases. Of course, ATA_FLUSHCACHE should *always* be sent. Would SLEEP not be a better option than STANBY IMMEDIATE, as SLEEP actually turns the disk's interface off so the disk cannot be woken up by any command other than RESET? Cheers, -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Spin down HDD after disk sync or before power off
2010/1/26 Alexander Best alexbes...@wwu.de: attached you'll find a very simple patch which issues ATA_STANDBY_IMMEDIATE instead of ATA_FLUSHCACHE during hdd spin down. Hold on, does STANDBY IMMEDIATE not abort the previous command within some short timeframe? What if there are pending writes? Cheers, -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Spin down HDD after disk sync or before power off
2010/1/27 Igor Mozolevsky i...@hybrid-lab.co.uk: Hold on, does STANDBY IMMEDIATE not abort the previous command within some short timeframe? What if there are pending writes? Nope, ignore me... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
newfs -r 2
I have found that newfs in 8-STABLE has -r switch with zero default value. I think it should be 1 or 2 by default: as I understand, these sectors are not used usually by filesystem anyway since they are not in last cylinder group. Therefore noone would see the difference in usable space, but this reservation will allow to add gjournal to the filesystem later. BTW, could anyone tell how to learn the last sector that filesystem may really use ? -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fcntl(F_RDAHEAD)
On Mon, Sep 21, 2009 at 02:29:09PM +0300, Kostik Belousov wrote: On Mon, Sep 21, 2009 at 03:12:45PM +0400, Igor Sysoev wrote: What I dislike about the patch is the new kernel-private flag that is eaten from the open(2) flags namespace. We do already have FHASLOCK, so far the only such flag. We can change intf_seqcount; to u_int f_seqcount; and can use highest bit instead of O_READAHEAD: anyway f_seqcount is shifted to 16 bits left. Or do the same trick as was done for FHASLOCK and override some flag that is not saved after open, see FMASK. Or split f_seqcount into two u_short fields, one for f_seqcount, second for f_kflag, and use the later for FHASLOCK and FREADAHEAD. [We are trying to not grow struct file unless absolutely neccessary]. I agree that struct file should not grow (at least in this case). However, I believe splitting f_seqcount into two fields will break kernel ABI. Or not ? I think f_seqcount should be splitted in 9-CURRENT and probably, in 8-STABLE, but in 7-STABLE we may use the open(2) flags namespace. -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fcntl(F_RDAHEAD)
On Tue, Sep 22, 2009 at 11:53:46AM +0300, Kostik Belousov wrote: On Tue, Sep 22, 2009 at 11:28:48AM +0400, Igor Sysoev wrote: On Mon, Sep 21, 2009 at 02:29:09PM +0300, Kostik Belousov wrote: On Mon, Sep 21, 2009 at 03:12:45PM +0400, Igor Sysoev wrote: What I dislike about the patch is the new kernel-private flag that is eaten from the open(2) flags namespace. We do already have FHASLOCK, so far the only such flag. We can change intf_seqcount; to u_int f_seqcount; and can use highest bit instead of O_READAHEAD: anyway f_seqcount is shifted to 16 bits left. Or do the same trick as was done for FHASLOCK and override some flag that is not saved after open, see FMASK. Or split f_seqcount into two u_short fields, one for f_seqcount, second for f_kflag, and use the later for FHASLOCK and FREADAHEAD. [We are trying to not grow struct file unless absolutely neccessary]. I agree that struct file should not grow (at least in this case). However, I believe splitting f_seqcount into two fields will break kernel ABI. Or not ? I think f_seqcount should be splitted in 9-CURRENT and probably, in 8-STABLE, but in 7-STABLE we may use the open(2) flags namespace. The struct file indeed participates in the KBI, in particular, pointer to it is supplied as an argument to VOP_OPEN() and d_fdopen(). On the other hand, it is assumed that drivers and fses use it to override f_ops and possibly f_data. f_seqcount status is internal VFS field that probably should be not accessed or modified by driver or fs. Reason to try hard to keep layout of struct file intact even between major branches is the userspace compatibility, with the code of lsof and fstat. Might be, fstat will be improved to not require this. Probably, best temporal solution would be to override some flag used only for open(2), postponing the task of separating bit- and name-spaces for other day. Also, it makes merge to 8 and 7 easier. Well, I think O_CREAT or O_TRUNC are good candidate to be an alias for O_READAHEAD. -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fcntl(F_RDAHEAD)
On Mon, Sep 21, 2009 at 02:29:09PM +0300, Kostik Belousov wrote: What I dislike about the patch is the new kernel-private flag that is eaten from the open(2) flags namespace. We do already have FHASLOCK, so far the only such flag. We can change intf_seqcount; to u_int f_seqcount; and can use highest bit instead of O_READAHEAD: anyway f_seqcount is shifted to 16 bits left. Or do the same trick as was done for FHASLOCK and override some flag that is not saved after open, see FMASK. Probably, you meant FPOSIXSHM, but not FHASLOCK: /* * We are out of bits in f_flag (which is a short). However, * the flag bits not set in FMASK are only meaningful in the * initial open syscall. Those bits can thus be given a * different meaning for fcntl(2). */ #if __BSD_VISIBLE /* * Set by shm_open(3) to get automatic MAP_ASYNC behavior * for POSIX shared memory objects (which are otherwise * implemented as plain files). */ #define FPOSIXSHM O_NOFOLLOW #endif -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fcntl(F_RDAHEAD)
On Fri, Sep 18, 2009 at 10:40:27AM +0300, Kostik Belousov wrote:
On Thu, Sep 17, 2009 at 03:26:41PM -0700, Xin LI wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, Igor,
Igor Sysoev wrote:
Hi,
nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISKIO
flag. When sendfile() returns EBUSY, nginx calls aio_read() to read single
byte. The first aio_read() preloads the first 128K part of a file in VM
cache,
however, all successive aio_read()s preload just 16K parts of the file.
This makes non-blocking sendfile() usage ineffective for files larger
than 128K.
I've created a small patch for Darwin compatible F_RDAHEAD fcntl:
fcntl(fd, F_RDAHEAD, preload_size)
There is small incompatibilty: Darwin's fcntl allows just to
enable/disable
read ahead, while the proposed patch allows to set exact preload size.
Currently the preload size affects vn_read() code path only and does not
affect on sendfile() code path. However, it can be easy extended on
sendfile() part too. The preload size is still limited by sysctl
vfs.read_max.
The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE
only.
I have ported this as a patch against -HEAD (should apply on 8.0-R but
it's too late for us to add a new feature) plus a manual page entry
documenting the feature.
I've used F_READAHEAD as the name, but reading the manual page, it looks
like we can just use F_RDAHEAD since Darwin seems to just distinguish 0
and !=0 case so that programmers won't have to use #ifdef or something
else to get code working on different platform?
What I dislike about the patch is the new kernel-private flag that is
eaten from the open(2) flags namespace. We do already have FHASLOCK,
so far the only such flag.
The new patch version against 7.2 is attached. Changes:
1) two fcntl's: F_READAHEAD and Darwin compatible F_RDAHEAD,
2) FREADAHEAD uses O_CREAT bit.
--
Igor Sysoev
http://sysoev.ru/en/
--- /sys/sys/fcntl.h2009-06-02 19:05:17.0 +0400
+++ /sys/sys/fcntl.h2009-09-22 16:28:52.0 +0400
@@ -132,7 +132,7 @@
/* bits to save after open */
#defineFMASK
(FREAD|FWRITE|FAPPEND|FASYNC|FFSYNC|FNONBLOCK|O_DIRECT)
/* bits settable by fcntl(F_SETFL, ...) */
-#defineFCNTLFLAGS
(FAPPEND|FASYNC|FFSYNC|FNONBLOCK|FPOSIXSHM|O_DIRECT)
+#defineFCNTLFLAGS
(FAPPEND|FASYNC|FFSYNC|FNONBLOCK|FPOSIXSHM|FRDAHEAD|O_DIRECT)
#endif
/*
@@ -163,6 +163,9 @@
* implemented as plain files).
*/
#defineFPOSIXSHM O_NOFOLLOW
+
+/* Read ahead */
+#define FRDAHEAD O_CREAT
#endif
/*
@@ -187,6 +190,8 @@
#defineF_SETLK 12 /* set record locking
information */
#defineF_SETLKW13 /* F_SETLK; wait if blocked */
#defineF_SETLK_REMOTE 14 /* debugging support for remote
locks */
+#defineF_READAHEAD 15 /* read ahead */
+#defineF_RDAHEAD 16 /* Darwin compatible read ahead
*/
/* file descriptor flags (F_GETFD, F_SETFD) */
#defineFD_CLOEXEC 1 /* close-on-exec flag */
--- /sys/kern/vfs_vnops.c 2009-06-02 19:05:00.0 +0400
+++ /sys/kern/vfs_vnops.c 2009-09-22 14:08:03.0 +0400
@@ -305,6 +305,9 @@
sequential_heuristic(struct uio *uio, struct file *fp)
{
+ if (fp-f_flag FRDAHEAD)
+ return(fp-f_seqcount IO_SEQSHIFT);
+
if ((uio-uio_offset == 0 fp-f_seqcount 0) ||
uio-uio_offset == fp-f_nextoff) {
/*
--- /sys/kern/kern_descrip.c2009-08-28 18:50:11.0 +0400
+++ /sys/kern/kern_descrip.c2009-09-22 14:17:47.0 +0400
@@ -411,6 +411,7 @@
u_int newmin;
int error, flg, tmp;
int vfslocked;
+ uint64_t bsize;
vfslocked = 0;
error = 0;
@@ -694,6 +695,35 @@
vfslocked = 0;
fdrop(fp, td);
break;
+
+ case F_RDAHEAD:
+ arg = arg ? 128 * 1024: 0;
+ /* FALLTHROUGH F_READAHEAD */
+
+ case F_READAHEAD:
+ FILEDESC_SLOCK(fdp);
+ if ((fp = fdtofp(fd, fdp)) == NULL) {
+ FILEDESC_SUNLOCK(fdp);
+ error = EBADF;
+ break;
+ }
+ if (fp-f_type != DTYPE_VNODE) {
+ FILEDESC_SUNLOCK(fdp);
+ error = EBADF;
+ break;
+ }
+ FILE_LOCK(fp);
+ if (arg) {
+ bsize = fp-f_vnode-v_mount-mnt_stat.f_iosize;
+ fp-f_seqcount = (arg + bsize - 1) / bsize;
+ fp-f_flag |= FRDAHEAD;
+ } else {
+ fp-f_flag = ~FRDAHEAD;
+ }
+ FILE_UNLOCK(fp
Re: fcntl(F_RDAHEAD)
On Fri, Sep 18, 2009 at 10:40:27AM +0300, Kostik Belousov wrote: On Thu, Sep 17, 2009 at 03:26:41PM -0700, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Igor, Igor Sysoev wrote: Hi, nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISKIO flag. When sendfile() returns EBUSY, nginx calls aio_read() to read single byte. The first aio_read() preloads the first 128K part of a file in VM cache, however, all successive aio_read()s preload just 16K parts of the file. This makes non-blocking sendfile() usage ineffective for files larger than 128K. I've created a small patch for Darwin compatible F_RDAHEAD fcntl: fcntl(fd, F_RDAHEAD, preload_size) There is small incompatibilty: Darwin's fcntl allows just to enable/disable read ahead, while the proposed patch allows to set exact preload size. Currently the preload size affects vn_read() code path only and does not affect on sendfile() code path. However, it can be easy extended on sendfile() part too. The preload size is still limited by sysctl vfs.read_max. The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE only. I have ported this as a patch against -HEAD (should apply on 8.0-R but it's too late for us to add a new feature) plus a manual page entry documenting the feature. I've used F_READAHEAD as the name, but reading the manual page, it looks like we can just use F_RDAHEAD since Darwin seems to just distinguish 0 and !=0 case so that programmers won't have to use #ifdef or something else to get code working on different platform? What I dislike about the patch is the new kernel-private flag that is eaten from the open(2) flags namespace. We do already have FHASLOCK, so far the only such flag. We can change intf_seqcount; to u_int f_seqcount; and can use highest bit instead of O_READAHEAD: anyway f_seqcount is shifted to 16 bits left. -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
fcntl(F_RDAHEAD)
Hi,
nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISKIO
flag. When sendfile() returns EBUSY, nginx calls aio_read() to read single
byte. The first aio_read() preloads the first 128K part of a file in VM cache,
however, all successive aio_read()s preload just 16K parts of the file.
This makes non-blocking sendfile() usage ineffective for files larger
than 128K.
I've created a small patch for Darwin compatible F_RDAHEAD fcntl:
fcntl(fd, F_RDAHEAD, preload_size)
There is small incompatibilty: Darwin's fcntl allows just to enable/disable
read ahead, while the proposed patch allows to set exact preload size.
Currently the preload size affects vn_read() code path only and does not
affect on sendfile() code path. However, it can be easy extended on
sendfile() part too. The preload size is still limited by sysctl vfs.read_max.
The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE only.
--
Igor Sysoev
http://sysoev.ru/en/
--- sys/sys/fcntl.h 2009-06-02 19:05:17.0 +0400
+++ sys/sys/fcntl.h 2009-09-12 20:29:34.0 +0400
@@ -118,6 +118,10 @@
#if __BSD_VISIBLE
/* Attempt to bypass buffer cache */
#define O_DIRECT 0x0001
+#ifdef _KERNEL
+/* Read ahead */
+#define O_RDAHEAD 0x0002
+#endif
#endif
/*
@@ -187,6 +191,7 @@
#defineF_SETLK 12 /* set record locking
information */
#defineF_SETLKW13 /* F_SETLK; wait if blocked */
#defineF_SETLK_REMOTE 14 /* debugging support for remote
locks */
+#defineF_RDAHEAD 15 /* read ahead */
/* file descriptor flags (F_GETFD, F_SETFD) */
#defineFD_CLOEXEC 1 /* close-on-exec flag */
--- sys/kern/vfs_vnops.c2009-06-02 19:05:00.0 +0400
+++ sys/kern/vfs_vnops.c2009-09-12 20:24:00.0 +0400
@@ -305,6 +305,9 @@
sequential_heuristic(struct uio *uio, struct file *fp)
{
+ if (fp-f_flag O_RDAHEAD)
+ return(fp-f_seqcount IO_SEQSHIFT);
+
if ((uio-uio_offset == 0 fp-f_seqcount 0) ||
uio-uio_offset == fp-f_nextoff) {
/*
--- sys/kern/kern_descrip.c 2009-08-28 18:50:11.0 +0400
+++ sys/kern/kern_descrip.c 2009-09-12 20:23:36.0 +0400
@@ -411,6 +411,7 @@
u_int newmin;
int error, flg, tmp;
int vfslocked;
+ uint64_t bsize;
vfslocked = 0;
error = 0;
@@ -694,6 +695,31 @@
vfslocked = 0;
fdrop(fp, td);
break;
+
+ case F_RDAHEAD:
+ FILEDESC_SLOCK(fdp);
+ if ((fp = fdtofp(fd, fdp)) == NULL) {
+ FILEDESC_SUNLOCK(fdp);
+ error = EBADF;
+ break;
+ }
+ if (fp-f_type != DTYPE_VNODE) {
+ FILEDESC_SUNLOCK(fdp);
+ error = EBADF;
+ break;
+ }
+ FILE_LOCK(fp);
+ if (arg) {
+ bsize = fp-f_vnode-v_mount-mnt_stat.f_iosize;
+ fp-f_seqcount = (arg + bsize - 1) / bsize;
+ fp-f_flag |= O_RDAHEAD;
+ } else {
+ fp-f_flag = ~O_RDAHEAD;
+ }
+ FILE_UNLOCK(fp);
+ FILEDESC_SUNLOCK(fdp);
+ break;
+
default:
error = EINVAL;
break;
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fcntl(F_RDAHEAD)
On Thu, Sep 17, 2009 at 03:50:36PM -0700, Alfred Perlstein wrote:
Please do not make the option have the same name but different
semantics.
Strongly suggest adding the Darwin name as a toggle and a FreeBSD
name as a specific size option.
Then it may be:
case F_RDAHEAD:
arg = arg ? 128 * 1024: 0;
/* FALLTHROUGH F_READAHEAD */
case F_READAHEAD:
-Alfred
* Xin LI delp...@delphij.net [090917 15:27] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, Igor,
Igor Sysoev wrote:
Hi,
nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISKIO
flag. When sendfile() returns EBUSY, nginx calls aio_read() to read single
byte. The first aio_read() preloads the first 128K part of a file in VM
cache,
however, all successive aio_read()s preload just 16K parts of the file.
This makes non-blocking sendfile() usage ineffective for files larger
than 128K.
I've created a small patch for Darwin compatible F_RDAHEAD fcntl:
fcntl(fd, F_RDAHEAD, preload_size)
There is small incompatibilty: Darwin's fcntl allows just to
enable/disable
read ahead, while the proposed patch allows to set exact preload size.
Currently the preload size affects vn_read() code path only and does not
affect on sendfile() code path. However, it can be easy extended on
sendfile() part too. The preload size is still limited by sysctl
vfs.read_max.
The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE
only.
I have ported this as a patch against -HEAD (should apply on 8.0-R but
it's too late for us to add a new feature) plus a manual page entry
documenting the feature.
I've used F_READAHEAD as the name, but reading the manual page, it looks
like we can just use F_RDAHEAD since Darwin seems to just distinguish 0
and !=0 case so that programmers won't have to use #ifdef or something
else to get code working on different platform?
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (FreeBSD)
iEYEARECAAYFAkqyt40ACgkQi+vbBBjt66AdKgCfXOo/Vn+zw0cCjS+gGJUgPo8t
WToAmgKIXaVKsKUcqVOqTwHl4eTFsbkM
=uP3m
-END PGP SIGNATURE-
Index: lib/libc/sys/fcntl.2
===
--- lib/libc/sys/fcntl.2(revision 197297)
+++ lib/libc/sys/fcntl.2(working copy)
@@ -28,7 +28,7 @@
.\ @(#)fcntl.28.2 (Berkeley) 1/12/94
.\ $FreeBSD$
.\
-.Dd March 8, 2008
+.Dd September 19, 2009
.Dt FCNTL 2
.Os
.Sh NAME
@@ -241,6 +241,14 @@
.Dv SA_RESTART
(see
.Xr sigaction 2 ) .
+.It Dv F_READAHEAD
+Set or clear the read ahead amount for sequential access to the third
+argument,
+.Fa arg ,
+which is rounded up to the nearest block size.
+A zero value in
+.Fa arg
+turns off read ahead.
.El
.Pp
When a shared lock has been set on a segment of a file,
Index: sys/kern/kern_descrip.c
===
--- sys/kern/kern_descrip.c (revision 197297)
+++ sys/kern/kern_descrip.c (working copy)
@@ -421,6 +421,7 @@
struct vnode *vp;
int error, flg, tmp;
int vfslocked;
+ uint64_t bsize;
vfslocked = 0;
error = 0;
@@ -686,6 +687,31 @@
vfslocked = 0;
fdrop(fp, td);
break;
+
+ case F_READAHEAD:
+ FILEDESC_SLOCK(fdp);
+ if ((fp = fdtofp(fd, fdp)) == NULL) {
+ FILEDESC_SUNLOCK(fdp);
+ error = EBADF;
+ break;
+ }
+ if (fp-f_type != DTYPE_VNODE) {
+ FILEDESC_SUNLOCK(fdp);
+ error = EBADF;
+ break;
+ }
+ fhold(fp);
+ FILEDESC_SUNLOCK(fdp);
+ if (arg) {
+ bsize = fp-f_vnode-v_mount-mnt_stat.f_iosize;
+ fp-f_seqcount = (arg + bsize - 1) / bsize;
+ fp-f_flag |= O_READAHEAD;
+ } else {
+ fp-f_flag = ~O_READAHEAD;
+ }
+ fdrop(fp, td);
+ break;
+
default:
error = EINVAL;
break;
Index: sys/kern/vfs_vnops.c
===
--- sys/kern/vfs_vnops.c(revision 197297)
+++ sys/kern/vfs_vnops.c(working copy)
@@ -312,6 +312,9 @@
sequential_heuristic(struct uio *uio, struct file *fp)
{
+ if (fp-f_flag O_READAHEAD)
+ return (fp-f_seqcount IO_SEQSHIFT);
+
/*
* Offset 0 is handled specially. open() sets f_seqcount to 1 so
* that the first I/O is normally considered to be slightly
Index: sys/sys/fcntl.h
Re: llvm/clang a tool chain or just a compiler for FreeBSD?
2009/7/22 Kostik Belousov kostik...@gmail.com: I believe that the nearest action that is quite reasonable and profitable by its own merit is divorcing base compiler and compiler used to build ports. Even if this means that we would only have different versions of gcc. On a similar note, has anyone one tried clang + yasm? Cheers, -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: c question: *printf'ing arrays
2009/7/4 Giorgos Keramidas keram...@ceid.upatras.gr: [snip] s/0x%/%#.2hh/g -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: c question: *printf'ing arrays
2009/6/30 Alexander Best alexbes...@math.uni-muenster.de: that works, but i really want to have a pretty output to stdout. i guess i have to stick with printf and use `for (i=0; i sizeof(XXX); i++)` for each array in the struct. just thought i could avoid it. btw. `./my-program | hexdump` works, but if i do `./my-program output` output is being created, but is empty. is this normal? Depends if you output to stdout or stderr --- `' redirects stdout. Cheers, -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: c question: *printf'ing arrays
2009/6/30 Alexander Best alexbes...@math.uni-muenster.de: thanks. but that simply dumps the contents of the struct to stdout. but since most of the struct's contents aren't ascii the output isn't really of much use. How about ./your-program | hexdump ? -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: c question: *printf'ing arrays
2009/6/30 Alexander Best alexbes...@math.uni-muenster.de:
should be stdout.
struct Header *hdr = rom;
int new_fd = open(/dev/stdout, O_RDWR);
printf(SIZE: %d\n,sizeof(*hdr));
write(new_fd, hdr, sizeof(*hdr));
close(new_fd);
You should really be checking what open returns, opening /dev/stdout
for reading is a bit weird not sure if that would work, and most
likely it's already open... Just use fileno(...):-
#include unistd.h
#include stdio.h
int main(void) {
write(fileno(stdout), Hello world!\n, 13);
return 0;
}
Cheers,
--
Igor
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Wi-Fi support - which iface works better?
Hi world, I'm up to build a little Wi-Fi network at my home. So I need to know, what Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: ZyXEL G-302 EE D-link DWA-510 ASUS WL-138g V2 TRENDnet TEW-423PI P.S. Digging the 7.1 Hardware Notes on the Web gave me no information about that cards. Please note me if they are supported at all. WBR, Igor Krasnoselski ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: open(2) and O_NOATIME
2008/10/31 Jeremy Chadwick [EMAIL PROTECTED]: ... If that's what you were referring to, then possibly making O_NOATIME only to root would be a suitable compromise. And no systems are compromised with rootkits?.. Igor :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
lock test from sh script
Hi all! I need to check if file is locked or not (with flock) from a shell script. I remember there was something but cannot recall what exactly. And if possible I do not want to write my own test utility even it is several lines in length) Thanks, -ip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
2008/9/30 Oliver Fromme [EMAIL PROTECTED]: Bill Moran wrote: In response to Oliver Fromme [EMAIL PROTECTED]: Pierre Riteau wrote: Because the 3-way handshake ensures that the source address is not being spoofed, more aggressive action can be taken based on these limits. s/not being spoofed/more difficult to spoofe/ ;-) On a modern OS (like FreeBSD) where ISNs are random, the possibility of blindly spoofing an IP during a 3-way handshake is so low as to be effectively impossible. It depends a lot on the environment, for example whether the attacker has access (or can somehow get access) to the server's uplink and trace packets. This can happen if the server is located with many other servers on the same network, which is often the case for co-location or so-called root servers. Yes, but in that situation you probably have the capacity to inject enough traffic into the pipe to cause a total blackout... Of course, if the network is regarded secure, then you are right. Spoofing a TCP handshake would be very difficult in that case. (I try to avoid the word impossible. Nothing is impossible, especially in the security business.) Security is always about the balance between the effort+risk to you vs the effort+benefit to the attacker... -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible bug (amd64/i386)
2008/9/6 Jeroen Ruigrok van der Werven [EMAIL PROTECTED]: -On [20080906 20:41], Alexander Sizov ([EMAIL PROTECTED]) wrote: Sep 5 00:34:38 test kernel: seScyonncdisn)g fdoirs kssy,s tvenmo dperso creesmsa i`nsiynngc.e.r.' to3 stop...0 0 done On my AMD64 box (using 32 bit FreeBSD due to the Nvidia drivers) my 7-STABLE is also showing this garbled text from time to time. I get that too on various SMP boxes. -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
opendir()/closedir()
Looking at opendir()/readdir()/closedir() sequence via ktrace, I've seen supposedly useless lseek() syscall just before close(). It's called from closedir(): _seekdir(dirp, dirp-dd_rewind);/* free seekdir storage */ It seems that free()ing libc seekdir storage should be done without calling lseek(). Other strange place for me is stat() before open() in opendir() /* * stat() before _open() because opening of special files may be * harmful. _fstat() after open because the file may have changed. */ What is the case when opening special file may be harmful ? -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: opendir()/closedir()
On Fri, Sep 05, 2008 at 10:48:45PM +0300, Kostik Belousov wrote: On Fri, Sep 05, 2008 at 10:40:32PM +0400, Igor Sysoev wrote: Looking at opendir()/readdir()/closedir() sequence via ktrace, I've seen supposedly useless lseek() syscall just before close(). It's called from closedir(): _seekdir(dirp, dirp-dd_rewind);/* free seekdir storage */ It seems that free()ing libc seekdir storage should be done without calling lseek(). Other strange place for me is stat() before open() in opendir() /* * stat() before _open() because opening of special files may be * harmful. _fstat() after open because the file may have changed. */ What is the case when opening special file may be harmful ? For instance, tape may be rewinded. The whole opendir/seekdir/telldir probably should be synced with OpenBSD version, at least due to SINGLEUSE. I made this conclusion when I merged the OpenBSD fix for seekdir several months ago. But I also decided then that I am not a volunteer. BTW, OpenBSD does not worry about tapes :), they use open()/fstat() from the very start. And closedir() does not lseek() since OpenBSD 4.0. -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years
2008/7/3 Doug Barton [EMAIL PROTECTED]: 1. It should be library-based and therefore be capable of supporting at least a few different UIs (see above). 2. At least one of those UIs should be functional over a standard serial console. 3. It should be scriptable. I was thinking of doing it, but nobody provided any constructive ideas and a lot of other installers started popping up, like the bsdinstaller et al, so I wasn't gonna waste any time on that front, and instead just ended up with a massive script that 'works for me'(TM) which does funky things like geom and ccache/distcc world build of the system it's installing onto. I had the first req. up and kind of expanded it into pretty cool stuff that essentially allowed the whole of system to be managed by providing custom plugins, but the monolithic world makes things a lot difficult to make the installer fancy. I'll happily revive the project if it's not going to be a total waste of time (read: others will be interested in contributing ideas and testing it). Cheers, Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
do not work nested unnamed anchor
Hello.
For example:
pf.conf
ext_if=xl0
ip_world=nn.nn.nn.nn
# Filter rules
block log all
anchor in on $ext_if {
pass quick proto tcp to $ip_world port 22 keep state
# SSH
pass quick proto tcp to $ip_world port 25 keep state
# SMTP
pass quick proto tcp to $ip_world port 110 keep state
# POP3
anchor {
pass quick proto tcp to $ip_world port 995 keep state
# POP3S
}
}
nmap results:
PORTSTATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.5p1 (FreeBSD 20061110; protocol 2.0)
25/tcp open smtp?
110/tcp open pop3Openwall popa3d
I can not understand what the problem...
FreeBSD-7.0-RELEASE-p1
i386
--
Igor A. Valcov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
do not work nested unnamed anchor
Hello.
For example:
pf.conf
ext_if=xl0
ip_world=nn.nn.nn.nn
# Filter rules
block log all
anchor in on $ext_if {
pass quick proto tcp to $ip_world port 22 keep state
# SSH
pass quick proto tcp to $ip_world port 25 keep state
# SMTP
pass quick proto tcp to $ip_world port 110 keep state
# POP3
anchor {
pass quick proto tcp to $ip_world port 995 keep state
# POP3S
}
}
nmap results:
PORTSTATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.5p1 (FreeBSD 20061110; protocol 2.0)
25/tcp open smtp?
110/tcp open pop3Openwall popa3d
I can not understand what the problem...
FreeBSD-7.0-RELEASE-p1
i386
--
Igor A. Valcov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[6]: vkernel GSoC, some questions
Matt, We use VMWare Server at work. It does not have the same nice image management interface and/or video capture as commercial counterparts. However, it is is free and testing on it helps us out big time. We never concluded whether it maked sense to pay for VMWare licenses, instead of using free shell scripts legally available for free. I have used UML for development in the past. I even used bochs once to debug a boot loader. All nice tools. Beats real hardware for me. Xen and KVM are significantly slower than commercial products due to hardware switching. There is a GPLed product that works about as fast as VMWare's BT - VirtualBox by innotek. Sun recently scooped them up. Don't you use something like VMWare for development and debugging? In production, we don't use any of these products - too slow and too much RAM would be required. Sincerely, Igor Shmukler, http://www.elusiva.com -Original Message- From: Matthew Dillon [EMAIL PROTECTED] To: Igor Shmukler [EMAIL PROTECTED] Date: Mon, 17 Mar 2008 14:58:25 -0700 (PDT) Subject: Re: Re[4]: vkernel GSoC, some questions : :Matt, : :You sure won't argue that UML isolation is inherently better than one that can be provided by a hypervisor. If the performance is the same, what are you gaining? : :Hypervisor while slow, allows treating a complete OS with all applications as a black box. Why would I choose UML over a hypervisor? : :I am not trying to say there cannot be a place for vkernel. [I don't even yet understand what is does or how.] However, as a hosting company, why would I choose UML over a hypervisor? : :... : :igor Well, whos hypervisor are you using? -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Summer of Code 2008 Project Ideas
On 17/03/2008, Murray Stokely [EMAIL PROTECTED] wrote: The FreeBSD Project was again accepted as a mentoring organization for the Google Summer of Code. The student application period will begin next week so if you have any ideas for great student projects, please send them to [EMAIL PROTECTED] or post them here for discussion. [snip] How about tick()-less kernel - replace dependance on regular hearbeat with a delta-queue that could be used to program the time of the next scheduled interrupt? You could start with the delta-queue pretending to be a regular heart beat then work on changing deltas between events... I'm sure there was a mention of something similar in Linux... Cheers, Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: vkernel GSoC, some questions
What's vkernel's or modern UML multithreaded performance compared to native? I have not been reading hackers in a long time and have no idea what's going on... Please excuse my butting in... Given the fact that there are not as many developers as needed, what would be a practical purpose of vkernel? UML is typically used to debug drivers and/or for hosting. Now that Linux about to have or already has container technology, hosting on UML makes little sense. KVM and other hypervisors are valuable testing tools and can sometimes make sense in a hosting environment. If someone was to work on an open source hypervisor, perhaps they should consider Innotek's product. KVM and Xen use VT extensions to run guests in a protected mode. It's a little slow. Innotek has a fast binary translator. The big questions is whether there is a practical reason to run FreeBSD as a host, or this more about the Freedom of choice? I couple of years ago, we implemented a fairly complete container functionality in FreeBSD 5.x. It even supported live-migration of virtual environments. I showed it A. Perlstein while he was working in New York. We tried to see if anyone was interested at the time, but we have found none. -Original Message- From: Robert Watson [EMAIL PROTECTED] To: Andrey V. Elsukov [EMAIL PROTECTED] Date: Sun, 16 Mar 2008 12:56:21 + (GMT) Subject: Re: vkernel GSoC, some questions On Sun, 16 Mar 2008, Andrey V. Elsukov wrote: 16.03.08, 09:30, David O'Brien [EMAIL PROTECTED]: Add virtual kernel (vkernel) support to FreeBSD for the i386 and amd64 architectures. The vkernel support in question is the one found in DragonFlyBSD. Not being up on DragonFlyBSD, can you better describe what vkernel is? vkernel is similar to User Mode Linux technology. You can boot vkernel as a user mode process. I think it will be good to have similar in FreeBSD. There are several links: http://leaf.dragonflybsd.org/mailarchive/users/2007-01/msg00237.html http://www.dragonflybsd.org/docs/articles/vkernel/vkernel.shtml Another avenue to consider is the Linux KVM virtualization technology, which is seeing a high level of interest in the Linux community and sounds increasingly mature and well-exercised. It would also offer interesting migration benefits for Linux users wanting to try FreeBSD, allowing them to trivially create new FreeBSD installs under their existing Linux install. We had an SoC project last year but I'm not sure what the outcome was; it would be useful to give Fabio a ping and see how things are going. Obviously, anyone doing this project would need to manage the license issues involved carefully. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] [EMAIL PROTECTED]: Новый Bugatti ndash; самый дорогой авто Женевы http://r.mail.ru/cln3686/auto.mail.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[4]: vkernel GSoC, some questions
Matt, You sure won't argue that UML isolation is inherently better than one that can be provided by a hypervisor. If the performance is the same, what are you gaining? Hypervisor while slow, allows treating a complete OS with all applications as a black box. Why would I choose UML over a hypervisor? I am not trying to say there cannot be a place for vkernel. [I don't even yet understand what is does or how.] However, as a hosting company, why would I choose UML over a hypervisor? I can provide a number of reasons to pick a hypervisor: 1. use the same platform to host Unix, Windows and other guests 2. load balance all available hardware [based on some policy] 3. better implies that a hypervisor upgrade is less likely to damage guests I am sure people hosting on hypervisors could write a longer list. Containers [including jail] provide significantly lower overhead[, but more difficult to maintain]. At least it can be argued [probably both ways] that containers are cheaper. Are there real world people hosting with UML today who could comment on this, perhaps supporting Matt's position? igor -Original Message- From: Matthew Dillon [EMAIL PROTECTED] To: Igor Shmukler [EMAIL PROTECTED] Date: Sun, 16 Mar 2008 17:12:00 -0700 (PDT) Subject: Re: Re[2]: vkernel GSoC, some questions : :Given the fact that there are not as many developers as needed, what would be a practical purpose of vkernel? : :UML is typically used to debug drivers and/or for hosting. Now that Linux about to have or already has container technology, hosting on UML makes little sense. The single largest benefit UML or a hardware emulated environment has over a jail is that it is virtually impossible to crash the real kernel no matter what you are doing within the virtualized environment. I don't know any ISP that is able to keep a user-accessible (shell prompt) machine up consistently outside of a UML environment. The only reason machines don't crash more is that they tend to run a subset of available applications in a subset of possible load and resource related circumstances. Neither jails no containers nor any other native-kernel technology will EVER solve that problem. For that matter, no native-kernel technology will ever come close to providing the same level of compartmentalization from a security standpoint, and particularly not if you intend to run general purposes applications in that environment. The reason UML is used, particularly for web hosting, is because web developers require numerous non-trivial backend tools to be installed each of which has the potential to hog resources, crash the machine, create security holes, or otherwise create hell for everyone else. The hell needs to be restricted and narrowed as much as possible so human resources can focus on the cause rather then on the collateral damage. For any compute-intensive business, collateral damage is the #1 IT issue, the cost of power is the #2 issue, and network resources are the #3 issue. Things like cpu and machines... those are in the noise. They're basically free. With a virtual kernel like UML (or our vkernel), the worse that happens is that the vkernel itself crashes and reboots in 5 seconds (+ fsck time for that particular user). No other vkernel is effected, no other customer is effected, no other compartmentalized resource is effected. Jails are great, no question about it, and there are numerous applications which require the performance benefits that running in a jail verses an emulated environment provides, but we will never, EVER see jails replace UML. This is particularly true considering the resource being put into improving emulated environments. The overhead for running an emulated environment ten years from now is probably going to be a fraction of the overhead it is now, as hardware catches up to desire. -Matt [EMAIL PROTECTED]: Новый Bugatti ndash; самый дорогой авто Женевы http://r.mail.ru/cln3686/auto.mail.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security Flaw in Popular Disk Encryption Technologies
On 24/02/2008, Bill Moran [EMAIL PROTECTED] wrote: Igor Mozolevsky [EMAIL PROTECTED] wrote: [snip] IMO the possibility of such attack is so remote that it doesn't really warrant any special attention, it's just something that should be kept in mind when writing secure crypto stuff... Then you're not using this to protect data of a particular sensitive nature, or you're being a fool. Not at all! Fact is, data is sensitive to different degrees. It's also valuable to different degrees. If you're worried about your personal financial information on your laptop being stolen, then modern disk encryption is fine. But, if you've got a mobile device with the sensitive information from 1000s of people on it, the stakes are different. That device is liable to be the target of an attack specifically to get the _data_. You're correct in 90% of the cases, but there's still the 10% that some of us need to consider. Crypto is merely a way of obfuscating data, and we all know the truth about security by obscurity, right? Why would you have sensitive data on a laptop that anyone could potentially snatch out of your hand??? If it's sensitive enough to be paranoid, it should never leave the site! There are better ways to protect data than simple disk encryption, *if you really have to* to take it offsite on a laptop. There's only one thing disk crypto is useful for - swap encryption, I'd not use straight crypto for anything else... But again, how many of us here actually use S/Key for remote logins?.. The fact is that the attack is not difficult, and it's not a matter of whether or not someone _can_ bypass your disk encryption, it's more a matter of whether or not they actually care enough to bother, or whether the $$$ they can get for the stolen hardware alone will satisfy them. Each user/organization really needs to evaluate this information with regards to their own situation, but it's important to understand the details of the risk when making such a decision. It's not a not difficult attack - someone has to get hold of your laptop first! Then there's things like BIOS passwords, restricting boot partitions, and if you don't want memory covers to be unscrewed (or your laptop case as a whole, for that matter) you can always use a bit of loctite! As the saying goes, those who think that crypto is the solution to their problem, don't crypto nor the problem... Igor :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security Flaw in Popular Disk Encryption Technologies
On 25/02/2008, Bill Moran [EMAIL PROTECTED] wrote: In response to Igor Mozolevsky [EMAIL PROTECTED]: Crypto is merely a way of obfuscating data, and we all know the truth about security by obscurity, right? I don't think you correctly understand the concept of security through obscurity ... as crypto is _not_ an example of that. You have way too much faith in crypto - any crypto system can be broken given enough time + computing power + determinism... You can't break a system when half the data that you need is missing (see * later). Why would you have sensitive data on a laptop that anyone could potentially snatch out of your hand??? If it's sensitive enough to be paranoid, it should never leave the site! That's like saying, Why would you ever drive a car on the freeway when you know how many people are killed in auto accidents every day. The answer is, because you must. That's a ridiculous analogy! Such as when?.. There are better ways to protect data than simple disk encryption, *if you really have to* to take it offsite on a laptop. Name 3. 1) Store the data on a USB stick, or other portable medium which you can detach from the laptop*; or 2) Use crypto system that requires a physical token to decrypt the data (which can be detached from the laptop in transit); and I don't have time to think of a third one ATM... There's only one thing disk crypto is useful for - swap encryption, I'd not use straight crypto for anything else... Again, I find you opinions odd, and possibly misinformed. How could it be misinformed - you've just said that HD crypto is easy to compromise using the aforementioned method, clearly it's not good enough to encrypt sensitive data?.. But again, how many of us here actually use S/Key for remote logins?.. S/Key isn't the magical solution to all security. I know, I was merely using it as an example of security solution being 'out there' and hardly anyone using it... Then there's things like BIOS passwords, How does a BIOS password protect RAM from being removed? Password protecting BIOS prevents the attacker from manipulating permissible boot partitions... restricting boot partitions, and if you don't want memory covers to be unscrewed (or your laptop case as a whole, for that matter) you can always use a bit of loctite! Sure, the old superglue in the USB port trick. I'm sure HW manufacturers love it when they see that ... warranty out the door! But in this case, if the attacker is after the data, breaking the RAM door to get it open isn't a very big deal, now is it? Once the computer is off you only need to delay the extraction of RAM sufficiently for the attack to be ineffective... And as for the warranty, you have a choice, you either make the system secure and compromise the warranty, or you make the system comply with warranty TC and compromise the security... As the saying goes, those who think that crypto is the solution to their problem, don't crypto nor the problem... Not sure I understand what you mean by that, but your flippant dismissal of strong cryptography is not justified by any facts I've ever seen. The issue is not how strong crypto is, but how people use it - if one relies on the fact that their highly sensitive national secrets are safe just because they've encrypted the hard drive the data is on, and haven't taken any other precautions then you can easily see how a simple attack like that would screw them over, and quite frankly they would deserve it!.. Crypto is not a replacement for common sense! Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security Flaw in Popular Disk Encryption Technologies
On 24/02/2008, Bill Moran [EMAIL PROTECTED] wrote: Igor Mozolevsky [EMAIL PROTECTED] wrote: On 23/02/2008, Brooks Davis [EMAIL PROTECTED] wrote: You should actually read the paper. :) They successfully defeat both of these type of protections by using canned air to chill the ram and transplanting it into another machine. Easy to get around this attack - store the key on a usb stick/cd/whatever and every time the OS needs to access the encrypted date the key should be read, data decrypted, then key wiped from the memory; or have the daemon erase the key from memory every T minutes and re-acquire the key at next access attempt... This is only effective if the sensitive data is infrequently accessed. If the unit is asleep, then software isn't running and it's not possible to kick of a timer to clear the memory, so it doesn't even start to solve that problem. IMO the possibility of such attack is so remote that it doesn't really warrant any special attention, it's just something that should be kept in mind when writing secure crypto stuff... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security Flaw in Popular Disk Encryption Technologies
On 23/02/2008, Brooks Davis [EMAIL PROTECTED] wrote: You should actually read the paper. :) They successfully defeat both of these type of protections by using canned air to chill the ram and transplanting it into another machine. Easy to get around this attack - store the key on a usb stick/cd/whatever and every time the OS needs to access the encrypted date the key should be read, data decrypted, then key wiped from the memory; or have the daemon erase the key from memory every T minutes and re-acquire the key at next access attempt... Or you could carry something that emits a huge EMI pulse to destroy the data on the disk... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pthreads memoty leak?
Hi
The startup of this program causes memory leak, doesn't it? What's the
reason?
Tested on FreeBSD-6.1 and 5.4 with the same effect.
On Linux work fine.
#include stdio.h
#include unistd.h
#include pthread.h
void* mythread(void* arg)
{
return NULL;
}
void threaded()
{
#define size 1
int ret, i;
for (i = 0; i size; i++) {
pthread_t t_id;
pthread_attr_t pthread_attr;
pthread_attr_init (pthread_attr);
pthread_attr_setdetachstate (pthread_attr,
PTHREAD_CREATE_DETACHED);
ret = pthread_create (t_id, pthread_attr, mythread, NULL);
pthread_attr_destroy (pthread_attr);
if (ret)
printf (pthread_create() returned error value %d\n, ret);
}
}
int main()
{
int i;
for (i = 0; i 1000; i++) {
if (i % 1000 == 0)
printf (main() iteration: %d\n, i);
threaded();
}
printf (FINISHED.\n);
sleep (3600);
return 0;
}
==
--
Igor A. Valcov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
pthreads memoty leak?
Hi
The startup of this program causes memory leak, doesn't it? What's the
reason?
Tested on FreeBSD-6.1 and 5.4 with the same effect.
On Linux work fine.
#include stdio.h
#include unistd.h
#include pthread.h
void* mythread(void* arg)
{
return NULL;
}
void threaded()
{
#define size 1
int ret, i;
for (i = 0; i size; i++) {
pthread_t t_id;
pthread_attr_t pthread_attr;
pthread_attr_init (pthread_attr);
pthread_attr_setdetachstate (pthread_attr,
PTHREAD_CREATE_DETACHED);
ret = pthread_create (t_id, pthread_attr, mythread, NULL);
pthread_attr_destroy (pthread_attr);
if (ret)
printf (pthread_create() returned error value %d\n, ret);
}
}
int main()
{
int i;
for (i = 0; i 1000; i++) {
if (i % 1000 == 0)
printf (main() iteration: %d\n, i);
threaded();
}
printf (FINISHED.\n);
sleep (3600);
return 0;
}
==
--
Igor A. Valcov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User mounting take 2
On Sat, Apr 15, 2006 at 01:05:45AM -0400, Joe Marcus Clarke wrote: Based on feedback I received on my initial diff, I took another crack at user mounting. To address Robert's concerns, I drop the setuid permissions until needed. Therefore, all permission checks are now done in the kernel. The same is true for umount(8). silby asked for wildcard support. To handle that, I added glob support to both the fs_file and fs_spec fstab components (via fnmatch(3)), and also added a special %u pattern that can be used to represent the current user (i.e. the user running mount(8)). This effectively allows the following in /etc/fstab: //[EMAIL PROTECTED]/homes/home/%u/smb_homesmbfsrw,noauto,user 0 0 Then, a user could just run, for example: mount /home/marcus/smb_home And their SMB home directory would get mounted (~/.nsmbrc is also respected). Additionally, something like the following is also possible: /dev/acd0/home/*/cdromcd9660 ro,noauto,user0 0 Same mount command works here: mount /home/marcus/cdrom Wildcards can also be mixed and matched. Finally, in testing this, I found a problem with smbfs, msdosfs, and ntfs relating to the statfs(2) f_flags field. smbfs always set this to 0, msdosfs didn't set this at all, and ntfs set this to all flags (not just those visible to statfs(2)). By fixing this, umount(8) works properly on relative paths to user mount points for those three file systems. http://www.marcuscom.com/downloads/usermount.diff Comments? Great feature! Hopefully it will hit the tree soon enough. Thanks! -ip -- A free agent is anything but. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqueue/kevent and directories (Was: Equivalent of POLLERR for kqueue.)
On Tue, 13 Dec 2005, John-Mark Gurney wrote: Vaclav Haisman wrote this message on Wed, Dec 14, 2005 at 01:12 +0100: On Tue, 13 Dec 2005, Vaclav Haisman wrote: Is there equivalent of POLLERR for kqueue()? Or is EV_EOF the only thing? I would like to use kqueue/kevent for sockets but error condition signaling is not clear to me from manpage. It's up to the driver, but I don't believe that kqueue normally delivers errors back to the process... it returns as ready, but needs to be checked manually via a call to the proper syscall... (at least for sockets).. Sorry for the late response, but kqueue delivers error code to process in fflags (at least for sockets), so application does not need to call unnecessary syscall to learn error code. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mmap() sendfile()
On Mon, 12 Dec 2005, Mike Silbersack wrote: On Mon, 12 Dec 2005, Cedric Tabary wrote: If it is true, doing a sendfile() on some very big files (even if not keeping the descriptor open after) will kill the cache ? Please help me to understand why this patch ? and the difference between sendfile() and mmap() at the memory or cache level.. C?dric My memory escapes me on all the details, but there were two potential reasons not to use sendfile with 4.x that no longer apply in 5.x and above: 1. Sendfile used to send small files inefficiently, sending the http headers in one packet and the data in another. I fixed this in 5.x. There is workaround, it's used in my server nginx: setting the TCP_NOPUSH socket option. By the way, I've backported the patch to 4.x: http://sysoev.ru/freebsd/patch.uio.txt http://sysoev.ru/freebsd/patch.sendfile_header.txt 2. Alan Cox improved the memory efficiency of sendfile greatly, it now uses a single kernel buffer for all copies of the same block of the same file, whereas the old implementation made an in-kernel copy of each block, making it no more memory efficient than using mbufs. sendfile() in 4.x is more memory efficient than mbufs because sfbufs use KVA only while mbuf clusters use both KVA and physical memory. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] pppd: added auto DNS configuration
Hello,
I've implemented DNS automatic negotiation and configuration in
pppd (RFC1877). Since it is not a standard thing, I made it an
optional feature of pppd. Some parts of the code were taken from ppp
implementation. I would be greatful for testing of this patch and
for any comments and suggestion.
Thanks,
-ip
--
If your condition seems to be getting better, it's
probably your doctor getting sick.
Index: pppd/Makefile
===
RCS file: /home/ncvs/src/usr.sbin/pppd/Makefile,v
retrieving revision 1.19.2.3
diff -u -r1.19.2.3 Makefile
--- pppd/Makefile 13 Dec 2004 13:50:02 - 1.19.2.3
+++ pppd/Makefile 25 Dec 2005 17:25:55 -
@@ -38,6 +38,9 @@
DPADD+=${LIBCRYPTO}
.endif
+# DNS automatic configuration support
+CFLAGS+=-DNS_NEGOTIATE -DDNS_CONFIGURE
+
.if defined(RELEASE_CRUNCH)
# We must create these objects because crunchgen will link them,
# and we don't want any unused symbols to spoil the final link.
Index: pppd/cbcp.c
===
RCS file: /home/ncvs/src/usr.sbin/pppd/cbcp.c,v
retrieving revision 1.4.2.2
diff -u -r1.4.2.2 cbcp.c
--- pppd/cbcp.c 11 Dec 2004 11:23:56 - 1.4.2.2
+++ pppd/cbcp.c 25 Dec 2005 14:43:18 -
@@ -26,6 +26,7 @@
#include string.h
#include sys/types.h
#include sys/time.h
+#include netinet/in.h
#include syslog.h
#include pppd.h
Index: pppd/demand.c
===
RCS file: /home/ncvs/src/usr.sbin/pppd/demand.c,v
retrieving revision 1.5
diff -u -r1.5 demand.c
--- pppd/demand.c 28 Aug 1999 01:19:02 - 1.5
+++ pppd/demand.c 25 Dec 2005 14:38:28 -
@@ -28,6 +28,7 @@
#include fcntl.h
#include syslog.h
#include netdb.h
+#include netinet/in.h
#include sys/param.h
#include sys/types.h
#include sys/wait.h
Index: pppd/ipcp.c
===
RCS file: /home/ncvs/src/usr.sbin/pppd/ipcp.c,v
retrieving revision 1.12
diff -u -r1.12 ipcp.c
--- pppd/ipcp.c 28 Aug 1999 01:19:03 - 1.12
+++ pppd/ipcp.c 27 Dec 2005 16:47:00 -
@@ -28,11 +28,15 @@
#include stdio.h
#include string.h
#include syslog.h
+#include fcntl.h
#include netdb.h
#include sys/param.h
+#include sys/stat.h
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
+#include arpa/inet.h
+#include resolv.h
#include pppd.h
#include fsm.h
@@ -49,6 +53,9 @@
static int cis_received[NUM_PPP]; /* # Conf-Reqs received */
static int default_route_set[NUM_PPP]; /* Have set up a default route */
static int proxy_arp_set[NUM_PPP]; /* Have created proxy arp entry */
+#ifdef DNS_CONFIGURE
+static ns_t ns;/* local storage for NS config
*/
+#endif
/*
* Callbacks for fsm code. (CI = Configuration Information)
@@ -154,7 +161,162 @@
return b;
}
+/*
+ * loadDNS - load info from existing resolv.conf
+ * Adopted from ppp.
+ */
+static void
+loadDNS(ns)
+ns_t *ns;
+{
+int fd;
+
+ns-dns[0].s_addr = ns-dns[1].s_addr = INADDR_NONE;
+
+if (ns-resolv != NULL) {
+ free(ns-resolv);
+ ns-resolv = NULL;
+}
+
+if (ns-resolv_nons != NULL) {
+ free(ns-resolv_nons);
+ ns-resolv_nons = NULL;
+}
+
+if ((fd = open(_PATH_RESCONF, O_RDONLY)) != -1) {
+ struct stat st;
+ if (fstat(fd, st) == 0) {
+ ssize_t got;
+
+ if ((ns-resolv_nons = (char *)malloc(st.st_size + 1)) == NULL)
+ IPCPDEBUG((LOG_ERROR, Failed to malloc %lu for %s: %s\n,
+ (unsigned long)st.st_size, _PATH_RESCONF, strerror(errno)));
+ else if ((ns-resolv = (char *)malloc(st.st_size + 1)) == NULL) {
+ IPCPDEBUG((LOG_ERROR, Failed(2) to malloc %lu for %s: %s\n,
+ (unsigned long)st.st_size, _PATH_RESCONF, strerror(errno)));
+ free(ns-resolv_nons);
+ ns-resolv_nons = NULL;
+ } else if ((got = read(fd, ns-resolv, st.st_size)) != st.st_size) {
+ if (got == -1)
+ IPCPDEBUG((LOG_ERROR, Failed to read %s: %s\n,
+ _PATH_RESCONF, strerror(errno)));
+ else
+ IPCPDEBUG((LOG_ERROR, Failed to read %s, got %lu not %lu\n,
+ _PATH_RESCONF, (unsigned long)got, (unsigned
long)st.st_size));
+ free(ns-resolv_nons);
+ ns-resolv_nons = NULL;
+ free(ns-resolv);
+ ns-resolv = NULL;
+ } else {
+
+#define issep(ch) ((ch) == ' ' || (ch) == '\t')
+#define isip(ch) (((ch) = '0' (ch) = '9') || (ch) == '.')
+
+ char *cp, *cp_nons, *ncp, ch;
+ int n;
+
+ ns-resolv[st.st_size] = '\0';
+
+ cp_nons = ns-resolv_nons;
+ cp = ns-resolv;
+ n = 0;
+
+ while ((ncp = strstr(cp, nameserver)) != NULL) {
+ if (ncp != cp) {
+
pppd and DNS
Hi, Looking through pppd sources I found that it doesn't know how to request DNS info from the server, while ppp can. Here I mean requesting DNS info and updating /etc/resolv.conf. Did anyone tried to make it possible with pppd? Since I used to pppd I'd like to teach him this useful functionality. -ip -- Laugh and the world laughs with you. cry and ... you have to blow your nose. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD VGA Framebuffer
On Wed, Dec 21, 2005 at 09:51:24AM +1300, Dale DuRose wrote: Hi I'm wondering if anyone knows if freebsd has a vga framebuffer? and how to use it? Yes it has. It's sources are in /usr/src/dev/fb and there is no man page (at least on RELENG_4). Not sure it even exist in RELENG_[56]. -ip -- If there are only two shows worth watching, they will be on together. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SB Live 7.1 soundcard trouble
On Tue, Dec 06, 2005 at 09:59:02AM +, Vyacheslav Sotnikov wrote: Hi list. I've got trouble with drivers for my soundcard - they dont detect it. pciconf brings that: [EMAIL PROTECTED]:9:0: class=0x040100 card=0x10061102 chip=0x00071102 rev=0x00 hdr=0x00 vendor = 'Creative Labs' device = 'CA0106-DAT Audigy LS' class= multimedia subclass = audio I has tried standard snd_emu10k1, that shipped with FreeBSD and that is in ports - /usr/ports/audio/emu10kx/ - they both failed. I also try to install OSS from opensound.com and it failed with kernel trap 18 while installation. Before trying to install OSS drivers you should first uninstall FreeBSD ones. And make also sure you downloaded drivers for your version of FreeBSD. If nothing helps you can bug OSS people, they are very responsible. -ip -- Self starters --- won't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Core dump after RELENG_5_4 to RELENG_6_0
Core dump after RELENG_5_4 to RELENG_6_0
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc04d2f92 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc04d3228 in panic (fmt=0xc064717a %s) at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0xc062a698 in trap_fatal (frame=0xc7b97c2c, eva=0) at
/usr/src/sys/i386/i386/trap.c:831
#4 0xc062a403 in trap_pfault (frame=0xc7b97c2c, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:742
#5 0xc062a061 in trap (frame=
{tf_fs = -1058078712, tf_es = -1058078680, tf_ds = -944177112,
tf_edi = -1057380052, tf_esi = 0, tf_ebp = -944145256, tf_isp =
-944145320, tf_ebx = 52, tf_edx = 128, tf_ecx = 13, tf_eax =
-1057380052, tf_trapno = 12, tf_err = 0, tf_eip = -1067284630, tf_cs =
32, tf_eflags = 66050, tf_esp = 0, tf_ss = -1057381320}) at
/usr/src/sys/i386/i386/trap.c:432
#6 0xc061a14a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc062876a in generic_bcopy () at /usr/src/sys/i386/i386/support.s:489
Previous frame inner to this frame (corrupt stack?)
(kgdb)
#less /var/log/messages
Nov 22 16:40:39 gate syslogd: kernel boot file is /boot/kernel/kernel
Nov 22 16:40:39 gate kernel: Copyright (c) 1992-2005 The FreeBSD Project.
Nov 22 16:40:39 gate kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988,
1989, 1991, 1992, 1993, 1994
Nov 22 16:40:39 gate kernel: The Regents of the University of
California. All rights reserved.
Nov 22 16:40:39 gate kernel: FreeBSD 6.0-RELEASE #0: Tue Nov 22 12:48:05
MSK 2005
Nov 22 16:40:39 gate kernel:
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/iPII350_6_0_1
Nov 22 16:40:39 gate kernel: Timecounter i8254 frequency 1193182 Hz
quality 0
Nov 22 16:40:39 gate kernel: CPU: Pentium II/Pentium II Xeon/Celeron
(350.80-MHz 686-class CPU)
Nov 22 16:40:39 gate kernel: Origin = GenuineIntel Id = 0x652
Stepping = 2
Nov 22 16:40:39 gate kernel:
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
Nov 22 16:40:39 gate kernel: real memory = 134205440 (127 MB)
Nov 22 16:40:39 gate kernel: avail memory = 125984768 (120 MB)
Nov 22 16:40:39 gate kernel: npx0: [FAST]
Nov 22 16:40:39 gate kernel: npx0: math processor on motherboard
Nov 22 16:40:39 gate kernel: npx0: INT 16 interface
Nov 22 16:40:39 gate kernel: acpi0: ASUS P2B on motherboard
Nov 22 16:40:39 gate kernel: acpi0: Power Button (fixed)
Nov 22 16:40:39 gate kernel: pci_link0: ACPI PCI Link LNKA irq 11 on acpi0
Nov 22 16:40:39 gate kernel: pci_link1: ACPI PCI Link LNKB irq 10 on acpi0
Nov 22 16:40:39 gate kernel: pci_link2: ACPI PCI Link LNKC irq 12 on acpi0
Nov 22 16:40:39 gate kernel: pci_link3: ACPI PCI Link LNKD irq 7 on acpi0
Nov 22 16:40:39 gate kernel: Timecounter ACPI-safe frequency 3579545
Hz quality 1000
Nov 22 16:40:39 gate kernel: acpi_timer0: 24-bit timer at 3.579545MHz
port 0xe408-0xe40b on acpi0
Nov 22 16:40:39 gate kernel: cpu0: ACPI CPU on acpi0
Nov 22 16:40:39 gate kernel: acpi_button0: Power Button on acpi0
Nov 22 16:40:39 gate kernel: pcib0: ACPI Host-PCI bridge port
0xcf8-0xcff on acpi0
Nov 22 16:40:39 gate kernel: pci0: ACPI PCI bus on pcib0
Nov 22 16:40:39 gate kernel: agp0: Intel 82443BX (440 BX) host to PCI
bridge mem 0xe400-0xe7ff at device 0.0 on pci0
Nov 22 16:40:39 gate kernel: pcib1: PCI-PCI bridge at device 1.0 on pci0
Nov 22 16:40:39 gate kernel: pci1: PCI bus on pcib1
Nov 22 16:40:39 gate kernel: pci1: display, VGA at device 0.0 (no
driver attached)
Nov 22 16:40:39 gate kernel: isab0: PCI-ISA bridge at device 4.0 on pci0
Nov 22 16:40:39 gate kernel: isa0: ISA bus on isab0
Nov 22 16:40:39 gate kernel: atapci0: Intel PIIX4 UDMA33 controller
port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0
Nov 22 16:40:39 gate kernel: ata0: ATA channel 0 on atapci0
Nov 22 16:40:39 gate kernel: ata1: ATA channel 1 on atapci0
Nov 22 16:40:39 gate kernel: uhci0: Intel 82371AB/EB (PIIX4) USB
controller port 0xd400-0xd41f at device 4.2 on pci0
Nov 22 16:40:39 gate kernel: uhci0: [GIANT-LOCKED]
Nov 22 16:40:39 gate kernel: usb0: Intel 82371AB/EB (PIIX4) USB
controller on uhci0
Nov 22 16:40:39 gate kernel: usb0: USB revision 1.0
Nov 22 16:40:39 gate kernel: uhub0: Intel UHCI root hub, class 9/0, rev
1.00/1.00, addr 1
Nov 22 16:40:39 gate kernel: uhub0: 2 ports with 2 removable, self powered
Nov 22 16:40:39 gate kernel: pci0: bridge at device 4.3 (no driver
attached)
Nov 22 16:40:39 gate kernel: rl0: RealTek 8139 10/100BaseTX port
0xd000-0xd0ff mem 0xdb80-0xdb8000ff irq 7 at device 9.0 on pci0
Nov 22 16:40:39 gate kernel: miibus0: MII bus on rl0
Nov 22 16:40:39 gate kernel: rlphy0: RealTek internal media interface
on miibus0
Nov 22 16:40:39 gate kernel: rlphy0: 10baseT, 10baseT-FDX, 100baseTX,
100baseTX-FDX, auto
Nov 22 16:40:39 gate kernel: rl0: Ethernet address: 00:c0:df:26:7a:25
Nov 22 16:40:39 gate kernel: rl1: RealTek 8139 10/100BaseTX port
0xb800-0xb8ff mem 0xdb00-0xdbff irq 12 at device 10.0 on pci0
Nov 22 16:40:39 gate kernel: miibus1:
Re: Core dump after RELENG_5_4 to RELENG_6_0
Core dump after RELENG_5_4 to RELENG_6_0
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc04d2f92 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc04d3228 in panic (fmt=0xc064717a %s) at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0xc062a698 in trap_fatal (frame=0xc7b97c2c, eva=0) at
/usr/src/sys/i386/i386/trap.c:831
#4 0xc062a403 in trap_pfault (frame=0xc7b97c2c, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:742
#5 0xc062a061 in trap (frame=
{tf_fs = -1058078712, tf_es = -1058078680, tf_ds = -944177112,
tf_edi = -1057380052, tf_esi = 0, tf_ebp = -944145256, tf_isp =
-944145320, tf_ebx = 52, tf_edx = 128, tf_ecx = 13, tf_eax =
-1057380052, tf_trapno = 12, tf_err = 0, tf_eip = -1067284630, tf_cs =
32, tf_eflags = 66050, tf_esp = 0, tf_ss = -1057381320}) at
/usr/src/sys/i386/i386/trap.c:432
#6 0xc061a14a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc062876a in generic_bcopy () at /usr/src/sys/i386/i386/support.s:489
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Did you remember to rebuild all your modules (e.g. any third-party
modules like the nvidia driver)?
Did as in /usr/src/Makefile
[skip]
# 1. `cd /usr/src' (or to the directory containing your source tree).
# 2. `make buildworld'
# 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
# 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
# 5. `reboot'(in single user mode: boot -s from the loader prompt).
# 6. `mergemaster -p'
# 7. `make installworld'
# 8. `mergemaster'
# 9. `reboot'
[skip]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: vn_fullpath() again
You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. Well, I do not think it is a Yes. I very much think it is a No. You should have continued reading my email 'til the middle or even farther. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: vn_fullpath() again
Perhaps, I do not get it or maybe you are do not getting my point. There are times when resolving would not be possible or a name returned is not necessarily the one used when file was first accessed. We have discussed it here and everyone agreed on that. The hardlinks or files unlinked while vnode is still open are corner cases. The unlink is a bit more difficult to deal with, but hardlinks are probably not a big issue. As long as we can get A name, we may not even need to know THE name. I am pleasantly surprised to know that fabric of the universe is not MSDOS. :) Igor Shmukler [EMAIL PROTECTED] writes: Dag-Erling SmЬrgrav [EMAIL PROTECTED] writes: Igor Shmukler [EMAIL PROTECTED] writes: You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. Well, I do not think it is a Yes. I very much think it is a No. You should have continued reading my email 'til the middle or even farther. I did. You just don't get it. A file may be associated with zero, one or more names and none of these names are more correct or authoritative than any of the others. If a user does 'ln /bin/ls /tmp' (assuming /bin and /tmp are on the same filesystem), it may be obvious to you that /bin/ls is the real name is /tmp/ls is just an alias, but it is not obvious to the kernel. In fact, the kernel is unable to see any difference at all between these two names. Storing the name that was used to access a file in the vnode does not solve anything, because the vnode is shared by all users of that file, regardless of which name they used to access it, and there is no guarantee that the name that was used to access a file two seconds ago still references the same file, or any file at all; the file may have been renamed or deleted, or a new filesystem may have been mounted that covers the namespace that file was in. In summary: THERE IS NO WAY TO UNIQUELY AND RELIABLY MAP A VNODE BACK TO A NAME, and I wish people would stop insisting that there must be. All the world is not MS-DOS. DES -- Dag-Erling SmЬrgrav - [EMAIL PROTECTED] Играй, общайся! Скачай новую версию М-Агента http://r.mail.ru/cln2659/agent.mail.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[3]: vn_fullpath() again
Robert, Thank you very much for a detailed reply. I was aware of many of the things you mentioned, but it never hurts to hear something one more time. How do you feel about small incremental improvements to name lookup? What about looking up device name in the structure itself for VCHR nodes then prepending /dev/ and returning device name, as a first step? If incremental improvements sound like a good idea, maybe we could do a few small modifications that would cover some additional cases. Would not it be good? Thank you in advance, Igor -Original Message- From: Robert Watson [EMAIL PROTECTED] To: Igor Shmukler [EMAIL PROTECTED] Date: Tue, 6 Sep 2005 16:21:47 +0100 (BST) Subject: Re[2]: vn_fullpath() again On Tue, 6 Sep 2005, Igor Shmukler wrote: You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? Yes. Get over it. Well, I do not think it is a Yes. I very much think it is a No. You should have continued reading my email 'til the middle or even farther. There are various tricks that can be played to increase the chances of finding a name in the name cache, but those tricks run out quickly on systems like NFS servers where files can be accessed without being looked up since the last boot, or with background fsck. This is a fundamental property of the UNIX file system design, and it while it offers some quite powerful capabilities, nothing changes the fact that names are fundamentally second class systems in the file system and VFS design. The main tricks that can be played are: - Don't purge intermediate but unused nodes from the name cache. A specific design choice in FreeBSD has been to allow cache entries for unused nodes to be removes so that the nodes can be reused. On systems that rapidly consume vnodes, this allows more vnodes to be recycled, so means more memory available. However, it also means that it is less likely to be possible to reconstruct a name from the name cache. - Maintain references to cache entries instead of vnodes when accessing leaf files. This is actually somewhat the approach taken by Linux -- typically the hardest name to identify is the last segment to reach a file, since files can have hard links (and directories typically don't). That name can rapidly be invalidated due to renaming, unlinking, linking, and so on, and hence can be quite stale, but if you assume the name space is static, this will help out with the files don't have parents problem. - With a minor redesign of UFS, eliminating hard links, it is possible to add a directory back-pointer to the parent of a file. In this case, there is an authoritative reference to the parent. Mind you, this comes with many down-sides: Apple attempted to ship a UNIX system without support for hard links, and had to rapidly hack support for it back into the file system. - Maintain a parent back-pointer for files in the vnode, reflecting the last directory used to reach the file, so that you can search that directory to find a possible name. This requires different reference management behavior, prevents directories from falling out of the cache if a file reached via the directory is in use, and will also require walking directories, which can be very expensive. At heart, though, fundamental issues remain: files can have no names, or they can be looked up using a name that is removed, yet still have another name. They can have several names. They can be accessed without any lookup. The same name can refer to several files due to mountpoint covering. Throughout the design, names are assumed to be only fleetingly valid (during the lookup), and of secondary importance after that. Most systems I've looked at try to work around a lack of names in two ways: (1) They treat the name as something valid only at time of lookup. For example, the Solaris audit system captures a name used to look up a node, and after that it is the responsibility of the consumer of the audit trail to identify any name operations that might affect the name of an object in use, if names are important. Typically they have to handle three names during lookup: path to process root, path from process root to cwd, and path from cwd to file. (2) Apple has an underlying file system, HFS+, that actually maintains a fairly strong notion of directory hierarchy, via its catalog, so you can look up parent nodes. They maintain a vnode backpointer from children to parents in VFS, set up during lookup. However, this breaks for several reasons: volfs, which allows access to files by device + inode number, NFS, which allows access to files not by path, and their hacks to re-add hard links using a special directory, which can result
Re[2]: vn_fullpath() again
Robert, You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? As long as vnode is referenced we should be able to perform the lookup for any file system. Linux does a pretty good job with d_path() and I understand Matt changed his NC to provide this. The FreeBSD name cache requires work. It could and IMHO should be improved. If there is a desire to have FreeBSD improved in this area, why doesn't someone look at a solution I submitted for returning devfs names. While a perfect solution would require serious changes to the OS, a solution that would work for referenced vnodes is easier to implement. igor. -Original Message- From: Robert Watson [EMAIL PROTECTED] To: Sergey Uvarov [EMAIL PROTECTED] Date: Mon, 5 Sep 2005 18:00:56 +0100 (BST) Subject: Re: vn_fullpath() again On Mon, 5 Sep 2005, Sergey Uvarov wrote: all knows that vn_fullpath() is unreliable. However I really need to get a filename for a given vnode. To simplify the task, I do not care of synthetic file systems or hardlinks. I have looked through archives in hope to find a better solution. It seems that linux_getcwd() approach could help. However to make that code work for me, I need to know a directory vnode where the file resides. vnode-v_dd field looks promising. But as I understand it did not help if file name is not in a name cache. So the question: is it ever possible to get directory vnode for a given file vnode? One way to look at the problem is from the perspective of how you might derive that information from an on-disk inode. If you look at the UFS layout on-disk, you'll see that there is no pointer to a directory back from a leaf inode; in kernel, you can have a reference to a vnode with no back pointer to a directory vnode. In order to find the parent, you potentially have to iterate through all directories on the hard disk looking for the parent, which is a potentially long-running activity. It's also not at all theoretical: vnodes are often accessed without any path lookup at all. For example, background fsck may pull inodes off disk without a name lookup, and the NFS server can receive file handle references following a reboot from a live client that maintains cached references -- it will service them without performing a lookup. So unfortunately, the answer is complex: (a) you may have to search the disk for a name, and (b) you may not even find one, since there can be files without any name at all (i.e., a temporary file that has been unlinked). On non-UFS style file systems, such as HFS+, it is possible to generate a path from the file system root without extensive disk I/O. However, all common UNIX-like file systems don't have this property -- Sun's version of UFS, ext2fs/ext3fs, and so on. If the child vnode is a directory, you can just follow it's '..' link or covered vnode, of course... Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Project BSDVISION Wants To Develop Native *BSD Console Desktop
On Sun, Aug 21, 2005 at 01:39:20AM -0700, Kamal R. Prasad wrote: It will be running on a virtual console in text or graphics mode like TurboVision used to, but we are focusing on text mode for now. As I just wrote to someone else, the main idea is to enable BSD programs to have a nice console (textual and graphical) interface with and without any windows system. So I could have a standalone program that Thst would be great to have and extend to a full-fledged GUI interface as X is overkill for lots of people. BTW -does it use drivers for graphics accelerator cards? Heh, what are you going to accelerate in text mode? 8-) -ip -- Go where the money is. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: perl's tie problem
On Fri, Aug 12, 2005 at 01:34:51PM -0700, Steve Watt wrote: In article [EMAIL PROTECTED] you write: Hi all, Consider the following except from a perl program: tie(%foodb, 'MLDBM', $BAR_FILE, O_CREAT | O_RDWR, 0666) or die(Cannot open $BAR_FILE: $!\n); I expect it to create a new $BAR_FILE, if none existed, with 0666 permissions. But it doesn't. It creates a file with default umask specified permissions - 0644. So I have to manually do chmod on that file afterwards. Is there anything I don't understand? %uname -a FreeBSD doom.homeunix.org 4.11-STABLE FreeBSD 4.11-STABLE #0: Tue Jul 5 21:05:20 MSD 2005 [...] i386 umask applies after the open call's permissions, and is used to remove bits from the value passed in to the open. That's the way POSIX says it works, and that's how it works on UNIX machines. Down in the guts of the open() syscall, there's a line that effectively says file_permissions = passed_in_permissions ~umask; It's working as designed. Thanks for explanation guys. I guess I'm still thinking windoze. -ip -- If there isn't a law, there will be. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
perl's tie problem
Hi all, Consider the following except from a perl program: tie(%foodb, 'MLDBM', $BAR_FILE, O_CREAT | O_RDWR, 0666) or die(Cannot open $BAR_FILE: $!\n); I expect it to create a new $BAR_FILE, if none existed, with 0666 permissions. But it doesn't. It creates a file with default umask specified permissions - 0644. So I have to manually do chmod on that file afterwards. Is there anything I don't understand? %uname -a FreeBSD doom.homeunix.org 4.11-STABLE FreeBSD 4.11-STABLE #0: Tue Jul 5 21:05:20 MSD 2005 [...] i386 Perl version is 5.8.7 Thanks, -ip -- Ignorance should be painful. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: per file lock list
Matt, Thank you very much for response. This is a general solution, but it not sufficient for our needs. I guess I should have been more clear while explaining what we need. We want list of these locks for a group of processes. We made an implementation based on your suggestion, but there is one problem... Unfortunately this method does not return all shared locks for a range. For example, if several processes have placed a shared lock on a range [1000 - 2000], F_GETLK returns a flock structure where l_pid field contains a pid of process that takes the lock first. While, we want to know all processes that takes this lock. Is there any way to retrieve such information without using of internal kernel structures (inode information)? Thank you in advance, igor On 7/21/05, Matthew Dillon [EMAIL PROTECTED] wrote: :Hi, : :We have a question: how to get all POSIX locks for a given file? :.. : :As far as I know, existing API does not allow to retrieve all file :locks. Therefore, we need to use kernel internal structures to get all :... :So the question: is there an elegant way to get the lock list for a given file? : :Thank you in advance. You can use F_GETLK to iterate through all posix locks held on a file. From man fcntl: F_GETLKGet the first lock that blocks the lock description pointed to by the third argument, arg, taken as a pointer to a struct flock (see above). The information retrieved overwrites the information passed to fcntl() in the flock structure. If no lock is found that would prevent this lock from being created, the structure is left unchanged by this function call except for the lock type which is set to F_UNLCK. So what you do is you specify a lock description that covers the whole file and call F_GETLK. You then use the results to modify the lock description to a range that starts just past the returned lock for the next call. You continue iterating until F_GETLK tells you that there are no more locks. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in portupgrade
On Sun, Jul 31, 2005 at 11:34:49AM +0900, KOMATSU Shinichiro wrote:
Hello.
Olivier Certner wrote:
Le Mardi 12 Juillet 2005 19:39, Florent Thoumie a ?crit :
Le Mardi 12 juillet 2005 ? 12:55 -0400, Kris Kennaway a ?crit :
On Sun, Jul 10, 2005 at 11:13:12PM +0200, Olivier Certner wrote:
Hi,
There is a bug with portupgrade when it is used to upgrade already
compiled and installed ports for which some dependencies have been
deleted in the package database. This causes a crash in the function
'deorigin' in pkgdb.rb.
Since I don't know the internals of portupgrade, I don't know if it's
normal to call 'deorigin' with its argument set to nil. If it is, then
the patch below might be useful (beware, I don't know any ruby, I've
just tried something and it works), if it is not, I only can provide
the stack (see below) in order for maintainers to seek the faulty
callers.
Please talk to the port maintainer.
Yeah, and good luck :)
Otherwise, he can try to pkgdb -F or remove pkgdb.rb and re-run
portupgrade.
This doesn't work in fact. I'm forwarding these mails to the
maintainer.
Sorry for my late reply, but would you try out the following patch?
Index: lib/portsdb.rb
===
--- lib/portsdb.rb (revision 37)
+++ lib/portsdb.rb (revision 38)
@@ -846,7 +846,7 @@
def all_depends_list(origin, before_args = nil, after_args = nil)
if !before_args !after_args i = port(origin)
- i.all_depends.map { |n| origin(n) }
+ i.all_depends.map { |n| origin(n) }.compact
else
all_depends_list!(origin, before_args, after_args)
end
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Thanks!
It works. Does it have a chance to be committed?
-ip
--
Never leave hold of what you've got until you've got hold
of something else.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
per file lock list
Hi, We have a question: how to get all POSIX locks for a given file? As far as I know, existing API does not allow to retrieve all file locks. Therefore, we need to use kernel internal structures to get all applied locks. Unfortunately, a head of list with file locks is attached to inode rather then vnode. As result, it is much harder to get the lock list head due to the need to know exact inode type that is hidden behind the vnode. Of course, the problem could be resolved in a hackish way: we may get the address of VOP_ADVLOCK() method and compare it with all known FS methods, that handles this VOP operation: (ufs_advlock, etc.) and therefore apply a proper type cast to vnode-v_data to get valid inode. However, this would be a last resort. So the question: is there an elegant way to get the lock list for a given file? Thank you in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
no sound in SDL apps
Hi, Some time ago (unfortunatly I cannot say when) all sound had dissapeared from SDL apps. However soundcard itself is fine as xmms via /dev/dsp is working fine. I tried to recompile all sdl related stuff - no difference (even did portupgrade -R sdl). Is there anybody out there who is experiencing the same behaviour? Before digging into this I'd like to know if there is something obvious I'm missing. This is STABLE-4 with the latest SDL. Sound driver is OSS 3.99.1h. P.S. Excuse me if it's not the appropriate list for this. -ip -- Consumer assistance doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in portupgrade
On Wed, Jul 13, 2005 at 12:15:31AM +0200, Olivier Certner wrote: Le Mardi 12 Juillet 2005 19:39, Florent Thoumie a ?crit : Le Mardi 12 juillet 2005 ? 12:55 -0400, Kris Kennaway a ?crit : On Sun, Jul 10, 2005 at 11:13:12PM +0200, Olivier Certner wrote: Hi, There is a bug with portupgrade when it is used to upgrade already compiled and installed ports for which some dependencies have been deleted in the package database. This causes a crash in the function 'deorigin' in pkgdb.rb. Since I don't know the internals of portupgrade, I don't know if it's normal to call 'deorigin' with its argument set to nil. If it is, then the patch below might be useful (beware, I don't know any ruby, I've just tried something and it works), if it is not, I only can provide the stack (see below) in order for maintainers to seek the faulty callers. Please talk to the port maintainer. Yeah, and good luck :) Otherwise, he can try to pkgdb -F or remove pkgdb.rb and re-run portupgrade. This doesn't work in fact. I'm forwarding these mails to the maintainer. Same here. I raised this problem on mailing list some time ago but without luck. -ip -- After things have gone from bad to worse, the cycle will repeat itself. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
debugging with Qemu
Hello, We have tried to use qemu for debugging of kernel-level code the same way we used bochs in past. The qemu whether with or without kqemu is quite fast for our needs. The gdb connects to guest just fine, however breakpoints break things and qemu stops working. Our guest OS is FreeBSD 5.3. We would not need to use qemu if not for the problems 5.3 has with gdb. Any ideas what could we do besides using painfully slow bochs? Thank you in advance, Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
vn_fullpath() and devices
hello,
i reported before that vn_fullpath() does not currently deal with VCHR type of
vnodes.
There is an easy solution for this:
if (vnp-v_type == VCHR) {
fullpath = vnp-v_rdev-si_name;
VOP_UNLOCK(vnp, 0, td);
len = sizeof(/dev/) + strlen(fullpath);
freepath = vdt_malloc(len);
sprintf(freepath, /dev/%s, fullpath);
fullpath = freepath;
} else {
it this works for everyone, i could make and test a patch against whatever
branch is
appropriate.
thank you,
igor
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
name cache cont.
Robert which would generally explain the issues. However, the my.file case is a bit concerning. Could you confirm that the file descriptor in that case is definitely pointed at a vnode? Indeed does not work. It only happens when my.file is a file newly created by the shell. If one forwarded output to an existing file, vn_fullpath() returns name just fine. For my purposes the Linux/DragonFly functionality is needed. Is there a way to know that once a patch that correctly resolves corner cases for vn_fullpath() (including name cache changes) exists it will be committed to the 5.x branch? It appears that these changes would require serious labor changing the name cache. Who would be the right person to even decide that these can/cannot be applied to a stable tree? Igor. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: name cache cont.
Bruce, Thank you for your reply. If you could email me a tarball, I would appreciate it. I don't have that much practical experience with FreeBSD name cache. However, I had some expeirence with other systems. I think the big question here do other developers agree that name cache could use some work. Obviously everything here is IMHO. Solaris has a very straightforward scalable cache. The FreeBSD cache is not bad, but as far as I understand issues I mentioned are a side-effect of design desicions aiming to lower pressure on the cache. I would very much be interested to know what Jeff and everyone else thinks about this. Is there a desire within the people who have hands-on expereience maintaining this part of FreeBSD to change the cache. I need d_path() like functionality for a specific kernel module. Right now, to get away, a secondary cache is implemented by intercepting open(2)/close(2). To minimize the amount of memory this cache needs (and keep to code simple) a dedicated kernel thread gc'es duplicate names from this cache, i.e. if vn_fullpath() works delete name from secondary cache). It's ugly, but it works for now. I would rather FreeBSD takes care of this for us. I am willing to contribute if folks who know VFS well, think it's a worthy cause. Igor. On Mon, Mar 28, 2005 at 05:42:52PM +0400, Igor Shmukler wrote: gt; For my purposes the Linux/DragonFly functionality is needed. gt; gt; Is there a way to know that once a patch that correctly resolves corner cases for gt; vn_fullpath() (including name cache changes) exists it will be committed to the 5.x gt; branch? Hey, I did some of this work quite some time ago. It is still floating around in the archives. I'm more than happy for people with more vfs knowledge than I to pick it up, review it, and commit it, but I don't have free time to do this right now. BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
name cache (was Re[4]: vn_fullpath())
Hi, Sorry for reopening an old thread. I am doing this because last time around I was unaware of some issues. There are more corner cases/issues with vn_fullpath() and possibly the name cache. Please correct me if I am wrong. Perhaps, I would even personally look into fixing these, but I would like to know everyone agrees that this is needed. 1. vn_fullpath() does not return names for VCHR vnodes. I think it would be handy if this was possible. 2. It appears that vn_fullpath() has problems with FD 0..2. [It even seems to happen regardless whether file descriptors were inherited or open via $foo my.file] I am under the impression that Linux d_path() does these things. Is there an agreement that this a problem and it would be benefitial to have vn_fullpath() [and name cache] behave in a proper way? Where does dragonfly stand on this? Thank you, Igor :I seem to recall that DragonFly keeps the intermediate nodes. There's no way to backport that, it would be hundreds of man hours of work. DragonFly uses a totally different namecache topology now, one that is mandatory and which guarentees the existance of intermediate nodes. You'd have to implement something similar to libc's getcwd code. e.g. .. through and scan each directory to find the matching inode if the namecache entry is not present. It actually wouldn't be too hard to do. It wouldn't be efficient, but vn_fullpath() is rarely used so it shouldn't be a problem. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: name cache (was Re[4]: vn_fullpath())
On FreeBSD, this occurs because devfs doesn't use the name cache. Two easy solutions are: - Use the name cache in devfs. This would have to be done carefully in the context of cloning, etc, but should work out. - Add a VOP/VFS operation to help figure out a pathname with the help of the file system, and implement it for devfs. This would avoid having to deal with cache invalidation issues in devfs. I would prefer whatever would be a lowest impact uniform (for different FSs) solution. I will start looking into this issue. I'm not familiar with this issue specifically. Normally these descriptors point to tty's (unnamed due to devfs issues above) and pipes (no name), which would generally explain the issues. However, the my.file case is a bit concerning. Could you confirm that the file descriptor in that case is definitely pointed at a vnode? I will do this. I would like to point out ( guess I was not clear the first time). That even if std[in/out/err] is VREG, not VCHR after child process inhereted this descriptor vn_fullpath() does not work. I understand that this sounds fishy, because fd simply points to vnode, but that the impression for now. If one closes a standard descriptor then opens a file, it does work, but seems not to survive through inheritance. I will follow-up with more information on this. Maybe, files issue for 0..2 is a just a product of imagination :) Linux does something a little different in how they maintain references to I am aware that Linux dentry/inode/cache are different, but I was asking this for a simple (selfish) reason. If there is a concesus that d_path() like functionality [in a black-box way i.e. let's forget how it is implemented] would be very helpful, then I think if a patch was made it might be committed before 5.5 is out. In that case, I would try to work on this and/or even ask my colleagues to help with coding/testing. If this is viewed as an obscure feature that will not be included anytime soon, I would remove from my agenda for now. I thank you Robert and everyone else who spent time reading this thread and thinking about this whole issue. Thank you, Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: relation between PQ_CACHESIZE and PQ_L2_SIZE
http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2003-June/001655.html But what puzzled me is : why not page size is a factor when calculating the number of colors? Page coloring in freebsd was implemented by John Dyson. It is needed to better utilize the cache. Depending on cache's implementation fully-associative vs. 4-way vs 2-way etc you might have problems. A subset of bits (low-bits) from the page frame's (physical) address tells us where can data be stored in processor cache. We want a relatively equal distribution of these colors so that we utilize as much of cache real estate as possible. Hence, we are interested in the size of a set, not size of a page. I am sure, there are whole bunch of articles written about this. I could give you some pointers offline. Igor. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Low level hardware access in FreeBSD
On Sat, Mar 12, 2005 at 06:12:19PM +, Alex Burke wrote: Hi, I am just wondering how I can access either BIOS calls, or preferably registers under FreeBSD? I am trying to write a simple system capable of displaying graphics on the screen, and I am pretty sure I can mmap the VGA memory to my programs address space. You'd better not try inventing the wheel. You can use already written libraries for that purpose - vgl(3) or graphics/svgalib for example. -ip -- If everybody doesn't want it, nobody gets it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamically Linked Library Problem (maybe)
On Mon, Feb 28, 2005 at 11:48:14PM +0200, Cole wrote: Hey. I have a Freebsd server running freebsd-4.9-stable. I cvsupped the ntop src last week for 3.1.1. I then had no problems what so ever building ntop, except for the xml plugin saying it was not built, cause it cannot find xmlversion.h, even though I have libxml installed, and specified the right paths to the .h. But that is not the problem. Ntop runs and works fine on this box, not a single problem that I can see. The problem is that, I have a few other servers, that I want to copy ntop too, but dont want to build it on all those boxes. I created a tar with all the ntop binaries, as well as all the libraries that its linked too, as well as all the plugins that ntop uses from both the /usr/local/lib directory as well as the plugins from the /usr/local/lib/ntop/plugins directory. I rebuilt all the symbolic links for all the libraries and plugins and all the files that ntop was linked too. I have also checked all the permissions on all the files and they are all the same. One other thing, the boxes that I am copying ntop to, are almost exact duplicates of the first box that I built ntop on, and where it works fine. The problem is, when running ntop on the boxes that I copied it to, after checking all the permissions and links and everything, I get these errors with regards to the plugins. Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/icmpPlugin.so' entry function [Invalid shared object handle 0x29a14000] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/snmpPlugin.so' entry function [Invalid shared object handle 0x29a16400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/sflowPlugin.so' entry function [Invalid shared object handle 0x29a19800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/rrdPlugin.so' entry function [Invalid shared object handle 0x29a1bc00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/pdaPlugin.so' entry function [Invalid shared object handle 0x2bcae400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/netflowPlugin.so' entry function [Invalid shared object handle 0x2d862800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/lastSeenPlugin.so' entry function [Invalid shared object handle 0x2d866c00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/xmldumpPlugin.so' entry function [Invalid shared object handle 0x2f697000] I have absolutely no idea how this has happened, and I have had this problem before, and not a single other person was able to help me in any regards what so ever. I was hoping maybe someone would at least know what this error even means, so that I have some idea of what I am meant to be doing to fix this. If anyone has any idea, I would gladly apprecaite any suggestions. It seems to me error messages mean one thing - those plugins were corrupted in some way. It is also not clear from your message - are you using net/ntop from ports tree or you are building it from sources manually? In case of problems when building from a port you'd better ping port maintainer. -ip -- You are never given enough time or money. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: vn_fullpath()
Robert and David, Thank you for your help. It depends a lot on the requirements. There are some nasty edge cases where the process of determining a name for an object can be quite expensive. Here's one of them: ln /usr/local/etc/apache/httpd.conf /usr/local/etc/apache.old/httpd.conf reboot apachectl start rm /usr/local/etc/apache/httpd.conf Now generate the name of the file that Apache has open. Note that you can't just look in the name cache, because the object has a name but the name used to open the object has been invalidated. And UFS even knows it has a name, because the link count remains non-zero when the unlink of one of the names occurs -- but the only way it can find the other name is to search the file system. So the first thing to do is to decied what your requirements are: are you willing to fail in the edge cases like the above? If so, life is a lot easier :-). I guess I am willing to fail :). Perhaps in some distant future, we will look into the nasty corner cases, but for now, as long as I get a name, it will do. We don't even mind the hardlinks so much, but we cannot afford to use existing vn_fullpath() because it does not guarantee anything. Thank you, Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
vn_fullpath()
Hello, I was wondering if anyone has figured a way to make vn_fullpath() reliable? Perhaps there is another approach to attacking this problem. Here is what I need to accomplish: I need to be able to determine dynamic linker, shared libraries or executable name for a specific process. The alternative to vn_fullpath() is intercepting calls, however I need an interpreter name in case of a script. The problem with name cache is: a. name has to be in the cache b. hardlinks cause vnodes with multiple names This must be a common problem so I was curious whether there is a solution. If anyone has any experience making this work, please advise. Thank you, Igor. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Finding variables
On Wed, Feb 16, 2005 at 06:24:08PM +0800, Kathy Quinlan wrote: Hi all, I am using some code from http://home.flash.net/~bobgh/serial.htm It uses variables of ioctl like TCSETS, I have seen it in other FreeBSD source code, but I can not find what I need to include to get it to work . #include termios.h in 5.x 4.x doesn't have this ioctl. -ip -- On a beautiful day like this it's hard to believe anyone can be unhappy -- but we will work on it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Could not find a spill register error on alpha-4
Hi,
One of my ports refuses to build on alpha-4.
Pointyhat gets the following error:
rib.cpp:4130: Could not find a spill register
(insn 4709 4708 4710 (set (reg:DI 15 $15)
(plus:DI (reg:DI 15 $15)
(const_int -131264 [0xfffdff40]))) 9 {adddi3} (nil)
(nil))
cpp0: output pipe has been closed
*** Error code 1
Googling and grepping through gcc sources doesn't provide me with any solution,
only a feeling that I'm not the first who gets such error.
Any ideas?
-ip
--
A lack of planning on your part
does not constitute an emergency on my part.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: loading kernel at any physical address
I think this might be somewhat off topic, but to support superpages you probably want kernel to be aligned on 4MB boundary. Also, Mach had macros for alignment. I browsed code and it seems there are macros in i386/include/asmacros.h Perhaps I am missing something, but I don't see why would you want to align with NOPS. -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 15 Dec 2004 10:43:45 -0800 Subject: loading kernel at any physical address Hello all, for a project I am trying to figure out how to boot a FreeBSD kernel loaded at any physical address. Right now the locore.s magic works because the load addres (KERNLOAD) and (KERNBASE) are set such that #define R(foo) ((foo)-KERNBASE) macro is able to get the addresses before paging is enabled. If the loadaddress information is not embedded in defines, then is the following solution expected to work: .globl _loadaddress/* should be at 16M aligned ??? */ .set_loadaddress,KERNBASE and then: NON_GPROF_ENTRY(btext) nop /* nops for 8 byte alignment */ nop nop call 0f 0: mov 4(%ebp), %eax add $-8, %eax /* This is actual physical load addr */ add $-0x10, %eax subl %eax, _loadaddress /* new kernbase w.r.t load addr */ /* instead of standard 1MB reloc */ and then #define R(foo) ((foo)- _loadaddress) One issue might be loadaddress over 16M, but for this problem we can assume that the processor has been in protected mode, so it has access to that space. Any input on this is highly appreciated. br vijay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Loadable Scheduler in Freebsd
If the schedulers were aware of the selected scheduler (or perhaps the previous scheduler), they could do the thread removal and insertions themselves I suppose. I doubt you would want to do that. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Relative performance of swap-backed MFS vs. regular UFS?
On Fri, Oct 22, 2004 at 12:32:40PM -1000, Clifton Royston wrote: I have seen some conflicting information posted about this in the past, and I figure this is the best place to get an authoritative answer. For a large temporary file system which must hold short-lived files, mostly small but occasionally several very large ones (e.g. 100MB+), is it better for performance and stability if this file system: 1) resides on a swap-backed MFS and trusts the OS to swap out low-priority blocks if needed under RAM pressure, or 2) on a regular UFS and trusts the OS to buffer as many blocks as possible into RAM when RAM is free? You can also use md(4). In my case I use it for /tmp. -ip -- The best shots happen immediately after the last frame is exposed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Relative performance of swap-backed MFS vs. regular UFS?
On Sat, Oct 23, 2004 at 01:12:46PM -0500, Ryan Sommers wrote: You can also use md(4). In my case I use it for /tmp. MFS is the same thing as md(4). mfs = Memory File System, md = Memory Disk. Difference is only in the name. I thought mfs is allocated from virtual memory, while md - directly from RAM. Am I wrong? -ip -- The best shots happen immediately after the last frame is exposed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
