On Wed, Feb 20 2008, Mike Miller wrote:
> Patch 1 of 1
>
> This patch hopefully fixes all the brokeness in my last submission. It
> compiles cleanly with tape support on or off. I added a couple of #ifdef's
> and removed the broken macro definition. The #ifdef's made it unneccesary.
> It also
On Wed, 20 Feb 2008, Diego Calleja wrote:
> I get the following new message in my dmesg:
>
> [0.155476] ACPI: bus type pci registered
> [0.155567] PCI: Found Intel Corporation 945G/GZ/P/PL Express Memory
> Controller Hub with MMCONFIG support.
> [0.161149] PCI: Cannot map mmconfig
Ingo Molnar wrote:
> * Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>> I disagree. The cost is only adding a field to cfs_rq [...]
>
> wrong. The cost is "only" of adding a field to cfs_rq and _updating it_,
> in the hottest paths of the scheduler:
>
> @@ -256,6 +257,7 @@ static void
On Thu, Feb 21, 2008 at 02:21:52AM +0100, Rafael J. Wysocki wrote:
> On Thursday, 21 of February 2008, Frans Pop wrote:
> > Rafael J. Wysocki wrote:
> > > On Wednesday, 20 of February 2008, Jarek Poplawski wrote:
> > >> So, has it to be so hard? It seems not - at least in good old times...
> > >
Introduced between 2.6.25-rc1 and -rc2.
drivers/acpi/executer/exregion.c:369:8: warning: incorrect type in argument 3
(different type sizes)
drivers/acpi/executer/exregion.c:369:8:expected unsigned int [usertype]
*value
drivers/acpi/executer/exregion.c:369:8:got unsigned long long
On Wed, Feb 20, 2008 at 4:11 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Wed, 20 Feb 2008, Thomas Gleixner wrote:
> > On Tue, 19 Feb 2008, Marcel Holtmann wrote:
>
> > > I don't really have any idea. Nothing has been changed in this area for a
> > > couple of years. The command TX
char can be unsigned
kernel/marker.c:64:20: error: dubious one-bit signed bitfield
kernel/marker.c:65:14: error: dubious one-bit signed bitfield
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Introduced between -rc1 and -rc2
kernel/marker.c |4 ++--
1 files changed, 2 insertions(+),
* Tejun Heo <[EMAIL PROTECTED]> wrote:
> Tejun Heo wrote:
> > Ingo Molnar wrote:
> >> On a second attempt to boot the same bzImage, another ATA related
> >> weirdness showed up:
> >>
> >> [8.226144] Calling initcall 0xc09f3d8e: isapnp_init+0x0/0xf()
> >> [8.232017] Bad IO access at port
On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
> Hi Andrew,
>
> The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
> to build on x86_64 machine
>
> CC drivers/acpi/osl.o
> drivers/acpi/osl.c:60:38: error: empty filename in #include
> drivers/acpi/osl.c: In function
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> I disagree. The cost is only adding a field to cfs_rq [...]
wrong. The cost is "only" of adding a field to cfs_rq and _updating it_,
in the hottest paths of the scheduler:
@@ -256,6 +257,7 @@ static void __enqueue_entity(struct cfs_
On Fedora9 Alpha with kernel-2.6.25-rc2,
I run " watch -n 0.1 "cat /proc/acpi/processor/CPU*/power | grep 'active
state'" ", I find that the CPU C state information "active state" remain
at "C0" and it do not change any time. The same issue also exit on
2.6.24-rc2 kernel.
But with RHEL5.1
On Wed, 2008-02-20 at 22:32 -0800, David Miller wrote:
> > + if (lost) {
> > + printk(KERN_WARNING
> > + "printk: %d %s%smessage%s suppressed.\n",
> > + lost,
> > + (state->facility == 0 ? "" :
>
KAMEZAWA Hiroyuki wrote:
> On Wed, 20 Feb 2008 21:45:13 +0530
> Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>>> But for computers, limits is an expected and understood term, and for
>>> filesystems it's quotas. So in this case, I *still* think you should
>>> be using the term "Memory Quota
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Tue, 19 Feb 2008 19:57:58 +0900
> On Sun, 17 Feb 2008 23:41:42 -0800 (PST)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: FUJITA Tomonori <[EMAIL PROTECTED]>
> > Date: Sat, 16 Feb 2008 15:03:43 +0900
> >
> > > [PATCH] sparc64: make IOMMU
Ingo Molnar wrote:
> * Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>> __pick_last_entity() walks the entire tree on O(lgn) time to find the
>> rightmost entry. This patch makes the routine more efficient by
>> reducing the cost of the lookup
>
> hm, i'm not sure we want to do this: we'd be
> From: "Divy Le Ray" <[EMAIL PROTECTED]>
> Date: Wed, 20 Feb 2008 21:57:08 -0800
>
> > The driver is cxgb3 here, it uses LLTX.
>
> That's extremely unfortunate, hopefully you can update it to
> use a model like tg3 and others use. LLTX is a lost cause
> for hardware device drivers, and in fact
On Wed, 20 Feb 2008 21:45:13 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> > But for computers, limits is an expected and understood term, and for
> > filesystems it's quotas. So in this case, I *still* think you should
> > be using the term "Memory Quota Controller" instead. It just makes it
On Thu, Feb 21, 2008 at 05:05:32PM +1100, Nigel Cunningham wrote:
> Hi Greg.
>
> Greg KH wrote:
>> On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
>>> Hi.
>>>
>>> Greg KH wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
> Hi.
>
> Matthew
From: "Hawkes Steve-FSH016" <[EMAIL PROTECTED]>
Date: Tue, 19 Feb 2008 15:30:51 -0600
[ netdev CC:'d ]
> The printk_ratelimit() and net_ratelimit() functions are coupled and
> interfere with each other. Each has their own tunable parameters to
> control their respective rate limiting feature,
* Jason Wessel <[EMAIL PROTECTED]> wrote:
> Here are 3 more patches against the kgdb-light. Porting kgdb-light to
> another arch has found 2 regressions, which are fixed in the first
> patch.
>
> The second patch adds hooks for an additional kgdboc uart driver which
> was required to
On 20-02-08 21:13, David P. Reed wrote:
Actually, disparaging things as "one idiotic system" doesn't seem like a
long-term thoughtful process - it's not even accurate.
Whatever we think about systems using port 0x80, fact of the matter is that
they do and outside of legacy stuff that isn't
From: "Divy Le Ray" <[EMAIL PROTECTED]>
Date: Wed, 20 Feb 2008 21:57:08 -0800
> The driver is cxgb3 here, it uses LLTX.
That's extremely unfortunate, hopefully you can update it to
use a model like tg3 and others use. LLTX is a lost cause
for hardware device drivers, and in fact we'd like to
mmconfig is only used to access ext conf space.
so don't need to reject MFG that only have one entry and only handle bus0
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/pci/mmconfig-shared.c
===
---
oops, sorry... for some reason I though you were the guy :)
I'll resend
jirka
Greg KH wrote:
> On Wed, Feb 20, 2008 at 09:57:23PM +0100, Jiri Olsa wrote:
>> Hi,
>>
>> seems struct char_device_struct::fops is no longer used, removing it.
>> I checked with "make allyesconfig" and got proper
Hi Greg.
Greg KH wrote:
On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
Hi.
Greg KH wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> __pick_last_entity() walks the entire tree on O(lgn) time to find the
> rightmost entry. This patch makes the routine more efficient by
> reducing the cost of the lookup
hm, i'm not sure we want to do this: we'd be slowing down the fastpath
of all
Hi Divy,
But the race doesn't exist even for LLTX drivers these days. There is no
way two cpu's can execute the xmit handler at the same time.
Thanks,
- KK
> > > > The first part of the patch removes the !netif_queue_stopped(dev).
> > > > It opens the race discussed a while ago between Stephen
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 20, 2008 9:47 PM
> To: [EMAIL PROTECTED]
> Cc: Divy Le Ray; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: Re: [git patches] net driver updates
>
> From:
Nick Piggin wrote:
>> 1. We could create something similar to mem_map, we would need to handle 4
>
>> different ways of creating mem_map.
>
>> 2. On x86 with 64 GB ram, if we decided to use vmalloc space, we would need
>
>> 64 MB of vmalloc'ed memory
>
> That's going to be a big job. You could
From: Krishna Kumar2 <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 09:13:49 +0530
> Hi Divy,
>
> > > Explain why, so I can include it in the changelog please...
> >
> > Hi Jeff,
> >
> > The first part of the patch removes the !netif_queue_stopped(dev).
> > It opens the race discussed a while ago
On 20-02-08 17:59, Bjorn Helgaas wrote:
I agree with you that we can just delete the dev->protocol tests
completely. So I'd rather see something like this (built but untested):
PNP: remove dev->protocol NULL checks
Every PNP device should have a valid protocol pointer. If it doesn't,
__pick_last_entity() walks the entire tree on O(lgn) time to find the
rightmost entry. This patch makes the routine more efficient by
reducing the cost of the lookup
Description
---
Cache the rightmost entry in the rb_tree in the same way that we cache
the leftmost entry.
Nick Piggin wrote:
> On Wednesday 20 February 2008 23:52, Balbir Singh wrote:
>> Andi Kleen wrote:
>>> Document huge memory/cache overhead of memory controller in Kconfig
>>>
>>> I was a little surprised that 2.6.25-rc* increased struct page for the
>>> memory controller. At least on many x86-64
On Wed, Feb 20, 2008 at 01:03:24PM +0100, Andrea Arcangeli wrote:
> If there's agreement that the VM should alter its locking from
> spinlock to mutex for its own good, then Christoph's
> one-config-option-fits-all becomes a lot more appealing (replacing RCU
> with a mutex in the mmu notifier list
Anton Vorontsov writes:
> > I was wondering if it would be sufficient to provide alternative
> > versions of fb_readl, fb_writel etc. that do byte-swapping.
>
> This is of course viable alternative. And I was considering this, but
> later I abandoned the idea: that way we'll end up doing math in
On Wed, Feb 20, 2008 at 11:39:42AM +0100, Andrea Arcangeli wrote:
> Given Nick's comments I ported my version of the mmu notifiers to
> latest mainline. There are no known bugs AFIK and it's obviously safe
> (nothing is allowed to schedule inside rcu_read_lock taken by
> mmu_notifier() with my
On Wed, Feb 20, 2008 at 02:09:41AM +0100, Andrea Arcangeli wrote:
> On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
> > Sorry, I realise I still didn't get this through my head yet (and also
> > have not seen your patch recently). So I don't know exactly what you
> > are doing...
>
>
On Tue, Feb 19, 2008 at 05:40:50PM -0600, Jack Steiner wrote:
> On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
> > On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
> > > On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
> > > > anything when changing the
On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
> Hi.
>
> Greg KH wrote:
>> On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
>>> Hi.
>>>
>>> Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
> - people keep talking
On Wednesday 20 February 2008 20:00, Robin Holt wrote:
> On Wed, Feb 20, 2008 at 02:51:45PM +1100, Nick Piggin wrote:
> > On Wednesday 20 February 2008 14:12, Robin Holt wrote:
> > > For XPMEM, we do not currently allow file backed
> > > mapping pages from being exported so we should never reach
On Thu, 21 Feb 2008 13:15:58 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Kumar Gala writes:
>
> > np. Are we trying to get this into 2.6.25 or .26?
>
> I was going to put it into my powerpc-next branch and put it in
> 2.6.26. I don't see any need for it to go in 2.6.25.
Is that a new
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> include/asm-x86/desc_64.h should have been removed, but is still in
> the tree containing just a newline.
fix is already in x86.git. Nothing references the file so there's no
harm done to any puppies :-)
Ingo
--
To unsubscribe from this
Alan Cox writes:
> For some weird reason I can't ascertain (translation "I think its
> broken") the viocons driver calls directly into the n_tty ldisc code even
> if another ldisc is in use. It'll probably break if you do that but I'm
> just fixing the locking and adding a comment that its
Kumar Gala writes:
> np. Are we trying to get this into 2.6.25 or .26?
I was going to put it into my powerpc-next branch and put it in
2.6.26. I don't see any need for it to go in 2.6.25.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
David Miller writes:
> I'm ambivalent but I would obviously prefer 2.6.25 because
> it would allow me to proceed more easily with my sparc64
> NUMA work as well as get your bug fixes in more smoothly.
Sounds like we should get Stephen to put it in linux-next-stable once
we're convinced it's all
* Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote:
> Fix lot of errors and warnings.
> Compile tested.
thanks Paolo, i've applied all 3 patches.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Hi Divy,
> > Explain why, so I can include it in the changelog please...
>
> Hi Jeff,
>
> The first part of the patch removes the !netif_queue_stopped(dev).
> It opens the race discussed a while ago between Stephen hemminger and
> David Miller:
> http://marc.info/?l=linux-netdev=113383224512427=2
On Tuesday February 19, [EMAIL PROTECTED] wrote:
> On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
> > First, I still don't understand why in God's sake barriers are "working"
> > while regular cache flushes are not. Almost no consumer-grade hard drive
> > supports write
include/asm-x86/desc_64.h should have been removed, but is still in the
tree containing just a newline.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> so far, no one complained that.
thanks Yinghai, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Monday February 18, [EMAIL PROTECTED] wrote:
>
>
> I'll put it even more strongly. My experience is that disabling write
> cache plus disabling barriers is often much faster than enabling both
> barriers and write cache enabled, when doing metadata intensive
> operations, as long as you have
* Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
> From: Hiroshi Shimamoto <[EMAIL PROTECTED]>
>
> Now cpu/proc.c and cpu/proc_64.c are same.
> So cpu/proc_64.c can be removed.
thanks Hiroshi, very nicely done! I've applied all 5 patches.
Ingo
--
To unsubscribe from this list: send the
Hi David,
On Wednesday 20 February 2008 08:05, David Howells wrote:
> These patches add local caching for network filesystems such as NFS.
Have you got before/after benchmark results?
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Malte Schröder wrote:
>> Does irqpoll kernel parameter help?
>
> No, problem stays.
Can you capture full boot log w/ irqpoll specified? If you have root
filesystem connected to ahci, you'll probably have to use serial or
netconsole. Also, please post full boot log from 2.6.23.11.
Thanks.
--
These are the updated pastbin links to my BT8x8 issue. Hopefully these
are helpful, if you need more information, let me know.
dmesg -> http://rafb.net/p/HfS8nS31.html
xorg.conf -> http://rafb.net/p/twDeb451.html
Xorg.0.log -> http://rafb.net/p/hBdXqc31.html
.config ->
so far, no one complained that.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index fafeb95..f4a5a2b 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -574,14 +574,6 @@ void __init mem_init(void)
/* clear_bss()
Tejun Heo wrote:
> Ingo Molnar wrote:
>> On a second attempt to boot the same bzImage, another ATA related
>> weirdness showed up:
>>
>> [8.226144] Calling initcall 0xc09f3d8e: isapnp_init+0x0/0xf()
>> [8.232017] Bad IO access at port 0x0 (outb(val,port))
>> [8.232799] [
Hi,
We recently got some of the "Desktop Form Factor" Optiplex 745's in. I
noticed that there's an entry for the SFF one's, but the BIOS model
number of the DFF differs from that of the SFF. We have been reliably
experiencing the same (as far as I can tell) reboot bug as the SFF boxes.
Please
Hi Jeff.
>
>I agree with the patch (and I see Andrew already accepted it). Do you
>have a reproducer for this problem?
Do you want to know the way of failing invalidate_complete_page2() ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Paul Menage wrote:
> I think that docbook-style function comments need /** at the start of
> the comment block.
>
Yes, I didn't notice it. I revised the patch to fix it.
---
fix:
- comments about need_forkexit_callback
- comments about release agent
- typo and comment style, etc.
The atmel_spi driver does not initialize clock polarity correctly
(except for at91rm9200 CS0 channel) in some case.
The atmel_spi driver uses gpio-controlled chipselect. OTOH spi clock
signal is controlled by CSRn.CPOL bit, but this register controls
clock signal correctly only in 'real
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]>
> wrote:
> > > Ok, can you give this patch a try with the 'platform' method? It should
> >
On Wed, 20 Feb 2008 18:55:01 +0100, Marc Pignat <[EMAIL PROTECTED]> wrote:
> > A spi transfer with zero length is not invalid. Such transfer can be
> > used to achieve delay before first CLK edge after chipselect assertion.
> How long will be that delay?
My funny custom device requires 100us or
On Thu, Feb 21, 2008 at 9:21 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > I hope those are just warning that can just be ignored.
>
> Oops again, should be dev->pdev. Silly DRM layer obfuscation.
I was just about to write that the test didn't work. Both std str
hangs even before attempting
On Wednesday 20 February 2008, Haavard Skinnemoen wrote:
> >
> > Unfortunately it did not work. The clock state did not change by
> > writing MR register.
>
> Ok, thanks for testing.
>
> In that case, I think the best fix is to let NPCS0 stay selected
> permanently in MR and overwrite CSR0
On Wednesday 20 February 2008, Atsushi Nemoto wrote:
> > David, do you want me to pass on the patch with my signoff or just ask
> > Andrew to add my Acked-by to the patch already in mm?
>
> The patch in mm also lacks my Signed-off line. I had thought Andrew
> never take a patch without
need to apply after
x86_64: check MSR to get MMCONFIG for AMD Family 10h Opteron v3
some BIOS only let AMD fam 10h handle bus0, and nvidia mcp55/ck804
to handle other buses. at that case MCFG will cover all over them.
this patch will skip it so to use MCFG later.
Signed-off-by: Yinghai
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Matthew Garrett wrote:
No, with a freezer-based model you can basically *never* suspend to
anything related to FUSE or a userspace USB device or anything involving
userspace iSCSI initiators or
On Thursday, 21 of February 2008, Frans Pop wrote:
> Rafael J. Wysocki wrote:
> > On Wednesday, 20 of February 2008, Jarek Poplawski wrote:
> >> So, has it to be so hard? It seems not - at least in good old times...
> >
> > Something in APM uses some code from drivers/base/power/main.c that
> >
On Wednesday, February 20, 2008 5:19 pm Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > Oops, maybe this should just be pci_choose_state instead.
> > And this change should just be reverted (leave it as PCI_D0).
>
> drivers/char/drm/i915_drv.c: In
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Oops, maybe this should just be pci_choose_state instead.
> And this change should just be reverted (leave it as PCI_D0).
drivers/char/drm/i915_drv.c: In function 'i915_suspend':
drivers/char/drm/i915_drv.c:372: warning:
Hi.
Greg KH wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking about hibernating to an ext3 fs mounted on fuse as
a limitation of the freezer. To do that
Jeff Garzik wrote:
Divy Le Ray wrote:
Jeff Garzik wrote:
Mostly fixes, a few cleanups (generally assisting fixes), and an
exception for PS3 wireless because it had been posted, reviewed and
acked for a while, just not committed.
Please pull from 'upstream-davem' branch of
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
> Matthew Garrett wrote:
> >No, with a freezer-based model you can basically *never* suspend to
> >anything related to FUSE or a userspace USB device or anything involving
> >userspace iSCSI initiators or whatever. Sure, there are
On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Wednesday, February 20, 2008 3:49 pm Rafael J. Wysocki wrote:
> > > And just to confirm that, I just tested the current DRM modules against a
> > > 2.6.23.15 kernel.
> >
> > In 2.6.23.x there's no second ->suspend() during hibernation, so
On Thursday, 21 of February 2008, Linus Torvalds wrote:
>
> On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> >
> > > Secondly, the one that people should use ("pci_choose_state()") doesn't
> > > actually do what you claim it does. It does all kinds of wrong things,
> > > and
> > > doesn't even
On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > Ok, can you give this patch a try with the 'platform' method? It should
> > at least tell us what ACPI would like the device to do at suspend time,
> > but it
On Wednesday 20 February 2008, Andre Tomt wrote:
> David Brownell wrote:
> > On Wednesday 20 February 2008, Andre Tomt wrote:
> >> It has not crashed yet with the patch though.
> >
> > It seems that one of the tweks in this patch made the watchdog
> > act better than before. So unless I hear
Hi Ingo,
Here is a delta patch against sched-devel.git tree.
These two patches in sched-devel.git tree fix the issues.
latencytop: fix kernel panic while reading latency proc file
latencytop: fix memory leak on latency proc file
However, this is more appropriate way to fix, I think.
---
From:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
> Hi.
>
> Matthew Garrett wrote:
>> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
>>> - people keep talking about hibernating to an ext3 fs mounted on fuse as
>>> a limitation of the freezer. To do that with
2008/2/17 Li Zefan <[EMAIL PROTECTED]>:
> Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
Acked-by: Paul Menage <[EMAIL PROTECTED]>
> ---
> kernel/cgroup.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 71cf961..879a056
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking about hibernating to an ext3 fs mounted on fuse as
a limitation of the freezer. To do that with kexec, you're still going
to have to bmap the ext3 fs and pass the block list (in
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Ok, can you give this patch a try with the 'platform' method? It should at
> least tell us what ACPI would like the device to do at suspend time, but it
> probably won't fix the hang.
I can't get it to compile.
On Wednesday, 20 of February 2008, Soeren Sonnenburg wrote:
> On Wed, 2008-02-20 at 00:50 +0100, Rafael J. Wysocki wrote:
> > On Tuesday, 19 of February 2008, Soeren Sonnenburg wrote:
> > > On Tue, 2008-02-19 at 22:06 +0100, Rafael J. Wysocki wrote:
> > > > On Tuesday, 19 of February 2008, Soeren
lockdep goes off on the iova copy_reserved_iova because it and a
function it calls grabs locks in the from, and the to of the copy
operation.
This patch gives the reserved_ioval_list locks special lockdep classes.
--mgross
Signed-off-by: <[EMAIL PROTECTED]>
Index:
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
>
> > Secondly, the one that people should use ("pci_choose_state()") doesn't
> > actually do what you claim it does. It does all kinds of wrong things, and
> > doesn't even take the target state into account at all. So look again.
>
> Well, if
David Brownell wrote:
On Wednesday 20 February 2008, Andre Tomt wrote:
It has not crashed yet with the patch though.
It seems that one of the tweks in this patch made the watchdog
act better than before. So unless I hear from you (before the
start of next week) that some other message
On Wednesday, 20 of February 2008, Jarek Poplawski wrote:
> Hi,
>
> I needed APM to have poweroff on old box. So, in 2.6.24.2 menuconfig:
>
> 1) Power management options -->
>No APM.
> 2) [*] Power Management support
>No APM. I can see ACPI...
> 3) I try searching with "/" + "APM"
>
On Wed, Feb 20, 2008 at 09:57:23PM +0100, Jiri Olsa wrote:
> Hi,
>
> seems struct char_device_struct::fops is no longer used, removing it.
> I checked with "make allyesconfig" and got proper compile.
>
> Signed-off-by: Jiri Olsa <[EMAIL PROTECTED]>
Hm, why send this to me?
Did I make the
On Wednesday, February 20, 2008 3:49 pm Rafael J. Wysocki wrote:
> > And just to confirm that, I just tested the current DRM modules against a
> > 2.6.23.15 kernel.
>
> In 2.6.23.x there's no second ->suspend() during hibernation, so no wonder.
In 2.6.23 it's just:
->suspend()
->resume()
The following patch is for batching up the flushing of the IOTLB for
the DMAR implementation found in the Intel VT-d hardware. It works by
building a list of to be flushed IOTLB entries and a bitmap list of
which DMAR engine they are from.
After either a high water mark (250 accessible via
On Wed, 20 Feb 2008 15:37:28 -0500
woodys <[EMAIL PROTECTED]> wrote:
> On ARM genrtc has been arbitrary disabled in Kconfig circa 2.6.19 and
> the change to rtc_cmos it is not 100% transparent (ARM Netwinder, Debian).
> If I want to use a current (Etch) hwclock binary - I need genrtc with
>
On Thursday, 21 of February 2008, Linus Torvalds wrote:
>
> On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> >
> > In fact we have acpi_pci_choose_state() that tells the driver which power
> > state to put the device into in ->suspend(). If that is used, the device
> > ends
> > up in the state
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
> - people keep talking about hibernating to an ext3 fs mounted on fuse as
> a limitation of the freezer. To do that with kexec, you're still going
> to have to bmap the ext3 fs and pass the block list (in which case we
> can
This is a note to let you know that I've just added the patch titled
Subject: firmware: move firmware_class from Documentation/ to samples/
to my gregkh-2.6 tree. Its filename is
firmware-move-firmware_class-from-documentation-to-samples.patch
This tree can be found at
Hi all...
since some time ago I have noticed that mplayer can't use the RTC for
time accounting. Perhaps it is deprecated and should be migrated to
hrtimers, that is what every reference I found said, but the fact is
that nowadays it uses it.
I thought I was because a misbuild of my kernel, but
On Wednesday, 20 of February 2008, Alan Stern wrote:
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
>
> > Well, below is an uncompiled and untested but illustrating the idea that
> > might allow people not to bother with device_pm_schedule_removal()
> > explicitly and can fix the issue at hand.
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
>
> In fact we have acpi_pci_choose_state() that tells the driver which power
> state to put the device into in ->suspend(). If that is used, the device ends
> up in the state expected by to BIOS for S4.
First off, nobody should *ever* use that
On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Wednesday, February 20, 2008 3:03 pm Jesse Barnes wrote:
> > On Wednesday, February 20, 2008 2:32 pm Jesse Barnes wrote:
> > > On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > > > On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL
Diego Calleja wrote:
I get the following new message in my dmesg:
[0.155476] ACPI: bus type pci registered
[0.155567] PCI: Found Intel Corporation 945G/GZ/P/PL Express Memory
Controller Hub with MMCONFIG support.
[0.161149] PCI: Cannot map mmconfig aperture for segment 0
[
1 - 100 of 1316 matches
Mail list logo
