Re: Reserving a (large) memory block

[Ryan Cumming]

 
>   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 to detect the device(s) and their size I use the> i2c and smbus 
>modules.  Ergo, to reserve the physical memory I need
> a kernel which is pretty well fully booted (ie the heap etc is
> already built) so I can load those modules and find
 the devices,
> which means that grabbing and reserving bits of physical memory is
> unsafe (because the heap etc is already built).  However, if I had
> access to the filesystem at init time, I could go read a file that
> told me where the device(s) are and how big they are, do the
> reservations, and then have the module double check the reservations
> against the reality of what's installed.  
> 
>   Problem is: I don't (think I) have filesystem access at init time,
> and can't safely reserve specific physical memory after init which
> seems to leave my only option being to pass in the reservation specs
> from the bootloader, which is what rather I'm trying to avoid.
> 
>   Or am I missing something?

Possibly... would it be pratical to have part of the module kernel
resident, and the pull its memory location/size off the kernel command
line? Something like memdevice0_mem_start=0xdeadbeef
memdevice0_mem_size=0xf00f? This would avoid crazy filesystem kludges,
but may not be practical for usability reasons...

-Ryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Richard Gooch]

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. automatic checksumming of
> > > every physical page in the system to detect stray DMA related memory
> > > corruption.  No rocket science, but ugly enough to 'taint' the
> > > kernel proper. Would any of the debugging facilities advocated in
> > > this thread have helped in the bugs we were chasing at that time?
> > > Nope. Do i want such debugging code to ever show up in the mainsteam
> > > kernel? Hell no.
> > 
> > Would you classify IKD as a pile of warts you wouldn't want to see in
> > the kernel?
> 
> I run IKD 99.99% of the time (maintenance helper bee).  Still, I wouldn't
> want to see it in the kernel.. except maybe kdb.  IKD is very intrusive
> from the code readability standpoint.  Memleak in particular has a zillion
> ugly ifdefs I don't know how to get rid of.
> 
> > Surely there must be some useful features that can be included in the
> > kernel without uglyfing it or slowing it down (configed out)? Leaving
> > aside the social engineering attempts, of course :-)
> 
> They can all be configured out, and they are all useful.  KDB is the
> only one which (imho) could be integrated without uglifying the
> code.

Fine. Then let's add that, at least. It's probably the #1 thing
anyway.

> (What means 'social engineering attempts'?)

Attempting to change people's habits by making it hard to debug.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] devfs support for LVM

[Christoph Hellwig]

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 really have to go into /dev rather than a subdirectory?

Yes. The userlevel tool can't handle other things without recompiling.
I can't use /dev/lvm, too because this is the name of the control file
without lvm (and the lvm tools will barf if this is a dircetory.

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Mike Galbraith]

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 physical page in the system to detect stray DMA related memory
> > corruption.  No rocket science, but ugly enough to 'taint' the
> > kernel proper. Would any of the debugging facilities advocated in
> > this thread have helped in the bugs we were chasing at that time?
> > Nope. Do i want such debugging code to ever show up in the mainsteam
> > kernel? Hell no.
> 
> Would you classify IKD as a pile of warts you wouldn't want to see in
> the kernel?

I run IKD 99.99% of the time (maintenance helper bee).  Still, I wouldn't
want to see it in the kernel.. except maybe kdb.  IKD is very intrusive
from the code readability standpoint.  Memleak in particular has a zillion
ugly ifdefs I don't know how to get rid of.

> Surely there must be some useful features that can be included in the
> kernel without uglyfing it or slowing it down (configed out)? Leaving
> aside the social engineering attempts, of course :-)

They can all be configured out, and they are all useful.  KDB is the only
one which (imho) could be integrated without uglifying the code.

-Mike

(What means 'social engineering attempts'?)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Mohammad A . Haque]

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:
> I'd test it .. I was planning on setting up vmware with an install and tryings
> stuff there. But I have too much !@#$ homework.
> 
> Anyone else want to be brave and volunteer? It's for a good cause!
> 

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Snoozy Ethernet Interfaces in 2.4testX?

[David C Niemi]

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
uniprocessor kernels on uniprocessor hardware (one a PIII and one a
K6).  In 2 of the 3 cases the machine was restored to full function just
by bringing the Ethernet interface down and back up again; in the 3rd case
this was not tried.

Does anyone have counterexamples of machines which have been busily
pushing network traffic much longer than 20 days under 2.4testx kernels?  
Or has anyone else seen tired Ethernet interfaces? I suspect this might be
a general problem, but it is also possible the EtherExpress100 incidents
and the PNIC incident might be unrelated; so some extra data points would
be a great help.

-
David C. Niemi  (Reston, Virginia, USA)  [EMAIL PROTECTED]
Know the difference between the color of the wine and the
color of the glass.  (Jalaluddin Rumi)
-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Reserving a (large) memory block

[coder]

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 for this that also
> guarantees that the allocation consists of fully valid RAM (no
> matter how complex the RAM map): alloc_bootmem(). We allocate
> 300MB+ worth of mem_map[] with this on multi-gigabyte boxes.

I don't see that alloc_bootmem() and friends do what I want under
2.4 in that they don't allow me to require that the
allocation/reservation occur from an explicit physical address
(there's no promise in the "goal" handling of
__alloc_bootmem_core()).  It seems that the *bootmem() calls are
intended to provide a lightweight kernel heap with alloc/free
semantics rather than an interface to explicit physical memory
reservation -- no? (am I misunderstanding how bdata is handled by
__alloc_bootmem_core()?)

  Am I correct that at init time I don't have access to the (root)
filesystem?  This makes total sense to me, but I'm not familiar
enough with the boot path to know for sure.

The problem I'm trying to solve:

  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 to detect the device(s) and their size I use the
i2c and smbus modules.  Ergo, to reserve the physical memory I need
a kernel which is pretty well fully booted (ie the heap etc is
already built) so I can load those modules and find the devices,
which means that grabbing and reserving bits of physical memory is
unsafe (because the heap etc is already built).  However, if I had
access to the filesystem at init time, I could go read a file that
told me where the device(s) are and how big they are, do the
reservations, and then have the module double check the reservations
against the reality of what's installed.  

  Problem is: I don't (think I) have filesystem access at init time,
and can't safely reserve specific physical memory after init which
seems to leave my only option being to pass in the reservation specs
from the bootloader, which is what rather I'm trying to avoid.

  Or am I missing something?

-- 
J C Lawrence Home: [EMAIL PROTECTED]
-(*)Work: [EMAIL PROTECTED]
http://www.kanga.nu/~claw/Keys etc: finger [EMAIL PROTECTED]
--=| A man is as sane as he is dangerous to his environment |=--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18-3 seems to break pcmcia-cs-3.1.20

[Horst von Brand]

Marcelo Tosatti <[EMAIL PROTECTED]> said:

[...]

> Thats because 2.2.18pre3 has a 2.4 "compatibility layer".
> 
> The attached patch fixes the problem. 
> 
> diff -Nur pcmcia-cs-3.1.20.orig/include/pcmcia/k_compat.h pcmcia-cs-3.1.20/incl
> ude/pcmcia/k_compat.h
> --- pcmcia-cs-3.1.20.orig/include/pcmcia/k_compat.h   Tue Sep  5 15:57:21 200
> 0
> +++ pcmcia-cs-3.1.20/include/pcmcia/k_compat.hTue Sep  5 16:07:30 2000
> @@ -55,7 +55,7 @@
>  #define DEV_ID   dev_id
>  #define IRQ_MAP(irq, dev)do { } while (0)
>  
> -#if (LINUX_VERSION_CODE < VERSION(2,3,1))
> +#if (LINUX_VERSION_CODE < VERSION(2,3,1)) && (LINUX_VERSION_CODE < VERSION(2,2
> ,18))

I.e., LINUX_VERSION_CODE < VERSION(2, 2, 18)? Weird way of saying that...
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

ps2esdi maintainer?

[A Duston]

Hello,

I am trying to contact the ps2esdi maintainer, as I have
some questions about the driver.  I have an ancient PS/2
Thinkpad that gives an annoying but cosmetic error when
it boots.  I contacted David Weinehall earlier, but he
isn't sure who the mainainer is.

Thanks,
Hal Duston
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

kernel debugging (was RE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux)

[Marty Fouts]

I've debugged quiet a few operating systems on a very wide range of hardware
over 25 years using a very wide range of tools and techniques, sometimes
even having to use logic analysers.  I've also watched this discussion for a
while. IMHO, y'all have conflated two quiet different processes (possibly
three,) and are trying to use your (lack of) tools as a form of social
engineering.

To the extent that computing is science, it is empirical science, and as
such any effective tools that gives you visibility into the running computer
belongs in your toolkit.  A good (remote) source level debugger, *properly
used*, is one of the most effective ways of obtaining visibility that I
know.  Tied in to a decent source code browser, it can also be a very
effective way of coming up to speed on the ins and outs of someone else's
code.

There are, in essences, three parts to debugging a problem: figuring out
what the system is really doing; figuring out why what it is doing is wrong;
and figuring out the best way to make it behave less wrongly.  Debuggers and
source code browsers can figure prominently in the first (as should Meyer's
programming contracts or a similar model backed up by real asserts in the
code, but that's a different topic.)

As I've posted earlier, our brains complement the computers, and we should
use both most effectively.  People are good at seeing patterns in the data,
but not so good at extracting the data or remembering it.  Good debuggers,
effectively used, help with both the extraction and the remembering.

Some people work best at identifying problems with abstraction and analysis.
That's the way they should work.  Others need hands on experience to
identify problems.  In the real world you need both kinds of people and you
need to supply tools for each.

Marty

-Original Message-
From: David S. Miller [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 05, 2000 5:03 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS
for Linux


   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.

   However, there are many many other people far less talented than
   yourselves and for use less capable people having a compile time
   options of IKD or something might really be of use

I think what it comes down to is that the folks who know the tree the
best and do the most work/fixing in it, think the debugging stuff
should remain a seperate patch.

We believe that it doesn't belong in the main source tree mainly
for two reasons:

1) It is clutter.  I don't want to see the debugging/debugger code
   when most of the time it serves no purpose.

   NOTE: This is different than "BUG()" and "ASSERT()" which serve
 a different purpose becuase they not only act as a
 consistency check, but they also _document_ how the author
 of the code believed the world around it must behave :-)

2) It is hoped that because it isn't the default, some new people
   will take the quantum leap to actually try debugging using the
   best debugger any of us have, our brains, instead of relying on
   automated tools.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Alexander Viro]

On Tue, 5 Sep 2000, Linus Torvalds wrote:

> Yeah, but that's a much bigger issue. Not something we can or want to fix
> for 2.4.x.

No arguments. UFS will have to live with its private copy for a while
(truncate there may have to zero out more than 4Kb of data).

> > * "make sure that ->buffers is there and map the buffers in given
> > range" is too fscking common and deserves a function of its own.
> 
> Yeah, maybe. It's just that every single case has different semantics
> inside the loop. So it would basically boil down to either macros or to
> passign around function pointers..

I'm not sure, but anyway, that's a separate story. Let's avoid doing too
many things simultaneously... Right now we really need to get the truncate()
mess settled down on ext2, then we will be able to reproduce the whole set
of fixes on other block filesystems. The sooner ext2 will get stable - the
better.

BTW, folks - do forced fsck before testing new kernels. These days it's
a must-do. There had been a lot of chances to screw fs, so testing new
variants on that may be interesting, but hardly useful. Oh, and do it
on the _old_ kernels. Just to be sure that you have relatively clean setup.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Mohammad A . Haque]

I'd test it .. I was planning on setting up vmware with an install and trying stuff 
there. But I have too much !@#$ homework.

Anyone else want to be brave and volunteer? It's for a good cause!

On Tue, Sep 05, 2000 at 08:35:37PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 5 Sep 2000, Mohammad A . Haque wrote:
> > 
> > Just wanted to throw I out that I JUST experienced the same oops with
> > netscape. I'mgoing to wait until Al submits a patch that he has gone
> > over to see if it fixes the problem.
> 
> Well, Al seems to agree with mine, but it still hasn't been tested.
> 
> Note that it doesn't ahve to be _me_ that tests the thing. Hint, hint.
> 
> [ yeah, I know. Testing these kinds of things is dangerous. I'll do it
>   first thing in the morning if nobody else beats me to it. It looks ok,
>   but even just a silly typo can cause nasty fs corruption here, as we've
>   seen in the past ]
> 
>   Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Linus Torvalds]

On Tue, 5 Sep 2000, Mohammad A . Haque wrote:
> 
> Just wanted to throw I out that I JUST experienced the same oops with
> netscape. I'mgoing to wait until Al submits a patch that he has gone
> over to see if it fixes the problem.

Well, Al seems to agree with mine, but it still hasn't been tested.

Note that it doesn't ahve to be _me_ that tests the thing. Hint, hint.

