Re: MTBF data for linux

[J. Dow]

From: "Chris Wedgwood" <[EMAIL PROTECTED]>
To: "Alan Cox" <[EMAIL PROTECTED]>

> We ran 1.2.13lmp for about 1100 days before the box finally got
> turned off - twice around the uptime clock and more
> 
> That's must be some kind of unofficial record... I though 400+ days
> was pretty neat, but 1100 says is really impressive, especially on a
> kernel which has races with jiffie wraps...

Um, another "uptime benchmark" is the little machine (old 75MHz
Pentium) we use here as our internal net's gateway to the internet
via IP Masquerading. It is the machine on the net with the honorary
unimaginative name, linux. Little linux endeared himself to me by
reaching 450+ days uptime as a v.90 dialup and internal http server
before I rebooted him for some upgrades. We went DSL. I needed
to install a new NIC. I'm not adventuresome enough to hotplug a
PCI card. So at something like 450 days, 6 hours and somewhat
more than another half hour he was cleanly shutdown. I installed a
new disk as hdc, a new CDROM as hdd, a new NIC, and rebooted.
He came up clean first time. Then I partitioned and mounted the
new disk, transferred critical files, and rebooted again to install
RedHat 6.2 and once more to upgrade the kernel. He has a month
of uptime at this point. (I took him down one more time to remove
the tiny original disks he ran on and move the 2gig drive to hda
and the CDROM to hdc after he'd been up and clean about a week
and a half.)

It appears Linux stays up longer than you care to leave it up. I
admit this was with no load to speak of. But it was kinda fun to
hold a birthday party for him at one year. (Heh, I even moved him
across the room sitting on top of the UPS when I rearranged the
furniture on my side of the room. hey, I'm female. I get to do silly
things like that. {O,o})

Er, do the True64 machines have any practical uptime problem?
The one BIX runs on seems to accumulate some impressive
uptime under the load the tiny number of remaining members
place on the machine.

{^_^}

-
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] add PPP filtering

[Paul Mackerras]

Linus,

The patch below adds the ability to filter packets going through a PPP
interface.  This allows users to specify that certain types of packets
are not to count as activity, i.e. they don't reset the idle timer or
bring up a demand-dialled link.  This is something I have been getting
a lot of requests for.

It also allows users to specify that certain types of packets are to
be dropped - this isn't a substitute for the netfilter stuff of
course, but it comes virtually for free and it can sometimes be
useful.

(Users will need to use ppp-2.4.0 and compile pppd with the line in
pppd/Makefile.linux that says "FILTER=y" uncommented.)

I hope this can go into 2.4.  It is a relatively small and
self-contained set of changes.  The only change to things outside the
PPP generic module is a small change to make sure that sk_chk_filter
is exported from the socket filtering code.  There is also a small
change where I have removed an unnecessary #include from
ppp_channel.h.

The files affected are:

Documentation/Configure.help
drivers/net/ppp_generic.c
include/linux/filter.h
include/linux/if_ppp.h
include/linux/ppp_channel.h
net/netsyms.c

Regards,
Paul.

diff -urN linux/Documentation/Configure.help pmac/Documentation/Configure.help
--- linux/Documentation/Configure.help  Sat Sep  2 15:08:58 2000
+++ pmac/Documentation/Configure.help   Sat Sep  2 14:58:22 2000
@@ -1748,6 +1748,10 @@
   certain types of data to get through the socket. Linux Socket
   Filtering works on all socket types except TCP for now. See the text
   file Documentation/networking/filter.txt for more information.
+
+  You need to say Y here if you want to use PPP packet filtering
+  (see the CONFIG_PPP_FILTER option below).
+
   If unsure, say N.
 
 Network packet filtering
@@ -6719,6 +6723,17 @@
 
   This has to be supported at the other end as well and you need a
   version of the pppd daemon which understands the multilink protocol.
+
+  If unsure, say N.
+
+PPP filtering (EXPERIMENTAL)
+CONFIG_PPP_FILTER
+  Say Y here if you want to be able to filter the packets passing over
+  PPP interfaces.  This allows you to control which packets count as
+  activity (i.e. which packets will reset the idle timer or bring up
+  a demand-dialled link) and which packets are to be dropped entirely.
+  You need to say Y here if you wish to use the pass-filter and
+  active-filter options to pppd.
 
   If unsure, say N.
 
diff -urN linux/drivers/net/ppp_generic.c pmac/drivers/net/ppp_generic.c
--- linux/drivers/net/ppp_generic.c Fri Jul 14 14:41:43 2000
+++ pmac/drivers/net/ppp_generic.c  Sat Sep  2 15:14:02 2000
@@ -19,7 +19,7 @@
  * PPP driver, written by Michael Callahan and Al Longyear, and
  * subsequently hacked by Paul Mackerras.
  *
- * ==FILEVERSION 2417==
+ * ==FILEVERSION 2902==
  */
 
 #include 
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -121,6 +122,10 @@
struct sk_buff_head mrq;/* MP: receive reconstruction queue */
 #endif /* CONFIG_PPP_MULTILINK */
struct net_device_stats stats;  /* statistics */
+#ifdef CONFIG_PPP_FILTER
+   struct sock_fprog pass_filter;  /* filter for packets to pass */
+   struct sock_fprog active_filter;/* filter for pkts to reset idle */
+#endif /* CONFIG_PPP_FILTER */
 };
 
 /*
@@ -621,6 +626,43 @@
err = 0;
break;
 
+#ifdef CONFIG_PPP_FILTER
+   case PPPIOCSPASS:
+   case PPPIOCSACTIVE:
+   {
+   struct sock_fprog uprog, *filtp;
+   struct sock_filter *code = NULL;
+   int len;
+
+   if (copy_from_user(, (void *) arg, sizeof(uprog)))
+   break;
+   if (uprog.len > 0) {
+   err = -ENOMEM;
+   len = uprog.len * sizeof(struct sock_filter);
+   code = kmalloc(len, GFP_KERNEL);
+   if (code == 0)
+   break;
+   err = -EFAULT;
+   if (copy_from_user(code, uprog.filter, len))
+   break;
+   err = sk_chk_filter(code, uprog.len);
+   if (err) {
+   kfree(code);
+   break;
+   }
+   }
+   filtp = (cmd == PPPIOCSPASS)? >pass_filter: >active_filter;
+   ppp_lock(ppp);
+   if (filtp->filter)
+   kfree(filtp->filter);
+   filtp->filter = code;
+   filtp->len = uprog.len;
+   ppp_unlock(ppp);
+   err = 0;
+   break;
+   }
+#endif /* CONFIG_PPP_FILTER */
+
 #ifdef CONFIG_PPP_MULTILINK
case PPPIOCSMRRU:
if (get_user(val, (int *) arg))
@@ -892,6 +934,33 @@
int len;
unsigned char *cp;
 
