At Thu, 13 Dec 2007 11:49:51 +0100,
I wrote:
>
> [Sorry for the late response as I've been on vacation]
>
> At Sat, 8 Dec 2007 21:15:44 -0500,
> Theodore Tso wrote:
> >
> > On Sat, Dec 08, 2007 at 11:30:53PM +0100, Rafael J. Wysocki wrote:
> > > On Saturday, 8 of December 2007, Theodore Tso wrot
On Tue, 11 Dec 2007 10:01:20 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok, just to make sure we are all synced up. I made 8 patches related to
> this problem category (and all the trickle effects). 3 are upstream
> already, 5 are pending for v2.6.25. One out of those 5 is an immaterial
> c
[Sorry for the late response as I've been on vacation]
At Sat, 8 Dec 2007 21:15:44 -0500,
Theodore Tso wrote:
>
> On Sat, Dec 08, 2007 at 11:30:53PM +0100, Rafael J. Wysocki wrote:
> > On Saturday, 8 of December 2007, Theodore Tso wrote:
> > > However, as far as I am concerned, Ingo's patch, firs
On Tue, 11 Dec 2007 10:01:20 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok, just to make sure we are all synced up. I made 8 patches related to
> this problem category (and all the trickle effects). 3 are upstream
> already, 5 are pending for v2.6.25. One out of those 5 is an immaterial
> c
* Stefano Brivio <[EMAIL PROTECTED]> wrote:
> > Stefano, could you please try to sum up your experiences with that
> > issue? Is it reproducable, and the 5 patches i did fix it? (if yes,
> > could you try to re-do the mdelay verifications perhaps, to make
> > sure it's not some other effect in
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Stefano Brivio <[EMAIL PROTECTED]> wrote:
>
> > Sorry for disappearing. Anyway, yes, those patches fixed it. Precision in
> > delays isn't that good when using my crappy unstable TSC (mdelay(2000)
> > causes delays between 2 and 2.9 seconds) but
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > That sounds like a big problem.
>
> it'll get way worse going forward. (but even on todays systems, the
> tsc no longer represents frequency, but is some fixed clock totally
> unrelated to cpu frequency)
X86_FEATURE_CONSTANT_TSC CPUs (all mode
On Tue, 11 Dec 2007 01:01:25 +0100
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > the frequency of both cores is the maximum of what linux sets each
> > core to;
>
> Do you mean that the cpufreq code can be confused about the actual
> frequency
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> the frequency of both cores is the maximum of what linux sets each core to;
Do you mean that the cpufreq code can be confused about the actual
frequency of the cores? That sounds like a big problem.
Thanks for any insight.
--
Guillaume
--
To unsubs
Stefano Brivio <[EMAIL PROTECTED]> wrote:
> Sorry for disappearing. Anyway, yes, those patches fixed it. Precision in
> delays isn't that good when using my crappy unstable TSC (mdelay(2000)
> causes delays between 2 and 2.9 seconds) but it's not depending on frequency
> changes anymore. So I'd sa
On Tue, 11 Dec 2007 00:34:33 +0100
Stefano Brivio <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Dec 2007 00:04:25 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > * Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > > > what do you think? Rig
On Tue, 11 Dec 2007 00:04:25 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > * Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > > what do you think? Right now i've got them queued up for 2.6.25 in
> > > > both the scheduler-devel and the x86-dev
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > what do you think? Right now i've got them queued up for 2.6.25 in
> > > both the scheduler-devel and the x86-devel git trees - but can
> > > submit them for 2.6.24 if it's better if we did them there
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > what do you think? Right now i've got them queued up for 2.6.25 in
> > both the scheduler-devel and the x86-devel git trees - but can
> > submit them for 2.6.24 if it's better if we did them there. I've got
> > no strong opinion either way.
>
> p
On Mon, 10 Dec 2007 21:42:12 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Subject : jiffies counter leaps in 2.6.24-rc3
> > Submitter : Stefano Brivio <[EMAIL PROTECTED]>
> > References : http://lkml.org/lkml/2007/11/24/53
> >
On Dec 10, 2007 9:42 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> although some claimed effect was on udelay()/mdelay() too.
Any specific report?
The jumping sched_clock on frequency change caused some
scheduling oddities for me, but CFS attenuated the effect.
Thanks.
--
Guillaume
--
To unsubsc
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Subject : jiffies counter leaps in 2.6.24-rc3
> Submitter : Stefano Brivio <[EMAIL PROTECTED]>
> References: http://lkml.org/lkml/2007/11/24/53
> http://bugzilla.kernel.org/show_bug.cgi?id=9475
> Handled-By
On Mon, 10 Dec 2007, Alan Cox wrote:
>
> And as I keep pointing out but you keep ignoring - not doing it breaks
> even more things, by a factor of quite a lot.
But we've never done it before in libata, right?
So the "not doing it breaks" argument is about stuff that isn't
regressions.
Can yo
* Tejun Heo <[EMAIL PROTECTED]> wrote:
> The following git tree contains patches pending review for 2.6.25.
>
> http://git.kernel.org/?p=linux/kernel/git/tj/libata-dev.git;a=shortlog;h=improve-ATAPI-data-transfer-no-pio
>
> And we're getting close to fixing the regression. I don't think
> the
Ingo Molnar wrote:
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>> Tejun already reported that this apparently gets fixed _properly_ with
>> the more extensive cleanups and fixes that are pending for 2.6.25.
>
> btw., how extensive are those cleanups and fixes in reality, is there a
> rollup
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Tejun already reported that this apparently gets fixed _properly_ with
> the more extensive cleanups and fixes that are pending for 2.6.25.
btw., how extensive are those cleanups and fixes in reality, is there a
rollup somewhere one could take a lo
> Have you even *read* the thread?
In detail, as it unfolds and while testing variants of Tejun's code on
the hardware I have access to - none of which has this bug making it
rather trickier to help.
> In other words, the stuff you call so critically important (yet we've been
> able to live with
Its your kernel. Its your call, and your privilege to be wrong.
And anyone with ATAPI problems should probably test the -mm tree before
reporting anything.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Tejun Heo wrote:
Robert Hancock wrote:
And you're quite right in your comment that we are often too quick to
blacklist hardware instead of looking into why it really is failing.
ACPI is one of those areas where we often just need to figure out how to
be bug-to-bug compatibile with what Windows i
Robert Hancock wrote:
> And you're quite right in your comment that we are often too quick to
> blacklist hardware instead of looking into why it really is failing.
> ACPI is one of those areas where we often just need to figure out how to
> be bug-to-bug compatibile with what Windows is doing..
I
Andreas Mohr wrote:
> As such one can conclude that this BIOS is rather very confused when being
> called for _GTM on an entirely
> unused controller port. And this is either because the BIOS is dumb or
> because ACPI doesn't really
> expect anyone to call _GTM on an unused physical port. I'd bet
On Sun, 9 Dec 2007, Alan Cox wrote:
>
> The one off regression is probably not one off, but this is IDE so
> actually its quite probable its a single broken firmware.
>
> The alternative is that you cripple just about every user of various
> other standards compliant devices and controllers who
Andreas Mohr wrote:
On Mon, Dec 10, 2007 at 01:04:31AM +0100, Andreas Mohr wrote:
IOW, it seems very likely that _GTM on these BIOSes (VIA chipsets) isn't
actually wrongly implemented but simply expects IDE controller values
to have been set up ""differently"".
Or... one could possibly even in
On Mon, Dec 10, 2007 at 01:04:31AM +0100, Andreas Mohr wrote:
> IOW, it seems very likely that _GTM on these BIOSes (VIA chipsets) isn't
> actually wrongly implemented but simply expects IDE controller values
> to have been set up ""differently"".
>
>
> Or... one could possibly even infer from th
Hi,
On Sun, Dec 09, 2007 at 10:36:42PM +0100, Andreas Mohr wrote:
> And the second, possibly much more lucrative, question would be
> whether we're actually doing something wrong with our ACPI _GTM execution
> which triggers the AE_AML_PACKAGE_LIMIT problem.
>
> This might help here, perhaps (rel
On Dec 9, 2007 2:01 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Btw, Alan, that "math" is total and utter BULLSH*T, and you should know
> > that.
>
> To blindly argue regressions are critical is sometimes (as in this case)
> to argue that "this freeway is no longer compatible with a horse and
> car
> Btw, Alan, that "math" is total and utter BULLSH*T, and you should know
> that.
The one off regression is probably not one off, but this is IDE so
actually its quite probable its a single broken firmware.
The alternative is that you cripple just about every user of various
other standards com
> Regressions are worse. It doesn't matter AT ALL if you think that it
> breaks ten times more devices, if it's a regression and those devices
> didn't work in the past, they simply DO NOT COUNT.
Must be time for an -ac tree again.
Alan
--
To unsubscribe from this list: send the line "unsubscri
Hi,
[ACPI _GTM suspend issue sorta fixed, read below]
On Sat, Dec 08, 2007 at 12:24:16PM -0600, Robert Hancock wrote:
> Matthew Garrett wrote:
>> On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote:
>>> On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote:
ACPI
Hi,
On Mon, Dec 10, 2007 at 12:46:57AM +0900, Tejun Heo wrote:
> Please post full kernel boot log and the result of 'lspci -nn'.
Done, on #9530.
Will try some of the promising patches/suggestions now, hopefully this will
show me what's up. Will add further results there.
Andreas Mohr
--
To unsu
On Sun, 9 Dec 2007, Alan Cox wrote:
>
> Great, make everyone else wait another three months for a working CD
> drive. The one off regression appears far less harmful than a revert.
Btw, Alan, that "math" is total and utter BULLSH*T, and you should know
that.
"The one off regression" is likely
On Sun, 9 Dec 2007, Alan Cox wrote:
>
> > If we fail to find out the solution in time, we always have the
> > alternative of backing out the ATAPI transfer chunk size update. This
>
> Which will break far more controllers and drives than it fixes, so
> backing it out is nonsensical and not in t
Andreas Mohr wrote:
> Hi,
>
> On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote:
>>> Does this report now win me the lucky draw, pretty please? ;)
>> nah, you have to cc the acpi guys to get a prize ;)
>
> Thought so shortly, but missed it.
>
>> Andreas, please do separately report t
Alan Cox wrote:
>> Newly broken ones will be regressions. How many do we fix by the
>> change? On SATA, setting the correct transfer chunk size doesn't seem
>> to fix many.
>
> Regressions are not some kind of grand evil. Better to regress the odd
> device than continue to break entire controlle
> Newly broken ones will be regressions. How many do we fix by the
> change? On SATA, setting the correct transfer chunk size doesn't seem
> to fix many.
Regressions are not some kind of grand evil. Better to regress the odd
device than continue to break entire controllers.
> > Tejun - instead
Rafael J. Wysocki wrote:
>>> If any machines _are_ breaking then this could cause real problems
>>> and I'd prefer that we either go for a whitelist or arrange to
>>> detect the condition and fall back to non-acpi ata.
>> The pending patchset should make ATA ACPI quite resistant to failures.
>
> A
Hello, Alan.
Alan Cox wrote:
>> will break some other cases which were fixed by the change but those
>> won't be regressions at least and we can add transfer chunk size
>> update with other changes to 2.6.25.
>
> Great, make everyone else wait another three months for a working CD
> drive. The on
On Sunday, 9 of December 2007, Andrew Morton wrote:
> On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > This message contains a list of some regressions from 2.6.23 which have been
> > reported since 2.6.24-rc1 was released and for which there are no fixes i
On Sunday, 9 of December 2007, Tejun Heo wrote:
> Hello,
>
> Andrew Morton wrote:
> >> Subject: PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is
> >> beyond end of object
> >> Submitter : Hans de Bruin <[EMAIL PROTECTED]>
> >> References : http://bugzilla.kernel.org/show_bug.cgi?
> If we fail to find out the solution in time, we always have the
> alternative of backing out the ATAPI transfer chunk size update. This
Which will break far more controllers and drives than it fixes, so
backing it out is nonsensical and not in the general good.
> will break some other cases wh
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> Am trying to do a git-disect on it but it seems that someone has been
> screwing with ata Kconfig and I'm hitting a pile of
> cant-find-root-disk bisection points and I can't immediately work out
> why. I'll try to find time to look at it again nex
On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> This message contains a list of some regressions from 2.6.23 which have been
> reported since 2.6.24-rc1 was released and for which there are no fixes in the
> mainline that I know of.
Here's one for you - I have a
Hello, (cc'ing Alan)
Andrew Morton wrote:
>> Subject : cd/dvd inaccessible in 2.6.24-rc2
>> Submitter: Will Trives <[EMAIL PROTECTED]>
>> References : http://lkml.org/lkml/2007/11/9/290
>>http://bugzilla.kernel.org/show_bug.cgi?id=9346
>> Handled-By : Len Brown
Hello,
Andrew Morton wrote:
>> Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is
>> beyond end of object
>> Submitter: Hans de Bruin <[EMAIL PROTECTED]>
>> References : http://bugzilla.kernel.org/show_bug.cgi?id=9320
>> Handled-By : Robert Moore <[EMAIL PROTECTED
Robert Hancock wrote:
> Matthew Garrett wrote:
>> On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote:
>>> On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote:
ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index
(0) is beyond end of object [2
On Sat, Dec 08, 2007 at 11:30:53PM +0100, Rafael J. Wysocki wrote:
> On Saturday, 8 of December 2007, Theodore Tso wrote:
> > However, as far as I am concerned, Ingo's patch, first posted to LKML
> > here: http://lkml.org/lkml/2007/11/16/66 should be listed as fixing
> > the above regression. Rafa
On Saturday, 8 of December 2007, Richard Purdie wrote:
> On Sat, 2007-12-08 at 03:40 +0100, Rafael J. Wysocki wrote:
> > Subject : leds: ledtrig-timer calls sleeping function from
> > invalid context
> > Submitter : Márton Németh <[EMAIL PROTECTED]>
> > References : http://bugzilla.
On Saturday, 8 of December 2007, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 01:42:41AM -0800, Andrew Morton wrote:
> > > Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always
> > > work on Lenovo X60s
> > > Submitter : Roland Dreier <[EMAIL PROTECTED]>
> > > References
On Saturday, 8 of December 2007, Andrew Morton wrote:
> On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > This message contains a list of some regressions from 2.6.23 which have been
> > reported since 2.6.24-rc1 was released and for which there are no fixes
On Saturday, 8 of December 2007, Andrew Morton wrote:
> On Sat, 8 Dec 2007 09:28:15 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Fabio Comolli <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > > Subject : Battery shows up twice in kpowersave
> > > > Submitter : Rolf Ei
* Theodore Tso <[EMAIL PROTECTED]> wrote:
> I am very happily running with Ingo's "snd hda suspend latency:
> shorten codec read" patch, which was originally intended to speed up
> resuming from hibernation, but which as I discovered, also has the
> nice side effect of eliminating the reported
On Sat, Dec 08, 2007 at 01:42:41AM -0800, Andrew Morton wrote:
> > Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always
> > work on Lenovo X60s
> > Submitter : Roland Dreier <[EMAIL PROTECTED]>
> > References : http://lkml.org/lkml/2007/11/8/255
> > http://b
> > Subject: snd_hda_intel 2.6.24-rc2 bug: interrupts don't always
> > work on Lenovo X60s
> > Submitter : Roland Dreier <[EMAIL PROTECTED]>
> > References : http://lkml.org/lkml/2007/11/8/255
> > http://bugzilla.kernel.org/show_bug.cgi?id=9332
> > Handled-By :
>
Matthew Garrett wrote:
On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote:
On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote:
ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0) is
beyond end of object [20070126]
ACPI Error (psparse-0537):
On Sat, 8 Dec 2007, Andrew Morton wrote:
> On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > This message contains a list of some regressions from 2.6.23 which have been
> > reported since 2.6.24-rc1 was released and for which there are no fixes in
> > the
Hi,
On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote:
> > Does this report now win me the lucky draw, pretty please? ;)
>
> nah, you have to cc the acpi guys to get a prize ;)
Thought so shortly, but missed it.
> Andreas, please do separately report that WOL problem too..
Local se
On Sat, 2007-12-08 at 03:40 +0100, Rafael J. Wysocki wrote:
> Subject : leds: ledtrig-timer calls sleeping function from
> invalid context
> Submitter : Márton Németh <[EMAIL PROTECTED]>
> References: http://bugzilla.kernel.org/show_bug.cgi?id=9264
> Handled-By: Richard P
On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote:
> On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote:
> > ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0) is
> > beyond end of object [20070126]
> > ACPI Error (psparse-0537): Method parse/
On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sat, Dec 08, 2007 at 01:36:31AM -0800, Andrew Morton wrote:
> > > Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is
> > > beyond end of object
> > > Submitter : Hans de Bruin <[EMAIL PRO
Hi,
On Sat, Dec 08, 2007 at 01:36:31AM -0800, Andrew Morton wrote:
> > Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is
> > beyond end of object
> > Submitter : Hans de Bruin <[EMAIL PROTECTED]>
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=9320
> > Hand
On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> This message contains a list of some regressions from 2.6.23 which have been
> reported since 2.6.24-rc1 was released and for which there are no fixes in the
> mainline that I know of. If any of them have been fixe
On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> This message contains a list of some regressions from 2.6.23 which have been
> reported since 2.6.24-rc1 was released and for which there are no fixes in the
> mainline that I know of. If any of them have been fixe
On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> This message contains a list of some regressions from 2.6.23 which have been
> reported since 2.6.24-rc1 was released and for which there are no fixes in the
> mainline that I know of. If any of them have been fixe
On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> This message contains a list of some regressions from 2.6.23 which have been
> reported since 2.6.24-rc1 was released and for which there are no fixes in the
> mainline that I know of. If any of them have been fixe
On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> This message contains a list of some regressions from 2.6.23 which have been
> reported since 2.6.24-rc1 was released and for which there are no fixes in the
> mainline that I know of. If any of them have been fixe
On Sat, 8 Dec 2007 09:28:15 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Fabio Comolli <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > > Subject : Battery shows up twice in kpowersave
> > > Submitter : Rolf Eike Beer <[EMAIL PROTECTED]>
> > > References : http://bugzilla.kern
* Fabio Comolli <[EMAIL PROTECTED]> wrote:
>
>
> > Subject : Battery shows up twice in kpowersave
> > Submitter : Rolf Eike Beer <[EMAIL PROTECTED]>
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=9494
> > Handled-By : Alexey Starikovskiy <[EMAIL PROTECTED]>
Hi.
On Dec 8, 2007 3:40 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> This message contains a list of some regressions from 2.6.23 which have been
> reported since 2.6.24-rc1 was released and for which there are no fixes in the
> mainline that I know of. If any of them have been fixed already
73 matches
Mail list logo
