Re: sysutils/lsof does not build (maybe) after r279433
On 2015-03-04 17:23, Ryan Stone wrote: Would: #undef __BSD_VISIBLE #include #define __BSD_VISIBLE 1 Work in lsof? ___ 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" I've fired off a note to Vic Abell (lsof author). Can one of you file a Bugzilla ticket for me? Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ 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: sysutils/lsof does not build (maybe) after r279433
Would: #undef __BSD_VISIBLE #include #define __BSD_VISIBLE 1 Work in lsof? ___ 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: system failure: cannot kill webkit-gtk3 if using dumbell/radeon
On Wed, Mar 4, 2015 at 8:47 AM, Beeblebrox wrote: > Hi. > > Sorry for the delay to get back to you (including your private emails). > Not a problem, those were various reports left to your judgment as to > their significance. Better to provide more information rather than less. > > slim failure: Traced to dbus start failure at bootup. Slim now starts, > after manual start of dbus. > GDM failure: Starts, but after taking a long time. I'll send Koop the log > files from my recent attempt. > > > You mentioned "ghost text" with nano in vt(4). Could you please file > > a bug in Bugzilla with a picture of what you get? Please join a dmesg > too. > I can confirm this is still an issue. I'll try to get to it at the soonest. > > > the unkillable processes are interesting. If you can reproduce > I really don't know how it came about, so no promises. The most > interesting part of that error however, was the behaviour of vt(4). The > problem is not only unkillable processes, but TTY freeze when doing an > unrelated action to the locked process. I mean, nano or top have nothing to > do with webkit-gtk3, yet caused TTY freeze (due to GPU lock-up I ignorantly > presume) > > > the flickering you see with some applications/desktop environments > This is really serious. It has lessened, but not gone away. > Additionally, I started to get a "sticky mouse" problem some time ago > and I'm inclined to agree with HPS' assessment that "drm2.ko graphics > driver has some hard spinning loops" ( > http://freebsd.1045724.n5.nabble.com/Some-unresolved-but-important-X-org-problems-td5987904.html > ) > Have not had the hardware to test with different GPU unfortunately. > > Regards. > > This sounds a lot like another rcorder issue. If you run "rcorder /etc/rc.d/* /usr/locl/rtc/rc.d/* > /dev/null", do you get errors... particularly circular dependencies? I know that webcamd and dbus have a problem. These are very dangerous as the behavior when they occur is undefined, very unstable and can easily result in daemons failing to start. They are also a real pain to track down. Most often just looking at "REQUIRES" and "BEFORE" statements is not very useful. Note that reports of "no providers" are warnings and often normal and expected. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@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: Massive libxo-zation that breaks everything
On Wed, Mar 4, 2015 at 1:11 PM, John Baldwin wrote: > On Wednesday, March 04, 2015 10:35:34 AM Alfred Perlstein wrote: > > On 3/4/15 8:21 AM, John Baldwin wrote: > > > I would probably want > > > pciconf -l in that case to dump the entire PCI header (right now the > > > human-readable pciconf -l only dumps a subset), and I would want it to > dump > > > fields in capabilities that we don't currently bother printing (and > that > > > I don't think the human-readable output should print due to it being > too > > > obscure, etc.) > > > > I actually agree on this and this is why I was upset that the more > > straightforward GSoC code was shot down in favor of this. That said > > don't we all need to look at the greater good when making software and > > we have some consensus on this so its worth going forward imo. > > > > We can agree on something even though it might make hairs stand up or we > > just stagnate. > > I think there might some cases where converting the existing output > directly > is fine (netstat -s comes to mind), but I think we should not be opposed to > the idea that some utilities should output a different set of data for > machine > -readable. > > Put another way, in my mind something like pciconf -l is a presentation > layer, > and it's just one way of representing the data involved. Ideally, > something > like pciconf -l could be rewritten as a consumer of the raw, > machine-readable > data (I'm not sure I would rewrite it, but in theory the data flow should > be > something like "raw data in kernel" -> "machine-readable format" -> > "presentation".) For example, pciconf -l currently has the misfeature > that it > is a flat listing and doesn't properly communicate the hierarchy that you > can > see in devinfo (and often times that hiearchy does matter). I would want a > machine-readable schema for PCI devices to describe the hierarcy so that > you > could implement multiple "views" of the data (think lspci -t vs pciconf > -l). > However, I think that requires designing the schema in terms of the data > you > are describing, not based on one extant view/presentation. To expend this > further, suppose that pciconf supported multiple views like lspci, would > you > want that to translate into multiple machine-readable schemas? > > -- > John Baldwin > ___ > > If I were the sole designer of the XML ( or any other such as JSON , YAML , etc. ) output system I would do the following : If a value is generated , and should be stored to output file as soon as possible ( such as debugging needs ) , the present sample in the Phabricator review is suitable . For other cases , I would define a record to store the variable values to list later , for example , pci_XML . Within related program part , by trying as much as to write assignment statements near to each other , I would assign values to the pci_XML variables . At the end of assigning values , I would call a routine to store the pci_XML record to file ( create file , write values from pci_XML record , close file ) . Within that routine , it is possible to store the values of pci_XML record in any way , without making difficult to read primary related program . Updates to that routine will not affect the calling program parts much . As a companion to writing routine , I would develop a reading routine ( open file , read values into pci_XML , close the file ) to call from where processing of the output file is required . As a third routine to display values by using pci_XML to the user during interactive work . Thank you very much . Mehmet Erol Sanliturk ___ 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: r279514: buildworld failure: /usr/src/lib/libnv/tests/dnv_tests.cc:453:2: error: use of overloaded operator '<<' is ambiguous
On 04 Mar 2015, at 21:19, Dimitry Andric wrote:
>
> On 04 Mar 2015, at 18:18, O. Hartmann wrote:
>>
>> Am Wed, 4 Mar 2015 14:10:00 +0100
>> Dimitry Andric schrieb:
>>
>>> On 04 Mar 2015, at 12:31, O. Hartmann wrote:
On Mon, 2 Mar 2015 08:58:05 -0500
Ryan Stone wrote:
> Can you post the contents of your make.conf and src.conf? I didn't
> see this in any of my "make tinderbox" runs
> ___
> 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"
The culprit is the option
CXXFLAGS+= -std=c++11
in /etc/src.conf
>>>
>>> Right, it would be nice to have libnv compiling for C++11 though. I'll
>>> have a look
>>> later today.
> ...
>
> It is caused by the following test in lib/libnv/tests/dnv_tests.cc:
>
> ATF_REQUIRE_EQ(actual_val, NULL);
>
> In C++ mode, ATF_REQUIRE_EQ will attempt to output the value of NULL
> onto a std::ostringstream, but this has become ambiguous in C++11. [1]
>
> The fix is to cast the NULL value to the specific pointer type ATF is
> testing against, 'nvlist_t *' in this case. See the attached diff.
Hmm, I've now seen that there many more ATF_REQUIRE_EQ() instance in the
tests, which compare against NULL. It is rather cumbersome to fix all
those, so maybe it should be fixed in atf-c++ instead. Depending on
what may be allowed in the headers, something like this:
Index: contrib/atf/atf-c++/macros.hpp
===
--- contrib/atf/atf-c++/macros.hpp (revision 279564)
+++ contrib/atf/atf-c++/macros.hpp (working copy)
@@ -111,7 +111,8 @@
std::ostringstream atfu_ss; \
atfu_ss << "Line " << __LINE__ << ": " \
<< #expected << " != " << #actual \
-<< " (" << (expected) << " != " << (actual) << ")"; \
+<< " (" << (expected) << " != " << \
+static_cast<__typeof(expected)>(actual) << ")"; \
atf::tests::tc::fail(atfu_ss.str()); \
} \
} while (false)
However, that breaks several ATF_REQUIRE_EQ() instances in atf-c++
itself, like this:
/usr/src/contrib/atf/atf-c++/detail/process_test.cpp: In member function
'virtual void {anonymous}::atfu_tc_argv_array_init_varargs::body() const':
/usr/src/contrib/atf/atf-c++/macros.hpp:115:59: error: invalid static_cast from
type 'std::__1::string {aka std::__1::basic_string, std::__1::allocator >}' to type 'const char*'
static_cast<__typeof(expected)>(actual) << ")"; \
^
/usr/src/contrib/atf/atf-c++/detail/process_test.cpp:174:9: note: in expansion
of macro 'ATF_REQUIRE_EQ'
ATF_REQUIRE_EQ(argv[0], std::string("arg0"));
^
So in these cases, the 'expected' argument's type does not match the
'actual' argument's type. It would be a bit of churn to fix all of
them...
I guess the easiest option is to forcibly disable C++11 if you are using
anything from atf-c++, until it is made C++11 compatible.
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Massive libxo-zation that breaks everything
On Wednesday, March 04, 2015 10:35:34 AM Alfred Perlstein wrote: > On 3/4/15 8:21 AM, John Baldwin wrote: > > I would probably want > > pciconf -l in that case to dump the entire PCI header (right now the > > human-readable pciconf -l only dumps a subset), and I would want it to dump > > fields in capabilities that we don't currently bother printing (and that > > I don't think the human-readable output should print due to it being too > > obscure, etc.) > > I actually agree on this and this is why I was upset that the more > straightforward GSoC code was shot down in favor of this. That said > don't we all need to look at the greater good when making software and > we have some consensus on this so its worth going forward imo. > > We can agree on something even though it might make hairs stand up or we > just stagnate. I think there might some cases where converting the existing output directly is fine (netstat -s comes to mind), but I think we should not be opposed to the idea that some utilities should output a different set of data for machine -readable. Put another way, in my mind something like pciconf -l is a presentation layer, and it's just one way of representing the data involved. Ideally, something like pciconf -l could be rewritten as a consumer of the raw, machine-readable data (I'm not sure I would rewrite it, but in theory the data flow should be something like "raw data in kernel" -> "machine-readable format" -> "presentation".) For example, pciconf -l currently has the misfeature that it is a flat listing and doesn't properly communicate the hierarchy that you can see in devinfo (and often times that hiearchy does matter). I would want a machine-readable schema for PCI devices to describe the hierarcy so that you could implement multiple "views" of the data (think lspci -t vs pciconf -l). However, I think that requires designing the schema in terms of the data you are describing, not based on one extant view/presentation. To expend this further, suppose that pciconf supported multiple views like lspci, would you want that to translate into multiple machine-readable schemas? -- 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: r279514: buildworld failure: /usr/src/lib/libnv/tests/dnv_tests.cc:453:2: error: use of overloaded operator '<<' is ambiguous
On 04 Mar 2015, at 18:18, O. Hartmann wrote: > > Am Wed, 4 Mar 2015 14:10:00 +0100 > Dimitry Andric schrieb: > >> On 04 Mar 2015, at 12:31, O. Hartmann wrote: >>> On Mon, 2 Mar 2015 08:58:05 -0500 >>> Ryan Stone wrote: >>> Can you post the contents of your make.conf and src.conf? I didn't see this in any of my "make tinderbox" runs ___ 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" >>> >>> The culprit is the option >>> >>> CXXFLAGS+= -std=c++11 >>> >>> in /etc/src.conf >> >> Right, it would be nice to have libnv compiling for C++11 though. I'll have >> a look >> later today. ... It is caused by the following test in lib/libnv/tests/dnv_tests.cc: ATF_REQUIRE_EQ(actual_val, NULL); In C++ mode, ATF_REQUIRE_EQ will attempt to output the value of NULL onto a std::ostringstream, but this has become ambiguous in C++11. [1] The fix is to cast the NULL value to the specific pointer type ATF is testing against, 'nvlist_t *' in this case. See the attached diff. -Dimitry [1] Before C++11, NULL is defined as 0, e.g. plain zero, and it will therefore be printed as an integer "0". In C++11 and later, NULL is defined as the keyword nullptr, e.g. the null pointer literal. Since the null pointer can be converted to any other pointer type, and there are many different operators defined in C++ to output those operators, the call is ambiguous, and must be resolved by the developer. libnv-fix-tests-cxx11-1.diff Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Massive libxo-zation that breaks everything
On 04.03.2015 19:21, John Baldwin wrote: > On Tuesday, March 03, 2015 09:09:43 AM David Chisnall wrote: >> Hopefully there's a lesson here that we can learn from: human-readable >> formats do not make good intermediate representations when communicating >> between tools. > > I think this is actually an argument against libxo-ification in the one case > where I've cringed a bit at the diffs: pciconf. The current pciconf code is > tailored to outputting something human readable. For non-human output I would > probably generate different output (not just put tags on the human output) > because I would want the non-human output to be both more verbose and more > raw. I think some other cases like 'netstat -s' are far more straightforward > as the current output maps fairly well to the backing structure, but in > general I would want machine-readable output that is closer to the structures > than to the human-readable formatting of them. > > For example, for something like 'mfiutil show drives', I would want the human > readable format to stay as it is (it only highlights certain fields in the PD > structures) but I would want the machine-readable format to basically output > tagged versions of the backing structures from sys/dev/mfi/mfireg.h. That > way > the machine-readable format has all of the data instead of only the subset > that is presented in the human-readable output. > > So while I am in general a big fan of having machine-readable output from > tools (and I think it belongs in the base system, and I don't think you want > a > post-processing tool), I think there is a bit of a flawed assumption that > says > that I want the same data in the human-readable format that I want in the > machine-readable format. I, for one, don't. I want the human-readable form > more condensed. > >> If your argument is about maintainability of these changes, then please >> point to concrete instances where the changes are complex and difficult to >> maintain. > > When I've looked at the xo diffs for pciconf, my reaction has been "ugh, I > guess I'm not going to work on pciconf again in the future because that's > super ugly". I don't object to the idea, I think I would just rather have a > very different schema for machine-readable output. I would probably want > pciconf -l in that case to dump the entire PCI header (right now the human- > readable pciconf -l only dumps a subset), and I would want it to dump fields > in capabilities that we don't currently bother printing (and that I don't > think the human-readable output should print due to it being too obscure, > etc.) > I agree that adding machine-readable output + separate option on a per-tool basis, when it is really needed, is more clean approach which don't break Unix way of things. In such case we don't intermix structured representation with human readable, so the chances that a bug in one representation code flow will affect other one are minimal unlike in unified libxo approach, which already demonstrate this weakness. -- http://ache.vniz.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: Massive libxo-zation that breaks everything
On 3/4/15 8:21 AM, John Baldwin wrote: On Tuesday, March 03, 2015 09:09:43 AM David Chisnall wrote: Hopefully there's a lesson here that we can learn from: human-readable formats do not make good intermediate representations when communicating between tools. I think this is actually an argument against libxo-ification in the one case where I've cringed a bit at the diffs: pciconf. The current pciconf code is tailored to outputting something human readable. For non-human output I would probably generate different output (not just put tags on the human output) because I would want the non-human output to be both more verbose and more raw. I think some other cases like 'netstat -s' are far more straightforward as the current output maps fairly well to the backing structure, but in general I would want machine-readable output that is closer to the structures than to the human-readable formatting of them. For example, for something like 'mfiutil show drives', I would want the human readable format to stay as it is (it only highlights certain fields in the PD structures) but I would want the machine-readable format to basically output tagged versions of the backing structures from sys/dev/mfi/mfireg.h. That way the machine-readable format has all of the data instead of only the subset that is presented in the human-readable output. So while I am in general a big fan of having machine-readable output from tools (and I think it belongs in the base system, and I don't think you want a post-processing tool), I think there is a bit of a flawed assumption that says that I want the same data in the human-readable format that I want in the machine-readable format. I, for one, don't. I want the human-readable form more condensed. If your argument is about maintainability of these changes, then please point to concrete instances where the changes are complex and difficult to maintain. When I've looked at the xo diffs for pciconf, my reaction has been "ugh, I guess I'm not going to work on pciconf again in the future because that's super ugly". I don't object to the idea, I think I would just rather have a very different schema for machine-readable output. +1 I would probably want pciconf -l in that case to dump the entire PCI header (right now the human- readable pciconf -l only dumps a subset), and I would want it to dump fields in capabilities that we don't currently bother printing (and that I don't think the human-readable output should print due to it being too obscure, etc.) I actually agree on this and this is why I was upset that the more straightforward GSoC code was shot down in favor of this. That said don't we all need to look at the greater good when making software and we have some consensus on this so its worth going forward imo. We can agree on something even though it might make hairs stand up or we just stagnate. ___ 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: r279278 failed to build (yacc: maximum table size exceeded)
[[ I know this is a bit stale, but this is a dangerous notion ]] > On Feb 25, 2015, at 1:11 PM, Garrett Cooper wrote: > I was going to propose something a bit more radical — I can remove the > BOOTSTRAPPING conditionals and simplify the code on 10-STABLE / 11-CURRENT. > > Maintaining BOOTSTRAPPING is error prone and it’s not saving much time in the > long run in builds (it's taking longer to diagnose issues, test them, and > commit fixes which will break at a later date). I’ve been bitten by this once > because I don’t run ancient CURRENT/STABLE (r279198) and here are a couple > follow up commits bumping tools versions in the past (e.g. r278975, r269662, > etc). > > Just a thought. It’s a terrible thought. We’ve done the bootstrapping thing for 15 years with very few bumps and biting. No need to ditch it because lately we’ve been updating yacc more often w/o bumping the revision. Don’t remove it. There was more blood on the floor before we had it than after. It documents how far back in time we try to support. Sure, things get missed, but it isn’t always clear why we have things in the bootstrap tools. Having them documented this way makes it clear. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: r279514: buildworld failure: /usr/src/lib/libnv/tests/dnv_tests.cc:453:2: error: use of overloaded operator '<<' is ambiguous
Am Wed, 4 Mar 2015 14:10:00 +0100 Dimitry Andric schrieb: > On 04 Mar 2015, at 12:31, O. Hartmann wrote: > > On Mon, 2 Mar 2015 08:58:05 -0500 > > Ryan Stone wrote: > > > > > Can you post the contents of your make.conf and src.conf? I didn't > > > see this in any of my "make tinderbox" runs > > > ___ > > > 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" > > > > The culprit is the option > > > > CXXFLAGS+= -std=c++11 > > > > in /etc/src.conf > > Right, it would be nice to have libnv compiling for C++11 though. I'll have > a look > later today. > > -Dimitry > Ah ... thank pgpwEVZOOP_oR.pgp Description: OpenPGP digital signature
Re: r279514: buildworld failure: /usr/src/lib/libnv/tests/dnv_tests.cc:453:2: error: use of overloaded operator '<<' is ambiguous
Am Wed, 4 Mar 2015 14:10:00 +0100 Dimitry Andric schrieb: > On 04 Mar 2015, at 12:31, O. Hartmann wrote: > > On Mon, 2 Mar 2015 08:58:05 -0500 > > Ryan Stone wrote: > > > > > Can you post the contents of your make.conf and src.conf? I didn't > > > see this in any of my "make tinderbox" runs > > > ___ > > > 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" > > > > The culprit is the option > > > > CXXFLAGS+= -std=c++11 > > > > in /etc/src.conf > > Right, it would be nice to have libnv compiling for C++11 though. I'll have > a look > later today. > > -Dimitry > Ah ... thank you very much. oh pgpg6CXu1bhtK.pgp Description: OpenPGP digital signature
Re: system failure: cannot kill webkit-gtk3 if using dumbell/radeon
Hi. > Sorry for the delay to get back to you (including your private emails). Not a problem, those were various reports left to your judgment as to their significance. Better to provide more information rather than less. slim failure: Traced to dbus start failure at bootup. Slim now starts, after manual start of dbus. GDM failure: Starts, but after taking a long time. I'll send Koop the log files from my recent attempt. > You mentioned "ghost text" with nano in vt(4). Could you please file > a bug in Bugzilla with a picture of what you get? Please join a dmesg too. I can confirm this is still an issue. I'll try to get to it at the soonest. > the unkillable processes are interesting. If you can reproduce I really don't know how it came about, so no promises. The most interesting part of that error however, was the behaviour of vt(4). The problem is not only unkillable processes, but TTY freeze when doing an unrelated action to the locked process. I mean, nano or top have nothing to do with webkit-gtk3, yet caused TTY freeze (due to GPU lock-up I ignorantly presume) > the flickering you see with some applications/desktop environments This is really serious. It has lessened, but not gone away. Additionally, I started to get a "sticky mouse" problem some time ago and I'm inclined to agree with HPS' assessment that "drm2.ko graphics driver has some hard spinning loops" (http://freebsd.1045724.n5.nabble.com/Some-unresolved-but-important-X-org-problems-td5987904.html) Have not had the hardware to test with different GPU unfortunately. Regards. -- FreeBSD_amd64_11-Current_RadeonKMS Please include my email when responding-I may have unabled auto-delivery. ___ 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: Massive libxo-zation that breaks everything
On Tuesday, March 03, 2015 09:09:43 AM David Chisnall wrote: > Hopefully there's a lesson here that we can learn from: human-readable > formats do not make good intermediate representations when communicating > between tools. I think this is actually an argument against libxo-ification in the one case where I've cringed a bit at the diffs: pciconf. The current pciconf code is tailored to outputting something human readable. For non-human output I would probably generate different output (not just put tags on the human output) because I would want the non-human output to be both more verbose and more raw. I think some other cases like 'netstat -s' are far more straightforward as the current output maps fairly well to the backing structure, but in general I would want machine-readable output that is closer to the structures than to the human-readable formatting of them. For example, for something like 'mfiutil show drives', I would want the human readable format to stay as it is (it only highlights certain fields in the PD structures) but I would want the machine-readable format to basically output tagged versions of the backing structures from sys/dev/mfi/mfireg.h. That way the machine-readable format has all of the data instead of only the subset that is presented in the human-readable output. So while I am in general a big fan of having machine-readable output from tools (and I think it belongs in the base system, and I don't think you want a post-processing tool), I think there is a bit of a flawed assumption that says that I want the same data in the human-readable format that I want in the machine-readable format. I, for one, don't. I want the human-readable form more condensed. > If your argument is about maintainability of these changes, then please > point to concrete instances where the changes are complex and difficult to > maintain. When I've looked at the xo diffs for pciconf, my reaction has been "ugh, I guess I'm not going to work on pciconf again in the future because that's super ugly". I don't object to the idea, I think I would just rather have a very different schema for machine-readable output. I would probably want pciconf -l in that case to dump the entire PCI header (right now the human- readable pciconf -l only dumps a subset), and I would want it to dump fields in capabilities that we don't currently bother printing (and that I don't think the human-readable output should print due to it being too obscure, etc.) -- 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: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
On Tue, 03 Mar 2015 23:33:23 +0100 Jean-Sébastien Pédron wrote: > > Hi! > > Here is a new patch to based on HEAD r279508: > https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch > > You can apply it to a Subversion checkout using the following command: > svn patch drm-update-38.i.patch > > There are few changes: > o The panic reported by J.R. Oldroyd is fixed, but not the CP init >problem. > o A lock assert was added, suggested by Konstantin Belousov > Tested as requested: svn update to r279508 and applied the 38i patch. Mixed results. The first boot, done as a warm "reboot" command while running 10-stable shows that the CP init failed again and I am back to the mtx_lock panic. I then let it auto-reboot back into 10-stable (this is an old 10-stable at the time of r271969 10.1-BETA2 but it is one in which the ring CP init still works). That shows it boots fine and ring CP inits OK - even as a warm reboot after the previous failure. I then thought to try a power-off cold reboot into r279508. This works, both ring CP inits OK and no mtx_lock panic. In fact, I am using it now to send this report. So, perhaps the previous fix for the mtx_lock panic wasn't right, but just seemed to work because I happened to cold-boot those times. The pattern that's emerging here is that older (mid-2014) kernels boot and init fine, warm or cold. The CP init problem started somewhere mid-2014. The mtx_lock panic is new, so I am guessing related to the drm2-38 update. BOTH CP init and mtx_lock problems go away when cold booting. I've uploaded info here: http://opal.com/jr/freebsd/panic/r279508M/dmesg.txt http://opal.com/jr/freebsd/panic/r279508M/core.txt.7 The dmesg shows the three boot sequences with annotations to make it clear which is which. Above is system with ATI Radeon RS690 X1270 IGP, RS690. BTW, I now also have the ring CP init failure on a second system that was just updated to 10.1-RELEASE-p6. It has ATI Radeon HD 4200 which is RS780 and it also shows the ring init failure at CAFEDEAD but in r600_ting_test(). Unfortunately, this system is a production one so I can't easily play with it. Note, no mtx_lock panic here. Fortunately, the graphics not working isn't a problem on this system. -jr pgpZ9qNOg7N2y.pgp Description: OpenPGP digital signature
[SOLVED] Re: pcie Realtek 8168G issues (re driver)(minnowboard)
Hi all, I've managed to get the Realtek 8168g running. It's actually a driver bug, the command register enables rx and tx too early. Apparently, it's OK for many Realtek chips, but not for 3 kind of them, as stated by the Realtek developer, who submitted this patch to Linux (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d6e572911a4cb2b9fcd1c26a38d5317a3971f2fd) I updated the Bugzilla entry https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 The patch (moving one line, sich!) works on this hardware, but I don't know how much portable it is. Thanks for all your tips. Best regards, Luca Pizzamiglio On Wed, Feb 25, 2015 at 3:59 PM, Luca Pizzamiglio wrote: > Hi, > thanks you all for the replies. > > Unfortunately, the network chip is still not working and I updated the > PR (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) with the > last tests. > It seems that received packets are not transferred to mbuf or they are > transferred, but later, after the mbuf is already freed; moreover, the > ring entries are written without looping, overwriting and messing up > the whole kernel memory. It looks like a DMA issues, but > > Apparently it seems a hardware error, but using a Linux distro, it works :( > > Has someone maybe any other ideas? In the meanwhile I'll get another > board with the same chip :O > > Best regards, > Luca > > > On Tue, Feb 17, 2015 at 7:31 PM, O. Hartmann > wrote: >> Am Tue, 17 Feb 2015 18:32:22 +0100 >> Luca Pizzamiglio schrieb: >> >>> Hi Ben, >>> thanks for the tip! tso was already disabled. >>> I tried anyway and unfortunately it crashes as before. >>> >>> I filled a bug report >>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) and marius@ >>> is giving me a big help on it. >>> >>> Best regards, >>> Luca >>> >>> On Fri, Feb 13, 2015 at 7:34 PM, Ben Perrault >>> wrote: >>> > Luca, >>> > >>> > I've had the same issue with this interface on both PCIe boards and >>> > embedded in a >>> > handful of Lenovo products. The one, fairly ugly workaround I've found >>> > that makes it >>> > work well enough is disable tso ( i.e. ifconfig re0 down && ifconfig re0 >>> > -tso && >>> > ifconfig re0 up ). This also seems to stop the panics under current. >>> > >>> > I'm not sure it will work for you - but it has on everyone of those >>> > interfaces I've >>> > dealt with. >>> > >>> > Good luck, >>> > -bp >>> > >>> >> On Feb 13, 2015, at 8:06 AM, Luca Pizzamiglio >>> >> wrote: >>> >> >>> >> Hi, I'm Luca, >>> >> >>> >> I've some issues using a PCIe Realtek Ethernet board: >>> >> re0@pci0:3:0:0: class=0x02 card=0x012310ec chip=0x816810ec rev=0x0c >>> >> hdr=0x00 >>> >>vendor = 'Realtek Semiconductor Co., Ltd.' >>> >>device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' >>> >>class = network >>> >>subclass = ethernet >>> >>bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled >>> >>bar [18] = type Memory, range 64, base 0x9050, size 4096, >>> >> enabled >>> >>bar [20] = type Prefetchable Memory, range 64, base 0x9040, >>> >> size 16384, enabled >>> >>cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 >>> >>cap 05[50] = MSI supports 1 message, 64 bit >>> >>cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link >>> >> x1(x1) >>> >> speed 2.5(2.5) ASPM disabled(L0s/L1) >>> >>cap 11[b0] = MSI-X supports 4 messages >>> >> Table in map 0x20[0x0], PBA in map 0x20[0x800] >>> >>cap 03[d0] = VPD >>> >>ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected >>> >>ecap 0002[140] = VC 1 max VC0 >>> >>ecap 0003[160] = Serial 1 0100684ce000 >>> >>ecap 0018[170] = LTR 1 >>> >> >>> >> Rx and Tx don't work. After some minutes the interface is activated I >>> >> get kernel panic. >>> >> I've already tried to disable MSIx and MSI. >>> >> It seems a DMA problem, rx fill the 256 descriptors and the nothing >>> >> else until the panic. netstat -s shows now new packets. >>> >> >>> >> I filled a bug report with more infos: >>> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 >>> >> >>> >> could someone kindly pointing some ideas? >>> >> >>> >> Best regards, >>> >> Luca >>> >> ___ >>> >> 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" >> >> In September 2014 I filed allready a bug acoording to strange behaviour with >> a Lenovo >> ThinkPad E540 with a Realtek chip: >> >> >> Bug 193743 - RTL8111/8168B PCI Express Gigabit Ethernet >> controller: doesn't work pr
Re: r279514: buildworld failure: /usr/src/lib/libnv/tests/dnv_tests.cc:453:2: error: use of overloaded operator '<<' is ambiguous
I don't think that libnv is the problem. It looks like a problem with atf-c++ to me. ___ 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: ports/audio/alsa-lib Error code 74
On Wed, Mar 04, 2015 at 06:17:01AM -0500, R0B_ROD wrote: > Hello, > First ld could not find python. What was the error? Python bindings are optional and off by default. Run 'make config' in audio/alsa-lib to disable it and try again. > I removed a $. This change is wrong. It breaks staging! install -o root -g wheel -m 0644 alsa.pc '/usr/ports/audio/alsa-lib/work/stage\/libdata/pkgconfig' vs. install -o root -g wheel -m 0644 alsa.pc '/usr/ports/audio/alsa-lib/work/stage/usr/local/libdata/pkgconfig' Revert it and try again! -- Herbert ___ 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: r279514: buildworld failure: /usr/src/lib/libnv/tests/dnv_tests.cc:453:2: error: use of overloaded operator '<<' is ambiguous
On 04 Mar 2015, at 12:31, O. Hartmann wrote: > On Mon, 2 Mar 2015 08:58:05 -0500 > Ryan Stone wrote: > > > Can you post the contents of your make.conf and src.conf? I didn't > > see this in any of my "make tinderbox" runs > > ___ > > 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" > > The culprit is the option > > CXXFLAGS+= -std=c++11 > > in /etc/src.conf Right, it would be nice to have libnv compiling for C++11 though. I'll have a look later today. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: r279514: buildworld failure: /usr/src/lib/libnv/tests/dnv_tests.cc:453:2: error: use of overloaded operator '<<' is ambiguous
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2 Mar 2015 08:58:05 -0500 Ryan Stone wrote: > Can you post the contents of your make.conf and src.conf? I didn't > see this in any of my "make tinderbox" runs > ___ > 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" The culprit is the option CXXFLAGS+= -std=c++11 in /etc/src.conf -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJU9uz+AAoJEOgBcD7A/5N8pc0IAM+DChmRz9D/NWzNmLRsy1+p GC2Jb+ha6n9b+/I0ra2QVgY193h2LvRAj9ykym8Vjz3Md0gnrGIx+S5Zum9d8zc4 2wMmd+rJ1CQf/cMO05jVivuvNCWTF1a3ikgd6seG67LEhu+HtqhlKsqSMMJIXQvm euJ4uu3F81V5KUlwv3uw1v8C/PqNwWgSkUnUitCplP+H3Y6RoiVf6nY+reJqhDJ2 f4YPF9m1VPzgZTo/pkXTjnhGqIH0Xtg+PEodWsmaHz1WiZ5saMl2chp5JEUeKxUA IZMzmo/h/fxHqceNlJQwBHtQ8wHJ5KTsjD60biAE36Qo7n0TobOSJehPfm9M9Vw= =UxvF -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: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
On 03/03/15 23:33, Jean-Sébastien Pédron wrote:
Hi!
Here is a new patch to based on HEAD r279508:
https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch
You can apply it to a Subversion checkout using the following command:
svn patch drm-update-38.i.patch
There are few changes:
o The panic reported by J.R. Oldroyd is fixed, but not the CP init
problem.
o A lock assert was added, suggested by Konstantin Belousov
I had several panics ("Stray timeout") with a taskqueue used by TTM, but
it didn't occur in the past 6 days. Maybe it was a problem outside of DRM.
I would like people to test again and report :) If something fails,
please post a full dmesg, taken after loading the relevant *kms module,
or the core.txt.$N file if it's a panic.
Hans Petter and Ed, I couldn't reproduce neither of your problems (HDMI
hotplug events storm and VT-switch misbehaviour). However, they both
involve callouts, like the "Stray timeout" panic I had with TTM. I
suspect there was a transient problem with callouts in HEAD at the same
time. Could you please test again with this patch and a very recent HEAD?
1) Callouts are not yet entirely fixed in HEAD yet. Fixes and
discussions are still ongoing, see D1894. BTW: I'm using:
https://reviews.freebsd.org/D1438
2) Maybe you could consider adding "SUBDIR_PARALLEL=" to some of the
drm2 Makefiles?
3) After a lot of digging I found the only way to get flicker free video
with XVideo using the Intel driver was to configure X.org like this:
Section "Device"
Identifier "Device0"
Driver "intel"
Option "AccelMethod" "sna"
Option "TearFree" "true"
EndSection
Maybe that could be the default?
4) High Xorg usage is not solved:
1026 root 1 26099M 26928K 915gbr 0 1:03 8.89% Xorg
1026 root 1 102099M 26936K CPU00 1:52 98.58% Xorg
info: [drm] Initialized drm 1.1.0 20060810
drmn0: on vgapci0
iicbus0: on iicbb0 addr 0xff
iic0: on iicbus0
iic1: on iicbus1
iicbus2: on iicbb1 addr 0x0
iic2: on iicbus2
iic3: on iicbus3
iicbus4: on iicbb2 addr 0x0
iic4: on iicbus4
iic5: on iicbus5
iicbus6: on iicbb3 addr 0x0
iic6: on iicbus6
iic7: on iicbus7
iicbus8: on iicbb4 addr 0x0
iic8: on iicbus8
iic9: on iicbus9
iicbus10: on iicbb5 addr 0x0
iic10: on iicbus10
iic11: on iicbus11
iicbus12: on iicbb6 addr 0x0
iic12: on iicbus12
iic13: on iicbus13
info: [drm] MSI enabled 1 message(s)
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
drmn0: taking over the fictitious range 0xe000-0xf000
info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off
info: [drm] Connector VGA-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.VGA-1
info: [drm] - kern.vt.fb.default_mode
info: [drm] Connector HDMI-A-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.HDMI-A-1
info: [drm] - kern.vt.fb.default_mode
info: [drm] Connector DP-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.DP-1
info: [drm] - kern.vt.fb.default_mode
fbd0 on drmn0
VT: Replacing driver "vga" with new "fb".
info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
error: [drm:pid1026:gen6_sanitize_pm] *ERROR* Power management
discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1400, was 1206
info: [drm] GMBUS [gmbus dpd] timed out, falling back to bit banging on
pin 6
--HPS
___
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"
ports/audio/alsa-lib Error code 74
Hello,
First ld could not find python.
I removed a $.
Now the following: Dunno what to do.
PS: Thanks to all for such amazing software! FreeBSD rocks!
Willing to be a tester. I have this hobby of breaking things ;)
-Roberto Rodriguez Jr
/*
# diff Makefile.R0B Makefile.11.0-CURRENT
18c18
< CONFIGURE_ARGS= --with-pkgconfdir="\${prefix}/libdata/pkgconfig"
---
> CONFIGURE_ARGS= --with-pkgconfdir="\$${prefix}/libdata/pkgconfig"
# make install clean
===> Installing for alsa-lib-1.0.29
===> Checking if alsa-lib already installed
===> Registering installation for alsa-lib-1.0.29
pkg-static: Unable to access file /usr/ports/audio/alsa-lib/work/stage/usr/local
/libdata/pkgconfig/alsa.pc: No such file or directory
*** Error code 74
Stop.
make[1]: stopped in /usr/ports/audio/alsa-lib
*** Error code 1
Stop.
make: stopped in /usr/ports/audio/alsa-lib
___
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"
sysutils/lsof does not build (maybe) after r279433
Hi. Today I upgraded my -head (amd64) VM from r279417 to r279579, and sysutils/lsof does not build any more. Looking into build log (attached), it seems that r279433 broke build. (Not actually bi-sected) Fix: Not known. But maybe renaming asprintf() and vasprintf() in sys/sys/systm.h and its consumers to avoid conflicts would help from base side. Can sysutils/lsof side support this? -- Tomoaki AOKIjunch...@dec.sakura.ne.jp lsof_20150304.log Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