+   if (proto < 0x8000) {
+#ifdef CONFIG_PPP_FILTER
+   

[PATCH] 2.2.18pre2: fencepost error in __ioremap() [AGP]

[Chip Salzenberg]

The AGP patches add some code to __ioremap.  That code seems to me to
have a fencepost error.

In the below hunk, note that temp_end is set to "temp_addr+(size-1)".
It points _at_ the last page to be examined, not beyond it.  So the
loop should be controlled by a "<=" test, not a "<" test.  Without
this patch, the last page in the range is not tested for reservation.

Index: arch/i386/mm/ioremap.c
--- arch/i386/mm/ioremap.c.prev
+++ arch/i386/mm/ioremap.c  Fri Sep  1 20:11:25 2000
@@ -118,5 +118,5 @@ void * __ioremap(unsigned long phys_addr
temp_end = temp_addr + (size - 1);
  
-   for(i = MAP_NR(temp_addr); i < MAP_NR(temp_end); i++) {
+   for(i = MAP_NR(temp_addr); i <= MAP_NR(temp_end); i++) {
if(!PageReserved(mem_map + i))
return NULL;

-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early."  // MST3K
-
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] 2.2.18pre2: AGP and the i810

[Chip Salzenberg]

First, thanks, Alan, for using the USB and AGP patches.  You just
saved me a bunch of integration work.

I'd like to suggest the below patches for the AGP i810 driver.


[1] I'm largely in the dark with AGP, but I know for a fact that with
my previous AGP driver -- which was, like the one you integrated,
based on 2.4 and PI's work -- I got kernel oopses about 10% of the
time when exiting X.  The oopses were fixed by the addition of
CACHE_FLUSH() calls in intel_i810_remove_entries(), in imitation of
the CACHE_FLUSH() calls already in intel_i810_insert_entries().

Index: drivers/char/agp/agpgart_be.c
--- drivers/char/agp/agpgart_be.c.prev
+++ drivers/char/agp/agpgart_be.c   Fri Sep  1 20:38:18 2000
@@ -951,4 +953,5 @@ static int intel_i810_remove_entries(agp
int i;
 
+   CACHE_FLUSH();
for (i = pg_start; i < (mem->page_count + pg_start); i++) {
OUTREG32(intel_i810_private.registers,
@@ -956,4 +959,5 @@ static int intel_i810_remove_entries(agp
 agp_bridge.scratch_page);
}
+   CACHE_FLUSH();
 
agp_bridge.tlb_flush(mem);



[2] When CONFIG_AGP_I810 is off, disable compilation of (more of the)
i810-specific code.

Index: drivers/char/agp/agpgart_be.c
--- drivers/char/agp/agpgart_be.c.prev
+++ drivers/char/agp/agpgart_be.c   Fri Sep  1 20:38:18 2000
@@ -791,4 +791,6 @@ void agp_enable(u32 mode)
 /* End - Generic Agp routines */
 
+#ifdef CONFIG_AGP_I810
+
 static aper_size_info_fixed intel_i810_sizes[] =
 {
@@ -1063,4 +1067,5 @@ static int __init intel_i810_setup(struc
 }
 
+#endif /* CONFIG_AGP_I810 */
 
 #ifdef CONFIG_AGP_INTEL
@@ -2198,5 +2203,5 @@ static int __init agp_find_supported_dev
 
/* Need to test for I810 here */
-
+#ifdef CONFIG_AGP_I810
if (dev->vendor == PCI_VENDOR_ID_INTEL) {
struct pci_dev *i810_dev;
@@ -2272,5 +2277,5 @@ static int __init agp_find_supported_dev
}
}
-
+#endif /* CONFIG_AGP_I810 */
 
/* find capndx */

-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early."  // MST3K
-
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/

2.2.18pre2: gcc 2.7 doesn't like __attr__((unused))

[Chip Salzenberg]

I'm not sure if __attribute__((unused)) has an equivalent in gcc 2.7,
but as it appears in the AGP driver, it doesn't work with gcc 2.7.
Below is the patch I used to get AGP to compile, but I don't recommend
it for adoption in the standard source tree.

Index: drivers/char/drm/ffb_drv.c
--- drivers/char/drm/ffb_drv.c.prev
+++ drivers/char/drm/ffb_drv.c  Fri Sep  1 21:21:08 2000
@@ -16,5 +16,5 @@
 #include 
 
-static __attribute__((unused)) void unused(void)
+static void unused(void)
 {
agp_enable(0);

Index: drivers/char/drm/gamma_drv.c
--- drivers/char/drm/gamma_drv.c.prev
+++ drivers/char/drm/gamma_drv.cFri Sep  1 21:21:03 2000
@@ -36,5 +36,5 @@
 #include 
 
-static __attribute__((unused)) void unused(void)
+static void unused(void)
 {
agp_enable(0);

Index: drivers/char/drm/i810_drv.c
--- drivers/char/drm/i810_drv.c.prev
+++ drivers/char/drm/i810_drv.c Fri Sep  1 21:20:58 2000
@@ -36,5 +36,5 @@
 #include 
 
-static __attribute__((unused)) void unused(void)
+static void unused(void)
 {
agp_enable(0);

Index: drivers/char/drm/mga_drv.c
--- drivers/char/drm/mga_drv.c.prev
+++ drivers/char/drm/mga_drv.c  Fri Sep  1 21:20:52 2000
@@ -37,5 +37,5 @@
 #include 
 
-static __attribute__((unused)) void unused(void)
+static void unused(void)
 {
agp_enable(0);

Index: drivers/char/drm/r128_drv.c
--- drivers/char/drm/r128_drv.c.prev
+++ drivers/char/drm/r128_drv.c Fri Sep  1 21:20:40 2000
@@ -36,5 +36,5 @@
 #include 
 
-static __attribute__((unused)) void unused(void)
+static void unused(void)
 {
agp_enable(0);

Index: drivers/char/drm/tdfx_drv.c
--- drivers/char/drm/tdfx_drv.c.prev
+++ drivers/char/drm/tdfx_drv.c Fri Sep  1 21:20:47 2000
@@ -37,5 +37,5 @@
 #include 
 
-static __attribute__((unused)) void unused(void)
+static void unused(void)
 {
agp_enable(0);

-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early."  // MST3K
-
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/

2.2.18pre2: slab.c missing return

[Chip Salzenberg]

The modification of slab.c in 2.2.18pre2 seems to be missing a "return"
in kmem_cache_shrink():

Index: mm/slab.c
--- mm/slab.c.prev
+++ mm/slab.c   Fri Sep  1 21:16:45 2000
@@ -1048,5 +1048,5 @@ found:
 int kmem_cache_shrink(kmem_cache_t *cachep)
 {
-   __kmem_cache_shrink(cachep,0);
+   return __kmem_cache_shrink(cachep,0);
 }
 

-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early."  // MST3K
-
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: thread group comments

[Linus Torvalds]

On Sat, 2 Sep 2000, Andi Kleen wrote:
> > tid = clone(CLONE_PID);
> 
> I'm not sure this will work very well (2.4.0test8-pre1):

Well, the above was written back when I hadn't done "CLONE_THREAD", so you
should really read CLONE_THREAD instead of CLONE_PID with the test8-pre1
semantics. 

Sorry for the confusion, I just cut-and-pasted from an older email

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: What the Heck? [Fwd: Returned mail: User unknown]

[Rick]

On Fri, Sep 01, 2000 at 11:40:06PM -0400, Chris Kloiber wrote:
> What is the deal here? I have NEVER seen anyboody flatly refuse email
> from me. Are you telling me I have to go into work and use my
> [EMAIL PROTECTED] email address to talk to Alan? That's asinine.

> > <<< 550-untestable - rr.com has multiple open relays and its admins have demanded 
>that ORBS not test further. Complaints to mherrick@va
> > <<< 550 rejected: administrative prohibition

I have had several sites reject mail from me because it's being sent
from a rr.com IP (notably sdesigns.com).  I had to use a shell acct
from another system to send it.  It's very annoying but I don't think
there's much to be done if they decide they don't want mail coming from
rr.com.

-- 
Rick ([EMAIL PROTECTED])
http://www.kuroyi.net

What the hell is content? Nobody buys content. Real people pay money
for music because it means something to them. A great song is not just
something to take up space on a Web site next to stock market quotes
and baseball scores.
-- Courtney Love
-
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: Press release - here we go again!

[Stephen Satchell]

At 04:15 PM 9/1/00 -0700, you wrote:
>And if got lost. That should tell you something. Perhaps something like
>"*Advanced interface support for USB, FireWire, and AGP!"
>
>Then place any expostulatory text indented under that as complete sentences.
>This treates the bulleted items as "titles". Your target audience dispises
>incomplete sentences and clunky grammar. (And do rest assured that folks
>like Jerry Pournelle have posted some REAL clunkers, worse than anything
>you did) on BIX for our chuckles.)

Interesting juxtaposition, Dow.  Your suggestion includes a bang 
(exclamation mark) and then you mention the most vicious bang-hater I've 
ever run into, Jerry Pournelle, in the next paragraph.  Whatever will you 
do next, Oh Emoticon Person?  :)

(This is a VERY serious thing -- one sign of an amateur press release is 
The! Excessive! Use! of! the! Ballbat! Character! -- I know columnists who 
stop reading and start scanning for exclamation marks when they encounter 
the first one.  Because all too many poof-piece writers place the bang in 
the headline, that means the entire release is ignored.  I remember when I 
was including some C code in an article I was writing for a magazine; the 
editor said to take out all of those bangs!  It took 10 minutes with a copy 
of K to show him that the exclamation marks were operators, not 
emphasis.  )

Satch

-
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: thread rant

[Lincoln Dale]

At 22:48 01/09/00, Michael Bacarella wrote:

>Q: Why do we need threads?
>A: Because on some operating systems, task switches are expensive.
>
>Q: So, threads are a hack to get around operating systems that suck?
>A: Basically.

urgh, i think you've missed the point.

while threads /may/ be abused by many applications where fork() or 
decent-event-queue/state-machine would probably produce much better 
performance (i believe some of the java libraries are a perfect example of 
this), there are _MANY_ applications where threads work, work well, and are 
superior to the alternatives available (fork with shm segments).

one such example is cpu compultationally-expensive work where some degree 
of working-set is required to be shared between processes.  one could use 
fork(), run multiple instances, have them register to a shm segment and 
then implement some form of IPC between them.
alternatively, you could create 'n' work threads where "n == NR_CPUs" with 
the working-set automatically available to all worker threads.  for 
whatever synchronization is required, you don't have to write your IPC 
mechanism - mutexes come standard with things like pthreads.  (of course, 
there is no excuse for bad programming or bad algorithms; mutex use should 
be kept to a minimum).  perhaps you then need this application to then do 
bulk disk-i/o?  one-thread-per-disk-spindle works nicely in this scenario too.

threads are useful and powerful.  perhaps the real problem with threads are 
that it is too easy to write bad code using them.
caveat emptor.


cheers,

lincoln.


--
   Lincoln Dale   Content Services Business Unit
   [EMAIL PROTECTED]  cisco Systems, Inc.   | |
||||
   +1 (408) 525-1274  bldg G, 170 West Tasman    
   +61 (3) 9659-4294 <<   San Jose CA 95134..:||:..:||:.. 

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

What the Heck? [Fwd: Returned mail: User unknown]

[Chris Kloiber]

What is the deal here? I have NEVER seen anyboody flatly refuse email
from me. Are you telling me I have to go into work and use my
[EMAIL PROTECTED] email address to talk to Alan? That's asinine.


Mail Delivery Subsystem wrote:
> 
> The original message was received at Fri, 1 Sep 2000 23:26:32 -0400
> from localhost.localdomain [127.0.0.1]
> 
>- The following addresses had permanent fatal errors -
> <[EMAIL PROTECTED]>
> 
>- Transcript of session follows -
> ... while talking to lightning.swansea.uk.linux.org.:
> >>> RCPT To:<[EMAIL PROTECTED]>
> <<< 550-untestable - rr.com has multiple open relays and its admins have demanded 
>that ORBS not test further. Complaints to mherrick@va
> <<< 550 rejected: administrative prohibition
> 550 <[EMAIL PROTECTED]>... User unknown
> 
>   
> Reporting-MTA: dns; ckloiber.homeip.net
> Received-From-MTA: DNS; localhost.localdomain
> Arrival-Date: Fri, 1 Sep 2000 23:26:32 -0400
> 
> Final-Recipient: RFC822; [EMAIL PROTECTED]
> Action: failed
> Status: 5.1.1
> Remote-MTA: DNS; lightning.swansea.uk.linux.org
> Diagnostic-Code: SMTP; 550-untestable - rr.com has multiple open relays and its 
>admins have demanded that ORBS not test further. Complaints to mherrick@va
> Last-Attempt-Date: Fri, 1 Sep 2000 23:26:58 -0400
> 
>   
> 
> Subject: Re: Linux 2.2.18pre2
> Date: Fri, 01 Sep 2000 23:26:32 -0400
> From: Chris Kloiber <[EMAIL PROTECTED]>
> To: Alan Cox <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
> 
> Alan Cox wrote:
> >
> > Since 2.2.17 isnt out yet I've released 2.2.18pre2 versus 2.2.17pre20. So
> 
> What's holding things up on 2.2.17? I thought you said it was ready and
> just waiting for Linus' penguin to take a trip to the john.
> 
> Chris Kloiber

begin:vcard 
n:Kloiber;Chris
x-mozilla-html:FALSE
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;0
fn:Chris Kloiber
end:vcard

Re: thread rant

[Mike A. Harris]

On Fri, 1 Sep 2000, Michael Bacarella wrote:

>Q: Why do we need threads?
>A: Because on some operating systems, task switches are expensive.
>
>Q: So, threads are a hack to get around operating systems that suck?
>A: Basically.

Am I understanding correctly then that using fork() is
faster/better?  Or should one use a state machine?  I'm just
asking out of curiosity because thread programming is new to me.

All portability issues aside, if one is writing an application in
Linux that one would be tempted to make multithreaded for
whatever reason, what would be the better Linux way of doing
things?

I've heard comments from Alan, and others in the past bashing
threads, and I can understand the "threads are for people who
can't write state machines" comments I've heard, but what other
ways are there of accomplishing the goals that threads solve in
an acceptable manner that gives good performance without coding
complexity?

This is all just curiosity.  I've considered trying some thread
programming, but if it is as stupid as it sounds, I'd rather
learn the "right" way of writing code that would ordinarily be
done with threads, etc..  Right now, I'm using fork() all over
the place and don't much care how much waste it is...  I'd like
to though.

>Q: So, why must Linux support threads?
>A1:  : |
>A2: So other programs can be easily ported to Linux!
>
>That can already happen. It's not the *best* implementation. It's
>not as fast as it can be. But it works. And that's all it should do. If
>you're not happy, cope.
>
>   "But threads on this system are faster than on Linux!"
>
>The fact that the system implements threads speaks enough about
>it's capabilities. ie, it's trying hard to suck less. So, from my POV,
>we're looking to make Linux suck more by effectively emulating systems
>that are trying to suck less.

Makes sense... if you understand the details of why threads
suck.  I understand there are some cache coherency issues, and
I've heard of other things as well, but is there an FAQ out there
saying "Why to not use threads?" that goes into good detail and
provides alternatives?


>But, I've never done anything worthwhile for Linux, so take this for what
>it's worth, from an asshole.

Works for me.  ;o)


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

Be up to date on nerd news and stuff that matters:  http://slashdot.org

-
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: thread rant

[dean gaudet]

On Fri, 1 Sep 2000, Michael Bacarella wrote:

> Q: Why do we need threads?
> A: Because on some operating systems, task switches are expensive.

maybe this problem will help you understand threads better:

design a webserver which supports SSL session keys.  consider the
performance of your webserver on single CPU and multiple CPU boxes.
consider also the performance of your webserver on datasets which do
not fit within RAM, hence requiring disk i/o.  and finally, consider
the effect of having one disk spindle versus multiple disk spindles.

in this problem, the "SSL session key" requirement is there so that state
information for previous connections has to be available to efficiently
process future connections.  (the ssl session key reduces the number of
times the RSA key signature needs to be performed.)

the SMP requirement is to indicate why single process select loop won't
always cut it.  (especially if you're doing SSL you'd like to grind crypto
on all CPUs).

the disk i/o, multiple spindle requirement is there so you consider what
it takes to get a disk array with 50 disks in it going full-tilt.  
(nevermind stuffing the elevator on a single disk -- i'm just trying to
make it really obvious how much parallelism may be available in a system.)

yup you can do this without threads.  apache-1.3+mod_ssl for example.

but it's not fun, and it's a lot more work on the portability side.  
inter-process shared memory and inter-process semaphores are notoriously
different across platforms... just look at the "mm" library from mod_ssl
(which is a less puke-filled version of what's in
apache-1.3/src/main/http_main.c).

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

thread rant

[Michael Bacarella]

Q: Why do we need threads?
A: Because on some operating systems, task switches are expensive.

Q: So, threads are a hack to get around operating systems that suck?
A: Basically.

Q: So, why must Linux support threads?
A1:  : |
A2: So other programs can be easily ported to Linux!

That can already happen. It's not the *best* implementation. It's
not as fast as it can be. But it works. And that's all it should do. If
you're not happy, cope.

"But threads on this system are faster than on Linux!"

The fact that the system implements threads speaks enough about
it's capabilities. ie, it's trying hard to suck less. So, from my POV,
we're looking to make Linux suck more by effectively emulating systems
that are trying to suck less.

But, I've never done anything worthwhile for Linux, so take this for what
it's worth, from an asshole.

-MB

-
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 2.2.18pre2

[Chip Salzenberg]

According to David S. Miller:
>o  Acenic 0.45 fixes   (Chip Salzenberg)
> 
> This adds a huge comment claiming to fix some race condition,
> but no actual code is changed.  How can this be? :-)

The bug fix was already in.  The log message is misleading.
-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early."  // MST3K
-
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/

2.4.0 do_fork() change, all architectures - take 2

[Keith Owens]

DaveM pointed out that my 2.4.0-test8-pre1 do_fork patch would generate
better sparc assembler if the extra parameter to do_fork was added at
the end instead of in the middle.  So change all do_fork(flags,sp,0,)
to do_fork(flags,sp,,0);

I'm not going to mail the complete patch again, you can get it from
ftp://ftp.ocs.com.au/pub/do_fork-2.4.0-test8-take2.gz.  The only
significant difference is this bit to IA64, untested.

Index: 0-test8-pre1.1/arch/ia64/kernel/entry.S
--- 0-test8-pre1.1/arch/ia64/kernel/entry.S Tue, 15 Aug 2000 17:50:48 +1000 kaos 
(linux-2.4/c/c/16_entry.S 1.3.1.1.1.2 644)
+++ 0-test8-pre1.2(w)/arch/ia64/kernel/entry.S Sat, 02 Sep 2000 12:49:16 +1100 kaos 
+(linux-2.4/c/c/16_entry.S 1.3.1.1.1.2 644)
@@ -68,8 +68,8 @@
mov loc1=r16// save ar.pfs across do_fork
UNW(.body)
mov out1=in1
-   mov out2=in2
-   adds out3=IA64_SWITCH_STACK_SIZE+16,sp  // out3 = 
+   mov out3=in2
+   adds out2=IA64_SWITCH_STACK_SIZE+16,sp  // out2 = 
mov out0=in0// out0 = clone_flags
br.call.sptk.few rp=do_fork
 .ret1: UNW(.restore sp)
@@ -87,8 +87,8 @@
mov loc1=r16// save ar.pfs across do_fork
UNW(.body)
mov out1=in1
-   mov out2=0
-   adds out3=IA64_SWITCH_STACK_SIZE+16,sp  // out3 = 
+   mov out3=0
+   adds out2=IA64_SWITCH_STACK_SIZE+16,sp  // out2 = 
mov out0=in0// out0 = clone_flags
br.call.sptk.few rp=do_fork
 .ret2: UNW(.restore sp)
Index: 0-test8-pre1.1/arch/ia64/ia32/ia32_entry.S
--- 0-test8-pre1.1/arch/ia64/ia32/ia32_entry.S Tue, 15 Aug 2000 17:50:48 +1000 kaos 
(linux-2.4/c/c/25_ia32_entry 1.3.1.1 644)
+++ 0-test8-pre1.2(w)/arch/ia64/ia32/ia32_entry.S Sat, 02 Sep 2000 12:49:58 +1100 kaos 
+(linux-2.4/c/c/25_ia32_entry 1.3.1.1 644)
@@ -91,8 +91,8 @@
UNW(.body)
 
mov out1=0
-   mov out2=0
-   adds out3=IA64_SWITCH_STACK_SIZE+16,sp
+   mov out3=0
+   adds out2=IA64_SWITCH_STACK_SIZE+16,sp  // out2 = 
br.call.sptk.few rp=do_fork
 .ret3: mov ar.pfs=loc1
UNW(.restore sp)

-
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 17:12:03 +0100 (BST) 
Alan Cox <[EMAIL PROTECTED]> wrote:

>> Now the device behaves just like memory to the BIOS during POST
>> etc, and is in fact, exactly memory if no device drivers are
>> loaded.  If a device driver is loaded and it detects one or more
>> of these devices then they and their memory ranges become
>> obviously special.  Now, we can detect the devices and where
>> their address ranges are via the SMBUS and some careful probing
>> so we know what we are trying to grab.  The problem is just
>> telling the rest of the kernel that in a clean VM
>> manner.

> Basically your base driver will have to do it at boot up
> time. Once that memory is allocated to someone you may not be able
> to move the memory and borrow the pages.

Aye, that's what we're doing ATM.  We find the board and its size,
and then go and edit mem_map and mark it reserved and uncacheable.
It doesn't seem the most graceful approach and I was hoping for
something cleaner (tho that looks like 2.4 per Ingo's comments which
I still have to look into).

> You don't neccessarily need the whole driver in the main kernel
> but you will need to grab the devices, reserve the memory pages in
> question and mark them as reserved before Linux gets going
> properly. Your actual users of these pages can then be dynamically
> loaded.

Yeah, that's what I'm looking at right now: how early I have to get
in to be safe.

-- 
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: hfs support for blocksize != 512

[Roman Zippel]

Hi,

On Thu, 31 Aug 2000, Alexander Viro wrote:

> Go ahead, write it. IMNSHO it's going to be much more complicated and
> race-prone, but code talks. If you will manage to write it in clear and
> race-free way - fine. Frankly, I don't believe that it's doable.

It will be insofar more complicated, as I want to use a more complex state
machine than "locked <-> unlocked", on the other hand I can avoid such
funny constructions as triple_down() and obscure locking order rules.

At any time the object will be either locked or in a well defined state,
where at any time only a single object is locked by a thread. (I hope some
pseudo code does for the beginning, too?) Most namespace operation work
simply like a semaphore:

restart:
lock(dentry);
if (dentry is busy) {
unlock(dentry);
sleep();
goto restart;
}
dentry->state = busy;
unlock(dentry);

If the operation is finished, the state is reset and everyone sleeping is
woken up. Ok, let's come to the most interesting operation - rename():

restart:
lock(olddentry);
if (olddentry is busy) {
unlock(olddentry);
sleep();
goto restart;
}
olddentry->state = moving;
unlock(olddentry);

restart2:
lock(newdentry);
if (newdentry->state == moving) {
lock(renamelock);
if (olddentry->state == deleted) {
unlock(renamelock);
unlock(newdentry);
sleep();
goto restart;
}
newdentry->state = deleted;
unlock(renamelock);
} else if (newdentry is busy) {
unlock(newdentry);
sleep();
goto restart2;
} else
newdentry->state = deleted;
unlock(newdentry);

if (!rename_valid(olddentry, newdentry)) {
lock(newdentry);
newdentry->state = idle;
unlock(renamelock);
lock(olddentry);
olddentry->state = idle;
unlock(olddentry);
wakeup_sleepers();
return;
}

if (newdentry exists)
unlink(newdentry);
do_rename(olddentry, newdentry);

lock(newdentry);
newdentry->state = idle;
unlock(renamelock);
lock(olddentry);
olddentry->state = deleted;
unlock(olddentry);
wakeup_sleepers();
return;

Note that I don't touch any inode here, everything happens in the dcache.
That means I move the complete inode locking into the fs, all I do here is
to make sure, that while operation("foo") is busy, no other operation will
use "foo".
IMO this should work, I tried it with a rename("foo", "bar") and 
rename("bar", "foo"):
case 1: one rename gets both dentries busy, the other rename will wait
till it's finished.
case 2: both mark the old dentry as moving and find the new dentry also
moving. To make the rename atomic the global rename lock is needed, one
rename will find the old dentry isn't moving anymore and has to restart
and wait, the other rename will complete.

Other operations will keep only one dentry busy, so that I don't a see
problem here. If you don't find any major problem here, I'm going to try
this. Since if this works, it will have some other advantages:
- a user space fs will become possible, that can't even deadlock the
system. The first restart loop can be easily made interruptable, so it can
be safely killed. (I don't really want to know how a 
triple_down_interruptable() looks, not to mention the other three locks
(+ BKL) taken during a rename.)
- I can imagine better support for hfs. It can access the other fork
without excessive locking (I think currently it doesn't even tries to).
The order in which the forks can be created can change then too.

> BTW, I really wonder what kind of locks are you going to have on _blocks_
> (you've mentioned that, unless I've misparsed what you've said). IMO that
> way lies the horror, but hey, code talks.

I thought about catching a bread, but while thinking about it, there
should also be other ways. But that's fs specific, let's concentrate on
the generic part first.

> You claim that it's doable. I seriously doubt it. Nobody knows your ideas
> better than you do, so... come on, demonstrate the patch.

I think the above example should do basically the same as some nothing
doing patch within affs.
I hope that example shows two important ideas (no idea if they will save
the world, but I'm willing to learn):
- I use the dcache instead of the inode to synchronize namespace
operation, what IMO makes quite a lot of sense, since it represents our
(cached) representation of the fs.
- Using states instead of a semaphore, makes it easily possible to detect
e.g. a rename loop.

bye, Roman



-
To 

[PressRel] v0.1.1 - the "errata" release

[Daniel Stone]

All,
Fixed up a few suggested "buglets" in the release, notably inconsistencies
in the grammar, etc. I won't bother you with big posts, so it's at
http://dustpuppy.ods.org/press-release - just grab it from there.
Still to do is to rewrite half the stuff, and to merge the longer details
into WWoL2.4 or similar, so the press release is designed for brevity.

d

--
Daniel Stone
Kernel Hacker (or at least has aspirations to be)
[EMAIL PROTECTED]
http://dustpuppy.ods.org

-
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] lne390.c: get rid of check_region

[Arnaldo Carvalho de Melo]

Hi,

Please consider applying.

- Arnaldo

--- linux-2.4.0-test8-pre1/drivers/net/lne390.c Mon Jun 19 17:30:58 2000
+++ linux-2.4.0-test8-pre1.acme/drivers/net/lne390.cFri Sep  1 15:36:19 2000
@@ -26,10 +26,13 @@
You can try  if you want more info, as I've
never even seen one of these cards.  :)
 
+   Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> - 2000/09/01
+   - get rid of check_region
+   - no need to check if dev == NULL in lne390_probe1
 */
 
 static const char *version =
-   "lne390.c: Driver revision v0.99, 12/05/98\n";
+   "lne390.c: Driver revision v0.99.1, 01/09/2000\n";
 
 #include 
 #include 
@@ -104,8 +107,11 @@
 {
unsigned short ioaddr = dev->base_addr;
 
-   if (ioaddr > 0x1ff) /* Check a single specified location. */
+   if (ioaddr > 0x1ff) {   /* Check a single specified location. */
+   if (!request_region(ioaddr, LNE390_IO_EXTENT, "lne390"))
+   return -EBUSY;
return lne390_probe1(dev, ioaddr);
+   }
else if (ioaddr > 0)/* Don't probe at all. */
return -ENXIO;
 
@@ -118,10 +124,11 @@
 
/* EISA spec allows for up to 16 slots, but 8 is typical. */
for (ioaddr = 0x1000; ioaddr < 0x9000; ioaddr += 0x1000) {
-   if (check_region(ioaddr , LNE390_IO_EXTENT))
+   if (!request_region(ioaddr, LNE390_IO_EXTENT, "lne390"))
continue;
if (lne390_probe1(dev, ioaddr) == 0)
return 0;
+   release_region(ioaddr, LNE390_IO_EXTENT);
}
 
return -ENODEV;
@@ -129,7 +136,7 @@
 
 int __init lne390_probe1(struct net_device *dev, int ioaddr)
 {
-   int i, revision;
+   int i, revision, ret;
unsigned long eisa_id;
 
if (inb_p(ioaddr + LNE390_ID_PORT) == 0xff) return -ENODEV;
@@ -161,13 +168,6 @@
return -ENODEV;
}
 #endif
-
-   /* We should have a "dev" from Space.c or the static module table. */
-   if (dev == NULL) {
-   printk("lne390.c: Passed a NULL device.\n");
-   dev = init_etherdev(0, 0);
-   }
-
/* Allocate dev->priv and fill in 8390 specific dev fields. */
if (ethdev_init(dev)) {
printk ("lne390.c: unable to allocate memory for dev->priv!\n");
@@ -225,20 +225,16 @@
printk(KERN_CRIT "lne390.c: Use EISA SCU to set card memory 
below 1MB,\n");
printk(KERN_CRIT "lne390.c: or to an address above 0x%lx.\n", 
virt_to_bus(high_memory));
printk(KERN_CRIT "lne390.c: Driver NOT installed.\n");
-   free_irq(dev->irq, dev);
-   kfree(dev->priv);
-   dev->priv = NULL;
-   return -EINVAL;
+   ret = -EINVAL;
+   goto cleanup;
}
dev->mem_start = (unsigned long)ioremap(dev->mem_start, 
LNE390_STOP_PG*0x100);
if (dev->mem_start == 0) {
printk(KERN_ERR "lne390.c: Unable to remap card memory above 
1MB !!\n");
printk(KERN_ERR "lne390.c: Try using EISA SCU to set memory 
below 1MB.\n");
printk(KERN_ERR "lne390.c: Driver NOT installed.\n");
-   free_irq(dev->irq, dev);
-   kfree(dev->priv);
-   dev->priv = NULL;
-   return -EAGAIN;
+   ret = -EAGAIN;
+   goto cleanup;
}
ei_status.reg0 = 1; /* Use as remap flag */
printk("lne390.c: remapped %dkB card memory to virtual address %#lx\n",
@@ -251,7 +247,6 @@
 
/* The 8390 offset is zero for the LNE390 */
dev->base_addr = ioaddr;
-   request_region(dev->base_addr, LNE390_IO_EXTENT, "lne390");
 
ei_status.name = "LNE390";
ei_status.tx_start_page = LNE390_START_PG;
@@ -271,6 +266,11 @@
dev->stop = _close;
NS8390_init(dev, 0);
return 0;
+cleanup:
+   free_irq(dev->irq, dev);
+   kfree(dev->priv);
+   dev->priv = NULL;
+   return ret;
 }
 
 /*
-
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: thread group comments

[Ulrich Drepper]

"Andi Kleen" <[EMAIL PROTECTED]> writes:

> So you have a different way to implement pthread_create without context
> switch to the thread manager in 2.4 ? 

It should be possible to do these things with CLONE_PARENT.  It's a
long weekend coming up, let's see what I have next week.

-- 
---.  ,-.   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: thread group comments

[Ulrich Drepper]

"Andi Kleen" <[EMAIL PROTECTED]> writes:

> But I guess you don't want the context switch to a thread manager just to
> generate a thread ? (and which is one of the main causes of the bad thread 
> creation latency in Linux currently)

The thread manager, is I see it in the moment, will consist more or
less of this:

extern volatile int nthreads;
do
  waitpid (0, , __WCLONE)
while (nthreads > 0);
exit (WEXITSTATUS (res));

No signal handler, since it cannot receive signals.  Everything else
the threads will do themselves.

There is a problem though: the code we currently use for something
like restarting depends on the manager doing this.  This can be
implemented in two ways:

- send the manager a signal; this would require the threadkill() syscall
  already mentioned.  Note that we can assume RT signals and therefore
  can transport data.  But we get into problems if too many RT signals
  are queued.

- extend the loop above to something similar to what we have today:

do
  n = poll (..,..,.., timeout);
  check_for_dead_threads();  // use WNOHANG
  if (n > 0)
read request and process it
while (nthreads > 0)

  I really would like to avoid this.  It has the problems we are
  seeing today:

  * high latency of these requests
  * must adjust the priority of the manager (this now gets complicated
since it's not the manager which start the threads)
  * problems with changing UID/GID

It will require some investigation to see whether we can implement the
restart semantics correctly without a manager thread.  If yes, we
should be able to live with the simple loop.

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

2.4.0 do_fork() change, all architectures

[Keith Owens]

This patch hits every arch so it is being cross mailed to every arch
mailing list, apologies for duplicates.  Please trim replies to the
relevant mailing list.  Also please cc: [EMAIL PROTECTED] on replies, I
am not on every list.

IA64 needs an extra parameter on do_fork() and copy_thread(), those
functions are globally defined but arch local so there are changes to
every architecture.  For everything except IA64, the extra parameter is
unused and is specified as 0.  Sparc assembler changes by DaveM, blame
me for everything else.  If nobody complains, this patch against
2.4.0-test8-pre1 will go to Linus on Monday evening GMT.

Index: 0-test8-pre1.1/kernel/fork.c
--- 0-test8-pre1.1/kernel/fork.c Tue, 29 Aug 2000 15:22:12 +1100 kaos 
(linux-2.4/j/35_fork.c 1.1.1.9.1.6 644)
+++ 0-test8-pre1.1(w)/kernel/fork.c Sat, 02 Sep 2000 11:34:02 +1100 kaos 
+(linux-2.4/j/35_fork.c 1.1.1.9.1.6 644)
@@ -528,10 +528,15 @@
 
 /*
  *  Ok, this is the main fork-routine. It copies the system process
- * information (task[nr]) and sets up the necessary registers. It
- * also copies the data segment in its entirety.
+ * information (task[nr]) and sets up the necessary registers. It also
+ * copies the data segment in its entirety.  The "stack_start" and
+ * "stack_top" arguments are simply passed along to the platform
+ * specific copy_thread() routine.  Most platforms ignore stack_top.
+ * For an example that's using stack_top, see
+ * arch/ia64/kernel/process.c.
  */
-int do_fork(unsigned long clone_flags, unsigned long usp, struct pt_regs *regs)
+int do_fork(unsigned long clone_flags, unsigned long stack_start, unsigned long 
+stack_top,
+   struct pt_regs *regs)
 {
int retval = -ENOMEM;
struct task_struct *p;
@@ -628,7 +633,7 @@
goto bad_fork_cleanup_fs;
if (copy_mm(clone_flags, p))
goto bad_fork_cleanup_sighand;
-   retval = copy_thread(0, clone_flags, usp, p, regs);
+   retval = copy_thread(0, clone_flags, stack_start, stack_top, p, regs);
if (retval)
goto bad_fork_cleanup_sighand;
p->semundo = NULL;
Index: 0-test8-pre1.1/include/linux/sched.h
--- 0-test8-pre1.1/include/linux/sched.h Tue, 29 Aug 2000 15:22:12 +1100 kaos 
(linux-2.4/Z/49_sched.h 1.1.1.7.1.3 644)
+++ 0-test8-pre1.1(w)/include/linux/sched.h Sat, 02 Sep 2000 11:45:41 +1100 kaos 
+(linux-2.4/Z/49_sched.h 1.1.1.7.1.3 644)
@@ -708,7 +708,7 @@
 extern int expand_fdset(struct files_struct *, int nr);
 extern void free_fdset(fd_set *, int);
 
-extern int  copy_thread(int, unsigned long, unsigned long, struct task_struct *, 
struct pt_regs *);
+extern int  copy_thread(int, unsigned long, unsigned long, unsigned long, struct 
+task_struct *, struct pt_regs *);
 extern void flush_thread(void);
 extern void exit_thread(void);
 
@@ -719,7 +719,7 @@
 extern void daemonize(void);
 
 extern int do_execve(char *, char **, char **, struct pt_regs *);
-extern int do_fork(unsigned long, unsigned long, struct pt_regs *);
+extern int do_fork(unsigned long, unsigned long, unsigned long, struct pt_regs *);
 
 extern void FASTCALL(add_wait_queue(wait_queue_head_t *q, wait_queue_t * wait));
 extern void FASTCALL(add_wait_queue_exclusive(wait_queue_head_t *q, wait_queue_t * 
wait));
Index: 0-test8-pre1.1/arch/s390/kernel/smp.c
--- 0-test8-pre1.1/arch/s390/kernel/smp.c Tue, 11 Jul 2000 11:25:12 +1000 kaos 
(linux-2.4/Y/b/24_smp.c 1.2 644)
+++ 0-test8-pre1.1(w)/arch/s390/kernel/smp.c Sat, 02 Sep 2000 11:30:29 +1100 kaos 
+(linux-2.4/Y/b/24_smp.c 1.2 644)
@@ -528,7 +528,7 @@
/* don't care about the psw and regs settings since we'll never
   reschedule the forked task. */
memset(,sizeof(pt_regs),0);
-   return do_fork(CLONE_VM|CLONE_PID, 0, );
+   return do_fork(CLONE_VM|CLONE_PID, 0, 0, );
 }
 
 static void __init do_boot_cpu(int cpu)
Index: 0-test8-pre1.1/arch/s390/kernel/process.c
--- 0-test8-pre1.1/arch/s390/kernel/process.c Sat, 05 Aug 2000 13:33:35 +1000 kaos 
(linux-2.4/Y/b/35_process.c 1.2.1.1 644)
+++ 0-test8-pre1.1(w)/arch/s390/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos 
+(linux-2.4/Y/b/35_process.c 1.2.1.1 644)
@@ -264,6 +264,7 @@
 }
 
 int copy_thread(int nr, unsigned long clone_flags, unsigned long new_stackp,
+   unsigned long unused,
 struct task_struct * p, struct pt_regs * regs)
 {
 struct stack_frame
@@ -313,7 +314,7 @@
 int ret;
 
 lock_kernel();
-ret = do_fork(SIGCHLD, regs.gprs[15], );
+ret = do_fork(SIGCHLD, regs.gprs[15], 0, );
 unlock_kernel();
 return ret;
 }
@@ -329,7 +330,7 @@
 newsp = regs.gprs[2];
 if (!newsp)
 newsp = regs.gprs[15];
-ret = do_fork(clone_flags, newsp, );
+ret = do_fork(clone_flags, newsp, 0, );
 unlock_kernel();
 return ret;
 }
@@ -347,7 +348,7 @@
 asmlinkage int sys_vfork(struct pt_regs regs)
 {
return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD,
-  

Linux 2.2 - BSD/OS 4.1 ARP incompatibility

[David Luyer]

I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one 
of our backbones.

We have a number of Linux hosts on this backbone with a primary address in
the network a.b.c.0/24 and a secondary address in the network d.e.f.0/24.

We also have some BSD/OS 4.1 machines in this network with addresses in
d.e.f.0/24 only.

Now when the Linux box a.b.c.1 (with secondary address d.e.f.1) wants to
talk to the BSD/OS system d.e.f.2 it does

a.b.c.1 arp who-has d.e.f.2

Which d.e.f.2 promptly ignores, presumably because the IP stack in BSD/OS
throws it away at a low level, or possibly simply because BSD/OS has no
idea where to send the ARP response.

The end result is that a.b.c.1 can't talk to d.e.f.2 because it does an ARP
from the wrong IP address and doesn't get a response.

Is this already fixed in 2.4 or it is something which needs investigation
and a patch?

According to the standards, who is in the wrong?  To me it looks like Linux
is the misbehaved OS in this case.

David.
-- 
--
David Luyer
Senior Network Engineer
Pacific Internet (Aust) Pty Ltd
Phone:  +61 3 9674 7525
Fax:+61 3 9699 8693
Mobile: +61 4 1064 2258, +61 4 1114 2258
http://www.pacific.net.auNASDAQ: PCNTF
<< fast 'n easy >>
--


-
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 2.2.18pre2

[David S. Miller]

   Date:Fri, 1 Sep 2000 19:01:18 +0100 (BST)
   From: Alan Cox <[EMAIL PROTECTED]>

   oAcenic 0.45 fixes   (Chip Salzenberg)

This adds a huge comment claiming to fix some race condition,
but no actual code is changed.  How can this be? :-)

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: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 06:15:52PM -0700, Linus Torvalds wrote:
> 
> if (!has_done_this_before) {
> pid_t tid;
> has_done_this_before = 1;
> tid = clone(CLONE_PID);

I'm not sure this will work very well (2.4.0test8-pre1):

int do_fork(unsigned long clone_flags, unsigned long usp, struct pt_regs *regs)
{
int retval = -ENOMEM;
struct task_struct *p;
DECLARE_MUTEX_LOCKED(sem);

if (clone_flags & CLONE_PID) {
/* This is only allowed from the boot up thread */
if (current->pid)
return -EPERM;
}


So it would require fixing CLONE_PID first, which is probably nasty.

Without it it'll still require the context switches when you're calling
pthread_create from the "original" thread.


-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: thread group comments

[Ulrich Drepper]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> Well, I would just swap it _before_ the clone() - basically in the
> original parent when you create the new stack, you call clone() with the
> new stack and with the old stack as the argument. No?

Yes.  I have it basically working.  You have of course to swap before
the clone since the new thread will use the stack.

-- 
---.  ,-.   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: thread group comments

[Linus Torvalds]

On Sat, 2 Sep 2000, Andi Kleen wrote:
> 
> But I guess you don't want the context switch to a thread manager just to
> generate a thread ? (and which is one of the main causes of the bad thread 
> creation latency in Linux currently)

No, you don't need that. Here it is again:

int pthread_create()
{
static int has_done_this_before = 0;
pid_t newtid;

if (!has_done_this_before) {
pid_t tid;
has_done_this_before = 1;
tid = clone(CLONE_PID);
if (tid > 0) {
/*
 *  original thread becomes hidden master
 * thread, and never returns
 */
i_am_the_master_thread();
exit(0);
}
/*
 * initial CLONE_PID thread comes here,
 * it is now one of the "regular children".
 */
}
newtid = clone(CLONE_PID | CLONE_PARENT);
.. now we have the two "pthread" threads here ..
}

and as Uli points out the only thing you need to do is to switch the
stacks around when you do the nasty "switch threads from under the users
feet" thing.

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: thread group comments

[Linus Torvalds]

On 1 Sep 2000, Ulrich Drepper wrote:
> 
> I see no big problems with this either.  The only tricky thing is to
> get the stack swapped after the first clone() but this is solvable.

Well, I would just swap it _before_ the clone() - basically in the
original parent when you create the new stack, you call clone() with the
new stack and with the old stack as the argument. No?

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: thread group comments

[Linus Torvalds]

On Sat, 2 Sep 2000, Andi Kleen wrote:
> 
> The first goal would be to get it out of the critical path of pthread_create.

It should already be out of there. See the proposal I had earlier in this
thread, about the _first_ time only, when you have pthread_create(), you
do two clone() calls - and subsequently you just use CLONE_PARENT etc.

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: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 06:11:05PM -0700, Ulrich Drepper wrote:
> "Andi Kleen" <[EMAIL PROTECTED]> writes:
> 
> > Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ? 
> 
> I'm not sure whether it's worth the effort.  But I'm saying this now
> looking at the code for another implementation following the 1:1 model.

So you have a different way to implement pthread_create without context
switch to the thread manager in 2.4 ? 



-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: thread group comments

[Ulrich Drepper]

"Andi Kleen" <[EMAIL PROTECTED]> writes:

> Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ? 

I'm not sure whether it's worth the effort.  But I'm saying this now
looking at the code for another implementation following the 1:1 model.

In a second stage where we have m kernel threads and n user-level
threads (the ultimate goal) things might be different.  But this is
beyond what is needed in the 2.4 kernel so lets just skip the
SA_NOCLDWAIT stuff for now.

-- 
---.  ,-.   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: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 06:00:58PM -0700, Linus Torvalds wrote:
> 
> 
> On 1 Sep 2000, Ulrich Drepper wrote:
> 
> > "Andi Kleen" <[EMAIL PROTECTED]> writes:
> > 
> > > I've been thinking about how to best get rid of the thread manager for
> > > thread creation in LinuxThreads.  It is currently needed to do the wait.
> > 
> > If you get rid of the manager thread (the +1 thread) then you have
> > another problem: you cannot send a signal explicitly to this thread
> > (to implement pthread_kill).  The PID of this initial thread is now
> > used as the PID of the thread group.
> 
> Well, that can be solved by having a separate "threadkill()" system call. 
> 
> But I'd much rather just have the "n+1" thing. The overhead is basically
> nonexistent, and it simplifies so many things.

But I guess you don't want the context switch to a thread manager just to
generate a thread ? (and which is one of the main causes of the bad thread 
creation latency in Linux currently)

-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: thread group comments

[Ulrich Drepper]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> But I'd much rather just have the "n+1" thing. The overhead is basically
> nonexistent, and it simplifies so many things.

I see no big problems with this either.  The only tricky thing is to
get the stack swapped after the first clone() but this is solvable.

-- 
---.  ,-.   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: thread group comments

[Ulrich Drepper]

"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:

> True, but this can be handled by having the master thread process catch
> SIGSEGV and redistributing the signal to all of its child-threads.

No, it cannot.  We have to have a core dump with all threads.

> (The assumption I'm making here is that the master thread doesn't do
> anything except spawn all threads for the process and monitors its child
> processes for death.  This is the n+1 model.)

The master thread will not anymore spawn the threads.  That's the
whole purpose of this exercise.


-- 
---.  ,-.   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: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 05:50:04PM -0700, Ulrich Drepper wrote:
> "Andi Kleen" <[EMAIL PROTECTED]> writes:
> 
> > I've been thinking about how to best get rid of the thread manager for
> > thread creation in LinuxThreads.  It is currently needed to do the wait.
> 
> If you get rid of the manager thread (the +1 thread) then you have
> another problem: you cannot send a signal explicitly to this thread
> (to implement pthread_kill).  The PID of this initial thread is now
> used as the PID of the thread group.

The first goal would be to get it out of the critical path of pthread_create.

I think Linus proposed to add a settid() system call later to generate 
a new thread id, when that one is there then you could use that tid and
remove it completely.

Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ? 



-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: thread group comments

[Linus Torvalds]

On 1 Sep 2000, Ulrich Drepper wrote:

> "Andi Kleen" <[EMAIL PROTECTED]> writes:
> 
> > I've been thinking about how to best get rid of the thread manager for
> > thread creation in LinuxThreads.  It is currently needed to do the wait.
> 
> If you get rid of the manager thread (the +1 thread) then you have
> another problem: you cannot send a signal explicitly to this thread
> (to implement pthread_kill).  The PID of this initial thread is now
> used as the PID of the thread group.

Well, that can be solved by having a separate "threadkill()" system call. 

But I'd much rather just have the "n+1" thing. The overhead is basically
nonexistent, and it simplifies so many things.

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: thread group comments

[Ulrich Drepper]

"Andi Kleen" <[EMAIL PROTECTED]> writes:

> I've been thinking about how to best get rid of the thread manager for
> thread creation in LinuxThreads.  It is currently needed to do the wait.

If you get rid of the manager thread (the +1 thread) then you have
another problem: you cannot send a signal explicitly to this thread
(to implement pthread_kill).  The PID of this initial thread is now
used as the PID of the thread group.

-- 
---.  ,-.   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: thread group comments

[Theodore Y. Ts'o]

   From: Ulrich Drepper <[EMAIL PROTECTED]>
   Date:01 Sep 2000 14:52:28 -0700

   1st Problem:   One signal handler process process-wide

   What is handled correctly now is sending signals to the group.  Also
   that every thread has its mask.  But there must be exactly one signal
   handler installed.  I.e., a sigaction() call to set a new handler has
   consequences process-wide.  Since this muse be atomic I think the
   information should be kept in the thread group leader's data
   structures and the other threads should simply use this information
   all the time.  Yeah, I know, one more indirection.

Unfortunately, I think you're right.  This will mean an extra
indirection and locking, but signals aren't performance critical.

   2nd Problem: Fatal signal handling

   kernel/signal.c contains:

* Send a thread-group-wide signal.
*
* Rule: SIGSTOP and SIGKILL get delivered to _everybody_.

   That's OK.  Except that is a signal whose default action is to
   terminate the process is not caught be the application, this signal is
   also handled process-wide.  E.g., if there is no SIGSEGV handler the
   whole process is terminated.

True, but this can be handled by having the master thread process catch
SIGSEGV and redistributing the signal to all of its child-threads.

(The assumption I'm making here is that the master thread doesn't do
anything except spawn all threads for the process and monitors its child
processes for death.  This is the n+1 model.)

   This will have to go hand in hand with an extension of the core file
   format to include information about all threads but for the time being
   it's enough if only the offending thread is dumped and the rest simply
   killed.

True, although my bias has always been that if you wanted debuggable
programs, you wouldn't have been using threads in the first place.  :-)
(That was a joke, for the humor-impaired!)

   3rd Problem: one uid/gid process-wide

   All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
   is similar to the signal handler.  I think one should again keep the
   information exclusively in the master thread and have all others refer
   to this information.

This will probably have to be emulated in user-mode via IPC's.  UID
changes don't happen often, and they're **NOT** performance critical.
The aternative is to put locking around all of the uid/gid checks in the
mainline kernel code, and that's been considered unreasonable.

   4th Problem: thread termination

   In general, thread termination is not of much interest for the rest of
   the system.  It is in the moment but if the fatal signal handling is
   done this will change.

   If a thread gets a fatal signal, the whole process is killed.  No
   cleanup necessary.  Signal handlers can be installed if necessary.

   If a thread terminates naturally and can perform the cleanup itself.

   In any case, the death signal should be ignored.  Except for the last
   thread, of course, which has to notify the process starting the MT
   application.

I assume here that when you say "death signal" you mean SIGCHLD?  If so,
if all threads are children of the master thread, then the master thread
will get all of the SIGCHLD's, and it can deal with them appropriately.
(In fact, the master thread can get the notification that one of the
threads died due to an unhandled SEGV, and it can use that information
to kill off all over the other threads.)

   5th Problem: suspended starting

   Related to the last problem a good old friend pops up.  Depending on
   the solution of the last problem it might be necessary to add
   suspended starting of threads.  The problem is that sometimes the
   starter has to modify parameters (e.g., scheduler) of the newly
   started thread before it can actually start working.  If this fails,
   the new thread must be terminated immediately.  But who will get the
   termination signal?  The data structures for the new thread must be
   removed as well and this after the new thread is guaranteed to be
   vanished.

Umm why can't this be done in user space?  We can do it in kernel
space, but it means adding a new flag to clone() which tells it to
suspend the child immediately and let the parent return.  Why can't it
be done in userpsace by having the library which calls clone() as part
of starting a new thread suspend itself if it's the child?  I must be
missing something.

- Ted
-
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: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 03:06:52PM -0700, Linus Torvalds wrote:
> 
> Good that _somebody_ actually looked at the code. I'll make some more
> modifications to handle blocked signals correctly (ie handling the case
> where the signal is blocked in all threads and then unblocked in one of
> them _after_ it was delivered), but I've been disappointed by how much hot
> air there's been on the list, and how little comments on how the actual
> code works.

I've been looking at the code and I think it could be extended a bit:

I've been thinking about how to best get rid of the thread manager for
thread creation in LinuxThreads.  It is currently needed to do the wait.

I think the easiest way is to just implement the Single Unix SA_NOCLDWAIT 
and add a prctl to set a queued exit signal to some arbitary pid. That pid 
could be the thread group so some thread would just handle it and do the 
necessary LinuxThreads bookkeeping.
The queued exit signal could carry which thread has died. The only tricky
issue is what to do when the exit signal cannot be queued because there
are too many threads in flight, in this case it makes sense to just make
it pending without any data (the thread library can search some global
data structure in this case)

All these changes are very easy.

-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: Linux 2.2.18pre1

[Chip Salzenberg]

According to Bill Rugolsky Jr.:
> On Fri, Sep 01, 2000 at 12:05:03PM +0100, Alan Cox wrote:
> > Right now Im not happy with the nfsv3 stuff I last looked at and
> > it seems to still contain things Linus rejected a while back.
>  
> Alan, would you please describe in a few words what items are
> problematic?

Yes, please ... without specifics we can't improve the situation.
-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early."  // MST3K
-
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 2.2.18pre2

[Chip Salzenberg]

According to Albert D. Cahalan:
> The last time this issue came up, it was discovered that Windows 9x
> does not use the same generation rules as Windows NT.

Well, making the rules the same as NT would be fine, I suspect.
Even better would be a mount option, I think, since there will
always be someone with specific compatibility issues.
-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early."  // MST3K
-
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: thread group comments

[Alexander Viro]

On Fri, 1 Sep 2000, Linus Torvalds wrote:

> Oh, I basically agree, _except_ that Al Viro has these ideas pending for
> 2.5.x that basically create a "process capability cache" that is a cache
> of all the process ID's and capabilities (ie uid, gid, groups etc). Which
> would be this copy-on-write thing.
> 
> And that may end up mixing well with a "CLONE_CAPABILITIES" flag.

I don't think so. Look: suppose we've got two processes sharing the
credentials pointer. Fine. We also have something else (e.g. opened file
or pending NFS request, etc.) sharing these creds. Now we do the setgid().
How would it know that we want to have creds of the second process
changed, but creds of everything else left unchanged? "Partial copy-on-write"
is an odd thing...

BTW, idea is hardly mine - it goes back at least to early 90s (as
do the problems that make it useful).

-
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

[Ari Pollak]

Hrm. very weird. I guess it doesn't do it anymore (couldn't tell you if it
did it on test8-pre1 w/o vmpatch, i had it disabled) - only when you abort
it in the middle. In any case, here's what /proc/slabinfo says:

slabinfo - version: 1.1
kmem_cache59 78100221
uhci_urb_priv  2112 32111
uhci_qh0  0 64001
uhci_td2 59 64111
nfs_read_data  0  0384001
nfs_write_data 0  0384001
nfs_page   0  0128001
nfs_fh16 60128221
blkdev_requests 1024   1050128   35   351
file lock cache6 43 88111
uid_cache  3112 32111
tcp_tw_bucket  1 30128111
tcp_bind_bucket   12112 32111
tcp_open_request   0  0 64001
inet_peer_cache1 59 64111
ip_fib_hash   10112 32111
ip_dst_cache  20 40192221
arp_cache  3 30128111
skbuff_head_cache161280192   14   141
sock 152153832   17   172
inode_cache43418  46980384 4698 46981
bdev_cache  6960   7021 64  118  1191
signal_queue  12 29132111
kiobuf 0  0128001
dentry_cache   23767  28590128  953  9531
dquot  0  0128001
filp1478   1500128   50   501
names_cache0  2   4096021
buffer_head30112  30720128 1024 10241
mm_struct 56 60192331
vm_area_struct  2113   2183 64   37   371
fs_cache  56 59 64111
files_cache   55 63448771
signal_act58 60   1344   20   201
size-131072(DMA)   0  0 13107200   32
size-1310720  0 13107200   32
size-65536(DMA)0  0  6553600   16
size-65536 0  0  6553600   16
size-32768(DMA)0  0  32768008
size-32768 4  4  32768448
size-16384(DMA)0  0  16384004
size-16384 2  2  16384224
size-8192(DMA) 0  0   8192002
size-8192 13 13   8192   13   132
size-4096(DMA) 0  0   4096001
size-4096 16 19   4096   16   191
size-2048(DMA) 0  0   2048001
size-2048 40 46   2048   21   231
size-1024(DMA) 0  0   1024001
size-1024 34 44   10249   111
size-512(DMA)  0  0512001
size-512  81 88512   11   111
size-256(DMA)  0  0256001
size-256  20 45256231
size-128(DMA)  0  0128001
size-128 567630128   21   211
size-64(DMA)   0  0 64001
size-64  396531 64891
size-32(DMA)   0  0 64001
size-32 3529   6195 64   68  1051



-
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: Press release - here we go again!

[J. Dow]

> I am not a lawyer, marketing manager, marketer, salesperson, pre-sales
> person, or indeed even a "real" kernel hacker. I'm a bloody high school
> student. Hence the lack of the "journalistic touch". I'm just hacking
away,
> hoping someone will notice, tell me everything to fix, I fix it, and in
the
> end I get credit, and people hail me down the streets with a ticker-tape
> para

Thank you for doing it, Daniel. SOMEBODY needs to do it. You elected to.
Stephan is attempting to help you do it right. (If he is who I believe him
to be
(there can't be TWO can there?) he's had plenty of experience listening to
the sort of pundits you want to reach complain about flakey press releases.
Um, I've seen this litany before - in almost the same order on BIX. {^_-}

> Read about the second paragraph of the initial email I sent out. A feature
> writer for a well-known computer magazine here tried to contact one of the
> higher deities and they more or less told him to bugger off. Do we want to
> do this to ALL the press? (besides, I don't have Linus' phone number on
> hand).

This is indeed "Not A Good Thing" (tm). Somebody should bite the bullet
and be there to answer questions. (I'm not volunteering. I don't know
enough to answer the questions cogently. But I did make one minor
successful kernel hack to keep one of my machines working past Y2K
when its BIOS would lockup on boot with a divide by zero error.)

> That was actually one of the things I red-flagged myself for and pondered
> about. Then I decided I'd get flamed for it on l-k and just hoped to god
> that someone would come up with something constructive.

If you refer to a trademarked item mark it so and place the usual
footnote. It covers your asterisk. {o.o}

> > 3.) The language is a bit (and here my own deficit strikes me as I'm
> > searching for the right word, let's try) 'unprofessional'. With that I
> > mean that it is not the 'typical' language of press releases. I quote:
> > 
> > >   * Enterprise Ready! Linux 2.4 includes changes that
> > > make it even more ready for Enterprise environments.
> > 
> > >   * Linux also includes Logical Volume Manager, for easy
> > > administration of disk space; you can also combine
> > > several hard drives/partitions into one for even more
> > > space and ease!
> > 
> > >   * More interface support! Linux is now even better
> > > supported for the desktop with the advent of support
> > > for USB, FireWire and AGP.
> > 
> > > Linux includes a new architecture, known as Netfilter,
> > > to act as a firewall (security - choose what gets
> > > through and what doesn't), and masquerading server
> > > (multiple machines can share the one connection without
> > > any fuss or hassle). Netfilter is now much quicker, 
> > 
>
> Yeah, well scroll up. I will go and read the KDE press release, but don't
> mistake me for a professional journalist, or someone who sits there all
day
> slamming out quality press releases.

The phrasing is inconsistent. Cleaning that piece up is good training for
engineers as well as PR authors. (English is my primary language - heck
only people language - and I am still learning to use it correctly. If you
spend
the time now it will be a BIG win come time to look for a job. I turned down
a few employment prospects when I was in the hiring loop because they
could not express themselves clearly.)

> > One should take time and discuss what _groundbreaking_ new features
> > Linux 2.4 will have when compared to both 2.2 and the competitors. I'm
> > thinking of the scalability issues, as well as all the other
> > 'enterprise' enhancements like maximum memory/processors supported. On
> > the other end of the user scale you might want to proudly present Linux
> > as the first system to support ATA100. Full USB support comes to mind.
>
> Well, does Linus, Alan, etc, want to share their viewpoint? ATA100 is a
very
> good one, yes, and I actually did put in USB if you bothered to read the

And if got lost. That should tell you something. Perhaps something like
"*Advanced interface support for USB, FireWire, and AGP!"

Then place any expostulatory text indented under that as complete sentences.
This treates the bulleted items as "titles". Your target audience dispises
incomplete sentences and clunky grammar. (And do rest assured that folks
like Jerry Pournelle have posted some REAL clunkers, worse than anything
you did) on BIX for our chuckles.)

> press release, indeed what you pasted also. And the first thing I wrote
was
> about how it's so much better for SMP and 64gig of ram, and >2gig files
...

> > One should single out what Linux 2.4 can do better than the competitors,
> > but in a respectful (w.r.t. competitors) and indirect way. And one
> > should take the time and space to go into some application examples to
> > elaborate on these outstanding features.
>
> Application != kernel.

Enh, one COULD 

RE: 2.4.0test7 panics on boot

[Sid Boyce]

Felix wrote:
> The last non-panic message on screen is:

>  IPv6 v0.8 for NET4.0

> The panic reason is "attempting to kill init".
> Has anyone else had this problem?

> Felix

Sid Boyce writes:
I experienced the same problem when I compiled the kernel with IPV6
selected on one of my machines. I recompiled without IPV6 and it's AOK.
I've not followed it up because I'm not using IPV6.
Regards
-- 
Sid Boyce ... hamradio G3VBV ... Cessna/Warrior Pilot
Linux only shop
-
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: thread group comments

[David Schwartz]

> 3rd Problem: one uid/gid process-wide
>
> All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
> is similar to the signal handler.  I think one should again keep the
> information exclusively in the master thread and have all others refer
> to this information.

Other than that it's required by the POSIX standard, can you see any real
use for this? It's generally an obstacle you have to code around.

What I would suggest is that the Linux kernel continue the way it is. The
race conditions in this are unavoidable, so let's just acknowledge them and
live with them.

The pthreads library can do the horrible deed of getting each thread to
change it's *id. At the very worst, add a kernel facility to change all the
*ids in a group and let the pthreads library code use it.

But to hack the kernel to have one set of *ids for all the threads is
illogical. It would make it unduly hard to have different threads serving
requests on behalf of different clients with different security contexts.

DS

-
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: thread group comments

[Ulrich Drepper]

Alan Cox <[EMAIL PROTECTED]> writes:

> You dont want it in kernel space.

I don't see how you can do this.  Also on user level you would have to
do this atomically since otherwise communication between the threads
isn't possible anymore.  We have a PR in the glibc bug data base about
just that.  And I know that there are many other users with this
problem.

-- 
---.  ,-.   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: Press release - here we go again!

[Daniel Stone]

> >-> Multimedia
> >   * Faster multimedia with specially designed video acceleration driver
s. In combination with the new release of the X Windows System, Linux includes 
drivers to take full advantage of your accelerated video card (nVidia and 3Dfx 
cards among those supported) to get maximum video performance for gaming, graph
ics, etc.
> 
> Actually it seems that hardware acceleration for nVidia cards has
> momentarily
> died with the loss of MAP_NR in page[cache].h.  NVidia only claims to 
> support 2.2.x kernels.  If updated drivers do exist, I would definitely
> love to hear about them.

Tim,
This may or may not be true. I have no idea as I'm too pov to own a real
video card. *fwaps self* More research needed. Treat this as
0.0.0.1-test1-pre1-beta1-alpha1-preview1-unstable-compile1.

d

--
Daniel Stone
Kernel Hacker (or at least has aspirations to be)
[EMAIL PROTECTED]
http://dustpuppy.ods.org
-
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: Press release - here we go again!

[Daniel Stone]

> Hi Daniel, anyone.

Hullo(tm).

> I am not a lawyer and I am not a marketing manager, but I think there
> are several things that need fixing. Most of these are differences that
> I think stand out when comparing your draft with the KDE press releases
> for their KDE2.0 betas (those being the only press releases I've read
> for an open source project yet), available at www.kde.org.

I am not a lawyer, marketing manager, marketer, salesperson, pre-sales
person, or indeed even a "real" kernel hacker. I'm a bloody high school
student. Hence the lack of the "journalistic touch". I'm just hacking away,
hoping someone will notice, tell me everything to fix, I fix it, and in the
end I get credit, and people hail me down the streets with a ticker-tape
para

> 1.) First of all, there should be some people named at the end of the
> p.r. that interested press people can contact to get an interview or
> such. Naturally, this should be some of the core developers.

Read about the second paragraph of the initial email I sent out. A feature
writer for a well-known computer magazine here tried to contact one of the
higher deities and they more or less told him to bugger off. Do we want to
do this to ALL the press? (besides, I don't have Linus' phone number on
hand).

> 2.) I'm still not sure whether you can use so many trademarks within the
> p.r. without marking them as such and using them incorrectly (e.g. 'Sun
> Microsystems' instead of 'Sun', 'Microsoft WindowsCE' (a guess) instead
> of 'Windows-CE', etc.)

That was actually one of the things I red-flagged myself for and pondered
about. Then I decided I'd get flamed for it on l-k and just hoped to god
that someone would come up with something constructive.

> 3.) The language is a bit (and here my own deficit strikes me as I'm
> searching for the right word, let's try) 'unprofessional'. With that I
> mean that it is not the 'typical' language of press releases. I quote:
> 
> >   * Enterprise Ready! Linux 2.4 includes changes that
> > make it even more ready for Enterprise environments.
> 
> >   * Linux also includes Logical Volume Manager, for easy
> > administration of disk space; you can also combine
> > several hard drives/partitions into one for even more
> > space and ease!
> 
> >   * More interface support! Linux is now even better
> > supported for the desktop with the advent of support
> > for USB, FireWire and AGP.
> 
> > Linux includes a new architecture, known as Netfilter,
> > to act as a firewall (security - choose what gets
> > through and what doesn't), and masquerading server
> > (multiple machines can share the one connection without
> > any fuss or hassle). Netfilter is now much quicker, 
> 

Yeah, well scroll up. I will go and read the KDE press release, but don't
mistake me for a professional journalist, or someone who sits there all day
slamming out quality press releases.

> One should take time and discuss what _groundbreaking_ new features
> Linux 2.4 will have when compared to both 2.2 and the competitors. I'm
> thinking of the scalability issues, as well as all the other
> 'enterprise' enhancements like maximum memory/processors supported. On
> the other end of the user scale you might want to proudly present Linux
> as the first system to support ATA100. Full USB support comes to mind.

Well, does Linus, Alan, etc, want to share their viewpoint? ATA100 is a very
good one, yes, and I actually did put in USB if you bothered to read the
press release, indeed what you pasted also. And the first thing I wrote was
about how it's so much better for SMP and 64gig of ram, and >2gig files ...

> One should single out what Linux 2.4 can do better than the competitors,
> but in a respectful (w.r.t. competitors) and indirect way. And one
> should take the time and space to go into some application examples to
> elaborate on these outstanding features.

Application != kernel.

> Well, look at the KDE people. I think they really got 'it' when it comes
> to writing press releases: Identify your strengths and explain them
> briefly, but so that my _mum_ says "Wow, Linux 2.4 is great! Where do I
> get one of those cute stuffed penguins?" after reading her woman's
> journal. (Ok, ok...:-)

okokok, I will. But please, for the love of God, stop mistaking me for a
full time quality-bullshit^Wpress-release-artist. Because I'm not. I just
hacked out a press release one night when I was pretty tired. Don't flame me
for it.

d

--
Daniel Stone
Kernel Hacker (or at least has aspirations to be)
[EMAIL PROTECTED]
http://dustpuppy.ods.org
-
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: thread group comments

[Jeff V. Merkey]

Linus Torvalds wrote:
> 
> 
> Yes. For 2.4.x, I'd love to fix anything that can be used to show real
> performance bugs. Something like "setuid() is slow when I run it threaded
> is not a real issue". Something like "pthreads is faster under NT than
> under Linux" _would_ be a real issue.
> 
> Linus
> 

pthreads is faster on NT than Linux.  It has to do with how they create
shared segments for local data to apps.  It's about twice as fast as
what's in Linux.

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: Press release - here we go again!

[Rick]

On Fri, Sep 01, 2000 at 02:00:25PM -0600, TimO wrote:
> Daniel Stone wrote:
> >-> Multimedia
> >   * Faster multimedia with specially designed video acceleration drivers. In 
>combination with the new release of the X Windows System, Linux includes drivers to 
>take full advantage of your accelerated video card (nVidia and 3Dfx cards among those 
>supported) to get maximum video performance for gaming, graphics, etc.
> 
> Actually it seems that hardware acceleration for nVidia cards has
> momentarily
> died with the loss of MAP_NR in page[cache].h.  NVidia only claims to 
> support 2.2.x kernels.  If updated drivers do exist, I would definitely
> love to hear about them.

Works perfectly for me with 2.4.0test7; the patch is fairly simple (as
noted by the fact that I have no clue what the stuff I changed does).
I'll attach it.

-- 
Rick ([EMAIL PROTECTED])
http://www.kuroyi.net

What the hell is content? Nobody buys content. Real people pay money
for music because it means something to them. A great song is not just
something to take up space on a Web site next to stock market quotes
and baseball scores.
-- Courtney Love


--- NVIDIA_kernel-0.9-4/nv.cMon Jul 10 18:32:13 2000
+++ NVIDIA_kernel-2.4/nv.c  Wed Aug  9 15:22:13 2000
@@ -549,5 +549,5 @@
 unsigned long page = get_phys_address( (unsigned long) 
 (address + (i * PAGE_SIZE)));
-unsigned long map_nr = MAP_NR(__va(page));
+struct page* map_nr = virt_to_page(__va(page));
 if (map_nr)
 {
@@ -573,9 +573,9 @@
 {
 unsigned long page = get_phys_address(address + (i * PAGE_SIZE));
-unsigned long map_nr = MAP_NR(__va(page));
+struct page* map_nr = virt_to_page(__va(page));
 if (map_nr)
 {
 mem_map_dec_count(map_nr);
-if (atomic_read(_map[map_nr].count) == 1)
+if (atomic_read(&(map_nr->count)) == 1)
 mem_map_unreserve(map_nr);
 else
--- NVIDIA_kernel-0.9-4/os-interface.c  Mon Jul 10 18:32:13 2000
+++ NVIDIA_kernel-2.4/os-interface.cWed Aug  9 15:14:05 2000
@@ -1226,5 +1226,5 @@
 while (num_pages--)
 {
-mem_map_reserve(MAP_NR(tmp_paddr)); 
+mem_map_reserve(virt_to_page(tmp_paddr)); 
 tmp_paddr += PAGE_SIZE;
 }
@@ -1241,5 +1241,5 @@
 while (num_pages--)
 {
-mem_map_unreserve(MAP_NR(tmp_paddr));
+mem_map_unreserve(virt_to_page(tmp_paddr));
 tmp_paddr += PAGE_SIZE;
 }

Re: thread group comments

[Brian Wellington]

On Fri, 1 Sep 2000, Linus Torvalds wrote:

> > 3rd Problem: one uid/gid process-wide
> > 
> > All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
> > is similar to the signal handler.  I think one should again keep the
> > information exclusively in the master thread and have all others refer
> > to this information.
> 
> No, it would be another "clone" option. 
> 
> But I don't think this is performance-critical, and I don't think it is
> something people really care about. So I'd be unlikely to handle this for
> 2.4.x.

I care.

Having written lots of Linux-specific code in BIND 9 to work around this
problem in LinuxThreads, I'd really like to see it work correctly
(correctly meaning according to posix, in this case).

Basically, on every non-Linux platform, we can start threads, parse the
config file in a thread, create new privileged sockets to listen on, and
then call setuid().  On Linux, that doesn't work, because the call to
setuid() only affects the running thread, which means we need to rework
the above logic into a capability-based mess.

This is not a performnace critical operation, but not implementing in the
kernel makes user space jump through some pretty large hoops.  The
solution would probably involve lots of inter-thread messages, which if I
remember correctly, these changes were supposed to remove.

I'd imagine other people have similar concerns...

Brian

-
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: MTBF data for linux

[Jim Garlick]

On Fri, 1 Sep 2000, Jim Garlick wrote:
> Can someone point me to MTBF data for Linux?  I realize this is kind of
> vague.  Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
> but any data is better than nothing.  This is to help win an argument to 
> put linux on a large cluster.  Thanks in advance.

Thanks for all the replies so far (public and private).  Just to clarify:  
the argument is Compaq Tru64 vs linux for a large (~1000 node) cluster of 
alphas.  NT is not in the running, so old ammo from the desktop wars 
won't help here.

What I'm looking for is someone who is running a large number of nodes and 
has gathered statistics reflecting the average number of system crashes over 
time.  Obviously this depends on hardware, workload, power, etc.;  however 
a good MTBF for any cluster of linux systems would help build a little 
confidence.  

Simply pointing to the many large HPC linux clusters in use all over the 
world, or even at other U.S. energy labs apparently isn't convincing enough.

Thanks again,

Jim

On Fri, 1 Sep 2000, Matthew Dharm wrote:

> I agree that the MTBF can be very misleading...
> 
> But put it this way:  My server ran 2.2.14 for over 400 days before I
> rebooted it.  It was down for about 5 minutes while rebooting (probably
> less).
> 
> My NT Server gets a nightly reboot.  I can't get it to run for more than a
> week without it developing _some_ problem.
> 
> Mind you, on both of these systems, nobody is doing any development/kernel
> hacking/anything.  They're just mail/www/ftp/dns/login (for linux) servers.
> To a first order approximation, they're basically the same hardware, both
> protected by a UPS.
> 
> Matt
> 
> On Fri, Sep 01, 2000 at 10:38:54PM +0200, Igmar Palsenberg wrote:
> > On Fri, 1 Sep 2000, Jim Garlick wrote:
> > 
> > 
> > MTBF is something that says shit. depends on hardware, what the machine
> > does, if it has a UPS, etc, etc, etc, etc.
> > 
> > This machine is running 2 years without problems.
> > 
> > > Jim Garlick
> > 
> > 
> > Igmar
> > 
> > -
> > 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/

[patch] smbfs update for 2.2.18-pre[12]

[Urban Widmark]

Hello

Patch vs pre1 but also applies vs pre2:

http://www.hojdpunkten.ac.se/054/samba/smbfs-2.2.18-pre1.patch.gz


Changes are mostly from 2.4.0-test7:
* proc.c: add back lanman2 support (OS/2 and others)
* proc.c: check length of paths to avoid buffer overflow
* proc.c: don't do interruptable_sleep in smb_retry to avoid signal
  problem/race.
* proc.c: O_RDONLY & smb_revalidate_inode fix (tail -f)
* proc.c: add nls support
* sock.c: attempt to fix smb_data_callback (avoid infinite loop)

The lanman2 is a partial undo of some changes made for 2.2.16 that caused
problems for OS/2 users.

"attempt to fix" should perhaps now be "appears to fix". A problem with
lockups (infinite loop with BKL held?) that appears to go away. But the
debug outputs haven't told us why. Doing while(1) after a lock_kernel()
seems dangerous anyway.

/Urban

-
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: thread group comments

[Linus Torvalds]

On Fri, 1 Sep 2000, Alan Cox wrote:
> > 
> > No, it would be another "clone" option. 
> 
> You dont want it in kernel space.

Oh, I basically agree, _except_ that Al Viro has these ideas pending for
2.5.x that basically create a "process capability cache" that is a cache
of all the process ID's and capabilities (ie uid, gid, groups etc). Which
would be this copy-on-write thing.

And that may end up mixing well with a "CLONE_CAPABILITIES" flag.

Which is not to say that this will necessarily get done. But other changes
may make it an option. I was just saying that if done that way, it would
be a CLONE_ flag instead of "we will use the thread leaders ID" thing.

> Its also very rare and not a performance case to push into glibc

Yes. For 2.4.x, I'd love to fix anything that can be used to show real
performance bugs. Something like "setuid() is slow when I run it threaded
is not a real issue". Something like "pthreads is faster under NT than
under Linux" _would_ be a real issue.

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: MTBF data for linux

[Alan Cox]

> > Can someone point me to MTBF data for Linux?  I realize this is kind of
> > vague.  Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
> > but any data is better than nothing.  This is to help win an argument to 
> > put linux on a large cluster.  Thanks in advance.
> 
> The answer is pretty simple...
>   longer than any hardware you put it on!

I dont think thats quite the case. I'd actually suggest the right place to
ask about clusters is the extreme-linux list (see www.extreme-linux.org). These
guys are running real large beowulfs and will actually have data reflecting
that kind of usage. Also since they run these sites and have to justify them
financially they'll have more reliable data than others.

Alpha and SMP are both things that seem to reduce your MTBF ..

-
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: thread group comments

[Alan Cox]

> > 3rd Problem: one uid/gid process-wide
> > 
> > All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
> > is similar to the signal handler.  I think one should again keep the
> > information exclusively in the master thread and have all others refer
> > to this information.
> 
> No, it would be another "clone" option. 

You dont want it in kernel space. Not unless you plan to lock uid/gid access
and make them atomic. Think about things like file operations where the uid
changes under you on another CPU as you walk a directory tree checking
permissions.. 

Quota looks even more horrible.

Its also very rare and not a performance case to push into glibc

-
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: MTBF data for linux

[Alan Cox]

> I'm sure there must be boxes with kernel 1.2.13 out there
> that have been running since 1.2.13 came out...

We ran 1.2.13lmp for about 1100 days before the box finally got turned off -
twice around the uptime clock and more

-
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: thread group comments

[Linus Torvalds]

Good that _somebody_ actually looked at the code. I'll make some more
modifications to handle blocked signals correctly (ie handling the case
where the signal is blocked in all threads and then unblocked in one of
them _after_ it was delivered), but I've been disappointed by how much hot
air there's been on the list, and how little comments on how the actual
code works.

Thanks, Uli/.

On 1 Sep 2000, Ulrich Drepper wrote:
> 
> 1st Problem:   One signal handler process process-wide
> 
> What is handled correctly now is sending signals to the group.  Also
> that every thread has its mask.  But there must be exactly one signal
> handler installed.  I.e., a sigaction() call to set a new handler has
> consequences process-wide.  Since this muse be atomic I think the
> information should be kept in the thread group leader's data
> structures and the other threads should simply use this information
> all the time.  Yeah, I know, one more indirection.

We already do this. This is exactly what CLONE_SIGHAND does.

Having looked at the problem some more, it appears to never really make
sense to have CLONE_THREAD and CLONE_SIGHAND be separate. Basically,
either you share signals or you don't. Pthreads shares them. I'll make it
a single flag, and we'll have CLONE_SIGNAL (same as old CLONE_SIGHAND),
and that will be a "signal group" aka "thread group".

> 2nd Problem: Fatal signal handling
> 
> kernel/signal.c contains:
> 
>  * Send a thread-group-wide signal.
>  *
>  * Rule: SIGSTOP and SIGKILL get delivered to _everybody_.
> 
> That's OK.  Except that is a signal whose default action is to
> terminate the process is not caught be the application, this signal is
> also handled process-wide.  E.g., if there is no SIGSEGV handler the
> whole process is terminated.

Fair enough. 

> 3rd Problem: one uid/gid process-wide
> 
> All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
> is similar to the signal handler.  I think one should again keep the
> information exclusively in the master thread and have all others refer
> to this information.

No, it would be another "clone" option. 

But I don't think this is performance-critical, and I don't think it is
something people really care about. So I'd be unlikely to handle this for
2.4.x.

> 4th Problem: thread termination
> 
> In general, thread termination is not of much interest for the rest of
> the system.  It is in the moment but if the fatal signal handling is
> done this will change.
> 
> If a thread gets a fatal signal, the whole process is killed.  No
> cleanup necessary.  Signal handlers can be installed if necessary.
> 
> If a thread terminates naturally and can perform the cleanup itself.
> 
> In any case, the death signal should be ignored.  Except for the last
> thread, of course, which has to notify the process starting the MT
> application.

This is why you should have the "n+1" approach. The "+1" thing is the one
that sees the "n" threads die. The parent of the threaded process is the
one that sees the "+1" die.

> I can see two possible solutions, neither of which I've tried:
> 
> - the termination signal given to clone calls is 0 (zero).  So no
>   notification is sent out.  Question is: does the kernel allow this?

Yes, as far as I can tell. I still don't think you should do it directly
like this.

> 5th Problem: suspended starting
> 
> Related to the last problem a good old friend pops up.  Depending on
> the solution of the last problem it might be necessary to add
> suspended starting of threads.  The problem is that sometimes the
> starter has to modify parameters (e.g., scheduler) of the newly
> started thread before it can actually start working.  If this fails,
> the new thread must be terminated immediately.  But who will get the
> termination signal?  The data structures for the new thread must be
> removed as well and this after the new thread is guaranteed to be
> vanished.

You can actually do this with CLONE_PTRACE right now.

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/

2.4.0-test7 doesn't boot on Fujitsu Lifebook 765DX

[Matt Yourst]

It looks like 2.4.0-test7 won't boot on a Fujitsu Lifebook 765DX. The
kernel immediately hard reboots very early in the setup phase, before
it even displays the Uncompressing Linux message (or so it looks.)

The machine's relevant specs:

Fujitsu Lifebook 765DX
Pentium MMX 133 MHz
48 MB of RAM (up from the standard 32 MB)

The kernel was compiled for a generic 586 (the actual CPU is a Pentium
MMX 133) with gcc 2.95.2, with all CPU-specific extras disabled. NFS
root support, initrd, romfs and ramfs were compiled into the bzImage;
everything else was modular (and never loaded.) The boot loader was
grub 0.5.96, with both the kernel and initrd loaded off a floppy. I
even tried explicitly specifying mem=48M since I've heard the BIOS has
bugs on some Fujitsu laptops.

Note that the diskette boots perfectly on my Dell Inspiron and several
other machines with at least a Pentium CPU, so it must be something
with this specific machine. I have not tried 2.2.x series kernels, but
since the machine is someone else's, I don't have unlimited access to
experiment with it.

Any ideas? Thanks.

-
 Matt T. YourstMassachusetts Institute of Technology
 [EMAIL PROTECTED] 617.225.7690
 513 French House - 476 Memorial Drive - Cambridge, MA 02136
-
-
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/

thread group comments

[Ulrich Drepper]

I hoped somebody else would write something about Linus' test8-pre1
thread group changes but I haven't seen anything.  Now you have to
bear with me even though I'm incompetent[1].

I took a look at the code and thought about the changes
necessary/possible in the thread library.  Here's what I came up with
so far:


1st Problem:   One signal handler process process-wide

What is handled correctly now is sending signals to the group.  Also
that every thread has its mask.  But there must be exactly one signal
handler installed.  I.e., a sigaction() call to set a new handler has
consequences process-wide.  Since this muse be atomic I think the
information should be kept in the thread group leader's data
structures and the other threads should simply use this information
all the time.  Yeah, I know, one more indirection.



2nd Problem: Fatal signal handling

kernel/signal.c contains:

 * Send a thread-group-wide signal.
 *
 * Rule: SIGSTOP and SIGKILL get delivered to _everybody_.

That's OK.  Except that is a signal whose default action is to
terminate the process is not caught be the application, this signal is
also handled process-wide.  E.g., if there is no SIGSEGV handler the
whole process is terminated.

This will have to go hand in hand with an extension of the core file
format to include information about all threads but for the time being
it's enough if only the offending thread is dumped and the rest simply
killed.


3rd Problem: one uid/gid process-wide

All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
is similar to the signal handler.  I think one should again keep the
information exclusively in the master thread and have all others refer
to this information.



4th Problem: thread termination

In general, thread termination is not of much interest for the rest of
the system.  It is in the moment but if the fatal signal handling is
done this will change.

If a thread gets a fatal signal, the whole process is killed.  No
cleanup necessary.  Signal handlers can be installed if necessary.

If a thread terminates naturally and can perform the cleanup itself.

In any case, the death signal should be ignored.  Except for the last
thread, of course, which has to notify the process starting the MT
application.

I can see two possible solutions, neither of which I've tried:

- the termination signal given to clone calls is 0 (zero).  So no
  notification is sent out.  Question is: does the kernel allow this?

- the kernel ignores the SIGCHLD signal for all threads except the last
  one

In any case is there the problem how to handle the termination of the
master thread.  If it is not aware of starting and terminating threads
I could imagine some user-level mechanisms to make this work but they
are not very clean (it involves changing the death signal in the
thread depending on the situation).  If there is something people
think the kernel could do this would be probably better.


5th Problem: suspended starting

Related to the last problem a good old friend pops up.  Depending on
the solution of the last problem it might be necessary to add
suspended starting of threads.  The problem is that sometimes the
starter has to modify parameters (e.g., scheduler) of the newly
started thread before it can actually start working.  If this fails,
the new thread must be terminated immediately.  But who will get the
termination signal?  The data structures for the new thread must be
removed as well and this after the new thread is guaranteed to be
vanished.

Anyway, I still think it's not even worth discussing this much since
the whole change to implement this is only a few lines.  And it's in
no fastpath.



I might have more if I get deeper into implementation details.  But if
the above problems could be fixed we'd be a long way down the read to
a good implementation.


[1] Since Linus says so it must be true.

-- 
---.  ,-.   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: MTBF data for linux

[dave]

On  1 Sep, Jim Garlick wrote:
> Can someone point me to MTBF data for Linux?  I realize this is kind of
> vague.  Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
> but any data is better than nothing.  This is to help win an argument to 
> put linux on a large cluster.  Thanks in advance.
> 
> Jim Garlick
> 

The answer is pretty simple...

  longer than any hardware you put it on!

-- 
Dave

---
Dave Helton, KD0YU- [EMAIL PROTECTED]   - http://www.kd0yu.com
Real World Computing  - 319-386-4041 - 8am-5pm CST
Linux/Novell/NT | Servers/Workstations | Consulting | Internet Technologies 
---
_
   / /  (_)__  __   __
  / /__/ / _ \/ // /\ \/ /  . . . t h e   c h o i c e   o f   a
 //_/_//_/\_,_/ /_/\_\ G N U   g e n e r a t i o n . .   
---

-
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: MTBF data for linux

[Rik van Riel]

On Fri, 1 Sep 2000, Matthew Dharm wrote:

> Whoops!  Think-o.  I meant I'm running 2.2.5 for over 400 days.

I'm sure there must be boxes with kernel 1.2.13 out there
that have been running since 1.2.13 came out...

(however, that doesn't mean I would recommend that kernel
to anyone)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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: MTBF data for linux

[Matthew Dharm]

Whoops!  Think-o.  I meant I'm running 2.2.5 for over 400 days.

Matt

On Fri, Sep 01, 2000 at 01:45:25PM -0700, Matthew Dharm wrote:
> I agree that the MTBF can be very misleading...
> 
> But put it this way:  My server ran 2.2.14 for over 400 days before I
> rebooted it.  It was down for about 5 minutes while rebooting (probably
> less).
> 
> My NT Server gets a nightly reboot.  I can't get it to run for more than a
> week without it developing _some_ problem.
> 
> Mind you, on both of these systems, nobody is doing any development/kernel
> hacking/anything.  They're just mail/www/ftp/dns/login (for linux) servers.
> To a first order approximation, they're basically the same hardware, both
> protected by a UPS.
> 
> Matt
> 
> On Fri, Sep 01, 2000 at 10:38:54PM +0200, Igmar Palsenberg wrote:
> > On Fri, 1 Sep 2000, Jim Garlick wrote:
> > 
> > > Can someone point me to MTBF data for Linux?  I realize this is kind of
> > > vague.  Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
> > > but any data is better than nothing.  This is to help win an argument to 
> > > put linux on a large cluster.  Thanks in advance.
> > 
> > MTBF is something that says shit. depends on hardware, what the machine
> > does, if it has a UPS, etc, etc, etc, etc.
> > 
> > This machine is running 2 years without problems.
> > 
> > > Jim Garlick
> > 
> > 
> > Igmar
> > 
> > -
> > 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/
> 
> -- 
> Matthew Dharm  Home: [EMAIL PROTECTED] 
> Maintainer, Linux USB Mass Storage Driver
> 
> M:  No, Windows doesn't have any nag screens.
> C:  Then what are those blue and white screens I get every day?
>   -- Mike and Cobb
> User Friendly, 1/4/1999
> -
> 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/

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

I'm just trying to think of a way to say "up yours" without getting fired.
-- Stef
User Friendly, 10/8/1998
-
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

[Rik van Riel]

On Fri, 1 Sep 2000, Ari Pollak wrote:

> Well, the vmpatch still didn't fix the problem I've been having
> for many moons (I believe since late 2.3.99) - When running
> updatedb from the slocate distribution, I lose at least 90 MB of
> memory by the time it's finished, and it takes about a day for
> the memory to become usable again - this is not cached/buffered
> mem, it just disappears off the face of my computer.

Does it show up as icache and/or dcache when you cat
/proc/slabinfo ?

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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

[Ari Pollak]

Well, the vmpatch still didn't fix the problem I've been having for many
moons (I believe since late 2.3.99) - When running updatedb from the
slocate distribution, I lose at least 90 MB of memory by the time it's
finished, and it takes about a day for the memory to become usable again -
this is not cached/buffered mem, it just disappears off the face of my
computer.

On Fri, 1 Sep 2000, Rik van Riel wrote:

> On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> 
> > Any of you tried copying a 2G file in the same (ext2)
> > filesystem? It starts swapping like mad and generally behaves
> > indecently, despite the huge 1024M of RAM it has.
> 
> http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
> 
> I'm working on these issues and seem to be pretty close
> to having fixed most of them now...
> 

-
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.0test7 panics on boot

[Stephen Lee]

Felix von Leitner <[EMAIL PROTECTED]> wrote:

> The last non-panic message on screen is:
> 
>   IPv6 v0.8 for NET4.0
> 
> The panic reason is "attempting to kill init".
> Has anyone else had this problem?

I have the same problem if I have ipv6 compiled in.  Sorry, I'll
post the oops messages when I get my hands on it.

Stephen

-
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] string-486.h modified

[Richard B. Johnson]

On Fri, 1 Sep 2000, Pavel Machek wrote:

> Hi!
> 
> > > > On Thu, 31 Aug 2000, Petko Manolov wrote:
> > > > 
> > > > [Snipped...]
> > > > 
> > > > Good. You understand. Keep up the good work.
> > > 
> > > 
> > > I realy would like to see this code in use ;-)
> > 
> > After you test it **THOUROUGHLY**, send a patch to Linus. I
> > recommend testing it in a user-mode program with all kinds of
> > sizes/shapes/lengths/offsets, etc., and making certain that you
> > don't destroy any registers that are "precious" for the
> > usual versions of gcc.
> > 
> > If your patch doesn't hurt anything, even if it only adds marginal
> > performance, I'm pretty sure that Linus will accept it.
> 
> I think patch like this is not safe for 2.4.X-pre.
> 

Not safe only in that there is so much stuff changed all at once
that it'd be a good idea not to change anything that doesn't have to
be changed. I agree.

> However, in 2.5.0 we should apply it, and force it on *all* cpus just
> to test it well. Then in 2.5.10 we should turn it off for
> pentium/MMX+.
> 
>   Pavel

Once 2.4 is released, has its usual bug-fixes, becomes reliable, then
Petko can send his diff. That way, new problems won't be thought to
be a result of his patch. That us a good idea.


Cheers,
Dick Johnson

Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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] string-486.h modified

[Alan Cox]

> However, in 2.5.0 we should apply it, and force it on *all* cpus just
> to test it well. Then in 2.5.10 we should turn it off for
> pentium/MMX+.

Even original pentium has hardware optimised rep movs fast paths. Its just
a few cpus they disable it via undocumented magic (ditto it seems a couple
of PII chip steppings judging by msr usage traces of bioses coming up in
bochs)


-
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: MTBF data for linux

[Matthew Dharm]

I agree that the MTBF can be very misleading...

But put it this way:  My server ran 2.2.14 for over 400 days before I
rebooted it.  It was down for about 5 minutes while rebooting (probably
less).

My NT Server gets a nightly reboot.  I can't get it to run for more than a
week without it developing _some_ problem.

Mind you, on both of these systems, nobody is doing any development/kernel
hacking/anything.  They're just mail/www/ftp/dns/login (for linux) servers.
To a first order approximation, they're basically the same hardware, both
protected by a UPS.

Matt

On Fri, Sep 01, 2000 at 10:38:54PM +0200, Igmar Palsenberg wrote:
> On Fri, 1 Sep 2000, Jim Garlick wrote:
> 
> > Can someone point me to MTBF data for Linux?  I realize this is kind of
> > vague.  Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
> > but any data is better than nothing.  This is to help win an argument to 
> > put linux on a large cluster.  Thanks in advance.
> 
> MTBF is something that says shit. depends on hardware, what the machine
> does, if it has a UPS, etc, etc, etc, etc.
> 
> This machine is running 2 years without problems.
> 
> > Jim Garlick
> 
> 
>   Igmar
> 
> -
> 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/

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

M:  No, Windows doesn't have any nag screens.
C:  Then what are those blue and white screens I get every day?
-- Mike and Cobb
User Friendly, 1/4/1999
-
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/

[patchlet] Removing an unused variable in do_anonymous_page()

[Rasmus Andersen]

Hi.

This is against 2.4.0-t8p1. The variable 'high' in do_anonymous_page seems
unused. The following patch removes it. Comments?

--- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
+++ linux/mm/memory.c   Fri Sep  1 22:21:43 2000
@@ -1095,15 +1095,12 @@
  */
 static int do_anonymous_page(struct mm_struct * mm, struct vm_area_struct * vma, 
pte_t *page_table, int write_access, unsigned long addr)
 {
-   int high = 0;
struct page *page = NULL;
pte_t entry = pte_wrprotect(mk_pte(ZERO_PAGE(addr), vma->vm_page_prot));
if (write_access) {
page = alloc_page(GFP_HIGHUSER);
if (!page)
return -1;
-   if (PageHighMem(page))
-   high = 1;
clear_user_highpage(page, addr);
entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot)));
mm->rss++;

-- 
Rasmus([EMAIL PROTECTED])

Gates' Law: Every 18 months, the speed of software halves
  -- Anonymous
-
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] string-486.h modified

[Pavel Machek]

Hi!

> > > On Thu, 31 Aug 2000, Petko Manolov wrote:
> > > 
> > > [Snipped...]
> > > 
> > > Good. You understand. Keep up the good work.
> > 
> > 
> > I realy would like to see this code in use ;-)
> 
> After you test it **THOUROUGHLY**, send a patch to Linus. I
> recommend testing it in a user-mode program with all kinds of
> sizes/shapes/lengths/offsets, etc., and making certain that you
> don't destroy any registers that are "precious" for the
> usual versions of gcc.
> 
> If your patch doesn't hurt anything, even if it only adds marginal
> performance, I'm pretty sure that Linus will accept it.

I think patch like this is not safe for 2.4.X-pre.

However, in 2.5.0 we should apply it, and force it on *all* cpus just
to test it well. Then in 2.5.10 we should turn it off for
pentium/MMX+.

Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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] 2.2: /proc/config.gz

[Pavel Machek]

Hi!

> > /lib/modules//.config is a big step up from the current situation
> > and I'm grateful.  But I do want /proc/config.gz in the kernel.
> 
> So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> If you dont even know what file you are running for kernel you have other
> problems anyway

Hugh? kernel image is not neccessarily accessible from running system.

Example 1: machine booted from ethernet.
Example 2: velo where I boot from wince and vmlinux is lost in
process.

I may have other problems, but config.gz would still be nice. (And:
how do you detect what kernel image corresponds to currently running
kernel even on normal system?)
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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.2.16 deadlocking in schedule()

[Pavel Machek]

Hi!

> > > I think I have found something. I've currently got 4 processes deadlocked
> > > on DAC960_WaitForCommand.
> > > 
> > > This machine is a VA Linux VAR Server 3000. 
> > 
> > If they stay deadlocked there then let Leonard Zubkoff know. He's both the
> > DAC960 guru and happens to work for VA so will know the box too 8)
> 
> With Leonard's help, I have determined that it is a defective card. After
> some amount of time, it ceases to generate interrupts. Now to contact
> support...

Hmm, then hook it on timer interrupt ;-). Seriously, if it only misses
few interrupts, then generate interrupt for it once a second; that
should pick up any interrupts missed.
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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] 2.2: /proc/config.gz

[Pavel Machek]

Hi!

> maintains all the useful information and will be less than 1/2kB.
> (things marked as not set or modular aren't relevant to the zImage)

Wrong. some modular options have efects on image (adding hooks, etc.)
Pavel

-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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/

[patchlet] Take two: Removing unneeded lines in vmtruncate.c (2.4.0-t8p1)

[Rasmus Andersen]

Hi.

(Thanks to Tigran Aivazian for catching me not being careful enough).

The following patch removes two, AFAICS, unneeded lines from mm/memory.c:
vmtruncate():

--- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
+++ linux/mm/memory.c   Fri Sep  1 22:25:53 2000
@@ -985,8 +985,6 @@
} while ((mpnt = mpnt->vm_next_share) != NULL);
 out_unlock:
spin_unlock(>i_shared_lock);
-   /* this should go into ->truncate */
-   inode->i_size = offset;
if (inode->i_op && inode->i_op->truncate)
inode->i_op->truncate(inode);
return;

-- 
Rasmus([EMAIL PROTECTED])

With Microsoft products, failure is not an option - it's a standard component. 
  -- Anonymous
-
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/

CE and -test7 communication broken

[Pavel Machek]

Hi!

With -test7, tcp connection to CE machine is _even slower_ than it
used to. CE are too slow to handle 115k200 serial, still they got at
least 2K/sec to linux-2.4.0-test6 (and previous). 

tcpdump now looks like this:
22:03:42.200251 10.0.0.3.www > 192.168.55.100.1026: . 8761:10221(1460)
ack 193 win 6432 (DF)
22:03:42.890251 192.168.55.100.1026 > 10.0.0.3.www: . ack 10221 win
3100 (DF)
22:03:42.900251 10.0.0.3.www > 192.168.55.100.1026: P
10221:11681(1460) ack 193 win 6432 (DF)
22:03:42.900251 10.0.0.3.www > 192.168.55.100.1026:
. 11681:13141(1460) ack 193 win 6432 (DF)
22:03:43.690251 192.168.55.100.1026 > 10.0.0.3.www: . ack 11681 win
3100 (DF)
22:03:43.700251 10.0.0.3.www > 192.168.55.100.1026: P
13141:14601(1460) ack 193 win 6432 (DF)
22:04:05.860251 10.0.0.3.www > 192.168.55.100.1026:
. 11681:13141(1460) ack 193 win 6432 (DF)
22:04:06.530251 192.168.55.100.1026 > 10.0.0.3.www: . ack 13141 win
3100 (DF)
22:04:06.540251 10.0.0.3.www > 192.168.55.100.1026: P
13141:14601(1460) ack 193 win 6432 (DF)
22:04:06.540251 10.0.0.3.www > 192.168.55.100.1026:
. 14601:16061(1460) ack 193 win 6432 (DF)
22:04:07.370251 192.168.55.100.1026 > 10.0.0.3.www: . ack 14601 win
3100 (DF)
22:04:07.380251 10.0.0.3.www > 192.168.55.100.1026: P
16061:17521(1460) ack 193 win 6432 (DF)
22:04:52.460251 10.0.0.3.www > 192.168.55.100.1026:
. 14601:16061(1460) ack 193 win 6432 (DF)
22:04:53.050251 192.168.55.100.1026 > 10.0.0.3.www: . ack 16061 win
3100 (DF)
22:04:53.060251 10.0.0.3.www > 192.168.55.100.1026: P
16061:17521(1460) ack 193 win 6432 (DF)
22:04:53.060251 10.0.0.3.www > 192.168.55.100.1026:
. 17521:18981(1460) ack 193 win 6432 (DF)
22:04:53.780251 192.168.55.100.1026 > 10.0.0.3.www: . ack 17521 win
3100 (DF)
22:04:53.790251 10.0.0.3.www > 192.168.55.100.1026: P
18981:20441(1460) ack 193 win 6432 (DF)
22:06:24.900251 10.0.0.3.www > 192.168.55.100.1026:
. 17521:18981(1460) ack 193 win 6432 (DF)
22:06:25.580251 192.168.55.100.1026 > 10.0.0.3.www: . ack 18981 win
3100 (DF)
22:06:25.590251 10.0.0.3.www > 192.168.55.100.1026: P
18981:20441(1460) ack 193 win 6432 (DF)
22:06:25.590251 10.0.0.3.www > 192.168.55.100.1026:
. 20441:21901(1460) ack 193 win 6432 (DF)
22:06:26.290251 192.168.55.100.1026 > 10.0.0.3.www: . ack 20441 win
3100 (DF)
22:06:26.300251 10.0.0.3.www > 192.168.55.100.1026: P
21901:23361(1460) ack 193 win 6432 (DF)

Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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/

Patch to add __setup() to 2.2.18pre2

[Arjan van de Ven]

Hi,

The drm code is added to 2.2.18pre, and this code uses the 2.4 __setup()
mechanism a lot. The patch at http://www.fenrus.demon.nl/setup.diff (16Kb 
so not posted here) adds this to 2.2.18pre2. The biggest part of the patch
is the change from char.a to char.o; this is needed to prevent the linker 
from being too smart.

The patch only changes the i386 linker-script, if this patch makes it into
2.2.18, I'll make sure the other archs are changed as well.

Greetings,
   Arjan van de Ven

-
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: [patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1)

[Tigran Aivazian]

On Fri, 1 Sep 2000, Rasmus Andersen wrote:
> Good point. So what is the Right Thing? Moving inode->i_size = offset
> into truncate() and cleaning up vmtruncate()? Or just kill the comment
> along with the other line? :)

the right thing is to kill the comment and the code but it will only turn
into The Right Thing when/if Linus accepts your patch :)

Regards,
Tigran

-
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: [OT] Re: Press release - here we go again!

[Theodore Y. Ts'o]

   Date:Fri, 01 Sep 2000 08:47:04 -0700
   From: Stephen Satchell <[EMAIL PROTECTED]>

   5)  Even better would be to obtain the services of a PR firm used to 
   dealing with high-tech questions -- if you would like a list of potential 
   sponsors I can poll the IPG to see who might be likely candidates.  Off the 
   top of my head, I would recommend Pam Alexander, Hastings & Humbolt, Marty 
   Winston, and S

Note that VA Linux and probably all of the various Linux companies out
there already have PR firms on retainer.  It might be best to get
someone from one of those corporations to volunteer (and I'm sure I
could probably volunteer VA) to handle actually getting the press
release out there and being the point of contact listed on the press
release.  

Of course whoever did this would have to make clear that they were doing
this as a community relations function, and that the press release would
be plugging the Linux community, and not any one specific Linux
company.  I think we could probably come up with at least a few companes
that most people would trust to represent the community fairly and not
try to exploit this for their own gain.

The point is that we *do* have people who interface with the press
professionaly, for a living, and we should be able to take advantage of
that kind of resources.

- Ted

P.S.  Yes, for those who don't know I *do* work for VA Linux, despite my
mit.edu e-mail address.

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

MTBF data for linux

[Jim Garlick]

Can someone point me to MTBF data for Linux?  I realize this is kind of
vague.  Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
but any data is better than nothing.  This is to help win an argument to 
put linux on a large cluster.  Thanks in advance.

Jim Garlick

-
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: [patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1)

[Rasmus Andersen]

On  0, Tigran Aivazian <[EMAIL PROTECTED]> wrote:
> On Fri, 1 Sep 2000, Rasmus Andersen wrote:
> 
> > Hi.
> > 
> > AFAICS, the line removed below is redundant. Comments?
> > 
> > --- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
> > +++ linux/mm/memory.c   Fri Sep  1 22:00:16 2000
> > @@ -986,7 +986,6 @@
> >  out_unlock:
> > spin_unlock(>i_shared_lock);
> > /* this should go into ->truncate */
> > -   inode->i_size = offset;
> > if (inode->i_op && inode->i_op->truncate)
> > inode->i_op->truncate(inode);
> > return;
> 
> Rasmus, you introduced a bug because you removed the code but left the
> comment around. now /* this should go into ->truncate */ is there and very
> confusing - what should go into ->truncate?

Good point. So what is the Right Thing? Moving inode->i_size = offset
into truncate() and cleaning up vmtruncate()? Or just kill the comment
along with the other line? :)

I guess my kernel experience mostly lends itself to the latter, but I
could take a shot at the former if it is the Right Thing.

Thanks for the prompt comment.
-- 
Regards,
Rasmus([EMAIL PROTECTED])

Are they taking DDT?
-- Vice President Dan Quayle asking doctors at a Manhattan
   AIDS clinic about their treatments of choice, 4/30/92
   (reported in Esquire, 8/92, and NY Post early May 92)
-
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: [patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1)

[Tigran Aivazian]

On Fri, 1 Sep 2000, Rasmus Andersen wrote:

> Hi.
> 
> AFAICS, the line removed below is redundant. Comments?
> 
> --- linux-240test8-pre1/mm/memory.c   Thu Aug 10 16:29:54 2000
> +++ linux/mm/memory.c Fri Sep  1 22:00:16 2000
> @@ -986,7 +986,6 @@
>  out_unlock:
>   spin_unlock(>i_shared_lock);
>   /* this should go into ->truncate */
> - inode->i_size = offset;
>   if (inode->i_op && inode->i_op->truncate)
>   inode->i_op->truncate(inode);
>   return;

Rasmus, you introduced a bug because you removed the code but left the
comment around. now /* this should go into ->truncate */ is there and very
confusing - what should go into ->truncate?

Regards,
Tigran

-
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: Small bugfix in ext2/namei.c

[Andreas Dilger]

Theodore Ts'o writes:
> Dr. Michael Weller writes:
> >  Sorry, I've no idea about the ext2 and fs implementation.
> >  However did you read the comment below and convince yourself that 'err' is
> >  always set correctly?
> 
> I looked at it and was convinced.

Ted and I submitted patches to this effect some months ago after I went
through all of the code paths for ext2_new_inode(), and I even thought
we removed all the comments about ext2_new_inode() not setting err.  See
thread http://kernelnotes.org/lnxlists/linux-kernel/lk_0005_05/msg00090.html
for more information.

It looks like it made it into test1-ac4 but was lost in test2...  Some of
the older patch is now irrelevant because ext2_getblk() was rewritten, so
here is a newer version of the patch to fix the error return codes.

Ted, please have a look (it is basically the same as the old patch), and
send it on to Linus.

Cheers, Andreas
 cut here 
diff -u linux/fs/ext2/balloc.c~ linux/fs/ext2/balloc.c
--- linux/fs/ext2/balloc.c~ Mon May 29 20:05:45 2000
+++ linux/fs/ext2/balloc.c  Fri Sep 01 13:42:21 2000
@@ -470,10 +470,8 @@
if (i >= sb->u.ext2_sb.s_groups_count)
i = 0;
gdp = ext2_get_group_desc (sb, i, );
-   if (!gdp) {
-   *err = -EIO;
-   goto out;
-   }
+   if (!gdp)
+   goto io_error;
if (le16_to_cpu(gdp->bg_free_blocks_count) > 0)
break;
}
diff -u linux/fs/ext2/ialloc.c~ linux/fs/ext2/ialloc.c
--- linux/fs/ext2/ialloc.c~ Mon May 29 20:05:45 2000
+++ linux/fs/ext2/ialloc.c  Fri Sep 01 13:42:21 2000
@@ -286,8 +286,7 @@
es = sb->u.ext2_sb.s_es;
 repeat:
gdp = NULL; i=0;
-   
-   *err = -ENOSPC;
+
if (S_ISDIR(mode)) {
avefreei = le32_to_cpu(es->s_free_inodes_count) /
sb->u.ext2_sb.s_groups_count;
@@ -369,6 +368,7 @@
if (!gdp) {
unlock_super (sb);
iput(inode);
+   *err = -ENOSPC;
return NULL;
}
bitmap_nr = load_inode_bitmap (sb, i);
@@ -416,9 +416,8 @@
ext2_error (sb, "ext2_new_inode",
"Free inodes count corrupted in group %d",
i);
-   unlock_super (sb);
-   iput (inode);
-   return NULL;
+   /* If we continue recover from this case */
+   gdp->bg_free_inodes_count = 0;
}
goto repeat;
}
@@ -429,6 +428,7 @@
"block_group = %d,inode=%d", i, j);
unlock_super (sb);
iput (inode);
+   *err = -EIO; /* Should never happen */
return NULL;
}
gdp->bg_free_inodes_count =
diff -u linux/fs/ext2/inode.c~ linux/fs/ext2/inode.c
--- linux/fs/ext2/inode.c~  Sun Mar 26 21:34:49 2000
+++ linux/fs/ext2/inode.c   Mon May 29 10:36:34 2000
@@ -117,7 +117,7 @@
inode->u.ext2_i.i_prealloc_count--;
ext2_debug ("preallocation hit (%lu/%lu).\n",
++alloc_hits, ++alloc_attempts);
-
+   *err = 0;
} else {
ext2_discard_prealloc (inode);
ext2_debug ("preallocation miss (%lu/%lu).\n",
@@ -606,13 +606,11 @@
 struct buffer_head * ext2_getblk(struct inode * inode, long block, int create, int * 
err)
 {
struct buffer_head dummy;
-   int error;
 
dummy.b_state = 0;
dummy.b_blocknr = -1000;
-   error = ext2_get_block(inode, block, , create);
-   *err = error;
-   if (!error && buffer_mapped()) {
+   *err = ext2_get_block(inode, block, , create);
+   if (!*err && buffer_mapped()) {
struct buffer_head *bh;
bh = getblk(dummy.b_dev, dummy.b_blocknr, inode->i_sb->s_blocksize);
if (buffer_new()) {
@@ -940,8 +938,23 @@
raw_inode->i_file_acl = cpu_to_le32(inode->u.ext2_i.i_file_acl);
if (S_ISDIR(inode->i_mode))
raw_inode->i_dir_acl = cpu_to_le32(inode->u.ext2_i.i_dir_acl);
-   else
+   else {
raw_inode->i_size_high = cpu_to_le32(inode->i_size >> 32);
+   if (inode->i_size >> 31) {
+   struct super_block *sb = inode->i_sb;
+   struct ext2_super_block *es = sb->u.ext2_sb.s_es;
+   if (!(es->s_feature_ro_compat & 
+cpu_to_le32(EXT2_FEATURE_RO_COMPAT_LARGE_FILE))) {
+   /* If this is the first large file
+* created, add a flag to the superblock
+* SMP Note: we're currently protected by the
+* big kernel lock here, so this will need

Re: 2.4.0-test8-pre1 is quite bad

[Rik van Riel]

On Fri, 1 Sep 2000, Chris Evans wrote:
> On Fri, 1 Sep 2000, Rik van Riel wrote:
> > On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> > 
> > > Any of you tried copying a 2G file in the same (ext2)
> > > filesystem? It starts swapping like mad and generally behaves
> > > indecently, despite the huge 1024M of RAM it has.
> > 
> > http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
> > 
> > I'm working on these issues and seem to be pretty close
> > to having fixed most of them now...
> 
> Got any of the standard benchmarks (bonnie?) for us to drool over? :-)

On my (puny) test system, sequential output with bonnie increased
from 3.5MB/s to 5MB/s.

But of course this doesn't really mean much. Also, IMHO the
important thing is that the machine stays perfectly usable
during the bonnie run.

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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/

[patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1)

[Rasmus Andersen]

Hi.

AFAICS, the line removed below is redundant. Comments?

--- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
+++ linux/mm/memory.c   Fri Sep  1 22:00:16 2000
@@ -986,7 +986,6 @@
 out_unlock:
spin_unlock(>i_shared_lock);
/* this should go into ->truncate */
-   inode->i_size = offset;
if (inode->i_op && inode->i_op->truncate)
inode->i_op->truncate(inode);
return;

-- 
Rasmus([EMAIL PROTECTED])

"Science is like sex: sometimes something useful comes out, but that 
is not the reason we are doing it" -- Richard Feynman 
-
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

[Chris Evans]

On Fri, 1 Sep 2000, Rik van Riel wrote:

> On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> 
> > Any of you tried copying a 2G file in the same (ext2)
> > filesystem? It starts swapping like mad and generally behaves
> > indecently, despite the huge 1024M of RAM it has.
> 
> http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
> 
> I'm working on these issues and seem to be pretty close
> to having fixed most of them now...

Got any of the standard benchmarks (bonnie?) for us to drool over? :-)

Cheers
Chris

-
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: 512 byte magic multiplier (was: Large File support and blocks)

[Theodore Y. Ts'o]

   From: Daniel Phillips <[EMAIL PROTECTED]>
   Date:Fri, 01 Sep 2000 20:49:14 +0200

   Curiously, this field is measured in 512 byte units, giving a 2TB Ext2
   filesize limit.  That's starting to look uncomfortably small - I can
   easily imagine a single database file wanting to be bigger than that. 
   One way to fix this would be to add a superblock flag indicating that
   this field is to be interpreted in units of filesystem blocks.

We can do that as part of adding support for larger blocksizes, sure.  

Although at the moment, the block device layer is caps the entire
filesystem to 2TB anyway, so I'm not losing any sleep over this.  The
block device layer badly needs a rototilling, which is a 2.5 project.
(And sct has said that he would do it, in front of numerous witnesses.
Sucker.  :-)

- Ted

-
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: Press release - here we go again!

[TimO]

Daniel Stone wrote:
> 
> Gidday!
{SNIP}
>-> Multimedia
>   * Faster multimedia with specially designed video acceleration drivers. In 
>combination with the new release of the X Windows System, Linux includes drivers to 
>take full advantage of your accelerated video card (nVidia and 3Dfx cards among those 
>supported) to get maximum video performance for gaming, graphics, etc.

Actually it seems that hardware acceleration for nVidia cards has
momentarily
died with the loss of MAP_NR in page[cache].h.  NVidia only claims to 
support 2.2.x kernels.  If updated drivers do exist, I would definitely
love to hear about them.

--- Tim

{SNIP}
-
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

[Mark Hahn]

> > Any of you tried copying a 2G file in the same (ext2)
> > filesystem? It starts swapping like mad and generally behaves
> > indecently, despite the huge 1024M of RAM it has.
> 
> http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2

this patch works very nicely.  it's still a little timid at 
swapping out truely idle pages, but is otherwise a major improvement.
I hope Linus takes it, since unpatched, 2.4 VM has some rough edges.

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

anyone international patches merged with rh kernel rpm?

[Jeremy Hansen]

I'm looking for anyone that has merged the international crypto patches
with Red Hat kernel rpm's.  

I've basically gotten the patch to apply cleanly, but then the build
completely fails during module building.  I don't have the know how to fix
things.

Thanks for any information.

I'm currently using H.J. Lu's rpm's from:

http://ftp.valinux.com/pub/support/hjl/redhat/6.2/SRPMS/

Thanks
-jeremy

-
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: [NFS] [PATCH] Re: grow_inodes: inode-max limit reached - how to find/fix the inode leak?

[Michael Riepe]

On Fri, Sep 01, 2000 at 11:40:31AM +0200, Trond Myklebust wrote:
[...]
>  > nlm_release_file() *does* grab the semaphore.  That's the
>  > problem.
> 
> Which is why I'm proposing a solution: to split it into 2 functions.
>1st function does the semaphore manipulations and calls
>2nd function which does the f_count--, nlm_delete_file()...
> 
> The second function can be called by any other creature already
> holding the semaphore to safely decrement f_count. That way we don't
> fill the lockd stuff with loads of different routines that may end up
> doing --f_count wrongly (like put_file(file, 0); will do).

Heck no, it won't.  I had `put_file(file, 1);' in nlmsvc_traverse_shares()
before, and it complained.

Have you looked at put_file() close enough?  It's an inline function,
and it's basically `--f_count' plus my paranoia.  Again, feel free to
remove it and simply decrement f_count if you like that better.  Or put
all f_count manipulations into a pair of new functions.  But please
stop arguing with me -- I only found the bug, fixed it, reported it,
and now I will say good-bye and move on.  I guess Linus & others are
already becoming bored... sorry for that.

>  > Adding or removing blocks or locks does not affect f_count at
>  > all.  There ist one function that changes f_count when it
>  > removes a block, but it is never called, at least not in 2.2.x.
> 
> Look again. With exception of nlmsvc_proc_null(), every single call to
> a nlmsvc_proc_*() routine will do nlmsvc_lookup_file() which does
> change f_count.

Yes, but the call to nlm_release_file() on return from nlmsvc_proc_*()
will decrement it again.  In lockd's main event loop, no changes are
visible unless you add or remove a share.

> In any case, the point is we don't want to have loads of different
> routines doing the work of nlm_release_file(). That's going to give
> rise to unnecessary maintenance issues whenever we want to make
> changes.

Who is "we"?

Excuse me, but lockd is so full of `maintenance issues' (*cough*) that I
would never have touched it if there hadn't been this bug.  Maybe that's
the reason why the bug has been there for such a long time and nobody
cared to fix it, although there has been at least one report 5 months ago.

Did I hear `thank you'?

Ciao,
-- 
 Michael "Tired" Riepe <[EMAIL PROTECTED]>
 "All I wanna do is have a little fun before I die"
-
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: Large File support and blocks.

[Matthew Jacob]

> > 
> > Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back
> > at Auspex in '93. ...Guess the compiler driver has gotten smarter since.
> > You know how it goes- you do a trick once- you don't change it for years...
> 
> According to the ChangeLog of the 2.7.2.3 compiler, Doug Evans added it in
> March of 1995.

ow. ow. ow. Okay. got 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: Large File support and blocks.

[Michael Meissner]

On Fri, Sep 01, 2000 at 12:01:39PM -0700, Matthew Jacob wrote:
> > 
> > Or use --print-libgcc-file-name:
> > 
> > `gcc  --print-libgcc-file-name`
> > 
> > where  are the options normally used to compile code (ie, for example
> > on machines that optionally do not have a floating point use, adding
> > -msoft-float would select the libgcc.a that was compiled with -msoft-float).
> 
> Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back
> at Auspex in '93. ...Guess the compiler driver has gotten smarter since.
> You know how it goes- you do a trick once- you don't change it for years...

According to the ChangeLog of the 2.7.2.3 compiler, Doug Evans added it in
March of 1995.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
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: Large File support and blocks.

[Matthew Jacob]

> 
> Or use --print-libgcc-file-name:
> 
>   `gcc  --print-libgcc-file-name`
> 
> where  are the options normally used to compile code (ie, for example
> on machines that optionally do not have a floating point use, adding
> -msoft-float would select the libgcc.a that was compiled with -msoft-float).

Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back
at Auspex in '93. ...Guess the compiler driver has gotten smarter since.
You know how it goes- you do a trick once- you don't change it for years...

> 
> > That is, unless somebody wants to write the support functions (specific to
> > gcc, ah, but which one?) into the linux kernel? Oh dear, I don't think so..
> 
> Other than division, most of the 64 bit support functions are fairly easy to
> write.  Obviously, if you do this and gcc 7.0 changes the interface to call
> different functions, you are hosed.

That's the point. The support routines are paired with the compiler, not the
kernel. And the support routines have to be able to link with the
kernel. Having 20 different kernel platforms duplicate code already in
libgcc.a is silly unless the code in libgcc.a is so bad for the kernel that
you have to do otherwise.

-matt


-
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 2.2.18pre2

[Albert D. Cahalan]

Alan Cox writes:

> o Make vfat use the same generation rules as  (H. Kawaguchi,
>   in windows 9xChip Salzenberg)

I doubt this is obviously correct. The last time this issue
came up, it was discovered that Windows 9x does not use the
same generation rules as Windows NT.

Consider that Microsoft has been trying to kill Windows 9x
for the last half dozen years, one might prefer the NT method.
With config.sys and autoexec.bat being ignored by the Windows
Millennium Edition, the transition seems to be making progress.
-
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: Large File support and blocks.

[Michael Meissner]

On Fri, Sep 01, 2000 at 10:34:19AM -0700, Matthew Jacob wrote:
> > On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote:
> > > So what do you propose to use when a long long division is needed (after
> > > much thought and considering all alternatives etc.etc.) ? 
> > 
> > Link against libgcc, what else?
> 
> As also does anyone who does solaris drivers (x86 or sparc) using gcc- the
> code that gcc emits that requires 64 bit operations is quite nicely available
> in libgcc.a. Only a minor bit of hackage with gcc -v is needed in a makefile
> to emit the correct path for the linker to use.

Or use --print-libgcc-file-name:

`gcc  --print-libgcc-file-name`

where  are the options normally used to compile code (ie, for example
on machines that optionally do not have a floating point use, adding
-msoft-float would select the libgcc.a that was compiled with -msoft-float).

> That is, unless somebody wants to write the support functions (specific to
> gcc, ah, but which one?) into the linux kernel? Oh dear, I don't think so..

Other than division, most of the 64 bit support functions are fairly easy to
write.  Obviously, if you do this and gcc 7.0 changes the interface to call
different functions, you are hosed.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
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

[Rik van Riel]

On Fri, 1 Sep 2000, Tigran Aivazian wrote:

> Any of you tried copying a 2G file in the same (ext2)
> filesystem? It starts swapping like mad and generally behaves
> indecently, despite the huge 1024M of RAM it has.

http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2

I'm working on these issues and seem to be pretty close
to having fixed most of them now...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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: To many Oops

[Albert D. Cahalan]

>  address 68736170
>  address 33312051
>  address 3331203d

The kernel is using ASCII text as pointers. Convert the above:

"pash"
"Q 13"
"= 13"

Try different kernels and different compilers.
The hardware is probably OK.
-
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/