drm/mesa: blocking (infinite) poll(2) after suspend/resume
Very often when resuming my x220 running GNOME3 the gnome-shell(1) process gets stuck and only the mouse can move on the screen. The stack trace indicates that all the threads seem to be waiting inside poll(2) for a GL-related operation that's unclear to me. At this stage switching to a virtual console (Ctrl+Alt+F1) and back "untsuck" the process for a small period then it returns waiting in poll(2) as per the trace below. 0x0225d9868dfa in poll () at :2 2 : No such file or directory. (gdb) bt #0 0x0225d9868dfa in poll () at :2 #1 0x02266e188b6d in poll (fds=0x7f7d7bb0, nfds=1, timeout=-1) at /usr/src/lib/librthread/rthread_cancel.c:353 #2 0x022605007377 in _xcb_conn_wait (c=0x225f1ce4000, cond=, vector=0x0, count=0x0) at /usr/xenocara/lib/libxcb/libxcb/../../../dist/libxcb/src/xcb_conn.c:459 #3 0x022605005a7a in wait_for_reply (c=0x225f1ce4000, request=110082, e=0x0 ) at /usr/xenocara/lib/libxcb/libxcb/../../../dist/libxcb/src/xcb_in.c:516 #4 0x022605005ce3 in xcb_wait_for_reply (c=0x225f1ce4000, request=110082, e =0x0) at /usr/xenocara/lib/libxcb/libxcb/../../../dist/libxcb/src/xcb_in.c:546 #5 0x022638f8c770 in dri2WaitForMSC () from /usr/X11R6/lib/libGL.so.16.0 #6 0x02263ccd010e in _cogl_winsys_wait_for_vblank () from /usr/local/lib/libcogl.so.3.1 #7 0x02263ccd0623 in _cogl_winsys_onscreen_swap_region () from /usr/local/lib/libcogl.so.3.1 #8 0x02263ccbf33d in cogl_onscreen_swap_region () from /usr/local/lib/libco gl.so.3.1 #9 0x02260e83c803 in clutter_stage_cogl_redraw () from /usr/local/lib/libclutter-1.0.so.6.0 #10 0x02260e8a2d24 in _clutter_stage_do_update () from /usr/local/lib/libclutter-1.0.so.6.0 #11 0x02260e88dbf8 in clutter_clock_dispatch () from /usr/local/lib/libclutter-1.0.so.6.0 #12 0x0226379b757f in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.4200.2 #13 0x0226379b95db in g_main_context_iterate () from /usr/local/lib/libglib-2.0.so.4200.2 #14 0x0226379ba555 in g_main_loop_run () from /usr/local/lib/libglib-2.0.so. 4200.2 #15 0x022643a8d03c in meta_run () from /usr/local/lib/libmutter.so.1.0 #16 0x022384e035f7 in main () OpenBSD 5.9 (GENERIC.MP) #1869: Thu Feb 4 09:50:59 MST 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8451125248 (8059MB) avail mem = 8190808064 (7811MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (66 entries) bios0: vendor LENOVO version "8DET51WW (1.21 )" date 08/02/2011 bios0: LENOVO 429137G acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT DMAR UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.30 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 5 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus -1 (EXP7) acpicpu0 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpicpu1 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2 acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "42T4942" serial 15354 type LION oem "LGC" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK docked (15) cpu0: Enhanced SpeedStep 2492 MHz: speeds: 2501, 2500, 2200, 2000, 1800, 1600, 1400,
Re: pax(1) gets stuck in a loop creating intermediate directories
On Mon Feb 15, Philip Guenther wrote: > ...and since pax's tar format code only trims a single trailing slash, it > will loop even in that case if you add more than one trailing slash. > > Indeed, if you add more than one trailing slash in general then it'll > still hang despite your patch: to fix it the code needs to be able to > detect when its reached an arbitrary number of trailing slashes. You're right, I didn't think about this case. On Tue Feb 16, Vadim Zhukov wrote: > I think we should change "if" to "while" in this function, too... > After that, okay zhuk@. For what it's worth, it looks good to me too.
Re: ACPI thinkpad brightness regression
> Date: Wed, 10 Feb 2016 20:10:41 +0100
> From: Martin Pieuchot
>
> On 09/02/16(Tue) 21:06, Christian Weisgerber wrote:
> > On 2016-02-09, Martin Pieuchot wrote:
> >
> > > Since brightness support has been added to acpithinkpad(4) I can easily
> > > trigger a regression on my x220:
> > >
> > > - Switching to the first virtual console just after xdm starts using the
> > > Ctrl+Alt+F1 key combination turns my screen dark.
> > > - Killing X just after xdm start, by using Ctrl+Alt+Del, also turns my
> > > screen Dark.
> >
> > Yes, I also see this on my X230.
> >
> > > The problem seems to be a race related to multiple events, diff below
> > > fixes that for me.
> >
> > With that diff the brightness is stuck at 100%.
>
> The diff is broken.
>
> I couldn't spot a way to fix this. Maybe it's a bug in the firmware?
Does the following diff work?
Index: acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.51
diff -u -p -r1.51 acpithinkpad.c
--- acpithinkpad.c 10 Jan 2016 16:30:43 - 1.51
+++ acpithinkpad.c 16 Feb 2016 19:42:58 -
@@ -126,6 +126,7 @@ struct acpithinkpad_softc {
const char *sc_thinklight_set;
uint64_t sc_brightness;
+ int sc_newbrightness;
};
extern void acpiec_read(struct acpiec_softc *, u_int8_t, int, u_int8_t *);
@@ -667,7 +668,7 @@ thinkpad_set_brightness(void *arg0, int
memset(&arg, 0, sizeof(arg));
arg.type = AML_OBJTYPE_INTEGER;
- arg.v_integer = sc->sc_brightness & 0xff;
+ arg.v_integer = sc->sc_newbrightness;
aml_evalname(sc->sc_acpi, sc->sc_devnode,
"PBLS", 1, &arg, NULL);
}
@@ -708,6 +709,7 @@ thinkpad_set_param(struct wsdisplay_para
dp->curval = maxval;
sc->sc_brightness &= ~0xff;
sc->sc_brightness |= dp->curval;
+ sc->sc_newbrightness = dp->curval;
acpi_addtask(sc->sc_acpi, thinkpad_set_brightness, sc, 0);
acpi_wakeup(sc->sc_acpi);
return 0;
Re: std::ifstream is broken on arm
Actually, I had forgotten to disable the stack protector, and guess
what? Disabling it produces a working libstdc++, at least for that
simple use case; I have not tried to build cmake.
Therefore I suggest the following diff until someone with enough love
for the utter crap known as `arm' comes with a real compiler fix:
Index: Makefile
===
RCS file: /OpenBSD/src/gnu/lib/libstdc++-v3/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile14 May 2015 02:56:01 - 1.8
+++ Makefile16 Feb 2016 20:04:20 -
@@ -17,6 +17,9 @@ CFLAGS+= -frandom-seed=RepeatabilityCons
CXXFLAGS+= -frandom-seed=RepeatabilityConsideredGood
CXXFLAGS+= -fno-implicit-templates -ffunction-sections -fdata-sections \
-Wno-deprecated
+.if ${MACHINE_ARCH} == "arm"
+CXXFLAGS+= -fno-stack-protector
+.endif
DPADD= ${LIBM}
LDADD= -lm
Re: ACPI thinkpad brightness regression
Mark Kettenis:
> Does the following diff work?
No. (Thinkpad X230.)
> Index: acpithinkpad.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 acpithinkpad.c
> --- acpithinkpad.c10 Jan 2016 16:30:43 - 1.51
> +++ acpithinkpad.c16 Feb 2016 19:42:58 -
> @@ -126,6 +126,7 @@ struct acpithinkpad_softc {
> const char *sc_thinklight_set;
>
> uint64_t sc_brightness;
> + int sc_newbrightness;
> };
>
> extern void acpiec_read(struct acpiec_softc *, u_int8_t, int, u_int8_t *);
> @@ -667,7 +668,7 @@ thinkpad_set_brightness(void *arg0, int
>
> memset(&arg, 0, sizeof(arg));
> arg.type = AML_OBJTYPE_INTEGER;
> - arg.v_integer = sc->sc_brightness & 0xff;
> + arg.v_integer = sc->sc_newbrightness;
> aml_evalname(sc->sc_acpi, sc->sc_devnode,
> "PBLS", 1, &arg, NULL);
> }
> @@ -708,6 +709,7 @@ thinkpad_set_param(struct wsdisplay_para
> dp->curval = maxval;
> sc->sc_brightness &= ~0xff;
> sc->sc_brightness |= dp->curval;
> + sc->sc_newbrightness = dp->curval;
> acpi_addtask(sc->sc_acpi, thinkpad_set_brightness, sc, 0);
> acpi_wakeup(sc->sc_acpi);
> return 0;
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: ACPI thinkpad brightness regression
On 16/02/16(Tue) 20:46, Mark Kettenis wrote: > > Date: Wed, 10 Feb 2016 20:10:41 +0100 > > From: Martin Pieuchot > > > > On 09/02/16(Tue) 21:06, Christian Weisgerber wrote: > > > On 2016-02-09, Martin Pieuchot wrote: > > > > > > > Since brightness support has been added to acpithinkpad(4) I can easily > > > > trigger a regression on my x220: > > > > > > > > - Switching to the first virtual console just after xdm starts using the > > > > Ctrl+Alt+F1 key combination turns my screen dark. > > > > - Killing X just after xdm start, by using Ctrl+Alt+Del, also turns my > > > > screen Dark. > > > > > > Yes, I also see this on my X230. > > > > > > > The problem seems to be a race related to multiple events, diff below > > > > fixes that for me. > > > > > > With that diff the brightness is stuck at 100%. > > > > The diff is broken. > > > > I couldn't spot a way to fix this. Maybe it's a bug in the firmware? > > Does the following diff work? Sadly not. This diff is roughly equivalent to the one I sent using arg1 to pass the value to set, no? Note that on my machine calling the "PBLS" triggers an event so there's no need to write sc_brightness directly. Actually doing so might create a race. Can you reproduce the bug on your x220?
Re: ACPI thinkpad brightness regression
On Wed, Feb 10, 2016 at 07:10:41PM GMT, Martin Pieuchot wrote:
> On 09/02/16(Tue) 21:06, Christian Weisgerber wrote:
> > On 2016-02-09, Martin Pieuchot wrote:
> >
> > > Since brightness support has been added to acpithinkpad(4) I can easily
> > > trigger a regression on my x220:
> > >
> > > - Switching to the first virtual console just after xdm starts using the
> > > Ctrl+Alt+F1 key combination turns my screen dark.
> > > - Killing X just after xdm start, by using Ctrl+Alt+Del, also turns my
> > > screen Dark.
> >
> > Yes, I also see this on my X230.
> >
> > > The problem seems to be a race related to multiple events, diff below
> > > fixes that for me.
> >
> > With that diff the brightness is stuck at 100%.
>
> The diff is broken.
>
> I couldn't spot a way to fix this. Maybe it's a bug in the firmware?
>
> For what I could see the intel driver (xf86-video-intel) switches the
> brightness, called backlight, twice when switching to a console with
> Ctrl+Alt+Fn. It does the equivalent of:
>
> # wsconsctl display.brightness=0
> # wsconsctl display.brightness=100
>
> Here are the relevant Xorg.0.log lines:
>
> [ 152.114] sna_output_dpms: saving current backlight 15
> [ 152.114] sna_output_backlight_set(LVDS1) level=0, max=15
> [ 152.387] sna_output_backlight_set(LVDS1) level=15, max=15
>
> Which trigger the following output in dmesg with the diff below:
>
> thinkpad_set_brightness: 0
> thinkpad_get_brightness: 3840
> thinkpad_set_brightness: 15
> thinkpad_get_brightness: 3855
>
> At this point the screen is still dark but the system *and* the ACPI
> notification reports it to be a 100% brightness.
Hi Martin,
Are you sure that this is Thinkpad-specific?
The reason why I'm asking is because I can see something similar on my
Sony Vaio VGN-Z11WN_B laptop when, after logging onto console, starting
X using startx, then quitting X (cwm in this case) gets me back to the
console with brightness set to 64% - subsequently brightness stays at
64% after I log onto X again. There, if I run `xbacklight -set 100`,
brightness goes back to 100% *but* if I quit X again, the screen goes
dark again (presumably to said 64%) *and* `wsconstl display.brightness`
reports 100% (sic!). I have to run `wsconstl display.brightness=100` to
bring it back to 100% brightness - this happens *every* time I quit X.
Also, a very strange behaviour: the brightness up key combination,
doesn't do anything but, when pressing the brightness down
key, the screen goes bright (to more like 99% since `wsconstl
display.brightness=100` still makes it a bit brighter) on first key
press, and then down (as one might expect) on subsequent key presses.
If it is just a coincidence, and you are looking at a different bug,
then I'll report a new one, otherwise, I can provide more information
(full dmesg, etc.) - simply don't want to hijack the thread (might have
done so already - sorry).
Running the newest snapshot, BTW:
OpenBSD 5.9 (GENERIC.MP) #1868: Mon Feb 1 20:02:36 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Regards,
Raf
> Pressing the "brighness up key" produces the following message and
> the brightness now really is at 100%:
>
> thinkpad_get_brightness: 3855
>
> I don't have any more idea about how to solve this regression but it
> is really annoying.
>
> Index: acpithinkpad.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 acpithinkpad.c
> --- acpithinkpad.c17 Dec 2015 12:17:14 - 1.50
> +++ acpithinkpad.c10 Feb 2016 18:15:41 -
> @@ -407,6 +407,7 @@ thinkpad_hotkey(struct aml_node *node, i
> break;
> case THINKPAD_BACKLIGHT_CHANGED:
> thinkpad_get_brightness(sc);
> + handled = 1;
> break;
> case THINKPAD_ADAPTIVE_BACK:
> case THINKPAD_ADAPTIVE_GESTURES:
> @@ -653,6 +654,7 @@ thinkpad_get_brightness(struct acpithink
> {
> aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
> "PBLG", 0, NULL, &sc->sc_brightness);
> + printf("%s: %lld\n", __func__, sc->sc_brightness);
> }
>
> void
> @@ -663,9 +665,11 @@ thinkpad_set_brightness(void *arg0, int
>
> memset(&arg, 0, sizeof(arg));
> arg.type = AML_OBJTYPE_INTEGER;
> - arg.v_integer = sc->sc_brightness & 0xff;
> - aml_evalname(sc->sc_acpi, sc->sc_devnode,
> - "PBLS", 1, &arg, NULL);
> + arg.v_integer = arg1;
> + if (aml_evalname(sc->sc_acpi, sc->sc_devnode,
> + "PBLS", 1, &arg, NULL))
> + return;
> + printf("%s: %d\n", __func__, arg1);
> }
>
> int
> @@ -702,9 +706,8 @@ thinkpad_set_param(struct wsdisplay_para
> dp->curval = 0;
> if (dp->curval > maxval)
> dp->curval = maxval;
> - sc->sc_brightness &= ~0xff;
> - s
