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 make the compiler
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 of
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 them create
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, 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 get function has a
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 swap
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 10:04:39.0 -0500
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 more general
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 added
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 if they are only used
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]
References:
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,
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
@@ -3899,7
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
-
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. page_cgroup()?
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 this
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 unconventional.
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 wrote:
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:
maps4-add-proc-kpagecount-interface.patch
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 timer for
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...) \
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.
Sigh -
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
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 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 everywhere
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
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 keys in a btree
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 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 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 another one, this
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, thanks.
2.
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 microtower
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 have the
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 some technology to
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. It
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
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 the things I
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 sense in
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 different idea
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 hardware faults. All
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 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 writing
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 for
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
evaluate whether
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
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
* 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 Linux 2.6.23.y.
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 mails I
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
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: Re: [PATCH] sky2:
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 fix the
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
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 -
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
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 preserve the TLB as
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 in
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
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
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 in
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 scheduled on
the hour
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 all. I tried
both on
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 conversion)
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 mkimage
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 performance
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 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 different idea
Kok, Auke 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?
*on that cpu*. Timers are per cpu, as are interrupts. Just not per se the same
one ...
On 12/20/2007 2:08 PM, Matthew Wilcox wrote:
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
Hi folks,
With this series, the bulk of the work of pvops64 is done.
Here, I integrate most of the paravirt.c and paravirt.h files, making
them applicable to both architectures.
CONFIG_PARAVIRT is _not_ present yet. Basically, this code is missing page
table integration (patches currently being
On Thu, 20 Dec 2007 11:32:25 -0800 Daniel Walker [EMAIL PROTECTED] wrote:
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
This patch adjust the PVOP_VCALL and PVOP_CALL macros to
work with x86_64. It has a different calling convention, and
we use auxiliary macros to account for both calling conventions
as cleanly as possible
Comments are adjusted accordingly.
Signed-off-by: Glauber de Oliveira Costa [EMAIL
This patch changes paravirt_32.c to paravirt.c. The goal
is to have paravirt support in x86_64, so we do it in a common file
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
arch/x86/kernel/Makefile_32 |2 +-
arch/x86/kernel/paravirt.c| 475
write_tsc() does not need to be enclosed in any paravirt closure,
as it uses wrmsr(). So we rip off the duplicate in msr.h
and the definition from paravirt.h
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
include/asm-x86/msr.h |2 --
include/asm-x86/paravirt.h |2 --
This patch adds a field in pv_cpu_ops for a paravirtualized hook
for rdtscp, needed for x86_64.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
arch/x86/kernel/paravirt.c |1 +
include/asm-x86/paravirt.h | 22 ++
2 files changed, 23 insertions(+), 0
To account for differences in x86_64, we change the macros that
create raw instances of the paravirt_patch_site struct.
We need to align 64-pointers to 64-bit boundaries, so we add an alignment
directive. Also, we need to make room for a word-sized pointer,
instead of a fixed 32-bit one
This patch adjust the paravirt macros used in assembly code
to accomodate for x86_64 as well.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
include/asm-x86/paravirt.h | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
Index:
i386 has a macro GET_CR0_INTO_EAX, used in early trap handling code.
x86_64 has similar needs, only it needs to put cr2 into rcx. We provide
a macro for such task, in the same way
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
include/asm-x86/paravirt.h |6 ++
1 files
This patch changes the irq handling function definitions
in paravirt.h (like raw_local_irq_disable) to accomodate for x86_64.
The differences are in the calling convention.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
include/asm-x86/paravirt.h | 43
The assembly code in entry_64.S issues a bunch of privileged instructions,
like cli, sti, swapgs, and others. Paravirt guests are forbidden to do so,
and we then replace them with macros that will do the right thing.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
This patch adds paravirt hook for swapgs operation, which is a privileged
operation in x86_64.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
arch/x86/kernel/paravirt.c |1 +
include/asm-x86/paravirt.h |9 +
include/asm-x86/processor.h |8
3 files
Since the advent of ticket locking, CLI_STRING, STI_STRING, and friends
are not used anymore. They can now be safely deleted.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
include/asm-x86/spinlock.h |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
Index:
x86_64 needs a potentially larger clobber list than i386, due to its calling
convention. So we add more CLBR_ defines for it.
Note that CLBR_ANY is different for each of the architectures, since it
comprises
the notion of All call clobbers in this architecture
Signed-off-by: Glauber de Oliveira
The core patching code for paravirt is sufficiently different
among i386 and x86_64, and we move them to specific files.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
arch/x86/kernel/Makefile_32 |2 +-
arch/x86/kernel/paravirt.c | 50
Like i386, x86_64 also need to include its own patching function.
(Well, if you're not in a hurry, and don't care about speed, you don't
really _need_ ;-))
So here they are. Not much different in essence from i386
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
x86_read_per_cpu() and its writeish sister are not present in x86_64. So in
this patch, we replace them with __get_cpu_var(), which is present in both
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
---
arch/x86/kernel/paravirt.c | 10 +-
1 files changed, 5 insertions(+), 5
Parag Warudkar wrote:
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
On Thu, 2007-12-20 at 12:06 -0800, Andrew Morton wrote:
On Thu, 20 Dec 2007 11:32:25 -0800 Daniel Walker [EMAIL PROTECTED] wrote:
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
Matthew Wilcox wrote:
Here's how BARs work ... when you write 0x to the BAR, it
ignores all the set bits that are less than the size of the BAR. So,
assuming this is a 256MB BAR (like my G33 is), what ends up written to
this BAR is 0xf000. Now, because this is graphics, apparently
On Thu, Dec 20, 2007 at 03:05:52PM -0500, Loic Prylli wrote:
I am not familiar with the tg3 driver, just trying to give a 5 minutes
look, it seems the typical cases where the pci-conf-space is used
intensively are with some rev in combination with the 82801
(TG3_FLG2_ICH_WORKAROUND) which I
Andrew Lutomirski wrote:
I understand that there's no way that /dev/random can provide good
output if there's insufficient entropy. But it still shouldn't leak
arbitrary bits of user data that were never meant to be put into the
pool at all.
It doesn't leak it though, it consumes it, and it
Ivan Kokshaysky wrote:
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
On Thu, 20 Dec 2007, Parag Warudkar wrote:
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
Adding A few more people to the discussion. You may well be right and we
would have to provide the same alignment, though that sucks a bit as one
of the reason we switched to 4K for the IOMMU is that the iommu space
available on pSeries is very small and we were running out of it with
64K pages
On Thu, 2007-12-20 at 13:29 -0600, Steve Wise wrote:
Or based on the alignment of vaddr actually...
The later wouldn't be realistic. What I think might be necessay, though
it would definitely cause us problems with running out of iommu space
(which is the reason we did the switch down to 4K),
1001 - 1100 of 1372 matches
Mail list logo
