clang/llvm 3.9.0 mysteriously zeroing variables?
Starting with r309124 (when clang/llvm 3.9.0 was imported) I'm seeing EC2
instances panic on boot with a division-by-zero error; the code in question
is in blkfront.c, printing out the size of disks:
> device_printf(dev, "%juMB <%s> at %s",
> (uintmax_t) sectors / (1048576 / sector_size),
> device_get_desc(dev),
> xenbus_get_node(dev));
My first thought was that 'sector_size' must be either zero or very large...
but no, when I add printf("sector_size = %ju\n", (uintmax_t)sector_size), it's
entirely normal. What's more, adding that printf makes the division-by-zero
panic go away.
I'd think I was just hallucinating, but earlier today I heard that a similarly
"impossible" panic had been observed in the NFS client code when compiled with
clang/llvm 3.9.0.
So... is anyone else seeing unexpected panics or other odd behaviour starting
after clang/llvm 3.9.0 was imported?
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
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_HEAD_i386 - Build #4293 - Fixed
FreeBSD_HEAD_i386 - Build #4293 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4293/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4293/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4293/console Change summaries: 309513 by adrian: [camcontrol] init ts=0 to quieten gcc. It "looks" like ts is set to something on success, and not modified on error. Checked on IRC with: cem 309504 by dteske: Fix bug preventing limits(1) from being applied PR: misc/212493 Differential Revision: https://reviews.freebsd.org/D8232 Submitted by: girgen Reviewed by:adrian MFC after: 3 days X-MFC-to: stable/11 309491 by rpokala: Build smbios.ko as a module for amd64 and i386 For whatever reason, smapi, smbios, vpd are all under the "bios" directory. smapi is only for i386, so the entire "bios" directory is only built for i386. Break smapi out, and make only it i386-specific. Then, build the "bios" directory for both amd64 and i386. Reviewed by:imp MFC after: 1 week Sponsored by: Panasas Differential Revision: https://reviews.freebsd.org/D8609 309490 by pfg: Revert r253678, r253661: Fix a segfault in ctfmerge(1) due to a bug in GCC. The change was correct and the bug real, but upstream didn't adopt it and we want to remain in sync. When/if upstream does something about it we can bring their version. The bug in question was fixed in GCC 4.9 which is now the default in FreeBSD's ports. Our native gcc-4.2, which is still in use in some Tier-2 platforms also has a workaround so no end-user should be harmed by the revert. 309486 by avos: rtwn: fix bitmap size calculation. Tested with RTL8188CE, STA mode. 309481 by avos: rsu: fix frame processing in the Rx path (similar to r292207). - Fill in Rx radiotap header correctly (for every packet in a chain; not once per chain). - Fix rate / flags fields in Rx radiotap. - Add debug messages for discarded frames. - Pass received control (< sizeof(struct ieee80211_frame)) frames to net80211 (if allowed by device filter; cannot happen yet). Tested with Asus USB-N10. Differential Revision: https://reviews.freebsd.org/D5723 309480 by kevlo: Fix logic error so the R92C_TDECTRL register value is updated correctly. Reviewed by:avos 309479 by avos: rsu: remove unused structures / variables. 309478 by bdrewery: DIRDEPS_BUILD: Fix '/' in group names creating a bad cookie. This is reworking the change in r296585 but to still properly install the files. This limits the change to only the DIRDEPS_BUILD logic for what it considers the name of the staging set, which is what the cookie name is based off of. Sponsored by: Dell EMC Isilon MFC after: 1 week 309477 by bdrewery: Revert r296585. This broke installing dtrace test files. It was poorly tested. Reported by:markj Pointyhat to: bdrewery MFC after: 1 week 309476 by bdrewery: Create the /usr/lib/include symlink as relative. This ugly code is done to avoid assuming LIBDIR is 2 components deep. Reported by:jhb 309474 by ngie: Don't build :strvis_locale if VIS_NOLOCALE is undefined The copy of contrib/libc-vis on ^/stable/10 doesn't contain all of the features in the ^/stable/11 // ^/head version, including VIS_NOLOCALE. The risk is lower in conditionally running the test instead of backporting the newer version of libc-vis MFC after: now 309472 by ngie: Restore pathing for factor(1), which unnecessarily diverged in r278616 factor lives in /usr/games/, not /usr/bin, in NetBSD. The correct way to handle this is do on-the-fly manipulation of the test script via ATF_TESTS_SH_SED_, not by modify the pathing directly in the test script. This is being done to resolve an unnecessary conflict made when pulling back ^/head@r309469 (contrib/netbsd-tests update) to ^/stable/10. No functional change MFC after: now 309467 by adrian: [ath] use the correct AMPDU frame limit for the given node, rather than the global config. This is important in hostap, ibss, (11s at some magical future date, etc) where different nodes may have smaller limits. Oops! MFC after: 1 week Relnotes: Yes 309465 by adrian: [net80211] prepare for 11ac aware NICs that want to know per-vdev channel and centre frequencies. * ic_freq is the centre of the primary channel, not the centre of the HT40/HT80/etc channel. Add a method to access that. * Add a method to access the centre of the primary channel, including knowing the centre of the 5/10/20/40/80, versus the primary channel. Ie, it's the centre of the 40, 80, 160MHz channel. * Add a method to access the centre frequency of the secondary 80MHz channel - we don't support VHT yet, but when we do. * Add methods to access the current channel and the per-dev desired channel. Ideally drivers that do full offload with a per-vap channel configuration should use the vap channel, NOT ic_curchan. Non-offload drivers that require net802
Re: freebsd-current Digest, Vol 684, Issue 8
please remove me from your mailing list. i repeat, please remove me from the thi subscription and any other subscription Daniel D'Alonzohttp://danieldalonzo.com/ On Sat, Dec 3, 2016 7:00 AM, freebsd-current-requ...@freebsd.org wrote: Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-requ...@freebsd.org You can reach the person managing the list at freebsd-current-ow...@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-current digest..." Today's Topics: 1. Re: CFT EFI Boot Refactoring (Ben Woods) 2. Re: CFT EFI Boot Refactoring (Ben Woods) -- Message: 1 Date: Sat, 3 Dec 2016 14:57:24 +0800 From: Ben Woods To: Eric McCorkle Cc: freebsd-hack...@freebsd.org, freebsd-am...@freebsd.org, "curr...@freebsd.org" Subject: Re: CFT EFI Boot Refactoring Message-ID: Content-Type: text/plain; charset=UTF-8 On 3 December 2016 at 14:40, Ben Woods wrote: > I just applied your diff to my subversion repository, and tried to > buildworld, but the build failed with the following error: > > make[6]: make[6]: don't know how to make efipart.c. Stop > > make[6]: stopped in /usr/src/sys/boot/efi/drivers > *** [all_subdir_sys/boot/efi/drivers] Error code 2 > > > Does it build ok for you? > > Because I use subversion, and I wanted to build it from my main tree, I > had to regenerate your patch using "git diff --no-prefix > master..origin/efize_new > /tmp/efize_new.diff". > I could then apply this cleanly with "svn patch /tmp/efize_new.diff". > > Never mind, I have realised that efipart.c was moved from boot/efi/libefi/ to boot/efi/drivers/ in your git patch, but subversion did not interpret this change and simply patched the file in place. I have fixed this with: $ svn mv boot/efi/libefi/efipart.c boot/efi/drivers/efipart.c Sorry for the noise (and the previous top post). Regards, Ben -- From: Benjamin Woods woods...@gmail.com -- Message: 2 Date: Sat, 3 Dec 2016 18:10:39 +0800 From: Ben Woods To: Eric McCorkle Cc: freebsd-hack...@freebsd.org, freebsd-am...@freebsd.org, "curr...@freebsd.org" Subject: Re: CFT EFI Boot Refactoring Message-ID: Content-Type: text/plain; charset=UTF-8 On 3 December 2016 at 01:02, Eric McCorkle wrote: > Therefore, I would like to issue a CFT for this changeset. We need > people using the boot1/loader EFI boot setup to test their setup using > boot1 and loader as built with this patch applied. > After I got this to build, I managed to install the new world, and copy the new boot1.efi to /EFI/BOOT/BOOTX64.EFI. Upon reboot, my machine hung at the loader, with the following text on the screen: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: FS Backend| Unfortunately it stopped there and didn't continue. I was able to recover my system by moving my BOOTX64.BAK to BOOTX64.EFI, and changing back to my old loader.efi. Any thoughts of how we can debug this? Regards, Ben -- From: Benjamin Woods woods...@gmail.com -- Subject: Digest Footer ___ 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" -- End of freebsd-current Digest, Vol 684, Issue 8 *** ___ 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: CFT EFI Boot Refactoring
On 3 December 2016 at 01:02, Eric McCorkle wrote: > Therefore, I would like to issue a CFT for this changeset. We need > people using the boot1/loader EFI boot setup to test their setup using > boot1 and loader as built with this patch applied. > After I got this to build, I managed to install the new world, and copy the new boot1.efi to /EFI/BOOT/BOOTX64.EFI. Upon reboot, my machine hung at the loader, with the following text on the screen: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: FS Backend| Unfortunately it stopped there and didn't continue. I was able to recover my system by moving my BOOTX64.BAK to BOOTX64.EFI, and changing back to my old loader.efi. Any thoughts of how we can debug this? Regards, Ben -- From: Benjamin Woods woods...@gmail.com ___ 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"
