On Thu, 7 Sep 2000, Henry Worth wrote:
> With all the talk of improving Linux's scalability to
> large-scale SMP and ccNUMA platforms -- including efforts
> at several HW companies and now OSDL forming to throw
> hardware at the effort -- is there any move afoot to
> coordinate these efforts?
Hello!
> I believe that the DoS is that the path through the kernel turns out to be
> long and that a lot of these packets will bring a machine to its knees.
It is not longer than path for any other kind of packet.
In the reported case it is much shorter. 8)
Apparently, you try to remind about
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote:
>(1) Rules.make had a load of ugly code to translate from the source tree
>to the symlink farm. This code had plenty of bugs and race conditions
>(e.g. if two subdirectories have the same MOD_LIST_NAME and make
>runs in parallel).
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote:
> Hello!
> > - Could there be some kind of handling for such packets (meaning TCP packets
> > reaching at an unused port with ACK bit set - with no previous SYN etc packet)
> > to avoid such DoS attacks? Is the same happening to newer kernels? If
On Tue, Sep 05, 2000 at 02:27:02PM -0700, [EMAIL PROTECTED] wrote:
> I was wondering if any one knows of a way around the following problem,
> and I wanted to warn people considering 3ware controllers as a storage
> solution.
>
> I talked to 3ware already and they don't have a solution.
>
> The
Hello!
> Well, now GCC does CSE across "asm" and will eliminate memory loads,
> even though it may not move them! I suspect it always did CSE across
> "asm" and we just never got hit by the bug.
dummy_lock trick is equivalent to "memory" clobber.
So that there is no real bug.
Alexey
-
To
On Mon, 4 Sep 2000, Lars Knudsen wrote:
> I have have serious problems using a specific Quantum disk connected
> to a Promise ATA/100 controller. The disk causing problems is the
> QUANTUM FIREBALLlct10 30. The disk simply locks up the machine solid
> during boot at the point where it should
On Thu, 7 Sep 2000, Jeff V. Merkey wrote:
> [...] so it takes me longer to ponder and digest things -- [...]
i'll quote a few 'digesting' comments of you:
- about the Linux networking code:
" [...] what a mess indeed. "
- about Linux itself:
" The lack of a Kernel Debugger and other basic
Also sprach dean gaudet:
} On Wed, 6 Sep 2000, Linus Torvalds wrote:
}
} > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we
} > fixed it now several times, and I was always wrong.
}
} obpainintheass: haven't you anti-debugger-religion folks been claiming
} that if you
On Thu, Sep 07, 2000 at 12:25:41PM -0400, Claude LeFrancois (LMC) wrote:
>
> cardmgr[386]: executing: './network start 3c575_cb'
> cardmgr[386]: + usage: ifup
> cardmgr[386]: start cmd exited with status 1
The new hot plug PCI interface does not provide a method for passing
On Thu, 7 Sep 2000, Alexander Viro wrote:
> On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
> > scale in the end. We'll either see forking, see another OS like FreeBSD
> > fill the void, or (worst case) Solaris.
>
> Somehow I doubt that arguments from marketshare/field circus/etc. peppered
> with
On Thu, 31 Aug 2000, Alan Cox wrote:
> > /lib/modules//.config is a big step up from the current situation
> > and I'm grateful. But I do want /proc/config.gz in the kernel.
>
> So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> If you dont even know what file you
Em Thu, Sep 07, 2000 at 01:14:24PM +0200, Torben Mathiasen escreveu:
> Linus and others,
>
> Please take a look at the patch attached, and consider applying. It fixes
> some of the OOM issues with sd.c and does general cleanups (module_init/exit,
> removing casts, etc.).
>
> I just searched the
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Common Subexpression Elimination.
>
>If the compiler sees an expression equivalent to one it evaluated
>earlier, there is no need to evaluate it a second time.
>
>So "a = x+x; b = x+x" will evaluate "x+x" just once and store it twice.
I didn't know the
> "andrea" == Andrea Arcangeli <[EMAIL PROTECTED]> writes:
andrea> On Thu, 7 Sep 2000, Jamie Lokier wrote:
>> Well, now GCC does CSE across "asm" and will eliminate memory loads,
andrea> What is "CSE"?
Common Subexpresion Elimination. You can get a lot of info in "The
Dragon book".
Andrea Arcangeli wrote:
> >Well, now GCC does CSE across "asm" and will eliminate memory loads,
>
> What is "CSE"?
Common Subexpression Elimination.
If the compiler sees an expression equivalent to one it evaluated
earlier, there is no need to evaluate it a second time.
So "a = x+x; b = x+x"
> And what's up with the explosion of directories?
The existing system had at least three problems:
(1) Rules.make had a load of ugly code to translate from the source tree
to the symlink farm. This code had plenty of bugs and race conditions
(e.g. if two subdirectories have the same
On Thu, 7 Sep 2000, Horst von Brand wrote:
> Alexander Viro <[EMAIL PROTECTED]> said:
>
> [...]
>
> > BTW, tools are really nice, but I wouldn't call conventional debuggers
> > a-la [asg]db good ones. I've been _very_ impressed by Acid - after gdb it
> > feels like a switch from MCR to sh.
Ingo Molnar wrote:
>
> On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
>
> > [...] Hardware problems require a debugger or logic analyzer to fix.
> > [...]
>
> 'kernel problems need a kernel debugger to fix'. How wrong.
It says "hardware problems" not "kernel problems". read it again.
:-)
Jeff
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>I tried it with two compilers, one older than yours and one newer:
So maybe I'm just been unlucky/lucky (depends on the point of view :) or
maybe we patched something I'm not aware of to make the kernel to compile
right.
>.ident "GCC: (GNU)
If you want to look at an existing source-code analyzer that works
hand-in-glove with compilers, to skim for good or bad ideas, take a look
at the LSE/SCA combo from the DECset tools. (Dunno if DECset is even
still available; I lost track of what went where as they were dicing up
the company.)
Ingo,
I did read it. You have to understand, I'm not a young guy but an old
man, so it takes me longer to ponder and digest things -- not because
I'm slower, but becasue I'm older. I used to blindy charge at anything
when a red flag was waved in front of my face in my youth. As I got
older,
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Yes, it does.
Nice.
>.ident "GCC: (GNU) 2.96 2724 (experimental)"
>
>>From the Red Hat 7 beta.
Ok.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
> [...] Hardware problems require a debugger or logic analyzer to fix.
> [...]
'kernel problems need a kernel debugger to fix'. How wrong.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Andrea Arcangeli wrote:
> >int *p;
> >int func()
> >{
> > int x;
> > x = *p;
> > __asm__ __volatile__ ("" : : : "memory");
> > x = *p;
> > return x;
> >}
>
> Defintely none difference here (-fstrict-aliasing doesn't change anything
> either).
>
> andrea@inspiron:~ > gcc -v
> Reading specs
On Wed, 6 Sep 2000, Linus Torvalds wrote:
> Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we
> fixed it now several times, and I was always wrong.
obpainintheass: haven't you anti-debugger-religion folks been claiming
that if you don't have a debugger you're forced to
Andrea Arcangeli wrote:
> Said that if your compiler puts the read before the spin_lock without the
> memory clobber, it is allowed to do that, and in such case you would proof
> it was a real world bug (not just a "documentation" one).
Yes, it does.
> Or maybe your testcase was a bit different
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Well, now GCC does CSE across "asm" and will eliminate memory loads,
What is "CSE"?
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>int *p;
>int func()
>{
> int x;
> x = *p;
> __asm__ __volatile__ ("" : : : "memory");
> x = *p;
> return x;
>}
>
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ > gcc -v
Reading specs from
Linus Torvalds wrote:
> Nope. "memory" fills that role too. Remember: "memory" doesn't actually
> say "this clobbers all memory". That would be silly: an asm that just
> wipes all memory would not be a very useful asm (or rather, it would have
> just _one_ use: "execve()"). So "memory" really
On Thu, 07 Sep 2000, George Athanassopoulos wrote:
Possibly post this message on the netfilter mailing list.
[EMAIL PROTECTED]
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> Ingo Molnar wrote:
> > > Your arguments are personal, not technical. [...]
> >
> > no, my arguments are technical, but are simply focused towards the
> > conceptual (horizontal) development of Linux, not the vertical
> > development of Linux
Jeff, please read Linus' mail for an explanation about the dangers of
kernel debuggers.
Ingo
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
>
> Ingo,
>
> KDB is a user mode debugger designed to debug user space apps that's
> been hacked to run with a driver. It's not designed as a
[EMAIL PROTECTED] wrote:
> Just hint. I remember the time when "memory" clobber option
> was _absent_ in gcc. And we managed to compile kernel with such gcc. 8)
> To all that I understand, "asm" (like function calls) implied barrier
> that time and constraints and clobber option were used only
What's the point of running depmod at the end of modules_install? The
System.map doesn't contain any versioned symbols so it just bitches about
everything as being undefined. (depmod needs a "-i" to temporarily ignore
versioning and it still bitches) And looking at the System.map is a bad way
Timur Tabi wrote:
> Well, if it really is just his hobby, then he shouldn't be chanting
> the "World Domination" mantra.
Why not? World Domination is my hobby too :-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Linus Torvalds wrote:
> Change it to something like
>
> __asm__("":"=r" (x):"0" (x));
>
> and the "volatile" should matter.
Yes it does. Without "volatile", the asm disappears :-)
> Not for memory references, perhaps. But for the movement issues.
The compiler isn't moving memory
I loose track at times Stephen -- sorry. I was talking about kgdb with
this statement.
:-)
Jeff
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Wed, Sep 06, 2000 at 09:44:54AM -0600, Jeff V. Merkey wrote:
> >
> > KDB is a user mode debugger designed to debug user space apps that's
> > been
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>
> It's ok for the compiler to do that (given we don't know what "volatile"
> means anyway :-). But it does have implications for spin_lock:
> spin_lock must say that it clobbers memory.
Yup. We should just fix that.
Linus
-
To
On Sun, Sep 03, 2000 at 02:59:43PM +0200, Pauline Middelink wrote:
>
> Anyway, linux-2.4.0-test7 wont boot on a Cyrix computer.
> test6 has no problems whatsoever and 7 stops right after
> 'Uncompressing kernel...'
>
> Kernel as always compiled for 586.
>
> Sounds familiar? Any solutions/tips?
On Wed, Sep 06, 2000 at 04:13:50PM -0400, James Simmons wrote:
>
>
> > > What video driver are you using? Fbcon or vgacon? If Fbcon which fbdev
> > > driver in particular?
> > >
> > This would be vgacon, having never figured out if it's even possible
> > to get framebuffers working on the
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>
> ps. There is a _clobber_ for memory, but no way to say "this asm _reads_
> arbitrary memory". __volatile__ may be filling that role though.
Nope. "memory" fills that role too. Remember: "memory" doesn't actually
say "this clobbers all memory". That
Linus Torvalds wrote:
> "volatile" should be equivalent to clobbering memory, although the gcc
> manual pages are certainly not very verbose on the issue.
It isn't. Try the following with/without the memory clobber:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : :
Andrea Arcangeli wrote:
> >>int a = *p;
> >>__asm__ __volatile__("" : :);
> >>a = *p;
> >>
> >> (to do two explicit reads)
> >
> >Sorry, that does just one read, kgcc (old stable gcc) and also with
> >gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
>
> I
On Thu, 7 Sep 2000, Jamie Lokier wrote:
> asm *__volatile__* seems to make no difference. I've tried a few things.
>
> Andrea Arcangeli wrote:
> > Maybe we can rely on the __volatile__ statement of the asm that will
> > enforce that if we write:
> >
> > *p = 0;
> > __asm__
** Reply to message from "J. Dow" <[EMAIL PROTECTED]> on Thu, 7 Sep 2000
02:50:37 -0700
> Aw, Tigran, give the kid his hobby, OK? We can try to bang some
> sense into his head and suggest ways his hobby could offer more
> satisfaction from good results achieved and make it more fun for
> the
Hello!
> tried to grep gcc but my gcc knowledge is too low to reverse engeneer the
> implement semantics of the "memory" clobber fast
Just hint. I remember the time when "memory" clobber option
was _absent_ in gcc. And we managed to compile kernel with such gcc. 8)
To all that I understand,
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>asm *__volatile__* seems to make no difference. I've tried a few things.
It makes a difference, see below.
>
>Andrea Arcangeli wrote:
>> Maybe we can rely on the __volatile__ statement of the asm that will
>> enforce that if we write:
>>
>> *p =
On Thu, 7 Sep 2000, Leonard N. Zubkoff wrote:
>I tried retrieving that file but was unsuccessful; is that the correct URL?
I guess I cut and pasted too much directories, sorry. I attached the file
since it's small.
>Is the fix simply moving the spin_unlock right before the call to
Hello,
I am using a 3CCFE575CT with a Compaq Armada under the kernel 2.4.0-test7
and pcmcia-3.1.19. I am running Mandrake 7.0. The problem concerns the
cardmgr and/or the 3c59x kernel module. When the pcmcia service starts, it
initializes the cardmgr, reads the sockets, installs the proper
On Thu, 7 Sep 2000, G. Hugh Song wrote:
> if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \
> -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \
> -o "$CONFIG_SMB_FS" != n ]; then
n vs "n" is my error.
However 'make menuconfig' works with just n. I know I should
Tigran Aivazian writes:
> On Thu, 7 Sep 2000, George Anzinger wrote:
> > I like this one better:
> >
> > "And I'm right. I'm always right, but in this case I'm just a bit more
> > right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000.
> >
>
> I like this one even better:
>
>
On Thu, 7 Sep 2000, Tigran Aivazian wrote:
>
> k) all swapout functions in mm/vmscan.c can be optimized by removing 'mm'
>argument. This part was reviewed by Rick van Riel and approved.
But they then get "mm" themselves anyway.
What's the point? With argument passing, on certain
Doug Gilbert and I ran across
some weirdness in the way the block device queues are plugged/unplugged.
It turned up with some benchmarks of the SCSI generics driver - with the new
queueing code, the generics driver is inserting requests into the same queue
that block device requests
On Thu, 7 Sep 2000, Andrea Arcangeli wrote:
> On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>
> >barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
> >"memory".
>
> I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
> memory (it looks necessary to
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > So it seems to be a bug at least in terms of timing. Unfortunately I
> > only got about 4 replies to the patches that touched 20+ drivers. I
> > suppose I should just hassle maintainers until they fix it or tell me
> > where I've gone wrong
Andi Kleen <[EMAIL PROTECTED]> wrote:
> This is far from a single CPU instruction between the test_bit and the
> set_bit. Even with a single CPU instruction you would need a cmpxchg with
> retry BTW, to handle the case of multiple CPUs entering the instruction at
> the same time. The easiest
On Thu, Sep 07, 2000 at 09:00:29AM -0700, Leonard N. Zubkoff wrote:
> WaitQueue_T WaitQueueEntry = { current, NULL };
> add_wait_queue(>CommandWaitQueue, );
> current->state = TASK_UNINTERRUPTIBLE;
> spin_unlock(_request_lock);
> schedule();
> current->state = TASK_RUNNING;
>
We had some problems booting 2.4.0-test7, and discovered that Linux fell
into a panic while parsing the MP Configuration table. After some debugging,
we found that there are 4 Busses entries:
Bus #0 is PCI
Bus #1 is PCI
Bus #18 is XPRESS
Bus #19 is EISA
Unfortunately, the XPRESS bus parsing
David Howells writes:
> I've done an implementation of some of the Win32 "system calls"
> in a kernel module in an attempt to speed up Wine.
Oh my. How dare you! I like it. :-)
> The preliminary benchmarks that I made, while not very real-world
> since I don't think I have managed to implement
Date: Thu, 7 Sep 2000 16:50:51 +0200 (CEST)
From: Andrea Arcangeli <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], Alan Cox <[EMAIL PROTECTED]>
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
Hi Leonard,
this night I (hopefully) finally spotted and
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
> Maybe we can rely on the __volatile__ statement of the asm that will
> enforce that if we write:
>
> *p = 0;
> __asm__ __volatile__("" : :);
> *p = 1;
>
> in the assembler we'll
On Thu, 7 Sep 2000, Franz Sirl wrote:
>In short terms:
>
>- __volatile__ assures that the code isn't reordered against other
>__volatile__ and isn't hoisted out of loops, nothing else
>- the "memory" clobber makes sure the asm isn't reordered against other
>memory accesses
Ok. That's all I
On Thu, 7 Sep 2000, Mike Jagdis wrote:
> > Q: Then why isn't kdb in the kernel?
> > A: Uh...
>
> More to the point, why don't the people that want a kernel
> debugger maintain kdb and simply drop in the patch when they
> need it? If Jeff releases his debugger will anyone care enough
> to
Hi,
In the past few days, a couple of our webservers (dual P3s)
have started to emit $SUBJECT into the kernel logs fairly
frequently:
Sep 7 06:41:04 web2 kernel: initial req->mss below 8
Sep 7 06:56:03 web2 last message repeated 18 times
Sep 7 07:56:04 web2 last message repeated 18 times
At 17:03 07.09.00, Andrea Arcangeli wrote:
>On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>
> >barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
> >"memory".
>
>I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
>memory (it looks necessary to make sure
On Thu, Sep 07, 2000 at 04:25:29PM +0100, David Howells wrote:
>
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> > But that's not race free on SMP. Two CPUs can set the bit in parallel
> > and you'll never notice. You would need at least a protecting spinlock
> > between the test bit and set bit (or
-test7 was the first one I tried that actually booted, the rest just froze.
I only tried 2 kernels. The first was compiled with
CONFIG_ALPHA_LEGACY_START_ADDRESS set to n, and the 2nd was with y.
First was -test6
when booting -test7, it can't find any IRQs for the PCI devices.
This is an
Andi Kleen <[EMAIL PROTECTED]> wrote:
> But that's not race free on SMP. Two CPUs can set the bit in parallel
> and you'll never notice. You would need at least a protecting spinlock
> between the test bit and set bit (or a cmpxchg on x86)
Are you sure? I understood that the "lock" prefix on
I just found out that gcc-2.96 won't compile glibc-2.1.93 or glibc-2.1.2 or
glibc-2.1.3 successfully whereas gcc-2.95.2 will. It bombs in a couple of
places.
I just downgraded my machine to 2.95.2 to prove the point. Guess I'll wait
for gcc-3.0.
Michael
Test
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Hi Linus,
This patch was reviewed by human kind for several hours and there was
found no fault in it.
It fixes:
a) bugfix to read_kmem() which currently can fail on low memory when it
should succeed (i.e. when it doesn't need that page)
b) nvram driver doesn't handle failures from
Hi Linus,
This patch (courtesy of Eric W. Biederman <[EMAIL PROTECTED]>) allows
the microcode driver to make the correct decision about patch revision
even if there were no update done by the BIOS at all.
Regards,
Tigran
--- linux/arch/i386/kernel/microcode.c Thu Aug 24 08:08:43 2000
+++
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
>"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the compiler doesn't delay to
write data to the
David Woodhouse wrote:
> But how much work would it require to do so? If your theoretical vendor of
> closed-source compiler backends were to believe that a shared lib of the
> GCC frontend would be legal, surely they'd just make it shared themselves,
> then use it as such? It's hardly a
Hello,
I am not sure if this is the right list to point out some linux TCP
implementation "weakness" but I think that something should be done
first at the kernel level and after with any other way (firewalling etc).
The problem:
I am using 2.0.38 and I am receiving lots of DoS attacks on one of
If it is the 2.2.16 scheduler & other linux'es have a bug.
The following code snippets can go into a tight loop.
while (p != _task)
{
if (can_schedule(p))
{
int weight = goodness(prev, p, this_cpu);
if (weight > c)
c = weight, next = p;
}
"make xconfig" failed in line 8 of fs/nls/Config.in.
---
#
# Native language support configuration
#
# msdos and Joliet want NLS
if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \
-o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \
Linus Torvalds wrote:
> Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that
> we fixed it now several times, and I was always wrong. Time for some
> reverse phychology:
>
> I'm sure this one doesn't fix the truncate bug either.
So far things look really promising here. No
David Woodhouse wrote:
> You cannot safely compile even 2.4 kernels with gcc-2.96 on any platform, as
> far as I'm aware. It's an insane thing to do. Use a sensible compiler.
Oh. I've been using gcc-2.96 with test7 for a while, no problems except
the ## warnings. Never occured to me that
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
> I have no axe to grind, but I do have a different view. I'm the 1 in 30
> million men born with an extra Y chromosone (a double YY), so you are
> pertially right there. DOuble YY males have a different brain structure
> -- the lymbic system in my
Alexander Viro <[EMAIL PROTECTED]> said:
[...]
> BTW, tools are really nice, but I wouldn't call conventional debuggers
> a-la [asg]db good ones. I've been _very_ impressed by Acid - after gdb it
> feels like a switch from MCR to sh. Small core providing a language with
> enough primitives to
> > Is it / will it be possible to run multiple, or at least two keyboards
> before the new linux console code in 2.5?
> It is a whole lot more complex than that.
> [snip]
> Consider a multihead enviroment with 2 users. Each VT is in
> console mode. One starts the X server. Automatically X
[viro]
> The _real_ problem is preprocessor abuse. BTW, could we schedule for
> 2.5 the following?
> * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
> branches just fine.
On Thu, Sep 07, 2000 at 02:44:26PM +0100, David Howells wrote:
>
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> > I did not see the lock. Where is it ?
>
> Well, on the bit functions set_bit() and test_and_clear_bit(), the macro
> inserts an appopriate locking instruction into the assembly.
But
"J. Dow" <[EMAIL PROTECTED]> said:
[...]
> The point is that WITH a debugger you have to take that step as well.
> A person without the self discipline to do that is still a child and should
> not be in this business. The debugger gives you a better picture of what
> is actually happening. If
> Is it / will it be possible to run multiple, or at least two keyboards
> before the new linux console code in 2.5?
XFree86 can use multiple keybaords. I don't think XF4.0 still supports USB
keyboards. Give them another 6 months or a year. By then they should
support them. As for the console
[EMAIL PROTECTED] wrote:
>
> On 6 Sep 2000, Linus Torvalds wrote:
> > In article <[EMAIL PROTECTED]>,
> > Jeff V. Merkey <[EMAIL PROTECTED]> wrote:
> I guarantee you that IT managers and CTOs do not share your enthusiasm for
> slow, correct coding when faced with their business being down,
Andi Kleen <[EMAIL PROTECTED]> wrote:
> I did not see the lock. Where is it ?
Well, on the bit functions set_bit() and test_and_clear_bit(), the macro
inserts an appopriate locking instruction into the assembly.
On the wait queue, the wait_queue structure includes
> I don't know too much
On Wed, 6 Sep 2000, Dan Hollis wrote:
> On Wed, 6 Sep 2000, Alan Cox wrote:
> > For things like driver debugging its the only way to work. Hardware simply does
> > not work like the manual says and no amount of Zen contemplation will ever
> > make you at one with a 3c905B ethernet card.
>
>
On Thu, Sep 07, 2000 at 02:28:36PM +0100, David Howells wrote:
> > I looked a bit over the code. Your Mutex classes do not look very SMP safe,
> > have they been tested with SMP ?
>
> Look carefully... It uses the atomic bit set/clear functions to modify the
> state, and the wait-queue carries
Andi Kleen <[EMAIL PROTECTED]> wrote:
> It could use a read-only-to-clients shared memory with some locking tricks.
You still have to be able to emulate WaitForMultipleObjects() which I think is
quite difficult from userspace. It can perhaps be done with signals, but that
then incurs costs in
With all the talk of improving Linux's scalability to
large-scale SMP and ccNUMA platforms -- including efforts
at several HW companies and now OSDL forming to throw
hardware at the effort -- is there any move afoot to
coordinate these efforts?
The LSE project at sourceforge seems to have
Igmar Palsenberg <[EMAIL PROTECTED]> writes:
> The 'problem' is a bunch of stupid American politics (excuse anyone
> American), than passed a law that all spam containing a remove adress is
> legal.
No, they haven't. Some bill passed the house (or senate, I can't
remember) but it hasn't been
On Thu, 7 Sep 2000, Boszormenyi Zoltan wrote:
>It contains code in arch/i386/mtrr.c that looks pretty much like
>my "64 bit MTRR" patch that was posted on lkml some time last year
>and makes use of the full 36 bit MTRR address and size on Intel and
>44 bits on AMD Athlon. BTW my patch contained
Ok, more bothersome irk. =|
test8-pre4 was the last kernel the pegasus driver worked in. Since then
it refuses to go online. The code in the pegasus.c file hasn't changed,
so somebody in the middle broke. All the changes seem to have happened
in pre5. Here's what I've gleaned thusfar.
This applies to any recent kernel. Changes :
-Forwarding between high speed interfaces
+NIC Hardware throttling for high speed interfaces
The original is confusing with the previous option which is "Fast
switching (read help!)", one might infer similar.
-d
--
"The difference between
On Thu, Sep 07, 2000 at 07:45:48AM +0200, Luca Montecchiani wrote:
> > I think I prefer the current version over your patched version.
> > But will probably change my mind when many people complain.
>
> Why have *fdisk or lilo trouble ?
I don't know whether lilo has trouble. But if it has
that
I'd like to advocate the inclusion of the majority of these patches of
Andrea's. I've been patching most of them in for a while now simply
because I've found my SMP system much more stable and useable.
Distinctly lacking from the 2.2.17 release was Marcelo Tosatti's age-old
1-character fix to
[viro]
> > making the internal API frozen by exposure to library users.
[Gooch]
> An exercise in decent API design. BFD.
^^^
Nah, that's the *de*compilation library.
(Sorry, couldn't resist.)
Peter
-
To unsubscribe from this list: send the line
101 - 200 of 431 matches
Mail list logo
