[HEADS-UP] BSD sort is the default sort in -CURRENT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/qooAACgkQkC3QTyNzprELpgCgo1hBQzT/Ns2pnWe3kjn06oIU ddgAn2NyYkRY7vvPK84ZQFkPG9afL0ib =iAEI -END PGP SIGNATURE- ___ 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] BSD sort is the default sort in -CURRENT
On 06/27/12 08:04, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor ... so, can I delete the entry WITH_BSD_SORT=yes in /etc/src.conf then? Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Has this been thoroughly regression-tested against the old version, option by option? Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current from yesterday during boot
on 27/06/2012 08:27 Andrey Fesenko said the following: On Wed, Jun 27, 2012 at 9:06 AM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, I am getting a panix when I boot a newly compiled system with sources downloaded yesterday. The panic was still there with the sources from three days ago. The panic regards /usr/src/sys/vm/uma_core/c line 2040. The machine is a Lenovo X220. I do not expect anything specific loaded yet as I load the Intel KMS module manually after the system is up and running on the console. confirm faced with the same error FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237565 You haven't provided a full stack trace, but let me take a guess: http://article.gmane.org/gmane.os.freebsd.devel.cvs/477167 Perhaps this could be useful. -- 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] BSD sort is the default sort in -CURRENT
-Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Tuesday, June 26, 2012 11:18 PM To: Gabor Kovesdan Cc: FreeBSD Current; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Of course it was performance-tested. As this is a totally different program with different algorithms, it has totally different performance profile on different tests, comparing to the old sort. In the default compilation mode (single thread sort) the performance is on the same level as the old sort (sometimes faster, sometimes slower). The new sort is often significantly faster in numeric sort tests. In experimental multi-threading mode, the new sort is much faster than the old sort on multi-CPU systems. The sort speed comparison is not actually fair because the old sort cuts some corners and has a number of bugs. The concrete figures do not have much sense because you change the sort file and you get a totally different performance ratio. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Has this been thoroughly regression-tested against the old version, option by option? Of course we have the regression tests. We have an overnight test that runs through probably 17 millions various sort option combinations. But we actually had to compare the new sort against a fresh GNU sort implementation (version 8.15), because the old BSD GNU sort is very buggy and testing against the old GNU sort has no sense. Oleg ___ 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] BSD sort is the default sort in -CURRENT
On 06/26/2012 11:48 PM, Oleg Moskalenko wrote: -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Tuesday, June 26, 2012 11:18 PM To: Gabor Kovesdan Cc: FreeBSD Current; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Of course it was performance-tested. Great, can you post the results somewhere? I understand what you're saying below that there are situations where worse performance may need explanation, but it would be helpful if we had the data to look at. As this is a totally different program with different algorithms, it has totally different performance profile on different tests, comparing to the old sort. In the default compilation mode (single thread sort) the performance is on the same level as the old sort (sometimes faster, sometimes slower). The new sort is often significantly faster in numeric sort tests. In experimental multi-threading mode, the new sort is much faster than the old sort on multi-CPU systems. This sounds encouraging. Is there a knob to enable the threaded build? The sort speed comparison is not actually fair because the old sort cuts some corners and has a number of bugs. Understood, but the existing sort is what we're changing away from, so that's what we have to test against. What we don't want is a situation where we are switching to the new sort by default without understanding what the tradeoffs are. (IOW, we don't want a repeat of the situation with grep.) The concrete figures do not have much sense because you change the sort file and you get a totally different performance ratio. I'm assuming that you'd run the performance tests on various different input files, and report the different results. Has this been thoroughly regression-tested against the old version, option by option? Of course we have the regression tests. We have an overnight test that runs through probably 17 millions various sort option combinations. This sounds great, but ... But we actually had to compare the new sort against a fresh GNU sort implementation (version 8.15), because the old BSD GNU sort is very buggy and testing against the old GNU sort has no sense. ... this not so much. The existing sort is what people have now, and what they rely on, particularly for scripts. Comparing apples to oranges doesn't help us understand how things are going to be different with the new version. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current from yesterday during boot
Hi, On Wednesday 27 June 2012 13:20:10 Andriy Gapon wrote: on 27/06/2012 08:27 Andrey Fesenko said the following: On Wed, Jun 27, 2012 at 9:06 AM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, I am getting a panix when I boot a newly compiled system with sources downloaded yesterday. The panic was still there with the sources from three days ago. The panic regards /usr/src/sys/vm/uma_core/c line 2040. The machine is a Lenovo X220. I do not expect anything specific loaded yet as I load the Intel KMS module manually after the system is up and running on the console. confirm faced with the same error FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237565 You haven't provided a full stack trace, but let me take a guess: http://article.gmane.org/gmane.os.freebsd.devel.cvs/477167 this is a direct hit. Perhaps this could be useful. I assume that you do not need one then. Anyway, What would be a save way to get a trace to a disk as I do not have a backup system with me? Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current from yesterday during boot
on 27/06/2012 11:39 Erich Dollansky said the following: Anyway, What would be a save way to get a trace to a disk as I do not have a backup system with me? Assuming I understand the question correctly your options are: - remote console (serial/firewire/etc) from another machine - digital camera - produce a crash dump (possible only after a certain point in boot sequence) -- 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: Panic on current from yesterday during boot
Hi, On Wednesday 27 June 2012 15:42:43 Andriy Gapon wrote: on 27/06/2012 11:39 Erich Dollansky said the following: Anyway, What would be a save way to get a trace to a disk as I do not have a backup system with me? Assuming I understand the question correctly your options are: - remote console (serial/firewire/etc) from another machine this is the problem as I do not have it here. - digital camera So, this is really the only option then. The photos I really have. Would you still need them? I do not think so after seeing the other post. - produce a crash dump (possible only after a certain point in boot sequence) I think that this was too early. Erich ___ 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] BSD sort is the default sort in -CURRENT
Doug, I'll post some performance figures, probably tomorrow. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. If some old scripts are relying on buggy behavior (and I hope they are not) then the old scripts must be fixed. Period. The system cannot grow replicating the old bugs. All system scripts that I've seen are using pretty basic sort features. In the basic area, the old sort and the new sort are 100% compatible. The incompatibilities are in more complex areas (numeric sorts and unusual key-based sorts). I am actually tested the new sort against the old GNU sort. There are some incompatibilities. All of them are due to the bugs of the old GNU sort. The new BSD sort program is compatible with the new GNU sort, a much cleaner program than the old GNU sort. Try to install the new GNU coreutils. If the scripts can work with the new GNU sort (version 8.15 and later) than they will work with the new BSD sort. There is a POSIX standard, and the program must be compatible with the POSIX standard. Take care, Oleg -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Wednesday, June 27, 2012 1:35 AM To: Oleg Moskalenko Cc: Gabor Kovesdan; FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/26/2012 11:48 PM, Oleg Moskalenko wrote: -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Tuesday, June 26, 2012 11:18 PM To: Gabor Kovesdan Cc: FreeBSD Current; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Of course it was performance-tested. Great, can you post the results somewhere? I understand what you're saying below that there are situations where worse performance may need explanation, but it would be helpful if we had the data to look at. As this is a totally different program with different algorithms, it has totally different performance profile on different tests, comparing to the old sort. In the default compilation mode (single thread sort) the performance is on the same level as the old sort (sometimes faster, sometimes slower). The new sort is often significantly faster in numeric sort tests. In experimental multi-threading mode, the new sort is much faster than the old sort on multi-CPU systems. This sounds encouraging. Is there a knob to enable the threaded build? The sort speed comparison is not actually fair because the old sort cuts some corners and has a number of bugs. Understood, but the existing sort is what we're changing away from, so that's what we have to test against. What we don't want is a situation where we are switching to the new sort by default without understanding what the tradeoffs are. (IOW, we don't want a repeat of the situation with grep.) The concrete figures do not have much sense because you change the sort file and you get a totally different performance ratio. I'm assuming that you'd run the performance tests on various different input files, and report the different results. Has this been thoroughly regression-tested against the old version, option by option? Of course we have the regression tests. We have an overnight test that runs through probably 17 millions various sort option combinations. This sounds great, but ... But we actually had to compare the new sort against a fresh GNU sort implementation (version 8.15), because the old BSD GNU sort is very buggy and testing against the old GNU sort has no sense. ... this not so much. The existing sort is what people have now, and what they rely on, particularly for scripts. Comparing apples to oranges doesn't help us understand how things are going to be different with the new version. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current from yesterday during boot
On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon a...@freebsd.org wrote: on 27/06/2012 11:39 Erich Dollansky said the following: Anyway, What would be a save way to get a trace to a disk as I do not have a backup system with me? Assuming I understand the question correctly your options are: - remote console (serial/firewire/etc) from another machine - digital camera - produce a crash dump (possible only after a certain point in boot sequence) FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631 https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/D1c/Ix6X8dkyX9k/s868/IMG_4147.jpg In the VirtualBox this system boot no error. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current from yesterday during boot
on 27/06/2012 11:49 Erich Dollansky said the following: Hi, On Wednesday 27 June 2012 15:42:43 Andriy Gapon wrote: on 27/06/2012 11:39 Erich Dollansky said the following: Anyway, What would be a save way to get a trace to a disk as I do not have a backup system with me? Assuming I understand the question correctly your options are: - remote console (serial/firewire/etc) from another machine this is the problem as I do not have it here. - digital camera So, this is really the only option then. The photos I really have. Would you still need them? I do not think so after seeing the other post. Not really, I think that you've already confirmed that that is the same issue. I just listed possibilities for future reference. - produce a crash dump (possible only after a certain point in boot sequence) I think that this was too early. Yes. -- 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] BSD sort is the default sort in -CURRENT
On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. If some old scripts are relying on buggy behavior (and I hope they are not) then the old scripts must be fixed. Period. With respect, that's not your decision (or mine for that matter). We first need the data, then as a project we decide how many old bugs we want to be compatible with, if any. The system cannot grow replicating the old bugs. And the project cannot grow if we lose users due to gratuitous differences in core utilities. All system scripts that I've seen are using pretty basic sort features. The system scripts are only a tiny fraction of how FreeBSD users use sort. In the basic area, the old sort and the new sort are 100% compatible. The incompatibilities are in more complex areas (numeric sorts and unusual key-based sorts). So here's one to add to your regression test. I use the following to sort IPv4 addresses in a list: sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4 When used with GNU sort that will sort a list of IPv4 addresses into a humanly-recognizable numeric order. Please ensure that this works the same way with the new sort. I am actually tested the new sort against the old GNU sort. There are some incompatibilities. All of them are due to the bugs of the old GNU sort. Please list all of those explicitly. The new BSD sort program is compatible with the new GNU sort, a much cleaner program than the old GNU sort. That's good, but not really relevant to the users of what we have in the base now. I realize that these questions may seem discouraging, but they need to be answered. It would have been nice if Gabor had posted a we think we're ready to make the new sort the default, any last concerns? message, but deal with where we are at and move forward. thanks, Doug ___ 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] BSD sort is the default sort in -CURRENT
On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? I believe we do not make this kind of work with any vendor code that is being updated in the base; I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. -- Kind regards Daniel ___ 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] BSD sort is the default sort in -CURRENT
Daniel Gerzo dan...@freebsd.org: On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? I believe we do not make this kind of work with any vendor code that is being updated in the base; I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. Seconded for -CURRENT. I think, we should at least provide some brief document, whatsoever on incompatibilities with the sort implementation that is currently active in RELENG_9, no matter how buggy it is. This allows adopters and people, who have to migrate their production systems to identify and quantify the areas to change and perform some risk management. This also allows them to move more quickly to the new release, since they can start with the necessary changes earlier and plan ahead. We provide such changes usually in the release notes for various tools, we updated and I think that giving out such a document earlier will be extremely benefitial for companies, which have to deal with more than one or two servers running FreeBSD, especially if we know that the currently shipped implementation is buggy and people most likely will have their own workarounds for that. Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current from yesterday during boot
On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko f0and...@gmail.com wrote: On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon a...@freebsd.org wrote: on 27/06/2012 11:39 Erich Dollansky said the following: Anyway, What would be a save way to get a trace to a disk as I do not have a backup system with me? Assuming I understand the question correctly your options are: - remote console (serial/firewire/etc) from another machine - digital camera - produce a crash dump (possible only after a certain point in boot sequence) FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631 https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/D1c/Ix6X8dkyX9k/s868/IMG_4147.jpg In the VirtualBox this system boot no error. FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237635M: Wed Jun 27 13:51:55 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/GENERIC amd64 if use patch http://people.freebsd.org/~jkim/evxfgpe.diff boot no error ___ 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] BSD sort is the default sort in -CURRENT
On 06/27/2012 03:02 AM, Daniel Gerzo wrote: On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? If the compatibility with the existing version were so dramatically different as Oleg claims, then yes, that would be a basic element of the replacement project. I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. The first question is, where is it not compatible with the existing sort that's already in the base. The second question is, how well does it perform vs. the existing sort. I think those are perfectly reasonable questions to ask, and frankly they should have been answered before the switch was made. We already went through this with BSD grep, I hope we can avoid a repeat. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current from yesterday during boot
on 27/06/2012 13:44 Andrey Fesenko said the following: On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko f0and...@gmail.com wrote: On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon a...@freebsd.org wrote: on 27/06/2012 11:39 Erich Dollansky said the following: Anyway, What would be a save way to get a trace to a disk as I do not have a backup system with me? Assuming I understand the question correctly your options are: - remote console (serial/firewire/etc) from another machine - digital camera - produce a crash dump (possible only after a certain point in boot sequence) FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631 https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/D1c/Ix6X8dkyX9k/s868/IMG_4147.jpg In the VirtualBox this system boot no error. FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237635M: Wed Jun 27 13:51:55 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/GENERIC amd64 if use patch http://people.freebsd.org/~jkim/evxfgpe.diff boot no error Thank you for the confirmation. -- 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: -CURRENT Panic at boot at Revision: 237264 mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105
Hi, Just a quick ping to make sure this isnt forgotten. Would it help if I open a PR? regards, Vince On 21/06/2012 19:34, John Baldwin wrote: On Thursday, June 21, 2012 12:41:59 pm Vincent Hoffman wrote: Hi again, The 2nd patch (to if.h and if_gif.c) also fixes the panic on boot. Thanks for the quick response as ever. Great, thanks for testing! Randall, do you have any thoughts on these patches? Vince ___ 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: [CFC/CFT] large changes in the loader(8) code
On Wednesday, June 27, 2012 12:50:20 am Andrey V. Elsukov wrote: On 26.06.2012 21:37, John Baldwin wrote: 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. The standard says: The following test must be performed to determine if a GPT is valid: • Check the Signature • Check the Header CRC • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table • Check the CRC of the GUID Partition Entry Array If the GPT is the primary table, stored at LBA 1: • Check the AlternateLBA to see if it is a valid GPT If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. Right, we break the last rule. If you want to use a partition editor that doesn't grok gmirror (because you are using another OS's editor), to repair a GPT, it will do the wrong thing. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partition editor, it might overwrite the last sector and might don't. I would not assume it would work at all. If it can't trust the primary GPT, it has to assume the alternate is at the last LBA. 5. Also the pmbr image now contains one fake partition record. When several first sectors are damaged the kernel can't detect GPT (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) command, but the old pmbr image has an empty partition table and loader doesn't able to boot from GPT, when there is no partition record in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' command, the kernel correctly modifies this partition record. So, this is only for the first rescue step. As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class. It only sends control requests to the kernel. If GPT is not detected, there is no geom objects to manage. And we can't write bootcode with gpart(8). I think that adding such functions to the gpart(8) is not good. Maybe, the boot0cfg is the better tool for that. Also we still haven't any tool to install zfsboot. We can't write bootcode with gpart? What do you think the 'bootcode' command does? Also, there is no reason we can't have a 'recover' command that attempts to recover a corrupted table including repairing the PMBR. gpart(8) already generates a full PMBR when you use 'gpart create' to create a GPT even though there isn't a GPT object yet. -- John Baldwin ___ 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: [CFC/CFT] large changes in the loader(8) code
On Tuesday, June 26, 2012 5:23:08 pm Pawel Jakub Dawidek wrote: On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. [...] My interpretation is different: The way to verify if the header is valid is to check its checksum, not to check if the backup header location in the primary header points at the last LBA. Of course if primary header's checksum is incorrect it is hard to trust that the backup header location is correct. And we need the backup header when the primary header is invalid... Right, which is why this fails. [...] It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. I don't think so. Most common case is to configure partitions on top of a mirror. Mirroring partitions is less common. Mostly because of hardware RAIDs being popular. You don't expect hardware RAID vendor to mirror partitions. Partition editors for other OS's won't work, but only because they don't support gmirror. If they wouldn't recognize and support some hardware (or pseudo-hardware) RAIDs there will be the same problem. Hardware RAIDs hide the metadata from the disk that the BIOS (and disk editors) see. Thus, putting a GPT on a hardware RAID volume works fine as the logical volume is always seen by all OS's consistently. The same is even true of the software RAID that graid supports since the metadata is defined by the vendor and thus the logical volume is always seen other OS's consistently. My approach has been to only use gmirror with MBR so far, though I realize that doesn't work above 2TB (until recently one had to have a hardware RAID to get above 2TB anyway which made this last a moot point). I won't object to patch our tools to handle this, but I think it is a really bad idea that users will have a hard way to recover from when they are bitten by it. -- John Baldwin ___ 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: [CFC/CFT] large changes in the loader(8) code
On 27.06.2012 16:07, John Baldwin wrote: • Check the Signature • Check the Header CRC • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table • Check the CRC of the GUID Partition Entry Array If the GPT is the primary table, stored at LBA 1: • Check the AlternateLBA to see if it is a valid GPT If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. Right, we break the last rule. If you want to use a partition editor that doesn't grok gmirror (because you are using another OS's editor), to repair a GPT, it will do the wrong thing. When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class. It only sends control requests to the kernel. If GPT is not detected, there is no geom objects to manage. And we can't write bootcode with gpart(8). I think that adding such functions to the gpart(8) is not good. Maybe, the boot0cfg is the better tool for that. Also we still haven't any tool to install zfsboot. We can't write bootcode with gpart? What do you think the 'bootcode' command does? `gpart bootcode -b` reads file, creates ioctl request and sends this data to the GEOM_PART class. GEOM_PART receives the control request, checks the data and writes it to the provider. `gpart bootcode -p` works like dd(1) and writes bootcode to the given partition. gpart(8) haven't any knowledge about specific partitioning scheme. Also, there is no reason we can't have a 'recover' command that attempts to recover a corrupted table including repairing the PMBR. gpart(8) already generates a full PMBR when you use 'gpart create' to create a GPT even though there isn't a GPT object yet. `gpart create` creates only ioctl control request to the GEOM_PART class. GEOM_PART class creates new GPT geom object and this objects writes PMBR and its metadata to the provider. -- WBR, Andrey V. Elsukov ___ 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: [CFC/CFT] large changes in the loader(8) code
On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote: I don't think so. Most common case is to configure partitions on top of a mirror. Mirroring partitions is less common. Mostly because of hardware RAIDs being popular. You don't expect hardware RAID vendor to mirror partitions. Partition editors for other OS's won't work, but only because they don't support gmirror. If they wouldn't recognize and support some hardware (or pseudo-hardware) RAIDs there will be the same problem. Hardware RAIDs hide the metadata from the disk that the BIOS (and disk editors) see. Thus, putting a GPT on a hardware RAID volume works fine as the logical volume is always seen by all OS's consistently. [...] Only if you won't connect this disk to a different controller. [...] The same is even true of the software RAID that graid supports since the metadata is defined by the vendor and thus the logical volume is always seen other OS's consistently. But is it seen without metadata by the boot loader? What I'm trying to say is that it is fair to expect from the user to not use gmirror-configured disk on different OS. If the user wants to use this disk in different OS then he has to use format that is recognized by both. Because gmirror is supported by FreeBSD we should improve the support by teaching boot loader about it. Pretending gmirror is special and recommending to mirror partitions with it instead of raw disks is not the solution. I really can't see how gmirror is different in this regard from any other software RAID or volume manager. If you try to use disk that contains unrecognized metadata the behaviour is undefined (but hopefully not a panic). -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpQmYWVuPgKs.pgp Description: PGP signature
Re: Removing an SDHC card causes a kernel panic on -current
On 06/26/12 22:29, Kenneth D. Merry wrote: On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote: On Tue, 26 Jun 2012, Michael Butler wrote: As follows, in g_disk_providergone, a NULL pointer reference?: g_disk_providergone() is new in r237518 (by ken); ken cc'd. Can you try the attached patch to sys/geom/geom_disk.c? This fixes the panic :-) Also, do you have full dmesg information for when the panic happened? It looks like disk_destroy() has already been called in this case, and I suppose that's likely to happen for any of the users of the GEOM disk class that haven't been updated with the reference count changes I made in da(4). (i.e. all of the rest of them.) Let me know whether this works for you. All I have is the following leading up to my removal of the card (and the restart afterwards): Jun 26 08:57:11 toshi kernel: sdhci0-slot0: Card inserted Jun 26 08:57:11 toshi kernel: mmc0: MMC/SD bus on sdhci0 Jun 26 08:57:11 toshi kernel: mmc0: Probing bus Jun 26 08:57:11 toshi kernel: mmc0: SD probe: OK (OCR: 0x00ff8000) Jun 26 08:57:11 toshi kernel: mmc0: Current OCR: 0x00ff8000 Jun 26 08:57:11 toshi kernel: mmc0: Probing cards Jun 26 08:57:11 toshi kernel: mmc0: New card detected (CID 03534453553136478080d4290400a300) Jun 26 08:57:11 toshi kernel: mmc0: New card detected (CSD 400e00325b5976b27f800a404000) Jun 26 08:57:11 toshi kernel: mmc0: Card at relative address 36832 added: Jun 26 08:57:11 toshi kernel: mmc0: card: SDHC SU16G 8.0 SN -2133579516 MFG 03/2010 by 3 SD Jun 26 08:57:11 toshi kernel: mmc0: bus: 4bit, 50MHz, high speed timing Jun 26 08:57:11 toshi kernel: mmc0: memory: 31116288 blocks, erase sector 8192 blocks Jun 26 08:57:12 toshi kernel: mmc0: setting transfer rate to 25.000MHz Jun 26 08:57:12 toshi kernel: mmcsd0: 14GB SDHC SU16G 8.0 SN -2133579516 MFG 03/2010 by 3 SD at mmc0 24.0MHz/4bit/65535-block Jun 26 08:57:12 toshi kernel: GEOM: new disk mmcsd0 Jun 26 08:57:12 toshi kernel: mmc0: setting bus width to 4 bits Jun 26 08:58:44 toshi syslogd: kernel boot file is /boot/kernel/kernel Jun 26 08:58:44 toshi kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jun 26 08:58:44 toshi kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jun 26 08:58:44 toshi kernel: The Regents of the University of California. All rights reserved. Jun 26 08:58:44 toshi kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. ___ 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] BSD sort is the default sort in -CURRENT
--- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto: ... I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. Really?? I guess you are speaking for bind, because the idea behind updating and piece of software is precisely shaking bugs. New functionality counts but fixing bugs takes the priority. We have three serious bug reports concerning GNU sort and I even submitted an update but no one cared to apply it. I would think only the maintainer of the package has the authority to make any request in the lines of being bug-for-bug compatible and in the case of GNU sort and GNU grep they are both unmaintained and replacements are welcome. Please let's stop being an obstacle towards people bringing real progress to FreeBSD! Pedro. ___ 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] BSD sort is the default sort in -CURRENT
On 06/27/2012 07:30 AM, Pedro Giffuni wrote: --- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto: ... I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. Really?? I guess you are speaking for bind, Nope. because the idea behind updating and piece of software is precisely shaking bugs. Nope. I would think only the maintainer of the package has the authority to make any request in the lines of being bug-for-bug compatible You have a seriously wrong idea of maintainer. The community owns the software, it's up to the community to decide how it should work. Historically we have looked at the maintainer as the person who volunteers to take care of code, not the person who has the exclusive lock on it. and in the case of GNU sort and GNU grep they are both unmaintained and replacements are welcome. Actually both are maintained, it's just that we don't want to import the new GNU versions. And yes, having BSD versions of these core tools is a nice goal, but it's not one we should pursue for its own sake. Please let's stop being an obstacle towards people bringing real progress to FreeBSD! In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? Doug ___ 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] BSD sort is the default sort in -CURRENT
--- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto: ... Nope. I would think only the maintainer of the package has the authority to make any request in the lines of being bug-for-bug compatible You have a seriously wrong idea of maintainer. The community owns the software, it's up to the community to decide how it should work. You have a serious wrong idea of ownership. No one really owns the code and only few people actually take the time to take care of it. Historically we have looked at the maintainer as the person who volunteers to take care of code, not the person who has the exclusive lock on it. The maintainer, in this context, doesn't have to be a committer but it has to be someone that spends time fixing bugs or enhancing the code. You might think that because you use the code and are used to certain bug that you depend on that you somehow have a say on how it shall behave in the future but that is simply an illusion. and in the case of GNU sort and GNU grep they are both unmaintained and replacements are welcome. Actually both are maintained, it's just that we don't want to import the new GNU versions. Our forks of such packages are unmaintained. I did the work (TM) of updating GNU sort and no one cared to commit it. Oleg, took as reference the latest upstream sort implementation. And yes, having BSD versions of these core tools is a nice goal, but it's not one we should pursue for its own sake. Having something that we can maintain is a goal we should pursue for it's own sake. Please let's stop being an obstacle towards people bringing real progress to FreeBSD! In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. Performance was an issue and in general it was a good decision that even the coder involved agreed upon. Once the issue is within acceptable limits, and there has been progress on this as I understand, BSD grep will be back. Don't expect BSD grep to support something different than posix behaviour though. So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? How about rationally pointing out your issues with the new BSD sort? Any regression that you want to report? Pedro. ___ 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
Occassional permission denied in the middle of a large transfer over NFS
Hi, After only one off-list reply from the author of kern/136865 (see below) after asking -questions, I thought it worth asking -CURRENT. Basically: I seem to have run into the problems described in this old thread. http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html tl:dr mountd may give incorrect permission denied errors when it is refreshing the exports list due to non-atomic operations, /sbin/mount has code that sends SIGHUP to mountd on any mount operation, which implies that any manual mount request would cause the problem. Currently I have still only tested on 8.3-RELEASE but the svn log doesnt seem to mention a fix since then. I'm currently taking a VM up to -CURRENT to test. Looking though old PRs I see the following related. kern/131342 kern/136865 (with patch for 7.2 and links to http://nfse.sourceforge.net/ for -CURRENT ) Does anyone who is qualified (sadly not me) feel like looking at the code to see if its suitable for inclusion in part/whole as not having NFS transfers interrupted by local mount operations on the nfs server would be very handy :) thanks, Vince ___ 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: Tmpfs panic in -current
On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote:
Kevin Lo wrote:
Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627
address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel
trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid ==
VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx,
NULL, NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is
zero,
so I do not understand why the asserted block was executed at all.
Thanks for looking into it. Unfortunately I can't get a crash dump
due to lack of disk space and memory.
I triggered the KASSERT on a different machine in the last hour.
It is not 'the' KASSERT, it is something different.
Are you sure that you do not have some systematic build issues on your
machines ? Although I do not think that tmpfs is 'ready for production use'
for arbitrary low value of this statement, there is no steady flow of
similar reports from other users. This makes me somewhat suspicious that
either you might have inconsistent build issues, or unrelated memory
corruption problems.
panic: Assertion (vp) !=NULL (vp)-v_data != NULL failed at
@/fs/tmpfs/tmpfs.h:527
The bad news is my coworker rebooted that machine after panic :-(
Kevin
pgpNw7ZYZRW88.pgp
Description: PGP signature
Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities
On 27/06/2012 02:11, Devin Teske wrote:
Fixed.
Thanks!
The mouse daemon flags text still seems to have an upper-case 'S'
('Please Specify').
--
Bruce Cran
___
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] BSD sort is the default sort in -CURRENT
-Original Message- But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. The problem is that the sort program has huge number of possible options combination. I can list some, but I cannot promise to catch all of them. It would be enormous work. If some old scripts are relying on buggy behavior (and I hope they are not) then the old scripts must be fixed. Period. With respect, that's not your decision (or mine for that matter). We first need the data, then as a project we decide how many old bugs we want to be compatible with, if any. This is an incorrect approach. You never want old bugs we want to be compatible with in a clean POSIX-compliant system. The system cannot grow replicating the old bugs. And the project cannot grow if we lose users due to gratuitous differences in core utilities. There are users that we are loosing because the utilities do not work as expected. For example, a common complain is about a situation like that: try run a trivial command like $ ls -l /usr/bin | env LANG=en_US.UTF-8 sort -n -k 5 and see what it yields for the old BSD/GNU sort. I suspect that when you are talking about the old sort compatibility you are really do not know what you are talking about. Once you start digging, you prospective may change. All system scripts that I've seen are using pretty basic sort features. The system scripts are only a tiny fraction of how FreeBSD users use sort. This is even stronger emphasizes the need in a standard-compliant implementation. In the basic area, the old sort and the new sort are 100% compatible. The incompatibilities are in more complex areas (numeric sorts and unusual key-based sorts). So here's one to add to your regression test. I use the following to sort IPv4 addresses in a list: sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4 When used with GNU sort that will sort a list of IPv4 addresses into a humanly-recognizable numeric order. Please ensure that this works the same way with the new sort. First, this is a pretty trivial use case. Don't expect anything different in the trivial cases. I think that 99% of users will never see the difference between the old sort and the new sort - for a usual non-expert usage the two are almost always compatible. Second, do you really think that I need lecturing which use cases to test ? I am actually tested the new sort against the old GNU sort. There are some incompatibilities. All of them are due to the bugs of the old GNU sort. Please list all of those explicitly. see above. The new BSD sort program is compatible with the new GNU sort, a much cleaner program than the old GNU sort. That's good, but not really relevant to the users of what we have in the base now. I bet many of them are installing the new GNU coreutils exactly for the reasons of better performance and compatibility. I realize that these questions may seem discouraging, but they need to be answered. It would have been nice if Gabor had posted a we think we're ready to make the new sort the default, any last concerns? message, but deal with where we are at and move forward. He actually did. You probably missed the messages. Thanks, Oleg ___ 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: Removing an SDHC card causes a kernel panic on -current
On Wed, Jun 27, 2012 at 10:22:59 -0400, Michael Butler wrote: On 06/26/12 22:29, Kenneth D. Merry wrote: On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote: On Tue, 26 Jun 2012, Michael Butler wrote: As follows, in g_disk_providergone, a NULL pointer reference?: g_disk_providergone() is new in r237518 (by ken); ken cc'd. Can you try the attached patch to sys/geom/geom_disk.c? This fixes the panic :-) Great! I just committed it. Also, do you have full dmesg information for when the panic happened? It looks like disk_destroy() has already been called in this case, and I suppose that's likely to happen for any of the users of the GEOM disk class that haven't been updated with the reference count changes I made in da(4). (i.e. all of the rest of them.) Let me know whether this works for you. All I have is the following leading up to my removal of the card (and the restart afterwards): Thanks! Ken -- Kenneth Merry k...@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: [HEADS-UP] BSD sort is the default sort in -CURRENT
Marcus, I'll provide some incompatibilities description, as many as I can do. Thanks Oleg -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Marcus von Appen Sent: Wednesday, June 27, 2012 3:40 AM To: freebsd-current@freebsd.org Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT Daniel Gerzo dan...@freebsd.org: On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? I believe we do not make this kind of work with any vendor code that is being updated in the base; I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. Seconded for -CURRENT. I think, we should at least provide some brief document, whatsoever on incompatibilities with the sort implementation that is currently active in RELENG_9, no matter how buggy it is. This allows adopters and people, who have to migrate their production systems to identify and quantify the areas to change and perform some risk management. This also allows them to move more quickly to the new release, since they can start with the necessary changes earlier and plan ahead. We provide such changes usually in the release notes for various tools, we updated and I think that giving out such a document earlier will be extremely benefitial for companies, which have to deal with more than one or two servers running FreeBSD, especially if we know that the currently shipped implementation is buggy and people most likely will have their own workarounds for that. Cheers Marcus ___ 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: Panic on current from yesterday during boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-06-27 07:07:40 -0400, Andriy Gapon wrote: on 27/06/2012 13:44 Andrey Fesenko said the following: On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko f0and...@gmail.com wrote: On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon a...@freebsd.org wrote: on 27/06/2012 11:39 Erich Dollansky said the following: Anyway, What would be a save way to get a trace to a disk as I do not have a backup system with me? Assuming I understand the question correctly your options are: - remote console (serial/firewire/etc) from another machine - digital camera - produce a crash dump (possible only after a certain point in boot sequence) FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631 https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/D1c/Ix6X8dkyX9k/s868/IMG_4147.jpg In the VirtualBox this system boot no error. FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237635M: Wed Jun 27 13:51:55 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/GENERIC amd64 if use patch http://people.freebsd.org/~jkim/evxfgpe.diff boot no error Thank you for the confirmation. Committed as r237652: http://svnweb.freebsd.org/base?view=revisionrevision=237652 I really wanted to get confirmation from ACPICA developers first but I had no choice. :-( Sorry for the delay, Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/rMrkACgkQmlay1b9qnVOg5gCeNcFWPjIcqTN3DyQttmtLC5bN EskAn083+eY8WWer4AFhYtT5pkmkmV+F =PKC4 -END PGP SIGNATURE- ___ 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] BSD sort is the default sort in -CURRENT
On Wed, Jun 27, 2012 at 9:56 AM, Doug Barton do...@freebsd.org wrote: On 06/27/2012 07:30 AM, Pedro Giffuni wrote: --- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto: ... I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. Really?? I guess you are speaking for bind, Nope. because the idea behind updating and piece of software is precisely shaking bugs. Nope. I would think only the maintainer of the package has the authority to make any request in the lines of being bug-for-bug compatible You have a seriously wrong idea of maintainer. The community owns the software, it's up to the community to decide how it should work. Historically we have looked at the maintainer as the person who volunteers to take care of code, not the person who has the exclusive lock on it. and in the case of GNU sort and GNU grep they are both unmaintained and replacements are welcome. Actually both are maintained, it's just that we don't want to import the new GNU versions. And yes, having BSD versions of these core tools is a nice goal, but it's not one we should pursue for its own sake. Please let's stop being an obstacle towards people bringing real progress to FreeBSD! In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? Doug, I think you need to give it a chance. I do not see any problem for anyone to switch the default and if the problems discover then switch the default back. It's a bleeding edge branch where more people can test it. The issue with grep was very harmeless and it was not difficult to switch the default between GNU and BSD. It's not like they threw GNU grep/sort away quickly. How come that I haven't heard anything from you about the jemalloc update? If you did then I must have missed it. It was very clearly that it was not test and he doesn't handle it very well, but got fixed evenly with the multi-commit. It was worst than grep/sort and other projects. If you are wondering why it's you. Because lately you are starting to whine a lot without give the things chance. If we are doing your way and nothing will moving on. Doug -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities
On Jun 27, 2012, at 8:58 AM, Bruce Cran wrote:
On 27/06/2012 02:11, Devin Teske wrote:
Fixed.
Thanks!
The mouse daemon flags text still seems to have an upper-case 'S' ('Please
Specify').
Oops, forgot that one. Thanks Bruce!
Fixed.
--
Devin
NOTE: I probably won't be rushing to roll a new port version for this change;
just know that it will make it into the next snapshot (and has been made to the
tree that will be imported to HEAD later, if there aren't any other issues
reported by end-of-day).
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
___
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: [CFC/CFT] large changes in the loader(8) code
On Wednesday, June 27, 2012 10:08:17 am Pawel Jakub Dawidek wrote: On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote: I don't think so. Most common case is to configure partitions on top of a mirror. Mirroring partitions is less common. Mostly because of hardware RAIDs being popular. You don't expect hardware RAID vendor to mirror partitions. Partition editors for other OS's won't work, but only because they don't support gmirror. If they wouldn't recognize and support some hardware (or pseudo-hardware) RAIDs there will be the same problem. Hardware RAIDs hide the metadata from the disk that the BIOS (and disk editors) see. Thus, putting a GPT on a hardware RAID volume works fine as the logical volume is always seen by all OS's consistently. [...] Only if you won't connect this disk to a different controller. Yes, but people do not expect to be able to yank a hardware RAID drive out and hook it up to a raw disk controller and have it work. [...] The same is even true of the software RAID that graid supports since the metadata is defined by the vendor and thus the logical volume is always seen other OS's consistently. But is it seen without metadata by the boot loader? Yes. The logical volume shows up as a BIOS disk device. What I'm trying to say is that it is fair to expect from the user to not use gmirror-configured disk on different OS. If the user wants to use this disk in different OS then he has to use format that is recognized by both. Because gmirror is supported by FreeBSD we should improve the support by teaching boot loader about it. Pretending gmirror is special and recommending to mirror partitions with it instead of raw disks is not the solution. I really can't see how gmirror is different in this regard from any other software RAID or volume manager. If you try to use disk that contains unrecognized metadata the behaviour is undefined (but hopefully not a panic). It is not gmirror I am complaining about, it is the non-standard use of GPT. Note that gmirror + MBR works fine without violating what little standard there is for the MBR. Using a dedicated GPT partition to hold the gmirrror metadata would work with GPT (but be a good bit harder to work with in terms of GEOM I realize). But as I said, I won't object to these patches. -- John Baldwin ___ 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: [CFC/CFT] large changes in the loader(8) code
On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: On 27.06.2012 16:07, John Baldwin wrote: • Check the Signature • Check the Header CRC • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table • Check the CRC of the GUID Partition Entry Array If the GPT is the primary table, stored at LBA 1: • Check the AlternateLBA to see if it is a valid GPT If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. Right, we break the last rule. If you want to use a partition editor that doesn't grok gmirror (because you are using another OS's editor), to repair a GPT, it will do the wrong thing. When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) Ah, yes. The solution to violating standards is to make sure you never use standards-compliant software. That's a great argument. :) (Although not entirely uncommon. Standards aren't always perfect, but if we had a way to not gratuitously violate them it would be nice to avoid doing so.) We can't write bootcode with gpart? What do you think the 'bootcode' command does? `gpart bootcode -b` reads file, creates ioctl request and sends this data to the GEOM_PART class. GEOM_PART receives the control request, checks the data and writes it to the provider. `gpart bootcode -p` works like dd(1) and writes bootcode to the given partition. gpart(8) haven't any knowledge about specific partitioning scheme. Correct, but in both cases it writes bootcode. Also, there is no reason we can't have a 'recover' command that attempts to recover a corrupted table including repairing the PMBR. gpart(8) already generates a full PMBR when you use 'gpart create' to create a GPT even though there isn't a GPT object yet. `gpart create` creates only ioctl control request to the GEOM_PART class. GEOM_PART class creates new GPT geom object and this objects writes PMBR and its metadata to the provider. You can't add a new ioctl? -- John Baldwin ___ 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: [CFC/CFT] large changes in the loader(8) code
On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. Agreed. While it is a nice trick to use the last sector for meta data, it does create 2 problems. 1 is mentioned above. The second is that when there's different metadata in the first *and* the last sector, you can't decide which is to take precedence without also looking at the other and know how to interpret it. We have not solved this second problem at all. We do get reports about the problems though. At best we're handwaving or kluging. I think it's unwise to depend on FreeBSD-specific extensions or features in industry-standard partitioning schemes and as such make the use of foreign tools hard if not impossible. A much more flexible approach is to support out-of-band configuration data. This allows us to mirror GPT disks without having to become non- standard as it removes the need to use the last sector for meta-data. The ability to construct GEOM hierarchies unambiguously is very important and our current approach has proven to not deliver on that. This is actually impacting existing FreeBSD consumers already, like Juniper. So, se should not go deeper into this rabbit hole. We should finally solve this problem for real... -- Marcel Moolenaar mar...@xcllnt.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: [HEADS-UP] BSD sort is the default sort in -CURRENT
I officially withdraw from the discussion. I hope it all works out well. ___ 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: [CFC/CFT] large changes in the loader(8) code
On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: As for sharing disk with other OS. If you share the disk with OS that doesn't support gmirror, you shouldn't use gmirror in the first place. You probably want to use only formats that are recognized by all your OSes. This statement is ridicuous by virtue of not being in touch with reality and by making gmirror useless for such wide range of cases that one can question why we have it at all. Put differently: a mirroring class is a fairly basic and useful thing to have. Limiting it's use is nothing but artificial and follows from having to use the underlying provider to store metadata. This then changes the view of the underlying providing to consumers above gmirror in a way that makes the presence or absence of gmirror visible. Solving the visibility problem makes gmirror useful all the time. I see that as a better way of looking at it than simply blurting out that you shouldn't use gmirror when certain awkward and artifical conditions apply. -- Marcel Moolenaar mar...@xcllnt.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: [HEADS-UP] BSD sort is the default sort in -CURRENT
Ah, I just tried sort on freebsd (5.3.0) versus sort on macosx 10.6 (5.93) - what a strange bug. We _could've_ fixed this with an import of the latest gnu sort and then migrated to a feature/bug compatible bsdsort, but I do see your point(s). :-) There's a fine line to walk between keeping POLA and making progress. Just be careful you don't stray too far to the Linux side of that. (And be careful of staying too close to the POLA side of it.) 2c, and great work! adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On Jun 26, 2012, at 9:50 PM, Andrey V. Elsukov wrote: If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. For the FreeBSD an each GEOM provider can be treated as disk device. So, i don't see anything criminal if we will add some quirks in the our loader for the better supporting of our technologies. You can't just re-interpret standards to match a context you know very well isn't applicable and consequently redefine what the word device means. You're on a slippery slope and while you may not see it as a problem, you do make it a problem for FreeBSD users. It's our users we should be keeping in mind when we solve problems. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partition editor, it might overwrite the last sector and might don't. Right. Another happy user that sees his/her FreeBSD installation destroyed or degraded (no mirroring, warning messages about corrupted GPT, etc) for no apparent reason and without any kind of warning that what he/she is doing is potentially harmful... That's the spirit! -- Marcel Moolenaar mar...@xcllnt.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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 2012-06-27 08:04, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor Thanks, I'm running textproc/bsdsort now a view weeks as BASE replacement on 8.3 and haven't seen any issues even on files with a view GB. Are you planing to update the port with your latest version? -- Regards, olli ___ 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] BSD sort is the default sort in -CURRENT
On Jun 27, 2012, at 8:56 AM, Doug Barton wrote: So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? What is your short list of issues? From a high level there appear to be none, but the devil is in the details, eh? From earlier in the thread, bsdsort and gnu sort are compatible. old, crunchy, unmaintained gnu sort that we have in the tree isn't compatible with either new gnu sort nor bsdsort. this means it isn't compatible with what the linux crowd is using, which is another consideration given the number of shell scripts that originate there these days. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote: On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. Agreed. Guys. This doesn't violate the GPT spec in any way. The spec is narrow-minded if it talks only about raw disks, but you should think about gmirror as pseudo-hardware RAID. That's all. If putting GPT on top of RAID array is spec violation, then I guess we just have to live with it. While it is a nice trick to use the last sector for meta data, it does create 2 problems. 1 is mentioned above. [...] It doesn't really matter where gmirror puts its metadata. If gmirror would keep its metadata in the first sector, gpart/gpt will find its metadata in the last sector and will complain about missing primary header. [...] The second is that when there's different metadata in the first *and* the last sector, you can't decide which is to take precedence without also looking at the other and know how to interpret it. We have not solved this second problem at all. We do get reports about the problems though. At best we're handwaving or kluging. This is different kind of problem. It took me a while to realize that, but now I know:) The real problem is that not all metadata formats are suitable for autodetection. That's all. The metadata I use in my GEOM classes play nice with autodetection. The solution is very easy - keep size of the disk device within metadata. This allows gmirror to figure out if it is configured on raw disk, last slice or last partition within last slice, etc. If GPT would keep disk size in its metadata the second problem you mentioned would not exist. And to be honest GPT kinda does that by having backup header's LBA stored in the primary header. And this is fine as long the primary header is valid. The same problem is with things like UFS labels. There is no way to properly support them using GEOM autodetection, because there is no provider size in UFS superblock. UFS superblock contains file system size, but it is not the same, as one can create smaller file system than the underlying disk device. I think it's unwise to depend on FreeBSD-specific extensions or features in industry-standard partitioning schemes and as such make the use of foreign tools hard if not impossible. If you plan to use the given disk with FreeBSD only, what's the problem? Partitioning is not the end of the world. Even if you use industry-standard partitioning schemes what file system are you going to use to actually access your data? FAT? Of course if you do share your disk between various OSes then probably your best bet is to use MBR or GPT on raw disk and FAT file system. But if you use your disk with FreeBSD only, then I see no reason to not to leverage FreeBSD-specific features (be it gmirror, geli or zfs). A much more flexible approach is to support out-of-band configuration data. This allows us to mirror GPT disks without having to become non- standard as it removes the need to use the last sector for meta-data. The ability to construct GEOM hierarchies unambiguously is very important and our current approach has proven to not deliver on that. This is actually impacting existing FreeBSD consumers already, like Juniper. So, se should not go deeper into this rabbit hole. We should finally solve this problem for real... Marcel, nothing stops anyone from implementing GEOM mirror class that uses no on-disk metadata. GEOM is not a limiting factor here. GEOM does provide mechanism for autoconfiguration, but it is totally optional and GEOM class might choose not to use it. As an example you can take a look at two other GEOM classes of mine: gconcat(8) and gstripe(8). You can use 'label' subcommand to store metadata on component disks, which will take advantage of GEOM autodetection and autoconfiguration. You can also use 'create' subcommand to create ad hoc provider that stores no metadata and makes use of entire disks, which also means it won't be automatically created on next boot. For Juniper it might be more handy to use out-of-band configuration as you know the hardware you are running on, so you know where the disks are exactly, etc. My company build appliances too, so I have been there. For most of our users automatic configuration is simply better, as they can shuffle disks around and not wonder if the system will boot or not. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am!
Re: [CFC/CFT] large changes in the loader(8) code
On Wed, Jun 27, 2012 at 10:45:35AM -0700, Marcel Moolenaar wrote: On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: As for sharing disk with other OS. If you share the disk with OS that doesn't support gmirror, you shouldn't use gmirror in the first place. You probably want to use only formats that are recognized by all your OSes. This statement is ridicuous by virtue of not being in touch with reality and by making gmirror useless for such wide range of cases that one can question why we have it at all. Put differently: a mirroring class is a fairly basic and useful thing to have. Limiting it's use is nothing but artificial and follows from having to use the underlying provider to store metadata. This then changes the view of the underlying providing to consumers above gmirror in a way that makes the presence or absence of gmirror visible. Solving the visibility problem makes gmirror useful all the time. I see that as a better way of looking at it than simply blurting out that you shouldn't use gmirror when certain awkward and artifical conditions apply. I'm sorry, Marcel, but what you describe here has nothing to do with reality. To be able to implement realiable mirroring you have to use on-disk metadata. There is no way around that. You can implement non-redundant GEOM classes without using on-disk metadata, but out-of-band configuration in case of mirroring is simply naive. How do you detect that components are out of sync, for example? And when it comes to visablity. Are you suggesting that gmirror should present entire underlying provider to upper layers? Including its metadata? I hope not, because we went through that hell already (remember skipping first 16 sectors by UFS, as BSDlabel metadata might be there? The same for swap?). I think I did pretty good job by making the metadata as simple as possible - I use exactly one sector at the end of the target device. I'm really having a hard time to think of a simpler format. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpwcpFwrh1lk.pgp Description: PGP signature
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
Olli, Thanks for the feedback. We are working on some minor improvements and fixes, when we are done we will commit them to the ports and to the base system. If you see any problems and inconsistencies, please let us know ASAP so we can fix that. Regards, Oleg -Original Message- From: olli hauer [mailto:oha...@gmx.de] Sent: Wednesday, June 27, 2012 10:56 AM To: FreeBSD Current Cc: Gabor Kovesdan; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 2012-06-27 08:04, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor Thanks, I'm running textproc/bsdsort now a view weeks as BASE replacement on 8.3 and haven't seen any issues even on files with a view GB. Are you planing to update the port with your latest version? -- Regards, olli ___ 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: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 11:34 AM, Pawel Jakub Dawidek wrote: I'm sorry, Marcel, but what you describe here has nothing to do with reality. To be able to implement realiable mirroring you have to use on-disk metadata. There is no way around that. You can implement non-redundant GEOM classes without using on-disk metadata, but out-of-band configuration in case of mirroring is simply naive. How do you detect that components are out of sync, for example? GEOM configuration and per-class runtime state are not to be treated the same. Out-of-band configuration is trivial. Per-class runtime state, like whether elements in a mirrored configuration are in sync or not is more difficult, but does not a priori require on-disk metadata as it's implemented now. You can have the configuration tell the GEOM where that state is being kept, so that you can put it in a partition on the disks involved, or even keep it independent from the disks, which then requires disks to be uniquely identifiable, for sure. But that's what GPT gives you anyway. But even without identification, you can invert the question from how do I detect that components are out of sync to how do I prove they are in fact in sync. That question has a very simple O(n) answer. So, if time isn't a concern or your storage is small, you can always scan all sectors as such prove that the disks are in sync. The point being: the current implementation isn't the only one. Granted, it can easily be the simplest one or even the best one in some cases, but that's besides the point you were making. -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On 06/27/12 16:28, John Baldwin wrote: On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) Ah, yes. The solution to violating standards is to make sure you never use standards-compliant software. That's a great argument. :) (Although not entirely uncommon. Standards aren't always perfect, but if we had a way to not gratuitously violate them it would be nice to avoid doing so.) To be standards compliant and allow whole-disk based mirroring to work at the same time wouldn't nested GPT work like this? Whole disk (start) | GPT header | GPT partition of type freebsd-geom (start) | | gmirror device (start) | | | GPT header | | | | freebsd-boot | | | | freebsd-ufs | | | | freebsd-swap | | | GPT backup header | | gmirror metadata | | gmirror device (end) | GPT partition of type freebsd-geom (end) | GPT backup header Whole disk (end) Nothing but FreeBSD would understand the freebsd-geom partition type, so the inner GPT device should be valid and standards compliant. The boot loader would of course need to understand this setup but that shouldn't be impossible. Just a thought. It might be too complicated compared to the non-standards compliant way it works now which works quite well in practice though. -- Christian Laursen ___ 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: [CFC/CFT] large changes in the loader(8) code
On 2012-06-26 14:50, Andrey V. Elsukov wrote: Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff FWIW, I verified it compiles OK with clang, and especially boot2's size isn't increased at all. It would be nice if you could check it with clang now and again, before you finally merge this project into head. ___ 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: [CFC/CFT] large changes in the loader(8) code
On Wednesday, June 27, 2012 1:45:35 pm Marcel Moolenaar wrote: On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: As for sharing disk with other OS. If you share the disk with OS that doesn't support gmirror, you shouldn't use gmirror in the first place. You probably want to use only formats that are recognized by all your OSes. This statement is ridicuous by virtue of not being in touch with reality and by making gmirror useless for such wide range of cases that one can question why we have it at all. Put differently: a mirroring class is a fairly basic and useful thing to have. Limiting it's use is nothing but artificial and follows from having to use the underlying provider to store metadata. This then changes the view of the underlying providing to consumers above gmirror in a way that makes the presence or absence of gmirror visible. Solving the visibility problem makes gmirror useful all the time. I see that as a better way of looking at it than simply blurting out that you shouldn't use gmirror when certain awkward and artifical conditions apply. I'm not sure we can force gmirror to be anything except FreeBSD-specific, but it would be nice to not make non-standard GPT tables while we are at it. The reason the metadata for things like Intel's onboard SATA RAID does work ok is because the metadata format is enforced by the vendor, so it is reasonable to assume that metadata format will work across other OS's. Anyway, I've said my piece and will let the matter drop from my end at this point. -- John Baldwin ___ 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: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 11:20 AM, Pawel Jakub Dawidek wrote: On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote: On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. Agreed. Guys. This doesn't violate the GPT spec in any way. The spec is narrow-minded if it talks only about raw disks, but you should think about gmirror as pseudo-hardware RAID. I'm sorry, but this is a contradiction. If it doesn't violate the spec, then the spec is not narrow-minded on the grounds of what we're discussing. If the spec *is* narrow-minded then obviously it doesn't capture our scenario, which means that we're violating the spec. Clearly we're not discussing anything that falls well within the spec, or is undebatable. This makes the whole topic dangerous anyway. When you're in the grey area (this is only for argument's sake -- we're in violation for sure) you're opening yourself up to compatibility problems. Should we deliberately go there? -- Marcel Moolenaar mar...@xcllnt.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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 2012-06-27 21:02, Oleg Moskalenko wrote: Olli, Thanks for the feedback. We are working on some minor improvements and fixes, when we are done we will commit them to the ports and to the base system. If you see any problems and inconsistencies, please let us know ASAP so we can fix that. Regards, Oleg Hi Oleg, until now I haven't found any issues, and I'm already in love with the new '-h' parameter which is really useful for some reporting scripts :) Regards, olli -Original Message- From: olli hauer [mailto:oha...@gmx.de] Sent: Wednesday, June 27, 2012 10:56 AM To: FreeBSD Current Cc: Gabor Kovesdan; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 2012-06-27 08:04, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor Thanks, I'm running textproc/bsdsort now a view weeks as BASE replacement on 8.3 and haven't seen any issues even on files with a view GB. Are you planing to update the port with your latest version? -- Regards, olli ___ 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: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote: On 06/27/12 16:28, John Baldwin wrote: On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) Ah, yes. The solution to violating standards is to make sure you never use standards-compliant software. That's a great argument. :) (Although not entirely uncommon. Standards aren't always perfect, but if we had a way to not gratuitously violate them it would be nice to avoid doing so.) To be standards compliant and allow whole-disk based mirroring to work at the same time wouldn't nested GPT work like this? GPTs don't nest. Nothing but FreeBSD would understand the freebsd-geom partition type, so the inner GPT device should be valid and standards compliant. If it were standards compliant, it would be discoverable by non-FreeBSD. That clearly isn't the case -- hence it's not standards compliant. What for example if someone wanted to share the swap partition between Linux and FreeBSD? -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
On 27.06.2012 21:55, Marcel Moolenaar wrote: You can't just re-interpret standards to match a context you know very well isn't applicable and consequently redefine what the word device means. You're on a slippery slope and while you may not see it as a problem, you do make it a problem for FreeBSD users. It's our users we should be keeping in mind when we solve problems. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partition editor, it might overwrite the last sector and might don't. Right. Another happy user that sees his/her FreeBSD installation destroyed or degraded (no mirroring, warning messages about corrupted GPT, etc) for no apparent reason and without any kind of warning that what he/she is doing is potentially harmful... That's the spirit! Ok. Let's return back to my patches. They don't add any new methods to shoot in the foot. We are talking about the *FreeBSD loader*. This is the program that starts FreeBSD kernel. It doesn't start other OS. We already have many users who uses FreeBSD as a single system on the machine. Many of them use GPT inside of some GEOM provider. You can just read the lists, articles about installing FreeBSD, forums, etc. We already have these users and i hope they will use FreeBSD as before. So, why can't add a simple quirk to make theirs system a bit more reliable? As i understand there two parts where we haven't a consensus: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. It is valid, because it's CRC is valid, it's self_LBA is valid. For the *FreeBSD* users it is better to don't use this GPT and just complain i'm sorry, can't boot. The other OSes can't, and we shouldn't. 2. You are against from having one fake PMBR entry by default in the /boot/pmbr image. Ok, I can propose several ways to resolve this: * remove from the loader's GPT probing code restriction to necessarily have PMBR partition record in the MBR; * teach the boot0cfg command properly write the PMBR; * add new condition to mark GPT as corrupt when it has invalid PMBR. Thus, when you write PMBR with empty partition table with dd(1), the kernel will complain and you will be forced to run `gpart recover`. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 12:27 PM, Andrey V. Elsukov wrote: On 27.06.2012 21:55, Marcel Moolenaar wrote: You can't just re-interpret standards to match a context you know very well isn't applicable and consequently redefine what the word device means. You're on a slippery slope and while you may not see it as a problem, you do make it a problem for FreeBSD users. It's our users we should be keeping in mind when we solve problems. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partition editor, it might overwrite the last sector and might don't. Right. Another happy user that sees his/her FreeBSD installation destroyed or degraded (no mirroring, warning messages about corrupted GPT, etc) for no apparent reason and without any kind of warning that what he/she is doing is potentially harmful... That's the spirit! Ok. Let's return back to my patches. They don't add any new methods to shoot in the foot. We are talking about the *FreeBSD loader*. This is the program that starts FreeBSD kernel. It doesn't start other OS. We already have many users who uses FreeBSD as a single system on the machine. Many of them use GPT inside of some GEOM provider. Your patches are a continuation on a path that we're discussing isn't necessarily the path we should be on. While you don't make things worse from a compliance perspective, you make it worse by adding the non-compliant behaviour to more components. As i understand there two parts where we haven't a consensus: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. How do you know it's valid? It's in a location that is not valid to begin with. Validity is based on rules and you're violating the the rules without defining exactly what we call valid given the new rules. This may seem nitpicking, but having went through the hassle of dealing with the broken way we created the dangerously dedicated disk, I appreciate the importance of being anal when it comes to something that lives on non-volatile storage and gets to be exposed to a world much larger than FreeBSD. 2. You are against from having one fake PMBR entry by default in the /boot/pmbr image. I don't understand what you're saying or what I'm being accused to be against. -- Marcel Moolenaar mar...@xcllnt.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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 2012.06.27. 10:34, Doug Barton wrote: Great, can you post the results somewhere? I understand what you're saying below that there are situations where worse performance may need explanation, but it would be helpful if we had the data to look at. If something is buggy than it is not comparable in terms of performance because usually those bugs are the exact problem of the better performance because of the negligence of some checks or aspects that were not well considered. And the project cannot grow if we lose users due to gratuitous differences in core utilities. There are more Linux users than FreeBSD users and they all use GNU sort. A great percent of FreeBSD users also manages Linux systems at work so they may also be using new GNU sort features. So in short, what people more usually expect is the behavior of the latest GNU version and POSIX-conformance, not an obsolete, buggy behavior. Losing users because something works better does not seem to be a real threat. But if this is a problem then we should stop fixing bugs and adding features at all since it may discourage someone from using FreeBSD. In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. These are relevant critics. But remember that it lived together with GNU grep so the switch back didn't have a great impact. It was slow but at least it worked. Recently the build is so regularly broken that it makes much more harm. With BSD sort, it is the same case, if there are problems that are hard to solve, we will switch back easily. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 2012.06.27. 8:11, O. Hartmann wrote: ... so, can I delete the entry WITH_BSD_SORT=yes in /etc/src.conf then? Yes. BSD sort will still be the default. And if you want default GNU sort, you can add WITH_GNU_SORT=yes. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 00:14, Marcel Moolenaar wrote: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. How do you know it's valid? It's in a location that is not valid to begin with. Validity is based on rules and you're violating the the rules without defining exactly what we call valid given the new rules. This may seem nitpicking, but having went through the hassle of dealing with the broken way we created the dangerously dedicated disk, I appreciate the importance of being anal when it comes to something that lives on non-volatile storage and gets to be exposed to a world much larger than FreeBSD. So why do you not prevent to attach GEOM_PART_GPT to any providers that are not the disk drive? This will be the right solution to all our problems. Just don't create invalid GPT. -- WBR, Andrey V. Elsukov ___ 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: [CFC/CFT] large changes in the loader(8) code
On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote: On 28.06.2012 00:14, Marcel Moolenaar wrote: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. How do you know it's valid? It's in a location that is not valid to begin with. Validity is based on rules and you're violating the the rules without defining exactly what we call valid given the new rules. This may seem nitpicking, but having went through the hassle of dealing with the broken way we created the dangerously dedicated disk, I appreciate the importance of being anal when it comes to something that lives on non-volatile storage and gets to be exposed to a world much larger than FreeBSD. So why do you not prevent to attach GEOM_PART_GPT to any providers that are not the disk drive? This will be the right solution to all our problems. Just don't create invalid GPT. It's not even the right solution, as it prevents legit nesting of gpart GEOMs *and* is fundamentally based on a flawed assumption that any non-disk GEOM underneath gpart yields an invalid GPT. Think gnop. -- Marcel Moolenaar mar...@xcllnt.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: [CFC/CFT] large changes in the loader(8) code
I would like to point out that all other operating system which has had this precise problem, have solved it by adding a bootfs partition to hold the kernel+modules required to truly understand the disk-layout ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports)
Hi All, I'd like to announce that I intend to import bsdconfig(8) today. === Run-up… Q. What is bsdconfig(8)? A. dialog(1) based post-install configuration utility for configuring/managing various aspects of FreeBSD. Q. What does it look like? A. No screenshots, but I do have a graphic illustrating the menu layout… http://druidbsd.sf.net/download/bsdconfig/bsdconfig-0.7.0-ic.svg Q. Why do we need this in base? A. Because this functionality was exactly produced by sysinstall(8) which has been deprecated (will not exist in FreeBSD 10). FreeBSD-9 is where bsdinstall is being evaluated as a replacement for the install functionality of sysinstall(8) meanwhile bsdconfig is to replace the configuration/management functionalities of sysinstall. Q. Did you discuss this with anyone? A. Everyone that would listen in the past 6 months as we run up to the 9.1 code freeze. Q. Did anyone test this? A. Ron, myself, and about 8 others in the community did both high-level testing, low-level review, and more over the past 6 months. Q. If it doesn't go well, can we back it out? A. Sure -- it's entirely self contained. src/usr.sbin/bsdconfig is the only directory being touched (oh, and the Makefile in the parent directory to add the new SUBDIR). Any other questions, don't hesitate to ask. === Heads-up… Code will land in src/usr.sbin/bsdconfig and _nowhere_ else. The code will be voluminous (~20k LOC across ~150 files including ~30 Makefiles). The code is entirely in sh(1) (don't knock it until you've seen it). The code used in this tool and all sub-modules was developed primarily over a 150-day period, but in reality contains code developed and revised over the past 5 years, entirely BSD licensed! All code was written by Ron McDowell and myself. === If there are no complaints by End-Of-Day (EOD), I'll go ahead and import. -- Cheers, Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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] BSD sort is the default sort in -CURRENT
Hi As promised, I am supplying an example of comparison between several sort programs. The test file is a randomly generated 1,000,000 lines, each line contain a single floating point number. We are going to sort it three ways - as text, as -n numeric sort, and as -g numeric sort, with 4 programs: 1) Old BSD/GNU sort 5.3.0 2) New GNU sort 8.15 3) New BSD sort, single threaded 4) New BSD sort, multi-threaded The system is a 3-CPUs system, 1.5Gb of RAM, FreeBSD version 8.2. All times are in seconds. Locale C. == TEXT SORT sys user real Old BSD/GNU sort:0.0 1.692 2.008 New GNU sort:0.0 2.279 1.605 New BSD sort, st:0.0 1.964 2.300 New BSD sort, mt:0.0 2.385 1.897 == NUMERIC SORT -n sys user real Old BSD/GNU sort:0.0 4.357 4.674 New GNU sort:0.0 8.839 5.134 New BSD sort, st:0.0 5.308 5.592 New BSD sort, mt:0.0 4.581 2.489 == NUMERIC SORT -g sys user real Old BSD/GNU sort:0.0 45.37845.630 New GNU sort: ~450~121 ~300 New BSD sort, st:0.334.334 5.992 New BSD sort, mt:11.140 4.624 8.983 === Thanks Oleg ___ 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: Tmpfs panic in -current
Konstantin Belousov wrote:
On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote:
Kevin Lo wrote:
Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627
address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel
trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0
||
1001 m-busy != 0) {
1002 vm_page_sleep(m,
tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid ==
VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx,
NULL, NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is
zero,
so I do not understand why the asserted block was executed at all.
Thanks for looking into it. Unfortunately I can't get a crash dump
due to lack of disk space and memory.
I triggered the KASSERT on a different machine in the last hour.
It is not 'the' KASSERT, it is something different.
Are you sure that you do not have some systematic build issues on your
machines ? Although I do not think that tmpfs is 'ready for production use'
for arbitrary low value of this statement, there is no steady flow of
similar reports from other users. This makes me somewhat suspicious that
either you might have inconsistent build issues, or unrelated memory
corruption problems.
As I mentioned, I'm running -CURRENT on a number of systems.
I haven't seen tmpfs panics on machines running FreeBSD 9.
Kevin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current from yesterday during boot
Hi, On Wednesday 27 June 2012 23:20:09 Jung-uk Kim wrote: On 2012-06-27 07:07:40 -0400, Andriy Gapon wrote: on 27/06/2012 13:44 Andrey Fesenko said the following: On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko f0and...@gmail.com wrote: On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon a...@freebsd.org wrote: Committed as r237652: http://svnweb.freebsd.org/base?view=revisionrevision=237652 I updated my sources around midnight (GMT) and compiled them again. The system then booted without any problems. Perfect! Erich ___ 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: [CFC/CFT] large changes in the loader(8) code
On Wed, Jun 27, 2012 at 2:39 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I would like to point out that all other operating system which has had this precise problem, have solved it by adding a bootfs partition to hold the kernel+modules required to truly understand the disk-layout ? I have seen some form of this solution suggested three times (once by me) and now by someone who I think I can safely states is pretty familiar with geom. So far I have seen no direct response and only a passing comment by jhb that it might be difficult. Sometimes standards need to be broken. Sometimes they such so badly that te entire industry ignores them. But, unless there i a good reason to ignore them, one should fully justify doing so, all the more so when there are obvious ways that non-compliance can lead to disaster. (Think of geli disk there some other software steps on the last block.) Moreover, I think I can see a legitimate case, though I have not tried it. Say I have a FreeBSD system with a large, unused space on the disk and it uses gmirror. I decide that I need to have the ability to occasionally boot Linux on this system (or, even Windows 8). For some reason, and I can think of several, I can't use a virtual system. I create a new partition for the second OS and install it. It knows nothing about the gmirror, so it just uses the disk it is installed on and never touches the metadata. Is this possible? Looks reasonable to me. I really, really feel uncomfortable about all of this. And when people start claiming that, by a very strained interpretation of what appears on the surface to be a clear specification, they are not violating the standard. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports)
On 06/28/12 01:11, Devin Teske wrote: Hi All, I'd like to announce that I intend to import bsdconfig(8) today. === Run-up… Q. What is bsdconfig(8)? A. dialog(1) based post-install configuration utility for configuring/managing various aspects of FreeBSD. Q. What does it look like? A. No screenshots, but I do have a graphic illustrating the menu layout… http://druidbsd.sf.net/download/bsdconfig/bsdconfig-0.7.0-ic.svg Q. Why do we need this in base? A. Because this functionality was exactly produced by sysinstall(8) which has been deprecated (will not exist in FreeBSD 10). FreeBSD-9 is where bsdinstall is being evaluated as a replacement for the install functionality of sysinstall(8) meanwhile bsdconfig is to replace the configuration/management functionalities of sysinstall. Q. Did you discuss this with anyone? A. Everyone that would listen in the past 6 months as we run up to the 9.1 code freeze. Q. Did anyone test this? A. Ron, myself, and about 8 others in the community did both high-level testing, low-level review, and more over the past 6 months. Q. If it doesn't go well, can we back it out? A. Sure -- it's entirely self contained. src/usr.sbin/bsdconfig is the only directory being touched (oh, and the Makefile in the parent directory to add the new SUBDIR). Any other questions, don't hesitate to ask. === Heads-up… Code will land in src/usr.sbin/bsdconfig and _nowhere_ else. The code will be voluminous (~20k LOC across ~150 files including ~30 Makefiles). The code is entirely in sh(1) (don't knock it until you've seen it). The code used in this tool and all sub-modules was developed primarily over a 150-day period, but in reality contains code developed and revised over the past 5 years, entirely BSD licensed! All code was written by Ron McDowell and myself. === If there are no complaints by End-Of-Day (EOD), I'll go ahead and import. What will happen with the old sysinstall? Well, I'm glad to read that FreeBSD makes a step forward, but maybe there are some people who want to be stick with the old sysinstall. While bsdconfig is flushed in from ports, sysinstall could be flushed out into the ports? If the question or suggestion sounds not rational, dump it ... Regards Oliver signature.asc Description: OpenPGP digital signature
Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports)
On Thu, 28 Jun 2012 07:27:19 +0200 O. Hartmann ohart...@zedat.fu-berlin.de wrote: [skipped] What will happen with the old sysinstall? Well, I'm glad to read that svn log -v -r 225937 svn://svn.freebsd.org/base FreeBSD makes a step forward, but maybe there are some people who want to be stick with the old sysinstall. While bsdconfig is flushed in from ports, sysinstall could be flushed out into the ports? If the question or suggestion sounds not rational, dump it ... Regards Oliver -- wbr, tiger ___ 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
