Re: question about do_IRQ + 4k stacks

2005-04-01 Thread Terence Ripperda
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

Re: question about do_IRQ + 4k stacks

2005-04-01 Thread Terence Ripperda
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

question about do_IRQ + 4k stacks

2005-03-30 Thread Terence Ripperda
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? */ { ...

question about do_IRQ + 4k stacks

2005-03-30 Thread Terence Ripperda
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? */ { ...

64-bit pci bar on a 32-bit kernel

2005-02-24 Thread Terence Ripperda
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

64-bit pci bar on a 32-bit kernel

2005-02-24 Thread Terence Ripperda
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

Re: How to disable slow agpgart in kernel config?

2005-02-11 Thread Terence Ripperda
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 >

Re: How to disable slow agpgart in kernel config?

2005-02-11 Thread Terence Ripperda
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

Re: inter_module_get and __symbol_get

2005-01-24 Thread Terence Ripperda
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

Re: inter_module_get and __symbol_get

2005-01-24 Thread Terence Ripperda
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