Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c [NDA's]
In message [EMAIL PROTECTED], Sam Leffler writes: The key to working with companies is always to establish a level of trust and a relationship with people that work there. Everything else falls out as a result. A CTO once said to me in perfect dead pan way: They only people we can't get to sign a NDA is our laywers, but they say I shouldn't worry about that. I agree with Sam, talk to them, explain that the NDA needs to allow you to release the driver or the effort will be pointless. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Yar Tikhiy wrote: On Wed, Apr 25, 2007 at 02:41:00PM -0400, Stephan Uphoff wrote: Yar Tikhiy wrote: On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote: On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. Alas, we don't live in an ideal world. If we did, our commit messages would always follow the well-known guideline: 0. Tell the essence of the change. 1. Give the reason for the change. 2. Explain the change unless it's trivial. In the ideal world there are no NDAs :-) Was the change based on a document under NDA? Then this case raises an interesting question: to what extent an open source developer is allowed to explain his code that was based on a document under NDA? Of course, it should depend on the NDA, but I suspect that a typical NDA requires a lawyer to interpret it unambiguously (I've never signed one by myself), and an overcautious lawyer would say that the open source code itself violates the NDA because anybody can RTFS. :-) Wow, that was painful to read. NDAs that specifically allow source code licensing and distribution are quite common. They even get written and reviewed by lawyers! =-) Scott ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
On Thu, Apr 26, 2007 at 12:42:14AM -0600, Scott Long wrote: Yar Tikhiy wrote: On Wed, Apr 25, 2007 at 02:41:00PM -0400, Stephan Uphoff wrote: Yar Tikhiy wrote: On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote: On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. Alas, we don't live in an ideal world. If we did, our commit messages would always follow the well-known guideline: 0. Tell the essence of the change. 1. Give the reason for the change. 2. Explain the change unless it's trivial. In the ideal world there are no NDAs :-) Was the change based on a document under NDA? Then this case raises an interesting question: to what extent an open source developer is allowed to explain his code that was based on a document under NDA? Of course, it should depend on the NDA, but I suspect that a typical NDA requires a lawyer to interpret it unambiguously (I've never signed one by myself), and an overcautious lawyer would say that the open source code itself violates the NDA because anybody can RTFS. :-) Wow, that was painful to read. NDAs that specifically allow source code licensing and distribution are quite common. They even get written and reviewed by lawyers! =-) It's a good news! But what about explaining the code to the public? - Mr. Developer, why does it take an ugly hack to make the device work? - Can't tell ya, I'm under NDA. ;-) -- Yar ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Yar Tikhiy wrote: On Thu, Apr 26, 2007 at 12:42:14AM -0600, Scott Long wrote: Yar Tikhiy wrote: On Wed, Apr 25, 2007 at 02:41:00PM -0400, Stephan Uphoff wrote: Yar Tikhiy wrote: On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote: On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. Alas, we don't live in an ideal world. If we did, our commit messages would always follow the well-known guideline: 0. Tell the essence of the change. 1. Give the reason for the change. 2. Explain the change unless it's trivial. In the ideal world there are no NDAs :-) Was the change based on a document under NDA? Then this case raises an interesting question: to what extent an open source developer is allowed to explain his code that was based on a document under NDA? Of course, it should depend on the NDA, but I suspect that a typical NDA requires a lawyer to interpret it unambiguously (I've never signed one by myself), and an overcautious lawyer would say that the open source code itself violates the NDA because anybody can RTFS. :-) Wow, that was painful to read. NDAs that specifically allow source code licensing and distribution are quite common. They even get written and reviewed by lawyers! =-) It's a good news! But what about explaining the code to the public? - Mr. Developer, why does it take an ugly hack to make the device work? - Can't tell ya, I'm under NDA. I think you have to respect that John and Stephan were doing the right thing with this. This was no different than a security fix that gets committed before the vulnerability is disclosed. No one seems to get upset that the security team operates this way. Scott ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Scott Long wrote: Yar Tikhiy wrote: [snip] It's a good news! But what about explaining the code to the public? - Mr. Developer, why does it take an ugly hack to make the device work? - Can't tell ya, I'm under NDA. I think you have to respect that John and Stephan were doing the right thing with this. This was no different than a security fix that gets committed before the vulnerability is disclosed. No one seems to get upset that the security team operates this way. I can only think of one recent case where a security fix was applied without the vulnerability details becoming public within a matter of minutes (i.e., as soon as we could get the advisory signed and uploaded), and that was due to a desire to avoid upstaging my BSDCan talk about hyperthreading (and in that case, all the details became available about 16 hours after patches were committed). That said, I think we have to respect the fact that NDAs, while not ideal, provide limited access to information which would otherwise be entirely unavailable; and in such circumstances I think Yar's suggested response of Can't tell ya, I'm under NDA would be perfectly acceptable. Colin Percival ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
On Thu, 26 Apr 2007 02:10:05 -0700 Colin Percival [EMAIL PROTECTED] wrote: Scott Long wrote: Yar Tikhiy wrote: [snip] It's a good news! But what about explaining the code to the public? - Mr. Developer, why does it take an ugly hack to make the device work? - Can't tell ya, I'm under NDA. I think you have to respect that John and Stephan were doing the right thing with this. This was no different than a security fix that gets committed before the vulnerability is disclosed. No one seems to get upset that the security team operates this way. I can only think of one recent case where a security fix was applied without the vulnerability details becoming public within a matter of minutes (i.e., as soon as we could get the advisory signed and uploaded), and that was due to a desire to avoid upstaging my BSDCan talk about hyperthreading (and in that case, all the details became available about 16 hours after patches were committed). That said, I think we have to respect the fact that NDAs, while not ideal, provide limited access to information which would otherwise be entirely unavailable; and in such circumstances I think Yar's suggested response of Can't tell ya, I'm under NDA would be perfectly acceptable. Oh, opinion time. My concern isn't with the NDA as long as a useful commit is made. I think we should be happy something is being put into cvs at all. -- Tom Rhodes ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
On Thu, Apr 26, 2007 at 02:41:02AM -0600, Scott Long wrote: Yar Tikhiy wrote: On Thu, Apr 26, 2007 at 12:42:14AM -0600, Scott Long wrote: Yar Tikhiy wrote: On Wed, Apr 25, 2007 at 02:41:00PM -0400, Stephan Uphoff wrote: Yar Tikhiy wrote: On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote: On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. Alas, we don't live in an ideal world. If we did, our commit messages would always follow the well-known guideline: 0. Tell the essence of the change. 1. Give the reason for the change. 2. Explain the change unless it's trivial. In the ideal world there are no NDAs :-) Was the change based on a document under NDA? Then this case raises an interesting question: to what extent an open source developer is allowed to explain his code that was based on a document under NDA? Of course, it should depend on the NDA, but I suspect that a typical NDA requires a lawyer to interpret it unambiguously (I've never signed one by myself), and an overcautious lawyer would say that the open source code itself violates the NDA because anybody can RTFS. :-) Wow, that was painful to read. NDAs that specifically allow source code licensing and distribution are quite common. They even get written and reviewed by lawyers! =-) It's a good news! But what about explaining the code to the public? - Mr. Developer, why does it take an ugly hack to make the device work? - Can't tell ya, I'm under NDA. I think you have to respect that John and Stephan were doing the right thing with this. This was no different than a security fix that gets committed before the vulnerability is disclosed. No one seems to get upset that the security team operates this way. John and Stephan are doing a great job in any case, but I fail to understand your point. I can't see how the two cases can be the same. A fixed vulnerability is no more a threat to security, but NDA doesn't get cancelled upon the commit. So I was curious about how much knowledge a developer is legally allowed to relay to the community besides the code itself if he is tied by NDA. -- Yar ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Yar Tikhiy wrote: On Thu, Apr 26, 2007 at 02:41:02AM -0600, Scott Long wrote: Yar Tikhiy wrote: On Thu, Apr 26, 2007 at 12:42:14AM -0600, Scott Long wrote: Yar Tikhiy wrote: On Wed, Apr 25, 2007 at 02:41:00PM -0400, Stephan Uphoff wrote: Yar Tikhiy wrote: On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote: On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. Alas, we don't live in an ideal world. If we did, our commit messages would always follow the well-known guideline: 0. Tell the essence of the change. 1. Give the reason for the change. 2. Explain the change unless it's trivial. In the ideal world there are no NDAs :-) Was the change based on a document under NDA? Then this case raises an interesting question: to what extent an open source developer is allowed to explain his code that was based on a document under NDA? Of course, it should depend on the NDA, but I suspect that a typical NDA requires a lawyer to interpret it unambiguously (I've never signed one by myself), and an overcautious lawyer would say that the open source code itself violates the NDA because anybody can RTFS. :-) Wow, that was painful to read. NDAs that specifically allow source code licensing and distribution are quite common. They even get written and reviewed by lawyers! =-) It's a good news! But what about explaining the code to the public? - Mr. Developer, why does it take an ugly hack to make the device work? - Can't tell ya, I'm under NDA. I think you have to respect that John and Stephan were doing the right thing with this. This was no different than a security fix that gets committed before the vulnerability is disclosed. No one seems to get upset that the security team operates this way. John and Stephan are doing a great job in any case, but I fail to understand your point. I can't see how the two cases can be the same. A fixed vulnerability is no more a threat to security, but NDA doesn't get cancelled upon the commit. So I was curious about how much knowledge a developer is legally allowed to relay to the community besides the code itself if he is tied by NDA. In this specific case the vendor was really helpful and just wanted to give us a chance to fix the code before publishing the documentation that described why it was needed. The vendor worked with me to get the fix in the tree before the document publication date and as such there was no problem with the NDA. Yesterday the vendor published the documentation and as planned I could then comment on why the changes were needed. In general I agree that source code written with documents under NDAs can not be fully understood/verified without access to these documents and as such does not fully benefit from the automatic open source review process. And I am really happy that now that the relevant document is published everyone can review my changes. Stephan ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c [NDA's]
Yar Tikhiy wrote: Was the change based on a document under NDA? Then this case raises an interesting question: to what extent an open source developer is allowed to explain his code that was based on a document under NDA? Of course, it should depend on the NDA, but I suspect that a typical NDA requires a lawyer to interpret it unambiguously (I've never signed one by myself), and an overcautious lawyer would say that the open source code itself violates the NDA because anybody can RTFS. :-) NDA's are negotiable. I've signed plenty and am very careful to structure them so that when the work product is to be released to the open source community there is no confusion about whether information may or may not be disclosed. Companies that work with the open source community but require NDA's typically use them to control premature release of information and restrict related information (e.g. product plans). In my experience companies often mark documents w/ an NDA because they don't want to have to deal with the liability of a doc having mistakes and because they don't want to deal with random folks badgering them for support when they can't understand what's written. The key to working with companies is always to establish a level of trust and a relationship with people that work there. Everything else falls out as a result. Sam ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c [NDA's]
Sam Leffler wrote: Yar Tikhiy wrote: Was the change based on a document under NDA? Then this case raises an interesting question: to what extent an open source developer is allowed to explain his code that was based on a document under NDA? Of course, it should depend on the NDA, but I suspect that a typical NDA requires a lawyer to interpret it unambiguously (I've never signed one by myself), and an overcautious lawyer would say that the open source code itself violates the NDA because anybody can RTFS. :-) NDA's are negotiable. I've signed plenty and am very careful to structure them so that when the work product is to be released to the open source community there is no confusion about whether information may or may not be disclosed. Companies that work with the open source community but require NDA's typically use them to control premature release of information and restrict related information (e.g. product plans). In my experience companies often mark documents w/ an NDA because they don't want to have to deal with the liability of a doc having mistakes and because they don't want to deal with random folks badgering them for support when they can't understand what's written. The key to working with companies is always to establish a level of trust and a relationship with people that work there. Everything else falls out as a result. Nicely put. Since developers tend to focus on legal stuff so much, I'd like to add that an NDA is a contract. A contract only is used one way, as part of a lawsuit. (Establishing a contract helps clarify things, but enforcement only happens through a suit.) In nearly all cases, if you're being sued, something else went wrong along the way in the relationship. And that's what you should be most focused on is avoiding the relationship problem in the first place, even with people who you don't have a contract with. -- Nate ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Yar Tikhiy wrote: On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote: On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. Alas, we don't live in an ideal world. If we did, our commit messages would always follow the well-known guideline: 0. Tell the essence of the change. 1. Give the reason for the change. 2. Explain the change unless it's trivial. In the ideal world there are no NDAs :-) As planned I forced a commit with a better comment once I was able to. Thanks for your patients, Stephan ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
On Wed, Apr 25, 2007 at 02:41:00PM -0400, Stephan Uphoff wrote: Yar Tikhiy wrote: On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote: On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. Alas, we don't live in an ideal world. If we did, our commit messages would always follow the well-known guideline: 0. Tell the essence of the change. 1. Give the reason for the change. 2. Explain the change unless it's trivial. In the ideal world there are no NDAs :-) Was the change based on a document under NDA? Then this case raises an interesting question: to what extent an open source developer is allowed to explain his code that was based on a document under NDA? Of course, it should depend on the NDA, but I suspect that a typical NDA requires a lawyer to interpret it unambiguously (I've never signed one by myself), and an overcautious lawyer would say that the open source code itself violates the NDA because anybody can RTFS. :-) As planned I forced a commit with a better comment once I was able to. Thank you, the new comment is excellent! I hope Intel won't sue you for it. :-) Thanks for your patients, Stephan -- Yar ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote: On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. Alas, we don't live in an ideal world. If we did, our commit messages would always follow the well-known guideline: 0. Tell the essence of the change. 1. Give the reason for the change. 2. Explain the change unless it's trivial. -- Yar ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
On Tuesday 24 April 2007 05:18:59 am Yar Tikhiy wrote: On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote: On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. Alas, we don't live in an ideal world. If we did, our commit messages would always follow the well-known guideline: 0. Tell the essence of the change. 1. Give the reason for the change. 2. Explain the change unless it's trivial. The point of the modification is to make sure we don't clear TLB entries for pages whose mappings are being removed until we've also made any necessary updates to other entries higher in the page table hierarchy such as pde's etc. We've seen some really bizarre bad pte panics at work that this change fixes. -- John Baldwin ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? -- Andre ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote: Stephan Uphoff wrote: ups 2007-04-21 14:17:30 UTC FreeBSD src repository Modified files: sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: Modify TLB invalidation handling. Reviewed by:alc@, peter@ MFC after: 1 week Could you be a bit more verbose what changed here and why it was done? I agree. I would really like to know what the modification accomplishes. -- Coleman Kane ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Hi, Sorry about the previous mail. Unfortunatly it proved that I can add a kernel option (DDB_UNATTENDED) to make a kernel with rev. 1.563 of sys/i386/i386/pmap.c in place to not crash anymore. The strange thing is, I've compiled GENERIC kernels from '2006-10-01', '2006-09-01', '2006-08-01', '2006-07-01', '2006-06-28'. Those HEAD kernels all crash my box. The kernels from '2006-04-01', '2006-05-01', '2006-06-01', '2006-06-06', '2006-06-15', '2006-06-22', '2006-06-27' don't crash ... After I've removed rev. 1.563 of sys/i386/i386/pmap.c from recent CURRENT and made a fresh compile the box did not crash anymore. I readded it, and it crashed. So is this corrupt memory ? Could that be ? Why I get then crashes always at the same place and nowhere else ? (The box is rocking stable). Martin ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Hi Alan, This commit makes my box crash with HEAD at startup. Please back it out and investige why it happens. I'm pretty sure that it happens for RELENG_6 too. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- On Wed, 27 Sep 2006, Alan Cox wrote: alc 2006-09-27 18:10:16 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: MFC Correct a very old and very obscure bug: vmspace_fork() calls pmap_copy() if the mapping is VM_INHERIT_SHARE. Suppose the mapping is also wired. vmspace_fork() clears the wiring attributes in the vm map entry but pmap_copy() copies the PG_W attribute in the PTE. I don't think this is catastrophic. It blocks pmap_remove_pages() from destroying the mapping and corrupts the pmap's wiring count. This revision fixes the problem by changing pmap_copy() to clear the PG_W attribute. Approved by: re (mux) Revision ChangesPath 1.516.2.8 +4 -3 src/sys/amd64/amd64/pmap.c 1.523.2.8 +5 -3 src/sys/i386/i386/pmap.c ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c
Martin Blapp wrote: Hi Alan, This commit makes my box crash with HEAD at startup. Please back it out and investige why it happens. I'm pretty sure that it happens for RELENG_6 too. The assertion that fails for you under HEAD does not exist in RELENG_6. Have you seen a different assertion failure or crash in RELENG_6 since this patch was applied there? I will discuss this with [EMAIL PROTECTED] Regards, Alan Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- On Wed, 27 Sep 2006, Alan Cox wrote: alc 2006-09-27 18:10:16 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) sys/amd64/amd64 pmap.c sys/i386/i386pmap.c Log: MFC Correct a very old and very obscure bug: vmspace_fork() calls pmap_copy() if the mapping is VM_INHERIT_SHARE. Suppose the mapping is also wired. vmspace_fork() clears the wiring attributes in the vm map entry but pmap_copy() copies the PG_W attribute in the PTE. I don't think this is catastrophic. It blocks pmap_remove_pages() from destroying the mapping and corrupts the pmap's wiring count. This revision fixes the problem by changing pmap_copy() to clear the PG_W attribute. Approved by: re (mux) Revision ChangesPath 1.516.2.8 +4 -3 src/sys/amd64/amd64/pmap.c 1.523.2.8 +5 -3 src/sys/i386/i386/pmap.c ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED]
