'(none)'

'(none)'

Post by Jim Sible » Sat, 14 Sep 2002 06:50:06



Quote:>Only if you assume that a bunch of users tries very hard to use up all the

resources...

Not true. A sudden surge in legitmate traffic can stretch the limits
unwittingly or a new legitmate appliation can stretch the limits in an
unexpected way. If there is such a surge, who has priority?

I have cause similar random behaviour 1) if I have a lot users doing little
things, 2) a few big users doing big things, 3) a  mix of users doing
various things or 4) one  users doing bad things. And in any of the cases,
I have no say in whose going to get killed.

And I don't have to try very hard and I don't have to be the super user.

Regards, Jim
Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs

*** Grace Happens ***

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

'(none)'

Post by Paolo Ciarrocch » Sun, 15 Sep 2002 21:50:05


[...]

Quote:>http://kernel.kolivas.net under the FAQ. A final >reminder note: it won't work on
>2.5.x

Con,
I think that only the _memload_ test is not
working with 2.5.*, am I wrong?

Paolo
--
Get your free email from www.linuxmail.org

Powered by Outblaze
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

'(none)'

Post by Con Koliva » Sun, 15 Sep 2002 22:00:09



Quote:> [...]
> >http://kernel.kolivas.net under the FAQ. A final >reminder note: it won't
> work on
> >2.5.x

> Con,
> I think that only the _memload_ test is not
> working with 2.5.*, am I wrong?

Correct. memload determines the amount of memory to allocate based on
/proc/meminfo which has changed in 2.5.x

Thanks for doing the 2.5.34 tests. They are promising results.

Con.

P.S. How does 2.4.19-ck7 compare ;-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

'(none)'

Post by Rik van Rie » Mon, 16 Sep 2002 02:10:10



> I think that only the _memload_ test is not
> working with 2.5.*, am I wrong?

You're right, the memload test doesn't work with 2.5 but
needs the following patch...

Rik
--
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/             http://distro.conectiva.com/


