Re: rwho on OpenBSD 5.6
Stuart Henderson wrote: > On 2014/11/09 22:08, Job Snijders wrote: > > On Sun, Nov 09, 2014 at 01:36:59PM -0700, Theo de Raadt wrote: > > > >I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, > > > >rshd, rwho, rwhod, etc have been removed (at least according to the > > > >Changelog). However, the upgrade instructions fail to mention that files > > > >like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. > > > > > > How much of a catastrophy is this? > > > > > > Question for the community: Do you want the upgrade instructions to > > > be 100% useful, or 100% complete? > > > > 100% complete should be the goal. > > > > I expect a system that is upgraded from 5.5 to 5.6 (following the > > upgrade documentation) to be in the _exact_ same state as a clean 5.6 > > installation, barring changes local to the system. > > I disagree. Consider the case of default MTA or default web server. > I expect the upgrade instructions to show me how to upgrade the system > keeping it running as before as much as possible. > > If I wanted it to work how it does on a clean install, I'd just do a > clean install... The old binaries won't run on the new kernel anyway. When the default has been changed but the old default remains, the upgrade instructions should say so and say what to do to change the default. You can continue running the old default if you want. When the old software has been removed completely, the old binaries are useless anyway. The instructions should be complete, but nobody should ever run who on a 5.6 system. Therefore you could claim running rwho is undefined, so it doesn't matter whether it still exists or not. Maybe this isn't such a good idea if /usr/bin comes before /usr/local/bin in your path. -- Martin Brandenburg
mail(1) -r argument with mailbox
This makes mail(1) reject -r when not sending a message as it already does for -s, -c, and -b. I was going to write a patch to take -r with a mailbox but realized I could set from interactively so nobody would want that. -- Martin Index: main.c === RCS file: /cvs/src/usr.bin/mail/main.c,v retrieving revision 1.28 diff -u -p -r1.28 main.c --- main.c 20 Jan 2015 16:59:07 - 1.28 +++ main.c 21 Jan 2015 22:57:51 - @@ -185,8 +185,10 @@ main(int argc, char **argv) /* * Check for inconsistent arguments. */ - if (to == NULL && (subject != NULL || cc != NULL || bcc != NULL)) - errx(1, "You must specify direct recipients with -s, -c, or -b"); + if (to == NULL && (subject != NULL || cc != NULL || bcc != NULL || + fromaddr != NULL)) + errx(1, "You must specify direct recipients with -s, -c, -b, " + "or -r"); /* * Block SIGINT except where we install an explicit handler for it. */
From lines and mail.local
When mail comes in for local delivery with two consecutive lines
beginning 'From ' only the first is escaped with a >. Two non-
consecutive 'From ' lines in one message does not cause this.
Connect to the local mail server and send
> From blah blah
> From blah blah
And you see in /var/mail/...
> >From blah blah
> From blah blah
Needless to say, this confuses practically everything handling mbox
files.
I'm not sure what eline was supposed to accomplish below, but it doesn't
seem to help since all 'From ' lines need to be escaped.
-- Martin
Index: mail.local.c
===
RCS file: /cvs/src/libexec/mail.local/mail.local.c,v
retrieving revision 1.33
diff -u -p -r1.33 mail.local.c
--- mail.local.c16 Jan 2015 06:39:50 - 1.33
+++ mail.local.c6 Feb 2015 15:00:13 -
@@ -117,7 +117,7 @@ storemail(char *from)
{
FILE *fp = NULL;
time_t tval;
- int fd, eline;
+ int fd;
size_t len;
char *line, *tbuf;
@@ -131,7 +131,7 @@ storemail(char *from)
(void)time(&tval);
(void)fprintf(fp, "From %s %s", from, ctime(&tval));
- for (eline = 1, tbuf = NULL; (line = fgetln(stdin, &len));) {
+ for (tbuf = NULL; (line = fgetln(stdin, &len));) {
/* We have to NUL-terminate the line since fgetln does not */
if (line[len - 1] == '\n')
line[len - 1] = '\0';
@@ -143,14 +143,8 @@ storemail(char *from)
tbuf[len] = '\0';
line = tbuf;
}
- if (line[0] == '\0')
- eline = 1;
- else {
- if (eline && line[0] == 'F' && len > 5 &&
- !memcmp(line, "From ", 5))
- (void)putc('>', fp);
- eline = 0;
- }
+ if (line[0] == 'F' && len > 5 && !memcmp(line, "From ", 5))
+ (void)putc('>', fp);
(void)fprintf(fp, "%s\n", line);
if (ferror(fp))
break;
Re: libtls documentation
> I'd have to say no. There are structures used but not documented and the
> one line description of some of the functions could be open to
> interpretation. Sample usage is never amiss in my estimation.
If we are thinking of the same structures they are not supposed to be
documented. Notice even in tls.h they are just
struct tls;
struct tls_config;
They compiler doesn't even know what's in them. They are pointers. Use
tls_config_new and tls_{client,server} to get one and don't think about
what might be inside them.
-- Martin
Re: ral(4) diff that needs testing
On Tue, Jul 30, 2013 at 12:16:13AM +0200, Mark Kettenis wrote: > Would appreciate it if somebody could test this diff on a RT2790, > RT2860 or RT3090 variant. Shouldn't change anything for those > variants, but is necessary to support some newer hardware. I have tested on amd64 with ral0 at pci0 dev 13 function 0 "Ralink RT2860" rev 0x00: apic 2 int 19, address 00:25:9c:0d:59:24 ral0: MAC/BBP RT2860 (rev 0x0103), RF RT2850 (MIMO 2T2R) Everything works fine. Was able to bring the interface up and pass packets. Didn't do any heavy load testing, as you said nothing should change, but was able to download a file at usual speeds. - Martin Brandenburg
alignment error rtadvd/armv7
On a PandaBoard (armv7) running -current, when I run rtadvd, it crashes
with a bus error shortly after printing (received a routing message). I
can reproduce by sending SIGHUP to a dhclient running on the same
interface.
I have traced this down to the following block of code in rtadvd.c.
static void
rtmsg_input(void)
{
int n, type, ifindex = 0, plen;
size_t len;
char msg[2048], *next, *lim;
u_char ifname[IF_NAMESIZE];
struct prefix *prefix;
struct rainfo *rai;
struct in6_addr *addr;
char addrbuf[INET6_ADDRSTRLEN];
So msg is not 32-bit aligned, presumably because INET6_ADDRSTRLEN is 46.
I can fix the bus error by hardcoding 48, but of course that's not
right.
Then msg is passed to get_next_msg (as next) where the expression
rtm->rtm_hdrlen (rtm is the not-aligned msg) is the first dereference
and thus the point where it crashes.
I'm at the point now where I think I've found the root of the problem
but don't know enough to fix it.
Any thoughts?
Martin
Re: alignment error rtadvd/armv7
On Sun, 18 Sep 2016, Jeremie Courreges-Anglas wrote:
> Martin Brandenburg writes:
>
> > On a PandaBoard (armv7) running -current, when I run rtadvd, it crashes
> > with a bus error shortly after printing (received a routing message). I
> > can reproduce by sending SIGHUP to a dhclient running on the same
> > interface.
> >
> > I have traced this down to the following block of code in rtadvd.c.
> >
> > static void
> > rtmsg_input(void)
> > {
> > int n, type, ifindex = 0, plen;
> > size_t len;
> > char msg[2048], *next, *lim;
> > u_char ifname[IF_NAMESIZE];
> > struct prefix *prefix;
> > struct rainfo *rai;
> > struct in6_addr *addr;
> > char addrbuf[INET6_ADDRSTRLEN];
> >
> > So msg is not 32-bit aligned, presumably because INET6_ADDRSTRLEN is 46.
> > I can fix the bus error by hardcoding 48, but of course that's not
> > right.
> >
> > Then msg is passed to get_next_msg (as next) where the expression
> > rtm->rtm_hdrlen (rtm is the not-aligned msg) is the first dereference
> > and thus the point where it crashes.
> >
> > I'm at the point now where I think I've found the root of the problem
> > but don't know enough to fix it.
> >
> > Any thoughts?
>
> Thanks for the report.
>
> I guess that we could fix the rtm_* functions to work on an unaligned
> input buffer, but an easier fix would be to just ask for a suitably
> aligned input buffer, with malloc(3). Does the diff below fix your
> problem?
This fixes the problem. I let it sit in debug mode for 30 minutes (which
is far longer than it ever lasted before) through plenty of routing
messages, and it never crashed. I will keep monitoring, but I think it's
good.
Martin
etherip alignment issues
Here's another alignment issue. I have configured two machines as follows. ifconfig vether0 inet ... ifconfig etherip0 tunnel ... ... ifconfig bridge0 add vether0 add etherip0 An amd64 machine works fine in this configuration, however armv7 and sparc64 both have trouble. This happens very quickly after setting up the interfaces and attempting to ping. The armv7 is running -current and the sparc64 is running 6.0. Some quick research points at the M_PREPEND calls in ip_etherip_output, since etherip headers are only two bytes. I can reproduce and get more information if necessary. Thanks, Martin Here's armv7 Fatal kernel mode data abort: 'Alignment fault' trapframe: 0xcc3c2c90 DFSR=0801, DFAR=ca1829e6, spsr=2113 r0 =ca182900, r1 =08c4, r2 =030a, r3 =7800 r4 =ca1829da, r5 =c56d92e8, r6 =c56d9000, r7 =c56d93e8 r8 =, r9 =ca182900, r10=0002, r11=cc3c2d24 r12=c06987d8, ssp=cc3c2ce0, slr=c0524ae8, pc =c040a13c Stopped at ip_etherip_output+0x158:str r2, [r4, #0x00c] ddb> trace ip_etherip_output+0x10 scp=0xc0409ff4 rlv=0xc040a688 (etherip_start+0xe8) rsp=0xcc3c2d28 rfp=0xcc3c2d4c r10=0xc5726800 r9=0xc56f8000 r8=0xc56f8000 r7=0xc56d9198 r6=0xc56d9000 r5=0xc56d9000 r4=0xca182900 etherip_start+0xc scp=0xc040a5ac rlv=0xc0403aac (if_start_locked+0x34) rsp=0xcc3c2d50 rfp=0xcc3c2d74 r7=0x r6=0xc069a840 r5=0x0003 r4=0xc56d9000 if_start_locked+0xc scp=0xc0403a84 rlv=0xc0407b14 (if_enqueue+0x88) rsp=0xcc3c2d78 rfp=0xcc3c2d9c r6=0x0062 r5=0x0012 r4=0xc56d9000 if_enqueue+0xc scp=0xc0407a98 rlv=0xc041a138 (bridge_ifenqueue+0x30) rsp=0xcc3c2da0 rfp=0xcc3c2dcc r7=0x r6=0x0062 r5=0x r4=0xc5727900 bridge_ifenqueue+0xc scp=0xc041a114 rlv=0xc041a6fc (bridge_output+0x278) rsp=0xcc3c2dd0 rfp=0xcc3c2e0c r8=0xca182900 r7=0x r6=0xc56d9000 r5=0x r4=0xc5727900 bridge_output+0xc scp=0xc041a490 rlv=0xc0409768 ($a+0xb0) rsp=0xcc3c2e10 rfp=0xcc3c2e54 r10=0xcc3c2e1e r9=0xc5726aa0 r8=0xca182f00 r7=0xc5726800 r6=0x0008 r5=0xca182900 r4=0xca1829f0 ether_output+0xc scp=0xc04095a8 rlv=0xc04510a4 (arpcache+0x130) rsp=0xcc3c2e58 rfp=0xcc3c2eac r10=0xc5726800 r9=0xca182c50 r8=0xca3ed08c r7=0xca0497f8 r6=0xca3ed09c r5=0xc07044b0 r4=0x0001 arpcache+0xc scp=0xc0450f80 rlv=0xc0451578 (in_arpinput+0x280) rsp=0xcc3c2eb0 rfp=0xcc3c2f14 r10=0x r9=0xca182c50 r8=0x0001 r7=0xc5726800 r6=0xca182c00 r5=0xca0497f8 r4=0xca182c48 in_arpinput+0xc scp=0xc0451304 rlv=0xc0451660 (arpintr+0x28) rsp=0xcc3c2f18 rfp=0xcc3c2f44 r10=0xc069a840 r9=0x r8=0x r7=0xc0703a98 r6=0xcc3c2f18 r5=0xc5726800 r4=0xca182c00 arpintr+0x10 scp=0xc0451648 rlv=0xc0406e2c (if_netisr+0xc8) rsp=0xcc3c2f48 rfp=0xcc3c2f74 r6=0x r5=0xc0703a98 r4=0x0004 if_netisr+0x10 scp=0xc0406d74 rlv=0xc03b85cc (taskq_thread+0x78) rsp=0xcc3c2f78 rfp=0xcc3c2fac r10=0xc06fbc98 r8=0xc06fbe78 r7=0xcc3c2f78 r6=0x0001 r5=0xc54c0040 r4=0xc03b4434 taskq_thread+0xc scp=0xc03b8560 rlv=0xc052b088 (proc_trampoline+0x18) rsp=0xcc3c2fb0 rfp=0xc0815ec4 r7=0x r6=0x r5=0xc54c0040 r4=0xc03b8554 Bad frame pointer: 0xc0815ec4 ddb> and here's sparc64 panic: trap type 0x34 (mem address not aligned): pc=11ffa0c npc=11ffa 10 pstate=820006 Stopped at Debugger+0x8: nop TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *45795 45795 0 0x14000 0x2101 softnet trap(4007849d370, 34, 11ffa0c, 820006, 4007849db10, 0) at trap+0x360 Lslowtrap_reenter(40014464400, 14, 2, 0, 88d8, 6) at Lslowtrap_reenter+0xf8 ip_etherip_output(4000a85c800, 40014464400, 62, 4007849dc08, 4007849db10, 0) at ip_etherip_output+0xd4 etherip_start(4000a85c800, 62, 0, 0, 88d8, 6) at etherip_start+0xc4 if_start_locked(4000a85c800, 40014464400, 62, 4007849dc08, 4007849db10, 0) at if_start_locked+0x24 if_enqueue(0, 62, 0, 0, 88d8, 6) at if_enqueue+0x6c bridge_ifenqueue(4000ae12000, 4000a85c800, 62, 4007849dc08, 4007849db10, 0) at bridge_ifenqueue+0x30 bridge_output(0, 40014464400, 0, 0, 88d8, 6) at bridge_output+0x260 if_enqueue(4000a85d800, 40014464400, 40014464400, 4007849dc08, 4007849db10, 0) at if_enqueue+0x90 ether_output(37, 40014464b00, 4007849dc08, 40014b04e70, 88d8, ) at ether_output+0x214 ip_output(40014464b00, 40014464b68, 4007849dbf8, 0, 0, 0) at ip_output+0x7a0 ip_send_dispatch(0, 4007849dde0, 119bfe0, 0, 4, 2000) at ip_send_dispatch+0x64 taskq_thread(40008b18080, 40014bded80, 168fe98, 168fc10, 0, 3b9ac800) at taskq_thread+0x6c proc_trampoline(0, 0, 0, 0, 0, 0) at proc_trampoline+0x14
Re: etherip alignment issues
On Sat, 24 Sep 2016, YASUOKA Masahiko wrote: > Hi, > > The problem doesn't repeat on my Octeon. > > Can you try the diff below? > > - I assume the diff fixes the problem > - A kernel message is added. please let me know if it appears. > > Thanks, > I got the message, but had another panic. ip_etherip_output: leading space is small 2 panic: ip_output no HDR Stopped at Debugger+0x8: nop TIDPIDUID PRFLAGS PFLAGS CPU COMMAND 32532 32532 730x100010 0x806 syslogd *79702 79702 0 0x14000 0x2101 softnet ip_output(4001491c200, 0, 0, 2, 0, 0) at ip_output+0x964 ip_etherip_output(4000ae87800, 4001491cc00, 2a, 4000ae84e8f, 0, 6) at ip_etherip_output+0x214 etherip_start(4000ae87800, 2a, 0, 0, e1, 6) at etherip_start+0xc4 if_start_locked(4000ae87800, 4001491cc00, 2a, 4000ae84e8f, 0, 6) at if_start_locked+0x24 if_enqueue(0, 2a, 0, 0, e1, 6) at if_enqueue+0x6c bridge_ifenqueue(4000a86, 4000ae87800, 2a, 4000ae84e8f, 0, 6) at bridge_ifenqueue+0x30 bridge_output(0, 4001491cc00, 0, 0, e1, 6) at bridge_output+0x260 if_enqueue(4000ae8a000, 4001491cc00, 2, 4000ae84e8f, 0, 6) at if_enqueue+0x90 ether_output(37, 4001491cc00, 4007849da68, 0, e1, ba) at ether_output+0x214 arpreply(4000ae8a000, 4001491cc00, 4007849db50, 4000ae84e8f, 0, 6) at arpreply+0x16c in_arpinput(4000ae8a000, 4001491cc00, 119bfe0, 0, 4, 2000) at in_arpinput+0x2ec arpintr(188aff8, 40014bded80, 168ff18, 168fc90, 0, 6) at arpintr+0x48 if_netisr(0, 4007849dde0, 119bfe0, 0, 4, 2000) at if_netisr+0xf0 taskq_thread(40008b18080, 40014bded80, 168ff18, 168fc90, 0, 3b9ac800) at taskq_thread+0x6c
lenovo scrollpoint mouse
The IBM/Lenovo ScrollPoint mouse is uses a TrackPoint-type mechanism
rather than a standard mouse wheel. It appears to the system as a
standard USB mouse with one caveat.
(http://www.ibmfiles.com/pages/scrollpoint.htm)
Where a standard USB mouse with a scrollwheel reports one click of the
wheel as 1 unit in the z direction, this one measures force and reports
a number from 1 to 64. It is VERY sensitive. Practically any force at
all will send it into double-digits range. Scrolling at ten to sixty
times normal speed is not pleasant.
IBM/Lenovo makes/made a driver for Microsoft Windows which lowered the
scrolling speed.
This divides the reported scroll movement by 16, giving a range from 1
to 4. I have been using this for over a year and find this comfortable.
Martin
Index: dev/hid/hidms.c
==
RCS file: /cvs/src/sys/dev/hid/hidms.c,v
retrieving revision 1.3
diff -u -p -r1.3 hidms.c
--- dev/hid/hidms.c 22 May 2016 22:06:11 - 1.3
+++ dev/hid/hidms.c 22 Sep 2016 00:55:18 -
@@ -385,6 +385,11 @@ hidms_input(struct hidms *ms, uint8_t *d
(ms->sc_tsscale.maxy - ms->sc_tsscale.miny);
}
+ if (ms->sc_flags & HIDMS_FASTSCROLL) {
+ dz /= 16;
+ dw /= 16;
+ }
+
for (i = 0; i < ms->sc_num_buttons; i++)
if (hid_get_data(data, len, &ms->sc_loc_btn[i]))
buttons |= (1 << HIDMS_BUT(i));
Index: dev/hid/hidmsvar.h
===
RCS file: /cvs/src/sys/dev/hid/hidmsvar.h,v
retrieving revision 1.1
diff -u -p -r1.1 hidmsvar.h
--- dev/hid/hidmsvar.h 8 Jan 2016 15:54:13 - 1.1
+++ dev/hid/hidmsvar.h 22 Sep 2016 00:55:18 -
@@ -43,18 +43,19 @@ struct tsscale {
struct hidms {
int sc_enabled;
int sc_flags; /* device configuration */
-#define HIDMS_SPUR_BUT_UP 0x001 /* spurious button up events */
-#define HIDMS_Z0x002 /* Z direction available */
-#define HIDMS_REVZ 0x004 /* Z-axis is reversed */
-#define HIDMS_W0x008 /* W direction available */
-#define HIDMS_REVW 0x010 /* W-axis is reversed */
-#define HIDMS_LEADINGBYTE 0x020 /* Unknown leading byte */
-#define HIDMS_ABSX 0x040 /* X-axis is absolute */
-#define HIDMS_ABSY 0x080 /* Y-axis is absolute */
-#define HIDMS_TIP 0x100 /* Tip switch on a digitiser pen */
-#define HIDMS_BARREL 0x200 /* Barrel switch on a digitiser pen */
-#define HIDMS_ERASER 0x400 /* Eraser switch on a digitiser pen */
-#define HIDMS_MS_BAD_CLASS 0x800 /* Mouse doesn't identify properly */
+#define HIDMS_SPUR_BUT_UP 0x0001 /* spurious button up events */
+#define HIDMS_Z0x0002 /* Z direction available */
+#define HIDMS_REVZ 0x0004 /* Z-axis is reversed */
+#define HIDMS_W0x0008 /* W direction available */
+#define HIDMS_REVW 0x0010 /* W-axis is reversed */
+#define HIDMS_LEADINGBYTE 0x0020 /* Unknown leading byte */
+#define HIDMS_ABSX 0x0040 /* X-axis is absolute */
+#define HIDMS_ABSY 0x0080 /* Y-axis is absolute */
+#define HIDMS_TIP 0x0100 /* Tip switch on a digitiser pen */
+#define HIDMS_BARREL 0x0200 /* Barrel switch on a digitiser pen */
+#define HIDMS_ERASER 0x0400 /* Eraser switch on a digitiser pen */
+#define HIDMS_MS_BAD_CLASS 0x0800 /* Mouse doesn't identify properly */
+#define HIDMS_FASTSCROLL 0x1000 /* Eraser switch on a digitiser pen */
int sc_num_buttons;
u_int32_t sc_buttons; /* mouse button status */
Index: dev/usb/ums.c
===
RCS file: /cvs/src/sys/dev/usb/ums.c,v
retrieving revision 1.43
diff -u -p -r1.43 ums.c
--- dev/usb/ums.c 12 Jan 2016 19:16:21 - 1.43
+++ dev/usb/ums.c 22 Sep 2016 00:55:18 -
@@ -143,6 +143,8 @@ ums_attach(struct device *parent, struct
qflags |= HIDMS_MS_BAD_CLASS;
if (quirks & UQ_MS_LEADING_BYTE)
qflags |= HIDMS_LEADINGBYTE;
+ if (quirks & UQ_LENOVO_FASTSCROLL)
+ qflags |= HIDMS_FASTSCROLL;
if (hidms_setup(self, ms, qflags, uha->reportid, desc, size) != 0)
return;
Index: dev/usb/usb_quirks.c
===
RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
retrieving revision 1.74
diff -u -p -r1.74 usb_quirks.c
--- dev/usb/usb_quirks.c27 Nov 2015 10:59:32 - 1.74
+++ dev/usb/usb_quirks.c22 Sep 2016 00:55:18 -
@@ -150,6 +150,9 @@ const struct usbd_quirk_entry {
{ USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_WLNOTEBOOK2,
ANY, { UQ_MS_BAD_CLA
Re: etherip alignment issues
On Sun, 25 Sep 2016, YASUOKA Masahiko wrote:
> On Sat, 24 Sep 2016 13:08:18 -0400 (EDT)
> Martin Brandenburg wrote:
> > On Sat, 24 Sep 2016, YASUOKA Masahiko wrote:
> >> The problem doesn't repeat on my Octeon.
> >>
> >> Can you try the diff below?
> >>
> >> - I assume the diff fixes the problem
> >> - A kernel message is added. please let me know if it appears.
> >
> > I got the message, but had another panic.
> >
> > ip_etherip_output: leading space is small 2
>
> Thanks. The diff was wrong. I'm sorry.
>
> Let me update the diff.
Still panicking.
ddb{3}> show panic
trap type 0x34 (mem address not aligned): pc=11ffa68 npc=11ffa6c
pstate=44820006
ddb{3}> trace
trap(4007849d370, 34, 11ffa68, 44820006, 4007849db10, 0) at trap+0x360
Lslowtrap_reenter(0, 14, 0, 4007849d566, 2, 6) at Lslowtrap_reenter+0xf8
ip_etherip_output(4000ae96000, 4001443a600, 62, 4007849dc08, 4007849db10, 0) at
ip_etherip_output+0x130
etherip_start(4000ae96000, 62, 0, 0, 292f, 6) at etherip_start+0xc4
if_start_locked(4000ae96000, 4001443a600, 62, 4007849dc08, 4007849db10, 0) at
if_start_locked+0x24
if_enqueue(0, 62, 0, 0, 292f, 6) at if_enqueue+0x6c
bridge_ifenqueue(4000a86, 4000ae96000, 62, 4007849dc08, 4007849db10, 0) at
bridge_ifenqueue+0x30
bridge_output(0, 4001443a600, 0, 0, 292f, 6) at bridge_output+0x260
if_enqueue(4000ae93800, 4001443a600, 4001443a600, 4007849dc08, 4007849db10, 0)
at if_enqueue+0x90
ether_output(37, 4001443ac00, 4007849dc08, 4001478bab0, 292f, ) at
ether_output+0x214
ip_output(4001443ac00, 4001443ac68, 4007849dbf8, 0, 0, 0) at ip_output+0x7a0
ip_send_dispatch(0, 4007849dde0, 119bfe0, 0, 4, 2000) at
ip_send_dispatch+0x64
taskq_thread(40008b18080, 40014bded80, 168fed8, 168fc50, 0, 3b9ac800) at
taskq_thread+0x6c
proc_trampoline(0, 0, 0, 0, 0, 0) at proc_trampoline+0x14
ddb{3}> sc> poweroff
Re: etherip alignment issues
On Mon, 26 Sep 2016, YASUOKA Masahiko wrote: > Hi, > > I could repeat the problem on my octeon. Tested the diff on it. > > ok? > > Use a new mbufs for a tunnel header to make sure it is aligned correctly. I have tested this latest diff and can confirm it also works on sparc64. Martin
Re: cwm: remove mouse resize window
On Wed, 28 Sep 2016, Okan Demirmen wrote:
> Hi,
>
> Curious what the reaction might be if I removed the little geometry
> window in the top-left corner for mouse/pointer based window resizes.
I don't know about anyone else, but I use this for one thing only:
making sure my terminal windows are still exactly 80 columns wide after
resizing them to be longer (or going back to 80 after making one wider
temporarily). Any other window I don't care about the exact size.
I suppose I could use stty and the keyboard resizing options if this
went away, but it seems more natural to move and resize windows with the
mouse.
>
> We currently print the x/y dimensions only for mouse based actions; we
> don't for kbd, nor do we do anything with mouse/kbd window moves (such
> as printing the x/y coordinates, etc). So why have mouse-resize be
> different? Thus, the below crudely removes it.
>
> One reason to remove it is for simplicity; this is the only place we
> need to hold and carry around menuwin and a drawable. If we abused
> menuwin/drawable in other locations but the actual menu'ing subsystem,
> then ok. Alternatively, can create/destroy each time for a mouse-resize,
> but likely not worth it, maybe it should stay...
So make it display on movement too? I'm not sure how useful it is, but
it adds symmetry.
Martin
Index: mousefunc.c
===
RCS file: /cvs/xenocara/app/cwm/mousefunc.c,v
retrieving revision 1.107
diff -u -p -r1.107 mousefunc.c
--- mousefunc.c 28 Sep 2016 17:06:33 - 1.107
+++ mousefunc.c 28 Sep 2016 18:33:12 -
@@ -32,16 +32,17 @@
#include "calmwm.h"
-static voidmousefunc_sweep_draw(struct client_ctx *);
+static voidmousefunc_sweep_draw(struct client_ctx *, int move);
static void
-mousefunc_sweep_draw(struct client_ctx *cc)
+mousefunc_sweep_draw(struct client_ctx *cc, int move)
{
struct screen_ctx *sc = cc->sc;
char s[14]; /* fits " x \0" */
XGlyphInfo extents;
- (void)snprintf(s, sizeof(s), " %4d x %-4d ", cc->dim.w, cc->dim.h);
+ (void)snprintf(s, sizeof(s), " %4d x %-4d ",
+ move ? cc->geom.x : cc->dim.w, move ? cc->geom.y : cc->dim.h);
XftTextExtentsUtf8(X_Dpy, sc->xftfont, (const FcChar8*)s,
strlen(s), &extents);
@@ -89,7 +90,7 @@ mousefunc_client_resize(struct client_ct
cc->geom.h = ev.xmotion.y;
client_applysizehints(cc);
client_resize(cc, 1);
- mousefunc_sweep_draw(cc);
+ mousefunc_sweep_draw(cc, 0);
break;
case ButtonRelease:
client_resize(cc, 1);
@@ -151,9 +152,12 @@ mousefunc_client_move(struct client_ctx
cc->geom.y + cc->geom.h + (cc->bwidth * 2),
area.y, area.y + area.h, sc->snapdist);
client_move(cc);
+ mousefunc_sweep_draw(cc, 1);
break;
case ButtonRelease:
client_move(cc);
+ XUnmapWindow(X_Dpy, sc->menuwin);
+ XReparentWindow(X_Dpy, sc->menuwin, sc->rootwin, 0, 0);
xu_ptr_ungrab();
return;
}
cwm: avoid displaying empty menu
This avoids an empty square in the upper left corner if there is nothing to display in some menu the user requests. -- Martin Index: menu.c === RCS file: /cvs/xenocara/app/cwm/menu.c,v retrieving revision 1.89 diff -u -p -r1.89 menu.c --- menu.c 11 Nov 2015 14:22:01 - 1.89 +++ menu.c 20 Feb 2016 17:26:17 - @@ -89,6 +89,9 @@ menu_filter(struct screen_ctx *sc, struc int evmask, focusrevert; int xsave, ysave, xcur, ycur; + if (TAILQ_EMPTY(menuq)) + return NULL; + TAILQ_INIT(&resultq); (void)memset(&mc, 0, sizeof(mc));
Re: cwm: avoid displaying empty menu
On Sat, 20 Feb 2016, Okan Demirmen wrote: > On Sat 2016.02.20 at 12:29 -0500, Martin Brandenburg wrote: > > This avoids an empty square in the upper left corner if > > there is nothing to display in some menu the user > > requests. > > Sorry, but I think that is a big hammer; in fact there is evidence of > why these checks are no longer there in the calling functions, such as: > > > revision 1.89 > date: 2015/06/07 19:10:00; author: okan; state: Exp; lines: +1 -7; > commitid: DuQBUgWvLWBQOJbB; > even if the menuq is empty, at least show an empty menu instead of just > bailing making it look like the binding isn't working. > > > So if your application menu is empty, do you want to see the > 'application' header with an empty list below it, or zero indication > (not even the header) that anything is working (or is it but empty?)? No I still see that with my patch. E.g. M-? brings an empty (really one item) menu that says "exec." I don't see any menu at all for e.g. left clicking when there are no hidden windows. I don't think I should. What I describe below hardly demonstrates that anything is working. Is there another sort of menu I'm not thinking of? I'll admit to not using all of cwm's features. > > ..that's the rationale at least. > > OR, is this empty square something else -what (empty) menu do you see > just an empty square with no indicator/header in it? If the border is set to 1px, you will see a 3px square in the upper corner With a larger border it looks like http://www.martinbrandenburg.com/2016/ss/0222.cwm.png I wouldn't have noticed if I wasn't playing with border width one day. -- Martin > > Thanks, > Okan > > > -- Martin > > > > Index: menu.c > > === > > RCS file: /cvs/xenocara/app/cwm/menu.c,v > > retrieving revision 1.89 > > diff -u -p -r1.89 menu.c > > --- menu.c 11 Nov 2015 14:22:01 - 1.89 > > +++ menu.c 20 Feb 2016 17:26:17 - > > @@ -89,6 +89,9 @@ menu_filter(struct screen_ctx *sc, struc > > int evmask, focusrevert; > > int xsave, ysave, xcur, ycur; > > > > + if (TAILQ_EMPTY(menuq)) > > + return NULL; > > + > > TAILQ_INIT(&resultq); > > > > (void)memset(&mc, 0, sizeof(mc)); > > >
Re: cwm: avoid displaying empty menu
On Mon, 22 Feb 2016, Martin Brandenburg wrote: > Is there another sort of menu I'm not thinking of? I'll > admit to not using all of cwm's features. Ooh! Right after sending this I accidentally hit CM-n, and it crashed since menu_filter wasn't supposed to return NULL. Well what was in there before 1.89 is better than my patch. -- Martin
