Re: RFC: 64-bit resources and changes to pci, ioremap, ...
current pentium4 have this problem as well. Shouldn't need to use the emt64 (x86_64) mode. It takes i/o bridges and MCH to support it, but the latest Intel ones do. However, I am pretty sure BIOSes wouldn't assign the pci/pci-e addresses > 4GIG so most are not impacted. --- Kumar Gala <[EMAIL PROTECTED]> wrote: > As I started to update the existing patches to make > struct resource > have 64-bit start and end values I started to see > all the places that > this effects and was hoping to get some discussion > on what direction > we want to take. > > One of the main reasons to make this change is to > handle processors > that have larger physical address space than > effective. A number of > higher-end embedded processors are starting to > support larger > physical address space while still having a 32-bit > effective > address. I was wondering if any x86 variants > support this type of > feature? > > The main issue that I'm starting to see is that the > concept of a > physical address from the processors point of view > needs to be > consistent throughout all subsystems of the kernel. > Currently the > major usage of struct resource is with the PCI > subsystem and PCI > drivers. The following are some questions that I > was hoping to get > answers to and discussion around: > > * How many 32-bit systems support larger than 32-bit > physical > addresses (I know newer PPCs do)? > * How many 32-bit systems support a 64-bit PCI > address space? > * Should ioremap and variants start taking 64-bit > physical addresses? > * Do we make this an arch option and wrap start and > end in a typedef > similar to pte_t and provide accessor macros to > ensure proper use? > > Andrew has also asked me to post size comparisons of > drivers/*/*.o > building allmodconfig with 32-bit resources and > 64-bit resources to > see what the size growth is. I'll post logs for > people to take a > look at in a followup email. > > - Kumar > Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - 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/
2.6.xxx race condition in x86_64's global_flush_tlb???
I have seen some hangs in 2.6-x86_64 in flush_kernel_map(). The tests
cause alot of ioremap/iounmap to occur concurrently across many
processor threads.
Looking at the hung processor hangs, they are looping in
flush_kernel_map() and the list they get from the smp_call_function()
appears to be corrupt. In fact, I see deferred_pages as an entry and
that isn't supposed to happen.
I am questioning the locking in global_flush_tlb() listed below. The
down_read/up_read protection doesn't seen safe. If several threads are
rushing thru here, deferred_pages could be getting changed as they
look at it. I don't think there any protection when
list_replace_init() calls INIT_LIST_HEAD().
I changed the down_read()/up_read() around list_replace_init() to
down_write()/up_write() and my test runs fine.
void global_flush_tlb(void)
{
struct page *pg, *next;
struct list_head l;
down_read(&init_mm.mmap_sem); // XXX should be down_write()???
list_replace_init(&deferred_pages, &l);
up_read(&init_mm.mmap_sem); // XXX should be up_write()
flush_map(&l);
list_for_each_entry_safe(pg, next, &l, lru) {
ClearPagePrivate(pg);
__free_page(pg);
}
}
-
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.xxx race condition in x86_64's global_flush_tlb???
Your right. I thought I was updated but was at 23-rc9.
Sorry!
On 10/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 24 Oct 2007 16:39:57 -0400 Doug Reiland wrote:
>
> > I have seen some hangs in 2.6-x86_64 in flush_kernel_map(). The tests
> > cause alot of ioremap/iounmap to occur concurrently across many
> > processor threads.
> >
> > Looking at the hung processor hangs, they are looping in
> > flush_kernel_map() and the list they get from the smp_call_function()
> > appears to be corrupt. In fact, I see deferred_pages as an entry and
> > that isn't supposed to happen.
> >
> > I am questioning the locking in global_flush_tlb() listed below. The
> > down_read/up_read protection doesn't seen safe. If several threads are
> > rushing thru here, deferred_pages could be getting changed as they
> > look at it. I don't think there any protection when
> > list_replace_init() calls INIT_LIST_HEAD().
> >
> > I changed the down_read()/up_read() around list_replace_init() to
> > down_write()/up_write() and my test runs fine.
> >
> >
> > void global_flush_tlb(void)
> > {
> > struct page *pg, *next;
> > struct list_head l;
> >
> > down_read(&init_mm.mmap_sem); // XXX should be down_write()???
> > list_replace_init(&deferred_pages, &l);
> > up_read(&init_mm.mmap_sem); // XXX should be up_write()
> > flush_map(&l);
> >
> > list_for_each_entry_safe(pg, next, &l, lru) {
> > ClearPagePrivate(pg);
> > __free_page(pg);
> > }
> > }
>
> Seems to be already fixed in current git tree.
>
> ---
> ~Randy
>
-
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: Kernel panic in 2.6.19-rc1
Andrew Morton sorry I missed your reply: To recap, I said: FYI, I had to get CONFIG_SYSCTL_SYSCALL set to solve my 2.6.19-rc1 boot panic. Actually, I couldn't get CONFIG_SYSCTL_SYSCALL=y to stick so I modified kernel/sysctl.c's ifdefs. You said: What boot panic was that? It depends on CONFIG_EMBEDDED. The panic was because init died. I get an error message about unknown library version (exact message I can't recall) and then the panic. Again, I am running a new 2.6.x kernel on an old distribution so my init binary or run-time loader might still be depending on SYSCTL. I am now playing with a x86_64 kernel and saw this same problem. Your CONFIG_EMBEDDED hint helped. I set that and CONFIG_SYSCTL_SYSCALL stays on. Thanks again and sorry for not attaching this to the original email thread. - 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: diabling interrupts on pentium 4 processor
On 11/16/06, ranjith kumar <[EMAIL PROTECTED]> wrote: Hi, How to disable interrupts on pentium 4 (or any i386) machine? I tried to include "cli" instruction in a kernel module. But got runtime error. Are you doing this at the kernel level or application? - 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/
