[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4733684D.6080108@rtr.ca>
Date: Thu, 08 Nov 2007 14:49:33 -0500
From: Mark Lord <liml@....ca>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Jeff Garzik <jeff@...zik.org>, 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)
Andrew Morton wrote:
>> On Thu, 8 Nov 2007 13:19:05 -0500 Jeff Garzik <jeff@...zik.org> wrote:
>> On Thu, Nov 08, 2007 at 10:13:41AM -0800, Andrew Morton wrote:
>>>> 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:
..
>>> 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.
>> Re-read my message :)
>>
>> The code is stable. Behavior _by definition_ will vary by BIOS.
>>
>> This feature (a) enables suspend/resume, but (b) now sends random
>> unvalidated shite to the device that we hope will work.
>>
>> Look at all the messages where turning on ACPI in libata _fixed_
>> suspend/resume (because its obviously required for many, including
>> laptops).
>
> We fixed a somewhat-known number of machines and broke an unknown number.
> Linus will come after you with a pointy stick if he finds out.
>
> Fixing previously-broken machines is nice, but breaking previously-working
> ones gets people a lot more upset.
>
>> So it's not an easy "turn it off" answer, you break shitloads of
>> suspend/resume that way, that we just fixed.
>>
>> The message "_GTF unexpected object type" indicates a broken BIOS, so
>> IMO we should proceed in that direction, blacklisting that platform.
>>
>
> Suggest that the feature be disabled until we have most of these
> blacklistings in place.
..
The problem is, this code has already sat out the last release,
and nobody noticed problems exactly because it was not enabled before.
If Jeff disables it again, then it will sit out another cycle without
anybody exercising it. At some point, we need to turn it on, and collect
information about where there are problems (and fix them).
Tricky, that.
-
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/
Powered by blists - more mailing lists