On Thu, Dec 20, 2007 at 02:37:49PM -0500, Tony Camuso wrote:
> Matthew Wilcox wrote:
>
> >Bad deduction. What's happening is that the write to the BAR is causing
> >it to overlap the decode for mmconfig space. So the mmconfig write to
> >set the BAR back never gets through.
> >
> >I have a
On Dec 20, 2007 2:22 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
> ok, that's just bad and if there's no user-defineable limit to the deferral I
> definately don't like this change.
>
> Can I safely assume that any irq will cause all deferred timers to run?
I think even other causes for wakeup like
On Thu, Dec 20, 2007 at 12:08:33PM -0700, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
> > Does anybody see a down side to this?
>
> It'll be slower than it would be if we used mmconfig directly. Now yes,
> nobody should be using pci config space in
On Thu, 20 Dec 2007 10:36:48 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Josh Boyer wrote:
> > Several platforms require the mkimage tool to generate a uImage file
> > that is used with U-Boot. This brings the mkimage tool in-kernel to
> > enable building those platforms without having
On Thursday 20 December 2007 06:29:06 am Ingo Molnar wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > Ingo.
> >
> > commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another
> > patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86:
> > fixup cpu_info array
Hello,
> > > Actually, you may only need these two:
> > >
> > > > maps4-add-proc-kpagecount-interface.patch
> > > > maps4-add-proc-kpageflags-interface.patch
> >
> > Yes these two were enough, and exporting fs/proc/base.c's
> > mem_lseek().
> >
> > As hard as I try, I can't reproduce this at
Arjan van de Ven wrote:
>
My interpretation of the api is:
* round_jiffies() - timer wants to wakeup but isn't precise
about when so schedule
on next second when system will wake up anyway;
e.g why meetings are usually
Hi Arjan,
I've not been able to find this file, "drivers/bluetooth/hci_tty.c", but
anyway, This seems to be what happens: Hci_uart_close() flushes using
hci_uart_flush(). Subsequently, in hci_dev_do_close(), (one step in
hci_unregister_dev()), hci_uart_flush() is called again. The comment
Matthew Wilcox wrote:
Bad deduction. What's happening is that the write to the BAR is causing
it to overlap the decode for mmconfig space. So the mmconfig write to
set the BAR back never gets through.
I have a different idea to fix this problem. Instead of writing
0x, we could look
On Tue, 2007-12-18 at 19:04 -0800, Geoff Levand wrote:
> Unfortunately there wasn't enough context in the patch to see
> that there is a down() earlier in the routine, and that the patch
> does indeed remove an incorrectly placed down(). Here is the
> entire routine, marked with what the patch
Steve Wise wrote:
Roland Dreier wrote:
> It appears that my problem boils down to a single host page of memory
> that is mapped for dma, and the dma address returned by dma_map_sg()
> is _not_ 64KB aligned. Here is an example:
> My first question is: Is there an assumption or requirement
On Thursday 20 December 2007 11:16, H. Peter Anvin wrote:
> Arjan van de Ven wrote:
> > On Wed, 19 Dec 2007 11:48:14 -0800
> > "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> >
> >> I think C3 guarantees that the cache contents stay intact, and thus
> >> it might make sense in some technology to
On Thu, 20 Dec 2007, Jan Kara wrote:
>
> As I wrote in my previous email, this solution works but hides the
> fact that the page really *has* dirty data in it and *is* pinned in memory
> until the commit code gets to writing it. So in theory it could disturb
> the writeout logic by having more
My interpretation of the api is:
* round_jiffies() - timer wants to wakeup but isn't precise about when so
schedule
on next second when system will wake up anyway;
e.g why meetings are usually scheduled on the hour
* deferrable -
Parag Warudkar wrote:
> On Dec 20, 2007 12:05 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
>> I can't even apply this patch and the e1000 one... not only is it whitespace
>> damaged it is also not properly formatted as patch at all. If you want me to
>> take
>> these patches seriously, then please
Roland Dreier wrote:
> It appears that my problem boils down to a single host page of memory
> that is mapped for dma, and the dma address returned by dma_map_sg()
> is _not_ 64KB aligned. Here is an example:
> My first question is: Is there an assumption or requirement in linux
> that
On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
> Also, this solution also would allow us to remove the unreachable_devices()
> routine and bitmap.
Not really ... we probe reading address 0x100 to see if the device
supports extended config space or not. So we need to make that fail
Stephen Hemminger wrote:
> On Thu, 20 Dec 2007 17:29:23 +
>
>> -Original Message-
>> From: Stephen Hemminger <[EMAIL PROTECTED]>
>>
>> Date: Thu, 20 Dec 2007 09:16:03
>> To:[EMAIL PROTECTED]
>> Cc:[EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org
>> Subject:
Hemmann, Volker Armin wrote:
> On Donnerstag, 20. Dezember 2007, you wrote:
>> The subject line is wrong.
>> You apparently run Linux, but not Linux 2.6.23.y.
>
> first of all, apart from this oops all other oopses I reported were with a
> not-tainted kernel. You might want to read the other
On Tue, Dec 18, 2007 at 09:59:24PM +0100, Stefan Richter wrote:
>
> From its purpose it sounds like you need this only for few special
> memory regions which would typically be mapped by dma_map_single()
We need the _sg versions too, as Roland already mentioned.
> and
> furthermore that
* Hemmann, Volker Armin <[EMAIL PROTECTED]> wrote:
> On Donnerstag, 20. Dezember 2007, you wrote:
> > Hemmann, Volker Armin wrote:
> > > [ 5194.131014] Pid: 22490, comm: sleep Tainted: P2.6.23.11reiser4
> > > #4
> >
> > The subject line is wrong.
> > You apparently run Linux, but not
Loic Prylli wrote:
Always using type 1 for accesses below 256 bytes looks like a very very
attractive solution
I know we had a lot of older kernels over the last two years that we
patched like that (we needed MMCONFIG for our own device development
purposes, but we also needed our machines to
Based on the discussion at http://lkml.org/lkml/2007/12/20/383, it was
felt that control_type might not be a good thing to implement right away.
We can add this flexibility at a later point when required.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
include/linux/memcontrol.h |6 --
On Thu, Dec 20, 2007 at 10:58:08AM +0100, Jean Delvare wrote:
> BTW, did you try your driver with lm-sensors 3.0.0?
Yes I did, and it looked ok to me. Did you find something wrong?
--D
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Tue, Dec 18, 2007 at 09:59:24PM +0100, Stefan Richter wrote:
>
> So that would be option 3) of yours, though without your attrs
> parameter. Do you expect the need for even more flags for other kinds
> of special behavior?
I was hoping to keep the option of adding additional
flags, but
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > This reintroduces the fault vs truncate race window, which must be fixed.
> >
> > Hmmm... perhaps.
>
> What do you mean by perhaps?
I mean 'perhaps'. I'm not sure I remember what the race was, so I can't
On 12/20/2007 1:16 PM, Matthew Wilcox wrote:
>
> Bad deduction. What's happening is that the write to the BAR is causing
> it to overlap the decode for mmconfig space. So the mmconfig write to
> set the BAR back never gets through.
>
> I have a different idea to fix this problem. Instead of
Josh Boyer wrote:
Several platforms require the mkimage tool to generate a uImage file
that is used with U-Boot. This brings the mkimage tool in-kernel to
enable building those platforms without having mkimage internally
provided.
This is currently based off of the version found in U-Boot
On Donnerstag, 20. Dezember 2007, David Newall wrote:
> >>> On Montag, 17. Dezember 2007, you wrote:
> >>>
> >>> and another one, this time tainted with the nvidia module:
> >>> 5194.130985] Unable to handle kernel paging request at 0300
> >>> RIP:
>
> Numbers like that don't suggest
Arjan van de Ven wrote:
On Thu, 20 Dec 2007 08:16:54 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
Arjan van de Ven wrote:
On Wed, 19 Dec 2007 11:48:14 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
I think C3 guarantees that the cache contents stay intact, and thus
it might make
On Thu, Dec 20, 2007 at 01:30:16PM -0500, Tony Camuso wrote:
> Matthew Wilcox wrote:
>
> >Bad deduction. What's happening is that the write to the BAR is causing
> >it to overlap the decode for mmconfig space. So the mmconfig write to
> >set the BAR back never gets through.
> >
> >I have a
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > I'd much prefer if you would handle this in the filesystem, and have it
> > > set PG_private whenever fscache needs to receive a callback, and DTRT
> > > depending on whether PG_fscache etc. is set or not.
> >
> > That's tricky and slower[*]. One of
Matthew Wilcox wrote:
Bad deduction. What's happening is that the write to the BAR is causing
it to overlap the decode for mmconfig space. So the mmconfig write to
set the BAR back never gets through.
I have a different idea to fix this problem. Instead of writing
0x, we could look
Greg KH wrote:
Why haven't we gotten reports about this before if this is a common
problem?
And why hasn't the vendor fixed the bios on these to work properly?
I can't really answer either of these questions. All I know is the
problem exists, and we need to deal with it.
That's why the
>
> It never gets to the printk(). You were right about the
> compilation. Somebody changed the kernel to compile with
> parameter passing in REGISTERS! This means that EVERYTHING
> needs to be compiled the same way, 'C' calling conventions
> were not good enough!
How did you build the module.
On Thu, 20 Dec 2007 08:16:54 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Wed, 19 Dec 2007 11:48:14 -0800
> > "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> >
> >> I think C3 guarantees that the cache contents stay intact, and thus
> >> it might make sense in
> It appears that my problem boils down to a single host page of memory
> that is mapped for dma, and the dma address returned by dma_map_sg()
> is _not_ 64KB aligned. Here is an example:
> My first question is: Is there an assumption or requirement in linux
> that dma_addressess should
On Thu, Dec 20, 2007 at 01:04:09PM -0500, Tony Camuso wrote:
> Sorry, that was the 82Q963/Q965 graphics controller, PCI ID 2992.
>
> I can't remember why I thought PCI ID 2992 maps to 830M/MG. I think
> it was in some intel doc about the ICH8 or ICH9.
>
> Nevertheless, I have an hp dc5700
On Donnerstag, 20. Dezember 2007, you wrote:
> On Thu, 2007-12-20 at 06:53 +0100, Hemmann, Volker Armin wrote:
> > On Donnerstag, 20. Dezember 2007, you wrote:
> > > On Thu, 2007-12-20 at 03:13 +0100, Hemmann, Volker Armin wrote:
> > > > On Montag, 17. Dezember 2007, you wrote:
> > > >
> > > > and
Hugh Dickins wrote:
> On Wed, 19 Dec 2007, Balbir Singh wrote:
>> Hugh Dickins wrote:
>>
>> We always call mem_cgroup_isolate_pages() from shrink_(in)active_pages
>> under spin_lock_irq of the zone's lru lock. That's the reason that we
>> don't explicitly use it in the routine.
>
> Indeed,
On Donnerstag, 20. Dezember 2007, you wrote:
> Hemmann, Volker Armin wrote:
> > [ 5194.131014] Pid: 22490, comm: sleep Tainted: P2.6.23.11reiser4
> > #4
>
> The subject line is wrong.
> You apparently run Linux, but not Linux 2.6.23.y.
first of all, apart from this oops all other oopses I
On Thu, 2007-12-20 at 11:07 +1100, James Morris wrote:
> On Wed, 19 Dec 2007, David Chinner wrote:
>
> > Folks,
> >
> > I just updated a git tree and started getting errors on a
> > "copy_keys" macro warning.
> >
> > The code I've been working on uses a ->copy_keys() method for
> > copying the
Greg KH wrote:
But you never answered my questions about _who_ would be responding to
those log messages about reporting things...
thanks,
greg k-h
I did.
I said I would remove that string, because I don't want all that email,
either. It's a little past the middle of the post appended
On Dec 20, 2007 12:51 PM, Stephen Hemminger
<[EMAIL PROTECTED]> wrote:
>
> Quit top-posting!
>
> If this is the case then the whole usage of round_jiffies() is bogus. All
> users of round_jiffies()
> should just be converted to deferrable?? I am a bit concerned that if
> deferrable gets used
I'm pleased to announce the v24.1 CFS backport patches.
It is a full backport of the latest & greatest upstream scheduler code
to v2.6.23.12, v2.6.22.15 and v2.6.21.7. (Note: the upstream 2.6.24-rc5
and soon-to-be-released v2.6.24-rc6 kernels already include the v24.1
CFS code.)
The CFS
Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 09:22:05AM -0800, Greg KH wrote:
I can't imagine there are too many machines with MMCONFIG and an i830
chipset. The laptop I'm currently typing on is an i830 ... and its
BIOS is from 2002, well predating the specification of MMCONFIG. If I
didn't
On Thu, Dec 20, 2007 at 06:51:04PM +0100, Jan Kara wrote:
> Hi Andrew,
>
> nobody seemed to care about this patch, so could you pull it into -mm so
> that it gets broader testing? Thanks.
Oh, this can get my ack btw:
Acked-by: Mark Fasheh <[EMAIL PROTECTED]>
--Mark
--
Mark Fasheh
On Dec 20, 2007 12:05 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
>
> I can't even apply this patch and the e1000 one... not only is it whitespace
> damaged it is also not properly formatted as patch at all. If you want me to
> take
> these patches seriously, then please fix the formatting issues.
On Thu, Dec 20, 2007 at 12:39:48PM -0500, Tony Camuso wrote:
> Greg KH wrote:
>> Ah, sorry, I was thinking you were using dev_info(), which is what you
>> should be using instead anyway :)
>
> I found it in include/linux/device.h
>
> #define dev_info(dev, format, arg...) \
>
Hi Andrew,
nobody seemed to care about this patch, so could you pull it into -mm so
that it gets broader testing? Thanks.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
Although we don't allow writes over
On Thu, 20 Dec 2007 17:29:23 +
>
> -Original Message-
> From: Stephen Hemminger <[EMAIL PROTECTED]>
>
> Date: Thu, 20 Dec 2007 09:16:03
> To:[EMAIL PROTECTED]
> Cc:[EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] sky2: Use deferrable
On Thu, Dec 20, 2007 at 04:53:59AM -0800, David Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Mon, 17 Dec 2007 08:55:54 -0600
>
> > On Sun, Dec 16, 2007 at 10:39:17PM -0800, Andrew Morton wrote:
> > Actually, you may only need these two:
> >
> > >
Hey Roland (and any iommu/ppc/dma experts out there):
I'm debugging a data corruption issue that happens on PPC64 systems
running rdma on kernels where the iommu page size is 4KB yet the host
page size is 64KB. This "feature" was added to the PPC64 code recently,
and is in kernel.org from
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
Greg KH wrote:
Ah, sorry, I was thinking you were using dev_info(), which is what you
should be using instead anyway :)
I found it in include/linux/device.h
#define dev_info(dev, format, arg...) \
dev_printk(KERN_INFO , dev , format , ## arg)
The info I'm trying to print
Hugh Dickins wrote:
> On Thu, 20 Dec 2007, Andrew Morton wrote:
>> On Thu, 20 Dec 2007 21:54:15 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
>>> I was going to say the same thing, page_get_page_cgroup() does not hold
>>> any references. May be _get_ in the name is confusing.
>> It is a bit
On Thu, 20 Dec 2007, Andrew Morton wrote:
> On Thu, 20 Dec 2007 21:54:15 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> > I was going to say the same thing, page_get_page_cgroup() does not hold
> > any references. May be _get_ in the name is confusing.
>
> It is a bit unconventional.
On Thu, Dec 20, 2007 at 09:22:05AM -0800, Greg KH wrote:
> > The one device we know about that throws exceptions is the 830M/MG
> > graphics chip. This chip passes the read-compare test, so the code
> > merrily advances to bus sizing. When the bus sizing code writes the
> > BAR at offset 0x18 in
On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <[EMAIL PROTECTED]> wrote:
> On further investigation, "cat /proc/iomem" does not trigger the stack
> trace until after a suspend-to-disk/resume cycle has occurred.
I still can't reproduce this.
Could you please try this?
- cat /proc/iomem
-
Parag Warudkar wrote:
>
> Reduce wakeups from idle per second.
>
> Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
>
> --- linux-2.6/drivers/net/e1000e/netdev.c2007-12-07
> 10:04:39.0 -0500
> +++ linux-2.6-work/drivers/net/e1000e/netdev.c2007-12-18
> 20:45:59.0 -0500
>
On Thu, Dec 20, 2007 at 07:28:00AM -0500, Tony Camuso wrote:
>
>
> Original Message
> Subject: Re: [PATCH 0/5]PCI: x86 MMCONFIG
> Date: Wed, 19 Dec 2007 19:33:45 -0500
> From: Tony Camuso <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: Greg KH <[EMAIL PROTECTED]>
>
> On Thu, 20 Dec 2007, Bj?rn Steinbrink wrote:
> >
> > OK, so I looked for PG_dirty anyway.
> >
> > In 46d2277c796f9f4937bfa668c40b2e3f43e93dd0 you made try_to_free_buffers
> > bail out if the page is dirty.
> >
> > Then in 3e67c0987d7567ad41164a153dca9a43b11d, Andrew fixed
> >
On Thu, 2007-12-20 at 11:14 -0600, Steve Wise wrote:
> Hey Roland (and any iommu/ppc/dma experts out there):
>
> I'm debugging a data corruption issue that happens on PPC64 systems
> running rdma on kernels where the iommu page size is 4KB yet the host
> page size is 64KB. This "feature" was
On Thu, Dec 20, 2007 at 07:26:17AM -0500, Tony Camuso wrote:
>>> +
>>> +#define CHECK_MMCFG_STR_1 \
>>> + "PCI: Device at %04x:%02x.%02x.%x is not MMCONFIG compliant.\n"
>>> +#define CHECK_MMCFG_STR_2 \
>>> + "PCI: Bus %04x:%02x and its descendents cannot use MMCONFIG.\n"
>> Why define these
On Tue, 18 Dec 2007 20:13:28 -0500 (EST)
Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> sky2 can use deferrable timer for watchdog - reduces wakeups from idle per
> second.
>
> Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
>
> --- linux-2.6/drivers/net/sky2.c 2007-12-07
On Thu, 2007-12-20 at 11:11 -0600, Matt Mackall wrote:
> On Thu, Dec 20, 2007 at 05:53:41PM +0100, Peter Zijlstra wrote:
> >
> > On Thu, 2007-12-20 at 15:26 +, Hugh Dickins wrote:
> >
> > > The asynch code: perhaps not worth doing for MADV_WILLNEED alone,
> > > but might prove useful for
On Thu, Dec 20, 2007 at 05:53:41PM +0100, Peter Zijlstra wrote:
>
> On Thu, 2007-12-20 at 15:26 +, Hugh Dickins wrote:
>
> > The asynch code: perhaps not worth doing for MADV_WILLNEED alone,
> > but might prove useful for more general use when swapping in.
> > Not really the same as Con's
On Thu, 20 Dec 2007 21:54:15 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> >> struct page_cgroup *page_get_page_cgroup(struct page *page)
> >> {
> >>return (struct page_cgroup *)
> >>(page->page_cgroup & ~PAGE_CGROUP_LOCK);
> >> }
> >>
> >> I guess the issue is that often a
Hi Matthew,
I worked on some thing similar. For one of our customer product that
goes to defense and security markets, we had to support maximum possible
memory test. We implemented a mechanism of pre-test to test the memory
with walking 1's and 0's just before Linux kernel starts allocating
On Thu, Dec 20, 2007 at 11:00:30AM -0500, Andres Salomon wrote:
> On Thu, 20 Dec 2007 18:07:16 +0300
> Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> > Hi Andres,
> >
> [...]
> >
> > Then, what the power supply subsystem is for? Just place all the
> > drivers together in driver/power/, and let
On Thu, Dec 20, 2007 at 09:19:00AM -0500, Tony Camuso wrote:
> Tony Camuso wrote:
>
>> Greg KH wrote:
>>> On Wed, Dec 19, 2007 at 05:17:51PM -0500, [EMAIL PROTECTED] wrote:
+extern struct pci_ops pci_legacy_ops; /* direct.c */
>>>
>>> This isn't needed in this patch at all, and might
Greg KH wrote:
Sure, but you do not reference it in this patch, right? So it's not
needed until you actually use it, so just include it in the patch that
you are needing it in.
thanks,
greg k-h
Will do.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Wed, 28 Nov 2007, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
>
> ps3: Use the HV's storage device notification mechanism properly
>
> The hypervisor has a storage device notification mechanism to wait until a
> storage device is ready. Unfortunately the storage
Ingo Molnar wrote:
> * Mike Travis <[EMAIL PROTECTED]> wrote:
>
by revert commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, we could
use c->cpu_index in identify_cpu.
>>> but that's 2.6.25 stuff, right? Travis?
>>>
>> Looking at this more closely, yes my change is not needed and should
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
>
> - If something goes wrong with a PCI device's probing or initialisation, try
> reverting pci-disable-decoding-during-sizing-of-bars.patch.
>
> - git-sched was dropped due to
On Thu, 2007-12-20 at 15:26 +, Hugh Dickins wrote:
> The asynch code: perhaps not worth doing for MADV_WILLNEED alone,
> but might prove useful for more general use when swapping in.
> Not really the same as Con's swap prefetch, but worth looking
> at that for reference. But I guess this
> But I'd be very surprised if the router is acting as anything more
> that a network-layer device. It might perhaps have some soft connection
> state being used for generating accounting records. Being Cisco
> it's probably a switch-router, so it might carry some per-port hard
> state for
On Wed, 19 Dec 2007, Balbir Singh wrote:
> Hugh Dickins wrote:
>
> We always call mem_cgroup_isolate_pages() from shrink_(in)active_pages
> under spin_lock_irq of the zone's lru lock. That's the reason that we
> don't explicitly use it in the routine.
Indeed, thanks.
>
> > 2. There's
On Thu, 2007-12-20 at 21:54 +0530, Balbir Singh wrote:
>
> I was going to say the same thing, page_get_page_cgroup() does not hold
> any references. May be _get_ in the name is confusing.
OK, you three had the entire conversation outing me before I even fot to
respond! :)
Yeah, I thought it
On Thu, 20.12.07 14:09, Hugh Dickins ([EMAIL PROTECTED]) wrote:
> > Lennart asked for madvise(WILLNEED) to work on anonymous pages, he plans
> > to use this to pre-fault pages. He currently uses: mlock/munlock for
> > this purpose.
>
> I certainly agree with this in principle: it just seems an
On Thu, Nov 29, 2007 at 06:35:28PM -0800, Joe Perches wrote:
> On Fri, 2007-11-30 at 09:54 +0800, Li Zefan wrote:
> > So it doesn't deserve the effort to eliminate these periods, isn't it?
>
> I hope these will eventually disappear.
>
> > Or we can add a check to checkpatch.pl to prevent new
* Mike Travis <[EMAIL PROTECTED]> wrote:
> >> by revert commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, we could
> >> use c->cpu_index in identify_cpu.
> >
> > but that's 2.6.25 stuff, right? Travis?
> >
>
> Looking at this more closely, yes my change is not needed and should
> be removed.
Ingo Molnar wrote:
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
>> Ingo.
>>
>> commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another
>> patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86:
>> fixup cpu_info array conversion) already removed clearing of
>>
Jeff,
Here are a few more for 2.6.24...please let me know if there are any
problems!
Thanks,
John
P.S. The rtl8187 USB ID is already in your upstream branch -- I'm sure
it would seem like a fix if it was the ID for your wireless stick. :-)
---
Individual patches are available here:
On Thu, 20 Dec 2007, Bj?rn Steinbrink wrote:
>
> OK, so I looked for PG_dirty anyway.
>
> In 46d2277c796f9f4937bfa668c40b2e3f43e93dd0 you made try_to_free_buffers
> bail out if the page is dirty.
>
> Then in 3e67c0987d7567ad41164a153dca9a43b11d, Andrew fixed
> truncate_complete_page,
On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote:
> It never gets to the printk(). You were right about the
> compilation. Somebody changed the kernel to compile with
> parameter passing in REGISTERS! This means that EVERYTHING
> needs to be compiled the same way, 'C'
Peter Zijlstra wrote:
> On Thu, 2007-12-20 at 14:16 +, Hugh Dickins wrote:
>> On Thu, 20 Dec 2007, Peter Zijlstra wrote:
>>> On Thu, 2007-12-20 at 13:14 +, Hugh Dickins wrote:
On Wed, 19 Dec 2007, Dave Hansen wrote:
>> - page_assign_page_cgroup(page, NULL);
>> +
Now that the mkimage tool is merged into the kernel, we can remove the
unused mkuboot.sh script.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
scripts/mkuboot.sh | 19 ---
1 file changed, 19 deletions(-)
--- linux-2.6.orig/scripts/mkuboot.sh
+++ /dev/null
@@ -1,19 +0,0 @@
Rework the architecture specific Makefiles to use the in-kernel version
of the mkimage tool.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/arm/boot/Makefile |4 ++--
arch/avr32/boot/images/Makefile |4 ++--
arch/blackfin/boot/Makefile |4 ++--
The following patches merge the mkimage tool into the kernel. This
utility is used by several arches to create a uImage file suitable for
booting with U-Boot.
As it stands today, a mkuboot.sh script is called, which searches for
the mkimage utility installed on the host system. This is slightly
Several platforms require the mkimage tool to generate a uImage file
that is used with U-Boot. This brings the mkimage tool in-kernel to
enable building those platforms without having mkimage internally
provided.
This is currently based off of the version found in U-Boot 1.3.1.
Signed-off-by:
Arjan van de Ven wrote:
On Wed, 19 Dec 2007 11:48:14 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
I think C3 guarantees that the cache contents stay intact, and thus
it might make sense in some technology to preserve the TLB as well
(being a kind of cache.)
that sounds nice. It's
On Thu, 20 Dec 2007, Lennart Sorensen wrote:
> On Wed, Dec 19, 2007 at 03:56:45PM -0500, linux-os (Dick Johnson) wrote:
>>
>> On Wed, 19 Dec 2007, Lennart Sorensen wrote:
>>
>>> On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
Here is a so-called BUG when
> I still dont understand.
>
> "tcpdump -p -n -s 1600 -c 1" doesnt reveal User data at all.
>
> Without any exact data from you, I am afraid nobody can help.
Oh, I didn't see that you specified specific options. I'll still have
to anonymize 2000+ IP addresses, but I think there is an open
> > On 2007.12.19 09:44:50 -0800, Linus Torvalds wrote:
> > >
> > >
> > > On Sun, 16 Dec 2007, Krzysztof Oledzki wrote:
> > > >
> > > > I'll confirm this tomorrow but it seems that even switching to
> > > > data=ordered
> > > > (AFAIK default o ext3) is indeed enough to cure this problem.
> >
On Thu, 20 Dec 2007 18:07:16 +0300
Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> Hi Andres,
>
[...]
>
> Then, what the power supply subsystem is for? Just place all the
> drivers together in driver/power/, and let them create sysfs
> attributes by their own. You'll get a medley, not the
On 12/20/07, David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 19, 2007 at 11:41:44PM -0500, Jon Smirl wrote:
> > Convert MPC i2c driver from being a platform_driver to an open
> > firmware version. Error returns were improved. Routine names were
> > changed from fsl_ to mpc_ to make them
On Wed, 19 Dec 2007, KAMEZAWA Hiroyuki wrote:
> On Tue, 18 Dec 2007 22:19:22 + (GMT)
> Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > 1. Why is spin_lock_irqsave rather than spin_lock needed on mz->lru_lock?
> > If it is needed, doesn't mem_cgroup_isolate_pages need to use it too?
> >
> When I
Andrew, I double-issued warnings in some cases. Mind replacing
with this one?
Thanks,
-Eric
hfs seems prone to bad things when it encounters on disk corruption.
Many values are read from disk, and used as lengths to memcpy, as an
example. This patch fixes up several of these problematic cases.
This patch makes the RTC emulation functions in arch/x86/kernel/hpet.c usable
for kernel modules. It
- exports the functions (EXPORT_SYMBOL_GPL()),
- adds an interface to register the interrupt callback function
instead of using only a fixed callback function and
- replaces the
301 - 400 of 1372 matches
Mail list logo
