I have seen unpleasant incidents in which the Ethernet interfaces have
stopped responding to anything higher-level than a ping after about 20
days of use. I saw 2 of these on 2.4test1 using an EtherExpress100, and
one with 2.4test6 using the tulip driver with a PNIC card. Both were
On Thu, 31 Aug 2000 14:09:48 +0200 (CEST)
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Aug 2000, Alan Cox wrote:
>> We then just follow the bios. You can also reserve blocks of
>> memory by hacking arch/i386/mm/init.c and marking them reserved
> in 2.4 there is an explicit interface
I went ahead and applied the patch and subjected my machine to some heavy disk
thrashing. Nothing has oopsed yet. Netscape is still running. Throwing >1.0 GB
files around isnt exhibiting any problems.
Need others to verify.
On Tue, Sep 05, 2000 at 11:48:45PM -0400, Mohammad A . Haque wrote:
>
On Tue, Sep 05, 2000 at 04:41:26PM -0600, Richard Gooch wrote:
> Christoph Hellwig writes:
> > Hi Linus,
> > I've updated my devfs for lvm patch to 2.4.0-test8pre.
> > Here it is.
> [...]
> > + lvm_devfs_handle = devfs_register(
> > + 0 , "lvm", 0, 0, LVM_CHAR_MAJOR,
>
> Does this
> I have a device that sits on the memory bus. It looks like RAM
> until a (module) device driver gets at it. At that point I want it
> to be reserved memory (private to driver). Now I can do this in
> init if I know the location of the device in memory and its size.
> The problem is that
On Tue, 5 Sep 2000, Alan Cox wrote:
> I spend my time thinking. But I prefer to spend it thinking about the
> bug not about finding it and how long fsck takes. [...]
if we only optimize for the debugging time spent by seasoned kernel
developers then you are completely right. But if we optimize
On Tue, Sep 05, 2000 at 01:03:49PM +0200, Ingo Molnar wrote:
> one problem is developer laziness ;-) We could as well include debugging
> code so that experienced people like you can fix easy / moderate bugs
> quicker. But the problem is that in this case people are not forced to
> understand the
Alexander Viro wrote:
>
> On Fri, 1 Sep 2000, Tigran Aivazian wrote:
>
> > Rasmus, you introduced a bug because you removed the code but left the
> > comment around. now /* this should go into ->truncate */ is there and very
> > confusing - what should go into ->truncate?
>
> ... except that
Ingo,
Your arguments are personal, not technical. Which billiob dollar
company did you support with 70 million customers exactly? Not having
this out in the field makes folks jobs 100 times harder and more costly
for companies to support. When and if you ever run your own business,
you'll
On Tue, 5 Sep 2000, Jeff V. Merkey 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 (drivers) and support issues.
Ingo
-
To
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Andi Kleen wrote:
>
> > My point was basically that omitting useful debugging tools makes it
> > not any less likely that people use the (A) strategy (easy fix instead
> > of real understanding). For some people it is so painfull to work with
> > raw
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey 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 (drivers)
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> A kernel debugger will reduce development costs. [...]
... of Jeff V. Merkey - possibly. You are too much focused on your own
needs, you dont contribute a bit to the generic kernel and the kernel
infrastructure itself.
Ingo
-
To unsubscribe
"David S. Miller" wrote:
>
>Date: Tue, 05 Sep 2000 17:08:03 -0600
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
>Go visit their website and review the materials directy -- these
>are their claims -- not mine. It's www.novell.com.
>
> Ummm... circa April 15th, 1998 ;-)))
On Tue, Sep 05, 2000 at 05:20:53PM -0600, Jeff V. Merkey wrote:
> I think it would not be hard to put this in. My problem is time and
> "debugging the debugger" in Linux. The codes at our site and anyone who
> wants to put it in is welcome to.
I looked at the Manos code and it seems to
On Wed, 6 Sep 2000, Kurt Roeckx wrote:
> A (better?) kernel debugger could help (certain) people to help improve
> the long term health, because they can't (or don't want) to use what's
> available,
like, brain?
> or just think they can't easely do it with them. It could help
> certain
A thinko request_region() says if you succeeded or not.
--- linux-2.4.0-test/include/asm-sparc/floppy.h.dist-2.4.0-test8-pre4 Tue Sep 5
15:31:34 2000
+++ linux-2.4.0-test/include/asm-sparc/floppy.h Tue Sep 5 15:26:40 2000
@@ -21,7 +21,7 @@
#undef request_region
#define
Actually, the solution I think would be to use the MSDOS loader to boot
linux. I will look at grabbing the ELF code in Linux and loading Linux
from MSDOS -- if this can be accomplished you're there -- with an added
benfit. When I am debugging MANOS, the source files and OS actually
load from
Date: Tue, 05 Sep 2000 17:29:10 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
"David S. Miller" wrote:
> Ummm... circa April 15th, 1998 ;-)))
They've got some newer stuff. The best way to get the latest numbers
would be to call Craig Miller 801-861-7000 ([EMAIL
On 9/5/00, 5:26:29 AM, Daniel Phillips wrote
> Alexander Viro wrote:
> >
> > On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> >
> > > Rasmus, you introduced a bug because you removed the code but left the
> > > comment around. now /* this should go into ->truncate */ is there and
very
> > >
On Tue, 5 Sep 2000, Richard Gooch wrote:
> Ingo Molnar writes:
>
> > The reference kernel should be IMO 'untainted' though. Believe me,
> > during the 2.3.2x pagecache rewrite my kernel was hacked with ad-hoc
> > debugging code beyond recognition - eg. automatic checksumming of
> > every
Ingo Molnar writes:
>
> On Tue, 5 Sep 2000, Andi Kleen wrote:
>
> > My point was basically that omitting useful debugging tools makes it
> > not any less likely that people use the (A) strategy (easy fix instead
> > of real understanding). For some people it is so painfull to work with
> > raw
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> A kernel debugger will reduce development costs. No one cares what's
> underneath, [...]
this is the point where IMO your argument gets flawed, and where you are
apparently ignoring our arguments. With utmost respect, we *do* care about
what's
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> [...] You guys can argue til your blue in the face as to why a kernel
> debugger in Linux is bad -- [...]
you havent yet replied to our arguments in substance, so i certainly will
not continue arguing - with whom, myself? ;)
Ingo
-
To
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> I think the disconnect for you here is that you assume the Linux world
> will remain constant [...]
> [...] Just because Linux puts everything in user space does not mean
> that's how the whole world should be. There's a lot of kernel
> development
Date: Wed, 6 Sep 2000 12:31:55 +1200
From: Chris Wedgwood <[EMAIL PROTECTED]>
Face it Dave -- you are just smarter than many of the rest of us.
I would actually assert that I am not, and that I know the things I do
for reasons other than "talent", and I think the best way to describe
Amen Brother.
Alan Cox wrote:
>
> > IMO there was only one historically hard spinlock-related problem that
> > needed solving, this is the 'locks up hard' problem (which is solved). The
> > rest was never really an debugging obstacle, 99% of the spinlock related
> > bugs manifest themselves
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > [...] You guys can argue til your blue in the face as to why a kernel
> > debugger in Linux is bad -- [...]
>
> you havent yet replied to our arguments in substance, so i certainly will
> not continue arguing - with whom,
On Tue, 5 Sep 2000, poke wrote:
>> Only, with the former, I get to restart the application everytime it
>> croaks, with the latter (modules excluded) I have to reboot. This is
>> much more time consuming and means you really have to be much smarter
>> about what checks and printk statements you
On Tue, 5 Sep 2000, Richard Gooch wrote:
> everyone has to start from nothing. But if the learning/development
> curve is too steep, or the process is too frustrating, you are going
> to lose a proportion of the potential gurus. You can't push people in
> a direction they don't want to go.
Date:Tue, 5 Sep 2000 21:31:17 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
Me neither, but IMO I have a cop-out:
Think it's a good idea to kunmap the page twice? :-)
...
__block_commit_write(inode, page, offset, offset+length);
+kunmap(page);
Date:Tue, 5 Sep 2000 21:32:45 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
On Wed, 6 Sep 2000, Andrew Morton wrote:
> > gcc -O2 -c t.c
> > strings t.o | grep hhh
> hhh
Eww... Do they _ever_ remove dead code?
They remove the code, they just forget to
On Tue, 5 Sep 2000, David S. Miller wrote:
>Date: Tue, 5 Sep 2000 21:31:17 -0400 (EDT)
>From: Alexander Viro <[EMAIL PROTECTED]>
>
>Me neither, but IMO I have a cop-out:
>
> Think it's a good idea to kunmap the page twice? :-)
Successful prepare_write() will kmap() it...
On Tue, 5 Sep 2000, Andi Kleen wrote:
> I don't really believe that. It is as easy to add a silly NULL pointer
> check based on a oops as it is after a debugging session (and it is
> even likely you chose the simple fix because it is harder and more
> work to proceed) Usually with the debugger
Date: Tue, 5 Sep 2000 21:39:59 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
On Tue, 5 Sep 2000, David S. Miller wrote:
> Think it's a good idea to kunmap the page twice? :-)
Successful prepare_write() will kmap() it...
Oops, indeed, I did not realize nested kmap/kunmap
Elmer Joandi wrote:
>
> > understanding the
> > > underlying principles and the code.
>
> Speaking about that, I have been long time dreaming
> about following strict standard template for linux kernel functions:
> (macroplay intended)
> --
> INLINE(context,level,for_speed,
Date: Tue, 05 Sep 2000 12:15:52 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
It's got the highest numbers for any web server on the planet on
Intel.
What is your metric for this claim? Last I checked Linux held the
record for the current version of specweb, specweb99.
Maybe
On Tue, Sep 05, 2000 at 05:30:46PM +0200, Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > A kernel debugger will reduce development costs. No one cares what's
> > underneath, [...]
>
> this is the point where IMO your argument gets flawed, and where you are
> apparently
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > I think the disconnect for you here is that you assume the Linux world
> > will remain constant [...]
>
> > [...] Just because Linux puts everything in user space does not mean
> > that's how the whole world should be.
David,
Go visit their website and review the materials directy -- these are
their claims -- not mine. It's www.novell.com.
"David S. Miller" wrote:
>
>Date: Tue, 05 Sep 2000 12:15:52 -0600
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
>It's got the highest numbers for any web
Date: Tue, 05 Sep 2000 17:08:03 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
Go visit their website and review the materials directy -- these
are their claims -- not mine. It's www.novell.com.
Ummm... circa April 15th, 1998 ;-)))
Later,
David S. Miller
[EMAIL PROTECTED]
-
To
> Only, with the former, I get to restart the application everytime it
> croaks, with the latter (modules excluded) I have to reboot. This is
> much more time consuming and means you really have to be much smarter
> about what checks and printk statements you put in where... the hope
> is with
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> Perhaps you would like to describe how you do debug the kernel? I ask
> this because I use printf more often than anything else when
> debugging userland code and I often use printk when debugging the
> kernel.
I can't speak for DaveM, but... the
Martin Dalecki wrote:
> Elmer Joandi wrote:
> > strict standard template for linux kernel functions:
> > INLINE(context,level,for_speed, fixed) returntype functionname
>
> Please have a tought look at the floppy tape streamer driver to see why
> this is a BAD IDEA.
Couldnt see much else than
On Wed, Sep 06, 2000 at 12:31:55PM +1200, Chris Wedgwood wrote:
> Perhaps you would like to describe how you do debug the kernel? I ask
I find that rebooting the machine and cursing myself is one of the
most effective kernel debugging methods.
--
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> > > I think the disconnect for you here is that you assume the Linux world
> > > will remain constant [...]
> >
> > > [...] Just because Linux puts everything in user space does not mean
> > > that's how the whole world should be. There's a lot of
> This is what a debugger does not do for you. The debugger allows you
> to be lazy, step around, "oh yeah check for NULL" and never have to
> _think_ about what you're doing or the changes you're making or even
> if the same bug might be elsewhere.
I don't really believe that. It is as easy to
"David S. Miller" wrote:
> This is what a debugger does not do for you. The debugger allows you
> to be lazy, step around, "oh yeah check for NULL" and never have to
> _think_ about what you're doing or the changes you're making or even
> if the same bug might be elsewhere.
>
> This is why
Amen,
The main issue for me is also for support. It's really nice to have an
integrated kernel debugger so if a customer has a problem, you can send
out trained folks to track stuff down more quickly since they can poke
around the system. It's also great for diagnosing customer problems
On Mon, 4 Sep 2000, David S. Miller wrote:
>Date: Sun, 3 Sep 2000 20:23:11 -0400 (EDT)
>From: Gregory McLean <[EMAIL PROTECTED]>
>
>[gregm@tweetie gregm]$ uname -a
>Linux tweetie.comstar.net 2.4.0-test7 #20 Sat Sep 2 16:17:06 EDT 2000 i686
>unknown
>[gregm@tweetie
Ingo Molnar writes:
>
> On Tue, 5 Sep 2000, Richard Gooch wrote:
>
> > everyone has to start from nothing. But if the learning/development
> > curve is too steep, or the process is too frustrating, you are going
> > to lose a proportion of the potential gurus. You can't push people in
> > a
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > A kernel debugger will reduce development costs. No one cares what's
> > underneath, [...]
>
> this is the point where IMO your argument gets flawed, and where you are
> apparently ignoring our arguments. With utmost
> IMO there was only one historically hard spinlock-related problem that
> needed solving, this is the 'locks up hard' problem (which is solved). The
> rest was never really an debugging obstacle, 99% of the spinlock related
> bugs manifest themselves in clear, unambiguous lockups.
Then why are
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> > no, my arguments are technical, but are simply focused towards the
> > conceptual (horizontal) development of Linux, not the vertical
> > development of Linux (drivers) and support issues.
>
> They seem focused on keeping us in the dark ages. [...]
Date: Wed, 6 Sep 2000 12:00:13 +1200
From: Chris Wedgwood <[EMAIL PROTECTED]>
Right now as I see it (pretending everything is black and white);
you, Dave, Linus and a few other people[1] are more than happy with
debugging aids as they exist right now in a stock kernel.
All the stuff on our website and ftp servers is free Linux code and it
runs in the kernel. Novell's customers have been downloading it for
over a year. At any point, Linux is free to take it and use it. Lots
of Linux users already are.
Jeff
Jes Sorensen wrote:
>
> > "Jeff" == Jeff V
> understanding the
> > underlying principles and the code.
Speaking about that, I have been long time dreaming
about following strict standard template for linux kernel functions:
(macroplay intended)
--
INLINE(context,level,for_speed, fixed) returntype functionname
On Tue, 5 Sep 2000, Alan Cox wrote:
> Then why are we still finding obscure lock ordering bugs in 2.2 ?
> Finding them when they bite you is easy, finding the obscure ones when
> they dont generally bite is much harder - thats where debugging
> kernels that trap and dump lock lists for order
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> Ingo Molnar wrote:
>> you dont contribute a bit to the generic kernel and the kernel
>> infrastructure itself.
Jeff> I contribute code, time, and $$$, Ingo.
HAve you contributed code to anything but your own private project
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Andi Kleen wrote:
>
> > My point was basically that omitting useful debugging tools makes it
> > not any less likely that people use the (A) strategy (easy fix instead
> > of real understanding). For some people it is so painfull to work with
> > raw
Martin Dalecki wrote:
>
>
> And finally I would like to emphasize that every singe additional
> facility doesn't
> come free - It's adding complexity which is a source of possible
> problems in itself.
Some interesting mental mastrubation, but it not on topic. You guys can
argue til your
"Jeff V. Merkey" wrote:
>
> Ingo Molnar wrote:
> >
> > On Tue, 5 Sep 2000, Jeff V. Merkey 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
Ingo Molnar wrote:
you dont contribute a bit to the generic kernel and the kernel
> infrastructure itself.
>
I contribute code, time, and $$$, Ingo.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > A kernel debugger will reduce development costs. [...]
>
> ... of Jeff V. Merkey - possibly. You are too much focused on your own
> needs, you dont contribute a bit to the generic kernel and the kernel
> infrastructure
Mike Galbraith writes:
> On Tue, 5 Sep 2000, Richard Gooch wrote:
> > Ingo Molnar writes:
> >
> > > The reference kernel should be IMO 'untainted' though. Believe me,
> > > during the 2.3.2x pagecache rewrite my kernel was hacked with ad-hoc
> > > debugging code beyond recognition - eg.
301 - 365 of 365 matches
Mail list logo
