Linux-Development-Sys Digest #433, Volume #6     Fri, 26 Feb 99 15:14:17 EST

Contents:
  Re: monolithic kernel and source that can only be compiled as a module (Tony Hoyle)
  Re: Problem 'sync'ing Linux filesystem on i386 (Chris Wagner)
  Re: IP to process network interface? (Erik Hensema)
  Re: Raw writing to PCMCIA SRAM cards (David Hinds)
  SO_SNDTIMEO in *sockopt() ("D. Emilio Grimaldo Tunon")
  Re: Overclocking (was: Re: K6-2 and Linux, Are there any Bug?) (GBP)
  Re: Overclocking (was: Re: K6-2 and Linux, Are there any Bug?) (GBP)
  Re: Where's my core ? (Christopher Mahmood)
  RedHat install crashes -- "buggy cmd640b" error (Patrick Mueller)
  Re: SMP Support (bill davidsen)
  Re: POSIX.1 Shared mem support (bill davidsen)
  Re: /dev/zero ("John McKown")
  CPU detection module source code (Kendall Bennett)
  Re: Overclocking (was: Re: K6-2 and Linux, Are there any Bug?) ("David A. Frantz")

----------------------------------------------------------------------------

From: Tony Hoyle <[EMAIL PROTECTED]>
Subject: Re: monolithic kernel and source that can only be compiled as a module
Date: Fri, 26 Feb 1999 13:47:39 +0000

Peter A Fein wrote:

> The difference is that a kernel module crack can hide all access to
> itself by fudging lsmod's, directory listings, etc..  Replacing
> programs can be detected automatically.  Sure, that's circumventable
> too, but isn't it easier to install a single module and be done?  Of
> course, it's harder to write such module, but again, I believe it's
> been done.

Compiling a monolithic kernel doesn't help you though.  Once someone has
got root access all bets are off...  There is *nothing* you can do to
stop
them, and if they are clever enough they will cover their tracks so you
won't
know they've been there.  

Try this:

Hacker has copy of insmod, and writes own kernel module which does
something nasty.
Hacker breaks into system, does 'insmod nasty.o', then leaves, after
modifying lsmod
then changing the modtime back to the old one.

As long as insmod works, there is no way around this.

Also the whole PAM security system is modular, this is a more obvious
line of attack.
A hacker could replace the pam_pwdb.so file to allow backdoor root
logins.

Someone else has already given the best advice.  If someone gains root
access to your system,
you have no practical alternative but to wipe everything and reinstall.

Tony

====================================================================================
Linux renders ships...  NT renders ships useless.
====================================================================================
[EMAIL PROTECTED]                           http://betty.magenta-logic.com
====================================================================================

------------------------------

From: [EMAIL PROTECTED] (Chris Wagner)
Subject: Re: Problem 'sync'ing Linux filesystem on i386
Date: 26 Feb 1999 14:44:33 GMT

In article <7b4ksh$[EMAIL PROTECTED]>,
        [EMAIL PROTECTED] writes:
>[snip] 
> The problem is that when I 'shutdown -h now' the machine, it halts on
>[snip] 
> THIS HAS NOT ALWAYS BEEN THE CASE! That's whats most disturbing, shutdown
> was fine for about 2 weeks, then this problem. When I startup, it then
> reports that the Linux partition was not correctly shutdown and checks it.
> 

I suspect hardware problems.  Check the HD cables.  The HD may be dying.

-- 
Recreational Calculus - Just For Fun!
P.S. "From" header is bogus, use below email address.
--
Chris Wagner
[EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED] (Erik Hensema)
Crossposted-To: comp.os.linux.networking
Subject: Re: IP to process network interface?
Date: Thu, 25 Feb 1999 15:06:51 +0100
Reply-To: [EMAIL PROTECTED]

Phil Howard wrote:
>Is there a way to get an IP network interface into the kernel so
>that the kernel can operate on it as any network interface, but
>have the interface really connect via a process on that machine?

I've never used it, so it meight not work, but try the kernel/user netlink
socket found in 2.2.

-- 
Erik Hensema ([EMAIL PROTECTED])

------------------------------

From: [EMAIL PROTECTED] (David Hinds)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.portable
Subject: Re: Raw writing to PCMCIA SRAM cards
Date: 26 Feb 1999 17:34:51 GMT

Mark Smith ([EMAIL PROTECTED]) wrote:
: 
: Seriously though, I take it I would could just copy my program to the memory
: card ie. "dd if=test.bin of=/dev/mem0c0c" or is there a nice pre-made
: program that will do it for me ?

What, "dd" isn't nice enough??

-- Dave

------------------------------

From: "D. Emilio Grimaldo Tunon" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: SO_SNDTIMEO in *sockopt()
Date: Fri, 26 Feb 1999 18:39:04 +0100

