Re: question about do_IRQ + 4k stacks
On Wed, Mar 30, 2005 at 09:14:22PM -0500, [EMAIL PROTECTED] wrote: > It checks for both process context (system call or kernel thread) or > interrupt context (nested irqs) stack overflows. ok, thanks. so we really only have 3k stacks rather than 4k stacks, right? if any code exceeds 3k stacks and is preempted by an interrupt, we can trigger this check and hang the system as a result (I notice that at least RHEL 4's kernels enable this check by default, not sure about other kernels). Thanks, Terence - 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/
question about do_IRQ + 4k stacks
I'm investigating some 4k stack issues with our driver, and I noticed
this ordering in do_IRQ:
asmlinkage unsigned int do_IRQ(struct pt_regs regs)
{
...
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 1KB free? */
{
...
}
#endif
...
#ifdef CONFIG_4KSTACKS
for (;;) {
... switch to interrupt stack
}
#endif
Is the intention of this stack overflow check to catch a currently
running kernel thread that's getting low on stack space, or is the
intent to make sure there's enough stack space to handle the incoming
interrupt? if the later, wouldn't you want to potentially switch to
your interrupt stack to be more accurate? (I recognize that often you
will have switched to an empty stack, unless you have nested
interrupts)
Thanks,
Terence
-
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/
64-bit pci bar on a 32-bit kernel
Hello, we've gotten a customer report of a problem whereby our framebuffer is not visible through the kernel. the kernel data structures in struct pci_dev have bar1 (our framebuffer) set to 0, and the bar does not appear in /proc/pci. after a little investigation, it appears that the bios allocated a 64-bit bar in pci config space. our gpu claims 64-bit support in pci config space and the cpu is an em64t. but the customer is running a 32-bit kernel on the em64t, which is a reasonable thing to do. it turns out the pci driver does not like 64-bit bars on a 32-bit kernel and prints out the following messages during boot: PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=5 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller 00:1f.1 PCI: Unable to handle 64-bit address space for PCI: Unable to handle 64-bit address space for PCI: Unable to handle 64-bit address for device 03:00.0 PCI: Unable to handle 64-bit address space for Is this an expected problem? Is there any reason why the 32-bit kernel couldn't handle 64-bit bars? here's what pci config space for our gpu looks like: 00: de 10 ce 00 07 01 10 00 a2 00 00 03 10 00 00 00 10: 00 00 00 de 0c 00 00 f8 0f 00 00 00 04 00 00 dd 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 43 02 30: 00 00 ee df 60 00 00 00 00 00 00 00 0a 01 00 00 Thanks, Terence - 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: How to disable slow agpgart in kernel config?
On Fri, Feb 11, 2005 at 01:48:21PM -0500, [EMAIL PROTECTED] wrote: > On Fri, Feb 11, 2005 at 06:04:06PM +, Nick Warne wrote: > > > > > This surprises me, especially considering the in-kernel nvidia-agp > driver > > > > was actually written by NVidia. Are there any agp error messages in > > > > your dmesg / X log ? > > > > > With the nVidia own nv_agp it appears directly in all apps, very fast > > > under GNOME 2.8.1. Why, I do not know. Also game (opengl) performance is > > > faster with the nv_agp, that I haven't used the kernel agp for months, > now. > > > > This is interesting. I always used agpgart without a second thought > (2.4.29, > > GeForce4 MX with Via KT133 chipset). > > > > I just read through the nVidia readme file, and there is a comprehensive > > section on what module to use for what chipset (and card). It recommends > > using the nVagp for my setup, so I just rebuilt excluding agpgart so I can > > use the nVdia module. > > > > I never had slowness as such in KDE or X apps, but playing quake2 openGL I > > used to get a 'wave' type effect rippling down the screen occasionally. A > > quick test using the nVagp module to have fixed that... > > Terrence, any ideas ? I would agree with your assessment Dave, there's very little difference betweeen the agp drivers. it's possible nvagp tweaks some register values that agpgart doesn't, I'd have to look closer at both to know. that might explain *modest* performance differences, but certainly wouldn't explain the dramatic performance differences the original poster described. I wouldn't expect even falling back to pci dma would have this big of an impact on 2d performance, but perhaps there's enough bus activity for this to happen. Marcus, can you verify that you're actually using agpgart in that situation? do you possibly have our XF86Config option set to nvagp only? (with IOMMU compiled in or agpgart loaded, our driver won't allow nvagp) you can verify whether agp is enabled with this command when our driver is loaded and X is started up: % cat /proc/drivers/nvidia/agp/status Status: Disabled (hmm, turns out my own dev machine doesn't have agp enabled and 2d performance isn't very noticeable) > > I just read through the nVidia readme file, and there is a comprehensive > > section on what module to use for what chipset (and card). It recommends > > using the nVagp for my setup, is that the "CONFIGURING AGP" appendix? I didn't think that we recommended which agp driver to use. the intention was just to document which chipsets are supported by nvagp and point out that agpgart may/probably supports more chipsets. that section also documents some hardware 'issues' that we work around. we work around these issues regardless of which agp driver is being used. for this via kt133 issue, I looked through the agpgart and nvagp initializations and didn't see anything much different. both initialize and flush gart mappings the same way. both seem to allocate memory the same way (nvagp uses __get_free_pages, which eventually calls alloc_pages) with the GFP_KERNEL flag. I'm not sure why there would be much difference between the two. > (It'd be really nice to get your PAT support in 2.6 sometime too btw). I've been meaning to finish that up. the actual PAT support is pretty simple; it's the protecting against cache aliasing that's a bit tricky and involved. for our push buffers, we don't worry too much about the cache aliasing, since change_page_attr() marks the kernel mapping uncached, and there shouldn't be any other mappings to the memory. mapping i/o regions like the framebuffer is a bit riskier, since it's more likely someone else has a conflicting mapping to it, but the damage of data corruption is much less fatal. Thanks, Terence - 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: inter_module_get and __symbol_get
On Tue, Jan 25, 2005 at 09:44:18AM +1100, kaos@ocs.com.au wrote: > Weak references are only done once, when the module is loaded. We > already use weak references for static determination of symbol > availability. inter_module_* and __symbol_* are aimed at the dynamic > reference problem, not static. this is probably a stupid question, but how are weak references used? Usually if a symbol is referenced by a module, but isn't resolved at load time, the module refuses to load. dynamic references allow a way to work around this for some applications, but I'm unfamiliar with weak references being used in this regard. or does that statement really mean "if we supported weak references, they would only be done once..." Thanks, Terence - 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/
overflow bugs in virtual memory routines?
Hello,
I believe I've found some corner-case overflow bugs in the virtual memory routines of
the kernel.
I'm tracking down some bugs with our driver on a 1 Gig system. This forces the
kernel's VMALLOC_AREA into very high memory, exactly where based on the
VMALLOC_RESERVE value, but roughly 0xfc00-0xe000 or 0xf800-0xe000. As
virtual memory is allocated, and the addresses come closer to 0xe000, it appears
some of the macros/tests in the virtual memory layer overflow and fail.
The first is in vmalloc.c:163, in the function get_vm_area():
161:addr = VMALLOC_START;
162:for (p = &vmlist; (tmp = *p) ; p = &tmp->next) {
163:if (size + addr < (unsigned long) tmp->addr)
If size is large enough, size + addr can overflow, and fulfill this condition when it
shouldn't. The new allocation will continue and overwrite some number of page tables.
The specific example I've seen is when the first virtual allocation (tmp->addr) is
0xfc00, and an ioremap of 64 Megs is tried. Since addr also starts off as
0xfc00, size + addr (0x400 + 0xfc00) overflows to 0x0, and the remapping
overwrites previous allocations.
Perhaps this would work (without too big a performance hit?):
163:if ( (size + addr < (unsigned long) tmp->addr) && (size + addr >
addr) )
The second is in vmalloc.c:135, in the function vmalloc_area_pages():
133:dir = pgd_offset_k(address);
134:flush_cache_all();
135:while (address < end) {
...
146:address = (address + PGDIR_SIZE) & PGDIR_MASK;
147:dir++;
148:}
If I do an allocation that fits exactly into the last bit of virtual address space,
this logic fails. My allocation ends up with a kernel virtual address of 0xffa09,
with a size of 0x50.
This allocation *should* span the last two page directories, 0xc0101ff8 & 0xc0101ffc,
and therefor make 2 passes through this loop, getting kicked out by the test at 135.
What ends up happening is that line 146 masks the address as so:
1st pass: (0xffa09000 + 0x40) & 0xffc0 => 0xffc0
2nd pass: (0xffc0 + 0x40) & 0xffc0 => 0x0
We start a 3rd with a pgd of 0xc0102000, which is the start of pg0. Obviously, very
bad things start happening when you rewrite those page tables, and the system shortly
reboots itself.
Perhaps something like this would work:
unsigned int start = address;
135:while ( (address < end) && (address > start) ) {
I'm more than happy to provide more details or test possible patches.
Thanks,
Terence Ripperda
NVIDIA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
