Can't umount a formerly mounted drive
I have two drives in a x86-64 machine. Drive ada2 has current on it, and drive ada1 has 9-stable on it. At some point, while running current, I mounted the /home partition from stable to copy some files and re-ipled the system into stable. every thing worked properly. Some time later I ipled current again. I then noticed that the stable /home was mounted on /mnt. I tried to umount it but the operation failed as /dev/ada1p7 was not considered mounted. Yet with out mounting I could access all the files on stable's /home, I could create and delete files. The current system was cvsup'ed on Wednesday this week, while the stable system was cvsup'ed last Sunday. Neither system has exhibited any hiccups. Can somebody explain what has happened her on the current system and how it should be corrected? -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't umount a formerly mounted drive
* Ryan Stone [120203 13:41]: > On Fri, Feb 3, 2012 at 9:34 AM, Derek Tattersall wrote: > > I have two drives in a x86-64 machine. Drive ada2 has current on it, and > > drive ada1 has 9-stable on it. At some point, while running current, I > > mounted the /home partition from stable to copy some files and re-ipled > > the system into stable. every thing worked properly. Some time later I > > ipled current again. I then noticed that the stable /home was mounted > > on /mnt. I tried to umount it but the operation failed as /dev/ada1p7 > > was not considered mounted. Yet with out mounting I could access all > > the files on stable's /home, I could create and delete files. > > > > The current system was cvsup'ed on Wednesday this week, while the stable > > system was cvsup'ed last Sunday. Neither system has exhibited any > > hiccups. Can somebody explain what has happened her on the current > > system and how it should be corrected? > > Does "mount" list anything as being mounted on /mnt? If not, are you > sure that /mnt isn't a symlink to somewhere else? Or maybe the > contents of the home directory were copied to /mnt by accident? mount command on the current system does not list anything under /mnt. ls /mnt on the current system list the top level directories on ada1p7, the stable /home. It lists them as soon as a user logs in on a newly booted current system. It's really frustrating. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't umount a formerly mounted drive
* Gary Jennejohn [120204 06:24]: > On Fri, 3 Feb 2012 13:50:53 -0500 > Derek Tattersall wrote: > > > * Ryan Stone [120203 13:41]: > > > On Fri, Feb 3, 2012 at 9:34 AM, Derek Tattersall wrote: > > > > I have two drives in a x86-64 machine. ?Drive ada2 has current on it, > > > > and > > > > drive ada1 has 9-stable on it. ?At some point, while running current, I > > > > mounted the /home partition from stable to copy some files and re-ipled > > > > the system into stable. ?every thing worked properly. ?Some time later I > > > > ipled current again. ?I then noticed that the stable /home was mounted > > > > on /mnt. ?I tried to umount it but the operation failed as /dev/ada1p7 > > > > was not considered mounted. ?Yet with out mounting I could access all > > > > the files on stable's /home, I could create and delete files. > > > > > > > > The current system was cvsup'ed on Wednesday this week, while the stable > > > > system was cvsup'ed last Sunday. ?Neither system has exhibited any > > > > hiccups. ?Can somebody explain what has happened her on the current > > > > system and how it should be corrected? > > > > > > Does "mount" list anything as being mounted on /mnt? If not, are you > > > sure that /mnt isn't a symlink to somewhere else? Or maybe the > > > contents of the home directory were copied to /mnt by accident? > > mount command on the current system does not list anything under /mnt. > > ls /mnt on the current system list the top level directories on ada1p7, > > the stable /home. It lists them as soon as a user logs in on a newly > > booted current system. It's really frustrating. > > > > Well, it certainly looks like Ryan's suggestion that files from /home were > copied to /mnt (with nothing mounted on it) is correct. > > Try mounting /home to a different location, like /mnt1, and compare the > dates on the suspicious files. Wouldn't surprise me to find that they > differ. > > -- > Gary Jennejohn You and Ryan are absolutely right - the problem was my looking for a complicated answer. I can't quite figure how I copied the whole file system but that's what I did. Thanks for pointing out my incorrect direction. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot2 overflow when building with clang
>From sources csup'ed this morning, I have the same problem. Is there a fix for folks that don't use SVN? -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ksh93 build failure
On a 10.0 Current system, cvsupped today, ksh93 fails to build. As best I can determine, the failure is due to a problem of conflicting includes. In file included from /home/ports/usr/ports/shells/ksh93/work/arch/freebsd.amd64/include/ast/ast_wchar.h:113, from /home/ports/usr/ports/shells/ksh93/work/arch/freebsd.amd64/include/ast/wchar.h:22, from /home/ports/usr/ports/shells/ksh93/work/src/cmd/ksh93/include/lexstates.h:85, from /home/ports/usr/ports/shells/ksh93/work/src/cmd/ksh93/include/shlex.h:32, from /home/ports/usr/ports/shells/ksh93/work/src/cmd/ksh93/data/keywords.c:22: /usr/include/../include/wchar.h:102: error: conflicting types for '_sfio_FILE' Has anyone else run into this problem, and if so, what did you do about it. ksh93 builds without error on 9.0 Stable. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ksh93 build failure
* Jason Hellenthal [120503 06:43]: > > > On Wed, May 02, 2012 at 06:52:21PM -0400, Derek Tattersall wrote: > > On a 10.0 Current system, cvsupped today, ksh93 fails to build. As best > > I can determine, the failure is due to a problem of conflicting > > includes. > > > > In file included from > > /home/ports/usr/ports/shells/ksh93/work/arch/freebsd.amd64/include/ast/ast_wchar.h:113, > > from > > /home/ports/usr/ports/shells/ksh93/work/arch/freebsd.amd64/include/ast/wchar.h:22, > > from > > /home/ports/usr/ports/shells/ksh93/work/src/cmd/ksh93/include/lexstates.h:85, > > from > > /home/ports/usr/ports/shells/ksh93/work/src/cmd/ksh93/include/shlex.h:32, > > from > > /home/ports/usr/ports/shells/ksh93/work/src/cmd/ksh93/data/keywords.c:22: > > /usr/include/../include/wchar.h:102: error: conflicting types for > > '_sfio_FILE' > > Has anyone else run into this problem, and if so, what did you do about > > it. ksh93 builds without error on 9.0 Stable. > > Do you perhaps have devel/sfio installed on that machine ? If so can you > deinstall and retry the build. > > -- > > - (2^(N-1)) Thanks for the pointer to sfio, but it's not installed on either the 10.0 Current system, nor the 9.0 Stable system. I'm still confused. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Problem with pkg_add
After installing 9.0-RC2 or RC3, pkg_add -r fails in trying to access ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/package-9-current as the terminal directory is acually packages-9-stable. It is a one line change in the source for pkg_add. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
iI am @248554 on an AMD64 box with 8 gig of memory, and a 64 bit kernel. The video is on the motherboard and is a Radeon chipset. I also experienced the panic while starting XDM. I found Shawn's suggested remedy of etting both vfs.unmapped_buf_allowed=0 and kern.bio_transient_maxcnt=512 in /boot/loader.conf allows the box to boot, XDM to start and everything seems to be working. It's probably just my imagination, but it does seem slightly slower in starting applications. It seems that the common thing between my situation and Shawn's is the recent changes to drm.ko. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Rebuild of xfce4-session
I am trying to rebuild xfce4-session on 10.0 as of r255478. It fails with /usr/local/lib/libiconv.a missing from libtool. Does anybody have a clue as to what to do at this point? -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Buildworld failure
I blew away /usr/src and /usr/obj and re-cvsuped this morning. I attempted to buildworld, only to have the process die in the mkdep step. CC='clang' mkdep -f .depend -a -I/usr/src/cddl/usr.bin/ctfmerge/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris -I/usr/src/cddl/usr.bin/ctfmerge/../../../sys/cddl/contrib/opensolaris -I/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/common -I/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/usr/src/cddl/usr.bin/ctfmerge/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/alist.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/barrier.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctf.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/hash.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/iidesc.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/input.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/common/list.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/common/memory.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/output.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/strtab.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/common/symbol.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/tdata.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/util.c In file included from /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/barrier.c:46: /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/barrier.h:39:10: fatal error: 'semaphore.h' file not found #include ^ 1 error generated. mkdep: compile failed *** Error code 1 Stop in /usr/src/cddl/usr.bin/ctfmerge. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -> End buildworld Wed Dec 22 19:13:13 EST 2010 RC = 0 I don't understand what's happening here, as the same procedure worked fine last week. Can anybody tell me what I'm doing wrong here? -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Buildworld failure
* Giorgos Keramidas [101223 06:30]: > On Wed, 22 Dec 2010 19:29:39 -0500, Derek Tattersall wrote: > > I blew away /usr/src and /usr/obj and re-cvsuped this morning. I > > attempted to buildworld, only to have the process die in the mkdep step. > > > > CC='clang' mkdep -f .depend -a > > -I/usr/src/cddl/usr.bin/ctfmerge/../../../sys/cddl/compat/opensolaris > > -I/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/compat/opensolaris/include > [...] > > -DNEED_SOLARIS_BOOLEAN -I/usr/obj/usr/src/tmp/legacy/usr/include > [...] > > /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/util.c > > In file included from > > /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/barrier.c:46: > > /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/barrier.h:39:10: > > fatal error: 'semaphore.h' file not found > > #include > > ^ > > 1 error generated. > > mkdep: compile failed > > Which branch is this? When was it last updated? I see that you are > using CC='clang', so my guess is you are building CURRENT, right? > > If that's the case, can you try: > > - building without CC='clang', to see if the breakage is clang's fault > - if that fails, resync your CURRENT source and retry > > NOTE: I did build a snapshot from /head at -r 216642 last afternoon and > it worked fine with the default CC. So if something broke *after* that > revision try bisecting from -r 216642 to the version you built, to see > if there's something that broke the build in-between. This is using CURRENT, cvsup'ed Wednesday. The same failure occurs with clang and with gcc. I note that there have been several changes in the recent past in the obsolete files list regarding semaphore.h. I will try again, blowing away both /usr/src and /usr/obj and see if that has any effect. Bisection will have to wait until next week. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
atacontrol
I have a new motherboard, ASUS A7V600, which replaced an ASU CUSL. Everythin else is as it was on the original. With a CURRENT from last Sunday, FreeBSD lorne.arm.org 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Sun Oct 12 10:00:41 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LORNE i386 when I atacontrol info 0 I get Master: ad0 ATA/ATAPI rev 5 Slave: no device present and when I atacontrol mode 0 I get Master = ??? Slave = BIOSPIO If I atacontrol mode 0 UDMA2 BIOSPIO I get Master = ??? Slave = BIOSPIO I also get lots of ad0: WARNING - WRITE_MUL write data underrun 8192>6144 In the log. How do I shoot this problem? -- Derek Tattersall[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atacontrol
* Matt Dawson ([EMAIL PROTECTED]) [031018 06:43]: > From: Matt Dawson <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: RE:atacontrol > Date: Sat, 18 Oct 2003 11:41:16 +0100 > User-Agent: KMail/1.5.4 > Message-Id: <[EMAIL PROTECTED]> > > You wrote: > "I have a new motherboard, ASUS A7V600, which replaced an ASU CUSL. > Everythin else is as it was on the original. With a CURRENT from last > Sunday, FreeBSD lorne.arm.org 5.1-CURRENT FreeBSD 5.1-CURRENT #8: " > > Just a thought and forgive me if I am teaching my gran to do strange things > with eggs: You do have 80 conductor cables on your new ATA-100/133 capable > controller, don't you? I wouldn't usually question this, but you do mention > that everything else is the same as the old board which I take to include the > IDE cables. > > Please accept my apologies in advance if I am mistaken here... > > -- > Matt Dawson. > > [EMAIL PROTECTED] > [EMAIL PROTECTED] > Tel 01745 560184 > Mobile 07980 156761 > > Well, the hard drive cable was the one that came in the motherboard box, and certainly appears to be an 80 conductor cable. The drive is a WD drive and when I bought it a couple years ago, it was sold as DMA66 capable. Dmesg doesn't even report the mode of ad0 at boot time, just the ???. -- Derek Tattersall[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Clang now builds world and kernel, on i386 and amd64
* Renato Botelho [100928 20:20]:
> On Tue, Sep 28, 2010 at 6:07 PM, Renato Botelho wrote:
> > On Wed, Sep 22, 2010 at 3:42 AM, Dimitry Andric wrote:
> >> Hi,
> >>
> >> As of r212979, you should now be able to build world and kernel on i386
> >> and amd64 with clang, without any additional patches!
> >>
> >> To do so, make sure you have updated your installed world to at least
> >> r212904 (which has the most recently imported clang/llvm snapshot), and
> >> put the following in /etc/src.conf:
> >>
> >> .if !defined(CC) || ${CC} == "cc"
> >> CC=clang
> >> .endif
> >> .if !defined(CXX) || ${CXX} == "c++"
> >> CXX=clang++
> >> .endif
> >> # Don't die on warnings
> >> NO_WERROR=
> >> WERROR=
> >>
> >> Both world and kernel can also be installed, and should run properly,
> >> but please make sure you have a way to revert if anything unexpected
> >> happens. :) ?Alternatively, just install into a chroot to try it out
> >> from there.
> >>
> >> Some additional information can be found on this wiki page:
> >>
> >> http://wiki.freebsd.org/BuildingFreeBSDWithClang
> >>
> >> Thanks to all the people that made this possible, especially Roman
> >> Divacky, Ed Schouten, Rui Paulo, and of course the clang/llvm
> >> developers.
> >
> > I built my desktop world + kernel with clang, rev. 213247 amd64, it
> > booted perfectly, the only problem i got was something went wrong
> > with a perl module File::Temp.
> >
> > To be sure it's related i'm rebuilding the src (same rev.) with gcc and
> > will take a look if it will back to work. I'll send an email after testing.
> >
> > Just to show, the problem i got with perl was using this code:
> >
> > #!/usr/bin/perl
> >
> > use File::Temp;
> >
> > my ( $fh, $filename ) = File::Temp::tempfile();
> > print "$filename\n";
> > unlink $filename;
> >
> > with this results:
> >
> > Error in tempfile() using /tmp/XX: Tried to get a new temp
> > name different to the previous value 50 times.
> > Something wrong with template?? (/tmp/XX) at testes/tmp.pl line 5
>
> After rebuild world+kernel with gcc and reboot everything
> back to normal:
>
> ga...@botelhor:~> perl testes/tmp.pl
> /tmp/MfmvMiztew
> ga...@botelhor:~> perl testes/tmp.pl
> /tmp/M4xIxsTxlc
>
> I'm using perl-5.12.2_2
>
> --
> Renato Botelho
> ___
> 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"
A test shell script using mktemp (1) works fine on current built with
clang today. The clang case produces a filename with all "A"'s rather
than the random letters expected.
--
Best regards,
Derek Tattersall
d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang now builds world and kernel, on i386 and amd64
* Dimitry Andric [100929 06:16]: > On 2010-09-29 02:28, Derek Tattersall wrote: > > A test shell script using mktemp (1) works fine on current built with > > clang today. The clang case produces a filename with all "A"'s rather > > than the random letters expected. > > I cannot reproduce this on a system compiled entirely with clang: > > $ mktemp foo.XX > foo.MyUM5k > $ mktemp foo.XX > foo.YidMeT > $ mktemp foo.XX > foo.L27Cfz > $ mktemp foo.XX > foo.k3haLx > > ... and so on. Can you post that test script, please? I think was ambiguous in description of the test I ran. The mktemp shell script test only had a call to /usr/bin/mktemp. The other case I ran, was Renato's perl script, and it produced the same results as he produced. I haven't had time yet to study the File::Temp code installed by perl 5.12.2. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang now builds world and kernel, on i386 and amd64
* Garrett Cooper [100929 06:16]: > On Tue, Sep 28, 2010 at 11:43 PM, Dimitry Andric wrote: > > On 2010-09-29 02:28, Derek Tattersall wrote: > >> > >> A test shell script using mktemp (1) works fine on current built with > >> clang today. ?The clang case produces a filename with all "A"'s rather > >> than the random letters expected. > > > > I cannot reproduce this on a system compiled entirely with clang: > > > > $ mktemp foo.XX > > foo.MyUM5k > > $ mktemp foo.XX > > foo.YidMeT > > $ mktemp foo.XX > > foo.L27Cfz > > $ mktemp foo.XX > > foo.k3haLx > > > > ... and so on. ?Can you post that test script, please? > > Please note your CPUTYPE and CFLAGS (for both those that had a problem > and those that didn't) there might be some evidence in there that > would help to resolve this issue with clang. > Thanks, > -Garrett > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" The CPUTYPE and CFLAGS are set as by a GENERIC build. The kernel configuration file is vanilla GENERIC with scsi and PCI ethernet drivers built as modules only. The uname is: FreeBSD oriental.arm.org 9.0-CURRENT FreeBSD 9.0-CURRENT #23: Tue Sep 28 11:06:43 EDT 2010 \ r...@oriental.arm.org:/usr/obj/usr/src/sys/ORIENTAL amd64 -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang now builds world and kernel, on i386 and amd64
* Dimitry Andric [100929 08:55]: > On 2010-09-29 13:23, Renato Botelho wrote: > > #!/usr/bin/perl > > > > use File::Temp; > > > > my ( $fh, $filename ) = File::Temp::tempfile(); > > print "$filename\n"; > > For me it works perfectly, though I am using perl 5.10: > > $ cat foo.pl > #!/usr/bin/perl > > use File::Temp; > > my ( $fh, $filename ) = File::Temp::tempfile(); > print "$filename\n"; > $ perl -v > > This is perl, v5.10.1 (*) built for i386-freebsd-64int > > Copyright 1987-2009, Larry Wall > > Perl may be copied only under the terms of either the Artistic License or the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". If you have access to the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > $ perl foo.pl > /tmp/tv25CPnWhF > $ perl foo.pl > /tmp/L2UJQ5_JJs > $ perl foo.pl > /tmp/6ynQYvWIc1 > $ perl foo.pl > /tmp/Tdpf7PKBMg > $ perl foo.pl > /tmp/76ir2i1ici > $ perl foo.pl > /tmp/LhfD0eZgd8 > > I'll try building perl 5.12 and try it again. > > Btw, I assume you did *not* rebuild perl with clang, so your perl is > still compiled with gcc? > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" I built a test case using perl 5.12 and demonstrated that calling int(rand()) in perl returns NAN, as does calling rand() by itself. A "C" program that calls libc's rand() does return differing integers. The perl documentation claims that perl's rand() calls "C"s rand() and srand() if necessary. I think this effectively demonstrates that the problem lies with the perl function rand() and it's interface to libc's rand() as provided by clang. On a recent stable system, perl's mktemp works fine. The only real difference is that libc on stable is built with gcc and libc on current is built with clang. The perl source for mktemp() is in /usr/local/lib/perl5/5.12.2/File/Temp.pm. The line that builds the filename from the template is line 632. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang now builds world and kernel, on i386 and amd64
* Dimitry Andric [100929 17:05]: > On 2010-09-29 21:47, Renato Botelho wrote: > >> Renato, Derek, could you please apply the attached patch for ldexp, > >> rebuild your libc (with clang), and run your random test program again? > > > > Worked perfectly here \o/ > > And what about perl? :) Super! Thanks very much for this rapid fix. And perldoc -f works again. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Another clang problem
In updating gnash to 8.8 the build failed while linking with libvgl.so. My current system was built last week, with both kernel and world built with clang. The linkage failure was due to an inlined function, "set4pixels" which is only referred to, as far as I can tell, within the source file simple.c which contains the function definition. I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at least in this case, that clang has some problems dealing with inlined functions. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Another clang problem
* Rui Paulo [101003 09:57]: > On 3 Oct 2010, at 14:41, Derek Tattersall wrote: > > > In updating gnash to 8.8 the build failed while linking with libvgl.so. My > > current system was built last week, with both kernel and world built > > with clang. The linkage failure was due to an inlined function, > > "set4pixels" which is only referred to, as far as I can tell, within the > > source file simple.c which contains the function definition. > > > > I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at > > least in this case, that clang has some problems dealing with inlined > > functions. > > We are still in the process of identifying which ports have problems, but we > are aware that building ports with clang is not an easy job: several ports > assume a gcc behavior and there some LLVM/Clang problems that need to be > ironed out. > > Given this, we need some sort of way to identify ports that can be built with > clang, but that requires man-hours. > > Regards, > -- > Rui Paulo I was not completely clear, I'm afraid. Gnash was built with gcc under all circumstances. libvgl.so is part of the world build and is installed in /usr/lib. It was originally built with clang when I built both the kernel and the world with clang last week. I found that building /usr/src/lib/libvgl with gcc was necessary to get gnash to build properly. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Another clang problem
* Dimitry Andric [101004 17:12]: > On 2010-10-04 20:41, Renato Botelho wrote: > >>There is also a chance this might fix your issue, can you please try it > >>out? > >Same problem here with this patch > > It turns out it was an issue in libvgl, which should be fixed by > r213412. Can you please try to update to that revision, rebuild and > reinstall (at least) lib/libvgl with clang, and then build the port > again? > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" I updated kernel and world via csup at approximately 1730 EST. simple.c was at version 1.9. No problems were encountered. I rebuilt libvgl with clang and installed it. I then rebuilt gnash with gcc and it builds and installs properly. Thanks for your successful resolution to this problem! -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
exclusive sleep mutex netisr...
I see several instances of this in /var/log/messages after cvsup'ing Monday evening and rebuilding world and kernel. I haven't seen any messages about this, so I figured I'd ask here. Message: Mar 11 17:33:30 lorne kernel: malloc() of "64" with the following non-sleepablelocks held: Mar 11 17:33:30 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 Can anybody supply me a clue as to what's going on here? -- Derek Tattersall[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: exclusive sleep mutex netisr...
* Jonathan Lemon ([EMAIL PROTECTED]) [030312 01:12]: > Date: Tue, 11 Mar 2003 18:59:15 -0600 (CST) > From: Jonathan Lemon <[EMAIL PROTECTED]> > Message-Id: <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: exclusive sleep mutex netisr... > Organization: > Cc: > > In article you write: > >I see several instances of this in /var/log/messages after cvsup'ing > >Monday evening and rebuilding world and kernel. I haven't seen any > >messages about this, so I figured I'd ask here. > > > >Message: > >Mar 11 17:33:30 lorne kernel: malloc() of "64" with the following > >non-sleepablelocks held: > >Mar 11 17:33:30 lorne kernel: exclusive sleep mutex netisr lock r = 0 > >(0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 > > > >Can anybody supply me a clue as to what's going on here? > > It can be ignored for now, the code path is still under the Giant lock, > so this is harmless, I'll fix this soon to use a different approach; > the lock was intended to protect against reentrancy. > > However, I'd be interested to know what is calling malloc(), if that > information is in the syslog. > -- > Jonathan > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > The only other bit of information I have is: Mar 10 20:55:09 lorne kernel: Bad malloc flags: 4 Mar 10 20:55:09 lorne kernel: Stack backtrace: Mar 10 20:55:09 lorne kernel: malloc() of "64" with the following non-sleepablelocks held: Mar 10 20:55:09 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 Mar 10 20:55:09 lorne kernel: malloc() of "64" with the following non-sleepablelocks held: Mar 10 20:55:09 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 I haven't found anything that was crisper. I hope this is useful. I'll keep following the list for more info. -- Derek Tattersall[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[no subject]
I found on tty0 the following backtrace. I infer, because it died in malloc, that it has something to do with netisr problem. I had to copy it by hand. backtrace(c04b7645,4,1,0,c40be100) at backtrace+0x17 malloc(3c,c050fca0,4,c1531300,d67e6c78) at malloc+0x5b mtag_alloc(0,e,30,4,c151ac00) at mtag_alloc+0x2f ip6_addaux(c1531300,d6706cbc,c037b09c,c1531300,c151ac00) at ip6_addaux+0x59 ip6_setdstifaddr(c1531300,c151ac00,d6te6cbc,c02d2480,c057a254) at ip6_setdstifaddr+0x11 ip6_input(c1531300,0,c04c0a40,e9,c1513ac00) at ip6_input+0x78c swi_net(0,0,c04b672f,217,c15209ec) at swi_net+0x112 ithread_loop(c151f200,d67e6048,c04b65ac,35f,0) at ithread_loop+0x182 fork_exit(c02c95e0,c151f200,d67e6048) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip=0, esp=0xd67e6d7c, ebp=0 --- -- Derek Tattersall[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
trap in netisr...
I found on tty0 the following backtrace. I infer, because it died in malloc, that it has something to do with netisr problem. I had to copy it by hand. backtrace(c04b7645,4,1,0,c40be100) at backtrace+0x17 malloc(3c,c050fca0,4,c1531300,d67e6c78) at malloc+0x5b mtag_alloc(0,e,30,4,c151ac00) at mtag_alloc+0x2f ip6_addaux(c1531300,d6706cbc,c037b09c,c1531300,c151ac00) at ip6_addaux+0x59 ip6_setdstifaddr(c1531300,c151ac00,d6te6cbc,c02d2480,c057a254) at ip6_setdstifaddr+0x11 ip6_input(c1531300,0,c04c0a40,e9,c1513ac00) at ip6_input+0x78c swi_net(0,0,c04b672f,217,c15209ec) at swi_net+0x112 ithread_loop(c151f200,d67e6048,c04b65ac,35f,0) at ithread_loop+0x182 fork_exit(c02c95e0,c151f200,d67e6048) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip=0, esp=0xd67e6d7c, ebp=0 --- -- Derek Tattersall[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