Hi,
   I was looking through the set/getsockopt() manual page and
it mentions that it supports SO_SNDTIMEO and SO_RCVTIMEO and
that it requires sys/types.h and sys/socket.h. However none
of those files, in fact no file in /usr/include defines those
values! What's wrong? is it or is it not supported? I have
Red Hat Linux 5.2 kernel 2.0.36 on an Intel machine. Solaris 
does have it... What are the alternatives?

                TIA,
                                Emilio

PS> Please copy to my email address as well.

-- 
D. Emilio Grimaldo Tunon       Compuware Europe B.V. (Uniface Lab)
Software Engineer              Amsterdam, The Netherlands
[EMAIL PROTECTED]  Tel. +31 (0)20 3126 516
*** The opinions expressed hereby are mine and not my employer's ***

------------------------------

From: GBP <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: 
alt.os.linux.slackware,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Overclocking (was: Re: K6-2 and Linux, Are there any Bug?)
Date: Fri, 26 Feb 1999 13:27:37 -0500



> 
> the only chips i hear of that can be is celeron but besides that.... the
> chip is not made to be over clocked..... if it was supposed to be over
> clocked it would RUN at THAT SPEED not 50-100 MHz slower

Its called multi tier pricing, and this isnt the only industry that does
it.  I means packaging essentially the same product two ways (or more)
one for poorer people, one for richer.  Some people will always want the
better product and a are willing to pay more, since money is no object. 
So company X can jack the price on widgets up 25% and call them super
widjets.  But other people just can't afford the super widgets, and
company X wants to sell to them too, even though they cant pay as much. 
So they sell "budget widgets". Both are just widgets made in the same
plant.  They dont want people to buy super widgets to know this, or they
wont pay extra, so they create the fiction that bugjet widgets are
somehow inferior.  Lots of people will still buy the "inferior" budget
widgets, beacuse they want widgets and thats what they can afford.  They
wish they could get super widgets but that doesnt stop them... budget
widgets are better than non at all right???

In this case intel used 18 micron technology to make Celerons .. so they
can run hotter than the older inferior 25 micron P2's.  They are
essentially dumping the celerons on the market at no profit to hurt AMD
their only real threat.  They intend to make all their money on the
"high end" PII's even though the P2's are almost exactly the same they
cost 2-4 times more!!  The P2 is the "super widget".  They developed the
18 micron manufacturing plants to make the upcoming P3 and beyond, but
since the design wasnt ready yet they knocked off some Celerons while
they were waiting.

Personally i dont feel comfortable overclocking.  But i can say that i
should be almost impossible to melt a celeron due to the 18 micron
design, and low offical clock speeds.  The fast that Intel has been
trying to devolope mechanisms to stop overclocking almost proves that
its possible...  For example due to design you cant run a celeron 300A
at say 366, you have to go all the way up to 1.5x at 450mhz.. which
actually works for a lot of people i hear!  The P2-450 is like $500 a
celeron 300A at 450 is $95 :)  So lets say you burn one, your still $300
ahead if the second one works, the odds are on the hacker's side here.

------------------------------

From: GBP <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: 
alt.os.linux.slackware,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Overclocking (was: Re: K6-2 and Linux, Are there any Bug?)
Date: Fri, 26 Feb 1999 14:00:46 -0500



Michael Creasy wrote:
> 
> If this is the case can someone tell me why my K6-2 350 when overclocked
> to 400 crashes linux on boot, it has a huge fan on it.
> 


Its because of the way chips are made.  Tehy are made from 1.5 foot
diameter wafers then cut, then tested.  The company doesnt say "ok these
are going to be p2-350's and these here will be p2-400's" what they do
is they make them the best they can and then cross their fingers.  Lets
say a batch has 12 dies (chips)  a typical yiled might be something like
this:

defective
p2-388
p2-478
defective
p2-312
defective
p2-444
p2-451
defective
defective
p2-398
p2-377

they test them to see, first if they work, second how fast they work.

Now intel has these chips:


p2-312
p2-377
p2-388
p2-398
p2-444
p2-451
p2-478

otherwise known as

p2-300
p2-350
p2-350
p2-350
p2-400
p2-450
p2-450

Now technically speaking all these chips cost the same to make, but they
arent going to charge you the same amoung of money-- some are better
than others.

Say intel has lots of 350s and just a few 300's.  Now lets say their are
a lot of people that just want the cheapest p2 they can get for their
budget pcs-- which makes sense.  inetl sells p2-300s for $100 and p2-350
for $125 (fake numbers).   A lot of people say , i dont care if its only
$25 more i want the slowest one, its only going to be about 15% faster
anyway... So they have lots of orders for 300's but few for 350s.  They
take lots of those 350s and mark them as 300s! So you can "over clock'
then safely... because intel "under clocked" before.  