[ yeah, I know. Testing these kinds of things is dangerous. I'll do it
  first thing in the morning if nobody else beats me to it. It looks ok,
  but even just a silly typo can cause nasty fs corruption here, as we've
  seen in the past ]

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Mohammad A . Haque]

Umm..what .. you get back here this instant .. Linus..come back here ...

Just kidding.


Just wanted to throw I out that I JUST experienced the same oops with netscape. 
I'mgoing to wait until Al submits a patch that he has gone over to see if it fixes the 
problem.

Also wanted to ask (because I'm still learning) if anyone knew which files have the 
potential to become corrupt. Is it only open files or can it also be files that aren't 
being accessed. The reason I ask is because my netscape prefs file contained half of 
my missing mailbox and I couldn't recall if I had opened netscape when the last 
corruption occured.

On Tue, Sep 05, 2000 at 07:14:02PM -0700, Linus Torvalds wrote:
> 
> 
> How about this patch?
> 
> NOTE NOTE NOTE! I'm on my way home now to be a family man, so I've not
> actually tested it AT ALL. You have been warned.
> 
> The basic approach should be ok, and it avoids using the write path at all
> because it isn't actually needed. The truncate() case is, in the end, much
> simpler than writing, exactly because we don't need to allocate any new
> blocks etc.
> 
> We just grab the page, populate it with buffers if required, and find the
> one buffer that we need to clear out. We clear it out and mark it dirty.
> End of story.
> 
> NOTE: Udo, because I haven't actually tested this (it may not actually
> compile etc small details), you probably shouldn't actually test this out
> as-is unless you are _really_ daring and don't mind fixing up after me.
> It's more a "this is how it should work" kind of thing.
> 
> Al? Mind giving it a quick look?
> 
>   Linus
> 
> ---

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Linus Torvalds]

On Tue, 5 Sep 2000, Alexander Viro wrote:
> 
> It looks OK, except for the following (issues are actually common to
> all block_... functions):
>   * if we ever do allocation unit != IO block size (have to do it on
> UFS, probably want it on ext2 to break 4Kb limit) we'll have to deal with
> more than one block. Not a big deal, but worth getting it right

Yeah, but that's a much bigger issue. Not something we can or want to fix
for 2.4.x.

I think it makes most sense as a complete change of interface: instead of
asking the filesystem for the blocknumber, we could ask the filesystem to
generate the buffer list for that page.

Your other this would be solved by this too:

>   * with some filesystems we really want an analog of get_block()
> acting on array. Aside of UFS, FAT-derived filesystems are obvious candidates.
> I mean, WTF? Why bother recalculating the thing if allocation unit is larger
> than IO unit?

I don't think it's about being a larger IO unit - it can be a smaller IO
unit that isn't even aligned with a 4kB page, for example. It's
potentially valid to have each page split up into 1kB+2kB+1kB requests,
because the filesystem really might be a 2kB system but for some strange
reason isn't doing aligned buffers or whatever.

The issue of a "tail" is the same thing. A 2kB block filesystem with a 512
byte tail, so a page might be 2kB+512B+unmapped if it is at the end of the
file.

But right now there's no way we'd make _those_ kinds of changes. In fact,
right now I'd be happy to just have a working truncate() for a change ;)

>   * "make sure that ->buffers is there and map the buffers in given
> range" is too fscking common and deserves a function of its own.

Yeah, maybe. It's just that every single case has different semantics
inside the loop. So it would basically boil down to either macros or to
passign around function pointers..

>   BTW, Jeff's complaint about size restriction in ll_rw_block() is
> valid. It made sense when we used the thing only for buffer-cache, but
> these days it looks bogus. It doesn't work as alias-prevention anymore, so
> there's little point in doing it.

Oh, I agree completely. What you didn't see me was me suggesting to Jeff
that he just remove the check.

It turns out that apparently several low-level drivers complain at that
point, so it's more than just that single test, though.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: GPL violations: make it harder

[dean gaudet]

sorry i should have pointed to this in my previous response -- read
 if you haven't already.

(really wish i knew more about these topics outside the US... i'm even
naive regarding these laws in my own home country Canada.)

-dean

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: GPL violations: make it harder

[dean gaudet]

On Tue, 5 Sep 2000, Jeff Epler wrote:

> strings plus code that I wrote.  (My actual desire was to figure out a way
> that I could release QuakeC modifications under the GPL, when the base
> QuakeC source was not GPL.  I hope there's no ethical brown stuff involved
> in that desire!)

assuming you have the freedom to distribute modifications in the first
place, then you have the freedom to distribute them under the original
license plus an additional license.

-dean

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Alexander Viro]

On Tue, 5 Sep 2000, Linus Torvalds wrote:

> We just grab the page, populate it with buffers if required, and find the
> one buffer that we need to clear out. We clear it out and mark it dirty.
> End of story.
> 
> NOTE: Udo, because I haven't actually tested this (it may not actually
> compile etc small details), you probably shouldn't actually test this out
> as-is unless you are _really_ daring and don't mind fixing up after me.
> It's more a "this is how it should work" kind of thing.
> 
> Al? Mind giving it a quick look?

It looks OK, except for the following (issues are actually common to
all block_... functions):
* if we ever do allocation unit != IO block size (have to do it on
UFS, probably want it on ext2 to break 4Kb limit) we'll have to deal with
more than one block. Not a big deal, but worth getting it right
* "make sure that ->buffers is there and map the buffers in given
range" is too fscking common and deserves a function of its own.
* with some filesystems we really want an analog of get_block()
acting on array. Aside of UFS, FAT-derived filesystems are obvious candidates.
I mean, WTF? Why bother recalculating the thing if allocation unit is larger
than IO unit?

I'll play with #2 and see what can be done there. I have a funny
feeling that lots of things will merrily factor out, so we may end up with
ability to do 10-liner transition to kiobuf whenever we will decide to do
it.

BTW, Jeff's complaint about size restriction in ll_rw_block() is
valid. It made sense when we used the thing only for buffer-cache, but
these days it looks bogus. It doesn't work as alias-prevention anymore, so
there's little point in doing it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: GPL violations: make it harder

[dean gaudet]

On Tue, 5 Sep 2000, Mike A. Harris wrote:

> If even one file in the kernel source gets modified, then the entire
> patch is GPL via the GPL assimilation rules in COPYING - regardless of
> what the author of the patch says.

IANAL.

i know this is what the GPL wants, but AFAIK it's never been tested in
court.

while there are continued attacks on our rights in the US -- such as
microsoft and others trying to make shrinkwrap licenses enforceable, i
believe it is still the case that there are some rights that you have to
explicitly wave (by signature for example), no matter what a contract
says.

i can't say whether there are some rights that definitely apply here --
and i doubt that it'll really be known until this goes all the way through
the court system.

but, for example, we all own rights to our words -- and have to explicitly
give up those rights.

another example -- someone reading enough linux-kernel can compose many
patches or otherwise suggest modifications to the kernel without ever
having downloaded the source, or used the kernel, or otherwise "agreed" to
clause 5... simply because this mailing list, and our transactions on it
do not include the approriate copyleft notices on them.

also, there could be conflicts with contracts which you have signed with
employers -- which typically give up a bunch of your rights, even in
fields "unrelated" to your work field.  only the courts can decide which
contract wins in the case where an employee of Big Company publishes a
patch which uses Big Company's intellectual property.  the NPL/MPL try to
cover this with the patent clauses -- but watch out, there's now even big
business laws governing trade secrets intended to deal with corporate
espionage (fortunately the laws seem difficult to enact, 'cause they're
real ugly... see one of the CACM issues from this summer).

there's grey areas.  maybe it's changed recently -- but in the past the
FSF itself recognized these grey areas by requiring you to explicitly
register a signed document with them before they could accept your
patches.

you can make the grey a little less grey by explicitly granting rights to
your own creations.

-dean


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Simon Kirby]

On Wed, Sep 06, 2000 at 02:55:29AM +0200, Udo A. Steinberg wrote:

> >>EIP; c0130400 <__block_commit_write+50/c0>   <=

Just got the same Oops with test8-pre5 while exiting mutt:

Writing /var/spool/mail/sim...Unable to handle kernel NULL pointer dereference at 
virtual address 0018
 printing eip:
c0130583
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010293
eax:    ebx:    ecx: 0800   edx: 
esi: 0800   edi: 0001   ebp:    esp: ceb19e40
ds: 0018   es: 0018   ss: 0018
Process mutt (pid: 2153, stackpage=ceb19000)
Stack: c1382a80  ce0ab000 0649  0800 c0130b52 ceb640a0
   c1382a80 09b7 1000 0dea  000b ceb640a0 ceb640a0
   09b7 c014d31e ceb6413c 006f49b7  0649 ceb640a0 ceb6413c
Call Trace: [] [] [] [] [] 
[] []
   [] [] [] []
Code: 8b 43 18 83 e0 01 0f 44 ef eb 35 89 f6 f6 43 18 10 74 2d f0

>>EIP; c0130583 <__block_commit_write+43/c0>   <=
Trace; c0130b52 
Trace; c014d31e 
Trace; c012336d 
Trace; c012156d 
Trace; c012168d 
Trace; c014189e 
Trace; c014198e 
Trace; c012c71a 
Trace; c0124608 
Trace; c012c963 
Trace; c010a65f 
Code;  c0130583 <__block_commit_write+43/c0>
 <_EIP>:
Code;  c0130583 <__block_commit_write+43/c0>   <=
   0:   8b 43 18  mov0x18(%ebx),%eax   <=
Code;  c0130586 <__block_commit_write+46/c0>
   3:   83 e0 01  and$0x1,%eax
Code;  c0130589 <__block_commit_write+49/c0>
   6:   0f 44 ef  cmove  %edi,%ebp
Code;  c013058c <__block_commit_write+4c/c0>
   9:   eb 35 jmp40 <_EIP+0x40> c01305c3 
<__block_commit_write+83/c0>
Code;  c013058e <__block_commit_write+4e/c0>
   b:   89 f6 mov%esi,%esi
Code;  c0130590 <__block_commit_write+50/c0>
   d:   f6 43 18 10   testb  $0x10,0x18(%ebx)
Code;  c0130594 <__block_commit_write+54/c0>
  11:   74 2d je 40 <_EIP+0x40> c01305c3 
<__block_commit_write+83/c0>
Code;  c0130596 <__block_commit_write+56/c0>
  13:   f0 00 00  lock add %al,(%eax)

Simon-

[  Stormix Technologies Inc.  ][  NetNation Communications Inc. ]
[   [EMAIL PROTECTED]   ][   [EMAIL PROTECTED]]
[ Opinions expressed are not necessarily those of my employers. ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: GPL violations: make it harder

[Jeff Epler]

On Tue, Sep 05, 2000 at 10:23:34PM -0400, Mike A. Harris wrote:
> For patches to be licensed otherwise would require that someone
> write some nasty scripts to patch the kernel given explicit line
> numbers, etc... and it is likely possible in theory, but doubtful
> that anyone would ever do it due to the effort involved and the
> brown stuff that would come back at them from an ethical point.
> 
> I'm glad you brought up this point indeed!  Good thinking!

Actually, I've considered a form of diff/patch which represented context
and deleted lines by their md5sum.  Thus, the diff only contains long hex
strings plus code that I wrote.  (My actual desire was to figure out a way
that I could release QuakeC modifications under the GPL, when the base
QuakeC source was not GPL.  I hope there's no ethical brown stuff involved
in that desire!)

Or is md5sum(line N of file) a derivative work of file?  If so, what duty
do I have under the GPL if I tell you md5sum(line N of GPL'd file)?

God, this stuff gets too weird when you start thinking about it.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Andrew Morton]

Richard Gooch wrote:
> 
> It will probably take about 5 years after a new version of GCC which
> has this fix before we can trust it to produce correct code for the
> kernel.

I don't think it's that bad, Richard.  As davem points out, the dead
code elimination works OK.  Chris has a counter-example but I was not
able to reproduce that with 2.7.2.3.

The only problem I'm aware of is this tendency to leave dangling strings
in .rodata.  Unfortunately you can't work around this with the linker
and -fdata-sections either.  See
http://gcc.gnu.org/ml/gcc-prs/2000-q2/msg00036.html

But still, doing the conditional compilation at compile-time rather than
preprocessing-time is so *nice* that if you don't have too many literal
strings floating about it may be justifiable.

In cs89x0.c you reduce the object size by 1.5k by setting DEBUGGING to
literal zero - no #ifdefs in sight.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Mike A. Harris]

On Wed, 6 Sep 2000, Martin Dalecki wrote:

>Basically I will just guess: The next maybe non free version of
>source navigator will use the mechanism I have just described above.
>So maybe there is already someone at RedHat doing exactly this work
>already ;-).

Source Navigator is GPL open source now, and has been for a
while.  

