Blank screen in the morning.

[dogshed]

I go to bed and when I get up in the morning my laptop is on, but the screen is blank and I have to shut it off by holding down the power button.
I don't know if this is X or what.
It's a Dell XPS 12 (The one from a few years ago, not the new one that just came out.)
I don't know where to start looking.
Thanks.

[GreyGeek]

Run Ksystemlog from the system menu and follow the timeline backward from the boot time in "system", then "kernel" then "X"

Or, run journalctl in a Konsol, hit the "End" key to get to the bottom and then "PgUp" past the latest boot time to get to the last lines before the X failure.

[dogshed]

Thanks. I don't know what I'm looking for though.
I have this repeated a lot last night:
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011Property: Backlight
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011State (newValue, Deleted): 0
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: RRNotify_OutputProperty (ignored)
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011Output: 67
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011Property: Backlight
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011State (newValue, Deleted): 0
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: RRNotify_OutputProperty (ignored)
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011Output: 67
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011Property: Backlight
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011State (newValue, Deleted): 0
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: RRNotify_OutputProperty (ignored)
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011Output: 67
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011Property: Backlight
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011State (newValue, Deleted): 0
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: RRNotify_OutputProperty (ignored)
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011Output: 67
Jul 29 21:39:16 dog org.kde.KScreen[2974]: kscreen.xcb.helper: #011Property: Backlight

[dogshed]

Thanks. I don't know what I'm looking for though.
I can see where I plugged in my phone. I'm assuming that was around the time I went to bed.
Jul 29 21:41:41 dog kernel: [28318.183361] usb 2-1: Product: SAMSUNG_Android
Jul 29 21:41:41 dog kernel: [28318.183362] usb 2-1: Manufacturer: SAMSUNG
Jul 29 21:41:41 dog kernel: [28318.183363] usb 2-1: SerialNumber: 444a96fc
Jul 29 21:47:05 dog org.kde.KScreen[2974]: kscreen: Primary output changed from KScreen::Output(Id: 67 , Name: "eDP1" ) (
"eDP1" ) to KScreen::Output(Id: 67 , Name: "eDP1" ) ( "eDP1" )
Jul 29 21:47:05 dog org.kde.KScreen[2974]: message repeated 7 times: [ kscreen: Primary output changed from KScreen::Outpu
t(Id: 67 , Name: "eDP1" ) ( "eDP1" ) to KScreen::Output(Id: 67 , Name: "eDP1" ) ( "eDP1" )]
Jul 29 21:49:50 dog smartd[2615]: Device: /dev/sdb [SAT], 16 Currently unreadable (pending) sectors
Jul 29 21:49:50 dog smartd[2615]: Device: /dev/sdb [SAT], 16 Offline uncorrectable sectors
Jul 29 21:54:19 dog kernel: [29075.928684] BTRFS info (device sdb1): disk space caching is enabled
Jul 29 21:54:19 dog kernel: [29075.928688] BTRFS: has skinny extents
Jul 29 21:54:22 dog udisksd[2883]: Mounted /dev/sdb1 at /media/dogshed/btrfs-seagate on behalf of uid 1000
Jul 29 21:56:34 dog org.kde.kuiserver[2974]: kuiserver: adding job contact for address: ":1.20" objectPath: "/DataEngin
e/applicationjobs/JobView_2"
Jul 29 21:56:34 dog org.kde.KScreen[2974]: kscreen: Primary output changed from KScreen::Output(Id: 67 , Name: "eDP1" ) (
"eDP1" ) to KScreen::Output(Id: 67 , Name: "eDP1" ) ( "eDP1" )
Jul 29 21:56:34 dog org.kde.KScreen[2974]: message rep

[GreyGeek]

First you need to look at your Btrfs. You have unreadable and uncorrectable sectors.
Use "man btrfs-rescue". Also look at "man btrfs-check" and the Btrfs commands that allow status, balance, etc...

[dogshed]

First you need to look at your Btrfs. You have unreadable and uncorrectable sectors.
Use "man btrfs-rescue". Also look at "man btrfs-check" and the Btrfs commands that allow status, balance, etc...