__BUT__  One of those things really was a p2-300 wasnt it-- a p2-312
actaully.  And when you over clock that one it will burn out or crash.


There MUST be some p2-300's that really are only 300's or intel would
just sell p2-350's as their slowest chip... One the other hand most
300's are really going to be faster than 300 because the average is
probably around 375.

gbp

------------------------------

From: Christopher Mahmood <[EMAIL PROTECTED]>
Subject: Re: Where's my core ?
Date: Fri, 26 Feb 1999 11:09:46 -0800

your shell is probably set to limit core dumps to Ok...put 'ulimit -c
XXX' in a startup file (such as .bashrc).
-ckm

------------------------------

From: Patrick Mueller <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.setup
Subject: RedHat install crashes -- "buggy cmd640b" error
Date: Thu, 25 Feb 1999 16:25:51 -0600
Reply-To: [EMAIL PROTECTED]

Hello, TIA for your help -- nothing like having a hardware problem you can't
figure out... :)

I am trying to install RedHat 5.2 on a system I inherited. It is a (gasp!)
Packard Bell Model 3960CD; a P60 with 40MB RAM. I have disconnected the
proprietary CDROM, and hooked up a spare IDE (Panasonic 24x, I don't have the
model number here). They are both on the PCI IDE port: the 4.3GB HD as master,
the CD as slave. [I should add that I also upgraded the 400MB HD to the 4.3GB].

The problem happens during the booting of the kernel on the RedHat boot disk.
Doing a 'strings' on the boot image, it looks like it is using kernel v2.036,
and I'm not sure what the "SYSLINUX" refers to; is that a RedHat component?
Here's the relevant output:
- SYSLINUX 1.40 1998-05-07
- BOOT_IMAGE=07 Linux 2.0

The kernel loads fine w/ only the HD, but once the CD is attached to the chain,
the crash occurs. I have also tried a different CDROM (Creative 32x), but it
still crashes. Unfortunately, the other IDE connector is so badly placed, that
it and the floppy connector cannot both be used at the same time; so I can't
test if the "PCI IDE" connector is bad.

The only other thing I can think of is to see if the RedHat install supports the
proprietary CD which originally came w/ the box (I think it was a Panasonic).
Unfortunately, I pulled that out and left that in another state; who knew I'd be
longing for a *proprietary* CDROM! So I can't try that (without having it
shipped to me, which is a possibility).

Anyway, here's the guts of the problem -- I hope there's a guru out there who
can help me with this. The dump goes like this:

ide0: buggy cmd640b interface on PCI(type 2) config=0x3e
ide1: not serialized, secondary interface not responding
cmd640: drive 0 timings/prefetch(on) preserved, clocks=2/3/3
cmd640: drive 1 timings/prefetch(on) preserved, clocks=4/16/17
divide error: 0000

CPU: 0
EIP: 0010:[<0016f2d5>]
EFLAGS: 0010246

<dump of the registers>

Code: f7 74 24 0c 89 c1 66 89 4b 20 8b 7e 78 80 4b 0c 40 0f b6 43


I am checking w/ PBell, to see if there is a BIOS upgrade I can get to see if
that will help, but I am not confident that they offer much support (especially
for a relatively old box like this P60).

Thanks again!! (Also, please cc: [EMAIL PROTECTED] because my news reader is
a pain to use).

        -- Patrick

------------------------------

From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: SMP Support
Date: 25 Feb 1999 22:34:06 GMT

In article <[EMAIL PROTECTED]>,
Peter Teuben  <[EMAIL PROTECTED]> wrote:

| OTOH two jobs with a healthy mix of CPU and disk I/O can step
| on each others toes and you will find that running them in
| parallel can be slower than running them jobs in serial !!!
| 
| This might be a bit worse for IDE than for SCSI.

I've been running (and benchmarking) Linux SMP since July 4 1996, and I
have never seen multiple jobs run slower in parallel than serial,
*except* when there is a lack of memory and you get swapping. There
always seems to be at least a little time when both CPUs get used.

I used to see jobs which ran faster in serial, because of kernel locks
in the 2.0 kernels, but on recent kernels, with adequate memory, I
think SMP is always a win.
-- 
  bill davidsen <[EMAIL PROTECTED]>  CTO, TMR Associates, Inc
Politicians and diapers have one thing in common. They should both be
changed regularly and for the same reason.
        --Ted Symons(?)


------------------------------

From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: POSIX.1 Shared mem support
Date: 25 Feb 1999 22:56:43 GMT

In article <[EMAIL PROTECTED]>,
Erik Svensson  <[EMAIL PROTECTED]> wrote:

| I'm looking at doing shared memory stuff on Linux and it doesn't seem
| to support POSIX shared memory. Is there any effort towards
| implementing that or am i stuck with mmap?