ftp://sourceware.cygnus.com/pub/sourcenav/releases



--
Mike A. Harris Linux advocate 
Computer Consultant  GNU advocate  
Capslock Consulting  Open Source advocate

"Facts do not cease to exist because they are ignored."
   - Aldous Huxley

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux

[yodaiken]

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.


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Linus Torvalds]

How about this patch?

NOTE NOTE NOTE! I'm on my way home now to be a family man, so I've not
actually tested it AT ALL. You have been warned.

The basic approach should be ok, and it avoids using the write path at all
because it isn't actually needed. The truncate() case is, in the end, much
simpler than writing, exactly because we don't need to allocate any new
blocks etc.

We just grab the page, populate it with buffers if required, and find the
one buffer that we need to clear out. We clear it out and mark it dirty.
End of story.

NOTE: Udo, because I haven't actually tested this (it may not actually
compile etc small details), you probably shouldn't actually test this out
as-is unless you are _really_ daring and don't mind fixing up after me.
It's more a "this is how it should work" kind of thing.

Al? Mind giving it a quick look?

Linus

---
diff -u --recursive --new-file p5/linux/fs/buffer.c linux/fs/buffer.c
--- p5/linux/fs/buffer.cTue Sep  5 18:56:06 2000
+++ linux/fs/buffer.c   Tue Sep  5 19:09:08 2000
@@ -1724,31 +1724,63 @@
return 0;
 }
 
-int block_zero_page(struct address_space *mapping, loff_t from, unsigned length)
+int block_truncate_page(struct address_space *mapping, loff_t from, get_block_t 
+*get_block)
 {
unsigned long index = from >> PAGE_CACHE_SHIFT;
unsigned offset = from & (PAGE_CACHE_SIZE-1);
+   unsigned blocksize, iblock, length, pos;
struct inode *inode = (struct inode *)mapping->host;
struct page *page;
+   struct buffer_head *bh;
int err;
 
+   blocksize = inode->i_sb->s_blocksize;
+   length = offset & (blocksize - 1);
+
+   /* Block boundary? Nothing to do */
if (!length)
return 0;
 
-   page = read_cache_page(mapping, index,
-   (filler_t *)mapping->a_ops->readpage, NULL);
+   length = blocksize - length;
+   iblock = index << (PAGE_CACHE_SHIFT - inode->i_sb->s_blocksize_bits);
+   
+   page = grab_cache_page(mapping, index);
err = PTR_ERR(page);
if (IS_ERR(page))
goto out;
-   lock_page(page);
-   err = -EIO;
-   if (!Page_Uptodate(page))
-   goto unlock;
+
+   if (!page->buffers)
+   create_empty_buffers(page, inode, blocksize);
+
+   /* Find the buffer that contains "offset" */
+   bh = page->buffers;
+   pos = blocksize;
+   while (offset >= pos) {
+   bh = bh->b_next;
+   iblock++;
+   pos += blocksize;
+   }
+
+   if (!buffer_uptodate(bh)) {
+   err = 0;
+   if (!buffer_mapped(bh)) {
+   get_block(inode, iblock, bh, 0);
+   if (!buffer_mapped(bh))
+   goto unlock;
+   }
+   err = -EIO;
+   bh->b_end_io = end_buffer_io_sync;
+   ll_rw_block(READ, 1, );
+   wait_on_buffer(bh);
+   if (!buffer_uptodate(bh))
+   goto unlock;
+   }
 
memset((char *) kmap(page) + offset, 0, length);
flush_dcache_page(page);
-   __block_commit_write(inode, page, offset, offset+length);
kunmap(page);
+
+   mark_buffer_dirty(bh);
err = 0;
 
 unlock:
diff -u --recursive --new-file p5/linux/fs/ext2/inode.c linux/fs/ext2/inode.c
--- p5/linux/fs/ext2/inode.cTue Sep  5 18:56:06 2000
+++ linux/fs/ext2/inode.c   Tue Sep  5 19:01:29 2000
@@ -874,7 +874,7 @@
int nr = 0;
int n;
long iblock;
-   unsigned blocksize, tail;
+   unsigned blocksize;
 
if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
S_ISLNK(inode->i_mode)))
@@ -887,9 +887,8 @@
blocksize = inode->i_sb->s_blocksize;
iblock = (inode->i_size + blocksize-1)
>> EXT2_BLOCK_SIZE_BITS(inode->i_sb);
-   tail = (iblock << EXT2_BLOCK_SIZE_BITS(inode->i_sb)) - inode->i_size;
 
-   block_zero_page(inode->i_mapping, inode->i_size, tail);
+   block_truncate_page(inode->i_mapping, inode->i_size, ext2_get_block);
 
n = ext2_block_to_path(inode, iblock, offsets);
if (n == 0)
diff -u --recursive --new-file p5/linux/include/linux/fs.h linux/include/linux/fs.h
--- p5/linux/include/linux/fs.h Tue Sep  5 18:56:07 2000
+++ linux/include/linux/fs.hTue Sep  5 19:00:59 2000
@@ -1173,7 +1173,7 @@
 
 int generic_block_bmap(struct address_space *, long, get_block_t *);
 int generic_commit_write(struct file *, struct page *, unsigned, unsigned);
-int block_zero_page(struct address_space *, loff_t, unsigned);
+int block_truncate_page(struct address_space *, loff_t, get_block_t *);
 
 extern int generic_file_mmap(struct file *, struct vm_area_struct *);
 extern ssize_t generic_file_read(struct file *, char *, size_t, loff_t *);
diff -u --recursive --new-file p5/linux/kernel/ksyms.c linux/kernel/ksyms.c

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Theodore Y. Ts'o]

   Date:Wed, 6 Sep 2000 01:43:47 +0100 (BST)
   From: Alex Buell <[EMAIL PROTECTED]>

   > 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 more intelligent debugging aids I can glean more information
   > for each reboot.

   If you have two machines, it does get a little easier.

Especially if your crash and burn machine TFTP boots from your
development machine.  

I have a blazingly fast development machine, and then a slower (but fast
booting --- no SCSI with the d*mned long SCSI bus scan times) machine
which boots a tftp-booter off the floppy and then loads the kernel from
there.

That plus a serial line between the two machines for the serial console,
and you have a fairly nice kernel development environment.  The only
thing I'm missing at this point is an X-10 module so I can remotely
power cycle the crash/burn machine in case it hangs, so I don't have to
get up and walk over to it.  :-)

- Ted

P.S.  And I *do* use kdb as well.  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

from binary towards source level scalability

[Elmer Joandi]

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 half of it being implemented.

1. My point is more in source level scalability, whatever techincal
way it is done. There is an natural potential for open source software
which is not quite completely used.
RedHat still ships i386 binaries which run 30% slower( and are still
with debug info default on) than Mandrakes
i586. Neither of them offers on-install automatic recompilation.
Before imitation of commercial binary vendors they could think about
using their native potential.

2. About macroplay, if you dislike it: if few macros would be used all over
the code, it would be very clear, cleaner than without them.
Ftape driver trace macros have some
 strings in them :), if strings are forced , then someone gets to comment his

code a lot more. It is just a matter of getting used to style.

3. Lets assume for a while, that for every container(array, hash,  btree) for
which
there is currently runtime dynamicly changeable default size or other
parameter
there would be a compile-time option to turn it static and compiled in with
both intentions:
  a) to keep it small an operational on 386sx25(your cellular phone) and
  b) fast on NxGB memory  top-tuned SMP superbox.
i.e. instead of
#define MY_HASH_SIZE 123
or #define MY_HASH_SIZE ((whatever)->size)
there would be
CONTAINER_SIZE(MY, 10, user_min, 40, 123, 1200, user_max, 1)
and it would by default compile to  dynamically changeable 123, but could
also
be user-specified size or developer-specified minimum statically compiled in.

And, would not go out of developer specified reasonable values.

4. symbol, printk and other text-based information, inline regulation...
all of  those disputes wheter to have or not to have something new like
  that in kernel could just end up being configuration options.
PRINTK(subsystem, module, level, "my networking whatever") could be
elliminated
by configuration option like: not verbose for subsystem=networking.

Top dream would be to have enduser to specify his intentions(file,webserving,

desktop,development) and then a program gathering memory and cpu speed-size
info, generating proper kernel and libraries config and  compiling it static
then and doing some
stress test just after that.That could be standard procedure for linux
installation :)
Instead of compiling it by hand and then getting 30% faster.

On some places source code must not be an art, but just systematic
structure or a bunch of data in table. Currently, for example, inlining
is an artistic act. And debugging. And /proc interface. The other way
would be to make it a configure-time option and/or flexibly
configurable/dynamicly changeable.
Then it would be compile-time art for distributors.

elmer.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Alexander Viro]

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 main technics is nicely described in
ftp://sailor.gutenberg.org/pub/gutenberg/etext95/study10.txt
Search for "In solving a problem of that sort" and read on...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Richard Gooch]

Alexander Viro writes:
> 
> 
> 
> On Wed, 6 Sep 2000, Andrew Morton wrote:
> 
> > > cat t.c
> > foo()
> > {
> > if (0)
> > bar("hhh");
> > }
> > > gcc -O2 -c t.c
> > > strings t.o | grep hhh
> > hhh

Nasty, eh?

> Eww... Do they _ever_ remove dead code?

I guess not. Also, even if we get the compilers fixed, it will be some
time before we can deploy the kind of change you're proposing (which I
do agree looks a lot nicer: #ifdefs are ugly if for no other reason
that they lie outside the brace levels).

It will probably take about 5 years after a new version of GCC which
has this fix before we can trust it to produce correct code for the
kernel.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Alexander Viro]

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...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[David S. Miller]

   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 was
valid.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[David S. Miller]

   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 mark the string in the data
section as unused and thus still emit it.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[David S. Miller]

   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);
   +unmap:
   kunmap(page);
   err = 0;

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Alexander Viro]

On Wed, 6 Sep 2000, Andrew Morton wrote:

> > cat t.c
> foo()
> {
> if (0)
> bar("hhh");
> }
> > gcc -O2 -c t.c
> > strings t.o | grep hhh
> hhh

Eww... Do they _ever_ remove dead code?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Linus Torvalds]

On Tue, 5 Sep 2000, Alexander Viro wrote:
> 
> How about reverting to compare-and-write-if-nonzero variant?
> _That_ will be definitely legal.

Yes, but I would really hate to have the case that a (shortening) truncate
could fail due to disk-full issues.

I think that's just wrong (sure, I can see some filesystem where it
happens because of how the filesystem is done, but basically I think we
should avoid it if possible. Which it is).

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Mike A. Harris]

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 put in where... the hope
>> is with more intelligent debugging aids I can glean more information
>> for each reboot.
>
>I do recall reading something a while back about using VMWare to simulate
>an operating environment so that you don't have to actually reboot your
>workstation. I haven't tried this and don't know all of the details, but
>it seems like a great idea.

Yes, I can say first hand that this is very useful advice.  
VMware is a wonderful aid for this purpose.  However, it is not
an all in one solution.  VMware gets an artificial emulated look
at the hardware, so your guest OS (Linux) will NOT see that you
have a Ultra100 or a whizbang2000 SCSI card.  Regardless of the
hardware, the guest OS sees a single unified hardware set on any
computer that doesn't relfect the real hardware.  So it is
useless debugging say an eexpress100 driver, because VMware
presents the hardware as an AMD LANCE NIC... etc...

It is certainly useful for many other situations that are not
hardware specific though.


--
Mike A. Harris Linux advocate 
Computer Consultant  GNU advocate  
Capslock Consulting  Open Source advocate

Want to run Microsoft Windows software in Linux?  You can!  VMware allows 
you to install and run other operating systems inside a window in X windows.
You can install Windows 95/98/NT/2000, FreeBSD, Solaris, and many more.
3D Games do not work yet, but virtually all office and productivity software
runs excellent.   http://www.vmware.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Andrew Morton]

Alexander Viro wrote:
> 
> 
> if (CONFIG_FOO) {
> 
> } else {
> 
> }

