ndiswrapper and driverloader will not work reliably with 4k stacks.
This is because of the Windoze drivers they use, to which, obviously,
they do not have the source. Since quite a few laptops have built-in
wireless cards by companies who will not release an open-source driver,
or won't release specs, ndiswrapper and driverloader are the only way
to get these cards to work.
Please don't tell me to "get a linux-supported wireless card". I don't
want the clutter of an external wireless adapter sticking out of my laptop,
nor do I want to spend money on a card when I have a free and working solution.
Thank you.
-Alex
I code, therefore I am
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Friday 02 September 2005 09:08, Alex Davis wrote:
> ndiswrapper and driverloader will not work reliably with 4k stacks.
> This is because of the Windoze drivers they use, to which, obviously,
> they do not have the source. Since quite a few laptops have built-in
> wireless cards by companies who will not release an open-source driver,
> or won't release specs, ndiswrapper and driverloader are the only way
> to get these cards to work.
> Please don't tell me to "get a linux-supported wireless card". I don't
> want the clutter of an external wireless adapter sticking out of my laptop,
> nor do I want to spend money on a card when I have a free and working solution.
Please don't tell me to "care for closed-source drivers". I don't
want the pain of debugging crashes on the machines which run unknown code
in kernel space.
IOW, if you run closed source modules - it's _your_ problem, not ours.
--
vda
On Sunday 04 September 2005 08:49, Denis Vlasenko wrote:
> On Friday 02 September 2005 09:08, Alex Davis wrote:
> > ndiswrapper and driverloader will not work reliably with 4k stacks.
> > This is because of the Windoze drivers they use, to which, obviously,
> > they do not have the source. Since quite a few laptops have built-in
> > wireless cards by companies who will not release an open-source driver,
> > or won't release specs, ndiswrapper and driverloader are the only way
> > to get these cards to work.
> > Please don't tell me to "get a linux-supported wireless card". I don't
> > want the clutter of an external wireless adapter sticking out of my laptop,
> > nor do I want to spend money on a card when I have a free and working solution.
>
> Please don't tell me to "care for closed-source drivers". I don't
> want the pain of debugging crashes on the machines which run unknown code
> in kernel space.
>
> IOW, if you run closed source modules - it's _your_ problem, not ours.
> --
There is no logic to the above statement. We know when a kernel is tainted and
do not try hard to debug problems when tainted . We also know that ndiswrapper
and friends _currently_ let people use hardware that otherwise would have to run
MS stuff. We know that 4K stacks hurt the above. Do we really want to break working
configs just to enforce 4K stacks? How does it hurt to make 4K the default and
allow 8K? What _might_ make sense is to make 8K a reason to taint the kernel.
Ed Tomlinson
On Sunday 04 September 2005 7:49 am, Denis Vlasenko wrote:
> On Friday 02 September 2005 09:08, Alex Davis wrote:
> > ndiswrapper and driverloader will not work reliably with 4k stacks.
> > This is because of the Windoze drivers they use, to which, obviously,
> > they do not have the source. Since quite a few laptops have built-in
> > wireless cards by companies who will not release an open-source driver,
> > or won't release specs, ndiswrapper and driverloader are the only way
> > to get these cards to work.
> > Please don't tell me to "get a linux-supported wireless card". I don't
> > want the clutter of an external wireless adapter sticking out of my
> > laptop, nor do I want to spend money on a card when I have a free and
> > working solution.
>
> Please don't tell me to "care for closed-source drivers". I don't
> want the pain of debugging crashes on the machines which run unknown code
> in kernel space.
>
> IOW, if you run closed source modules - it's _your_ problem, not ours.
> --
> vda
> -
No one is asking you to 'care' about our problems running a notebook with a
closed source driver under ndiswrapper. We aren't asking you to debug
problems with them either. All we're asking is for you to not go out of your
way to break existing working machines, and make it difficult to run Linux on
them. You are talking about knowingly removing an option that allows many
machines to currently run without problems, some of them for reasons other
than closed source code.
If you want 4k stacks to be the default, I have no problem with that. If you
want to rip out the provision for 8k stacks to be selectable at build time,
that is a different issue entirely.
Paul
On 9/4/05, Paul Misner <[email protected]> wrote:
> No one is asking you to 'care' about our problems running a notebook with a
> closed source driver under ndiswrapper.
Yes you are. You're asking for 4KSTACKS config option to maintained
and it is not something you get for free. Besides, if it is indeed
ripped out of mainline kernel, you can always keep it a separate patch
for ndiswrapper.
Pekka
> Yes you are. You're asking for 4KSTACKS config option to maintained
> and it is not something you get for free. Besides, if it is indeed
> ripped out of mainline kernel, you can always keep it a separate patch
> for ndiswrapper.
Though 4K stacks are used a lot, they probably aren't used on all
configurations yet. Other situations may arise where 8K stacks may be
preferred. It is too early to kill 8K stacks imho.
--
Bas Westerbaan
http://blog.w-nz.com/
GPG Public Keys: http://w-nz.com/keys/bas.westerbaan.asc
On Sun, Sep 04, 2005 at 07:12:33PM +0200, Bas Westerbaan wrote:
> > Yes you are. You're asking for 4KSTACKS config option to maintained
> > and it is not something you get for free. Besides, if it is indeed
> > ripped out of mainline kernel, you can always keep it a separate patch
> > for ndiswrapper.
>
> Though 4K stacks are used a lot, they probably aren't used on all
> configurations yet. Other situations may arise where 8K stacks may be
> preferred. It is too early to kill 8K stacks imho.
Please name situations where 8K stacks may be preferred that do not
involve binary-only modules.
> Bas Westerbaan
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
> > Though 4K stacks are used a lot, they probably aren't used on all
> > configurations yet. Other situations may arise where 8K stacks may be
> > preferred. It is too early to kill 8K stacks imho.
>
> Please name situations where 8K stacks may be preferred that do not
> involve binary-only modules.
I meant that there could be situations, which have not yet been found,
where it could be preferred to use 8K stacks instead of 4K. When you
switch from having 8K stacks as default to 4K stacks without
possibility for 8K stacks you'd possibly encounter these yet to be
found situations.
When on the other hand the 4K stacks are set as default, leaving the
option in, instead of removing it, these possible situations, when
found, could be resolved (temporarilly) by switching back to 8K
stacks.
After a while having 4K stacks as default would be a better time to
decide whether to remove the option or not instead of now.
--
Bas Westerbaan
http://blog.w-nz.com/
GPG Public Keys: http://w-nz.com/keys/bas.westerbaan.asc
On Sun, Sep 04, 2005 at 10:13:10PM +0200, Bas Westerbaan wrote:
> > > Though 4K stacks are used a lot, they probably aren't used on all
> > > configurations yet. Other situations may arise where 8K stacks may be
> > > preferred. It is too early to kill 8K stacks imho.
> >
> > Please name situations where 8K stacks may be preferred that do not
> > involve binary-only modules.
>
> I meant that there could be situations, which have not yet been found,
And the boogeyman might really exist too.
This is just hypotetical hand-waving.
> where it could be preferred to use 8K stacks instead of 4K. When you
> switch from having 8K stacks as default to 4K stacks without
> possibility for 8K stacks you'd possibly encounter these yet to be
> found situations.
Fedora kernels have been built with 4K stacks for a long time.
(Since even before the option went upstream). The only things that
have been reported to have problems with 4KB stacks are..
- NDISwrapper / driverloader.
(Shock, horror - no-one cares).
- XFS when used in conjunction with RAID
Fixed now ? (Though Neil Brown does have a pending patch for md
to make that use less stack, which will also help).
- Reiser4
Fixed 'soon'.
> When on the other hand the 4K stacks are set as default, leaving the
> option in, instead of removing it, these possible situations, when
> found, could be resolved (temporarilly) by switching back to 8K
> stacks.
>
> After a while having 4K stacks as default would be a better time to
> decide whether to remove the option or not instead of now.
This is what was proposed not long after the option got merged.
"After a while" has passed by quite a stretch.
Dave
On Sul, 2005-09-04 at 09:30 -0400, Ed Tomlinson wrote:
> MS stuff. We know that 4K stacks hurt the above. Do we really want to break working
> configs just to enforce 4K stacks? How does it hurt to make 4K the default and
> allow 8K? What _might_ make sense is to make 8K a reason to taint the kernel.
The question is whether ndiswrapper can do stack switching itself. Since
as I understand it the NT stack is way more than 8K. Is there anything
else needed so it (and perhaps in future other 'hard cases') can handle
stacks themselves. We have seperate IRQ stack handling already which
should also help this.
So what is needed to make it go away - specific technical items or just
the persuasive effect of having to fix it ?
Adrian Bunk <[email protected]> writes:
> Please name situations where 8K stacks may be preferred that do not
> involve binary-only modules.
How about NFS-exporting a filesystem on LVM atop md? I believe it has
been mentioned before in discussions that 8k stacks are strongly
recommended in this case. Are those issues solved?
Thorild Sel?n
Datorf?reningen Update / Update Computer Club, Uppsala, SE
On Sep 5, 2005, at 18:32:32, Thorild Selen wrote:
> Adrian Bunk <[email protected]> writes:
>> Please name situations where 8K stacks may be preferred that do not
>> involve binary-only modules.
>
> How about NFS-exporting a filesystem on LVM atop md? I believe it has
> been mentioned before in discussions that 8k stacks are strongly
> recommended in this case. Are those issues solved?
I think the worst overflow case anyone found was
nfs=>xfs=>lvm=>dm=>scsi, if
someone has such a configuration, please retest with current -mm or
similar.
I think there are several patches in there to resolve the excessive
stack
usage and a few to do some sort of bio chaining (Instead of recursive
calls).
I don't remember what underlying hardware was behind the SCSI, but I
suspect
something like iSCSI or USB would push some extra stack in there for
stress
testing.
Cheers,
Kyle Moffett
--
I have yet to see any problem, however complicated, which, when you
looked at
it in the right way, did not become still more complicated.
-- Poul Anderson
Dave Jones wrote:
> On Sun, Sep 04, 2005 at 10:13:10PM +0200, Bas Westerbaan wrote:
> > > > Though 4K stacks are used a lot, they probably aren't used on all
> > > > configurations yet. Other situations may arise where 8K stacks may be
> > > > preferred. It is too early to kill 8K stacks imho.
> > >
> > > Please name situations where 8K stacks may be preferred that do not
> > > involve binary-only modules.
> >
> > I meant that there could be situations, which have not yet been found,
>
> And the boogeyman might really exist too.
> This is just hypotetical hand-waving.
>
> > where it could be preferred to use 8K stacks instead of 4K. When you
> > switch from having 8K stacks as default to 4K stacks without
> > possibility for 8K stacks you'd possibly encounter these yet to be
> > found situations.
>
> Fedora kernels have been built with 4K stacks for a long time.
> (Since even before the option went upstream). The only things that
> have been reported to have problems with 4KB stacks are..
>
> - NDISwrapper / driverloader.
> (Shock, horror - no-one cares).
Actually, people who want to run Linux on laptops instead of MS care a
whole bunch! And not everyone has a committment from their employer to
provide Linux compatible hardware, or the personal funds to spend extra
to buy their own instead of getting a bargain laptop which may not be
fully supported. 8KSTACKS is in and working, you are proposing to break
Linux on a number of machines just to satisfy some personal distaste for
the code, not because there is neat new code which fails to work with 8K
stacks.
You must have something more useful to work on, which would ADD value to
the kernel instead of breaking existing installations. Ripping out petty
stuff which works is a waste of your time and talent, please find
something better to do. Perhaps devise a way for programs like
ndiswrapper to provide their own stack, for instance.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
At 12:38 PM 9/7/2005 -0400, Bill Davidsen wrote:
>You must have something more useful to work on, which would ADD value to
>the kernel instead of breaking existing installations. Ripping out petty
>stuff which works is a waste of your time and talent, please find
>something better to do.
Ahem. Please...
>Perhaps devise a way for programs like ndiswrapper to provide their own
>stack, for instance.
...follow your own suggestion instead of hammering someone else.
I've seen some discussion. More of that, and less of this please.
-Mike
Mike Galbraith wrote:
> At 12:38 PM 9/7/2005 -0400, Bill Davidsen wrote:
>
>> You must have something more useful to work on, which would ADD value
>> to the kernel instead of breaking existing installations. Ripping out
>> petty stuff which works is a waste of your time and talent, please
>> find something better to do.
>
>
> Ahem. Please...
>
>> Perhaps devise a way for programs like ndiswrapper to provide their
>> own stack, for instance.
>
>
> ...follow your own suggestion instead of hammering someone else.
>
> I've seen some discussion. More of that, and less of this please.
Frankly this should be done by someone who really understands the code,
and considering the time it's likely to take it would probably be (a)
someone with a desparate need, (b) someone rich or retired who doesn't
work for a living and has the time, or (c) someone who works for a
company which sells Linux distributions and therefore could get paid to
do this. That lets me out on all counts, I would resent wasting the time
to patch 8KSTACKS back in as a patch, but I could do that to make
laptops useful. As Andi pointed out some architectures can't run 4k
stacks, and at the memory sizes people typically use there would
probably be a performance gain to do memory in 8k or larger blocks anyway.
I just see this as a large hassle for many laptop users and people with
unconverted drivers, and no significant gain for most. 4k stacks work
fine on most machines, but some people just can't use them.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
I have a question about the Large File Support using Linux and glibc 2.3
on a 32-Bit machine. What's the correct limit for the file size and the
file system using LFS (just for the kernel, not to mention filesystem
limits etc)?
I found two references:
"The 2.6 kernel imposes its own limits on the size of files and file
systems handled by it. These are as follows:
- file size: On 32-bit systems, files may not exceed the size of 2 TB.
- file system size: File systems may be up to 2e73 bytes large. However,
this limit is still out of reach for the currently available hardware."
Source:
http://www.novell.com/documentation/suse91/suselinux-adminguide/html/apas04.html
"Kernel 2.6: For both 32-bit systems with option CONFIG_LBD set and for
64-bit systems: The size of a file system is limited to 2e73 (far too
much for today). On 32-bit systems (without CONFIG_LBD set) the size of
a file is limited to 2 TiB. Note that not all filesystems and hardware
drivers might handle such large filesystems."
Source: http://www.suse.de/~aj/linux_lfs.html
I think it's 2TB for the file size and 2e73 for the file system, but I
don't understand the second reference and the part about the CONIFG_LBD.
What is exactly the CONFIG_LBD option?
On Thu, 08 Sep 2005 21:27:42 +0200
Andreas Baer <[email protected]> wrote:
> I think it's 2TB for the file size and 2e73 for the file system, but
> I don't understand the second reference and the part about the
> CONIFG_LBD. What is exactly the CONFIG_LBD option?
> -
This is "Support for Large Block Devices" under Device Drivers/Block
Devices:
CONFIG_LBD:
Say Y here if you want to attach large (bigger than 2TB) discs to
your machine, or if you want to have a raid or loopback device
bigger than 2TB. Otherwise say N.
The "2e73" refers to 2 to the exponent 73 bytes in size. Huge :-)
Mike Houston wrote:
> On Thu, 08 Sep 2005 21:27:42 +0200
> Andreas Baer <[email protected]> wrote:
>
>
>
>>I think it's 2TB for the file size and 2e73 for the file system, but
>>I don't understand the second reference and the part about the
>>CONIFG_LBD. What is exactly the CONFIG_LBD option?
>>-
>
>
> This is "Support for Large Block Devices" under Device Drivers/Block
> Devices:
>
> CONFIG_LBD:
>
> Say Y here if you want to attach large (bigger than 2TB) discs to
> your machine, or if you want to have a raid or loopback device
> bigger than 2TB. Otherwise say N.
>
> The "2e73" refers to 2 to the exponent 73 bytes in size. Huge :-)
So in other words, both the file size and the file system limit is 2e73
using CONFIG_LBD option, right? And 2TB are always possible?
Sorry, but I need to get pretty sure.
> -
> 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/
>
>