I thought the SysV stuff was POSIX.1. What are you missing?
-- 
  bill davidsen <[EMAIL PROTECTED]>  CTO, TMR Associates, Inc
Politicians and diapers have one thing in common. They should both be
changed regularly and for the same reason.
        --Ted Symons(?)


------------------------------

From: "John McKown" <[EMAIL PROTECTED]>
Subject: Re: /dev/zero
Date: Thu, 25 Feb 1999 17:14:08 -0600

It's real neat for initializing a new file to 0x00!

dd if=/dev/zero of=myfile bs=512 count=20
Will create a 10K file which has 0x00 as every byte.
][ndigo - Stormy blue sky wrote in message ...
>Hi.
>Can anyone explain me the purpose of this file (except for DCC send to
>friends)?
>Thank you.
>Bye.
>
>Michele
>



------------------------------

From: [EMAIL PROTECTED] (Kendall Bennett)
Subject: CPU detection module source code
Date: Thu, 25 Feb 1999 14:54:35 -0800

Hi All,

A number of people have requested the sources to the CPU detection 
program, so I have put together a package of the sources and uploaded 
them to our ftp site. Please read the readme file on the ftp site for 
more information about installing and compiling the sources:

 ftp://ftp.scitechsoft.com/devel/cpu/readme.txt

You can download executeables for DOS, Win32, OS/2 and Linux (glibc) from 
the same directory on the ftp site, along with the source code and the 
binary tools you will need to build the sources (such as prebuilt 
versions of dmake and nasm).

Things to be done:
==================

For the most part the CPU detection module is working very well and 
detecting the type and speed of most processors. However one area that 
does need some work is the detection of the speed of older processors 
from Cyrix and AMD that do not support the Pentium RDTSC instruction (ie: 
Cyrix 6x86, AMD Am486 and Am5x86). The speed detection code for those 
processors is based on timing the BSF instruction and comparing it 
against known calibrated values for those CPU's. Included in the 
calibration tables is Intel i386 and i486 processors, and Cyrix MediaGX 
processors. 

If you are getting incorrect measurements on earlier processors, please 
take a look at the calibration values and adjust them to suit your 
processor so it reports the correct speed. The tables of values are 
intel_cycles and cyrix_cycles located in the CPU_getProcessorSpeed 
function in the main cpuinfo.c module.

Regards,

-- 

+----------------------------------------------------------------------+
|      SciTech Software - Building Truly Plug'n'Play Software!         |
+----------------------------------------------------------------------+
| Kendall Bennett          | To reply via email, remove nospam from    |
| Director of Engineering  | the reply to email address. Do NOT send   |
| SciTech Software, Inc.   | unsolicited commercial email!             |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com                |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com         |
+----------------------------------------------------------------------+

------------------------------

From: "David A. Frantz" <[EMAIL PROTECTED]>
Crossposted-To: 
alt.os.linux.slackware,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Overclocking (was: Re: K6-2 and Linux, Are there any Bug?)
Date: Thu, 25 Feb 1999 18:42:00 -0500


Bugs Bunny wrote in message <[EMAIL PROTECTED]>...
>
>Yair Paz wrote in message <[EMAIL PROTECTED]>...
>>Bugs Bunny wrote:
>>> you can overclock it it will run hotter and finally burn out like all
>chips
>>> that are over clocked it is a gamble
>>>
>>> do it aown risk
>>Bulls. some chips are meant to beoverclocked - the P2-300 for example,
>>in the last 6 months of it's manufacture, it was made with a P2-350 core
>>hard wired to be 300. you can easily un-wire it (OK , not so easily). or
>>the Celeron 300A which overclocks to 450 w/o a glitch just by changing
>>the FSB speed, or the K6-2 300 which can overclock to 375 w/o additional
>>cooling, or any P5 MMX chips which can usually be overclocked to about
>>20% more, if you have the right board, w/o needing for extra hardware
>>(coolants) or voltage tweeking. nowdays, you can even overclock
>>HardDisks.
>>Oded
>
>the only chips i hear of that can be is celeron but besides that.... the
>chip is not made to be over clocked..... if it was supposed to be over
>clocked it would RUN at THAT SPEED not 50-100 MHz slower



Actually this is not true at all it would mean that Intel had no plans for
upgrading the chip or improving the process.    Without going to the advance
processess in the first place for the Celeron, Intel would not have had the
oportunity to quickly add the on chip cache that makes the new Celerons such
standouts.

Economics come into play as the "faster" processes are also the processes
that produce the smaller dies.    This means of course more Celerons per
wafer which means cheap.    Since the product was initially targeted at the
low end of the market there is no reason to believe that the Celeron wasn't
designed from the beginning to run faster.    Intel just tried to rake a
little money in from the sucker market.

Dave




------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to