Only 10 MB/sec with via 82c686b chipset?
I have an IWill KK-266R motherboard with an athlon-c 1200
processor in it, and for the life of me I can't get more than
10 MB/sec through the on-board ide controller. Yes, all the
appropriate support is turned on in the kernel to enable dma
and specific chipset support, and yes, I think I have all
relevant patches and a reasonable kernel.
I started out with stock kernel 2.4.2. I later added Hedrick's
ide.2.4.3-p4.all.03132001.patch, which did not change the
behaviour other than to include messages in the dmesg output. I
have even tried removing the via-specific chipset support from
the kernel, only to find that enabling dma with generic support
leaves me at the same 10 MB/sec as the specific support does.
I noted a number of other interesting things; one, that -X33,
-X34, and -X64 through -X69 all have the same 10 MB/sec transfer
rate, and two, that the 10 MB/sec transfer rate can be linearly
increased to 12 MB/sec by raising the system bus from 100 mhz to
120 mhz (all components are safely rated at 133, no overclocking
involved.)
It is also quite strange that I have been able to run 'hdparm
-t /dev/hda' and 'hdparm -t /dev/hdb' concurrently and can still
get the full 10 MB/sec on both, for a sum total of 20 MB/sec. I
would have expected that the drives would clobber each other
given that they are on the same ide bus.
>From the /proc data and other information below, it seems to me
that this is some kind of screwball tuning issue between linux and
the chipset, not the chipset and the drives. As near as I can
tell, the chipset is talking to the drives at a much higher data
rate than 10 MB/sec, but for some reason linux isn't able to
process the data any faster than that. Running hdparm -t in
parallel and observing a speed increase from raising the cpu
clock leads me in that direction. (Also note that hdparm -t only
uses a few percent of cpu. It's not like the machine doesn't
have enough processing power.)
I'm really baffled at this point. I can't rule out that I have
done something dumb, but for the life of me I can't think of
anything else. I've been to a number of web pages, but the
general consensus seems to be that this chipset should just work,
and work beautifully without any trouble. There aren't any
fixes because I seem to be the only one having this problem.
Does anyone have any other ideas?
-dennis T
Misc hardware information:
----------------------------------------------------
The board has raid hardware on it, but its currently disabled with
jumpers. Cables are high quality 80 wire/40 pin cables. Both
drives are the same, but currently hdb has the 32 gig clip jumper
attached. Putting the drives on separate ide busses does not
change the 10 MB/sec throughput. Removing hdb from the chain
does not raise the throughput of hda. Both drives are rated at
37 MB/sec continuous DTR. Hdd is a cheap 8x cdrom.
Hdb, when installed in a nearby machine, has a 17 MB/sec data
rate. The machine is an AMD K6-II 500, 100 MHz bus, with via
82c586 chipset, running kernel 2.4.1 (via chipset support
enabled.)
Various miscellaneous data, and dmesg output:
----------------------------------------------------
root@gurney:~# cat /proc/ide/via
----------VIA BusMastering IDE Configuration----------------
Driver Version: 3.20
South Bridge: VIA vt82c686b
Revision: ISA 0x40 IDE 0x6
BM-DMA base: 0xd000
PCI clock: 33MHz
Master Read Cycle IRDY: 0ws
Master Write Cycle IRDY: 0ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: yes yes
Post Write Buffer: yes no
Enabled: yes yes
Simplex only: no no
Cable Type: 80w 40w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode: UDMA UDMA PIO PIO
Address Setup: 30ns 30ns 120ns 60ns
Cmd Active: 90ns 90ns 90ns 90ns
Cmd Recovery: 30ns 30ns 90ns 90ns
Data Active: 90ns 90ns 330ns 240ns
Data Recovery: 30ns 30ns 270ns 240ns
Cycle Time: 20ns 20ns 50ns 90ns
Transfer Rate: 100.0MB/s 100.0MB/s 40.0MB/s 22.2MB/s
----------------------------------------------------
root@gurney:~# hdparm /dev/hda
/dev/hda:
multcount = 0 (off)
I/O support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 5606/255/63, sectors = 90069840, start = 0
----------------------------------------------------
root@gurney:~# hdparm -i /dev/hda
/dev/hda:
Model=IBM-DTLA-307045, FwRev=TX6OA60A, SerialNo=YMEYMNF7564
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=90069840
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
----------------------------------------------------
root@gurney:~# hdparm -T /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.88 seconds =145.45 MB/sec
----------------------------------------------------
root@gurney:~# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 64 MB in 6.11 seconds = 10.47 MB/sec
----------------------------------------------------
root@gurney:~# dmesg
Linux version 2.4.2 (root@gurney) (gcc version 2.95.2 19991024 (release)) #4 Tue Mar 20 18:02:16 CST 2001
BIOS-provided physical RAM map:
BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)
BIOS-e820: 0000000000000400 @ 000000000009fc00 (usable)
BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
BIOS-e820: 000000000fef0000 @ 0000000000100000 (usable)
BIOS-e820: 000000000000d000 @ 000000000fff3000 (ACPI data)
BIOS-e820: 0000000000003000 @ 000000000fff0000 (ACPI NVS)
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=2.4.2 ro root=304
Initializing CPU#0
Detected 898.848 MHz processor.
Console: colour VGA+ 80x34
Calibrating delay loop... 1789.13 BogoMIPS
Memory: 255656k/262080k available (903k kernel code, 6036k reserved, 337k data,
192k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb240, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Bus master read caching disabled
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
block: queued sectors max/low 169880kB/56626kB, 512 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:pio, hdd:DMA
hda: IBM-DTLA-307045, ATA DISK drive
hdb: IBM-DTLA-307045, ATA DISK drive
hdd: HITACHI CDR-7930, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=5606/255/63, UDMA(100)
hdb: 66055248 sectors (33820 MB) w/1916KiB Cache, CHS=65531/16/63, UDMA(100)
hdd: ATAPI 8X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2 hda3 hda4
hdb: hdb1 hdb2
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10d
8139too Fast Ethernet driver 0.9.13 loaded
PCI: Found IRQ 10 for device 00:0b.0
PCI: The same IRQ used for device 00:0f.0
eth0: RealTek RTL8139 Fast Ethernet at 0xd0800000, 00:e0:7d:95:af:a6, IRQ 10
eth0: Identified 8139 chip type 'RTL-8139C'
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: Detected Via Apollo Pro KT133 chipset
agpgart: AGP aperture is 64M @ 0xd8000000
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
reiserfs: checking transaction log (device 03:04) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 192k freed
Adding Swap: 530136k swap-space (priority -1)
hda: Write Cache SUCCESSED Flushing!<6>hda: Write Cache SUCCESSED Flushing!<6>usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
On 20 Mar, SodaPop wrote:
> I have an IWill KK-266R motherboard with an athlon-c 1200
> processor in it, and for the life of me I can't get more than
> 10 MB/sec through the on-board ide controller. Yes, all the
> appropriate support is turned on in the kernel to enable dma
> and specific chipset support, and yes, I think I have all
> relevant patches and a reasonable kernel.
Yes, actually I'm seeing the same on a KT133 board from Elitegroup.
Although here I get a bit more: 15 MB/s
> I noted a number of other interesting things; one, that -X33,
> -X34, and -X64 through -X69 all have the same 10 MB/sec transfer
> rate, and two, that the 10 MB/sec transfer rate can be linearly
> increased to 12 MB/sec by raising the system bus from 100 mhz to
> 120 mhz (all components are safely rated at 133, no overclocking
> involved.)
Duh, before making such a claim you should consider the fact that
this is overclocking your PCI/AGP bus and I have yet to see any
graphic cards/IDE controllers/other devices which are rated for
37MHz PCI bus speed.
--
Servus,
Daniel
> Duh, before making such a claim you should consider the fact that
> this is overclocking your PCI/AGP bus and I have yet to see any
> graphic cards/IDE controllers/other devices which are rated for
> 37MHz PCI bus speed.
The "blue and white" PowerMac G3 and certain early PowerMac G4s used a
66MHz PCI card for graphics in lieu of proper AGP. 66MHz PCI is used in
certain high-end workstations, as well, but it's not normally found on
consumer-level devices.
Look at 'lspci -vvv' output for the "66MHz" flag on the devices listed
there - all the ones in my Duron system leave it unset, except for my (very
recent and pretty nippy) SCSI controller and (AGP) video card.
That said, *most* PCI devices don't like being overclocked, and it's not
well known that pushing the system bus also pushes the PCI and ISA buses in
the same manner. A friend of mine had *severe* locking problems with his
system when he inserted his cheap SCSI adapter into his overclocked
machine, even though the other cards handled it OK (relatively speaking -
I'm not convinced). I don't know how far he'd overclocked it, but 37MHz
kinda rings true.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected] (not for attachments)
big-mail: [email protected]
uni-mail: [email protected]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----
On 21 Mar, Jonathan Morton wrote:
> The "blue and white" PowerMac G3 and certain early PowerMac G4s used a
> 66MHz PCI card for graphics in lieu of proper AGP. 66MHz PCI is used
> in certain high-end workstations, as well, but it's not normally found
> on consumer-level devices.
> Look at 'lspci -vvv' output for the "66MHz" flag on the devices listed
> there - all the ones in my Duron system leave it unset, except for my
> (very recent and pretty nippy) SCSI controller and (AGP) video card.
Well, I wasn't talking about 66Mhz nor about 64bit cards but rather
normal consumer cards which are specified for 33Mhz.
> That said, *most* PCI devices don't like being overclocked, and it's
> not well known that pushing the system bus also pushes the PCI and ISA
> buses in the same manner. A friend of mine had *severe* locking
> problems with his system when he inserted his cheap SCSI adapter into
> his overclocked machine, even though the other cards handled it OK
> (relatively speaking - I'm not convinced). I don't know how far he'd
> overclocked it, but 37MHz kinda rings true.
Trying to enhance a systems performance by overclocking the bus is
about the most stupid thing one can do as one ANY of the connected
devices memory/CPU/chipset/PCI devices/AGP cards (just to name a
few) have a high probability of failing and all those probabilites
factor up which basically means that the system is in a unpredictable
state which is never acceptable for any serious kind of system.
Better leave the overclocking of busses to kids who are bored
by their live.
--
Servus,
Daniel
[email protected] wrote:
>
> On 20 Mar, SodaPop wrote:
>
> > I have an IWill KK-266R motherboard with an athlon-c 1200
> > processor in it, and for the life of me I can't get more than
> > 10 MB/sec through the on-board ide controller. Yes, all the
> > appropriate support is turned on in the kernel to enable dma
> > and specific chipset support, and yes, I think I have all
> > relevant patches and a reasonable kernel.
>
> Yes, actually I'm seeing the same on a KT133 board from Elitegroup.
> Although here I get a bit more: 15 MB/s
>
> > I noted a number of other interesting things; one, that -X33,
> > -X34, and -X64 through -X69 all have the same 10 MB/sec transfer
> > rate, and two, that the 10 MB/sec transfer rate can be linearly
> > increased to 12 MB/sec by raising the system bus from 100 mhz to
> > 120 mhz (all components are safely rated at 133, no overclocking
> > involved.)
>
> Duh, before making such a claim you should consider the fact that
> this is overclocking your PCI/AGP bus and I have yet to see any
> graphic cards/IDE controllers/other devices which are rated for
> 37MHz PCI bus speed.
>
> --
>
> Servus,
> Daniel
Actually this depends on the MB. On mine for instance (Athlon also, but
not IWill), the PCI bus is a quotient of the oscillator and the FSB is
a multiple of the PCI and the CPU & ev6 are multiples of the FSB.
Memory
speed is also a multibple of PCI. In this case increasing the FSB
doesn't increase the PCI. Mine has two crystals 100/133 jumper con-
figurable.
Anyway this is probably getting way off-topic; although I'd kinda like
to see Dennis' output of both buffered and sustained output. Looks
kinda
like a hw config problem. Mine for comparison:
Maxtor 13.4 Gig 5400rpm ATA66
Buffered: ~170 - 175 MB
Sustained: ~24 MB inner ~26 MB outer
PCI: 33 FSB: 100 Memory 128M@133 CPU: 750Mhz EV6: 200
===============
-- Tim
--------------------==============++==============--------------------
Regarding the overclocking of the PCI bus, I was not aware of this. The
documentation led me to believe the pci clock was fixed, however further
experimentation indicates that's clearly not the case. Thanks.
Regarding the fix: I installed an Ensonique AudioPci sound card, and
experienced horrible distortion, crackling, and high pitched chirps any
time I tried to use the device. I noticed that various interrupts were
causing chunks of the real audio to sometimes slip through; on a whim I
tried ping flooding a nearby machine and the sound quality improved
greatly.
Putting two and two together, it occurred to me that the motherboard was
having irq/interrupt routing problems. The disks could not get reasonable
throughput because the interrupts were getting choked or held up, and the
sound card couldn't properly function either.
Wonder of wonders, I flashed the bios to the latest and greatest version.
Current data transfer rates are 35.7 MB/sec on both udma drives, exactly
as expected and darn close to the continuous read limits of the disks.
The audio also started working, flawlessly.
There are other issues however - the athlon now runs significantly hotter
at idle for one, but the most serious is that the K7 kernel optimizations
cause horrendous kernel panics and crashes. I'm running now on a kernel
compiled for 386, which seems to be stable. I'll attempt to build other
kernels to see if I can figure out whats going on.
Net result: IWill KK266 motherboards have bios problems, it may be a good
idea to upgrade the bios.
-dennis T
On Wed, 21 Mar 2001 [email protected] wrote:
> On 20 Mar, SodaPop wrote:
>
> > I have an IWill KK-266R motherboard with an athlon-c 1200
> > processor in it, and for the life of me I can't get more than
> > 10 MB/sec through the on-board ide controller. Yes, all the
> > appropriate support is turned on in the kernel to enable dma
> > and specific chipset support, and yes, I think I have all
> > relevant patches and a reasonable kernel.
>
> Yes, actually I'm seeing the same on a KT133 board from Elitegroup.
> Although here I get a bit more: 15 MB/s
>
> > I noted a number of other interesting things; one, that -X33,
> > -X34, and -X64 through -X69 all have the same 10 MB/sec transfer
> > rate, and two, that the 10 MB/sec transfer rate can be linearly
> > increased to 12 MB/sec by raising the system bus from 100 mhz to
> > 120 mhz (all components are safely rated at 133, no overclocking
> > involved.)
>
> Duh, before making such a claim you should consider the fact that
> this is overclocking your PCI/AGP bus and I have yet to see any
> graphic cards/IDE controllers/other devices which are rated for
> 37MHz PCI bus speed.
>
> --
>
> Servus,
> Daniel
>
Further note - kernels built with K6-2 support seem to be just fine. But
all athlon/K7 kernels die horribly, with greatly varying death messages.
Most commonly I get bogus pointer/dereference errors and eventually init
gets killed, other times it just locks up, sometimes I get things like
'cannot exec syslogd: Out of memory'. It looks like the memory registers
are horked up somehow.
I could try to copy some of this out by hand if anyone thought it
worthwhile. Either way, I think IWill has some work to do yet on their
system bios.
-dennis T
On Wed, 21 Mar 2001 [email protected] wrote:
> On 20 Mar, SodaPop wrote:
>
> > I have an IWill KK-266R motherboard with an athlon-c 1200
> > processor in it, and for the life of me I can't get more than
> > 10 MB/sec through the on-board ide controller. Yes, all the
> > appropriate support is turned on in the kernel to enable dma
> > and specific chipset support, and yes, I think I have all
> > relevant patches and a reasonable kernel.
>
> Yes, actually I'm seeing the same on a KT133 board from Elitegroup.
> Although here I get a bit more: 15 MB/s
>
> > I noted a number of other interesting things; one, that -X33,
> > -X34, and -X64 through -X69 all have the same 10 MB/sec transfer
> > rate, and two, that the 10 MB/sec transfer rate can be linearly
> > increased to 12 MB/sec by raising the system bus from 100 mhz to
> > 120 mhz (all components are safely rated at 133, no overclocking
> > involved.)
>
> Duh, before making such a claim you should consider the fact that
> this is overclocking your PCI/AGP bus and I have yet to see any
> graphic cards/IDE controllers/other devices which are rated for
> 37MHz PCI bus speed.
>
> --
>
> Servus,
> Daniel
>
> Wonder of wonders, I flashed the bios to the latest and greatest version.
> Current data transfer rates are 35.7 MB/sec on both udma drives, exactly
> as expected and darn close to the continuous read limits of the disks.
> The audio also started working, flawlessly.
>
> There are other issues however - the athlon now runs significantly hotter
> at idle for one, but the most serious is that the K7 kernel optimizations
> cause horrendous kernel panics and crashes. I'm running now on a kernel
> compiled for 386, which seems to be stable. I'll attempt to build other
> kernels to see if I can figure out whats going on.
Check the bios update didnt leave some of the other configuration values
wrong. A 'reset to factory defaults' and resetting the stuff you need might
be a good idea. Could be it now has voltages wrong or something like that
Alan
Thanks Alan, but no dice. Most of the stuff on the board is autodetect
anyway, but even after a reset it exhibited the same behaviour.
Windows, however, continues to run fine. It's not properly set up with
all the various drivers installed though, so its probably running with the
equivalent of a 486 kernel as well.
I tried rebuilding with K6-II as the cpu type instead of K7, that works
fine. Is there any data in particular you'd like me to collect or
experiments you'd like me to try?
-dennis T
On Fri, 23 Mar 2001, Alan Cox wrote:
> > Wonder of wonders, I flashed the bios to the latest and greatest version.
> > Current data transfer rates are 35.7 MB/sec on both udma drives, exactly
> > as expected and darn close to the continuous read limits of the disks.
> > The audio also started working, flawlessly.
> >
> > There are other issues however - the athlon now runs significantly hotter
> > at idle for one, but the most serious is that the K7 kernel optimizations
> > cause horrendous kernel panics and crashes. I'm running now on a kernel
> > compiled for 386, which seems to be stable. I'll attempt to build other
> > kernels to see if I can figure out whats going on.
>
> Check the bios update didnt leave some of the other configuration values
> wrong. A 'reset to factory defaults' and resetting the stuff you need might
> be a good idea. Could be it now has voltages wrong or something like that
>
> Alan
>
Rik, is there any way we could get a /proc entry for this, so that one
could do something like:
cat /proc/oom-kill-scores | sort +3
to get a process list (similar to ps) with a field for the current oom
scores? It would likely be very useful to be able to dump the current
scores and see what will be the first thing to die, and may help people
tune the killer for specific uses.
Part of the current problem with the OOM killer is that people only know
what it's going to kill after it's too late.
-dennis T
SodaPop wrote:
>
> Rik, is there any way we could get a /proc entry for this, so that one
> could do something like:
I will respond; NO there is no way for security reasons this is not a
good idea.
> cat /proc/oom-kill-scores | sort +3
>> Rik, is there any way we could get a /proc entry for this, so that one
>> could do something like:
>
>I will respond; NO there is no way for security reasons this is not a
>good idea.
Just out of interest, what information does the OOM score expose that isn't
already available to Joe Random Unprivileged User? Looking at my 2.4.1
source, nothing. The badness() function uses the following:
- memory size
- run time
- cpu time
- nice value
- if it's a root process
- (rare) if process has direct hardware access
Apart from the last item, which is rarely encountered, all the above info
is available using 'top' or 'ps' or via the /proc filesystem already, by
any unprivileged user (unless you've make /proc su-access only, in which
case your point is moot anyway).
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected] (not for attachments)
big-mail: [email protected]
uni-mail: [email protected]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----
On Fri, 23 Mar 2001, Martin Dalecki wrote:
> SodaPop wrote:
> >
> > Rik, is there any way we could get a /proc entry for this, so that one
> > could do something like:
>
> I will respond; NO there is no way for security reasons this is not a
> good idea.
>
> > cat /proc/oom-kill-scores | sort +3
Oh, you mean like /proc/kcore is a bad idea for security reasons?
Duh, make its permission bits 400.
-dennis T
SodaPop wrote:
>
> On Fri, 23 Mar 2001, Martin Dalecki wrote:
>
> > SodaPop wrote:
> > >
> > > Rik, is there any way we could get a /proc entry for this, so that one
> > > could do something like:
> >
> > I will respond; NO there is no way for security reasons this is not a
> > good idea.
> >
> > > cat /proc/oom-kill-scores | sort +3
>
> Oh, you mean like /proc/kcore is a bad idea for security reasons?
Yes. It should be the good old /dev/core anyway.
But its far more obscure to hack at, since it isn't plain text,
so basically it's far more difficult to get mands on it...