There are a zillion reasons why this technique is superior
to using `#ifdef CONFIG_FOO'. But, alas, gcc fumbles
the ball:

> cat t.c
foo()
{
if (0)
bar("hhh");
}
> gcc -O2 -c t.c
> strings t.o | grep hhh
hhh

This was raised with the gcc guys 4-5 weeks ago 
and might now be fixed.  I'm too bandwidth-deprived
to check.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Alexander Viro]

On Wed, 6 Sep 2000, Udo A. Steinberg wrote:

> Calltrace follows:

[bh==NULL in the loop in __block_commit_write()]

WTF?  Erm... Linus, I suspect that we are losing the thing on the
very simple effect: readpage() gets buffer_heads, all right, but then
we lose the lock. That's your window for losing the buffer_head ring of
that page.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux

[David S. Miller]

   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
it is hard work.

   You might not need certain debugging aids, some people _right now_
   do (at at the very least will benefit from them).

True.

   Maybe debugging aids should be excluded from the kernel for various
   reasons, I'm not commenting on that, but expecting the rest of the
   world to get smarter all of a sudden isn't very realistic.

I'm not expecting them to get smarter, I am expecting them to put in a
little bit of hard work and become more familiar with how the kernel
works.  I want people to do a little bit of this, instead of stepping
over a few instructions and examine a few variables from a debugger.

That process does not increase familiarity, it is the study of
behaviorology and _nothing_ more.  You don't come from the debugger
experience having learned how something works, however debugging using
your brain does have this effect.

   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.

Sure, no problem, I'll describe how it usually goes.

%85 of cases requiring probing the kernel for info go something like:

1) Some evidence of kernel being in an incorrect state is made visible
   to me.  Either this comes from an OOPS/etc. dump in an email, or
   someone prescribes a reproducable test case with which I can
   capture the dump on one of my systems.

2) Once dump is decoded, I determine what is most immediately wrong in
   the kernel at the moment the dump triggered.  Ie. I decide that
   some part of some data structure is corrupt, or that some page
   cache page had ended up being used for an inode structure, etc.

3) Once I know the nature of the immedately incorrect state, I sit and
   think about how it would be possible arrive at that state.  I try
   to walk backwards from the point of corruption back to where it may
   have originated.

4) Once I've got a decent idea of the ways such a corruption could
   possibly happen, I begin studying the kernel looking for places
   where the necessary set of conditions might be allowed.  I verify
   these specific (and usually surrounding parts of) code for
   correctness.

5) If I am truly stumped I strategically place debugging checks from
   the point of corruption and gradually "upwards" in the event
   chains.

   Because I have taken the thinking time required in step #4 I
   will not spend much time rebooting over and over, 2 or 3 reboots
   and debugging check changes should be sufficient to capture the
   information I need to pinpoint the source of the problem.

   Actually, usually the phases are "run step 5, learn something from
   what is printed, iterate redoing step 4+5 until problem is spotted"

And step 6 is reached when the true root cause of the bug is
discovered :-)

The other %15 entails situations where I code up specialized debugging
code because capturing the specific set of conditions is nontrivial
(for example, userspace seeing stale corrupt TLB translations, I have
written code for sparc64 which validates the TLB to find such bugs).

   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 more intelligent debugging aids I can glean more information
   for each reboot.

While you're rebooting you can come up with a game plan for steps 4
and 5 above, this is what I do.  fsck time is "time to think".

Ever have a situation where you were totally stumped on something, you
go out and get a hamburger or something, and halfway through eating
that juicy thing you're working out in your head the problem you're
working on, and the solution just comes to you?  This is the kind of
process the above steps are meant to encourage.  Discovery is IMHO
one of the most fantastic parts of the human experiance.

Now keep in mind, long ago I spent some inordinate amounts of time
sprinkling printk's all over the place.  And you can do this arbitrary
poking to find bugs regardless of how much you know about the code,
but it takes a long time.  The goal is to learn how to sit, think, and
study.  Doing this instead of running immediately to the editor and
trying to find an arbitrary new spot to stick a printk.

Here's a suggestion, buy a pair of chinese balls, and upon reboot put
some relevant source files into an editor on your screen and use your
hands to play with the chinese balls.  This is meant to fight the urge
to just start typing, 

Re: Still ext2-corruption in test8-pre5 (incl. OOPS)

[Linus Torvalds]

On Wed, 6 Sep 2000, Udo A. Steinberg wrote:
> 
> I'm still experiencing ext2 corruption even with the newest patch
> test8-pre5. I'm not using bugtraq, mutt or pine and I'm fairly sure
> it's not caused by a badly written application or strange input.

Interesting oops.

Basically your "page->buffers" thing seems to be NULL.

Which is certainly interesting. And, thinking about it, quite legal. The
page can have been up-to-date a long time ago, and we ended up pruning the
buffers away in order to be able to free the page later - so when truncate
comes along and wants to look at the buffers they don't exist any more.

This is basically all due to the fact that the new truncate logic does a
"__block_commit_write()" without ever having itself called any of the
routines that establish the buffers (a regular write will always have
called "__block_prepare_write()" first, for example.)

We really should have done a true "block_truncate_write()", but it looked
so clever to just re-use the existing code. Fair enough. 

Still willing to test?

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

pcmcia_cs.05-Sep-00 + 2.2.18pre3 not good with Xircom RBEM56G100TX

[Alessandro Suardi]

Used to work up to 3.1.20, which didn't build on 2.2.18pre3 - the 5/9
 snapshot compiles but I get this in /var/log/messages:

Sep  5 17:49:38 princess cardmgr[840]: executing: './network start eth0'
Sep  5 17:49:38 princess kernel: TxStopped 
Sep  5 17:49:41 princess kernel: TxStopped 
Sep  5 17:49:41 princess kernel: RxStopped 
Sep  5 17:49:41 princess kernel: eth0: Setting full-duplex based on MII#0 link partner 
capability of 41e1. 

 and while lights blink I can't get my DHCP address (tcpdump -n sees
  packets though).

 As cardmgr works with both 2.2.18pre2 and 2.4.0-test8-pre5 I
  assume it's an issue with the tulip_cb module alone.


Let me know what more I can do, thanks in advance & ciao,

--alessandro  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Linux:  kernel 2.2.18p2/2.4.0-t8p5 glibc-2.1.3 gcc-2.95.2 binutils-2.10.0.24
Oracle: Oracle8i 8.1.6.1.0 Enterprise Edition for Linux
motto:  Tell the truth, there's less to remember.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[poke]

> 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 more intelligent debugging aids I can glean more information
> for each reboot.

I do recall reading something a while back about using VMWare to simulate
an operating environment so that you don't have to actually reboot your
workstation. I haven't tried this and don't know all of the details, but
it seems like a great idea.

-Chuck

--
 
:"Condense fact from the vapor of nuance":
: 25 -> ten.knilrevlis@ekop  :
: 80 -> ekop\ten.knilrevlis.www\\:ptth   :
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

rocket port patch for 2.4

[Steven Critchfield]

I have been playing with the rocket port driver in 2.4 trying to make 
it work. It appears that the driver hasn't been modified in some time,
as it did not work at all on the debian potato inbstall of 2.2.17, nor
did it work under a fresh 2.4.0-test6 compile. 

The problem was it registered all the ports at /dev/ttyR, and did not
try to use the minor number. I am appending a patch made mostly from
copying code from serial.c to rocket.c and fixing the structure names.
This patch works on my 8 port board, but I know that it needs to have
the registering fixed to the correct number of ports detected. I am not
knowledgable enough yet to figure that out, but at least this gets my
card working.

here is the diff against a 2.4.0-test6 kernel


608c608
< 
---
>   
2133c2133
<   int i, retval, pci_boards_found, isa_boards_found;
---
>   int i, pci_boards_found, isa_boards_found;
2217a2218,2220
> #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
>   rocket_driver.name = "ttr/%d";
> #else
2218a
> #endif
2221c2225
<   rocket_driver.num = MAX_RP_PORTS;
---
>   rocket_driver.num = MAX_RP_PORTS; 
2227c2231
<   rocket_driver.flags = TTY_DRIVER_REAL_RAW;
---
>   rocket_driver.flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_NO_DEVFS;
2259a2264,2266
> #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
>   callout_driver.name = "cur/%d";
> #else
2260a2268
> #endif
2263a2272,2275
> #if (LINUX_VERSION_CODE >= 131343)
>   callout_driver.read_proc = 0;
>   callout_driver.proc_entry = 0;
> #endif
2265,2276c2277,2292
<   retval = tty_register_driver(_driver);
<   if (retval < 0) {
<   printk("Couldn't install Rocketport callout driver "
<  "(error %d)\n", -retval);
<   return -1;
<   }
< 
<   retval = tty_register_driver(_driver);
<   if (retval < 0) {
<   printk("Couldn't install tty Rocketport driver "
<  "(error %d)\n", -retval);
<   return -1;
---
>   if (tty_register_driver(_driver))
>   panic("Couldn't register Rocket Port serial driver\n");
>   if (tty_register_driver(_driver))
>   panic("Couldn't register Rocket Port callout driver\n");
>   /*
>* STEVEN
>* 
>*  This needs to get fixed to only loop through active ports, but
>*  for the meantime I only have 8 ports on my test machine so it is
>*  hardcoded here.
>*/
>   for(i = 0 ; i < 8 ; i++){
>   tty_register_devfs(_driver, 0,
>  rocket_driver.minor_start + i );
>   tty_register_devfs(_driver, 0,
>  callout_driver.minor_start + i );
2277a2294
>   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Still ext2-corruption in test8-pre5 (incl. OOPS)

[Udo A. Steinberg]

Hello,

I'm still experiencing ext2 corruption even with the newest patch
test8-pre5. I'm not using bugtraq, mutt or pine and I'm fairly sure
it's not caused by a badly written application or strange input.

Right now Linux oopsed and badly broke the whole FS.
Hopefully this will help tracking the little bugger down really soon.

Regards
Udo.

Calltrace follows:

Unable to handle kernel NULL pointer dereference at virtual address
0018
c0130400
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010287
eax:    ebx:    ecx: 1000   edx: 
esi: 1000   edi:    ebp: 0001   esp: c6a0de10
ds: 0018   es: 0018   ss: 0018
Process netscape (pid: 512, stackpage=c6a0d000)
Stack: cba56b00 1000 cb8bf000   1000 c0130a4d
cba56b00
   c12e2f80 0d98 1000 0012  000c 
c12e2f80
   0011  1000 cba56b00 0d98 c014d275 cba56b9c
00011d98
Call Trace: [] [] [] []
[]
[] []
   [] [] [] [] []
Code: f6 43 18 10 74 2b 0f ba 6b 18 00 0f ab 6b 18 19 c0 85 c0 75

>>EIP; c0130400 <__block_commit_write+50/c0>   <=
Trace; c0130a4d 
Trace; c014d275 
Trace; c0123ee7 
Trace; c0122181 
Trace; c0122272 
Trace; c01d0c51 
Trace; c0140be6 
Trace; c0140cbb 
Trace; c012c87c 
Trace; c0136e90 
Trace; c012cb13 
Trace; c010a98b 
Code;  c0130400 <__block_commit_write+50/c0>
 <_EIP>:
Code;  c0130400 <__block_commit_write+50/c0>   <=
   0:   f6 43 18 10   testb  $0x10,0x18(%ebx)   <=
Code;  c0130404 <__block_commit_write+54/c0>
   4:   74 2b je 31 <_EIP+0x31> c0130431
<__block_commit_write+81/c0>
Code;  c0130406 <__block_commit_write+56/c0>
   6:   0f ba 6b 18 00btsl   $0x0,0x18(%ebx)
Code;  c013040b <__block_commit_write+5b/c0>
   b:   0f ab 6b 18   btsl   %ebp,0x18(%ebx)
Code;  c013040f <__block_commit_write+5f/c0>
   f:   19 c0 sbbl   %eax,%eax
Code;  c0130411 <__block_commit_write+61/c0>
  11:   85 c0 testl  %eax,%eax
Code;  c0130413 <__block_commit_write+63/c0>
  13:   75 00 jne15 <_EIP+0x15> c0130415
<__block_commit_write+65/c0>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Alexander Viro]

On Wed, 6 Sep 2000, Chris Wedgwood wrote:

> Oh, yes there is.
> 
>   if (CONFIG_FOO) {
>   
>   } else {
>   
>   }
> 
> gcc can optimize that away and parser will see the whole thing. 
> 
> I'm not sure I like this construct either. 
> 
> Yes, it does mean gcc makes all the decisions and allows the
> c-compiler to to more checking (as opposed to the preprocessor which
> obviosly is really dumb) but it also assumes the compiler will always
> elimiate dead code and I'm not convinced it's any more readable that
> have "#if foo" scattered through the code.

If gcc will _ever_ fail to optimize away else in
if (1) {
...
} else {
...
}
- it's a bug in gcc. Sorry. Checking for the absence of code paths that would
lead into block in question is trivial. I suspect that if you can demonstrate
such example to gcc folks they will consider it as an obvious bug.

As readability - it's definitely at least as readable as
#if[def]. It also provides more consistent syntax. And when you are
using ifdef to violate scoping - your code is in need of rewrite anyway.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Alex Buell]

On Wed, 6 Sep 2000, Chris Wedgwood 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 put in where... the hope
> is with more intelligent debugging aids I can glean more information
> for each reboot.

If you have two machines, it does get a little easier.

Cheers, 
Alex
-- 
This message has been ROT-13 encrypted twice for extra security.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Alexander Viro]

On Wed, 6 Sep 2000, Martin Dalecki wrote:

> Alexander Viro wrote:
> > 
> > On Wed, 6 Sep 2000, Martin Dalecki wrote:
> > 
> > > Easy - the same way you do for cross compilation. Basically just:
> > >
> > > export CC=g++ --some-magic-long-option-i-dont-remember; make
> > 
> > ... and you still have only a subset of the tree, simply because it is fed
> > through cpp before it reaches the parser. And cpp cuts away many pieces.
> > Different config options and you've got a different subset. Good luck
> > providing the coverage.
> 
> That's not quite the problem - with the exception of the boundary cases
> of compleatly broken CONFIG_BLAH combinations... You have the fine
> .confg file there you know... Count them n and take the n! for all the
> possible config choices. Then you will see that THERE CAN'T be any
> better
> automatic approach then just what I have described above (ie. going
> directly into the compiler) and doing the CONFIG_ handling by hand. 
> (I mean scripting for the most appriopriate choices...)


Oh, yes there is.

if (CONFIG_FOO) {

} else {

}

gcc can optimize that away and parser will see the whole thing. 

> > > Basically I will just guess: The next maybe non free version of
> > > source navigator will use the mechanism I have just described above.
> > > So maybe there is already someone at RedHat doing exactly this work
> > > already ;-).
> > 
> > Physically impossible without a major cleanup of the tree.
> 
> Yeah... let me be nice to you as well Source Navigator got released
> for free - since the project died inside RedHat anyway due to the
> fact that it's full of the worst coding practices I ever saw - like
> for example literally copy and paste Tcl/Tk/iTcl and such. So instead
> of buring it they just threw it "out of the window" for "free".
> 

WTF _is_ Source Navigator? I'm not kidding - I have no idea what the thing
is. My IDE is nvi and I don't touch userland code I don't use. World is
full of crappy code, so I don't particulary care for random GUI stuff, no
matter where it comes from.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Richard Gooch]

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 direction they don't want to go. [...]
> 
> nobody wants to force anything on anyone - you are free to apply KDB
> and the other debugging patches. But we can certainly help the usage
> of the right kind of debugging methodology.

You might think you're encouraging people to think instead of
monkey-tap, but consider the people you're putting off. It's the other
side of that coin.

> > [...] From what I've seen, most of the
> > active developers are chronically overworked. Many projects compete
> > for your attention. Why hit your head against a purposely erected
> > brick wall?
> 
> active developers certainly have the skills to apply debugging
> facilities they need.

It's not just the skills. It's the time and energy. It's more effort,
because you have to download it (and hope it's current and kernel
drift hasn't rooted it), and you have to maintain more kernel trees
(otherwise you send out patches with IKD mistakenly included (and
don't tell me it doesn't happen, even by the most esteemed
developers)).

Skilled people are usually busy people (they have their fingers in too
many pies). While they are better able to download and apply IKD, by
the same token they are less inclined to, because they are busy, and
besides, they know that they *shouldn't have to*.

> 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 physical page in the system to detect stray DMA related memory
> corruption.  No rocket science, but ugly enough to 'taint' the
> kernel proper. Would any of the debugging facilities advocated in
> this thread have helped in the bugs we were chasing at that time?
> Nope. Do i want such debugging code to ever show up in the mainsteam
> kernel? Hell no.

Would you classify IKD as a pile of warts you wouldn't want to see in
the kernel?

Surely there must be some useful features that can be included in the
kernel without uglyfing it or slowing it down (configed out)? Leaving
aside the social engineering attempts, of course :-)

> you dont want to carry a whole car-construction factory along with
> you when you are rally-racing. You probably want to carry a spare
> tire and a mobile phone - anything else would be a slowdown.

We're already carrying a small city. One extra factory won't
hurt. It's just source bloat, not object or data bloat.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Martin Dalecki]

Alexander Viro wrote:
> 
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
> 
> > Easy - the same way you do for cross compilation. Basically just:
> >
> > export CC=g++ --some-magic-long-option-i-dont-remember; make
> 
> ... and you still have only a subset of the tree, simply because it is fed
> through cpp before it reaches the parser. And cpp cuts away many pieces.
> Different config options and you've got a different subset. Good luck
> providing the coverage.

That's not quite the problem - with the exception of the boundary cases
of compleatly broken CONFIG_BLAH combinations... You have the fine
.confg file there you know... Count them n and take the n! for all the
possible config choices. Then you will see that THERE CAN'T be any
better
automatic approach then just what I have described above (ie. going
directly into the compiler) and doing the CONFIG_ handling by hand. 
(I mean scripting for the most appriopriate choices...)
 
> > Basically I will just guess: The next maybe non free version of
> > source navigator will use the mechanism I have just described above.
> > So maybe there is already someone at RedHat doing exactly this work
> > already ;-).
> 
> Physically impossible without a major cleanup of the tree.

Yeah... let me be nice to you as well Source Navigator got released
for free - since the project died inside RedHat anyway due to the
fact that it's full of the worst coding practices I ever saw - like
for example literally copy and paste Tcl/Tk/iTcl and such. So instead
of buring it they just threw it "out of the window" for "free".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux

[David S. Miller]

   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.

   However, there are many many other people far less talented than
   yourselves and for use less capable people having a compile time
   options of IKD or something might really be of use

I think what it comes down to is that the folks who know the tree the
best and do the most work/fixing in it, think the debugging stuff
should remain a seperate patch.

We believe that it doesn't belong in the main source tree mainly
for two reasons:

1) It is clutter.  I don't want to see the debugging/debugger code
   when most of the time it serves no purpose.

   NOTE: This is different than "BUG()" and "ASSERT()" which serve
 a different purpose becuase they not only act as a
 consistency check, but they also _document_ how the author
 of the code believed the world around it must behave :-)

2) It is hoped that because it isn't the default, some new people
   will take the quantum leap to actually try debugging using the
   best debugger any of us have, our brains, instead of relying on
   automated tools.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Remarks about sigtestsetmask()

[Martin Dalecki]

1. This function is only used in the poorly maintained ftape driver.
   The usage there isn't appriopriate for modern kernels.

2. This function acts only on the sig set of the current process, so
   the first parameter should be just  a porinter to current, instead of
   currgen->sigset.

So it should be presumably removed all-together.

-- 
- phone: +49 214 8656 283
- job:   STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Alexander Viro]

On Wed, 6 Sep 2000, Martin Dalecki wrote:

> Easy - the same way you do for cross compilation. Basically just:
> 
> export CC=g++ --some-magic-long-option-i-dont-remember; make

... and you still have only a subset of the tree, simply because it is fed
through cpp before it reaches the parser. And cpp cuts away many pieces.
Different config options and you've got a different subset. Good luck
providing the coverage.
 
> And then the normal compilation is not just generating *.o files, but
> files with dumped parser trees as well. Hell It's even documented there!

Yeah... May I suggest you to take info on gcc and look for references to
preprocessor?

> Basically I will just guess: The next maybe non free version of
> source navigator will use the mechanism I have just described above.
> So maybe there is already someone at RedHat doing exactly this work
> already ;-).

Physically impossible without a major cleanup of the tree.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[David S. Miller]

   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 PROTECTED]), Dana
   Henriksen ([EMAIL PROTECTED]), same # or Drew Major, Darren's brother,
   same # ([EMAIL PROTECTED]).

This was an amusing progression:

1) Novell has the best web benchmark numbers

2) Oops, I didn't say that, Novell is, go see www.novell.com

3) Oops, that's from nearly 2 years ago, go talk to the engineers
   they have the latest numbers certainly.

I have to be honest and say that I can't take you seriously anymore.

As usual, numbers talk bullshit walks, and when Novell makes some
more up to date specweb submissions, I'll have a look, but until
then it's hot air as far as I'm concerned.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux/MANOS Kernel Debugger

[Jeff V. Merkey]

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 another NetWare server over a DOS connection (pretty slick) so
in my setup the files are always remote, though they could just as well
reside on a local fat partiton.  Having DOS resident underneath gives
you all kinds of cool stuff you can do (you will note that while MANOS
is active in memory, DOS is still resident underneath and accessible). 

Perhaps the way to do this unobtrusively would be a different loader for
Linux (a DOS loader) that will run the debugger underneath.  The
debugger in MANOS is self contained, and you will note has few
dependencies on the OS code of any kind -- it was developed this way
intentionally.  We just take the MANOS loader, rip out the kernel, load
Linux from LLOADER.386, and the debugger is there!

Jeff 



Andi Kleen wrote:
> 
> 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 require a functional file system
> to read the source code during debugging. When the kernel is stopped
> in the debugger it is definitely not safe to access anything like a file
> system in Linux (e.g. due to locking issues)
> 
> Without accessing the file system the debugger couldn't
> do much more than assembly level debugging like KDB, which already works
> fine.  Precaching source is not practical. Developing a separate independent
> file system module that works safely even from a stopped kernel (and would
> still be functional enough so that you can compile and edit files on it)
> would also be major work. I guess Manos solved it by using DOS for that,
> but this is simply not possible in Linux.
> 
> The only sane way to do source level kernel debugging  IMHO is to do
> it from a second machine (sane =~ without being in deadlock country), which
> also already works nicely using remote gdb + kgdb stub.
> 
> -Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Andi Kleen]

On Tue, Sep 05, 2000 at 07:19:11PM -0400, Peter Rival wrote:
> Linus Torvalds wrote:
> 
> > On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> > >
> > > There are several other structures that have the same problem; very
> > > generic sounding members. I wonder would a patch changing struct page
> > > to something like this be acceptable?
> >
> > No.
> >
> > What would be acceptable is something that understands C, and that can be
> > used to follow these things. Like "tags".
> >
> 
> How about something like cscope?  It's sort of backwards if you're used to
> tags, but I use it all the time here and have found it pretty useful in areas
> that I'm not familiar with.  Once they teach it how to handle assembly files
> (they may have already, I don't know) it should be great for the kernel.

cscope does not know much more about C than tags (like some regexpr
hacks to detect declarations and calls) 

What Chris wants is really something only the compiler could do: log every
reference of a pointer type to a file including line number. Then you could 
you could look for all references to "struct page *" as a type (be it from
a variable or from a cast). This would be much more
information than even -gdwarf2 includes, probably not much less than a full
parse tree. It also could not catch references from assembly files.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Alexander Viro]

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 people who are used to debug a problem in certain ways, to debug
> it, where they have no idea how to do it with the current tools, because
> nobody explained them how to use them for that problem.

OK, let me say some unpleasant things. First of all, disclaimers: (1) I'm
speaking only for myself; (2) I have no religious problems with debuggers.
However, I have problems with patches of the "I don't know WTF it was, but
it seems to go away with the patch below" kind. I have _very_ big problem
with "we have no time to investigate WTF is wrong, $BOSS required fix by
yesterday, with $FOO we will be able to slap something out of shit, saliva
and duct-tape _now_ and to hell with everything else, don't you dare to
say us that it's shit, $RANDOM_REFERENCE_TO_MARKETPLACE" kind of attitude.
I'm sorry, but all I can suggest to that kind of folks is personal,
empathical "fuck you and fuck the crap you produce". I've seen the results
of such patches. On different projects. It _never_ did any good.

"Make it easy" is OK, unless it is followed by "for lusers". And anyone
saying that code reviews are not practical can go and fuck himself. He
will, anyway. Code reviews are MUST. I have no problems with folks who
want to have debugger in addition to that. I consider anyone who wants it
as _replacement_ for code reviews as a dangerous luser who should be taken
out and put out of his misery.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux/MANOS Kernel Debugger

[Andi Kleen]

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 require a functional file system 
to read the source code during debugging. When the kernel is stopped 
in the debugger it is definitely not safe to access anything like a file
system in Linux (e.g. due to locking issues) 

Without accessing the file system the debugger couldn't
do much more than assembly level debugging like KDB, which already works 
fine.  Precaching source is not practical. Developing a separate independent
file system module that works safely even from a stopped kernel (and would
still be functional enough so that you can compile and edit files on it) 
would also be major work. I guess Manos solved it by using DOS for that,
but this is simply not possible in Linux.

The only sane way to do source level kernel debugging  IMHO is to do 
it from a second machine (sane =~ without being in deadlock country), which 
also already works nicely using remote gdb + kgdb stub.


-Andi 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Jeff V. Merkey]

"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 ;-)))

They've got some newer stuff.  The best way to get the latest numbers
would be to call Craig Miller 801-861-7000 ([EMAIL PROTECTED]), Dana
Henriksen ([EMAIL PROTECTED]), same # or Drew Major, Darren's brother,
same # ([EMAIL PROTECTED]).  Drew will have the latest numbers for
certain since he wrote the Web Server on NetWare, but both Craig and
Dana are the guys to talk to about NetWare and could get them.  Dana is
the maintainer and principal architect of NetWare and knows more about
it than anyone except Drew and Darren.

:-)

Jeff

> 
> Later,
> David S. Miller
> [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[David S. Miller]

   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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Jeff V. Merkey]

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 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 Netware held some old specweb record with the specweb96 version
> of that benchmark, which is %100 static content whereas specweb99 is
> part static part dynamic content.
> 
> I have just checked and in fact I do not see any SpecWeb99 submitted
> results which use NetWare as the OS.
> 
> Later,
> David S. Miller
> [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Kurt Roeckx]

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 ignoring our arguments. With utmost respect, we *do* care about
> what's underneath. The health of what's underneath fueled and fuels the
> growth of Linux. I'd like to repeat it again: we cannot optimize for both
> the speed of FS driver development (your goal - correct me if i got it
> wrong), and long term health of the kernel proper itself (our goal),
> because in some areas (such as the inclusion of high complexity debugging
> facilities) they do contradict. (mostly they dont contradict) Long term
> health has priority - i cannot put it any simpler for you. Anyone who
> thinks driver development is the most important for Linux then thats a
> pretty shortsighted view IMO.

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, or just think they can't easely do it with them. It could help
certain people who are used to debug a problem in certain ways, to debug
it, where they have no idea how to do it with the current tools, because
nobody explained them how to use them for that problem.

That debugger shouldn't be part of the main kernel, specially if it's so
complex. Trying to get the debugger to work might even find problems you
wouldn't easely find otherwise.


Kurt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[David S. Miller]

   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 Netware held some old specweb record with the specweb96 version
of that benchmark, which is %100 static content whereas specweb99 is
part static part dynamic content.

I have just checked and in fact I do not see any SpecWeb99 submitted
results which use NetWare as the OS.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel debugging

[Martin Dalecki]

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, fixed)  returntype functionname
> (PARM(parameters)){
> DEBUG(ENTRY,SUBSYSTEM, module, functionname);
> /* function body starts */
> do something
> do something
> on success goto  ok;
> on failure goto failure_reason_name;
> /* function body ends */
> ok:
>   on ok do something
> DEBUG(EXIT,SUBSYSTEM, module functionname, OK);
> exit or return whatever
> failure_reason_name;
>   on this reason do something
> DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name);
> exit or return whatever
> failure_reason_name1;
>   on this reason do something
> DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name1);
> exit or return whatever
> };
> --

Please have a tought look at the floppy tape streamer driver to see why
this
is a BAD IDEA.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Martin Dalecki]

Linus Torvalds wrote:
> 
> On Tue, 5 Sep 2000, Alexander Viro wrote:
> > >
> > > What would be acceptable is something that understands C, and that can be
> > > used to follow these things. Like "tags".
> >
> >   I don't like hungarian notation too, but tags is out of question,
> > unfortunately. Too much preprocessor abuse in include/*/*.h.
> 
> Notice the _like_ tags.
> 
> Basically, what I'm saying is that I understand why people want to grep
> for specific uses, but I'm saying that a pure textual greap that doesn't
> understand the context is not an option - because it implies adding
> "cruft" to everything you want to grep for. Not for readability, but for
> greppability.
> 
> And I'm saying that if people really want to do this, then use the
> computer to do it for you, having more than just "grep", and making your
> tools aware of it.

There is some facility allowing to implement this kind of things
in the C++ part of the most recent EGCS version which makes implementing
such things "relatively" easy - basiclly there is the provision to dump
the parser trees as easy to process ascii text already there.

Basically I think this dererr of syntactical analysis can only be
implementen by serious help from the compiler.

Maybe this is a new argument to facilitate at least correct syntactical
processing of the kernel by  the C++ flavour of EGCS?

Please note that this wouldn't need to generate really executable code -
which as we all know is rather difficult due to the extensive runtime
support as well as ehm. the wired calling conventions C++ is oppressing
on the compiler... Just correct syntactical processing is all what's
neccessary -
this isn't THAT difficult to achive ;-).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.2: /proc/config.gz

[Timur Tabi]

** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Fri, 01 Sep 2000
11:10:49 +1100


> Having one directory per installed kernel containing vmlinuz, map,
> config, build symlink, modules and any future kernel related data makes
> sense.

I agree.  This idea gets my vote!


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test8-pre4 data corruption?

[Linus Torvalds]

On Wed, 6 Sep 2000, Chris Wedgwood wrote:

> On Tue, Sep 05, 2000 at 06:25:39PM -0300, Rik van Riel wrote:
> 
> I hope Linus will release an "emergency" 2.4.0-test8-pre5 really
> soon, maybe even with /only/ Al Viro's two-line fix...
> 
> Ouch... I just got hit by this. At first I though it was flakey mbox
> code and started saying bad works.
> 
> Here is the fix diff style for those who missed it:

..and test5 is out there now (and if you get test5, please don't apply the
fix in reverse by mistake ;)

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

linux-2.4.0-test8-pre5

[Linus Torvalds]

This entry in the changelog says it all:

- truncate. Guess what? We threw away the key to the clue-box

Most of the other stuff is cleanups or reasonably straightforward fixes.
The truncate thread that's been going through the last few pre-releases is
the big thing, and the one that has caused heartache.

Oh, well. It really is fixed now. Everybody involved has been forced to
wear the brown paper bag for the next month or so, but we cut out small
holes so that we can see where we are going and not bump into things and
make even more of a spectacle of ourselves.

And the really is fixed this time. Cross my heart and hope to die. I can
only say that "truncate" has always been the nastiest operation of them
all. 

[ The truncate bug, btw, has been there for roughly 14 months. We just
  first made it easier to trigger, and then messed up about three times
  when we tried to fix it. Oh, well. ]

Read my lips. No more fscks. And thanks to everybody who did.

Linus

-
test8:
 - pre1
- Oops. Moved back stallion.c to drivers/char. It's not a TV driver.
  Never has been, and I don't see it ever really becoming one ;)
- mca.c: outp_b() should be outb_p().  Obviously nobody actually
  _uses_ the MCA bus any more ;)
- umsdos should be ok again after the page_address() type-changes.
- re-enable asynchronous read-ahead code.
- Sun ESP driver update
- netfilter debug fixes
- IPv6 needs to register before proto_init()
- socket() error code fix (EAFNOSUPPORT instead of EINVAL)
- potential TCP socket leak fix
- don't self-deadlock on the kbd_controller_lock when probing for the mouse
- CONFIG_SMB_NLS_REMOTE didn't work. Silly typo.
- scheduler wakeup race condition could cause delayed scheduling on SMP..
- net/packet/af_packet.c: use the standard macros for marking page resevredness
- ncpfs buffer-overflow fix
- thread groups, take 1.
- USB storage driver update
 - pre2
- The TCP socket leak patch _really_ went in this time.
- get rid of more suser() checks in networking.. It's "capable(CAP_NET_ADMIN)".
- sparc updates
- alpha updates. Fast alpha xor for raid. AP1000 updates.
- Wonders never cease. digiboard driver updates. Christoph Lameter is BAAACK!
- SiS frame buffer driver updates. Can be used without a BIOS.
- nfsd interface cleanup.
- fix potential buffer overruns in get_partition_list.  Remove
  limitation of one page. 
- floppy driver capability cleanups. Use "request_region()".
- handle dcache flushing when there are shared user mappings that
  may be dirty. 
- get rid of the "_ret()" user access macros. They are more complex than
  just doing the return directly and they hide what's going on.
- fix up broken BIOSes that don't give unique ID's to different APICs
- make more of the drm drivers compile on other platforms and know
  about the signal blocking issues.
- net/atm/mpoa_proc.c: user-space access thinko
- pcmcia: David Hinds: merge updates from 3.1.20
- pcmcia: non-ISA machines really shouldn't use ISA interrupts ;)
- ext2: truncate races and error code return fixes
- true shared signals for pthreads..
 - pre3:
- ext2: final truncate piece - fix the innd problem.
- use "sfence" for x86 memory barrier when available.
- remove the thread-group signal code for now: no feedback.
  Leave the cleanups in place so that we can add it back in
  cleanly later, but remove the new features.
- ARM update.
- released for Al Viro to check the truncate thing
 - pre4:
- truncate really fixed this time. Everybody agrees.
 - pre5
- truncate. Guess what? We threw away the key to the clue-box.
- simplify signal notification. And remember the spinlock.
- VIA ide driver update (well, rewrite - the old one was buggy and broken)
- network driver fixes (not checking for oom etc)
- USB serial driver SMP locking fixes
- fix memory leak on failed USB configuration queries
- USB initialization using proper "init()" calls.
- dvd capacity bug fix and other cdrom driver cleanups
- sis5513 IDE chipset update
- do_fork() - add "stack-top" for ia64 (and potentially other
  architectures that may care)
- devfs support for LVM
- quota transfer miscount fix
- x86 checksum/copy prefetch
- NFS sillydelete fix
- mark_buffer_dirty() doesn't actually use the second argument. Delete it.
- SCSI communications device - no need to complain about it
- SCSI WP test fix (all pages, not just the first one)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Ingo Molnar]

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. [...]

nobody wants to force anything on anyone - you are free to apply KDB and
the other debugging patches. But we can certainly help the usage of the
right kind of debugging methodology.

> [...] From what I've seen, most of the
> active developers are chronically overworked. Many projects compete
> for your attention. Why hit your head against a purposely erected
> brick wall?

active developers certainly have the skills to apply debugging facilities
they need. 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
physical page in the system to detect stray DMA related memory corruption.
No rocket science, but ugly enough to 'taint' the kernel proper. Would any
of the debugging facilities advocated in this thread have helped in the
bugs we were chasing at that time? Nope. Do i want such debugging code to
ever show up in the mainsteam kernel? Hell no.

you dont want to carry a whole car-construction factory along with you
when you are rally-racing. You probably want to carry a spare tire and a
mobile phone - anything else would be a slowdown.

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.x driver audit help

[Arnaldo Carvalho de Melo]

Em Tue, Sep 05, 2000 at 08:06:21PM +0200, Jes Sorensen escreveu:
> > "Frank" == Frank Davis <[EMAIL PROTECTED]> writes:
> 
> Frank> Hello all, Anyone wishing to re-audit the drivers/block and
> Frank> drivers/char for locking issues and submit their patches to me
> Frank> directly, feel free. I think if more people comb through the
> Frank> code than myself, patches I missed will be found (100 eyes are
> Frank> better than 2). Once I think I have all the neccessary patches,
> Frank> blessed by the current maintainers, then I'll submit the
> Frank> patches to Linus for a finally blessing for inclusion into
> Frank> 2.4.0.  Regards, Frank [EMAIL PROTECTED]
> 
> It would be a lot more useful if you posted incremental patches here
> instead of doing a giant mega patch once you decide it's done.

I completely agree with Jes, I've done one such big patch and it was
rejected, sent dozens of patches and lots have been applied, please send
incremental patches, please.

- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18-3 seems to break pcmcia-cs-3.1.20

[Marcelo Tosatti]

On Tue, 5 Sep 2000 [EMAIL PROTECTED] wrote:

> # make all
> make[1]: Entering directory /usr/src/pcmcia-cs-3.1.20/modules'
> cc   -MD -O2 -Wall -Wstrict-prototypes -pipe -I../include
> -I/usr/src/linux/include  -D__KERNEL__ -DMODULE -c cs.c
> In file included from /usr/src/linux/include/linux/fs.h:12,

Thats because 2.2.18pre3 has a 2.4 "compatibility layer".

The attached patch fixes the problem. 

diff -Nur pcmcia-cs-3.1.20.orig/include/pcmcia/k_compat.h 
pcmcia-cs-3.1.20/include/pcmcia/k_compat.h
--- pcmcia-cs-3.1.20.orig/include/pcmcia/k_compat.h Tue Sep  5 15:57:21 2000
+++ pcmcia-cs-3.1.20/include/pcmcia/k_compat.h  Tue Sep  5 16:07:30 2000
@@ -55,7 +55,7 @@
 #define DEV_ID dev_id
 #define IRQ_MAP(irq, dev)  do { } while (0)
 
-#if (LINUX_VERSION_CODE < VERSION(2,3,1))
+#if (LINUX_VERSION_CODE < VERSION(2,3,1)) && (LINUX_VERSION_CODE < VERSION(2,2,18))
 #if (LINUX_VERSION_CODE < VERSION(2,0,16))
 #define init_waitqueue_head(p) (*(p) = NULL)
 #else
@@ -162,10 +162,10 @@
 #define mdelay(x) { int i; for (i=0;istate = TASK_INTERRUPTIBLE; } while (0)
-#elif (LINUX_VERSION_CODE < VERSION(2,3,16))
+#elif (LINUX_VERSION_CODE < VERSION(2,3,16)) && (LINUX_VERSION_CODE < VERSION(2,2,18))
 #define __set_current_state(n) do { current->state = (n); } while (0)
 #endif
 
 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Alan Cox]

> > True the i960 based one I didn't think of, however Intel never
> > provided docs for it.
> 
> ??? I find this surprising.  Email [EMAIL PROTECTED] and ask him if
> they will give them to you.  I'm sure they would for Linux.

I've spent over 2 years trying to extract eepro100 server docs out of Intel
and failed. I've been refused info on how to detect the problematic 820/840
boards with the memory translation hub - which means we now flush many intel
chipset related bug reports into the 'cannot trust hardware' bucket. Intel
have also consistently refused to document the MSR's that allow you to read
the CPU intended speed and the bus clock that would allow us to flag and
note overclocked CPU's on the /proc/cpuinfo and help bug reporting.

Intel document what they feel like documenting, on their own agenda for their
own purposes.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Jes Sorensen]

> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:

Jeff> IPX is a really good LAN protocol (but totally sucks for
Jeff> internet).  A full blown NCP server in-kernel that's toughtly
Jeff> coupled to the page cache running over IPX would make flames
Jeff> shoot out of the back of a Linux server, and make NT like look
Jeff> an old lady hobbling down the street.  There's no need to
Jeff> configure client addresses with it, and for file and print, it's
Jeff> the best.

IPX is WHAT?

I'd recommend you go look at the switches on your network and note how
they look likg flashing chrstmas trees - broadcast traffic is not good
for any type of network, be it LAN or WAN.

Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Jeff V. Merkey]

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, myself? ;)

Ingo,

I on't believe debating with you on this topic will change your mind  --
you seem to have already decided.  Here's some substance -- visit
vger.timpanogas.org/manos/os/src/*.tar.gz  download the code, boot it,
copy the source files, invoke the kernel debugger (with alt-d) and try
it for yourself and see if you think having that in inux would save you
hours of debugging time.  

:-)

Jeff

> 
> Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [Danger] Re: test8-pre4: innd fixed?

[Horst von Brand]

=?iso-8859-1?Q?Andr=E9_Dahlqvist?= <[EMAIL PROTECTED]> said:

[...]

> Believe it or not, but I just saw something similar on test7 while
> reading linux-kernel with Mutt. A recent message to linux-kernel from
> Daniel Philips got partly zeroed out, and partly tangled up with a
> message from the debian-user mailing lists. This message had a very
> long From: line. Here's the weird message:

I've also seen messed up files (even totally innocent bystanders AFAICT)
with ext2 on Red Hat 6.9.5 and linux-2.4.0-test7, P3/600.  Also broken
group descriptors, files with weird modes, you name it. Building a kernel
there sometimes gives massive fallout from fsck(8).
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Linus Torvalds]

On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> 
> There are several other structures that have the same problem; very
> generic sounding members. I wonder would a patch changing struct page
> to something like this be acceptable?

No.

What would be acceptable is something that understands C, and that can be
used to follow these things. Like "tags". 

I do not like hungarian notion. I do not agree with making names easy to
grep for. I like _human_ readable source code.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.x driver audit help

[Jes Sorensen]

> "Frank" == Frank Davis <[EMAIL PROTECTED]> writes:

Frank> Hello all, Anyone wishing to re-audit the drivers/block and
Frank> drivers/char for locking issues and submit their patches to me
Frank> directly, feel free. I think if more people comb through the
Frank> code than myself, patches I missed will be found (100 eyes are
Frank> better than 2). Once I think I have all the neccessary patches,
Frank> blessed by the current maintainers, then I'll submit the
Frank> patches to Linus for a finally blessing for inclusion into
Frank> 2.4.0.  Regards, Frank [EMAIL PROTECTED]

It would be a lot more useful if you posted incremental patches here
instead of doing a giant mega patch once you decide it's done.

Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[dean gaudet]

On Sun, 3 Sep 2000, Andre Hedrick wrote:

> But there is no Copyright license in patch code.

On Mon, 4 Sep 2000, Mike A. Harris wrote:

> I was under the understanding a "patch" to something GPL, means
> the "patch" is also GPL.

when IBM started working with the apache group their lawyers did a bunch
of studying of various licenses and worked out a system by which their
folks could contribute code.  one of the things their folks do is
explicitly release every patch under the apache license -- just to be
sure.  they tend to explicitly include the release boilerplate along with
the patch mail message... but they did mention that the method that i've
been using for years is probably fine as well, although somewhat weaker.

look in my message headers and you'll see i point folks at
, and one of the clauses in there
explicitly puts any patch/docs/etc. i send in a message under the same
license as the software it's intended to support.

explicit notices are much better for legal purposes.  although just by
posting you never give up your copyright -- you have to do that explicitly
(i explicitly listed public domain because it's a blanket "i give up my
rights" when you do that).  linus or anyone taking your patches and
putting them into the kernel without your explicit release is weaker
legally than if you put a notice in your messages.

you can expect all these issues to come up the first time the GPL is
challenged in court.

IANAL.

-dean

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Jes Sorensen]

> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:

Jeff> Intel Nitro Card - i960 processor on the card.  The SMP
Jeff> debugging involved the use of a bus analyser since this card had
Jeff> a piggish memory bus footprint (i960 processors do not have an
Jeff> IO address space, so everything is memory mapped.  The big
Jeff> weakness of early I2O stuff was that the I960 running off on the
Jeff> boards had access to the memory bus of these early systems.
Jeff> Performace problems that were related to passing messages to the
Jeff> embedded OS running on the i960 on the Nitro Card, and it
Jeff> "missing" messages when two processors were talking to it at
Jeff> once.

True the i960 based one I didn't think of, however Intel never
provided docs for it.

Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.x driver audit help

[Frank Davis]

Hello,
 Posting incremental changes to l-k is fine, just CC me, and I'll compile a list 
of patches for inclusion into 2.4.0 .
Regards,
-Frank

--Original Message--
From: Jes Sorensen <[EMAIL PROTECTED]>
To: Frank Davis <[EMAIL PROTECTED]>
Sent: September 5, 2000 6:06:21 PM GMT
Subject: Re: 2.4.x driver audit help


> "Frank" == Frank Davis <[EMAIL PROTECTED]> writes:

Frank> Hello all, Anyone wishing to re-audit the drivers/block and
Frank> drivers/char for locking issues and submit their patches to me
Frank> directly, feel free. I think if more people comb through the
Frank> code than myself, patches I missed will be found (100 eyes are
Frank> better than 2). Once I think I have all the neccessary patches,
Frank> blessed by the current maintainers, then I'll submit the
Frank> patches to Linus for a finally blessing for inclusion into
Frank> 2.4.0.  Regards, Frank [EMAIL PROTECTED]

It would be a lot more useful if you posted incremental patches here
instead of doing a giant mega patch once you decide it's done.

Jes


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Ingo Molnar]

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. [...]

(there is really no need for name-calling, i was purely describing
technical arguments. I started the development of half of the debugging
utilities which are IKD today - so you certainly cannot accuse me of not
being support-oriented enough.)

> [...] We need tools to make it faster and easier for folks to perform
> kernel development and make field support of Linux easier.

debugging tools are not necesserily the most important goal to help the
Linux kernel. IMO we rather need people who have a deeper understanding of
things - even if this makes support a bit harder. If it was up to the
support department then the Linus would drop dead today and only bugs
would be fixed in the kernel tree. Being only support-oriented isnt
exactly helping Linux. If we can do something that helps support - sure
lets do it! But if something contradicts with some other, potentially more
imporant goal, then that other goal takes precedence.

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Jes Sorensen]

> "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
which you have just declared to be withdrawn so you can go stick it
into your own custom OS? I don't remember seeing you contribute code
to any other part of the kernel, besides scream about bugs in the
kernel that shows up to be bugs in your compiler etc.

Jes

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Suggestion for laptop suspension

[Richard Stallman]

Well, while it would be a good option to have, I'm not sure it's a
good idea to make it the default. If you flush the buffer+page caches,
then later you will need to repopulate them. 

It is worth caching data, in ordinary circumstances, because it has a
certain chance of being useful and caching costs essentially nothing.
But often the data will never be used again.  It is not worth waiting
to write and then reread many megabytes of cached data.

What would be nicer is if when you suspend, you record the cached
block numbers (and then flush+clear the caches), and on resume kick
off a daemon/kernel thread which touches those blocks, bringing them
back into the caches.

If this is done in background, whenever there is no other disk
activity, it could not do any harm.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Alexander Viro]

On Tue, 5 Sep 2000, Linus Torvalds wrote:

> 
> 
> On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> > 
> > There are several other structures that have the same problem; very
> > generic sounding members. I wonder would a patch changing struct page
> > to something like this be acceptable?
> 
> No.
> 
> What would be acceptable is something that understands C, and that can be
> used to follow these things. Like "tags". 
> 
> I do not like hungarian notion. I do not agree with making names easy to
> grep for. I like _human_ readable source code.

I don't like hungarian notation too, but tags is out of question,
unfortunately. Too much preprocessor abuse in include/*/*.h. Besides,
tags doesn't distinguish structure types, IIRC - same problem as with grep
(notice the pattern I've used - it weeds out everything not in the "field
of some structure" contexts).

The _real_ problem is preprocessor abuse. BTW, could we schedule for
2.5 the following?
* things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
* #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
branches just fine.
* Yes, Virginia, it means that controlflow-affecting expansion has to
go. Good riddance, IMO.

Goal: making sure that every bloody line of the files we choose to
compile goes through the parser. Will do wonders with test coverage and will
make analysis tools like tags viable. Then we can just use the gcc frontend
output as input for such beasts.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

kernel debugging

[Elmer Joandi]

>  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
(PARM(parameters)){
DEBUG(ENTRY,SUBSYSTEM, module, functionname);
/* function body starts */
do something
do something
on success goto  ok;
on failure goto failure_reason_name;
/* function body ends */
ok:
  on ok do something
DEBUG(EXIT,SUBSYSTEM, module functionname, OK);
exit or return whatever
failure_reason_name;
  on this reason do something
DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name);
exit or return whatever
failure_reason_name1;
  on this reason do something
DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name1);
exit or return whatever
};
--


You see, you try to catch somebody by following their steps.
Instead, try to enchanche your own advantages.

Those two macros: DEBUG and INLINE would let the code be
generated as effective as possible and as debuggable as possible.
strict rule that all returns must be explicitly goto'd to the end would
make code also much easier to read and would force people to
formalize all  failure reasons.

Closed source people have only one way to go, it is to make
kernel binary fully debuggable.

Imagine kernel configuration options: which subsystems
to optimize for speeed and which for size, for which to have
debug options turned on, etc. Different debug macros
for different situations - debugging, logging, timing.
All printk's made macros and configure-time option to dump
them all... that way the kernel may run in 2MB 386sx16 again
for embedded devices and have lots of inlines for 2MB cache
Xeon processors.

For to stay competitive, linux should less try to repeat others
tricks and more try to advance those, whitch are naturally its own.
Essentially the trick that everyone may recompile the kernel.

elmer.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Jes Sorensen]

> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:

Jeff> Jes Sorensen wrote:
>>  True the i960 based one I didn't think of, however Intel never
>> provided docs for it.

Jeff> ??? I find this surprising.  Email [EMAIL PROTECTED] and ask
Jeff> him if they will give them to you.  I'm sure they would for
Jeff> Linux.

Well you obviously never had to deal with some of these companies. I
have little interest in writing a driver for a card which I don't have
and which is very old. I know that Don Becker had problems in the past
getting proper specs out on some of the other Intel cards, I don't
know whether he tried to get specs on the Nitro but I would asume so.
>From Don's web page about unsupported boards:

  "No board with an on-board processor is supported, because these
  invariably have a proprietary/undocumented interface. (EEPro Server
  and Matrox multiport PCI switch cards fall into this category.)".

Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Jeff V. Merkey]

Jes Sorensen wrote:
> 
> > "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
> 
> Jeff> Intel Nitro Card - i960 processor on the card.  The SMP
> Jeff> debugging involved the use of a bus analyser since this card had
> Jeff> a piggish memory bus footprint (i960 processors do not have an
> Jeff> IO address space, so everything is memory mapped.  The big
> Jeff> weakness of early I2O stuff was that the I960 running off on the
> Jeff> boards had access to the memory bus of these early systems.
> Jeff> Performace problems that were related to passing messages to the
> Jeff> embedded OS running on the i960 on the Nitro Card, and it
> Jeff> "missing" messages when two processors were talking to it at
> Jeff> once.
> 
> True the i960 based one I didn't think of, however Intel never
> provided docs for it.

??? I find this surprising.  Email [EMAIL PROTECTED] and ask him if
they will give them to you.  I'm sure they would for Linux.

Jeff

> 
> Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Jeff V. Merkey]

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 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
> which you have just declared to be withdrawn so you can go stick it
> into your own custom OS? I don't remember seeing you contribute code
> to any other part of the kernel, besides scream about bugs in the
> kernel that shows up to be bugs in your compiler etc.
> 
> Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Jeff V. Merkey]

Dear Stu,

I apologize for bothering you, but how possible would it be to let the
Linux folks get access to the Nitro docs and docs for Intel ethernet
cards in general.  There seems to be interest from folks in getting this
to improve Linux support for Intel products.

Any help would be appreciated.

Thanks,

Jeff Merkey

Alan Cox wrote:
> 
> > > True the i960 based one I didn't think of, however Intel never
> > > provided docs for it.
> >
> > ??? I find this surprising.  Email [EMAIL PROTECTED] and ask him if
> > they will give them to you.  I'm sure they would for Linux.
> 
> I've spent over 2 years trying to extract eepro100 server docs out of Intel
> and failed. I've been refused info on how to detect the problematic 820/840
> boards with the memory translation hub - which means we now flush many intel
> chipset related bug reports into the 'cannot trust hardware' bucket. Intel
> have also consistently refused to document the MSR's that allow you to read
> the CPU intended speed and the bus clock that would allow us to flag and
> note overclocked CPU's on the /proc/cpuinfo and help bug reporting.
> 
> Intel document what they feel like documenting, on their own agenda for their
> own purposes.
> 
> Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Suggestion for laptop suspension

[Richard Stallman]

Well, while it would be a good option to have, I'm not sure it's a
good idea to make it the default. If you flush the buffer+page caches,
then later you will need to repopulate them. 

It is worth caching data, in ordinary circumstances, because it has a
certain chance of being useful and caching costs essentially nothing.
But often the data will never be used again.  It is not worth waiting
to write and then reread many megabytes of cached data.

What would be nicer is if when you suspend, you record the cached
block numbers (and then flush+clear the caches), and on resume kick
off a daemon/kernel thread which touches those blocks, bringing them
back into the caches.

If this is done in background, whenever there is no other disk
activity, it could not do any harm.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Jeff V. Merkey]

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 respect, we *do* care about
> what's underneath. The health of what's underneath fueled and fuels the
> growth of Linux. I'd like to repeat it again: we cannot optimize for both
> the speed of FS driver development (your goal - correct me if i got it
> wrong), and long term health of the kernel proper itself (our goal),
> because in some areas (such as the inclusion of high complexity debugging
> facilities) they do contradict. (mostly they dont contradict) Long term
> health has priority - i cannot put it any simpler for you. Anyone who
> thinks driver development is the most important for Linux then thats a
> pretty shortsighted view IMO.
> 

Ingo,

I think the disconnect for you here is that you assume the Linux world
will remain constant and that everything must look like unix to be
good.  In NetWare, susbsytems that are user space in Linux are in-kernel
in NetWare for speed.  NDS is a good example. NCP is another, routing is
another.  I am moving this stuff in-kernel to replicate NetWare's
performance -- debugging an in-kernel NDS with "code reviews" will take
forever.  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 I'm sure folks want to do with Linux they cannot because it
too tough to debug.  SMP problems I've run into on Linux with just take
too long without these types of tools.  THis is  simple issue.  I told
Darren Major, Drew Major's brother, folks comments this morning against
a kernel debugger in Linux -- he shook his head and said "how stupid can
they be?"  Enough said.

Jeff 


> Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Dan Hollis]

On Tue, 5 Sep 2000, Henning P . Schmiedehausen wrote:
> On Tue, Sep 05, 2000 at 11:25:12AM -0700, Dan Hollis wrote:
> > I think you mean IPX is dead. Netware *could* work over TCP or UDP.
> > IP is definitely king. Even micro$haft gave up on NetBEUI.
> Yep, thats' what I meant. Sorry that I was not clearer. But I think
> that there are even with NetWare on IP not many new
> installations. There is lots of migration of existing servers and
> keeping existing systems alive but new rollouts?
> But then again, maybe with MANOS and OpenNetWare, everything will be
> different.

OpenNetWare could reign king, if they would abandon the legacy cruft.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Dan Hollis]

On 5 Sep 2000, Henning P. Schmiedehausen wrote:
> [EMAIL PROTECTED] (Jeff V. Merkey) writes:
> >IPX is a really good LAN protocol (but totally sucks for internet).  A
> Jeff, Netware is dead. Please leave it there. IP won. The number of
> new Netware Installations (as compared to existing or just upgrades)
> is close (really close) to nil.

I think you mean IPX is dead. Netware *could* work over TCP or UDP.
IP is definitely king. Even micro$haft gave up on NetBEUI.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] devfs support for LVM

[Christoph Hellwig]

Hi Linus,
I've updated my devfs for lvm patch to 2.4.0-test8pre.
Here it is.

Christoph

-- 
Always remember that you are unique.  Just like everyone else.


--- linux.orig/drivers/block/lvm.c  Fri Jul 14 14:38:29 2000
+++ linux/drivers/block/lvm.c   Sun Sep  3 13:54:00 2000
@@ -299,6 +299,11 @@
 
 static spinlock_t lvm_lock = SPIN_LOCK_UNLOCKED;
 
+static devfs_handle_t lvm_devfs_handle;
+static devfs_handle_t vg_devfs_handle[MAX_VG];
+static devfs_handle_t ch_devfs_handle[MAX_VG];
+static devfs_handle_t lv_devfs_handle[MAX_LV];
+
 static struct file_operations lvm_chr_fops =
 {
owner:  THIS_MODULE,
@@ -358,13 +363,18 @@
printk(KERN_ERR "%s -- register_chrdev failed\n", lvm_name);
return -EIO;
}
-   if (register_blkdev(MAJOR_NR, lvm_name, _blk_dops) < 0)
-   {
+   if (register_blkdev(MAJOR_NR, lvm_name, _blk_dops) < 0) {
printk("%s -- register_blkdev failed\n", lvm_name);
if (unregister_chrdev(LVM_CHAR_MAJOR, lvm_name) < 0)
printk(KERN_ERR "%s -- unregister_chrdev failed\n", lvm_name);
return -EIO;
}
+
+   lvm_devfs_handle = devfs_register(
+   0 , "lvm", 0, 0, LVM_CHAR_MAJOR,
+   S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP,
+   _chr_fops, NULL);
+
 #if defined CONFIG_LVM_PROC_FS && defined CONFIG_PROC_FS
create_proc_info_entry(LVM_NAME, S_IFREG | S_IRUGO,
   _root, lvm_proc_get_info_ptr);
@@ -422,6 +432,8 @@
 {
struct gendisk *gendisk_ptr = NULL, *gendisk_ptr_prev = NULL;
 
+   devfs_unregister (lvm_devfs_handle);
+
if (unregister_chrdev(LVM_CHAR_MAJOR, lvm_name) < 0) {
printk(KERN_ERR "%s -- unregister_chrdev failed\n", lvm_name);
}
@@ -1625,6 +1637,14 @@
kfree(vg_ptr);
return -EFAULT;
}
+
+   vg_devfs_handle[vg_ptr->vg_number] = devfs_mk_dir(0, vg_ptr->vg_name, NULL);
+   ch_devfs_handle[vg_ptr->vg_number] = devfs_register(
+   vg_devfs_handle[vg_ptr->vg_number] , "group",
+   DEVFS_FL_DEFAULT, LVM_CHAR_MAJOR, vg_ptr->vg_number,
+   S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP,
+   _chr_fops, NULL);
+
/* we are not that active so far... */
vg_ptr->vg_status &= ~VG_ACTIVE;
vg[VG_CHR(minor)] = vg_ptr;
@@ -1852,6 +1872,9 @@
/* let's go inactive */
vg_ptr->vg_status &= ~VG_ACTIVE;
 
+   devfs_unregister (ch_devfs_handle[vg_ptr->vg_number]);
+   devfs_unregister (vg_devfs_handle[vg_ptr->vg_number]);
+
/* free LVs */
/* first free snapshot logical volumes */
for (i = 0; i < vg_ptr->lv_max; i++) {
@@ -1907,6 +1930,7 @@
 {
int l, le, l_new, p, size;
ulong lv_status_save;
+   char *lv_tmp, *lv_buf;
lv_block_exception_t *lvbe = lv->lv_block_exception;
vg_t *vg_ptr = vg[VG_CHR(minor)];
lv_t *lv_ptr = NULL;
@@ -2062,6 +2086,17 @@
vg_ptr->lv_cur++;
lv_ptr->lv_status = lv_status_save;
 
+   strtok(lv->lv_name, "/");   /* /dev */
+
+   while((lv_tmp = strtok(NULL, "/")) != NULL)
+   lv_buf = lv_tmp;
+
+   lv_devfs_handle[lv->lv_number] = devfs_register(
+   vg_devfs_handle[vg_ptr->vg_number], lv_buf,
+   DEVFS_FL_DEFAULT, LVM_BLK_MAJOR, lv->lv_number,
+   S_IFBLK | S_IRUSR | S_IWUSR | S_IRGRP,
+   _blk_dops, NULL);
+
/* optionally add our new snapshot LV */
if (lv_ptr->lv_access & LV_SNAPSHOT) {
/* sync the original logical volume */
@@ -2153,6 +2188,8 @@
lv_ptr->lv_snapshot_org->lv_access &= ~LV_SNAPSHOT_ORG;
lvm_snapshot_release(lv_ptr);
}
+
+   devfs_unregister(lv_devfs_handle[lv_ptr->lv_number]);
 
 #ifdef DEBUG_KFREE
printk(KERN_DEBUG "%s -- kfree %d\n", lvm_name, __LINE__);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Jeff V. Merkey]

Only Linux makes the lights flash with IPX RIP/SAP.  NetWare uses NLSP
routing and has since 1993 for IPX/SPX.  I agree if someone is running
NetWare 3 or NetWare 4.1 or earlier there's a lot of RIP/SAP traffic,
but not the NLSP versions -- they do not use RIP/SAP but NLSP.

Jeff

Jes Sorensen wrote:
> 
> > "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
> 
> Jeff> IPX is a really good LAN protocol (but totally sucks for
> Jeff> internet).  A full blown NCP server in-kernel that's toughtly
> Jeff> coupled to the page cache running over IPX would make flames
> Jeff> shoot out of the back of a Linux server, and make NT like look
> Jeff> an old lady hobbling down the street.  There's no need to
> Jeff> configure client addresses with it, and for file and print, it's
> Jeff> the best.
> 
> IPX is WHAT?
> 
> I'd recommend you go look at the switches on your network and note how
> they look likg flashing chrstmas trees - broadcast traffic is not good
> for any type of network, be it LAN or WAN.
> 
> Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18-3 seems to break pcmcia-cs-3.1.20

[Alan Cox]

> ../include/pcmcia/k_compat.h:64: ait_queue_head_t' previously declared
> here
> {standard input}: Assembler messages:
> {standard input}:9: Warning: Ignoring changed section attributes for
> .modinfo

Im working on weeding out the tons of duplicated gunge in the header files.
For the moment assume there may be some further re-ordering and messing about.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Question regarding kernel_threads

[Ulrich Drepper]

[EMAIL PROTECTED] writes:

> I'm currently thinking of adding a PF_NOZOMBIE flag to the process
> flags which releases the process immeadiately instead of calling
> exit_notify in do_exit in exit.c

I think this should happen if the exit signal is zero.  At least I
would like to use it this way.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Quick memory corruption with cramfs

[George France]

Hello Pavel;

> Is anyone using cramfs?
> 

We use cramfs everyday at http://handhelds.org with Linux
2.4.0-test6-rmk1-np2-hh1. We have no problems.

> I copy cramfs image from nfs onto /dev/ram0, then mount it. It mounts,
> and first few accesses are okay, but then it breaks. ls shows garbage
> etc.

We run the cramfs image out of flash instead of ram. Are you mounting the
cramfs image as 'ro'??

Best Regards,


--George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: zero-copy TCP

[Jes Sorensen]

> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:

Jeff> Only Linux makes the lights flash with IPX RIP/SAP.  NetWare
Jeff> uses NLSP routing and has since 1993 for IPX/SPX.  I agree if
Jeff> someone is running NetWare 3 or NetWare 4.1 or earlier there's a
Jeff> lot of RIP/SAP traffic, but not the NLSP versions -- they do not
Jeff> use RIP/SAP but NLSP.

Well I looked at the switches for NT installations not Linux boxes, it
was a sad sight.

Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

[Jeff V. Merkey]

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. There's a lot of kernel
> > development I'm sure folks want to do with Linux they cannot because
> > it too tough to debug. SMP problems I've run into on Linux with just
> > take too long without these types of tools. [...]
> 
> like a webserver?

In NetWare, the webserver does run in-kernel.  It's got the highest
numbers for any web server on the planet on Intel.  Visit
www.novell.com.  I don't plan to put the MANOS webserver in-kernel, BTW,
but I mention this in anwswer to your question.  Microsoft's web server
appears to run in user space, but in fact, does not, BTW  -- they have
half of it down in-kernel as well for performance.

Jeff

Jeff

> 
> Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for

[Alan Cox]

> 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 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 violations are a big win


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/