On Sun, Oct 28, 2012 at 02:09:01AM +0000, Ben Hutchings wrote: > On Fri, 2012-10-26 at 14:16 +0200, Gabor Z. Papp wrote: > > * Greg KH <[email protected]>: > > > > | > > $ dd if=/dev/zero of=/dev/fd0 > > | > > > > | > > ------------[ cut here ]------------ > > | > > WARNING: at drivers/block/floppy.c:1041 setup_rw_floppy+0x2f7/0x310 > > [floppy]() > > | > > Hardware name: System Product Name > > | > > floppy_disable_hlt() scheduled for removal in 2012 > > | > > > | > Yes. I don't understand the point of that warning: > > | > http://bugs.debian.org/667501 > > | > > > | > Ben and Greg, would > > | > > > | > f6365201d8a2 x86: Remove the ancient and deprecated disable_hlt() > > | > and enable_hlt() facility > > | > > > | > be a candidate for inclusion in the 3.0.y and 3.2.y trees? > > | > > > | > An alternative would be to revert 3b70b2e5fcf6 ("x86 idle floppy: > > | > deprecate disable_hlt()", 2011-04-01), which in principle seems a > > | > little safer. > > > > | Gabor, does applying this patch fix this issue? > > > > Yes, using patch¹ fix this issue with 3.0.48 and 3.2.32. > > > > ¹http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=x86-Remove-the-ancient-and-deprecated-disable_hlt-an.patch;att=1;bug=667501 > > I find this particular deprecation process deeply flawed. Since we had > this hack for ages and it wasn't restricted to specific known-broken > CPUs or chipsets, how can we be confident that no later 32-bit PCs > depend on it? Why was the warning issued to floppy users *before* the > change - with no option to test the new behaviour and quiet the warning > - and not after? Many distribution users who skip several kernel > versions will never see the warning at all. > > (Bonus bug: the warning was not dependent on CONFIG_X86_32.) > > Greg, which of these bad options do you think is preferable?
I don't really know. I'm leaning to include the f6365201d8a2 commit, but am open for other opinions. greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
