libata does not have a noprobe option at all; that was a legacy IDE option...
But I went and wrote a kernel patch for you that implements it. It Should apply to many kernels very easily (the line above it was added 2013-05-21/v3.10-rc1*, but can be safely applied manually without that line).
Update The patch is now upstream (at least in 3.12.7 stable kernel). It is in the standard kernel distributed with Ubuntu 14.04 (which is based on 3.13-stable).
Once the patch is installed, adding
libata.force=2.00:disable
to the kernel boot parameters will hide the disk from the Linux kernel. Double check that the number is correct; searching for the device name can help (obviously, you have to check the kernel messages before adding the boot parameters):
(0)samsung-romano:~% dmesg | grep iSSD
[ 1.493279] ata2.00: ATA-8: SanDisk iSSD P4 8GB, SSD 9.14, max UDMA/133
[ 1.494236] scsi 1:0:0:0: Direct-Access ATA SanDisk iSSD P4 SSD PQ: 0 ANSI: 5
The important number is the ata2.00 in the first line above.
This doesn't quite answer your question per se, but is arguably a technically correct answer, so I'm taking advantage of the nicer formatting afforded to answers so this isn't 30 wall-of-text comments.
You aren't likely to get an answer on SO/SE, because there simply isn't enough domain-specific knowledge present. You're far better off talking straight to the i915 kernel driver developers.
https://01.org/linuxgraphics/documentation/how-report-bugs contains very comprehensive instructions on how to do so in an organized way.
The way you've worded your bugreport implies that /sys/class/drm/card0-DP-2/status does exist when you connect a DisplayPort cable after boot, but doesn't when a cable and no screen is connected. Well, anything involving /sys/* is definitely not X11-related, and the drm in the path absolutely confirms that you want to follow the 1.1 - DRM Kernel section from the above link.
I've had a look at the details requested by that section and am reasonably confident that the impossible-to-understand bits are not actually needed. This being said, kernel and distro info, full dmesg after rebooting with drm.debug=0xe, etc are all very good ideas.
As is somewhat obvious, two dmesgs would logically be appropriate here; one from a boot without the connector present, and another with. It may be very useful to annotate the exact or approximate point you actually plug the connector in.
5 minutes' thought came up with a suitably hacky-but-successful way to easily annotate:
script -c 'dmesg -w | cat' dmesg.txt
will run dmesg -w and also allow you to type lines of text directly into the terminal to add annotations, and you can ^C when you're done collecting dmesg info. (dmesg -w | cat is shorter than dmesg -w --color=never.)
One possibly-unlikely thing, just in case: has this ever worked? If yes, do you remember what time? If yes, try installing old versions of the distributions you used at those points, and if they work, collect the kernel versions!
Also... you may not want to hear this, but as always one cannot be 100% sure if begrudgingly getting the latest kernel version working doesn't magically fix everything. :)
Thankfully, this is much less fearful than you might fear: https://cgit.freedesktop.org/drm-tip/ is an entire clone of the Linux kernel with the drm tip-of-tree patches already folded in. As best as I can tell, just clone and build this and you should be ready to go.
...That being said, as a matter of cautiousness, you may want to download the latest kernel release and get that known-working first, and then copy the .config over to the drm-tip tree. If you don't do this first, and everything explodes sideways, verifying you can build and boot a mainline kernel may be a good first fire-squashing sanity-check.
Here's the bugzilla page you'll want: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
Actually, that will almost certainly show you a login view; in that case you'll want this URL first: https://bugs.freedesktop.org/createaccount.cgi
Finally, if you want to ask questions, https://01.org/linuxgraphics/community/kernel mentions #gfx-intel on freenode.
FWIW, what I've described above is an ideal set of steps. You might open a provisional bug on freedesktop.org before eg going and doing a kernel rebuild to find out if there aren't some other debugging steps you can try. (The bug entry page only lists "drm git" in the version section, though, so they really want you using the git version... heh)
I actually do have a good question for the IRC channel - I listed the drm-tip git repo because that's the one the documentation mentions, but there's also an drm-intel repo, and I don't know what its relevance is. It also looks like a kernel tree, and is being updated every few minutes too.
Best Answer
This isn't the xrandr-approach the I know works in X, but for console you can try this — you can write to that
/sys/class/drm/card0-DP-1/statusfile as well. I couldn't find proper documentation, but thankfully Linux is open source. Reviewing the source code, it looks like it takes a few values:detect,on,on-digital, andoff.So
echo detect > /sys/class/drm/card0-DP-1/statusshould force a re-check for a monitor. Orecho on-digital > /sys/class/drm/card0-DP-1/statusmight manage to turn it on, regardless of what the detection thinks.edit: Under X, I've used this to deal with HDMI that did not detect being plugged it — it'll force-enable the output. But unfortunately video only, HDMI audio won't work (and apparently isn't possible without a kernel patch):
All those numbers specify the video timings; normally it's auto-detected, the easiest way to get them is to grab the mode it's using when you've booted with it so it's working (
xrandr --verbosewill show them).