Re: xhci broken on 10-CURRENT and 2013 MacBook Air?
What I got so far is this;
USB driver from current stops after
xhci0: 32 byte context size
While driver from 9.1 continues to the next step which is
usbus0 on xhci0
xhci0: usbpf: Attached
...
I can try adding some printf's in the code and see if I get some more..
On Tuesday, August 27, 2013, Lundberg, Johannes wrote:
Hi Hans
Sure, I will try it out later and mail the results.
Now I'm running current with usb part reverted to 9.1. It gets me pass the
usb probing to the part that I really wanted to confirm. If FreeBSD
supports the SSD drive on the new MacBook Air. It seems that it doesn't so
that one more thing that we need to look into.
Johannes Lundberg
BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp
On Tue, Aug 27, 2013 at 10:06 AM, Hans Petter Selasky
h...@bitfrost.nojavascript:_e({}, 'cvml', 'h...@bitfrost.no');
wrote:
On 08/26/13 21:02, Lundberg, Johannes wrote:
Hi Hans
Thanks but nothing of that makes any difference. Well, it's gonna be
difficult to find the diff I think... The oldest image I could find was
from May.
What I'm doing now is compiling a bootonly.iso of current with a xhci.h/c
that's reverted to 9.1 release version to see if that will boot.
Hi,
If it just hangs, can be an IRQ looping issue.
You can also try to boot using bootverbose and configure the xhci driver
with debugging on in the sys/dev/usb/controller/xhci.c by default to see
just what is exactly going on.
If you can suggest a patch, that would be great.
--HPS
--
Johannes Lundberg
BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp
___
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: xhci broken on 10-CURRENT and 2013 MacBook Air?
On 08/30/13 08:09, Lundberg, Johannes wrote: What I got so far is this; USB driver from current stops after xhci0: 32 byte context size While driver from 9.1 continues to the next step which is usbus0 on xhci0 xhci0: usbpf: Attached ... I can try adding some printf's in the code and see if I get some more.. Hi, There are only a few commits to the xhci driver since 9.1 was releases, so this should be easy to figure out. I'm doing a wild guess. Can you try the attached patch. It will ensure that any BIOS generated interrupts get cleared before we reset the controller. --HPS === sys/dev/usb/controller/xhci.c == --- sys/dev/usb/controller/xhci.c (revision 254832) +++ sys/dev/usb/controller/xhci.c (local) @@ -320,6 +320,12 @@ device_printf(sc-sc_bus.parent, 32 byte context size.\n); } + temp = XREAD4(sc, oper, XHCI_USBSTS); + /* clear all pending interrupts */ + XWRITE4(sc, oper, XHCI_USBSTS, temp); + /* clear and disable leftover interrupts */ + XWRITE4(sc, runt, XHCI_IMAN(0), XHCI_IMAN_INTR_PEND); + /* Reset controller */ XWRITE4(sc, oper, XHCI_USBCMD, XHCI_CMD_HCRST); @@ -385,10 +391,6 @@ sc-sc_exit_lat_max = XHCI_HCS3_U1_DEL(temp) + XHCI_HCS3_U2_DEL(temp) + 250 /* us */; - temp = XREAD4(sc, oper, XHCI_USBSTS); - - /* clear interrupts */ - XWRITE4(sc, oper, XHCI_USBSTS, temp); /* disable all device notifications */ XWRITE4(sc, oper, XHCI_DNCTRL, 0); @@ -462,11 +464,8 @@ XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr 32)); /* Setup interrupter registers */ + XWRITE4(sc, runt, XHCI_IMAN(0), XHCI_IMAN_INTR_ENA); - temp = XREAD4(sc, runt, XHCI_IMAN(0)); - temp |= XHCI_IMAN_INTR_ENA; - XWRITE4(sc, runt, XHCI_IMAN(0), temp); - /* setup command ring control base address */ addr = buf_res.physaddr; addr += (uintptr_t)((struct xhci_hw_root *)0)-hwr_commands[0]; ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw
On 8/30/13 1:02 AM, David Chisnall wrote: On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote: I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't really start using clang-specific features yet anyway. Apparently I haven't been good at communicating, so I'll try to here. I apologise for ignoring this thread for the last week: I've been rather busy organising the DevSummit. The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki. You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base). This is not a new plan, it is the plan that has been on the wiki and discussed at at least two DevSummits that I have attended before this week and probably others that I missed, as well as on various mailing lists and in IRC. To summarise the current issues: Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine-dependent code on these architecture. Our g++ in base can only work with libstdc++, not libc++. This means that shipping gcc in 10.0 in base means that we'd be shipping two C++ compilers, which preferred different standard libraries, with incompatible ABIs. This is setting us up for a world of pain. When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). Lots of configure scripts will use gcc in preference to cc (or g++ in preference to c++) if they find them in the same place. Many of these no longer work with our old gcc, but do work with clang, adding more effort to ports. According to the test runs that bapt did at the DevSummit this week, we have more ports failing on 10 with gcc than on 10 with gcc removed. Our gcc does not support the ARM EABI hard float variant. I misspoke earlier when I thought it didn't support EABI at all, but it turns out that it's only the case for hard-float. This is the ABI that we want to be using on pretty much all ARMv6 and newer systems, because a lot of ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has paid for FreeBSD to be ported on to use as a demo ARM device) require a complete pipeline flush when moving between integer and floating point registers and the soft-float variant of the ABI puts all arguments in integer registers. This means that a simple function that takes a rectangle (4 floating point values) as an argument will require 8 pipeline flushes to call, which various Linux distributions have found is crippling for graphical applications.
Re: GCC withdraw
On 29 Aug 2013, at 18:44, John Baldwin j...@freebsd.org wrote: How does removing GCC from base change this? I already deal with having 3 different GCC versions at work by building them from ports and building things with the right rpath, etc. so I am familiar with this, and having GCC in the base doesn't make that problem any worse. In fact, I'd argue that this is an argument for not shipping an STL in the base system at all (though I'd be loathe to do that) if it is an argument for disabling GCC. It means that you don't need to patch configure scripts to tell them to ignore gcc even if they find it. Please talk to port maintainers about the amount of effort that they're being forced to put into this. They'll still have to keep doing this until 9.x is EOL'd, but it would be nice if they could then stop, rather than having to wait for 10.x to also be EOL'd. Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Strictly speaking you do not have to modify it in all cases. The recent change to make it work with log10 does not appear to have been a requirement to fix anything (at least judging from the log message). There does seem to have been about 10 changes to libstdc++ in the past year, though a few were 2-3 line changes in config.h which isn't but so earth-shattering. And each libc change that exposes anything that is used by libstdc++ goes through the same cycle: - Commit - Wait for bug reports - Spend a few hours trying to work out why C++ programs are failing to run or compile in odd ways - Commit a libstdc++ fix And, once again, the people who are advocating for gcc to remain in the default install are not the ones doing this work. Also, unless you plan on desupporting all non-x86 platforms, you _still_ have to do all this work while those platforms require GCC anyway. Just turning off GCC on x86 doesn't change this problem one iota. And that point is actually relevant to many of the other concerns you raised. It's not at all clear what disabling GCC on x86 will buy you unless you are intending on short-changing support for GCC on non-x86. It gives us a much cleaner deprecation strategy. Ports on tier-2 are best effort. We don't need to be quite as careful to ensure that they build with the base system compiler on tier-2 architectures. We don't make as strong guarantees about compatibility on tier-2 architectures, so removing gcc from their build at some point over the next five years is fine, but this is not the case for tier 1 architectures, where we can be reasonably expected to support anything that is in the base system for the next five years. If we remove it from the default install now, users don't expect it to keep working for the lifetime of the 10.x branch. If we leave it in, then they do. If tier-2 architectures are still using it for 10.0, that's fine, because users of tier-2 architectures don't expect everything to remain stable over the span of a release. ARM is technically Tier-2, but for the purpose of this I'm including modern ARM platforms (i.e. things like the Efika and Raspberry Pi, where we hope to get re@-supported images soon - by 10.1 if not by 10.0), but ARM EABI Hard-Float (the platform in question) is already supported by clang and so has the same level of support as x86. So let's be absolutely clear what we mean by non-x86: - Old ARM (ARMv4/ARMv5), most commonly used in microcontrollers which don't have the power to run a full base system or arbitrary ports anyway. - MIPS, which is a few months of effort in LLVM to get completely working. LLVM on MIPS is already self-hosting and I'm currently chasing the remaining issues. We are planning on releasing an open source MIPS64 implementation soon, and gcc will be the system compiler for the first release, but we'll be switching to clang very soon for that - long before 10.x goes EOL. MIPS has other serious issues (for example, gdb doesn't work at all - it can't even find the memory regions that contain the binary) and our ld is too old to support several of the GOT-related optimisations required to build large programs, so gcc is the least of its concerns, toolchain-wise. The MIPS binutils changes have not been upstreamed, so this is somewhat problematic as we don't have any useable toolchains for MIPS64, including gcc in base, for moderately-sized applications. This should be addressed some time over the next 6-12 months by switching MIPS over to LLVM / MCLinker. MIPS is perhaps the m ost important one because the new owners of MIPS are investing in LLVM quite heavily (they've been ramping up their LLVM development a lot over the last year even before the
Re: GCC withdraw
On 30 Aug 2013, at 08:18, Julian Elischer jul...@freebsd.org wrote: As far as I'm concerned we can even slate it for possible removal in 10.2-- if clang has proven up to the task I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). David ___ 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: GCC withdraw
On Friday, 30 August 2013 at 08:35, David Chisnall wrote: I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). Wouldn't this mean that we can't build base using the shipped-in-base g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++, then people wanting to compile the base system with gcc/g++ will have to install a libstdc++ package. I don't see how that's very different from requiring a gcc/g++ package. Jon -- Jonathan Anderson jonat...@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: GCC withdraw
On 30 Aug 2013, at 08:56, Jonathan Anderson jonat...@freebsd.org wrote: Wouldn't this mean that we can't build base using the shipped-in-base g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++, then people wanting to compile the base system with gcc/g++ will have to install a libstdc++ package. People wanting to build base with g++ will still have to explicitly enable the build of libstdc++, yes. That's only really an issue for 10.0 though, because in 10.1 we won't be able to build clang (or lldb) with either g++ from base or our libstdc++ from base, as both use C++11 features. David ___ 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: xhci broken on 10-CURRENT and 2013 MacBook Air?
Hi Hans
I tried the patch and the result is the same. However, I found the command
that causes the freeze. Also, it is not always it freezes but maybe 9/10
reboots or more frequently.
At the end of the function xhci_start_controller(..) there is a for loop:
487for (i = 0; i != 100; i++) {
488usb_pause_mtx(NULL, hz / 100);
489temp = XREAD4(sc, oper, XHCI_USBSTS) XHCI_STS_HCH;
490if (!temp)
491break;
492}
and it freezes at usb_pause_mtx(...)
value of i is 0
value of hz is 1000
Johannes Lundberg
BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp
On Fri, Aug 30, 2013 at 8:42 AM, Hans Petter Selasky h...@bitfrost.nowrote:
On 08/30/13 08:09, Lundberg, Johannes wrote:
What I got so far is this;
USB driver from current stops after
xhci0: 32 byte context size
While driver from 9.1 continues to the next step which is
usbus0 on xhci0
xhci0: usbpf: Attached
...
I can try adding some printf's in the code and see if I get some more..
Hi,
There are only a few commits to the xhci driver since 9.1 was releases, so
this should be easy to figure out.
I'm doing a wild guess. Can you try the attached patch. It will ensure
that any BIOS generated interrupts get cleared before we reset the
controller.
--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
Re: xhci broken on 10-CURRENT and 2013 MacBook Air?
On 08/30/13 11:35, Lundberg, Johannes wrote:
Hi Hans
I tried the patch and the result is the same. However, I found the command
that causes the freeze. Also, it is not always it freezes but maybe 9/10
reboots or more frequently.
At the end of the function xhci_start_controller(..) there is a for loop:
487for (i = 0; i != 100; i++) {
488usb_pause_mtx(NULL, hz / 100);
489temp = XREAD4(sc, oper, XHCI_USBSTS) XHCI_STS_HCH;
490if (!temp)
491break;
492}
and it freezes at usb_pause_mtx(...)
value of i is 0
value of hz is 1000
Hi,
Can you try the attached patch?
I think this is a problem inside DELAY(). Maybe you have to select
another timing source for DELAY(), mav @ CC'ed?
--HPS
=== sys/kern/kern_synch.c
==
--- sys/kern/kern_synch.c (revision 254832)
+++ sys/kern/kern_synch.c (local)
@@ -356,11 +356,8 @@
int
pause_sbt(const char *wmesg, sbintime_t sbt, sbintime_t pr, int flags)
{
- int sbt_sec;
+ KASSERT(sbt = 0, (pause: timeout must be = 0));
- sbt_sec = sbintime_getsec(sbt);
- KASSERT(sbt_sec = 0, (pause: timo must be = 0));
-
/* silently convert invalid timeouts */
if (sbt == 0)
sbt = tick_sbt;
@@ -370,11 +367,14 @@
* We delay one second at a time to avoid overflowing the
* system specific DELAY() function(s):
*/
- while (sbt_sec 0) {
+ while (sbt = SBT_1S) {
DELAY(100);
- sbt_sec--;
+ sbt -= SBT_1S;
}
- DELAY((sbt 0x) / SBT_1US);
+ /* Do the delay remainder */
+ sbt /= SBT_1US;
+ if (sbt != 0)
+ DELAY(sbt);
return (0);
}
return (_sleep(pause_wchan[curcpu], NULL, 0, wmesg, sbt, pr, flags));
___
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
Shared object libssl.so.6 not found solution
# uname -a FreeBSD RnD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254766: Sat Aug 24 14:36:08 BDT 2013 biddut@RnD:/usr/obj/usr/src/sys/GENERIC i386 # svn update /usr/src Shared object libssl.so.6 not found, required by libserf-1.so.0 solution root@RnD:/usr/src # ln -s /usr/lib/libssl.so.7 /usr/lib/libssl.so.6 root@RnD:/usr/src # ___ 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: Shared object libssl.so.6 not found solution
Le 30/08/2013 10:47, biddut.mi...@ovi.com a écrit : # uname -a FreeBSD RnD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254766: Sat Aug 24 14:36:08 BDT 2013 biddut@RnD:/usr/obj/usr/src/sys/GENERIC i386 # svn update /usr/src Shared object libssl.so.6 not found, required by libserf-1.so.0 solution root@RnD:/usr/src # ln -s /usr/lib/libssl.so.7 /usr/lib/libssl.so.6 Uhu Ô.o That's *not* a solution, no more than a workaround, it's bad, it hurts brains… The real solution is to rebuild subversion. -- Florent Peterschmitt | Please: flor...@peterschmitt.fr| * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) signature.asc Description: OpenPGP digital signature
Re: Shared object libssl.so.6 not found solution
Le 30/08/2013 13:38, Florent Peterschmitt a écrit : The real solution is to rebuild subversion. Woops, it's to rebuild www/serf signature.asc Description: OpenPGP digital signature
Re: xhci broken on 10-CURRENT and 2013 MacBook Air?
Still got the same behaviour after applying the patch...
Johannes Lundberg
BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp
On Fri, Aug 30, 2013 at 12:13 PM, Hans Petter Selasky h...@bitfrost.nowrote:
On 08/30/13 11:35, Lundberg, Johannes wrote:
Hi Hans
I tried the patch and the result is the same. However, I found the command
that causes the freeze. Also, it is not always it freezes but maybe 9/10
reboots or more frequently.
At the end of the function xhci_start_controller(..) there is a for loop:
487for (i = 0; i != 100; i++) {
488usb_pause_mtx(NULL, hz / 100);
489temp = XREAD4(sc, oper, XHCI_USBSTS) XHCI_STS_HCH;
490if (!temp)
491break;
492}
and it freezes at usb_pause_mtx(...)
value of i is 0
value of hz is 1000
Hi,
Can you try the attached patch?
I think this is a problem inside DELAY(). Maybe you have to select another
timing source for DELAY(), mav @ CC'ed?
--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
Re: xhci broken on 10-CURRENT and 2013 MacBook Air?
On 08/30/13 13:54, Lundberg, Johannes wrote:
Still got the same behaviour after applying the patch...
Johannes Lundberg
BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp
I've seen something similar with my mac, that the boot menu counter is
not always counting stable. I think this problem is inside the following
function, if you say that the code is stuck inside pause():
sys/x86/isa/clock.c:DELAY()
Maybe you can try this patch instead. Just apply it by hand:
=== sys/x86/isa/clock.c
==
--- sys/x86/isa/clock.c (revision 254832)
+++ sys/x86/isa/clock.c (local)
@@ -262,6 +262,7 @@
timecounter_get_t *func;
uint64_t end, freq, now;
u_int last, mask, u;
+ int overflow = 0;
tc = timecounter;
freq = atomic_load_acq_64(tsc_freq);
@@ -281,6 +282,11 @@
sched_pin();
last = func(tc) mask;
do {
+ if (--overflow == 0) {
+ printf(DELAY overflow\n);
+ break;
+ }
+
cpu_spinwait();
u = func(tc) mask;
if (u last)
@@ -304,6 +310,7 @@
DELAY(int n)
{
int delta, prev_tick, tick, ticks_left;
+ int overflow = 0;
#ifdef DELAYDEBUG
int getit_calls = 1;
int n1;
@@ -365,6 +372,10 @@
/ 100;
while (ticks_left 0) {
+ if (--overflow == 0) {
+ printf(DELAY overflow\n);
+ break;
+ }
#ifdef KDB
if (kdb_active) {
#ifdef PC98
--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
Re: Shared object libssl.so.6 not found solution
... well, this is why Peter committed svnlite to -HEAD. To avoid this kind of not-easy-to-recover-from breakage.. -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: xhci broken on 10-CURRENT and 2013 MacBook Air?
Hi Hans
I tried that too and no change... But, the variable overflow you
introduced, it is never increased, right? So, it will never become zero...
Johannes Lundberg
BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp
On Fri, Aug 30, 2013 at 2:26 PM, Hans Petter Selasky h...@bitfrost.nowrote:
On 08/30/13 13:54, Lundberg, Johannes wrote:
Still got the same behaviour after applying the patch...
Johannes Lundberg
BRILLIANTSERVICE CO., LTD.
http://www.brilliantservice.**co.jphttp://www.brilliantservice.co.jp
I've seen something similar with my mac, that the boot menu counter is not
always counting stable. I think this problem is inside the following
function, if you say that the code is stuck inside pause():
sys/x86/isa/clock.c:DELAY()
Maybe you can try this patch instead. Just apply it by hand:
=== sys/x86/isa/clock.c
==**==**==
--- sys/x86/isa/clock.c (revision 254832)
+++ sys/x86/isa/clock.c (local)
@@ -262,6 +262,7 @@
timecounter_get_t *func;
uint64_t end, freq, now;
u_int last, mask, u;
+ int overflow = 0;
tc = timecounter;
freq = atomic_load_acq_64(tsc_freq);
@@ -281,6 +282,11 @@
sched_pin();
last = func(tc) mask;
do {
+ if (--overflow == 0) {
+ printf(DELAY overflow\n);
+ break;
+ }
+
cpu_spinwait();
u = func(tc) mask;
if (u last)
@@ -304,6 +310,7 @@
DELAY(int n)
{
int delta, prev_tick, tick, ticks_left;
+ int overflow = 0;
#ifdef DELAYDEBUG
int getit_calls = 1;
int n1;
@@ -365,6 +372,10 @@
/ 100;
while (ticks_left 0) {
+ if (--overflow == 0) {
+ printf(DELAY overflow\n);
+ break;
+ }
#ifdef KDB
if (kdb_active) {
#ifdef PC98
--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
Default kern.ipc.shm_allow_removed to 1
Would it be feasible to change the default for 10? There is a lot of code that depends on the following behavior: void* address = shmat(shmkey, NULL /* desired address */, 0 /* flags */); // Here we mark the shared memory for deletion. Since we attached it in the // line above, it doesn't actually get deleted but, if we crash, this means // that the kernel will automatically clean it up for us. shmctl(shmkey, IPC_RMID, 0); if (address == kInvalidAddress) return NULL; The above snip is from Google Chrome, under FreeBSD with the current defaults that memory becomes unusable. If you don't follow that route it becomes extremely difficult to cleanup especially in a beast like Chrome. From what I understand PC-BSD defaults to 1, OpenBSD and Linux also allow this behavior. Am I missing something obvious here? It seems to me that the pragmatic approach is to change this. Regards, George ___ 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: xhci broken on 10-CURRENT and 2013 MacBook Air?
On 08/30/13 15:19, Lundberg, Johannes wrote: Hi Hans I tried that too and no change... But, the variable overflow you introduced, it is never increased, right? So, it will never become zero... It will become zero when it wraps. Maybe 2**32 is too long. You could add a printf while it is running, and see if it goes == 100 for example. --HPS Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp On Fri, Aug 30, 2013 at 2:26 PM, Hans Petter Selasky h...@bitfrost.nowrote: On 08/30/13 13:54, Lundberg, Johannes wrote: Still got the same behaviour after applying the patch... Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.**co.jphttp://www.brilliantservice.co.jp ___ 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: GCC withdraw
I've been reading this thread and must confess that I'm a little confused about what exactly is being discussed. * I presume we've all agreed that clang is installed by default in FreeBSD-10. * I presume everyone agrees that cc is clang in FreeBSD-10. * There obviously needs to be a gcc command in FreeBSD-10, since cc and gcc are synonyms in so many people's finger-memory. Is the debate here just a question of whether gcc is clang or the *real* GCC? Would it be feasible to install GCC as gcc42 or something similar so people could still reach it regardless of what the gcc alias pointed to? On 30 Aug 2013, at 08:56, Jonathan Anderson jonat...@freebsd.org wrote: ... then people wanting to compile the base system with gcc/g++ ... I'm still curious *why* some people want this? Personally, I would rather compile the base system with the *supported* compiler. Today, on FreeBSD-CURRENT/x86 and FreeBSD-CURRENT/amd64, that is clang. On Aug 30, 2013, at 12:18 AM, Julian Elischer jul...@freebsd.org wrote: Clang is new. clang WILL HAVE BUGS. Based on my own experience, I would put this rather differently: GCC and Clang are COMPILERS. Therefore, they have DIFFERENT BUGS. This is why I worry about having cc and gcc be different compilers. Tim ___ 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: GCC withdraw
I had a long, rambling reply to this that corrected many of the factual errors made in it. But why bother. You have your world view, it doesn't match what people are doing today and this mismatch is going to cause people pain and suffering in the embedded world far beyond what you think. And you've shown an extreme reluctance to accept that your world view isn't quite right, and listen to people. This makes me sad, but I recognize a lost cause when I see it. Do whatever the fuck you want, but it won't make your arguments right. And it won't keep me from saying I told you so when your optimistic timelines don't come to fruition, or the people processors you dismiss as being too weak to run a full FreeBSD (despite the fact they are doing it today) complain about the needless pain they are going through. 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: GCC withdraw
On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote: I had a long, rambling reply to this that corrected many of the factual errors made in it. But why bother. You have your world view, it doesn't match what people are doing today and this mismatch is going to cause people pain and suffering in the embedded world far beyond what you think. And you've shown an extreme reluctance to accept that your world view isn't quite right, and listen to people. This makes me sad, but I recognize a lost cause when I see it. Do whatever the fuck you want, but it won't make your arguments right. And it won't keep me from saying I told you so when your optimistic timelines don't come to fruition, or the people processors you dismiss as being too weak to run a full FreeBSD (despite the fact they are doing it today) complain about the needless pain they are going through. Warner Actually, I have to put a +1 on this. I also had a long reply full of reality-based refutations of various facts from this thread, and I also just deleted it because clearly the discussion has become pointless. -- Ian ___ 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: i915kms.ko not loading
On 29.08.2013 19:51, Alexander wrote: I have swapinfo on zfs partition I always heard that swap on ZFS is asking for trouble, because ZFS loves to use memory. So when the system is using swap space, ZFS has more work and therefore wants more RAM, whici is unavailable. Furthermore, I'm not sure if kernel core dumping on swap on ZFS is supported at all. The following discussion on the forum suggests it's not possible: http://forums.freebsd.org/showthread.php?t=37958 Can you plug another driver and setup swap on it? A USB drive/key should be fine. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: xhci broken on 10-CURRENT and 2013 MacBook Air?
I added printf at every 100,000th iteration in both locations but I didn't get any output at all.. Seems it stuck in some other place. During my test I actually passed that stage a couple of times but still the xhci_do_command times out and I get the mountroot prompt With the 9.1 driver I never get either of the errors. Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp On Fri, Aug 30, 2013 at 3:32 PM, Hans Petter Selasky h...@bitfrost.nowrote: On 08/30/13 15:19, Lundberg, Johannes wrote: Hi Hans I tried that too and no change... But, the variable overflow you introduced, it is never increased, right? So, it will never become zero... It will become zero when it wraps. Maybe 2**32 is too long. You could add a printf while it is running, and see if it goes == 100 for example. --HPS Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.**co.jphttp://www.brilliantservice.co.jp On Fri, Aug 30, 2013 at 2:26 PM, Hans Petter Selasky h...@bitfrost.no wrote: On 08/30/13 13:54, Lundberg, Johannes wrote: Still got the same behaviour after applying the patch... Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp http://www.**brilliantservice.co.jp http://www.brilliantservice.co.jp ___ 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: xhci broken on 10-CURRENT and 2013 MacBook Air?
On 08/30/13 15:53, Lundberg, Johannes wrote: I added printf at every 100,000th iteration in both locations but I didn't get any output at all.. Seems it stuck in some other place. During my test I actually passed that stage a couple of times but still the xhci_do_command times out and I get the mountroot prompt With the 9.1 driver I never get either of the errors. Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp Hi, If you have a git checkout of the FreeBSD source tree, you can try stripping away patches for xhci*.[ch] only, since end of December 2012. The 9- and 10- XHCI code should be almost the same, except for the streams mode support. Here is a list of patches you can try to revert if I get it right: commit 2969ec61bfd9be3fdcaa50432755d24df345874d Author: hselasky hsela...@freebsd.org Date: Fri Jul 26 06:24:33 2013 + MFC r253532: Fix an XHCI regression: The Block Event Interrupts, BEI, feature does not work like expected with the Renesas XHCI chipsets. Revert feature. While at it correct the TD SIZE computation in case of Zero Length Packet, ZLP, in the end of a multi frame USB transfer. PR: usb/180726 Approved by:re, hrs commit 7dbeb07e555c5e9649fac8079a4b3bcdd57b2cfc Author: hselasky hsela...@freebsd.org Date: Tue Jun 11 06:18:51 2013 + MFC r251249, r251251, r251252, r2512, r251254 and r251515: Correct XHCI DMA descriptor programming. Correct maximum IRQ rate. commit 1941cac2597eea224c9e0e76a789692dfa8dda91 Author: marius mar...@freebsd.org Date: Sat Mar 9 02:36:32 2013 + MFC: r227309 (partial) Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs. The SYSCTL_NODE macro defines a list that stores all child-elements of that node. If there's no SYSCTL_DECL macro anywhere else, there's no reason why it shouldn't be static. commit 9b2efd37b6d3afb84b234348094adf8cc533e2c6 Author: hselasky hsela...@freebsd.org Date: Wed Feb 6 11:08:11 2013 + MFC r246113 and r246126: Add missing NULL pointer check. Reported by: Lars Engels commit 63af294dc7c2db6a120eba9cec16fabec13aeec1 Author: hselasky hsela...@freebsd.org Date: Mon Jan 21 07:25:38 2013 + MFC r245132 and r245175: Optimise the XHCI interrupt handling. This patch will save CPU time when the XHCI interrupt is shared with other devices. Only check event rings when interrupt bits are set. Otherwise would indicate hiding possible hardware fault(s). Tested by: sos @ Submitted by: sos @ commit fa4f2cf0b90d6c5ce9eca2417e200fb693d6f239 Author: hselasky hsela...@freebsd.org Date: Mon Jan 21 07:22:45 2013 + MFC r243780: - Add support for Etron EJ168 USB 3.0 Host Controllers. This brand of controllers expects that the number of contexts specified in the input slot context points to an active endpoint context, else it refuses to operate. - Wrap one or two long lines. Tested by: Markus Pfeiffer (DragonFlyBSD) --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
Re: GCC withdraw
30.08.2013 11:33, David Chisnall пишет: The time to raise objections for this was when the plan was originally raised over a year ago David, can you please point me to the original plan with gcc removal at 10.x? (I do remember only a plan to make clang the default compiler, but I may be wrong here) Thanks. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: GCC withdraw
On 08/30/13 00:35, David Chisnall wrote: On 30 Aug 2013, at 08:18, Julian Elischer jul...@freebsd.org wrote: As far as I'm concerned we can even slate it for possible removal in 10.2-- if clang has proven up to the task I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). So the real driver here is switching to libc++. Is there really no way at all to use it with gcc? If, even with hacking, we could arrange that to work then it seems that all of our problems would go away. -Nathan ___ 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: GCC withdraw
On 30 Aug 2013, at 15:41, John Baldwin j...@freebsd.org wrote: So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. I expect that platforms that don't have support from clang or some external toolchain will die. If people care about IA64, then getting Intel's compiler working as an external toolchain would probably be a good idea (it generates vastly better code than gcc). If people care about SPARC64, then either gcc from ports as an external toolchain, or finishing up the SPARC64 back end in LLVM are options. Finishing the SPARC64 back end is not that much effort (it's probably a couple of person-months of work - getting the calling conventions right does require some small tweaks to LLVM IR that I think someone's working on), but it hasn't been done because no one appears to care quite enough to make it a priority. Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked the relevant ports so that everything is built with clang. I would also love to be able to build the base system with GCC 47 instead of 42, it just doesn't seem that we are there yet. The time to raise objections for this was when the plan was originally raised over a year ago, or at any of the points when it's been discussed in between. It is not after we're ready to flip the switch. So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@ and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86. Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of Oh, don't bother cause I'm disabling GCC next week (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? Yes, we certainly could have communicated this better. I was under the impression that this was widespread common knowledge and something I've personally discussed with various people including ports people on several occasions. I would have made the commit a couple of months ago, but getting the ports infrastructure back up to a state where it's easy to test has been a blocker there. If removing gcc from the standard install is going to cause major pain for people, then we can leave it in for 10.0. I'm currently doing a make tinderbox on the removal patch, modified to leave gcc in, and only remove libstdc++, which is something that we definitely need to do because it's causing an amount of pain that is only going to increase. I have no plans to make anything in the base system (other than clang itself, when 3.4 is imported) depend on libc++-only features (I'd love to do it for dtc, but it has to run on embedded platforms that are going to be stuck with libstdc++ in base for a while - at least a year, and that's if we're lucky). Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) - On platforms where clang is cc, allow building libstdc++ by setting the WITH_GNUCXX flag - On platforms where clang is cc, allow building gcc by setting the WITH_GCCflag - On platforms where clang is not cc, leave gcc as the default system compiler - On platforms where clang is not cc, leave libstdc++ as the default system STL, but encourage ports to start depending explicitly on ports-libstdc++ so that they don't suffer from ABI mismatch issues. If your workflow depends on gcc on a clang-is-cc platform, then you are free to install it. If your workflow depends on libstdc++ on a clang-is-cc platform, then you are free to install it, clang will still use it if you specify -stdlib=libstdc++. If your workflow depends on gcc or libstdc++ on any other platform, you will see no difference. If you need to test whether building the base system or kernel with gcc fixes things that are broken, then you
Re: GCC withdraw
On 30 Aug 2013, at 15:53, Nathan Whitehorn nwhiteh...@freebsd.org wrote: So the real driver here is switching to libc++. Is there really no way at all to use it with gcc? If, even with hacking, we could arrange that to work then it seems that all of our problems would go away. If we can make our g++ compile C++11 code, then we can compile libc++ with g++. This support requires significant modifications to the parser (it adds a second Turing-complete compile-time language, for one...) and so retrofitting C++11 support to g++ 4.2.1 is not going to happen. It's taken upstream gcc a couple of years to get to the required level of support. We don't have the manpower to replicate this. David ___ 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: GCC withdraw
Only a few comments in reply to avoid banging my head against a brick wall and then I'm done: On Friday, August 30, 2013 3:33:21 am David Chisnall wrote: On 29 Aug 2013, at 18:44, John Baldwin j...@freebsd.org wrote: Also, unless you plan on desupporting all non-x86 platforms, you _still_ have to do all this work while those platforms require GCC anyway. Just turning off GCC on x86 doesn't change this problem one iota. And that point is actually relevant to many of the other concerns you raised. It's not at all clear what disabling GCC on x86 will buy you unless you are intending on short-changing support for GCC on non-x86. It gives us a much cleaner deprecation strategy. Ports on tier-2 are best effort. We don't need to be quite as careful to ensure that they build with the base system compiler on tier-2 architectures. We don't make as strong guarantees about compatibility on tier-2 architectures, so removing gcc from their build at some point over the next five years is fine, but this is not the case for tier 1 architectures, where we can be reasonably expected to support anything that is in the base system for the next five years. [snip] So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked the relevant ports so that everything is built with clang. I would also love to be able to build the base system with GCC 47 instead of 42, it just doesn't seem that we are there yet. The time to raise objections for this was when the plan was originally raised over a year ago, or at any of the points when it's been discussed in between. It is not after we're ready to flip the switch. So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@ and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86. Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of Oh, don't bother cause I'm disabling GCC next week (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? -- 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: GCC withdraw
On Fri, Aug 30, 2013 at 6:47 AM, Ian Lepore i...@freebsd.org wrote: On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote: I had a long, rambling reply to this that corrected many of the factual errors made in it. But why bother. You have your world view, it doesn't match what people are doing today and this mismatch is going to cause people pain and suffering in the embedded world far beyond what you think. And you've shown an extreme reluctance to accept that your world view isn't quite right, and listen to people. This makes me sad, but I recognize a lost cause when I see it. Do whatever the fuck you want, but it won't make your arguments right. And it won't keep me from saying I told you so when your optimistic timelines don't come to fruition, or the people processors you dismiss as being too weak to run a full FreeBSD (despite the fact they are doing it today) complain about the needless pain they are going through. Warner Actually, I have to put a +1 on this. I also had a long reply full of reality-based refutations of various facts from this thread, and I also just deleted it because clearly the discussion has become pointless. I don't really have any skin in this game; the vendor I work for uses x86 hardware, and we're not ready to be running on FreeBSD 10 yet. But as an old guy I really don't see why we'd change the plan of record so late. Nor do I think prioritizing ports over the base system on alternate architectures is the right play -- there's a lot of vendors who use FreeBSD on !x86. And there's a lot of vendors who don't use very many ports. And there's a lot of vendors putting money into the FreeBSD foundation, and into the hands of FreeBSD committers, to make it better. Vendors who, while it would be painful to switch, do have a choice of which OS to build their product around. Just my 2c. Actual value may differ. Cheers, matthew ___ 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: GCC withdraw
On Fri, Aug 30, 2013 at 08:33:21AM +0100, David Chisnall wrote: On 29 Aug 2013, at 18:44, John Baldwin j...@freebsd.org wrote: default every time, that we're telling people not to use, won't help with that... This is your worst argument as clang is known to take far longer than GCC to build. :) Not really. Clang + gcc takes longer to build than just clang. Building gcc is in the noise. I've sent you number on this. John is correct. It takes much much longer to buildworld with clang. -- Steve ___ 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
gobject-introspection-1.36.0_1 problem compiling causing xorg to fail
CC gthash_test-gthash-test.o
CCLD gthash-test
CC gi_dump_types-gdump.o
CC gi_dump_types-gi-dump-types.o
CCLD gi-dump-types
CC glib_print-glib-print.o
CCLD glib-print
GEN g-ir-scanner
GEN g-ir-annotation-tool
GISCAN GLib-2.0.gir
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
File /usr/local/lib/python2.7/hashlib.py, line 139, in module
globals()[__func_name] = __get_hash(__func_name)
File /usr/local/lib/python2.7/hashlib.py, line 91, in __get_builtin_construc
tor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
ERROR:root:code for hash sha1 was not found.
Traceback (most recent call last):
File /usr/local/lib/python2.7/hashlib.py, line 139, in module
globals()[__func_name] = __get_hash(__func_name)
File /usr/local/lib/python2.7/hashlib.py, line 91, in __get_builtin_construc
tor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha1
ERROR:root:code for hash sha224 was not found.
Traceback (most recent call last):
File /usr/local/lib/python2.7/hashlib.py, line 139, in module
globals()[__func_name] = __get_hash(__func_name)
File /usr/local/lib/python2.7/hashlib.py, line 91, in __get_builtin_construc
tor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha224
ERROR:root:code for hash sha256 was not found.
Traceback (most recent call last):
File /usr/local/lib/python2.7/hashlib.py, line 139, in module
globals()[__func_name] = __get_hash(__func_name)
File /usr/local/lib/python2.7/hashlib.py, line 91, in __get_builtin_construc
tor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha256
ERROR:root:code for hash sha384 was not found.
Traceback (most recent call last):
File /usr/local/lib/python2.7/hashlib.py, line 139, in module
globals()[__func_name] = __get_hash(__func_name)
File /usr/local/lib/python2.7/hashlib.py, line 91, in __get_builtin_construc
tor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha384
ERROR:root:code for hash sha512 was not found.
Traceback (most recent call last):
File /usr/local/lib/python2.7/hashlib.py, line 139, in module
globals()[__func_name] = __get_hash(__func_name)
File /usr/local/lib/python2.7/hashlib.py, line 91, in __get_builtin_construc
tor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha512
Traceback (most recent call last):
File ./g-ir-scanner, line 46, in module
sys.exit(scanner_main(sys.argv))
File ./giscanner/scannermain.py, line 443, in scanner_main
transformer = create_transformer(namespace, options)
File ./giscanner/scannermain.py, line 318, in create_transformer
accept_unprefixed=options.accept_unprefixed)
File ./giscanner/transformer.py, line 52, in __init__
self._cachestore = CacheStore()
File ./giscanner/cachestore.py, line 81, in __init__
self._check_cache_version()
File ./giscanner/cachestore.py, line 87, in _check_cache_version
current_hash = _get_versionhash()
File ./giscanner/cachestore.py, line 41, in _get_versionhash
return hashlib.sha1(''.join(mtimes)).hexdigest()
AttributeError: 'module' object has no attribute 'sha1'
gmake[14]: *** [GLib-2.0.gir] Error 1
gmake[14]: Leaving directory
`/usr/ports/devel/gobject-introspection/work/gobject-introspection-1.36.0'
gmake[13]: *** [all-recursive] Error 1
gmake[13]: Leaving directory `/usr/ports/devel/gobject-introspection/work/gobjec
t-introspection-1.36.0'
gmake[12]: *** [all] Error 2
gmake[12]: Leaving directory `/usr/ports/devel/gobject-introspection/work/gobjec
t-introspection-1.36.0'
*** Error code 1
Stop.
make[11]: stopped in /usr/ports/devel/gobject-introspection
*** Error code 1
Stop.
make[10]: stopped in /usr/ports/sysutils/polkit
*** Error code 1
Stop.
make[9]: stopped in /usr/ports/sysutils/polkit
*** Error code 1
Stop.
make[8]: stopped in /usr/ports/sysutils/consolekit
*** Error code 1
Stop.
make[7]: stopped in /usr/ports/sysutils/hal
*** Error code 1
Stop.
make[6]: stopped in /usr/ports/sysutils/hal
*** Error code 1
Stop.
make[5]: stopped in /usr/ports/x11-servers/xorg-server
*** Error code 1
Stop.
make[4]: stopped in /usr/ports/x11-servers/xorg-server
*** Error code 1
Stop.
make[3]: stopped in /usr/ports/x11-drivers/xf86-input-mouse
*** Error code 1
Stop.
make[2]: stopped in /usr/ports/x11-drivers/xorg-drivers
*** Error code 1
Stop.
make[1]: stopped in /usr/ports/x11-drivers/xorg-drivers
*** Error code 1
Stop.
make: stopped in /usr/ports/x11/xorg
___
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
2013 MacBook Air Project
Hi I thought I'd give a progress report on running FreeBSD 10 on a MacBook Air 11 2013 model. PCI-E SSD DRIVE - Added device ID to device list. Should be committed to head already. - Failed to write partition table due to weird characters at the end in the SSD's identifier key. Solved by ugly hack (cutting off the ident string in the middle), fix not committed. SMP - No problem when booting from usb memory stick. However, have to disable smp in /boot/loader.conf with kern.smp.disabled=1 to boot from the SSD. USB - Reverted sys/dev/usb/controller/xhci* to 243780 to make it work. WIFI - Seems like this one is gonna be difficult due to Broadcom's proprietary driver ETHERNET - Thunderbolt adapter works fine but hot-plugging not supported so you need to connect it before booting. BLUETOOTH - Added device to usbdevs and ng_ubt.c. Device is recognised and ubt0 created but when running service bluetooth start ubt0 I get Unable to setup Bluetooth stack for device ubt0. Works fine with other generic bluetooth 4.0 usb dongle. No debugging done. Will install Xorg next week so report about that coming later. Best Regards Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp ___ 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: GCC withdraw
On Fri, Aug 30, 2013 at 11:11 AM, David Chisnall thera...@freebsd.orgwrote: On 30 Aug 2013, at 15:41, John Baldwin j...@freebsd.org wrote: So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. I expect that platforms that don't have support from clang or some external toolchain will die. If people care about IA64, then getting Intel's compiler working as an external toolchain would probably be a good idea (it generates vastly better code than gcc). If people care about SPARC64, then either gcc from ports as an external toolchain, or finishing up the SPARC64 back end in LLVM are options. Finishing the SPARC64 back end is not that much effort (it's probably a couple of person-months of work - getting the calling conventions right does require some small tweaks to LLVM IR that I think someone's working on), but it hasn't been done because no one appears to care quite enough to make it a priority. Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked the relevant ports so that everything is built with clang. I would also love to be able to build the base system with GCC 47 instead of 42, it just doesn't seem that we are there yet. The time to raise objections for this was when the plan was originally raised over a year ago, or at any of the points when it's been discussed in between. It is not after we're ready to flip the switch. So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86. Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of Oh, don't bother cause I'm disabling GCC next week (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? Yes, we certainly could have communicated this better. I was under the impression that this was widespread common knowledge and something I've personally discussed with various people including ports people on several occasions. I would have made the commit a couple of months ago, but getting the ports infrastructure back up to a state where it's easy to test has been a blocker there. If removing gcc from the standard install is going to cause major pain for people, then we can leave it in for 10.0. I'm currently doing a make tinderbox on the removal patch, modified to leave gcc in, and only remove libstdc++, which is something that we definitely need to do because it's causing an amount of pain that is only going to increase. I have no plans to make anything in the base system (other than clang itself, when 3.4 is imported) depend on libc++-only features (I'd love to do it for dtc, but it has to run on embedded platforms that are going to be stuck with libstdc++ in base for a while - at least a year, and that's if we're lucky). Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) - On platforms where clang is cc, allow building libstdc++ by setting the WITH_GNUCXX flag - On platforms where clang is cc, allow building gcc by setting the WITH_GCCflag - On platforms where clang is not cc, leave gcc as the default system compiler - On platforms where clang is not cc, leave libstdc++ as the default system STL, but encourage ports to start depending explicitly on ports-libstdc++ so that they don't suffer from ABI mismatch issues. If your workflow depends on gcc on a clang-is-cc platform, then you are free to install it. If your workflow depends on libstdc++ on a clang-is-cc platform, then you are free to install it, clang will still use it if you specify -stdlib=libstdc++. If your workflow depends on gcc or libstdc++ on any other platform, you will see no
Re: GCC withdraw
On Fri, Aug 30, 2013 at 06:38:41AM -0700, Tim Kientzle wrote: On 30 Aug 2013, at 08:56, Jonathan Anderson jonat...@freebsd.org wrote: ... then people wanting to compile the base system with gcc/g++ ... I'm still curious *why* some people want this? Buildworld completes in 1/4th the amount of time with gcc and it consumes much less memory. -- Steve ___ 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: i915kms.ko not loading
Jean-Sbastien Pdron wrote this message on Fri, Aug 30, 2013 at 15:50 +0200: On 29.08.2013 19:51, Alexander wrote: I have swapinfo on zfs partition I always heard that swap on ZFS is asking for trouble, because ZFS loves to use memory. So when the system is using swap space, ZFS has more work and therefore wants more RAM, whici is unavailable. Furthermore, I'm not sure if kernel core dumping on swap on ZFS is supported at all. The following discussion on the forum suggests it's not possible: http://forums.freebsd.org/showthread.php?t=37958 Can you plug another driver and setup swap on it? A USB drive/key should be fine. You don't need to use a swap device to dump to it... You can just set up the USB drive as the dump device only... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: i915kms.ko not loading
30.08.2013 20:11, John-Mark Gurney пишет: Jean-Sbastien Pdron wrote this message on Fri, Aug 30, 2013 at 15:50 +0200: On 29.08.2013 19:51, Alexander wrote: I have swapinfo on zfs partition I always heard that swap on ZFS is asking for trouble, because ZFS loves to use memory. So when the system is using swap space, ZFS has more work and therefore wants more RAM, whici is unavailable. Furthermore, I'm not sure if kernel core dumping on swap on ZFS is supported at all. The following discussion on the forum suggests it's not possible: http://forums.freebsd.org/showthread.php?t=37958 Can you plug another driver and setup swap on it? A USB drive/key should be fine. You don't need to use a swap device to dump to it... You can just set up the USB drive as the dump device only... Hi I created the coredump files after create swap on new disk. But size very large. Where can I upload these files. ls -lah /var/crash ... -rw-r--r-- 1 root wheel 2B Aug 30 20:27 bounds -rw--- 1 root wheel 480B Aug 30 20:27 info.0 lrwxr-xr-x 1 root wheel 6B Aug 30 20:27 info.last - info.0 -r--r--r-- 1 root wheel 5B Jul 19 2010 minfree -rw--- 1 root wheel 450M Aug 30 20:27 vmcore.0 lrwxr-xr-x 1 root wheel 8B Aug 30 20:27 vmcore.last - vmcore.0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw
Subject: Re: GCC withdraw From: Warner Losh i...@bsdimp.com Date: Thu, 29 Aug 2013 10:00:19 -0600 Gcc is still an absolute requirement on all non-x86 platforms (including arm) due to the issues with clang. Some of these issues are bugs in specific things (arm) that keep coming up (and keep getting fixed), while others are more severe (sparc64 has no clang support, and don't forget ia64 Anton ___ 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: GCC withdraw
On Fri, Aug 30, 2013 at 04:11:08PM +0100, David Chisnall wrote: Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) And remember about breaking firewire+clang ___ 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: i915kms.ko not loading
Le 30/08/2013 19:45, Alexander a écrit : Hi I created the coredump files after create swap on new disk. But size very large. Great! Could you please run: kgdb /boot/kernel/kernel /var/crash/vmcore.0 And, at gdb prompt: bt Then send the whole output (from the moment you run kgdb to the end of bt output) and your /var/log/messages file? -- Jean-Sébastien Pédron ___ 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: Default kern.ipc.shm_allow_removed to 1
On Friday, August 30, 2013 9:30:09 am George Liaskos wrote: Would it be feasible to change the default for 10? There is a lot of code that depends on the following behavior: void* address = shmat(shmkey, NULL /* desired address */, 0 /* flags */); // Here we mark the shared memory for deletion. Since we attached it in the // line above, it doesn't actually get deleted but, if we crash, this means // that the kernel will automatically clean it up for us. shmctl(shmkey, IPC_RMID, 0); if (address == kInvalidAddress) return NULL; The above snip is from Google Chrome, under FreeBSD with the current defaults that memory becomes unusable. If you don't follow that route it becomes extremely difficult to cleanup especially in a beast like Chrome. From what I understand PC-BSD defaults to 1, OpenBSD and Linux also allow this behavior. Am I missing something obvious here? It seems to me that the pragmatic approach is to change this. Hmm, I can see why that is useful though it seems to violate POSIX. This claims that IPC_RMID should delete the segment immediately (which does not seem useful): http://pubs.opengroup.org/onlinepubs/007904975/functions/shmctl.html -- 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: 2013 MacBook Air Project
This is so cool! Do you have a repo on github with these patches? On 8/30/13 9:25 AM, Lundberg, Johannes wrote: Hi I thought I'd give a progress report on running FreeBSD 10 on a MacBook Air 11 2013 model. PCI-E SSD DRIVE - Added device ID to device list. Should be committed to head already. - Failed to write partition table due to weird characters at the end in the SSD's identifier key. Solved by ugly hack (cutting off the ident string in the middle), fix not committed. SMP - No problem when booting from usb memory stick. However, have to disable smp in /boot/loader.conf with kern.smp.disabled=1 to boot from the SSD. USB - Reverted sys/dev/usb/controller/xhci* to 243780 to make it work. WIFI - Seems like this one is gonna be difficult due to Broadcom's proprietary driver ETHERNET - Thunderbolt adapter works fine but hot-plugging not supported so you need to connect it before booting. BLUETOOTH - Added device to usbdevs and ng_ubt.c. Device is recognised and ubt0 created but when running service bluetooth start ubt0 I get Unable to setup Bluetooth stack for device ubt0. Works fine with other generic bluetooth 4.0 usb dongle. No debugging done. Will install Xorg next week so report about that coming later. Best Regards Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp ___ 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 -- Alfred Perlstein ___ 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: 2013 MacBook Air Project
Thanks :) No github but I will attach the patches in this mail. Remember, the diskgeom patch is a ugly hack Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp On Fri, Aug 30, 2013 at 11:38 PM, Alfred Perlstein bri...@mu.org wrote: This is so cool! Do you have a repo on github with these patches? On 8/30/13 9:25 AM, Lundberg, Johannes wrote: Hi I thought I'd give a progress report on running FreeBSD 10 on a MacBook Air 11 2013 model. PCI-E SSD DRIVE - Added device ID to device list. Should be committed to head already. - Failed to write partition table due to weird characters at the end in the SSD's identifier key. Solved by ugly hack (cutting off the ident string in the middle), fix not committed. SMP - No problem when booting from usb memory stick. However, have to disable smp in /boot/loader.conf with kern.smp.disabled=1 to boot from the SSD. USB - Reverted sys/dev/usb/controller/xhci* to 243780 to make it work. WIFI - Seems like this one is gonna be difficult due to Broadcom's proprietary driver ETHERNET - Thunderbolt adapter works fine but hot-plugging not supported so you need to connect it before booting. BLUETOOTH - Added device to usbdevs and ng_ubt.c. Device is recognised and ubt0 created but when running service bluetooth start ubt0 I get Unable to setup Bluetooth stack for device ubt0. Works fine with other generic bluetooth 4.0 usb dongle. No debugging done. Will install Xorg next week so report about that coming later. Best Regards Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.**co.jphttp://www.brilliantservice.co.jp __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org freebsd-current-unsubscr...@freebsd.org -- Alfred Perlstein diskgeom.diff Description: Binary data machdep.diff Description: Binary data netgraph.diff Description: Binary data usbdevs.diff 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
