fts(3) not checking for readdir(3) errors
Hello, For one of my projects, I've received a patch to our implementation of fts(3) which does not check for readdir(3) errors. The patch seemed obvious and looked OK to me so I merged it to my project. I think we should merge it to FreeBSD too so I've opened a PR (with the patch) here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262038 Could a src committer have a look at it please ? Thanks in advance, Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org
Re: Is there any error checking on swap?
On 7/12/20 12:29 AM, John-Mark Gurney wrote: > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: >> Is there any error checking on swap traffic, along the lines of >> a checksum or parity test? >> >> Just curious what happens if a page written out is corrupted when >> it comes back. > > Looks like it doesn't: > https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389 Technically one can enable checks with e.g. geli(8), but note that the geli(8) provider will not "prime" the HMAC data so attaching the device will immediately spam the system log with some authentication errors due to GEOM tasting (because the kernel would try to read locations that potentially contain metadata for other GEOM providers). For the case of swap, since the write is always page sized, it's probably optimal to implement something in the swap layer itself and store the expected checksums in memory. Cheers, signature.asc Description: OpenPGP digital signature
Re: Is there any error checking on swap?
Xin Li wrote this message on Sun, Jul 12, 2020 at 15:06 -0700: > > > On 7/12/20 12:29 AM, John-Mark Gurney wrote: > > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > >> Is there any error checking on swap traffic, along the lines of > >> a checksum or parity test? > >> > >> Just curious what happens if a page written out is corrupted when > >> it comes back. > > > > Looks like it doesn't: > > https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389 > > Technically one can enable checks with e.g. geli(8), but note that the > geli(8) provider will not "prime" the HMAC data so attaching the device > will immediately spam the system log with some authentication errors due > to GEOM tasting (because the kernel would try to read locations that > potentially contain metadata for other GEOM providers). Yeah, and enabling auth w/ geli(8) is problematic, as it creates a disconnect between layers, as it expands 4096 byte writes to 9 512 byte sector writes, if you're using a 4k drive (which is pretty much the only thing sold these days), the performance is likely to be pretty terrible... see: https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli_integrity.c?annotate=361481#l56 So, it'd be doable, but less than ideal... > For the case of swap, since the write is always page sized, it's > probably optimal to implement something in the swap layer itself and > store the expected checksums in memory. +1 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." signature.asc Description: PGP signature
Re: Is there any error checking on swap?
bob prohaska wrote this message on Sun, Jul 12, 2020 at 08:37 -0700: > On Sun, Jul 12, 2020 at 12:29:12AM -0700, John-Mark Gurney wrote: > > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > > > Is there any error checking on swap traffic, along the lines of > > > a checksum or parity test? > > > > > > Just curious what happens if a page written out is corrupted when > > > it comes back. > > > > Looks like it doesn't: > > https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389 > > > > Certainly nothing about parity or checksums in the comments. > All faith in the hardware, I guess > > Thanks for writing! It probably wouldn't be too hard to add the feature... Just expand the page entry to store a fletcher checksum or the like... Another option would be to try to use swap on ZFS, and use ZFS's builtin checksum feature: https://wiki.freebsd.org/RootOnZFS#ZFS_Swap_Volume -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is there any error checking on swap?
On Sun, Jul 12, 2020 at 12:29:12AM -0700, John-Mark Gurney wrote: > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > > Is there any error checking on swap traffic, along the lines of > > a checksum or parity test? > > > > Just curious what happens if a page written out is corrupted when > > it comes back. > > Looks like it doesn't: > https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389 > Certainly nothing about parity or checksums in the comments. All faith in the hardware, I guess Thanks for writing! bob prohaska ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is there any error checking on swap?
bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > Is there any error checking on swap traffic, along the lines of > a checksum or parity test? > > Just curious what happens if a page written out is corrupted when > it comes back. Looks like it doesn't: https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Is there any error checking on swap?
Is there any error checking on swap traffic, along the lines of a checksum or parity test? Just curious what happens if a page written out is corrupted when it comes back. Thanks for reading, bob prohaska ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
On Thu, Jun 20, 2019 at 7:40 AM Rodney W. Grimes wrote: > > > On 19-06-20 05 h 59, Warner Losh wrote: > > > On Wed, Jun 19, 2019 at 7:55 PM Alan Somers wrote: > > > > > >> On Wed, Jun 19, 2019 at 8:41 PM Warner Losh wrote: > > >>> > > >>> > > >>> > > >>> On Wed, Jun 19, 2019, 7:09 PM Alan Somers wrote: > > > > On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: > > > > > > > > > > > > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers > > >> wrote: > > >> > > >> Does anybody know how to check out a local copy of the CSRG > > >> repository? I can view it with ViewVC, but I would really like local > > >> access. It doesn't seem to be available on the usual > > >> repo.FreeBSD.org > > >> or svn.FreeBSD.org. > > >> > > >> $ svn checkout https://svn.FreeBSD.org/csrg csrg > > >> svn: E170013: Unable to connect to a repository at URL > > >> 'https://svn.freebsd.org/csrg' > > >> svn: E175009: The XML response contains invalid XML > > >> svn: E130003: Malformed XML: no element found at line 1 > > >> > > >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > > >> svn: E170013: Unable to connect to a repository at URL > > >> 'svn+ssh://asom...@repo.freebsd.org/csrg' > > >> svn: E210005: No repository found in 'svn+ssh:// > > >> asom...@repo.freebsd.org/csrg' > > > > > > > > > Can't answer this question directly about svn > > > > > > But I have been using > > >> https://github.com/dspinellis/unix-history-repo.git to look at historical > > >> sources. https://github.com/csrg has a number of additional repos of > > >> historical interest, though they are all forks from somewhere else. > > > > > > Warner > > > > Thanks for that Github link; it's pretty useful. Also, I found this > > site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just > > wish I had a better understanding of the relationship between CSRG and > > the various releases. It seems like some stuff got committed to CSRG > > yet didn't make it into an official release for years, if ever. > > >>> > > >>> > > >>> TUHS is awesome. I use it too, bit the historical github tree is more > > >> convenient. > > >>> > > >>> CSRG's 4.x series was pretty linear. What didn't make it? > > >>> > > >>> Warner > > >> > > >> I'm looking at bmap. When I wrote that email, the earliest released > > >> reference I could find was in 4.3-Reno. However, I just spotted it in > > >> 4.2, which is a much more reasonable time frame (it moved to a > > >> different file which is why I missed it before). However, the files > > >> in question don't even exist in the git branches from dspinellis's > > >> repository. I had to find them on tuhs.org. Am I doing something > > >> wrong, or are dspinellis's release branches not fully populated? > > >> Compare > > >> https://github.com/dspinellis/unix-history-repo/tree/BSD-4_3_Reno-Snapshot-Development/usr/src/sys/sys > > >> to https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/sys/sys > > > > > > > > > I'm guessing the SCCS -> SVN -> Git process broke files that were renamed > > > or copied... I've not dug deeper though... This tells me that we need to > > > send dspinellis some corrections :) > > > > > > Warner > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > > > > Replying to an arbitrary message.. > > > > Using svnweb it so EASY to see that the correct invocation is > > > > svn co https://svn.freebsd.org/base/vendor/CSRG > > > > as I just done.. > > Well once you know that it is obvious, I think is what > is happening is that people go to https://svn.freebsd.org/ > and there is csrg listed there and the paths you get once > you follow that is wrong from then on. > > Maybe obliterarate that top level miss leading link > would be the right thing to do? Or put a roadmap > file at that level in place and then delete that csrg link. > > Thank you for pointing us all to where the "real data" > is at. No. base/vendor/CSRG is different. It just has a dump of a few things that were imported into base/head. It doesn't have the full history of CSRG's work. You can tell just by looking at the number of commits. base/vendor/CSRG only has 73 commits, but the full CSRG repo has about 1000x as many. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
> On 19-06-20 05 h 59, Warner Losh wrote: > > On Wed, Jun 19, 2019 at 7:55 PM Alan Somers wrote: > > > >> On Wed, Jun 19, 2019 at 8:41 PM Warner Losh wrote: > >>> > >>> > >>> > >>> On Wed, Jun 19, 2019, 7:09 PM Alan Somers wrote: > > On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: > > > > > > > > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers > >> wrote: > >> > >> Does anybody know how to check out a local copy of the CSRG > >> repository? I can view it with ViewVC, but I would really like local > >> access. It doesn't seem to be available on the usual > >> repo.FreeBSD.org > >> or svn.FreeBSD.org. > >> > >> $ svn checkout https://svn.FreeBSD.org/csrg csrg > >> svn: E170013: Unable to connect to a repository at URL > >> 'https://svn.freebsd.org/csrg' > >> svn: E175009: The XML response contains invalid XML > >> svn: E130003: Malformed XML: no element found at line 1 > >> > >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > >> svn: E170013: Unable to connect to a repository at URL > >> 'svn+ssh://asom...@repo.freebsd.org/csrg' > >> svn: E210005: No repository found in 'svn+ssh:// > >> asom...@repo.freebsd.org/csrg' > > > > > > Can't answer this question directly about svn > > > > But I have been using > >> https://github.com/dspinellis/unix-history-repo.git to look at historical > >> sources. https://github.com/csrg has a number of additional repos of > >> historical interest, though they are all forks from somewhere else. > > > > Warner > > Thanks for that Github link; it's pretty useful. Also, I found this > site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just > wish I had a better understanding of the relationship between CSRG and > the various releases. It seems like some stuff got committed to CSRG > yet didn't make it into an official release for years, if ever. > >>> > >>> > >>> TUHS is awesome. I use it too, bit the historical github tree is more > >> convenient. > >>> > >>> CSRG's 4.x series was pretty linear. What didn't make it? > >>> > >>> Warner > >> > >> I'm looking at bmap. When I wrote that email, the earliest released > >> reference I could find was in 4.3-Reno. However, I just spotted it in > >> 4.2, which is a much more reasonable time frame (it moved to a > >> different file which is why I missed it before). However, the files > >> in question don't even exist in the git branches from dspinellis's > >> repository. I had to find them on tuhs.org. Am I doing something > >> wrong, or are dspinellis's release branches not fully populated? > >> Compare > >> https://github.com/dspinellis/unix-history-repo/tree/BSD-4_3_Reno-Snapshot-Development/usr/src/sys/sys > >> to https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/sys/sys > > > > > > I'm guessing the SCCS -> SVN -> Git process broke files that were renamed > > or copied... I've not dug deeper though... This tells me that we need to > > send dspinellis some corrections :) > > > > Warner > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > Replying to an arbitrary message.. > > Using svnweb it so EASY to see that the correct invocation is > > svn co https://svn.freebsd.org/base/vendor/CSRG > > as I just done.. Well once you know that it is obvious, I think is what is happening is that people go to https://svn.freebsd.org/ and there is csrg listed there and the paths you get once you follow that is wrong from then on. Maybe obliterarate that top level miss leading link would be the right thing to do? Or put a roadmap file at that level in place and then delete that csrg link. Thank you for pointing us all to where the "real data" is at. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
On 19-06-20 05 h 59, Warner Losh wrote: On Wed, Jun 19, 2019 at 7:55 PM Alan Somers wrote: On Wed, Jun 19, 2019 at 8:41 PM Warner Losh wrote: On Wed, Jun 19, 2019, 7:09 PM Alan Somers wrote: On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: On Wed, Jun 19, 2019 at 1:14 PM Alan Somers wrote: Does anybody know how to check out a local copy of the CSRG repository? I can view it with ViewVC, but I would really like local access. It doesn't seem to be available on the usual repo.FreeBSD.org or svn.FreeBSD.org. $ svn checkout https://svn.FreeBSD.org/csrg csrg svn: E170013: Unable to connect to a repository at URL 'https://svn.freebsd.org/csrg' svn: E175009: The XML response contains invalid XML svn: E130003: Malformed XML: no element found at line 1 $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg svn: E170013: Unable to connect to a repository at URL 'svn+ssh://asom...@repo.freebsd.org/csrg' svn: E210005: No repository found in 'svn+ssh:// asom...@repo.freebsd.org/csrg' Can't answer this question directly about svn But I have been using https://github.com/dspinellis/unix-history-repo.git to look at historical sources. https://github.com/csrg has a number of additional repos of historical interest, though they are all forks from somewhere else. Warner Thanks for that Github link; it's pretty useful. Also, I found this site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just wish I had a better understanding of the relationship between CSRG and the various releases. It seems like some stuff got committed to CSRG yet didn't make it into an official release for years, if ever. TUHS is awesome. I use it too, bit the historical github tree is more convenient. CSRG's 4.x series was pretty linear. What didn't make it? Warner I'm looking at bmap. When I wrote that email, the earliest released reference I could find was in 4.3-Reno. However, I just spotted it in 4.2, which is a much more reasonable time frame (it moved to a different file which is why I missed it before). However, the files in question don't even exist in the git branches from dspinellis's repository. I had to find them on tuhs.org. Am I doing something wrong, or are dspinellis's release branches not fully populated? Compare https://github.com/dspinellis/unix-history-repo/tree/BSD-4_3_Reno-Snapshot-Development/usr/src/sys/sys to https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/sys/sys I'm guessing the SCCS -> SVN -> Git process broke files that were renamed or copied... I've not dug deeper though... This tells me that we need to send dspinellis some corrections :) Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Replying to an arbitrary message.. Using svnweb it so EASY to see that the correct invocation is svn co https://svn.freebsd.org/base/vendor/CSRG as I just done.. CBu ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
On Wed, Jun 19, 2019 at 7:55 PM Alan Somers wrote: > On Wed, Jun 19, 2019 at 8:41 PM Warner Losh wrote: > > > > > > > > On Wed, Jun 19, 2019, 7:09 PM Alan Somers wrote: > >> > >> On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: > >> > > >> > > >> > > >> > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers > wrote: > >> >> > >> >> Does anybody know how to check out a local copy of the CSRG > >> >> repository? I can view it with ViewVC, but I would really like local > >> >> access. It doesn't seem to be available on the usual > repo.FreeBSD.org > >> >> or svn.FreeBSD.org. > >> >> > >> >> $ svn checkout https://svn.FreeBSD.org/csrg csrg > >> >> svn: E170013: Unable to connect to a repository at URL > >> >> 'https://svn.freebsd.org/csrg' > >> >> svn: E175009: The XML response contains invalid XML > >> >> svn: E130003: Malformed XML: no element found at line 1 > >> >> > >> >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > >> >> svn: E170013: Unable to connect to a repository at URL > >> >> 'svn+ssh://asom...@repo.freebsd.org/csrg' > >> >> svn: E210005: No repository found in 'svn+ssh:// > asom...@repo.freebsd.org/csrg' > >> > > >> > > >> > Can't answer this question directly about svn > >> > > >> > But I have been using > https://github.com/dspinellis/unix-history-repo.git to look at historical > sources. https://github.com/csrg has a number of additional repos of > historical interest, though they are all forks from somewhere else. > >> > > >> > Warner > >> > >> Thanks for that Github link; it's pretty useful. Also, I found this > >> site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just > >> wish I had a better understanding of the relationship between CSRG and > >> the various releases. It seems like some stuff got committed to CSRG > >> yet didn't make it into an official release for years, if ever. > > > > > > TUHS is awesome. I use it too, bit the historical github tree is more > convenient. > > > > CSRG's 4.x series was pretty linear. What didn't make it? > > > > Warner > > I'm looking at bmap. When I wrote that email, the earliest released > reference I could find was in 4.3-Reno. However, I just spotted it in > 4.2, which is a much more reasonable time frame (it moved to a > different file which is why I missed it before). However, the files > in question don't even exist in the git branches from dspinellis's > repository. I had to find them on tuhs.org. Am I doing something > wrong, or are dspinellis's release branches not fully populated? > Compare > https://github.com/dspinellis/unix-history-repo/tree/BSD-4_3_Reno-Snapshot-Development/usr/src/sys/sys > to https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/sys/sys I'm guessing the SCCS -> SVN -> Git process broke files that were renamed or copied... I've not dug deeper though... This tells me that we need to send dspinellis some corrections :) Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
On Wed, Jun 19, 2019 at 8:41 PM Warner Losh wrote: > > > > On Wed, Jun 19, 2019, 7:09 PM Alan Somers wrote: >> >> On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: >> > >> > >> > >> > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers wrote: >> >> >> >> Does anybody know how to check out a local copy of the CSRG >> >> repository? I can view it with ViewVC, but I would really like local >> >> access. It doesn't seem to be available on the usual repo.FreeBSD.org >> >> or svn.FreeBSD.org. >> >> >> >> $ svn checkout https://svn.FreeBSD.org/csrg csrg >> >> svn: E170013: Unable to connect to a repository at URL >> >> 'https://svn.freebsd.org/csrg' >> >> svn: E175009: The XML response contains invalid XML >> >> svn: E130003: Malformed XML: no element found at line 1 >> >> >> >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg >> >> svn: E170013: Unable to connect to a repository at URL >> >> 'svn+ssh://asom...@repo.freebsd.org/csrg' >> >> svn: E210005: No repository found in >> >> 'svn+ssh://asom...@repo.freebsd.org/csrg' >> > >> > >> > Can't answer this question directly about svn >> > >> > But I have been using https://github.com/dspinellis/unix-history-repo.git >> > to look at historical sources. https://github.com/csrg has a number of >> > additional repos of historical interest, though they are all forks from >> > somewhere else. >> > >> > Warner >> >> Thanks for that Github link; it's pretty useful. Also, I found this >> site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just >> wish I had a better understanding of the relationship between CSRG and >> the various releases. It seems like some stuff got committed to CSRG >> yet didn't make it into an official release for years, if ever. > > > TUHS is awesome. I use it too, bit the historical github tree is more > convenient. > > CSRG's 4.x series was pretty linear. What didn't make it? > > Warner I'm looking at bmap. When I wrote that email, the earliest released reference I could find was in 4.3-Reno. However, I just spotted it in 4.2, which is a much more reasonable time frame (it moved to a different file which is why I missed it before). However, the files in question don't even exist in the git branches from dspinellis's repository. I had to find them on tuhs.org. Am I doing something wrong, or are dspinellis's release branches not fully populated? Compare https://github.com/dspinellis/unix-history-repo/tree/BSD-4_3_Reno-Snapshot-Development/usr/src/sys/sys to https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/sys/sys . -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
On Wed, Jun 19, 2019, 7:09 PM Alan Somers wrote: > On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: > > > > > > > > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers wrote: > >> > >> Does anybody know how to check out a local copy of the CSRG > >> repository? I can view it with ViewVC, but I would really like local > >> access. It doesn't seem to be available on the usual repo.FreeBSD.org > >> or svn.FreeBSD.org. > >> > >> $ svn checkout https://svn.FreeBSD.org/csrg csrg > >> svn: E170013: Unable to connect to a repository at URL > >> 'https://svn.freebsd.org/csrg' > >> svn: E175009: The XML response contains invalid XML > >> svn: E130003: Malformed XML: no element found at line 1 > >> > >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > >> svn: E170013: Unable to connect to a repository at URL > >> 'svn+ssh://asom...@repo.freebsd.org/csrg' > >> svn: E210005: No repository found in 'svn+ssh:// > asom...@repo.freebsd.org/csrg' > > > > > > Can't answer this question directly about svn > > > > But I have been using > https://github.com/dspinellis/unix-history-repo.git to look at historical > sources. https://github.com/csrg has a number of additional repos of > historical interest, though they are all forks from somewhere else. > > > > Warner > > Thanks for that Github link; it's pretty useful. Also, I found this > site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just > wish I had a better understanding of the relationship between CSRG and > the various releases. It seems like some stuff got committed to CSRG > yet didn't make it into an official release for years, if ever. > TUHS is awesome. I use it too, bit the historical github tree is more convenient. CSRG's 4.x series was pretty linear. What didn't make it? Warner > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: > > > > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers wrote: >> >> Does anybody know how to check out a local copy of the CSRG >> repository? I can view it with ViewVC, but I would really like local >> access. It doesn't seem to be available on the usual repo.FreeBSD.org >> or svn.FreeBSD.org. >> >> $ svn checkout https://svn.FreeBSD.org/csrg csrg >> svn: E170013: Unable to connect to a repository at URL >> 'https://svn.freebsd.org/csrg' >> svn: E175009: The XML response contains invalid XML >> svn: E130003: Malformed XML: no element found at line 1 >> >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg >> svn: E170013: Unable to connect to a repository at URL >> 'svn+ssh://asom...@repo.freebsd.org/csrg' >> svn: E210005: No repository found in >> 'svn+ssh://asom...@repo.freebsd.org/csrg' > > > Can't answer this question directly about svn > > But I have been using https://github.com/dspinellis/unix-history-repo.git to > look at historical sources. https://github.com/csrg has a number of > additional repos of historical interest, though they are all forks from > somewhere else. > > Warner Thanks for that Github link; it's pretty useful. Also, I found this site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just wish I had a better understanding of the relationship between CSRG and the various releases. It seems like some stuff got committed to CSRG yet didn't make it into an official release for years, if ever. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
> > From: Alan Somers > > Date: Wed, 19 Jun 2019 14:12:21 -0600 > > Subject: Checking out the CSRG repository? > > To: FreeBSD CURRENT > > > > Does anybody know how to check out a local copy of the CSRG > > repository? I can view it with ViewVC, but I would really like local > > access. It doesn't seem to be available on the usual repo.FreeBSD.org > > or svn.FreeBSD.org. > > > > $ svn checkout https://svn.FreeBSD.org/csrg csrg > > svn: E170013: Unable to connect to a repository at URL > > 'https://svn.freebsd.org/csrg' > > svn: E175009: The XML response contains invalid XML > > svn: E130003: Malformed XML: no element found at line 1 > > > > $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > > svn: E170013: Unable to connect to a repository at URL > > 'svn+ssh://asom...@repo.freebsd.org/csrg' > > svn: E210005: No repository found in > > 'svn+ssh://asom...@repo.freebsd.org/csrg' > > > > -Alan > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > You can browse the history at http://svnweb.freebsd.org/csrg/ Since svnweb seems to be able to get to it there should be a near 0 cost of making this work with a straight svn checkout as Alan originally asked for. It is probably something missing, or not configured so that the checkout "can just work". > The repository is also available via FTP: > > ftp://ftp.freebsd.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz > > Hope this helps, Thank you, mirroring locally to my repo server so I can infact use svn directly on it. > Kirk McKusick -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
> From: Alan Somers > Date: Wed, 19 Jun 2019 14:12:21 -0600 > Subject: Checking out the CSRG repository? > To: FreeBSD CURRENT > > Does anybody know how to check out a local copy of the CSRG > repository? I can view it with ViewVC, but I would really like local > access. It doesn't seem to be available on the usual repo.FreeBSD.org > or svn.FreeBSD.org. > > $ svn checkout https://svn.FreeBSD.org/csrg csrg > svn: E170013: Unable to connect to a repository at URL > 'https://svn.freebsd.org/csrg' > svn: E175009: The XML response contains invalid XML > svn: E130003: Malformed XML: no element found at line 1 > > $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > svn: E170013: Unable to connect to a repository at URL > 'svn+ssh://asom...@repo.freebsd.org/csrg' > svn: E210005: No repository found in 'svn+ssh://asom...@repo.freebsd.org/csrg' > > -Alan > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" You can browse the history at http://svnweb.freebsd.org/csrg/ The repository is also available via FTP: ftp://ftp.freebsd.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz Hope this helps, Kirk McKusick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Checking out the CSRG repository?
On Wed, Jun 19, 2019 at 1:14 PM Alan Somers wrote: > Does anybody know how to check out a local copy of the CSRG > repository? I can view it with ViewVC, but I would really like local > access. It doesn't seem to be available on the usual repo.FreeBSD.org > or svn.FreeBSD.org. > > $ svn checkout https://svn.FreeBSD.org/csrg csrg > svn: E170013: Unable to connect to a repository at URL > 'https://svn.freebsd.org/csrg' > svn: E175009: The XML response contains invalid XML > svn: E130003: Malformed XML: no element found at line 1 > > $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > svn: E170013: Unable to connect to a repository at URL > 'svn+ssh://asom...@repo.freebsd.org/csrg' > svn: E210005: No repository found in 'svn+ssh:// > asom...@repo.freebsd.org/csrg' > Can't answer this question directly about svn But I have been using https://github.com/dspinellis/unix-history-repo.git to look at historical sources. https://github.com/csrg has a number of additional repos of historical interest, though they are all forks from somewhere else. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Checking out the CSRG repository?
Does anybody know how to check out a local copy of the CSRG repository? I can view it with ViewVC, but I would really like local access. It doesn't seem to be available on the usual repo.FreeBSD.org or svn.FreeBSD.org. $ svn checkout https://svn.FreeBSD.org/csrg csrg svn: E170013: Unable to connect to a repository at URL 'https://svn.freebsd.org/csrg' svn: E175009: The XML response contains invalid XML svn: E130003: Malformed XML: no element found at line 1 $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg svn: E170013: Unable to connect to a repository at URL 'svn+ssh://asom...@repo.freebsd.org/csrg' svn: E210005: No repository found in 'svn+ssh://asom...@repo.freebsd.org/csrg' -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"
[A amd64->armv7 cross build shows interesting hang-up behavior as well, apparently highly repeatable for my current context.] On 2018-Dec-19, at 16:21, Mark Millard wrote: > [I attached to the hung-up process with gdb and looked around a little.] > > On 2018-Dec-19, at 13:58, Mark Millard wrote: > >> [Looks like a race or some such for devel/qt5-testlib: retry of >> poudreire-devel >> did not hang. The other hang-up seems to be repeating and I give some >> details.] >> >> On 2018-Dec-19, at 12:20, Mark Millard wrote: >> >>> FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . >>> This >>> was a rebuild based on going from perl5.26 to perl5.28 without updating the >>> ports >>> tree and from system clang 6 for the prior FreeBSD-head context used to >>> clang 7 >>> this time. (I'm not attributing causes here.) poudriere was using >>> amd64-native >>> tools for speeding up the cross-build. >>> >>> # grep -r =perl5= /etc/ ~/src.configs/ /usr/local/etc/ >>> /etc/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 >>> /usr/local/etc/poudriere.d/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 >>> >>> There was also a "print/texinfo:configure/runaway" but I've not looked into >>> it at all yet and it may be a while before I do. The other ports attempted >>> built fine as far as I can tell so far. >>> >>> >>> The devel/qt5-testlib failure looks like: >>> >>> [00:00:13] Building 123 packages using 28 builders >>> . . . >>> [00:49:30] [10] [00:00:00] Building devel/qt5-testlib | qt5-testlib-5.11.2 >>> . . . >>> [07:31:31] [10] [06:42:01] Saved devel/qt5-testlib | qt5-testlib-5.11.2 >>> wrkdir to: >>> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailCortexA57-default/default/qt5-testlib-5.11.2.tar >>> [07:31:32] [10] [06:42:02] Finished devel/qt5-testlib | qt5-testlib-5.11.2: >>> Failed: configure/runaway >>> >>> With logs/errors/qt5-testlib-5.11.2.log showing: >>> >>> Checking for POSIX monotonic clock... >>> + cd >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> && >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake >>> "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared >>> warn_off console single_arch" >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> + cd >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> && MAKEFLAGS= make >>> =>> Killing runaway build after 21600 seconds with no output >>> =>> Cleaning up wrkdir >>> ===> Cleaning for qt5-testlib-5.11.2 >>> Killed >>> build of devel/qt5-testlib | qt5-testlib-5.11.2 ended at Wed Dec 19 >>> 06:45:42 PST 2018 >>> build time: 06:41:46 >>> !!! build failure encountered !!! >>> >>> >>> # less >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.log >>> . . . >>> test config.qtbase_corelib.libraries.librt succeeded >>> executing config test clock-monotonic >>> + cd >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> && >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake >>> "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared >>> warn_off console single_arch" >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> + cd >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> && MAKEFLAGS= make >>> >>> >>> Some supporting details of context: >>> >>> # uname -apKU >>> FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r341836M: Tue Dec 11 >>> 16:37:42 PST 2018 >>> markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG >>> amd64 amd64 135 135 >>> >>> # svnlite info /usr/ports/ | grep "Re[plv]" >>> Relative URL: ^/head >>> Repository Root: svn://svn.freebsd.org/ports >>> Repository UUID: 35697150-7ecd-e111-bb59
Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"
[I attached to the hung-up process with gdb and looked around a little.] On 2018-Dec-19, at 13:58, Mark Millard wrote: > [Looks like a race or some such for devel/qt5-testlib: retry of > poudreire-devel > did not hang. The other hang-up seems to be repeating and I give some > details.] > > On 2018-Dec-19, at 12:20, Mark Millard wrote: > >> FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . >> This >> was a rebuild based on going from perl5.26 to perl5.28 without updating the >> ports >> tree and from system clang 6 for the prior FreeBSD-head context used to >> clang 7 >> this time. (I'm not attributing causes here.) poudriere was using >> amd64-native >> tools for speeding up the cross-build. >> >> # grep -r =perl5= /etc/ ~/src.configs/ /usr/local/etc/ >> /etc/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 >> /usr/local/etc/poudriere.d/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 >> >> There was also a "print/texinfo:configure/runaway" but I've not looked into >> it at all yet and it may be a while before I do. The other ports attempted >> built fine as far as I can tell so far. >> >> >> The devel/qt5-testlib failure looks like: >> >> [00:00:13] Building 123 packages using 28 builders >> . . . >> [00:49:30] [10] [00:00:00] Building devel/qt5-testlib | qt5-testlib-5.11.2 >> . . . >> [07:31:31] [10] [06:42:01] Saved devel/qt5-testlib | qt5-testlib-5.11.2 >> wrkdir to: >> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailCortexA57-default/default/qt5-testlib-5.11.2.tar >> [07:31:32] [10] [06:42:02] Finished devel/qt5-testlib | qt5-testlib-5.11.2: >> Failed: configure/runaway >> >> With logs/errors/qt5-testlib-5.11.2.log showing: >> >> Checking for POSIX monotonic clock... >> + cd >> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >> && >> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake >> "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared >> warn_off console single_arch" >> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >> + cd >> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >> && MAKEFLAGS= make >> =>> Killing runaway build after 21600 seconds with no output >> =>> Cleaning up wrkdir >> ===> Cleaning for qt5-testlib-5.11.2 >> Killed >> build of devel/qt5-testlib | qt5-testlib-5.11.2 ended at Wed Dec 19 06:45:42 >> PST 2018 >> build time: 06:41:46 >> !!! build failure encountered !!! >> >> >> # less >> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.log >> . . . >> test config.qtbase_corelib.libraries.librt succeeded >> executing config test clock-monotonic >> + cd >> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >> && >> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake >> "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared >> warn_off console single_arch" >> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >> + cd >> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >> && MAKEFLAGS= make >> >> >> Some supporting details of context: >> >> # uname -apKU >> FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r341836M: Tue Dec 11 >> 16:37:42 PST 2018 >> markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG >> amd64 amd64 135 135 >> >> # svnlite info /usr/ports/ | grep "Re[plv]" >> Relative URL: ^/head >> Repository Root: svn://svn.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 484783 >> Last Changed Rev: 484783 >> > > I started poudriere up again with just the 2 needing to be rebuilt (plus > what depends on the 2). devel/qt5-testlib quickly completed just fine: > > [00:02:16] [02] [00:00:00] Building devel/qt5-testlib | qt5-testlib-5.11.2 > [00:04:54] [02] [00:02:38] Finished devel/qt5-testlib | qt5-testlib-5.11.2: > Success > > > In the prior build that had the hang-ups I looked and dor print/texinfo : > > /wrkdirs/usr/ports/print/texin
Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"
[Looks like a race or some such for devel/qt5-testlib: retry of poudreire-devel did not hang. The other hang-up seems to be repeating and I give some details.] On 2018-Dec-19, at 12:20, Mark Millard wrote: > FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . > This > was a rebuild based on going from perl5.26 to perl5.28 without updating the > ports > tree and from system clang 6 for the prior FreeBSD-head context used to clang > 7 > this time. (I'm not attributing causes here.) poudriere was using amd64-native > tools for speeding up the cross-build. > > # grep -r =perl5= /etc/ ~/src.configs/ /usr/local/etc/ > /etc/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 > /usr/local/etc/poudriere.d/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 > > There was also a "print/texinfo:configure/runaway" but I've not looked into > it at all yet and it may be a while before I do. The other ports attempted > built fine as far as I can tell so far. > > > The devel/qt5-testlib failure looks like: > > [00:00:13] Building 123 packages using 28 builders > . . . > [00:49:30] [10] [00:00:00] Building devel/qt5-testlib | qt5-testlib-5.11.2 > . . . > [07:31:31] [10] [06:42:01] Saved devel/qt5-testlib | qt5-testlib-5.11.2 > wrkdir to: > /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailCortexA57-default/default/qt5-testlib-5.11.2.tar > [07:31:32] [10] [06:42:02] Finished devel/qt5-testlib | qt5-testlib-5.11.2: > Failed: configure/runaway > > With logs/errors/qt5-testlib-5.11.2.log showing: > > Checking for POSIX monotonic clock... > + cd > /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic > && > /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake > "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared > warn_off console single_arch" > /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic > + cd > /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic > && MAKEFLAGS= make > =>> Killing runaway build after 21600 seconds with no output > =>> Cleaning up wrkdir > ===> Cleaning for qt5-testlib-5.11.2 > Killed > build of devel/qt5-testlib | qt5-testlib-5.11.2 ended at Wed Dec 19 06:45:42 > PST 2018 > build time: 06:41:46 > !!! build failure encountered !!! > > > # less > /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.log > . . . > test config.qtbase_corelib.libraries.librt succeeded > executing config test clock-monotonic > + cd > /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic > && > /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake > "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared > warn_off console single_arch" > /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic > + cd > /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic > && MAKEFLAGS= make > > > Some supporting details of context: > > # uname -apKU > FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r341836M: Tue Dec 11 > 16:37:42 PST 2018 > markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG > amd64 amd64 135 135 > > # svnlite info /usr/ports/ | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 484783 > Last Changed Rev: 484783 > I started poudriere up again with just the 2 needing to be rebuilt (plus what depends on the 2). devel/qt5-testlib quickly completed just fine: [00:02:16] [02] [00:00:00] Building devel/qt5-testlib | qt5-testlib-5.11.2 [00:04:54] [02] [00:02:38] Finished devel/qt5-testlib | qt5-testlib-5.11.2: Success In the prior build that had the hang-ups I looked and dor print/texinfo : /wrkdirs/usr/ports/print/texinfo/work/texinfo-6.5/config.log shows for its hang-up: . . . configure:6639: checking for alloca configure:6676: /nxb-bin/usr/bin/cc -o conftest -O2 -pipe -mcpu=cortex-a57 -DLIBICONV_PLUG -g -fno-strict-aliasing -mcpu=cortex-a57 -DLIBICONV_PLUG -D_THREAD_SAFE conftest.c >&5 configure:6676: $? = 0 configure:6684: result: yes configure:6794: checking for C/C++ restrict keyword configure:6821: /nxb-bin/usr/bin/cc -c -O2 -pipe -mcpu=cortex-a57 -DLIBICONV_PLUG -g -fno-strict-aliasing -mcpu=cortex-a57 -DLIBICONV_PLUG -D_THREAD_SAFE conftest.c >&
FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"
FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . This was a rebuild based on going from perl5.26 to perl5.28 without updating the ports tree and from system clang 6 for the prior FreeBSD-head context used to clang 7 this time. (I'm not attributing causes here.) poudriere was using amd64-native tools for speeding up the cross-build. # grep -r =perl5= /etc/ ~/src.configs/ /usr/local/etc/ /etc/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 /usr/local/etc/poudriere.d/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 There was also a "print/texinfo:configure/runaway" but I've not looked into it at all yet and it may be a while before I do. The other ports attempted built fine as far as I can tell so far. The devel/qt5-testlib failure looks like: [00:00:13] Building 123 packages using 28 builders . . . [00:49:30] [10] [00:00:00] Building devel/qt5-testlib | qt5-testlib-5.11.2 . . . [07:31:31] [10] [06:42:01] Saved devel/qt5-testlib | qt5-testlib-5.11.2 wrkdir to: /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailCortexA57-default/default/qt5-testlib-5.11.2.tar [07:31:32] [10] [06:42:02] Finished devel/qt5-testlib | qt5-testlib-5.11.2: Failed: configure/runaway With logs/errors/qt5-testlib-5.11.2.log showing: Checking for POSIX monotonic clock... + cd /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic && /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic + cd /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic && MAKEFLAGS= make =>> Killing runaway build after 21600 seconds with no output =>> Cleaning up wrkdir ===> Cleaning for qt5-testlib-5.11.2 Killed build of devel/qt5-testlib | qt5-testlib-5.11.2 ended at Wed Dec 19 06:45:42 PST 2018 build time: 06:41:46 !!! build failure encountered !!! # less /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.log . . . test config.qtbase_corelib.libraries.librt succeeded executing config test clock-monotonic + cd /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic && /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic + cd /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic && MAKEFLAGS= make Some supporting details of context: # uname -apKU FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r341836M: Tue Dec 11 16:37:42 PST 2018 markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 135 135 # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 484783 Last Changed Rev: 484783 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
amd64 head -r317015 system clang 4.0 crashes during qt5-widgets "checking" activity: "Wrong prefetch hint in intrinsic: should be 0 or 1" (avx512.cpp)
[ports -r438577 with devel/*binutils reverted to 2.27 via -r436731 .] The qr5-widgets build attempt reported: checking for avx512cd... clang++ -c -pipe -O2 -g -fstack-protector -fno-strict-aliasing -mavx512cd -g -Wall -W -fPIC -DAVX512WANT=CD -I. -I/usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o avx512.o avx512.cpp clang++ -o avx512 avx512.o -L/usr/local/lib avx512cd enabled. checking for avx512pf... clang++ -c -pipe -O2 -g -fstack-protector -fno-strict-aliasing -mavx512pf -g -Wall -W -fPIC -DAVX512WANT=PF -I. -I/usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o avx512.o avx512.cpp Assertion failed: (HintVal < 2 && "Wrong prefetch hint in intrinsic: should be 0 or 1"), function LowerINTRINSIC_W_CHAIN, file /usr/src/contrib/llvm/lib/Target/X86/X86ISelLowering.cpp, line 19956. clang++: ESC[0;1;31merror: ESC[0munable to execute command: Abort trap (core dumped)ESC[0m clang++: ESC[0;1;31merror: ESC[0mclang frontend command failed due to signal (use -v to see invocation)ESC[0m FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin clang++: ESC[0;1;30mnote: ESC[0mdiagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.ESC[0m clang++: ESC[0;1;30mnote: ESC[0mdiagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at:ESC[0m clang++: ESC[0;1;30mnote: ESC[0mdiagnostic msg: /tmp/avx512-258133.cppESC[0m clang++: ESC[0;1;30mnote: ESC[0mdiagnostic msg: /tmp/avx512-258133.shESC[0m clang++: ESC[0;1;30mnote: ESC[0mdiagnostic msg: ESC[0m *** Error code 254 Stop. make[2]: stopped in /usr/obj/portswork/usr/ports/x11-toolkits/qt5-widgets/work/qtbase-opensource-src-5.7.1/config.tests/common/avx512 # more /tmp/avx512-258133.sh # Crash reproducer for FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) # Driver args: "--driver-mode=g++" "-c" "-pipe" "-O2" "-g" "-fstack-protector" "-fno-strict-aliasing" "-mavx512pf" "-g" "-Wall" "-W" "-fPIC" "-D" "AVX512WANT=PF" "-I" "." "-I" "/usr/local/include" "-I" "/usr/local/lib/qt5/mkspecs/freebsd-clang" "-o" "avx512.o" "avx512.cpp" # Original command: "/usr/bin/clang++" "-cc1" "-triple" "x86_64-unknown-freebsd12.0" "-emit-obj" "-disable-free" "-main-file-name" "avx512.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-relaxed-aliasing" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-target-feature" "+avx512pf" "-dwarf-column-info" "-debug-info-kind=standalone" "-dwarf-version=2" "-debugger-tuning=gdb" "-coverage-notes-file" "/usr/obj/portswork/usr/ports/x11-toolkits/qt5-widgets/work/qtbase-opensource-src-5.7.1/config.tests/common/avx512/avx512.gcno" "-resource-dir" "/usr/bin/../lib/clang/4.0.0" "-D" "AVX512WANT=PF" "-I" "." "-I" "/usr/local/include" "-I" "/usr/local/lib/qt5/mkspecs/freebsd-clang" "-internal-isystem" "/usr/include/c++/v1" "-O2" "-Wall" "-W" "-fdeprecated-macro" "-fdebug-compilation-dir" "/usr/obj/portswork/usr/ports/x11-toolkits/qt5-widgets/work/qtbase-opensource-src-5.7.1/config.tests/common/avx512" "-ferror-limit" "19" "-fmessage-length" "80" "-stack-protector" "1" "-fobjc-runtime=gnustep" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops" "-vectorize-slp" "-o" "avx512.o" "-x" "c++" "avx512.cpp" "/usr/bin/clang++" "-cc1" "-triple" "x86_64-unknown-freebsd12.0" "-emit-obj" "-disable-free" "-main-file-name" "avx512.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-relaxed-aliasing" "-masm-verbose" &quo
Re: WTF mergemaster VCS Id checking?
On Mon, 16 Jan 2012, deeptec...@gmail.com wrote: Every time I run mergemaster, I have to manually confirm all of the What is your timescale for every time? One year? Five years? local changes I have done to /etc (ie., state how to merge the temporary and existing files), even files have not changed in the upstream since the last mergemaster run (for example, temproot/etc/master.passwd virtually never changes). This behaviour is annoying, but I've already gotten used to it, and thought that it's the preferred one, to force a system administrator to review, periodically, all changes in /etc. I was surprized that today, mergemaster did not mention one of my changes in /etc: *** Temp ./etc/rc.d/bgfsck and installed have the same CVS Id, deleting So it now seems that it actually is intended for mergemaster to mention only files that have changed in the upstream since the last mergemaster run, but that funtionality fails. Apparently, some That is correct up to a point. Now that the main src repository is stored in subversion, a svn2cvs exporter is used to populate a cloned CVS tree which is then used for csup and friends. However, the svn2cvs exporter deals poorly with branches and causes version number churn on many files. upstream files have the following VCS Id: # $FreeBSD$ and that anulls version checking. Recently, a lot of files in /etc (ie., rc.d files) have received full VCS Id strings, but not all. Someone ought to touch files in the subversion repository? Perhaps, but it's not entirely clear. Have you considered the -F or -U options to mergemaster? If I remember correctly, -F was added precisely because of this issue you are encountering. So in either way you look at it, something is WRONG(TM). BTW, off-topic: 1. mergemaster outputs CVS Id, while mergemaster's manpage contains VCS Id. One of these is WRONG(TM). Which one? Oh, probably the output, but I'm not authoritative. 2. mergemaster outputs Use 'i' to install merged file. TODO: add a the. Constructions of this form are quite common in technical writing, though I would not object to the addition of the 'the'. 3. The BUGS section of mergemaster's manpage is redundant. Maybe, but sometimes it's worth explicitly mentioning things which should go without saying. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WTF mergemaster VCS Id checking?
On 01/15/2012 23:31, deeptec...@gmail.com wrote: Apparently, some upstream files have the following VCS Id: # $FreeBSD$ and that anulls version checking. Your src tree is not checked out properly. This usually happens because at some point in the subversion 1.6 days you used devel/subversion to check it out, rather than devel/subversion-freebsd. Fortunately, the new version of devel/subversion has the option to include the FreeBSD-specific bits, enabled by default. So, to fix this problem: 1. 'svn diff' your src tree, save any local patches. 2. rm -rf /usr/src 3. Upgrade devel/subversion, make sure that the first 3 options are enabled. 4. Check out the new src tree, re-apply any local patches 5. Run mergemaster again. Make sure to merge the new $FreeBSD Ids. BTW, off-topic: 1. mergemaster outputs CVS Id, while mergemaster's manpage contains VCS Id. One of these is WRONG(TM). Which one? The 'CVS Id' is a remnant of the pre-svn days. I haven't changed it in case someone has a script that parses the output. 2. mergemaster outputs Use 'i' to install merged file. TODO: add a the. Maybe. It's lasted as long as it has without anyone getting confused. 3. The BUGS section of mergemaster's manpage is redundant. So don't read it. :) Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
WTF mergemaster VCS Id checking?
Every time I run mergemaster, I have to manually confirm all of the local changes I have done to /etc (ie., state how to merge the temporary and existing files), even files have not changed in the upstream since the last mergemaster run (for example, temproot/etc/master.passwd virtually never changes). This behaviour is annoying, but I've already gotten used to it, and thought that it's the preferred one, to force a system administrator to review, periodically, all changes in /etc. I was surprized that today, mergemaster did not mention one of my changes in /etc: *** Temp ./etc/rc.d/bgfsck and installed have the same CVS Id, deleting So it now seems that it actually is intended for mergemaster to mention only files that have changed in the upstream since the last mergemaster run, but that funtionality fails. Apparently, some upstream files have the following VCS Id: # $FreeBSD$ and that anulls version checking. Recently, a lot of files in /etc (ie., rc.d files) have received full VCS Id strings, but not all. Someone ought to touch files in the subversion repository? So in either way you look at it, something is WRONG(TM). BTW, off-topic: 1. mergemaster outputs CVS Id, while mergemaster's manpage contains VCS Id. One of these is WRONG(TM). Which one? 2. mergemaster outputs Use 'i' to install merged file. TODO: add a the. 3. The BUGS section of mergemaster's manpage is redundant. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gmultipath: act/act, path checking?
On 26.10.2011 12:09, Dennis Koegel wrote: are there any plans to have gmultipath support for active/active? Few days ago I've started from fixing some issues in gmultipath and already rewritten half of it while trying to make it usable. I expect to have something to present in a week or two. It will also include active/active mode support there, as at my present point required changes are minimal. -- Alexander Motin. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gmultipath: act/act, path checking?
On 10/28/2011 12:37 PM, Alexander Motin wrote: On 26.10.2011 12:09, Dennis Koegel wrote: are there any plans to have gmultipath support for active/active? Few days ago I've started from fixing some issues in gmultipath and already rewritten half of it while trying to make it usable. I expect to have something to present in a week or two. It will also include active/active mode support there, as at my present point required changes are minimal. Free at last! Free at last! Free at last! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
gmultipath: act/act, path checking?
Cheers, are there any plans to have gmultipath support for active/active? Also, is there any way to check available paths periodically? As far as I unterstand, once gmultipath kicks a certain path due to failure, it will never come back automatically. (And it won't ever be used if it isn't working at boot time) I've found some discussion about this from 2008, but nothing since... Thanks, - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gmultipath: act/act, path checking?
On 10/26/2011 2:09 AM, Dennis Koegel wrote: Cheers, are there any plans to have gmultipath support for active/active? I was given patches but have lacked motivation to do it. Also, is there any way to check available paths periodically? As far as I unterstand, once gmultipath kicks a certain path due to failure, it will never come back automatically. (And it won't ever be used if it isn't working at boot time) That is something that should have been fixed. I might be confused with the changes I did for Panasas that didn't make it back here, but I certainly had a rolling test where I ran for several days periodically failing one path and then then the other. I've found some discussion about this from 2008, but nothing since... Thanks, - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gmultipath: act/act, path checking?
Hi. On 26.10.2011 12:09, Dennis Koegel wrote: are there any plans to have gmultipath support for active/active? Also, is there any way to check available paths periodically? As far as I unterstand, once gmultipath kicks a certain path due to failure, it will never come back automatically. (And it won't ever be used if it isn't working at boot time) I haven't tested it, but if gmultipath behaves same as other GEOM classes with on-disk metadata, new paths should be connected automatically when detected. Boot time in GEOM is not different from later operation. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
freebsd-update not checking disk space?
Hi, I tried to upgrade a server at work from 8.2-RELEASE-i386 to 9.0-RC1-i386 using freebsd-update.When running 'freebsd-update install' to install the new kernel, but that failed because there was insufficient disk space. This resulted in freebsd-update thinking everything is ok but left the kernel unbootable. From the screen capture: 10G# freebsd-update install Installing updates... /: write failed, filesystem is full install: ///boot/kernel/INS@SmmC: No space left on device install: ///boot/kernel/INS@lMJN: No space left on device install: ///boot/kernel/INS@ez1L: No space left on device install: ///boot/kernel/INS@D78d: No space left on device [... more patch files ..] install: ///boot/kernel/ng_bt3c.ko.symbols: No space left on device install: ///boot/kernel/ng_btsocket.ko: No space left on device [.. more destination files ..] These two types of messages are interleaved. It ends with: install: ///boot/INS@yqYd: No space left on device rmdir: ///boot/kernel: Directory not empty Kernel updates have been installed. Please reboot and run /usr/sbin/freebsd-update install again to finish installing updates. 10G# df Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ad0s1a507630 502860-35840 108%/ So in reality the update never finished properly. More logs on request. Regards, René -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update not checking disk space?
On 10/25/11 00:52, René Ladan wrote: I tried to upgrade a server at work from 8.2-RELEASE-i386 to 9.0-RC1-i386 using freebsd-update.When running 'freebsd-update install' to install the new kernel, but that failed because there was insufficient disk space. This resulted in freebsd-update thinking everything is ok but left the kernel unbootable. Yes, this is a known issue in freebsd-update -- it needs to be much smarter about detecting and handling errors. Unfortunately I haven't had time to deal with this (and it's a lot of work). -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: device name checking on device registration
On 2010-10-12, Andriy Gapon wrote: on 12/10/2010 16:36 Matthew Jacob said the following: Good workaround, still a nasty surprising bug. Yeah. I also would prefer ignoring such a partition or somehow sanitizing its name or etc. panic(9) on bad internal state of a kernel sounds appropriate, panic(9) on bad input sounds like trouble. I am working on a change for GEOM. I will post a patch to -geom for comments shortly. I want just to note that previously bad names could cause erratic behavior (including panics) deep in devfs code instead of catching them early. -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: device name checking on device registration
On 2010-10-11, barbara wrote: The panic is caused by: g_dev_taste(): make_dev_p() failed (gp-name=ext2fs//, error=22) as I have a linux partition (I swear, it's for my mom!) on the same machine. As I don't care about that partition (being ext4 I can't even mount it), is there any solution other then applying the patch after every csup? If you don't need ext2fs labels you can put the following line to /boot/loader.conf as a workaround: kern.geom.label.ext2fs.enable=0 -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: device name checking on device registration
Good workaround, still a nasty surprising bug. On 2010-10-11, barbara wrote: The panic is caused by: g_dev_taste(): make_dev_p() failed (gp-name=ext2fs//, error=22) as I have a linux partition (I swear, it's for my mom!) on the same machine. As I don't care about that partition (being ext4 I can't even mount it), is there any solution other then applying the patch after every csup? If you don't need ext2fs labels you can put the following line to /boot/loader.conf as a workaround: kern.geom.label.ext2fs.enable=0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: device name checking on device registration
on 12/10/2010 16:36 Matthew Jacob said the following: Good workaround, still a nasty surprising bug. Yeah. I also would prefer ignoring such a partition or somehow sanitizing its name or etc. panic(9) on bad internal state of a kernel sounds appropriate, panic(9) on bad input sounds like trouble. P.S. Matthew, it seems like you have a really unhelpful mail client program: first, it top-posts :-) second, it doesn't always attribute quoted text. It also doesn't cc in replies the addresses that were in to or cc of original message, which may or may not be a good thing. On 2010-10-11, barbara wrote: The panic is caused by: g_dev_taste(): make_dev_p() failed (gp-name=ext2fs//, error=22) as I have a linux partition (I swear, it's for my mom!) on the same machine. As I don't care about that partition (being ext4 I can't even mount it), is there any solution other then applying the patch after every csup? If you don't need ext2fs labels you can put the following line to /boot/loader.conf as a workaround: kern.geom.label.ext2fs.enable=0 -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: device name checking on device registration
I am antisocial. Okay, changed it so my replies are above the quotes. Seems to have attributes here. And I usually hit 'reply list' since multiple copies burns bandwidth. On 10/12/2010 1:57 PM, Andriy Gapon wrote: P.S. Matthew, it seems like you have a really unhelpful mail client program: first, it top-posts :-) second, it doesn't always attribute quoted text. It also doesn't cc in replies the addresses that were in to or cc of original message, which may or may not be a good thing. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re:HEADS UP: device name checking on device registration
Since r213526 device names are checked on device registration. That is, if you call a make_dev*() function with an invalid device name, a panic will occur by default. For make_dev_credf(9) or make_dev_p(9) you can specify the MAKEDEV_CHECKNAME flag to get an error return instead of a panic. Invalid names are as follows: - empty name - names longer than SPECNAMELEN - names containing . or .. path component - names ending with '/' - already existing device names So, if you see a bad si_name panic you may have encountered a driver bug. Currently several GEOM classes (notably geom_label) allow to create devices with invalid names. Below is a link to a patch which converts g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not a complete solution and essentially changes the panic to a printf. http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff -- Jaakko Hi, I faced that kind of panic today and now I'm able to boot again into CURRENT after applying the patch and rebuilding kernel. The panic is caused by: g_dev_taste(): make_dev_p() failed (gp-name=ext2fs//, error=22) as I have a linux partition (I swear, it's for my mom!) on the same machine. As I don't care about that partition (being ext4 I can't even mount it), is there any solution other then applying the patch after every csup? Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HEADS UP: device name checking on device registration
Since r213526 device names are checked on device registration. That is, if you call a make_dev*() function with an invalid device name, a panic will occur by default. For make_dev_credf(9) or make_dev_p(9) you can specify the MAKEDEV_CHECKNAME flag to get an error return instead of a panic. Invalid names are as follows: - empty name - names longer than SPECNAMELEN - names containing . or .. path component - names ending with '/' - already existing device names So, if you see a bad si_name panic you may have encountered a driver bug. Currently several GEOM classes (notably geom_label) allow to create devices with invalid names. Below is a link to a patch which converts g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not a complete solution and essentially changes the panic to a printf. http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: checking stopevent 2!
On Sat, 15 Nov 2003, Andy Farkas wrote:
These messages spew onto my console and into syslogd once every second:
Heh. Sounds like your box is having a really bad day, we'll see if we
can't get it fixed up over the next couple of weeks as things settle out
:-).
I think John has this one in his sights already, we talked about the
sigacts locking during the release engineering telecon yesterday (CC'd
gratuitously in this message). Basically, every place where a debugger
can stop a process there's a call to STOPEVENT(), which may sleep
indefinitely waiting to be restarted by the process performing the
debugging. The problem appears to be that recent changes pushed a
STOPEVENT() call inside code holding a mutex, so the locking of that piece
of code needs to be changed slightly to make sure that doesn't happen. IT
would probably be useful if you could drop to DDB and generate a trace for
the event.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
...
Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/kern_synch.c:293
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
...
This is latest -current (cvsup'd a few hours ago)
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: checking stopevent 2!
On Sat, Nov 15, 2003 at 09:38:37AM -0500, Robert Watson wrote:
On Sat, 15 Nov 2003, Andy Farkas wrote:
would probably be useful if you could drop to DDB and generate a trace for
the event.
I've done that, in this email message:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2157067+0+current/freebsd-current
...
Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/kern_synch.c:293
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
...
This is latest -current (cvsup'd a few hours ago)
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Cosmin Stroe
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: checking stopevent 2!
On Sat, Nov 15, 2003 at 09:38:37AM -0500, Robert Watson wrote: On Sat, 15 Nov 2003, Andy Farkas wrote: These messages spew onto my console and into syslogd once every second: I'm seeing the same on a recently upgraded dual cpu machine. Also when I run the reboot command the errors get mixed on the console as if the process writing to the console wasn't locking the device. A verbose dmesg can be found at http://xbsd.net/~esbjerg/enzo.verb.dmesg and a kernel conf http://xbsd.net/~esbjerg/ENZO I might add that the recent changes has totally hosed the USB support... regards Sven Esbjerg -- http://www.usenet.dk/netikette - på forhånd tak. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: checking stopevent 2!
On Sat, 15 Nov 2003, Sven Esbjerg wrote: On Sat, Nov 15, 2003 at 09:38:37AM -0500, Robert Watson wrote: On Sat, 15 Nov 2003, Andy Farkas wrote: These messages spew onto my console and into syslogd once every second: I'm seeing the same on a recently upgraded dual cpu machine. Also when I run the reboot command the errors get mixed on the console as if the process writing to the console wasn't locking the device. A verbose dmesg can be found at http://xbsd.net/~esbjerg/enzo.verb.dmesg and a kernel conf http://xbsd.net/~esbjerg/ENZO I might add that the recent changes has totally hosed the USB support... Could you be more specific about the USB problems? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: checking stopevent 2!
On 15 Nov, Robert Watson wrote: On Sat, 15 Nov 2003, Andy Farkas wrote: These messages spew onto my console and into syslogd once every second: Heh. Sounds like your box is having a really bad day, we'll see if we can't get it fixed up over the next couple of weeks as things settle out :-). Mine is worse. If I try to boot it multiuser, it pegs its serial console with these messages. It seems to bring up the network to the point where it can be pinged, but the ping latency averages about 200 ms, and even after a half an hour it still hadn't gotten sshd started. I can't drop back to the old kernel because I just did an installworld with the new version of statfs. I hope the fix isn't too extensive, since I'll probably be typing it in by hand in single user mode ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: checking stopevent 2!
In message: [EMAIL PROTECTED] Don Lewis [EMAIL PROTECTED] writes: : I hope the fix isn't too extensive, since I'll probably be typing it in : by hand in single user mode ... You could do what I did: remove the two lines that jhb added. You'll get no more warnings. Sure, the problems are still there, but jhb likely will fix them, at which time you'll be able to run stock proc.h again. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: checking stopevent 2!
On Sat, 15 Nov 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Don Lewis [EMAIL PROTECTED] writes: : I hope the fix isn't too extensive, since I'll probably be typing it in : by hand in single user mode ... You could do what I did: remove the two lines that jhb added. You'll get no more warnings. Sure, the problems are still there, but jhb likely will fix them, at which time you'll be able to run stock proc.h again. Maybe we should just go ahead and commit that change until John has a chance to merge the actual fix? I talked with him a bit about it on Friday, but I'm not sure whether he's working on it this weekend, or plans to address it on Monday. He may not have realized the problem was quite so debilitating as the problem apparently turns out to be... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: checking stopevent 2!
Robert Watson wrote:
On Sat, 15 Nov 2003, Andy Farkas wrote:
These messages spew onto my console and into syslogd once every second:
Heh. Sounds like your box is having a really bad day, we'll see if we
can't get it fixed up over the next couple of weeks as things settle out
:-).
As you've probably noticed, this problem is pretty wide-spread. A fix
better get in before 5.2-release please :)
I've managed to stop the message flooding by not running ntpd.
IT would probably be useful if you could drop to DDB and generate a
trace for the event.
Do you still want me to do this? I thought the messages themselves were
supposed to useful:
locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
locked @ /hummer/src-current/src/sys/kern/kern_synch.c:293
locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
# ident /hummer/src-current/src/sys/kern/kern_condvar.c
/hummer/src-current/src/sys/kern/kern_condvar.c:
$FreeBSD: src/sys/kern/kern_condvar.c,v 1.44 2003/11/09 09:17:24 tanimura Exp $
# ident /hummer/src-current/src/sys/kern/kern_synch.c
/hummer/src-current/src/sys/kern/kern_synch.c:
$FreeBSD: src/sys/kern/kern_synch.c,v 1.237 2003/10/29 15:23:09 bde Exp $
# ident /hummer/src-current/src/sys/kern/subr_trap.c
/hummer/src-current/src/sys/kern/subr_trap.c:
$FreeBSD: src/sys/kern/subr_trap.c,v 1.261 2003/09/05 22:15:26 peter Exp $
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
checking stopevent 2!
Help!
These messages spew onto my console and into syslogd once every second:
...
Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/kern_synch.c:293
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
...
This is latest -current (cvsup'd a few hours ago)
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Bug: nmount(2) lacks parameter checking.
Hi,
Looking over the code for nmount(), I think I noticed a few bugs.
(tried send-pr, but the lack of a web-front-end at freebsd.org,
and a decent mail system locally means that's not a runner)
nmount() calls vfs_nmount() pretty much directly after copying in
the io vector from userland.
vfs_nmount() then calls vfs_buildopts() as the first thing it does.
There's a couple of problems here. Firstly, there's no check up to
this point that the user passing the options in is indeed root. So,
all the bugs mentioned can be tickled by a non-root user.
vfs_buildopts doesn't ensure that the option's name is a null
terminated string, but, it later calls vfs_sanitizeopts(), which
assumes this. By passing in strings just at and just over the
pagesize, a non-root user can cause a crash in vfs_buildopts
reasonably reliably when strcmp to hit an unmappped page. (Program
available on request)
vfs_buildopts also leaks memory if it jumps to bad: anything in
the current option is lost to the woods.
There's also no checking on how much memory is actually aquired by
vfs_buildopts(): it can be passed up to MAX_IOVCOUNT (1024) elements
in the iovec, and each of these can be up to 64K in size. That's
64M of memory, plus some overhead for option structures, which would
be a lot to start chewing up in the kernel.
The source I based these observations on is from today, while my
kernel is a few weeks old, and I no longer have source for it.
Given the traffic on the list recently, I figure now is Not A Good
Time to install a fresh kernel, so the patch attached is tested to
the point that it compiles, but I think something like it is
required.
Index: kern/vfs_mount.c
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/kern/vfs_mount.c,v
retrieving revision 1.111
diff -u -r1.111 vfs_mount.c
--- kern/vfs_mount.c26 Sep 2003 09:07:27 - 1.111
+++ kern/vfs_mount.c4 Nov 2003 21:46:44 -
@@ -246,6 +246,8 @@
struct vfsopt *opt;
unsigned int i, iovcnt;
int error, namelen, optlen;
+ size_t memTotal = 0;
+ static const size_t maxMemTotal = 1024 * 64;
iovcnt = auio-uio_iovcnt;
opts = malloc(sizeof(struct vfsoptlist), M_MOUNT, M_WAITOK);
@@ -256,6 +258,26 @@
optlen = auio-uio_iov[i + 1].iov_len;
opt-name = malloc(namelen, M_MOUNT, M_WAITOK);
opt-value = NULL;
+ opt-len = optlen;
+
+ /*
+* Do this early, so jumps to bad will free the current
+* option
+*/
+ TAILQ_INSERT_TAIL(opts, opt, link);
+ memTotal += sizeof (struct vfsopt) + optlen + namelen;
+
+ /*
+* Avoid consuming too much memory, and attempts to overflow
+* memTotal
+*/
+ if (memTotal maxMemTotal ||
+ optlen maxMemTotal ||
+ namelen maxMemTotal) {
+ error = EINVAL;
+ goto bad;
+ }
+
if (auio-uio_segflg == UIO_SYSSPACE) {
bcopy(auio-uio_iov[i].iov_base, opt-name, namelen);
} else {
@@ -264,7 +286,11 @@
if (error)
goto bad;
}
- opt-len = optlen;
+ /* Ensure names are null-terminated strings */
+ if (opt-name[namelen - 1] != '\0') {
+ error = EINVAL;
+ goto bad;
+ }
if (optlen != 0) {
opt-value = malloc(optlen, M_MOUNT, M_WAITOK);
if (auio-uio_segflg == UIO_SYSSPACE) {
@@ -277,7 +303,6 @@
goto bad;
}
}
- TAILQ_INSERT_TAIL(opts, opt, link);
}
vfs_sanitizeopts(opts);
*options = opts;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Checking the status of ATA raids in periodic daily ?
Hi, Any objections if I commit the below diff, and add the attached file as src/etc/periodic/daily/405.status-ata_raid ? Index: defaults/periodic.conf === RCS file: /home/ncvs/src/etc/defaults/periodic.conf,v retrieving revision 1.25 diff -u -r1.25 periodic.conf --- defaults/periodic.conf 1 Apr 2003 17:45:27 - 1.25 +++ defaults/periodic.conf 25 Oct 2003 00:15:52 - @@ -85,6 +85,9 @@ daily_status_disks_enable=YES# Check disk status daily_status_disks_df_flags=-k -t nonfs # df(1) flags for check +# 405.status-ata_raid +status_ata_raid_enable=YES # Check ATA raid status + # 420.status-network daily_status_network_enable=YES # Check network status daily_status_network_usedns=YES # DNS lookups are ok Index: periodic/daily/Makefile === RCS file: /home/ncvs/src/etc/periodic/daily/Makefile,v retrieving revision 1.11 diff -u -r1.11 Makefile --- periodic/daily/Makefile 1 Apr 2003 20:32:01 - 1.11 +++ periodic/daily/Makefile 25 Oct 2003 00:15:52 - @@ -12,6 +12,7 @@ 310.accounting \ 330.news \ 400.status-disks \ + 405.status-ata_raid \ 420.status-network \ 430.status-rwho \ 440.status-mailq \ /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. #!/bin/sh # # $FreeBSD: $ # # If there is a global system configuration file, suck it in. # if [ -r /etc/defaults/periodic.conf ] then . /etc/defaults/periodic.conf source_periodic_confs fi case $daily_status_ata_raid_enable in [Yy][Ee][Ss]) echo echo 'Checking status of ATA raid partitions:' rc=0 for raid in `/usr/bin/find /dev/ -name 'ar[0-9]*' -type c \ | /usr/bin/egrep '[0-9]$' | /usr/bin/egrep -v 's[0-9]' \ | cut -d / -f 3` do status=`/sbin/atacontrol status $raid` echo $status raid_rc=`echo $status | grep -v READY | wc -l` [ $rc -eq 0 ] [ $raid_rc -gt 0 ] rc=3 done ;; *) rc=0;; esac exit $rc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
On Mon, Aug 04, 2003 at 10:45:39PM -0700, Stephen Casner wrote: I tried what I thought might be the equivalent patch (eliminating an else clause), but it did not solve the problem. In 4.8-RELEASE I sometimes get a system hang and sometimes not, but even when it does not hang, I just get Device not configured when I try to mount /dev/acd0c. The output I get is: /kernel: pccard: card inserted, slot 0 pccardd[49]: Card (NinjaATA-) [V1.0] [AP00 ] matched (NinjaATA-) [(null)] [(null)] /kernel: ata2 at port 0x180-0x187,0x386 iomem 0xd4000-0xd4fff irq 9 slot 0 on pccard0 pccardd[49]: ata2: NinjaATA inserted. I saw similar behaviour with STABLE when trying to use a CompactFlash card on a CPU board that didn't support the default range of I/O ports. This might not be the case you have, but I saw output just like that quoted above. The ata device gets reported, but there is no 'ad' device following it like there normally is. In my case the solution was to use the I/O port range hidden in the manufacturer's notes on their web site. Once I set the port range in /etc/pccard.conf to override the default, the CompactFlash card worked fine. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
On Tue, 5 Aug 2003, John Birrell wrote: On Mon, Aug 04, 2003 at 10:45:39PM -0700, Stephen Casner wrote: I tried what I thought might be the equivalent patch (eliminating an else clause), but it did not solve the problem. In 4.8-RELEASE I sometimes get a system hang and sometimes not, but even when it does not hang, I just get Device not configured when I try to mount /dev/acd0c. The output I get is: /kernel: pccard: card inserted, slot 0 pccardd[49]: Card (NinjaATA-) [V1.0] [AP00 ] matched (NinjaATA-) [(null)] [(null)] /kernel: ata2 at port 0x180-0x187,0x386 iomem 0xd4000-0xd4fff irq 9 slot 0 on pccard0 pccardd[49]: ata2: NinjaATA inserted. I saw similar behaviour with STABLE when trying to use a CompactFlash card on a CPU board that didn't support the default range of I/O ports. This might not be the case you have, but I saw output just like that quoted above. The ata device gets reported, but there is no 'ad' device following it like there normally is. In my case the solution was to use the I/O port range hidden in the manufacturer's notes on their web site. Once I set the port range in /etc/pccard.conf to override the default, the CompactFlash card worked fine. I had an opportunity to try the same CD-ROM drive on an identical laptop that had a 4.2-STABLE system installed. The drive works on that version, and the console output is the same as what I quoted above for 4.8. That is, the same default port space is used. The only difference is another line follows for the acd0 device coming up. So, it looks like your solution for the CompactFlash card does not apply. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
password strength checking not consistently implemented
I have set up the password strength checking system using pam_passwdqc.so, set in /etc/pam.d/passwd. I have also set up password expiration. When a user issues the 'passwd' command, the password strength checking module works as expected. When a user logs in via the console after the password expiry time has passed, the login program prompts for a new password before the session begins. However, this password change has no strength check at all. Is there some other change I need to make to may pam configuration? Thanks. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
My question is really about -STABLE rather than -CURRENT, but it involves a problem recently resolved in -CURRENT. On Thu, 26 Jun 2003, Bill Paul started this thread regarding failed support for the Sony PCMCIA CD-ROM drive (NinjaATA-) in releases since 4.5, including 4.8 and 5.1. You folks resolved a patch for ata-card.c that was applied in -CURRENT. Can some equivalent patch be made for -STABLE? I tried what I thought might be the equivalent patch (eliminating an else clause), but it did not solve the problem. In 4.8-RELEASE I sometimes get a system hang and sometimes not, but even when it does not hang, I just get Device not configured when I try to mount /dev/acd0c. The output I get is: /kernel: pccard: card inserted, slot 0 pccardd[49]: Card (NinjaATA-) [V1.0] [AP00 ] matched (NinjaATA-) [(null)] [(null)] /kernel: ata2 at port 0x180-0x187,0x386 iomem 0xd4000-0xd4fff irq 9 slot 0 on pccard0 pccardd[49]: ata2: NinjaATA inserted. I don't get anything like Bill Paul's success case: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 acd0: CDROM CD-224E at ata2-master PIO4 But I don't know what I should expect to see on success in -STABLE vs. this message from -CURRENT. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Checking buildworld success from ssh
Hi all, I started a buildworld on current sources this morning, but, foolishly, didn't redirect the output to a file. Now I have some free time at work and would like to ssh in and do the kernel and mergemaster. Of course, I don't want to do these things if buildworld failed. Is there any way I can tell in the absence of saved output? Thanks. Greg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Checking buildworld success from ssh
On Mon, Jul 28, 2003 at 09:28:07AM -0400, Gregory Pavelcak wrote: Hi all, I started a buildworld on current sources this morning, but, foolishly, didn't redirect the output to a file. Now I have some free time at work and would like to ssh in and do the kernel and mergemaster. Of course, I don't want to do these things if buildworld failed. Is there any way I can tell in the absence of saved output? The last thing made is creation of the freebsd.cf file. See if it was created in /usr/obj/usr/src/etc/sendmail. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Checking buildworld success from ssh
Hi, you could restart the buildworld with the -DNOCLEAN option, this would terminate much faster than usual o r show up where it fails.. Hope this helps. Regards Henry Am Montag, 28.07.03, um 15:28 Uhr (Europe/Berlin) schrieb Gregory Pavelcak: Hi all, I started a buildworld on current sources this morning, but, foolishly, didn't redirect the output to a file. Now I have some free time at work and would like to ssh in and do the kernel and mergemaster. Of course, I don't want to do these things if buildworld failed. Is there any way I can tell in the absence of saved output? ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
It seems Bill Paul wrote:
In message [EMAIL PROTECTED], M. Warner Losh writes:
Here's a better patch, basesd on wpaul's input. Bill, can you try it
an see if it works for you? If so, i would be better to commit this
one. If not, I'll work with you to fix it.
FYI, I have a no-name (PCMCIA/CD-ROM) drive that also requires
failure of the second IO range to be made non-fatal. How about just
deleting the `else' clause as in the patch below? It seems that
this can only affect CD-ROM drives that were otherwise not working,
so it should be fairly safe.
This patch also tests good with my drive.
Thats what I proposed on the unnamed IRC channel yesterday, its fine by
me as well, can we agree to commit just this then ?
Index: ata-card.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/ata/ata-card.c,v
retrieving revision 1.14
diff -u -r1.14 ata-card.c
--- ata-card.c 17 Jun 2003 12:33:53 - 1.14
+++ ata-card.c 26 Jun 2003 23:00:01 -
@@ -131,10 +131,6 @@
start + ATA_ALTOFFSET, ATA_ALTIOSIZE);
}
}
-else {
- bus_release_resource(dev, SYS_RES_IOPORT, rid, io);
- return ENXIO;
-}
/* allocate the altport range */
rid = ATA_ALTADDR_RID;
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
Soeren Schmidt wrote: I do have problems with the wording you use in the comments in that patch mentioned below, I will even say that I will remove that as soon as it appears *and* shoot the committer so it doesn't happen again to use your choice of wording.. While you are making those changes, be sure to change ENXIO to EDOOFUS... 8-) 8-). Lighten up! Have a beer or something! Bill's comments are often irascible, and the license wording in his slight modification to the BSD license boilerplate gave the IBM lawers fits, but he's not the only one who does this sort of thing to the sources, and he's not even the worst offender. Personally, Bill's comments have kept me from making mistakes in the purchase of hardware in the past, even if they were a bit biting... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Heads up: checking in change to ata-card.c
A long time ago, circa FreeBSD 4.3, my Sony PCMCIA CD-ROM drive with brain-damaged Teac ATA controller drive worked, and the people were content and all was right with the land. Then my 4.4 CD set arrived, and I was disappointed to find the install kernel would lock up after the driver was probed. Complaints were made and epithets were hurled, and lo, in 4.5-RELEASE, all was well once again. Then came 4.6-RELEASE, and it was broken again. Then came 4.6.2, and it was still broken. And in 4.7. And 4.8. And 5.0. (Yeah yeah, shut up.) I just got my 5.1-RELEASE CDs and guess what? My CD-ROM drive STILL doesn't work!!! Guys, there's nothing more frustrating than getting a brand new CD set in the mail and not being able to install via CD. So I'm not leaving it up to chance anymore. I have a patch to make my drive work here: http://www.freebsd.org/~wpaul/ata-card.c.diff-5.1 I have no idea what the altio port remapping goop in ata_pccard_probe() is supposed to accomplish, but I'm telling you all right now, it doesn't work with my drive. I have specifically added to code to skip the remapping for drives with the product string of NinjaATA- (the problem with the Teac controller is that its vendor/product ID is 0x/0x, so there's really no better way to indentify it). This patch changes this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 device_probe_and_attach: ata2 attach returned 6 Into this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 acd0: CDROM CD-224E at ata2-master PIO4 Now, I'm sending out this notification that I _WILL_ check this patch in before I leave the office today. I'm not asking for permission. I've been waiting for half a dozen releases for this to get fixed. When 5.2-RELEASE arrives in my mailbox, it _WILL_ install from CD-ROM on my laptop or so help me I will find the responsible parties and force them to listen to RMS sing Free The Software -- _live_ -- until their ears bleed. I have tested this patch. It compiles. It works. I can mount CDs successfully and transfer stuff from them to my heart's content. I've reduced the change down to the absolute minimum and insured that it won't affect any other drives except mine. It's going in. Period. I am not leaving it up for debate, because if I do, all that will happen is that people will argue over what the more correct fix should be, and at this point I _just_ _don't_ _care_. I want my drive to work, and this does it. Understand? Good. This concludes my announcement. Thank you all for your attention. Don't forget to tip the waitress. -Bill P.S.: Be sure to join us next time when I ream out whoever it was that broke support for my 3Com 3c575C cardbus ethernet NIC. -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
Lose the attitude in the patch and email. otherwise it looks good. I'd rather that we had a table rather than doing the string coparison, but I can fix that after your commit. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
I do have problems with the wording you use in the comments in that patch mentioned below, I will even say that I will remove that as soon as it appears *and* shoot the committer so it doesn't happen again to use your choice of wording.. Now, I dont think this way is productive at all, and would appreciate if we could have a civilized way of doing this instead... This is exactly the crap that makes one wonder if the time used on the project is well spent... -Søren It seems Bill Paul wrote: A long time ago, circa FreeBSD 4.3, my Sony PCMCIA CD-ROM drive with brain-damaged Teac ATA controller drive worked, and the people were content and all was right with the land. Then my 4.4 CD set arrived, and I was disappointed to find the install kernel would lock up after the driver was probed. Complaints were made and epithets were hurled, and lo, in 4.5-RELEASE, all was well once again. Then came 4.6-RELEASE, and it was broken again. Then came 4.6.2, and it was still broken. And in 4.7. And 4.8. And 5.0. (Yeah yeah, shut up.) I just got my 5.1-RELEASE CDs and guess what? My CD-ROM drive STILL doesn't work!!! Guys, there's nothing more frustrating than getting a brand new CD set in the mail and not being able to install via CD. So I'm not leaving it up to chance anymore. I have a patch to make my drive work here: http://www.freebsd.org/~wpaul/ata-card.c.diff-5.1 I have no idea what the altio port remapping goop in ata_pccard_probe() is supposed to accomplish, but I'm telling you all right now, it doesn't work with my drive. I have specifically added to code to skip the remapping for drives with the product string of NinjaATA- (the problem with the Teac controller is that its vendor/product ID is 0x/0x, so there's really no better way to indentify it). This patch changes this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 device_probe_and_attach: ata2 attach returned 6 Into this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 acd0: CDROM CD-224E at ata2-master PIO4 Now, I'm sending out this notification that I _WILL_ check this patch in before I leave the office today. I'm not asking for permission. I've been waiting for half a dozen releases for this to get fixed. When 5.2-RELEASE arrives in my mailbox, it _WILL_ install from CD-ROM on my laptop or so help me I will find the responsible parties and force them to listen to RMS sing Free The Software -- _live_ -- until their ears bleed. I have tested this patch. It compiles. It works. I can mount CDs successfully and transfer stuff from them to my heart's content. I've reduced the change down to the absolute minimum and insured that it won't affect any other drives except mine. It's going in. Period. I am not leaving it up for debate, because if I do, all that will happen is that people will argue over what the more correct fix should be, and at this point I _just_ _don't_ _care_. I want my drive to work, and this does it. Understand? Good. This concludes my announcement. Thank you all for your attention. Don't forget to tip the waitress. -Bill P.S.: Be sure to join us next time when I ream out whoever it was that broke support for my 3Com 3c575C cardbus ethernet NIC. -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
Here's a better patch, basesd on wpaul's input. Bill, can you try it
an see if it works for you? If so, i would be better to commit this
one. If not, I'll work with you to fix it.
If you are uninterested in working with us to get things in, then your
patch will not lasts the evening as such an approach is unacceptibe.
Warner
Index: ata-card.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-card.c,v
retrieving revision 1.14
diff -u -r1.14 ata-card.c
--- ata-card.c 17 Jun 2003 12:33:53 - 1.14
+++ ata-card.c 26 Jun 2003 19:12:34 -
@@ -44,17 +44,26 @@
#include dev/pccard/pccardvar.h
#include dev/pccard/pccarddevs.h
-static const struct pccard_product ata_pccard_products[] = {
+struct ata_pccard_product
+{
+struct pccard_product p;
+u_int flags;
+#define ONE_REGION 1
+};
+
+
+
+static const struct ata_pccard_product ata_pccard_products[] = {
/* NetBSD has a few others that need to migrate into pccarddevs */
/* XXX */
- PCMCIA_CARD(FREECOM, PCCARDIDE, 0),
- PCMCIA_CARD(EXP, EXPMULTIMEDIA, 0),
- PCMCIA_CARD(IODATA, CBIDE2, 0),
- PCMCIA_CARD(OEM2, CDROM1, 0),
- PCMCIA_CARD(OEM2, IDE, 0),
- PCMCIA_CARD(PANASONIC, KXLC005, 0),
- PCMCIA_CARD(TEAC, IDECARDII, 0),
- {NULL}
+ { PCMCIA_CARD(FREECOM, PCCARDIDE, 0), 0 },
+ { PCMCIA_CARD(EXP, EXPMULTIMEDIA, 0), 0 },
+ { PCMCIA_CARD(IODATA, CBIDE2, 0), 0 },
+ { PCMCIA_CARD(OEM2, CDROM1, 0), 0 },
+ { PCMCIA_CARD(OEM2, IDE, 0), 0 },
+ { PCMCIA_CARD(PANASONIC, KXLC005, 0), 0 },
+ { PCMCIA_CARD(TEAC, IDECARDII, 0), ONE_REGION},
+ { {NULL}, 0}
};
static int
@@ -73,7 +82,7 @@
return (0);
/* Match other devices here, primarily cdrom/dvd rom */
-if ((pp = pccard_product_lookup(dev, ata_pccard_products,
+if ((pp = pccard_product_lookup(dev, ata_pccard_products[0].p,
sizeof(ata_pccard_products[0]), NULL)) != NULL) {
if (pp-pp_name)
device_set_desc(dev, pp-pp_name);
@@ -96,6 +105,7 @@
static int
ata_pccard_probe(device_t dev)
{
+const struct ata_pccard_product *ap;
struct ata_channel *ch = device_get_softc(dev);
struct resource *io, *altio;
int i, rid, len, start, end;
@@ -116,12 +126,16 @@
io = bus_alloc_resource(dev, SYS_RES_IOPORT, rid,
start, end, ATA_IOSIZE, RF_ACTIVE);
+ap = (const struct ata_pccard_product *)pccard_product_lookup(dev,
+ ata_pccard_products[0].p, sizeof(ata_pccard_products[0]), NULL);
+
/*
* if we got more than the default ATA_IOSIZE ports, this is likely
* a pccard system where the altio ports are located at offset 14
* otherwise its the normal altio offset
*/
-if (bus_get_resource(dev, SYS_RES_IOPORT, ATA_ALTADDR_RID, tmp, tmp)) {
+if ((ap == NULL || (ap-flags ONE_REGION) != 0)
+ bus_get_resource(dev, SYS_RES_IOPORT, ATA_ALTADDR_RID, tmp, tmp)) {
if (len ATA_IOSIZE) {
bus_set_resource(dev, SYS_RES_IOPORT, ATA_ALTADDR_RID,
start + ATA_PCCARD_ALTOFFSET, ATA_ALTIOSIZE);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Bill Paul) writes: : P.S.: Be sure to join us next time when I ream out whoever it was that : broke support for my 3Com 3c575C cardbus ethernet NIC. It looks like my 3ccfe575ct is working well as of lasts week's current. Any public reamings likely will result in some sanction from core. Control your temper, or else. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
On Thu, 26 Jun 2003, Bill Paul wrote: A long time ago, circa FreeBSD 4.3, my Sony PCMCIA CD-ROM drive with brain-damaged Teac ATA controller drive worked, and the people were content and all was right with the land. Then my 4.4 CD set arrived, and I was disappointed to find the install kernel would lock up after the driver was probed. Complaints were made and epithets were hurled, and lo, in 4.5-RELEASE, all was well once again. Then came 4.6-RELEASE, and it was broken again. Then came 4.6.2, and it was still broken. And in 4.7. And 4.8. And 5.0. (Yeah yeah, shut up.) I just got my 5.1-RELEASE CDs and guess what? My CD-ROM drive STILL doesn't work!!! Guys, there's nothing more frustrating than getting a brand new CD set in the mail and not being able to install via CD. So I'm not leaving it up to chance anymore. I have a patch to make my drive work here: http://www.freebsd.org/~wpaul/ata-card.c.diff-5.1 I have no idea what the altio port remapping goop in ata_pccard_probe() is supposed to accomplish, but I'm telling you all right now, it doesn't work with my drive. I have specifically added to code to skip the remapping for drives with the product string of NinjaATA- (the problem with the Teac controller is that its vendor/product ID is 0x/0x, so there's really no better way to indentify it). This patch changes this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 device_probe_and_attach: ata2 attach returned 6 Into this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 acd0: CDROM CD-224E at ata2-master PIO4 Someone also broke the NVidia ata chip between 4.3 and 4.4. it too has remained broken.. I didn't know that nvidia made such things until I saw this machine.. You CAN boot if you force it to not allow DMA and only use PIO. Now, I'm sending out this notification that I _WILL_ check this patch in before I leave the office today. I'm not asking for permission. I've been waiting for half a dozen releases for this to get fixed. When 5.2-RELEASE arrives in my mailbox, it _WILL_ install from CD-ROM on my laptop or so help me I will find the responsible parties and force them to listen to RMS sing Free The Software -- _live_ -- until their ears bleed. I have tested this patch. It compiles. It works. I can mount CDs successfully and transfer stuff from them to my heart's content. I've reduced the change down to the absolute minimum and insured that it won't affect any other drives except mine. It's going in. Period. I am not leaving it up for debate, because if I do, all that will happen is that people will argue over what the more correct fix should be, and at this point I _just_ _don't_ _care_. I want my drive to work, and this does it. Understand? Good. This concludes my announcement. Thank you all for your attention. Don't forget to tip the waitress. -Bill P.S.: Be sure to join us next time when I ream out whoever it was that broke support for my 3Com 3c575C cardbus ethernet NIC. -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
Here's a better patch, basesd on wpaul's input. Bill, can you try it
an see if it works for you? If so, i would be better to commit this
one. If not, I'll work with you to fix it.
Close, but this doesn't quite do it. I thought something didn't look
right when I read it, and I tested it just to be certain. Detecting the
card via the table is fine, but you're not skipping the right piece of
code. The existing code logic says:
if (getting the altio port range with bus_get_resource() succeeds)
then (set the resource offset depending on port range size)
else
(release the ioport resource and bail with ENXIO)
With my drive, it's the bus_get_resource() that fails, so we end up
failing the probe with ENXIO. Your patch changes this to:
if (the ONE_REGION flag is not set?) and (getting the port range
with bus_get_resource() succeeds)
then (set the resource offset depending on port range size)
else
(release the ioport resource and bail with ENXIO)
So if the ONE_REGION bit is set, we still bail with ENXIO. I put the
question mark up there because I think there's a typo:
-if (bus_get_resource(dev, SYS_RES_IOPORT, ATA_ALTADDR_RID, tmp, tmp)) {
+if ((ap == NULL || (ap-flags ONE_REGION) != 0)
+ bus_get_resource(dev, SYS_RES_IOPORT, ATA_ALTADDR_RID, tmp, tmp)) {
I think this:
if ((ap == NULL || (ap-flags ONE_REGION) != 0) ...
should be this:
if ((ap == NULL || (ap-flags ONE_REGION) == 0) ...
I might be wrong. In any case, it still doesn't work. I think the logic
should be:
if (the ONE_REGION flag is not set)
then (do all the other stuff)
This way, we skip the whole altio remapping step entirely. I just tested
this and it seems to work. Here's a modified version of your patch
showing what I mean:
http://www.freebsd.org/~wpaul/ata-card.c.diff2
Also, since Soren asked, here are verbose boot messages in both the
failure and success cases:
http://www.freebsd.org/~wpaul/dmesg.bad
http://www.freebsd.org/~wpaul/dmesg.good
If you are uninterested in working with us to get things in, then your
patch will not lasts the evening as such an approach is unacceptibe.
Well, with all due respect, the fact that this is still broken is
also unacceptable. All I want is to insure that this is fixed and
that it stays fixed. I don't care if it's your patch or mine, as
long as it works, and doesn't regress.
And for the record, if somebody came to me and said: Bill! Your
so-and-so driver hasn't worked right on such-and-such card I don't
have in months! I'm at wit's end! You leave me *NO* alternative!
I'm just going to have to fix it for you! At gunpoint! No no, don't
try and stop me! This is for your own good! well, then, gosh, I'd
let 'em.
But I guess that's just me.
-Bill
--
=
-Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
[EMAIL PROTECTED] | Wind River Systems
=
If stupidity were a handicap, you'd have the best parking spot.
=
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
I have another problem different with Bill Paul's. I have a Tyan Tiger 230T dual CPU MB. On second IDE, there are MITSUBISHI 52X CDROM as master and a SONY CD-RW CRX140E 8X/4X/32X as slave. FreeBSD never got them to work, while MS Windows and Linux and NetBSD and OpenBSD all work well with these devices. FreeBSD always stuck at MODE SENSE BIG, this sucks, I must disable second IDE in BIOS before booting into FreeBSD and reenable it before booting into another OS. I changed configuration several times, both DMA and PIO mode don't work, it works only when CR-RW is pulled. David Xu - Original Message - From: Soeren Schmidt [EMAIL PROTECTED] To: Bill Paul [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, June 27, 2003 3:03 AM Subject: Re: Heads up: checking in change to ata-card.c I do have problems with the wording you use in the comments in that patch mentioned below, I will even say that I will remove that as soon as it appears *and* shoot the committer so it doesn't happen again to use your choice of wording.. Now, I dont think this way is productive at all, and would appreciate if we could have a civilized way of doing this instead... This is exactly the crap that makes one wonder if the time used on the project is well spent... -Søren It seems Bill Paul wrote: A long time ago, circa FreeBSD 4.3, my Sony PCMCIA CD-ROM drive with brain-damaged Teac ATA controller drive worked, and the people were content and all was right with the land. Then my 4.4 CD set arrived, and I was disappointed to find the install kernel would lock up after the driver was probed. Complaints were made and epithets were hurled, and lo, in 4.5-RELEASE, all was well once again. Then came 4.6-RELEASE, and it was broken again. Then came 4.6.2, and it was still broken. And in 4.7. And 4.8. And 5.0. (Yeah yeah, shut up.) I just got my 5.1-RELEASE CDs and guess what? My CD-ROM drive STILL doesn't work!!! Guys, there's nothing more frustrating than getting a brand new CD set in the mail and not being able to install via CD. So I'm not leaving it up to chance anymore. I have a patch to make my drive work here: http://www.freebsd.org/~wpaul/ata-card.c.diff-5.1 I have no idea what the altio port remapping goop in ata_pccard_probe() is supposed to accomplish, but I'm telling you all right now, it doesn't work with my drive. I have specifically added to code to skip the remapping for drives with the product string of NinjaATA- (the problem with the Teac controller is that its vendor/product ID is 0x/0x, so there's really no better way to indentify it). This patch changes this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 device_probe_and_attach: ata2 attach returned 6 Into this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 acd0: CDROM CD-224E at ata2-master PIO4 Now, I'm sending out this notification that I _WILL_ check this patch in before I leave the office today. I'm not asking for permission. I've been waiting for half a dozen releases for this to get fixed. When 5.2-RELEASE arrives in my mailbox, it _WILL_ install from CD-ROM on my laptop or so help me I will find the responsible parties and force them to listen to RMS sing Free The Software -- _live_ -- until their ears bleed. I have tested this patch. It compiles. It works. I can mount CDs successfully and transfer stuff from them to my heart's content. I've reduced the change down to the absolute minimum and insured that it won't affect any other drives except mine. It's going in. Period. I am not leaving it up for debate, because if I do, all that will happen is that people will argue over what the more correct fix should be, and at this point I _just_ _don't_ _care_. I want my drive to work, and this does it. Understand? Good. This concludes my announcement. Thank you all for your attention. Don't forget to tip the waitress. -Bill P.S.: Be sure to join us next time when I ream out whoever it was that broke support for my 3Com 3c575C cardbus ethernet NIC. -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED
Re: Heads up: checking in change to ata-card.c
On Fri, Jun 27, 2003 at 06:30:17AM +0800, David Xu wrote: I'm sure Soeren will be be glad to investigate, I don't think it is very worthwhile for you to piggyback your problem on top of Bill's controversial email.. Make code, not war ;-) Wilko I have another problem different with Bill Paul's. I have a Tyan Tiger 230T dual CPU MB. On second IDE, there are MITSUBISHI 52X CDROM as master and a SONY CD-RW CRX140E 8X/4X/32X as slave. FreeBSD never got them to work, while MS Windows and Linux and NetBSD and OpenBSD all work well with these devices. FreeBSD always stuck at MODE SENSE BIG, this sucks, I must disable second IDE in BIOS before booting into FreeBSD and reenable it before booting into another OS. I changed configuration several times, both DMA and PIO mode don't work, it works only when CR-RW is pulled. David Xu - Original Message - From: Soeren Schmidt [EMAIL PROTECTED] To: Bill Paul [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, June 27, 2003 3:03 AM Subject: Re: Heads up: checking in change to ata-card.c I do have problems with the wording you use in the comments in that patch mentioned below, I will even say that I will remove that as soon as it appears *and* shoot the committer so it doesn't happen again to use your choice of wording.. Now, I dont think this way is productive at all, and would appreciate if we could have a civilized way of doing this instead... This is exactly the crap that makes one wonder if the time used on the project is well spent... -Søren ... [snip snip ] ---end of quoted text--- -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
In message [EMAIL PROTECTED], M. Warner Losh writes:
Here's a better patch, basesd on wpaul's input. Bill, can you try it
an see if it works for you? If so, i would be better to commit this
one. If not, I'll work with you to fix it.
FYI, I have a no-name (PCMCIA/CD-ROM) drive that also requires
failure of the second IO range to be made non-fatal. How about just
deleting the `else' clause as in the patch below? It seems that
this can only affect CD-ROM drives that were otherwise not working,
so it should be fairly safe.
Ian
Index: ata-card.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/ata/ata-card.c,v
retrieving revision 1.14
diff -u -r1.14 ata-card.c
--- ata-card.c 17 Jun 2003 12:33:53 - 1.14
+++ ata-card.c 26 Jun 2003 23:00:01 -
@@ -131,10 +131,6 @@
start + ATA_ALTOFFSET, ATA_ALTIOSIZE);
}
}
-else {
- bus_release_resource(dev, SYS_RES_IOPORT, rid, io);
- return ENXIO;
-}
/* allocate the altport range */
rid = ATA_ALTADDR_RID;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Heads up: checking in change to ata-card.c
-Original Message- From: David Xu [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 6:30 PM To: Soeren Schmidt; Bill Paul Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Heads up: checking in change to ata-card.c I have another problem different with Bill Paul's. I have a Tyan Tiger 230T dual CPU MB. On second IDE, there are MITSUBISHI 52X CDROM as master and a SONY CD-RW CRX140E 8X/4X/32X as slave. FreeBSD never got them to work, while MS Windows and Linux and NetBSD and OpenBSD all work well with these devices. FreeBSD always stuck at MODE SENSE BIG, this sucks, I must disable second IDE in BIOS before booting into FreeBSD and reenable it before booting into another OS. I changed configuration several times, both DMA and PIO mode don't work, it works only when CR-RW is pulled. David Xu I started seeing this behavior also, but it started when I swapped drives from a dead Via dual chipset board machine (MSI 694D Pro, I think) into an athlon machine with an Asus A7Vsomething. I can get correct model numbers, etc. if helpful. This is a 4.8-RELEASE installation. I had to reboot the first time with an old 4.4 GENERIC leftover from installation, and I saw no errors, but after compiling a uniprocessor kernel I started seeing the above behavior. Although, I left it for awhile and eventually the machine does boot after about 30 of the MODE_SENSE_BIG, resetting devices lines. -Will ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Heads up: checking in change to ata-card.c
Nvidia (I previously didn't know they made full chipsets) IDE interfaces got broken around FreeBSD 4.3 and at 4.8 they are still not working.. There is however a workaround which is to disable the use of DMA on the devices (in the loader.conf file). if you don't the system hangs during boot. I have only sporadic access to one, but I don't have one myself which makes it hard to test more.. I have not tested it on 5.x yet.. On Thu, 26 Jun 2003, Will Saxon wrote: -Original Message- From: David Xu [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 6:30 PM To: Soeren Schmidt; Bill Paul Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Heads up: checking in change to ata-card.c I have another problem different with Bill Paul's. I have a Tyan Tiger 230T dual CPU MB. On second IDE, there are MITSUBISHI 52X CDROM as master and a SONY CD-RW CRX140E 8X/4X/32X as slave. FreeBSD never got them to work, while MS Windows and Linux and NetBSD and OpenBSD all work well with these devices. FreeBSD always stuck at MODE SENSE BIG, this sucks, I must disable second IDE in BIOS before booting into FreeBSD and reenable it before booting into another OS. I changed configuration several times, both DMA and PIO mode don't work, it works only when CR-RW is pulled. David Xu I started seeing this behavior also, but it started when I swapped drives from a dead Via dual chipset board machine (MSI 694D Pro, I think) into an athlon machine with an Asus A7Vsomething. I can get correct model numbers, etc. if helpful. This is a 4.8-RELEASE installation. I had to reboot the first time with an old 4.4 GENERIC leftover from installation, and I saw no errors, but after compiling a uniprocessor kernel I started seeing the above behavior. Although, I left it for awhile and eventually the machine does boot after about 30 of the MODE_SENSE_BIG, resetting devices lines. -Will ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Heads up: checking in change to ata-card.c
-Original Message- From: Julian Elischer [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 7:26 PM To: Will Saxon Cc: David Xu; Soeren Schmidt; Bill Paul; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Heads up: checking in change to ata-card.c Nvidia (I previously didn't know they made full chipsets) IDE interfaces got broken around FreeBSD 4.3 and at 4.8 they are still not working.. There is however a workaround which is to disable the use of DMA on the devices (in the loader.conf file). if you don't the system hangs during boot. I have only sporadic access to one, but I don't have one myself which makes it hard to test more.. I have not tested it on 5.x yet.. Well I am pretty sure this isn't an Nvidia chipset, actually I know it isn't: atapci0: VIA 8235 ATA133 controller port 0xb000-0xb00f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 9797MB QUANTUM FIREBALLP LM10.2 [19906/16/63] at ata0-master UDMA66 acd0: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done ..repeat 19 more times.. acd0: CDROM CD-956E/AKV at ata1-master PIO4 Maybe there are some similarities though - Nvidia seemed to just pull a good chipset out of nowhere a couple of years ago, maybe they licensed some stuff from Via? I know they worked a lot on the Xbox but that is an Intel system - the nForce stuff is AMD-only. I have 4 operable machines, 3 of them working with this 694D board, the other (ironically) a 230T also (which is working fine with a 4.8-PRERELEASE kernel from 2/19). In a few weeks they will all be replaced by new P4 machines and I should have the ability to basically do whatever I want with them. So if this turns into a protracted issue that requires testing, I will be more than happy to test patches for 4.x and 5.x, single and dual processor. -Will On Thu, 26 Jun 2003, Will Saxon wrote: -Original Message- From: David Xu [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 6:30 PM To: Soeren Schmidt; Bill Paul Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Heads up: checking in change to ata-card.c I have another problem different with Bill Paul's. I have a Tyan Tiger 230T dual CPU MB. On second IDE, there are MITSUBISHI 52X CDROM as master and a SONY CD-RW CRX140E 8X/4X/32X as slave. FreeBSD never got them to work, while MS Windows and Linux and NetBSD and OpenBSD all work well with these devices. FreeBSD always stuck at MODE SENSE BIG, this sucks, I must disable second IDE in BIOS before booting into FreeBSD and reenable it before booting into another OS. I changed configuration several times, both DMA and PIO mode don't work, it works only when CR-RW is pulled. David Xu I started seeing this behavior also, but it started when I swapped drives from a dead Via dual chipset board machine (MSI 694D Pro, I think) into an athlon machine with an Asus A7Vsomething. I can get correct model numbers, etc. if helpful. This is a 4.8-RELEASE installation. I had to reboot the first time with an old 4.4 GENERIC leftover from installation, and I saw no errors, but after compiling a uniprocessor kernel I started seeing the above behavior. Although, I left it for awhile and eventually the machine does boot after about 30 of the MODE_SENSE_BIG, resetting devices lines. -Will ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
In message [EMAIL PROTECTED], M. Warner Losh writes:
Here's a better patch, basesd on wpaul's input. Bill, can you try it
an see if it works for you? If so, i would be better to commit this
one. If not, I'll work with you to fix it.
FYI, I have a no-name (PCMCIA/CD-ROM) drive that also requires
failure of the second IO range to be made non-fatal. How about just
deleting the `else' clause as in the patch below? It seems that
this can only affect CD-ROM drives that were otherwise not working,
so it should be fairly safe.
This patch also tests good with my drive.
-Bill
--
=
-Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
[EMAIL PROTECTED] | Wind River Systems
=
If stupidity were a handicap, you'd have the best parking spot.
=
Ian
Index: ata-card.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/ata/ata-card.c,v
retrieving revision 1.14
diff -u -r1.14 ata-card.c
--- ata-card.c17 Jun 2003 12:33:53 - 1.14
+++ ata-card.c26 Jun 2003 23:00:01 -
@@ -131,10 +131,6 @@
start + ATA_ALTOFFSET, ATA_ALTIOSIZE);
}
}
-else {
- bus_release_resource(dev, SYS_RES_IOPORT, rid, io);
- return ENXIO;
-}
/* allocate the altport range */
rid = ATA_ALTADDR_RID;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
On Thu, Jun 26, 2003 at 01:20:04PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Bill Paul) writes: : P.S.: Be sure to join us next time when I ream out whoever it was that : broke support for my 3Com 3c575C cardbus ethernet NIC. It looks like my 3ccfe575ct is working well as of lasts week's current. Any public reamings likely will result in some sanction from core. Control your temper, or else. Here comes the Great Core FreeBSD Censor Police!!! I can't believe Bill's email, elected this threat from Core. Become a committer and loose rights others on this mailing list have. Feh, is a group hug next? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
This works for all my ata-like cards. I've gone ahead and committed it... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
On Thu, Jun 26, 2003 at 05:04:10PM -0700, David O'Brien wrote: On Thu, Jun 26, 2003 at 01:20:04PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Bill Paul) writes: : P.S.: Be sure to join us next time when I ream out whoever it was that : broke support for my 3Com 3c575C cardbus ethernet NIC. It looks like my 3ccfe575ct is working well as of lasts week's current. Any public reamings likely will result in some sanction from core. Control your temper, or else. Here comes the Great Core FreeBSD Censor Police!!! I can't believe Bill's email, elected this threat from Core. Become a committer and loose rights others on this mailing list have. Feh, is a group hug next? Come on... -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
bsd.port.mk dependency loop checking patch (Re: Who broke 'make clean' for ports ?)
(add To: [EMAIL PROTECTED])
From: Garrett Rooney [EMAIL PROTECTED]
Subject: Re: Who broke 'make clean' for ports ?
Date: Sat, May 11, 2002 at 02:31:32AM JST
there's a circular dependency that was just introduced to gettext.
gettext now depends on expat, which depends on gmake, which depends on
gettext.
Recently, I wrote a patch for bsd.port.mk that checks circular dependency.
If a dependency loop is found, it gives you a warning and
does not invoke 'make' process any further.
Someone, please test the patch below.
If no problem is found, I will send-pr(8).
Index: bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.411
diff -u -u -r1.411 bsd.port.mk
--- bsd.port.mk 27 Apr 2002 11:22:59 - 1.411
+++ bsd.port.mk 8 May 2002 17:13:40 -
@@ -684,6 +684,16 @@
.else
PORTSDIR?= /usr/ports
.endif
+.if exists(/bin/realpath)
+PORTSDIR!= /bin/realpath ${PORTSDIR}
+.else
+PORTSDIR_IS_SYMLINK!= if [ -L ${PORTSDIR} ]; then echo yes ; fi
+. if ${PORTSDIR_IS_SYMLINK} == yes
+. errorPORTSDIR must not be a symlink
+. endif
+. undef PORTSDIR_IS_SYMLINK
+.endif
+
LOCALBASE?=${DESTDIR}/usr/local
X11BASE?= ${DESTDIR}/usr/X11R6
LINUXBASE?=${DESTDIR}/compat/linux
@@ -3068,11 +3078,20 @@
@${ALL-DEPENDS-LIST}
ALL-DEPENDS-LIST= \
+ parents=${PARENTS} ${.CURDIR}; \
checked=${PARENT_CHECKED}; \
- for dir in $$(${ECHO_CMD} ${FETCH_DEPENDS} ${BUILD_DEPENDS} ${LIB_DEPENDS}
${RUN_DEPENDS} | ${TR} '\040' '\012' | ${SED} -e 's/^[^:]*://' -e 's/:.*//')
$$(${ECHO_CMD} ${DEPENDS} | ${TR} '\040' '\012' | ${SED} -e 's/:.*//'); do \
+ for dir in $$( { ${ECHO_CMD} ${FETCH_DEPENDS} ${BUILD_DEPENDS} ${LIB_DEPENDS}
+${RUN_DEPENDS} | ${TR} '\040' '\012' | ${SED} -e 's/^[^:]*://' -e 's/:.*//' ;
+${ECHO_CMD} ${DEPENDS} | ${TR} '\040' '\012' | ${SED} -e 's/:.*//'; } | sort -u); do \
if [ -d $$dir ]; then \
- if (${ECHO_CMD} $$checked | ${GREP} -qwv $$dir); then \
- child=$$(cd $$dir; ${MAKE} PARENT_CHECKED=$$checked
all-depends-list); \
+ for p in $$parents; do \
+ if [ $$p = $$dir ]; then \
+ ${ECHO_MSG} Dependency loop: 2; \
+ ${ECHO_MSG} ${.CURDIR} = $$p 2; \
+ ${ECHO_MSG} 2; \
+ exit 1;\
+ fi; \
+ done; \
+ if $$( for c in $$checked; do if [ $$dir = $$c ]; then
+exit 1; fi ; done ); then \
+ child=$$(cd $$dir; ${MAKE} PARENTS=$$parents
+PARENT_CHECKED=$$checked all-depends-list); \
for d in $$child; do ${ECHO_CMD} $$d; done; \
${ECHO_CMD} $$dir; \
checked=$$dir $$child $$checked; \
@@ -3155,11 +3174,20 @@
if [ ${CHILD_DEPENDS} ]; then \
${ECHO_CMD} ${PKGNAME} ${.CURDIR}; \
fi; \
+ parents=${PARENTS} ${.CURDIR}; \
checked=${PARENT_CHECKED}; \
- for dir in $$(${ECHO_CMD} ${LIB_DEPENDS} ${RUN_DEPENDS} | ${TR} '\040'
'\012' | ${SED} -e 's/^[^:]*://' -e 's/:.*//') $$(${ECHO_CMD} ${DEPENDS} | ${TR}
'\040' '\012' | ${SED} -e 's/:.*//'); do \
+ for dir in $$( { ${ECHO_CMD} ${LIB_DEPENDS} ${RUN_DEPENDS} | ${TR} '\040'
+'\012' | ${SED} -e 's/^[^:]*://' -e 's/:.*//' ; ${ECHO_CMD} ${DEPENDS} | ${TR} '\040'
+'\012' | ${SED} -e 's/:.*//'; } | sort -u); do \
if [ -d $$dir ]; then \
- if (${ECHO_CMD} $$checked | ${GREP} -qwv $$dir); then \
- childout=$$(cd $$dir; ${MAKE} CHILD_DEPENDS=yes
PARENT_CHECKED=$$checked package-depends-list); \
+ for p in $$parents; do \
+ if [ $$p = $$dir ]; then \
+ ${ECHO_MSG} Dependency loop: 2; \
+ ${ECHO_MSG} ${.CURDIR} = $$p 2; \
+ ${ECHO_MSG} 2; \
+ exit 1;\
+ fi; \
+ done; \
+ if $$( for c in $$checked; do if [ $$dir = $$c ]; then
+exit 1; fi ; done ); then \
+ childout=$$(cd $$dir; ${MAKE} CHILD_DEPENDS=yes
+PARENTS=$$parents PARENT_CHECKED=$$checked package-depends-list); \
set -- $$childout; \
childname=; childdir=; \
while [ $$\# != 0 ]; do \
@@ -3173,7 +3201,7 @@
else \
${ECHO_MSG} ${PKGNAME}: \$$dir\ non-existent -- dependency
list incomplete 2; \
Re: bsd.port.mk dependency loop checking patch (Re: Who broke 'make clean' for ports ?)
KOMATSU Shinichiro wrote: (add To: [EMAIL PROTECTED]) From: Garrett Rooney [EMAIL PROTECTED] Subject: Re: Who broke 'make clean' for ports ? Date: Sat, May 11, 2002 at 02:31:32AM JST there's a circular dependency that was just introduced to gettext. gettext now depends on expat, which depends on gmake, which depends on gettext. Recently, I wrote a patch for bsd.port.mk that checks circular dependency. If a dependency loop is found, it gives you a warning and does not invoke 'make' process any further. Someone, please test the patch below. If no problem is found, I will send-pr(8). I don't think that we really need such patch. In 99.% of cases it would just waste CPU cycles. Circular dependency is a bug and as such it doesn't need to be a supported special case. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bsd.port.mk dependency loop checking patch (Re: Who broke 'make clean' for ports ?)
* Maxim Sobolev [EMAIL PROTECTED] [2002-05-11 15:00]:
KOMATSU Shinichiro wrote:
(add To: [EMAIL PROTECTED])
From: Garrett Rooney [EMAIL PROTECTED]
Subject: Re: Who broke 'make clean' for ports ?
Date: Sat, May 11, 2002 at 02:31:32AM JST
there's a circular dependency that was just introduced to gettext.
gettext now depends on expat, which depends on gmake, which depends on
gettext.
Recently, I wrote a patch for bsd.port.mk that checks circular dependency.
If a dependency loop is found, it gives you a warning and
does not invoke 'make' process any further.
Someone, please test the patch below.
If no problem is found, I will send-pr(8).
I don't think that we really need such patch. In 99.% of cases it
would just waste CPU cycles. Circular dependency is a bug and as such
it doesn't need to be a supported special case.
But it might be a good idea to incorporate this functionality into
${PORTSDIR}/devel/portlint.
Regards,
Olli
--
Institute for Software TechnologyInstitute for Information Systems
Department of Computing Science, Federal Armed Forces University Munich
--- http://ist.unibw-muenchen.de/People/obraun/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bsd.port.mk dependency loop checking patch (Re: Who broke 'make clean' for ports ?)
On Sat, May 11, 2002 at 04:00:53PM +0300, Maxim Sobolev wrote: KOMATSU Shinichiro wrote: (add To: [EMAIL PROTECTED]) From: Garrett Rooney [EMAIL PROTECTED] Subject: Re: Who broke 'make clean' for ports ? Date: Sat, May 11, 2002 at 02:31:32AM JST there's a circular dependency that was just introduced to gettext. gettext now depends on expat, which depends on gmake, which depends on gettext. Recently, I wrote a patch for bsd.port.mk that checks circular dependency. If a dependency loop is found, it gives you a warning and does not invoke 'make' process any further. Someone, please test the patch below. If no problem is found, I will send-pr(8). I don't think that we really need such patch. In 99.% of cases it would just waste CPU cycles. Circular dependency is a bug and as such it doesn't need to be a supported special case. Actually it would be useful to have this functionality somewhere. I recently spent a couple of hours trying to track down a circular dependency I had introduced via a bsd.port.mk patch. The main symptom was that the make_index script would just go into a loop and exhaust memory. I ended up finding it by adding all sorts of debugging printfs to the perl script, but this was pretty ugly. Kris msg38195/pgp0.pgp Description: PGP signature
Re: checking in...
On Sun, Nov 18, 2001 at 02:41:30PM -0800, Hiten Pandya wrote: hello all, please tell me if i have done something wrong but... i have installed 5.0-CURRENT as of the latest CVS copy of 7.00pm GMT British Time.. it all works fine... but.. i think there is a problem witht the linux compatibility.. although i am not a very much of a programmer (yet).. but... it seems that linux-netscape* dont seem to be working properly.. thanks... If you're going to run -current, it's expected that you can give better bug reports than this, and also that you'll pay close attention to the CVS commit logs and mailing list traffic so you know what's going on with the system, and what should and shouldn't work. Kris msg31884/pgp0.pgp Description: PGP signature
checking in...
hello all, please tell me if i have done something wrong but... i have installed 5.0-CURRENT as of the latest CVS copy of 7.00pm GMT British Time.. it all works fine... but.. i think there is a problem witht the linux compatibility.. although i am not a very much of a programmer (yet).. but... it seems that linux-netscape* dont seem to be working properly.. thanks... = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k Guys!... stay away from Einstein Junior! __ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sysinstall: Avoiding version checking of CD-ROM (patchincluded)
jkh there should be a boot/kernel/kernel.ko file and I'm not sure why
jkh there isn't.
This is because 'release.3' target (in src/release/Makefile) does not
know that the kernel should go to into ${RD}/trees/bin/boot/kernel.
Note that we cannot change 'doKERNEL' target, which is also used by
other places (see 'doMFSKERN' target).
Other modules and boot stuffs were installed by 'make distribute' (of
src/sys/Makefile), in a procedure of 'release.2' target.
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: Avoiding version checking of CD-ROM (patch included)
Speaking about sysinstall, would you please check my PR (bin/21423, URL:http://www.freebsd.org/cgi/query-pr.cgi?pr=21423) ? Done and fixed, thanks! It should be in the next (2930) -current snapshot in ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/ - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: Avoiding version checking of CD-ROM (patchincluded)
jkh Done and fixed, thanks! Wow, thank you ^_^ But.. maybe my PR is not clearly described, it does not fix current situation; very sorry for my poor presentations. Here is a current directory structure (just extracted tarballs) of 5-current as of Sep/29/2000. % cd ~ftp/pub/FreeBSD/snapshots/i386/livetree/5-LATEST/ % ls COPYRIGHT cdrom.inf kernel.GENERIC roottmp bin dev mnt sbinusr bootetc procsys var % ls boot/kernel/kernel* zsh: no matches found: boot/kernel/kernel* % We can easily found that: * Generic kernel is /kernel.GENERIC. (and sysinstall copies /kernel.GENERIC to /kernel when installed) * There is no /boot/kernel/kernel. We cannot boot without kernel:) So, it should be: * Generic kernel go to /boot/kernel directory (I have no idea of about its filename). * After installation, /boot/kernel/kernel exists. To do that, we can: * modify src/release/Makefile to put generic kernel under /boot/kernel. * modify src/release/install.c to copy generic kernel to /boot/kernel/kernel. or, * modify src/release/Makefile to put generic kernel to /boot/kernel/kernel. * modify src/release/install.c, not to do copying generic kernel. (this is done by rev. 1.283) Sorry if I'm wrong, -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: Avoiding version checking of CD-ROM (patch included)
% ls boot/kernel/kernel* zsh: no matches found: boot/kernel/kernel* That's a different problem - there should be a boot/kernel/kernel.ko file and I'm not sure why there isn't. I'll talk to David O'Brien about fixing it. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: Avoiding version checking of CD-ROM (patchincluded)
jkh Thanks for reminding me to go look at that code - you're right, jkh the check is incorrectly done and insufficiently general. Fixed jkh in -current and -stable! Very glad to hear that... thank you. Today is Wednesday and 3-stable build will run at current.jp.FreeBSD.org. If it goes successfully, I'll put cdrom.inf file to the triplex CD-ROM (yeah!). Speaking about sysinstall, would you please check my PR (bin/21423, URL:http://www.freebsd.org/cgi/query-pr.cgi?pr=21423) ? Maybe there are few people who want to install -CURRENT to a fresh PC (too crasy ?:-), but when we want to release 5.0-RELEASE, it would be a big problem. It should be considered also that where is the best location for *GENERIC* kernel image (/boot/kernel/kernel.GENERIC is a good candidate). -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sysinstall: Avoiding version checking of CD-ROM (patch included)
I'm an administrator of current.jp.FreeBSD.org, yet another snapshots
services in Japan. Now I'm going to make a bootable FreeBSD
installation CD which contains FreeBSD 3-stable, 4-stable and -current
(namely, 'triplex CD-ROM'). Maybe it's useful for installation events
at BUGs (BSD Users Groups), or any people who wanna try both
bleeding-edge/solid-state version of FreeBSD.
If you have interested in triplex CD-ROM, try (approx. 600MB):
URL:ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i386/ISO-IMAGES/triplex.iso
The directory layout of CD-ROM is quite simple just like this.
% ls
3.5-2913-JPSNAP 5.0-2913-JPSNAP
4.1-2919-JPSNAP boot.img
Note that 'boot.img' contains all three versions of kernel images. You
can choice which sysinstall to kick (thanks you loader(8).)
Most procedures works well, except one warnings. When CD-ROM is
initialized to use (after all installation option was selected),
sysinstall complains as follows:
Warning: The CD currently in the drive is either not a FreeBSD
CD or it is an older (pre 2.1.5) FreeBSD CD which does not
have a version number on it. Do you wish to use this CD anyway?
You can say "yes" to proceed, but it's not welcome. Yeah, It's easy
to fix; create 'cdrom.inf' file at root directory of CD-ROM. But the
contents of cdrom.inf is the problem.
cdrom.inf has it's version name included in CD-ROM, and sysinstall
checks its string. Maybe it's OK when CD-ROM has *one* version of
FreeBSD, but triplex CD-ROM has *three* versions of FreeBSD. So
sysinstall should complains as follow:
Warning: The version of the FreeBSD CD currently in the drive
(XXX) does not match the version of the boot floppy
(YYY).
If this is intentional, to avoid this message in the future
please visit the Options editor to set the boot floppy version
string to match that of the CD before selecting it as your
installation media.
where 'XXX' is version string in cdrom.inf and 'YYY' is version string
in sysinstall. You can also say "yes" to next dialog to proceed
installation, however, it's also not welcome.
I do not want to make a *custom* sysinstall; it's quite hard to do
within a shell script (triplex CD-ROM is built by shell script which
is kicked by crom).
To avoid this situation, make an escape from version checking. Maybe
"CD_VERSION = any" in cdrom.inf is reasonable solution.
Index: cdrom.c
===
RCS file: /usr/site/FreeBSD/ncvs/src/release/sysinstall/cdrom.c,v
retrieving revision 1.47
diff -c -r1.47 cdrom.c
*** cdrom.c 1999/08/28 01:34:08 1.47
--- cdrom.c 2000/09/22 06:12:44
***
*** 122,128
"try again.", mountpoint);
}
else {
! if (variable_cmp(VAR_RELNAME, cp)
variable_cmp(VAR_RELNAME, "none")
variable_cmp(VAR_RELNAME, "any") !bogusCDOK) {
msgConfirm("Warning: The version of the FreeBSD CD currently in the
drive\n"
--- 122,129
"try again.", mountpoint);
}
else {
! if (strcmp(cp, "any")
!variable_cmp(VAR_RELNAME, cp)
variable_cmp(VAR_RELNAME, "none")
variable_cmp(VAR_RELNAME, "any") !bogusCDOK) {
msgConfirm("Warning: The version of the FreeBSD CD currently in the
drive\n"
Is there any chance to apply this patch to sysinstall of -current,
4-stable, and 3-stable?
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: Avoiding version checking of CD-ROM (patch included)
Most procedures works well, except one warnings. When CD-ROM is initialized to use (after all installation option was selected), sysinstall complains as follows: Thanks for reminding me to go look at that code - you're right, the check is incorrectly done and insufficiently general. Fixed in -current and -stable! - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck successfull on checking root-fs but OS still can't mount it
:Hi ! : :I'm seeing strange behaviour of fsck in -current. :FreeBSD titan.klemm.gtn.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Wed Dec 22 07:07:11 :CET 1999 root@:/usr/src/sys/compile/TITAN i386 : :SCSI bus hang, so I had to reboot. fsck checked every filesystem. :But then mount was unable to mount the filesystem and tells you to :check the fs using fsck. Did that again, nothing changed. :You have to reboot. : :I was bitten by that 3 times. : :Another thing are the (I assume SCSI) hangs I got 3 times since :I upgraded from 3.4-STABLE to -current. Next time I'll write down :the messages. Two times the messages were hidden by another X Window. :Nothing in /var/log/messages. I've been bitten by this several times myself recently. The system comes up after a crash, fsck's the media, and then can't mount it and drops into single-user. The only solution is to reboot. It didn't used to do this. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck successfull on checking root-fs but OS still can't mount it
In message [EMAIL PROTECTED], Matthew Dillon writes: I've been bitten by this several times myself recently. The system comes up after a crash, fsck's the media, and then can't mount it and drops into single-user. The only solution is to reboot. (install MAKEDEV by hand) cd /dev sh MAKEDEV (appropriate arguments) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck successfull on checking root-fs but OS still can't mountit
On Thu, 23 Dec 1999, Matthew Dillon wrote: :Hi ! : :I'm seeing strange behaviour of fsck in -current. :FreeBSD titan.klemm.gtn.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Wed Dec 22 07:07:11 CET 1999 root@:/usr/src/sys/compile/TITAN i386 : :SCSI bus hang, so I had to reboot. fsck checked every filesystem. :But then mount was unable to mount the filesystem and tells you to :check the fs using fsck. Did that again, nothing changed. :You have to reboot. : :I was bitten by that 3 times. : :Another thing are the (I assume SCSI) hangs I got 3 times since :I upgraded from 3.4-STABLE to -current. Next time I'll write down :the messages. Two times the messages were hidden by another X Window. :Nothing in /var/log/messages. I've been bitten by this several times myself recently. The system comes up after a crash, fsck's the media, and then can't mount it and drops into single-user. The only solution is to reboot. I thought so too, but you can actually 'tunefs -n (enbale|disable) /' after that you should be able to mount your /. It didn't used to do this. -Matt I know... If anyone else cares, the current situation about being unable to auto-reboot (halting on /) is pretty annoying and ought to be fixed. There were various promises made that all the changes going on with devices wouldn't cause such problems. This makes running -current in somewhat production enviornments impossible. unless you hack /etc/rc. Of course I may have just not remade my /dev/ properly, please flame if appropriate. thanks, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fsck successfull on checking root-fs but OS still can't mount it
Hi ! I'm seeing strange behaviour of fsck in -current. FreeBSD titan.klemm.gtn.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Wed Dec 22 07:07:11 CET 1999 root@:/usr/src/sys/compile/TITAN i386 SCSI bus hang, so I had to reboot. fsck checked every filesystem. But then mount was unable to mount the filesystem and tells you to check the fs using fsck. Did that again, nothing changed. You have to reboot. I was bitten by that 3 times. Another thing are the (I assume SCSI) hangs I got 3 times since I upgraded from 3.4-STABLE to -current. Next time I'll write down the messages. Two times the messages were hidden by another X Window. Nothing in /var/log/messages. -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
