Re: bsdinstall wifi setup is broken on CURRENT
On 18/05/24 11:33, Alfonso S. Siciliano wrote: On 5/16/24 20:40, Renato Botelho wrote: I saw some users on a .br group complaining bsdinstall was failing to setup wifi network on 15.0 snapshots and tried it myself. I was able to reproduce the problem and also noticed another one. Thank you for your report, the video is highly appreciated to understand the problem quickly and exactly. I noticed Network Selection screen only shows one line, it's not beautiful to navigate through items this way. On 14.1-BETA2 it shows multiple lines so it seems to be a regression. Problem 1. Looking at wlanconfig it seems related to $height $width $rows for the selecting menu. Please could you open a PR adding me, so we can test and solve. I've fixed it locally and submitted a fix for review https://reviews.freebsd.org/D45271 The problem users reported was: after selecting desired network it just starts over instead of asking for password. I made a video [1] showing the problem. Problem 2. I know this issue about --mixedform, my last import 2 day ago should solve a6d8be451f62d425b71a4874f7d4e133b9fb393c. You could try the last main snapshot (yesterday 17 May), please let me know any problem. Last snapshot still contains bsddialog 1.0 so I'll wait for the next one and give it a try. Jessica, I've cc'd you because git shows you were the last person making changes in this area. If it's not related and I made a mistake, just ignore me. [1] https://youtube.com/shorts/Gmeckokw2a0 Again thanks for the video. Best Regards, Alfonso -- Renato Botelho
Re: bsdinstall wifi setup is broken on CURRENT
On 16/05/24 15:47, Jessica Clarke wrote: On 16 May 2024, at 19:40, Renato Botelho wrote: I saw some users on a .br group complaining bsdinstall was failing to setup wifi network on 15.0 snapshots and tried it myself. I was able to reproduce the problem and also noticed another one. I noticed Network Selection screen only shows one line, it's not beautiful to navigate through items this way. On 14.1-BETA2 it shows multiple lines so it seems to be a regression. The problem users reported was: after selecting desired network it just starts over instead of asking for password. I made a video [1] showing the problem. Jessica, I've cc'd you because git shows you were the last person making changes in this area. If it's not related and I made a mistake, just ignore me. Hi Renato, I touched the code that lets you select the wireless interface in the first place, but not the script that then gets called to set it up and is responsible for the dialogs you see. Given the behaviour, I wonder if this is what today’s import of bsddialog[1] fixes? From reading the script the next dialog uses --mixedform, and restarts the script on error, which it looks like is what you observe. Thanks for pointing that out, Jessica. I'll wait for the next 15 snapshot and will check. I'm not sure about a good way to test it on a running system instead. -- Renato Botelho
bsdinstall wifi setup is broken on CURRENT
I saw some users on a .br group complaining bsdinstall was failing to setup wifi network on 15.0 snapshots and tried it myself. I was able to reproduce the problem and also noticed another one. I noticed Network Selection screen only shows one line, it's not beautiful to navigate through items this way. On 14.1-BETA2 it shows multiple lines so it seems to be a regression. The problem users reported was: after selecting desired network it just starts over instead of asking for password. I made a video [1] showing the problem. Jessica, I've cc'd you because git shows you were the last person making changes in this area. If it's not related and I made a mistake, just ignore me. [1] https://youtube.com/shorts/Gmeckokw2a0 -- Renato Botelho
Re: [RFC] Three patches for time infrastructure in FreeBSD!
On 03/10/22 10:20, Hans Petter Selasky wrote: Hi, I've made three patches to improve conversion between timing units, like sbintime, and usecs and so on. I've been testing these for some days and can see a notiable difference when using realtime audio applications, in the form of less jitter, audio/hpsjam and video-chat using www/firefox . https://reviews.freebsd.org/D36857 https://reviews.freebsd.org/D36858 https://reviews.freebsd.org/D36858 You added D36858 twice. -- Renato Botelho
Re: Good practices with bectl
On 20/09/22 19:19, Alan Somers wrote:
On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira wrote:
Hello to all,
I will use becl for the first time for current upgrades.
Just to check that I'm thinking correctly:
Create a test environment for upgrade:
bectl create -r test (should I use '-r'?)
Activate test:
bectl activate test
reboot
...
upgrade OS on test
reboot
...
if a problem happens, reboot default from BE loader
---
if everything fine destroy default and rename test to default
bectl destroy -o default
bectl rename test default
repeat on next upgrade
Don't know if a faster way exists with chroot or bectl jail...
Any hints appreciated.
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
I don't think you need to use "-r". Also, you're forgetting one of
the best things about boot environments: you can upgrade them even
when not booted into them. That's faster than upgrading the running
BE. Here is the procedure I use:
RELEASE=Whatever
sudo bectl create ${RELEASE}
sudo bectl mount ${RELEASE}
BASEDIR=/tmp/be_mount.# Use mount point returned by bectl mount
sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
upgrade -r ${RELEASE}
sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
# Ignore admonitions to reboot, since we're using a boot environment
sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
sudo bectl activate ${RELEASE}
I like to use `sudo bectl activate -t ${RELEASE}`, it activates new
partition to be ROOT only for the next boot. If something goes wrong,
you just need to power cycle the machine and it will boot on previous
partition.
After a success boot you must run `sudo bectl activate RELEASE` again to
make it permanent.
sudo reboot
This general procedure works just as well if you're upgrading from source, too.
sudo make DESTDIR=${BASEDIR} installworld
sudo mergemaster -m $PWD -D $BASEDIR -U
-Alan
Re: archivers/arj fails to build on jail
On 30/08/22 12:39, Renato Botelho wrote: On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote: On 30.08.2022 13.17, Renato Botelho wrote: On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote: On 29.08.2022 17.29, Renato Botelho wrote: There is a PR [1] opened for years reporting arj fails to build on a jail. Recently I reproduced it on a system running CURRENT. I just launched a jail and tried to build it, and got the error as described: Did you use ezjail? I tried to replicate and I think the error is triggered by the nullfs usage of ezjail. I copied the settings of ezjail without nullfs usage (using the basejail as path adding etc from the failing jail to it and removing the fstab from jail.conf) and arj did get a working msgbind. Yes, I also use ezjail. I'm cc'ing ezjail's maintainer to see if we can get some advice. Thanks! Hi again. I narrowed this down to symlinks ,wiithin the jail, to the nullfs mountpoint. Replacing symlinks to the basejail mount point with dirs and setting this in the fstab of the jail and msgbind is a valid executable /usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0 /usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0 /usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0 /usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0 /usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0 /usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0 /usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0 /usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0 /usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs ro 0 0 /usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0 /usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0 /usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs ro 0 0 /usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0 /usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0 /usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs ro 0 0 /usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0 It should be further narrowed down but nullfs alone is not the issue. Interesting. And just to add a note here, I copied msgbind from jail to host and tried to execute it to confirm binary was really bad and I got the same Abort trap message. And one more interesting information is it builds fine with gcc. I just added USE_GCC=yes to the port and it worked. -- Renato Botelho
Re: archivers/arj fails to build on jail
On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote: On 30.08.2022 13.17, Renato Botelho wrote: On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote: On 29.08.2022 17.29, Renato Botelho wrote: There is a PR [1] opened for years reporting arj fails to build on a jail. Recently I reproduced it on a system running CURRENT. I just launched a jail and tried to build it, and got the error as described: Did you use ezjail? I tried to replicate and I think the error is triggered by the nullfs usage of ezjail. I copied the settings of ezjail without nullfs usage (using the basejail as path adding etc from the failing jail to it and removing the fstab from jail.conf) and arj did get a working msgbind. Yes, I also use ezjail. I'm cc'ing ezjail's maintainer to see if we can get some advice. Thanks! Hi again. I narrowed this down to symlinks ,wiithin the jail, to the nullfs mountpoint. Replacing symlinks to the basejail mount point with dirs and setting this in the fstab of the jail and msgbind is a valid executable /usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0 /usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0 /usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0 /usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0 /usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0 /usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0 /usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0 /usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0 /usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs ro 0 0 /usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0 /usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0 /usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs ro 0 0 /usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0 /usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0 /usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs ro 0 0 /usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0 It should be further narrowed down but nullfs alone is not the issue. Interesting. And just to add a note here, I copied msgbind from jail to host and tried to execute it to confirm binary was really bad and I got the same Abort trap message. -- Renato Botelho
Re: archivers/arj fails to build on jail
On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote: On 29.08.2022 17.29, Renato Botelho wrote: There is a PR [1] opened for years reporting arj fails to build on a jail. Recently I reproduced it on a system running CURRENT. I just launched a jail and tried to build it, and got the error as described: Did you use ezjail? I tried to replicate and I think the error is triggered by the nullfs usage of ezjail. I copied the settings of ezjail without nullfs usage (using the basejail as path adding etc from the failing jail to it and removing the fstab from jail.conf) and arj did get a working msgbind. Yes, I also use ezjail. I'm cc'ing ezjail's maintainer to see if we can get some advice. Thanks! gmake[3]: *** [GNUmakefile:258: freebsd12.1/en/rs/msg_crp.h] Abort trap msgbind binary built inside arj, when called, ends like this. I has no clue about what could be the root cause here. I also don't understand why arj builds fine on poudriere, which uses jail as well. If anyone has any idea about what could be causing this, please let me know. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235636 -- Renato Botelho
archivers/arj fails to build on jail
There is a PR [1] opened for years reporting arj fails to build on a jail. Recently I reproduced it on a system running CURRENT. I just launched a jail and tried to build it, and got the error as described: gmake[3]: *** [GNUmakefile:258: freebsd12.1/en/rs/msg_crp.h] Abort trap msgbind binary built inside arj, when called, ends like this. I has no clue about what could be the root cause here. I also don't understand why arj builds fine on poudriere, which uses jail as well. If anyone has any idea about what could be causing this, please let me know. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235636 -- Renato Botelho
Re: [HEADSUP] the default root shell is now /bin/sh
On 20/10/21 04:40, Baptiste Daroussin wrote: Hello, Following up on the proposal which happened last month, /bin/sh is now the default shell for the root user. As claimed during that proposal, I have so far no intention to change anything more: I won't remove or modify the 'toor' user, neither modify the root gecos. By popular demand on the thread about the proposal the following bindings have been set by default: navigation through history "ala" csh via the up and down arrow navigation on the command line via ctrl+arrow (left/right) jumps from words to words An alias on fc -l named "history", so the history command to exist. etcupdate will silently switch to sh(1) the first time, for people who wants to keep root on csh, they will have to run: $ chsh -s csh The next upgrade will keep that setting Will sh config be upgraded to reflect all recent changes as well or we need to do it manually? -- Renato Botelho
Re: [HEADSUP] making /bin/sh the default shell for root
+1 for keeping this behavior on default config On 22/09/21 06:19, Daniel Morante via freebsd-current wrote: Will history/completion continue to work the same way? (for example typing part of the command, pressing UP and having it complete based on history) On 9/22/2021 4:36 AM, Baptiste Daroussin wrote: Hello, TL;DR: this is not a proposal to deorbit csh from base!!! For years now, csh is the default root shell for FreeBSD, csh can be confusing as a default shell for many as all other unix like settled on a bourne shell compatible interactive shell: zsh, bash, or variant of ksh. Recently our sh(1) has receive update to make it more user friendly in interactive mode: * command completion (thanks pstef@) * improvement in the emacs mode, to make it behave by default like other shells * improvement in the vi mode (in particular the vi edit to respect $EDITOR) * support for history as described by POSIX. This makes it a usable shell by default, which is why I would like to propose to make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) If no strong arguments has been raised until October 15th, I will make this proposal happen. Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! Best regards, Baptiste -- Renato Botelho
zpool upgrade can't enable new features
I recently upgraded a CURRENT system to main-n244932-248a47a4c2f and zpool status shows: pool: zroot state: ONLINE status: Some supported and requested features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(5) for details. config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 da0p4 ONLINE 0 0 0 da1p4 ONLINE 0 0 0 da2p4 ONLINE 0 0 0 da3p4 ONLINE 0 0 0 errors: No known data errors Then I ran zpool upgrade zroot and got: This system supports ZFS pool feature flags. Pool 'zroot' already has all supported and requested features enabled. After that zpool status output stays the same what made me believe something is not right here. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On 24/12/20 11:15, Michael Grimm wrote: Correction: On 24. Dec 2020, at 15:11, Michael Grimm wrote: In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a larger revision number than those in advisories or notices. In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a smaller revision number than those in advisories or notices. FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 3cc0c0d66a0-c255241(main)-dirty: ^ This is an incremental counter of commits -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 23/12/20 15:20, Michael Grimm wrote: Renato Botelho wrote: If you want to switch to a different already existing branch, as svn switch does, you should look at git-checkout. It can be a bit expensive due to the size of src repository so if you do work on multiple branches too often you can improve it using git-worktree. If I understand git-worktree(1) correctly I will most probably not need it, because I will only follow one single branch stable/12, and soon stable/13. Or do I miss something important? You are correct. You can clone stable/12 now and when it's time just do # git checkout stable/13 -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 23/12/20 11:32, Michael Grimm wrote: Hi, Warner Losh wrote: The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. First of all I'd like to thank all those involved in this for their efforts. Following https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md form your other mail I was able to migrate from svn to git without running into any issues. Right now I am learning how to use git the way I sed svn before. I am just following 12-STABLE in order to build world and kernel. I am not developing, neither am I committing. I wonder how one would switch from a currently used branch (OLD) to another branch (NEW). With svn I used: svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src For git I found: git branch -m stable/OLD stable/NEW or git branch -M stable/OLD stable/NEW git-branch(1): With a -m or -M option, will be renamed to . If had a corresponding reflog, it is renamed to match , and a reflog entry is created to remember the branch renaming. If exists, -M must be used to force the rename to happen. I don't understand that text completely, because I don't know what a reflog is, yet ;-) Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to stable/13 in the near future? git-branch is used to create/delete/rename branches. If you want to switch to a different already existing branch, as svn switch does, you should look at git-checkout. It can be a bit expensive due to the size of src repository so if you do work on multiple branches too often you can improve it using git-worktree. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Deprecating ftpd in the FreeBSD base system?
On 17/09/20 11:04, Cy Schubert wrote: In message , Ed Maste writes: FTP is (becoming?) a legacy protocol, and I think it may be time to remove the ftp server from the FreeBSD base system - with the recent security advisory for ftpd serving as a reminder. I've proposed adding a deprecation notice to the man page in https://reviews.freebsd.org/D26447 to start this off. There are a number of ftp servers in ports, and if we're going to remove the base system one we can create a port for it first, as well. Any comments or concerns, please follow up in the code review or in email her e. We should also deprecate the FTP client. I've been advocating removing FTP (and HTTP) from libfetch as well. People should be using HTTPS only. (libfetch could support a plugin that might be supplied by a port should someone be inclined to write one.) FTP is firewall unfriendly. The F5 gateway at $JOB does not support FTP. When we still worked at the office I had to take my $JOB laptop to the coffee shop to use their wireless to download patches from Broadcom's FTP site. Now that I WFH (we won't ever go back to the office) I download while disconnected from the VPN. Then move the removed bits to ports, which I think we already have in tnftp and tnftpd. pkg still uses HTTP ❯ sudo pkg -d update -f Password: DBG(1)[78228]> pkg initialized Updating FreeBSD repository catalogue... DBG(1)[78228]> PkgRepo: verifying update for FreeBSD DBG(1)[78228]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite' DBG(1)[78228]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/latest/meta.conf with opts "i" Fetching meta.conf: 100%163 B 0.2kB/s00:01 DBG(1)[78228]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/latest/packagesite.txz with opts "i" Fetching packagesite.txz: 100%6 MiB 6.5MB/s00:01 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Please check the current beta git conversions
On 02/09/20 20:20, Steffen Nurpmeso wrote: Ed Maste wrote in : I tried simply updating my github clone by switching url = https://cgit-beta.freebsd.org/src.git #url = https://github.com/freebsd/freebsd.git and whereas ls-remote worked fine fetch -v --dry-run aborted as well as normal fetch, after dumping dozens of POSTs POST git-upload-pack (gzip 1472 to 804 bytes) ... POST git-upload-pack (gzip 976722 to 483608 bytes) POST git-upload-pack (chunked) error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 fatal: the remote end hung up unexpectedly Maybe clone from scratch instead, but mysterious it is? Good night, and Ciao from Germany, github and cgit-beta repositories are not the same. Commit hashes won't match so you cannot simply change the URL. Look at this example. Same commit with different hash: https://github.com/freebsd/freebsd/commit/33ad4343e75940eae87391cc2198ddb617246ea3 https://cgit-beta.freebsd.org/src/commit/?id=f04d830d76bdba3c5d2f3a184a72f64413dafe44 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM (i915kms) panic on r353303
On 08/10/19 10:15, Mateusz Guzik wrote: > Try this: > > https://people.freebsd.org/~mjg/pmap-nosparse.diff It fixed the problem here. Thanks for the quick reply! -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
DRM (i915kms) panic on r353303
I'm not sure which revision I was before it broke. I can try to bisect if necessary. I'm getting a panic as you can see on these pictures [1] after I upgraded my ThinkPad x230 to r353303. drm-current-kmod is in the last version and I already tried to rebuild it just to be sure. Any help would be much appreciated. [1] https://imgur.com/a/JmZ4uTv -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't boot current on Minnowboard
On 24/09/19 17:46, D Scott Phillips wrote: > Renato Botelho writes: > >> On 24/09/19 15:36, Toomas Soome wrote: >>> >>> >>>> On 24 Sep 2019, at 21:12, Renato Botelho wrote: >>>> >>>> On 24/09/19 15:10, Toomas Soome wrote: >>>>> >>>>> >>>>>> On 24 Sep 2019, at 20:50, Renato Botelho wrote: >>>>>> >>>>>> As reported at pfSense ticket [1], we can't see console after booting >>>>>> FreeBSD installer iso on Minnowboard. This video [2] demonstrates the >>>>>> problem. >>>>>> >>>>>> Basically I can see all kernel messages but nothing from userland after >>>>>> kernel finishes to load. >>>>>> >>>>>> I would be glad to collect any kind of data you need to help tracking it >>>>>> down. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> [1] https://redmine.pfsense.org/issues/9488 >>>>>> [2] https://imgur.com/a/V4IrQWo >>>>>> -- >>>>>> Renato Botelho >>>>> >>>>> Hi! >>>>> >>>>> does it have bios emulation and does it behave there? >>>> >>>> No, this board is EFI only. >>>> >>> >>> Is it atom board? UEFI32 or UEFI64? >> >> It's Atom and is UEFI64. >> >> I figured out this board has HDMI and serial console and output is going >> only to serial. If LiveCD option is selected on serial it shows up on >> HDMI as well. >> >> I've downloaded latest firmware version and updated the board. After >> that I noted serial console is configurable on setup and disabled by >> default. >> >> Even with Input/Output serial items disabled it's sending output to >> serial console and I can see UArt item listed on EFI variables on loader >> prompt. > > The logic in stand/efi/loader/main.c:parse_uefi_con_out() seems to be > that RB_SERIAL is set when the serial device appears before the video > device in the ConOut efi variable, which is the case on a minnowboard > that I looked at. You can override this by setting boot_serial="NO" in > loader.conf or running `set boot_serial=NO` at the loader prompt. Adding boot_serial=NO works. I just wonder why the firmware setup option to disable serial port is not being respected. Thanks! -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't boot current on Minnowboard
On 24/09/19 15:36, Toomas Soome wrote: > > >> On 24 Sep 2019, at 21:12, Renato Botelho wrote: >> >> On 24/09/19 15:10, Toomas Soome wrote: >>> >>> >>>> On 24 Sep 2019, at 20:50, Renato Botelho wrote: >>>> >>>> As reported at pfSense ticket [1], we can't see console after booting >>>> FreeBSD installer iso on Minnowboard. This video [2] demonstrates the >>>> problem. >>>> >>>> Basically I can see all kernel messages but nothing from userland after >>>> kernel finishes to load. >>>> >>>> I would be glad to collect any kind of data you need to help tracking it >>>> down. >>>> >>>> Thanks! >>>> >>>> [1] https://redmine.pfsense.org/issues/9488 >>>> [2] https://imgur.com/a/V4IrQWo >>>> -- >>>> Renato Botelho >>> >>> Hi! >>> >>> does it have bios emulation and does it behave there? >> >> No, this board is EFI only. >> > > Is it atom board? UEFI32 or UEFI64? It's Atom and is UEFI64. I figured out this board has HDMI and serial console and output is going only to serial. If LiveCD option is selected on serial it shows up on HDMI as well. I've downloaded latest firmware version and updated the board. After that I noted serial console is configurable on setup and disabled by default. Even with Input/Output serial items disabled it's sending output to serial console and I can see UArt item listed on EFI variables on loader prompt. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't boot current on Minnowboard
On 24/09/19 15:10, Toomas Soome wrote: > > >> On 24 Sep 2019, at 20:50, Renato Botelho wrote: >> >> As reported at pfSense ticket [1], we can't see console after booting >> FreeBSD installer iso on Minnowboard. This video [2] demonstrates the >> problem. >> >> Basically I can see all kernel messages but nothing from userland after >> kernel finishes to load. >> >> I would be glad to collect any kind of data you need to help tracking it >> down. >> >> Thanks! >> >> [1] https://redmine.pfsense.org/issues/9488 >> [2] https://imgur.com/a/V4IrQWo >> -- >> Renato Botelho > > Hi! > > does it have bios emulation and does it behave there? No, this board is EFI only. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Can't boot current on Minnowboard
As reported at pfSense ticket [1], we can't see console after booting FreeBSD installer iso on Minnowboard. This video [2] demonstrates the problem. Basically I can see all kernel messages but nothing from userland after kernel finishes to load. I would be glad to collect any kind of data you need to help tracking it down. Thanks! [1] https://redmine.pfsense.org/issues/9488 [2] https://imgur.com/a/V4IrQWo -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: IPv6 RFC3041 temporary address broken?
On 12/02/19 11:03, Shawn Webb wrote: > Hey all, > > I have net.inet6.ip6.use_tempaddr and net.inet6.ip6.prefer_tempaddr > both set to 1. Yet, I'm not seeing temporary addresses created upon > receipt of a router advertisement. I'm only seeing the HostID-based > SLAAC IP be generated. Has something changed recently that would > prevent RFC3041 from working in FreeBSD HEAD? > > Thanks, > It's working as expected here: lagg0: flags=8843 metric 0 mtu 1500 ether 3c:97:0e:48:3f:f8 inet6 fe80::3e97:eff:fe48:3ff8%lagg0 prefixlen 64 scopeid 0x4 inet6 2804:f1c:800:e00:3e97:eff:fe48:3ff8 prefixlen 64 autoconf inet6 2804:f1c:800:e00:30e9:88ac:84fc:ebea prefixlen 64 autoconf temporary inet 172.21.4.121 netmask 0xff00 broadcast 172.21.4.255 laggproto failover lagghash l2,l3,l4 laggport: em0 flags=1 laggport: wlan0 flags=4 groups: lagg media: Ethernet autoselect status: active nd6 options=23 ❯ uname -a FreeBSD x230 13.0-CURRENT FreeBSD 13.0-CURRENT #83 r344002: Mon Feb 11 11:54:18 -02 2019 root@x230:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 -- Renato Botelho signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 26/11/18 19:59, Yuri Pankov wrote: > Renato Botelho wrote: >> On 26/11/18 19:32, Florian Limberger wrote: >>> Hi, >>> >>> On 20.11.18 14:46, Charlie Li wrote: >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] >>>> (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl >>>> (ID=3) has no handler (20181031/exfldio-428) >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution >>>> failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) >>> >>> On my Thinkpad T410 I get exactly the same error, but it prevents the >>> ACPI poweroff. Instead following lines are printed: >> >> I'm seeing it on my ThinkPad x230 as well > > Looks like r340993 should be the fix? > If fixed it to me. Thanks! -- Renato Botelho signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 26/11/18 19:32, Florian Limberger wrote: > Hi, > > On 20.11.18 14:46, Charlie Li wrote: >> Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] >> (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) >> Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl >> (ID=3) has no handler (20181031/exfldio-428) >> Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution >> failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) > > On my Thinkpad T410 I get exactly the same error, but it prevents the > ACPI poweroff. Instead following lines are printed: I'm seeing it on my ThinkPad x230 as well -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Testing: UEFI Changes
On 21/03/18 21:45, Kyle Evans wrote: > Hello! > > A number of changes have gone in recently pertaining to UEFI booting > and UEFI runtime services. The changes with the most damaging > potential are: > > We now put UEFI runtime services into virtual address mode, fixing > runtime services with U-Boot/UEFI as well as the firmware > implementation in many Lenovos. The previously observed behavior was a > kernel panic upon invocation of efibootmgr/efivar, or a kernel panic > just loading efirt.ko or compiling EFIRT into the kernel. > > Graphics mode selection is now done differently to avoid regression > caused by r327058 while still achieving the same effect. The observed > regression was that the kernel would usually end up drawing > incorrectly at the old resolution on a subset of the screen, due to > incorrect framebuffer information. > > Explicit testing of these changes, the latest of which happened in > r331326, and any feedback from this testing would be greatly > appreciated. Testing should be done with either `options EFIRT` in > your kernel config or efirt.ko loaded along with updated bootloader > bits. > > I otherwise plan to MFC commits involved with the above-mentioned > changes by sometime in the first week of April, likely no earlier than > two (2) weeks from now on April 4th. Just FYI, After upgrade to r331350 on a Thinkpad X230 using drm-next-kmod trackpoint stopped working and touchpad worked but 3 buttons above it didn't. Removing drm-next-kmod and start using i915kms.ko from /boot/kernel fixed it. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Question mark on Lua menu box
On 02/03/18 12:55, Kyle Evans wrote: > On Fri, Mar 2, 2018 at 9:52 AM, Renato Botelho <ga...@freebsd.org> wrote: >> On 02/03/18 12:31, Kyle Evans wrote: >>> On Fri, Mar 2, 2018 at 6:06 AM, Renato Botelho <ga...@freebsd.org> wrote: >>>> Kyle, >>>> >>>> I've moved to Lua loader to help testing and it worked fine. The only >>>> odd thing I noted is the menu box with odd chars as you can see at [1]. >>>> >>>> My laptop is running a recent current (r330275) with ZFS and UEFI. >>>> >>>> [1] https://imgur.com/a/kIQ0O >>>> -- >>>> Renato Botelho >>>> >>> >>> Hi, >>> >>> Thanks for testing! =) Can you give it a shot with EFI boot after >>> r330281 (just committed), please? >>> >>> I think our working theory is that we were printing newlines along >>> with our box-drawing characters, and that could be problematic. The >>> new version handles all of that a little better and respects >>> loader_menu_frame to boot. >> >> Hi, >> >> Unfortunately it didn't change anything. >> > > Aw =(. Can you take a picture of what Forth loader looks like for you > with the default frame style on an EFI boot? I'm wondering if it's not > doing something sneaky that I can't determine from the things I've > looked at. Sure, here it is: https://imgur.com/a/fmO8w -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Question mark on Lua menu box
On 02/03/18 12:31, Kyle Evans wrote: > On Fri, Mar 2, 2018 at 6:06 AM, Renato Botelho <ga...@freebsd.org> wrote: >> Kyle, >> >> I've moved to Lua loader to help testing and it worked fine. The only >> odd thing I noted is the menu box with odd chars as you can see at [1]. >> >> My laptop is running a recent current (r330275) with ZFS and UEFI. >> >> [1] https://imgur.com/a/kIQ0O >> -- >> Renato Botelho >> > > Hi, > > Thanks for testing! =) Can you give it a shot with EFI boot after > r330281 (just committed), please? > > I think our working theory is that we were printing newlines along > with our box-drawing characters, and that could be problematic. The > new version handles all of that a little better and respects > loader_menu_frame to boot. Hi, Unfortunately it didn't change anything. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Question mark on Lua menu box
Kyle, I've moved to Lua loader to help testing and it worked fine. The only odd thing I noted is the menu box with odd chars as you can see at [1]. My laptop is running a recent current (r330275) with ZFS and UEFI. [1] https://imgur.com/a/kIQ0O -- Renato Botelho signature.asc Description: OpenPGP digital signature
Re: [RESOLVED] Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11
On 26/06/17 00:59, Benjamin Kaduk wrote: > On Fri, Jun 23, 2017 at 11:22:46PM -0500, Benjamin Kaduk wrote: >> I fixed the rc.conf snippet in the handbook in r50399. >> I lost track of the rest of the thread as to what needs to be >> changed in the actual command examples in lagg.4 and/or the >> handbook, though. > > To be clear, that is: one of you please supply the correct commands > to execute this configuration manually (i.e., not via rc.conf), or the > rest of the documentation is unlikely to get updated. On lagg(4): # ifconfig em0 up # ifconfig create wlan0 wlandev ath0 ssid my_net \ wlanaddr 00:11:22:33:44:55 up # ifconfig lagg0 create # ifconfig lagg0 laggproto failover laggport em0 laggport wlan0 \ 192.168.1.1 netmask 255.255.255.0 On Handbook [1]: Following line should be removed: # ifconfig iwn0 ether 00:21:70:da:ae:37 And the next example command should be changed to: # ifconfig wlan0 create wlandev iwn0 ssid my_router \ wlanaddr 00:21:70:da:ae:37 up The rc.conf block looks fine. Thank you for taking care of it. [1] https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RESOLVED] Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11
On 23/06/17 13:43, Adrian Chadd wrote: > Hi, > > You can't change a wifi mac address /after the interface is up/. So if > that's happening with this RC script combination then we should kinda > fix that. OK, so in the end I managed to make it work without any kernel change. This is how rc.conf look like, as pointed out by András Krasznai. ifconfig_em0="up" wlans_iwn0="wlan0" ifconfig_wlan0="WPA" create_args_wlan0="wlanaddr 3c:97:0e:48:3f:f8" cloned_interfaces="lagg0" ifconfig_lagg0="up laggproto failover laggport em0 laggport wlan0 DHCP" So now the only remaining issue is related to docs. lagg(4) manpage example and Handbook must be fixed Thank you all for the help -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11
On 21/06/17 16:26, Sean Bruno wrote:
>
>
> On 06/21/17 11:48, Renato Botelho wrote:
>> I've already sent it to net, but I suspect this is the appropriate place
>> to discuss this subject.
>>
>> Last night I was configuring a new laptop and decided to give it [1] a
>> try. I figured out this section of handbook (similar instructions are on
>> lagg(4) manpage) is outdated, based on FreeBSD 10.x.
>>
>> Then I modified a bit the commands and tried to get it configured on
>> 12-CURRENT, without success. I spoke with adrian@, who told me this
>> setup doesn't work on FreeBSD > 10, because on newer versions Wireless
>> interfaces mac address cannot be changed.
>>
>> My next attempt was to do the other way round and make lagg to use wlan0
>> mac address instead of em0's. but even doing this my wireless interface
>> ended up not working.
>>
>> After further investigation I noted that a simple command:
>>
>> # ifconfig wlan0 ether $wlan0_current_mac_address
>>
>> is enough to break it on 12-CURRENT.
>>
>> I've checked if_setlladdr() source code and noted it always replace the
>> mac address, even if the same is already configured on the interface. Is
>> it the expected behavior?
>>
>> Just as a PoC I've applied the following patch to if_setlladdr():
>>
>> Index: sys/net/if.c
>> ===
>> --- sys/net/if.c (revision 320097)
>> +++ sys/net/if.c (working copy)
>> @@ -3519,6 +3519,10 @@
>> ifa_free(ifa);
>> return (EINVAL);
>> }
>> +if (memcmp(lladdr, LLADDR(sdl), len) == 0) {
>> +ifa_free(ifa);
>> +return (0);
>> +}
>> switch (ifp->if_type) {
>> case IFT_ETHER:
>> case IFT_FDDI:
>>
>> And configured it to use wlan0 mac address on rc.conf:
>>
>> ifconfig_em0="ether 60:67:20:c5:2d:48 up"
>> wlans_iwn0="wlan0"
>> ifconfig_wlan0="WPA"
>> cloned_interfaces="lagg0"
>> ifconfig_lagg0="up laggproto failover laggport em0 laggport wlan0 DHCP"
>>
>> and it's now working as expected.
>>
>> Other than that, I believe if wlan interfaces cannot have their mac
>> address changed, ifconfig should return an error when user attempts to
>> do it, and if_setlladdr() should do the same.
>>
>> Thoughts?
>>
>> [1]
>> https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless
>>
>
>
> Maybe this is a "iflib" problem. em(4) and igb(4) are pretty different
> now in head. Can you shove it into bugzilla with a test case
> (copy/paste your email) and tag me on it?
em0 is working as expected, the main problem is on iwn, which in my case is:
iwn0@pci0:3:0:0:class=0x028000 card=0x13118086 chip=0x00858086 rev=0x34
hdr=0x00
vendor = 'Intel Corporation'
device = 'Centrino Advanced-N 6205 [Taylor Peak]'
class = network
After investigate a bit more I noted wpa_supplicant is exiting when I
change wlan0 mac address, and because of that my interface is
disconnected. If I start wpa_supplicant again it back to work.
# ifconfig wlan0 | grep status:
status: associated
# ifconfig wlan0 ether 60:67:20:c5:2d:49
# ifconfig wlan0 | grep status:
status: no carrier
# /etc/rc.d/wpa_supplicant restart wlan0
wpa_supplicant not running? (check /var/run/wpa_supplicant/wlan0.pid).
Starting wpa_supplicant.
# ifconfig wlan0 | grep status:
status: associated
It happens every time, even if I call ifconfig using the same mac
address already configured. In this case, that patch I submitted on
first email prevent the error to happen.
Attached you can see wpa_supplicant log, my understanding is the
relevant line is:
1498213478.949506: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't
assign requested address
--
Renato Botelho
1498213478.949265: wlan0: Event DISASSOC (1) received
1498213478.949291: wlan0: Disassociation notification
1498213478.949308: wlan0: CTRL-EVENT-DISCONNECTED bssid=56:d9:e7:75:3f:b6
reason=0
1498213478.949321: wlan0: Auto connect enabled: try to reconnect (wps=0/0
wpa_state=9)
1498213478.949335: wlan0: Setting scan request: 0.10 sec
1498213478.949367: Added BSSID 56:d9:e7:75:3f:b6 into blacklist
1498213478.949383: wlan0: Blacklist count 1 --> request scan in 100 ms
1498213478.949395: wlan0: Ignore new scan request for 0.10 sec since an
earlier request is scheduled to trigger sooner
1498213478.949408: wlan0: WPA: Clear old PMK and PTK
1498213478.949416: wlan0: Disconnect event - remove keys
1498213478.949422: bsd_set_key:
Re: Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11
On 21/06/17 14:56, Guido Falsi wrote: > On 06/21/17 19:48, Renato Botelho wrote: >> I've already sent it to net, but I suspect this is the appropriate place >> to discuss this subject. > [...] >> >> My next attempt was to do the other way round and make lagg to use wlan0 >> mac address instead of em0's. but even doing this my wireless interface >> ended up not working. > > Strange enough, this works for me. My laptop has a bge interface. Maybe > that's relevant. > > [...] >> >> And configured it to use wlan0 mac address on rc.conf: >> >> ifconfig_em0="ether 60:67:20:c5:2d:48 up" >> wlans_iwn0="wlan0" >> ifconfig_wlan0="WPA" >> cloned_interfaces="lagg0" >> ifconfig_lagg0="up laggproto failover laggport em0 laggport wlan0 DHCP" >> >> and it's now working as expected. > > I can confirm this is exactly what I've been doing for a while on my > laptop. As noted before I did not need to patch the kernel to have this > working. Maybe bge is not affected by this bug, interesting. It would be good to know which models are affected > >> >> Other than that, I believe if wlan interfaces cannot have their mac >> address changed, ifconfig should return an error when user attempts to >> do it, and if_setlladdr() should do the same. >> >> Thoughts? > > I agree returning some error code would be nicer on users. > In this case since some drivers are OK and others not, we cannot remove the possibility of changing mac address from ifconfig for all wlan interfaces. I'm wondering if there is any side-effect to have only the change I made applied, not sure if there are reasons to run filters and event_handler when if_setlladdr() is called with the same address that is current set on NIC. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11
I've already sent it to net, but I suspect this is the appropriate place
to discuss this subject.
Last night I was configuring a new laptop and decided to give it [1] a
try. I figured out this section of handbook (similar instructions are on
lagg(4) manpage) is outdated, based on FreeBSD 10.x.
Then I modified a bit the commands and tried to get it configured on
12-CURRENT, without success. I spoke with adrian@, who told me this
setup doesn't work on FreeBSD > 10, because on newer versions Wireless
interfaces mac address cannot be changed.
My next attempt was to do the other way round and make lagg to use wlan0
mac address instead of em0's. but even doing this my wireless interface
ended up not working.
After further investigation I noted that a simple command:
# ifconfig wlan0 ether $wlan0_current_mac_address
is enough to break it on 12-CURRENT.
I've checked if_setlladdr() source code and noted it always replace the
mac address, even if the same is already configured on the interface. Is
it the expected behavior?
Just as a PoC I've applied the following patch to if_setlladdr():
Index: sys/net/if.c
===
--- sys/net/if.c(revision 320097)
+++ sys/net/if.c(working copy)
@@ -3519,6 +3519,10 @@
ifa_free(ifa);
return (EINVAL);
}
+ if (memcmp(lladdr, LLADDR(sdl), len) == 0) {
+ ifa_free(ifa);
+ return (0);
+ }
switch (ifp->if_type) {
case IFT_ETHER:
case IFT_FDDI:
And configured it to use wlan0 mac address on rc.conf:
ifconfig_em0="ether 60:67:20:c5:2d:48 up"
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA"
cloned_interfaces="lagg0"
ifconfig_lagg0="up laggproto failover laggport em0 laggport wlan0 DHCP"
and it's now working as expected.
Other than that, I believe if wlan interfaces cannot have their mac
address changed, ifconfig should return an error when user attempts to
do it, and if_setlladdr() should do the same.
Thoughts?
[1]
https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless
--
Renato Botelho
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make warning: ?: No such file or directory.
On 10/05/17 13:02, Bryan Drewery wrote: > On 5/9/17 9:50 PM, Ngie Cooper (yaneurabeya) wrote: >> >>> On May 9, 2017, at 21:37, O. Hartmann <ohartm...@walstatt.org> wrote: >>> >>> On recent CURRENT, the source tree /usr/src seems to have issues on some of >>> my >>> boxes and whenever I issue "make build", the message: >>> >>> make warning: �: No such file or directory. >>> >>> pops up. "svn st" doesn't reveal anything wrong. >>> >>> My locale settings are: >>> >>> LANG= >>> LC_CTYPE="C" >>> LC_COLLATE="C" >>> LC_TIME="C" >>> LC_NUMERIC="C" >>> LC_MONETARY="C" >>> LC_MESSAGES="C" >>> LC_ALL= >>> >>> (just for the record). Those spooky non-printables are seen on xterm(s) of >>> various other systems (11.0, 11-STABLE, 12-CURRENT) when connecting to the >>> systems in question. >>> >>> What is this? >>> >>> Kind regards and thanks in advance, >> >> I see similar oddness when running some commands. It seems to be happening >> as of the last month or two. >> Thanks, >> -Ngie >> >> $ make buildenv TARGET_ARCH=armv6 >> make warning: I: No such file or directory. >> make warning: I: No such file or directory. >> Entering world for armv6:arm >> $ > > "I" > > Do you have an "I" in your env somewhere? Though a later email makes it > look like uninitialized memory. I've reported a similar issue in 04/21 [1] and I keep seeing the problem around: # ❯❯❯ make check-old make warning: $5bZ� : No such file or directory. make warning: $5bZ� : No such file or directory. >>> Checking for old files make warning: $5bZ� : No such file or directory. >>> Checking for old libraries make warning: $5bZ� : No such file or directory. >>> Checking for old directories make warning: $5bZ� : No such file or directory. To remove old files and directories run 'make delete-old'. To remove old libraries run 'make delete-old-libs'. [1] https://lists.freebsd.org/pipermail/freebsd-current/2017-April/065690.html -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make warning: ?: No such file or directory.
On 10/05/17 13:02, Bryan Drewery wrote: > On 5/9/17 9:50 PM, Ngie Cooper (yaneurabeya) wrote: >> >>> On May 9, 2017, at 21:37, O. Hartmann <ohartm...@walstatt.org> wrote: >>> >>> On recent CURRENT, the source tree /usr/src seems to have issues on some of >>> my >>> boxes and whenever I issue "make build", the message: >>> >>> make warning: �: No such file or directory. >>> >>> pops up. "svn st" doesn't reveal anything wrong. >>> >>> My locale settings are: >>> >>> LANG= >>> LC_CTYPE="C" >>> LC_COLLATE="C" >>> LC_TIME="C" >>> LC_NUMERIC="C" >>> LC_MONETARY="C" >>> LC_MESSAGES="C" >>> LC_ALL= >>> >>> (just for the record). Those spooky non-printables are seen on xterm(s) of >>> various other systems (11.0, 11-STABLE, 12-CURRENT) when connecting to the >>> systems in question. >>> >>> What is this? >>> >>> Kind regards and thanks in advance, >> >> I see similar oddness when running some commands. It seems to be happening >> as of the last month or two. >> Thanks, >> -Ngie >> >> $ make buildenv TARGET_ARCH=armv6 >> make warning: I: No such file or directory. >> make warning: I: No such file or directory. >> Entering world for armv6:arm >> $ > > "I" > > Do you have an "I" in your env somewhere? Though a later email makes it > look like uninitialized memory. I've reported a similar issue in 04/21 [1] and I keep seeing the problem around: # ❯❯❯ make check-old make warning: $5bZ� : No such file or directory. make warning: $5bZ� : No such file or directory. >>> Checking for old files make warning: $5bZ� : No such file or directory. >>> Checking for old libraries make warning: $5bZ� : No such file or directory. >>> Checking for old directories make warning: $5bZ� : No such file or directory. To remove old files and directories run 'make delete-old'. To remove old libraries run 'make delete-old-libs'. [1] https://lists.freebsd.org/pipermail/freebsd-current/2017-April/065690.html -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make check-old warnings
On 21/04/17 15:58, Renato Botelho wrote: > I've updated my laptop to r317256 and started to see some warnings when > I run make check-old: > > ❯ make check-old > make warning: $5bZ� > : No such file or directory. > make warning: $5bZ� > : No such file or directory. >>>> Checking for old files > make warning: $5bZ� > : No such file or directory. This warning is not exclusive from check-old. IF I just run: # make -V ANY_VARIABLE_HERE make warning: $5bZ : No such file of directory VALUE_OF_ANY_VARIABLE_HERE -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
make check-old warnings
I've updated my laptop to r317256 and started to see some warnings when I run make check-old: ❯ make check-old make warning: $5bZ� : No such file or directory. make warning: $5bZ� : No such file or directory. >>> Checking for old files make warning: $5bZ� : No such file or directory. /usr/bin/gdb /usr/lib/debug/usr/bin/gdb.debug /usr/bin/gdbserver /usr/lib/debug/usr/bin/gdbserver.debug /usr/bin/gdbtui /usr/lib/debug/usr/bin/gdbtui.debug /usr/bin/kgdb /usr/lib/debug/usr/bin/kgdb.debug /usr/share/man/man1/gdb.1.gz /usr/share/man/man1/gdbserver.1.gz /usr/share/man/man1/kgdb.1.gz >>> Checking for old libraries make warning: $5bZ� : No such file or directory. >>> Checking for old directories make warning: $5bZ� : No such file or directory. /usr/share/examples/hast /usr/share/examples/ipfilter /usr/libexec/lpr/ru /usr/lib/debug/usr/libexec/lpr/ru /usr/libexec/lpr /usr/lib/debug/usr/libexec/lpr /usr/share/doc/smm/07.lpd /usr/share/pc-sysinstall/backend /usr/share/pc-sysinstall/backend-partmanager /usr/share/pc-sysinstall/backend-query /usr/share/pc-sysinstall/conf/license /usr/share/pc-sysinstall/conf /usr/share/pc-sysinstall/doc /usr/share/pc-sysinstall /usr/share/examples/pc-sysinstall /etc/ppp /usr/include/libmilter /usr/share/doc/smm/08.sendmailop /usr/share/sendmail /usr/include/atf-c /usr/include/atf-c++ /usr/share/atf /usr/share/doc/atf To remove old files and directories run 'make delete-old'. To remove old libraries run 'make delete-old-libs'. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A question about updating src & ports
> On 29 Dec 2016, at 08:11, blubee blubeeme <gurenc...@gmail.com> wrote: > > Howdy > > I went through the process of building world for the first time, that was > interesting but I got it. svn clean up prior object files, build world, > kernel, etc. > > Okay that part is fine > > I have a question about keeping ports up to date, in the past I did > portsnap fetch update to update the ports but since I totally deleted all > the ports and used svn checkout to get the latest ports. > > Can I mix portsnap fetch update or should I just continue to use svn update > /usr/ports If you download ports tree using ‘portsnap fetch extract’ you can keep using ‘portsnap fetch update’ to update it. If you download ports tree using ‘svn checkout …’, then you should use ‘svn up’. IMO, portsnap is the easiest way. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 1st build stops when WITH_AUTO_OBJ=yes
> On 9 Nov 2016, at 19:48, Simon J. Gerraty <s...@juniper.net> wrote: > > Renato Botelho <ga...@freebsd.org> wrote: > >> I decided to give a try to WITH_AUTO_OBJ and noted the first time I ran >> buildworld it failed with following message: >> >> /u/src # ❯❯❯ make WITH_AUTO_OBJ=yes buildworld >> [Creating objdir obj...] >> make: "/usr/src/share/mk/auto.obj.mk" line 61: could not use obj: >> .OBJDIR=/usr/src/obj >> >> After that I noted it created a directory /usr/src/obj and if I call >> it again it runs without issues. If I remove /usr/src/obj directory >> error happens again > > Interesting; what .OBJDIR do you end up with for say bin/cat ? In this case it fails the first time pointing to expected .OBJDIR, then second time I run it builds /u/s/b/cat # ❯❯❯ make -DWITH_AUTO_OBJ [Creating objdir obj...] make: "/usr/src/share/mk/auto.obj.mk" line 61: could not use obj: .OBJDIR=/usr/obj/usr/src/bin/cat /u/s/b/cat # ❯❯❯ make -DWITH_AUTO_OBJ ⏎ Building /usr/obj/usr/src/bin/cat/cat.o Building /usr/obj/usr/src/bin/cat/cat.full Building /usr/obj/usr/src/bin/cat/cat.debug Building /usr/obj/usr/src/bin/cat/cat -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
1st build stops when WITH_AUTO_OBJ=yes
I decided to give a try to WITH_AUTO_OBJ and noted the first time I ran buildworld it failed with following message: /u/src # ❯❯❯ make WITH_AUTO_OBJ=yes buildworld [Creating objdir obj...] make: "/usr/src/share/mk/auto.obj.mk" line 61: could not use obj: .OBJDIR=/usr/src/obj After that I noted it created a directory /usr/src/obj and if I call it again it runs without issues. If I remove /usr/src/obj directory error happens again. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Use of env SRC_ENV_CONF=. . . for buildworld does not override/avoid use of /etc/src.conf : Intentional?
> On 3 Nov 2016, at 22:28, Mark Millard <mar...@dsl-only.net> wrote: > > I just had a case of "odd" command text in a buildworld that was based on (in > part) env SRC_ENV_CONF=. . . > > env __MAKE_CONF=. . . does not get the kind of behavior reported below for > /etc/src.conf . > > Overall this means that even with an explicit env SRC_ENV_CONF=. . . one must > separately prevent /etc/src.conf from contributing if the SRC_ENV_CONF file > is intended to cover everything. > > Looking in the log from a failure that resulted shows that .MAKE.MAKEFILES > shows both the SRC_ENV_CONF expansion and also a /etc/src.conf as well > (formatted to make the /etc/src.conf and such stand out: separate lines wiht > whitespace before and after and with just one path on the line for such file > paths): > >> Script started on Thu Nov 3 16:37:26 2016 >> Command: env __MAKE_CONF=/root/src.configs/make.conf >> SRC_ENV_CONF=/root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host >> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/powerpc64vtsc_xtoolchain make >> -j 5 buildworld buildkernel > . . . >> .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk >> /usr/src/share/mk/src.sys.env.mk > >> /root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host > >> /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk > >> /root/src.configs/make.conf > >> /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk > >> /etc/src.conf > >> /usr/src/include/rpcsvc/Makefile /usr/src/share/mk/bsd.prog.mk >> /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk >> /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk >> /usr/src/share/mk/src.init >> .mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk >> /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk >> /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk >> /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share >> /mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk >> /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk >> /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk >> /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk >> /usr/src/share/mk/bsd.sys.mk' >> .PATH='. /usr/src/include/rpcsvc' > > Note: > >> # grep src.conf /root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host >> # > > > The context I was under was: > >> # uname -apKU >> FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r308247M: Thu Nov 3 >> 04:05:55 PDT 2016 >> markmi@FreeBSDx64:/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC-NODBG >> amd64 amd64 1200014 1200014 > > I'd just cloned and switched from a stable/11 context to head (12-CURRENT). > > If this is intentional then I think the man src.conf references and such > should be explicit about the /etc/make.conf vs. /etc/src.conf distinction for > __MAKE_CONF= vs. SRC_ENV_CONF= . There are 3 possible files and 3 possible variables to cover it. SRC_ENV_CONF is to /etc/src-env.conf and not to /etc/src.conf. Default values are: __MAKE_CONF=/etc/make.conf SRCCONF=/etc/src.conf SRC_ENV_CONF=/etc/src-env.conf According src.conf(5) there are few items that are supposed to be defined in /etc/src-env.conf instead of /etc/src.conf -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)
> On 26 Sep 2016, at 17:10, Andriy Voskoboinyk <a...@freebsd.org> wrote: > > Mon, 26 Sep 2016 23:02:15 +0300 було написано Renato Botelho > <ga...@freebsd.org>: > > No, warnings are for 'untested' parts (although I think they are not the > reason...) > > Can you send messages.log when > dev.rtwn.0.debug=0x829f > is set? Sure, here it is rtwn0: port 0x4000-0x40ff mem 0xf1c0-0xf1c03fff at device 0.0 on pci2 rtwn0: r92ce_attach: warning: hardware crypto enabled rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R wlan0: Ethernet address: e0:06:e6:c7:54:73 rtwn0: r92ce_post_init: warning: net80211 ratectl is used rtwn0: rtwn_raw_xmit: called; m 0xf80010f7e700, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 10FF46E8 (64: ), next: 050B0E40 (64: ), rsvd: rtwn0: rtwn_pci_intr: status , tx_rings 0008 rtwn0: rtwn_pci_tx_done: qid 3, last 56, cur 57 rtwn0: rtwn_raw_xmit: called; m 0xf80010f7e700, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 10FF46E8 (64: ), next: 050B0E80 (64: ), rsvd: rtwn0: rtwn_pci_intr: status , tx_rings 0008 rtwn0: rtwn_pci_tx_done: qid 3, last 57, cur 58 rtwn0: rtwn_raw_xmit: called; m 0xf80038177400, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 381BD6E8 (64: ), next: 050B0EC0 (64: ), rsvd: rtwn0: rtwn_pci_intr: status , tx_rings 0008 rtwn0: rtwn_pci_tx_done: qid 3, last 58, cur 59 rtwn0: rtwn_raw_xmit: called; m 0xf80038477900, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 384EA6E8 (64: ), next: 050B0F00 (64: ), rsvd: rtwn0: rtwn_pci_intr: status , tx_rings 0008 rtwn0: rtwn_pci_tx_done: qid 3, last 59, cur 60 rtwn0: rtwn_raw_xmit: called; m 0xf80010f7e700, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 10FF46E8 (64: ), next: 050B0F40 (64: ), rsvd: rtwn0: rtwn_pci_intr: status , tx_rings 0008 rtwn0: rtwn_pci_tx_done: qid 3, last 60, cur 61 rtwn0: rtwn_raw_xmit: called; m 0xf80038055000, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 3809BEE8 (64: ), next: 050B0F80 (64: ), rsvd: rtwn0: rtwn_pci_intr: status , tx_rings 0008 rtwn0: rtwn_pci_tx_done: qid 3, last 61, cur 62 rtwn0: rtwn_raw_xmit: called; m 0xf80038211200, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 382816E8 (64: ), next: 050B0FC0 (64: ), rsvd: rtwn0: rtwn_pci_intr: status , tx_rings 0008 rtwn0: rtwn_pci_tx_done: qid 3, last 62, cur 63 rtwn0: rtwn_raw_xmit: called; m 0xf80113eb7900, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 08181000 (64: ), next: 050B1000 (64: ), rsvd: rtwn0: rtwn_pci_intr: status , tx_rings 0008 rtwn0: rtwn_pci_tx_done: qid 3, last 63, cur 64 rtwn0: rtwn_raw_xmit: called; m 0xf80038212000, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 38289EE8 (64: ), next: 050B1040 (64: ), rsvd: rtwn0: rtwn_pci_intr: status , tx_rings 0008 rtwn0: rtwn_pci_tx_done: qid 3, last 64, cur 65 rtwn0: rtwn_raw_xmit: called; m 0xf80038206700, ni 0xfe0015226000 rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 , 3 (seq ), 4 0180, 5 1F00, 6 , size 002A, pad , addr: 382306E8 (64: ), next: 050B1080 (64: ), rsvd: rt
Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)
> On 26 Sep 2016, at 16:53, Andriy Voskoboinyk <a...@freebsd.org> wrote: > > Mon, 26 Sep 2016 22:46:58 +0300 було написано Renato Botelho > <ga...@freebsd.org <mailto:ga...@freebsd.org>>: > > AFAIK, it is not critical (at least for USB devices). > > If it won't work without firmware try to install it from > sys/modules/rtwnfw/rtwnrtl8192cEB (and restart the interface). I’ve built and loaded it and the error is gone. But ‘list scan’ never show anything and I got this warning, not sure if it’s relevant rtwn0: port 0x4000-0x40ff mem 0xf1c0-0xf1c03fff at device 0.0 on pci2 rtwn0: r92ce_attach: warning: hardware crypto enabled rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R wlan0: Ethernet address: e0:06:e6:c7:54:73 rtwn0: r92ce_post_init: warning: net80211 ratectl is used Thanks -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)
> On 1 Sep 2016, at 13:29, Andriy Voskoboinyk <a...@freebsd.org> wrote: > > Hi everyone, > > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged into a > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is > available on https://github.com/s3erios/rtwn repository. Among bugfixes / > code deduplication, there some new features too: > > 1) multi-vap support (one any wireless interface + one STA interface + > any number of monitor mode interfaces). > 2) few new sysctls: > * dev.rtwn.#.crypto - controls how to use hardware crypto acceleration > * dev.rtwn.#.ratectl_selected > * dev.rtwn.#.ratectl - selects current 'rate control' algorithm > (currently only 'none' and 'net80211' are supported; RTL8192CE needs testing > with the last). > 3) (incomplete) power management support for RTL8188EU (requires firmware). > 4) Short Guard Interval support. > > It's known to work with RTL8188CUS, RTL8188EU and RTL8821AU; however, > it was never tested with RTL8192CE or RTL8812AU. > > How-to-build: > 1) download / checkout the repository. > 2) apply 'patch-usbdevs.diff' against '/usr/src' > 3) build and install rtwn module: > cd $repository/sys/modules/rtwn && make && make install > 4) build and install rtwn_usb/rtwn_pci: > cd ../rtwn_usb && make && make install > cd ../rtwn_pci && make && make install > 5) unload previous && load current drivers: > kldunload if_urtwn if_rtwn > kldload /boot/modules/if_rtwn.ko /boot/modules/if_rtwn_usb.ko > /boot/modules/if_rtwn_pci.ko > 6) Use. I have a Thinkpad T430 with a PCIe RTL8188CE. It fails waying I didn’ t load a firmware that doesn’ t exist: rtwn0: port 0x4000-0x40ff mem 0xf1c0-0xf1c03fff at device 0.0 on pci2 rtwn0: r92ce_attach: warning: hardware crypto enabled rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R wlan0: Ethernet address: e0:06:e6:c7:54:73 rtwn-rtl8192cfwE_B: could not load firmware image, error 2 rtwn0: failed loadfirmware of file rtwn-rtl8192cfwE_B I’ve loaded rtwn-rtl8192cfwU_B.ko, never heard of rtwn-rtl8192cfwE_B.ko -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Going to 11-STABLE
> On Aug 23, 2016, at 11:30, Ricardo Campos Passanezi <ri...@ige.unicamp.br> > wrote: > > Hello all. > > I'm using an old 11-CURRENT (FreeBSD 11.0-CURRENT #2 r293335) and with > the relase date for 11 getting closer, I'd like to go to 11-STABLE. > > I had the "URL: svn://svn.freebsd.org/base/head" under /usr/src and > switched to "URL: svn://svn.freebsd.org/base/stable/11". > > Is this the right way to go (after the svn ends, i'll make buildworld, > make buildkernel, and so on)? Just to be sure... > > Thanks in advance, Yes, it’s correct -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error building kernel WITH_META_MODE=yes
> On Jun 17, 2016, at 15:38, Renato Botelho <ga...@freebsd.org> wrote: > >> On Jun 17, 2016, at 15:36, Bryan Drewery <bdrew...@freebsd.org> wrote: >> >> On 6/17/2016 10:28 AM, Renato Botelho wrote: >>> Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/ia32_genassym.o >>> In file included from :312: >>> :4:10: fatal error: 'opt_global.h' file not found >>> #include "opt_global.h" >>>^ >>> 1 error generated. >>> *** [ia32_genassym.o] Error code 1 >>> >>> bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC-NODEBUG >> >> There's a handful of genassym files that are lacking opt_global.h as a >> dependency. This is more of a FAST_DEPEND failure. It's interesting it >> is only now coming up. > > I moved /usr/obj to other place and did a buildkernel without meta mode and > without any option in src.conf and it worked. > > Now after I got the system updated (it was a fresh install of ALPHA2), I’m > starting to build it again with meta mode and all desired options. Lets see > what happens this time. After that I managed to build everything using the same src*.conf, no more problems so far. -- Renato Botelho signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Error building kernel WITH_META_MODE=yes
> On Jun 17, 2016, at 15:36, Bryan Drewery <bdrew...@freebsd.org> wrote: > > On 6/17/2016 10:28 AM, Renato Botelho wrote: >> Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/ia32_genassym.o >> In file included from :312: >> :4:10: fatal error: 'opt_global.h' file not found >> #include "opt_global.h" >> ^ >> 1 error generated. >> *** [ia32_genassym.o] Error code 1 >> >> bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC-NODEBUG > > There's a handful of genassym files that are lacking opt_global.h as a > dependency. This is more of a FAST_DEPEND failure. It's interesting it > is only now coming up. I moved /usr/obj to other place and did a buildkernel without meta mode and without any option in src.conf and it worked. Now after I got the system updated (it was a fresh install of ALPHA2), I’m starting to build it again with meta mode and all desired options. Lets see what happens this time. -- Renato Botelho signature.asc Description: Message signed with OpenPGP using GPGMail
Error building kernel WITH_META_MODE=yes
k/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/kern.post.mk /usr/src/sys/conf/kern.mk' .PATH='. /usr/obj/usr/src/sys/GENERIC-NODEBUG' 1 error bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC-NODEBUG .ERROR_TARGET='ia32_genassym.o' .ERROR_META_FILE='/usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/ia32_genassym.o.meta' .MAKE.LEVEL='2' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose curdirOk=yes' .CURDIR='/usr/obj/usr/src/sys/GENERIC-NODEBUG' .MAKE='/usr/obj/usr/src/make.amd64/bmake' .OBJDIR='/usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG' .TARGETS='all' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/usr/obj' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20160606' PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/usr/src' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/obj/usr/src/sys/GENERIC-NODEBUG/Makefile /usr/src/sys/conf/kern.pre.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/kern.post.mk /usr/src/sys/conf/kern.mk' .PATH='. /usr/obj/usr/src/sys/GENERIC-NODEBUG' *** [buildkernel] Error code 2 bmake[1]: stopped in /usr/src .ERROR_TARGET='buildkernel' .ERROR_META_FILE='' .MAKE.LEVEL='1' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' .CURDIR='/usr/src' .MAKE='/usr/obj/usr/src/make.amd64/bmake' .OBJDIR='/usr/src/obj' .TARGETS='buildkernel' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/usr/obj' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20160606' PATH='/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/obj/usr/src' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/Makefile.inc1 /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/Makefile.libcompat /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk' .PATH='. /usr/src' 1 error bmake[1]: stopped in /usr/src .ERROR_TARGET='buildkernel' .ERROR_META_FILE='' .MAKE.LEVEL='1' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' .CURDIR='/usr/src' .MAKE='/usr/obj/usr/src/make.amd64/bmake' .OBJDIR='/usr/src/obj' .TARGETS='buildkernel' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/usr/obj' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20160606' PATH='/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/obj/usr/src' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/Makefile.inc1 /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/Makefile.libcompat /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk' .PATH='. /usr/src' *** [buildkernel] Error code 2 make: stopped in /usr/src .ERROR_TARGET='buildkernel' .ERROR_META_FILE='' .MAKE.LEVEL='0' MAKEFILE='' .MAKE.MODE='normal' .CURDIR='/usr/src' .MAKE='make' .OBJDIR='/usr/src/obj' .TARGETS='buildkernel' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/usr/obj' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20160512' PATH='/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/obj/usr/src' 1 error make: stopped in /usr/src .ERROR_TARGET='buildkernel' .ERROR_META_FILE='' .MAKE.LEVEL='0' MAKEFILE='' .MAKE.MODE='normal' .CURDIR='/usr/src' .MAKE='make' .OBJDIR='/usr/src/obj' .TARGETS='buildkernel' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/usr/obj' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20160512' PATH='/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/obj/usr/sr -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.
Re: 11.0-RELEASE pkg base & base.txz file
> On Apr 20, 2016, at 03:54, krad <kra...@gmail.com> wrote: > > will it still be buildable though from source? Yes -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: objcopy exit with signal 10 trying to update to recent -CURRENT
> On Apr 18, 2016, at 10:59, Renato Botelho do Couto <ren...@netgate.com> wrote: > > I’m trying to upgrade a -CURRENT amd64 installation from r297492 to r298203 > and got: > > c++ -O2 -pipe > -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/include > -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/tools/clang/include > -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/utils/TableGen > -I. > -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/../../lib/clang/include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -fno-strict-aliasing > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" > -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -g -Qunused-arguments > -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions > -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -static > -L/usr/obj/usr/src/tmp/legacy/usr/lib -o llvm-tblgen.full > AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o Attributes.o > CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o > CodeGenInstruction.o CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o > CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.o DAGISelMatcherEmitter.o > DAGISelMatcherGen.o DAGISelMatcherOpt.o DFAPacketizerEmitter.o > DisassemblerEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o > InstrInfoEmitter.o IntrinsicEmitter.o OptParserEmitter.o > PseudoLoweringEmitter.o RegisterInfoEmitter.o SubtargetEmitter.o TableGen.o > X86DisassemblerTables.o X86ModRMFilters.o X86RecognizableInstr.o > /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/llvm-tblgen/../../../lib/clang/libllvmtablegen/libllvmtablegen.a > > /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/llvm-tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a > -lncursesw -lpthread -legacy > objcopy --only-keep-debug llvm-tblgen.full llvm-tblgen.debug > objcopy --strip-debug --add-gnu-debuglink=llvm-tblgen.debug llvm-tblgen.full > llvm-tblgen > *** Signal 10 > > I’ve already tried a fresh build after remove /usr/obj, same problem. Any > ideas? Fixed after I manually rebuilt usr.bin/elfcopy -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
objcopy exit with signal 10 trying to update to recent -CURRENT
I’m trying to upgrade a -CURRENT amd64 installation from r297492 to r298203 and got: c++ -O2 -pipe -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/utils/TableGen -I. -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -g -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o llvm-tblgen.full AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o Attributes.o CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenInstruction.o CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o DFAPacketizerEmitter.o DisassemblerEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o OptParserEmitter.o PseudoLoweringEmitter.o RegisterInfoEmitter.o SubtargetEmitter.o TableGen.o X86DisassemblerTables.o X86ModRMFilters.o X86RecognizableInstr.o /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/llvm-tblgen/../../../lib/clang/libllvmtablegen/libllvmtablegen.a /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/llvm-tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a -lncursesw -lpthread -legacy objcopy --only-keep-debug llvm-tblgen.full llvm-tblgen.debug objcopy --strip-debug --add-gnu-debuglink=llvm-tblgen.debug llvm-tblgen.full llvm-tblgen *** Signal 10 I’ve already tried a fresh build after remove /usr/obj, same problem. Any ideas? -- Renato Botelho do Couto Software Engineer Netgate, Inc. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP][CFT] pkgng beta1^6 is out
FreeBSD murphys.ramenzoni.com.br 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r231691: Tue Feb 14 15:51:35 BRST 2012 r...@murphys.ramenzoni.com.br:/usr/obj/usr/src/sys/MURPHYS i386 On Wed, Feb 15, 2012 at 8:57 PM, Baptiste Daroussin b...@freebsd.org wrote: On Wed, Feb 15, 2012 at 08:53:42PM -0200, Renato Botelho wrote: On Wed, Feb 15, 2012 at 3:50 PM, Baptiste Daroussin b...@freebsd.org wrote: beta6 is now out with the following changes: * pkg register: now run inside a transaction, this speeds up things a lot (thanks avg) * pkg version: -v now print name-version to match behaviour of legacy pkg_version * pkg register: fix flatsize calculation * new pkg-updating(1) man page (thanks beat) if you are upgrading from previous version you migh discover the weird value the the disk space saved or required for some operation, this is just because a bug in previous version was always calculating each package flatsize as 0 B, this is now fixed. Hello Bapt, I tried to build it on a recent current and got these errors: FreeBSD murphys.ramenzoni.com.br 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r231691: Tue Feb 14 15:51:35 BRST 2012 r...@murphys.ramenzoni.com.br:/usr/obj/usr/src/sys/MURPHYS i386 root@murphys:/root# make -C /usr/ports/ports-mgmt/pkg install clean === License BSD accepted by the user = pkg-1.0-beta6.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/portmgr/pkg-1.0-beta6.tar.bz2 pkg-1.0-beta6.tar.bz2 100% of 1434 kB 108 kBps 00m00s === Extracting for pkg-1.0.b6 = SHA256 Checksum OK for pkg-1.0-beta6.tar.bz2. === Patching for pkg-1.0.b6 === Configuring for pkg-1.0.b6 === FreeBSD 10 autotools fix applied to /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/aclocal.m4 === FreeBSD 10 autotools fix applied to /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/configure === Building for pkg-1.0.b6 === external (all) === external/sqlite (all) Warning: Object directory not changed from original /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/sqlite cc -O2 -pipe -fno-strict-aliasing -fPIC -DSQLITE_OMIT_AUTOVACUUM -DSQLITE_OMIT_BLOB_LITERAL -DSQLITE_OMIT_COMPLETE -DSQLITE_OMIT_DECLTYPE -DSQLITE_OMIT_DEPRECATED -DSQLITE_OMIT_EXPLAIN -DSQLITE_OMIT_GET_TABLE -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_OMIT_PROGRESS_CALLBACK -DSQLITE_OMIT_TCL_VARIABLE -DSQLITE_OMIT_UTF16 -DSQLITE_OMIT_CAT -DSQLITE_OMIT_CHECK -DSQLITE_OMIT_AUTOINIT -DSQLITE_OMIT_COMPILEOPTION_DIAGS -DSQLITE_OMIT_INTEGRITY_CHECK -DSQLITE_OMIT_BUILTIN_TEST -DSQLITE_OMIT_SHARED_CACHE -DUSE_PREAD -DSQLITE_THREADSAFE=1 -DSQLITE_TEMP_STORE=3 -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c sqlite3.c -o sqlite3.o building static sqlite3 library ranlib libsqlite3.a === external/libyaml (all) Warning: Object directory not changed from original /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml cc -O2 -pipe -fno-strict-aliasing -fPIC -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/include -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml -DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/src/api.c -o api.o cc -O2 -pipe -fno-strict-aliasing -fPIC -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/include -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml -DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/src/dumper.c -o dumper.o cc -O2 -pipe -fno-strict-aliasing -fPIC -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/include -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml -DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/src/emitter.c -o emitter.o cc -O2 -pipe -fno-strict-aliasing -fPIC -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/include -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml -DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/src/loader.c -o loader.o cc -O2 -pipe -fno-strict-aliasing -fPIC -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/include -I/usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml -DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/external/libyaml/src/parser.c -o parser.o cc -O2 -pipe -fno-strict-aliasing -fPIC -I/usr/ports/ports-mgmt/pkg
Re: [HEADSUP][CFT] pkgng beta1^6 is out
for 'isblank_l' /usr/include/xlocale/_ctype.h:112: warning: no previous prototype for 'iscntrl_l' /usr/include/xlocale/_ctype.h:113: warning: no previous prototype for 'isdigit_l' /usr/include/xlocale/_ctype.h:114: warning: no previous prototype for 'isgraph_l' /usr/include/xlocale/_ctype.h:115: warning: no previous prototype for 'ishexnumber_l' /usr/include/xlocale/_ctype.h:116: warning: no previous prototype for 'isideogram_l' /usr/include/xlocale/_ctype.h:117: warning: no previous prototype for 'islower_l' /usr/include/xlocale/_ctype.h:118: warning: no previous prototype for 'isnumber_l' /usr/include/xlocale/_ctype.h:119: warning: no previous prototype for 'isphonogram_l' /usr/include/xlocale/_ctype.h:120: warning: no previous prototype for 'isprint_l' /usr/include/xlocale/_ctype.h:121: warning: no previous prototype for 'ispunct_l' /usr/include/xlocale/_ctype.h:122: warning: no previous prototype for 'isrune_l' /usr/include/xlocale/_ctype.h:123: warning: no previous prototype for 'isspace_l' /usr/include/xlocale/_ctype.h:124: warning: no previous prototype for 'isspecial_l' /usr/include/xlocale/_ctype.h:125: warning: no previous prototype for 'isupper_l' /usr/include/xlocale/_ctype.h:126: warning: no previous prototype for 'isxdigit_l' /usr/include/xlocale/_ctype.h:164: warning: no previous prototype for 'digittoint_l' /usr/include/xlocale/_ctype.h:167: warning: no previous prototype for 'tolower_l' /usr/include/xlocale/_ctype.h:174: warning: no previous prototype for 'toupper_l' In file included from /usr/include/wctype.h:93, from pkg_manifest.c:6: /usr/include/xlocale/_ctype.h:48: warning: redundant redeclaration of '___runetype_l' /usr/include/xlocale/_ctype.h:48: warning: previous declaration of '___runetype_l' was here /usr/include/xlocale/_ctype.h:49: warning: redundant redeclaration of '___tolower_l' /usr/include/xlocale/_ctype.h:49: warning: previous declaration of '___tolower_l' was here /usr/include/xlocale/_ctype.h:50: warning: redundant redeclaration of '___toupper_l' /usr/include/xlocale/_ctype.h:50: warning: previous declaration of '___toupper_l' was here /usr/include/xlocale/_ctype.h:51: warning: redundant redeclaration of '__runes_for_locale' /usr/include/xlocale/_ctype.h:51: warning: previous declaration of '__runes_for_locale' was here /usr/include/xlocale/_ctype.h:109: warning: no previous prototype for 'iswalnum_l' /usr/include/xlocale/_ctype.h:110: warning: no previous prototype for 'iswalpha_l' /usr/include/xlocale/_ctype.h:111: warning: no previous prototype for 'iswblank_l' /usr/include/xlocale/_ctype.h:112: warning: no previous prototype for 'iswcntrl_l' /usr/include/xlocale/_ctype.h:113: warning: no previous prototype for 'iswdigit_l' /usr/include/xlocale/_ctype.h:114: warning: no previous prototype for 'iswgraph_l' /usr/include/xlocale/_ctype.h:115: warning: no previous prototype for 'iswhexnumber_l' /usr/include/xlocale/_ctype.h:116: warning: no previous prototype for 'iswideogram_l' /usr/include/xlocale/_ctype.h:117: warning: no previous prototype for 'iswlower_l' /usr/include/xlocale/_ctype.h:118: warning: no previous prototype for 'iswnumber_l' /usr/include/xlocale/_ctype.h:119: warning: no previous prototype for 'iswphonogram_l' /usr/include/xlocale/_ctype.h:120: warning: no previous prototype for 'iswprint_l' /usr/include/xlocale/_ctype.h:121: warning: no previous prototype for 'iswpunct_l' /usr/include/xlocale/_ctype.h:122: warning: no previous prototype for 'iswrune_l' /usr/include/xlocale/_ctype.h:123: warning: no previous prototype for 'iswspace_l' /usr/include/xlocale/_ctype.h:124: warning: no previous prototype for 'iswspecial_l' /usr/include/xlocale/_ctype.h:125: warning: no previous prototype for 'iswupper_l' /usr/include/xlocale/_ctype.h:126: warning: no previous prototype for 'iswxdigit_l' /usr/include/xlocale/_ctype.h:131: warning: no previous prototype for 'towlower_l' /usr/include/xlocale/_ctype.h:138: warning: no previous prototype for 'towupper_l' /usr/include/xlocale/_ctype.h:146: warning: no previous prototype for '__wcwidth_l' *** [pkg_manifest.o] Error code 1 Stop in /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6/libpkg. *** [all] Error code 1 Stop in /usr/ports/ports-mgmt/pkg/work/pkg-1.0-beta6. *** [do-build] Error code 1 Stop in /usr/ports/ports-mgmt/pkg. [1]97410 exit 1 make -C /usr/ports/ports-mgmt/pkg install clean make -C /usr/ports/ports-mgmt/pkg install clean 33.86s user 1.48s system 61% cpu 57.212 total -- 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
Re: Apropos Removal of sysinstall
On Thu, Dec 29, 2011 at 5:10 AM, Peter J. Cherny pet...@luddite.com.au wrote: Rather than hijack the previous thread, it's probably time to make a few comments on the current and future installation and use of ZFS FreeBSD. I've used both Solaris and FreeBSD since nearly day one for both OSs, so have a deal of familiarity in their use. I believe removal of sysinstall exposes the community's blindness to a major parts of it's future, ZFS root. Other than following arcane recipes, the only way to create a system with ZFS root is by using Martin Matuška's excellent mfsboot images. IIRC, PCBSD installer can install a regular FreeBSD on ZFS. -- 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
Re: Clang error make buildworld
On Tue, May 3, 2011 at 10:07 PM, Manfred Antar n...@pozo.com wrote: I get this error when trying to buildworld on current i386. It's been this way for awhile Any Ideas ? === boot/i386/boot0 (all) clang -O2 -pipe -DVOLUME_SERIAL -DPXE -DFLAGS=0x8f -DTICKS=0xb6 -DCOMSPEED=7 5 + 3 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99 -c /usr/src/sys/boot/i386/boot0/boot0.S clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' /tmp/cc-4SXZt8.s:42:11: error: .code16 not supported yet .code16 # This runs in real mode ^ /tmp/cc-4SXZt8.s:313:3: error: unknown use of instruction mnemonic without a size suffix jmp *%bx # Invoke bootstrap ^ /tmp/cc-4SXZt8.s:346:3: error: invalid operand for instruction retw # To caller ^ /tmp/cc-4SXZt8.s:372:3: error: invalid operand for instruction retw # To caller ^ *** Error code 1 Stop in /usr/src/sys/boot/i386/boot0. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. Hello Manfred, I'm having this same issue on a i386 HEAD buildworld with clang. Did you find a fix for this? For now i built boot0 with gcc and it was built fine. Regards -- 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
Re: Clang error make buildworld
On Wed, Dec 28, 2011 at 2:26 PM, Dimitry Andric d...@freebsd.org wrote:
On 2011-12-28 16:44, Renato Botelho wrote:
On Tue, May 3, 2011 at 10:07 PM, Manfred Antarn...@pozo.com wrote:
I get this error when trying to buildworld on current i386.
It's been this way for awhile Any Ideas ?
=== boot/i386/boot0 (all)
clang -O2 -pipe -DVOLUME_SERIAL -DPXE -DFLAGS=0x8f -DTICKS=0xb6
-DCOMSPEED=7 5 + 3 -ffreestanding -mpreferred-stack-boundary=2
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99
-c /usr/src/sys/boot/i386/boot0/boot0.S
clang: warning: argument unused during compilation:
'-mpreferred-stack-boundary=2'
/tmp/cc-4SXZt8.s:42:11: error: .code16 not supported yet
.code16 # This runs in real mode
^
This is expected, since the above command line is supposed to have
'-no-integrated-as' added. For some reason, the test for clang in
sys/boot/i386/boot0/Makefile is not working as it should.
Most likely, it is due to the way you set CC, CXX and/or CPP in
make.conf. Can you please post that file?
Sure, follow my src.conf:
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP=clang-cpp
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
NO_FSCHG=
and my make.conf
KERNCONF=MURPHYS
WITH_OPTIONS=yes
WITH_VIM_OPTIONS=yes
WITHOUT_X11=yes
# added by use.perl 2011-12-12 13:19:26
PERL_VERSION=5.12.4
More information about the system installed on this machine:
garga@murphys:~ uname -a
FreeBSD murphys.ramenzoni.com.br 9.0-RC3 FreeBSD 9.0-RC3 #0: Sun Dec
4 08:01:02 UTC 2011
r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
garga@murphys:~ clang -v
FreeBSD clang version 3.0 (branches/release_30 142614) 20111021
Target: i386-unknown-freebsd9.0
Thread model: posix
--
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
Re: Clang error make buildworld
On Wed, Dec 28, 2011 at 2:39 PM, Dimitry Andric d...@freebsd.org wrote:
On 2011-12-28 17:32, Renato Botelho wrote:
On Wed, Dec 28, 2011 at 2:26 PM, Dimitry Andricd...@freebsd.org wrote:
...
Most likely, it is due to the way you set CC, CXX and/or CPP in
make.conf. Can you please post that file?
Sure, follow my src.conf:
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP=clang-cpp
.endif
This part should go into make.conf, *not* src.conf. If you want to use
clang only for src, not for anything else, put:
.if ${.CURDIR:M/usr/src*} || ${.CURDIR:M/usr/obj*}
# [... set CC, etc here... ]
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
NO_FSCHG=
This is fine to have in src.conf.
Worked like a charm. Thanks!!
--
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
Re: [clang] OpenOffice does not work with clang-compiled libgcc_s.so.1
On Wed, Jul 27, 2011 at 7:19 AM, Alexey Shuvaev
shuv...@physik.uni-wuerzburg.de wrote:
Hello list!
I have decided that clang in mature enough to give it a try on a main
desktop. Everything is working fine except OpenOffice. The problem was
already reported [1] and even analyzed [2]. Although the OP has reported [3]
that since r218915 he has no problems anymore, I still have :(
Note, that according to [4] it seems it was not specifically fixed upstream.
So, if I compile the whole world (and kernel) with clang, soffice.bin
dumps core. If I recompile the world with gcc and replace /lib/libgcc_s.so.1
with the new one, OpenOffice works fine again. Here are some information
about the system that may be useful:
~ uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-BETA1 FreeBSD 9.0-BETA1 #0 r224414: Tue Jul
26 16:00:43 CEST 2011
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC amd64
~ gcc --version
gcc (GCC) 4.2.2 20070831 prerelease [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
~ clang --version
FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: x86_64-unknown-freebsd9.0
Thread model: posix
~ cat /etc/make.conf
SUP_UPDATE= YES
PORTSSUPFILE= /root/ports-supfile
DOCSUPFILE= /root/doc-supfile
DOC_LANG= en_US.ISO8859-1
.if ${.CURDIR:M*/usr/ports*}
.include /etc/ports.conf
.endif
# Building base with clang
.if ${.CURDIR:M*/usr/src*}
.if !defined(CC) || ${CC} == cc
CC= clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX= clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP= clang -E
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
.endif
# added by use.perl 2011-07-18 17:50:51
PERL_VERSION=5.14.1
I don't have much time recently, so any further debugging will be on a
best effort basis. Anyway I thought it is better to post it here, so
it won't be just lost. If necessary I can file a PR about it.
Hello,
I had a similar problem in the past, but IIRC after rebuild openoffice
it started to work again. The machine where it happened is not
available anymore.
Regards
--
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
Re: Can't buildworld since Clang update
On Wed, Feb 23, 2011 at 10:22 AM, datastream datastream.freecity
datastream.freec...@gmail.com wrote:
I deleted all files in /usr/src and /usr/obj. it changes nothing, i still
get same error.
In /etc/make.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=
STRIP=
CFLAGS+=-fno-omit-frame-pointer
I'm not having problems here, my /etc/make.conf contains:
.if ${.CURDIR:N*usr/src*}==
. if !defined(CC) || ${CC} == cc
CC=clang
. endif
. if !defined(CXX) || ${CXX} == c++
CXX=clang++
. endif
# Don't die on warnings
NO_WERROR=
WERROR=
.endif
And my /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=
It's building fine with clang.
--
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
Re: Error building world after last clang update
On Mon, Feb 21, 2011 at 12:34 PM, Renato Botelho rbga...@gmail.com wrote:
I was trying to upgrade my 9.0-CURRENT amd64 after clang
was updated, but i got following error:
=== sys/boot/i386/cdboot (all)
=== sys/boot/i386/gptboot (all)
=== sys/boot/i386/kgzldr (all)
=== sys/boot/i386/libi386 (all)
clang -O2 -pipe -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600
-DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU
-Dalloca=__builtin_alloca
-I/usr/src/sys/boot/i386/libi386/../../common
-I/usr/src/sys/boot/i386/libi386/../btx/lib
-I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include
-I/usr/src/sys/boot/i386/libi386/../../.. -I.
-I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/
-ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99
-c /usr/src/sys/boot/i386/libi386/amd64_tramp.S
clang: warning: argument unused during compilation:
'-mpreferred-stack-boundary=2'
/tmp/cc-ohEeiE.s:35:9: error: .code32 not supported yet
.code32
^
/tmp/cc-ohEeiE.s:69:9: error: .code64 not supported yet
.code64
^
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
[1] 94534 exit 2 nice -n 15 make -j1 buildworld buildkernel
My /etc/src.conf has:
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
Any hints?
I read the answer for a problem like this and followed
the suggestion of add clang config lines on /etc/make.conf.
It worked fine, it's building again now.
--
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
Error building world after last clang update
I was trying to upgrade my 9.0-CURRENT amd64 after clang
was updated, but i got following error:
=== sys/boot/i386/cdboot (all)
=== sys/boot/i386/gptboot (all)
=== sys/boot/i386/kgzldr (all)
=== sys/boot/i386/libi386 (all)
clang -O2 -pipe -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600
-DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU
-Dalloca=__builtin_alloca
-I/usr/src/sys/boot/i386/libi386/../../common
-I/usr/src/sys/boot/i386/libi386/../btx/lib
-I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include
-I/usr/src/sys/boot/i386/libi386/../../.. -I.
-I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/
-ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99
-c /usr/src/sys/boot/i386/libi386/amd64_tramp.S
clang: warning: argument unused during compilation:
'-mpreferred-stack-boundary=2'
/tmp/cc-ohEeiE.s:35:9: error: .code32 not supported yet
.code32
^
/tmp/cc-ohEeiE.s:69:9: error: .code64 not supported yet
.code64
^
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
[1]94534 exit 2 nice -n 15 make -j1 buildworld buildkernel
My /etc/src.conf has:
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
Any hints?
--
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
Re: Openoffice doesn't work with kernel+world built with Clang
On Wed, Nov 3, 2010 at 1:05 PM, Renato Botelho rbga...@gmail.com wrote:
On Wed, Nov 3, 2010 at 12:44 PM, Ed Schouten e...@80386.nl wrote:
* Renato Botelho rbga...@gmail.com, 20101103 15:36:
On Wed, Nov 3, 2010 at 11:44 AM, Ed Schouten e...@80386.nl wrote:
Garga!
* Renato Botelho rbga...@gmail.com, 20101103 13:36:
For now i solve my problem adding this to /etc/src.conf
.if ${.CURDIR} == /usr/src/gnu/lib/libgcc
CC=cc
CXX=c++
.endif
This way libgcc_s.so is built using gcc instead of clang and the problem
is gone. I just wonder other problems we can find since simething on
libgcc_s.so is broken when built with clang.
Would it be hard to figure out which exact object file causes this?
Hi Ed,
I've submitted a ktrace result of openoffice execution [1], i just
saw it got a SIGBUS at some point, but debug openoffice doesn't
seem to be a trivial task.
I don't know if we can build OO with debug symbols to make it
easier to debug. If you know what i can do to help debugging,
just let me know and i can provide any information.
Well, I mean, can you build some of libgcc's object files with Clang and
others with GCC? Hint: Just build everything with GCC. Afterwards, go
into the object directory, rm some of the .o files and make CC=clang.
Since OOo is a C++ application, I suspect the unwind-related object
files to be the culprit.
Bingo! When I build everything but unwind-dw2.o with clang it works.
This is the object that is causing the problem.
FYI, after upgrade it today to r218915, and remove the hack to
build libgcc with gcc instead of clang, the problem is gone. Now
my world + kernel are both 100% built with clang and i can start
openoffice as well.
--
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
Re: Syscons and termcap
On Tue, Nov 9, 2010 at 5:13 PM, Ed Schouten e...@80386.nl wrote: * Renato Botelho rbga...@gmail.com, 20101109 19:12: It had no effect on console but, i don't know why, screwed up my Xorg keymap, some meta keys (Mod4) stop working even if I run a setxkbmap like this: Oh yes. d'oh! I forgot that that specific input path is used by both the console and the raw keyboard interface used by Xorg. I've updated the patch to only emit UTF-8 when using K_XLATE keyboard mode, which is used on the console. http://80386.nl/pub/syscons-utf8.txt Now Xorg is working properly, but it has no effect on console. I'm using cp437 fonts and us.iso.kbd -- 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
Re: Syscons and termcap
On Tue, Nov 9, 2010 at 8:03 AM, Ed Schouten e...@80386.nl wrote: Hello Eir, * Eir Nym eir...@gmail.com, 20101109 05:10: I've compiled -CURRENT kernel with UTF-8 and CONS25 support. ( r214751 ) in xterm emulation mode I have problems with bindings for some keys, such as Home If I start vis(1) and press Home, I always get ^[[H sequence instead of ^[OH which is defined in termcap (5) file. I get correct results after switching to cons25. What do I wrong ? Does sc(4) driver in current correctly support xterm-like key bindings? Yes, but not only must you set TERM=xterm, you must also remove TEKEN_CONS25 from your kernel configuration or run vidcontrol -T xterm on that specific window. There is almost no reason why anyone would want to use the TEKEN_CONS25 option. Depending on whether the terminal is switched to cursor keys mode, it will return ^[[H or ^[OH. See /sys/teken/teken.c, teken_get_sequence(). Hi Ed, Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg environment, and after reading this I decided to make a test. I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel config, and after configure my syscons to use cp850-* fonts i can see UTF-8 chars properly \o/ The only thing i cannot do here is to type chars with accent like áé on console, because it seems to don't respect deadkeys, when I press ' the char ' is show and never wait the next char to compose a new one when necessary. Is it a knwon issue or i'm doing something wrong? I'm using us.iso.kbd Regards -- 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
Re: Syscons and termcap
On Tue, Nov 9, 2010 at 3:45 PM, Ed Schouten e...@80386.nl wrote: * Renato Botelho rbga...@gmail.com, 20101109 17:08: Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg environment, and after reading this I decided to make a test. I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel config, and after configure my syscons to use cp850-* fonts i can see UTF-8 chars properly \o/ Well, the point here is that it just performs some really hackish translation to CP437, not CP850, on the output path. It is really not robust. Copy-pasting is also broken because of it, because it pastes CP437 characters. OK, i changed my fonts to cp437. The only thing i cannot do here is to type chars with accent like áé on console, because it seems to don't respect deadkeys, when I press ' the char ' is show and never wait the next char to compose a new one when necessary. Is it a knwon issue or i'm doing something wrong? This is a known issue, since there is no translation from Unicode code points to UTF-8 sequences. In other words, if you press ë, the keyboard layer will properly send a 235 to Syscons, but instead of encoding it as 0xC3 0xA9, will just emit a single byte, having value 0xE9. Maybe a patch like this could already get that working, but it's just a quick hack. http://80386.nl/pub/syscons-utf8.txt It had no effect on console but, i don't know why, screwed up my Xorg keymap, some meta keys (Mod4) stop working even if I run a setxkbmap like this: /usr/local/bin/setxkbmap -rules xorg -symbols pc(pc105)+sun_vndr/usb(sun_usb)+pc(pc105)+us(intl) Now i back old kernel and everything is working fine. It's not something I need, but would be nice to have console working with UTF-8 and accent keys :) -- 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
Re: utmpx
On Fri, Nov 5, 2010 at 10:09 AM, Ed Schouten e...@80386.nl wrote: * Anonymous swel...@gmail.com, 20101105 12:58: There are more, see ports listed under utmpx.h in http://wiki.freebsd.org/PortsBrokenOnCurrent It should be noted that that list is a bit pessimistic, since various ports have been fixed in the mean time. Ed, I've made a patch for chkrootkit [1], it's building, but i didn't test if it's working. Could you take a look at it? [1] http://people.freebsd.org/~garga/patches/chkrootkit-utmpx.diff Regards -- 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
Re: Openoffice doesn't work with kernel+world built with Clang
On Fri, Oct 22, 2010 at 8:54 AM, Renato Botelho rbga...@gmail.com wrote:
I have a 9.0-current (r214167) amd64, kernel and world built
with clang and all ports built with gcc, and i cannot start
openoffice anymore, it shows splash, start to go up and die.
If I reinstall world+kernel built with gcc openoffice works fine.
The is a ktrace result available [1], let me know if you need
more information or tests.
For now i solve my problem adding this to /etc/src.conf
.if ${.CURDIR} == /usr/src/gnu/lib/libgcc
CC=cc
CXX=c++
.endif
This way libgcc_s.so is built using gcc instead of clang and the problem
is gone. I just wonder other problems we can find since simething on
libgcc_s.so is broken when built with clang.
--
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
Re: Openoffice doesn't work with kernel+world built with Clang
On Wed, Nov 3, 2010 at 11:44 AM, Ed Schouten e...@80386.nl wrote:
Garga!
* Renato Botelho rbga...@gmail.com, 20101103 13:36:
For now i solve my problem adding this to /etc/src.conf
.if ${.CURDIR} == /usr/src/gnu/lib/libgcc
CC=cc
CXX=c++
.endif
This way libgcc_s.so is built using gcc instead of clang and the problem
is gone. I just wonder other problems we can find since simething on
libgcc_s.so is broken when built with clang.
Would it be hard to figure out which exact object file causes this?
Hi Ed,
I've submitted a ktrace result of openoffice execution [1], i just
saw it got a SIGBUS at some point, but debug openoffice doesn't
seem to be a trivial task.
I don't know if we can build OO with debug symbols to make it
easier to debug. If you know what i can do to help debugging,
just let me know and i can provide any information.
[1] - http://people.freebsd.org/~garga/ktrace-error2.txt.gz
--
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
Re: Openoffice doesn't work with kernel+world built with Clang
On Wed, Nov 3, 2010 at 12:44 PM, Ed Schouten e...@80386.nl wrote:
* Renato Botelho rbga...@gmail.com, 20101103 15:36:
On Wed, Nov 3, 2010 at 11:44 AM, Ed Schouten e...@80386.nl wrote:
Garga!
* Renato Botelho rbga...@gmail.com, 20101103 13:36:
For now i solve my problem adding this to /etc/src.conf
.if ${.CURDIR} == /usr/src/gnu/lib/libgcc
CC=cc
CXX=c++
.endif
This way libgcc_s.so is built using gcc instead of clang and the problem
is gone. I just wonder other problems we can find since simething on
libgcc_s.so is broken when built with clang.
Would it be hard to figure out which exact object file causes this?
Hi Ed,
I've submitted a ktrace result of openoffice execution [1], i just
saw it got a SIGBUS at some point, but debug openoffice doesn't
seem to be a trivial task.
I don't know if we can build OO with debug symbols to make it
easier to debug. If you know what i can do to help debugging,
just let me know and i can provide any information.
Well, I mean, can you build some of libgcc's object files with Clang and
others with GCC? Hint: Just build everything with GCC. Afterwards, go
into the object directory, rm some of the .o files and make CC=clang.
Since OOo is a C++ application, I suspect the unwind-related object
files to be the culprit.
Bingo! When I build everything but unwind-dw2.o with clang it works.
This is the object that is causing the problem.
--
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
Openoffice doesn't work with kernel+world built with Clang
I have a 9.0-current (r214167) amd64, kernel and world built with clang and all ports built with gcc, and i cannot start openoffice anymore, it shows splash, start to go up and die. If I reinstall world+kernel built with gcc openoffice works fine. The is a ktrace result available [1], let me know if you need more information or tests. Thanks [1] - http://people.freebsd.org/~garga/ktrace.out -- 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
Re: Openoffice doesn't work with kernel+world built with Clang
On Fri, Oct 22, 2010 at 10:53 AM, Dimitry Andric d...@freebsd.org wrote: On 2010-10-22 12:54, Renato Botelho wrote: I have a 9.0-current (r214167) amd64, kernel and world built with clang and all ports built with gcc, and i cannot start openoffice anymore, it shows splash, start to go up and die. If I reinstall world+kernel built with gcc openoffice works fine. The is a ktrace result available [1], let me know if you need more information or tests. Thanks [1] - http://people.freebsd.org/~garga/ktrace.out I guess the permissions of that file are still 700? I get 403 - Forbidden. :) Fixed, sorry. -- 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
Re: Openoffice doesn't work with kernel+world built with Clang
On Fri, Oct 22, 2010 at 10:53 AM, Dimitry Andric d...@freebsd.org wrote: On 2010-10-22 12:54, Renato Botelho wrote: I have a 9.0-current (r214167) amd64, kernel and world built with clang and all ports built with gcc, and i cannot start openoffice anymore, it shows splash, start to go up and die. If I reinstall world+kernel built with gcc openoffice works fine. The is a ktrace result available [1], let me know if you need more information or tests. Thanks [1] - http://people.freebsd.org/~garga/ktrace.out I guess the permissions of that file are still 700? I get 403 - Forbidden. :) I've added a dumped version to make it easy: http://people.freebsd.org/~garga/ktrace-error.txt.gz -- 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
Re: Openoffice doesn't work with kernel+world built with Clang
On Fri, Oct 22, 2010 at 10:53 AM, Dimitry Andric d...@freebsd.org wrote: On 2010-10-22 12:54, Renato Botelho wrote: I have a 9.0-current (r214167) amd64, kernel and world built with clang and all ports built with gcc, and i cannot start openoffice anymore, it shows splash, start to go up and die. If I reinstall world+kernel built with gcc openoffice works fine. The is a ktrace result available [1], let me know if you need more information or tests. Thanks [1] - http://people.freebsd.org/~garga/ktrace.out I guess the permissions of that file are still 700? I get 403 - Forbidden. :) I ran ktrace -di to collect information of child processes, here is the result: http://people.freebsd.org/~garga/ktrace-error2.txt.gz -- 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
Re: Openoffice doesn't work with kernel+world built with Clang
On Fri, Oct 22, 2010 at 10:53 AM, Dimitry Andric d...@freebsd.org wrote: On 2010-10-22 12:54, Renato Botelho wrote: I have a 9.0-current (r214167) amd64, kernel and world built with clang and all ports built with gcc, and i cannot start openoffice anymore, it shows splash, start to go up and die. If I reinstall world+kernel built with gcc openoffice works fine. The is a ktrace result available [1], let me know if you need more information or tests. Thanks [1] - http://people.freebsd.org/~garga/ktrace.out I guess the permissions of that file are still 700? I get 403 - Forbidden. :) One more information, i found the problem is on libgcc_s.so, after build /usr/src/gnu/lib/libgcc with gcc and install openoffice back to work fine. -- 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
Re: Another clang problem
On Sun, Oct 3, 2010 at 7:34 PM, Dimitry Andric d...@freebsd.org wrote: On 2010-10-03 17:21, Dimitry Andric wrote: Since gnash has about a gazillion dependencies, and I have the idea that after 12 hours of building stuff, I will not be able to reproduce your error message anyway, could you please post it (or upload it, if it is very large)? I cannot reproduce your problem, even after installing the gazillion dependencies. :) However, gnash has the same problem that a lot of other ports have: its configure script assumes the verbose output of a linking command has a certain format. The end result is almost always a linking error hidden symbol `__dso_handle' in /usr/lib/crtbegin.o is referenced by DSO, or similar. That problem should be fixed by this patch: http://www.andric.com/freebsd/clang/graphics-gnash-clang.diff There is also a chance this might fix your issue, can you please try it out? Same problem here with this patch -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 3:43 AM, Dimitry Andric d...@freebsd.org 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? I'm using perl 5.12.2_2 and this is the code to reproduce the problem. I didn't tested with other perl versions because it's a hard task to move to another perl. #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) = File::Temp::tempfile(); print $filename\n; -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 3:58 AM, Garrett Cooper gcoo...@freebsd.org wrote:
On Tue, Sep 28, 2010 at 11:43 PM, Dimitry Andric d...@freebsd.org 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.
I just have this on my 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=
--
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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 3:56 AM, Buganini bugan...@gmail.com wrote: mktemp foo.XX works here but perl's File::Temp is not working when I tried to build editors/openoffice.org-3-devel, I got: Error in tempdir() using /tmp/XX: Tried to get a new temp name different to the previous value 50 times. Something wrong with template?? (/tmp/XX) at /usr/ports/editors/openoffice.org-3-devel/work/DEV300_m88/solenv/bin/build.pl line 2282 Exactly thge same way I discovered the problem here. -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric d...@freebsd.org wrote: 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? Correct, i didn't build any port with clang. -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 8:50 AM, Buganini bugan...@gmail.com wrote: I'm using perl 5.10, on amd64 only enable clang in src.conf no CPU nor CFLAGS settings in src.conf/make.conf so it seems that the problem is perl-version independent? perhaps amd64? I didn't test on i386 but it seems to be a problem using world built with clang + perl 5.12. I booted here with kernel built woth clang and keeping world built with gcc and no problems happened. The problem is in some lib. -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric d...@freebsd.org wrote: 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? Well, I find out where the problem is, now I have my entire system built with gcc. After install libc.so.7 built with clang the problem starts, installing same lib built with gcc the problem stops. How can I debug it to give you more information? -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 9:40 AM, Renato Botelho rbga...@gmail.com wrote: On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric d...@freebsd.org wrote: 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? Well, I find out where the problem is, now I have my entire system built with gcc. After install libc.so.7 built with clang the problem starts, installing same lib built with gcc the problem stops. How can I debug it to give you more information? Re-sending to the list, here is a ktrace using built-with-clang libc.so.7, when the error occours. -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 10:12 AM, Renato Botelho rbga...@gmail.com wrote: On Wed, Sep 29, 2010 at 9:40 AM, Renato Botelho rbga...@gmail.com wrote: On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric d...@freebsd.org wrote: 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? Well, I find out where the problem is, now I have my entire system built with gcc. After install libc.so.7 built with clang the problem starts, installing same lib built with gcc the problem stops. How can I debug it to give you more information? Re-sending to the list, here is a ktrace using built-with-clang libc.so.7, when the error occours. Seems the list didn't like my attachment, so here is place to get it - http://people.freebsd.org/~garga/ktrace-error.txt.gz -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 11:06 AM, Roman Divacky rdiva...@freebsd.org wrote: renato, can you check if libc compiled with clang -O0 still exhibits the bug? I got the following error when i try to build libc with -O0 clang -O2 -pipe -O0 -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/amd64/gen/ldexp.c clang: warning: argument unused during compilation: '-O2' Assertion failed: (RegMap[RegOnTop] StackTop), function moveToTop, file /usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86FloatingPoint.cpp, line 200. Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name ldexp.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir /usr/lib/clang/2.8 -D NLS -D __DBINTERFACE_PRIVATE -D INET6 -D _ACL_PRIVATE -D POSIX_MISTAKE -D BROKEN_DES -D PORTMAP -D DES_BUILTIN -D YP -D NS_CACHING -D SYMBOL_VERSIONING -I /usr/src/lib/libc/include -I /usr/src/lib/libc/../../include -I /usr/src/lib/libc/amd64 -I /usr/src/lib/libc/../../contrib/gdtoa -I /usr/obj/usr/src/lib/libc -I /usr/src/lib/libc/resolv -I /usr/src/lib/libc/../../contrib/tzcode/stdtime -I /usr/src/lib/libc/stdtime -I /usr/src/lib/libc/locale -I /usr/src/lib/libc/rpc -O0 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -std=gnu99 -ferror-limit 19 -fmessage-length 105 -stack-protector 1 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-8DfzyK.s -x c /usr/src/lib/libc/amd64/gen/ldexp.c 1. eof parser at end of file 2. Code generation 3. Running pass 'X86 FP Stackifier' on function '@ldexp' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) *** Error code 250 Removing -O0 from CFLAGS it builds fine. Am I doing something wrong? I added CFLAGS+=-O0 on /etc/make.conf, and # cd /usr/src/lib/libc # make clean make clean make cleandir # make obj # make depend # make Thanks -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 11:06 AM, Roman Divacky rdiva...@freebsd.org wrote:
renato, can you check if libc compiled with clang -O0 still exhibits
the bug?
Hi Roman,
I needed to build ldexp.{o,po,So} manually with -O2, and built every
other object using -O0, the same problem happened.
--
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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 2:31 PM, Roman Divacky rdiva...@freebsd.org wrote: On Wed, Sep 29, 2010 at 11:56:59AM -0400, Derek Tattersall wrote: * Dimitry Andric d...@freebsd.org [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 Cs 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. what does this show with clang libc? perl -e 'print int(rand(60)) . \n foreach (1 .. 10)' I guess it returns all 0, as the $CHAR[0] is 'A', can you test that? r...@botelhor:/usr/src/lib/libc# perl -e 'print int(rand(60)) . \n foreach (1 .. 10)' nan nan nan nan nan nan nan nan nan nan -- 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
Fwd: Clang now builds world and kernel, on i386 and amd64
Could you guys give us some help on this? -- Forwarded message -- From: Roman Divacky rdiva...@freebsd.org Date: Wed, Sep 29, 2010 at 2:44 PM Subject: Re: Clang now builds world and kernel, on i386 and amd64 To: Renato Botelho rbga...@gmail.com Cc: Derek Tattersall d...@mebtel.net, Dimitry Andric d...@freebsd.org, curr...@freebsd.org On Wed, Sep 29, 2010 at 02:41:17PM -0300, Renato Botelho wrote: On Wed, Sep 29, 2010 at 2:31 PM, Roman Divacky rdiva...@freebsd.org wrote: On Wed, Sep 29, 2010 at 11:56:59AM -0400, Derek Tattersall wrote: * Dimitry Andric d...@freebsd.org [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 Cs 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. what does this show with clang libc? perl -e 'print int(rand(60)) . \n foreach (1 .. 10)' I guess it returns all 0, as the $CHAR[0] is 'A', can you test that? r...@botelhor:/usr/src/lib/libc# perl -e 'print int(rand(60)) . \n foreach (1 .. 10)' nan nan nan nan nan nan nan nan nan nan heh, now I noticed that Derek already wrote that ;) is anyone able to find where in perl sources the rand function is defined? I failed that :( -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 2:44 PM, Roman Divacky rdiva...@freebsd.org wrote:
heh, now I noticed that Derek already wrote that ;) is anyone able
to find where in perl sources the rand function is defined? I failed
that :(
It's using drand48() instead of rand()
r...@botelhor:/usr/ports/lang/perl5.12# make configure | grep -i rand
drand48_r() NOT found.
random_r() NOT found.
srand48_r() NOT found.
srandom_r() NOT found.
Looking for a random number function...
Good, found drand48().
Use which function to generate random numbers? [drand48]
Checking how to generate random libraries on your machine...
Test results here:
GCC libc:
ga...@botelhor:~/testes ./test
random value 0.396465
clang libc:
ga...@botelhor:~/testes ./test
random value -inf
Source of test.c:
#include stdlib.h
#include stdio.h
#include string.h
int main() {
printf(random value %f\n, drand48());
exit(0);
}
--
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
Re: Soft update panic while running perl 5.12 tests
On Wed, Sep 29, 2010 at 11:32 AM, Dimitry Andric d...@freebsd.org wrote: Hi, I just encountered the following soft update panic while running perl 5.12's tests: panic: indir_trunc: Index out of range -148 parent -2061 lbn -305164 cpuid = 3 KDB: enter: panic [ thread pid 19 tid 100047 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db bt Tracing pid 19 tid 100047 td 0xc72e9b40 kdb_enter(c0cd6a90,c0cd6a90,c0cfe8ab,e6be2b58,3,...) at kdb_enter+0x3a panic(c0cfe8ab,ff6c,f7f3,,fffb57f4,...) at panic+0x136 indir_trunc(f7f3,,c85507c0,c834d200,c733de00,...) at indir_trunc+0x4be handle_workitem_indirblk(4,c0cd520e,df,c834d200,c834d200,...) at handle_workitem_indirblk+0x64 handle_workitem_freeblocks(0,e6be2c74,2,5dc,1e0,...) at handle_workitem_freeblocks+0x95 process_worklist_item(c0fb2f98,0,c0cfdf8d,54a,c72e9b40,...) at process_worklist_item+0x21c softdep_process_worklist(c732aca8,0,c0cfdf8d,4cd,64,...) at softdep_process_worklist+0x8c softdep_flush(0,e6be2d28,c0cd1c8a,349,c72ed550,...) at softdep_flush+0x2a0 fork_exit(c0afb670,0,e6be2d28) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6be2d60, ebp = 0 --- It is consistently reproducible. This is on a -current system, at r213139, on i386. Settings for the affected filesystem: tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) dimtest1 The panic is apparently caused by perl's op/lfs.t test, which tests perlio with big files. You can test it by building the perl 5.12 port, and then running: cd /usr/ports/lang/perl5.12/work/perl-5.12.2/t ../miniperl op/lfs.t Alternatively, just run make test in /usr/ports/lang/perl5.12. Since i'm running -current with SUJ here, and built perl 5.12 recently without problems, maybe this can help you (I have that patch applied locally since it was not committed yet). http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019409.html -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 4:35 PM, Dimitry Andric d...@freebsd.org wrote: On 2010-09-29 20:22, Renato Botelho wrote: It's using drand48() instead of rand() ... GCC libc: ga...@botelhor:~/testes ./test random value 0.396465 clang libc: ga...@botelhor:~/testes ./test random value -inf 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/ Thank you -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 4:49 PM, Dimitry Andric d...@freebsd.org wrote: 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? :) Just fine :) ga...@botelhor:~/testes perl tmp.pl /tmp/_68PLsxOhY ga...@botelhor:~/testes perl tmp.pl /tmp/XUQhE_7DKY ga...@botelhor:~/testes perl tmp.pl /tmp/8VyPZdAWD7 ga...@botelhor:~/testes perl tmp.pl /tmp/3bdOmoPhL2 -- 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
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 22, 2010 at 3:42 AM, Dimitry Andric d...@freebsd.org 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
Regards
--
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
Re: Clang now builds world and kernel, on i386 and amd64
On Tue, Sep 28, 2010 at 6:07 PM, Renato Botelho rbga...@gmail.com wrote:
On Wed, Sep 22, 2010 at 3:42 AM, Dimitry Andric d...@freebsd.org 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
Re: Clang now builds world and kernel, on i386 and amd64
On Tue, Sep 28, 2010 at 9:28 PM, Derek Tattersall d...@mebtel.net wrote:
* Renato Botelho rbga...@gmail.com [100928 20:20]:
On Tue, Sep 28, 2010 at 6:07 PM, Renato Botelho rbga...@gmail.com wrote:
On Wed, Sep 22, 2010 at 3:42 AM, Dimitry Andric d...@freebsd.org 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.
I didn't test mktemp, but my perl test code generate files
with all 'A' just after i reboot the machine with clang, after
few minutes it stop working and give the error I reported.
Please let me know if there is any kind of information I
can send to help fixing this.
--
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
Re: softupdate with journal panic
On Mon, Aug 23, 2010 at 6:12 PM, Kostik Belousov kostik...@gmail.com wrote:
On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote:
On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
While updating sysutils/coreutils port on -current as of this morning
(SVN r211550), I noted a panic during the directory rename config test.
Your problem seems identical to this report:
http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC
I believe that dotdotremref in this case is legitimately NULL. With this
assumption, the following patch would help.
diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
index b666c0f..65e5255 100644
--- a/sys/ufs/ffs/ffs_softdep.c
+++ b/sys/ufs/ffs/ffs_softdep.c
@@ -6770,7 +6794,8 @@ cancel_diradd(dap, dirrem, jremref, dotremref,
dotdotremref)
mkdir-md_jaddref = NULL;
if (mkdir-md_state MKDIR_PARENT) {
if (cancel_jaddref(jaddref, NULL,
- dirrem-dm_jwork) == 0) {
+ dirrem-dm_jwork) == 0
+ dotdotremref != NULL) {
free_jremref(dotdotremref);
dotdotremref = NULL;
}
I was having a kernel panic trying to build coreutils, at configure
time it make some tests with rename() and system crashed. It was
just happening on the box i'm using SUJ. After apply this patch
everything went fine. Thanks!
--
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
Re: missing /usr/lib/liblzma.a during HEAD buildworld ?
On Sat, May 15, 2010 at 6:18 PM, Luigi Rizzo ri...@iet.unipi.it wrote: Hi, building HEAD on my laptop (stable/7 approx jun 2009) fails with the following error: sh /usr/home/luigi/FreeBSD/head/tools/install.sh -o root -g wheel -m 444 fr.ISO8859-1-s /home/luigi/FreeBSD/obj_head/usr/home/luigi/FreeBSD/head/tmp/legacy/usr/share/tmac/mdoc/fr.ISO8859-1 sh /usr/home/luigi/FreeBSD/head/tools/install.sh -o root -g wheel -m 444 ru.KOI8-R-s /home/luigi/FreeBSD/obj_head/usr/home/luigi/FreeBSD/head/tmp/legacy/usr/share/tmac/mdoc/ru.KOI8-R === usr.bin/ar (obj,depend,all,install) make: don't know how to make /usr/lib/liblzma.a. Stop *** Error code 2 Stop in /usr/home/luigi/FreeBSD/head. *** Error code 1 The build apparently works fine on my desktop, still stable/7 from Sep.2009) Any idea on what could be wrong ? http://lists.freebsd.org/pipermail/freebsd-current/2010-May/017250.html -- 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
Error 127.0.0.1: no route to host
I updated my 9.0-current amd64 today on rev. 204915 and start to get errors like this 127.0.0.1: no route to host I boot using kernel.old and everything back to normal. I don't know exactly revision of my kernel.old because last change made on sys/conf/newvers.sh simply removed this information from my uname, see: FreeBSD botelhor.bplab.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon Mar 8 15:52:59 BRT 2010 r...@botelhor.bplab.local:/usr/obj/usr/src/sys/GARGA amd64 I just know it was built yesterday about 18:00 UTC Is there any other way to get this information? Let me know if you need more information about my environment. Regards -- 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
Re: Error 127.0.0.1: no route to host
On Tue, Mar 9, 2010 at 5:14 PM, Li, Qing qing...@bluecoat.com wrote: This error was caused by my commit r204902 from yesterday. Please try patch at http://people.freebsd.org/~qingli/route.h.diff Patch fixed the problem, thanks for the quick reply and fix. -- 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
