> 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
-
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
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 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 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
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
> > 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
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
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
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
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
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)?
_
|_| -
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
[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
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
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
[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, 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
"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
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
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
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, 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
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 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, 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
>> 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 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
} 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?
} > >
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
} 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
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
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
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, 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 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, 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
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
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
}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 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
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
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
> 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
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
"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
> "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
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 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
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
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 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 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
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
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 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
>
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 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
59 matches
Mail list logo