The btrfs drive is an external backup drive. I'm not that worried about it. I wouldn't think it would cause the blank screen in the morning.
I ran a check on it in gparted and it says it's OK.

[oshunluvr]

Jul 29 21:49:50 dog smartd[2615]: Device: /dev/sdb [SAT], 16 Currently unreadable (pending) sectors
Jul 29 21:49:50 dog smartd[2615]: Device: /dev/sdb [SAT], 16 Offline uncorrectable sectors

Jerry, those are smartd errors so they're related to the hardware not the file system.

dogshed, regardless you should run a long test with smartctl and make sure your drive isn't about to die.

Also, some info about your video would help: chipset, driver, brand,model etc.

[GreyGeek]

Jerry, those are smartd errors so they're related to the hardware not the file system.

dogshed, regardless you should run a long test with smartctl and make sure your drive isn't about to die.
...

I saw the smartd lables. If one or more sectors are going bad my thinking was that he could have Btrfs move the data in the bad areas to good locations. I'd be surprised if he isn't in the beginning of HD failure because of exhaustion of his reserve sectors.

[dogshed]

I saw the smartd lables. If one or more sectors are going bad my thinking was that he could have Btrfs move the data in the bad areas to good locations. I'd be surprised if he isn't in the beginning of HD failure because of exhaustion of his reserve sectors.

I'm not sure btrfs will do that. I think bad sectors and blocks are handled by the hardware. One thing I found said I should write to everywhere on the drive so the drive hardware would know which blocks were bad. (Must be true, it was on the internet.)

[dogshed]

Jerry, those are smartd errors so they're related to the hardware not the file system.

dogshed, regardless you should run a long test with smartctl and make sure your drive isn't about to die.

Also, some info about your video would help: chipset, driver, brand,model etc.

Thanks.
The Dell website says: Intel HD Graphics 4000 (UMA)
lspci says: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) (prog-if 00 [VGA
controller])
Subsystem: Dell Haswell-ULT Integrated Graphics Controller
It's a Dell XPS 12 purchased in 2014. According to Wikipedia it has a Haswell processor. It's not the XPS 12 that came out last year.

[dogshed]

I saw the smartd lables. If one or more sectors are going bad my thinking was that he could have Btrfs move the data in the bad areas to good locations. I'd be surprised if he isn't in the beginning of HD failure because of exhaustion of his reserve sectors.

Here's a nice thread about bad sector reads. Maybe I'll write to my whole disk some day.
http://serverfault.com/questions/104...n-a-linux-disk
This btrfs drive is a brand new Seagate expansion drive my wife gave me. I copied everything to it and then decided to convert it to btrfs. All that writing really heated it up. For safety I really need a third copy somewhere. It's mostly pictures from trips.

[dogshed]

Since my scrub reported no errors I guess I'm safe on the disk issue.
I have all the files on an external ntfs drive so that gives me some redundancy for now.
For the screen blanking, I think I'll just wait for it to happen again. It might have been caused by the drive. Now I can't remember if I was running anything on that drive when I went to bed that night.
Thanks for all your help.

[GreyGeek]

I'm not sure btrfs will do that. I think bad sectors and blocks are handled by the hardware. One thing I found said I should write to everywhere on the drive so the drive hardware would know which blocks were

If that were true then fsck would be a waste of time. The OS (and thus fsck or btrfs) operate on the disk through the disk controller. They do not need to know the condition of sector B to determine if sector A is bad. When a read fails a chksum the controller is informed. Using parity the data is moved to another part of the drive and the controller marks the sector (or block) bad and activates a sector from reserve. The disk becomes marginal when the reserve blocks are exhausted and subsequent failures cannot be replaced. These events usually cascade after the MTBF has been reached or the drive was damaged by excessive G forces. This says nothing about low quality drives that have cheap components or design parameters. About 20 yrs ago Seagate (IIRC) was in economic trouble and started sending out defective returned drives to fulfill new orders. It caught up with them.

[dogshed]

