Byron Stanoszek wrote:
>
> After about 3 days running 2.4.0-test9-pre2 (32mb i586 machine), I switched on
> the system console and saw these messages. Nothing seems to be wrong with the
> system. Can anyone enlighten me?
>
> Flags; bus-master 1, full 0; dirty 1267452(12) current 1267456(0).
B
On Tue, 19 Sep 2000, Tom Rini wrote:
> On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote:
> > The VM work has been scheduled to go in for a while. If you check the TODO
> > emails from months back, it's always been there.
>
> I wasn't arguing that (really) it's just that it really shou
After about 3 days running 2.4.0-test9-pre2 (32mb i586 machine), I switched on
the system console and saw these messages. Nothing seems to be wrong with the
system. Can anyone enlighten me?
Flags; bus-master 1, full 0; dirty 1267452(12) current 1267456(0).
Transmit list 010c72f0 vs. c10c72c0.
> "Barry K. Nathan" <[EMAIL PROTECTED]> said:
>
> > In other words, if I understand things correctly, once we have Linux
> > 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of
> > testing before release, 2.4.0-pre1 will be next...
>
> That so? Must get Linus an Alpha or SPAR
"Barry K. Nathan" <[EMAIL PROTECTED]> said:
[...]
> In other words, if I understand things correctly, once we have Linux
> 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of
> testing before release, 2.4.0-pre1 will be next...
That so? Must get Linus an Alpha or SPARC64 ASA
On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
> I'm tired of you screwing up the VM and then complaining the elevator. At least
> try to vary and choose something else to complain. At test1 time you may been
> right, but now we're so permissive in the default settings exactly to be sure
> the elev
On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
> On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote:
> > One of the issues which seems to be affecting performance
> > is the elevator starvation bug, though, so I'm not sure how
>
> You are contraddicting yourself. If you decrease the laten
On Wed, Sep 20, 2000 at 03:24:28PM +0200, Andi Kleen wrote:
> That would just break the whole idea behind softnet. When you're juggling
I agree ;(.
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 a
On Wed, Sep 20, 2000 at 03:29:39PM +0200, Andrea Arcangeli wrote:
> On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote:
> > We must be talking about different things. It of course detects it on
> > ACK input, but only for data it did send itself. Every TCP detects
> > reordering automatic
On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote:
> We must be talking about different things. It of course detects it on
> ACK input, but only for data it did send itself. Every TCP detects
> reordering automatically on the input with the sequence number check,
> but all we still do is
On Tue, Sep 19, 2000 at 08:56:57PM -0700, David S. Miller wrote:
>Just use __cacheline_aligned instead, like I did with the
>ip_local_data in the patch you just rejected. There is still the
>problem that generic SMP x86 kernels use a 32byte cacheline. Not a
>problem currently becau
David S. Miller writes:
> Why not just
> tell these people "why are you working on experimental stuff, put
> together PPC stress test and kernel regression suites if you are
> bored, because we know 2.4.x isn't read for prime time"
Mainly because:
1. the people providing the new "features" hav
Tom Rini wrote:
> I wasn't arguing that (really) it's just that it really should have gone in
> sooner. It's all really a moot point I understand, but still. major
I understand your gripe but it couldn't be helped as it was. If more people stepped
forward who really understood the mechanics a
On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote:
> Tom Rini wrote:
>
> > >that. I see that 2.4 is getting all kinds of changes merged in
> > >that should be going on with 2.5. The recent VM changes have left
> > >us with deadlocks that we didn't have before. Shouldn't th
On Tue, Sep 19, 2000 at 09:26:44PM -0700, Barry K. Nathan wrote:
> > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like
> > small stuff (maybe my memory just sucks tho).
>
> I don't think there ever were any 2.2.0-testX patches - my recollection is
> that we went from 2
Tom Rini wrote:
> >that. I see that 2.4 is getting all kinds of changes merged in
> >that should be going on with 2.5. The recent VM changes have left
> >us with deadlocks that we didn't have before. Shouldn't that have
> >gone into 2.5 not 2.4?
> Well, I think the bitterness c
> to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like
> small stuff (maybe my memory just sucks tho).
I don't think there ever were any 2.2.0-testX patches - my recollection is
that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we
seem to be having n
Date:Wed, 20 Sep 2000 04:38:24 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
We must be talking about different things. It of course detects it
on ACK input, but only for data it did send itself. Every TCP detects
reordering automatically on the input with the sequence numb
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote:
>Date: Tue, 19 Sep 2000 18:07:20 -0600
>From: Cort Dougan <[EMAIL PROTECTED]>
>
>Do you really think that's forcing people to concentrate of fixing
>bugs? Tell me if you disagree, I'd like to understand how you see
On Tue, Sep 19, 2000 at 06:54:30PM -0700, David S. Miller wrote:
>Date: Wed, 20 Sep 2000 03:51:37 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>>Receiver side SMP reordering is still there, but I'm not sure if it is
>>fixable (but it'll surely hit people that cannot use
Date: Wed, 20 Sep 2000 03:51:37 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
>Receiver side SMP reordering is still there, but I'm not sure if it is
>fixable (but it'll surely hit people that cannot use Linux senders, I
>just see the reports)
>
> Reordering is
On Tue, Sep 19, 2000 at 06:13:38PM -0700, David S. Miller wrote:
>Date: Wed, 20 Sep 2000 03:14:10 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>The ipid handling is still fishy, it will break when you talk to
>more destinations than the inetpeer cache can take (I fixed it in
>
Date: Wed, 20 Sep 2000 03:14:10 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
The ipid handling is still fishy, it will break when you talk to
more destinations than the inetpeer cache can take (I fixed it in
my local tree with the appended patch)
I don't like this change, please
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote:
> And hey, guess what, as a result of this right now my "non-driver
> caused" core/ipv4/ipv6 networking bug list is pretty much empty right
> now. Only a few netfilter glitches appear to remain.
Some items for your list:
The ipid
Date: Tue, 19 Sep 2000 18:07:20 -0600
From: Cort Dougan <[EMAIL PROTECTED]>
Do you really think that's forcing people to concentrate of fixing
bugs? Tell me if you disagree, I'd like to understand how you see
that. I see that 2.4 is getting all kinds of changes merged in
that
}Date: Tue, 19 Sep 2000 16:49:00 -0600
}From: Cort Dougan <[EMAIL PROTECTED]>
}
}If anyone else wants access to the 2.5 tree we have as a place to
}keep experimental changes I'm happy to open it up to the outside.
}
} Well, let's first step back for a second and really think
Date:Tue, 19 Sep 2000 16:49:00 -0600
From: Cort Dougan <[EMAIL PROTECTED]>
If anyone else wants access to the 2.5 tree we have as a place to
keep experimental changes I'm happy to open it up to the outside.
Well, let's first step back for a second and really think about
what
} Cort Dougan writes:
} > I've had to create a 2.5 for the PPC tree so we aren't stuck with either no
} > experimentation or experimentation in the stable trees.
}
} Well, you're not alone. There's a lot going on in the ARM side of Linux
} which looks very promising; yes it is true that ARM is n
Cort Dougan writes:
> I've had to create a 2.5 for the PPC tree so we aren't stuck with either no
> experimentation or experimentation in the stable trees.
Well, you're not alone. There's a lot going on in the ARM side of Linux
which looks very promising; yes it is true that ARM is not the faste
} On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote:
} >
} >
} > >> Linus,
} > >
} > >> Where do architecture maintainers stand when they don't submit their
} > >> problems to linux-kernel or the great Ted Bug List(tm)?
} > >
} > >Up against the wall so we can shoot them?
} > >
On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote:
>
>
> >> Linus,
> >
> >> Where do architecture maintainers stand when they don't submit their
> >> problems to linux-kernel or the great Ted Bug List(tm)?
> >
> >Up against the wall so we can shoot them?
> >
> >:)
>
> So I am o
Linus Torvalds writes:
>
>
>On Tue, 19 Sep 2000, Rogier Wolff wrote:
>>
>> If gcc starts shouting:
>>
>> somefile.c:1234: declared inline function 'serial_paranoia_check' is
>> somefile.c:1234: larger than 1k. Declining to honor the inline directive.
>
>That's not what gcc does.
>
>Gcc silentl
>> Linus,
>
>> Where do architecture maintainers stand when they don't submit their
>> problems to linux-kernel or the great Ted Bug List(tm)?
>
>Up against the wall so we can shoot them?
>
>:)
So I am one of the guys who will be shot ... I wanted to do an update for
the s/390 architecture sin
On Tue, Sep 19, 2000 at 07:50:05AM -0700, Linus Torvalds wrote:
>
>
> On Tue, 19 Sep 2000, Rogier Wolff wrote:
> >
> > If gcc starts shouting:
> >
> > somefile.c:1234: declared inline function 'serial_paranoia_check' is
> > somefile.c:1234: larger than 1k. Declining to honor the inline direct
On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote:
> One of the issues which seems to be affecting performance
> is the elevator starvation bug, though, so I'm not sure how
You are contraddicting yourself. If you decrease the latency (so if you fix the
starvation) the global disk throu
On Tue, 19 Sep 2000, Rogier Wolff wrote:
>
> If gcc starts shouting:
>
> somefile.c:1234: declared inline function 'serial_paranoia_check' is
> somefile.c:1234: larger than 1k. Declining to honor the inline directive.
That's not what gcc does.
Gcc silently just doesn't inline it.
And the
On Sun, 17 Sep 2000, Mark Orr wrote:
> Has anyone else tried 240-test9-pre2 on low-memory systems?
>
> I compiled 240t9p2, bzlilo'ed it, and rebooted. During
> boot it tripped up on e2fsck -- it was at maximum mount count
> and it stopped during the check.
> Sys: pentium 100, 16Mb RAM + 17 Mb
Linus Torvalds wrote:
>
>
> On Mon, 18 Sep 2000, David Woodhouse wrote:
> >
> > [EMAIL PROTECTED] said:
> > > Note that with most versions of gcc this is all a complete non-issue,
> > > as most versions of gcc will _always_ inline a function that the user
> > > has asked to be inlined. So the
On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote:
>
> Ok. I think we're getting to the point where there are no major known
> bugs. That means that as of the final 2.4.0-test9 I will no longer accept
> any patches that don't have a critical problem (as defined by Teds list)
> associ
Hi!
> Ok. I think we're getting to the point where there are no major known
> bugs. That means that as of the final 2.4.0-test9 I will no longer accept
> any patches that don't have a critical problem (as defined by Teds list)
> associated with them.
> So when you send me a patch, either bug T
"Dunlap, Randy" <[EMAIL PROTECTED]> said:
[]
> > Good thing I promised Ted to bring another bottle of
> > that Brazillian liquor to the next event we meet ;)
> Rik, does it have to be Brazilian liquor?
> I still have patches for 2.4.0-final also.
You'd have to ask Ted...
BTW folks, please
On Mon, Sep 18, 2000 at 05:11:35PM +0100, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Linus,
>
> > Where do architecture maintainers stand when they don't submit their
> > problems to linux-kernel or the great Ted Bug List(tm)?
>
> Up against the wall so we can shoot them?
I know t
[EMAIL PROTECTED] said:
> Linus,
> Where do architecture maintainers stand when they don't submit their
> problems to linux-kernel or the great Ted Bug List(tm)?
Up against the wall so we can shoot them?
:)
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Mon, 18 Sep 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Note that with most versions of gcc this is all a complete non-issue,
> > as most versions of gcc will _always_ inline a function that the user
> > has asked to be inlined. So the issue seldom actually comes up.
>
> I
On Sun, 17 Sep 2000, Mark Orr wrote:
> Has anyone else tried 240-test9-pre2 on low-memory systems?
Hmmm... I am getting periodic hangs on reading floppies AFTER initrd
inititialization Maybe once every 20 boots.. same thing.. strange hang,
and a control gets by whatever process was hanging
[EMAIL PROTECTED] said:
> Note that with most versions of gcc this is all a complete non-issue,
> as most versions of gcc will _always_ inline a function that the user
> has asked to be inlined. So the issue seldom actually comes up.
I thought that 'extern inline' was in fact the intended usage
Ted,
How does one identify the "critical" items in the
2.4 Status/TODO list?
Will you be adding a "critical" section or adding
"(critical)" on some items on the 2.4 Status/TODO list?
I'm updating the USB list now and wondering how to
mark items as critical.
Thanks,
~Randy
Linus Torvalds writes:
> So when you send me a patch, either bug Ted to mark the issue as
> "critical" first, or pay me money. It's that easy.
Linus,
Where do architecture maintainers stand when they don't submit their
problems to linux-kernel or the great Ted Bug List(tm)?
_
|_| -
When trying to compile I get:
drivers/scsi/scsidrv.o: In function `init_sd':
drivers/scsi/scsidrv.o(.text+0x68ae): undefined reference to
`scsi_register_module'
drivers/scsi/scsidrv.o: In function `exit_sd':
drivers/scsi/scsidrv.o(.text+0x68c3): undefined reference to
`scsi_unregister_module'
dri
H. Peter Anvin wrote:
> Ideally, the linker should have some kind of merging pass to merge
> these multiple instances -- this really could help C++ template
> instantiation problems as well -- but for now, the only "safe" way is
> pretty much to provide a library with non-inlined versions and hope
Followup to: <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Let's assume that gcc decides that it won't inline a function, because
> it's too "big", according to some gcc definition of "big".
>
> With "extern inline", the function will no
Has anyone else tried 240-test9-pre2 on low-memory systems?
I compiled 240t9p2, bzlilo'ed it, and rebooted. During
boot it tripped up on e2fsck -- it was at maximum mount count
and it stopped during the check.
Once I got past the check, and was able to get it to a prompt.
I tried to compile th
> > Ok. I think we're getting to the point where there are no major
> > known bugs. That means that as of the final 2.4.0-test9 I will
> > no longer accept any patches that don't have a critical problem
> > (as defined by Teds list) associated with them.
> >
> > So when you send me a patch, eithe
Erick Kinnee wrote:
>
> On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote:
> > - pre2:
> > - "extern inline" -> "static inline". It doesn't matter right now,
> > but it's proactive for future gcc versions.
> > - various net drvr updates and fixes
> > - more initca
On Sun, 17 Sep 2000, Alan Cox wrote:
> > bugs. That means that as of the final 2.4.0-test9 I will no longer accept
> > any patches that don't have a critical problem (as defined by Teds list)
> > associated with them.
>
> Argh. Im not going to have time to push all the driver fixes from 2.2 int
Linus Torvalds wrote:
> Ok. I think we're getting to the point where there are no major known
> bugs. That means that as of the final 2.4.0-test9 I will no longer accept
> any patches that don't have a critical problem (as defined by Teds list)
> associated with them.
[snip]
> - PCI bridge scann
On Mon, Sep 18, 2000 at 07:07:18AM +1200, Chris Wedgwood wrote:
> - "extern inline" -> "static inline". It doesn't matter right now,
> but it's proactive for future gcc versions.
>
> can someone please explain the difference?
info gcc 'c ext' inline
"extern inline" implies
> > Argh. Im not going to have time to push all the driver fixes from 2.2 into
> > 2.4 then, I've got a house move to do yet
>
> Alan, 'it happens that is why most distros will not ship a 2.4.0 kernel
> and will wait for 2.4.1 or 2.4.2.
Historically distros ship something about version 5-6, sign
On Mon, 18 Sep 2000, Chris Wedgwood wrote:
> On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote:
>
> - "extern inline" -> "static inline". It doesn't matter right now,
> but it's proactive for future gcc versions.
>
> can someone please explain the difference?
On Sun, 17 Sep 2000, Linus Torvalds wrote:
> Ok. I think we're getting to the point where there are no major
> known bugs. That means that as of the final 2.4.0-test9 I will
> no longer accept any patches that don't have a critical problem
> (as defined by Teds list) associated with them.
>
> So
> bugs. That means that as of the final 2.4.0-test9 I will no longer accept
> any patches that don't have a critical problem (as defined by Teds list)
> associated with them.
Argh. Im not going to have time to push all the driver fixes from 2.2 into
2.4 then, I've got a house move to do yet
-
Ok. I think we're getting to the point where there are no major known
bugs. That means that as of the final 2.4.0-test9 I will no longer accept
any patches that don't have a critical problem (as defined by Teds list)
associated with them.
So when you send me a patch, either bug Ted to mark the
62 matches
Mail list logo
