October 2003 - openSUSE AMD64 - openSUSE Mailing Lists

[OT] Spammers harvest from this list
by Stephen Williams 22 Oct '03

22 Oct '03

It appears that there is at least one spammer subscribed to this list who is using it to harvest e-mail addresses. I use a unique e-mail address for the list, and sure enough, I am getting about a spam a day on it. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."

2 1

It didn't swap?
by Kristoffer Ongbongan 17 Oct '03

17 Oct '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We're running SLES 8 on a Tyan 2800 BIOS 2.01l with 2x Opteron 244, 6GB RAM. Linux db64 2.4.19-SMP #1 SMP Mon Mar 31 23:48:08 UTC 2003 x86_64 unknown Last time I tried to upgrade the kernel the new kernel didn't like something about the zero channel raid and wouldn't mount the root disk. :(, same with the SLES Service pack 2, so we started from scratch install, no extra patches. we've got a couple of issues... 1) Linux won't boot with the DRAM ECC enabled in the BIOS.. so we're running w/o ECC. 2) I ran a "memory eater" script, that ate up all the memory, the machine didn't swap.. it crashed... spit out some errors... below is the script, top output right after the crash, and the error messages. Any ideas? bad ram? Kris. - --- snip --- export PARALLEL=1 #!/bin/bash2 # # memtest.sh # # Shell script to help isolate memory failures under linux # # Author: Doug Ledford + contributors # # (C) Copyright 2000-2002 Doug Ledford; Red Hat, Inc. # This shell script is released under the terms of the GNU General # Public License Version 2, June 1991. If you do not have a copy # of the GNU General Public License Version 2, then one may be # retrieved from http://people.redhat.com/dledford/GPL.html # # Note, this needs bash2 for the wait command support. # This is where we will run the tests at if [ -z "$TEST_DIR" ]; then ~ TEST_DIR=/usr/zap/tmp fi # The location of the linux kernel source file we will be using if [ -z "$SOURCE_FILE" ]; then ~ SOURCE_FILE=$TEST_DIR/linux.tar.gz fi if [ ! -f "$SOURCE_FILE" ]; then ~ echo "Missing source file $SOURCE_FILE" ~ exit 1 fi # How many passes to run of this test, higher numbers are better if [ -z "$NR_PASSES" ]; then ~ NR_PASSES=40 fi # Guess how many megs the unpacked archive is if [ -z "$MEG_PER_COPY" ]; then ~ MEG_PER_COPY=$(ls -l $SOURCE_FILE | awk '{print int($5/1024/1024) * 4}') fi # How many trees do we have to unpack in order to make our trees be larger # than physical RAM? If we don't unpack more data than memory can hold # before we start to run the diff program on the trees then we won't # actually flush the data to disk and force the system to reread the data # from disk. Instead, the system will do everything in RAM. That doesn't # work (as far as the memory test is concerned). It's the simultaneous # unpacking of data in memory and the read/writes to hard disk via DMA that # breaks the memory subsystem in most cases. Doing everything in RAM without # causing disk I/O will pass bad memory far more often than when you add # in the disk I/O. if [ -z "$NR_SIMULTANEOUS" ]; then ~ NR_SIMULTANEOUS=$(free | awk -v meg_per_copy=$MEG_PER_COPY 'NR == 2 {print int($2*1.5/1024/meg_per_ copy + (($2/1024)%meg_per_copy >= (meg_per_copy/2)) + (($2/1024/32) < 1))}') fi # Should we unpack/diff the $NR_SIMULTANEOUS trees in series or in parallel? if [ ! -z "$PARALLEL" ]; then ~ PARALLEL="yes" else ~ PARALLEL="no" fi if [ ! -z "$JUST_INFO" ]; then ~ echo "TEST_DIR: $TEST_DIR" ~ echo "SOURCE_FILE: $SOURCE_FILE" ~ echo "NR_PASSES: $NR_PASSES" ~ echo "MEG_PER_COPY: $MEG_PER_COPY" ~ echo "NR_SIMULTANEOUS: $NR_SIMULTANEOUS" ~ echo "PARALLEL: $PARALLEL" ~ echo ~ exit fi cd $TEST_DIR # Remove any possible left over directories from a cancelled previous run rm -fr linux linux.orig linux.pass.* # Unpack the one copy of the source tree that we will be comparing against tar -xzf $SOURCE_FILE mv linux linux.orig i=0 while [ "$i" -lt "$NR_PASSES" ]; do ~ j=0 ~ while [ "$j" -lt "$NR_SIMULTANEOUS" ]; do ~ if [ $PARALLEL = "yes" ]; then ~ (mkdir $j; tar -xzf $SOURCE_FILE -C $j; mv $j/linux linux.pass.$j; rmdir $j) & ~ else ~ tar -xzf $SOURCE_FILE ~ mv linux linux.pass.$j ~ fi ~ j=`expr $j + 1` ~ done ~ wait ~ j=0 ~ while [ "$j" -lt "$NR_SIMULTANEOUS" ]; do ~ if [ $PARALLEL = "yes" ]; then ~ (mkdir $j; tar -xzf $SOURCE_FILE -C $j; mv $j/linux linux.pass.$j; rmdir $j) & ~ else ~ tar -xzf $SOURCE_FILE ~ mv linux linux.pass.$j ~ fi ~ j=`expr $j + 1` ~ done ~ wait ~ j=0 ~ while [ "$j" -lt "$NR_SIMULTANEOUS" ]; do ~ if [ $PARALLEL = "yes" ]; then ~ (diff -U 3 -rN linux.orig linux.pass.$j; rm -fr linux.pass.$j) & ~ else ~ diff -U 3 -rN linux.orig linux.pass.$j ~ rm -fr linux.pass.$j ~ fi ~ j=`expr $j + 1` ~ done ~ wait ~ i=`expr $i + 1` done # Clean up after ourselves rm -fr linux linux.orig linux.pass.* ~ 8:50pm up 3:06, 2 users, load average: 54.12, 51.66, 33.69 207 processes: 206 sleeping, 1 running, 0 zombie, 0 stopped CPU0 states: 0.1% user, 0.0% system, 0.0% nice, 99.4% idle CPU1 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle Mem: 5806792K av, 5791816K used, 14976K free, 0K shrd, 437508K buff Swap: 1052248K av, 0K used, 1052248K free 4640676K cached ~ PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND ~ 1738 zappos 15 0 1260 1260 844 R 0.1 0.0 0:05 top ~ 1 root 15 0 240 240 188 S 0.0 0.0 0:04 init ~ 2 root 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU0 ~ 3 root 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU1 ~ 4 root 15 0 0 0 0 SW 0.0 0.0 0:00 keventd ~ 5 root 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0 ~ 6 root 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1 ~ 7 root 15 0 0 0 0 SW 0.0 0.0 0:00 kswapd ~ 8 root 25 0 0 0 0 SW 0.0 0.0 0:00 bdflush ~ 9 root 15 0 0 0 0 SW 0.0 0.0 0:00 kupdated ~ 10 root 25 0 0 0 0 SW 0.0 0.0 0:00 kinoded ~ 12 root 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd ~ 16 root 15 0 0 0 0 SW 0.0 0.0 0:00 kreiserfsd ~ 73 root 0 -20 0 0 0 SW< 0.0 0.0 0:00 lvm-mpd ~ 420 root 15 0 660 660 524 S 0.0 0.0 0:00 syslogd ~ 423 root 15 0 1376 1376 444 S 0.0 0.0 0:00 klogd ~ 459 root 24 0 0 0 0 SW 0.0 0.0 0:00 khubd ~ 612 bin 25 0 460 460 360 S 0.0 0.0 0:00 portmap ~ 634 root 23 0 2860 2860 1488 S 0.0 0.0 0:00 snmpd ~ 678 root 15 0 1904 1904 1736 S 0.0 0.0 0:00 sshd ~ 876 root 15 0 1828 1828 1388 S 0.0 0.0 0:00 master ~ 885 postfix 15 0 2020 2020 1532 S 0.0 0.0 0:00 qmgr ~ 900 at 16 0 608 608 488 S 0.0 0.0 0:00 atd ~ 915 root 15 0 696 696 552 S 0.0 0.0 0:00 cron ~ 1012 root 15 0 800 800 620 S 0.0 0.0 0:00 nscd ~ 1013 root 15 0 800 800 620 S 0.0 0.0 0:00 nscd ~ 1014 root 15 0 800 800 620 S 0.0 0.0 0:00 nscd ~ 1015 root 15 0 800 800 620 S 0.0 0.0 0:00 nscd ~ 1016 root 15 0 800 800 620 S 0.0 0.0 0:00 nscd ~ 1017 root 15 0 800 800 620 S 0.0 0.0 0:00 nscd ~ 1018 root 15 0 800 800 620 S 0.0 0.0 0:00 nscd ~ 1031 root 20 0 512 512 428 S 0.0 0.0 0:00 mingetty ~ 1032 root 20 0 512 512 428 S 0.0 0.0 0:00 mingetty ~ 1033 root 21 0 512 512 428 S 0.0 0.0 0:00 mingetty ~ 1034 root 20 0 512 512 428 S 0.0 0.0 0:00 mingetty ~ 1035 root 21 0 512 512 428 S 0.0 0.0 0:00 mingetty ~ 1036 root 21 0 512 512 428 S 0.0 0.0 0:00 mingetty ~ 1320 postfix 15 0 1724 1724 1312 S 0.0 0.0 0:00 pickup ~ 1366 root 15 0 2548 2548 2368 S 0.0 0.0 0:00 sshd ~ 1368 zappos 15 0 2652 2652 2424 S 0.0 0.0 0:00 sshd Message from syslogd@db64 at Thu Oct 16 20:49:20 2003 ... db64 kernel: MCG_STATUS: unrecoverable memtest.bash: line 108: 1627 Segmentation fault tar -xzf $SOURCE_FILE -C $j Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: Northbridge Machine Check exception b40000000005001b 0 Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: Uncorrectable condition Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: Unrecoverable condition Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: Error uncorrected Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: Address: 0000000009470000 Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: MCE at EIP ffffffffa001412e ESP 10025659d98 Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: CPU 0: Machine Check Exception: 0000000000000000 Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: Kernel panic: Unable to continue Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: Kernel BUG at journal:3092 Message from syslogd@db64 at Thu Oct 16 20:49:22 2003 ... db64 kernel: invalid operand: 0000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/j25WuBLfyXibQuYRAlCmAJwK7J81+donOr3xnJwW5EUfiDSZmACePLHC jGzmj8K//nK7Fi7275meFLs= =Dx+U -----END PGP SIGNATURE-----

