Michael J Clark <[EMAIL PROTECTED]> writes:
>
> I have been reading through TCP/IP Illustrated Vol 2 and the linux
> source. I am having a heck of a time finding where it sees a SYN packet
> and check to see if the desitination port is open. In the book it looks
> like it happens in tcp_inpu
Alan Cox <[EMAIL PROTECTED]> writes:
>
> Do you see this if you run a -ac kernel or apply the APIC 440BX patch ?
Alan, what APIC 440BX patch are you referring to? I must have missed
it, and I can't find anything in the archives.
Kevin <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send t
Yiping Chen <[EMAIL PROTECTED]> writes:
>
> So, I have two question now,
> 1. how to determine whether your kernel support SMP?
Type "uname -a", as you did before:
> Linux lab5-1 2.4.2-2 #1 SMP Wed Apr 25 18:56:05 CST 2001 i686 unknown
^^^
SMP appears here i
Jonathan Morton <[EMAIL PROTECTED]> writes:
>
> Understood - my Physics courses covered this as well, but not using the
> word "normalise".
Be that as it may, Martin's comments about normalizing are nonsense.
Rik's killer (at least in 2.4.3-pre7) produces a badness value that's
a product of badne
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> On 24 Mar 2001, Kevin Buhr wrote:
> >
> > A huge win for 2.96 and absolutely no benefit whatsoever for 3.0, even
> > though it obviously had a 10-fold effect on maps counts. On the
> > positive side, there was
Jakob Østergaard <[EMAIL PROTECTED]> writes:
>
> It's important that you use at least -O3 to get inlining too.
[ . . . ]
> 25 MB doesn't count ;)
Aggh! I feel like I'm in a comedy sketch. You tell me "do that".
I do that. You tell me, "you should try this instead", so I do this.
Then, you
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
>
> Let me inject some information about what gcc's doing in each version.
Thanks... very useful information.
> 2.95.3 allocates its memory via a bunch of 'obstacks' which,
> underneath, get memory from malloc, and therefore brk(2). I'm very
> surpr
Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
[ under kernel 2.4.2 ]
> >
> >CVS gcc 3.0: Debian gcc 2.95.3: RedHat gcc 2.96:
> >
> >real16m8.423s real8m2.417s real12m24.939s
> >user15m23.710suser7m22.200suser10m1
Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> Times are fine. Local APIC timer interrupts are used.
Okay, thanks. That's good.
> Testing's easy, thanks for the fix.
This is where I'd submit the patch, but Alan evidently works 80 hours
a day. ;) The new patch is already in ac24.
Alan, FYI
Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> > Mike, would you like to try out the following (untested) patch against
> > vanilla ac20 to see if it does the trick?
>
> Yes, that fixed it.
Great! Can you test one more configuration, please? I can't test it
properly with my SMP motherboard.
Alan Cox <[EMAIL PROTECTED]> writes:
>
> > > o Fix ppp memory corruption (Kevin Buhr)
> > > | Bizzarely enough a direct re-invention of a 1.2 ppp bug
> >
> > Could this explain my MPPP skb corruption I've reported since 2.3.x?
Unless you saw
Paul Mackerras <[EMAIL PROTECTED]> writes:
>
> I didn't realize you were talking about linux 2.4.0 and pppd 2.3.11.
That was my stupid oversight. I carefully tested and retested the
patch under 2.4.0-test5, then ported it to 2.4.2 and sent it off with
only a cursory check using the new pppd [sm
Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> 2.4.2.ac20.virgin 2.4.3-pre6
> real11m0.708s 11m58.617s
> user15m8.720s 7m29.970s
> sys 1m31.410s 0m41.590s
>
> It looks like ac20 is doing some double accounting.
Alan:
In "2.4.2-ac20", the check in "apic.c" in the "APIC_init_
Leif Sawyer <[EMAIL PROTECTED]> writes:
>
> What happens when init is not pid == 1, as is often the case
> during installs, booting off of cdrom, etc..
Well, after spending hours scrutinizing Patrick's one-line patch, I'll
guess that, in these cases, the patch does not prevent init from being
ki
Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> Yes. I'm so used to UP numbers I didn't think. I saw user larger than
> real on my UP box yesterday during some testing, and then seeing this
> post... oops.
Okay, so you see "user > real" on a UP box running an SMP kernel.
First, I'm not really
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> Cool. Somebody actually found a real case.
>
> I'll fix the mmap case asap. Its' not hard, I just waited to see if it
> ever actually triggers. Something like g++ certainly counts as major.
I frequently build Mozilla from scratch on my (aging) dual
Paul Mackerras <[EMAIL PROTECTED]> writes:
>
> But the waiting process must have had an instance of /dev/ppp open and
> attached to the channel in order to be doing anything with rwait,
> within either ppp_file_read or ppp_poll. The process of attaching to
> the channel increases its refcnt, mea
Linus:
This one was tough to find. I think I triggered it maybe four times
over the space of six months and almost chalked it up to an electrical
problem with the modem.
If there's a hangup in the TTY layer on an async PPP channel,
do_tty_hangup shuts down the PPP line discipline, and, in ppp_a
Alan Cox <[EMAIL PROTECTED]> writes:
>
> You want peoples existing applications to suddenely and magically change
> their results. Umm problem.
So, how would you feel about a mechanism whereby the kernel could be
passed a default FPU control word by the binary (with old binaries, by
default, usi
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
>
> IEEE-754 floating point is available under glibc-based systems,
> including most current GNU/Linux distributions, by linking with -lieee.
> Your example program produces the "9 10" result you wanted when linked
> this way, even when compiled
Jason Riedy <[EMAIL PROTECTED]> writes:
>
> Note that getting what some people want to call `true' IEEE 754
> arithmetic on an x86 is frightfully tricky. Changing the precision
> does not shorten the exponent field, and that can have, um, fun
> effects on and around under/overflow.
Whoops. Th
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> >
> > Well, yes, but I'll try not to cry myself to sleep over it. I'm
> > tempted to say that someone who chooses to use "float"s has given up
> > all pretense of caring about the answers they get. And, if they
> > really want to do predictable m
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
>
> So you change it to 2... but what about the "float" type? It gets
> a mixture of 64-bit and 32-bit IEEE arithmetic depending rather
> unpredictably on compiler register allocations and optimizations???
Well, yes, but I'll try not to cry myself
A question recently came up in "c.o.l.d.s"; actually, it was a comment
on Slashdot that had been cross-posted to 15 Usenet groups by some
ignoramus. It concerned a snippet of C code that cast a double to int
in such a way as to get a different answer under i386 Linux than under
the i386 free BSDs
Christoph Rohland <[EMAIL PROTECTED]> writes:
>
> I am just running a stress test on 2.4.0-test13-pre3 + appended patch
> without problems. Is the shm segment deleted sometimes or is it always
> the same segment?
IIRC, in my particular crash case, the Enlightenment window manager
was using the X
Peter Berger <[EMAIL PROTECTED]> writes:
>
> Hi. I have the following tiny test program which fails dramatically,
> using pthreads, in a number of fascinating ways on various version of
> linux, using various versions of glibc, under various (current) versions
> of GDB.
It looks like a GDB bug.
Trond Myklebust <[EMAIL PROTECTED]> writes:
>
> The problem then arises that lseek tries to cram both a returned
> offset and an error value into the return values.
Oops. You're right; I didn't think of this.
So, I guess the best short-term solution is to fix the C library so it
always uses ll
Trond:
Fiddling with the Crytographic File System the other day, I managed to
tickle a mysterious bug. When some directories grew large enough,
suddenly a chunk of files would half "disappear". "find" would list
them fine, but "ls" and "echo *" wouldn't.
After a bit of troubleshooting, I disco
Christoph Rohland <[EMAIL PROTECTED]> writes:
>
> > I use a SysReq patch to do an oops-style dump instead of the usual
> > "showPc" function, so I was able to copy a stack dump down.
>
> Could you send me the patch? Does it do the dump on all cpus?
You can grab it at:
ftp://mozart.stat
Christoph Rohland <[EMAIL PROTECTED]> writes:
>
> This is the first report of such corruption. If it's real it is _not_
> fixed between test5 and test11. There is probably no way to reproduce
> it since you ask if it's fixed in test11, right?
I know no way to reproduce it. I've been using "test
I've been chasing after a bug in 2.4.0-test5 that I can't quite nail
down. I don't see anything obvious between test5 and test11 that
leads me to believe it's been fixed.
I encountered a lockup on my SMP box. One CPU got stuck in a spinlock
via the following call trace. There were enough args
KMF AV <[EMAIL PROTECTED]> writes:
>
> ... obviously the Linux logo should be the
> international symbol for the fucking retard.
Actually, this was considered. However, in those dark days, the ISO
had not yet standardized the international symbol for the fucking
retard. A symbol for "dimwit cr
32 matches
Mail list logo
