Re: 2.6.13-rc3-mm3
On Mon, 8 Aug 2005, Richard Purdie wrote: > The following patch (against -mm) cleared the problem up but I'm not > sure how correct it is: Almost. The new entry needs to be made dirty. new_entry is already made young. entry is not. --- Set dirty bit correctly in handle_pte_fault new_entry is used for the new pte entry. handle_mm_fault must dirty new_entry and not "entry". entry is only used for comparison. The current version does not set the dirty bit. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Index: linux-2.6.13-rc4/mm/memory.c === --- linux-2.6.13-rc4.orig/mm/memory.c 2005-08-03 17:15:22.0 -0700 +++ linux-2.6.13-rc4/mm/memory.c2005-08-08 17:54:53.0 -0700 @@ -2091,7 +2091,7 @@ return do_wp_page(mm, vma, address, pte, pmd, entry); #endif } - entry = pte_mkdirty(entry); + new_entry = pte_mkdirty(new_entry); } /* - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
On Mon, Aug 08, 2005 at 10:25:59AM -0700, Andrew Morton wrote: > Dipankar Sarma <[EMAIL PROTECTED]> wrote: > > > > > But: IIRC the counters were moved to the ctor/dtor for performance > > > reasons, I'd guess mbligh ran into cache line trashing on the > > > filp_count_lock spinlock with reaim or something like that. > > > > Ah, so the whole idea was to inc/dec nr_files less often so > > that we reduce contention on filp_count_lock, right ? This however > > causes skews nr_files by the size of the slab array, AFAICS. > > Since we check nr_files before we allocate files from slab, the > > check seems inaccurate. > > > > Anyway, I guess, I need to look at scaling the file counting > > first. > > Something like vm_acct_memory() or percpu_counter would suit. Yes, that is what I am doing, except that because of the sysctl stuff, I now have to wallow myself in /proc code. Thanks Dipankar - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
I've done a bit of analysis: cmpxchg fail fault mm=c3945b20 vma=c304ad84 addr=402cb000 write=2048 ptep=c2af5b2c pmd=c2bc5008 entry=886c0f7 new=886c077 current=886c077 Note the Dirty bit is set on entry and not new where it probably should be... ptep_cmpxchg(mm, address, pte, entry, new_entry) This will compare "current"(886c077) with "entry"(886c0f7) which are not equal and the whole thing therefore correctly fails leading to the loop. The following patch (against -mm) cleared the problem up but I'm not sure how correct it is: Index: linux-2.6.12/mm/memory.c === --- linux-2.6.12.orig/mm/memory.c 2005-08-08 23:03:45.0 +0100 +++ linux-2.6.12/mm/memory.c2005-08-08 23:04:02.0 +0100 @@ -2046,7 +2046,7 @@ return do_wp_page(mm, vma, address, pte, pmd, entry); #endif } - entry = pte_mkdirty(entry); + new_entry = pte_mkdirty(entry); } /* - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-08 at 09:48 -0700, Christoph Lameter wrote: > Ok. So we cannot set the dirty bit. > > Here is a patch that also prints the pte status immediately before > ptep_cmpxchg. I guess this will show that dirty bit is already set. > > Does the ARM have some hardware capability to set dirty bits? > > + printk(KERN_CRIT "cmpxchg fail fault mm=%p vma=%p addr=%lx > write=%d ptep=%p pmd=%p entry=%lx new=%lx current=%lx\n", > + mm, vma, address, write_access, pte, pmd, > pte_val(entry), pte_val(new_entry), *pte); Ok, this results in: cmpxchg fail fault mm=c39fc4e0 vma=c2a37bcc addr=4025f000 write=2048 ptep=c2fc197c pmd=c2b91008 entry=88000f7 new=8800077 current=8800077 I'm beginning to understand this code a bit more so I'll see if I can work out anything myself as well... Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
Dipankar Sarma <[EMAIL PROTECTED]> wrote: > > On Mon, Aug 08, 2005 at 06:31:52PM +0200, Manfred Spraul wrote: > > Dipankar Sarma wrote: > > > > >Hugh, could you please try this with the experimental patch below ? > > >Manfred, is it safe to decrement nr_files in file_free() > > >instead of the destructor ? I can't see any problem. > > > > > > > > > > > The ctor/dtor are only called when new objects are created, not on every > > kmem_cache_alloc/kmem_cache_free. Thus I would expect that the counter > > becomes negative on builds without CONFIG_DEBUG_SLAB. > > Thus increase in the ctor and decrease in file_free() is the wrong > > thing. If you want to move the decrease from the dtor to file_free, then > > you must move the increase, too. > > But: IIRC the counters were moved to the ctor/dtor for performance > > reasons, I'd guess mbligh ran into cache line trashing on the > > filp_count_lock spinlock with reaim or something like that. > > Ah, so the whole idea was to inc/dec nr_files less often so > that we reduce contention on filp_count_lock, right ? This however > causes skews nr_files by the size of the slab array, AFAICS. > Since we check nr_files before we allocate files from slab, the > check seems inaccurate. > > Anyway, I guess, I need to look at scaling the file counting > first. Something like vm_acct_memory() or percpu_counter would suit. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 8 Aug 2005, Russell King wrote: > ARM doesn't have cmpxchg nor does it have hardware access nor dirty > bits. They're simulated in software. Even the cmpxchg is simulated. > What's the problem you're trying to solve? A hang when starting X on ARM with rc4-mm1 which contains the page fault patches. But I have no access to the platform. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, Aug 08, 2005 at 09:48:22AM -0700, Christoph Lameter wrote: > On Sun, 7 Aug 2005, Richard Purdie wrote: > > > > > We know the the failure case can be identified by the > > > > cmpxchg_fail_flag_update condition being met. Can you provide me with a > > > > patch to dump useful debugging information when that occurs? > > > > Ok, this results in an infinite loop of one message with no change to > > the numbers: > > > > cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048 > > ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077 > > Ok. So we cannot set the dirty bit. > > Here is a patch that also prints the pte status immediately before > ptep_cmpxchg. I guess this will show that dirty bit is already set. > > Does the ARM have some hardware capability to set dirty bits? ARM doesn't have cmpxchg nor does it have hardware access nor dirty bits. They're simulated in software. What's the problem you're trying to solve? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
On Mon, Aug 08, 2005 at 06:31:52PM +0200, Manfred Spraul wrote: > Dipankar Sarma wrote: > > >Hugh, could you please try this with the experimental patch below ? > >Manfred, is it safe to decrement nr_files in file_free() > >instead of the destructor ? I can't see any problem. > > > > > > > The ctor/dtor are only called when new objects are created, not on every > kmem_cache_alloc/kmem_cache_free. Thus I would expect that the counter > becomes negative on builds without CONFIG_DEBUG_SLAB. > Thus increase in the ctor and decrease in file_free() is the wrong > thing. If you want to move the decrease from the dtor to file_free, then > you must move the increase, too. > But: IIRC the counters were moved to the ctor/dtor for performance > reasons, I'd guess mbligh ran into cache line trashing on the > filp_count_lock spinlock with reaim or something like that. Ah, so the whole idea was to inc/dec nr_files less often so that we reduce contention on filp_count_lock, right ? This however causes skews nr_files by the size of the slab array, AFAICS. Since we check nr_files before we allocate files from slab, the check seems inaccurate. Anyway, I guess, I need to look at scaling the file counting first. Thanks Dipankar - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Sun, 7 Aug 2005, Richard Purdie wrote:
> > > We know the the failure case can be identified by the
> > > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > > patch to dump useful debugging information when that occurs?
>
> Ok, this results in an infinite loop of one message with no change to
> the numbers:
>
> cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048
> ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077
Ok. So we cannot set the dirty bit.
Here is a patch that also prints the pte status immediately before
ptep_cmpxchg. I guess this will show that dirty bit is already set.
Does the ARM have some hardware capability to set dirty bits?
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-05 08:38:10.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-08 09:46:12.0 -0700
@@ -2104,6 +2104,8 @@
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
} else {
+ printk(KERN_CRIT "cmpxchg fail fault mm=%p vma=%p addr=%lx
write=%d ptep=%p pmd=%p entry=%lx new=%lx current=%lx\n",
+ mm, vma, address, write_access, pte, pmd,
pte_val(entry), pte_val(new_entry), *pte);
inc_page_state(cmpxchg_fail_flag_update);
}
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
Dipankar Sarma wrote: Hugh, could you please try this with the experimental patch below ? Manfred, is it safe to decrement nr_files in file_free() instead of the destructor ? I can't see any problem. The ctor/dtor are only called when new objects are created, not on every kmem_cache_alloc/kmem_cache_free. Thus I would expect that the counter becomes negative on builds without CONFIG_DEBUG_SLAB. Thus increase in the ctor and decrease in file_free() is the wrong thing. If you want to move the decrease from the dtor to file_free, then you must move the increase, too. But: IIRC the counters were moved to the ctor/dtor for performance reasons, I'd guess mbligh ran into cache line trashing on the filp_count_lock spinlock with reaim or something like that. -- Manfred - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
On Mon, 8 Aug 2005, Dipankar Sarma wrote: > On Wed, Aug 03, 2005 at 09:56:44AM +1000, Andrew Morton forwarded from Hugh: > > > > Subject: two 2.6.13-rc3-mm3 oddities > > > > One time my tmpfs-and-looped-tmpfs-kernel-builds collapsed with lots of > > VFS: file-max limit 49778 reached > > messages, which I imagine was a side-effect of the struct file RCU > > patches you've dropped from -rc4-mm1, perhaps a grace period problem. > > Hugh, could you please try this with the experimental patch below ? I'll give it a go. But first I ought to try to reproduce the problem more easily - it happened after about two hours of a test which had run for two or more hours (before hitting the apparently unrelated problem) at least twice each on at least two machines. So until I can reproduce the problem more easily, it'll take some while to have confidence that your patch addresses it. Therefore worth a little effort at my end to cut it down (and if I can't cut it down, I may have to solve the odder locked page issue to get the original test to run long enough to hit the file-max problem with any likelihood). > Hugh, can you mail me the exact test you run ? I would like to run > it myself and see if I can reproduce it. It'll waste less of both our time if I at least try to reproduce it more quickly first. Hold on... Hugh - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
I am ccing this to linux-kernel for a wider audience.
On Wed, Aug 03, 2005 at 09:56:44AM +1000, Andrew Morton wrote:
>
> Subject: two 2.6.13-rc3-mm3 oddities
>
> Just wanted to record a couple of oddities I noticed with 2.6.13-rc3-mm3
> (maybe there before: I hardly tested -mm1 and didn't even download -mm2),
> which have gone away in 2.6.13-rc4-mm1 - so of no great importance, but
> perhaps worth noting in case they resurface later.
>
> One time my tmpfs-and-looped-tmpfs-kernel-builds collapsed with lots of
> VFS: file-max limit 49778 reached
> messages, which I imagine was a side-effect of the struct file RCU
> patches you've dropped from -rc4-mm1, perhaps a grace period problem.
Hugh, could you please try this with the experimental patch below ?
Manfred, is it safe to decrement nr_files in file_free()
instead of the destructor ? I can't see any problem.
>
> And repeatably (after a couple of hours or so), on both i386 and x86_64,
> those tests hung waiting on page locks, as if there was a missing
> unlock_page (or a spurious SetPageLocked) somewhere. I didn't have
> time to do any bisection, but studying source diffs showed no likely
> candidates whatsoever (I did wonder about Nick's __ClearPageDirty,
> but reproduced the problem with that backed out). As I say, gone
> away (same tests on -rc4-mm1 have run two days), but curious.
Hugh, can you mail me the exact test you run ? I would like to run
it myself and see if I can reproduce it.
Thanks
Dipankar
nr_files need to decremented before the file structure is handed
over to RCU.
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
---
fs/file_table.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff -puN fs/file_table.c~files-fix-nr-files fs/file_table.c
--- linux-2.6.13-rc3-mm3-fixes/fs/file_table.c~files-fix-nr-files
2005-08-08 18:28:12.0 +0530
+++ linux-2.6.13-rc3-mm3-fixes-dipankar/fs/file_table.c 2005-08-08
18:32:31.0 +0530
@@ -48,10 +48,6 @@ void filp_ctor(void * objp, struct kmem_
void filp_dtor(void * objp, struct kmem_cache_s *cachep, unsigned long dflags)
{
- unsigned long flags;
- spin_lock_irqsave(_count_lock, flags);
- files_stat.nr_files--;
- spin_unlock_irqrestore(_count_lock, flags);
}
static inline void file_free_rcu(struct rcu_head *head)
@@ -62,6 +58,10 @@ static inline void file_free_rcu(struct
static inline void file_free(struct file *f)
{
+ unsigned long flags;
+ spin_lock_irqsave(_count_lock, flags);
+ files_stat.nr_files--;
+ spin_unlock_irqrestore(_count_lock, flags);
call_rcu(>f_rcuhead, file_free_rcu);
}
_
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
I am ccing this to linux-kernel for a wider audience.
On Wed, Aug 03, 2005 at 09:56:44AM +1000, Andrew Morton wrote:
Subject: two 2.6.13-rc3-mm3 oddities
Just wanted to record a couple of oddities I noticed with 2.6.13-rc3-mm3
(maybe there before: I hardly tested -mm1 and didn't even download -mm2),
which have gone away in 2.6.13-rc4-mm1 - so of no great importance, but
perhaps worth noting in case they resurface later.
One time my tmpfs-and-looped-tmpfs-kernel-builds collapsed with lots of
VFS: file-max limit 49778 reached
messages, which I imagine was a side-effect of the struct file RCU
patches you've dropped from -rc4-mm1, perhaps a grace period problem.
Hugh, could you please try this with the experimental patch below ?
Manfred, is it safe to decrement nr_files in file_free()
instead of the destructor ? I can't see any problem.
And repeatably (after a couple of hours or so), on both i386 and x86_64,
those tests hung waiting on page locks, as if there was a missing
unlock_page (or a spurious SetPageLocked) somewhere. I didn't have
time to do any bisection, but studying source diffs showed no likely
candidates whatsoever (I did wonder about Nick's __ClearPageDirty,
but reproduced the problem with that backed out). As I say, gone
away (same tests on -rc4-mm1 have run two days), but curious.
Hugh, can you mail me the exact test you run ? I would like to run
it myself and see if I can reproduce it.
Thanks
Dipankar
nr_files need to decremented before the file structure is handed
over to RCU.
Signed-off-by: Dipankar Sarma [EMAIL PROTECTED]
---
fs/file_table.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff -puN fs/file_table.c~files-fix-nr-files fs/file_table.c
--- linux-2.6.13-rc3-mm3-fixes/fs/file_table.c~files-fix-nr-files
2005-08-08 18:28:12.0 +0530
+++ linux-2.6.13-rc3-mm3-fixes-dipankar/fs/file_table.c 2005-08-08
18:32:31.0 +0530
@@ -48,10 +48,6 @@ void filp_ctor(void * objp, struct kmem_
void filp_dtor(void * objp, struct kmem_cache_s *cachep, unsigned long dflags)
{
- unsigned long flags;
- spin_lock_irqsave(filp_count_lock, flags);
- files_stat.nr_files--;
- spin_unlock_irqrestore(filp_count_lock, flags);
}
static inline void file_free_rcu(struct rcu_head *head)
@@ -62,6 +58,10 @@ static inline void file_free_rcu(struct
static inline void file_free(struct file *f)
{
+ unsigned long flags;
+ spin_lock_irqsave(filp_count_lock, flags);
+ files_stat.nr_files--;
+ spin_unlock_irqrestore(filp_count_lock, flags);
call_rcu(f-f_rcuhead, file_free_rcu);
}
_
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
On Mon, 8 Aug 2005, Dipankar Sarma wrote: On Wed, Aug 03, 2005 at 09:56:44AM +1000, Andrew Morton forwarded from Hugh: Subject: two 2.6.13-rc3-mm3 oddities One time my tmpfs-and-looped-tmpfs-kernel-builds collapsed with lots of VFS: file-max limit 49778 reached messages, which I imagine was a side-effect of the struct file RCU patches you've dropped from -rc4-mm1, perhaps a grace period problem. Hugh, could you please try this with the experimental patch below ? I'll give it a go. But first I ought to try to reproduce the problem more easily - it happened after about two hours of a test which had run for two or more hours (before hitting the apparently unrelated problem) at least twice each on at least two machines. So until I can reproduce the problem more easily, it'll take some while to have confidence that your patch addresses it. Therefore worth a little effort at my end to cut it down (and if I can't cut it down, I may have to solve the odder locked page issue to get the original test to run long enough to hit the file-max problem with any likelihood). Hugh, can you mail me the exact test you run ? I would like to run it myself and see if I can reproduce it. It'll waste less of both our time if I at least try to reproduce it more quickly first. Hold on... Hugh - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
Dipankar Sarma wrote: Hugh, could you please try this with the experimental patch below ? Manfred, is it safe to decrement nr_files in file_free() instead of the destructor ? I can't see any problem. The ctor/dtor are only called when new objects are created, not on every kmem_cache_alloc/kmem_cache_free. Thus I would expect that the counter becomes negative on builds without CONFIG_DEBUG_SLAB. Thus increase in the ctor and decrease in file_free() is the wrong thing. If you want to move the decrease from the dtor to file_free, then you must move the increase, too. But: IIRC the counters were moved to the ctor/dtor for performance reasons, I'd guess mbligh ran into cache line trashing on the filp_count_lock spinlock with reaim or something like that. -- Manfred - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Sun, 7 Aug 2005, Richard Purdie wrote:
We know the the failure case can be identified by the
cmpxchg_fail_flag_update condition being met. Can you provide me with a
patch to dump useful debugging information when that occurs?
Ok, this results in an infinite loop of one message with no change to
the numbers:
cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048
ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077
Ok. So we cannot set the dirty bit.
Here is a patch that also prints the pte status immediately before
ptep_cmpxchg. I guess this will show that dirty bit is already set.
Does the ARM have some hardware capability to set dirty bits?
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-05 08:38:10.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-08 09:46:12.0 -0700
@@ -2104,6 +2104,8 @@
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
} else {
+ printk(KERN_CRIT cmpxchg fail fault mm=%p vma=%p addr=%lx
write=%d ptep=%p pmd=%p entry=%lx new=%lx current=%lx\n,
+ mm, vma, address, write_access, pte, pmd,
pte_val(entry), pte_val(new_entry), *pte);
inc_page_state(cmpxchg_fail_flag_update);
}
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
On Mon, Aug 08, 2005 at 06:31:52PM +0200, Manfred Spraul wrote: Dipankar Sarma wrote: Hugh, could you please try this with the experimental patch below ? Manfred, is it safe to decrement nr_files in file_free() instead of the destructor ? I can't see any problem. The ctor/dtor are only called when new objects are created, not on every kmem_cache_alloc/kmem_cache_free. Thus I would expect that the counter becomes negative on builds without CONFIG_DEBUG_SLAB. Thus increase in the ctor and decrease in file_free() is the wrong thing. If you want to move the decrease from the dtor to file_free, then you must move the increase, too. But: IIRC the counters were moved to the ctor/dtor for performance reasons, I'd guess mbligh ran into cache line trashing on the filp_count_lock spinlock with reaim or something like that. Ah, so the whole idea was to inc/dec nr_files less often so that we reduce contention on filp_count_lock, right ? This however causes skews nr_files by the size of the slab array, AFAICS. Since we check nr_files before we allocate files from slab, the check seems inaccurate. Anyway, I guess, I need to look at scaling the file counting first. Thanks Dipankar - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, Aug 08, 2005 at 09:48:22AM -0700, Christoph Lameter wrote: On Sun, 7 Aug 2005, Richard Purdie wrote: We know the the failure case can be identified by the cmpxchg_fail_flag_update condition being met. Can you provide me with a patch to dump useful debugging information when that occurs? Ok, this results in an infinite loop of one message with no change to the numbers: cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048 ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077 Ok. So we cannot set the dirty bit. Here is a patch that also prints the pte status immediately before ptep_cmpxchg. I guess this will show that dirty bit is already set. Does the ARM have some hardware capability to set dirty bits? ARM doesn't have cmpxchg nor does it have hardware access nor dirty bits. They're simulated in software. What's the problem you're trying to solve? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 8 Aug 2005, Russell King wrote: ARM doesn't have cmpxchg nor does it have hardware access nor dirty bits. They're simulated in software. Even the cmpxchg is simulated. What's the problem you're trying to solve? A hang when starting X on ARM with rc4-mm1 which contains the page fault patches. But I have no access to the platform. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
Dipankar Sarma [EMAIL PROTECTED] wrote: On Mon, Aug 08, 2005 at 06:31:52PM +0200, Manfred Spraul wrote: Dipankar Sarma wrote: Hugh, could you please try this with the experimental patch below ? Manfred, is it safe to decrement nr_files in file_free() instead of the destructor ? I can't see any problem. The ctor/dtor are only called when new objects are created, not on every kmem_cache_alloc/kmem_cache_free. Thus I would expect that the counter becomes negative on builds without CONFIG_DEBUG_SLAB. Thus increase in the ctor and decrease in file_free() is the wrong thing. If you want to move the decrease from the dtor to file_free, then you must move the increase, too. But: IIRC the counters were moved to the ctor/dtor for performance reasons, I'd guess mbligh ran into cache line trashing on the filp_count_lock spinlock with reaim or something like that. Ah, so the whole idea was to inc/dec nr_files less often so that we reduce contention on filp_count_lock, right ? This however causes skews nr_files by the size of the slab array, AFAICS. Since we check nr_files before we allocate files from slab, the check seems inaccurate. Anyway, I guess, I need to look at scaling the file counting first. Something like vm_acct_memory() or percpu_counter would suit. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-08 at 09:48 -0700, Christoph Lameter wrote: Ok. So we cannot set the dirty bit. Here is a patch that also prints the pte status immediately before ptep_cmpxchg. I guess this will show that dirty bit is already set. Does the ARM have some hardware capability to set dirty bits? + printk(KERN_CRIT cmpxchg fail fault mm=%p vma=%p addr=%lx write=%d ptep=%p pmd=%p entry=%lx new=%lx current=%lx\n, + mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry), *pte); Ok, this results in: cmpxchg fail fault mm=c39fc4e0 vma=c2a37bcc addr=4025f000 write=2048 ptep=c2fc197c pmd=c2b91008 entry=88000f7 new=8800077 current=8800077 I'm beginning to understand this code a bit more so I'll see if I can work out anything myself as well... Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
I've done a bit of analysis: cmpxchg fail fault mm=c3945b20 vma=c304ad84 addr=402cb000 write=2048 ptep=c2af5b2c pmd=c2bc5008 entry=886c0f7 new=886c077 current=886c077 Note the Dirty bit is set on entry and not new where it probably should be... ptep_cmpxchg(mm, address, pte, entry, new_entry) This will compare current(886c077) with entry(886c0f7) which are not equal and the whole thing therefore correctly fails leading to the loop. The following patch (against -mm) cleared the problem up but I'm not sure how correct it is: Index: linux-2.6.12/mm/memory.c === --- linux-2.6.12.orig/mm/memory.c 2005-08-08 23:03:45.0 +0100 +++ linux-2.6.12/mm/memory.c2005-08-08 23:04:02.0 +0100 @@ -2046,7 +2046,7 @@ return do_wp_page(mm, vma, address, pte, pmd, entry); #endif } - entry = pte_mkdirty(entry); + new_entry = pte_mkdirty(entry); } /* - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: two 2.6.13-rc3-mm3 oddities
On Mon, Aug 08, 2005 at 10:25:59AM -0700, Andrew Morton wrote: Dipankar Sarma [EMAIL PROTECTED] wrote: But: IIRC the counters were moved to the ctor/dtor for performance reasons, I'd guess mbligh ran into cache line trashing on the filp_count_lock spinlock with reaim or something like that. Ah, so the whole idea was to inc/dec nr_files less often so that we reduce contention on filp_count_lock, right ? This however causes skews nr_files by the size of the slab array, AFAICS. Since we check nr_files before we allocate files from slab, the check seems inaccurate. Anyway, I guess, I need to look at scaling the file counting first. Something like vm_acct_memory() or percpu_counter would suit. Yes, that is what I am doing, except that because of the sysctl stuff, I now have to wallow myself in /proc code. Thanks Dipankar - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 8 Aug 2005, Richard Purdie wrote: The following patch (against -mm) cleared the problem up but I'm not sure how correct it is: Almost. The new entry needs to be made dirty. new_entry is already made young. entry is not. --- Set dirty bit correctly in handle_pte_fault new_entry is used for the new pte entry. handle_mm_fault must dirty new_entry and not entry. entry is only used for comparison. The current version does not set the dirty bit. Signed-off-by: Christoph Lameter [EMAIL PROTECTED] Index: linux-2.6.13-rc4/mm/memory.c === --- linux-2.6.13-rc4.orig/mm/memory.c 2005-08-03 17:15:22.0 -0700 +++ linux-2.6.13-rc4/mm/memory.c2005-08-08 17:54:53.0 -0700 @@ -2091,7 +2091,7 @@ return do_wp_page(mm, vma, address, pte, pmd, entry); #endif } - entry = pte_mkdirty(entry); + new_entry = pte_mkdirty(new_entry); } /* - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
--"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005 21:21:30 -0700): > --"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005 > 18:17:33 -0700): >> --Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, July 28, 2005 >> 23:10:29 -0700): >> >>> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we identified earlier with the sched patches ... http://test.kernel.org/9398/debug/console.log >>> >>> Oh, thanks. That's about 8,349 bugs ago and I'd forgotten. >>> Works with mainline still (including -rc4) ... hopefully those patches aren't on their way upstream anytime soon ;-) >>> >>> Well can you identify the offending patch(es)? If so, I'll exterminate >>> them. >> >> scheduler-cache-hot-autodetect.patch, I think. >> >> will double-check. > > Yup, backing out that one patch definitely fixes it. There was an earlier > thread with Ingo about doing some possible debug on it, but to be honest, > I haven't had time to play much beyond the initial ideas we tried. Still broken in 2.6.13-rc5-mm1, any chance you could back this one out until it gets fixed? that way I can still test with that platform (plus it'll stop it from getting accidentally merged ;-)) Thanks, M. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Fri, 2005-08-05 at 08:17 -0700, Christoph Lameter wrote: > On Thu, 4 Aug 2005, Richard Purdie wrote: > > > > We know the the failure case can be identified by the > > cmpxchg_fail_flag_update condition being met. Can you provide me with a > > patch to dump useful debugging information when that occurs? > > Well yes simply print out the information available in that context. > > + printk(KERN_CRIT "cmpxchg fail mm=%p vma=%p addr=%lx write=%d > ptep=%p pmd=%p entry=%lx new=%lx\n", > + mm, vma, address, write_access, pte, pmd, > pte_val(entry), pte_val(new_entry)); Ok, this results in an infinite loop of one message with no change to the numbers: cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048 ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077 Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Fri, 2005-08-05 at 08:17 -0700, Christoph Lameter wrote: On Thu, 4 Aug 2005, Richard Purdie wrote: We know the the failure case can be identified by the cmpxchg_fail_flag_update condition being met. Can you provide me with a patch to dump useful debugging information when that occurs? Well yes simply print out the information available in that context. + printk(KERN_CRIT cmpxchg fail mm=%p vma=%p addr=%lx write=%d ptep=%p pmd=%p entry=%lx new=%lx\n, + mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry)); Ok, this results in an infinite loop of one message with no change to the numbers: cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048 ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077 Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
--Martin J. Bligh [EMAIL PROTECTED] wrote (on Tuesday, August 02, 2005 21:21:30 -0700): --Martin J. Bligh [EMAIL PROTECTED] wrote (on Tuesday, August 02, 2005 18:17:33 -0700): --Andrew Morton [EMAIL PROTECTED] wrote (on Thursday, July 28, 2005 23:10:29 -0700): Martin J. Bligh [EMAIL PROTECTED] wrote: NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we identified earlier with the sched patches ... http://test.kernel.org/9398/debug/console.log Oh, thanks. That's about 8,349 bugs ago and I'd forgotten. Works with mainline still (including -rc4) ... hopefully those patches aren't on their way upstream anytime soon ;-) Well can you identify the offending patch(es)? If so, I'll exterminate them. scheduler-cache-hot-autodetect.patch, I think. will double-check. Yup, backing out that one patch definitely fixes it. There was an earlier thread with Ingo about doing some possible debug on it, but to be honest, I haven't had time to play much beyond the initial ideas we tried. Still broken in 2.6.13-rc5-mm1, any chance you could back this one out until it gets fixed? that way I can still test with that platform (plus it'll stop it from getting accidentally merged ;-)) Thanks, M. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Thu, 4 Aug 2005, Richard Purdie wrote:
> I'm at a disadvantage here as the linux mm system is one area I've
> avoided getting too deeply involved with so far. My knowledge is
> therefore limited and I won't know what correct or incorrect behaviour
> would look like.
>
> We know the the failure case can be identified by the
> cmpxchg_fail_flag_update condition being met. Can you provide me with a
> patch to dump useful debugging information when that occurs?
Well yes simply print out the information available in that context.
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-03 17:02:29.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-05 08:17:14.0 -0700
@@ -2104,6 +2104,8 @@
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
} else {
+ printk(KERN_CRIT "cmpxchg fail mm=%p vma=%p addr=%lx write=%d
ptep=%p pmd=%p entry=%lx new=%lx\n",
+ mm, vma, address, write_access, pte, pmd,
pte_val(entry), pte_val(new_entry));
inc_page_state(cmpxchg_fail_flag_update);
}
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.13-rc3-mm3
Hello Andrew, Andrew Morton wrote: Michael, I'm assuming that a) this problem remains in those -mm kernels which include git-acpi.patch and that b) the problems are not present in 2.6.13-rc5 or 2.6.13-rc6, yes? a.) I don't have any problems in 2.6.13-rc5-git[1-3] and 2.6.13-rc4-mm1 they are working quite fantastic. Good work :-) So I think we have a bug in git-acpi.patch? I reverted them and left them in..no problems with kernels I said above. Again good work :-) If that's all correct then can you please test the next -mm (which will include git-acpi.patch - the most recent -mm did not) and if the bug's still there can you raise a bugzilla.kernel.org entry for it? I would, but the motherboard is dropped from my hardware test approval. Maybe I can get it back to test again if it helps to solve some acpi issues. We seem to have a handful of bug reports against the -mm acpi patch. Well, I noticed that there are a lots of bugs and I'm willing to find search and reproduce them. Thanks. I have to say thanks for the great help/feedback. Greets and Best regards -- _Michael Thonke IT-Systemintegrator / System- and Softwareanalyist - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.13-rc3-mm3
Hello Andrew, Andrew Morton wrote: Michael, I'm assuming that a) this problem remains in those -mm kernels which include git-acpi.patch and that b) the problems are not present in 2.6.13-rc5 or 2.6.13-rc6, yes? a.) I don't have any problems in 2.6.13-rc5-git[1-3] and 2.6.13-rc4-mm1 they are working quite fantastic. Good work :-) So I think we have a bug in git-acpi.patch? I reverted them and left them in..no problems with kernels I said above. Again good work :-) If that's all correct then can you please test the next -mm (which will include git-acpi.patch - the most recent -mm did not) and if the bug's still there can you raise a bugzilla.kernel.org entry for it? I would, but the motherboard is dropped from my hardware test approval. Maybe I can get it back to test again if it helps to solve some acpi issues. We seem to have a handful of bug reports against the -mm acpi patch. Well, I noticed that there are a lots of bugs and I'm willing to find search and reproduce them. Thanks. I have to say thanks for the great help/feedback. Greets and Best regards -- _Michael Thonke IT-Systemintegrator / System- and Softwareanalyist - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Thu, 4 Aug 2005, Richard Purdie wrote:
I'm at a disadvantage here as the linux mm system is one area I've
avoided getting too deeply involved with so far. My knowledge is
therefore limited and I won't know what correct or incorrect behaviour
would look like.
We know the the failure case can be identified by the
cmpxchg_fail_flag_update condition being met. Can you provide me with a
patch to dump useful debugging information when that occurs?
Well yes simply print out the information available in that context.
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-03 17:02:29.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-05 08:17:14.0 -0700
@@ -2104,6 +2104,8 @@
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
} else {
+ printk(KERN_CRIT cmpxchg fail mm=%p vma=%p addr=%lx write=%d
ptep=%p pmd=%p entry=%lx new=%lx\n,
+ mm, vma, address, write_access, pte, pmd,
pte_val(entry), pte_val(new_entry));
inc_page_state(cmpxchg_fail_flag_update);
}
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.13-rc3-mm3
Michael Thonke <[EMAIL PROTECTED]> wrote: > > Moore, Robert schrieb: > > >+ACPI-0287: *** Error: Region SystemMemory(0) has no handler > >+ACPI-0127: *** Error: acpi_load_tables: Could not load namespace: > >AE_NOT_EXIST > >+ACPI-0136: *** Error: acpi_load_tables: Could not load tables: > > > >This looks like a nasty case where some executable code in the table is > >attempting to access a SystemMemory operation region before any OpRegion > >handlers are initialized. > > > >We certainly want to see the output of acpidump to attempt to diagnose > >and/or reproduce the problem. > > > >Bob > > > > > > > > > Sorry for double post. > > With this mail I hand over the acpidump output with the pmtools > Andrew pointed me to. > > And a dmesg output with CONFIG_KALLSYMS=y. > > > I attached them in bz2 format, because of the length. > > I hope we find the problem. > Michael, I'm assuming that a) this problem remains in those -mm kernels which include git-acpi.patch and that b) the problems are not present in 2.6.13-rc5 or 2.6.13-rc6, yes? So I think we have a bug in git-acpi.patch? If that's all correct then can you please test the next -mm (which will include git-acpi.patch - the most recent -mm did not) and if the bug's still there can you raise a bugzilla.kernel.org entry for it? We seem to have a handful of bug reports against the -mm acpi patch. Thanks. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Thu, 2005-08-04 at 07:04 -0700, Christoph Lameter wrote: > On Thu, 4 Aug 2005, Richard Purdie wrote: > > > On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote: > > > Could you try the following patch? I think the problem was that higher > > > addressses were not mappable via the page fault handler. This patch > > > inserts the pmd entry into the pgd as necessary if the pud level is > > > folded. > > > > I tried this patch against 2.6.13-rc4-mm1 and there was no change - X > > still hung in memcpy as before and the cmpxchg_fail_flag_update just > > increases... > > Is there some way you can give us more information about the problem? > Something that would allow us to determine where the thing is looping? I'm at a disadvantage here as the linux mm system is one area I've avoided getting too deeply involved with so far. My knowledge is therefore limited and I won't know what correct or incorrect behaviour would look like. We know the the failure case can be identified by the cmpxchg_fail_flag_update condition being met. Can you provide me with a patch to dump useful debugging information when that occurs? Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Thu, 4 Aug 2005, Richard Purdie wrote: > On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote: > > Could you try the following patch? I think the problem was that higher > > addressses were not mappable via the page fault handler. This patch > > inserts the pmd entry into the pgd as necessary if the pud level is > > folded. > > I tried this patch against 2.6.13-rc4-mm1 and there was no change - X > still hung in memcpy as before and the cmpxchg_fail_flag_update just > increases... Is there some way you can give us more information about the problem? Something that would allow us to determine where the thing is looping? - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote: > Could you try the following patch? I think the problem was that higher > addressses were not mappable via the page fault handler. This patch > inserts the pmd entry into the pgd as necessary if the pud level is > folded. I tried this patch against 2.6.13-rc4-mm1 and there was no change - X still hung in memcpy as before and the cmpxchg_fail_flag_update just increases... Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote: Could you try the following patch? I think the problem was that higher addressses were not mappable via the page fault handler. This patch inserts the pmd entry into the pgd as necessary if the pud level is folded. I tried this patch against 2.6.13-rc4-mm1 and there was no change - X still hung in memcpy as before and the cmpxchg_fail_flag_update just increases... Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Thu, 4 Aug 2005, Richard Purdie wrote: On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote: Could you try the following patch? I think the problem was that higher addressses were not mappable via the page fault handler. This patch inserts the pmd entry into the pgd as necessary if the pud level is folded. I tried this patch against 2.6.13-rc4-mm1 and there was no change - X still hung in memcpy as before and the cmpxchg_fail_flag_update just increases... Is there some way you can give us more information about the problem? Something that would allow us to determine where the thing is looping? - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Thu, 2005-08-04 at 07:04 -0700, Christoph Lameter wrote: On Thu, 4 Aug 2005, Richard Purdie wrote: On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote: Could you try the following patch? I think the problem was that higher addressses were not mappable via the page fault handler. This patch inserts the pmd entry into the pgd as necessary if the pud level is folded. I tried this patch against 2.6.13-rc4-mm1 and there was no change - X still hung in memcpy as before and the cmpxchg_fail_flag_update just increases... Is there some way you can give us more information about the problem? Something that would allow us to determine where the thing is looping? I'm at a disadvantage here as the linux mm system is one area I've avoided getting too deeply involved with so far. My knowledge is therefore limited and I won't know what correct or incorrect behaviour would look like. We know the the failure case can be identified by the cmpxchg_fail_flag_update condition being met. Can you provide me with a patch to dump useful debugging information when that occurs? Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.13-rc3-mm3
Michael Thonke [EMAIL PROTECTED] wrote: Moore, Robert schrieb: +ACPI-0287: *** Error: Region SystemMemory(0) has no handler +ACPI-0127: *** Error: acpi_load_tables: Could not load namespace: AE_NOT_EXIST +ACPI-0136: *** Error: acpi_load_tables: Could not load tables: This looks like a nasty case where some executable code in the table is attempting to access a SystemMemory operation region before any OpRegion handlers are initialized. We certainly want to see the output of acpidump to attempt to diagnose and/or reproduce the problem. Bob Sorry for double post. With this mail I hand over the acpidump output with the pmtools Andrew pointed me to. And a dmesg output with CONFIG_KALLSYMS=y. I attached them in bz2 format, because of the length. I hope we find the problem. Michael, I'm assuming that a) this problem remains in those -mm kernels which include git-acpi.patch and that b) the problems are not present in 2.6.13-rc5 or 2.6.13-rc6, yes? So I think we have a bug in git-acpi.patch? If that's all correct then can you please test the next -mm (which will include git-acpi.patch - the most recent -mm did not) and if the bug's still there can you raise a bugzilla.kernel.org entry for it? We seem to have a handful of bug reports against the -mm acpi patch. Thanks. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Could you try the following patch? I think the problem was that higher
addressses were not mappable via the page fault handler. This patch
inserts the pmd entry into the pgd as necessary if the pud level is
folded.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc4/mm/memory.c
===
--- linux-2.6.13-rc4.orig/mm/memory.c 2005-08-03 17:08:29.0 -0700
+++ linux-2.6.13-rc4/mm/memory.c2005-08-03 17:15:22.0 -0700
@@ -2144,9 +2144,16 @@
*/
page_table_atomic_start(mm);
pgd = pgd_offset(mm, address);
-#ifndef __PAGETABLE_PUD_FOLDED
if (unlikely(pgd_none(*pgd))) {
+#ifdef __PAGETABLE_PUD_FOLDED
+ /* If the pud is folded then we need to insert a pmd entry into
+* a pgd. pud_none(pgd) == 0 so the next if statement will never
+* be taken
+*/
+ pmd_t *new;
+#else
pud_t *new;
+#endif
page_table_atomic_stop(mm);
new = pud_alloc_one(mm, address);
@@ -2158,7 +2165,6 @@
if (!pgd_test_and_populate(mm, pgd, new))
pud_free(new);
}
-#endif
pud = pud_offset(pgd, address);
if (unlikely(pud_none(*pud))) {
Index: linux-2.6.13-rc4/include/asm-generic/4level-fixup.h
===
--- linux-2.6.13-rc4.orig/include/asm-generic/4level-fixup.h2005-08-03
17:06:01.0 -0700
+++ linux-2.6.13-rc4/include/asm-generic/4level-fixup.h 2005-08-03
17:09:38.0 -0700
@@ -27,6 +27,7 @@
#define pud_ERROR(pud) do { } while (0)
#define pud_clear(pud) pgd_clear(pud)
#define pud_populate pgd_populate
+#define pud_alloc_one pmd_alloc_one
#undef pud_free_tlb
#define pud_free_tlb(tlb, x)do { } while (0)
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Could you try the following patch? I think the problem was that higher
addressses were not mappable via the page fault handler. This patch
inserts the pmd entry into the pgd as necessary if the pud level is
folded.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Index: linux-2.6.13-rc4/mm/memory.c
===
--- linux-2.6.13-rc4.orig/mm/memory.c 2005-08-03 17:08:29.0 -0700
+++ linux-2.6.13-rc4/mm/memory.c2005-08-03 17:15:22.0 -0700
@@ -2144,9 +2144,16 @@
*/
page_table_atomic_start(mm);
pgd = pgd_offset(mm, address);
-#ifndef __PAGETABLE_PUD_FOLDED
if (unlikely(pgd_none(*pgd))) {
+#ifdef __PAGETABLE_PUD_FOLDED
+ /* If the pud is folded then we need to insert a pmd entry into
+* a pgd. pud_none(pgd) == 0 so the next if statement will never
+* be taken
+*/
+ pmd_t *new;
+#else
pud_t *new;
+#endif
page_table_atomic_stop(mm);
new = pud_alloc_one(mm, address);
@@ -2158,7 +2165,6 @@
if (!pgd_test_and_populate(mm, pgd, new))
pud_free(new);
}
-#endif
pud = pud_offset(pgd, address);
if (unlikely(pud_none(*pud))) {
Index: linux-2.6.13-rc4/include/asm-generic/4level-fixup.h
===
--- linux-2.6.13-rc4.orig/include/asm-generic/4level-fixup.h2005-08-03
17:06:01.0 -0700
+++ linux-2.6.13-rc4/include/asm-generic/4level-fixup.h 2005-08-03
17:09:38.0 -0700
@@ -27,6 +27,7 @@
#define pud_ERROR(pud) do { } while (0)
#define pud_clear(pud) pgd_clear(pud)
#define pud_populate pgd_populate
+#define pud_alloc_one pmd_alloc_one
#undef pud_free_tlb
#define pud_free_tlb(tlb, x)do { } while (0)
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
--"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005 18:17:33 -0700): > --Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, July 28, 2005 > 23:10:29 -0700): > >> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: >>> >>> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we >>> identified earlier with the sched patches ... >>> >>> http://test.kernel.org/9398/debug/console.log >> >> Oh, thanks. That's about 8,349 bugs ago and I'd forgotten. >> >>> Works with mainline still (including -rc4) ... hopefully those patches >>> aren't on their way upstream anytime soon ;-) >> >> Well can you identify the offending patch(es)? If so, I'll exterminate them. > > scheduler-cache-hot-autodetect.patch, I think. > > will double-check. Yup, backing out that one patch definitely fixes it. There was an earlier thread with Ingo about doing some possible debug on it, but to be honest, I haven't had time to play much beyond the initial ideas we tried. M. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
--Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, July 28, 2005 23:10:29 -0700): > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: >> >> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we >> identified earlier with the sched patches ... >> >> http://test.kernel.org/9398/debug/console.log > > Oh, thanks. That's about 8,349 bugs ago and I'd forgotten. > >> Works with mainline still (including -rc4) ... hopefully those patches >> aren't on their way upstream anytime soon ;-) > > Well can you identify the offending patch(es)? If so, I'll exterminate them. > > > scheduler-cache-hot-autodetect.patch, I think. will double-check. M. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Wed, 3 Aug 2005, Ivan Kokshaysky wrote: > > On Tue, Aug 02, 2005 at 02:21:44PM -0700, Greg KH wrote: > > Nice, care to make up a single patch with these two changes in it? > > Yep, I'll do it shortly, plus some minor additions as separate > patches. Actually, since everybody seems to like the "ignore 'min' if we have a known bus resource" patch, and it was already in my tree, I just committed it. But you don't need to split up any patches you've already prepared: I can easily just edit away the part I already committed. Linus - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 02:21:44PM -0700, Greg KH wrote: > Nice, care to make up a single patch with these two changes in it? Yep, I'll do it shortly, plus some minor additions as separate patches. Ivan. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 10:11:40AM -0700, Linus Torvalds wrote: > So I think it would be much easier to just make the change in > "pci_bus_alloc_resource()", and say that if the parent resource that we're > testing starts at some non-zero value, we just use that instead of "min" > when we call down to allocate_resource(). That gets it for MEM resources > too. Cool! I think it's the way to go. > Something like the following (also _totally_ untested, but even simpler > than yours). It basically says: if the parent resource starts at non-zero, > we use that as the starting point for allocations, otherwise the passed-in > value. Tested on alpha. Initially I was concerned a bit about architectures where resources _never_ start at zero (due to some specific bus to resource conversions), but this change is just a no-op for them. > That, together with changing PCIBIOS_MIN_IO to 0x2000 (or even 0x4000) > might be the ticket... Definitely 0x4000. Then we can get rid of PCIBIOS_MIN_CARDBUS_IO which was introduced exactly for this reason, I guess. Ivan. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Wed, Aug 03, 2005 at 01:13:37AM +0400, Ivan Kokshaysky wrote: > On Tue, Aug 02, 2005 at 10:11:40AM -0700, Linus Torvalds wrote: > > So I think it would be much easier to just make the change in > > "pci_bus_alloc_resource()", and say that if the parent resource that we're > > testing starts at some non-zero value, we just use that instead of "min" > > when we call down to allocate_resource(). That gets it for MEM resources > > too. > > Cool! I think it's the way to go. > > > Something like the following (also _totally_ untested, but even simpler > > than yours). It basically says: if the parent resource starts at non-zero, > > we use that as the starting point for allocations, otherwise the passed-in > > value. > > Tested on alpha. Initially I was concerned a bit about architectures > where resources _never_ start at zero (due to some specific bus to > resource conversions), but this change is just a no-op for them. > > > That, together with changing PCIBIOS_MIN_IO to 0x2000 (or even 0x4000) > > might be the ticket... > > Definitely 0x4000. Then we can get rid of PCIBIOS_MIN_CARDBUS_IO which > was introduced exactly for this reason, I guess. Nice, care to make up a single patch with these two changes in it? thanks, greg k-h - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, 2 Aug 2005, Ivan Kokshaysky wrote: > > Right, and this hurts the cardbus as well... > But it should be pretty easy to learn the PCI layer to allocate above > PCIBIOS_MIN_IO _only_ when we allocate on the root bus. > Something like this (completely untested)? I think you'd have to follow the "transparent" case down.. And even then you'd have the half-transparent case to worry about it. So I think it would be much easier to just make the change in "pci_bus_alloc_resource()", and say that if the parent resource that we're testing starts at some non-zero value, we just use that instead of "min" when we call down to allocate_resource(). That gets it for MEM resources too. Something like the following (also _totally_ untested, but even simpler than yours). It basically says: if the parent resource starts at non-zero, we use that as the starting point for allocations, otherwise the passed-in value. That, together with changing PCIBIOS_MIN_IO to 0x2000 (or even 0x4000) might be the ticket... Linus diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -60,7 +60,9 @@ pci_bus_alloc_resource(struct pci_bus *b continue; /* Ok, try it out.. */ - ret = allocate_resource(r, res, size, min, -1, align, + ret = allocate_resource(r, res, size, + r->start ? : min, + -1, align, alignf, alignf_data); if (ret == 0) break; - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 08:48:21AM -0700, Linus Torvalds wrote:
> The problem with this is that it only papers over the bug.
>
> I don't mind trying to allocate at higher addresses per se: we used to
> have the starting point be 0x4000 at some point, and that part is fine.
> The problem is that this also screws us if somebody has a PCI bridge with
> an IO window that is at a lower address than 0x2000 - now the PCI layer
> will refuse to try to allocate within it, and you'll replace one bug by
> another.
Right, and this hurts the cardbus as well...
But it should be pretty easy to learn the PCI layer to allocate above
PCIBIOS_MIN_IO _only_ when we allocate on the root bus.
Something like this (completely untested)?
Ivan.
--- linux/drivers/pci/setup-res.c.orig Fri Jun 17 23:48:29 2005
+++ linux/drivers/pci/setup-res.c Tue Aug 2 20:44:59 2005
@@ -113,11 +113,12 @@ int pci_assign_resource(struct pci_dev *
{
struct pci_bus *bus = dev->bus;
struct resource *res = dev->resource + resno;
- unsigned long size, min, align;
+ unsigned long size, min, align, min_io;
int ret;
+ min_io = (bus->self && !bus->self->transparent) ? 0 : PCIBIOS_MIN_IO;
size = res->end - res->start + 1;
- min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
+ min = (res->flags & IORESOURCE_IO) ? min_io : PCIBIOS_MIN_MEM;
/* The bridge resources are special, as their
size != alignment. Sizing routines return
required alignment in the "start" field. */
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, 2 Aug 2005, Ivan Kokshaysky wrote: > > Does the patch in appended message fix that? The problem with this is that it only papers over the bug. I don't mind trying to allocate at higher addresses per se: we used to have the starting point be 0x4000 at some point, and that part is fine. The problem is that this also screws us if somebody has a PCI bridge with an IO window that is at a lower address than 0x2000 - now the PCI layer will refuse to try to allocate within it, and you'll replace one bug by another. Linus - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 03:40:22PM +0400, Ivan Kokshaysky wrote: > On Tue, Aug 02, 2005 at 12:32:26PM +0200, Manuel Lauss wrote: > > Does not work on -rc4-mm1. The IO-ports pre-reserved message appears, > > though. The 2 io-regions are still located under the "CardBus #03" > > device. Re-Applying > > "revert-gregkh-pci-pci-assign-unassigned-resources.patch" makes it > > work again. > > Does the patch in appended message fix that? Indeed, it does fix it (vanilla -rc4-mm1 and your patch) Thanks! -- Manuel Lauss - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 12:32:26PM +0200, Manuel Lauss wrote: > Does not work on -rc4-mm1. The IO-ports pre-reserved message appears, > though. The 2 io-regions are still located under the "CardBus #03" > device. Re-Applying > "revert-gregkh-pci-pci-assign-unassigned-resources.patch" makes it > work again. Does the patch in appended message fix that? Ivan. - Forwarded message from Ivan Kokshaysky <[EMAIL PROTECTED]> - Date: Mon, 1 Aug 2005 11:22:45 +0400 From: Ivan Kokshaysky <[EMAIL PROTECTED]> To: Andrew Morton <[EMAIL PROTECTED]> Cc: Tero Roponen <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Mikael Pettersson <[EMAIL PROTECTED]> Subject: Re: 2.6.14-rc4: dma_timer_expiry [was 2.6.13-rc2 hangs at boot] User-Agent: Mutt/1.2.5i In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Fri, Jul 29, 2005 at 02:39:21AM -0700 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on jurassic.park.msu.ru X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Level: On Fri, Jul 29, 2005 at 02:39:21AM -0700, Andrew Morton wrote: > Tero Roponen <[EMAIL PROTECTED]> wrote: > > My original report is here: http://lkml.org/lkml/2005/7/6/174 > > I see. Ivan, do we know what's going on here? Sort of. The 4K cardbus windows are working fine for non-x86 architectures where all IO resources are usually well known and added to the resource tree properly. However, on x86 there are sometimes "hidden" system IO port ranges that aren't reported by BIOS, so the large (4K) cardbus windows overlap these ranges. Actually I don't like reducing CARDBUS_IO_SIZE to 256 bytes, because we lose an ability to handle cards with built-in p2p bridges (which require 4K for IO), plus it won't fix Sony VAIO problem. Tero and Mikael, can you try this one-liner instead? Ivan. --- 2.6.13-rc4/include/asm-i386/pci.h Sun Jul 31 14:32:09 2005 +++ linux/include/asm-i386/pci.hMon Aug 1 08:29:18 2005 @@ -18,7 +18,7 @@ extern unsigned int pcibios_assign_all_b #define pcibios_scan_all_fns(a, b) 0 extern unsigned long pci_mem_start; -#define PCIBIOS_MIN_IO 0x1000 +#define PCIBIOS_MIN_IO 0x2000 #define PCIBIOS_MIN_MEM(pci_mem_start) #define PCIBIOS_MIN_CARDBUS_IO 0x4000 - End forwarded message - - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 11:49:28AM +0200, Stelian Pop wrote: > Le lundi 01 ao??t 2005 ?? 16:37 +0200, Stelian Pop a ??crit : > > > > Also, it looks like sonypi really is pretty nasty to probe for, so it's > > > not enough to just say "oh, it's a sony VAIO, let's reserve that region". > > > Otherwise I'd just suggest adding a "dmi_check_system()" table to > > > arch/i386/pci/i386.c, at the top of "pcibios_assign_resources()", and > > > then you could just allocate things based on DMI information. > > > Since every Vaio laptop out there seems indeed to use only the first IO > > port range in the list, we can de-nastyify the probe. And if we don't > > even bother to check for Type1 vs. Type2 devices and we reserve both, > > then it may be acceptable to do the above. > > > > See the attached patch below which does just that. This has NOT been > > tested (only compile-tested), and moreover it has a high breakage > > probability in case some Vaios cannot live with the fixed ioport choice. > > > > Note that this patch will conflict with the recent Eric's one (added in > > CC:), he may want to rediff his Type3 changes in case this patch gets > > in. > > I had no feedback at all on the patch so I have no idea if this will go > in or not, but since Eric's patch was accepted into -mm I rediffed the > patch in order to ease the testing (in case someone is willing to test > it). Does not work on -rc4-mm1. The IO-ports pre-reserved message appears, though. The 2 io-regions are still located under the "CardBus #03" device. Re-Applying "revert-gregkh-pci-pci-assign-unassigned-resources.patch" makes it work again. -- Manuel Lauss - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Le lundi 01 août 2005 à 16:37 +0200, Stelian Pop a écrit :
> > Also, it looks like sonypi really is pretty nasty to probe for, so it's
> > not enough to just say "oh, it's a sony VAIO, let's reserve that region".
> > Otherwise I'd just suggest adding a "dmi_check_system()" table to
> > arch/i386/pci/i386.c, at the top of "pcibios_assign_resources()", and
> > then you could just allocate things based on DMI information.
> Since every Vaio laptop out there seems indeed to use only the first IO
> port range in the list, we can de-nastyify the probe. And if we don't
> even bother to check for Type1 vs. Type2 devices and we reserve both,
> then it may be acceptable to do the above.
>
> See the attached patch below which does just that. This has NOT been
> tested (only compile-tested), and moreover it has a high breakage
> probability in case some Vaios cannot live with the fixed ioport choice.
>
> Note that this patch will conflict with the recent Eric's one (added in
> CC:), he may want to rediff his Type3 changes in case this patch gets
> in.
I had no feedback at all on the patch so I have no idea if this will go
in or not, but since Eric's patch was accepted into -mm I rediffed the
patch in order to ease the testing (in case someone is willing to test
it).
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
arch/i386/pci/i386.c | 42 +
drivers/char/sonypi.c | 71 ++
2 files changed, 57 insertions(+), 56 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-08-02 10:21:58.0
+0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-02 10:28:26.0 +0200
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "pci.h"
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, "Sony Programable I/O Type1 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type1 IO region\n");
+
+ /* IO ports for 'type2' and 'type3' devices */
+ if (!request_region(0x1080, 0x20, "Sony Programable I/O Type2 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type2 IO region\n");
+
+ printk(KERN_INFO "Sony Vaio: pre-reserved IO ports\n");
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata sonyvaioio_dmi_table[] = {
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PCG-"),
+ },
+ },
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VGN-"),
+ },
+ },
+ { }
+};
+
static int __init pcibios_assign_resources(void)
{
struct pci_dev *dev = NULL;
int idx;
struct resource *r;
+ dmi_check_system(sonyvaioio_dmi_table);
+
for_each_pci_dev(dev) {
int class = dev->class >> 8;
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-02 10:22:18.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-02 10:27:28.0 +0200
@@ -105,7 +105,9 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_TYPE1_BASE 0x50
#define SONYPI_G10A(SONYPI_TYPE1_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
@@ -113,13 +115,18 @@
#define SONYPI_SLOB0x9c
#define SONYPI_SHIB0x9d
#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOPORT2 0x1084
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
/* type3 series specifics */
#define SONYPI_TYPE3_BASE 0x40
#define SONYPI_TYPE3_GID2 (SONYPI_TYPE3_BASE+0x48) /* 16 bits */
#define
Re: 2.6.13-rc3-mm3
Le lundi 01 août 2005 à 16:37 +0200, Stelian Pop a écrit :
Also, it looks like sonypi really is pretty nasty to probe for, so it's
not enough to just say oh, it's a sony VAIO, let's reserve that region.
Otherwise I'd just suggest adding a dmi_check_system() table to
arch/i386/pci/i386.c, at the top of pcibios_assign_resources(), and
then you could just allocate things based on DMI information.
Since every Vaio laptop out there seems indeed to use only the first IO
port range in the list, we can de-nastyify the probe. And if we don't
even bother to check for Type1 vs. Type2 devices and we reserve both,
then it may be acceptable to do the above.
See the attached patch below which does just that. This has NOT been
tested (only compile-tested), and moreover it has a high breakage
probability in case some Vaios cannot live with the fixed ioport choice.
Note that this patch will conflict with the recent Eric's one (added in
CC:), he may want to rediff his Type3 changes in case this patch gets
in.
I had no feedback at all on the patch so I have no idea if this will go
in or not, but since Eric's patch was accepted into -mm I rediffed the
patch in order to ease the testing (in case someone is willing to test
it).
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
arch/i386/pci/i386.c | 42 +
drivers/char/sonypi.c | 71 ++
2 files changed, 57 insertions(+), 56 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-08-02 10:21:58.0
+0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-02 10:28:26.0 +0200
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/ioport.h
#include linux/errno.h
+#include linux/dmi.h
#include pci.h
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, Sony Programable I/O Type1 Device))
+ printk(KERN_ERR Sony Vaio: cannot reserve Type1 IO region\n);
+
+ /* IO ports for 'type2' and 'type3' devices */
+ if (!request_region(0x1080, 0x20, Sony Programable I/O Type2 Device))
+ printk(KERN_ERR Sony Vaio: cannot reserve Type2 IO region\n);
+
+ printk(KERN_INFO Sony Vaio: pre-reserved IO ports\n);
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata sonyvaioio_dmi_table[] = {
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = Sony Vaio Laptop,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, PCG-),
+ },
+ },
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = Sony Vaio Laptop,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, VGN-),
+ },
+ },
+ { }
+};
+
static int __init pcibios_assign_resources(void)
{
struct pci_dev *dev = NULL;
int idx;
struct resource *r;
+ dmi_check_system(sonyvaioio_dmi_table);
+
for_each_pci_dev(dev) {
int class = dev-class 8;
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-02 10:22:18.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-02 10:27:28.0 +0200
@@ -105,7 +105,9 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_TYPE1_BASE 0x50
#define SONYPI_G10A(SONYPI_TYPE1_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
@@ -113,13 +115,18 @@
#define SONYPI_SLOB0x9c
#define SONYPI_SHIB0x9d
#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOPORT2 0x1084
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
/* type3 series specifics */
#define SONYPI_TYPE3_BASE 0x40
#define SONYPI_TYPE3_GID2 (SONYPI_TYPE3_BASE+0x48) /* 16 bits */
#define SONYPI_TYPE3_MISC
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 11:49:28AM +0200, Stelian Pop wrote: Le lundi 01 ao??t 2005 ?? 16:37 +0200, Stelian Pop a ??crit : Also, it looks like sonypi really is pretty nasty to probe for, so it's not enough to just say oh, it's a sony VAIO, let's reserve that region. Otherwise I'd just suggest adding a dmi_check_system() table to arch/i386/pci/i386.c, at the top of pcibios_assign_resources(), and then you could just allocate things based on DMI information. Since every Vaio laptop out there seems indeed to use only the first IO port range in the list, we can de-nastyify the probe. And if we don't even bother to check for Type1 vs. Type2 devices and we reserve both, then it may be acceptable to do the above. See the attached patch below which does just that. This has NOT been tested (only compile-tested), and moreover it has a high breakage probability in case some Vaios cannot live with the fixed ioport choice. Note that this patch will conflict with the recent Eric's one (added in CC:), he may want to rediff his Type3 changes in case this patch gets in. I had no feedback at all on the patch so I have no idea if this will go in or not, but since Eric's patch was accepted into -mm I rediffed the patch in order to ease the testing (in case someone is willing to test it). Does not work on -rc4-mm1. The IO-ports pre-reserved message appears, though. The 2 io-regions are still located under the CardBus #03 device. Re-Applying revert-gregkh-pci-pci-assign-unassigned-resources.patch makes it work again. -- Manuel Lauss - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 12:32:26PM +0200, Manuel Lauss wrote: Does not work on -rc4-mm1. The IO-ports pre-reserved message appears, though. The 2 io-regions are still located under the CardBus #03 device. Re-Applying revert-gregkh-pci-pci-assign-unassigned-resources.patch makes it work again. Does the patch in appended message fix that? Ivan. - Forwarded message from Ivan Kokshaysky [EMAIL PROTECTED] - Date: Mon, 1 Aug 2005 11:22:45 +0400 From: Ivan Kokshaysky [EMAIL PROTECTED] To: Andrew Morton [EMAIL PROTECTED] Cc: Tero Roponen [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Mikael Pettersson [EMAIL PROTECTED] Subject: Re: 2.6.14-rc4: dma_timer_expiry [was 2.6.13-rc2 hangs at boot] User-Agent: Mutt/1.2.5i In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Fri, Jul 29, 2005 at 02:39:21AM -0700 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on jurassic.park.msu.ru X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Level: On Fri, Jul 29, 2005 at 02:39:21AM -0700, Andrew Morton wrote: Tero Roponen [EMAIL PROTECTED] wrote: My original report is here: http://lkml.org/lkml/2005/7/6/174 I see. Ivan, do we know what's going on here? Sort of. The 4K cardbus windows are working fine for non-x86 architectures where all IO resources are usually well known and added to the resource tree properly. However, on x86 there are sometimes hidden system IO port ranges that aren't reported by BIOS, so the large (4K) cardbus windows overlap these ranges. Actually I don't like reducing CARDBUS_IO_SIZE to 256 bytes, because we lose an ability to handle cards with built-in p2p bridges (which require 4K for IO), plus it won't fix Sony VAIO problem. Tero and Mikael, can you try this one-liner instead? Ivan. --- 2.6.13-rc4/include/asm-i386/pci.h Sun Jul 31 14:32:09 2005 +++ linux/include/asm-i386/pci.hMon Aug 1 08:29:18 2005 @@ -18,7 +18,7 @@ extern unsigned int pcibios_assign_all_b #define pcibios_scan_all_fns(a, b) 0 extern unsigned long pci_mem_start; -#define PCIBIOS_MIN_IO 0x1000 +#define PCIBIOS_MIN_IO 0x2000 #define PCIBIOS_MIN_MEM(pci_mem_start) #define PCIBIOS_MIN_CARDBUS_IO 0x4000 - End forwarded message - - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 03:40:22PM +0400, Ivan Kokshaysky wrote: On Tue, Aug 02, 2005 at 12:32:26PM +0200, Manuel Lauss wrote: Does not work on -rc4-mm1. The IO-ports pre-reserved message appears, though. The 2 io-regions are still located under the CardBus #03 device. Re-Applying revert-gregkh-pci-pci-assign-unassigned-resources.patch makes it work again. Does the patch in appended message fix that? Indeed, it does fix it (vanilla -rc4-mm1 and your patch) Thanks! -- Manuel Lauss - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 08:48:21AM -0700, Linus Torvalds wrote:
The problem with this is that it only papers over the bug.
I don't mind trying to allocate at higher addresses per se: we used to
have the starting point be 0x4000 at some point, and that part is fine.
The problem is that this also screws us if somebody has a PCI bridge with
an IO window that is at a lower address than 0x2000 - now the PCI layer
will refuse to try to allocate within it, and you'll replace one bug by
another.
Right, and this hurts the cardbus as well...
But it should be pretty easy to learn the PCI layer to allocate above
PCIBIOS_MIN_IO _only_ when we allocate on the root bus.
Something like this (completely untested)?
Ivan.
--- linux/drivers/pci/setup-res.c.orig Fri Jun 17 23:48:29 2005
+++ linux/drivers/pci/setup-res.c Tue Aug 2 20:44:59 2005
@@ -113,11 +113,12 @@ int pci_assign_resource(struct pci_dev *
{
struct pci_bus *bus = dev-bus;
struct resource *res = dev-resource + resno;
- unsigned long size, min, align;
+ unsigned long size, min, align, min_io;
int ret;
+ min_io = (bus-self !bus-self-transparent) ? 0 : PCIBIOS_MIN_IO;
size = res-end - res-start + 1;
- min = (res-flags IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
+ min = (res-flags IORESOURCE_IO) ? min_io : PCIBIOS_MIN_MEM;
/* The bridge resources are special, as their
size != alignment. Sizing routines return
required alignment in the start field. */
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, 2 Aug 2005, Ivan Kokshaysky wrote: Right, and this hurts the cardbus as well... But it should be pretty easy to learn the PCI layer to allocate above PCIBIOS_MIN_IO _only_ when we allocate on the root bus. Something like this (completely untested)? I think you'd have to follow the transparent case down.. And even then you'd have the half-transparent case to worry about it. So I think it would be much easier to just make the change in pci_bus_alloc_resource(), and say that if the parent resource that we're testing starts at some non-zero value, we just use that instead of min when we call down to allocate_resource(). That gets it for MEM resources too. Something like the following (also _totally_ untested, but even simpler than yours). It basically says: if the parent resource starts at non-zero, we use that as the starting point for allocations, otherwise the passed-in value. That, together with changing PCIBIOS_MIN_IO to 0x2000 (or even 0x4000) might be the ticket... Linus diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -60,7 +60,9 @@ pci_bus_alloc_resource(struct pci_bus *b continue; /* Ok, try it out.. */ - ret = allocate_resource(r, res, size, min, -1, align, + ret = allocate_resource(r, res, size, + r-start ? : min, + -1, align, alignf, alignf_data); if (ret == 0) break; - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Wed, Aug 03, 2005 at 01:13:37AM +0400, Ivan Kokshaysky wrote: On Tue, Aug 02, 2005 at 10:11:40AM -0700, Linus Torvalds wrote: So I think it would be much easier to just make the change in pci_bus_alloc_resource(), and say that if the parent resource that we're testing starts at some non-zero value, we just use that instead of min when we call down to allocate_resource(). That gets it for MEM resources too. Cool! I think it's the way to go. Something like the following (also _totally_ untested, but even simpler than yours). It basically says: if the parent resource starts at non-zero, we use that as the starting point for allocations, otherwise the passed-in value. Tested on alpha. Initially I was concerned a bit about architectures where resources _never_ start at zero (due to some specific bus to resource conversions), but this change is just a no-op for them. That, together with changing PCIBIOS_MIN_IO to 0x2000 (or even 0x4000) might be the ticket... Definitely 0x4000. Then we can get rid of PCIBIOS_MIN_CARDBUS_IO which was introduced exactly for this reason, I guess. Nice, care to make up a single patch with these two changes in it? thanks, greg k-h - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 10:11:40AM -0700, Linus Torvalds wrote: So I think it would be much easier to just make the change in pci_bus_alloc_resource(), and say that if the parent resource that we're testing starts at some non-zero value, we just use that instead of min when we call down to allocate_resource(). That gets it for MEM resources too. Cool! I think it's the way to go. Something like the following (also _totally_ untested, but even simpler than yours). It basically says: if the parent resource starts at non-zero, we use that as the starting point for allocations, otherwise the passed-in value. Tested on alpha. Initially I was concerned a bit about architectures where resources _never_ start at zero (due to some specific bus to resource conversions), but this change is just a no-op for them. That, together with changing PCIBIOS_MIN_IO to 0x2000 (or even 0x4000) might be the ticket... Definitely 0x4000. Then we can get rid of PCIBIOS_MIN_CARDBUS_IO which was introduced exactly for this reason, I guess. Ivan. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, Aug 02, 2005 at 02:21:44PM -0700, Greg KH wrote: Nice, care to make up a single patch with these two changes in it? Yep, I'll do it shortly, plus some minor additions as separate patches. Ivan. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
--Andrew Morton [EMAIL PROTECTED] wrote (on Thursday, July 28, 2005 23:10:29 -0700): Martin J. Bligh [EMAIL PROTECTED] wrote: NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we identified earlier with the sched patches ... http://test.kernel.org/9398/debug/console.log Oh, thanks. That's about 8,349 bugs ago and I'd forgotten. Works with mainline still (including -rc4) ... hopefully those patches aren't on their way upstream anytime soon ;-) Well can you identify the offending patch(es)? If so, I'll exterminate them. scheduler-cache-hot-autodetect.patch, I think. will double-check. M. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
--Martin J. Bligh [EMAIL PROTECTED] wrote (on Tuesday, August 02, 2005 18:17:33 -0700): --Andrew Morton [EMAIL PROTECTED] wrote (on Thursday, July 28, 2005 23:10:29 -0700): Martin J. Bligh [EMAIL PROTECTED] wrote: NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we identified earlier with the sched patches ... http://test.kernel.org/9398/debug/console.log Oh, thanks. That's about 8,349 bugs ago and I'd forgotten. Works with mainline still (including -rc4) ... hopefully those patches aren't on their way upstream anytime soon ;-) Well can you identify the offending patch(es)? If so, I'll exterminate them. scheduler-cache-hot-autodetect.patch, I think. will double-check. Yup, backing out that one patch definitely fixes it. There was an earlier thread with Ingo about doing some possible debug on it, but to be honest, I haven't had time to play much beyond the initial ideas we tried. M. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 16:16 -0700, Christoph Lameter wrote:
> Hmmm. this should have returned the behavior to normal. Ah. Need to use
> new_entry instead of entry. Try this (is there any way that I could get
> access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
>
> +#ifdef CONFIG_ATOMIC_TABLE_OPS
> /*
>* If the cmpxchg fails then another processor may have done
>* the changes for us. If not then another fault will bring
> @@ -2106,6 +2107,11 @@
> } else {
> inc_page_state(cmpxchg_fail_flag_update);
> }
> +#else
> + ptep_set_access_flags(vma, address, pte, new_entry, write_access);
> + update_mmu_cache(vma, address, new_entry);
> + lazy_mmu_prot_update(new_entry);
> +#endif
With this applied, the system boots then X locks up in memcpy as before.
The cmpxchg_fail_flag_update remains at zero but given the above patch,
that's to be expected...
Sadly, remote access to the system isn't really much use as there is no
compiler on the device and flashing a new kernel is a manual procedure
involving pressing buttons.
Richard
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, 2 Aug 2005, Richard Purdie wrote:
> > + update_mmu_cache(vma, address, entry);
> > + lazy_mmu_prot_update(entry);
> > +#endif
>
> This locks the system up after the "INIT: version 2.86 booting" message.
> SysRq still responds but that's about it.
Hmmm. this should have returned the behavior to normal. Ah. Need to use
new_entry instead of entry. Try this (is there any way that I could get
access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 16:11:45.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-01 16:15:35.0 -0700
@@ -2094,6 +2094,7 @@
entry = pte_mkdirty(entry);
}
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, new_entry, write_access);
+ update_mmu_cache(vma, address, new_entry);
+ lazy_mmu_prot_update(new_entry);
+#endif
pte_unmap(pte);
page_table_atomic_stop(mm);
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 15:19 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > That number rapidly increases and so it looks like something is failing
> > and looping...
>
> Maybe we better restore the pte flags changes the way they were if
> CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
> then we need two different handle_pte_fault functions to get rid of the
> macro mess:
>
> +#ifdef CONFIG_ATOMIC_TABLE_OPS
> /*
>* If the cmpxchg fails then another processor may have done
>* the changes for us. If not then another fault will bring
> @@ -2106,6 +2107,11 @@
> } else {
> inc_page_state(cmpxchg_fail_flag_update);
> }
> +#else
> + ptep_set_access_flags(vma, address, pte, entry, write_access);
> + update_mmu_cache(vma, address, entry);
> + lazy_mmu_prot_update(entry);
> +#endif
This locks the system up after the "INIT: version 2.86 booting" message.
SysRq still responds but that's about it.
The system also feels/looks extremely sluggish after this change (more
looping?).
With your previously suggested change:
} else {
inc_page_state(cmpxchg_fail_flag_update);
+ set_pte_at(mm, address, pte, new_entry);
}
the system proceeds past INIT and boots normally but X still locks up...
Richard
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
> Could you get me some more information about the hang? A stacktrace would
> be useful.
I've attached gdb to it and its stuck in memcpy (from glibc). The rest
of the trace is junk as glibc's arm memcpy implementation will have
destroyed the frame pointer. The current instruction is a store to
memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
changing...
> Well the device is able to run X so I guess that a slow kernel compile
> would work. At least the embedded device that I used to work on was
> capable of doing that (but then we had Debian on that thing which made
> doing stuff like that very easy).
I agree, it would probably do a slow compile. I have no compiler or
development tools on it though and only slow vfat disks other than the
internal flash. There are plenty of options to get such things working
but it will take me a while to setup.
Hopefully the memcpy clue will mean something?
Richard
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
> That number rapidly increases and so it looks like something is failing
> and looping...
Maybe we better restore the pte flags changes the way they were if
CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
then we need two different handle_pte_fault functions to get rid of the
macro mess:
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 12:59:49.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-01 15:08:31.0 -0700
@@ -2094,6 +2094,7 @@
entry = pte_mkdirty(entry);
}
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, entry, write_access);
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+#endif
pte_unmap(pte);
page_table_atomic_stop(mm);
Index: linux-2.6.13-rc4-mm1/mm/memory.o
===
Binary files linux-2.6.13-rc4-mm1.orig/mm/memory.o 2005-08-01
15:03:10.0 -0700 and linux-2.6.13-rc4-mm1/mm/memory.o2005-08-01
15:09:50.0 -0700 differ
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
> cmpxchg_fail_flag_update 1359210189
>
> That number rapidly increases and so it looks like something is failing
> and looping...
That looks like some trouble with the MMU. The time between pte read and
write has been shortened through the page fault scalability patches.
Does this patch fix it?
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 12:59:49.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-01 15:02:19.0 -0700
@@ -2105,6 +2105,7 @@
lazy_mmu_prot_update(entry);
} else {
inc_page_state(cmpxchg_fail_flag_update);
+ set_pte_at(mm, address, pte, new_entry);
}
pte_unmap(pte);
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 14:40 -0700, Christoph Lameter wrote: > Can you run kgdb on it to figure out what is going on? Maybe, depending on how easily kgdb cross compiles and how quickly I can learn to use it... > There are some variables in /proc/vmstat that may help: > > spurious_page_faults 0 > cmpxchg_fail_flag_update 0 > cmpxchg_fail_flag_reuse 0 > cmpxchg_fail_anon_read 0 > cmpxchg_fail_anon_write 0 In my case: spurious_page_faults 0 cmpxchg_fail_flag_update 1359210189 cmpxchg_fail_flag_reuse 0 cmpxchg_fail_anon_read 0 cmpxchg_fail_anon_write 0 That number rapidly increases and so it looks like something is failing and looping... Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote: > > IP Not changing? Could it be in a loop doing faults for the same memory > > location that you cannot observe with gdb? Or is there some hardware fault > > that has stopped the processor? > > I'm not the worlds most experienced user of gdb but I can't see any > evidence of a hardware fault and the processor shows all indications of > running. It seems likely to be looping with memory faults or otherwise > jammed somehow. Can you run kgdb on it to figure out what is going on? > Is there anything I can use in /proc to monitor page faults or anything > I can do with gdb to help narrow this down? Run kgdb and see what is going on in the fault handler. There are some variables in /proc/vmstat that may help: spurious_page_faults 0 cmpxchg_fail_flag_update 0 cmpxchg_fail_flag_reuse 0 cmpxchg_fail_anon_read 0 cmpxchg_fail_anon_write 0 etc. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 14:16 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > I've attached gdb to it and its stuck in memcpy (from glibc). The rest
> > of the trace is junk as glibc's arm memcpy implementation will have
> > destroyed the frame pointer. The current instruction is a store to
> > memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
> > changing...
>
> IP Not changing? Could it be in a loop doing faults for the same memory
> location that you cannot observe with gdb? Or is there some hardware fault
> that has stopped the processor?
I'm not the worlds most experienced user of gdb but I can't see any
evidence of a hardware fault and the processor shows all indications of
running. It seems likely to be looping with memory faults or otherwise
jammed somehow.
Is there anything I can use in /proc to monitor page faults or anything
I can do with gdb to help narrow this down?
Richard
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
> On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
> > Could you get me some more information about the hang? A stacktrace would
> > be useful.
>
> I've attached gdb to it and its stuck in memcpy (from glibc). The rest
> of the trace is junk as glibc's arm memcpy implementation will have
> destroyed the frame pointer. The current instruction is a store to
> memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
> changing...
IP Not changing? Could it be in a loop doing faults for the same memory
location that you cannot observe with gdb? Or is there some hardware fault
that has stopped the processor?
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote: > > Is this related to the size of the process? Can you do a successful kernel > > compile w/o X? > > Its an embedded device and lacks development tools to test that. I ran > some programs which abuse malloc and the process would quite happily hit > oom so it looks like something more is needed to trigger the bug... Could you get me some more information about the hang? A stacktrace would be useful. Well the device is able to run X so I guess that a slow kernel compile would work. At least the embedded device that I used to work on was capable of doing that (but then we had Debian on that thing which made doing stuff like that very easy). - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 09:10 -0700, Christoph Lameter wrote: > On Mon, 1 Aug 2005, Richard Purdie wrote: > > > The system appears to be ok and boots happily to a console but if you > > load any graphical UI, the screen will blank and the process stops > > working (tested with opie and and xserver+GPE). You can kill -9 the > > process but you can't regain the console without a suspend/resume cycle > > which performs enough of a reset to get it back. chvt and the console > > switching keys don't respond. > > Is this related to the size of the process? Can you do a successful kernel > compile w/o X? Its an embedded device and lacks development tools to test that. I ran some programs which abuse malloc and the process would quite happily hit oom so it looks like something more is needed to trigger the bug... > > I tried the patch mentioned in http://lkml.org/lkml/2005/7/28/304 but it > > makes no difference. > > Yes that only helps if compilation fails and its alread in rc4-mm1 AFAIK. I thought that might be the case. Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote: > The system appears to be ok and boots happily to a console but if you > load any graphical UI, the screen will blank and the process stops > working (tested with opie and and xserver+GPE). You can kill -9 the > process but you can't regain the console without a suspend/resume cycle > which performs enough of a reset to get it back. chvt and the console > switching keys don't respond. Is this related to the size of the process? Can you do a successful kernel compile w/o X? > I tried the patch mentioned in http://lkml.org/lkml/2005/7/28/304 but it > makes no difference. Yes that only helps if compilation fails and its alread in rc4-mm1 AFAIK. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Friday 29 July 2005 5:17 pm, Andrew Morton wrote: > Khalid Aziz <[EMAIL PROTECTED]> wrote: > > > > Serial console is broken on ia64 on an HP rx2600 machine on > > 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no > > output ever appears on the console and system is hung. So I booted the > > kernel with "console=uart,mmio,0xff5e" to enable early console and > > here is how far the kernel got before hanging: > > Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled > > ... > > No ttyS device at MMIO 0xff5e for console > > > > Serial driver failed to find any serial ports. I am using defconfig. A > > 2.6.13-rc3 kernel (no mm3 patch) compiled with defconfig boots up fine > > and finds all serial ports. Your rc3-mm3 boot is also missing this: IOC: zx1 2.2 HPA 0xfed01000 IOVA space 1024Mb at 0x4000 So something's busted with ACPI. Both the IOC and the rx2600 serial ports should be discovered via ACPI. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
[Sorry all for the duplicate, LKML slipped somehow from the CC: line so I'm
sending this again]
Le dimanche 31 juillet 2005 à 16:22 -0700, Linus Torvalds a écrit :
> Also, it looks like sonypi really is pretty nasty to probe for, so it's
> not enough to just say "oh, it's a sony VAIO, let's reserve that region".
> Otherwise I'd just suggest adding a "dmi_check_system()" table to
> arch/i386/pci/i386.c, at the top of "pcibios_assign_resources()", and
> then you could just allocate things based on DMI information.
Since every Vaio laptop out there seems indeed to use only the first IO
port range in the list, we can de-nastyify the probe. And if we don't
even bother to check for Type1 vs. Type2 devices and we reserve both,
then it may be acceptable to do the above.
See the attached patch below which does just that. This has NOT been
tested (only compile-tested), and moreover it has a high breakage
probability in case some Vaios cannot live with the fixed ioport choice.
Note that this patch will conflict with the recent Eric's one (added in
CC:), he may want to rediff his Type3 changes in case this patch gets
in.
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
arch/i386/pci/i386.c | 42 +++
drivers/char/sonypi.c | 60 --
2 files changed, 52 insertions(+), 50 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-07-08 14:08:10.0
+0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-01 15:46:06.0 +0200
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "pci.h"
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, "Sony Programable I/O Type1 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type1 IO region\n");
+
+ /* IO ports for 'type2' device */
+ if (!request_region(0x1080, 0x20, "Sony Programable I/O Type2 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type2 IO region\n");
+
+ printk(KERN_INFO "Sony Vaio: pre-reserved IO ports\n");
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata sonyvaioio_dmi_table[] = {
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PCG-"),
+ },
+ },
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VGN-"),
+ },
+ },
+ { }
+};
+
static int __init pcibios_assign_resources(void)
{
struct pci_dev *dev = NULL;
int idx;
struct resource *r;
+ dmi_check_system(sonyvaioio_dmi_table);
+
for_each_pci_dev(dev) {
int class = dev->class >> 8;
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-01 11:06:47.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-01 15:45:27.0 +0200
@@ -104,14 +104,18 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_BASE0x50
#define SONYPI_G10A(SONYPI_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
#define SONYPI_SIRQ0x9b
#define SONYPI_SLOB0x9c
#define SONYPI_SHIB0x9d
-#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOPORT2 0x1084
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
/* battery / brightness addresses */
@@ -136,29 +140,6 @@
#define SONYPI_DATA_IOPORT 0x62
#define SONYPI_CST_IOPORT 0x66
-/* The set of possible ioports */
-struct sonypi_ioport_list {
- u16 port1;
- u16 port2;
-};
-
-static struct sonypi_ioport_list
Re: 2.6.13-rc3-mm3
[Sorry all for the duplicate, LKML slipped somehow from the CC: line so I'm
sending this again]
Le dimanche 31 juillet 2005 à 16:22 -0700, Linus Torvalds a écrit :
Also, it looks like sonypi really is pretty nasty to probe for, so it's
not enough to just say oh, it's a sony VAIO, let's reserve that region.
Otherwise I'd just suggest adding a dmi_check_system() table to
arch/i386/pci/i386.c, at the top of pcibios_assign_resources(), and
then you could just allocate things based on DMI information.
Since every Vaio laptop out there seems indeed to use only the first IO
port range in the list, we can de-nastyify the probe. And if we don't
even bother to check for Type1 vs. Type2 devices and we reserve both,
then it may be acceptable to do the above.
See the attached patch below which does just that. This has NOT been
tested (only compile-tested), and moreover it has a high breakage
probability in case some Vaios cannot live with the fixed ioport choice.
Note that this patch will conflict with the recent Eric's one (added in
CC:), he may want to rediff his Type3 changes in case this patch gets
in.
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
arch/i386/pci/i386.c | 42 +++
drivers/char/sonypi.c | 60 --
2 files changed, 52 insertions(+), 50 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-07-08 14:08:10.0
+0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-01 15:46:06.0 +0200
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/ioport.h
#include linux/errno.h
+#include linux/dmi.h
#include pci.h
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, Sony Programable I/O Type1 Device))
+ printk(KERN_ERR Sony Vaio: cannot reserve Type1 IO region\n);
+
+ /* IO ports for 'type2' device */
+ if (!request_region(0x1080, 0x20, Sony Programable I/O Type2 Device))
+ printk(KERN_ERR Sony Vaio: cannot reserve Type2 IO region\n);
+
+ printk(KERN_INFO Sony Vaio: pre-reserved IO ports\n);
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata sonyvaioio_dmi_table[] = {
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = Sony Vaio Laptop,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, PCG-),
+ },
+ },
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = Sony Vaio Laptop,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, VGN-),
+ },
+ },
+ { }
+};
+
static int __init pcibios_assign_resources(void)
{
struct pci_dev *dev = NULL;
int idx;
struct resource *r;
+ dmi_check_system(sonyvaioio_dmi_table);
+
for_each_pci_dev(dev) {
int class = dev-class 8;
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-01 11:06:47.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-01 15:45:27.0 +0200
@@ -104,14 +104,18 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_BASE0x50
#define SONYPI_G10A(SONYPI_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
#define SONYPI_SIRQ0x9b
#define SONYPI_SLOB0x9c
#define SONYPI_SHIB0x9d
-#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOPORT2 0x1084
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
/* battery / brightness addresses */
@@ -136,29 +140,6 @@
#define SONYPI_DATA_IOPORT 0x62
#define SONYPI_CST_IOPORT 0x66
-/* The set of possible ioports */
-struct sonypi_ioport_list {
- u16 port1;
- u16 port2;
-};
-
-static struct sonypi_ioport_list
Re: 2.6.13-rc3-mm3
On Friday 29 July 2005 5:17 pm, Andrew Morton wrote: Khalid Aziz [EMAIL PROTECTED] wrote: Serial console is broken on ia64 on an HP rx2600 machine on 2.6.13-rc3-mm3. When kernel is booted up with console=ttyS,..., no output ever appears on the console and system is hung. So I booted the kernel with console=uart,mmio,0xff5e to enable early console and here is how far the kernel got before hanging: Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled ... No ttyS device at MMIO 0xff5e for console Serial driver failed to find any serial ports. I am using defconfig. A 2.6.13-rc3 kernel (no mm3 patch) compiled with defconfig boots up fine and finds all serial ports. Your rc3-mm3 boot is also missing this: IOC: zx1 2.2 HPA 0xfed01000 IOVA space 1024Mb at 0x4000 So something's busted with ACPI. Both the IOC and the rx2600 serial ports should be discovered via ACPI. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote: The system appears to be ok and boots happily to a console but if you load any graphical UI, the screen will blank and the process stops working (tested with opie and and xserver+GPE). You can kill -9 the process but you can't regain the console without a suspend/resume cycle which performs enough of a reset to get it back. chvt and the console switching keys don't respond. Is this related to the size of the process? Can you do a successful kernel compile w/o X? I tried the patch mentioned in http://lkml.org/lkml/2005/7/28/304 but it makes no difference. Yes that only helps if compilation fails and its alread in rc4-mm1 AFAIK. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 09:10 -0700, Christoph Lameter wrote: On Mon, 1 Aug 2005, Richard Purdie wrote: The system appears to be ok and boots happily to a console but if you load any graphical UI, the screen will blank and the process stops working (tested with opie and and xserver+GPE). You can kill -9 the process but you can't regain the console without a suspend/resume cycle which performs enough of a reset to get it back. chvt and the console switching keys don't respond. Is this related to the size of the process? Can you do a successful kernel compile w/o X? Its an embedded device and lacks development tools to test that. I ran some programs which abuse malloc and the process would quite happily hit oom so it looks like something more is needed to trigger the bug... I tried the patch mentioned in http://lkml.org/lkml/2005/7/28/304 but it makes no difference. Yes that only helps if compilation fails and its alread in rc4-mm1 AFAIK. I thought that might be the case. Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote: Is this related to the size of the process? Can you do a successful kernel compile w/o X? Its an embedded device and lacks development tools to test that. I ran some programs which abuse malloc and the process would quite happily hit oom so it looks like something more is needed to trigger the bug... Could you get me some more information about the hang? A stacktrace would be useful. Well the device is able to run X so I guess that a slow kernel compile would work. At least the embedded device that I used to work on was capable of doing that (but then we had Debian on that thing which made doing stuff like that very easy). - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
Could you get me some more information about the hang? A stacktrace would
be useful.
I've attached gdb to it and its stuck in memcpy (from glibc). The rest
of the trace is junk as glibc's arm memcpy implementation will have
destroyed the frame pointer. The current instruction is a store to
memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
changing...
IP Not changing? Could it be in a loop doing faults for the same memory
location that you cannot observe with gdb? Or is there some hardware fault
that has stopped the processor?
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 14:16 -0700, Christoph Lameter wrote:
On Mon, 1 Aug 2005, Richard Purdie wrote:
I've attached gdb to it and its stuck in memcpy (from glibc). The rest
of the trace is junk as glibc's arm memcpy implementation will have
destroyed the frame pointer. The current instruction is a store to
memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
changing...
IP Not changing? Could it be in a loop doing faults for the same memory
location that you cannot observe with gdb? Or is there some hardware fault
that has stopped the processor?
I'm not the worlds most experienced user of gdb but I can't see any
evidence of a hardware fault and the processor shows all indications of
running. It seems likely to be looping with memory faults or otherwise
jammed somehow.
Is there anything I can use in /proc to monitor page faults or anything
I can do with gdb to help narrow this down?
Richard
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote: IP Not changing? Could it be in a loop doing faults for the same memory location that you cannot observe with gdb? Or is there some hardware fault that has stopped the processor? I'm not the worlds most experienced user of gdb but I can't see any evidence of a hardware fault and the processor shows all indications of running. It seems likely to be looping with memory faults or otherwise jammed somehow. Can you run kgdb on it to figure out what is going on? Is there anything I can use in /proc to monitor page faults or anything I can do with gdb to help narrow this down? Run kgdb and see what is going on in the fault handler. There are some variables in /proc/vmstat that may help: spurious_page_faults 0 cmpxchg_fail_flag_update 0 cmpxchg_fail_flag_reuse 0 cmpxchg_fail_anon_read 0 cmpxchg_fail_anon_write 0 etc. - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 14:40 -0700, Christoph Lameter wrote: Can you run kgdb on it to figure out what is going on? Maybe, depending on how easily kgdb cross compiles and how quickly I can learn to use it... There are some variables in /proc/vmstat that may help: spurious_page_faults 0 cmpxchg_fail_flag_update 0 cmpxchg_fail_flag_reuse 0 cmpxchg_fail_anon_read 0 cmpxchg_fail_anon_write 0 In my case: spurious_page_faults 0 cmpxchg_fail_flag_update 1359210189 cmpxchg_fail_flag_reuse 0 cmpxchg_fail_anon_read 0 cmpxchg_fail_anon_write 0 That number rapidly increases and so it looks like something is failing and looping... Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
cmpxchg_fail_flag_update 1359210189
That number rapidly increases and so it looks like something is failing
and looping...
That looks like some trouble with the MMU. The time between pte read and
write has been shortened through the page fault scalability patches.
Does this patch fix it?
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 12:59:49.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-01 15:02:19.0 -0700
@@ -2105,6 +2105,7 @@
lazy_mmu_prot_update(entry);
} else {
inc_page_state(cmpxchg_fail_flag_update);
+ set_pte_at(mm, address, pte, new_entry);
}
pte_unmap(pte);
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
That number rapidly increases and so it looks like something is failing
and looping...
Maybe we better restore the pte flags changes the way they were if
CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
then we need two different handle_pte_fault functions to get rid of the
macro mess:
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 12:59:49.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-01 15:08:31.0 -0700
@@ -2094,6 +2094,7 @@
entry = pte_mkdirty(entry);
}
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, entry, write_access);
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+#endif
pte_unmap(pte);
page_table_atomic_stop(mm);
Index: linux-2.6.13-rc4-mm1/mm/memory.o
===
Binary files linux-2.6.13-rc4-mm1.orig/mm/memory.o 2005-08-01
15:03:10.0 -0700 and linux-2.6.13-rc4-mm1/mm/memory.o2005-08-01
15:09:50.0 -0700 differ
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
Could you get me some more information about the hang? A stacktrace would
be useful.
I've attached gdb to it and its stuck in memcpy (from glibc). The rest
of the trace is junk as glibc's arm memcpy implementation will have
destroyed the frame pointer. The current instruction is a store to
memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
changing...
Well the device is able to run X so I guess that a slow kernel compile
would work. At least the embedded device that I used to work on was
capable of doing that (but then we had Debian on that thing which made
doing stuff like that very easy).
I agree, it would probably do a slow compile. I have no compiler or
development tools on it though and only slow vfat disks other than the
internal flash. There are plenty of options to get such things working
but it will take me a while to setup.
Hopefully the memcpy clue will mean something?
Richard
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 15:19 -0700, Christoph Lameter wrote:
On Mon, 1 Aug 2005, Richard Purdie wrote:
That number rapidly increases and so it looks like something is failing
and looping...
Maybe we better restore the pte flags changes the way they were if
CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
then we need two different handle_pte_fault functions to get rid of the
macro mess:
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, entry, write_access);
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+#endif
This locks the system up after the INIT: version 2.86 booting message.
SysRq still responds but that's about it.
The system also feels/looks extremely sluggish after this change (more
looping?).
With your previously suggested change:
} else {
inc_page_state(cmpxchg_fail_flag_update);
+ set_pte_at(mm, address, pte, new_entry);
}
the system proceeds past INIT and boots normally but X still locks up...
Richard
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Tue, 2 Aug 2005, Richard Purdie wrote:
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+#endif
This locks the system up after the INIT: version 2.86 booting message.
SysRq still responds but that's about it.
Hmmm. this should have returned the behavior to normal. Ah. Need to use
new_entry instead of entry. Try this (is there any way that I could get
access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 16:11:45.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-01 16:15:35.0 -0700
@@ -2094,6 +2094,7 @@
entry = pte_mkdirty(entry);
}
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, new_entry, write_access);
+ update_mmu_cache(vma, address, new_entry);
+ lazy_mmu_prot_update(new_entry);
+#endif
pte_unmap(pte);
page_table_atomic_stop(mm);
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 16:16 -0700, Christoph Lameter wrote:
Hmmm. this should have returned the behavior to normal. Ah. Need to use
new_entry instead of entry. Try this (is there any way that I could get
access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, new_entry, write_access);
+ update_mmu_cache(vma, address, new_entry);
+ lazy_mmu_prot_update(new_entry);
+#endif
With this applied, the system boots then X locks up in memcpy as before.
The cmpxchg_fail_flag_update remains at zero but given the above patch,
that's to be expected...
Sadly, remote access to the system isn't really much use as there is no
compiler on the device and flashing a new kernel is a manual procedure
involving pressing buttons.
Richard
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Thu, 2005-07-28 at 02:58 -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/ I'm seeing a problem on ARM with -rc3-mm3 and -rc4-mm1. -rc3-mm2 and -rc4 are fine and looking for the problem reveals the problems start after these patches are applied: > +page-fault-patches-optional-page_lock-acquisition-in.patch > +page-fault-patches-optional-page_lock-acquisition-in-tidy.patch The system appears to be ok and boots happily to a console but if you load any graphical UI, the screen will blank and the process stops working (tested with opie and and xserver+GPE). You can kill -9 the process but you can't regain the console without a suspend/resume cycle which performs enough of a reset to get it back. chvt and the console switching keys don't respond. I tried the patch mentioned in http://lkml.org/lkml/2005/7/28/304 but it makes no difference. Richard - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Le dimanche 31 juillet 2005 à 11:25 -0700, Linus Torvalds a écrit : > - The SonyPI driver just allocates IO regions in random areas. Those are not really random, the list of IO regions available is given in the ACPI SPIC device specification. The list is hardcoded here because the driver does not (yet ?) use the ACPI services for initializing the device, and experience has shown that the list does not vary with different models. > and I think the real bug here is the SonyPI driver. > > It should either use an IO port in the legacy motherboard resource area > (ie allocate itself somewhere in IO ports 0x100-0x3ff), this cannot be done, because the regions are already defined, and are not in the legacy area. > _or_ it should > play well as a PCI device, and actually try to work with the PCI IO port > allocation layer. sure, but the SPIC device is not really tied to a specific PCI device (it is for the 'type1' models, but not for the 'type2' ones). That's why the sonypi driver is not a PCI driver but relies on a DMI ident to detect each and every Vaio laptop out there. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Sun, 31 Jul 2005, Manuel Lauss wrote: > > Linus Torvalds wrote: > > > > > - The SonyPI driver just allocates IO regions in random areas. It's got a > >list of places to try allocating in, and the 1080 area just happens to > >be the first on the list, and since it's not used by anything else, it > >succeeds (never mind that it's on totally the wrong bus). > > On three different intel-vaios, I've seen the sonypi device always > located at ioport 0x1080. Even the windows driver on these models > always allocates the 0x1080-0x109f io-range for it. I think that's how the Linux driver IO list was gathered - looking at where it tends to sit by default. And the thing is, that would actually be ok too (as I sent in a separate email to Stelian later) - if the BIOS actually sets it up at 1080, we could easily just make a PCI quirk that marks that region _early_ in the bootup sequence as being reserved for SonyPI. That would make any later PCI allocation requests know to avoid it. The problem with the current setup is that the SonyPI driver is a perfectly regular driver, and thus obviously loads _after_ a number of other drivers, and the PCI setup code in particular. So what has happened is that we've set up other PCI IO regious without knowing - or caring - about the SonyPI driver, and then the SonyPI driver comes along and says "oh, btw, I want that region". And _that_ cannot work reliably. If you have a specific pre-allocated region that you want (or must have - some regions are fixed because of things like ACPI tables or SMM etc that depend on them), then you need to tell the world about it _before_ it starts allocating anything else, because otherwise the allocation routines obviously cannot know about that fixed thing. So what the sonypi driver does now is wrong, but there are two choices to do it right: tell the PCI subsystem early (traditionally done as a PCI quirk in drivers/pci/quirks.c, but you could possibly also make it as a driver-specific "subsys_initcall()" - but only if your driver is always compiled in, which sonypi isn't), or then allocate it nicely later. It's the combination of the two that is bad: "just tell somebody later" doesn't work. They may say that it's easier to get forgiveness than ask for permission, but that's not true in kernels. Because if you do something wrong, the device simply won't _work_, which is exactly what happened here ;). Linus - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Linus Torvalds wrote: > > - The SonyPI driver just allocates IO regions in random areas. It's got a >list of places to try allocating in, and the 1080 area just happens to >be the first on the list, and since it's not used by anything else, it >succeeds (never mind that it's on totally the wrong bus). On three different intel-vaios, I've seen the sonypi device always located at ioport 0x1080. Even the windows driver on these models always allocates the 0x1080-0x109f io-range for it. -- Manuel Lauss - 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