5 8

Re: [suse-amd64] It didn\'t swap?
by Juan Erbes 17 Oct '03

17 Oct '03

¿IRQ 26? I mean, it was wrong. What motherboard is? What chipset? Mensaje citado por: Kristoffer Ongbongan <kris(a)vfrogs.com>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ECC issues aside, I\'d like to get this box running.. > > I installed the k_numa kernel per advice of suse business support... and > this is what I got.. > > scsi0: Found a MegaRAID controller at 0x1b000, IRQ: 26 > scsi0: Enabling 64 bit support > megaraid: [1Z26:G112] detected 1 logical drives > megaraid: supports extended CDBs. > megaraid: channel[1] is raid. > megaraid: channel[2] is raid. > scsi0: LSI Logic MegaRAID 1Z26 254 commands 16 targs 5 chans 7 luns > scsi0: scanning virtual channel 0 for logical drives. > ~ Vendor: MegaRAID Model: LD0 RAID1 10018R Red: 1Z26 > ~ Type: Direct Access ANSI SCSI revision: 02 > scsi0: scanning virtual channel 1 for logical drives. > scsi0: scanning virtual channel 2 for logical drives. > scsi0: scanning virtual channel 3 for logical drives. > scsi0: scanning physical channel 0 for devices. > scsi0: scanning physical channel 1 for devices. > sd: allocated major 8 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 > SCSI device sda: 430116864 512-byte hdwr sectors (220220 MB) > Partition check: > ~ sda: sda1 sda2 sda3 > Loading module reiserfs ... > Using /lib/modules/2.4.19-NUMA/kernel/fs/reiserfs/reiserfs.o > sh-2021: reiserfs_read_super: can not find reiserfs on sd(8,1) > Kernel panic: VFS: Unable to mount root fs on 08:01 > > > anyone know how I could boot this? > > Andreas Jaeger wrote: > | > |>2) I ran a \"memory eater\" script, that ate up all the memory, the > |>machine didn\'t swap.. it crashed... spit out some errors... > |> > |>below is the script, top output right after the crash, and the error > |>messages. Any ideas? bad ram? > | > | > | The original SLES8 kernel had some bugs in the MCE code, this got only > | fixed for SP2. So, the error message while pointing to bad memory > | might still be wrong. I would still try to get SP2 running. I\'m > | also uploading our current kernel, you might want to try that one. > | > | It\'s the -127 kernel at ftp.suse.com/pub/people/aj/Kernel-AMD64/ > | > | Andreas > | > | > |>Kris. > |> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQE/j+XvuBLfyXibQuYRApmIAJ4kQmhDw5OyKSIJwpXyNv6tvl8jZACeO9vK > 2Jcs80KdT+fELRhv5K+bi+Q= > =+EL7 > -----END PGP SIGNATURE----- > > > -- > Check the List-Unsubscribe header to unsubscribe > For additional commands, email: suse-amd64-help(a)suse.com > > > __________________________________ Registrate desde http://servicios.arnet.com.ar/registracion/registracion.asp?origenid=9 y participá de todos los beneficios del Portal Arnet.

