* Re: IBM spamms me with error messages
From: Matti Aarnio @ 2002-12-10 22:43 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list
In-Reply-To: <20021210205611.GH20049@atrey.karlin.mff.cuni.cz>
On Tue, Dec 10, 2002 at 09:56:11PM +0100, Pavel Machek wrote:
> Hi!
>
> I replied to some mail on l-k and IBM spammed me with 20+ error
> messages. Now it is apparently going to do that again.
Still/again ?
> IBM: I asked your postmasters to fix your mail systems, and you
> apparently don't know how to do that. Can you fix it?!
>
> I don't know what broken mailserver substituted my email address as
> pavel%internet.vnet@RCHGATE.RCHLAND.IBM.COM, and I do not care much,
> but STOP SPAMMING ME.
> Pavel
It is same type of MTA misbehaviour as is exhibited by
various M$ email virus scanners. Visible "From:" header
has absolutely nothing to do with what is the correct
address to send the message to. (Or "To:"/"Cc:" headers..)
> RCHGATE.RCHLAND.IBM.COM unable to deliver following mail to
> recipient(s):
> <tinglett@rchmail.rchland.ibm.com>
> RCHGATE.RCHLAND.IBM.COM received negative reply:
> 501 5.1.8 <@RCHGATE.RCHLAND.IBM.COM:PAVEL@INTERNET.RSCS>... Domain of
> sender address PAVEL@INTERNET.RSCS does not exist
Tinglett isn't subscribed. Yet the message is quite fresh...
> ** Text of Mail follows **
> Received: by RCHGATE.RCHLAND.IBM.COM (IBM VM SMTP Level 3A0) via
> spool with SMTP id 6538 ; Tue, 10 Dec 2002 14:45:57 CST
> Received: by RCHGATE (cvtto822 5.1.7) via <pavel@internet> id 2652
> (NOTE)
> for <tinglett@rchland>; Tue, 10 Dec 2002 14:45:57 -0600
> Date: Tue, 10 Dec 2002 21:40:31 +0100
> From: "Pavel Machek" <pavel%internet.vnet@RCHGATE.RCHLAND.IBM.COM>
> To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
^ permalink raw reply
* Re: [PATCH 2.4.20-BK] usbnet typo
From: Greg KH @ 2002-12-10 22:42 UTC (permalink / raw)
To: Stelian Pop, Linux Kernel Mailing List, Marcelo Tosatti
In-Reply-To: <20021210162820.G18849@deep-space-9.dsnet>
On Tue, Dec 10, 2002 at 04:28:20PM +0100, Stelian Pop wrote:
> There is a typo in the latest usbnet driver which disables
> the compile of iPAQ specific code.
>
> With the attached patch, the new driver recognises the iPAQ
> and even works :*)
Thanks, I've added this to my tree and will send it on to Marcelo.
greg k-h
^ permalink raw reply
* something like cron
From: r4mz3z @ 2002-12-10 22:37 UTC (permalink / raw)
To: linux-newbie
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi friends...
I'm trying to run an application each XX time, I'm using cron but with it I
can't do it... I have a script to send a email to my admin but I need to use
this script since I connect and each 5 minutes.
Example:
10:32 -> connect --> run this script
10:37 -> run the script
10:42 -> run the script
...
Thank you very much
- --
Linux User Registered #232544
my GnuPG-key at www.keyserver.net
--- rm -rf /bin/laden ---
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE99my5s4dF9gl05swRAsxOAKCQcXP4d6flmxFnR1UbTGgc+mJw5wCfQsom
SxcM0SL9h3W+o/h2KfqKlwU=
=qGYI
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* xxx_check_var
From: Paul Mackerras @ 2002-12-10 22:40 UTC (permalink / raw)
To: James Simmons; +Cc: linux-kernel, linux-fbdev-devel
When I look at atyfb_check_var or aty128fb_check_var, I see that they
will alter the contents of *info->par. Isn't this a bad thing? My
understanding was that after calling check_var, you don't necessarily
call set_par next (particularly if check_var returned an error).
Also I notice that atyfb_set_par and aty128fb_set_par don't look at
info->var, they simply set the hardware state based on the contents of
*info->par.
Looking at skeletonfb.c, it seems that this is the wrong behaviour. I
had fixed the aty128fb.c driver in the linuxppc-2.5 tree. James, if
you let me know whether the current behaviour is wrong or not, I'll
fix them and send you the patch.
Paul.
^ permalink raw reply
* [PATCH] dm-ioctl.h - device-mapper ioctl packet fixes
From: Kevin Corry @ 2002-12-10 22:03 UTC (permalink / raw)
To: Joe Thornber, Linus Torvalds; +Cc: Kernel Mailing List, lvm-devel
Joe, Linus,
This patch fixes some device-mapper ioctl packet definitions in dm-ioctl.h
in 2.5.51.
Notes:
- The "dev" fields in "struct dm_ioctl" and "struct dm_target_deps" should
be fixed-size to avoid requiring translation code on architectures such as
ppc64 and sparc64 with 32-bit user-space and 64-bit kernel-space.
- The "length" field in "struct dm_target_spec" should be should be 64-bit
to allow single targets within a device to be greater than 2 TB.
- The "status" field in "struct dm_target_spec" should be moved to ensure
proper field alignment on 64-bit architectures.
- The version of the ioctl interface changes from 1.0.6 to 2.0.0, because
the new structure definitions are not backwards compatible with the previous
definitions.
--
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/
--- linux-2.5.51a/include/linux/dm-ioctl.h Tue Dec 10 10:59:55 2002
+++ linux-2.5.51b/include/linux/dm-ioctl.h Wed Nov 20 14:44:06 2002
@@ -50,7 +50,7 @@
uint32_t open_count; /* out */
uint32_t flags; /* in/out */
- __kernel_dev_t dev; /* in/out */
+ uint32_t dev; /* in/out */
char name[DM_NAME_LEN]; /* device name */
char uuid[DM_UUID_LEN]; /* unique identifier for
@@ -62,9 +62,9 @@
* dm_ioctl.
*/
struct dm_target_spec {
- int32_t status; /* used when reading from kernel only */
uint64_t sector_start;
- uint32_t length;
+ uint64_t length;
+ int32_t status; /* used when reading from kernel only */
/*
* Offset in bytes (from the start of this struct) to
@@ -87,7 +87,7 @@
struct dm_target_deps {
uint32_t count;
- __kernel_dev_t dev[0]; /* out */
+ uint32_t dev[0]; /* out */
};
/*
@@ -129,10 +129,10 @@
#define DM_TARGET_STATUS _IOWR(DM_IOCTL, DM_TARGET_STATUS_CMD, struct dm_ioctl)
#define DM_TARGET_WAIT _IOWR(DM_IOCTL, DM_TARGET_WAIT_CMD, struct dm_ioctl)
-#define DM_VERSION_MAJOR 1
+#define DM_VERSION_MAJOR 2
#define DM_VERSION_MINOR 0
-#define DM_VERSION_PATCHLEVEL 6
-#define DM_VERSION_EXTRA "-ioctl (2002-10-15)"
+#define DM_VERSION_PATCHLEVEL 0
+#define DM_VERSION_EXTRA "-ioctl (2002-12-10)"
/* Status bits */
#define DM_READONLY_FLAG 0x00000001
^ permalink raw reply
* [PATCH] dm.c - device-mapper I/O path fixes
From: Kevin Corry @ 2002-12-10 22:03 UTC (permalink / raw)
To: Joe Thornber, Linus Torvalds; +Cc: Kernel Mailing List, lvm-devel
Joe, Linus,
This patch fixes problems with the device-mapper I/O path in 2.5.51. The
existing code does not properly split requests when necessary, and can
cause segfaults and/or data corruption. This can easily manifest itself
when running XFS on striped LVM volumes.
Notes:
- New bio's must be alloc'd instead of clone'd, since the bio vector may need
to be adjusted if the end of the split request does not fill a page.
- Fix reference counting of md->pending. This should only be incremented once
for each incoming bio, not for each split bio that is resubmitted.
- Copy the correct bvec when splitting the tail-end of a page.
--
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/
--- linux-2.5.51a/drivers/md/dm.c Tue Dec 10 11:01:13 2002
+++ linux-2.5.51b/drivers/md/dm.c Tue Dec 10 11:03:55 2002
@@ -242,17 +242,18 @@
static spinlock_t _uptodate_lock = SPIN_LOCK_UNLOCKED;
unsigned long flags;
- spin_lock_irqsave(&_uptodate_lock, flags);
- if (error)
+ if (error) {
+ spin_lock_irqsave(&_uptodate_lock, flags);
io->error = error;
- spin_unlock_irqrestore(&_uptodate_lock, flags);
+ spin_unlock_irqrestore(&_uptodate_lock, flags);
+ }
if (atomic_dec_and_test(&io->io_count)) {
if (atomic_dec_and_test(&io->md->pending))
/* nudge anyone waiting on suspend queue */
wake_up(&io->md->wait);
- bio_endio(io->bio, io->error ? 0 : io->bio->bi_size, io->error);
+ bio_endio(io->bio, io->bio->bi_size, io->error);
free_io(io);
}
}
@@ -261,15 +262,15 @@
{
struct dm_io *io = bio->bi_private;
- /*
- * Only call dec_pending if the clone has completely
- * finished. If a partial io errors I'm assuming it won't
- * be requeued. FIXME: check this.
- */
- if (error || !bio->bi_size) {
- dec_pending(io, error);
- bio_put(bio);
+ if (bio->bi_size)
+ return 1;
+
+ if (error) {
+ struct gendisk *disk = dm_disk(io->md);
+ DMWARN("I/O error (%d) on device %s\n", error, disk->disk_name);
}
+ dec_pending(io, error);
+ bio_put(bio);
return 0;
}
@@ -313,7 +314,6 @@
* anything, the target has assumed ownership of
* this io.
*/
- atomic_inc(&io->md->pending);
atomic_inc(&io->io_count);
r = ti->type->map(ti, clone);
if (r > 0)
@@ -341,9 +341,7 @@
{
struct dm_target *ti = dm_table_find_target(ci->md->map, ci->sector);
struct bio *clone, *bio = ci->bio;
- struct bio_vec *bv = bio->bi_io_vec + (bio->bi_vcnt - 1);
-
- DMWARN("splitting page");
+ struct bio_vec *bv = bio->bi_io_vec + ci->idx;
if (len > ci->sector_count)
len = ci->sector_count;
@@ -353,11 +351,13 @@
clone->bi_sector = ci->sector;
clone->bi_bdev = bio->bi_bdev;
- clone->bi_flags = bio->bi_flags | (1 << BIO_SEG_VALID);
clone->bi_rw = bio->bi_rw;
+ clone->bi_vcnt = 1;
clone->bi_size = len << SECTOR_SHIFT;
clone->bi_end_io = clone_endio;
clone->bi_private = ci->io;
+ clone->bi_io_vec->bv_offset = clone->bi_io_vec->bv_len - clone->bi_size;
+ clone->bi_io_vec->bv_len = clone->bi_size;
ci->sector += len;
ci->sector_count -= len;
@@ -369,24 +369,48 @@
{
struct bio *clone, *bio = ci->bio;
struct dm_target *ti = dm_table_find_target(ci->md->map, ci->sector);
- sector_t len = max_io_len(ci->md, bio->bi_sector, ti);
+ sector_t bv_len, len = max_io_len(ci->md, ci->sector, ti);
+ struct bio_vec *bv;
+ int i, vcnt = bio->bi_vcnt - ci->idx;
/* shorter than current target ? */
if (ci->sector_count < len)
len = ci->sector_count;
/* create the clone */
- clone = bio_clone(ci->bio, GFP_NOIO);
+ clone = bio_alloc(GFP_NOIO, vcnt);
+ if (!clone) {
+ dec_pending(ci->io, -ENOMEM);
+ return;
+ }
clone->bi_sector = ci->sector;
- clone->bi_idx = ci->idx;
+ clone->bi_bdev = bio->bi_bdev;
+ clone->bi_rw = bio->bi_rw;
+ clone->bi_vcnt = vcnt;
clone->bi_size = len << SECTOR_SHIFT;
clone->bi_end_io = clone_endio;
clone->bi_private = ci->io;
+ /* copy the original vector and adjust if necessary. */
+ memcpy(clone->bi_io_vec, bio->bi_io_vec + ci->idx,
+ vcnt * sizeof(*clone->bi_io_vec));
+ bv_len = len << SECTOR_SHIFT;
+ bio_for_each_segment(bv, clone, i) {
+ if (bv_len >= bv->bv_len) {
+ bv_len -= bv->bv_len;
+ } else {
+ bv->bv_len = bv_len;
+ clone->bi_vcnt = i + 1;
+ break;
+ }
+ }
+
+ /* submit this io */
+ __map_bio(ti, clone);
+
/* adjust the remaining io */
ci->sector += len;
ci->sector_count -= len;
- __map_bio(ti, clone);
/*
* If we are not performing all remaining io in this
@@ -395,8 +419,8 @@
*/
if (ci->sector_count) {
while (len) {
- struct bio_vec *bv = clone->bi_io_vec + ci->idx;
- sector_t bv_len = bv->bv_len >> SECTOR_SHIFT;
+ bv = bio->bi_io_vec + ci->idx;
+ bv_len = bv->bv_len >> SECTOR_SHIFT;
if (bv_len <= len)
len -= bv_len;
@@ -427,6 +451,8 @@
ci.sector_count = bio_sectors(bio);
ci.idx = 0;
+ atomic_inc(&ci.io->md->pending);
+
while (ci.sector_count)
__clone_and_map(&ci);
@@ -457,13 +483,13 @@
up_read(&md->lock);
if (bio_rw(bio) == READA) {
- bio_io_error(bio, 0);
+ bio_io_error(bio, bio->bi_size);
return 0;
}
r = queue_io(md, bio);
if (r < 0) {
- bio_io_error(bio, 0);
+ bio_io_error(bio, bio->bi_size);
return 0;
} else if (r == 0)
^ permalink raw reply
* Re: HPT372 RAID controller
From: Spacecake @ 2002-12-10 22:46 UTC (permalink / raw)
To: Alan Cox; +Cc: sflory, linux-kernel
In-Reply-To: <1039553984.14302.65.camel@irongate.swansea.linux.org.uk>
> Does the same occur without taskfile I/O ?
I just tried it... copying the exact same files across from the exact
same hdd etc. It didn't crash my system this time, and the files seem
okay. However - there were long pauses where CPU load was so high that X
wouldn't update the screen for about 10 seconds at a time, and things
were acting slightly weird for a few seconds after i got back my prompt.
And now the HDD light is on permanently whether i have disk access or
not. Hmm.
Though this *could* be a coincidence.
^ permalink raw reply
* Re: [2.5.51] unknown field 'driver_data' compiling cs4243
From: Adam J. Richter @ 2002-12-10 22:55 UTC (permalink / raw)
To: bwindle; +Cc: ambx1, linux-kernel
Burton Windle writes:
>I'm getting an error compiling cs4232 in 2.5.51. It built fine in 50-bk6.
[...]
>sound/oss/cs4232.c:361: unknown field `driver_data' specified in initializer
[etc.]
This is not due to the change that I submitted removing
driver_data from struct pci_dev, although it looks like a similar change
for isapnp devices. I started to make a change to convert
the references to driver_data to
dev_set_drvdata(&isapnpdev->dev,...) and dev_get_drvdata(&isapnpdev->dev),
but got a little confused by the multiple classes of isapnp drivers:
Driver structure Device structure ID structure
include/linux/isapnp.h:
isapnp_driver pci_dev isapnp_device_id
(none) pci_bus isapnp_card_id
include/linux/pnp.h:
pnpc_driver pnp_card pnp_card_id
pnp_driver pnp_dev pnp_id
From ChangeLog-2.5.51, I see mention of isapnp changes
associated with Adam Belay. So, I'm cc'ing him as he is probably
much better qualified to explain.
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
^ permalink raw reply
* Complete freeze with 2.4.20 on 4-proc IBM xSeries 350
From: "Rüegg, Peter H." @ 2002-12-10 22:58 UTC (permalink / raw)
To: 'linux-kernel@vger.kernel.org'
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear all,
I'm experiencing serious problems with Kernel 2.4.20 on a IBM xSeries 350
machine, having 4 700 MHz processors and 4 GB RAM (same on another machine
with the same configuration, but only 3 GB RAM). The machine just com-
pletely freezes after some time, ranging from 20 minutes to 3 hours. It
is running IBM DB/2 with quite some load, the base system is RedHat 7.2
with all the updates applied. There is no oops or other fault, just a
plain freeze.
I first thought, this might be related to the ips-driver, as the firmware
wasn't up-to-date on the first run, but updating this didn't help at all.
2.4.20 is the first 2.4-kernel I ran, thinking that earlier ones might
not be ready for real production systems yet. The machine has been rock-
stable on several 2.2-kernels for months.
The only change I did to the source was some small patch to sem.h which
set SEMMNI and SEMMSL to 1024, and SEMOPM to 512.
I had a small loop on a network-shell that simply wrote the date to a
file as well as stdout. This seems to work 5 to 10 seconds longer on
the network than on the disc.
If anybody has any idea what else I could try I'd be more than happy -
we're experiencing a bit of a problem with "only" 2GB RAM... I'm willing
to try anything, but as this is a production machine it could take some
time to find a timeframe.
Attached there's a dmesg as well as the kernel-config if that helps any-
thing.
Greets
Peter H. Ruegg
Systems-/Networkadministrator RHCE eEnterprises Technology
-
--8<------------------------------------------------------------------------
-
main(){char*s="O_>>^PQAHBbPQAHBbPOOH^^PAAHBJPAAHBbPA_H>BB";int
i,j,k=1,l,m,n;
for(j=0;j<7;j++)for(l=0;m=l-6+j,i=m/6,n=j*6+i,k=1<<m%6,l<41-j;l++)
putchar(l<6-j?' ':l==40-j?'\n':k&&s[n]&k?'*':' ');}
Dec 10 21:42:33 db03 syslogd 1.4.1: restart.
Dec 10 21:42:33 db03 syslog: syslogd startup succeeded
Dec 10 21:42:33 db03 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec 10 21:42:33 db03 kernel: Inspecting /boot/System.map-2.4.20-0.2.smp
Dec 10 21:42:33 db03 syslog: klogd startup succeeded
Dec 10 21:42:33 db03 keytable: Loading keymap: succeeded
Dec 10 21:42:33 db03 kernel: Loaded 18185 symbols from
/boot/System.map-2.4.20-0.2.smp.
Dec 10 21:42:33 db03 kernel: Symbols match kernel version 2.4.20.
Dec 10 21:42:33 db03 kernel: Loaded 11 symbols from 2 modules.
Dec 10 21:42:33 db03 kernel: Linux version 2.4.20-0.2.smp
(root@devint.eproduction.ch) (gcc version 2.96 20000731 (Red Hat Linux 7.2
2.96-112.7.2)) #1 SMP Tue Dec 10 21:01:29 CET 2002
Dec 10 21:42:33 db03 kernel: BIOS-provided physical RAM map:
Dec 10 21:42:33 db03 kernel: BIOS-e820: 0000000000000000 - 000000000009c800
(usable)
Dec 10 21:42:33 db03 kernel: BIOS-e820: 000000000009c800 - 00000000000a0000
(reserved)
Dec 10 21:42:33 db03 kernel: BIOS-e820: 00000000000e0000 - 0000000000100000
(reserved)
Dec 10 21:42:33 db03 kernel: BIOS-e820: 0000000000100000 - 00000000eb7f9380
(usable)
Dec 10 21:42:33 db03 kernel: BIOS-e820: 00000000eb7f9380 - 00000000eb800000
(ACPI data)
Dec 10 21:42:33 db03 kernel: BIOS-e820: 00000000fec00000 - 00000000fec01000
(reserved)
Dec 10 21:42:33 db03 kernel: BIOS-e820: 00000000fee00000 - 00000000fee01000
(reserved)
Dec 10 21:42:33 db03 kernel: BIOS-e820: 00000000fff80000 - 0000000100000000
(reserved)
Dec 10 21:42:33 db03 kernel: 2871MB HIGHMEM available.
Dec 10 21:42:33 db03 keytable: Loading system font: succeeded
Dec 10 21:42:33 db03 kernel: 896MB LOWMEM available.
Dec 10 21:42:33 db03 kernel: found SMP MP-table at 0009c9d0
Dec 10 21:42:33 db03 kernel: hm, page 0009c000 reserved twice.
Dec 10 21:42:33 db03 kernel: hm, page 0009d000 reserved twice.
Dec 10 21:42:33 db03 kernel: hm, page 0009c000 reserved twice.
Dec 10 21:42:33 db03 kernel: hm, page 0009d000 reserved twice.
Dec 10 21:42:33 db03 random: Initializing random number generator:
succeeded
Dec 10 21:42:33 db03 kernel: WARNING: MP table in the EBDA can be UNSAFE,
contact linux-smp@vger.kernel.org if you experience SMP problems!
Dec 10 21:42:33 db03 kernel: On node 0 totalpages: 964601
Dec 10 21:42:33 db03 kernel: zone(0): 4096 pages.
Dec 10 21:42:33 db03 kernel: zone(1): 225280 pages.
Dec 10 21:42:33 db03 kernel: zone(2): 735225 pages.
Dec 10 21:42:33 db03 kernel: Intel MultiProcessor Specification v1.4
Dec 10 21:42:34 db03 kernel: Virtual Wire compatibility mode.
Dec 10 21:42:34 db03 ntpd[610]: ntpd 4.1.0 Wed Sep 5 06:54:30 EDT 2001 (1)
Dec 10 21:42:34 db03 ntpd: ntpd startup succeeded
Dec 10 21:42:34 db03 kernel: OEM ID: IBM ENSW Product ID: NF 6000R SMP APIC
at: 0xFEE00000
Dec 10 21:42:34 db03 kernel: Processor #3 Pentium(tm) Pro APIC version 17
Dec 10 21:42:34 db03 kernel: Processor #0 Pentium(tm) Pro APIC version 17
Dec 10 21:42:34 db03 kernel: Processor #1 Pentium(tm) Pro APIC version 17
Dec 10 21:42:34 db03 kernel: Processor #2 Pentium(tm) Pro APIC version 17
Dec 10 21:42:34 db03 kernel: I/O APIC #14 Version 17 at 0xFEC00000.
Dec 10 21:42:34 db03 ntpd[610]: precision = 8 usec
Dec 10 21:42:34 db03 kernel: I/O APIC #13 Version 17 at 0xFEC01000.
Dec 10 21:42:34 db03 ntpd[610]: kernel time discipline status 0040
Dec 10 21:42:34 db03 kernel: Processors: 4
Dec 10 21:42:34 db03 kernel: IBM machine detected. Enabling interrupts
during APM calls.
Dec 10 21:42:34 db03 ntpd[610]: frequency initialized 229.359 from
/etc/ntp/drift
Dec 10 21:42:34 db03 kernel: Kernel command line: ro root=/dev/sda2
vga=extended
Dec 10 21:42:34 db03 kernel: Initializing CPU#0
Dec 10 21:42:34 db03 kernel: Detected 699.475 MHz processor.
Dec 10 21:42:34 db03 kernel: Console: colour VGA+ 80x50
Dec 10 21:42:34 db03 kernel: Calibrating delay loop... 1395.91 BogoMIPS
Dec 10 21:42:34 db03 kernel: Memory: 3809868k/3858404k available (1563k
kernel code, 48136k reserved, 573k data, 108k init, 2940900k highmem)
Dec 10 21:42:34 db03 kernel: Dentry cache hash table entries: 262144 (order:
9, 2097152 bytes)
Dec 10 21:42:34 db03 kernel: Inode cache hash table entries: 262144 (order:
9, 2097152 bytes)
Dec 10 21:42:34 db03 kernel: Mount-cache hash table entries: 65536 (order:
7, 524288 bytes)
Dec 10 21:42:34 db03 kernel: Buffer-cache hash table entries: 262144 (order:
8, 1048576 bytes)
Dec 10 21:42:34 db03 kernel: Page-cache hash table entries: 524288 (order:
9, 2097152 bytes)
Dec 10 21:42:34 db03 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K
Dec 10 21:42:34 db03 kernel: CPU: L2 cache: 1024K
Dec 10 21:42:34 db03 kernel: Intel machine check architecture supported.
Dec 10 21:42:35 db03 kernel: Intel machine check reporting enabled on CPU#0.
Dec 10 21:42:35 db03 kernel: Enabling fast FPU save and restore... done.
Dec 10 21:42:35 db03 kernel: Enabling unmasked SIMD FPU exception support...
done.
Dec 10 21:42:35 db03 kernel: Checking 'hlt' instruction... OK.
Dec 10 21:42:35 db03 kernel: POSIX conformance testing by UNIFIX
Dec 10 21:42:35 db03 kernel: mtrr: v1.40 (20010327) Richard Gooch
(rgooch@atnf.csiro.au)
Dec 10 21:42:35 db03 snmpd: snmpd startup succeeded
Dec 10 21:42:35 db03 kernel: mtrr: detected mtrr type: Intel
Dec 10 21:42:35 db03 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K
Dec 10 21:42:30 db03 sysctl: fs.file-max = 32768
Dec 10 21:42:35 db03 kernel: CPU: L2 cache: 1024K
Dec 10 21:42:35 db03 sshd: Starting sshd:
Dec 10 21:42:35 db03 kernel: Intel machine check reporting enabled on CPU#0.
Dec 10 21:42:30 db03 sysctl: kernel.msgmni = 1024
Dec 10 21:42:30 db03 network: Setting network parameters: succeeded
Dec 10 21:42:30 db03 network: Bringing up interface lo: succeeded
Dec 10 21:42:35 db03 kernel: CPU0: Intel Pentium III (Cascades) stepping 01
Dec 10 21:42:35 db03 kernel: per-CPU timeslice cutoff: 2927.35 usecs.
Dec 10 21:42:35 db03 kernel: enabled ExtINT on CPU#0
Dec 10 21:42:35 db03 kernel: ESR value before enabling vector: 00000000
Dec 10 21:42:35 db03 sshd[647]: Server listening on 0.0.0.0 port 22.
Dec 10 21:42:35 db03 sshd: sshd startup succeeded
Dec 10 21:42:35 db03 kernel: ESR value after enabling vector: 00000000
Dec 10 21:42:35 db03 sshd: ^[[60G
Dec 10 21:42:35 db03 kernel: Booting processor 1/0 eip 2000
Dec 10 21:42:35 db03 kernel: Initializing CPU#1
Dec 10 21:42:36 db03 kernel: masked ExtINT on CPU#1
Dec 10 21:42:36 db03 sshd:
Dec 10 21:42:36 db03 kernel: ESR value before enabling vector: 00000000
Dec 10 21:42:36 db03 rc: Starting sshd: succeeded
Dec 10 21:42:36 db03 kernel: ESR value after enabling vector: 00000000
Dec 10 21:42:36 db03 kernel: Calibrating delay loop... 1395.91 BogoMIPS
Dec 10 21:42:36 db03 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K
Dec 10 21:42:36 db03 kernel: CPU: L2 cache: 1024K
Dec 10 21:42:36 db03 kernel: Intel machine check reporting enabled on CPU#1.
Dec 10 21:42:36 db03 ucd-snmp[629]: UCD-SNMP version 4.2.5
Dec 10 21:42:36 db03 kernel: CPU1: Intel Pentium III (Cascades) stepping 01
Dec 10 21:42:36 db03 kernel: Booting processor 2/1 eip 2000
Dec 10 21:42:36 db03 kernel: Initializing CPU#2
Dec 10 21:42:36 db03 kernel: masked ExtINT on CPU#2
Dec 10 21:42:36 db03 kernel: ESR value before enabling vector: 00000000
Dec 10 21:42:36 db03 kernel: ESR value after enabling vector: 00000000
Dec 10 21:42:36 db03 kernel: Calibrating delay loop... 1395.91 BogoMIPS
Dec 10 21:42:36 db03 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K
Dec 10 21:42:36 db03 kernel: CPU: L2 cache: 1024K
Dec 10 21:42:36 db03 kernel: Intel machine check reporting enabled on CPU#2.
Dec 10 21:42:36 db03 kernel: CPU2: Intel Pentium III (Cascades) stepping 01
Dec 10 21:42:36 db03 kernel: Booting processor 3/2 eip 2000
Dec 10 21:42:36 db03 kernel: Initializing CPU#3
Dec 10 21:42:36 db03 kernel: masked ExtINT on CPU#3
Dec 10 21:42:36 db03 kernel: ESR value before enabling vector: 00000000
Dec 10 21:42:36 db03 kernel: ESR value after enabling vector: 00000000
Dec 10 21:42:36 db03 kernel: Calibrating delay loop... 1395.91 BogoMIPS
Dec 10 21:42:36 db03 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K
Dec 10 21:42:36 db03 kernel: CPU: L2 cache: 1024K
Dec 10 21:42:36 db03 kernel: Intel machine check reporting enabled on CPU#3.
Dec 10 21:42:36 db03 kernel: CPU3: Intel Pentium III (Cascades) stepping 01
Dec 10 21:42:36 db03 kernel: Total of 4 processors activated (5583.66
BogoMIPS).
Dec 10 21:42:36 db03 kernel: ENABLING IO-APIC IRQs
Dec 10 21:42:36 db03 xinetd[680]: xinetd Version 2.3.7 started with libwrap
options compiled in.
Dec 10 21:42:36 db03 kernel: Setting 14 in the phys_id_present_map
Dec 10 21:42:36 db03 xinetd[680]: Started working: 0 available services
Dec 10 21:42:36 db03 kernel: ...changing IO-APIC physical APIC ID to 14 ...
ok.
Dec 10 21:42:36 db03 kernel: Setting 13 in the phys_id_present_map
Dec 10 21:42:36 db03 kernel: ...changing IO-APIC physical APIC ID to 13 ...
ok.
Dec 10 21:42:36 db03 kernel: ..TIMER: vector=0x31 pin1=2 pin2=-1
Dec 10 21:42:36 db03 kernel: ..MP-BIOS bug: 8254 timer not connected to
IO-APIC
Dec 10 21:42:36 db03 kernel: ...trying to set up timer (IRQ0) through the
8259A ... failed.
Dec 10 21:42:36 db03 kernel: ...trying to set up timer as Virtual Wire
IRQ... works.
Dec 10 21:42:37 db03 kernel: testing the IO APIC.......................
Dec 10 21:42:37 db03 kernel:
Dec 10 21:42:37 db03 kernel:
Dec 10 21:42:37 db03 kernel: .................................... done.
Dec 10 21:42:37 db03 kernel: Using local APIC timer interrupts.
Dec 10 21:42:37 db03 kernel: calibrating APIC timer ...
Dec 10 21:42:37 db03 kernel: ..... CPU clock speed is 699.3801 MHz.
Dec 10 21:42:37 db03 kernel: ..... host bus clock speed is 99.9113 MHz.
Dec 10 21:42:37 db03 kernel: cpu: 0, clocks: 999113, slice: 199822
Dec 10 21:42:37 db03 kernel: CPU0<T0:999104,T1:799280,D:2,S:199822,C:999113>
Dec 10 21:42:37 db03 kernel: cpu: 1, clocks: 999113, slice: 199822
Dec 10 21:42:37 db03 kernel: cpu: 2, clocks: 999113, slice: 199822
Dec 10 21:42:37 db03 kernel: cpu: 3, clocks: 999113, slice: 199822
Dec 10 21:42:37 db03 kernel: CPU2<T0:999104,T1:399632,D:6,S:199822,C:999113>
Dec 10 21:42:37 db03 kernel: CPU3<T0:999104,T1:199808,D:8,S:199822,C:999113>
Dec 10 21:42:37 db03 kernel: CPU1<T0:999104,T1:599456,D:4,S:199822,C:999113>
Dec 10 21:42:37 db03 kernel: checking TSC synchronization across CPUs:
passed.
Dec 10 21:42:37 db03 kernel: Waiting on wait_init_idle (map = 0xe)
Dec 10 21:42:37 db03 kernel: All processors have done init_idle
Dec 10 21:42:37 db03 kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd32c,
last bus=8
Dec 10 21:42:37 db03 kernel: PCI: Using configuration type 1
Dec 10 21:42:37 db03 kernel: PCI: Probing PCI hardware
Dec 10 21:42:37 db03 kernel: PCI: Discovered peer bus 02
Dec 10 21:42:37 db03 kernel: PCI->APIC IRQ transform: (B0,I5,P0) -> 16
Dec 10 21:42:37 db03 kernel: PCI->APIC IRQ transform: (B0,I15,P0) -> 19
Dec 10 21:42:37 db03 kernel: PCI->APIC IRQ transform: (B2,I1,P0) -> 17
Dec 10 21:42:37 db03 kernel: PCI->APIC IRQ transform: (B2,I1,P1) -> 18
Dec 10 21:42:37 db03 kernel: PCI->APIC IRQ transform: (B2,I6,P0) -> 25
Dec 10 21:42:37 db03 kernel: Linux NET4.0 for Linux 2.4
Dec 10 21:42:37 db03 kernel: Based upon Swansea University Computer Society
NET3.039
Dec 10 21:42:37 db03 kernel: Initializing RT netlink socket
Dec 10 21:42:37 db03 kernel: Starting kswapd
Dec 10 21:42:37 db03 kernel: allocated 32 pages and 32 bhs reserved for the
highmem bounces
Dec 10 21:42:37 db03 kernel: VFS: Diskquotas version dquot_6.4.0 initialized
Dec 10 21:42:37 db03 kernel: Journalled Block Device driver loaded
Dec 10 21:42:37 db03 kernel: Installing knfsd (copyright (C) 1996
okir@monad.swb.de).
Dec 10 21:42:37 db03 kernel: pty: 256 Unix98 ptys configured
Dec 10 21:42:37 db03 kernel: Serial driver version 5.05c (2001-07-08) with
MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
Dec 10 21:42:37 db03 kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
Dec 10 21:42:37 db03 kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
Dec 10 21:42:37 db03 kernel: Uniform Multi-Platform E-IDE driver Revision:
6.31
Dec 10 21:42:37 db03 kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
Dec 10 21:42:37 db03 kernel: ServerWorks OSB4: IDE controller on PCI bus 00
dev 79
Dec 10 21:42:37 db03 kernel: ServerWorks OSB4: detected chipset, but driver
not compiled in!
Dec 10 21:42:37 db03 kernel: ServerWorks OSB4: chipset revision 0
Dec 10 21:42:37 db03 kernel: ServerWorks OSB4: not 100%% native mode: will
probe irqs later
Dec 10 21:42:37 db03 kernel: ide0: BM-DMA at 0x0700-0x0707, BIOS
settings: hda:DMA, hdb:DMA
Dec 10 21:42:37 db03 kernel: ide1: BM-DMA at 0x0708-0x070f, BIOS
settings: hdc:pio, hdd:pio
Dec 10 21:42:37 db03 kernel: hda: LG CD-ROM CRD-8484B, ATAPI CD/DVD-ROM
drive
Dec 10 21:42:37 db03 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Dec 10 21:42:37 db03 kernel: Floppy drive(s): fd0 is 1.44M
Dec 10 21:42:37 db03 kernel: FDC 0 is a National Semiconductor PC87306
Dec 10 21:42:37 db03 kernel: SCSI subsystem driver Revision: 1.00
Dec 10 21:42:37 db03 kernel: Red Hat/Adaptec aacraid driver, Dec 10 2002
Dec 10 21:42:37 db03 kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA
DRIVER, Rev 6.2.8
Dec 10 21:42:37 db03 kernel: <Adaptec aic7899 Ultra160 SCSI adapter>
Dec 10 21:42:37 db03 kernel: aic7899: Ultra160 Wide Channel A, SCSI
Id=7, 32/253 SCBs
Dec 10 21:42:37 db03 kernel:
Dec 10 21:42:37 db03 kernel: scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA
DRIVER, Rev 6.2.8
Dec 10 21:42:37 db03 kernel: <Adaptec aic7899 Ultra160 SCSI adapter>
Dec 10 21:42:37 db03 kernel: aic7899: Ultra160 Wide Channel B, SCSI
Id=7, 32/253 SCBs
Dec 10 21:42:37 db03 kernel:
Dec 10 21:42:37 db03 kernel: blk: queue f7963c18, I/O limit 4095Mb (mask
0xffffffff)
Dec 10 21:42:37 db03 kernel: scsi2 : IBM PCI ServeRAID 5.10.21 <ServeRAID
4H>
Dec 10 21:42:37 db03 kernel: Vendor: IBM Model: SERVERAID
Rev: 1.00
Dec 10 21:42:37 db03 kernel: Type: Direct-Access
ANSI SCSI revision: 02
Dec 10 21:42:37 db03 kernel: Vendor: IBM Model: SERVERAID
Rev: 1.00
Dec 10 21:42:37 db03 kernel: Type: Direct-Access
ANSI SCSI revision: 02
Dec 10 21:42:37 db03 kernel: Vendor: IBM Model: SERVERAID
Rev: 1.00
Dec 10 21:42:37 db03 kernel: Type: Processor
ANSI SCSI revision: 02
Dec 10 21:42:37 db03 kernel: Vendor: IBM Model: YGLv3 S2
Rev: 0
Dec 10 21:42:37 db03 kernel: Type: Processor
ANSI SCSI revision: 02
Dec 10 21:42:37 db03 kernel: Vendor: IBM Model: EXP300 S160
Rev: D014
Dec 10 21:42:37 db03 kernel: Type: Processor
ANSI SCSI revision: 03
Dec 10 21:42:37 db03 kernel: Vendor: IBM Model: EXP300 S160
Rev: D014
Dec 10 21:42:37 db03 kernel: Type: Processor
ANSI SCSI revision: 03
Dec 10 21:42:37 db03 kernel: megaraid: v1.18 (Release Date: Thu Oct 11
15:02:53 EDT 2001)
Dec 10 21:42:37 db03 kernel: megaraid: no BIOS enabled.
Dec 10 21:42:37 db03 kernel: Attached scsi disk sda at scsi2, channel 0, id
0, lun 0
Dec 10 21:42:37 db03 kernel: Attached scsi disk sdb at scsi2, channel 0, id
1, lun 0
Dec 10 21:42:37 db03 kernel: SCSI device sda: 35547136 512-byte hdwr sectors
(18200 MB)
Dec 10 21:42:37 db03 kernel: Partition check:
Dec 10 21:42:37 db03 kernel: sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8
>
Dec 10 21:42:37 db03 kernel: SCSI device sdb: 177735680 512-byte hdwr
sectors (91001 MB)
Dec 10 21:42:37 db03 kernel: sdb: sdb1
Dec 10 21:42:37 db03 kernel: md: raid1 personality registered as nr 3
Dec 10 21:42:37 db03 kernel: md: raid5 personality registered as nr 4
Dec 10 21:42:37 db03 kernel: raid5: measuring checksumming speed
Dec 10 21:42:37 db03 kernel: 8regs : 1291.200 MB/sec
Dec 10 21:42:37 db03 kernel: 32regs : 606.800 MB/sec
Dec 10 21:42:37 db03 kernel: pIII_sse : 1406.000 MB/sec
Dec 10 21:42:37 db03 kernel: pII_mmx : 1599.600 MB/sec
Dec 10 21:42:37 db03 kernel: p5_mmx : 1668.400 MB/sec
Dec 10 21:42:38 db03 kernel: raid5: using function: pIII_sse (1406.000
MB/sec)
Dec 10 21:42:38 db03 kernel: md: md driver 0.90.0 MAX_MD_DEVS=256,
MD_SB_DISKS=27
Dec 10 21:42:38 db03 kernel: md: Autodetecting RAID arrays.
Dec 10 21:42:38 db03 kernel: md: autorun ...
Dec 10 21:42:38 db03 kernel: md: ... autorun DONE.
Dec 10 21:42:38 db03 kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Dec 10 21:42:38 db03 kernel: IP Protocols: ICMP, UDP, TCP
Dec 10 21:42:38 db03 kernel: IP: routing cache hash table of 32768 buckets,
256Kbytes
Dec 10 21:42:38 db03 kernel: TCP: Hash tables configured (established 262144
bind 65536)
Dec 10 21:42:38 db03 kernel: NET4: Unix domain sockets 1.0/SMP for Linux
NET4.0.
Dec 10 21:42:38 db03 kernel: VFS: Mounted root (ext2 filesystem) readonly.
Dec 10 21:42:38 db03 kernel: Freeing unused kernel memory: 108k freed
Dec 10 21:42:38 db03 kernel: Real Time Clock Driver v1.10e
Dec 10 21:42:38 db03 kernel: Adding Swap: 2097136k swap-space (priority -1)
Dec 10 21:42:38 db03 kernel: pcnet32.c:v1.27b 01.10.2002
tsbogend@alpha.franken.de
Dec 10 21:42:38 db03 kernel: pcnet32: PCnet/FAST III 79C975 at 0x2200, 00 02
55 fc 32 5c assigned IRQ 16.
Dec 10 21:42:38 db03 kernel: eth0: registered as PCnet/FAST III 79C975
Dec 10 21:42:38 db03 kernel: pcnet32: 1 cards_found.
Dec 10 21:42:38 db03 kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
Dec 10 21:42:39 db03 xinetd: xinetd startup succeeded
Dec 10 21:42:40 db03 sendmail: sendmail startup succeeded
Dec 10 21:42:40 db03 crond: crond startup succeeded
Dec 10 21:42:40 db03 atd: atd startup succeeded
Dec 10 21:42:41 db03 su(pam_unix)[789]: session opened for user db2admin by
(uid=0)
Dec 10 21:42:44 db03 su(pam_unix)[789]: session closed for user db2admin
Dec 10 21:42:44 db03 su(pam_unix)[875]: session opened for user db2iholy by
(uid=0)
Dec 10 21:42:46 db03 su(pam_unix)[875]: session closed for user db2iholy
Dec 10 21:42:46 db03 su(pam_unix)[940]: session opened for user db2ijava by
(uid=0)
Dec 10 21:42:47 db03 su(pam_unix)[940]: session closed for user db2ijava
Dec 10 21:42:47 db03 su(pam_unix)[1005]: session opened for user db2ietsb by
(uid=0)
Dec 10 21:42:49 db03 su(pam_unix)[1005]: session closed for user db2ietsb
CONFIG_X86=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_MPENTIUMIII=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_F00F_WORKS_OK=y
CONFIG_X86_MCE=y
CONFIG_MICROCODE=m
CONFIG_HIGHMEM4G=y
CONFIG_HIGHMEM=y
CONFIG_HIGHIO=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_X86_TSC=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_HOTPLUG=y
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_IBM=m
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_1284=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_STATS=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID5=y
CONFIG_MD_MULTIPATH=m
CONFIG_BLK_DEV_LVM=m
CONFIG_PACKET=y
CONFIG_NETFILTER=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IPV6=m
CONFIG_IP6_NF_QUEUE=m
CONFIG_ATALK=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=m
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_AHA1740=m
CONFIG_SCSI_AACRAID=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
CONFIG_SCSI_MEGARAID=y
CONFIG_SCSI_GDTH=y
CONFIG_SCSI_IPS=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_EEPRO100=y
CONFIG_NE2K_PCI=m
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_SHAPER=m
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SERIAL_EXTENDED=y
CONFIG_SERIAL_MANY_PORTS=y
CONFIG_SERIAL_SHARE_IRQ=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
CONFIG_WATCHDOG=y
CONFIG_SOFT_WATCHDOG=m
CONFIG_RTC=m
CONFIG_QUOTA=y
CONFIG_AUTOFS4_FS=y
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_CODA_FS=m
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPfZxrVcv4X0c4GKrEQJ5WACfZvlo9cK/se4vxUVx0uOuYRoIlrEAn2/9
TOMLYwBnm6iHgKqu5a+K9BWO
=v4EB
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 3/3] High-res-timers part 3 (posix to hrposix) take 20
From: george anzinger @ 2002-12-10 22:57 UTC (permalink / raw)
To: Joe Korty; +Cc: Andrew Morton, Linus Torvalds, linux-kernel@vger.kernel.org
In-Reply-To: <200212101514.PAA15602@rudolph.ccur.com>
Joe Korty wrote:
>
> [ repost - first attempt failed to get out ]
>
> > > Is the "don't reuse an ID for some time" requirement still there?
> >
> > I don't see the need for the "don't reuse an ID for some
> > time" thing and it looked like what Jim had messed up the
> > book keeping AND it also looked like it failed to actually
> > work. All of this convinced me that the added complexity
> > was just not worth it.
>
> A thought: any algorithm that fails to "reuse an ID for some time"
> can be converted into one that does by tweaking the algorithn to
> return an ID with fewer bits and putting a counter (bumped on each
> fresh allocation of that ID) in the remaining bits. Or, one can go
> stateless and achieve an "almost never reuse an ID for some time" by
> instead inserting a freshly generated pseudo-random number in the
> unused ID bits.
>
With out going into a lot of detail, since I don't think I
need such an animal, one would need to keep the actual id
somewhere (either the node or in what it pointed to).
Perhaps a less costly way would be to keep a sequence
number, say the number of items allocated so far and
inserting that. I think one would want to make sure this is
not a power of 2, but this may not be needed as the first
freeing would generate an indexing of the number WRT to the
id.
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Hanging Init
From: Pagnotta, Chris @ 2002-12-10 22:52 UTC (permalink / raw)
To: linuxppc-embedded
I figure I am at the last stage in boot (I hope). I am however having an
issue that I was hoping someone
may shed some light on. I am having a hanging init.
1) I rebuilt busybox and here are the dependencies:
lb-deviant-linux:/home/eldk/eldk-ppc-linux-x86-2.0.2/usr/bin#
./ppc-linux-strings /tftpboot/powerpc/bin/busybox | grep lib /lib/ld.so.1
libc.so.6
/lib/modules/
2) Here is the lib. Everything seems ok here
lb-deviant-linux:/home/eldk/eldk-ppc-linux-x86-2.0.2/usr/bin# ls -l
/tftpboot/powerpc/lib
total 1990
-rwxr-xr-x 1 root root 453086 Dec 9 07:59 ld-2.2.5.so
lrwxrwxrwx 1 root root 11 Dec 9 08:00 ld.so -> ld-2.2.5.so
lrwxrwxrwx 1 root root 11 Dec 9 08:00 ld.so.1 ->
ld-2.2.5.so
-rwxr-xr-x 1 root root 1325740 Nov 25 08:20 libc-2.2.5.so
lrwxrwxrwx 1 root root 9 Nov 26 08:19 libc.so -> libc.so.6
lrwxrwxrwx 1 root root 13 Nov 20 09:50 libc.so.6 ->
libc-2.2.5.so
-rwxr-xr-x 1 root root 246266 Dec 10 12:25
libnss_files-2.2.5.so
lrwxrwxrwx 1 root root 21 Dec 10 12:27 libnss_files.so.2 ->
libnss_files-2.2.5.so
3) Here is the output from PPCBoot. It looks like NFS mount was successfull.
I am using
NFS mount server that run in user space NOT kernel. Don't know of this
makes any difference,
but I was able to NFS mount the directory from another machine.
mount -t nfs 172.25.4.55:/tftpboot/powerpc/ /mnt/nfs.
=> tftpboot
ENET Speed is 10 Mbps - HALF duplex connection
ARP broadcast 1
TFTP from server 172.25.4.55; our IP address is 172.25.4.57
Filename '/tftpboot/powerpc/vmlinux.PPCBoot'.
Load address: 0x400000
Loading: *\b########################################T ###################T
######
#################################################################
############################################
done
Bytes transferred = 888431 (d8e6f hex)
=> boots
** Device 0 not available
## Booting image at 00400000 ...
Image Name: Linux-2.4.19-pre6
Created: 2002-12-09 15:28:09 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 888367 Bytes = 867 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
arch: exit
Linux version 2.4.19-pre6 (cpagnotta@lb-deviant-linux) (gcc version 2.95.4
20010319 (prerelease/franzo/20011204)) #10 Mon Dec 9 07:26:53 PST 2002
On node 0 totalpages: 32768
zone(0): 4096 pages.
zone(1): 28672 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs nfsroot=/tftpboot/powerpc
ip=172.25.4.57:172.25.4.55:172.25.4.55:255.255.0.0:lb-vib-linux::off
Calibrating delay loop... 263.78 BogoMIPS
Memory: 127124k available (1504k kernel code, 668k data, 208k init, 0k
highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
PCI: moved device 00:06.1 resource 4 (101) to 1000
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications
AB.
i2c-core.o: i2c core module
i2c-dev.o: i2c /dev entries driver module
i2c-core.o: driver i2c-dev dummy driver registered.
i2c-proc.o version 2.6.1 (20010825)
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
ttyS00 at 0xef600300 (irq = 0) is a 16550A
ttyS01 at 0xef600400 (irq = 1) is a 16550A
ttyS02 at 0xf4100000 (irq = 26) is a ST16650V2
ttyS03 at 0xf4200000 (irq = 26) is a ST16650V2
PPC 405 watchdog driver v0.5
IBM gpio driver version 02.01.21.d
GPIO #0 at 0xc900d700
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: Phy @ 0x1, type LXT971A (0x001378e2)
pcnet32.c:v1.27a 10.02.2002 tsbogend@alpha.franken.de
Equalizer1996: $Revision: 1.2.1 $ $Date: 1996/09/22 13:52:00 $ Simon Janes
(simon@ncm.com)
Universal TUN/TAP device driver 1.4 (C)1999-2001 Maxim Krasnyansky
NFTL driver: nftlcore.c $Revision: 1.85 $, nftlmount.c $Revision: 1.25 $
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
Reset ethernet interfaces
eth0: IBM EMAC: link up, 10 Mbps Half Duplex, auto-negotiation complete.
eth0: IBM EMAC: MAC 00:60:c2:0a:00:1f.
eth0: IBM EMAC: open completed
IP-Config: Complete:
device=eth0, addr=172.25.4.57, mask=255.255.0.0, gw=172.25.4.55,
host=lb-vib-linux, domain=, nis-domain=(none),
bootserver=172.25.4.55, rootserver=172.25.4.55, rootpath=
ip_conntrack (1024 buckets, 8192 max)
ip_tables: (C) 2000-2002 Netfilter core team
arp_tables: (C) 2002 David S. Miller
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Root-NFS: Mounting /tftpboot/powerpc on server 172.25.4.55 as root
Root-NFS: rsize = 4096, wsize = 4096, timeo = 7, retrans = 3
Root-NFS: acreg (min,max) = (3,60), acdir (min,max) = (30,60)
Root-NFS: nfsd port = -1, mountd port = 0, flags = 00000200
Looking up port of RPC 100003/2 on 172.25.4.55
Root-NFS: Portmapper on server returned 2049 as nfsd port
Looking up port of RPC 100005/1 on 172.25.4.55
Root-NFS: mountd port is 812
NFS: nfs_mount(ac190437:/tftpboot/powerpc)
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 208k init (We are just in a hang state)
init does not seem to be executed.
Here is one more thing from my exports dir
/tftpboot/powerpc 172.25.0.0/255.255.0.0(rw,no_root_squash)
Please let me know if you have any suggestions.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* You can be of assistance please.
From: Dr.Edward Daggash @ 2002-12-10 22:55 UTC (permalink / raw)
To: ed50daggash
Senator (Dr.)Edward Daggash
Chairman Senate Committee on
Public Accounts.
Senate Building Apo Quarters,Abuja.
Sir,
Firstly let me solicit for your strictest confidence in this matter as I know,that this might come to you as a surprise.I am Senator (Dr.)Edward Daggash ,chairman of the senate committee on public accounts, of the Federal republic of Nigeria.
I am equally a close friend and confidant of the embattled Senate President of the Federal Republic of Nigeria, Senator Chief Anyim Pius Anyim.As you may be aware.presently the Senate President and a fellow Senator and unfortunately his kinsman,Senator Arthur Nzeribe,is
having a face off,which have resulted in the two parties calling each other several unprintable names.This has actually brought the person and the position of the senate presidency to ridicule.As I am writing this letter to you .The Senate President is considering resigning,his
position,before he is disgraced out of office,he is presently out of the country for fear of been prosecuted as he was billed to face trial at the independent corrupt practices commission,(ICPC),otherwise known as anti-corruption commission.
My friend,in confidence, the embattled senate President called me today from his base.and told me that before he left,that he deposited the total amount of USD10.5M in a security company ,(Though not in his name)which has branches in Europe and that I should assist him scout for a foreigner,who will,open communication with the security company in Europe,possibly visit the security company on his behalf,follow his instructions and lay claims over the funds,then transfer the funds to a safer offshore account for him.This is important as he is not sure of the out
come of his present predicament.
The good thing about it all is that he deposited the funds in the name of his foreigner friend (MR ALAN TASCA) with the view of contacting Alan to do exactly what he wants you to do for him now.But unfortunately for him,On getting through to Alan!/s family,he was told that his good
friend (Alan)died of cancer a day before.Actually he said he was not surprised as his friend have been leaving with this deadly disease for years.This actually threw Chief Anyim into confusion.But be it as it may,like he said life most continue.
So we are soliciting for your assistance to help us,visit the security company!/s office here in Nigeria or in Europe,precisely Spain and Netherland.lay claims over this funds as,Alan Tasca ,make the transfer of
this funds into your account yourself,then open communication with Chief Anyim through his lawyers for further discussion,basically on the future investment plans, as he wishes to invest the money in your country.
All necessary documentation will be secured to back you,as the bonafide beneficiary of the funds.Nevertheless for your assistance,we are offering you a certain percentage of the entire amount.However,this is negotiable,but we are considering between 15-20% of the entire funds for you
and 5% will be set aside incase,should incidental expenses be
incurred,to take care of the expenses, at the end of the transaction.This is important,as it may interest you to know,that the funds are bonded.The
remaining, will be for us with which we intend to go into any lucrative business in your country based on your advise.
However it is imperative to know that Chief Anyim do not wish to be mentioned in connection with this transaction,as you are to deal strictly with his lawyers and the security company.While he will be at the background to confirm things to the security firm.
You are advised to contact me immediately via e-mail,to enable me furnish you with the contact informations of Chief Anyim!/s lawyers,for further instructions.Your response will be appreciated,whether you are interested or not,at least for courtesy sake and also to enable us know exactly what your position is(positive or negative)to enable us move
ahead.While replying please include your phone(Including cell phones, if available) and fax numbers ,to facilitate communications.I await your response immediately.Thanks and God Bless.
Yours in service,
Senator(Dr)Edward Daggash
_______________________________________________________
EC Plaza!!!
The world's No.1 B2B site, http://www.ecplaza.net
_______________________________________________________
EC Plaza!!!
The world's No.1 B2B site, http://www.ecplaza.net
[[HTML alternate version deleted]]
^ permalink raw reply
* NAND and concat
From: Christian Gan @ 2002-12-10 23:29 UTC (permalink / raw)
To: linux-mtd, yaffs list
In-Reply-To: <1039541302.8122.40.camel@timmy>
Quick, but possibly loaded question:
Is anyone working on concat for NAND flashes? I looked though and realised
that there is no functionality at the moment for NAND (i.e. no support for
read/write oob etc).
^ permalink raw reply
* Re: [PATCH] compatibility syscall layer (lets try again)
From: george anzinger @ 2002-12-10 23:07 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Linus Torvalds, Jim Houston, Stephen Rothwell, LKML, anton,
David S. Miller, ak, davidm, schwidefsky, ralf, willy
In-Reply-To: <20021209154142.GA22901@nevyn.them.org>
Daniel Jacobowitz wrote:
>
> On Fri, Dec 06, 2002 at 09:57:08AM -0800, Linus Torvalds wrote:
> >
> > I just pushed my version of the system call restart code to the BK trees.
> > It's losely based on Georges code, but subtly different. Also, I didn't
> > actually update any actual system calls to use it, I just did the
> > infrastructure.
> >
> > Non-x86 architectures need to be updated to work with this: they need to
> > update their thread structures, the additional do_signal() support in
> > their signal.c, and add the actual system call itself somewhere. For x86,
> > this was about 15 lines of changes.
> >
> > The basic premise is very simple: if you want to restart a system call,
> > you can do
> >
> > restart = ¤t_thread()->restart_block;
> > restart->fn = my_continuation_function;
> > restart->arg0 = my_arg0_for_continuation;
> > restart->arg1 = my_arg1_for_continuation;
> > ..
> > return -ERESTARTSYS_RESTARTBLOCK;
> >
> > which will cause the system call to either return -EINTR (if a signal
> > handler was actually invoced) or for "benign" signals (SIGSTOP etc) it
> > will end up restarting the system call at the continuation function (with
> > the "restart" block as the argument).
> >
> > We could extend this to allow restarting even over signal handlers, but
> > that would have some re-entrancy issues (ie what happens if a signal
> > handler itself wants to use a system call that may want restarting), so at
> > least for now restarting is only done when no handler is invoced (*).
> >
> > Linus
> >
> > (*) The nesting case is by no means impossible to handle gracefully
> > (adding a "restart even if handler is called" error number and returning
> > -EINTR if nesting, for example), but I don't know of any system calls that
> > would really want to try to restart anyway, so..
>
> Well, here's something to consider. This isn't entirely hypothetical;
> there are test cases in GDB's regression suite that cover nearly this.
>
> Suppose a process is sleeping for an hour. The user wants to see what
> another thread is doing, so he hits Control-C; the thread which happens
> to be reported as 'current' is the one that was in nanosleep(). It
> used to be that when he said continue, the nanosleep would return; now
> hopefully it'll continue. Great! But this damnable user isn't done
> yet. He wants to look at one of his data structures. He calls a
> debugging print_foo() function from GDB. He realizes he left a
> sleep-for-a-minute nanosleep call in it and C-c's again. Now we have
> two interrupted nanosleep calls and the application will never see a
> signal to interrupt either of them; he says "continue" twice and
> expects to get back to his hour-long sleep.
>
> Note that I'm not saying we _need_ to support this, mind :) It's a
> little pathological.
I seem to recall working on a debugger in the distant past
and put a lock in it that did not allow it to run a debuggee
function while the debugee was in a system call. It seems
to me that is is begging for problems and is not that hard
for gdb/etc to prevent.
Daniel, what to you think?
-g
>
> Another thing that annoys me slightly about this is that we mess with
> the value in orig_eax etc. Now a debugger would have to look at the
> instruction stream to figure out what the syscall was that we're
> stopped in, reliably. Not a big deal.
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* [Fwd: [BENCHMARK] AIM9 results]
From: Hans Reiser @ 2002-12-10 23:04 UTC (permalink / raw)
To: ReiserFS, Paolo Ciarrocchi, mason
[-- Attachment #1: Type: text/plain, Size: 107 bytes --]
thanks for your interesting results. Chris and Oleg can probably
comment best, so I will let them do so.
[-- Attachment #2: [BENCHMARK] AIM9 results --]
[-- Type: message/rfc822, Size: 15761 bytes --]
From: "Paolo Ciarrocchi" <ciarrocchi@linuxmail.org>
To: linux-kernel@vger.kernel.org
Cc: akpm@digeo.com
Subject: [BENCHMARK] AIM9 results
Date: Wed, 11 Dec 2002 06:10:23 +0800
Message-ID: <20021210221023.16603.qmail@linuxmail.org>
Hi all,
file system is reiserfs.
2.4.19
2.5.50
2.5.51
add_double 10030 23.9282 430707.88 Thousand Double Precision Additions/second
add_double 10040 23.7052 426693.23 Thousand Double Precision Additions/second
add_double 10030 23.7288 427118.64 Thousand Double Precision Additions/second
add_float 10000 35.9 430800.00 Thousand Single Precision Additions/second
add_float 10010 35.5644 426773.23 Thousand Single Precision Additions/second
add_float 10010 35.5644 426773.23 Thousand Single Precision Additions/second
add_long 10010 22.1778 1330669.33 Thousand Long Integer Additions/second
add_long 10020 21.9561 1317365.27 Thousand Long Integer Additions/second
add_long 10020 21.9561 1317365.27 Thousand Long Integer Additions/second
add_int 10020 22.0559 1323353.29 Thousand Integer Additions/second
add_int 10010 21.8781 1312687.31 Thousand Integer Additions/second
add_int 10020 21.8563 1311377.25 Thousand Integer Additions/second
add_short 10000 55.4 1329600.00 Thousand Short Integer Additions/second
add_short 10010 54.8452 1316283.72 Thousand Short Integer Additions/second
add_short 10000 54.9 1317600.00 Thousand Short Integer Additions/second
creat-clo 10040 19.4223 19422.31 File Creations and Closes/second
creat-clo 10040 17.4303 17430.28 File Creations and Closes/second
creat-clo 10010 87.2128 87212.79 File Creations and Closes/second
^^^^Big change here!
page_test 10000 123.9 210630.00 System Allocations & Pages/second
page_test 10000 104.8 178160.00 System Allocations & Pages/second
page_test 10000 105.7 179690.00 System Allocations & Pages/second
^^^ still slower than 2.4.19
brk_test 10010 48.951 832167.83 System Memory Allocations/second
brk_test 10000 44.5 756500.00 System Memory Allocations/second
brk_test 10020 44.6108 758383.23 System Memory Allocations/second
^^^ still slower than 2.4.19
jmp_test 10000 4313.7 4313700.00 Non-local gotos/second
jmp_test 10000 4272.6 4272600.00 Non-local gotos/second
jmp_test 10000 4273.2 4273200.00 Non-local gotos/second
signal_test 10000 166.1 166100.00 Signal Traps/second
signal_test 10000 125.5 125500.00 Signal Traps/second
signal_test 10000 157.4 157400.00 Signal Traps/second
^^^2.5.51 is better than 2.5.50 but 2.4.19 is faster
exec_test 10000 13.8 69.00 Program Loads/second
exec_test 10040 12.9482 64.74 Program Loads/second
exec_test 10020 12.9741 64.87 Program Loads/second
^^^2.5.* is slower than 2.4.19
fork_test 10000 44.8 4480.00 Task Creations/second
fork_test 10010 25.7742 2577.42 Task Creations/second
fork_test 10020 23.9521 2395.21 Task Creations/second
^^^ Very slow here
link_test 10000 155.3 9783.90 Link/Unlink Pairs/second
link_test 10010 141.658 8924.48 Link/Unlink Pairs/second
link_test 10000 147.7 9305.10 Link/Unlink Pairs/second
^^^ I don't know the meaning of this test, but 2.5.* is slower than 2.4.19
disk_rr 10050 6.96517 35661.69 Random Disk Reads (K)/second
disk_rr 10120 7.31225 37438.74 Random Disk Reads (K)/second
disk_rr 10110 7.51731 38488.63 Random Disk Reads (K)/second
disk_rw 10060 5.666 29009.94 Random Disk Writes (K)/second
disk_rw 10120 6.62055 33897.23 Random Disk Writes (K)/second
disk_rw 10000 6.8 34816.00 Random Disk Writes (K)/second
disk_rd 10010 38.1618 195388.61 Sequential Disk Reads (K)/second
disk_rd 10020 38.024 194682.63 Sequential Disk Reads (K)/second
disk_rd 10020 38.024 194682.63 Sequential Disk Reads (K)/second
disk_wrt 10100 8.51485 43596.04 Sequential Disk Writes (K)/second
disk_wrt 10020 9.08184 46499.00 Sequential Disk Writes (K)/second
disk_wrt 10070 9.43396 48301.89 Sequential Disk Writes (K)/second
disk_cp 10120 7.31225 37438.74 Disk Copies (K)/second
disk_cp 10010 7.49251 38361.64 Disk Copies (K)/second
disk_cp 10010 7.69231 39384.62 Disk Copies (K)/second
sync_disk_rw 16020 0.062422 159.80 Sync Random Disk Writes (K)/second
sync_disk_rw 14500 0.0689655 176.55 Sync Random Disk Writes (K)/second
sync_disk_rw 18790 0.0532198 136.24 Sync Random Disk Writes (K)/second
sync_disk_wrt 11220 0.0891266 228.16 Sync Sequential Disk Writes (K)/second
sync_disk_wrt 10240 0.0976562 250.00 Sync Sequential Disk Writes (K)/second
sync_disk_wrt 10150 0.0985222 252.22 Sync Sequential Disk Writes (K)/second
sync_disk_cp 10870 0.0919963 235.51 Sync Disk Copies (K)/second
sync_disk_cp 19900 0.100503 257.29 Sync Disk Copies (K)/second
sync_disk_cp 19580 0.102145 261.49 Sync Disk Copies (K)/second
disk_src 10000 118.2 8865.00 Directory Searches/second
disk_src 10010 109.191 8189.31 Directory Searches/second
disk_src 10010 110.889 8316.68 Directory Searches/second
div_double 10000 24.4 73200.00 Thousand Double Precision Divides/second
div_double 10020 24.1517 72455.09 Thousand Double Precision Divides/second
div_double 10020 24.1517 72455.09 Thousand Double Precision Divides/second
div_float 10010 24.3756 73126.87 Thousand Single Precision Divides/second
div_float 10020 24.1517 72455.09 Thousand Single Precision Divides/second
div_float 10010 24.1758 72527.47 Thousand Single Precision Divides/second
div_long 10020 19.9601 17964.07 Thousand Long Integer Divides/second
div_long 10010 19.7802 17802.20 Thousand Long Integer Divides/second
div_long 10020 19.7605 17784.43 Thousand Long Integer Divides/second
div_int 10020 19.9601 17964.07 Thousand Integer Divides/second
div_int 10020 19.7605 17784.43 Thousand Integer Divides/second
div_int 10010 19.7802 17802.20 Thousand Integer Divides/second
div_short 10030 19.9402 17946.16 Thousand Short Integer Divides/second
div_short 10020 19.7605 17784.43 Thousand Short Integer Divides/second
div_short 10020 19.7605 17784.43 Thousand Short Integer Divides/second
fun_cal 10000 62.5 32000000.00 Function Calls (no arguments)/second
fun_cal 10000 61.9 31692800.00 Function Calls (no arguments)/second
fun_cal 10000 61.9 31692800.00 Function Calls (no arguments)/second
fun_cal1 10000 170.4 87244800.00 Function Calls (1 argument)/second
fun_cal1 10000 169 86528000.00 Function Calls (1 argument)/second
fun_cal1 10010 168.831 86441558.44 Function Calls (1 argument)/second
fun_cal2 10000 112.5 57600000.00 Function Calls (2 arguments)/second
fun_cal2 10010 111.389 57030969.03 Function Calls (2 arguments)/second
fun_cal2 10000 111.5 57088000.00 Function Calls (2 arguments)/second
fun_cal15 10010 34.0659 17441758.24 Function Calls (15 arguments)/second
fun_cal15 10010 33.7662 17288311.69 Function Calls (15 arguments)/second
fun_cal15 10010 33.7662 17288311.69 Function Calls (15 arguments)/second
sieve 10450 0.861244 4.31 Integer Sieves/second
sieve 10620 0.847458 4.24 Integer Sieves/second
sieve 10600 0.849057 4.25 Integer Sieves/second
mul_double 10020 21.5569 258682.63 Thousand Double Precision Multiplies/second
mul_double 10030 21.336 256031.90 Thousand Double Precision Multiplies/second
mul_double 10020 21.3573 256287.43 Thousand Double Precision Multiplies/second
mul_float 10030 21.5354 258424.73 Thousand Single Precision Multiplies/second
mul_float 10030 21.336 256031.90 Thousand Single Precision Multiplies/second
mul_float 10030 21.336 256031.90 Thousand Single Precision Multiplies/second
mul_long 10000 947.7 227448.00 Thousand Long Integer Multiplies/second
mul_long 10000 939.6 225504.00 Thousand Long Integer Multiplies/second
mul_long 10000 939.6 225504.00 Thousand Long Integer Multiplies/second
mul_int 10000 951.9 228456.00 Thousand Integer Multiplies/second
mul_int 10000 941.2 225888.00 Thousand Integer Multiplies/second
mul_int 10000 943.2 226368.00 Thousand Integer Multiplies/second
mul_short 10000 759.1 227730.00 Thousand Short Integer Multiplies/second
mul_short 10000 753.3 225990.00 Thousand Short Integer Multiplies/second
mul_short 10000 753.4 226020.00 Thousand Short Integer Multiplies/second
num_rtns_1 10000 467.2 46720.00 Numeric Functions/second
num_rtns_1 10000 463.8 46380.00 Numeric Functions/second
num_rtns_1 10000 463.8 46380.00 Numeric Functions/second
trig_rtns 10010 28.6713 286713.29 Trigonometric Functions/second
trig_rtns 10020 28.3433 283433.13 Trigonometric Functions/second
trig_rtns 10020 28.3433 283433.13 Trigonometric Functions/second
matrix_rtns 10000 5964.3 596430.00 Point Transformations/second
matrix_rtns 10000 5904.9 590490.00 Point Transformations/second
matrix_rtns 10000 5906.8 590680.00 Point Transformations/second
array_rtns 10010 13.6863 273.73 Linear Systems Solved/second
array_rtns 10050 13.5323 270.65 Linear Systems Solved/second
array_rtns 10010 13.2867 265.73 Linear Systems Solved/second
string_rtns 10060 9.04573 904.57 String Manipulations/second
string_rtns 10050 8.95522 895.52 String Manipulations/second
string_rtns 10050 8.95522 895.52 String Manipulations/second
mem_rtns_1 10000 27.7 831000.00 Dynamic Memory Operations/second
mem_rtns_1 10020 23.4531 703592.81 Dynamic Memory Operations/second
mem_rtns_1 10010 24.975 749250.75 Dynamic Memory Operations/second
^^^ 2.5.51 is faster than 2.5.50 but is not fast as 2.4.19
mem_rtns_2 10000 1632.5 163250.00 Block Memory Operations/second
mem_rtns_2 10000 1631.9 163190.00 Block Memory Operations/second
mem_rtns_2 10000 1631.8 163180.00 Block Memory Operations/second
sort_rtns_1 10020 33.6327 336.33 Sort Operations/second
sort_rtns_1 10010 33.0669 330.67 Sort Operations/second
sort_rtns_1 10010 33.0669 330.67 Sort Operations/second
misc_rtns_1 10000 782.2 7822.00 Auxiliary Loops/second
misc_rtns_1 10000 713.8 7138.00 Auxiliary Loops/second
misc_rtns_1 10000 738 7380.00 Auxiliary Loops/second
^^^ 2.5.* is still slow
dir_rtns_1 10000 85.8 858000.00 Directory Operations/second
dir_rtns_1 10010 73.7263 737262.74 Directory Operations/second
dir_rtns_1 10000 96.9 969000.00 Directory Operations/second
^^^ Good result here for 2.5.51
shell_rtns_1 10020 25.9481 25.95 Shell Scripts/second
shell_rtns_1 10000 23.9 23.90 Shell Scripts/second
shell_rtns_1 10030 24.1276 24.13 Shell Scripts/second
shell_rtns_2 10010 26.0739 26.07 Shell Scripts/second
shell_rtns_2 10010 23.976 23.98 Shell Scripts/second
shell_rtns_2 10000 24.1 24.10 Shell Scripts/second
shell_rtns_3 10010 26.0739 26.07 Shell Scripts/second
shell_rtns_3 10030 23.9282 23.93 Shell Scripts/second
shell_rtns_3 10000 24.1 24.10 Shell Scripts/second
series_1 10000 31924.9 3192490.00 Series Evaluations/second
series_1 10000 31644.6 3164460.00 Series Evaluations/second
series_1 10000 31651.5 3165150.00 Series Evaluations/second
shared_memory 10000 2227.4 222740.00 Shared Memory Operations/second
shared_memory 10000 1935.9 193590.00 Shared Memory Operations/second
shared_memory 10000 1987.5 198750.00 Shared Memory Operations/second
^^^ Slow
tcp_test 10000 661.7 59553.00 TCP/IP Messages/second
tcp_test 10000 537.6 48384.00 TCP/IP Messages/second
tcp_test 10000 558.7 50283.00 TCP/IP Messages/second
^^^Debug I guess
udp_test 10000 1182.7 118270.00 UDP/IP DataGrams/second
udp_test 10000 994.6 99460.00 UDP/IP DataGrams/second
udp_test 10000 972.3 97230.00 UDP/IP DataGrams/second
^^^Debug I guess
fifo_test 10000 1207 120700.00 FIFO Messages/second
fifo_test 10000 991.2 99120.00 FIFO Messages/second
fifo_test 10000 1052.3 105230.00 FIFO Messages/second
^^^ Slow
stream_pipe 10000 2418.6 241860.00 Stream Pipe Messages/second
stream_pipe 10000 2161.5 216150.00 Stream Pipe Messages/second
stream_pipe 10000 2281.5 228150.00 Stream Pipe Messages/second
^^^ 2.5.51 is better than 2.5.50, but 2.4.19 is the winner
dgram_pipe 10000 2357.8 235780.00 DataGram Pipe Messages/second
dgram_pipe 10000 2132.4 213240.00 DataGram Pipe Messages/second
dgram_pipe 10000 2112.2 211220.00 DataGram Pipe Messages/second
^^^ Slow
pipe_cpy 10000 3918 391800.00 Pipe Messages/second
pipe_cpy 10000 3137.1 313710.00 Pipe Messages/second
pipe_cpy 10000 3139 313900.00 Pipe Messages/second
^^^ Slow
ram_copy 10000 19338.7 483854274.00 Memory to Memory Copy/second
ram_copy 10000 19158.1 479335662.00 Memory to Memory Copy/second
ram_copy 10000 19160.9 479405718.00 Memory to Memory Copy/second
--
______________________________________________
http://www.linuxmail.org/
Now with POP3/IMAP access for only US$19.95/yr
Powered by Outblaze
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: module-init-tools 0.9.3 -- "missing" issue
From: Rusty Russell @ 2002-12-10 22:59 UTC (permalink / raw)
To: ALESSANDRO.SUARDI; +Cc: linux-kernel
In-Reply-To: <2105495.1039535073217.JavaMail.nobody@web55.us.oracle.com>
In message <2105495.1039535073217.JavaMail.nobody@web55.us.oracle.com> you writ
e:
> As per the README...
>
> [asuardi@dolphin module-init-tools-0.9.3]$ aclocal
> [asuardi@dolphin module-init-tools-0.9.3]$ automake --add-missing --copy
> Makefile.am: installing `./depcomp'
> [asuardi@dolphin module-init-tools-0.9.3]$ autoconf
> [asuardi@dolphin module-init-tools-0.9.3]$ ./configure --prefix=/
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> /download/kernel/v2.5/module-init-tools-0.9.3/missing: Unknown `--run' option
> Try `/download/kernel/v2.5/module-init-tools-0.9.3/missing --help' for more i
nformation
Hmm, you don't need to run aclocal, automake and autoconf if you don't
alter the sources. I have altered the README to put that at the
bottom:
5) If you want to hack on the source:
aclocal && automake --add-missing --copy && autoconf
Thanks for the report!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: [PATCH] compatibility syscall layer (lets try again)
From: george anzinger @ 2002-12-10 23:11 UTC (permalink / raw)
To: Paul Mackerras
Cc: Linus Torvalds, Mikael Starvik, 'Daniel Jacobowitz',
'Jim Houston', 'LKML', 'anton@samba.org',
'David S. Miller', 'ak@muc.de',
'davidm@hpl.hp.com', 'schwidefsky@de.ibm.com',
'ralf@gnu.org', 'willy@debian.org'
In-Reply-To: <15861.12698.361774.252071@argo.ozlabs.ibm.com>
Paul Mackerras wrote:
>
> Linus Torvalds writes:
>
> > Note that I've not committed the patch to my tree at all, and as far as I
> > am concerned this is in somebody elses court (ie somebody that cares about
> > restarting). I don't have any strong feelings either way about how
> > restarting should work - and I'd like to have somebody take it up and
> > testing it as well as having architecture maintainers largely sign off on
> > this approach.
>
> There is a simpler way to solve the nanosleep problem which doesn't
> involve any more restart magic than we have been using for years.
> That is to define a new sys_new_nanosleep system call which takes one
> argument which is a pointer to the time to sleep. If the sleep gets
> interrupted by a pending signal, the kernel sys_new_nanosleep will
> write back the remaining time (overwriting the requested time) and
> return -ERESTARTNOHAND. The glibc nanosleep() then looks like this:
>
> int nanosleep(const struct timespec *req, struct timespec *rem)
> {
> *rem = *req;
> return new_nanosleep(rem);
> }
>
> Any reason why this can't work?
>
> (BTW this is Rusty's idea. :)
>
This all started because the standard says nano_sleep should
wake up delta time from when it went to sleep. To this one
would need to save the absolute time, not the time
remaining. In other words, while ptrace or what ever are
doing there thing, time IS passing.
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: AW: RFC - new raid superblock layout for md driver
From: Neil Brown @ 2002-12-10 23:07 UTC (permalink / raw)
To: Martin Bene; +Cc: linux-raid
In-Reply-To: <4D618F6493CE064A844A5D496733D66703158F@freedom.icomedias.com>
On Tuesday December 10, martin.bene@icomedias.com wrote:
> Hi Neil,
>
> > When a raid1 array is out of sync, it doesn't mean anything to say
> > which disc is out of sync. They all are, with each other...
> > Nonetheless, the per-device stateflags have an 'in-sync' bit which can
> > be set or cleared as appropriate.
>
> Not quite, esp. not in the case of interrupted sync. in that case you've got
> one disk with valid data and another disk known to contain nothing usable.
>
> Disk1 Disk2
> aaaaaaaaaa aaaaabbbbb
>
> If the information that disk2 is currently NOT usable isn't preserved bad
> things might happen on resume - I don't think a result of
>
> Disk1 Disk2
> aaaaabbbbb aaaaabbbbb
>
> after resync finishes would make anyone especially happy :-)
I think we are using different terminology.
There are two similar but different proccesses that a raid1 array
can go though: resync and recovery.
Resync happens after an unclean shutdown. Most of the data is exactly
the same of both (all) drives. In the few cases of differences, it is
not meaningful to say which is correct. Hopefully the file filesystem
will be careful about using this data (either through journal
techniques or via fsck). At start-up you have to arbitrarily choose
one, and it really doesn't matter which one, and make sure that the
other drive(s) have the same data.
Recovery happens after a drive has failed and a spare is being build.
This is the case you seem to be talking about. I don't call it
resync, and neither does /proc/mdstat. We call it 'recovery'.
In this case, you obviously need to know which drive is being
recoverred on-to.
In the 0.90.0 superblock, this is done by leaving it marked as a spare
until the rebuild in complete.
In the new version-1 superblock this id done by using a per-device
'in-sync' flag.
The 2.5 code already uses this model, but writes out 0.90.0
superblocks using the old model for compatability.
So I stand by what I said. "When an array is out of sync, it doesn't
mean anything to say which disc is out of sync." It is still possibly
to have a single disc being out-of-sync (it was spare and is being
recovered) but this is a different concept from an array being
out-of-sync.
(raid5 obviously has similar concepts. When the array is out of sync,
you have to rebuild the parity. When a drive is out of sync, you have
to rebuild that drive)
NeilBrown
^ permalink raw reply
* Re: atyfb in 2.5.51
From: Benjamin Herrenschmidt @ 2002-12-10 23:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-kernel, linux-fbdev-devel, James Simmons
In-Reply-To: <15862.27438.787187.93003@argo.ozlabs.ibm.com>
On Tue, 2002-12-10 at 23:31, Paul Mackerras wrote:
> I tried 2.5.51 on my G3 powerbook (laptop), which has a Rage LT Pro
> video chip (ID 0x4c49 or LI). With the patch below, atyfb compiles
> and seems to mostly work. However, I didn't see any penguin on boot.
> Instead the top inch or so of the screen was just black.
>
> X seems to be running just fine. I have 'Option "UseFBDev"' in my
> /etc/X11/XF86Config-4.
AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
Marc Aurele La France (maintainer of this driver) is basically allergic
to kernel fbdev support.
> What doesn't work is changing VTs from X to a
> text console. If I press ctrl-alt-F1, for instance, the colormap
> changes but I don't see anything get redrawn. The screen looks just
> like what I had in X but with the altered colormap. If I then press
> alt-F7, it switches back to X and X redraws the screen properly and
> restores its colormap.
I don't know if happened with earlier fbdev versions for you, but one
possibility is that X reconfigures the display base, and possibly more
bits of the card's internal memory map. Either fbdev should restore
that, or adapt to what X set. On R128's and radeon's, this is things
like DISPLAY_BASE_ADDR.
> The patch below also takes out the CONFIG_NVRAM stuff since it doesn't
> work and I don't believe anyone has ever used it.
Yup, it's some wacky old pmac stuff that should be killed.
> I have also tried aty128fb with some local patches to get it to
> compile for my G4 powerbook. It also doesn't draw the penguin, and it
> oopses when X starts, for some reason.
Hrm... I'll have to test radeonfb... It worked yesteday in console (I
don't remember about the penguin) but I didn't try X.
^ permalink raw reply
* Couple IPQ questions
From: Ryan / Tilzs @ 2002-12-10 23:12 UTC (permalink / raw)
To: netfilter
Hi all,
I have a project where I need to mangle and route packets on 2 different
network interfaces. Each network interface will be assigned a different
subnet. I'm trying to figure out the best approach at doing this.
I'm wondering if it is possible to choose what network interface to send
packets to via a user level IPQ app or is something like this only possible
doing a kenel level module.
I'm also curious if it is possible (I assume the answer is yes on this one)
to inject completely new packets to one NIC or the other using an IPQ user
level app.
Third, if the answer is yes to both, if anyone has an example for me it
would be appreciated.
I've written kernel netfilter modules before, but I'd rather do codeing at
user level if IPQ will support what I need to do.
ryan hagelstrom
Sonic Fury - http://www.sonicfury.net
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
^ permalink raw reply
* Re: xxx_check_var
From: Benjamin Herrenschmidt @ 2002-12-10 23:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: James Simmons, linux-kernel, linux-fbdev-devel
In-Reply-To: <15862.27978.670448.901111@argo.ozlabs.ibm.com>
On Tue, 2002-12-10 at 23:40, Paul Mackerras wrote:
> When I look at atyfb_check_var or aty128fb_check_var, I see that they
> will alter the contents of *info->par. Isn't this a bad thing? My
Yes, this wrong, and afaik, it's your original port to 2.5 that did that
;)
> understanding was that after calling check_var, you don't necessarily
> call set_par next (particularly if check_var returned an error).
> Also I notice that atyfb_set_par and aty128fb_set_par don't look at
> info->var, they simply set the hardware state based on the contents of
> *info->par.
Which is wrong too indeed
> Looking at skeletonfb.c, it seems that this is the wrong behaviour. I
> had fixed the aty128fb.c driver in the linuxppc-2.5 tree. James, if
> you let me know whether the current behaviour is wrong or not, I'll
> fix them and send you the patch.
I _think_ my radeonfb (in linuxppc-2.5) is right in this regard too.
Look at the initialization too, iirc, you had some non necessary stuff
in there (calling gen_set_disp, gen_set_var is plenty enough).
Ben.
> Paul.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: terminfo: changing the mappings from remote serial terminal
From: Glynn Clements @ 2002-12-10 23:14 UTC (permalink / raw)
To: chris db; +Cc: linux-admin
In-Reply-To: <E18LhsK-0003yc-00@tankard.sout.netline.net.uk>
chris db wrote:
> hello, a bit lost on this one - I'm using zterm on a mac powerbook as a
> serial terminal for an IPC,
> everything seems to work fine, but the powerbook has no function keys, and
> zterm only supports
> character substitution for file transfers.
> Ideally I'd like the sparc to output F1 when zterm sends control-1 and etc,
> but I can't find anything
> in the howtos. I first tried changing the sparcs keymap, though it dawned on
> me that this had
> nothing to do with serial terminals, only keyboards directly connected...and
> it didn't work.
> Next I tried to understand the terminfo database but got confused - the
> terminfo manpage
> discussed a human readable format which I felt I could work with easily, but
> the actual files on my
> system(I was hoping to modify vt100) seemed to be in some kind of binary
> format
> (compiled in some way?).
>
> Am I just missing the knowledge on how to compile a database entry? and if
> so, where are the human readable 'source' files I can hack? and how is the
> compilation done?
> Or am I totally going the wrong way here?
Terminfo files are compiled with "tic". You can reverse the process to
get the human-readable form with "infocmp".
--
Glynn Clements <glynn.clements@virgin.net>
^ permalink raw reply
* Board specific info for no EEPROM case
From: Prakash kanthi @ 2002-12-10 23:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20021206024109.S1931@mind.be>
Hi Folks,
I do not have a NVRAM or EEPROM on my board (PPC405
based). I see that during the linux booting, it is
trying to read bd_t info from EEPROM and failing. Is
there an alternative to this problem? Can i hardcode
the stuff in decompress_kernel method and go ahead?
thanks,
Prakash
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [PATCH] scheduler tunables
From: Robert Love @ 2002-12-10 23:27 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm
Attached patch implements sysctl/procfs scheduler tunables, knobs which
let one play with all of the important scheduler variables:
[18:12:54]rml@phantasy:~$ ls /proc/sys/sched/
child_penalty max_sleep_avg parent_penalty
exit_weight max_timeslice prio_bonus_ratio
interactive_delta min_timeslice starvation_limit
Which may help in tuning and debugging the scheduler.
I believe Ingo did something similar to this ages ago, so original
credit for the idea goes to him.
Note the values are not checked and you can probably cause a
divide-by-zero somewhere, but only root can write these.
Patch is against 2.5.51-mm1. It also applies to 2.5.51 modulo a simple
failed hunk in sysctl.c.
Robert Love
include/linux/sysctl.h | 15 ++++++++++++++-
kernel/sched.c | 31 ++++++++++++++++++++++---------
kernel/sysctl.c | 35 ++++++++++++++++++++++++++++++++++-
3 files changed, 70 insertions(+), 11 deletions(-)
diff -urN linux-2.5.51-mm1/include/linux/sysctl.h linux/include/linux/sysctl.h
--- linux-2.5.51-mm1/include/linux/sysctl.h 2002-12-10 17:48:10.000000000 -0500
+++ linux/include/linux/sysctl.h 2002-12-10 16:50:41.000000000 -0500
@@ -66,7 +66,8 @@
CTL_DEV=7, /* Devices */
CTL_BUS=8, /* Busses */
CTL_ABI=9, /* Binary emulation */
- CTL_CPU=10 /* CPU stuff (speed scaling, etc) */
+ CTL_CPU=10, /* CPU stuff (speed scaling, etc) */
+ CTL_SCHED=11, /* scheduler tunables */
};
/* CTL_BUS names: */
@@ -157,6 +158,18 @@
VM_LOWER_ZONE_PROTECTION=20,/* Amount of protection of lower zones */
};
+/* Tunable scheduler parameters in /proc/sys/sched/ */
+enum {
+ SCHED_MIN_TIMESLICE=1, /* minimum process timeslice */
+ SCHED_MAX_TIMESLICE=2, /* maximum process timeslice */
+ SCHED_CHILD_PENALTY=3, /* penalty on fork to child */
+ SCHED_PARENT_PENALTY=4, /* penalty on fork to parent */
+ SCHED_EXIT_WEIGHT=5, /* penalty to parent of CPU hog child */
+ SCHED_PRIO_BONUS_RATIO=6, /* percent of max prio given as bonus */
+ SCHED_INTERACTIVE_DELTA=7, /* delta used to scale interactivity */
+ SCHED_MAX_SLEEP_AVG=8, /* maximum sleep avg attainable */
+ SCHED_STARVATION_LIMIT=9, /* no re-active if expired is starved */
+};
/* CTL_NET names: */
enum
diff -urN linux-2.5.51-mm1/kernel/sched.c linux/kernel/sched.c
--- linux-2.5.51-mm1/kernel/sched.c 2002-12-10 17:48:10.000000000 -0500
+++ linux/kernel/sched.c 2002-12-10 16:33:34.000000000 -0500
@@ -57,16 +57,29 @@
* Minimum timeslice is 10 msecs, default timeslice is 150 msecs,
* maximum timeslice is 300 msecs. Timeslices get refilled after
* they expire.
+ *
+ * They are configurable via /proc/sys/sched
*/
-#define MIN_TIMESLICE ( 10 * HZ / 1000)
-#define MAX_TIMESLICE (300 * HZ / 1000)
-#define CHILD_PENALTY 95
-#define PARENT_PENALTY 100
-#define EXIT_WEIGHT 3
-#define PRIO_BONUS_RATIO 25
-#define INTERACTIVE_DELTA 2
-#define MAX_SLEEP_AVG (2*HZ)
-#define STARVATION_LIMIT (2*HZ)
+
+int min_timeslice = (10 * HZ) / 1000;
+int max_timeslice = (300 * HZ) / 1000;
+int child_penalty = 95;
+int parent_penalty = 100;
+int exit_weight = 3;
+int prio_bonus_ratio = 25;
+int interactive_delta = 2;
+int max_sleep_avg = 2 * HZ;
+int starvation_limit = 2 * HZ;
+
+#define MIN_TIMESLICE (min_timeslice)
+#define MAX_TIMESLICE (max_timeslice)
+#define CHILD_PENALTY (child_penalty)
+#define PARENT_PENALTY (parent_penalty)
+#define EXIT_WEIGHT (exit_weight)
+#define PRIO_BONUS_RATIO (prio_bonus_ratio)
+#define INTERACTIVE_DELTA (interactive_delta)
+#define MAX_SLEEP_AVG (max_sleep_avg)
+#define STARVATION_LIMIT (starvation_limit)
/*
* If a task is 'interactive' then we reinsert it in the active
diff -urN linux-2.5.51-mm1/kernel/sysctl.c linux/kernel/sysctl.c
--- linux-2.5.51-mm1/kernel/sysctl.c 2002-12-10 17:48:10.000000000 -0500
+++ linux/kernel/sysctl.c 2002-12-10 17:05:04.000000000 -0500
@@ -54,6 +54,15 @@
extern int cad_pid;
extern int pid_max;
extern int sysctl_lower_zone_protection;
+extern int min_timeslice;
+extern int max_timeslice;
+extern int child_penalty;
+extern int parent_penalty;
+extern int exit_weight;
+extern int prio_bonus_ratio;
+extern int interactive_delta;
+extern int max_sleep_avg;
+extern int starvation_limit;
/* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */
static int maxolduid = 65535;
@@ -111,6 +120,7 @@
static ctl_table kern_table[];
static ctl_table vm_table[];
+static ctl_table sched_table[];
#ifdef CONFIG_NET
extern ctl_table net_table[];
#endif
@@ -155,6 +165,7 @@
{CTL_FS, "fs", NULL, 0, 0555, fs_table},
{CTL_DEBUG, "debug", NULL, 0, 0555, debug_table},
{CTL_DEV, "dev", NULL, 0, 0555, dev_table},
+ {CTL_SCHED, "sched", NULL, 0, 0555, sched_table},
{0}
};
@@ -357,7 +368,29 @@
static ctl_table dev_table[] = {
{0}
-};
+};
+
+static ctl_table sched_table[] = {
+ {SCHED_MAX_TIMESLICE, "max_timeslice",
+ &max_timeslice, sizeof(int), 0644, NULL, &proc_dointvec},
+ {SCHED_MIN_TIMESLICE, "min_timeslice",
+ &min_timeslice, sizeof(int), 0644, NULL, &proc_dointvec},
+ {SCHED_CHILD_PENALTY, "child_penalty",
+ &child_penalty, sizeof(int), 0644, NULL, &proc_dointvec},
+ {SCHED_PARENT_PENALTY, "parent_penalty",
+ &parent_penalty, sizeof(int), 0644, NULL, &proc_dointvec},
+ {SCHED_EXIT_WEIGHT, "exit_weight",
+ &exit_weight, sizeof(int), 0644, NULL, &proc_dointvec},
+ {SCHED_PRIO_BONUS_RATIO, "prio_bonus_ratio",
+ &prio_bonus_ratio, sizeof(int), 0644, NULL, &proc_dointvec},
+ {SCHED_INTERACTIVE_DELTA, "interactive_delta",
+ &interactive_delta, sizeof(int), 0644, NULL, &proc_dointvec},
+ {SCHED_MAX_SLEEP_AVG, "max_sleep_avg",
+ &max_sleep_avg, sizeof(int), 0644, NULL, &proc_dointvec},
+ {SCHED_STARVATION_LIMIT, "starvation_limit",
+ &starvation_limit, sizeof(int), 0644, NULL, &proc_dointvec},
+ {0}
+};
extern void init_irq_proc (void);
^ permalink raw reply
* Re: hidden interface (ARP) 2.4.20 / network performance
From: Willy TARREAU @ 2002-12-10 23:29 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Roberto Nibali, willy, linux-kernel, linux-net
In-Reply-To: <20021210140912.7a9092b6.skraw@ithnet.com>
On Tue, Dec 10, 2002 at 02:09:12PM +0100, Stephan von Krawczynski wrote:
> Well, what I am trying to say is this: my experience is that under load with
> small sized packets even standard routing/packet forwarding becomes lossy.
This is more often dependant on hardware itself (NICs, chipsets). When your NIC
doesn't support scatter/gather, mitigated interrupts and other wonderful features,
and it receives 148600 pkts/second, it generates as many interrupts. Many chipsets
completely die under such a load. I can tell you that I wasn't proud of hanging my
Dual Athlon 1800+ with its 64/66 PCI slots and so from a single Celeron 800 on
100 Mbps copper !
> If I put NAT and other nice netfilter features on top of such a situation things
> get a lot worse (obviously) - no comparison to building the "application" (e.g.
> cluster) with routing and hidden-patch (mainly because of its pure simplicity I
> guess).
don't even need that to kill a system. Only a cheap NIC, a responding MAC address
and that's all. Of course routing make it worse and NAT even more. And BTW, when I
get 10 to 12 kHits/s with Tux on a 100 Mbps network, you'll notice that it only
happens on empty files. This is about 1 kB per hit, from a wire point of vue.
Count the ACKs, the data (tcp headers), and global overhead, and you're not far
from wire-speed on very small packets.
> Don't get me wrong: I am pretty content with the hidden-patch and my setup
> without NAT. But I wanted to point to the direction of possible further routing
> performance improvement in 2.4.X tree. Is it correct that I can expect higher
> data-rates (concerning small packets) if using higher HZ ?
don't know. perhaps forwarding packets between input and output involves queues
that are processed alternatively at HZ rate, but that seems strange to me.
> Someone selling E3 cards told me he cannot manage loads like these (small
> packet stuff) with a stock kernel, and that you _at least_ have to increase HZ
> to get acceptable throughput results.
E3 is only 45 Mbps (or I'm mistaken) ? Tweaking such parameters for such medium
rates doesn't seem the most appropriate to me. Perhaps his driver has some problems.
Cheers,
Willy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.