It seems most problems with 4k stacks are already resolved.
I'd like to see this patch to always use 4k stacks in -mm now for
finding any remaining problems before submitting this patch for 2.6.16.
Signed-off-by: Adrian Bunk <[email protected]>
---
arch/i386/Kconfig.debug | 10 ----------
arch/i386/kernel/irq.c | 10 ----------
include/asm-i386/irq.h | 11 +++--------
include/asm-i386/module.h | 8 +-------
include/asm-i386/thread_info.h | 6 +-----
5 files changed, 5 insertions(+), 40 deletions(-)
--- linux-2.6.14-mm2-full/arch/i386/Kconfig.debug.old 2005-11-14 01:30:54.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/Kconfig.debug 2005-11-14 01:31:06.000000000 +0100
@@ -52,16 +52,6 @@
portion of the kernel code won't be covered by a 2MB TLB anymore.
If in doubt, say "N".
-config 4KSTACKS
- bool "Use 4Kb for kernel stacks instead of 8Kb"
- depends on DEBUG_KERNEL
- help
- If you say Y here the kernel will use a 4Kb stacksize for the
- kernel stack attached to each process/thread. This facilitates
- running more threads on a system and also reduces the pressure
- on the VM subsystem for higher order allocations. This option
- will also use IRQ stacks to compensate for the reduced stackspace.
-
config X86_FIND_SMP_CONFIG
bool
depends on X86_LOCAL_APIC || X86_VOYAGER
--- linux-2.6.14-mm2-full/include/asm-i386/irq.h.old 2005-11-14 01:31:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/irq.h 2005-11-14 01:31:29.000000000 +0100
@@ -27,14 +27,9 @@
# define ARCH_HAS_NMI_WATCHDOG /* See include/linux/nmi.h */
#endif
-#ifdef CONFIG_4KSTACKS
- extern void irq_ctx_init(int cpu);
- extern void irq_ctx_exit(int cpu);
-# define __ARCH_HAS_DO_SOFTIRQ
-#else
-# define irq_ctx_init(cpu) do { } while (0)
-# define irq_ctx_exit(cpu) do { } while (0)
-#endif
+extern void irq_ctx_init(int cpu);
+extern void irq_ctx_exit(int cpu);
+#define __ARCH_HAS_DO_SOFTIRQ
#ifdef CONFIG_IRQBALANCE
extern int irqbalance_disable(char *str);
--- linux-2.6.14-mm2-full/include/asm-i386/thread_info.h.old 2005-11-14 01:31:45.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/thread_info.h 2005-11-14 01:32:11.000000000 +0100
@@ -53,11 +53,7 @@
#endif
#define PREEMPT_ACTIVE 0x10000000
-#ifdef CONFIG_4KSTACKS
-#define THREAD_SIZE (4096)
-#else
-#define THREAD_SIZE (8192)
-#endif
+#define THREAD_SIZE (4096)
#define STACK_WARN (THREAD_SIZE/8)
/*
--- linux-2.6.14-mm2-full/include/asm-i386/module.h.old 2005-11-14 01:32:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/module.h 2005-11-14 01:32:42.000000000 +0100
@@ -64,12 +64,6 @@
#define MODULE_REGPARM ""
#endif
-#ifdef CONFIG_4KSTACKS
-#define MODULE_STACKSIZE "4KSTACKS "
-#else
-#define MODULE_STACKSIZE ""
-#endif
-
-#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM MODULE_STACKSIZE
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM
#endif /* _ASM_I386_MODULE_H */
--- linux-2.6.14-mm2-full/arch/i386/kernel/irq.c.old 2005-11-14 01:32:56.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/kernel/irq.c 2005-11-14 01:33:28.000000000 +0100
@@ -33,7 +33,6 @@
}
#endif
-#ifdef CONFIG_4KSTACKS
/*
* per-CPU IRQ handling contexts (thread information and stack)
*/
@@ -44,7 +43,6 @@
static union irq_ctx *hardirq_ctx[NR_CPUS];
static union irq_ctx *softirq_ctx[NR_CPUS];
-#endif
/*
* do_IRQ handles all normal device IRQ's (the special
@@ -58,10 +56,8 @@
#ifdef CONFIG_DEBUG_PREEMPT
u32 count = preempt_count() & PREEMPT_MASK;
#endif
-#ifdef CONFIG_4KSTACKS
union irq_ctx *curctx, *irqctx;
u32 *isp;
-#endif
irq_enter();
#ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -79,8 +75,6 @@
}
#endif
-#ifdef CONFIG_4KSTACKS
-
curctx = (union irq_ctx *) current_thread_info();
irqctx = hardirq_ctx[smp_processor_id()];
@@ -118,7 +112,6 @@
irqctx->tinfo.preempt_count -= count;
#endif
} else
-#endif
__do_IRQ(irq, regs);
irq_exit();
@@ -128,8 +121,6 @@
return 1;
}
-#ifdef CONFIG_4KSTACKS
-
/*
* These should really be __section__(".bss.page_aligned") as well, but
* gcc's 3.0 and earlier don't handle that correctly.
@@ -228,7 +219,6 @@
}
EXPORT_SYMBOL(do_softirq);
-#endif
/*
* Interrupt statistics:
On Mon, 2005-11-14 at 03:11 +0100, Adrian Bunk wrote:
> It seems most problems with 4k stacks are already resolved.
>
> I'd like to see this patch to always use 4k stacks in -mm now for
> finding any remaining problems before submitting this patch for
> 2.6.16.
>
>
> Signed-off-by: Adrian Bunk <[email protected]>
Acked-by: Arjan van de Ven <[email protected]>
>
Adrian Bunk wrote:
> It seems most problems with 4k stacks are already resolved.
>
> I'd like to see this patch to always use 4k stacks in -mm now for
> finding any remaining problems before submitting this patch for 2.6.16.
>
>
Has the block layer been remade to a serial approach? Last time I
checked you could exhaust the stack fairly easy by layering a couple of
block subsystems on each other (usb+scsi+raid+lvm+xfs+nfs to make things
as horrible as possible).
Rgds
Pierre
On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
> Adrian Bunk wrote:
> > It seems most problems with 4k stacks are already resolved.
> >
> > I'd like to see this patch to always use 4k stacks in -mm now for
> > finding any remaining problems before submitting this patch for 2.6.16.
> >
> >
>
> Has the block layer been remade to a serial approach?
yes.
Arjan van de Ven wrote:
> On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
>
>>
>> Has the block layer been remade to a serial approach?
>>
>
> yes.
>
>
Great. Then please excuse my uninformed objections. :)
Rgds
Pierre
On Mon, Nov 14 2005, Arjan van de Ven wrote:
> On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
> > Adrian Bunk wrote:
> > > It seems most problems with 4k stacks are already resolved.
> > >
> > > I'd like to see this patch to always use 4k stacks in -mm now for
> > > finding any remaining problems before submitting this patch for 2.6.16.
> > >
> > >
> >
> > Has the block layer been remade to a serial approach?
>
> yes.
Not in mainline it hasn't.
Are there any recent benchmarks of 4kb vs 8kb stacks? Is anyone shipping
4kb stack kernels?
--
Jens Axboe
On Mon, 2005-11-14 at 12:11 +0100, Jens Axboe wrote:
> On Mon, Nov 14 2005, Arjan van de Ven wrote:
> > On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
> > > Adrian Bunk wrote:
> > > > It seems most problems with 4k stacks are already resolved.
> > > >
> > > > I'd like to see this patch to always use 4k stacks in -mm now for
> > > > finding any remaining problems before submitting this patch for 2.6.16.
> > > >
> > > >
> > >
> > > Has the block layer been remade to a serial approach?
> >
> > yes.
>
> Not in mainline it hasn't.
well the patch was for -mm ;)
>
> Are there any recent benchmarks of 4kb vs 8kb stacks?
not sure; I do know that it very much helps java (many more threads
possible) and the VM (far less order 1 allocs). In addition the 4Kb
allocation can be satisfied with the per cpu list of free 4Kb pages,
while obviously an order 1 cannot and has to go global.
> Is anyone shipping 4kb stack kernels?
Both Fedora and RHEL are shipping this for all 2.6 based versions (eg
FC2 and all later, RHEL4)
On Mon, Nov 14 2005, Arjan van de Ven wrote:
> On Mon, 2005-11-14 at 12:11 +0100, Jens Axboe wrote:
> > On Mon, Nov 14 2005, Arjan van de Ven wrote:
> > > On Mon, 2005-11-14 at 11:20 +0100, Pierre Ossman wrote:
> > > > Adrian Bunk wrote:
> > > > > It seems most problems with 4k stacks are already resolved.
> > > > >
> > > > > I'd like to see this patch to always use 4k stacks in -mm now for
> > > > > finding any remaining problems before submitting this patch for 2.6.16.
> > > > >
> > > > >
> > > >
> > > > Has the block layer been remade to a serial approach?
> > >
> > > yes.
> >
> > Not in mainline it hasn't.
>
> well the patch was for -mm ;)
ok :)
> >
> > Are there any recent benchmarks of 4kb vs 8kb stacks?
>
> not sure; I do know that it very much helps java (many more threads
> possible) and the VM (far less order 1 allocs). In addition the 4Kb
> allocation can be satisfied with the per cpu list of free 4Kb pages,
> while obviously an order 1 cannot and has to go global.
I realize it has nice advantages in theory, just wondering if anyone has
done a performance analysis of 4kb vs 8kb stacks lately (or at all?).
> > Is anyone shipping 4kb stack kernels?
>
> Both Fedora and RHEL are shipping this for all 2.6 based versions (eg
> FC2 and all later, RHEL4)
Cool, that's the kind of testing coverage I was hoping for.
--
Jens Axboe
On Mon, 2005-11-14 at 12:24 +0100, Jens Axboe wrote:
> >
> > not sure; I do know that it very much helps java (many more threads
> > possible) and the VM (far less order 1 allocs). In addition the 4Kb
> > allocation can be satisfied with the per cpu list of free 4Kb pages,
> > while obviously an order 1 cannot and has to go global.
>
> I realize it has nice advantages in theory, just wondering if anyone has
> done a performance analysis of 4kb vs 8kb stacks lately (or at all?).
I don't think at least anyone at RH has done any; the functionality gain
was already enough for us. One item I missed: in the many-thread cases,
you also save a lot of memory that can now be used for pagecache;
this won't of course be visible in a microbenchmark but should help
system wide.
Also in the implementation I don't see any way 4Kb stacks could show up
in any benchmarks as negative; there are only 4 or 5 extra instructions
in any path, and afaics no cache downsides (in fact the same irq stack
memory is now reused for irqs instead of threadstack-du-jour, so less
footprint/hotter caches)
On Mon, Nov 14 2005, Arjan van de Ven wrote:
> On Mon, 2005-11-14 at 12:24 +0100, Jens Axboe wrote:
> > >
> > > not sure; I do know that it very much helps java (many more threads
> > > possible) and the VM (far less order 1 allocs). In addition the 4Kb
> > > allocation can be satisfied with the per cpu list of free 4Kb pages,
> > > while obviously an order 1 cannot and has to go global.
> >
> > I realize it has nice advantages in theory, just wondering if anyone has
> > done a performance analysis of 4kb vs 8kb stacks lately (or at all?).
>
> I don't think at least anyone at RH has done any; the functionality gain
> was already enough for us. One item I missed: in the many-thread cases,
> you also save a lot of memory that can now be used for pagecache;
> this won't of course be visible in a microbenchmark but should help
> system wide.
>
> Also in the implementation I don't see any way 4Kb stacks could show up
> in any benchmarks as negative; there are only 4 or 5 extra instructions
> in any path, and afaics no cache downsides (in fact the same irq stack
> memory is now reused for irqs instead of threadstack-du-jour, so less
> footprint/hotter caches)
The only downside is the potential crashes due to overflowing the stack,
I'm not worried about 4kb stacks performing worse.
--
Jens Axboe
> >
> > Also in the implementation I don't see any way 4Kb stacks could show up
> > in any benchmarks as negative; there are only 4 or 5 extra instructions
> > in any path, and afaics no cache downsides (in fact the same irq stack
> > memory is now reused for irqs instead of threadstack-du-jour, so less
> > footprint/hotter caches)
>
> The only downside is the potential crashes due to overflowing the stack,
> I'm not worried about 4kb stacks performing worse.
>
First of all the 8Kb->4Kb change sounds like a big change, but 4Kb
really is 4Kb+4Kb (eg interrupt stacks). So the net reduction in
available stack for user context is a lot less (IRQ context need at
least 2Kb given that this is reentrant code wrt softirq processing),
probably in the order of 2Kb (compared to 8Kb 2.6 kernels) to 500 bytes
compared to 2.4 kernels (in 2.4 you lost 1.5 to the task struct on the
stack).
The experience with Fedora so far is exceptionally good; in early 2.6
there were some reports with XFS stacked on top of DM, but since then
XFS has gone on a stack diet... also the -mm patches to do non-recursive
IO submission will bury this (mostly theoretical) monster for good.
Arjan van de Ven wrote:
>
> The experience with Fedora so far is exceptionally good; in early 2.6
> there were some reports with XFS stacked on top of DM, but since then
> XFS has gone on a stack diet... also the -mm patches to do non-recursive
> IO submission will bury this (mostly theoretical) monster for good.
>
>
Fedora with their 2.6.12 and raid+xfs+nfs still causes occasional
problems for me. Haven't tried their 2.6.14. But until the block layer
modifications are mainline I'm sticking with 8 KiB. My heart momentarily
stops every time the file server decides to have a kernel panic, so
better safe than sorry.
Rgds
Pierre
On Mon, Nov 14, 2005 at 12:53:31PM +0100, Arjan van de Ven wrote:
> The experience with Fedora so far is exceptionally good; in early 2.6
> there were some reports with XFS stacked on top of DM, but since then
> XFS has gone on a stack diet... also the -mm patches to do non-recursive
> IO submission will bury this (mostly theoretical) monster for good.
Not theorical for iscsi though. I guess net+block is a little too
much.
OG.
On Llu, 2005-11-14 at 13:04 +0100, Olivier Galibert wrote:
> Not theorical for iscsi though. I guess net+block is a little too
> much.
net + block fits for the simpler stuff at least (nbd, ataoe)
This will break ndiswrapper. Why can't we just leave this in and let people choose?
I code, therefore I am
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
On Llu, 2005-11-14 at 05:38 -0800, Alex Davis wrote:
> This will break ndiswrapper. Why can't we just leave this in and let people choose?
If we spent our entire lives waiting for people to fix code nothing
would ever happen. Removing 8K stacks is a good thing to do for many
reasons. The ndis wrapper people have known it is coming for a long
time, and if it has a lot of users I'm sure someone in that community
will take the time to make patches.
On Monday 14 November 2005 14:49, Alan Cox wrote:
> On Llu, 2005-11-14 at 05:38 -0800, Alex Davis wrote:
> > This will break ndiswrapper. Why can't we just leave this in and let
> > people choose?
>
> If we spent our entire lives waiting for people to fix code nothing
> would ever happen. Removing 8K stacks is a good thing to do for many
> reasons. The ndis wrapper people have known it is coming for a long
> time, and if it has a lot of users I'm sure someone in that community
> will take the time to make patches.
I honestly don't know if this is the case, but is it conceivable that no patch
could be written to resolve this, because the Windows drivers themselves only
respect Windows stack limits (which are presumably still 8K?).
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
> I honestly don't know if this is the case, but is it conceivable that no patch
> could be written to resolve this, because the Windows drivers themselves only
> respect Windows stack limits (which are presumably still 8K?).
afaik Windows has 12k or 16k stacks.
On Mon, Nov 14, 2005 at 06:02:45PM +0000, Alistair John Strachan wrote:
> On Monday 14 November 2005 14:49, Alan Cox wrote:
> > On Llu, 2005-11-14 at 05:38 -0800, Alex Davis wrote:
> > > This will break ndiswrapper. Why can't we just leave this in and let
> > > people choose?
> >
> > If we spent our entire lives waiting for people to fix code nothing
> > would ever happen. Removing 8K stacks is a good thing to do for many
> > reasons. The ndis wrapper people have known it is coming for a long
> > time, and if it has a lot of users I'm sure someone in that community
> > will take the time to make patches.
>
> I honestly don't know if this is the case, but is it conceivable that no patch
> could be written to resolve this, because the Windows drivers themselves only
> respect Windows stack limits (which are presumably still 8K?).
Windows drivers can actually use more than 8KB. So in some situations,
you're already screwed. There are already cases where vendors customer
service are now telling people "Use ndiswrapper" when people ask about
Linux support.
If we continue down this path, we'll have no native wireless drivers for Linux.
The answer is not to complain to linux-kernel for breaking ndiswrapper,
but complain to the vendors for not releasing specifications for
native drivers to be written.
Dave
On Monday 14 November 2005 18:18, Dave Jones wrote:
> On Mon, Nov 14, 2005 at 06:02:45PM +0000, Alistair John Strachan wrote:
> > On Monday 14 November 2005 14:49, Alan Cox wrote:
> > > On Llu, 2005-11-14 at 05:38 -0800, Alex Davis wrote:
> > > > This will break ndiswrapper. Why can't we just leave this in and let
> > > > people choose?
> > >
> > > If we spent our entire lives waiting for people to fix code nothing
> > > would ever happen. Removing 8K stacks is a good thing to do for many
> > > reasons. The ndis wrapper people have known it is coming for a long
> > > time, and if it has a lot of users I'm sure someone in that community
> > > will take the time to make patches.
> >
> > I honestly don't know if this is the case, but is it conceivable that no
> > patch could be written to resolve this, because the Windows drivers
> > themselves only respect Windows stack limits (which are presumably still
> > 8K?).
>
> Windows drivers can actually use more than 8KB. So in some situations,
> you're already screwed. There are already cases where vendors customer
> service are now telling people "Use ndiswrapper" when people ask about
> Linux support.
>
> If we continue down this path, we'll have no native wireless drivers for
> Linux. The answer is not to complain to linux-kernel for breaking
> ndiswrapper, but complain to the vendors for not releasing specifications
> for native drivers to be written.
I agree, and I was not arguing for or against breaking ndiswrapper. I think
it's an interesting (and difficult) problem to solve if 4K-stacks gets in.
LWN has a piece on the possible options, but I suppose you could use the
argument that forcibly breaking ndiswrapper will spur new driver development
(but if you look at vendors like Broadcom, they have seem consistently
unwilling to do this).
http://lwn.net/Articles/150580/
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
> LWN has a piece on the possible options, but I suppose you could use the
> argument that forcibly breaking ndiswrapper will spur new driver development
> (but if you look at vendors like Broadcom, they have seem consistently
> unwilling to do this).
there now is a specification for the broadcom wireless, and a driver is
being written right now to that specification; and it seems to be
getting along quite well (it's not ready for primetime use yet but at
least they can send and receive stuff, which is probably the hardest
part)
On Monday 14 November 2005 18:29, Arjan van de Ven wrote:
> > LWN has a piece on the possible options, but I suppose you could use the
> > argument that forcibly breaking ndiswrapper will spur new driver
> > development (but if you look at vendors like Broadcom, they have seem
> > consistently unwilling to do this).
>
> there now is a specification for the broadcom wireless, and a driver is
> being written right now to that specification; and it seems to be
> getting along quite well (it's not ready for primetime use yet but at
> least they can send and receive stuff, which is probably the hardest
> part)
Great news. Perhaps all is not lost. This seems to be a leading chip for
laptop wireless, which is an especially contentious issue (since users cannot
swap it out as easily due to BIOS locks).
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Alan Cox wrote:
> reasons. The ndis wrapper people have known it is coming for a long
> time, and if it has a lot of users I'm sure someone in that community
> will take the time to make patches.
I believe I mentioned it before. ndiswrapper itself has been 4k stacks ready
for quite sometime. It is Windows drivers that need more than 4k stacks
(although Windows uses 12k stacks, I don't know of any Windows driver
requiring more than 8k stacks). One or two Windows drivers work with
ndiswrapper and 4k stacks, Broadcom for example.
If this 4k stack patch makes into mainstream, I am wondering what options,
other than maintaining a patch to back this patch, are available. The last
time this issue came up some people suggested pushing ndiswrapper into user
space. However, AFAIK this is non-trivial; I looked into FUSD
http://www.circlemud.org/~jelson/software/fusd/ which doesn't support
network drivers and seems to be not active in the recent past.
Any suggestions on how ndiswrapper can live with this patch would be greatly
appreciated.
Giri
On Mon, Nov 14, 2005 at 01:29:54PM -0500, Giridhar Pemmasani wrote:
> Any suggestions on how ndiswrapper can live with this patch would be greatly
> appreciated.
Couldn't ndiswrapper have its own private stack to switch to when
calling the windows driver, or are there still things hanging off the
end of the stack area?
OG.
On Mon, 14 Nov 2005, Arjan van de Ven wrote:
>
> there now is a specification for the broadcom wireless, and a driver is
> being written right now to that specification; and it seems to be
> getting along quite well (it's not ready for primetime use yet but at
> least they can send and receive stuff, which is probably the hardest
> part)
Goodie. With Broadcom and Intel on-board, we should have most of the
market covered in wireless, and ndiswrappers really should be less of an
argument (it was never an argument for me personally, but for others..).
Linus
On Mon, Nov 14, 2005 at 08:00:07PM +0100, Olivier Galibert wrote:
> Couldn't ndiswrapper have its own private stack to switch to when
> calling the windows driver, or are there still things hanging off the
> end of the stack area?
It's possible, but would need a change to how the kernel finds the thread
local data (which is currently done by masking off the stack pointer).
There are certainly a few ways of doing this, like using tr to find out
which cpu we're on and then indexing into the thread info state.
-ben
--
"Time is what keeps everything from happening all at once." -- John Wheeler
On Monday 14 November 2005 20:17, you wrote:
>
> On Mon, 14 Nov 2005, Arjan van de Ven wrote:
> >
> > there now is a specification for the broadcom wireless, and a driver is
> > being written right now to that specification; and it seems to be
> > getting along quite well (it's not ready for primetime use yet but at
> > least they can send and receive stuff, which is probably the hardest
> > part)
>
> Goodie. With Broadcom and Intel on-board, we should have most of the
> market covered in wireless, and ndiswrappers really should be less of an
> argument (it was never an argument for me personally, but for others..).
I really hope we get this thing usable in a few weeks.
Looks good so far... .
However, I did not test the broadcom driver on 4k-stacks,
as I only have a G4 with a broadcom card. ;) But I do not expect any problems.
--
Greetings Michael.
Benjamin LaHaise wrote:
> On Mon, Nov 14, 2005 at 08:00:07PM +0100, Olivier Galibert wrote:
>> Couldn't ndiswrapper have its own private stack to switch to when
>> calling the windows driver, or are there still things hanging off the
>> end of the stack area?
This has been discussed sometime back. Search for "ndiswrapper" on lkml.
See, e.g.,
http://marc.theaimsgroup.com/?l=linux-kernel&m=112602638406796&w=2
> It's possible, but would need a change to how the kernel finds the thread
> local data (which is currently done by masking off the stack pointer).
> There are certainly a few ways of doing this, like using tr to find out
> which cpu we're on and then indexing into the thread info state.
If any such alternate ways are used instead of relying on stack pointer, we
could have implemented private stacks for threads in ndiswrapper (and
driverloader).
Giri
On Llu, 2005-11-14 at 18:02 +0000, Alistair John Strachan wrote:
> > If we spent our entire lives waiting for people to fix code nothing
> > would ever happen. Removing 8K stacks is a good thing to do for many
> > reasons. The ndis wrapper people have known it is coming for a long
> > time, and if it has a lot of users I'm sure someone in that community
> > will take the time to make patches.
>
> I honestly don't know if this is the case, but is it conceivable that no patch
> could be written to resolve this, because the Windows drivers themselves only
> respect Windows stack limits (which are presumably still 8K?).
Both systems are (subject to memory limits) turing complete, so it is
definitely possible 8) The kernel itself switches stacks on an IRQ with
the 4K stack so you only have to worry about switching your kernel stack
not about taking interrupts on it and confusion that may cause.
Hi,
On Monday, 14 of November 2005 20:28, Michael Buesch wrote:
> On Monday 14 November 2005 20:17, you wrote:
> >
> > On Mon, 14 Nov 2005, Arjan van de Ven wrote:
> > >
> > > there now is a specification for the broadcom wireless, and a driver is
> > > being written right now to that specification; and it seems to be
> > > getting along quite well (it's not ready for primetime use yet but at
> > > least they can send and receive stuff, which is probably the hardest
> > > part)
> >
> > Goodie. With Broadcom and Intel on-board, we should have most of the
> > market covered in wireless, and ndiswrappers really should be less of an
> > argument (it was never an argument for me personally, but for others..).
>
> I really hope we get this thing usable in a few weeks.
> Looks good so far... .
Great!
> However, I did not test the broadcom driver on 4k-stacks,
> as I only have a G4 with a broadcom card. ;) But I do not expect any problems.
If you want someone to test it on x86-64, I think I can do that.
Greetings,
Rafael
On Llu, 2005-11-14 at 13:29 -0500, Giridhar Pemmasani wrote:
> If this 4k stack patch makes into mainstream, I am wondering what options,
> other than maintaining a patch to back this patch, are available. The last
> time this issue came up some people suggested pushing ndiswrapper into user
> space. However, AFAIK this is non-trivial; I looked into FUSD
> http://www.circlemud.org/~jelson/software/fusd/ which doesn't support
> network drivers and seems to be not active in the recent past.
>
> Any suggestions on how ndiswrapper can live with this patch would be greatly
> appreciated.
Switch stack before calling the Windows bits. If we take an IRQ then the
kernel will itself switch to its own IRQ stack for the IRQ handling. I
don't think there is much more required.
On Mon, 14 Nov 2005 22:33:57 +0000, Alan Cox <[email protected]> said:
Alan> Switch stack before calling the Windows bits. If we take an IRQ then
Alan> the kernel will itself switch to its own IRQ stack for the IRQ
Alan> handling. I don't think there is much more required.
Shouldn't I have to prevent scheduler from changing the tasks when executing
Windows code? Otherwise, kernel gets wrong current thread information,
which is based on stack pointer. This is the stumbling block for implementing
private stacks.
Thanks,
Giri
Olivier Galibert wrote:
> On Mon, Nov 14, 2005 at 12:53:31PM +0100, Arjan van de Ven wrote:
>
>>The experience with Fedora so far is exceptionally good; in early 2.6
>>there were some reports with XFS stacked on top of DM, but since then
>>XFS has gone on a stack diet... also the -mm patches to do non-recursive
>>IO submission will bury this (mostly theoretical) monster for good.
>
>
> Not theorical for iscsi though. I guess net+block is a little too
> much.
>
If you have stack problem with iscsi then you should post it to those
lists or send me a pointer offlist. There were problems with iscsi and
XFS but they should be fixed in mainline. The XFS + iscsi problems that
have been reported have not been stack usage problems though.
Mike Christie wrote:
> Olivier Galibert wrote:
>
>> On Mon, Nov 14, 2005 at 12:53:31PM +0100, Arjan van de Ven wrote:
>>
>>> The experience with Fedora so far is exceptionally good; in early 2.6
>>> there were some reports with XFS stacked on top of DM, but since then
>>> XFS has gone on a stack diet... also the -mm patches to do non-recursive
>>> IO submission will bury this (mostly theoretical) monster for good.
>>
>>
>>
>> Not theorical for iscsi though. I guess net+block is a little too
>> much.
>>
>
> If you have stack problem with iscsi then you should post it to those
> lists or send me a pointer offlist. There were problems with iscsi and
> XFS but they should be fixed in mainline. The XFS + iscsi problems that
> have been reported have not been stack usage problems though.
>
I think to hit a iscsi stack problem you will have to have the scsi
request_fn get called from __make_request (or one of the functions it
calls like __elv_add_request which looks like it could call
__generic_unplug_device). And then the iscsi queuecomamnd would have to
hit the path that calls iscsi_data_xmit. Have you hit this?
On Mon, Nov 14, 2005 at 06:32:02PM -0600, Mike Christie wrote:
> If you have stack problem with iscsi then you should post it to those
> lists or send me a pointer offlist. There were problems with iscsi and
> XFS but they should be fixed in mainline. The XFS + iscsi problems that
> have been reported have not been stack usage problems though.
That hasn't been very efficient last time. In any case, on the latest
version I tried (0.4-408, I can't blow up the backup machine every
other day):
- iscsi-tape is incompatible with tg3 and works with e1000
- iscsi-disk blows after a random time in what seems to be a (irq?)
stack explosion on x86 but not on x86-64 (which iirc has bigger
stacks). Seems to because the serial console blows too and only
writes a handful of characters.
Filesystem is reiser3.
OG.
Giridhar Pemmasani wrote:
> Shouldn't I have to prevent scheduler from changing the tasks when executing
> Windows code? Otherwise, kernel gets wrong current thread information,
> which is based on stack pointer. This is the stumbling block for implementing
> private stacks.
As long as preemption is disabled when the driver code is executing I
don't see how this would happen.. I don't know much of how ndiswrapper
does things but if the driver calls back into your code then you'd just
have to change the stack back before doing anything that could schedule.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
That doesn't answer my question. I want to know what __problems__
are caused by allowing the __choice__ of stack sizes.
-Alex
--- Alan Cox <[email protected]> wrote:
> If we spent our entire lives waiting for people to fix code nothing
> would ever happen. Removing 8K stacks is a good thing to do for many
> reasons. The ndis wrapper people have known it is coming for a long
> time, and if it has a lot of users I'm sure someone in that community
> will take the time to make patches.
>
>
I code, therefore I am
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
On Mon, 2005-11-14 at 19:02 -0600, Robert Hancock wrote:
> Giridhar Pemmasani wrote:
> > Shouldn't I have to prevent scheduler from changing the tasks when executing
> > Windows code? Otherwise, kernel gets wrong current thread information,
> > which is based on stack pointer. This is the stumbling block for implementing
> > private stacks.
>
> As long as preemption is disabled when the driver code is executing
Um, but it's really really bad for drivers to do that.
Lee
Lee Revell wrote:
>>As long as preemption is disabled when the driver code is executing
>
> Um, but it's really really bad for drivers to do that.
Normally yes.. but that may be a sacrifice that may have to be made
considering what ndiswrapper is doing - inserting blobs of code into the
kernel that were never designed to run there. I would think that would
be something you would want to do with such a driver regardless of stack
switching - do we have any way of knowing whether the Windows driver is
doing some timing-dependent thing that will cause bad things to happen
if we take away the CPU from it in the middle?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Olivier Galibert wrote:
> On Mon, Nov 14, 2005 at 06:32:02PM -0600, Mike Christie wrote:
>
>>If you have stack problem with iscsi then you should post it to those
>>lists or send me a pointer offlist. There were problems with iscsi and
>>XFS but they should be fixed in mainline. The XFS + iscsi problems that
>>have been reported have not been stack usage problems though.
>
>
> That hasn't been very efficient last time. In any case, on the latest
> version I tried (0.4-408, I can't blow up the backup machine every
> other day):
>
> - iscsi-tape is incompatible with tg3 and works with e1000
>
> - iscsi-disk blows after a random time in what seems to be a (irq?)
> stack explosion on x86 but not on x86-64 (which iirc has bigger
> stacks). Seems to because the serial console blows too and only
> writes a handful of characters.
>
And these only occur with 4k stacks? Do you have the traces still?
On Mon, Nov 14, 2005 at 09:07:48PM -0500, Lee Revell wrote:
> On Mon, 2005-11-14 at 19:02 -0600, Robert Hancock wrote:
> > Giridhar Pemmasani wrote:
> > > Shouldn't I have to prevent scheduler from changing the tasks when executing
> > > Windows code? Otherwise, kernel gets wrong current thread information,
> > > which is based on stack pointer. This is the stumbling block for implementing
> > > private stacks.
> >
> > As long as preemption is disabled when the driver code is executing
>
> Um, but it's really really bad for drivers to do that.
And loading Windows drivers into the kernel isn't ?
I think we're already in no-mans land here.
Remember, we have no clue what those drivers are even doing.
Preemption is the least of its problems.
Dave
Lee Revell wrote:
> Um, but it's really really bad for drivers to do that.
Not really. The Windows driver calls kernel API (in this case ndiswraper
functions) whenever it needs to wait on an event, sleep etc. So if preempt
is enabled on the way back (from Windows driver to Linux kernel call), it
shouldn't be a problem as far as preempt is concerned.
Giri
Dave Jones wrote:
>On Mon, Nov 14, 2005 at 09:07:48PM -0500, Lee Revell wrote:
> > On Mon, 2005-11-14 at 19:02 -0600, Robert Hancock wrote:
> > > Giridhar Pemmasani wrote:
> > > > Shouldn't I have to prevent scheduler from changing the tasks when executing
> > > > Windows code? Otherwise, kernel gets wrong current thread information,
> > > > which is based on stack pointer. This is the stumbling block for implementing
> > > > private stacks.
> > >
> > > As long as preemption is disabled when the driver code is executing
> >
> > Um, but it's really really bad for drivers to do that.
>
>And loading Windows drivers into the kernel isn't ?
>I think we're already in no-mans land here.
>
>Remember, we have no clue what those drivers are even doing.
>Preemption is the least of its problems.
>
> Dave
>
>
>
>
NetWare used 16K stacks in kernel by default. 4K is not enough room. I
have to dance around a lot of issues with 4K stacks. I haven't followed
who came up with the idea to limit stacks to 4K, but they should have
the option of 4-16K. NeWare 5.0 started using 32 Stacks for
all the compression support and FS crap, but 16K was a good number.
Why does the kernel need to be limited to 4K? for kernel preemption?
Someone needs to fix this. It's busted. It makes porting code between
Windows and Linux and other OS's difficult to support.
Jeff
Jeff V. Merkey wrote:
> Why does the kernel need to be limited to 4K? for kernel preemption?
No, because it makes a whole lot of things simpler and more reliable if
the kernel stack is only one page.
>
> Someone needs to fix this. It's busted. It makes porting code between
> Windows and Linux and other OS's difficult to support.
Ease of porting drivers written for other OSes to Linux is clearly not a
high priority for the kernel community..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
> Jeff V. Merkey wrote:
>
>> Why does the kernel need to be limited to 4K? for kernel preemption?
>
>
> No, because it makes a whole lot of things simpler and more reliable
> if the kernel stack is only one page.
>
>>
>> Someone needs to fix this. It's busted. It makes porting code between
>> Windows and Linux and other OS's difficult to support.
>
>
> Ease of porting drivers written for other OSes to Linux is clearly not
> a high priority for the kernel community..
What? There's more kernel apps than just ndis network drivers that get
ported. ndiswrapper is busted (which is used for a lot of laptops)
without 4K stacks. My laptop is a Compaq and there isn't a Linux driver
for the wireless. I also discovered Fedora Core 4 won't install
on a Compaq Presario with SATA (stacks crashes).
What are you saying? People with wireless and laptops who run Linux
can't because ndiswrapper is busted without 8K stacks?
Should be a configurable option 4-16K -- set at RUN TIME on the COMMAND
LINE of the BOOT LOADER. Peopl can set
profile=? why not kernel default stack size. That way Fedora, ES, AS,
and Suse can run out of the box on laptops like Windows,
or is M$ going to keep owning the desktop?
Jeff
Jeff V. Merkey wrote:
> What? There's more kernel apps than just ndis network drivers that get
> ported. ndiswrapper is busted (which is used for a lot of laptops)
> without 4K stacks.
Which is why ndiswrapper needs to get fixed to work with 4K stacks.
ndiswrapper is the thing that's doing the wierd stuff, it needs to adapt
to the kernel, not the other way around. The reasons to use 4K stacks
are strong enough that they are not made up for by the fact that
ndiswrapper currently would like to have more stack space.
Windows apparently has 12K of kernel stack for drivers.. in that case
even 8K of stack in Linux would not necessarily be enough. If
ndiswrapper wants to run Windows code in the kernel with any amount of
reliability it should be providing its own stack which is the size that
the code expects.
> My laptop is a Compaq and there isn't a Linux driver
> for the wireless. I also discovered Fedora Core 4 won't install
> on a Compaq Presario with SATA (stacks crashes).
How do you know this is related to the stack? Did you report this as a bug?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
> Jeff V. Merkey wrote:
>
>> What? There's more kernel apps than just ndis network drivers that
>> get ported. ndiswrapper is busted (which is used for a lot of laptops)
>> without 4K stacks.
>
>
> Which is why ndiswrapper needs to get fixed to work with 4K stacks.
> ndiswrapper is the thing that's doing the wierd stuff, it needs to
> adapt to the kernel, not the other way around. The reasons to use 4K
> stacks are strong enough that they are not made up for by the fact
> that ndiswrapper currently would like to have more stack space.
The NDIS drivers require the 8K stack, not ndiswrapper.
>
> Windows apparently has 12K of kernel stack for drivers.. in that case
> even 8K of stack in Linux would not necessarily be enough. If
> ndiswrapper wants to run Windows code in the kernel with any amount of
> reliability it should be providing its own stack which is the size
> that the code expects.
>
>> My laptop is a Compaq and there isn't a Linux driver for the
>> wireless. I also discovered Fedora Core 4 won't install
>> on a Compaq Presario with SATA (stacks crashes).
>
>
> How do you know this is related to the stack? Did you report this as a
> bug?
Because I use MDB, a kernel debugger I wrote that inserts beneath Linux
via DRLX or inside of it, and I watched it crash in the Linux SCSI
code. There's code in Linux proper that also walks off the end of the
stack. No I did not report it. But now I have.
Jeff
On Mon, Nov 14, 2005 at 08:26:45PM -0700, Jeff V. Merkey wrote:
> NetWare used 16K stacks in kernel by default.
unsubscribe netware-kernel
Dave Jones wrote:
>On Mon, Nov 14, 2005 at 08:26:45PM -0700, Jeff V. Merkey wrote:
>
> > NetWare used 16K stacks in kernel by default.
>
>unsubscribe netware-kernel
>
>
Making the point that in 1990, folks had grown beyond 4K stacks in
kernels, along with MS DOS 640K Limitations.
:-)
Jeff
>-
>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/
>
>
>
On Monday November 14, [email protected] wrote:
> Dave Jones wrote:
>
> >On Mon, Nov 14, 2005 at 08:26:45PM -0700, Jeff V. Merkey wrote:
> >
> > > NetWare used 16K stacks in kernel by default.
> >
> >unsubscribe netware-kernel
> >
> >
>
> Making the point that in 1990, folks had grown beyond 4K stacks in
> kernels, along with MS DOS 640K Limitations.
But I seem to remember learning in CS101 (or whatever we called it),
that the stack grows down and the heap grows up.
So if 'folks had grown beyond 4K stacks', I guess they must be at 2K
stacks ?->
NeilBrown
>
> :-)
>
> Jeff
Neil Brown wrote:
>On Monday November 14, [email protected] wrote:
>
>
>>Dave Jones wrote:
>>
>>
>>
>>>On Mon, Nov 14, 2005 at 08:26:45PM -0700, Jeff V. Merkey wrote:
>>>
>>>
>>>
>>>>NetWare used 16K stacks in kernel by default.
>>>>
>>>>
>>>unsubscribe netware-kernel
>>>
>>>
>>>
>>>
>>Making the point that in 1990, folks had grown beyond 4K stacks in
>>kernels, along with MS DOS 640K Limitations.
>>
>>
>
>But I seem to remember learning in CS101 (or whatever we called it),
>that the stack grows down and the heap grows up.
>So if 'folks had grown beyond 4K stacks', I guess they must be at 2K
>stacks ?->
>
>NeilBrown
>
>
Great point, and you are correct that MS DOS had bigger stacks than 4K.
Onward through the fog ....
Jeff
On Mon, 2005-11-14 at 22:31 -0600, Robert Hancock wrote:
> Jeff V. Merkey wrote:
> > What? There's more kernel apps than just ndis network drivers that get
> > ported. ndiswrapper is busted (which is used for a lot of laptops)
> > without 4K stacks.
>
> Which is why ndiswrapper needs to get fixed to work with 4K stacks.
> ndiswrapper is the thing that's doing the wierd stuff, it needs to adapt
> to the kernel, not the other way around. The reasons to use 4K stacks
> are strong enough that they are not made up for by the fact that
> ndiswrapper currently would like to have more stack space.
There was a discussion weeks (or already months?) ago about this. The
ndiswrapper maintainer had no problem with private stacks for the NDIS
drivers but IIRC there where some issues with callbacks from the NDIS
drivers which led to the conclusion that it's way too much of a hassle
to get it working and stable.
And yes, you need ndiswrapper for almost all of the WLAN drivers since
there is no documentation of them.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
> And yes, you need ndiswrapper for almost all of the WLAN drivers since
> there is no documentation of them.
you're wrong.
documentation for broadcom wireless:
http://bcm-specs.sipsolutions.net/
embrionic driver based on this spec:
http://bcm43xx.berlios.de/
driver for atheros wireless is nearly done:
http://www.selenic.com/pipermail/kernel-mentors/2005-August/000351.html
now if people started to help these folks instead of crying for
ndiswrapper binary solutions maybe those drivers will be finished
quicker.
El Mon, 14 Nov 2005 23:47:10 -0700,
"Jeff V. Merkey" <[email protected]> escribi?:
> Great point, and you are correct that MS DOS had bigger stacks than 4K.
> Onward through the fog ....
And Linux had stacks bigger than 4K until recently and could be made
bigger again. But 4K stacks are not considered a regression, but a
feature (ie: a good thing). So I guess you're not impressing lots
of people saying that msdos had bigger stacks...
On Tue, 2005-11-15 at 14:18 +0100, Tue, 15 Nov 2005 14:18:51 +0100
wrote:
> El Mon, 14 Nov 2005 23:47:10 -0700,
> "Jeff V. Merkey" <[email protected]> escribió:
>
> > Great point, and you are correct that MS DOS had bigger stacks than 4K.
> > Onward through the fog ....
>
>
> And Linux had stacks bigger than 4K until recently and could be made
> bigger again.
well ......
in 2.4 kernels you had a 4K stack as well (even though it was 8Kb in
size, you lost 1.5Kb to the task struct and you lost 2 to 2.5 Kb to irq
context, net usable was 4Kb). In 2.6 the task struct moved off the
stack, and the 4KSTACK feature allowed you to split the irq stack usage
off to a seperate stack, still giving you 4Kb available.. that's still
the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
soon) an option to get 6Kb effective stack space instead. This is an
increase of 2Kb compared to 2.4.
Giridhar Pemmasani wrote:
> Alan Cox wrote:
>
>>reasons. The ndis wrapper people have known it is coming for a long
>>time, and if it has a lot of users I'm sure someone in that community
>>will take the time to make patches.
>
>[...]
> Any suggestions on how ndiswrapper can live with this patch would be greatly
> appreciated.
One idea that has not yet been suggested, is to use a x86 emulator to
run the driver code.
I did some development a while ago, to reduce the size a x86 emulator to
run VGA BIOS functions. If an emulator like this would make it to the
kernel it could also be used to change video modes even using the VESA
driver, suspend/resume the VGA using the VGA own code, etc.
The final size of the emulator was a little over 30k, but there was
still room for even more reductions.
The advantages:
- the driver runs in a complete sandbox
- support for running NDIS drivers in multiple architectures (not just
x86)
- the emulator could be shared amongst more kernel subsystems in need
of an emulator (VESA, for instance)
Disadvantages:
- increase in kernel code size (about 30k)
- decrease in driver code execution speed
I'm not really advocating for this, just wanted to make sure people
would be aware of all the solutions available before committing to any
approach.
--
Paulo Marques - http://www.grupopie.com
The rule is perfect: in all matters of opinion our
adversaries are insane.
Mark Twain
On Tue, 15 Nov 2005, Arjan van de Ven wrote:
> documentation for broadcom wireless:
> http://bcm-specs.sipsolutions.net/
> embrionic driver based on this spec:
> http://bcm43xx.berlios.de/
Thanks, someone mentioned this but didn't provide any links...
> now if people started to help these folks instead of crying for
> ndiswrapper binary solutions maybe those drivers will be finished
> quicker.
Indeed, time to dig out my Linksys WPC54G.
-cp
--
Phishing, pharming; n.: Ways to obtain phood. -- The Devil's Infosec Dictionary
Arjan van de Ven wrote:
> the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
> soon) an option to get 6Kb effective stack space instead. This is an
> increase of 2Kb compared to 2.4.
It has been asked couple of times before in this context and no one cared to
answer:
Using 4k stacks may have advantages, but what compelling reasons are there
to drop the choice of 4k/8k stacks? You can make 4k stacks default, but why
throw away the option of 8k stacks, especially since the impact of this
option on the kernel implementation is very little?
Giri
Arjan van de Ven wrote:
>>And yes, you need ndiswrapper for almost all of the WLAN drivers since
>>there is no documentation of them.
>>
>>
>
>you're wrong.
>
>
>documentation for broadcom wireless:
>http://bcm-specs.sipsolutions.net/
>embrionic driver based on this spec:
>http://bcm43xx.berlios.de/
>
>driver for atheros wireless is nearly done:
>http://www.selenic.com/pipermail/kernel-mentors/2005-August/000351.html
>
>
>now if people started to help these folks instead of crying for
>ndiswrapper binary solutions maybe those drivers will be finished
>quicker.
>
>
No one is crying about ndiswrapper, some folks just want to use Linux on
their laptops without waiting
two years for all the drivers to port to Linux. Make the 4K stack
setting a command line option. Problem solved.
Jeff
>-
>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/
>
>
>
On Tue, Nov 15, 2005 at 11:46:30AM -0500, Giridhar Pemmasani wrote:
> Arjan van de Ven wrote:
>
> > the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
> > soon) an option to get 6Kb effective stack space instead. This is an
> > increase of 2Kb compared to 2.4.
>
> It has been asked couple of times before in this context and no one cared to
> answer:
>
> Using 4k stacks may have advantages, but what compelling reasons are there
> to drop the choice of 4k/8k stacks? You can make 4k stacks default, but why
> throw away the option of 8k stacks, especially since the impact of this
> option on the kernel implementation is very little?
One important point is to get remaining problems reported:
All the known issues in e.g. xfs, dm or reiser4 should have been
addressed.
But how many issues have never been reported because people noticed that
disabling CONFIG_4KSTACKS fixed the problem for them and therefore
didn't report it?
I experienced something similar with my patch to schedule OSS drivers
with ALSA replacements for removal - when someone reported he needed an
OSS driver for $reason I asked him for bug numbers in the ALSA bug
tracking system - and the highest number were 4 new bugs against one
ALSA driver.
Unconditionally enabling 4k stacks is the only way to achieve this.
And the fact that it might force people to help with the development or
at least use open source drivers for their hardware instead of
binary-only Windows drivers isn't exactly a disadvantage for the
development of Linux.
> Giri
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
JVM> No one is crying about ndiswrapper, some folks just want to use Linux on
JVM> their laptops without waiting
JVM> two years for all the drivers to port to Linux. Make the 4K stack
JVM> setting a command line option. Problem solved.
Just do a "fgrep -rI CONFIG_4KSTACKS linux" and see that this is just
not a matter of one malloc call but the code differs in many things.
That's what gives 4KSTACKS its strength.
--
Meelis Roos
On Tue, 15 Nov 2005 19:55:43 +0100, Adrian Bunk <[email protected]> said:
Adrian> And the fact that it might force people to help with the
Adrian> development or at least use open source drivers for their
Adrian> hardware instead of binary-only Windows drivers isn't
Adrian> exactly a disadvantage for the development of Linux.
IMO, this is at best only one side of the coin: Many people that ask
for help with ndiswrapper seem to be newbies that have just begun
using Linux. Most of these people can't/won't help with development of
native drivers. On the other hand, ndiswrapper can be used in reverse
engineering. I know of at least two such cases. So thinking
ndiswrapper as a scourge that hinders development (I am exaggerating a
bit here, but it has been suggested so by certain people more than
once on lkml) is not correct. Informed users, especially those that
follow lkml, are more interested in helping development of native
drivers and would chose to use native drivers if possible. Leaving
other end users high and dry without wireless support until such
drivers are available is not necessarily helpful for development of
open source drivers.
In essence, ndiswrapper is for those chipsets that have no open source
drivers until one can be developed.
This issue raises a concern for me as developer of ndiswrapper. I
perceive that some kernel developers have strong opinions against
ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
vested interests in ndiswrapper, although it will be sad to see lot of
effort and time put into ndiswrapper go waste. However, I believe
there is a need for such a project: There is a company (Linuxant) that
sells a product similar to ndiswrapper, ndisulator, which is similar
to ndiswrapper, is merged into FreeBSD kernel, and ndiswrapper itself
has been downloaded more than half a million times from Sourceforge
alone. And not all native drivers support all the features that users
need, e.g., WPA, whereas ndiswrapper supports all features provided by
vendor for Windows driver. And there are chipsets for which open
source drivers may not be available ever since they are rare. And if
it takes many months/years to develop a stable open source driver,
users need some way of using their hardware until then. And so on. I
am not trying to argue in favor of ndiswrapper at the cost of open
source drivers, but that there is a genuine need for such a project,
at least for now.
This is neither a complaint nor a plea; if option to chose 8k stacks
is dropped in the kernel, so be it. If I find time to provide support
for private 8k stacks within ndiswrapper, I will do that, so that if
this patch makes into kernel, users who need some way of using the
wireless cards can do so, for now.
Adrian> Unconditionally enabling 4k stacks is the only way to
Adrian> achieve this.
I think this is a bit drastic. As I suggested earlier, making 4k
stacks the default may be enough. For example, RedHat already
distributes kernels with 4k stacks and I am not sure if you will get
lot more cases, considering the popularity of RedHat.
--
Giri
On Tue, Nov 15, 2005 at 05:27:10PM -0500, Giridhar Pemmasani wrote:
> On Tue, 15 Nov 2005 19:55:43 +0100, Adrian Bunk <[email protected]> said:
>
> Adrian> And the fact that it might force people to help with the
> Adrian> development or at least use open source drivers for their
> Adrian> hardware instead of binary-only Windows drivers isn't
> Adrian> exactly a disadvantage for the development of Linux.
>
> IMO, this is at best only one side of the coin: Many people that ask
> for help with ndiswrapper seem to be newbies that have just begun
> using Linux. Most of these people can't/won't help with development of
> native drivers. On the other hand, ndiswrapper can be used in reverse
> engineering. I know of at least two such cases. So thinking
> ndiswrapper as a scourge that hinders development (I am exaggerating a
> bit here, but it has been suggested so by certain people more than
> once on lkml) is not correct. Informed users, especially those that
> follow lkml, are more interested in helping development of native
> drivers and would chose to use native drivers if possible. Leaving
> other end users high and dry without wireless support until such
> drivers are available is not necessarily helpful for development of
> open source drivers.
My impression is more that there is a big demand for ndiswrapper (look
e.g. at your download numbers below and some statements in this thread)
while support for the people developing open source drivers isn't that
big.
> In essence, ndiswrapper is for those chipsets that have no open source
> drivers until one can be developed.
In essency, ndiswrapper is a good excuse for hardware vendors who do not
want to support the development of open source drivers, because they can
always tell their costumers "Our hardware is supported by Linux through
the open source ndiswrapper module".
> This issue raises a concern for me as developer of ndiswrapper. I
> perceive that some kernel developers have strong opinions against
> ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
> vested interests in ndiswrapper, although it will be sad to see lot of
> effort and time put into ndiswrapper go waste. However, I believe
My personal opinion is that the ability to use unmodified binary-only
Windows drivers under Linux is really a cool project - and this is meant
in a 100% positive sense.
But a side effect is a worse open source support for the hardware in
question.
> there is a need for such a project: There is a company (Linuxant) that
> sells a product similar to ndiswrapper, ndisulator, which is similar
> to ndiswrapper, is merged into FreeBSD kernel, and ndiswrapper itself
> has been downloaded more than half a million times from Sourceforge
> alone. And not all native drivers support all the features that users
> need, e.g., WPA, whereas ndiswrapper supports all features provided by
> vendor for Windows driver. And there are chipsets for which open
> source drivers may not be available ever since they are rare. And if
> it takes many months/years to develop a stable open source driver,
> users need some way of using their hardware until then. And so on. I
> am not trying to argue in favor of ndiswrapper at the cost of open
> source drivers, but that there is a genuine need for such a project,
> at least for now.
As I tried to express above, both current end users and hardware vendors
might like ndiswrapper, but as a side effect there are less and/or worse
open source drivers.
It partially boils down to the question whether it's better for Linux to
get as much hardware supported now no matter how, or whether it's better
to have less hardware supported with good open source drivers and with
end users putting pressure on hardware vendors to help people developing
open source drivers.
And there's also the side effect that a poorly written Windows driver
might crash the Linux kernel. Many end users will attribute such a crash
to the Linux kernel harming the reputation of Linux as being stable.
> This is neither a complaint nor a plea; if option to chose 8k stacks
> is dropped in the kernel, so be it. If I find time to provide support
> for private 8k stacks within ndiswrapper, I will do that, so that if
> this patch makes into kernel, users who need some way of using the
> wireless cards can do so, for now.
>...
It's not the main purpose of my patch to break ndiswrapper, that is a
collateral damage - but IMHO a positive one.
And we are talking about open source.
You are free to solve the stack problem in ndiswrapper (which might
already be requierd for some drivers that aren't even happy with the
current stack limit), or you can tell people to undo my patch or
whatever.
> Giri
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> documentation for broadcom wireless:
> http://bcm-specs.sipsolutions.net/
> embrionic driver based on this spec:
> http://bcm43xx.berlios.de/
Maybe a good deal would be to delay the 4K patch until some preliminary
version of those is merged?
On Nov 15, 2005, at 6:41 PM, Wed, 16 Nov 2005 00:41:11 +0100 wrote:
>
>> documentation for broadcom wireless:
>> http://bcm-specs.sipsolutions.net/
>> embrionic driver based on this spec:
>> http://bcm43xx.berlios.de/
>
>
> Maybe a good deal would be to delay the 4K patch until some
> preliminary
> version of those is merged?
Andi had some pretty valid comments against the 4K approach.
Here - http://lkml.org/lkml/2005/9/6/4
I didn't see anyone contradicting his opinion. Seems very plausible
to me.
Parag
Could someone either list or post a link to someplace that lists
all the advantages of 4K stacks?
-Alex
I code, therefore I am
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
On Tue, 15 Nov 2005, Alex Davis wrote:
> Could someone either list or post a link to someplace that lists
> all the advantages of 4K stacks?
See the help text for the option under the kernel configurator...
or <http://lwn.net/Articles/84583/>
To summarize: it allows for more processes/threads (each process/thread
requires a kernel stack) and it makes it easier for the VM subsystem to
allocate larger than order 0 (4k) memory segments (i.e. it will be easier
to find contiguous free blocks).
HTH,
-cp
--
Phishing, pharming; n.: Ways to obtain phood. -- The Devil's Infosec Dictionary
-=> In article 15 Nov 05 15:00:28, Adrian Bunk wrote to All <=-
[...]
AB> Unconditionally enabling 4k stacks is the only way to achieve
AB> this.
:) 2K might do here..
5 Tue Nov 15 19:29:43 ~/build/kernel/linux-2.6.15-rc1-git3 $ make checkstack
objdump -d vmlinux $(find . -name '*.ko') | \
perl /home/ken/build/kernel/linux-2.6.15-rc1-git3/scripts/checkstack.pl i386
0xc02bd528 huft_build: 1432
0xc02bd954 huft_build: 1432
0xc02be1c4 inflate_dynamic: 1312
0xc02be2ff inflate_dynamic: 1312
0xc02be082 inflate_fixed: 1168
0xc02be172 inflate_fixed: 1168
0x0000d748 ipv6_setsockopt: 604
0x0000d788 ipv6_setsockopt: 604
0xc0182a38 semctl_main: 588
0xc0182b11 semctl_main: 588
0xc022e938 ip_setsockopt: 548
0xc022e9eb ip_setsockopt: 548
0xc01831d4 sys_semtimedop: 460
0xc01832d7 sys_semtimedop: 460
0xc022f31d ip_getsockopt: 436
0xc022f3b7 ip_getsockopt: 436
0xc01b98de extract_buf: 424
0xc01b9818 extract_buf: 420
0xc0158ee4 sys_pivot_root: 412
0xc0158f06 sys_pivot_root: 412
0x0000e1a6 ipv6_getsockopt: 392
0x0000e1e0 ipv6_getsockopt: 392
... SPF - Sender Policy Framework [Electronic Mail]
--- MultiMail/Linux Cyrix MII 1999 e-machines @ 200 MHz
On Tue, 2005-11-15 at 18:56 -0500, Parag Warudkar wrote:
> On Nov 15, 2005, at 6:41 PM, Wed, 16 Nov 2005 00:41:11 +0100 wrote:
>
> >
> >> documentation for broadcom wireless:
> >> http://bcm-specs.sipsolutions.net/
> >> embrionic driver based on this spec:
> >> http://bcm43xx.berlios.de/
> >
> >
> > Maybe a good deal would be to delay the 4K patch until some
> > preliminary
> > version of those is merged?
>
> Andi had some pretty valid comments against the 4K approach.
> Here - http://lkml.org/lkml/2005/9/6/4
> I didn't see anyone contradicting his opinion. Seems very plausible
> to me.
the only argument I see is "we had overflows in 2.4 with 8k". In fact
that is part of why 4K stacks was done! With 4k/4k stacks there is MORE
stack space than in 2.4. Most of the overflows I've seen in 2.4 were
nested interrupts with complex softirqs; with the 4k/4k stack approach
interrupts have MORE stack space available than in 2.4, making overflows
less likely. In addition the 2.6 kernel has undergone a "stack diet",
the final piece of which is the IO submission change that is now in -mm.
On Tue, 2005-11-15 at 16:50 -0800, Alex Davis wrote:
> Could someone either list or post a link to someplace that lists
> all the advantages of 4K stacks?
* less kernel memory (eg lowmem) used for a thread
- allows more threads on the same system (java!)
- increases performance in high-thread systems because more memory
is available for disk cache etc
* thread stacks are now order 0 not order 1
- order 0 is easy for the VM, order > 0 is harder (increasingly so
the higher the order; so the 16Kb/32Kb request is just really
wrong). For order > 0, fragmentation becomes an issue (just look
at the entire fragmentation debate from a few weeks ago how bad
a problem fragmentation can be). Thread stacks are just about the
last remaining "big" user of order > 0 allocations normally.
(eg excluding init/setup code)
- order 0 allocations come from a per cpu "quicklist" of pages,
while order>0 allocations need to go to a global allocator pool.
"global" means "cache line bounces" and "cpu scalability problem".
* less CPU cache footprint due to interrupt stacks
- interrupt stacks are per cpu now instead of borrowing the per
thread stack space; this both has less impact on the caches, and
has more cache hits; the per cpu stack will be in cache more than
the previously scattered bits and pieces
* more stack space is available for interrupts compared to 2.4 kernels
- in 2.4 kernels only 2Kb was available for interrupt context (to
keep 4K available for user context). With complex softirqs such as
PPP and firewall rules and nested interrupts this wasn't always
enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
2Kb extra available there compared to 2.4 and arguably some of that
extra is for interrupts.
Am Mittwoch, 16. November 2005 09:03 schrieb Arjan van de Ven:
> * less CPU cache footprint due to interrupt stacks
> - interrupt stacks are per cpu now instead of borrowing the per
> thread stack space; this both has less impact on the caches, and
> has more cache hits; the per cpu stack will be in cache more than
> the previously scattered bits and pieces
> * more stack space is available for interrupts compared to 2.4 kernels
> - in 2.4 kernels only 2Kb was available for interrupt context (to
> keep 4K available for user context). With complex softirqs such as
> PPP and firewall rules and nested interrupts this wasn't always
> enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
> 2Kb extra available there compared to 2.4 and arguably some of that
> extra is for interrupts.
This is due to having interrupt stacks. Is there any reason not to have
8K task stacks and per CPU interrupt stacks?
Regards
Oliver
On Wed, 2005-11-16 at 00:41 +0100, Wed, 16 Nov 2005 00:41:11 +0100
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Interesting Name.
wrote:
> > documentation for broadcom wireless:
> > http://bcm-specs.sipsolutions.net/
> > embrionic driver based on this spec:
> > http://bcm43xx.berlios.de/
>
>
> Maybe a good deal would be to delay the 4K patch until some preliminary
> version of those is merged?
Set the default value to "4k" and - to streß it further - remove the
questions on `make *config` so that sufficiently interesting people must
edit by hand after searching for it.
This will give the correct impression for everyone where it will go,
possibly raises the awareness of this area (WLAN drivers) and it doesn't
break ATM anything seriously.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
* Oliver Neukum <[email protected]> wrote:
> Am Mittwoch, 16. November 2005 09:03 schrieb Arjan van de Ven:
> > * less CPU cache footprint due to interrupt stacks
> > ? ?- interrupt stacks are per cpu now instead of borrowing the per
> > ? ? ?thread stack space; this both has less impact on the caches, and
> > ? ? ?has more cache hits; the per cpu stack will be in cache more than
> > ? ? ?the previously scattered bits and pieces
> > * more stack space is available for interrupts compared to 2.4 kernels
> > ? ?- in 2.4 kernels only 2Kb was available for interrupt context (to
> > ? ? ?keep 4K available for user context). With complex softirqs such as
> > ? ? ?PPP and firewall rules and nested interrupts this wasn't always
> > ? ? ?enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
> > ? ? ?2Kb extra available there compared to 2.4 and arguably some of that
> > ? ? ?extra is for interrupts.
>
> This is due to having interrupt stacks. Is there any reason not to
> have 8K task stacks and per CPU interrupt stacks?
yes, all the other arguments you snipped :) Arjan wrote 4K+4K stacks for
Fedora almost 2 years ago, and the patch has a good track record. Here's
some more background info about 4K+4K stacks:
http://lwn.net/Articles/84583/
http://lwn.net/Articles/150580/
http://lwn.net/Articles/160138/
Ingo
El Wed, 16 Nov 2005 09:03:32 +0100,
Arjan van de Ven <[email protected]> escribi?:
> * more stack space is available for interrupts compared to 2.4 kernels
> - in 2.4 kernels only 2Kb was available for interrupt context (to
> keep 4K available for user context). With complex softirqs such as
> PPP and firewall rules and nested interrupts this wasn't always
> enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
> 2Kb extra available there compared to 2.4 and arguably some of that
> extra is for interrupts.
I would like to contribute that listing with two non-technical reasons
more:
* Encourages good code. Due to the 4 Kb stacks patch several parts of
the kernel have gone on diet, improving the quality of the code
(see ndiswrapper, ndis drivers can overflow the stack even with
8KB stacks, the 4KB patch will force them to develop a _real_
safe solution for that, improving the quality of ndiswrapper).
* Some distros are enabling 4KB (fedora), other distros aren't, so
having a single stack size option will make 3rd party modules
distribution easier (some propietary drivers may not be caring
about making their drivers work with 4Kb stacks due to the lack
of uniformity)
On Wed, 2005-11-16 at 11:18 +0100, Wed, 16 Nov 2005 11:18:12 +0100
wrote:
> El Wed, 16 Nov 2005 09:03:32 +0100,
> Arjan van de Ven <[email protected]> escribió:
>
>
> > * more stack space is available for interrupts compared to 2.4 kernels
> > - in 2.4 kernels only 2Kb was available for interrupt context (to
> > keep 4K available for user context). With complex softirqs such as
> > PPP and firewall rules and nested interrupts this wasn't always
> > enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
> > 2Kb extra available there compared to 2.4 and arguably some of that
> > extra is for interrupts.
>
>
> I would like to contribute that listing with two non-technical reasons
> more:
>
> * Encourages good code. Due to the 4 Kb stacks patch several parts of
> the kernel have gone on diet, improving the quality of the code
this argument I agree with. especially since 64 bit platforms have a
higher stack footprint by nature (bigger call frames and more to store
on the stack) and if x86 allows stackbloat, the other architectures get
in trouble and are going to need really large stacks.
> * Some distros are enabling 4KB (fedora), other distros aren't, so
> having a single stack size option will make 3rd party modules
> distribution easier (some propietary drivers may not be caring
> about making their drivers work with 4Kb stacks due to the lack
> of uniformity)
this I don't see as a reason; illegal drivers should never be a reason
to clutter our kernel one way or the other. And for GPL 3rd party
drivers the problem isn't there realistically. If they were reliable in
2.4, they're reliable with 2.6+4K stacks. If they're not then they need
to be fixed (eg your previous point).
Arjan van de Ven <[email protected]> writes:
> > I would like to contribute that listing with two non-technical reasons
> > more:
> >
> > * Encourages good code. Due to the 4 Kb stacks patch several parts of
> > the kernel have gone on diet, improving the quality of the code
>
> this argument I agree with. especially since 64 bit platforms have a
> higher stack footprint by nature (bigger call frames and more to store
> on the stack) and if x86 allows stackbloat, the other architectures get
> in trouble and are going to need really large stacks.
I think it's in general risky. It's like balancing without a safety
net. Might be a nice hobby, but for real production you want a safety
net. That's simple because there are likely some code paths through
the code that need more stack space and that are rarely hit (and
cannot be easily found by static analysis, e.g. if they involve
indirect pointers or particularly complex configuration setups). With
very tight stack space you're much nearer a crash in extreme
situations than otherwise.
So I think it's a bad idea to change this.
-Andi (who prefers to have safety nets)
On Wed, 16 November 2005 13:57:36 +0100, Andi Kleen wrote:
>
> I think it's in general risky. It's like balancing without a safety
> net. Might be a nice hobby, but for real production you want a safety
> net. That's simple because there are likely some code paths through
> the code that need more stack space and that are rarely hit (and
> cannot be easily found by static analysis, e.g. if they involve
> indirect pointers or particularly complex configuration setups).
It isn't that hard to find such places. Trouble is that you find so
many of them and it takes quite a while to go through them all. Years
is a good unit for "quite a while".
J?rn
--
With a PC, I always felt limited by the software available. On Unix,
I am limited only by my knowledge.
-- Peter J. Schoenster
J?rn Engel wrote:
>On Wed, 16 November 2005 13:57:36 +0100, Andi Kleen wrote:
>
>
>>I think it's in general risky. It's like balancing without a safety
>>net. Might be a nice hobby, but for real production you want a safety
>>net. That's simple because there are likely some code paths through
>>the code that need more stack space and that are rarely hit (and
>>cannot be easily found by static analysis, e.g. if they involve
>>indirect pointers or particularly complex configuration setups).
>>
>>
>
>It isn't that hard to find such places. Trouble is that you find so
>many of them and it takes quite a while to go through them all. Years
>is a good unit for "quite a while".
>
>J?rn
>
>
>
Map a blank ro page beneath the address range when stack memory is
mapped is trap on page faults to the page when folks go off the end of
th e stack.
Easy to find.
Jeff
On Wed, 16 November 2005 07:42:06 -0700, jmerkey wrote:
> >
> Map a blank ro page beneath the address range when stack memory is
> mapped is trap on page faults to the page when folks go off the end of
> th e stack.
You forgot the part with the testcase that will trigger every single
possible stack overflow.
> Easy to find.
J?rn
--
Sometimes, asking the right question is already the answer.
-- Unknown
Am Mittwoch, 16. November 2005 15:42 schrieb jmerkey:
> Map a blank ro page beneath the address range when stack memory is
> mapped is trap on page faults to the page when folks go off the end of
> th e stack.
>
> Easy to find.
Provided you can easily trigger it. I don't see how that is a given.
Regards
Oliver
On Wed, 2005-11-16 at 16:30 +0100, Oliver Neukum wrote:
> Am Mittwoch, 16. November 2005 15:42 schrieb jmerkey:
> > Map a blank ro page beneath the address range when stack memory is
> > mapped is trap on page faults to the page when folks go off the end of
> > th e stack.
> >
> > Easy to find.
>
> Provided you can easily trigger it. I don't see how that is a given.
the same is true for a unified 8k stack or for the 4k/4k split though.
Ok sure there's a 1.5Kb difference on the one side.. (but a 2Kb gain on
the other side)
On Wednesday 16 November 2005 16:38, Arjan van de Ven wrote:
> On Wed, 2005-11-16 at 16:30 +0100, Oliver Neukum wrote:
> > Am Mittwoch, 16. November 2005 15:42 schrieb jmerkey:
> > > Map a blank ro page beneath the address range when stack memory is
> > > mapped is trap on page faults to the page when folks go off the end of
> > > th e stack.
> > >
> > > Easy to find.
> >
> > Provided you can easily trigger it. I don't see how that is a given.
>
> the same is true for a unified 8k stack or for the 4k/4k split though.
> Ok sure there's a 1.5Kb difference on the one side.. (but a 2Kb gain on
> the other side)
I was always in favour of 8K process stacks + irq stacks. Works great on x86-64.
-Andi
On Wed, Nov 16, 2005 at 10:04:14AM +0100, Bernd Petrovitsch wrote:
> On Wed, 2005-11-16 at 00:41 +0100, Wed, 16 Nov 2005 00:41:11 +0100
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Interesting Name.
> wrote:
> > > documentation for broadcom wireless:
> > > http://bcm-specs.sipsolutions.net/
> > > embrionic driver based on this spec:
> > > http://bcm43xx.berlios.de/
> >
> >
> > Maybe a good deal would be to delay the 4K patch until some preliminary
> > version of those is merged?
>
> Set the default value to "4k" and - to stre? it further - remove the
> questions on `make *config` so that sufficiently interesting people must
> edit by hand after searching for it.
If you are sufficiently interested, reverting my patch would be more
simple than manually hacking a Kconfig file.
> This will give the correct impression for everyone where it will go,
> possibly raises the awareness of this area (WLAN drivers) and it doesn't
> break ATM anything seriously.
>
> Bernd
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Nov 16, 2005 at 02:03:50AM +0000, Kenneth Parrish wrote:
> -=> In article 15 Nov 05 15:00:28, Adrian Bunk wrote to All <=-
>
> [...]
> AB> Unconditionally enabling 4k stacks is the only way to achieve
> AB> this.
> :) 2K might do here..
No, it wouldn't.
If one function calls another function you have to add the stack usages.
> 5 Tue Nov 15 19:29:43 ~/build/kernel/linux-2.6.15-rc1-git3 $ make checkstack
> objdump -d vmlinux $(find . -name '*.ko') | \
> perl /home/ken/build/kernel/linux-2.6.15-rc1-git3/scripts/checkstack.pl i386
> 0xc02bd528 huft_build: 1432
> 0xc02bd954 huft_build: 1432
> 0xc02be1c4 inflate_dynamic: 1312
> 0xc02be2ff inflate_dynamic: 1312
> 0xc02be082 inflate_fixed: 1168
> 0xc02be172 inflate_fixed: 1168
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Nov 16, 2005 at 05:10:04PM +0100, Andi Kleen wrote:
> On Wednesday 16 November 2005 16:38, Arjan van de Ven wrote:
> > On Wed, 2005-11-16 at 16:30 +0100, Oliver Neukum wrote:
> > > Am Mittwoch, 16. November 2005 15:42 schrieb jmerkey:
> > > > Map a blank ro page beneath the address range when stack memory is
> > > > mapped is trap on page faults to the page when folks go off the end of
> > > > th e stack.
> > > >
> > > > Easy to find.
> > >
> > > Provided you can easily trigger it. I don't see how that is a given.
> >
> > the same is true for a unified 8k stack or for the 4k/4k split though.
> > Ok sure there's a 1.5Kb difference on the one side.. (but a 2Kb gain on
> > the other side)
>
> I was always in favour of 8K process stacks + irq stacks. Works great on x86-64.
J?rn did some analysis regarding possible call paths > 3k.
Our goal is to achieve a stack usage < 3k with a safety margin of 1k.
The problem is similar no matter whether you have 4k or 8k stacks, but
with 4k stacks you have the additional benefits of order 0 allocations
and less memory usage.
> -Andi
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Nov 16, 2005 at 07:45:08PM +0100, Adrian Bunk wrote:
> The problem is similar no matter whether you have 4k or 8k stacks, but
> with 4k stacks you have the additional benefits of order 0 allocations
> and less memory usage.
We could implement a stack guard page for the transition period, so that
any stack overflows would end up generating a fault. That's easy enough
to do by using vmalloc().
-ben
Bernd Petrovitsch <[email protected]> writes:
> Set the default value to "4k" and - to stre? it further - remove the
> questions on `make *config` so that sufficiently interesting people must
> edit by hand after searching for it.
Haven't Red Hat tested that long enough?
--
Krzysztof Halasa
El Wed, 16 Nov 2005 14:03:34 -0500,
Benjamin LaHaise <[email protected]> escribi?:
> We could implement a stack guard page for the transition period, so that
CONFIG_DEBUG_STACKOVERFLOW doesn't do that but it looks useful too.
Does CONFIG_DEBUG_STACKOVERFLOW harm performance a lot? (doesn't
look like that for a newbie's eye)
On Wed, 16 November 2005 19:45:08 +0100, Adrian Bunk wrote:
>
> J?rn did some analysis regarding possible call paths > 3k.
And most of them have been changed since. Zlib remains high on the
list, but those paths are from /lib/inflate.c, during bootup.
What remains to be analysed is the recursions. If someone seriously
wants to work on those, I can respin the tests. The process is not
fully automated, so it will take me a weekend (and this weekend is
scheduled for a party).
J?rn
--
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories
J?rn Engel wrote:
>On Wed, 16 November 2005 19:45:08 +0100, Adrian Bunk wrote:
>
>
>>J?rn did some analysis regarding possible call paths > 3k.
>>
>>
>
>And most of them have been changed since. Zlib remains high on the
>list, but those paths are from /lib/inflate.c, during bootup.
>
>What remains to be analysed is the recursions. If someone seriously
>wants to work on those, I can respin the tests. The process is not
>fully automated, so it will take me a weekend (and this weekend is
>scheduled for a party).
>
>J?rn
>
>
>
The SCSI layer needs to be checked. I reproduced another crash on today
on an older Niksun box running off the end of the stack.
Jeff
Jeffrey V. Merkey wrote:
> J?rn Engel wrote:
>
>> On Wed, 16 November 2005 19:45:08 +0100, Adrian Bunk wrote:
>>
>>
>>> J?rn did some analysis regarding possible call paths > 3k.
>>>
>>
>>
>> And most of them have been changed since. Zlib remains high on the
>> list, but those paths are from /lib/inflate.c, during bootup.
>>
>> What remains to be analysed is the recursions. If someone seriously
>> wants to work on those, I can respin the tests. The process is not
>> fully automated, so it will take me a weekend (and this weekend is
>> scheduled for a party).
>>
>> J?rn
>>
>>
>>
> The SCSI layer needs to be checked. I reproduced another crash on
> today on an older Niksun box running off the end of the stack.
>
> Jeff
>
>
It's somewhere in the scanning code. There's a case where it runs off
the end of the stack. Check the compaq drivers for SATA as well, they
also crash in a similiar place during bus scan. Both occurred during
bootup, so I wasn't able to get a log of the particulars. Should be
easy to reproduce. Compaq Presario 2200.
Jeff
On Wed, 16 November 2005 15:54:27 -0700, Jeffrey V. Merkey wrote:
> Jeffrey V. Merkey wrote:
> >>
> >The SCSI layer needs to be checked. I reproduced another crash on
> >today on an older Niksun box running off the end of the stack.
> >
> It's somewhere in the scanning code. There's a case where it runs off
> the end of the stack. Check the compaq drivers for SATA as well, they
> also crash in a similiar place during bus scan. Both occurred during
> bootup, so I wasn't able to get a log of the particulars. Should be
> easy to reproduce. Compaq Presario 2200.
Do you have a backtrace for these? Real-life problem tend to generate
more attention than theoretical results based on code checkers.
J?rn
--
Linux is more the core point of a concept that surrounds "open source"
which, in turn, is based on a false concept. This concept is that
people actually want to look at source code.
-- Rob Enderle
On Wed, Nov 16, 2005 at 03:54:27PM -0700, Jeffrey V. Merkey wrote:
> >
> >The SCSI layer needs to be checked. I reproduced another crash on
> >today on an older Niksun box running off the end of the stack.
> >
> >Jeff
> >
> >
> It's somewhere in the scanning code. There's a case where it runs off
> the end of the stack. Check the compaq drivers for SATA as well, they
> also crash in a similiar place during bus scan. Both occurred during
> bootup, so I wasn't able to get a log of the particulars. Should be
> easy to reproduce. Compaq Presario 2200.
Are you using completely unmodified ftp.kernel.org kernels?
Which version?
If it occurs during bootup, you should see the error displayed.
Please use a digital camera to photograph the error and send a linkt ot
the photo.
> Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
J?rn Engel wrote:
>On Wed, 16 November 2005 15:54:27 -0700, Jeffrey V. Merkey wrote:
>
>
>>Jeffrey V. Merkey wrote:
>>
>>
>>>The SCSI layer needs to be checked. I reproduced another crash on
>>>today on an older Niksun box running off the end of the stack.
>>>
>>>
>>>
>>It's somewhere in the scanning code. There's a case where it runs off
>>the end of the stack. Check the compaq drivers for SATA as well, they
>>also crash in a similiar place during bus scan. Both occurred during
>>bootup, so I wasn't able to get a log of the particulars. Should be
>>easy to reproduce. Compaq Presario 2200.
>>
>>
>
>Do you have a backtrace for these? Real-life problem tend to generate
>more attention than theoretical results based on code checkers.
>
>J?rn
>
>
>
I'll try to get one tonight ad post to the list.
Jeff
Adrian Bunk wrote:
>On Wed, Nov 16, 2005 at 03:54:27PM -0700, Jeffrey V. Merkey wrote:
>
>
>>>The SCSI layer needs to be checked. I reproduced another crash on
>>>today on an older Niksun box running off the end of the stack.
>>>
>>>Jeff
>>>
>>>
>>>
>>>
>>It's somewhere in the scanning code. There's a case where it runs off
>>the end of the stack. Check the compaq drivers for SATA as well, they
>>also crash in a similiar place during bus scan. Both occurred during
>>bootup, so I wasn't able to get a log of the particulars. Should be
>>easy to reproduce. Compaq Presario 2200.
>>
>>
>
>Are you using completely unmodified ftp.kernel.org kernels?.
>
>
Yes.
>Which version?
>
>
>
2.6.14
>If it occurs during bootup, you should see the error displayed.
>Please use a digital camera to photograph the error and send a linkt ot
>the photo.
>
>
>
The error is a stack trace rolling off the screen with a list of
functions -- right before it reboots.
Jeff
>>Jeff
>>
>>
>
>cu
>Adrian
>
>
>
-=> In article 16 Nov 05 14:40:16, Adrian Bunk wrote to All <=-
AB> If one function calls another function you have to add the stack
AB> usages.
these few may do that, i bet.
0xc02bb528 huft_build: 1432
0xc02bb954 huft_build: 1432
0xc02bc1c4 inflate_dynamic: 1312
0xc02bc2ff inflate_dynamic: 1312
0xc02bc082 inflate_fixed: 1168
0xc02bc172 inflate_fixed: 1168
78.5% of 493 make checkstack lines here report fewer than 200 bytes.
Only six over 600.
... Life is like a simile.
--- MultiMail/Linux v0.46
-=> In article 17 Nov 05, 06:17ish -0600 Kenneth Parrish wrote to All <=-
AB> If one function calls another function you have to add the stack
AB> usages.
[..]
> 78.5% of 493 make checkstack lines here report fewer than 200 bytes.
> Only six over 600.
Only six over 604. :)
--- MultiMail/Linux v0.46
On Tuesday 15 November 2005 10:46, Giridhar Pemmasani wrote:
> Arjan van de Ven wrote:
> > the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
> > soon) an option to get 6Kb effective stack space instead. This is an
> > increase of 2Kb compared to 2.4.
>
> It has been asked couple of times before in this context and no one cared
> to answer:
>
> Using 4k stacks may have advantages, but what compelling reasons are there
> to drop the choice of 4k/8k stacks? You can make 4k stacks default, but why
> throw away the option of 8k stacks, especially since the impact of this
> option on the kernel implementation is very little?
Once everything in the kernel tree has been cleaned up to work with 4k stacks,
then none of the in-kernel drivers need this option. No future kernel
drivers will be accepted into the tree if they don't work with 4k stacks,
either. Therefore, the 8k stack option becomes something _only_ needed for
out-of-tree drivers, and if out-of-tree drivers need >4k stacks they can
maintain the 8k patch out of tree along with said driver.
Why is this difficult to understand? The "impact on the implementation" of
having 100 extra exports of random internal kernel symbols is fairly small as
well (from a lines of code perspective), but on a policy level it ain't gonna
happen.
Rob
On Wednesday 16 November 2005 20:03, Benjamin LaHaise wrote:
> On Wed, Nov 16, 2005 at 07:45:08PM +0100, Adrian Bunk wrote:
> > The problem is similar no matter whether you have 4k or 8k stacks, but
> > with 4k stacks you have the additional benefits of order 0 allocations
> > and less memory usage.
>
> We could implement a stack guard page for the transition period, so that
> any stack overflows would end up generating a fault. That's easy enough
> to do by using vmalloc()
And would add considerable overhead in TLB flushes and locking ...
-Andi
On Wednesday 16 November 2005 21:46, Wed, 16 Nov 2005 21:46:05 +0100 wrote:
> El Wed, 16 Nov 2005 14:03:34 -0500,
> Benjamin LaHaise <[email protected]> escribi?:
>
> > We could implement a stack guard page for the transition period, so that
>
> CONFIG_DEBUG_STACKOVERFLOW doesn't do that but it looks useful too.
>
> Does CONFIG_DEBUG_STACKOVERFLOW harm performance a lot? (doesn't
> look like that for a newbie's eye)
No, it's very cheap. In fact it could be probably enabled by default.
-Andi
P.S.: Can you please chose a less irritating realname?
Adrian Bunk wrote:
> On Tue, Nov 15, 2005 at 11:46:30AM -0500, Giridhar Pemmasani wrote:
>
>>Arjan van de Ven wrote:
>>
>>
>>>the same as 2.4 effectively. 2.6 also has (and I wish it becomes "had"
>>>soon) an option to get 6Kb effective stack space instead. This is an
>>>increase of 2Kb compared to 2.4.
>>
>>It has been asked couple of times before in this context and no one cared to
>>answer:
>>
>>Using 4k stacks may have advantages, but what compelling reasons are there
>>to drop the choice of 4k/8k stacks? You can make 4k stacks default, but why
>>throw away the option of 8k stacks, especially since the impact of this
>>option on the kernel implementation is very little?
>
>
>
> One important point is to get remaining problems reported:
>
> All the known issues in e.g. xfs, dm or reiser4 should have been
> addressed.
>
> But how many issues have never been reported because people noticed that
> disabling CONFIG_4KSTACKS fixed the problem for them and therefore
> didn't report it?
>
> I experienced something similar with my patch to schedule OSS drivers
> with ALSA replacements for removal - when someone reported he needed an
> OSS driver for $reason I asked him for bug numbers in the ALSA bug
> tracking system - and the highest number were 4 new bugs against one
> ALSA driver.
>
> Unconditionally enabling 4k stacks is the only way to achieve this.
The problem is that you persist in saying "the only way to achieve this"
without admiting that some people are questioning the need to run in 4k
stacks. The only argument I have seen for 4k stacks is that memory is
allocated in 4k blocks and there might not be 8k contiguous available.
When that's true the system is probably in deep trouble on memory anyway.
As someone pointed out using a larger memory allocation block (ie.
multiple of hardware minimum page) would avoid the fragmentation, make
all the bitmaps smaller, and generally have minimal effect either way on
memory use. And you could make the stack size the memory allocation
block size and never have to do conversions. Then the allocation size
could be anything reasonable, from 4k to 32k as mentioned recently.
Given the memory size of typical computers today, saving a few K per
process matters as much as a beer fart in a cow barn.
Do all other non-x86 platforms use 4k stacks? Then why is it such a big
thing to do it as the only choice for x86?
It seems like a lot of effort is being spent making things run in 4k
stacks, with minimal consideration of what benefits are gained or if
there are other ways to gain them. It just feels as though it's being
done to prove it's possible. Linux is about choice, let's go back to that.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Jeff V. Merkey wrote:
> Robert Hancock wrote:
>
>> Jeff V. Merkey wrote:
>>
>>> Why does the kernel need to be limited to 4K? for kernel preemption?
>>
>>
>>
>> No, because it makes a whole lot of things simpler and more reliable
>> if the kernel stack is only one page.
>>
>>>
>>> Someone needs to fix this. It's busted. It makes porting code between
>>> Windows and Linux and other OS's difficult to support.
>>
>>
>>
>> Ease of porting drivers written for other OSes to Linux is clearly not
>> a high priority for the kernel community..
>
>
>
> What? There's more kernel apps than just ndis network drivers that get
> ported. ndiswrapper is busted (which is used for a lot of laptops)
> without 4K stacks. My laptop is a Compaq and there isn't a Linux driver
> for the wireless. I also discovered Fedora Core 4 won't install
> on a Compaq Presario with SATA (stacks crashes).
> What are you saying? People with wireless and laptops who run Linux
> can't because ndiswrapper is busted without 8K stacks?
>
> Should be a configurable option 4-16K -- set at RUN TIME on the COMMAND
> LINE of the BOOT LOADER. Peopl can set
> profile=? why not kernel default stack size. That way Fedora, ES, AS,
> and Suse can run out of the box on laptops like Windows,
> or is M$ going to keep owning the desktop?
Having stack size as a compile time value and having it as a runtime
value are two totally different problems. I just don't see much benefit
from making changing the size easy, when it is likely to be a VERY
infrequent need at all.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Bill Davidsen wrote:
> process matters as much as a beer fart in a cow barn.
This one cracked me up :-)
> It seems like a lot of effort is being spent making things run in 4k
> stacks, with minimal consideration of what benefits are gained or if
> there are other ways to gain them. It just feels as though it's being
> done to prove it's possible. Linux is about choice, let's go back to that.
I couldn't agree more.
Giri
On Wednesday 16 November 2005 00:27, Giridhar Pemmasani wrote:
> In essence, ndiswrapper is for those chipsets that have no open source
> drivers until one can be developed.
>
> This issue raises a concern for me as developer of ndiswrapper. I
> perceive that some kernel developers have strong opinions against
> ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
> vested interests in ndiswrapper, although it will be sad to see lot of
> effort and time put into ndiswrapper go waste.
Does it mean that you support ndiswrapper just because you wrote it?
I understand this, but it's not a valid technical reason why
it should be supported.
> However, I believe
> there is a need for such a project: There is a company (Linuxant) that
> sells a product similar to ndiswrapper, ndisulator, which is similar
> to ndiswrapper, is merged into FreeBSD kernel, and ndiswrapper itself
> has been downloaded more than half a million times from Sourceforge
> alone. And not all native drivers support all the features that users
> need, e.g., WPA, whereas ndiswrapper supports all features provided by
> vendor for Windows driver. And there are chipsets for which open
> source drivers may not be available ever since they are rare. And if
> it takes many months/years to develop a stable open source driver,
> users need some way of using their hardware until then.
Companies got nice excuse for not giving us docs, making those
months/years even longer.
> And so on. I
> am not trying to argue in favor of ndiswrapper at the cost of open
> source drivers, but that there is a genuine need for such a project,
> at least for now.
Ok, how can we make any progress on obtaining docs for TI acx wireless
chipset? Or on Prism54 "softmac" chipset? The reply is "Open source
driver already exists (ndiswrapper), go away".
BTW, a few of wireless developers are interested in writing _open source
firmware_ (not just driver) for these, and it is not that hard to do,
if only we had the docs on components which make up the device.
Both of those are based on ARM processor + some specialized chips.
How can we hope to persuade companies into releasing that info
when they are escaping from giving us even docs on "external" interface
to their firmware with ndiswrapper argument, let alone on "internal"
components?
> This is neither a complaint nor a plea; if option to chose 8k stacks
> is dropped in the kernel, so be it. If I find time to provide support
> for private 8k stacks within ndiswrapper, I will do that, so that if
> this patch makes into kernel, users who need some way of using the
> wireless cards can do so, for now.
>
> Adrian> Unconditionally enabling 4k stacks is the only way to
> Adrian> achieve this.
>
> I think this is a bit drastic. As I suggested earlier, making 4k
> stacks the default may be enough. For example, RedHat already
> distributes kernels with 4k stacks and I am not sure if you will get
> lot more cases, considering the popularity of RedHat.
--
vda
Denis Vlasenko <[email protected]> wrote:
> On Wednesday 16 November 2005 00:27, Giridhar Pemmasani wrote:
[because of ndiswrapper, ...]
> Companies got nice excuse for not giving us docs, making those
> months/years even longer.
<snip>
> Ok, how can we make any progress on obtaining docs for TI acx wireless
> chipset? Or on Prism54 "softmac" chipset? The reply is "Open source
> driver already exists (ndiswrapper), go away".
That why are these cards (Netgear WG511) are documented as being supported
in the CONFIG_PRISM54 help text. I asume the list was copied from the same
bad list of supported cards that made me buy one in the first place. If
there was no ndiswrapper support, I'd have been fooled to completely waste
my money, with ndiswrapper I can at least partially use it. I do neither
want to wait some years to use a by-then obsolete card nor can I help
developing a driver beyond doing some testing.
BTW: What about creating a "Native linux support" logo saying "If you find
a slot and plug it in, you can use it with a vanilla kernel on any arch and
get vendor support"? That would help against Netgear's faksimile products of
working models or ATI's claims for having "linux support".
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
Bodo Eggert wrote:
> BTW: What about creating a "Native linux support" logo saying "If you find
> a slot and plug it in, you can use it with a vanilla kernel on any arch and
> get vendor support"? That would help against Netgear's faksimile products of
> working models or ATI's claims for having "linux support".
We can do that. Well, Linus can do that... he holds the trademark, he
could create a "Linux native driver" emblem. Have to be a tad careful to
require open source to get it, but I don't know about requiring GPL. In
the real world a single FOSS driver which could be used for Linux, BSD,
and Solaris would be easier for a vendor to justify, but it would have
to be covered by a license which satisfied all applications.
Even if it couldn't be part of a kernel.org source, at least if it were
available in source it would satisfy better than ndis. Anyone with real
expertise in what license could apply to all kernels please speak up.
None of this should imply that I have changed my mind about larger stack
sizes being desirable.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Llu, 2005-11-14 at 23:19 -0700, Jeff V. Merkey wrote:
> Making the point that in 1990, folks had grown beyond 4K stacks in
> kernels, along with MS DOS 640K Limitations.
And Linux 8086 uses 512 byte kernel stacks, and really wants a bit of
tuning to get down to 256.
Its about discipline and design not year
Alan Cox wrote:
>On Llu, 2005-11-14 at 23:19 -0700, Jeff V. Merkey wrote:
>
>
>>Making the point that in 1990, folks had grown beyond 4K stacks in
>>kernels, along with MS DOS 640K Limitations.
>>
>>
>
>And Linux 8086 uses 512 byte kernel stacks, and really wants a bit of
>tuning to get down to 256.
>
>Its about discipline and design not year
>
>-
>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/
>
>
>
Amen.
:-)
Jeff
Denis Vlasenko wrote:
>> This issue raises a concern for me as developer of ndiswrapper. I
>> perceive that some kernel developers have strong opinions against
>> ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
>> vested interests in ndiswrapper, although it will be sad to see lot of
>> effort and time put into ndiswrapper go waste.
>
> Does it mean that you support ndiswrapper just because you wrote it?
> I understand this, but it's not a valid technical reason why
> it should be supported.
What logic did you use to infer that? I only said I am continuing to develop
ndiswrapper and "vested interests" comment is to indicate that I have
nothing to gain by supporting ndiswrapper in Linux kernel; I am doing what
I can so people with unsupported wireless cards can use them in Linux.
> Companies got nice excuse for not giving us docs, making those
> months/years even longer.
>
>> And so on. I
>> am not trying to argue in favor of ndiswrapper at the cost of open
>> source drivers, but that there is a genuine need for such a project,
>> at least for now.
TI ACX chipset has been out long before ndiswrapper supported it. It has
been years since that chipset is out. In fact, ACX 100 chipset is no longer
made. Still the open source driver doesn't support WEP/WPA (I could be
wrong about current status, but at least until recently it was not). As I
said before, ndiswrapper is not competition to open source drivers - if
anything, it could be used to understand what the Windows driver does and
that may help in developing/improving open source driver.
> BTW, a few of wireless developers are interested in writing _open source
> firmware_ (not just driver) for these, and it is not that hard to do,
> if only we had the docs on components which make up the device.
I agree. But that is big "if".
> How can we hope to persuade companies into releasing that info
> when they are escaping from giving us even docs on "external" interface
> to their firmware with ndiswrapper argument, let alone on "internal"
> components?
This argument is debatable: There are wireless cards that didn't have
drivers even before ndiswrapper supported them. To claim that if they are
supported with anything less than an open source driver is hurting Linux is
one opinion. Given a choice, many people (I myself included) would chose
open source driver, but there are others that want to use the hardware they
have in Linux right now. Until an open source driver is available, I am
helping provide support for some hardware, so such people can use that
hardware in Linux.
I also would like to point out that using NDIS drivers in Linux is not
exactly same as using binary drivers: Whereas full-binary drivers hide
everything, NDIS drivers use an API to do anything/everything from the
kernel (e.g., to obtain/release a spinlcok, allocate/free memory etc).
ndiswrapper implements that API, so one can understand what an NDIS driver
is doing at the level of that API. In a way it is similar to loading
firmware (that runs on CPU) into open source driver.
Giri
On Tuesday 15 November 2005 12:55, Adrian Bunk wrote:
> I experienced something similar with my patch to schedule OSS drivers
> with ALSA replacements for removal - when someone reported he needed an
> OSS driver for $reason I asked him for bug numbers in the ALSA bug
> tracking system - and the highest number were 4 new bugs against one
> ALSA driver.
Speaking of which: I've been playing with qemu recently, and the sound card it
emulates is a sound blaster 16. Which only seems to have an OSS driver, no
ALSA...
This is known? If so I might take a whack at porting this if I get really
bored this weekend...
Rob
On Fri, 2005-11-18 at 19:33 -0600, Rob Landley wrote:
> On Tuesday 15 November 2005 12:55, Adrian Bunk wrote:
> > I experienced something similar with my patch to schedule OSS drivers
> > with ALSA replacements for removal - when someone reported he needed an
> > OSS driver for $reason I asked him for bug numbers in the ALSA bug
> > tracking system - and the highest number were 4 new bugs against one
> > ALSA driver.
>
> Speaking of which: I've been playing with qemu recently, and the sound card it
> emulates is a sound blaster 16. Which only seems to have an OSS driver, no
> ALSA...
>
> This is known? If so I might take a whack at porting this if I get really
> bored this weekend...
There already is an ALSA driver, check out sound/isa/sb/sb16.c:
/*
* Driver for SoundBlaster 16/AWE32/AWE64 soundcards
* Copyright (c) by Jaroslav Kysela <[email protected]>
etc
Lee
On Friday 18 November 2005 20:02, Lee Revell wrote:
> > Speaking of which: I've been playing with qemu recently, and the sound
> > card it emulates is a sound blaster 16. Which only seems to have an OSS
> > driver, no ALSA...
> >
> > This is known? If so I might take a whack at porting this if I get
> > really bored this weekend...
>
> There already is an ALSA driver, check out sound/isa/sb/sb16.c:
Ok, so where is the config option?
find . | xargs grep CONFIG_SND_SB16
./arch/i386/defconfig:# CONFIG_SND_SB16 is not set
./arch/ppc/configs/common_defconfig:# CONFIG_SND_SB16 is not set
./arch/ppc/configs/power3_defconfig:# CONFIG_SND_SB16 is not set
./include/sound/sb.h: void *csp; /* used only when CONFIG_SND_SB16_CSP is
set */
./sound/isa/sb/Makefile:obj-$(CONFIG_SND_SB16) += snd-sb16.o snd-sb16-dsp.o
snd-sb-common.o
./sound/isa/sb/Makefile:ifeq ($(CONFIG_SND_SB16_CSP),y)
./sound/isa/sb/Makefile: obj-$(CONFIG_SND_SB16) += snd-sb16-csp.o
./sound/isa/sb/sb16.c:#ifdef CONFIG_SND_SB16_CSP
./sound/isa/sb/sb16.c:#ifdef CONFIG_SND_SB16_CSP
./sound/isa/sb/sb16.c:#ifdef CONFIG_SND_SB16_CSP
./sound/isa/sb/sb16.c:#ifdef CONFIG_SND_SB16_CSP
./sound/isa/sb/sb16_main.c:#ifdef CONFIG_SND_SB16_CSP
It's in defconfig, source, and the makefile, but nowhere in Kconfig...
Rob
On Fri, 2005-11-18 at 20:43 -0600, Rob Landley wrote:
> On Friday 18 November 2005 20:02, Lee Revell wrote:
> > > Speaking of which: I've been playing with qemu recently, and the sound
> > > card it emulates is a sound blaster 16. Which only seems to have an OSS
> > > driver, no ALSA...
> > >
> > > This is known? If so I might take a whack at porting this if I get
> > > really bored this weekend...
> >
> > There already is an ALSA driver, check out sound/isa/sb/sb16.c:
>
> Ok, so where is the config option?
>
sound/isa/Kconfig:
253 config SND_SB16
254 tristate "Sound Blaster 16 (PnP)"
255 depends on SND
256 select SND_OPL3_LIB
257 select SND_MPU401_UART
258 select SND_PCM
259 select SND_GENERIC_DRIVER
260 help
261 Say Y here to include support for Sound Blaster 16 soundcards
262 (including the Plug and Play version).
263
264 To compile this driver as a module, choose M here: the module
265 will be called snd-sb16.
Lee
On Friday 18 November 2005 21:22, Lee Revell wrote:
> On Fri, 2005-11-18 at 20:43 -0600, Rob Landley wrote:
> > On Friday 18 November 2005 20:02, Lee Revell wrote:
> > > > Speaking of which: I've been playing with qemu recently, and the
> > > > sound card it emulates is a sound blaster 16. Which only seems to
> > > > have an OSS driver, no ALSA...
> > > >
> > > > This is known? If so I might take a whack at porting this if I get
> > > > really bored this weekend...
> > >
> > > There already is an ALSA driver, check out sound/isa/sb/sb16.c:
> >
> > Ok, so where is the config option?
>
> sound/isa/Kconfig:
Ah, I see.
that entire menu doesn't show up unless you've selected ISA under the bus menu
(which I thought means we probe for ISA slots, not that we don't support ISA
devices built onto the motherboard).
Meanwhile, the OSS SB16 driver shows up just fine with ISA disabled in the bus
menu...
Rob
On Fri, Nov 18, 2005 at 09:38:29PM -0600, Rob Landley wrote:
> that entire menu doesn't show up unless you've selected ISA under the bus menu
> (which I thought means we probe for ISA slots, not that we don't support ISA
> devices built onto the motherboard).
Common misconception. CONFIG_ISA means "Show me drivers that need
an ISA bus". Nothing more, nothing less.
You can't actually probe for the existance of an ISA slot, only
(unsafely) probe for a specific ISA device by poking ports.
Dave
Denis Vlasenko wrote:
>> This issue raises a concern for me as developer of ndiswrapper. I
>> perceive that some kernel developers have strong opinions against
>> ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no
>> vested interests in ndiswrapper, although it will be sad to see lot of
>> effort and time put into ndiswrapper go waste.
>
> Does it mean that you support ndiswrapper just because you wrote it?
> I understand this, but it's not a valid technical reason why
> it should be supported.
What logic did you use to infer that? I only said I am continuing to develop
ndiswrapper. "Vested interests" comment is to indicate that I have nothing
to gain by supporting ndiswrapper in Linux kernel; I am doing what I can so
people with unsupported wireless cards can use them in Linux.
> Companies got nice excuse for not giving us docs, making those
> months/years even longer.
>
>> And so on. I
>> am not trying to argue in favor of ndiswrapper at the cost of open
>> source drivers, but that there is a genuine need for such a project,
>> at least for now.
>
> Ok, how can we make any progress on obtaining docs for TI acx wireless
> chipset? Or on Prism54 "softmac" chipset? The reply is "Open source
> driver already exists (ndiswrapper), go away".
TI ACX chipset has been out long before ndiswrapper supported it. It has
been years since that chipset is out. In fact, ACX 100 chipset is no longer
made. Still the open source driver doesn't support WEP/WPA (I could be
wrong about current status, but at least until recently it was not). As I
said before, ndiswrapper is not competition to open source drivers - if
anything, it could be used to understand what the Windows driver does and
that may help in developing/improving open source driver.
> BTW, a few of wireless developers are interested in writing _open source
> firmware_ (not just driver) for these, and it is not that hard to do,
> if only we had the docs on components which make up the device.
I agree. But that is big "if".
> How can we hope to persuade companies into releasing that info
> when they are escaping from giving us even docs on "external" interface
> to their firmware with ndiswrapper argument, let alone on "internal"
> components?
This argument is debatable: There are wireless cards that didn't have
drivers even before ndiswrapper supported them. To claim that if they are
supported with anything less than an open source driver is hurting Linux is
one opinion. Given a choice, many people (I myself included) would chose
open source driver, but there are others that want to use the hardware they
have in Linux right now. Until an open source driver is available, I am
helping provide support for some hardware, so such people can use that
hardware in Linux.
I also would like to point out that using NDIS drivers in Linux is not
exactly same as using binary drivers: Whereas full-binary drivers hide
everything, NDIS drivers use an API to support the hardware (e.g., to
obtain/release a spinlcok, allocate/free memory etc). ndiswrapper
implements that API, so one can understand what an NDIS driver is doing at
the level of that API.
Giri
Kenneth Parrish <[email protected]> writes:
> -=> In article 16 Nov 05 14:40:16, Adrian Bunk wrote to All <=-
>
> AB> If one function calls another function you have to add the stack
> AB> usages.
>
> these few may do that, i bet.
> 0xc02bb528 huft_build: 1432
> 0xc02bb954 huft_build: 1432
> 0xc02bc1c4 inflate_dynamic: 1312
> 0xc02bc2ff inflate_dynamic: 1312
> 0xc02bc082 inflate_fixed: 1168
> 0xc02bc172 inflate_fixed: 1168
Now what is interesting is these functions currently run with a 4KiB
stack on every bootup. So unless they have callers with a
significant stack footprint things are fine.
Eric
On Wed, 30 November 2005 03:31:13 -0700, Eric W. Biederman wrote:
> Kenneth Parrish <[email protected]> writes:
>
> > -=> In article 16 Nov 05 14:40:16, Adrian Bunk wrote to All <=-
> >
> > AB> If one function calls another function you have to add the stack
> > AB> usages.
> >
> > these few may do that, i bet.
> > 0xc02bb528 huft_build: 1432
> > 0xc02bb954 huft_build: 1432
> > 0xc02bc1c4 inflate_dynamic: 1312
> > 0xc02bc2ff inflate_dynamic: 1312
> > 0xc02bc082 inflate_fixed: 1168
> > 0xc02bc172 inflate_fixed: 1168
>
> Now what is interesting is these functions currently run with a 4KiB
> stack on every bootup. So unless they have callers with a
> significant stack footprint things are fine.
The longest call chain for these functions eats roughly 3.2k on i386
with allyesconfig. Measured with a statical code checker, not tested.
J?rn
--
Simplicity is prerequisite for reliability.
-- Edsger W. Dijkstra