1 0

RE: [suse-amd64] SCSI RAID controller support for x86-64 Linux (A daptec 2120S and LSI MegaRAID) ?
by Anurag.R 17 Oct '03

17 Oct '03

Christian Røsnes <christian(a)cellus.no> writes: > Hello, > > I'm putting together a dual opteron system. I'm considering two SCSI RAID > controllers: > > 1) Adaptec SCSI RAID 2120S (single-channel, Ultra320) > > 2) LSI MegaRAID SCSI 320-1 (single-channel, Ultra320) > > Will both of these work with any x86-64 linux kernels (64 bit), and will > they work > with the kernels shipped with either SLES8 (x86-64) or SuSE8.2 (x86-64) > Beta9 ? Yes it should work, we tested LSI FC and QLogic SCSI adaptor with x86-64 Andreas -- Andreas Jaeger, aj(a)suse.de, http://www.suse.de/~aj SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 0

SCSI RAID controller support for x86-64 Linux (Adaptec 2120S and LSI MegaRAID) ?
by Christian Røsnes 17 Oct '03

17 Oct '03

Hello, I'm putting together a dual opteron system. I'm considering two SCSI RAID controllers: 1) Adaptec SCSI RAID 2120S (single-channel, Ultra320) 2) LSI MegaRAID SCSI 320-1 (single-channel, Ultra320) Will both of these work with any x86-64 linux kernels (64 bit), and will they work with the kernels shipped with either SLES8 (x86-64) or SuSE8.2 (x86-64) Beta9 ? Thanks Christian

