On Thu, September 8, 2005 4:18 pm, Bill Davidsen said:
> Is "maintain your own operating system" really better in your mind? Does
> that sound like a viable alternative?
No, that's a false choice. You folks just need to convince your
distribution to apply the patches you "need" or create your ow
Bill Davidsen wrote:
It appears that Linus has decided that there are not going to be any
such from kernel.org. That's a bad thing for users, to choose between
obsolete and stable, but it's his kernel.
Most users are best served to stick with the latest kernel *from their
distro*. It's only
Horst von Brand wrote:
Just go and try to make some piece of ancient hardware work on some of the
propietary systems. /There/ you get no chance but "Oh, just change your
machine".
Is "maintain your own operating system" really better in your mind? Does
that sound like a viable alternative?
Willy Tarreau wrote:
Hi,
On Mon, Sep 05, 2005 at 12:12:56AM -0400, Sean wrote:
On Mon, September 5, 2005 12:03 am, Alex Davis said:
What if you don't have a choice? When someone comes to me with their
laptop
containing a built-in wireless card not natively supported by Linux, am I
supposed t
Jan Kiszka wrote:
2005/9/7, Bill Davidsen <[EMAIL PROTECTED]>:
Is there a technical reason ("hard to implement" is a practical reason)
why all stacks need to be the same size?
Because of
static inline struct thread_info *current_thread_info(void)
{
struct thread_info *ti;
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
On Thu, 8 Sep 2005 01:25:20 +0200, Jan Kiszka <[EMAIL PROTECTED]> said:
Jan> Yes, I can provide some numbers around atheros devices (10-20%
Jan> speed-up). And yes, I can explain why ndiswrapper suffers from
Are you comparing atheros Windows driver with ndiswrapper or madwifi
with ndiswrappe
--- Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Alex Davis wrote:
> >>Please don't tell me to "care for closed-source drivers".
> >
> > ndiswrapper is NOT closed source. And I'm not asking you to "care".
> >
> >
> >>I don't want the pain of debugging crashes on the machines which run
> >>unk
2005/9/7, Giridhar Pemmasani <[EMAIL PROTECTED]>:
> Jan Kiszka wrote:
>
> > Ndiswrapper is already slower than native drivers are, also due to
> > horribly implemented Windows drivers btw (the ndis model itself isn't
> > that bad, though).
>
> Do you have any evidence to back your claims? What te
Jan Kiszka wrote:
> Ndiswrapper is already slower than native drivers are, also due to
> horribly implemented Windows drivers btw (the ndis model itself isn't
> that bad, though).
Do you have any evidence to back your claims? What tests did you do to say
that ndiswrapper is slower than native dri
2005/9/7, Daniel Phillips <[EMAIL PROTECTED]>:
> On Wednesday 07 September 2005 15:52, Daniel Phillips wrote:
> Ah, there's another issue: an interrupt can come in when esp is on the ndis
> stack and above THREAD_SIZE, so do_IRQ will not find thread_info. Sorry,
> this one is nasty.
>
Oh, you al
2005/9/7, Daniel Phillips <[EMAIL PROTECTED]>:
> > > Is there a technical reason ("hard to implement" is a practical reason)
> > > why all stacks need to be the same size?
> >
> > Because of
> >
> > static inline struct thread_info *current_thread_info(void)
> > {
> > struct thread_info *ti
On Wednesday 07 September 2005 15:52, Daniel Phillips wrote:
Ah, there's another issue: an interrupt can come in when esp is on the ndis
stack and above THREAD_SIZE, so do_IRQ will not find thread_info. Sorry,
this one is nasty.
Regards,
Daniel
-
To unsubscribe from this list: send the line "un
> > Is there a technical reason ("hard to implement" is a practical reason)
> > why all stacks need to be the same size?
>
> Because of
>
> static inline struct thread_info *current_thread_info(void)
> {
> struct thread_info *ti;
> __asm__("andl %%esp,%0; ":"=r" (ti) : "" (~(THREAD_
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. P
2005/9/7, Bill Davidsen <[EMAIL PROTECTED]>:
> Jan Kiszka wrote:
> > 2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
> >
> >>Jan Kiszka wrote:
> >>
> >>
> >>>The only way I see is to switch stacks back on ndiswrapper API entry.
> >>>But managing all those stacks correctly is challenging, as you w
Jan Kiszka wrote:
2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging, as you will
likely not want to create a new stack on each switching point. Rathe
Alex Davis wrote:
Please don't tell me to "care for closed-source drivers".
ndiswrapper is NOT closed source. And I'm not asking you to "care".
I don't want the pain of debugging crashes on the machines which run unknown
code
in kernel space.
I'm not asking you to debug crashes. I'm simpl
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.
> >
On Wednesday 07 September 2005 00:16, Daniel Phillips wrote:
> ...as long as ->task and ->previous_esp are initialized,
> staying on the bigger stack looks fine (previous_esp is apparently used
> only for backtrace) ... just like do_IRQ.
Ahem, but let me note before somebody else does: it isn't in
On Tuesday 06 September 2005 21:59, Mark Lord wrote:
> Daniel Phillips wrote:
> > There are only two stacks involved, the normal kernel stack and your new
> > ndis stack. You save ESP of the kernel stack at the base of the ndis
> > stack. When the Windows code calls your api, you get the ndis ESP
On Tue, 2005-09-06 at 21:59 -0400, Mark Lord wrote:
> Daniel Phillips wrote:
> > There are only two stacks involved, the normal kernel stack and your new
> > ndis
> > stack. You save ESP of the kernel stack at the base of the ndis stack.
> > When
> > the Windows code calls your api, you get t
Daniel Phillips wrote:
There are only two stacks involved, the normal kernel stack and your new ndis
stack. You save ESP of the kernel stack at the base of the ndis stack. When
the Windows code calls your api, you get the ndis ESP, load the kernel ESP
from the base of the ndis stack, push the
On Tuesday 06 September 2005 18:28, Roland Dreier wrote:
> Daniel> There are only two stacks involved, the normal kernel
> Daniel> stack and your new ndis stack. You save ESP of the kernel
> Daniel> stack at the base of the ndis stack. When the Windows
> Daniel> code calls your ap
On Tue, 2005-09-06 at 18:36 -0400, Daniel Phillips wrote:
> But then how would thread_info->task on the irq stack ever get initialized?
>
> My "what for" question was re why interrupt routines even need a valid
> current. I see one answer out there on the web: statistical profiling. Is
> that
On Tue, 6 Sep 2005 18:19:45 -0400, Daniel Phillips <[EMAIL PROTECTED]> said:
Daniel> There are only two stacks involved, the normal kernel stack
Daniel> and your new ndis stack. You save ESP of the kernel stack
Sadly, that is not the case: Some drivers, especially USB drivers,
create multip
On Tuesday 06 September 2005 18:21, Andi Kleen wrote:
> On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
> > Andi, their stack will have to have a valid thread_info->task because
> > interrupts will use it. Out of interest, could you please explain what
> > for?
>
> No, with 4k interru
Daniel> There are only two stacks involved, the normal kernel
Daniel> stack and your new ndis stack. You save ESP of the kernel
Daniel> stack at the base of the ndis stack. When the Windows
Daniel> code calls your api, you get the ndis ESP, load the kernel
Daniel> ESP from the
On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
> Andi, their stack will have to have a valid thread_info->task because
> interrupts will use it. Out of interest, could you please explain what
> for?
No, with 4k interrupts run on their own stack with their own thread_info
Or rather
On Tuesday 06 September 2005 13:23, Giridhar Pemmasani wrote:
> Jan Kiszka wrote:
> > The only way I see is to switch stacks back on ndiswrapper API entry.
> > But managing all those stacks correctly is challenging,
There are only two stacks involved, the normal kernel stack and your new ndis
sta
On Tue, 6 Sep 2005, Jan Kiszka wrote:
> 2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
>> Jan Kiszka wrote:
>>
>>> The only way I see is to switch stacks back on ndiswrapper API entry.
>>> But managing all those stacks correctly is challenging, as you will
>>> likely not want to create a new s
2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
> Jan Kiszka wrote:
>
> > The only way I see is to switch stacks back on ndiswrapper API entry.
> > But managing all those stacks correctly is challenging, as you will
> > likely not want to create a new stack on each switching point. Rather,
>
>
On Tue, Sep 06, 2005 at 02:42:02PM -0400, linux-os (Dick Johnson) wrote:
> I think
... and we have clear winner for the most incredible statement made on l-k.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
On Tue, 6 Sep 2005, Giridhar Pemmasani wrote:
> Jan Kiszka wrote:
>
>> The only way I see is to switch stacks back on ndiswrapper API entry.
>> But managing all those stacks correctly is challenging, as you will
>> likely not want to create a new stack on each switching point. Rather,
>
> This is
Jan Kiszka wrote:
> The only way I see is to switch stacks back on ndiswrapper API entry.
> But managing all those stacks correctly is challenging, as you will
> likely not want to create a new stack on each switching point. Rather,
This is what I had in mind before I saw this thread here. I, in
2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
> Andi Kleen wrote:
>
> > AFAIK with interrupt stacks it shouldn't be a big issue to switch
> > to a private bigger stack. ndiswrapper just needs to have its own private
> > way to do "current" which accesses thread_info at the bottom of the stack.
On Mon, Sep 05, 2005 at 12:26:41AM -0400, Dave Jones wrote:
> As someone who gets to read a lot of bug reports from end-users,
> this thing is far from perfect judging by the number of tainted
> oopses I've seen, and not all of them look like stack size issues.
It would make sense to use 4KB pages
El Tue, 06 Sep 2005 17:32:57 +1000,
Nick Piggin <[EMAIL PROTECTED]> escribió:
> Are there still good reasons to have such a thing?
Bigger block sizes was one of their features.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 04 Sep 2005 at 15:49:11 +0100, Alan Cox wrote:
> The question is whether ndiswrapper can do stack switching itself. Since
> as I understand it the NT stack is way more than 8K.
W2K usable kernel stack is about two pages. I'm not clear whether
this is r
> Are there still good reasons to have such a thing?
I think so yes. It just doesn't make much sense to handle larger 64bit
setups with multiple GB of memory with 4K pages. While larger softpage
size will not increase TLB usage it will give you less cache use and in
general less cycles while acc
On Tue, 2005-09-06 at 09:13 +0200, Andi Kleen wrote:
> At some point we undoubtedly will need to increase it further,
> the logical point would be when Linux switches to larger softpage
> sizes.
Is this really a "when"?
Hugh and wli were both working on this and IIRC neither could
show enough
On Tuesday 06 September 2005 08:39, Denis Vlasenko wrote:
> I think one of the reasons is:
>
> "No matter how big stack is, there are always careless
> code which can overflow it. 4k, 8k, 64k (hypotetically),
> we still must keep stack size in mind when coding.
>
> So, since we already are writing
On Tuesday 06 September 2005 07:37, Andi Kleen wrote:
> Running with tight stack is just a fundamentally fragile configuration
> and will come back to bite you later. Even with 8k we regularly
> had overflows reported and with 4k it will be much worse.
I think one of the reasons is:
"No matter ho
Alan Cox <[EMAIL PROTECTED]> writes:
> On Sul, 2005-09-04 at 07:51 -0700, Alex Davis wrote:
> > I'm not asking you to debug crashes. I'm simply requesting that the
> > kernel stack size situation remain as it is: with 8K as the default
> > and 4K configurable.
>
> How about the relevant question
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
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
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 tain
On Sul, 2005-09-04 at 07:51 -0700, Alex Davis wrote:
> I'm not asking you to debug crashes. I'm simply requesting that the
> kernel stack size situation remain as it is: with 8K as the default
> and 4K configurable.
How about the relevant question - why hasn't someone fixed ndiswrapper
yet - its
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 05, 2005 at 12:47:03AM -0400, Sean wrote:
[...]
> > But the real crux of the argument here is not whether or not people should
> > ever use binary-only drivers, it's whether the open source kernel
> > developers should spend any time worrying
Willy Tarreau wrote (ao):
> So you're both half-right from your point of view. But you're both half-wrong
> too : no, people can't always choose, and no, people who don't choose their
> laptop are not impacted by development kernels. So let's turn the page and
> wait for a stable kernel.
If the co
On 9/5/05, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Except that someone has to maintain the patch, because with the speed the
> kernel is changing, a patch against 2.6.14 will not work on 2.6.15.
Indeed. It has to be maintained in tree as well and I don't see any
justification for making mainlin
On Mon, September 5, 2005 2:04 am, Willy Tarreau said:
> They don't mind. Those people install Checkpoint on Linux. A product of
> which previous releases were even incompatible with security updates !
Heh.. well all the power to them. Still no reason for an open source
developer to waste one se
On Mon, Sep 05, 2005 at 01:31:29AM -0400, Sean wrote:
> On Mon, September 5, 2005 1:01 am, Willy Tarreau said:
>
> > But how do you think Linux has penetrated the enterprise market ???
> > We all have put dual boots on every windows machine we had access to,
> > eventhough this was clearly forbidd
On Mon, September 5, 2005 1:01 am, Willy Tarreau said:
> But how do you think Linux has penetrated the enterprise market ???
> We all have put dual boots on every windows machine we had access to,
> eventhough this was clearly forbidden. And after repeatedly showing
> to the staff that you saved t
On Mon, Sep 05, 2005 at 12:47:03AM -0400, Sean wrote:
> On Mon, September 5, 2005 12:36 am, Willy Tarreau said:
>
> > Well, to be fair, most laptop users today are in companies which provide
> > them with the model the staff has chosen for all the employees. And
> > employees
> > try to install Li
Hi Dave,
On Mon, Sep 05, 2005 at 12:26:41AM -0400, Dave Jones wrote:
(...)
> A lot of users look at it as nirvana. I've seen users report bugs against
> ancient kernels, that are extremely likely to be fixed in later kernels,
> yet they're unwilling to move to a newer kernel due to them being tied
On Mon, September 5, 2005 12:36 am, Willy Tarreau said:
> Well, to be fair, most laptop users today are in companies which provide
> them with the model the staff has chosen for all the employees. And
> employees
> try to install Linux on them anyway. That's how you end up with things
> like
> ndi
Hi,
On Mon, Sep 05, 2005 at 12:12:56AM -0400, Sean wrote:
> On Mon, September 5, 2005 12:03 am, Alex Davis said:
> >
> > What if you don't have a choice? When someone comes to me with their
> > laptop
> > containing a built-in wireless card not natively supported by Linux, am I
> > supposed to tel
On Sun, Sep 04, 2005 at 08:41:58PM -0700, Alex Davis wrote:
> It will never be 'appropriate' if the system doesn't somehow work on Joe's
> hardware. We currently have something that works.
"works".
As someone who gets to read a lot of bug reports from end-users,
this thing is far from perfect
On Mon, September 5, 2005 12:03 am, Alex Davis said:
>
> What if you don't have a choice? When someone comes to me with their
> laptop
> containing a built-in wireless card not natively supported by Linux, am I
> supposed to tell them "go buy a Linux-supported card" when there's a way
> I can make
--- Sean <[EMAIL PROTECTED]> wrote:
> On Sun, September 4, 2005 11:41 pm, Alex Davis said:
>
> > It will never be 'appropriate' if the system doesn't somehow work on Joe's
> > hardware. We currently have something that works. In my opinion it's
> > pointless to take that away. The manufacturers
On Sep 4, 2005, at 23:41:58, Alex Davis wrote:
--- Sean <[EMAIL PROTECTED]> wrote:
It's not a philosophical issue, it's what Linux _is_: an open source
operating system! That's what the developers are working on; not your
half-baked vision.
Um, ever hear of 'compromise'?? All I'm saying is let
On Sun, September 4, 2005 11:41 pm, Alex Davis said:
> It will never be 'appropriate' if the system doesn't somehow work on Joe's
> hardware. We currently have something that works. In my opinion it's
> pointless to take that away. The manufacturers will still stone-wall us
> regardless of ndiswra
--- Sean <[EMAIL PROTECTED]> wrote:
> On Sun, September 4, 2005 10:29 pm, Alex Davis said:
>
> > Linux isn't just used by kernel developers. It's that attitude that
> > helps insure Linux will always have a small userbase. Lack of numbers
> > just gives the manufacturers another reason not to c
On Sun, September 4, 2005 10:29 pm, Alex Davis said:
> Linux isn't just used by kernel developers. It's that attitude that
> helps insure Linux will always have a small userbase. Lack of numbers
> just gives the manufacturers another reason not to care about us. Joe
> User doesn't care about our p
--- Sean <[EMAIL PROTECTED]> wrote:
> On Sun, September 4, 2005 10:00 pm, Alex Davis said:
> > Dave Jones wrote:
> >>- NDISwrapper / driverloader.
> >> (Shock, horror - no-one cares).
> >
> > Shock, horror. Someone DOES care: everyone who uses ndiswrapper or
> > driverloader, whether they know
On Sun, September 4, 2005 10:00 pm, Alex Davis said:
> Dave Jones wrote:
>>- NDISwrapper / driverloader.
>> (Shock, horror - no-one cares).
>
> Shock, horror. Someone DOES care: everyone who uses ndiswrapper or
> driverloader, whether they know it or not. Are you proposing that
> we punish the end
Dave Jones wrote:
>- NDISwrapper / driverloader.
> (Shock, horror - no-one cares).
Shock, horror. Someone DOES care: everyone who uses ndiswrapper or
driverloader, whether they know it or not. Are you proposing that
we punish the end-users because of the obstinence of the hardware
manufacturers?
On Mon, 5 Sep 2005, Adrian Bunk wrote:
> How do you put pressure on hardware manufacturers for getting them to
> release the specs?
>
> If they are able to write "supported by Linux" on their products anyway
> because there's a driver that runs under NdisWrapper?
that's specious... they can pu
On Sun, Sep 04, 2005 at 06:30:29PM -0700, Alex Davis wrote:
> >The NdisWrapper FAQ already tells you that you need a patch for some of
> >the binary-only Windows drivers that require more than 8kB stacks.
> >
> >And the fact that NdisWrapper is mostly working hinders the development
> >of open so
>The NdisWrapper FAQ already tells you that you need a patch for some of
>the binary-only Windows drivers that require more than 8kB stacks.
>
>And the fact that NdisWrapper is mostly working hinders the development
>of open source drivers for this hardware.
If the hardware manufacturer won't gi
Bas Westerbaan <[EMAIL PROTECTED]> 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 stack
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 situ
> > 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 modul
On Sun, Sep 04, 2005 at 04:23:04AM -0400, Lee Revell wrote:
> On Sun, 2005-09-04 at 09:36 +0200, Stefan Smietanowski wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Lee Revell wrote:
> > > On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote:
> > >
> > >>4Kb kernel stacks are
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 ndiswrapp
Guillaume Chazarain wrote:
Just a thought : why couldn't ndiswrapper set apart some piece
of memory and use it as the stack by changing the esp register
before executing windows code.
Like http://article.gmane.org/gmane.linux.drivers.ndiswrapper.general/4737
It's dirty, I know, but after all th
> 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
c
* Stefan Smietanowski ([EMAIL PROTECTED]) wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Alex Davis wrote:
> >>Please don't tell me to "care for closed-source drivers".
> >
> > ndiswrapper is NOT closed source. And I'm not asking you to "care".
>
> While ndiswrapper might not be c
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 i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Davis wrote:
>>Please don't tell me to "care for closed-source drivers".
>
> ndiswrapper is NOT closed source. And I'm not asking you to "care".
While ndiswrapper might not be closed source, I would not call the
windows driver it loads open sou
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
>Please don't tell me to "care for closed-source drivers".
ndiswrapper is NOT closed source. And I'm not asking you to "care".
>I don't want the pain of debugging crashes on the machines which run unknown
>code
>in kernel space.
I'm not asking you to debug crashes. I'm simply requesting that the
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 qu
Adrian Bunk wrote (ao):
> 4Kb kernel stacks are the future on i386, and it seems the problems it
> initially caused are now sorted out.
>
> Does anyone knows about any currently unsolved problems?
>
> I'd like to:
> - get a patch into on of the next -mm kernels that unconditionally
> enables 4
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
2005/9/4, Lee Revell <[EMAIL PROTECTED]>:
> On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote:
> > 4Kb kernel stacks are the future on i386, and it seems the problems it
> > initially caused are now sorted out.
> >
> > Does anyone knows about any currently unsolved problems?
>
> ndiswrapper
Ju
On Sun, 2005-09-04 at 09:36 +0200, Stefan Smietanowski wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Lee Revell wrote:
> > On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote:
> >
> >>4Kb kernel stacks are the future on i386, and it seems the problems it
> >>initially caused are n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lee Revell wrote:
> On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote:
>
>>4Kb kernel stacks are the future on i386, and it seems the problems it
>>initially caused are now sorted out.
>>
>>Does anyone knows about any currently unsolved problems?
>
On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote:
> 4Kb kernel stacks are the future on i386, and it seems the problems it
> initially caused are now sorted out.
>
> Does anyone knows about any currently unsolved problems?
ndiswrapper
-
To unsubscribe from this list: send the line "unsubscri
Adrian Bunk wrote:
>4Kb kernel stacks are the future on i386, and it seems the problems it
>initially caused are now sorted out.
>
>Does anyone knows about any currently unsolved problems?
>
>I'd like to:
>- get a patch into on of the next -mm kernels that unconditionally
> enables 4KSTACKS
>- i
Hello
Adrian Bunk wrote:
> 4Kb kernel stacks are the future on i386, and it seems the problems it
> initially caused are now sorted out.
>
> Does anyone knows about any currently unsolved problems?
>
> I'd like to:
> - get a patch into on of the next -mm kernels that unconditionally
> enables
On Friday September 2, [EMAIL PROTECTED] wrote:
> On Thu, Sep 01, 2005 at 10:33:56PM -0700, Chris Wedgwood wrote:
> > On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote:
> >
> > > 4Kb kernel stacks are the future on i386, and it seems the problems
> > > it initially caused are now sorted
On Thu, Sep 01, 2005 at 10:33:56PM -0700, Chris Wedgwood wrote:
> On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote:
>
> > 4Kb kernel stacks are the future on i386, and it seems the problems
> > it initially caused are now sorted out.
>
> Not entirely.
>
> XFS when mixed with raid/lvm/
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 spe
On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote:
> 4Kb kernel stacks are the future on i386, and it seems the problems
> it initially caused are now sorted out.
Not entirely.
XFS when mixed with raid/lvm/nfs still blows up. It's probably not
alone in this respect but worse than ext2
Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> > > > > NB: gcc 3.4.3 can use excessive stack in degenerate cases, so please
> > > > > include gcc version in your reports.
> > > >
> > > > But this can't occur in the kernel.
> > >
> > > It can. I saw the OOPS myself.
> > > One of the functions in cryp
> > > > NB: gcc 3.4.3 can use excessive stack in degenerate cases, so please
> > > > include gcc version in your reports.
> > >
> > > But this can't occur in the kernel.
> >
> > It can. I saw the OOPS myself.
> > One of the functions in crypto/wp512.c was compiled with 3k+ stack usage.
>
> Stran
On Wed, Jun 08, 2005 at 03:13:09PM +0300, Denis Vlasenko wrote:
> On Wednesday 08 June 2005 14:12, Adrian Bunk wrote:
> > On Wed, Jun 08, 2005 at 01:39:56PM +0300, Denis Vlasenko wrote:
> > >...
> > > NB: gcc 3.4.3 can use excessive stack in degenerate cases, so please
> > > include gcc version in
99 matches
Mail list logo
