Re: armv7 pmap fix for Cortex A53 (and Cortex A7?)

On Sun, Jul 31, 2016 at 08:03:58PM +0200, Mark Kettenis wrote: > So the CPU might speculatively load TLB entries. The upshot from this > is that we always have to perform a TLB flush if we modify a valid > entry. So we can't rely on PV_BEEN_REFD() to decide whether we should > flush or not. The

Re: armv7 pmap fix for Cortex A53 (and Cortex A7?)

The patch doesn't fix the bug on Cortex A7. cpu0 at mainbus0: ARM Cortex A7 rev 4 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache Scanning scsi 0:1... reading /sun7i-a20-olinuxino-lime2.dtb 2989

Re: Use of uninitialized variables in binutils-2.17

On Sun, Jul 31, 2016 at 10:00 AM, Stefan Kempf wrote: > clang errors out about use of undefined variables when building > binutils-2.17. > > In elf.c, do not increment `s' before it is initialized. At the time > of the increment, `s' is otherwise unused anyway. Indeed, it's dead there. > In elf

[PATCH] afterboot.8: clarify mail aliases handling

We have smtpd(8) that now uses file-based aliases table instead of db-based. This table backend requires running $ smtpctl update table aliases instead of $ newaliases in order to fetch changes. However, afterboot(8) still mentions the old way of doing things. --- share/man/man

small ndp(8) fix

WARNINGS=Yes says: /usr/src/usr.sbin/ndp/ndp.c: In function 'dump': /usr/src/usr.sbin/ndp/ndp.c:564: warning: 'lim' may be used uninitialized in this function The warning looks legitimate, IIUC there's room here for invalid memory accesses (those would probably involve ndp -A). Here's a fix pr

armv7 pmap fix for Cortex A53 (and Cortex A7?)

The ARMv7 ARM says in B3.9 that The architecture guarantees that a translation table entry that generates a Translation fault or an Access flag fault is not held in the TLB. However a translation table entry that generates a Domain fault or a Permission fault might be held in the TLB. and

Re: libtool -bindir support

On July 31, 2016 7:14:21 PM GMT+02:00, j...@wxcvbn.org wrote: > >Making read(2) return EISDIR for directories breaks two ports, both >because they use libtool -bindir. cc(1) gets executed with an unknown >option, -bindir, and a path such as /usr/local/bin, which then gets >passed to ld(1). ld(1)

Re: Use of uninitialized variables in binutils-2.17

Stefan Kempf writes: > clang errors out about use of undefined variables when building > binutils-2.17. > > In elf.c, do not increment `s' before it is initialized. At the time > of the increment, `s' is otherwise unused anyway. > > In elflink.c, initialize sec_contents and l_sec_contents to make

libtool -bindir support

Making read(2) return EISDIR for directories breaks two ports, both because they use libtool -bindir. cc(1) gets executed with an unknown option, -bindir, and a path such as /usr/local/bin, which then gets passed to ld(1). ld(1) copes with read(2) returning 0, not with EISDIR. Thanks to Antoine

Use of uninitialized variables in binutils-2.17

clang errors out about use of undefined variables when building binutils-2.17. In elf.c, do not increment `s' before it is initialized. At the time of the increment, `s' is otherwise unused anyway. In elflink.c, initialize sec_contents and l_sec_contents to make sure that the free(sec_contents) a

Re: Alternative control socket location in ripd

Nima GHOTBI writes: > Hi everyone > > In one of our projects we had to run multiple instances of ripd on > different rdomains so I made a patch to add "-s" argument to ripd and > ripctl to let the user change control socket path from /var/run/ripd.sock Sounds like a valuable addition, but your p

Re: hotplugd restart problem

Martin Natano writes: > On Mon, Jul 25, 2016 at 02:17:11PM +0300, Alexey Vatchenko wrote: >> Hi! >> If something is running which is started from attach script, restarting of >> hotplugd fails because /dev/hotplug is occupied by child process. >> >> Attached is the patch to fix this problem. > >

Re: iwm driver in latest snapshot has terrible performance

Now testing with a July 17th kernel, everything works fine at .11n speeds but the ping goes from 1ms to 100+ms for one packet on average every 50-60 packets. 64 bytes from 192.168.50.1: icmp_seq=499 ttl=255 time=1.158 ms 64 bytes from 192.168.50.1: icmp_seq=500 ttl=255 time=0.832 ms 64 bytes f

Re: iwm driver in latest snapshot has terrible performance

This is with mode 11g added to /etc/hostname.iwm0 : # ifconfig iwm0 scan iwm0: flags=208843 mtu 1500 lladdr 5c:51:4f:43:b5:c0 index 1 priority 4 llprio 3 groups: wlan egress media: IEEE802.11 autoselect (OFDM54 mode 11a) status: active ieee80211:

Re: Use m_devget(9) in smsc(4)

On Sun, Jul 31, 2016 at 01:55:31PM +0200, Claudio Jeker wrote: > On Sat, Jul 30, 2016 at 10:03:33PM +0200, Mark Kettenis wrote: > > Removes a couple of lines of code from the driver. > > > > ok? > > This is the right use of m_devget. OK claudio@ > Another one. (2 dlg@, this was the m_*() i was

Re: Use m_devget(9) in smsc(4)

On Sat, Jul 30, 2016 at 10:03:33PM +0200, Mark Kettenis wrote: > Removes a couple of lines of code from the driver. > > ok? This is the right use of m_devget. OK claudio@ PS: realized that the manpage for m_devget still has the old prototype with the ifp in it... -- :wq Claudio > > Index: i

Re: Style update for some files in arch/arm

On Thu, Jul 28, 2016 at 10:31:35AM -0400, Robert Tate wrote: > I found a few files that could use updated function declarations. Here > is my diff: Thanks, committed without the comment removal portion. One issue per diff (and other files have the "End of foo.c" comment).