Re: fix iwn firmware error during init
On Sat, Jan 09, 2016 at 10:25:45PM +0100, Stefan Sperling wrote:
> I've run into an issue where iwn(4) fails to init the hardware.
>
> Running 'ifconfig iwn0 scan' resulted in:
>
> setting configuration
> iwn0: fatal firmware error
> firmware error log:
> error type = "SYSASSERT" (0x0005)
> program counter = 0x00022088
> source line = 0x00A4
> error data = 0x00A4
> branch link = 0x0002225800022258
> interrupt link = 0x1532
> time= 27873
> driver status:
> tx ring 0: qid=0 cur=0 queued=0
> tx ring 1: qid=1 cur=0 queued=0
> tx ring 2: qid=2 cur=0 queued=0
> tx ring 3: qid=3 cur=0 queued=0
> tx ring 4: qid=4 cur=6 queued=0
> tx ring 5: qid=5 cur=0 queued=0
> tx ring 6: qid=6 cur=0 queued=0
> tx ring 7: qid=7 cur=0 queued=0
> tx ring 8: qid=8 cur=0 queued=0
> tx ring 9: qid=9 cur=0 queued=0
> tx ring 10: qid=10 cur=0 queued=0
> tx ring 11: qid=11 cur=0 queued=0
> tx ring 12: qid=12 cur=0 queued=0
> tx ring 13: qid=13 cur=0 queued=0
> tx ring 14: qid=14 cur=0 queued=0
> tx ring 15: qid=15 cur=0 queued=0
> tx ring 16: qid=16 cur=0 queued=0
> tx ring 17: qid=17 cur=0 queued=0
> tx ring 18: qid=18 cur=0 queued=0
> tx ring 19: qid=19 cur=0 queued=0
> rx ring: cur=7
> 802.11 state 0
> iwn0: RXON command failed
> iwn0: could not configure device
> iwn0: could not load firmware .data section
> iwn0: could not load firmware
> iwn0: could not initialize hardware
>
> A debug printf revealed the rxon command channel was set to zero:
>
> iwn_config: rxon chan 0 flags 40008000 cck f ofdm ff
>
> I haven't been able to reproduce the problem with the diff below.
> Note that this code runs during hardware initialization only.
> It shouldn't really matter what channel we set here as long as
> it isn't zero.
>
> Fix a misplaced curly brace while here...
>
> ok?
Anyone?
I've been running with this for 3 days without issues.
> Index: if_iwn.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
> retrieving revision 1.153
> diff -u -p -r1.153 if_iwn.c
> --- if_iwn.c 7 Jan 2016 23:08:38 - 1.153
> +++ if_iwn.c 9 Jan 2016 21:12:23 -
> @@ -3429,7 +3429,7 @@ iwn_set_link_quality(struct iwn_softc *s
> /* Next retry at immediate lower bit-rate. */
> if (txrate > 0)
> txrate--;
> - }
> + }
> }
>
> return iwn_cmd(sc, IWN_CMD_LINK_QUALITY, &linkq, sizeof linkq, 1);
> @@ -4455,15 +4455,9 @@ iwn_config(struct iwn_softc *sc)
> IEEE80211_ADDR_COPY(ic->ic_myaddr, LLADDR(ifp->if_sadl));
> IEEE80211_ADDR_COPY(sc->rxon.myaddr, ic->ic_myaddr);
> IEEE80211_ADDR_COPY(sc->rxon.wlap, ic->ic_myaddr);
> - sc->rxon.chan = ieee80211_chan2ieee(ic, ic->ic_ibss_chan);
> + sc->rxon.chan = 1;
> sc->rxon.flags = htole32(IWN_RXON_TSF | IWN_RXON_CTS_TO_SELF);
> - if (IEEE80211_IS_CHAN_2GHZ(ic->ic_ibss_chan)) {
> - sc->rxon.flags |= htole32(IWN_RXON_AUTO | IWN_RXON_24GHZ);
> - if (ic->ic_flags & IEEE80211_F_USEPROT)
> - sc->rxon.flags |= htole32(IWN_RXON_TGG_PROT);
> - DPRINTF(("%s: 2ghz prot 0x%x\n", __func__,
> - le32toh(sc->rxon.flags)));
> - }
> + sc->rxon.flags |= htole32(IWN_RXON_AUTO | IWN_RXON_24GHZ);
> switch (ic->ic_opmode) {
> case IEEE80211_M_STA:
> sc->rxon.mode = IWN_MODE_STA;
> @@ -4489,6 +4483,9 @@ iwn_config(struct iwn_softc *sc)
> IWN_RXCHAIN_IDLE_COUNT(2);
> sc->rxon.rxchain = htole16(rxchain);
> DPRINTF(("setting configuration\n"));
> + DPRINTF(("%s: rxon chan %d flags %x cck %x ofdm %x\n", __func__,
> + sc->rxon.chan, le32toh(sc->rxon.flags), sc->rxon.cck_mask,
> + sc->rxon.ofdm_mask));
> error = iwn_cmd(sc, IWN_CMD_RXON, &sc->rxon, sc->rxonsz, 0);
> if (error != 0) {
> printf("%s: RXON command failed\n", sc->sc_dev.dv_xname);
>
ifconfig mode subcommand
Do not require users to type 'media autoselect mode ...' if all
they want is to force a particular operating mode.
This allows 11n support to be disabled by typing short commands like:
ifconfig iwn0 mode 11a
ifconfig iwn0 mode 11g
ifconfig iwn0 mode 11b
The new -mode command restores the default behaviour (mode autoselect).
ok?
Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.264
diff -u -p -r1.264 ifconfig.8
--- ifconfig.8 6 Dec 2015 12:50:05 - 1.264
+++ ifconfig.8 12 Jan 2016 11:59:16 -
@@ -373,16 +373,21 @@ The routing metric can be used by routin
Higher metrics have the effect of making a route less favorable.
.It Cm mode Ar mode
If the driver for the interface supports the media selection system,
-set the specified operating mode on the interface to the given
+force the operating mode of the interface to the given
.Ar mode .
For IEEE 802.11 wireless interfaces that support multiple operating modes,
this directive is used to select between 802.11a
.Pq Dq 11a ,
802.11b
.Pq Dq 11b ,
-and 802.11g
-.Pq Dq 11g
+802.11g
+.Pq Dq 11g,
+and 802.11n
+.Pq Dq 11n
operating modes.
+.It Fl mode
+Select the operating mode automatically.
+This is the default for IEEE 802.11 wireless interfaces.
.It Cm mpls
Enable Multiprotocol Label Switching (MPLS) on the interface,
allowing it to send and receive MPLS traffic.
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.314
diff -u -p -r1.314 ifconfig.c
--- ifconfig.c 6 Jan 2016 21:37:00 - 1.314
+++ ifconfig.c 12 Jan 2016 11:40:26 -
@@ -193,6 +193,7 @@ voidunsetkeepalive(const char *, int);
void setmedia(const char *, int);
void setmediaopt(const char *, int);
void setmediamode(const char *, int);
+void unsetmediamode(const char *, int);
void clone_create(const char *, int);
void clone_destroy(const char *, int);
void unsetmediaopt(const char *, int);
@@ -517,6 +518,7 @@ const structcmd {
{ "mediaopt", NEXTARG,A_MEDIAOPTSET, setmediaopt },
{ "-mediaopt", NEXTARG,A_MEDIAOPTCLR, unsetmediaopt },
{ "mode", NEXTARG,A_MEDIAMODE,setmediamode },
+ { "-mode", 0, A_MEDIAMODE,unsetmediamode },
{ "instance", NEXTARG,A_MEDIAINST,setmediainst },
{ "inst", NEXTARG,A_MEDIAINST,setmediainst },
{ "lladdr", NEXTARG,0, setiflladdr },
@@ -2367,7 +2369,7 @@ void
process_media_commands(void)
{
- if ((actions & (A_MEDIA|A_MEDIAOPT)) == 0) {
+ if ((actions & (A_MEDIA|A_MEDIAOPT|A_MEDIAMODE)) == 0) {
/* Nothing to do. */
return;
}
@@ -2450,6 +2452,26 @@ setmediamode(const char *val, int d)
if ((mode = get_media_mode(type, val)) == -1)
errx(1, "invalid media mode: %s", val);
media_current = IFM_MAKEWORD(type, subtype, options, inst) | mode;
+ /* Media will be set after other processing is complete. */
+}
+
+void
+unsetmediamode(const char *val, int d)
+{
+ uint64_t type, subtype, options, inst;
+
+ init_current_media();
+
+ /* Can only issue `mode' once. */
+ if (actions & A_MEDIAMODE)
+ errx(1, "only one `mode' command may be issued");
+
+ type = IFM_TYPE(media_current);
+ subtype = IFM_SUBTYPE(media_current);
+ options = IFM_OPTIONS(media_current);
+ inst = IFM_INST(media_current);
+
+ media_current = IFM_MAKEWORD(type, subtype, options, inst) | IFM_AUTO;
/* Media will be set after other processing is complete. */
}
Re: ifconfig mode subcommand
On Tue, Jan 12, 2016 at 01:06:42PM +0100, Stefan Sperling wrote:
> Do not require users to type 'media autoselect mode ...' if all
> they want is to force a particular operating mode.
>
> This allows 11n support to be disabled by typing short commands like:
>
> ifconfig iwn0 mode 11a
> ifconfig iwn0 mode 11g
> ifconfig iwn0 mode 11b
>
> The new -mode command restores the default behaviour (mode autoselect).
>
> ok?
Slightly improved diff:
Shorten the man page blurb.
Note that 'operating mode' is also used to refer to hostap, ibss,
and monitor mode, at least in the net80211 code. The code calls
11a/b/g/n the 'phy mode'.
In the ethernet world, we have 'media instance' (IFM_INST) for
selecting a PHY. I'm not sure why wireless doesn't use IFM_INST
instead of 'mode' (IFM_MODE), but in any case changing that right
now opens a bigger can of worms. For now, I decided to just use the
word 'mode' in the man page to avoid spreading further confusion.
Use the proper shift for clearing the mode bits in the media word.
This is a no-op since 0 is being shifted but the code is clearer this way.
Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.264
diff -u -p -r1.264 ifconfig.8
--- ifconfig.8 6 Dec 2015 12:50:05 - 1.264
+++ ifconfig.8 12 Jan 2016 12:36:38 -
@@ -373,16 +373,21 @@ The routing metric can be used by routin
Higher metrics have the effect of making a route less favorable.
.It Cm mode Ar mode
If the driver for the interface supports the media selection system,
-set the specified operating mode on the interface to the given
+force the mode of the interface to the given
.Ar mode .
-For IEEE 802.11 wireless interfaces that support multiple operating modes,
+For IEEE 802.11 wireless interfaces that support multiple modes,
this directive is used to select between 802.11a
.Pq Dq 11a ,
802.11b
.Pq Dq 11b ,
-and 802.11g
-.Pq Dq 11g
-operating modes.
+802.11g
+.Pq Dq 11g,
+and 802.11n
+.Pq Dq 11n
+modes.
+.It Fl mode
+Select the mode automatically.
+This is the default for IEEE 802.11 wireless interfaces.
.It Cm mpls
Enable Multiprotocol Label Switching (MPLS) on the interface,
allowing it to send and receive MPLS traffic.
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.314
diff -u -p -r1.314 ifconfig.c
--- ifconfig.c 6 Jan 2016 21:37:00 - 1.314
+++ ifconfig.c 12 Jan 2016 12:23:53 -
@@ -193,6 +193,7 @@ voidunsetkeepalive(const char *, int);
void setmedia(const char *, int);
void setmediaopt(const char *, int);
void setmediamode(const char *, int);
+void unsetmediamode(const char *, int);
void clone_create(const char *, int);
void clone_destroy(const char *, int);
void unsetmediaopt(const char *, int);
@@ -517,6 +518,7 @@ const structcmd {
{ "mediaopt", NEXTARG,A_MEDIAOPTSET, setmediaopt },
{ "-mediaopt", NEXTARG,A_MEDIAOPTCLR, unsetmediaopt },
{ "mode", NEXTARG,A_MEDIAMODE,setmediamode },
+ { "-mode", 0, A_MEDIAMODE,unsetmediamode },
{ "instance", NEXTARG,A_MEDIAINST,setmediainst },
{ "inst", NEXTARG,A_MEDIAINST,setmediainst },
{ "lladdr", NEXTARG,0, setiflladdr },
@@ -2367,7 +2369,7 @@ void
process_media_commands(void)
{
- if ((actions & (A_MEDIA|A_MEDIAOPT)) == 0) {
+ if ((actions & (A_MEDIA|A_MEDIAOPT|A_MEDIAMODE)) == 0) {
/* Nothing to do. */
return;
}
@@ -2450,6 +2452,27 @@ setmediamode(const char *val, int d)
if ((mode = get_media_mode(type, val)) == -1)
errx(1, "invalid media mode: %s", val);
media_current = IFM_MAKEWORD(type, subtype, options, inst) | mode;
+ /* Media will be set after other processing is complete. */
+}
+
+void
+unsetmediamode(const char *val, int d)
+{
+ uint64_t type, subtype, options, inst;
+
+ init_current_media();
+
+ /* Can only issue `mode' once. */
+ if (actions & A_MEDIAMODE)
+ errx(1, "only one `mode' command may be issued");
+
+ type = IFM_TYPE(media_current);
+ subtype = IFM_SUBTYPE(media_current);
+ options = IFM_OPTIONS(media_current);
+ inst = IFM_INST(media_current);
+
+ media_current = IFM_MAKEWORD(type, subtype, options, inst) |
+ (IFM_AUTO << IFM_MSHIFT);
/* Media will be set after other processing is complete. */
}
Re: Xen virtual network (Netfront) driver
On Thu, 7 Jan 2016, Mike Belopuhov wrote:
> On 7 January 2016 at 13:17, Mark Kettenis wrote:
> >> From: Mike Belopuhov
> >> Date: Thu, 7 Jan 2016 12:02:23 +0100
> >>
> >> On 6 January 2016 at 17:58, Stefan Fritsch wrote:
> >> > On Wed, 6 Jan 2016, Mike Belopuhov wrote:
> >> >
> >> >> There's still stuff to do, but it receives and transmits reliably
> >> >> (at least on modern Xen) so I'd like to get it in. Man page will
> >> >> follow.
> >> >
> >> > I only had a quick glance at the code, but I have one comment about your
> >> > use of memory barriers. The membar_* macros are pure compiler barriers
> >> > when the openbsd kernel is compiled for UP. But since the host machine
> >> > and
> >> > xen may use SMP even in this case, I suspect the that you need hardware
> >> > memory barriers even if MULTIPROCESSOR is not defined. This does not seem
> >> > relevant for x86 because you don't use membar_sync, but it may become
> >> > relevant for arm, which is also supported by xen.
> >> >
> >>
> >> membar_{producer,consumer} are defined on arm to perform store and
> >> load memory barriers. Our arm code currently does not distinguish
> >> between an MP case and non-MP case regarding the definition of these
> >> macros, so I'm not entirely certain what are you trying to say.
I didn't check arm's implementation but new that it had non-empty
membar_{producer,consumer}. So, if it does not distinguish between an MP
case and non-MP case, then there is no problem there. But maybe you should
document somewhere which assumptions about the architecture you make, so
that they can be checked when adding a new architecture. I guess arm64
will come sooner or later and I don't know if it has exactly the same
memory model as 32bit arm.
> >
> > Not sure ARM is a good example to look at.
> >
>
> The only architectures that Xen dom0 is implemented for are i386,
> adm64 and arm, so there's no real need to look at anything else.
>
> > In principle I think that the membar_xxx() interfaces could be simple
> > compiler barriers on all our architectures, at least as long as the
> > CPU will observe its own stores in the same order as they were
> > emitted. But I think all sane CPU architectures make those
> > guarantees. At least for "normal" memory. However, we treat that as
> > an optimization. And we haven't done that for all our architectures.
> >
> > The problem with virtualization is of course that even a non-MP kernel
> > is actually running in an MP environment. If data structures are
> > shared with the hypervisor or another domain running on a different
> > CPU, proper memory barriers must be used to guarantee the other side
> > sees our stores in the right order. The typical case would be
> > populating a descriptor with some sort of validity bit. There you
> > want to make sure the other side doesn't see the valid bit set until
> > all the other parts of the descriptor have been filled in and are
> > visible. In that case a simple compiler barrier may not be enough.
Yes. With intel it's the "Reads may be reordered with older writes to
different locations but not with older writes to the same location" bit
from the memory model that is causing problems. So you have to check if
xen hits this case. virtio does (and removing the membarriers causes
observable hangs).
>
> That's what I was referring to in my example below.
>
> > This is why the virtio_membar_xxx() primitives were introduced.
> >
>
> Any idea why wasn't store and load barriers implemented separately?
No idea. virtio_membar_xxx() was modeled after the existing membar_xxx().
But AIUI membar_consumer() plus membar_producer() is not equivalent to
membar_sync() (which also prevents read vs. write reordering).
Re: klog uiomove() conversion
Martin Natano wrote:
> Below the uiomove() conversion for kern/subr_log.c. msg_buf[rsx] are all
> of type long, but are always positive. This diff prevents truncation of
> uio_resid (and l) due to min() usage.
Makes sense.
ok?
> Index: kern/subr_log.c
> ===
> RCS file: /cvs/src/sys/kern/subr_log.c,v
> retrieving revision 1.36
> diff -u -p -u -r1.36 subr_log.c
> --- kern/subr_log.c 7 Jan 2016 12:27:07 - 1.36
> +++ kern/subr_log.c 9 Jan 2016 14:49:27 -
> @@ -180,7 +180,7 @@ int
> logread(dev_t dev, struct uio *uio, int flag)
> {
> struct msgbuf *mbp = msgbufp;
> - long l;
> + size_t l;
> int s;
> int error = 0;
>
> @@ -202,13 +202,14 @@ logread(dev_t dev, struct uio *uio, int
> logsoftc.sc_state &= ~LOG_RDWAIT;
>
> while (uio->uio_resid > 0) {
> - l = mbp->msg_bufx - mbp->msg_bufr;
> - if (l < 0)
> + if (mbp->msg_bufx >= mbp->msg_bufr)
> + l = mbp->msg_bufx - mbp->msg_bufr;
> + else
> l = mbp->msg_bufs - mbp->msg_bufr;
> - l = min(l, uio->uio_resid);
> + l = ulmin(l, uio->uio_resid);
> if (l == 0)
> break;
> - error = uiomovei(&mbp->msg_bufc[mbp->msg_bufr], (int)l, uio);
> + error = uiomove(&mbp->msg_bufc[mbp->msg_bufr], l, uio);
> if (error)
> break;
> mbp->msg_bufr += l;
>
> cheers,
> natano
>
Re: fix iwn firmware error during init
Stefan Sperling wrote:
> I've run into an issue where iwn(4) fails to init the hardware.
>
> Running 'ifconfig iwn0 scan' resulted in:
>
> setting configuration
> iwn0: fatal firmware error
> firmware error log:
> error type = "SYSASSERT" (0x0005)
> program counter = 0x00022088
> source line = 0x00A4
> error data = 0x00A4
> branch link = 0x0002225800022258
> interrupt link = 0x1532
> time= 27873
> driver status:
> tx ring 0: qid=0 cur=0 queued=0
> tx ring 1: qid=1 cur=0 queued=0
> tx ring 2: qid=2 cur=0 queued=0
> tx ring 3: qid=3 cur=0 queued=0
> tx ring 4: qid=4 cur=6 queued=0
> tx ring 5: qid=5 cur=0 queued=0
> tx ring 6: qid=6 cur=0 queued=0
> tx ring 7: qid=7 cur=0 queued=0
> tx ring 8: qid=8 cur=0 queued=0
> tx ring 9: qid=9 cur=0 queued=0
> tx ring 10: qid=10 cur=0 queued=0
> tx ring 11: qid=11 cur=0 queued=0
> tx ring 12: qid=12 cur=0 queued=0
> tx ring 13: qid=13 cur=0 queued=0
> tx ring 14: qid=14 cur=0 queued=0
> tx ring 15: qid=15 cur=0 queued=0
> tx ring 16: qid=16 cur=0 queued=0
> tx ring 17: qid=17 cur=0 queued=0
> tx ring 18: qid=18 cur=0 queued=0
> tx ring 19: qid=19 cur=0 queued=0
> rx ring: cur=7
> 802.11 state 0
> iwn0: RXON command failed
> iwn0: could not configure device
> iwn0: could not load firmware .data section
> iwn0: could not load firmware
> iwn0: could not initialize hardware
>
> A debug printf revealed the rxon command channel was set to zero:
>
> iwn_config: rxon chan 0 flags 40008000 cck f ofdm ff
>
> Fix a misplaced curly brace while here...
Cannot comment on the code unfortunately. But with a current kernel
I regularly get the above error on startup since today. Your diff fixes it.
I'd be happy to see a fix for this to go in :-)
> ok?
>
> Index: if_iwn.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
> retrieving revision 1.153
> diff -u -p -r1.153 if_iwn.c
> --- if_iwn.c 7 Jan 2016 23:08:38 - 1.153
> +++ if_iwn.c 9 Jan 2016 21:12:23 -
> @@ -3429,7 +3429,7 @@ iwn_set_link_quality(struct iwn_softc *s
> /* Next retry at immediate lower bit-rate. */
> if (txrate > 0)
> txrate--;
> - }
> + }
> }
>
> return iwn_cmd(sc, IWN_CMD_LINK_QUALITY, &linkq, sizeof linkq, 1);
> @@ -4455,15 +4455,9 @@ iwn_config(struct iwn_softc *sc)
> IEEE80211_ADDR_COPY(ic->ic_myaddr, LLADDR(ifp->if_sadl));
> IEEE80211_ADDR_COPY(sc->rxon.myaddr, ic->ic_myaddr);
> IEEE80211_ADDR_COPY(sc->rxon.wlap, ic->ic_myaddr);
> - sc->rxon.chan = ieee80211_chan2ieee(ic, ic->ic_ibss_chan);
> + sc->rxon.chan = 1;
> sc->rxon.flags = htole32(IWN_RXON_TSF | IWN_RXON_CTS_TO_SELF);
> - if (IEEE80211_IS_CHAN_2GHZ(ic->ic_ibss_chan)) {
> - sc->rxon.flags |= htole32(IWN_RXON_AUTO | IWN_RXON_24GHZ);
> - if (ic->ic_flags & IEEE80211_F_USEPROT)
> - sc->rxon.flags |= htole32(IWN_RXON_TGG_PROT);
> - DPRINTF(("%s: 2ghz prot 0x%x\n", __func__,
> - le32toh(sc->rxon.flags)));
> - }
> + sc->rxon.flags |= htole32(IWN_RXON_AUTO | IWN_RXON_24GHZ);
> switch (ic->ic_opmode) {
> case IEEE80211_M_STA:
> sc->rxon.mode = IWN_MODE_STA;
> @@ -4489,6 +4483,9 @@ iwn_config(struct iwn_softc *sc)
> IWN_RXCHAIN_IDLE_COUNT(2);
> sc->rxon.rxchain = htole16(rxchain);
> DPRINTF(("setting configuration\n"));
> + DPRINTF(("%s: rxon chan %d flags %x cck %x ofdm %x\n", __func__,
> + sc->rxon.chan, le32toh(sc->rxon.flags), sc->rxon.cck_mask,
> + sc->rxon.ofdm_mask));
> error = iwn_cmd(sc, IWN_CMD_RXON, &sc->rxon, sc->rxonsz, 0);
> if (error != 0) {
> printf("%s: RXON command failed\n", sc->sc_dev.dv_xname);
>
gcc typo
Hi, this looks like a typo in gcc. Jan Index: gnu/gcc/gcc/config/mt/mt.c === RCS file: /cvs/src/gnu/gcc/gcc/config/mt/mt.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 mt.c --- gnu/gcc/gcc/config/mt/mt.c 15 Oct 2009 17:11:30 - 1.1.1.1 +++ gnu/gcc/gcc/config/mt/mt.c 12 Jan 2016 20:07:28 - @@ -475,7 +475,7 @@ mt_print_operand (FILE * file, rtx x, in break; default: - fprintf(file, "Uknown code: %d", GET_CODE (x)); + fprintf(file, "Unknown code: %d", GET_CODE (x)); break; }
Fix aml_find_node(9)
This function is really weird. It looks for nodes with a specific
name, and calls a callback function if a match is found. But it
doesn't just look at the children of the passed node, it also looks
atthe passed node itself and all of its children. That is really
unexpected, and jcs@ fell into that trap. The result is that the
dwiic(4) code actually tries to attach all i2c devices to all i2c
controllers ;).
I looked at all the use cases, and AFAIK the intention always is to
just look at the children of the passed node. This diff makes it so.
ok?
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.218
diff -u -p -r1.218 dsdt.c
--- dsdt.c 20 Aug 2015 20:50:10 - 1.218
+++ dsdt.c 12 Jan 2016 21:01:48 -
@@ -1249,26 +1249,26 @@ aml_walknodes(struct aml_node *node, int
nodecb(node, arg);
}
-int
+void
aml_find_node(struct aml_node *node, const char *name,
int (*cbproc)(struct aml_node *, void *arg), void *arg)
{
+ struct aml_node *child;
const char *nn;
- int st = 0;
- while (node) {
- if ((nn = node->name) != NULL) {
+ SIMPLEQ_FOREACH(child, &node->son, sib) {
+ nn = child->name;
+ if ((nn = child->name) != NULL) {
if (*nn == AMLOP_ROOTCHAR) nn++;
while (*nn == AMLOP_PARENTPREFIX) nn++;
- if (!strcmp(name, nn))
- st = cbproc(node, arg);
+ if (strcmp(name, nn) == 0) {
+ /* Only recurse if cbproc() wants us to */
+ if (cbproc(child, arg) == 0)
+ continue;
+ }
}
- /* Only recurse if cbproc() wants us to */
- if (!st)
- aml_find_node(SIMPLEQ_FIRST(&node->son), name, cbproc,
arg);
- node = SIMPLEQ_NEXT(node, sib);
+ aml_find_node(child, name, cbproc, arg);
}
- return st;
}
/*
Index: dsdt.h
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.h,v
retrieving revision 1.65
diff -u -p -r1.65 dsdt.h
--- dsdt.h 9 Jan 2016 10:50:43 - 1.65
+++ dsdt.h 12 Jan 2016 21:01:48 -
@@ -53,7 +53,7 @@ void aml_showvalue(struct aml_value *,
void aml_walkroot(void);
void aml_walktree(struct aml_node *);
-intaml_find_node(struct aml_node *, const char *,
+void aml_find_node(struct aml_node *, const char *,
int (*)(struct aml_node *, void *), void *);
intacpi_parse_aml(struct acpi_softc *, u_int8_t *,
u_int32_t);
octeon usb devs
Likely some other configs have more exhaustive list of devices supported, but even these would be great to have, especially uhub* at uhub?, as ERL physically has only one port limiting it's use to a single umass. -Artturi Index: sys/arch/octeon/conf/GENERIC === RCS file: /cvs/src/sys/arch/octeon/conf/GENERIC,v retrieving revision 1.23 diff -u -p -r1.23 GENERIC --- sys/arch/octeon/conf/GENERIC18 Aug 2015 12:49:41 - 1.23 +++ sys/arch/octeon/conf/GENERIC12 Jan 2016 21:30:49 - @@ -69,8 +69,37 @@ dwctwo0 at iobus? irq 56 usb* at dwctwo? # USB devices -uhub* at usb? # USB Hubs +uhub* at usb? +uhub* at uhub? +uhidev*at uhub? +ukbd* at uhidev? +wskbd* at ukbd? mux 1 umass* at uhub? +aue* at uhub?# ADMtek AN986 Pegasus Ethernet +atu* at uhub?# Atmel AT76c50x based 802.11b +axe* at uhub?# ASIX Electronics AX88172 USB Ethernet +axen* at uhub?# ASIX Electronics AX88179 USB Ethernet +cue* at uhub?# CATC USB-EL1201A based Ethernet +kue* at uhub?# Kawasaki KL5KUSB101B based Ethernet +smsc* at uhub?# SMSC LAN95xx Ethernet +cdce* at uhub?# CDC Ethernet +udav* at uhub?# Davicom DM9601 based Ethernet +mos* at uhub?# MOSCHIP MCS7730/7830 10/100 Ethernet +url* at uhub?# Realtek RTL8150L based adapters +wi*at uhub?# WaveLAN IEEE 802.11DS +upl* at uhub?# Prolific PL2301/PL2302 host-to-host +ugl* at uhub?# Genesys Logic GL620USB-A host-to-host +ural* at uhub?# Ralink RT2500 +rum* at uhub?# Ralink RT2501USB/RT2601USB +run* at uhub?# Ralink RT2700U/RT2800U/RT3000U +zyd* at uhub?# Zydas ZD1211 +upgt* at uhub?# Conexant/Intersil PrismGT SoftMAC USB +urtw* at uhub?# Realtek 8187 +urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU +rsu* at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU +uath* at uhub?# Atheros AR5005UG/AR5005UX +otus* at uhub?# Atheros AR9001U +athn* at uhub?# Atheros AR9002U scsibus* at scsi? sd*at scsibus? Index: sys/arch/octeon/conf/RAMDISK === RCS file: /cvs/src/sys/arch/octeon/conf/RAMDISK,v retrieving revision 1.22 diff -u -p -r1.22 RAMDISK --- sys/arch/octeon/conf/RAMDISK18 Aug 2015 12:49:41 - 1.22 +++ sys/arch/octeon/conf/RAMDISK12 Jan 2016 21:30:49 - @@ -57,7 +57,36 @@ wd* at pciide? flags 0x dwctwo0at iobus0 irq 56 usb* at dwctwo? uhub* at usb? +uhub* at uhub? +uhidev*at uhub? +ukbd* at uhidev? +wskbd* at ukbd? mux 1 umass* at uhub? +aue* at uhub?# ADMtek AN986 Pegasus Ethernet +atu* at uhub?# Atmel AT76c50x based 802.11b +axe* at uhub?# ASIX Electronics AX88172 USB Ethernet +axen* at uhub?# ASIX Electronics AX88179 USB Ethernet +cue* at uhub?# CATC USB-EL1201A based Ethernet +kue* at uhub?# Kawasaki KL5KUSB101B based Ethernet +smsc* at uhub?# SMSC LAN95xx Ethernet +cdce* at uhub?# CDC Ethernet +udav* at uhub?# Davicom DM9601 based Ethernet +mos* at uhub?# MOSCHIP MCS7730/7830 10/100 Ethernet +url* at uhub?# Realtek RTL8150L based adapters +wi*at uhub?# WaveLAN IEEE 802.11DS +upl* at uhub?# Prolific PL2301/PL2302 host-to-host +ugl* at uhub?# Genesys Logic GL620USB-A host-to-host +ural* at uhub?# Ralink RT2500 +rum* at uhub?# Ralink RT2501USB/RT2601USB +run* at uhub?# Ralink RT2700U/RT2800U/RT3000U +zyd* at uhub?# Zydas ZD1211 +upgt* at uhub?# Conexant/Intersil PrismGT SoftMAC USB +urtw* at uhub?# Realtek 8187 +urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU +rsu* at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU +uath* at uhub?# Atheros AR5005UG/AR5005UX +otus* at uhub?# Atheros AR9001U +at
Re: Problem with svlan(4) and bge(4)
Hi David, > naddy is right, the extre header confuses things. i just rewrote > vlan(4) and thought this could happen. > > this is a minimal diff that should work. > > can you try this and see? > It works like a charm on both bge(4) and em(4) in my test setup. Thank you, Denis
Re: fix iwn firmware error during init
On Tue, Jan 12, 2016 at 11:59:08AM +0100, Stefan Sperling wrote:
> On Sat, Jan 09, 2016 at 10:25:45PM +0100, Stefan Sperling wrote:
> > I've run into an issue where iwn(4) fails to init the hardware.
> >
> > Running 'ifconfig iwn0 scan' resulted in:
> >
> > setting configuration
> > iwn0: fatal firmware error
> > firmware error log:
> > error type = "SYSASSERT" (0x0005)
> > program counter = 0x00022088
> > source line = 0x00A4
> > error data = 0x00A4
> > branch link = 0x0002225800022258
> > interrupt link = 0x1532
> > time= 27873
> > driver status:
> > tx ring 0: qid=0 cur=0 queued=0
> > tx ring 1: qid=1 cur=0 queued=0
> > tx ring 2: qid=2 cur=0 queued=0
> > tx ring 3: qid=3 cur=0 queued=0
> > tx ring 4: qid=4 cur=6 queued=0
> > tx ring 5: qid=5 cur=0 queued=0
> > tx ring 6: qid=6 cur=0 queued=0
> > tx ring 7: qid=7 cur=0 queued=0
> > tx ring 8: qid=8 cur=0 queued=0
> > tx ring 9: qid=9 cur=0 queued=0
> > tx ring 10: qid=10 cur=0 queued=0
> > tx ring 11: qid=11 cur=0 queued=0
> > tx ring 12: qid=12 cur=0 queued=0
> > tx ring 13: qid=13 cur=0 queued=0
> > tx ring 14: qid=14 cur=0 queued=0
> > tx ring 15: qid=15 cur=0 queued=0
> > tx ring 16: qid=16 cur=0 queued=0
> > tx ring 17: qid=17 cur=0 queued=0
> > tx ring 18: qid=18 cur=0 queued=0
> > tx ring 19: qid=19 cur=0 queued=0
> > rx ring: cur=7
> > 802.11 state 0
> > iwn0: RXON command failed
> > iwn0: could not configure device
> > iwn0: could not load firmware .data section
> > iwn0: could not load firmware
> > iwn0: could not initialize hardware
> >
> > A debug printf revealed the rxon command channel was set to zero:
> >
> > iwn_config: rxon chan 0 flags 40008000 cck f ofdm ff
> >
> > I haven't been able to reproduce the problem with the diff below.
> > Note that this code runs during hardware initialization only.
> > It shouldn't really matter what channel we set here as long as
> > it isn't zero.
> >
> > Fix a misplaced curly brace while here...
> >
> > ok?
>
> Anyone?
>
> I've been running with this for 3 days without issues.
>
This fixed it for me.
OK reyk@
> > Index: if_iwn.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
> > retrieving revision 1.153
> > diff -u -p -r1.153 if_iwn.c
> > --- if_iwn.c7 Jan 2016 23:08:38 - 1.153
> > +++ if_iwn.c9 Jan 2016 21:12:23 -
> > @@ -3429,7 +3429,7 @@ iwn_set_link_quality(struct iwn_softc *s
> > /* Next retry at immediate lower bit-rate. */
> > if (txrate > 0)
> > txrate--;
> > - }
> > + }
> > }
> >
> > return iwn_cmd(sc, IWN_CMD_LINK_QUALITY, &linkq, sizeof linkq, 1);
> > @@ -4455,15 +4455,9 @@ iwn_config(struct iwn_softc *sc)
> > IEEE80211_ADDR_COPY(ic->ic_myaddr, LLADDR(ifp->if_sadl));
> > IEEE80211_ADDR_COPY(sc->rxon.myaddr, ic->ic_myaddr);
> > IEEE80211_ADDR_COPY(sc->rxon.wlap, ic->ic_myaddr);
> > - sc->rxon.chan = ieee80211_chan2ieee(ic, ic->ic_ibss_chan);
> > + sc->rxon.chan = 1;
> > sc->rxon.flags = htole32(IWN_RXON_TSF | IWN_RXON_CTS_TO_SELF);
> > - if (IEEE80211_IS_CHAN_2GHZ(ic->ic_ibss_chan)) {
> > - sc->rxon.flags |= htole32(IWN_RXON_AUTO | IWN_RXON_24GHZ);
> > - if (ic->ic_flags & IEEE80211_F_USEPROT)
> > - sc->rxon.flags |= htole32(IWN_RXON_TGG_PROT);
> > - DPRINTF(("%s: 2ghz prot 0x%x\n", __func__,
> > - le32toh(sc->rxon.flags)));
> > - }
> > + sc->rxon.flags |= htole32(IWN_RXON_AUTO | IWN_RXON_24GHZ);
> > switch (ic->ic_opmode) {
> > case IEEE80211_M_STA:
> > sc->rxon.mode = IWN_MODE_STA;
> > @@ -4489,6 +4483,9 @@ iwn_config(struct iwn_softc *sc)
> > IWN_RXCHAIN_IDLE_COUNT(2);
> > sc->rxon.rxchain = htole16(rxchain);
> > DPRINTF(("setting configuration\n"));
> > + DPRINTF(("%s: rxon chan %d flags %x cck %x ofdm %x\n", __func__,
> > + sc->rxon.chan, le32toh(sc->rxon.flags), sc->rxon.cck_mask,
> > + sc->rxon.ofdm_mask));
> > error = iwn_cmd(sc, IWN_CMD_RXON, &sc->rxon, sc->rxonsz, 0);
> > if (error != 0) {
> > printf("%s: RXON command failed\n", sc->sc_dev.dv_xname);
> >
>
--
Re: fix iwn firmware error during init
On Tue, Jan 12, 2016 at 11:59 +0100, Stefan Sperling wrote: > On Sat, Jan 09, 2016 at 10:25:45PM +0100, Stefan Sperling wrote: > > I've run into an issue where iwn(4) fails to init the hardware. > > > > Running 'ifconfig iwn0 scan' resulted in: > > > > setting configuration > > iwn0: fatal firmware error > > firmware error log: > > error type = "SYSASSERT" (0x0005) > > program counter = 0x00022088 > > source line = 0x00A4 > > error data = 0x00A4 > > branch link = 0x0002225800022258 > > interrupt link = 0x1532 > > time= 27873 > > driver status: > > tx ring 0: qid=0 cur=0 queued=0 > > tx ring 1: qid=1 cur=0 queued=0 > > tx ring 2: qid=2 cur=0 queued=0 > > tx ring 3: qid=3 cur=0 queued=0 > > tx ring 4: qid=4 cur=6 queued=0 > > tx ring 5: qid=5 cur=0 queued=0 > > tx ring 6: qid=6 cur=0 queued=0 > > tx ring 7: qid=7 cur=0 queued=0 > > tx ring 8: qid=8 cur=0 queued=0 > > tx ring 9: qid=9 cur=0 queued=0 > > tx ring 10: qid=10 cur=0 queued=0 > > tx ring 11: qid=11 cur=0 queued=0 > > tx ring 12: qid=12 cur=0 queued=0 > > tx ring 13: qid=13 cur=0 queued=0 > > tx ring 14: qid=14 cur=0 queued=0 > > tx ring 15: qid=15 cur=0 queued=0 > > tx ring 16: qid=16 cur=0 queued=0 > > tx ring 17: qid=17 cur=0 queued=0 > > tx ring 18: qid=18 cur=0 queued=0 > > tx ring 19: qid=19 cur=0 queued=0 > > rx ring: cur=7 > > 802.11 state 0 > > iwn0: RXON command failed > > iwn0: could not configure device > > iwn0: could not load firmware .data section > > iwn0: could not load firmware > > iwn0: could not initialize hardware > > > > A debug printf revealed the rxon command channel was set to zero: > > > > iwn_config: rxon chan 0 flags 40008000 cck f ofdm ff > > > > I haven't been able to reproduce the problem with the diff below. > > Note that this code runs during hardware initialization only. > > It shouldn't really matter what channel we set here as long as > > it isn't zero. > > > > Fix a misplaced curly brace while here... > > > > ok? > > Anyone? > > I've been running with this for 3 days without issues. > I can't judge the diff, but it fixes iwn in my x220. Intel WiFi Link 1000" rev 0x00: msi, MIMO 1T2R, BGS Thanks!
Re: [diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)
On Tue, 12 Jan 2016 01:37:39 +0200
Sviatoslav Chagaev wrote:
> On Sun, 10 Jan 2016 21:28:31 +0100
> Joerg Jung wrote:
> > On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote:
> >
> > > An Intel developer claims [2] that it's not a bug in Intel KMS driver and
> > > people
> > > claim [3] the problem goes away when booting in legacy BIOS mode.
> >
> > That makes no sense to me. If the problem goes aways when booting
> > legacy BIOS, so it must be a bug when not, right?
>
> Judging by the code at e.g. sys/dev/pci/drm/i915/intel_panel.c:984, it
> seems Intel KMS driver expects BIOS or EFI to configure backlight,
> then reads these values and uses them itself.
>
> I found documentation for Intel Haswell [1] and glanced over
> descriptions of relevant registers (BLC_PWM_CTL, BLC_PWM2_CTL,
> BLC_PWM_DATA, BLC_MISC_CTL, BLM_HIST_CTL, BLM_HIST_BIN, BLM_HIST_GUARD,
> UTIL_PIN_CTL, SBLC_PWM_CTL1, SBLC_PWM_CTL2), they are confusing...
>
> Based on these, I agree, it might be a bug in Intel KMS.
>
> I'll add debug prints and play with these registers, maybe I'll spot
> some incorrect values.
>
> [1]
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-hsw-commandreference-registers_0_0.pdf
>
Had no luck with Intel KMS:
Added register dump to every backlight operation, see first diff.
State of registers I get from EFI:
pch_dump_backlight_registers(): pch_setup_backlight
MY_BLC_PWM_CTL= 0x; MY_BLC_PWM_DATA = 0x
MY_BLC_PWM_DATA2 = 0x; MY_BLM_HIST_CTL = 0x
MY_BLM_HIST_BIN = 0x; MY_BLM_HIST_GUARD = 0x
MY_BLC_PWM2_CTL = 0x6000; MY_BLC_MISC_CTL = 0x
MY_UTIL_PIN_CTL = 0x; MY_SBLC_PWM_CTL1 = 0xc000
MY_SBLC_PWM_CTL2 = 0x0ad901c3;
State of registers after Intel KMS configures them:
pch_dump_backlight_registers(): pch_set_backlight
MY_BLC_PWM_CTL= 0xe000; MY_BLC_PWM_DATA = 0x0ad9
MY_BLC_PWM_DATA2 = 0x; MY_BLM_HIST_CTL = 0x0006
MY_BLM_HIST_BIN = 0x; MY_BLM_HIST_GUARD = 0x
MY_BLC_PWM2_CTL = 0x6000; MY_BLC_MISC_CTL = 0x
MY_UTIL_PIN_CTL = 0x; MY_SBLC_PWM_CTL1 = 0x8000
MY_SBLC_PWM_CTL2 = 0x0ad9;
BLC_PWM_CTL change seems strange.
Modified pch_*_backlight() functions so they do not change the
configuration set by EFI, see second diff, but observed no change in
behaviour.
Index: sys/dev/pci/drm/i915/i915_reg.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_reg.h,v
retrieving revision 1.11
diff -u -p -r1.11 i915_reg.h
--- sys/dev/pci/drm/i915/i915_reg.h 25 Sep 2015 16:15:19 - 1.11
+++ sys/dev/pci/drm/i915/i915_reg.h 12 Jan 2016 02:54:49 -
@@ -2493,6 +2493,18 @@
#define BACKLIGHT_DUTY_CYCLE_MASK_PNV(0xfffe)
#define BLM_POLARITY_PNV (1 << 0) /* pnv only */
+#define MY_BLC_PWM_CTL 0x48250
+#define MY_BLC_PWM_DATA0x48254
+#define MY_BLC_PWM_DATA2 0x48354
+#define MY_BLM_HIST_CTL0x48260
+#define MY_BLM_HIST_BIN0x48264
+#define MY_BLM_HIST_GUARD 0x48268
+#define MY_BLC_PWM2_CTL0x48350
+#define MY_BLC_MISC_CTL0x48360
+#define MY_UTIL_PIN_CTL0x48400
+#define MY_SBLC_PWM_CTL1 0xc8250
+#define MY_SBLC_PWM_CTL2 0xc8254
+
#define BLC_HIST_CTL (dev_priv->info->display_mmio_offset + 0x61260)
/* New registers for PCH-split platforms. Safe where new bits show up, the
Index: sys/dev/pci/drm/i915/intel_panel.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_panel.c,v
retrieving revision 1.11
diff -u -p -r1.11 intel_panel.c
--- sys/dev/pci/drm/i915/intel_panel.c 23 Sep 2015 23:12:12 - 1.11
+++ sys/dev/pci/drm/i915/intel_panel.c 12 Jan 2016 02:54:49 -
@@ -36,6 +36,38 @@
#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+void pch_dump_backlight_registers(struct intel_connector *connector, const
char *msg)
+{
+ struct drm_device *dev = connector->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 i = 0;
+ u32 value;
+
+ printf("%s(): %s\n", __func__, msg);
+
+#define Y(register)\
+ value = I915_READ(register);\
+ printf("%-17s = 0x%08x%s", \
+ #register, value, (i++ & 1) ? "\n" : "; ");
+
+ Y(MY_BLC_PWM_CTL);
+ Y(MY_BLC_PWM_DATA);
+ Y(MY_BLC_PWM_DATA2);
+ Y(MY_BLM_HIST_CTL);
+ Y(MY_BLM_HIST_BIN);
+ Y(MY_BLM_HIST_GUARD);
+ Y(MY_BLC_PWM2_CTL);
+ Y(MY_BLC_MISC_CTL);
+ Y(MY_UTIL_PIN_CTL);
+ Y(MY_SBLC_PWM_CTL1);
+ Y(MY_SBLC_PWM_CTL2);
+
+ if (i & 1)
+ printf("\n");
+
+#undef Y
+}
+
void
intel_fixed_panel_mode(const struct drm_display_mode *fixed_mod
ntpd.conf and Google
Hello, $ fgrep constraint /etc/ntpd.conf constraints from "https://www.google.com"; $ www.google.com and other Google services are not accessible from countries like China or Vietnam. It's easy enough for people to change their ntpd.conf if necessary but how about using a default value that is more likely to work for everyone? Something like https://www.un.org/ for example. Cheers, Philippe
Simplify less(1) off_t formatting
I'm working on bigger simplifications for less's string formatting, but
this is a good start. We've removed the off_t aliases for linenums and
positions, so we now have two identical sets of off_t formatting and
appending functions. The below diff unifies them.
As you can see, there is more cleanup to be done.
Thoughts?
Index: less.h
===
RCS file: /cvs/src/usr.bin/less/less.h,v
retrieving revision 1.21
diff -u -p -r1.21 less.h
--- less.h 12 Jan 2016 17:48:04 - 1.21
+++ less.h 13 Jan 2016 04:43:15 -
@@ -205,6 +205,5 @@ struct textlist {
#include "funcs.h"
/* Functions not included in funcs.h */
-void postoa(off_t, char *, size_t);
-void linenumtoa(off_t, char *, size_t);
+void offttoa(off_t, char *, size_t);
void inttoa(int, char *, size_t);
Index: line.c
===
RCS file: /cvs/src/usr.bin/less/line.c,v
retrieving revision 1.16
diff -u -p -r1.16 line.c
--- line.c 12 Jan 2016 17:48:04 - 1.16
+++ line.c 13 Jan 2016 04:43:15 -
@@ -178,7 +178,7 @@ plinenum(off_t pos)
char buf[INT_STRLEN_BOUND(pos) + 2];
int n;
- linenumtoa(linenum, buf, sizeof (buf));
+ offttoa(linenum, buf, sizeof(buf));
n = strlen(buf);
if (n < MIN_LINENUM_WIDTH)
n = MIN_LINENUM_WIDTH;
Index: output.c
===
RCS file: /cvs/src/usr.bin/less/output.c,v
retrieving revision 1.14
diff -u -p -r1.14 output.c
--- output.c12 Jan 2016 17:48:04 - 1.14
+++ output.c13 Jan 2016 04:43:15 -
@@ -148,8 +148,7 @@ funcname(type num, char *buf, size_t len
(void) strlcpy(buf, s, len);\
}
-TYPE_TO_A_FUNC(postoa, off_t)
-TYPE_TO_A_FUNC(linenumtoa, off_t)
+TYPE_TO_A_FUNC(offttoa, off_t)
TYPE_TO_A_FUNC(inttoa, int)
/*
@@ -173,7 +172,7 @@ iprint_linenum(off_t num)
{
char buf[INT_STRLEN_BOUND(num)];
- linenumtoa(num, buf, sizeof (buf));
+ offttoa(num, buf, sizeof(buf));
putstr(buf);
return (strlen(buf));
}
Index: prompt.c
===
RCS file: /cvs/src/usr.bin/less/prompt.c,v
retrieving revision 1.19
diff -u -p -r1.19 prompt.c
--- prompt.c12 Jan 2016 23:01:23 - 1.19
+++ prompt.c13 Jan 2016 04:43:15 -
@@ -116,23 +116,11 @@ ap_char(char c)
* Append a off_t (as a decimal integer) to the end of the message.
*/
static void
-ap_pos(off_t pos)
+ap_off_t(off_t pos)
{
char buf[INT_STRLEN_BOUND(pos) + 2];
- postoa(pos, buf, sizeof buf);
- ap_str(buf);
-}
-
-/*
- * Append a line number to the end of the message.
- */
-static void
-ap_linenum(off_t linenum)
-{
- char buf[INT_STRLEN_BOUND(linenum) + 2];
-
- linenumtoa(linenum, buf, sizeof buf);
+ offttoa(pos, buf, sizeof(buf));
ap_str(buf);
}
@@ -245,7 +233,7 @@ protochar(int c, int where)
case 'b': /* Current byte offset */
pos = curr_byte(where);
if (pos != -1)
- ap_pos(pos);
+ ap_off_t(pos);
else
ap_quest();
break;
@@ -255,7 +243,7 @@ protochar(int c, int where)
case 'd': /* Current page number */
linenum = currline(where);
if (linenum > 0 && sc_height > 1)
- ap_linenum(PAGE_NUM(linenum));
+ ap_off_t(PAGE_NUM(linenum));
else
ap_quest();
break;
@@ -266,13 +254,13 @@ protochar(int c, int where)
ap_quest();
} else if (len == 0) {
/* An empty file has no pages. */
- ap_linenum(0);
+ ap_off_t(0);
} else {
linenum = find_linenum(len - 1);
if (linenum <= 0)
ap_quest();
else
- ap_linenum(PAGE_NUM(linenum));
+ ap_off_t(PAGE_NUM(linenum));
}
break;
case 'E': /* Editor name */
@@ -293,7 +281,7 @@ protochar(int c, int where)
case 'l': /* Current line number */
linenum = currline(where);
if (linenum != 0)
- ap_linenum(linenum);
+ ap_off_t(linenum);
else
ap_quest();
break;
@@ -303,7 +291,7 @@ protochar(int c, int where)
(linenum = find_linenum(len)) <= 0)
ap_quest();
else
- ap_linenum(linenum-1);
+ ap_off_t(linenum-
Re: ntpd.conf and Google
> $ fgrep constraint /etc/ntpd.conf > constraints from "https://www.google.com"; > $ > > www.google.com and other Google services are not accessible from > countries like China or Vietnam. It's easy enough for people to > change their ntpd.conf if necessary but how about using a default > value that is more likely to work for everyone? Something like > https://www.un.org/ for example. That looks like a centralized service operated on a single provider network without global load balancing "features", the DNS TTL alone hints this would be unsuitable. Probably not built to the same scale, does not feel right to me. There are are a lot of variables involved in making a selection, and the result is certainly imperfect. I get where you are coming from, but you can probably see why we currently choose what we do.
