Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On Feb 20, 2013, at 10:14 PM, Digimer li...@alteeve.ca wrote: I wanted to use the onboard FDE but didn't find docs on how to do it. Yeah small problem. They even make it difficult to figure out if it's an OPAL variety of SED. If it is, it's always encrypting, it's just unlocked by default. So figuring out a better way to support SEDs is useful. As for discard, can I just add this after defaults? defaults is just a place holder, you can change defaults to discard. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On 02/19/2013 01:49 AM, Chris Murphy wrote: On Feb 18, 2013, at 10:13 PM, Digimer li...@alteeve.ca wrote: what's offline data collection? http://smartmontools.sourceforge.net/man/smartctl.8.html Read in particular the paragraph containing the word unfortunate. 0x0009 2 19 Transition from drive PhyRdy to drive PhyNRdy Have you had about 19 of these freezes? You said you've had the problem with lock screen which implies inactivity. I wonder if the system is sleeping/hibernating and the drive isn't waking up in time and dbus or gdm or gnome-shell are getting irritated. I'd ssh in remotely, run journalctl --follow and see what's displayed the next time you have a freeze. Chris Murphy An update; I reinstalled on the Samsung 840 Pro not long before I ran/reported the smart test earlier in the thread. I've been running now for a couple days with F18 and have not had another crash. The main differences from last time is that; a) I had installed windows on the drive and ran the Samsung SSD utils, though I don't think it changed anything unless it did so behind the scenes. b) I 0'ed out the entire drive (over USB from F18 on my older SSD) before reinstalling F18 on the Samsung. Not sure how or if these could have changed anything. However, this is the longest stretch I've gone without a crash since getting this Samsung drive. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On Feb 20, 2013, at 12:42 PM, Digimer li...@alteeve.ca wrote: b) I 0'ed out the entire drive (over USB from F18 on my older SSD) before reinstalling F18 on the Samsung. FYI this isn't a good idea with SSDs. Use ATA Secure Erase instead with hdparm, or the included Windows utility can do this - it almost always requires a direct SATA connection because most of the USB to SATA bridge chipsets are crap and don't pass through these ATA commands. What mount options are you using? In particular do you have discard enabled? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On Feb 20, 2013, at 3:45 PM, Digimer li...@alteeve.ca wrote: Currently, as the OS disk, it mounts on boot with the default values set by Fedora; ==] /etc/fstab [ /dev/mapper/luks-bd252fe0-a16f-4a14-ad4e-b99a0d4c0716 / ext4 defaults,x-systemd.device-timeout=0 1 1 UUID=eca11946-68d8-444c-90f2-ad65455caf6d /boot ext4 defaults1 2 Thanks for the tips on secure erase. I'll use that in the future. I would do it now because as far as that SSD is concerned, every single block is in use, and then also you should be using the discard mount option, and also not using dmcrypt. The 840 Pro supports FDE, that's what you should use. But for reference dmcrypt supports TRIM passthrough, just not by default. https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Discard.2FTRIM_support_for_solid_state_disks_.28SSD.29 Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On 02/20/2013 10:37 PM, Chris Murphy wrote: On Feb 20, 2013, at 3:45 PM, Digimer li...@alteeve.ca wrote: Currently, as the OS disk, it mounts on boot with the default values set by Fedora; ==] /etc/fstab [ /dev/mapper/luks-bd252fe0-a16f-4a14-ad4e-b99a0d4c0716 / ext4 defaults,x-systemd.device-timeout=0 1 1 UUID=eca11946-68d8-444c-90f2-ad65455caf6d /boot ext4 defaults1 2 Thanks for the tips on secure erase. I'll use that in the future. I would do it now because as far as that SSD is concerned, every single block is in use, and then also you should be using the discard mount option, and also not using dmcrypt. The 840 Pro supports FDE, that's what you should use. But for reference dmcrypt supports TRIM passthrough, just not by default. https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Discard.2FTRIM_support_for_solid_state_disks_.28SSD.29 Chris Murphy I wanted to use the onboard FDE but didn't find docs on how to do it. As for discard, can I just add this after defaults? I'll read that link now. Thank you, again. :) -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On 02/19/2013 01:49 AM, Chris Murphy wrote: On Feb 18, 2013, at 10:13 PM, Digimer li...@alteeve.ca wrote: what's offline data collection? http://smartmontools.sourceforge.net/man/smartctl.8.html Read in particular the paragraph containing the word unfortunate. 0x0009 2 19 Transition from drive PhyRdy to drive PhyNRdy Have you had about 19 of these freezes? You said you've had the problem with lock screen which implies inactivity. I wonder if the system is sleeping/hibernating and the drive isn't waking up in time and dbus or gdm or gnome-shell are getting irritated. I'd ssh in remotely, run journalctl --follow and see what's displayed the next time you have a freeze. Thanks for the link and key word! I've started to lose count, but I think it's been 12 or 13 lock ups. However, one of those failed to recover or instantly re-failed after restarting dbus. At least, this is how many I noticed. Does the number 19 come from: = 0x0009 2 19 Transition from drive PhyRdy to drive PhyNRdy 0x000a 2 19 Device-to-host register FISes sent due to a COMRESET = If so, is this a sign of a bad drive? If so, could gnome/dbus/whatever handle the failure better? I just reinstalled on the Samsung last night. As soon as I get a crash, I will run 'journalctl --follow' and 'dmesg' and report whatever is shown. Thanks again! -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Frequent dbus(?) crashes with Samsung 840 Pro SSD
Last weekend, I both a new Samsung 840 Pro 256GB SSD. Prior to this, I
was using a Corsair Performance Pro 256 SSD without issue (F17 had been
upgrade to F18 about a week before). I got the drive to do a fresh install.
From last weekend until Saturday, I would get ~2~3 hard crashes a day.
Gnome 3 would lock up hard, but I could ctrl+alt+fX to get to other
terminals. Here's my original post/thread;
http://lists.fedoraproject.org/pipermail/users/2013-February/430993.html
Two days ago, I reinstalled F18 on my Corsair drive. I had the Samsung
connected as a USB drive to restore my files and after a few hours, the
system locked up again ('tail -n 100' below). I pulled the Samsung out
of the laptop and booted with just the Corsair and it's been rock solid
since.
Each time it crashed, it *looked* like a dbus hang-up. However, I am not
a programmer so I could be way off base with this guess. Here's the last
log from the system after the last crash (when the drive was the OS
drive, I didn't get the messages from the crash when it was connected
via USB);
===
Feb 16 11:16:25 lemass avahi-daemon[694]: New relevant interface
em1.IPv4 for mDNS.
Feb 16 11:16:25 lemass avahi-daemon[694]: Registering new address record
for 10.255.0.229 on em1.IPv4.
Feb 16 11:16:26 lemass avahi-daemon[694]: Registering new address record
for fe80::f2de:f1ff:fefc:65b3 on em1.*.
Feb 16 11:16:26 lemass NetworkManager[860]: info (em1): device state
change: ip-config - secondaries (reason 'none') [70 90 0]
Feb 16 11:16:26 lemass NetworkManager[860]: info Activation (em1)
Stage 5 of 5 (IPv4 Commit) complete.
Feb 16 11:16:26 lemass NetworkManager[860]: info (em1): device state
change: secondaries - activated (reason 'none') [90 100 0]
Feb 16 11:16:26 lemass NetworkManager[860]: info Policy set 'Boot
Disk' (em1) as default for IPv4 routing and DNS.
Feb 16 11:16:26 lemass NetworkManager[860]: info Activation (em1)
successful, device activated.
Feb 16 11:16:26 lemass systemd[1]: Starting LSB: Starts and stops login
and scanning of iSCSI devices
Feb 16 11:16:26 lemass iscsi[6568]: Starting iscsi: iscsiadm: No records
found
Feb 16 11:16:26 lemass iscsi[6568]: [ OK ]
Feb 16 11:16:26 lemass systemd[1]: Started LSB: Starts and stops login
and scanning of iSCSI devices..
Feb 16 11:16:26 lemass dbus-daemon[733]: Starting iscsi (via systemctl):
[ OK ]
Feb 16 11:16:26 lemass systemd[1]: Stopping Sendmail Mail Transport
Client...
Feb 16 11:16:26 lemass systemd[1]: Stopping Sendmail Mail Transport Agent...
Feb 16 11:16:26 lemass systemd[1]: Starting Sendmail Mail Transport Agent...
Feb 16 11:16:26 lemass systemd[1]: Started Sendmail Mail Transport Agent.
Feb 16 11:16:26 lemass systemd[1]: Starting Sendmail Mail Transport
Client...
Feb 16 11:16:26 lemass chronyd[780]: Source 174.36.71.205 online
Feb 16 11:16:26 lemass chronyd[780]: Source 50.97.210.169 online
Feb 16 11:16:26 lemass chronyd[780]: Source 70.88.148.4 online
Feb 16 11:16:26 lemass chronyd[780]: Source 96.44.142.5 online
Feb 16 11:16:26 lemass systemd[1]: Started Sendmail Mail Transport Client.
Feb 16 11:16:26 lemass chronyd[780]: Selected source 174.36.71.205
Feb 16 11:16:26 lemass chronyd[780]: System clock wrong by 1.803794
seconds, adjustment started
Feb 16 11:18:36 lemass chronyd[780]: Selected source 70.88.148.4
Feb 16 11:35:24 lemass dbus-daemon[733]: dbus[733]: [system] Activating
service name='org.freedesktop.PackageKit' (using servicehelper)
Feb 16 11:35:24 lemass dbus[733]: [system] Activating service
name='org.freedesktop.PackageKit' (using servicehelper)
Feb 16 11:35:24 lemass dbus-daemon[733]: dbus[733]: [system]
Successfully activated service 'org.freedesktop.PackageKit'
Feb 16 11:35:24 lemass dbus[733]: [system] Successfully activated
service 'org.freedesktop.PackageKit'
Feb 16 11:59:18 lemass kernel: [15870.934309] nf_conntrack: automatic
helper assignment is deprecated and it will be removed soon. Use the
iptables CT target to attach helpers instead.
Feb 16 12:23:20 lemass dbus-daemon[733]: dbus[733]: [system] Activating
via systemd: service name='org.freedesktop.hostname1'
unit='dbus-org.freedesktop.hostname1.service'
Feb 16 12:23:20 lemass dbus[733]: [system] Activating via systemd:
service name='org.freedesktop.hostname1'
unit='dbus-org.freedesktop.hostname1.service'
Feb 16 12:23:20 lemass systemd[1]: Starting Hostname Service...
Feb 16 12:23:20 lemass dbus-daemon[733]: dbus[733]: [system]
Successfully activated service 'org.freedesktop.hostname1'
Feb 16 12:23:20 lemass dbus[733]: [system] Successfully activated
service 'org.freedesktop.hostname1'
Feb 16 12:23:20 lemass systemd[1]: Started Hostname Service.
Feb 16 12:26:34 lemass dbus-daemon[733]: dbus[733]: [system] Activating
service name='org.freedesktop.PackageKit' (using servicehelper)
Feb 16 12:26:34 lemass dbus[733]: [system] Activating service
name='org.freedesktop.PackageKit' (using servicehelper)
Feb 16 12:26:34 lemass dbus-daemon[733]:
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On Feb 18, 2013, at 7:20 PM, Digimer li...@alteeve.ca wrote:
Two days ago, I reinstalled F18 on my Corsair drive. I had the Samsung
connected as a USB drive to restore my files and after a few hours, the
system locked up again ('tail -n 100' below). I pulled the Samsung out of the
laptop and booted with just the Corsair and it's been rock solid since.
I assume you've looked at smartctl -a on this drive, and that's why you don't
think it's just a bad SSD that needs to be swapped out for replacement? I'm
using an 830, which is related to the 840, but admittedly different in some
important ways; but I'm not experiencing problems like you're describing.
And what have you found in dmesg for the time this is happening? Or 'journalctl
--follow' using ssh?
Each time it crashed, it *looked* like a dbus hang-up.
Why do you say this? There's nothing in your syslog that implicates dbus, or
anything else for that matter. I also think that's the wrong diagnostic tool
for this, actually.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On 02/18/2013 09:50 PM, Chris Murphy wrote:
On Feb 18, 2013, at 7:20 PM, Digimer li...@alteeve.ca wrote:
Two days ago, I reinstalled F18 on my Corsair drive. I had the Samsung
connected as a USB drive to restore my files and after a few hours, the system
locked up again ('tail -n 100' below). I pulled the Samsung out of the laptop
and booted with just the Corsair and it's been rock solid since.
I assume you've looked at smartctl -a on this drive, and that's why you don't
think it's just a bad SSD that needs to be swapped out for replacement? I'm
using an 830, which is related to the 840, but admittedly different in some
important ways; but I'm not experiencing problems like you're describing.
And what have you found in dmesg for the time this is happening? Or 'journalctl
--follow' using ssh?
Each time it crashed, it *looked* like a dbus hang-up.
Why do you say this? There's nothing in your syslog that implicates dbus, or
anything else for that matter. I also think that's the wrong diagnostic tool
for this, actually.
Chris Murphy
I went so far as to install Windows 7 on the 840 Pro, downloaded and ran
Samsung's own tool to verify it was at the latest firmware and was
healthy. The smartctl is below.
Next time it crashes, I will check dmesg and run that command.
If it's not dbus, which I readily admitted it might not be :), I would
love to hear suggestions. The reason I thought it was related to dbus
was that I kept seeing so many dbus messages at the time of each crash.
Also, restarting the dbus.service would (all but one time) recover Gnome
and restore the system to working. Of course, that could be normal and
unrelated.
Again, I am open to advice or suggestions.
==
[root@localhost digimer]# smartctl -a /dev/sda
smartctl 6.0 2012-10-10 r3643 [x86_64-linux-3.6.10-4.fc18.x86_64] (local
build)
Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: Samsung SSD 840 PRO Series
Serial Number:S12RNEACC95023M
LU WWN Device Id: 5 002538 55015d61e
Firmware Version: DXM04B0Q
User Capacity:256,060,514,304 bytes [256 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate:Solid State Device
Device is:Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:Mon Feb 18 22:43:47 2013 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine
completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection:(53956) seconds.
Offline data collection
capabilities:(0x53) SMART execute Offline immediate.
Auto Offline data collection on/off
support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities:(0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability:(0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time:( 2) minutes.
Extended self-test routine
recommended polling time:( 20) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010Pre-fail
Always - 0
9 Power_On_Hours 0x0032 099 099 000Old_age
Always - 88
12 Power_Cycle_Count 0x0032 099 099 000
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On Feb 18, 2013, at 8:44 PM, Digimer li...@alteeve.ca wrote: I went so far as to install Windows 7 on the 840 Pro, downloaded and ran Samsung's own tool to verify it was at the latest firmware and was healthy. The smartctl is below. update-smart-drivedb smartctl -t long /dev/sda wait 20 minutes if system is idle; longer if active smartctl -x /dev/sda Report that smartctl along with dmesg. [root@localhost digimer]# smartctl -a /dev/sda Total time to complete Offline data collection: (53956) seconds. Weird. 15 hours for an SSD offline data collection? On my 830 this figure is 1020 seconds, same as the extended self-test. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On 02/18/2013 11:24 PM, Chris Murphy wrote: On Feb 18, 2013, at 8:44 PM, Digimer li...@alteeve.ca wrote: I went so far as to install Windows 7 on the 840 Pro, downloaded and ran Samsung's own tool to verify it was at the latest firmware and was healthy. The smartctl is below. update-smart-drivedb smartctl -t long /dev/sda wait 20 minutes if system is idle; longer if active smartctl -x /dev/sda Report that smartctl along with dmesg. [root@localhost digimer]# smartctl -a /dev/sda Total time to complete Offline data collection:(53956) seconds. Weird. 15 hours for an SSD offline data collection? On my 830 this figure is 1020 seconds, same as the extended self-test. Chris Murphy The output of the smartctl commands are below. Pardon the ignorance, but what's offline data collection? digimer ps - thanks for the help. :) localhost:~# smartctl -x /dev/sda smartctl 6.0 2012-10-10 r3643 [x86_64-linux-3.7.8-202.fc18.x86_64] (local build) Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Samsung based SSDs Device Model: Samsung SSD 840 PRO Series Serial Number:S12RNEACC95023M LU WWN Device Id: 5 002538 55015d61e Firmware Version: DXM04B0Q User Capacity:256,060,514,304 bytes [256 GB] Sector Size: 512 bytes logical/physical Rotation Rate:Solid State Device Device is:In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is:Tue Feb 19 00:11:44 2013 EST SMART support is: Available - device has SMART capability. SMART support is: Enabled AAM feature is: Unavailable APM feature is: Unavailable Rd look-ahead is: Enabled Write cache is: Enabled ATA Security is: Disabled, frozen [SEC2] === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection:(53956) seconds. Offline data collection capabilities:(0x53) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. No Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 2) minutes. Extended self-test routine recommended polling time:( 20) minutes. SCT capabilities: (0x003d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGSVALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 100 100 010-0 9 Power_On_Hours -O--CK 099 099 000-89 12 Power_Cycle_Count -O--CK 099 099 000-53 177 Wear_Leveling_Count PO--C- 099 099 000-3 179 Used_Rsvd_Blk_Cnt_Tot PO--C- 100 100 010-0 181 Program_Fail_Cnt_Total -O--CK 100 100 010-0 182 Erase_Fail_Count_Total -O--CK 100 100 010-0 183 Runtime_Bad_Block PO--C- 100 100 010-0 187 Uncorrectable_Error_Cnt -O--CK 100 100 000-0 190 Airflow_Temperature_Cel -O--CK 062 059 000-38 195 ECC_Rate-O-RC- 200 200 000-0 199 CRC_Error_Count -OSRCK 100 100 000-0 235 POR_Recovery_Count -O--C- 099 099 000-6 241 Total_LBAs_Written -O--CK 099 099 000-1153722313 ||_ K auto-keep
Re: Frequent dbus(?) crashes with Samsung 840 Pro SSD
On Feb 18, 2013, at 10:13 PM, Digimer li...@alteeve.ca wrote: what's offline data collection? http://smartmontools.sourceforge.net/man/smartctl.8.html Read in particular the paragraph containing the word unfortunate. 0x0009 2 19 Transition from drive PhyRdy to drive PhyNRdy Have you had about 19 of these freezes? You said you've had the problem with lock screen which implies inactivity. I wonder if the system is sleeping/hibernating and the drive isn't waking up in time and dbus or gdm or gnome-shell are getting irritated. I'd ssh in remotely, run journalctl --follow and see what's displayed the next time you have a freeze. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