3 2

16GB DMA support
by Anurag.R 14 Oct '03

14 Oct '03

Dear All, We are developing a Solid State Cache usingAMD Opteron Processor with 64 bit Linux as OS. The system has 16GB SDRAM. We are plannig to use 14GB of RAM for storage and remaining for kernel and applications. Our SCSI IO Controller (FC919x) supports 64 bit dma. How we can use 14GB for storage purpose. We used pci_alloc_consistent and failed to allocate memory more than 6MB. We are allocating 512 bytes block at a time. Is there is any other optiom to use 14GB allocation for DMA. Thanks in Advance. Anurag

2 1

3ware SATA controller
by Mark Horton 11 Oct '03

11 Oct '03

Hi, I'm using Sles 8.2beta9 for some testing and have come accross a performance issue with a SATA card. This is in a dual opteron system using the Rioworks HDAMA motherboard. I added a 3ware 8506-4LP SATA raid controller card with 2 drives attached to it. I'm seeing slow performance copying large files when I use the controller to build a raid-0 array. Copying a 5GB file takes about 6 minutes. I deleted the array from the controller and left the 2 drives to be regocnized by the OS. I then built a raid-0 array using 'mdadm'. I can now copy the same 5GB file in about 95 seconds. This is on a fresh reboot so I know the file isn't cached. My first question is, does anyone else have this card? and if so are they seeing any performance issues in their opteron system? Any idea if I should I go to 3ware for opteron linux support? Or is the driver an open source project? Last question isnt amd_64 specific but if anyone knows the answer I would appreciate it. Will I take a noticable performance hit using raid-0 in the OS as opposed to the controller card? (Assuming they improve performance on the card.) Mark