If that were true then fsck would be a waste of time. The OS (and thus fsck or btrfs) operate on the disk through the disk controller. They do not need to know the condition of sector B to determine if sector A is bad. When a read fails a chksum the controller is informed. Using parity the data is moved to another part of the drive and the controller marks the sector (or block) bad and activates a sector from reserve. The disk becomes marginal when the reserve blocks are exhausted and subsequent failures cannot be replaced. These events usually cascade after the MTBF has been reached or the drive was damaged by excessive G forces. This says nothing about low quality drives that have cheap components or design parameters. About 20 yrs ago Seagate (IIRC) was in economic trouble and started sending out defective returned drives to fulfill new orders. It caught up with them.

Since I haven't dug through the code, and have no intention to, I really don't know for sure how all this works. I have to rely on random things I find on the internet.
If you look at this thread there is a section by a guy who says he worked for WD. See if that matches what you are thinking. http://serverfault.com/questions/104...n-a-linux-disk

[dogshed]

It happened again. No drive plugged in this time.
I have a lot of these messages in syslog:
Aug 2 15:25:56 dog org.kde.KScreen[2970]: kscreen.xcb.helper: #011State (newValue, Deleted): 0
Aug 2 15:25:57 dog org.kde.KScreen[2970]: kscreen.xcb.helper: RRNotify_OutputProperty (ignored)
Aug 2 15:25:57 dog org.kde.KScreen[2970]: kscreen.xcb.helper: #011Output: 67
Aug 2 15:25:57 dog org.kde.KScreen[2970]: kscreen.xcb.helper: #011Property: Backlight
Aug 2 15:25:57 dog org.kde.KScreen[2970]: kscreen.xcb.helper: #011State (newValue, Deleted): 0
Aug 2 15:25:57 dog org.kde.KScreen[2970]: kscreen.xcb.helper: RRNotify_OutputProperty (ignored)
Aug 2 15:25:57 dog org.kde.KScreen[2970]: kscreen.xcb.helper: #011Output: 67
Aug 2 15:25:57 dog org.kde.KScreen[2970]: kscreen.xcb.helper: #011Property: Backlight
Aug 2 15:25:57 dog org.kde.KScreen[2970]: kscreen.xcb.helper: #011State (newValue, Deleted): 0
Aug 2 15:25:57 dog wpa_supplicant[2787]: wlp6s0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1
Aug 2 15:26:02 dog wpa_supplicant[2787]: message repeated 5 times: [ wlp6s0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1]
Aug 2 15:26:03 dog dhclient[4175]: DHCPREQUEST of 192.168.16.105 on wlp6s0 to 192.168.16.254 port 67 (xid=0x1f87b158)
Aug 2 15:26:03 dog dhclient[4175]: send_packet: Operation not permitted
Aug 2 15:26:03 dog dhclient[4175]: dhclient.c:2386: Failed to send 300 byte long packet over fallback interface.
Aug 2 15:26:03 dog wpa_supplicant[2787]: wlp6s0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1
Aug 2 15:26:13 dog wpa_supplicant[2787]: message repeated 10 times: [ wlp6s0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1]
Aug 2 15:26:14 dog dhclient[4175]: DHCPREQUEST of 192.168.16.105 on wlp6s0 to 192.168.16.254 port 67 (xid=0x1f87b158)
Aug 2 15:26:14 dog dhclient[4175]: send_packet: Operation not permitted
Aug 2 15:26:14 dog dhclient[4175]: dhclient.c:2386: Failed to send 300 byte long packet over fallback interface.
Aug 2 15:26:14 dog wpa_supplicant[2787]: wlp6s0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1
Aug 2 15:26:33 dog wpa_supplicant[2787]: message repeated 19 times: [ wlp6s0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1]
Aug 2 15:26:33 dog dhclient[4175]: DHCPREQUEST of 192.168.16.105 on wlp6s0 to 192.168.16.254 port 67 (xid=0x1f87b158)
Aug 2 15:26:33 dog dhclient[4175]: send_packet: Operation not permitted
Aug 2 15:26:33 dog dhclient[4175]: dhclient.c:2386: Failed to send 300 byte long packet over fallback interface.
: