Re: blank screen with LCD off after waking up from suspend

[Aaron Miller]

On Tue, Dec 1, 2015 at 12:48 AM, Mike Larkin  wrote:
>
> On Sat, Nov 21, 2015 at 01:29:18AM -0800, aaron.mille...@gmail.com wrote:
> > >Synopsis:sometimes, waking up from suspend results in a black screen 
> > >with the LCD turned off
> > >Category:system kernel amd64
> > >Environment:
> >   System  : OpenBSD 5.8
> >   Details : OpenBSD 5.8-current (GENERIC.MP) #1616: Sun Nov 15 
> > 20:58:13 MST 2015
> >
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> >   Architecture: OpenBSD.amd64
> >   Machine : amd64
> > >Description:
> >   I had X with KDE running on my laptop, and I closed the lid, which
> >   caused a suspend. When I opened the lid again sometime later, I 
> > didn't see
> >   anything on the screen, and the LCD backlight was turned off. Caps 
> > Lock turned
> >   on and off the indicator light, so the keyboard was working.
> >
> >   The dmesg and usbdevs info in this bug report is from after I forced 
> > a restart.
> > >How-To-Repeat:
> >   Unfortunately, I'm not sure how to replicate this. It doesn't happen 
> > every time -- so far it's only happened once.
> > >Fix:
> >   I don't know how to fix it.
> >
>
> Should this happen again, it may be sitting in ddb.
>
> Try ssh'ing into the machine and if that works, do a dmesg remotely
> and see if it gives any hints.
>
> If ssh doesn't work. you can (blindly) try:
>
> trace
> boot reboot
>
> ("boot reboot" reboots the machine from ddb)
>
> Then check if your dmesg survived across the reboot on the next boot.
> Sometimes more than one "boot reboot" is needed (all typed blindiy).

Thanks, Mike!

It seems unlikely to me that sshing will work because the wifi dongle
LED was not lit, indicating no connection. I'll try it anyway, though.
The ethernet port on this laptop doesn't work due to a coffee spill,
so there's no other way to connect to the network with the hardware I
have on hand.

If it's sitting at the ddb prompt, that would explain why there's no
hard drive accesses. I'll try those commands and report back if I get
a dmesg.

--Aaron

Re: troubles to extract bzip2 compressed tar file

[Sebastien Marie]

On Tue, Dec 01, 2015 at 03:20:10PM +0100, Jiri Navratil wrote:
> Thank you for all responses. I'm sending, what I was able get:
> 
> Program received signal SIGABRT, Aborted.
> 0x09503cf679ea in mkfifo () from /usr/lib/libc.so.84.2
> 
> (gdb) bt
> #0  0x09503cf679ea in mkfifo () from /usr/lib/libc.so.84.2
> #1  0x094d65b0bcd3 in node_creat (arcn=0x7f7bb1a0)
> at /usr/src/bin/pax/file_subs.c:405
> #2  0x094d65b06a5b in extract () at /usr/src/bin/pax/ar_subs.c:308
> #3  0x094d65b11284 in main (argc=3, argv=0x7f7bcb58)
> at /usr/src/bin/pax/pax.c:281

Hi Jiri,

Thanks for you report. The problem is identified: your archive contains
fifo, and the mkfifo(2) syscall isn't currently allowed with pledge.

We are working on a proper way to resolv that.

Thanks.
-- 
Sebastien Marie

Re: blank screen with LCD off after waking up from suspend

[Mike Larkin]

On Sat, Nov 21, 2015 at 01:29:18AM -0800, aaron.mille...@gmail.com wrote:
> >Synopsis:sometimes, waking up from suspend results in a black screen 
> >with the LCD turned off
> >Category:system kernel amd64
> >Environment:
>   System  : OpenBSD 5.8
>   Details : OpenBSD 5.8-current (GENERIC.MP) #1616: Sun Nov 15 
> 20:58:13 MST 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   I had X with KDE running on my laptop, and I closed the lid, which
>   caused a suspend. When I opened the lid again sometime later, I didn't 
> see
>   anything on the screen, and the LCD backlight was turned off. Caps Lock 
> turned
>   on and off the indicator light, so the keyboard was working.
> 
>   The dmesg and usbdevs info in this bug report is from after I forced a 
> restart.
> >How-To-Repeat:
>   Unfortunately, I'm not sure how to replicate this. It doesn't happen 
> every time -- so far it's only happened once.
> >Fix:
>   I don't know how to fix it.
> 