2 1

RE: [suse-amd64] 3ware SATA controller
by Miller, Daniel J. 11 Oct '03

11 Oct '03

I've had very good experiences with the 3Ware line, though the only SATA unit I've used is the 8500-8, not the 8506-X. One thing you might check is to be sure that your driver version and firmware version are in sync. 3Ware does seem to release new drivers quite often, and most driver upgrades require that you also upgrade the firmware and display manager. I believe that support for the 85xx is compiled into the kernel so you might want to check that your firmware isn't a different version from whatever is compiled into the kernel. The one box I have with an 8500-x in it is presently being use to test Windows 2003 server, but it was initially loaded with SuSE 8.2 (shrink wrapped production version, not the beta - don't know if anything is different) and it did very well. I can't confirm any specific tests copying large files, but don't recall any need to test for that (performance seemed fine). Not sure what would happen if the firmware and driver were different versions, but poor performance is certainly one possibility. Dan -----Original Message----- From: Mark Horton [mailto:mark@nostromo.net] Sent: Friday, October 10, 2003 3:05 PM To: suse-amd64(a)suse.com Subject: [suse-amd64] 3ware SATA controller Hi, I'm using Sles 8.2beta9 for some testing and have come accross a performance issue with a SATA card. This is in a dual opteron system using the Rioworks HDAMA motherboard. I added a 3ware 8506-4LP SATA raid controller card with 2 drives attached to it. I'm seeing slow performance copying large files when I use the controller to build a raid-0 array. Copying a 5GB file takes about 6 minutes. I deleted the array from the controller and left the 2 drives to be regocnized by the OS. I then built a raid-0 array using 'mdadm'. I can now copy the same 5GB file in about 95 seconds. This is on a fresh reboot so I know the file isn't cached. My first question is, does anyone else have this card? and if so are they seeing any performance issues in their opteron system? Any idea if I should I go to 3ware for opteron linux support? Or is the driver an open source project? Last question isnt amd_64 specific but if anyone knows the answer I would appreciate it. Will I take a noticable performance hit using raid-0 in the OS as opposed to the controller card? (Assuming they improve performance on the card.) Mark -- Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help(a)suse.com

2 1

Andreas J's kernel k_smp-2.4.21-89.amd64.rpm
by Hugh Song 10 Oct '03

10 Oct '03

Updating the kernel failed on my Beta9 machine with the following message Would you please help me sort this problem out? Thanks. Hugh ============================================== # rpm -Uvh *.rpm error: failed dependencies: irqbalance is needed by k_smp-2.4.21-89 rpmlib(PartialHardlinkSets) <= 4.0.4-1 is needed by k_smp-2.4.21-89 ========================================= Basically, I do not know which packages provide irqbalance and rpmlib.

2 1

8.1 on Athlon-64 ?
by Dmitry Melekhov 09 Oct '03

09 Oct '03

Hello! I'm afraid this is offtopic here, but... Sorry! Is it possible to install 32 bit Suse 8.1 to Athlon-64 box on VIA K8T800 / VT8237 ? I plan to install it before Suse 9 for x86-64 will be available...

2 1