https://bugzilla.kernel.org/show_bug.cgi?id=14442

Duncan 1i5t5.duncan@cox.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Resolution| |PATCH_ALREADY_AVAILABLE

--- Comment #34 from Duncan 1i5t5.duncan@cox.net 2011-02-23 08:45:14 --- AFAICT, Resolved with 2.6.37 release, so updating as such.

I finally got some time to test with a stable kernel, and as of 2.6.37, as best I can tell (this one bedeviled me to the point I'm reluctant to say it's for sure fixed now, without a YEAR of it not coming back!), it's fixed.

The kernel comes back up and from CLI (there's major X corruption preventing use of it after restore, but that'd be a different bug), I can dmesg, which clearly shows (1) an initial failure to read the drive's ID info properly, as before, but now, (2) instead of kicking it out to sde (with sd[a-d] normal) or whatever as it did before, it apparently retries and comes up with the proper ID, thus returning the drive to the proper sd[a-d] letter and its partitions to the proper place in their assigned md/RAIDs.

On a slightly different note, a big THANKS! to whoever introduced and continues maintaining magic-sysreq. I had a hardware issue for awhile and at first thought it was yet another pre-release kernel bug. A bit of circuit-trace paint later (expensive keyboard) and it's working fine again, but as often the case, I didn't realize how much I took that feature for granted until it failed.

And of course, thanks for getting the device-id detect and if necessary retry working, too. =:^)

Now to see how 2.6.38 is coming along. Maybe the radeon graphics restore-state-on-resume works better now. We'll see.