Should this happen again, it may be sitting in ddb.

Try ssh'ing into the machine and if that works, do a dmesg remotely
and see if it gives any hints.

If ssh doesn't work. you can (blindly) try:

trace
boot reboot

("boot reboot" reboots the machine from ddb)

Then check if your dmesg survived across the reboot on the next boot.
Sometimes more than one "boot reboot" is needed (all typed blindiy).

-ml

> 
> dmesg:
> OpenBSD 5.8-current (GENERIC.MP) #1616: Sun Nov 15 20:58:13 MST 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8464150528 (8072MB)
> avail mem = 8203472896 (7823MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb270 (42 entries)
> bios0: vendor American Megatrends Inc. version "4.6.5" date 05/24/2012
> bios0: CLEVO CO. W240EU/W250EUQ/W270EUQ
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG SSDT HPET SSDT SSDT SSDT
> acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) 
> USB6(S3) USB7(S3) PXSX(S5) RP01(S4) PXSX(S5) RP02(S4) PXSX(S5) RP03(S4) 
> PXSX(S5) RP04(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2394.92 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i7-3630QM CPU @ 2.40GHz, 2394.57 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2394.57 MHz
> cpu2: 
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2394.57 MHz
> cpu3: 
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2394.57 MHz
> cpu4: 
> 

Re: kernel panic - sparc64 on Netra X1 - psycho0: uncorrectable DMA error AFAR

[David Gwynne]

> On 30 Nov 2015, at 9:01 AM, Steven Chamberlain  wrote:
> 
> Hi!
> 
> David Gwynne wrote:
>> could you guys try this and let me know how it goes? i dont expect
>> it to fix the problems, but i also dont expect them to get worse.
> 
> I've never seen those panics with dc(4), but I'm now testing -CURRENT
> with your patch applied as well as mine below, and my Netra X1 is stable
> so far.  Thanks!

hrm. could you try it without your diff below and see if its still stable?

my theory is dc is (was?) sensitive to the layout of objects in memory, so by 
moving the pool page headers in or out of the item pages you're moving dc next 
to something that ends up causing the iommu to fault.

cheers,
dlg


> 
> --- kern/subr_pool.c11 Sep 2015 09:26:13 -  1.193
> +++ kern/subr_pool.c29 Nov 2015 22:59:21 -
> @@ -258,7 +258,7 @@ pool_init(struct pool *pp, size_t size, 
> */
>if (pgsize - (size * items) > sizeof(struct pool_item_header)) {
>off = pgsize - sizeof(struct pool_item_header);
> -   } else if (sizeof(struct pool_item_header) * 2 >= size) {
> +   } else if (sizeof(struct pool_item_header) * 8 >= size) {
>off = pgsize - sizeof(struct pool_item_header);
>items = off / size;
>}
> 
> Regards,
> -- 
> Steven Chamberlain
> ste...@pyro.eu.org

ssh-add pledge crash on Dec 1 snapshot

[Lauri Tirkkonen]

Hi, ssh-add is dumping core from pledge in the Dec 1 snapshot, or more
specifically:

OpenBSD 5.8-current (GENERIC.MP) #1691: Mon Nov 30 19:39:08 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

And the error: ssh-add(31221): syscall 2 "proc"

Happens when you do 'ssh-add < /dev/null' under X (this is also done in
xdm's default Xsession; the intention is to show a graphical dialog box
to ask for the passphrase). I would provide a source fix, but this
particular pledge change does not seem to be available from CVS yet.

-- 
Lauri Tirkkonen | lotheac @ IRCnet