Re: [regression] external HDD in USB3 enclosure cannot bedynamically removed (Re: Linux 3.7.5)

[Sarah Sharp]

On Wed, Feb 13, 2013 at 09:04:13PM +0100, Matthias Schniedermeyer wrote:
> On 13.02.2013 11:33, Sarah Sharp wrote:
> > On Wed, Feb 13, 2013 at 06:16:56PM +0100, Matthias Schniedermeyer wrote:
> > > On 13.02.2013 09:28, Holger Hoffstätte wrote:
> > > > On 12.02.2013 21:42, Sarah Sharp wrote:
> > > > > [..]
> > > > > There was a further set of patches queued for 3.9 to deal with connected
> > > > > devices going to the Inactive state, but they looked like they were too
> > > > > big for stable:
> > > > > 
> > > > > d3b9d7a USB: Fix connected device switch to Inactive state.
> > > > > a24a607 USB: Rip out recursive call on warm port reset.
> > > > > 2d4fa94 USB: Prepare for refactoring by adding extra udev checks.
> > > > > 0fe51aa USB: Don't use EHCI port sempahore for USB 3.0 hubs.
> > 
> > Holger and Matthias, can you double check that cherry picking just those
> > four patches on top of 3.7.7 or 3.8 works as well?
> 
> 3.7.7 + those 4 patches workes for me.
> 
> As i'm not very firm in git i generated separate diffs for each commit 
> and applying them in the order 2d4fa94 0fe51aa d3b9d7a a24a607 worked 
> without hunks dropped.
> 
> I have attached `git diff` against vanilla 3.7.7, so you can check that 
> i got it right.

Yep, that diff looks fine compared to the git diff of those four patches.

Greg,

How do you want to handle this?  The above four patches should go into
3.8 and stable, but they're not currently in Linus' tree and it's
probably too late in the cycle to merge them this week.  Should we just
wait until 3.9 is out and put the patches into the stable trees then?

My email shows that the bad commit
f7965c0846d74b270e246c1470ca955d5078eb07 has been added to the 3.2, 3.4,
and 3.7 stable trees, as well as Canonical's 3.7 stable tree.  I'm also
fine with just reverting that commit from 3.8 and stable.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/