Re: UEFI Loader problems in CURRENT
Having had a few hours to think about things, I'm starting to think that the loader may be crashing w/o any clue or traceback. I'll look into this being a possibility. In the past, this has happened because of an untested error condition and/or assuming pointers were non-NULL. It would be super swell if there were a cheap to obtain box that exhibits this problem. Warner On Sat, Sep 29, 2018 at 6:14 PM Warner Losh wrote: > Sadly both of these bugs are thin on detail beyond it doesn't work. Makes > it hard to even look into it. > > Warner > > On Sat, Sep 29, 2018, 6:00 PM Yuri wrote: > >> See: >> >> * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230090 >> >> * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219957 >> >> >> Yuri >> >> >> ___ >> 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 >> " >> > ___ 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: UEFI Loader problems in CURRENT
Sadly both of these bugs are thin on detail beyond it doesn't work. Makes it hard to even look into it. Warner On Sat, Sep 29, 2018, 6:00 PM Yuri wrote: > See: > > * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230090 > > * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219957 > > > Yuri > > > ___ > 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" > ___ 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"
UEFI Loader problems in CURRENT
See: * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230090 * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219957 Yuri ___ 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"
Dell latitude 7490 touchpad support?
Hi I just got a new work laptop and the touchpad does not work. Some information points to that this machine has a Microsoft precision touchpad. I can't see any USB device so I'm wondering if this is an I2C device? Do we have any driver for this? /Johannes ___ 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: unknown -z value: common-page-size=4096
On 29/09/2018 07:36, Dimitry Andric wrote: > You can apply this changeset from the clang700-import branch: > > https://svnweb.freebsd.org/changeset/base/337325 > Ah, I definitely missed this revision. I ended up working around the error by manually removing the offending bit from kern.pre.mk, which has the same effect of this changeset. > or just use the clang700-import branch wholesale. :-) > I would, but I also update and build head irregularly and prefer to build and run the newest code as they are committed. That, and I'm a bit lazy to run svn merge when I update :-) -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
mkimg(1) creates a file in TMPDIR until no space left
Hello, I'm using a copy of src/release/amd64/make-memstick.sh to build from a complete root in /usr/local/r338641/root.r338641 (result of make installworld and installkernel to this dir) for testing purpose a memstick image and write this with dd(1) to an USB key of ~32 GByte. I'm using a copy of this script because I want to define the size of the UFS in the image to have there enough free space to install later after boot as well packages to test them. The modification is only setting '-M 50331648b -m 50331648b' for the file system created with mkfs(8). Here is what is running exactly: # TMPDIR=/usr/tmp export TMPDIR # ./make-memstick.sh /usr/local/r338641/root.r338641 /usr/local/r338641/memstick.im + makefs -B little -M 50331648b -m 50331648b -o 'label=FreeBSD_Install' -o 'version=2' /usr/local/r338641/memstick.im.part /usr/local/r338641/root.r338641 Calculated size of `/usr/local/r338641/memstick.im.part': 25769803776 bytes, 24530 inodes Extent size set to 32768 /usr/local/r338641/memstick.im.part: 24576.0MB (50331648 sectors) block size 32768, fragment size 4096 using 28 cylinder groups of 901.44MB, 28846 blks, 1024 inodes. super-block backups (for fsck -b #) at: 192, 1846336, 3692480, 5538624, 7384768, 9230912, 11077056, 12923200, 14769344, 16615488, 18461632, 20307776, 22153920, 2464, 25846208, 27692352, 29538496, 31384640, 33230784, 35076928, 36923072, 38769216, 40615360, 42461504, 44307648, 46153792, 4736, 49846080, Populating `/usr/local/r338641/memstick.im.part' Image `/usr/local/r338641/memstick.im.part' complete + rm /usr/local/r338641/root.r338641/etc/fstab + rm /usr/local/r338641/root.r338641/etc/rc.conf.local + mkimg -C 28G -s mbr -b /usr/local/r338641/root.r338641/boot/mbr -p 'efi:=/usr/local/r338641/root.r338641/boot/boot1.efifat' -p 'freebsd:-mkimg -C 28G -s bsd -b /usr/local/r338641/root.r338641/boot/boot -p freebsd-ufs:=/usr/local/r338641/memstick.im.part' -a 2 -o /usr/local/r338641/memstick.im ... While the cascade of mkimg(1) is running a *big* temp file is created, which at the end eats up all memory of the disk: # ls -lh /usr/local/r338641 /usr/tmp /usr/local/r338641: total 25172008 -rwxr-xr-x 1 root wheel 1.3K Sep 29 16:41 make-memstick.sh -rw-r--r-- 1 root wheel 0B Sep 29 16:50 memstick.im -rw-r--r-- 1 root wheel24G Sep 29 16:50 memstick.im.part drwxr-xr-x 18 root wheel 512B Sep 24 07:11 root.r338641 /usr/tmp: total 11307168 -rw--- 1 root wheel 456G Sep 29 17:01 mkimg-LmntlL<<< 456G !!! -rw--- 1 root wheel 0B Sep 29 16:50 mkimg-yfU8Lr /: write failed, filesystem is full /: write failed, filesystem is full But the 'memstick.im' is created fine at the end: # ls -lh /usr/local/r338641 /usr/tmp /usr/local/r338641: total 2591752 -rwxr-xr-x 1 root wheel 1.3K Sep 29 16:41 make-memstick.sh -rw-r--r-- 1 root wheel24G Sep 29 17:22 memstick.im drwxr-xr-x 18 root wheel 512B Sep 24 07:11 root.r338641 /usr/tmp: total 0 And the UBS stick produced from 'memstick.im' with dd(1) boots fine and the root file system has around 20 GB free space. Why it is mkimg(1) creating such a big temp. file? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ 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"
Resume Issue with em(4) ALPHA7
Hello, More suspend/resume testing on my end. This system is a desktop, so not critical for my daily workflow but wanted to flag it regardless. The system is a Lenovo m900 with skylake and em(4) NIC. Entering suspend works without issues, resuming seems to mostly work as well. I.e. no issues with display or input from keyboard or mouse. The one issue I am running into is my NIC is non-functional after resume. restarting the network stack via "service netif restart" does not work - as in no DHCP lease is aquired and no link is detected. Nor does manually down'ing and up'ing the interface work. I see these messages in my dmesg buffer after resume: in6_purgeaddr: err=65, destination address delete failed lo0: link state changed to DOWN lo0: link state changed to UP Link state changed to down em0: link state changed to DOWN em0: TX(0) desc avail = 1024, pidx = 0 em0: TX(0) desc avail = 1024, pidx = 0 em0: TX(0) desc avail = 1024, pidx = 0 em0: TX(0) desc avail = 1024, pidx = 0 Another thing I noticed is that after resume "ifconfig" hangs for a couple seconds printing after printing the first line of my em0 device (after the flags). Not sure if that's helpful but thought it could be a useful datapoint. It is easy to reproduce this, so I am happy to do any additional debugging or testing on this. Cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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: unknown -z value: common-page-size=4096
On 29 Sep 2018, at 04:08, Shawn Webb wrote: > > On Fri, Sep 28, 2018 at 10:01:31PM -0400, Charlie Li wrote: >> I've switched to using devel/xtoolchain-llvm70 yesterday to build amd64 >> base starting with r338990, and among other issues, ld.lld70 refuses to >> link the kernel: >> >> Building /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE/kernel.full >> --- kernel.full --- >> linking kernel.full >> ld.lld: error: unknown -z value: common-page-size=4096 >> ld.lld: error: unknown -z value: ifunc-noplt >> *** [kernel.full] Error code 1 >> >> make[2]: stopped in /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE >> >> (ARDMORE is basically GENERIC-NODEBUG, not that it matters) >> >> The ifunc-noplt is a known issue, it obviously didn't make it upstream >> in time for LLVM 7.0.0, and thus we carry the feature downstream. >> >> The crux of this link error though, emaste@ quipped in PR 230604 that >> LLD prior to 7.0.0 accepted but ignored unknown options, but now at >> least 7.0.0 disallows unknown options entirely. Which brings up the -z >> common-page-size=4096: has LLD been ignoring this part the whole time, >> and is it of any meaningful use anymore (it seemed to mean something >> with bfd)? > > I noticed the same issues. I reverted parts of recent work by upstream > FreeBSD in HardenedBSD's Cross-DSO CFI branch since that branch uses > clang/llvm/lld 7.0.0. You can apply this changeset from the clang700-import branch: https://svnweb.freebsd.org/changeset/base/337325 or just use the clang700-import branch wholesale. :-) -Dimitry signature.asc Description: Message signed with OpenPGP
