Andi Kleen wrote:
[Ideally apply before the patch to enable gbpages direct mapping]
The gbpages direct patch assumed that __PAGE_KERNEL contains _PAGE_GLOBAL
(I think because that was true at some point in git-x86 and i forgot
to remove it again when forward porting)
This is currently true on
Adrian Bunk wrote:
On Thu, Jan 31, 2008 at 05:15:23PM +0100, Ingo Molnar wrote:
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Thu, Jan 31, 2008 at 05:00:33PM +0100, Ingo Molnar wrote:
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
You tested x86 but broke more than half a doz
Ingo Molnar wrote:
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
What about the breakages caused by commit
a5a19c63f4e55e32dc0bc3d936d7f94793d8b380 (this commit broke the
defconfig compilation on at least avr32, blackfin, sh, sparc and uml)?
the patch below fixes that.
Is it sa
Something in current x86.git is making my kernel build as ia64. I don't
see any obvious change which might be the cause.
: ezr:pts/6; make oldconfig
make -C /home/jeremy/hg/xen/paravirt/linux
O=/home/jeremy/hg/xen/paravirt/linux-i386/. oldconfig
/home/jeremy/hg/xen/paravirt/linux/arch/ia64/scr
Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
But I guess I overlooked the comment...
I guess the fix is to scatter linux/pagemap.h into the appropriate
places where these macros are used (asm-generic/tlb.h, for a start).
no. The fix is always to un
From: Ian Campbell <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 18:56:06 +
Subject: [PATCH] x86: fix early_ioremap pagetable ops for paravirt.
Some important parts of f6df72e71eba621b2f5c49b3a763116fac748f6e got dropped
along the way, reintroduce them.
Yep.
Acked-by: Jeremy Fitzh
Ingo Molnar wrote:
* Ian Campbell <[EMAIL PROTECTED]> wrote:
Some important parts of f6df72e71eba621b2f5c49b3a763116fac748f6e got
dropped along the way, reintroduce them.
thanks, applied. AFAICS it should only affect paravirt, not the native
kernel, right?
Correct.
J
--
To u
Xen currently needs swapper_pg_dir page aligned and sized. This fixes
the second part of that...
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/kernel/head_32.S |1 +
1 file changed, 1 ins
Ingo Molnar wrote:
thanks, applied. I'm wondering, where did we break that?
In the "PAE from boot" patch, I would guess.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.o
Ingo Molnar wrote:
FYI, only this one applied to the latest x86.git tree, could you please
resend? I guess the pgalloc.h related revert interfered.
OK. I'll do a quick rebase to this morning's tree and resend.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Hi Ingo,
Here's a followup set from that last batch of patches:
1. fix up the pgd_ctor merge, so that non-PAE will end up getting
kernel mappings
2. revert "optimise-pud_clear-cr3-reload"
3. only do a cr3 reload if pud_clear is being used on the active pagetable
4. update documentation abo
only
other use of pud_clear is during a large (1Gbyte+) munmap, and those
are sufficiently rare that a couple of cr3 reloads won't hurt.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable-3level.h | 11 +++
1 file changed, 7 insertions(+), 4 de
Remove bogus reference to "Pentium-II erratum A13" and point to the
actual canonical source of information about what requirements x86
processors have for PAE pagetable updates.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgalloc_32.h |6 +++
The constructors for PAE and non-PAE pgd_ctors are more or less
identical, and can be made into the same function.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: William Irwin <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable_32.c | 58 +
Revert "defer cr3 reload when doing pud_clear()" since I'm going to
replace it.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable_32.c |7 ---
include/asm-x86/pgtable-3level.h | 21 ++---
2 files changed
Andi Kleen wrote:
[Actually not needed for gbpages, but an indepedent, but related cleanup]
Use set_pte() for setting up the 2MB pages in the direct mapping similar
to what the earlier GBPAGES patches did for the 1GB PUDs.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/mm/init_6
Andi Kleen wrote:
Why? 64-bit Xen will need this to be set_pmd if its an update to L2 of
the table.
Then change_page_attr() and hugepages will already not work because they both
do exactly that.
And I didn't want to duplicate this manual code for the GBpages case, so i
changed it ever
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable.h | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
--- a/include/asm-x86/pgtable.h
+++ b/include/a
Hi Ingo,
This series:
1. Renames the alloc/release_{pt,pd} calls to _pte, _pmd so that its
clear what they operate on.
2. Adds alloc/release_pud, and puts calls in the appropriate places
3. Demacros some stuff in pgtable.h
A bit eclectic, but all fairly straightforward (and no changes to
n
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/kernel/paravirt.c |2 ++
arch/x86/mm/pgtable.c |1 +
include/asm-x86/paravirt.h | 11 +++
include/asm-x86/pgalloc.h |3 +++
4 files changed, 17 insertions(+)
diff --git a/arch/x86/kernel/paravi
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable.h | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
--- a/include/asm-x86/pgtable.h
+++ b/include/asm-x86/pgt
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
--- a/include/asm-x86/pgtable.h
+++ b/include/asm-x86/pgt
Rename (alloc|release)_(pt|pd) to pte/pmd to explicitly match the name
of the appropriate pagetable level structure.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/kernel/paravirt.c | 10 +-
arch/x86/kernel/vmi_32.c | 20 ++--
arch/
Hi Ingo,
This series does more unification of pgalloc, and creates a unified
mm/pgtable.c for common pagetable functions. Ends up removing
pgalloc_32/64.h in favour of pgalloc.h.
[ I thought I'd mailed this earlier, but I don't see it on lkml.
Maybe I created the mbox without sending it. Anyway
Convert asm-x86/pgalloc_64.h from macros into inline functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgalloc_64.h | 41 ++---
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/arch/x86/mm/init_64.c
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pageattr.c |2 --
include/asm-x86/pgalloc.h| 11 +++
include/asm-x86/pgalloc_32.h | 10 --
3 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/
Common definitions for 2-level pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c|6 ++
arch/x86/mm/pgtable_32.c |6 --
include/asm-x86/pgalloc.h| 16
include/asm-x86/pgalloc_32.h
Add a common arch/x86/mm/pgtable.c file for common pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/Makefile_32 |2
arch/x86/mm/Makefile_64 |2
arch/x86/mm/pgtable.c| 234 ++
arch/
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -39,32
Common definitions for 4-level pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c|7 ++
include/asm-x86/pgalloc.h| 46 --
include/asm-x86/pgalloc_32.h
Common definitions for 3-level pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c|8
arch/x86/mm/pgtable_32.c | 10 --
include/asm-x86/pgalloc.h| 31 +++
include/a
Ingo Molnar wrote:
another thing: these inlines are a bit fat and they are used in more
than one place. Please move them into pgtable.c. The rule of thumb is:
if an inline is more than 2 lines big, it is a likely candidate for
uninlining. (and even many 2-liners, and even some 1-liners are
can
Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
Common definitions for 4-level pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c|7 ++
include/asm-x86/pgalloc
Ingo Molnar wrote:
yes but the early hang is very real so either my hardware is stubbornly
ignoring that your patch is pure code movement (in which case i'll have
to have a word or two with my hardware), or your patch is perhaps wrong
somewhere ;-)
I see what it is. set_pud on 32-bit need
Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
Add a common arch/x86/mm/pgtable.c file for common pagetable functions.
randconfig testing found a build breakage on 32-bit, and that got
bisected down to this patch of yours.
Couldn't reproduce. W
Ingo Molnar wrote:
oops, i thought i pasted that. It was this:
arch/x86/mm/pgtable.c: In function 'pgd_alloc':
arch/x86/mm/pgtable.c:213: error: implicit declaration of function
'quicklist_alloc'
arch/x86/mm/pgtable.c:213: warning: initialization makes pointer from integer
without a cast
arch/
Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
Ingo Molnar wrote:
oops, i thought i pasted that. It was this:
arch/x86/mm/pgtable.c: In function 'pgd_alloc':
arch/x86/mm/pgtable.c:213: error: implicit declaration of function
'quickli
dir
At the early stages of boot, before the kernel pagetable has been
fully initialized, a Xen kernel will still be running off the
Xen-provided pagetables rather than swapper_pg_dir[]. Therefore,
readback cr3 to determine the base of the pagetable rather than
assuming swapper_pg_dir[].
Si
Joel Becker wrote:
On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct f
Ian Campbell wrote:
On Thu, 2008-02-14 at 17:01 +, Ian Campbell wrote:
I have a xen domain builder patch as well. I was waiting for the Linux
side to gain some traction before putting it forward (I'd attach it
now but it's at home on a laptop which is sleeping).
Here it is:
# HG c
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
Do you also have a patch to update the boot protocol?
Looking for anything different than the root of this thread?
Yes, the patch for the Xen domain builder to boot a bzImage using the
Linux boot protocol rather than the Xen one. Ian&#
Joel Becker wrote:
On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
I'm seeing the same problem, with no messages at all from xen
other than "domain crashed, restart disabled" in xend.log. I got a
different comm
Joel Becker wrote:
On Sat, Feb 16, 2008 at 01:44:26PM +1100, Jeremy Fitzhardinge wrote:
Joel Becker wrote:
(XEN) mm.c:1825:d109 Bad type (saw 2801 != exp
e000) for mfn 3a2f0f (pfn f0)
(XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry
On 07/24/2012 06:15 AM, Yuanhan Liu wrote:
> The old code would call __get_free_page() even though previous
> allocation fail met. This is not needed.
Yeah, I guess, but its hardly worth changing.
J
>
> Signed-off-by: Yuanhan Liu
> Cc: Jeremy Fitzhardinge
> Cc: Tho
On 10/09/2012 06:14 PM, Andrew Morton wrote:
> On Wed, 10 Oct 2012 00:09:12 + KY Srinivasan wrote:
>
+ if (!pg) {
+ *alloc_error = true;
+ return i * alloc_unit;
+ }
+
+ totalram_pages -= alloc_unit;
>>>
On 06/01/2013 01:14 PM, Andi Kleen wrote:
> FWIW I use the paravirt spinlock ops for adding lock elision
> to the spinlocks.
Does lock elision still use the ticketlock algorithm/structure, or are
they different? If they're still basically ticketlocks, then it seems
to me that they're complimentar
On 06/01/2013 12:21 PM, Raghavendra K T wrote:
> x86/spinlock: Replace pv spinlocks with pv ticketlocks
>
> From: Jeremy Fitzhardinge
I'm not sure what the etiquette is here; I did the work while at Citrix,
but jer...@goop.org is my canonical email address. The Citrix address
is de
reasonable for all other operations because it makes a real
semantic difference, but overly strict for bit operations.
J
> [1]: http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf
>
> Cc: Jeremy Fitzhardinge
> Cc: Andi Kleen
> Cc: Linus Torvalds
> Cc: Ingo Molnar
>
(Resent without HTML)
On 07/14/2013 10:19 AM, Linus Torvalds wrote:
> Now, there are possible cases where you want to make the size explicit
> because you are mixing memory operand sizes and there can be nasty
> performance implications of doing a 32-bit write and then doing a
> 64-bit read of the
On 07/14/2013 12:30 PM, Tim Northover wrote:
>> And that is why I think you should just consider "bt $x,y" to be
>> trivially the same thing and not at all ambiguous. Because there is
>> ABSOLUTELY ZERO ambiguity when people write
>>
>>bt $63, mem
>>
>> Zero. Nada. None. The semantics are *exac
On 07/30/2013 12:53 PM, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> I was wondering if it would be possible to remove from linux-next
> the three xen trees and instead use a combined tree, similar to the
> x86 tip (so the various maintainers share it)?
>
> The ones that would be removed are:
>
> xen
On 08/13/2013 01:02 PM, Raghavendra K T wrote:
> * Ingo Molnar [2013-08-13 18:55:52]:
>
>> Would be nice to have a delta fix patch against tip:x86/spinlocks, which
>> I'll then backmerge into that series via rebasing it.
>>
> There was a namespace collision of PER_CPU lock_waiting variable when
>
On 08/05/2013 11:05 AM, Konrad Rzeszutek Wilk wrote:
> Jeremy has been a key person in making Linux work with Xen.
> He has been enjoying the last year working on something
> different so reflect that in the maintainers file.
Ack.
J
>
> CC: Jeremy Fitzhardinge
> Sig
Joel Becker wrote:
Unfortunately that doesn't narrow down what the kernel was actually
trying to do at the time. Clearly a set_pte; looks like someone is
trying to create a writable mapping of an existing pte page.
Does "console=hvc0 earlyprintk=xen" on the kernel command line give any
Ian Campbell wrote:
On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
x86/xen: Do not scan for DMI unless the DMI region is re
[EMAIL PROTECTED] wrote:
diff --git a/arch/x86/xen/events.c b/drivers/xen/events.c
similarity index 95%
rename from arch/x86/xen/events.c
rename to drivers/xen/events.c
index dcf613e..7474739 100644
--- a/arch/x86/xen/events.c
+++ b/drivers/xen/events.c
@@ -37,7 +37,9 @@
#include
#include
-
[EMAIL PROTECTED] wrote:
Yep. We removed the guest handle stuff for the initial upstreaming,
since it isn't necessary on x86 and it quietened some of the reviewer
noise. But I expected we'd need to reintroduce it at some stage.
J
--
To unsubscribe from this list: send the line "unsubscri
Markus Armbruster wrote:
Forgot to mention: This patch depends on
Subject: [PATCH] xen: Make xen-blkfront write its protocol ABI to xenstore
From: Markus Armbruster <>
Date: Thu, 06 Dec 2007 14:45:53 +0100
http://lkml.org/lkml/2007/12/6/132
Sorry!
Sorry, I haven't pushed this ups
[EMAIL PROTECTED] wrote:
Hi. Recently the xen-ia64 community started to make efforts to merge
xen/ia64 Linux to upstream. The first step is to merge up domU portion.
This patchset is preliminary for xen/ia64 domU linux making the current
xen/x86 domU code more arch generic and adding missing def
Markus Armbruster wrote:
This is a pair of Xen para-virtual frontend device drivers:
drivers/video/xen-fbfront.c provides a framebuffer, and
drivers/input/xen-kbdfront provides keyboard and mouse.
Unless they're actually inter-dependent, could you post this as two
separate patches? I don't
around the place.
Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
From: Ian Campbell <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
drivers/block/xen-blkfront.c | 18 ++
1 file chan
Ian Campbell wrote:
I'll see if I can track down where the page is getting used and have a
go at getting in there first. It must be pretty early to be allocated
already when dmi_scan_machine gets called.
It's possible that the domain builder might have already allocated a PT
at this address. I h
Linus Torvalds wrote:
On Thu, 21 Feb 2008, Jeremy Fitzhardinge wrote:
Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
From: Ian Campbell <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
This is just wrong. The From: goes at the *top*, and
H. Peter Anvin wrote:
Still curious about why a pagetable page is ending up in that range
though. Seems like it shouldn't be possible, since we shouldn't be
allowed to allocate from those pages, at least until the DMI probe
has happened... Unless the early allocator is only excluded from
e82
Linus Torvalds wrote:
On Thu, 21 Feb 2008, Jeremy Fitzhardinge wrote:
OK. Have you fixed it, or shall I resend?
I'll fix it, but I want people to know so that I don't have to fix things
like this in the future (*).
Linus
(*) I keed, I keed.
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
It seems to me that those pages are being handed out as heap pages by
the early allocator. In the Xen case this is OK because there's
nothing magic about them. But if real hardware doesn't reserve these
pages in the E820 map,
On 08/13/2012 03:47 AM, Mel Gorman wrote:
> Resending to correct Jeremy's address.
>
> On Wed, Aug 08, 2012 at 03:50:46PM -0700, David Miller wrote:
>> From: Mel Gorman
>> Date: Tue, 7 Aug 2012 09:55:55 +0100
>>
>>> Commit [c48a11c7: netvm: propagate page->pfmemalloc to skb] is responsible
>>> for
On 08/18/2012 07:56 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> The paravirt patching code assumes that it can reference a
> local assembler label between two different top level assembler
> statements. This does not work with some experimental gcc builds,
> where the assembler code may end up in
On 08/18/2012 07:56 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> The paravirt thunks use a hack of using a static reference to a static
> function to reference that function from the top level statement.
>
> This assumes that gcc always generates static function names in a specific
> format, which
Arnd Hannemann wrote:
As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
accordingly.
!PAE is supposed to work, but it is a rarely used configuration. How
does it fail?
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Arnd Hannemann wrote:
This is with 2.6.24.2, but latest-git looks the same:
I also tried with 2.6.23 which crashes instantly, without any output of the
guest.
I'm not too surprised. Non-PAE Xen is a bit of a rarity, and it only
gets tested rarely. Chris Wright did spend some time on it a
Linus Torvalds wrote:
This isn't a problem with things like "Signed-off-by:" etc tags, because
they have no automated meaning and don't really change the commit itself,
but the "From:"/"Date:"/"Subject:" markers at the head of the message
really do have real meaning, and get removed from the co
Arnd Hannemann wrote:
Jeremy Fitzhardinge wrote:
Arnd Hannemann wrote:
This is with 2.6.24.2, but latest-git looks the same:
I also tried with 2.6.23 which crashes instantly, without any output
of the guest.
I'm not too surprised. Non-PAE Xen is a bit of a rarity, a
Markus Armbruster wrote:
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
Markus Armbruster wrote:
This is a pair of Xen para-virtual frontend device drivers:
drivers/video/xen-fbfront.c provides a framebuffer, and
drivers/input/xen-kbdfront provides keyboard and
CC arch/x86/kernel/traps_32.o
/home/jeremy/hg/xen/paravirt/linux/arch/x86/kernel/traps_32.c:59:27: error:
asm/kmemcheck.h: No such file or directory
asm-x86/kmemcheck.h does seem to be completely missing. Looks like
8db0acefb3025795abe3f37669354677a03de680 "x86: add hooks for kmemcheck"
Ingo Molnar wrote:
* Vegard Nossum <[EMAIL PROTECTED]> wrote:
asm-x86/kmemcheck.h does seem to be completely missing. Looks like
8db0acefb3025795abe3f37669354677a03de680 "x86: add hooks for
kmemcheck" should have added the file.
Hm. This is x86#testing, no? I don't think there's
Ingo Molnar wrote:
Jeremy, you might want to start tracking x86.git#testing:
http://people.redhat.com/mingo/x86.git/README
if you want to follow the latest & greatest x86.git code.
Right, will do.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
Mark McLoughlin wrote:
@@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
}
}
else {
+ if (e820_all_mapped(0xF, 0xF+0x1, E820_RAM))
+ goto out;
One issue with using the e820 map for this is that a X
On Tue, Apr 10, 2001 at 02:35:52PM +0200, Heusden, Folkert van wrote:
> So, I was wondering: isn't it a nice idea to have a switch in the
> configuration menu to disable entropy-gathering in the interrupt-routines,
> have some simplistic routine (like x'=(x * m + a) % p) which returns a non-
> cry
This is a fix for a potential deadlock in autofs4's expire routine.
It tries to use dput() while holding the dcache_lock. This isn't a
problem in principle since dput() should only try to take the dcache_lock
when the counter makes a transition to zero, which can't happen in
this case. Unfortuna
On Fri, Apr 20, 2001 at 05:00:04AM -0400, Alexander Viro wrote:
> Frankly, I'd rather add dput_locked() in dcache.c. The bug is real and
> since autofs4 is not the only place like that... I'll look into that
> stuff.
Sounds fine.
J
-
To unsubscribe from this list: send the line "unsubscr
On Fri, Apr 20, 2001 at 10:59:43PM -0700, Linus Torvalds wrote:
> It's untested, but looks fairly obvious. It removes the increment, and
> changes autofs4_expire() to properly bump the count of the returned dentry
> (and callers will dput() it when done). This may be unnecessarily careful,
> but i
On Sat, Apr 21, 2001 at 02:21:38AM -0400, Alexander Viro wrote:
> Looks sane for me. However, I would add check for dentry being hashed and
> would skip the unhashed ones. Otherwise you can get a directory that
> had been removed but is still busy - doesn't look like a right thing to
> do. Jeremy?
On Fri, Apr 20, 2001 at 03:53:45PM -0400, Alexander Viro wrote:
> > Why are we doing the mntget/dget at all? We hold the spinlock, so we know
> > they are not going away. Not doing the mntget/dget means that we (a) run
> > faster and (b) don't have the bug, because we don't need to put the damn
>
On Fri, Oct 20, 2000 at 03:16:14PM -0400, safemode wrote:
> That's what i was thinking, but 30MB/s seems to be quite an exaggeration.
I reliably get 30MB/s with my IBM 30G 7200rpm ATA66 drive, using a
Via VT82C586 controller. 2.4.0-test9. Modern drives are really fast.
J
-
To unsubscri
S: Germany
N: Jeremy Fitzhardinge
-E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
+W: http://www.goop.org/~jeremy
+D: author of userfs filesystem
D: Improved mmap and munmap handling
D: General mm minor tidyups
-S: 67 Surrey St.
-S: Darlinghurst, Sydney
-S: New South Wales 2010
-S: Australia
+D:
On Fri, Oct 20, 2000 at 01:22:59PM -0700, Andre Hedrick wrote:
> On Fri, 20 Oct 2000 [EMAIL PROTECTED] wrote:
>
> > [EMAIL PROTECTED] wrote..
> >
> > > I reliably get 30MB/s with my IBM 30G 7200rpm ATA66 drive, using a
> > > Via VT82C586 controller. 2.4.0-test9. Modern drives are really fast.
On Wed, Oct 18, 2000 at 04:48:48PM +0100, Stephen Tweedie wrote:
> On Tue, Oct 17, 2000 at 12:31:24AM -0400, John Kacur wrote:
> > I'm trying to understand how the proc file system works. In particular
> > I'd like to know more about the algorithm by which the information is
> > updated and how fr
On Sat, Oct 21, 2000 at 01:37:26PM -0600, Jonathan Corbet wrote:
> physical address
> An address as known by the low-level hardware. In the modern
> world, these can be 64-bit quantities, even on 32-bit systems.
> These are the addresses used by /dev/mem - which appears to work
Hi,
/proc has no way to indicate whether tasks share an address space.
This one-liner patch adds a new ASID: field to /proc//status so
there's some way to see address-space sharing between tasks.
While this is hardly a bug-fix, it is a pretty useful thing to know
which is otherwise completely ab
On Thu, Oct 26, 2000 at 03:45:27PM -0700, I wrote:
> + buffer += sprintf("ASID: %p\n", mm);
Obviously, this should be:
+ buffer += sprintf("ASID:\t%p\n", mm);
for consistency.
J
PGP signature
On Thu, Oct 26, 2000 at 07:01:26PM -0400, Johannes Erdfelt wrote:
> and even more obvious:
>
> + buffer += sprintf(buffer, "ASID:\t%p\n", mm);
>
> Actually putting it into the buffer would be useful as well :)
That serves me right for hand-editing patches.
J
--
Repeat to self: I am
On Tue, Oct 31, 2000 at 08:55:13PM +, Alan Cox wrote:
> Does autofs4 work yet
Autofs4 was fixed in 2.4.0-test10-pre6 or so. Autofs4 for 2.2.x has
been working for some time, though I just updated the 2.2 patch so it
doesn't stomp on autofs (v3).
J
PGP signature
On Thu, Oct 05, 2000 at 11:33:30AM +0200, Helge Hafting wrote:
> A power failure might leave you with a corrupt disk block. That is
> detectable (read failure) and you may then reconstruct it using the
> rest of the stripe. This will get you data from either before
> or after the update was sup
Hi,
I've been playing with user-mode linux (2.4.0-pre9). It works well on
one machine, but on my laptop I'm consistently getting stack overflows
just as init is started.
The backtrace (from a breakpoint at panic()):
(gdb) bt
#0 panic (fmt=0x10112e00 "Stack overflowed onto current_task page")
On Sun, Oct 08, 2000 at 12:35:48AM -0500, Jeff Dike wrote:
> I've been waiting for someone to send me that stack. There aren't any real
> smoking guns there. I'm guessing that the difference between your laptop and
> the machine it works on is that your laptop is running a fairly recent kernel
On Sun, Oct 08, 2000 at 11:21:01AM -0500, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > Even with this patch, the overflow is 808 bytes (without the patch
> > it's 1232 bytes).
>
> I was mulling over some other changes that would have saved another 256 bytes,
> but those don't look like they wo
On Sun, Oct 08, 2000 at 11:21:01AM -0500, Jeff Dike wrote:
> Also, could you look at the stack pointer at each frame, to see if you are
> encountering any stack hogs in the generic kernel? In a different situation,
> I found devfs putting a 3K structure on the stack.
OK, top candidates on that
I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my
Apple iSight camera, it is not detected; repeated
connections/disconnections don't help. When I tried to rmmod all the
appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the
rmmod command hung. Alt-Sysreq-t shows th
Quoting John Martin <[EMAIL PROTECTED]>:
> this patch adds a check to make sure memory was allocated, returns an
> error code otherwise.
autofs4_dentry_ino doesn't allocate memory; it just extracts the fsdata pointer
from the dentry structure. If it's returning NULL, then there's something else
1 - 100 of 1859 matches
Mail list logo
