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
On Fri, 14 Dec 2007, Ingo Molnar wrote:
> which is of little help if it regresses on other workloads. As we've
> seen it, SLUB can be more than 10 times slower on hackbench. You can
> tune SLUB to use 2MB pages but of course that's not a production level
> system. OTOH, have you tried to tune S
* Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > I think we should we make SLAB the default for v2.6.24 ...
>
> If you guarantee that all the regression of SLAB vs. SLUB are
> addressed then thats fine but AFAICT that is not possible.
huh? You got the ordering wrong ;-) SLUB needs to resolve
Christoph Lameter a écrit :
On Sat, 8 Dec 2007, Ingo Molnar wrote:
Good. Although we should perhaps look at that reported performance
problem with SLUB. It looks like SLUB will do a memclear() for the
area twice (first for the whole page, then for the thing it allocated)
for the slow case. Ma
On Sat, 8 Dec 2007, Ingo Molnar wrote:
>
> > Good. Although we should perhaps look at that reported performance
> > problem with SLUB. It looks like SLUB will do a memclear() for the
> > area twice (first for the whole page, then for the thing it allocated)
> > for the slow case. Maybe that ex
On Sun, 9 Dec 2007, Ingo Molnar wrote:
> unless i'm missing something obvious (and i easily might), i see SLUB as
> SLAB reimplemented with a different queueing model. Not "without
> queueing".
The "queue" that you are talking about is the freelist of a slab. It exist
for each slab. SLAB uses
On Sat, 8 Dec 2007, Linus Torvalds wrote:
> On that note, shouldn't we also do this for slub.c? Christoph?
SLUB does not pass __GFP_ZERO to the page allocator.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
[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
On Tue, 2007-12-11 at 09:52 +0100, Ingo Molnar wrote:
> * Dave Jones <[EMAIL PROTECTED]> wrote:
> > Which leaves my only other gripe. It broke slabtop.
>
> that's actually a _bad_ ABI regression. Rafael, could you please add
> this to the regressions list?
>
> > There's an alternative impleme
* 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
* Dave Jones <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 08, 2007 at 08:52:11PM +0100, Ingo Molnar wrote:
>
> > so even today's upstream kernel, which has 'ancient' SLUB code, SLAB and
> > SLUB have essentially the same linecount:
> >
> > $ wc -l mm/slab.c mm/slub.c
> > 4478 mm/slab.c
>
* 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 Sat, Dec 08, 2007 at 08:52:11PM +0100, Ingo Molnar wrote:
> so even today's upstream kernel, which has 'ancient' SLUB code, SLAB and
> SLUB have essentially the same linecount:
>
> $ wc -l mm/slab.c mm/slub.c
> 4478 mm/slab.c
> 4125 mm/slub.c
>
> (and while linecount != complex
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
On Sun, 9 Dec 2007 10:20:19 +0200
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
\
> Now, while SLAB code is "pleasant and straightforward code" (thanks,
> btw) for UMA, it's really hairy for NUMA plus the "alien caches" eat
> tons of memory
.. and they make slab slower on numa systems for database wo
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?
On Sunday, 9 of December 2007, Ingo Molnar wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > It's a kmap_atomic() debugging patch which I wrote ages ago and whcih
> > Ingo sucked into his tree. I don't _think_ this warning is present in
> > your tree at all.
> >
> > http://lkml.org/
> 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
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > The problem is that for each cache, you have an "per-node alien
> > queues" for each node (see struct kmem_cache nodelists -> struct
> > kmem_list3 alien). Moving slab metadata to struct page solves this
> > but now you can only have one "queue" tha
* 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
* Pekka Enberg <[EMAIL PROTECTED]> wrote:
> I mostly live in the legacy 32-bit UMA/UP land still so I cannot
> verify this myself but the kind folks at SGI claim the following
> (again from the announcement):
>
> "On our systems with 1k nodes / processors we have several gigabytes
> just tied
Hi Ingo,
On Dec 9, 2007 10:50 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> yes, i understand the initial announcement (and the Kconfig entry still
> says the same), but that is not matched up by the reality i see in the
> actual code - SLUB clearly uses a queue/list of objects (as cited in my
> pr
* Pekka Enberg <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> On Dec 8, 2007 10:29 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > so it has a "free list", which is clearly per cpu. Hang on! Isnt that
> > actually a per CPU queue? Which SLUB has not, we are told? The "U" in
> > SLUB. How on earth can
Hi Linus,
On Dec 8, 2007 7:54 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> diff --git a/mm/slob.c b/mm/slob.c
> index ee2ef8a..773a7aa 100644
> --- a/mm/slob.c
> +++ b/mm/slob.c
> @@ -330,7 +330,7 @@ static void *slob_alloc(size_t size, gfp_t gfp, int
> align, int node)
>
> /* Not enou
Hi Ingo,
On Dec 8, 2007 10:29 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> so it has a "free list", which is clearly per cpu. Hang on! Isnt that
> actually a per CPU queue? Which SLUB has not, we are told? The "U" in
> SLUB. How on earth can an allocator in 2007 claim to have no queuing
> (which i
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> It's a kmap_atomic() debugging patch which I wrote ages ago and whcih
> Ingo sucked into his tree. I don't _think_ this warning is present in
> your tree at all.
>
> http://lkml.org/lkml/2007/11/29/157 is where it starts.
>
> I had a lenghty back-
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
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the SLUB concept is proudly outlined in init/Kconfig:
>
> config SLUB
> bool "SLUB (Unqueued Allocator)"
> help
>SLUB is a slab allocator that minimizes cache line usage
>instead of managing queues of cached obj
* 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
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > But I don't think we need to do anything for 2.6.24..
>
> Good. Although we should perhaps look at that reported performance
> problem with SLUB. It looks like SLUB will do a memclear() for the
> area twice (first for the whole page, then for the
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
On Sat, Dec 08, 2007 at 09:54:06AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 8 Dec 2007, Linus Torvalds wrote:
> >
> > But I'll apply it anyway, because it looks "obviously correct" from the
> > standpoint that the _other_??slob user already clears the end result
> > explicitly later on, and
> > 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 :
>
On Sat, 8 Dec 2007, Andrew Morton wrote:
>
> > So which warning is it that triggers the bogus error?
>
> It's a kmap_atomic() debugging patch which I wrote ages ago and whcih Ingo
> sucked into his tree. I don't _think_ this warning is present in your tree
> at all.
Ok, that explains it.
> Kn
On Sat, Dec 08, 2007 at 09:54:06AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 8 Dec 2007, Linus Torvalds wrote:
> >
> > But I'll apply it anyway, because it looks "obviously correct" from the
> > standpoint that the _other_??slob user already clears the end result
> > explicitly later on, and
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 09:54:06 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> On Sat, 8 Dec 2007, Linus Torvalds wrote:
> >
> > But I'll apply it anyway, because it looks "obviously correct" from the
> > standpoint that the _other___slob user already clears the end result
> > explicitly
On Sat, 8 Dec 2007, Linus Torvalds wrote:
>
> But I'll apply it anyway, because it looks "obviously correct" from the
> standpoint that the _other_Â slob user already clears the end result
> explicitly later on, and we simply should never pass down __GFP_ZERO to
> the actual page allocator.
On Sat, 8 Dec 2007, Matt Mackall wrote:
>
> Avoid calling page allocator with __GFP_ZERO, as we might be in atomic
> context and this will make thing unhappy on highmem systems. Instead,
> manually zero allocations from the page allocator.
I think this is fine, but didn't we fix the warning alr
On Sat, Dec 08, 2007 at 10:30:39AM +0100, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Subject : tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52
> > kmap_atomic_prot()
> > Submitter : Ingo Molnar <[EMAIL PROTECTED]>
> > References : http://lkml.
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
On Sat, 8 Dec 2007 10:30:39 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Subject : tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52
> > kmap_atomic_prot()
> > Submitter : Ingo Molnar <[EMAIL PROTECTED]>
> > References :
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
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Subject : tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52
> kmap_atomic_prot()
> Submitter : Ingo Molnar <[EMAIL PROTECTED]>
> References: http://lkml.org/lkml/2007/11/29/157
> http://bugzilla.kernel.org/
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
1 - 100 of 103 matches
Mail list logo
