Profile cover photo
Profile photo
Rasmus Lerdorf
2,660 followers -
PHP Guy and master of the LIMIT clause
PHP Guy and master of the LIMIT clause

2,660 followers
About
Rasmus's posts

Post has attachment
Visiting IIT Roorkee this weekend.
PhotoPhotoPhotoPhotoPhoto
34 Photos - View album

Post has attachment
Photo

Post has attachment
Photo

Post has attachment
Photo

Post has attachment
Photo

Post has attachment
Photo

Post has attachment
Photo

Post has attachment
Aha! I figured out my Crucial M4 SSD deaths (https://plus.google.com/u/0/113641248237520845183/posts/SXWeXVY7Y6p) cause. There is an entry in the latest firmware changelog:

Correct a condition where an incorrect response to a SMART counter will cause the m4 drive to become unresponsive after 5184 hours of Power-on time. The drive will recover after a power cycle, however, this failure will repeat once per hour after reaching this point. The condition will allow the end user to successfully update firmware, and poses no risk to user or system data stored on the drive.

Ouch! Checking my Powered-On hours for the 128GB M4. Sure enough 5210 hours now. Now to update the 256GB one and copy everything back and put it back into the laptop. Grr!

Another SSD died on me?


[252837.140962] sd 1:0:0:0: [sdb] Unhandled error code
[252837.140965] sd 1:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[252837.140968] sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 0e 84 8b d8 00 00 08 00
[252837.140976] end_request: I/O error, dev sdb, sector 243567576

Somehow I doubt that both my SSDs in different machines went bad within a couple of weeks of each other. Both machines are running Ubuntu 11.10 with kernel 3.0.0-16-generic and the SSD fstab looking like this:

UUID=65da1033-347d-4b9a-a660-312cb2f33ac0 / ext4 discard,noatime,errors=remount-ro 0 1

Crucial M4 256G

Did I miss some critical Linux bug related to SSDs?

Post has shared content
Your PHP homework
We are in the final push to PHP 5.4 and we need your help. Everyone who is using PHP can give us a hand here, regardless of your technical abilities. Facebook employees, take a break from calculating your stock option scenarios and give us an hour of your time. Yahoo and Zynga engineers, take an hour or two on Monday as well. If your managers complain, just blame me.

Some starting points to choose between:

1) Grab the latest code and run the tests:
svn co https://svn.php.net/repository/php/php-src/branches/PHP_5_4 PHP_5_4
cd PHP_5_4
./buildconf
./configure <add your typical options here>
make
make test

Then, track down one of the failed tests, assuming you had any, and try to figure out why it failed in your environment. Just cd into the directory of the failed test and you will see .out, .diff, .exp and .php files for that test. They should be self-explanatory. If you figure it out, you can open a bug at bugs.php.net with the explanation.

2) Go to https://bugs.php.net and click on one of the shortcut search links you see there. Like the "Most recent open bugs" search. Go in a couple of pages to randomize things a bit and pick one in an area that you know a little bit about. Just a simple, "Yes, I was able to reproduce this problem in my environment" comment is helpful. Or, for many bug reports the reporter misunderstood something, a comment explaining why it isn't a bug helps a lot as well. For documentation bugs, see 3)

3) If in your normal use of the PHP documentation you run across something that isn't quite right and could be better, and/or if you see some really useful user comments that you think should be folded into the documentation, look for an [edit] link near the top-right corner of the page. That takes you to our super-fancy browser-based docbook editor where you can log in anonymously and edit a page and submit the changes to us.
Wait while more posts are being loaded