Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On 06/22/12 08:22, Hans Petter Selasky wrote: On Friday 22 June 2012 08:01:38 O. Hartmann wrote: I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? Regards, oh ugen7.6: Lexar at usbus7 umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted Hi, After plugging the device, try: usbconfig -d 7.6 add_quirk UQ_MSC_NO_INQUIRY Then re-plug it. I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) --HPS I tried the USB drive this morning with the recommended quirk shown above on FreeBSD 10.0-CURRENT #1 r237462: Sat Jun 23 01:00:35 CEST 2012 without success. I get the same error message as shown above. With or without quirk. I then started Windows 7 on the same box. The USB drive is seen as expected and reflects what I experienced on every other non-FreeBSD box and hardware in the lab on last week. I reformatted the USB drive with extFAT and standard block size on Windows 7. The USB drive is now seen again on FreeBSD and recognized as a drive. Seen in my sloppy terminology means: recognized as a disk. The hardware is recognized, but it is not recognized as a drive. The fact, that the very first time after I bought that USB drive, I was able to put several GB on it, use it on both FreeBSD 9-STABLE and 10-CURRENT, and then it broke, drives me nuts. Using the very same pen drive on other OSes even on the same hardware without issues makes me believe FreeBSD does have an issue, not the USB drive. I will fill the USB drive with data and try to use it very often on FreeBSD. Last time the error occured, it was read by a Suse Linux box. If I wouldn't know better I would say Linux tries to kill the USB drive ... But Linux did see it all the time. A usual customer would see it the same way, I guess. I will test and report next week when I have access to the other boxes and OSes again. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
At 09:21 23/06/2012, you wrote: I tried the USB drive this morning with the recommended quirk shown above on FreeBSD 10.0-CURRENT #1 r237462: Sat Jun 23 01:00:35 CEST 2012 without success. I get the same error message as shown above. With or without quirk. I then started Windows 7 on the same box. The USB drive is seen as expected and reflects what I experienced on every other non-FreeBSD box and hardware in the lab on last week. I reformatted the USB drive with extFAT and standard block size on Windows 7. The USB drive is now seen again on FreeBSD and recognized as a drive. Seen in my sloppy terminology means: recognized as a disk. The hardware is recognized, but it is not recognized as a drive. AFAIK extFAT is not directly supported by FreeBSD current. You must use fusefs-exfat to mount them. If you try to mount it as if it is a fat32, it won't work or weird problems may happen. It may be that fusefs-extfat has a bug and you get a 00 on rolldice encounter table. ___ 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: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On 21 June 2012 23:22, Hans Petter Selasky hsela...@c2i.net wrote: usbconfig -d 7.6 add_quirk UQ_MSC_NO_INQUIRY Then re-plug it. I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) Question - if that's the case, then why are we even doing that by default? 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: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On 06/23/12 10:39, Eduardo Morras wrote: At 09:21 23/06/2012, you wrote: I tried the USB drive this morning with the recommended quirk shown above on FreeBSD 10.0-CURRENT #1 r237462: Sat Jun 23 01:00:35 CEST 2012 without success. I get the same error message as shown above. With or without quirk. I then started Windows 7 on the same box. The USB drive is seen as expected and reflects what I experienced on every other non-FreeBSD box and hardware in the lab on last week. I reformatted the USB drive with extFAT and standard block size on Windows 7. The USB drive is now seen again on FreeBSD and recognized as a drive. Seen in my sloppy terminology means: recognized as a disk. The hardware is recognized, but it is not recognized as a drive. AFAIK extFAT is not directly supported by FreeBSD current. You must use fusefs-exfat to mount them. If you try to mount it as if it is a fat32, it won't work or weird problems may happen. It may be that fusefs-extfat has a bug and you get a 00 on rolldice encounter table. ... but even this does not work if FreeBSD does not recognize a device like /dev/da1, does it? Even with a ext4 filesystem, the computer should recognize a devcie I could access to mount via /dev/da1 signature.asc Description: OpenPGP digital signature
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Saturday 23 June 2012 11:52:53 Adrian Chadd wrote: On 21 June 2012 23:22, Hans Petter Selasky hsela...@c2i.net wrote: usbconfig -d 7.6 add_quirk UQ_MSC_NO_INQUIRY Then re-plug it. I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) Question - if that's the case, then why are we even doing that by default? Hi, Do you want a blacklist or do you want a whitelist? Please explain the pros and cons. I believe that those that program wrong shall be held responsible for that and given a chance to clean up, and not the opposite way around. As a senior programmer I can only testify that many people care equally little about what their computer is made of and what they eat. We probably need a control body to certify USB devices that is cheaper than USB.org, simply put. I think it is a bad idea to cripple all USB SCSI devices because what looks like the majority do not obey the rules of the specifications they are supposed to support. Else we need to make a new USB SCSI class for devices that are certified and one for devices that are not certified. Non-certified devices can have a limited SCSI command set, which should be implemented in the CAM layer like some kind of flag. If we could join heads on the Linux guys on this, we might be able to do something! Like having a pop-up every time a USB device fails certain tests. From the history we can predict what people will do when they do not know what they are doing. They will nail the guy doing it right and let the guy doing it wrong go free. And it seems like this happened before too ;-) I have a personal FreeBSD-native USB test utilty that runs mass storage devices through a series of tests. Most USB mass storage devices I've tested so far have obvious bugs, which either means their firmware can be hacked or made to crash. Also worth noting, that many USB device are not certified at all. It might be clever to look for the USB logo from USB.org next time you want to transfer X GB of personal data from location X to Y. --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: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
and hardware in the lab on last week. I reformatted the USB drive with extFAT and standard block size on Windows 7. The USB drive is now seen again on FreeBSD and recognized as this points that the pendrive's controller is not just flaky but horrid. The communiation with OS, and how/whether it is configured properly should not depend on what data is written to it - in your case exFAT metadata. It seems that controller manufacturer just did something to run on windows and linux instead of something that conform to USB mass storage interface standard :( Sorry but it may be hopeless case. ___ 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: [RFT] llquantize for FreeBSD's dtrace
Pedro Giffuni p...@freebsd.org wrote:
I am not a Dtrace user (yet) but I started to port the Log/linear
quantizations from Illumos:
http://dtrace.org/blogs/bmc/2011/02/08/llquantize/
Apparently this patch should do it:
http://people.freebsd.org/~pfg/patches/patch-llquantize-complete
Unfortunately when I tried to build current with Dtrace support,
my i386 Virtualbox VM got stuck in ctfmerge so this is
completely untested.
Testers that know how to use it are welcome :).
I applied it on 10-CURRENT amd64 from /usr/src with patch -p0
without any conflicts, but it doesn't appear to be working.
The example from the blog post above triggers an assertion
that is still reproducible when reducing the test case:
fk@r500 /tmp $sudo dtrace -n 'tick-1ms{@ = llquantize(i++, 10, 0, 6, 20);}'
Assertion failed: (!(arg (UINT16_MAX args[i].shift))), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
line 1429.
Changing the i++ to i seems to trigger a different bug
(or at least doesn't behave like I would expect):
fk@r500 /tmp $sudo dtrace -n 'tick-1ms{@ = llquantize(i, 10, 0, 6, 20);}'
dtrace: invalid probe specifier tick-1ms{@ = llquantize(i, 10, 0, 6, 20);}: in
action list: failed to resolve i: Unknown variable name
Replacing the i with a zero behaves similar to the version that uses i++ again:
fk@r500 /tmp $sudo dtrace -n 'tick-1ms{ i = 0; @ = llquantize(0, 10, 0, 6,
20);}'
Assertion failed: (!(arg (UINT16_MAX args[i].shift))), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
line 1429.
fk@r500 /tmp $gdb741 $(which dtrace) dtrace.core
[GDB will not be able to debug user-mode threads: Undefined symbol
td_thr_getxmmregs]
GNU gdb (GDB) 7.4.1 [GDB v7.4.1 for FreeBSD]
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-portbld-freebsd10.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/sbin/dtrace...done.
[New process 100454]
Core was generated by `dtrace'.
Program terminated with signal 6, Aborted.
#0 0x0008019a26ac in thr_kill () at thr_kill.S:3
3 RSYSCALL(thr_kill)
(gdb) where
#0 0x0008019a26ac in thr_kill () at thr_kill.S:3
#1 0x00080082ff5c in _thr_send_sig (thread=optimized out, sig=6) at
/usr/src/lib/libthr/thread/thr_sig.c:113
#2 0x0008008305b6 in _raise (sig=0) at
/usr/src/lib/libthr/thread/thr_sig.c:505
#3 0x000801a517d3 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#4 0x000800a91c60 in __assert (line=optimized out, file=optimized out,
expr=optimized out) at
/usr/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include/assert.h:56
#5 dt_compile_agg (dtp=0x80243f000, dnp=0x803e223e0, sdp=0x803e17140) at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c:1366
#6 0x000800a9257f in dt_compile_one_clause (pnp=optimized out,
cnp=optimized out, dtp=optimized out)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c:1597
#7 dt_compile_clause (dtp=0x80243f000, cnp=0x803e23040) at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c:1628
#8 0x000800a94441 in dt_compile (dtp=0x80243f000, context=362,
pspec=DTRACE_PROBESPEC_NAME, arg=0x0, cflags=128, argc=1, argv=0x802417040,
fp=0x0,
s=0x7fffd9ca tick-1ms{ i = 0; @ = llquantize(i, 10, 0, 6, 20);}) at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c:2396
#9 0x000800a948bc in dtrace_program_strcompile (dtp=0x18866, s=optimized
out, spec=DTRACE_PROBESPEC_PROVIDER, cflags=0, argc=-2123430480,
argv=optimized out)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c:2460
#10 0x00405ae4 in compile_str (dcp=0x802418e00) at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:766
#11 0x00403b41 in main (argc=optimized out, argv=0x7fffd668) at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1632
Fabian
signature.asc
Description: PGP signature
Re: [RFT] llquantize for FreeBSD's dtrace
Hello Fabian;
--- Sab 23/6/12, Fabian Keil ha scritto:
Pedro Giffuni p...@freebsd.org wrote:
I am not a Dtrace user (yet) but I started to port the
Log/linear
quantizations from Illumos:
http://dtrace.org/blogs/bmc/2011/02/08/llquantize/
Apparently this patch should do it:
http://people.freebsd.org/~pfg/patches/patch-llquantize-complete
Unfortunately when I tried to build current with Dtrace
support, my i386 Virtualbox VM got stuck in ctfmerge so
this is completely untested.
Testers that know how to use it are welcome :).
I applied it on 10-CURRENT amd64 from /usr/src with patch
-p0 without any conflicts, but it doesn't appear to be
working.
The example from the blog post above triggers an assertion
that is still reproducible when reducing the test case:
fk@r500 /tmp $sudo dtrace -n 'tick-1ms{@ = llquantize(i++,
10, 0, 6, 20);}'
Assertion failed: (!(arg (UINT16_MAX
args[i].shift))), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
line 1429.
Thanks for testing!
It seems like the syntax has changed from the time the
example from the blog was made. The code says:
/*
* For log/linear quantizations, we have between one and five
* arguments in addition to the expression:
*
*arg1 = Factor
*arg2 = Low magnitude
*arg3 = High magnitude
*arg4 = Number of steps per magnitude
*arg5 = Quantization increment value (defaults to 1)
*/
My suggestion would be to instead try using the test
scripts in
cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/
err.D_LLQUANT_FACTORSMALL.d (for example) has
@ = llquantize(0, 1, 0, 10, 10);
hope that helps!
Pedro.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] llquantize for FreeBSD's dtrace
Pedro Giffuni p...@freebsd.org wrote:
Hello Fabian;
--- Sab 23/6/12, Fabian Keil ha scritto:
Pedro Giffuni p...@freebsd.org wrote:
I am not a Dtrace user (yet) but I started to port the
Log/linear
quantizations from Illumos:
http://dtrace.org/blogs/bmc/2011/02/08/llquantize/
Apparently this patch should do it:
http://people.freebsd.org/~pfg/patches/patch-llquantize-complete
Unfortunately when I tried to build current with Dtrace
support, my i386 Virtualbox VM got stuck in ctfmerge so
this is completely untested.
Testers that know how to use it are welcome :).
I applied it on 10-CURRENT amd64 from /usr/src with patch
-p0 without any conflicts, but it doesn't appear to be
working.
The example from the blog post above triggers an assertion
that is still reproducible when reducing the test case:
fk@r500 /tmp $sudo dtrace -n 'tick-1ms{@ = llquantize(i++,
10, 0, 6, 20);}'
Assertion failed: (!(arg (UINT16_MAX
args[i].shift))), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
line 1429.
Thanks for testing!
It seems like the syntax has changed from the time the
example from the blog was made. The code says:
/*
* For log/linear quantizations, we have between one and five
* arguments in addition to the expression:
*
*arg1 = Factor
*arg2 = Low magnitude
*arg3 = High magnitude
*arg4 = Number of steps per magnitude
*arg5 = Quantization increment value (defaults to 1)
*/
My suggestion would be to instead try using the test
scripts in
cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/
err.D_LLQUANT_FACTORSMALL.d (for example) has
@ = llquantize(0, 1, 0, 10, 10);
The problem appears to be unrelated to the syntax change:
fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize
$sudo dtrace -s err.D_LLQUANT_FACTORSMALL.d
Assertion failed: (!(arg (UINT16_MAX args[i].shift))), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
line 1429.
fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize
$sudo dtrace -s tst.bases.d
Assertion failed: (!(arg (UINT16_MAX args[i].shift))), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
line 1429.
fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize
$sudo dtrace -s tst.negvalue.d
Assertion failed: (!(arg (UINT16_MAX args[i].shift))), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
line 1429.
fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize
$sudo dtrace -s tst.steps.d
Assertion failed: (!(arg (UINT16_MAX args[i].shift))), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
line 1429.
root@r500:/root # dtrace -s
/usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/tst.steps.d
Assertion failed: (!(arg (UINT16_MAX args[i].shift))), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
line 1429.
Abort (core dumped)
Fabian
signature.asc
Description: PGP signature
Re: [RFT] llquantize for FreeBSD's dtrace
--- Sab 23/6/12, Fabian Keil freebsd-lis...@fabiankeil.de ha scritto: ... My suggestion would be to instead try using the test scripts in cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/ err.D_LLQUANT_FACTORSMALL.d (for example) has @ = llquantize(0, 1, 0, 10, 10); The problem appears to be unrelated to the syntax change: fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize $sudo dtrace -s err.D_LLQUANT_FACTORSMALL.d Assertion failed: (!(arg (UINT16_MAX args[i].shift))), file It's a different assertion. Probably some difference between Solaris and BSD. this is very useful, thanks! Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: minor GEOM disk API change coming
On Fri, Jun 22, 2012 at 19:50:01 +0300, Alexander Motin wrote: Hi. I understand problem you are going to fix and I think your patch should do it. What I don't very like is addition of new GEOM method. Now GEOM doesn't need it because all internal open/close operations and provider destructions there protected by the topology SX lock. Unluckily that lock doesn't cover g_wither_provider(), called by disk_gone() while holding CAM SIM lock. If not that SIM lock, it would be enough to just grab and drop GEOM topology lock to ensure that no new open() calls will follow. Indirect way to do it could be to post GEOM event that would drop the reference as soon as it will be handled and can obtain the topology lock. Unluckily it uses malloc() for event storage and also can be unreliable if called from under the SIM mutex lock. So it seems many things would be much easier if it was possible to drop SIM lock inside periph invalidate method, but now it is unsafe That is not an objection, just some thoughts about. Yeah, there are things in CAM (and GEOM) that need to be cleaned up. I wouldn't have added a GEOM method if there were a reasonable way around it, but as you pointed out, there isn't right now. I committed the patch, and plan to merge it to stable/9. Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2012-06-24 04:51:29 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 04:51:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 04:51:29 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-06-24 04:51:29 - cleaning the object tree TB --- 2012-06-24 04:51:29 - cvsupping the source tree TB --- 2012-06-24 04:51:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-06-24 04:52:06 - building world TB --- 2012-06-24 04:52:06 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 04:52:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 04:52:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 04:52:06 - SRCCONF=/dev/null TB --- 2012-06-24 04:52:06 - TARGET=sparc64 TB --- 2012-06-24 04:52:06 - TARGET_ARCH=sparc64 TB --- 2012-06-24 04:52:06 - TZ=UTC TB --- 2012-06-24 04:52:06 - __MAKE_CONF=/dev/null TB --- 2012-06-24 04:52:06 - cd /src TB --- 2012-06-24 04:52:06 - /usr/bin/make -B buildworld World build started on Sun Jun 24 04:52:06 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 04:52:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 04:52:31 - ERROR: failed to build world TB --- 2012-06-24 04:52:31 - 11.95 user 4.70 system 61.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ 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