--- contest-0.1/mem_load.c.orig 2002-09-13 23:36:47.000000000 -0400

   switch (type) {

   case 0: /* RAM */
-    if ((position = strstr(buffer, "Mem:")) == (char *) NULL) {
-      fprintf (stderr, "Can't parse \"Mem:\" in /proc/meminfo\n");
+    if ((position = strstr(buffer, "MemTotal:")) == (char *) NULL) {
+      fprintf (stderr, "Can't parse \"MemTotal:\" in /proc/meminfo\n");
       exit (-1);
     }
-    sscanf (position, "Mem:  %ul", &size);
+    sscanf (position, "MemTotal:  %ul", &size);
     break;

   case 1:
-    if ((position = strstr(buffer, "Swap:")) == (char *) NULL) {
-      fprintf (stderr, "Can't parse \"Swap:\" in /proc/meminfo\n");
+    if ((position = strstr(buffer, "SwapTotal:")) == (char *) NULL) {
+      fprintf (stderr, "Can't parse \"SwapTotal:\" in /proc/meminfo\n");
       exit (-1);
     }
-    sscanf (position, "Swap: %ul", &size);
+    sscanf (position, "SwapTotal: %ul", &size);
     break;

   }

-  return (size / MB);
+  /* convert from kB to MB */
+  return (size / KB);

 }

--- contest-0.1/mem_load.h.orig 2002-09-14 11:09:28.000000000 -0400

 #define MAX_BUF_SIZE 1024          /* size of /proc/meminfo in bytes */
 #define MB (1024 * 1024)           /* 2^20 bytes */
+#define KB 1024
 #define MAX_MEM_IN_MB (1024 * 64)  /* 64 GB */

 /* Tuning parameter.  Increase if you are getting an 'unreasonable' load

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

'(none)'

Post by Paolo Ciarrocch » Mon, 16 Sep 2002 03:30:09




> > [...]
> > >http://kernel.kolivas.net under the FAQ. A final >reminder note: it won't
> > work on
> > >2.5.x

> > Con,
> > I think that only the _memload_ test is not
> > working with 2.5.*, am I wrong?

> Correct. memload determines the amount of memory to allocate based on
> /proc/meminfo which has changed in 2.5.x

Rik has a pacth for this (thanks ;-).
Let me know when you are going to release a new version of the benchmark.

[...]

Quote:> P.S. How does 2.4.19-ck7 compare ;-)

Downloaded, compiled and tested ;-)
BTW, I tested also the latest compressed cache patch.

_NOLOAD_
Kernel          Time            CPU
2.4.19          7:37.99         99%
2.5.34          7:47.68         99%
2.4.19-0.24pre4 7:38.17         99%
2.4.19-ck7      7:35.54         99%

_CPULOAD_
Kernel          Time            CPU
2.4.19          9:07.80         82%
2.5.34          8:50.56         87%
2.4.19-0.24pre4 9:07.61         82%
2.4.19-ck7      8:38.07         87%

_IOLOAD_
Kernel          Time            CPU
2.4.19          11:23.86                65%
2.5.34          10:48.24                72%
2.4.19-0.24pre4 11:51.79                63%
2.4.19-ck7      10:41.56                71%

_MEMLOAD_
Kernel          Time            CPU
2.4.19          10:00.63        78%
2.5.34          [7:45.80]       [99%]
2.4.19-0.24pre4 10:37.85        78%
2.4.19-ck7      10:46.06        72%

Ciao,
         Paolo
--
Get your free email from www.linuxmail.org

Powered by Outblaze
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

'(none)'

Post by PRINCESS VIVIAN INYEKWER » Thu, 19 Sep 2002 21:20:05


ATTN: INTRODUTION I am Princess Vivian Onyekwere, daughter of Chief Oti Onyekwer, the king of Ogoni Kingdom. Iam 25 Years old and a graduate of Mass Communication. My Father was the king of Ogoni Kingdom the highest oil Producing area in Nigeria. He was in charge of Reviving royalties from the multi-national oil Companies and government on behalf of the oil Producing communities in Nigeria. After the* of The Ogoni Nine (9) including Ken Saro Wiwa by the late Dictator General Sani Abacha, my father suffered Stroke and died November 15th lastyear. But before his death, he called me and told me he has twenty Three Million Five Hundred and Sixty Thousand Dollars(USD23,560,000.00) cash in his Possession, Specially deposited in a Security company here. He advised me not to tell anybody except my mother who is the last wife of the (8) eight wives that he married. My mother did not bear any male child for him. Which implies that all my fathers' properties, companies' e.t.c, we have no share in them because my mother has No male child according to African Tradition. My father there fore secretly gave me all the relevant Documents of the said money, and told me that I should Use this money with my mother and my younger sisters Because he knows that traditionally, if he dies we Cannot get anything, as inheritance. He importantly Advised me that I should seek foreign assistances and that I should not invest this money here in Nigeria Because of his other wives and male children who happen to be my elders. I am soliciting for your immediate assistance to get a bungalow for us, wherein Will live with my mother and two younger sisters and Further advise me where and how I will invest the balance money overseas, possibly on products of your Company and other profitable ventures. I believe that by the special grace of God, you will help us move this money out of Nigeria to any country of your Choice where we can invest this money judiciously with you. You are entitled to a reasonable part of this Money based on our agreement, and God will bless you as you help us. Please reply through my e-mail Looking Forward to hear from you as soon as possible. Best regard,

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

'(none)'

Post by Mala Anan » Sat, 21 Sep 2002 08:00:09


Andrew Morton wrote ...

Quote:>It seems that movsl works acceptably with all alignments on AMD
>hardware, although this needs to be checked with more recent machines.
>movsl is a (bad) loss on PII and PIII for all alignments except 8&8.
>Don't know about P4 - I can test that in a day or two.
>I expect that a minimal, 90% solution would be just:
>fancy_copy_to_user(dst, src, count)
>{
>        if (arch_has_sane_movsl || ((dst|src) & 7) == 0)
>                movsl_copy_to_user(dst, src, count);
>        else
>                movl_copy_to_user(dst, src, count);
>}
>and
>#ifndef ARCH_HAS_FANCY_COPY_USER
>#define fancy_copy_to_user copy_to_user
>#endif
>and we really only need fancy_copy_to_user in a handful of
>places - the bulk copies in networking and filemap.c. For all
>the other call sites it's probably more important to keep the
>code footprint down than it is to squeeze the last few drops out
>of the copy speed.
>Mala Anand has done some work on this. See
>http://www.uwsg.iu.edu/hypermail/linux/kernel/0206.3/0100.html
><searches> Yes, I have a copy of Mala's patch here which works
>against 2.5.current. Mala's patch will cause quite an expansion
>of kernel size; we would need an implementation which did not
>use inlining. This work was discussed at OLS2002. See
>http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz

I will move the code from uaccess.h (inline) to usercopy.c (routine)
and will post it soon. It is in my list of things to do.

Regards,
    Mala

   Mala Anand
   IBM Linux Technology Center - Kernel Performance

   http://www-124.ibm.com/developerworks/opensource/linuxperf
   http://www-124.ibm.com/developerworks/projects/linuxperf
   Phone:838-8088; Tie-line:678-8088

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

'(none)'

Post by Greg K » Sun, 22 Sep 2002 14:40:05


cgl_discuss...@lists.osdl.org, hardeneddrivers-disc...@lists.sourceforge.net
Cc:
Bcc:
Subject:
Reply-To:

hardeneddrivers-disc...@lists.sourceforge.net,
cgl_discuss...@lists.osdl.org
Bcc:
Subject: my review of the Device Driver Hardening Design Spec
Reply-To:
In-Reply-To: <20020921014054.GA25665@kroah.com>

On Fri, Sep 20, 2002 at 06:40:54PM -0700, Greg KH wrote:
> Hi,

> I've just started to read over the published spec, and will reserve
> comment on it, and the example code you've created after I'm done
> reading it.

Ok, here's some comments on the 0.5h release of the Device Driver
Hardening Design Specification:

(I'll skip the intro, and feel good sections and get into the details
that you lay out, starting in section 2)

Section 2:
2.1:
        - do NOT use /proc for driver info.  Use driverfs.
        - If you are using a kernel version that does not have driverfs,
          put all /proc driver info under /proc/drivers, which is where
          it belongs.
        - Only have 1 value per file, and no binary data in the files.
        - Do not put the "kernel version for which the driver was
          compiled", as that _always_ much match the kernel version that
          is running, so is redundant.

2.2:
        - do NOT use typedef

2.5.5:
        - you do not have to always check data returned from functions,
          if you wrote the functions in the first place.  Redundant
          checking of all data within the kernel, slows things down.
          Sure, some checking is good, but do not say that it is a
          requirement, or no one will want to use your driver.

The majority of section 2 is very nice, it's a good list of things that
drivers should do.

Section 3:

Wow, where to start...

The Common Statistic Manager:
        - why does this have to live in the kernel?  It should be in
          userspace, grabbing all of the data from the /proc files you
          just specified in section 2.1.

POSIX event logging:
        - wow, not much I can say here, that hasn't already been said
          before :(

Diagnostics:
        - now these are a good idea.  A common subsystem that drivers
          can register what kind of diagnostics they can run on their
          hardware, nice.

3.1.1:
        - UUIDs!!!???  You have got to be kidding.  Here, for the
          benefit of those who have not read this, I'll quote:
                "Each subsystem, and each resource contained within each
                subsystem, needs to be uniquely identified.  In order to
                do this a hardened driver developer shall pre-assign a
                Universally Unique Identifier (UUID) as the Subsystem ID
                for each subsystem, and shall provide a means to assign
                a unique Resource ID string for each resource within a
                subsystem."

         So for every resource, a string shall be associated with it.
         But that means for most resources, the string will take up more
         memory than the resource itself does.  Does that make sense?

         It's also up to the driver to create these resource ids at
         runtime and guarantee their uniqueness over the lifetime of the
         kernel.  How in the world can you expect every driver author to
         do this?  Any example code out there?

         And what are these UUIDs going to be used for, ah, event
         logging.  Enough said.

3.2 Statistics:
        You actually want every driver to support SNMP compliant
        statistics groups within themselves?  Why?  What a bloat of a
        kernel.

        All of this should be done (if at all) from userspace.

3.2.5.2:
(I'm not condoning ANY of these functions or code, just trying to point out how
you should, if they were to be in the kernel, done properly.)
        - do not use typedef
        - struct stat_info does not need *unit, as that is already
          specified in the scale field, right?
        - the stat_value_t union is just a horrible abomination, don't
          do that.

3.3 Diagnostics:
        - not a bad idea, but some work could be done on the
          implementation.  Would fit in nicely with the device driver
          model in 2.5.  For 2.4, it would be another subsystem a driver
          would register with.

3.3.3.2:
        - no typedefs
        - run() is horrible, you are trying to fit all kinds of possible
          diagnosis into one function callback.  Not a good idea.
          Break the different kinds of callbacks out into different
          functions.  That ensures type safety, right now you are just
          creating another ioctl() type mess.

3.4 Event logging:
        - I'm not even going to touch this, sorry.

4: High Availability
        - are you all working with the existing HA group?

4.1:
        - um, what are you trying to say here.  This section is
          pointless.  Yes we all think Hot Swap is a good idea, that's
          why Linux currently supports it.

4.2:
        - RAID and ethernet bonding is nice. Again, Linux already has
          projects and support for these things.  Why mention them?

The rest of this section is fine, and I welcome any test harnesses that
are created to do this kind of fault injection for driver testing.

5:
        - Here you back-pedal on everything you said up till now.  Let
          me summarize what is said in these 3 paragraphs in 1 sentence:
                "Yes, all these things are well and good, but don't let
                them effect the currently great performance Linux has
                today."
          Sorry, but you can't have it both ways.

5.1:
        - do NOT use #ifdef in the .c files.  Only in .h files.
        - why is CONFIG_DRIVER_HOTSWAP an option.  What does it do that
          CONFIG_HOTPLUG does not do today?
        - actually, what do any of these CONFIG_ options do, and why
          would someone not want the CONFIG_DRIVER_ROBUST to be always
          enabled?

In summary, I think that a lot of people have spent a lot of time in
creating this document, and the surrounding code that matches this
document.  I really wish that a tiny bit of that effort had gone into
contacting the Linux kernel development community, and asking to work
with them on a project like this.  Due to that not happening, and by
looking at the resultant spec and code, I'm really afraid the majority
of that time and effort will have been wasted.

What do I think can be salvaged?  Diagnostics are a good idea, and I
think they fit into the driver model in 2.5 pretty well.  A lot of
kernel janitoring work could be done by the CG team to clean up, and
harden (by applying the things in section 2) the existing kernel
drivers.  That effort alone would go a long way in helping the stability
of Linux, and also introduce the CG developers into the kernel community
as active, helping developers.  It would allow the CG developers to
learn from the existing developers, as we must be doing something right
for Linux to be working as well as it does :)

Also, open specs for the hardware the CG members produce, to allow
existing kernel drivers to be enhanced (instead of having to be reverse
engineered), and new kernel drivers to be created, would also go a long
way in helping out both the CG's members and the entire Linux
community's cause of having a robust, stable kernel be achived easier.
Closed specs, and closed drivers do not help anyone.

thanks for reading this far,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

'(none)'

Post by Andrew Rodlan » Mon, 23 Sep 2002 08:30:08


unsubscribe linux-kernel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

'(none)'

Post by Patrick Moche » Wed, 25 Sep 2002 03:40:07


In general, I agree completely with what Greg says (as usual), but I do
have a few additional comments.

Quote:> (I'll skip the intro, and feel good sections and get into the details
> that you lay out, starting in section 2)

> Section 2:
> 2.1:
>    - do NOT use /proc for driver info.  Use driverfs.
>    - If you are using a kernel version that does not have driverfs,
>      put all /proc driver info under /proc/drivers, which is where
>      it belongs.

Actually, they mention using driverfs in Section 3: Instrumentation. I
can't tell if this was around before, or this was just added. The date is
the same (16 Aug), but there is no changelog information about the spec.

I would suggest not using procfs at all, even if driverfs is not avaiable.  
If you're using 2.4, backport driverfs, or clone it for your own
filesystem. It's not dependent on the driver model at all, and has been
done at least once before (Greg's pcihpfs).

Quote:> Section 3:
> The Common Statistic Manager:

Please drop the term 'Manager' from your nomenclature. It is ambiguous,
because of the context in which its generally used in. Windows uses the
term for any collection of kernel or device data and/or kernel policy.
It's not a bad term, but it fails to make a clear distinction between
kernel space and user space, which we insist on.

Only the mechanism for setting the policy should exist in the kernel, and
itself my be very intelligent. But, the policy itself should exist outside
of the kernel.

Quote:> 3.2.5.2:
> (I'm not condoning ANY of these functions or code, just trying to point out how
> you should, if they were to be in the kernel, done properly.)
>    - do not use typedef
>    - struct stat_info does not need *unit, as that is already
>      specified in the scale field, right?
>    - the stat_value_t union is just a horrible abomination, don't
>      do that.

Please do not pass void *. You should only pass type-safe structures. If
you cannot get that information, you should redesign the API.

Quote:> 3.4 Event logging:
>    - I'm not even going to touch this, sorry.

There are a lot of topics in this spec, most of which are irrelevant to
actually hardening drivers. They may be features dependent on your APIs,
but they are completely optional and may hinder acceptance of your primary
objectives.

Event logging is definitely one of them, esp. with a function like

evl_log_event_string(  
        ME_EVENT_BUCKET_EMPTY,
        LOG_WARNING,
        "Leaky bucket exception (bucket empty):\
        Bucket_Level <= Observed_Value - Last_Value\
        |%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s\
        |%s=%u|%s=%u|%s=%u|%s=%u|%s=%u|%s=%u|",
        RMGT_FacilityIDAttrStr,         RMUUID,
        RMGT_SubsystemIDAttrStr,    SUBSYSTEM_UUID,
        RMGT_SubsystemNameAttrStr,  subsystem_name,
        RMGT_ResourceIDAttrStr,         resource_id,
        RMGT_ResourceNameAttrStr,   resource_name,
        ME_MonitorIDAttrStr,        monitor_uuid,  
        ME_StatisticIDAttrStr,         statistic_id,
        ME_StatisticNameAttrStr,    statistic_name,  
        ME_BucketSizeAttrStr,       bucketsz,  
        ME_FillValueAttrStr,            fillval,
        ME_FillIntervalAttrStr,         fillint,
        ME_BucketLevelAttrStr,      bucketlvl,
        ME_ObservedValueAttrStr,    obsval,
        ME_LastValueAttrStr,        lastval);

Quote:> In summary, I think that a lot of people have spent a lot of time in
> creating this document, and the surrounding code that matches this
> document.  I really wish that a tiny bit of that effort had gone into
> contacting the Linux kernel development community, and asking to work
> with them on a project like this.  Due to that not happening, and by
> looking at the resultant spec and code, I'm really afraid the majority
> of that time and effort will have been wasted.

I completely agree. There is definitely good intention in some aspects of
the spec, and definitely in the effort put forth to support this type of
work. But, in order to gain the support of kernel developers, or even the
blessing of a few, you should be working with them on the design from the
beginnging.

Designing APIs is hard. Doing it well is very hard. I'm not claiming I've
done a stellar job, but I have at least learned that. I've made a lot of
poor design decisions, many of which are also evident in your code
descriptions and examples. I can't tell you how many times I've rewritten
things over and over and over because someone hated them (usually Linus or
Greg).

There are people that are willing to help, as we are trying to do. But,
it's much easier if you do things gradually and get that help from the
beginning.

Quote:> What do I think can be salvaged?  Diagnostics are a good idea, and I
> think they fit into the driver model in 2.5 pretty well.  A lot of
> kernel janitoring work could be done by the CG team to clean up, and
> harden (by applying the things in section 2) the existing kernel
> drivers.  That effort alone would go a long way in helping the stability
> of Linux, and also introduce the CG developers into the kernel community
> as active, helping developers.  It would allow the CG developers to
> learn from the existing developers, as we must be doing something right
> for Linux to be working as well as it does :)

Which kernel are you targeting? I didn't see it in the spec, though I
could have easily missed it. CGL is based on 2.4, so I would assume that.
But, I would think the ideal choice would be to start in 2.5 and backport
it to 2.4.

If that's the case, how do you intend to work with the driver model?
There will be quite a bit of code and interface duplication between
your code and the driver model. I can see ways to support many of the
things you want in a relatively easy manner, and not punish the common
user or developer; but the margin is to small to write the answer... ;)

Also, there are many projects in areas similar to what your doing:
diganostics, HA, etc, etc. It would be nice to see some collaboration
between the developers of those projects instead of having many disparate
projects with similar goals.

        -pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. init: can't exec getty 'none' ...

I rebooted earlier today and now I'm getting this in my all.log:

Feb  8 17:41:25 Gandalf /kernel: Feb  8 17:41:25 init: can't exec getty
'none' for port /dev/console: No such file or directory
Feb  8 17:42:18 Gandalf /kernel: Feb  8 17:42:18 init: can't exec getty
'none' for port /dev/console: No such file or directory
Feb  8 17:42:48 Gandalf /kernel: Feb  8 17:42:48 init: can't exec getty
'none' for port /dev/console: No such file or directory

/dev/console does exist:

Gandalf# ls -l /dev/console
crw-------  1 root  wheel    0,   0 Feb  8 17:44 /dev/console

The interesting thing is when I do an strace:

Gandalf# strace -f -p1
strace: open("/proc/.../regs", ...): No such file or directory
trouble opening proc file
Gandalf# ls -a /proc/
.       163     179     190     217     263     293     306     328     4
..      165     180     191     220     264     294     307     329     5
0       167     181     2       251     274     3       322     34      curproc
1       173     184     209     260     276     300     323     387
147     176     188     211     261     285     303     324     393
159     178     189     214     262     287     305     325     395

As you can see, I don't have a "..." directory in /proc.  What could be causing
this?

Allen
--
if (length($rant) > $normal)
    s/decaf/coffee/g;
  5:40pm  up 35 days,  8:16,  1 user,  load average: 0.00, 0.00, 0.00

2. Install Software Package from Redhat 6 CD using RPM?

3. '(none)'

4. Good modem for Voice, Fax in Redhat 6.2

5. Goto

6. Wabi problem with Word for Windows 6