linux-kernel - Re: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20071108101341.6c4f88d4.akpm@linux-foundation.org>
Date:	Thu, 8 Nov 2007 10:13:41 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	roppedisano@...racomspa.it, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org, rjw@...k.pl, linux-acpi@...r.kernel.org
Subject: Re: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)

> On Thu, 8 Nov 2007 13:02:56 -0500 Jeff Garzik <jeff@...zik.org> wrote:
> On Thu, Nov 08, 2007 at 09:49:58AM -0800, Andrew Morton wrote:
> > > On Thu, 08 Nov 2007 17:43:59 +0100 Roberto Oppedisano <roppedisano@...racomspa.it> wrote:
> > > Andrew Morton wrote, On 11/07/2007 09:13 PM:
> > > >> On Wed, 07 Nov 2007 15:15:07 +0100 Roberto Oppedisano <roppedisano@...racomspa.it> wrote:
> > > >> Hello.
> > > >> I noticed that after suspending to ram the DVD-ROM/CDRW
> > > >> drive in no more recognized on my laptop. Looking at dmesg
> > > >> after suspend i found:
> > > >>
> > > >> [    5.313446] ata2.00: _GTF unexpected object type 0x1
> > > >> [    5.313453] ata2.00: ACPI on devcfg failed the second time, disabling 
> > > >> (errno=-22)
> > > >> [    5.313457] ata2.00: revalidation failed (errno=1)
> > > >> [    5.313459] ata2.00: disabled
> > > >>
> > > >>
> > > >> Not sure when the bug was introduced or if it has been always been there
> > > >> (but I can investigate if needed).
> > > >>
> > > >> More details on request.
> > > >>
> > > >> Following dmesg pre and after suspend.
> > > > Yes, it would be useful if you could work ot whether this worked OK in an
> > > > earlier kernel, thanks.
> > > Hello Andrew.
> > > The bug has been recently added.
> > > 
> > > I did a git-bisect, but the result is probably not completely useful,
> > > because many kernel did non build with my config, and I marked them as bad.
> > 
> > Those build errors are bad.  Please report them.  They directly prevented
> > you from finding the commit which caused this regression.
> > 
> > The only way in which we'll stop people doing crap like this is to rub
> > their noses (and the person who committed its nose) in it.
> > 
> > > Anyway here's the output of git-bisect:
> > > 
> > > rao@...ra-bb:/usr/src/linux-2.6$ git bisect bad
> > > 99874d50481c093adfe74e796436024d88b6a48c is first bad commit
> > > commit 99874d50481c093adfe74e796436024d88b6a48c
> > > Author: Jens Axboe <jens.axboe@...cle.com>
> > > Date:   Fri Oct 12 12:50:41 2007 +0200
> > > 
> > >     [BLOCK] Only include the compat ioctl code if CONFIG_BLOCK is set
> > > 
> > >     Add an extra CONFIG_BLOCK_COMPAT that we can use in the Makefile
> > > 
> > >     Signed-off-by: Jens Axboe <jens.axboe@...cle.com>
> > > 
> > > :040000 040000 f88b7b0e496edb8fbdd4bc74abd1a742a6a1d6d9
> > > 32ead3bd57b52a664cc8ccb662195041868d7632 M      block
> > > 
> > > ...
> > > 
> > > If needed I can do further investigation, changing the assumption of
> > > efefc6eb38d43b8e5daef482f575d767b002004e to good and see if the bisect
> > > points to a different commit.
> > 
> > Yes, it'll be some other commit.  Sorry.
> > 
> > It would help you (and me) if an ata developer could pay some attention.
> > 
> > Rafael, please track this as an ata regression.
> 
> We unfortunately need to bounce this ACPI people.
> 
> We recently turned on ACPI by default in libata, which INTRODUCES the
> ability of the BIOS to pass random, unknown-quality ATA commands to the
> device.
> 
> I highly expect some breakage related to this...  if ACPI folks
> determine it is not an ACPI bug, then its a firmware bug and we will
> have to avoid that firmware on that platform.
> 
> Set module option "noacpi" to 1, to disable ACPI and see if that fixes
> the problem.
> 
> This will be a common diagnosis and workaround, FWIW...
> 

I suspect it wold be best to disable the feature for the 2.6.24 release,
then reenable it afterwards and keep doing this until the code is
sufficiently stable.

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