* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> But yeah, if Debian/sid is just using random compiler snapshots of the
> day, I htink we can just bury this as "pointless".
Err, debian/sid *isn't* defaulting to gcc-4.2 yet, but it is made
available to people who want to install it and play with it.
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> I'm hoping your Debian/sid gcc version is some very experimental
> known-buggy one, and not something that people _expect_ to be solid and
> work well?
No such luck. :( Debian's close to moving to gcc-4.2 as the default
compiler in sid. We've
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
I'm hoping your Debian/sid gcc version is some very experimental
known-buggy one, and not something that people _expect_ to be solid and
work well?
No such luck. :( Debian's close to moving to gcc-4.2 as the default
compiler in sid. We've rebuilt
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
But yeah, if Debian/sid is just using random compiler snapshots of the
day, I htink we can just bury this as pointless.
Err, debian/sid *isn't* defaulting to gcc-4.2 yet, but it is made
available to people who want to install it and play with it.
* Adam Megacz ([EMAIL PROTECTED]) wrote:
> --- include/linux/magic.h 2006-12-29 15:48:50.0 -0800
> +++ include/linux/magic.h 2006-11-29 13:57:37.0 -0800
> @@ -3,7 +3,6 @@
>
> #define ADFS_SUPER_MAGIC 0xadf5
> #define AFFS_SUPER_MAGIC 0xadff
> -#define
* Adam Megacz ([EMAIL PROTECTED]) wrote:
--- include/linux/magic.h 2006-12-29 15:48:50.0 -0800
+++ include/linux/magic.h 2006-11-29 13:57:37.0 -0800
@@ -3,7 +3,6 @@
#define ADFS_SUPER_MAGIC 0xadf5
#define AFFS_SUPER_MAGIC 0xadff
-#define
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> FWIW the Tejun cleanups are a fix, split into three reviewable pieces.
>
> Also, my local iomap branch has advanced sufficiently enough that I
> think it's high time to kill those libata warnings that spew on every
> build. (I hear the crowds roar)
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
FWIW the Tejun cleanups are a fix, split into three reviewable pieces.
Also, my local iomap branch has advanced sufficiently enough that I
think it's high time to kill those libata warnings that spew on every
build. (I hear the crowds roar)
Perhaps
* Lion Vollnhals ([EMAIL PROTECTED]) wrote:
> Am Sonntag, den 14.08.2005, 09:29 -0400 schrieb Willem Riede:
> > On Wed, 10 Aug 2005 20:54:35 +, Allen Martin wrote:
> > That is disappointing. I was seriously considering a motherboard with your
> > chipset because of its impressive
* Lion Vollnhals ([EMAIL PROTECTED]) wrote:
Am Sonntag, den 14.08.2005, 09:29 -0400 schrieb Willem Riede:
On Wed, 10 Aug 2005 20:54:35 +, Allen Martin wrote:
That is disappointing. I was seriously considering a motherboard with your
chipset because of its impressive specifications, but
* Jakob Oestergaard ([EMAIL PROTECTED]) wrote:
> This is really the clever way to run a 64-bit system - 99% of what is
> commonly run on most systems only gains overhead from the 64-bit address
> space - tools like postfix, cron, syslog, apache, ... will not gain from
> being native 64-bit.
For
* Jakob Oestergaard ([EMAIL PROTECTED]) wrote:
This is really the clever way to run a 64-bit system - 99% of what is
commonly run on most systems only gains overhead from the 64-bit address
space - tools like postfix, cron, syslog, apache, ... will not gain from
being native 64-bit.
For most
* Marc Aurele La France ([EMAIL PROTECTED]) wrote:
> To that end, I would propose, as a possible technical solution, extending
> the kernel build process to detect these errors during kernel development.
Well, couple stupid comments:
#1: I'm not *entirely* sure Linus reads every mail to lkml..
* Marc Aurele La France ([EMAIL PROTECTED]) wrote:
To that end, I would propose, as a possible technical solution, extending
the kernel build process to detect these errors during kernel development.
Well, couple stupid comments:
#1: I'm not *entirely* sure Linus reads every mail to lkml..
* Benjamin Herrenschmidt ([EMAIL PROTECTED]) wrote:
> Hrm... reading more of the patch & Martin's previous work, I'm not sure
> I like the idea too much in the end... The main problem is that you are
> just "replaying" the ticks afterward, which I see as a problem for
> things like sched_clock()
* Benjamin Herrenschmidt ([EMAIL PROTECTED]) wrote:
Hrm... reading more of the patch Martin's previous work, I'm not sure
I like the idea too much in the end... The main problem is that you are
just replaying the ticks afterward, which I see as a problem for
things like sched_clock() which
* David S. Miller ([EMAIL PROTECTED]) wrote:
>
> Russell King writes:
> > At the time I suggested it was because of a missing wakeup in 2.4.2 kernels,
> > but I was shouted down for using 2.2.15pre13. Since then I've seen these
> > reports appear on lkml several times, each time without a
* David S. Miller ([EMAIL PROTECTED]) wrote:
Russell King writes:
At the time I suggested it was because of a missing wakeup in 2.4.2 kernels,
but I was shouted down for using 2.2.15pre13. Since then I've seen these
reports appear on lkml several times, each time without a solution
Running into a problem with one of our Dell PowerEdge 1400 servers.
We see these messages very rarely, but after they show up the machine
goes into a really odd state:
Mar 26 09:37:27 maul kernel: spurious APIC interrupt on CPU#1, should never happen.
Mar 26 09:37:27 maul kernel: unexpected IRQ
Running into a problem with one of our Dell PowerEdge 1400 servers.
We see these messages very rarely, but after they show up the machine
goes into a really odd state:
Mar 26 09:37:27 maul kernel: spurious APIC interrupt on CPU#1, should never happen.
Mar 26 09:37:27 maul kernel: unexpected IRQ
* fsnchzjr ([EMAIL PROTECTED]) wrote:
> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> Nice little article on how we're all going to die of herpes from our
> repeated exposition to Linux...
> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?tag=ltnc
Just
* fsnchzjr ([EMAIL PROTECTED]) wrote:
Watch Microsoft's Jim Allchin go Linux-bashing!!!
Nice little article on how we're all going to die of herpes from our
repeated exposition to Linux...
http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?tag=ltnc
Just
* David Ford ([EMAIL PROTECTED]) wrote:
> A person just brought up a problem in #kernelnewbies, building an SMP
> kernel doesn't work very well, current is undefined. I don't have more
> time to debug it but I'll strip the config and put it up at
> http://stuph.org/smp-config
They're
* David Ford ([EMAIL PROTECTED]) wrote:
A person just brought up a problem in #kernelnewbies, building an SMP
kernel doesn't work very well, current is undefined. I don't have more
time to debug it but I'll strip the config and put it up at
http://stuph.org/smp-config
They're trying
* David S. Miller ([EMAIL PROTECTED]) wrote:
>
> Now against 2.4.1-pre2:
>
> ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p2-1.diff.gz
Tried it with 2.4.1-pre3, didn't have any problem applying it, but
when I rebooted the system it pretty much had no interest in talking
* David S. Miller ([EMAIL PROTECTED]) wrote:
Now against 2.4.1-pre2:
ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p2-1.diff.gz
Tried it with 2.4.1-pre3, didn't have any problem applying it, but
when I rebooted the system it pretty much had no interest in talking TCP
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> On Tue, 9 Jan 2001, Stephen Frost wrote:
>
> > Now, the interesting bit here is that the processes can grow to be
> > pretty large (200M+, up as high as 500M, higher if we let it ;) ) and what
> > happens with MOSIX i
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
>
> > but it just doesn't apply when you look at some other applications,
> > such as streaming out video data or performing fileserving in a
> > high-performance compute cluster where you are serving
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
but it just doesn't apply when you look at some other applications,
such as streaming out video data or performing fileserving in a
high-performance compute cluster where you are serving bulk data.
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
On Tue, 9 Jan 2001, Stephen Frost wrote:
Now, the interesting bit here is that the processes can grow to be
pretty large (200M+, up as high as 500M, higher if we let it ;) ) and what
happens with MOSIX is that entire processes get sent over
* Jes Sorensen ([EMAIL PROTECTED]) wrote:
> > "David" == David S Miller <[EMAIL PROTECTED]> writes:
>
> I don't question Alexey's skills and I have no intentions of working
> against him. All I am asking is that someone lets me know if they make
> major changes to my code so I can keep track
* Jes Sorensen ([EMAIL PROTECTED]) wrote:
"David" == David S Miller [EMAIL PROTECTED] writes:
I don't question Alexey's skills and I have no intentions of working
against him. All I am asking is that someone lets me know if they make
major changes to my code so I can keep track of whats
* Oliver Xymoron ([EMAIL PROTECTED]) wrote:
> On Thu, 14 Dec 2000, Linus Torvalds wrote:
>
> > A 100ms delay sounds like some interrupt shut up or similar (and then
> > timer handling makes it limp along).
>
> Possibly related datapoint: after several days of uptime, my
> 2.4.0-test10pre?
* Oliver Xymoron ([EMAIL PROTECTED]) wrote:
On Thu, 14 Dec 2000, Linus Torvalds wrote:
A 100ms delay sounds like some interrupt shut up or similar (and then
timer handling makes it limp along).
Possibly related datapoint: after several days of uptime, my
2.4.0-test10pre? machine went
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
>
>
> On Thu, 14 Dec 2000, Stephen Frost wrote:
> >
> > This go around I compiled everything into the kernel, actually.
> > If it would be useful I can compile them as modules reboot and then see
> > what h
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
>
>
> On Thu, 14 Dec 2000, Stephen Frost wrote:
> >
> > Any idea if these issues would cause a general slow-down of a
> > machine? For no apparent reason after 5 days running 2.4.0test12
> > everything going
* Alan Cox ([EMAIL PROTECTED]) wrote:
> > machine? For no apparent reason after 5 days running 2.4.0test12
> > everything going through my firewall (set up using iptables) I got about
> > 100ms time added on to pings and traceroutes. I'll probably reboot the
> > machine tonight and see if that
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
>
> Especially if we get that netfilter problem sorted out (see the other
> thread about the IP fragmentation issues associated with that one), and
> if we figure out why apparently some people have trouble with external
> modules (at least one person
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Especially if we get that netfilter problem sorted out (see the other
thread about the IP fragmentation issues associated with that one), and
if we figure out why apparently some people have trouble with external
modules (at least one person has
* Alan Cox ([EMAIL PROTECTED]) wrote:
machine? For no apparent reason after 5 days running 2.4.0test12
everything going through my firewall (set up using iptables) I got about
100ms time added on to pings and traceroutes. I'll probably reboot the
machine tonight and see if that helps.
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
On Thu, 14 Dec 2000, Stephen Frost wrote:
Any idea if these issues would cause a general slow-down of a
machine? For no apparent reason after 5 days running 2.4.0test12
everything going through my firewall (set up using iptables) I
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
On Thu, 14 Dec 2000, Stephen Frost wrote:
This go around I compiled everything into the kernel, actually.
If it would be useful I can compile them as modules reboot and then see
what happens...
Even when compiled into the kernel
* Jeroen Geusebroek ([EMAIL PROTECTED]) wrote:
>
> I'm having troubles with the eepro driver included in kernel 2.2.17.
> It stops sometimes with no apparent reason. The one thing i noticed
> is that it seems to have a lot of carrier problems(998!)
>
> This is part of the result from ifconfig:
* Jeroen Geusebroek ([EMAIL PROTECTED]) wrote:
I'm having troubles with the eepro driver included in kernel 2.2.17.
It stops sometimes with no apparent reason. The one thing i noticed
is that it seems to have a lot of carrier problems(998!)
This is part of the result from ifconfig:
* Andries Brouwer ([EMAIL PROTECTED]) wrote:
> So, in the long run we want a large pid_t. What about the short run?
> For today the disadvantages are negligeable, and for people who
> like security there are definite advantages.
Much more the problem is giving people the *impression* of
* Andries Brouwer ([EMAIL PROTECTED]) wrote:
So, in the long run we want a large pid_t. What about the short run?
For today the disadvantages are negligeable, and for people who
like security there are definite advantages.
Much more the problem is giving people the *impression* of
* Igmar Palsenberg ([EMAIL PROTECTED]) wrote:
>
> Tell my teacher it's a good idea, he is telling otherwise :)
Academics and reality don't tend to equate. :) Something to do with the
world not exactly being perfect. The reality is, if you hadn't guessed, Linux
is doing rather well. :)
* Igmar Palsenberg ([EMAIL PROTECTED]) wrote:
Tell my teacher it's a good idea, he is telling otherwise :)
Academics and reality don't tend to equate. :) Something to do with the
world not exactly being perfect. The reality is, if you hadn't guessed, Linux
is doing rather well. :)
* Admin Mailing Lists ([EMAIL PROTECTED]) wrote:
> On Tue, 5 Sep 2000, Andrey Savochkin wrote:
>
> > On Sun, Sep 03, 2000 at 02:57:54PM -0300, Cesar Eduardo Barros wrote:
> > >
> > > I'm having endless problem with an eepro100 here. After some trying found out
> > > that doing a soft reset
* Admin Mailing Lists ([EMAIL PROTECTED]) wrote:
On Tue, 5 Sep 2000, Andrey Savochkin wrote:
On Sun, Sep 03, 2000 at 02:57:54PM -0300, Cesar Eduardo Barros wrote:
I'm having endless problem with an eepro100 here. After some trying found out
that doing a soft reset (ctrl+alt+del)
50 matches
Mail list logo
