February 2004 - openSUSE AMD64 - openSUSE Mailing Lists

VMware can't access fd0 and sr0
by M. Ranjit Mathews 26 Feb '04

26 Feb '04

I'm running SUSE 9.0 for AMD64: # uname -a Linux linux 2.4.21-201-smp #1 SMP Wed Feb 18 19:17:53 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux I installed VMware 4.5 & configured it with vmware-config.pl: # rpm -qa | fgrep -i vmware VMwareWorkstation-4.5.0-7174 I went to the dev directory and linked sr0 to cdrom # ls -l cdrom lrwxrwxrwx 1 root root 3 Feb 26 02:08 cdrom -> sr0 I have no trouble accessing fd0 and cdrom from a command line with media in them: # dd if=/dev/fd0 of=/dev/null count=1 1+0 records in 1+0 records out # dd if=/dev/cdrom of=/dev/null count=1 1+0 records in 1+0 records out When I start the virtual machine, it says fd0 doesn't seem to be a floppy drive and that I can start the virtual machine without a floopy drive. When the boot proceeds gets to the cdrom, an oops message from the kernel appears and to get things back to normal, I have to restart the host system (dual Opteron 240) If I remove the cdrom from the virtual machine definition, the boot sequence makes it to a PXE boot; there's no more Oops. QUESTION: How can I give the virtual machine access to a floppy drive and CDROM (I have an NEC BD2500 DVD-RW/ CD-RW)?

1 0

kernel 2.6 and eth0
by Eros Albertazzi 25 Feb '04

25 Feb '04

Just for curiosity I tried (unsupported) kernel 2.6.3-6 on my Opteron Suse 9 box. Boot goes, but it cannot configure eth0 Is there something (different from what it does when I boot 2.4) that I have to add? Or, likely, should I better give up and wait. Regards. -- Eros Albertazzi CNR-IMM, Sez. Bologna Via P.Gobetti 101 I-40129 Bologna, Italy Tel:(+39)-051-639 9179 Fax:(+39)-051-639 9216

3 5

RE: [suse-amd64] Kernel support for large arrays...
by richard.brunner＠amd.com 25 Feb '04

25 Feb '04

There is a limitation with PGI F90 and large arrays greater than 2GB. F77 for PGI 5.1-3 doesn't have this limitation. This will be fixed in the future for F90 by PGI. Please contact PGI, they can give you the latest info. ] -Rich ... ] AMD Fellow ] richard.brunner at amd com

1 0

opteron lockup
by Andrej Filipcic 25 Feb '04

25 Feb '04

Hi, I have some troubles with dual opteron server, Tyan Thunder K8S pro motherboard, 2x246 opteron CPU, 4G mem, suse 9.0 AMD64, kernel 2.4.21-178-smp. I have not yet tested the latest kernel... Occassionaly (once in 2 weeks), there is a deadlock. I am not sure if this is a hardware or kernel problem, since the power supply died once. Any suggestions? There is a ksymoops output attached. Thanks, Andrej -- _____________________________________________________________ doc. dr. Andrej Filipcic, E-mail: Andrej.Filipcic(a)ijs.si Department of Experimental High Energy Physics - F9 Jozef Stefan Institute, Jamova 39, P.o.Box 3000 SI-1001 Ljubljana, Slovenia Tel.: +386-1-477-3674 Fax: +386-1-425-7074 ------------------------------------------------------------- ksymoops 2.4.9 on x86_64 2.4.21-178-smp. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.21-178-smp/ (default) -m /boot/System.map-2.4.21-178-smp (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 000000121c9322c8 ffffffff801845b8 PML4 f65dd067 PGD 0 Oops: 0000 CPU 0 Pid: 26374, comm: top Tainted: P RIP: 0010:[<ffffffff801845b8>]{collect_sigign_sigcatch+56} Using defaults from ksymoops -t elf64-x86-64 -a i386:x86-64 RSP: 0018:000001002f699d80 EFLAGS: 00010006 RAX: 000000121c9322c0 RBX: 00000100a7294000 RCX: 0000000000000000 RDX: 000001002f699ed8 RSI: 000001002f699ed0 RDI: 00000100a7294000 RBP: 00000100570f45b8 R08: 000000121c9322c8 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: 00000100570f4580 R13: 00000000003db000 R14: 0000000000000000 R15: 000000000051a780 FS: 000000000050eee0(0000) GS:ffffffff804bbf00(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000121c9322c8 CR3: 0000000000101000 CR4: 00000000000006e0 Process top (pid: 26374, stackpage=1002f699000) Stack: 000001002f699d80 0000000000000018 ffffffff80184bf7 00000100a7294000 ffffffff8016f3e0 0000000000000246 ffffffff80182edb 000001007f90b000 0000010080013020 ffffffff803d3480 fffffffffffffff4 00000100656344c0 Call Trace: [<ffffffff80184bf7>]{proc_pid_stat+407} [<ffffffff8016f3e0>]{new_inode+16} [<ffffffff80182edb>]{proc_pid_make_inode+235} [<ffffffff80183343>]{proc_base_lookup+563} [<ffffffff80161ae7>]{real_lookup+167} [<ffffffff8016c5d1>]{dput+33} [<ffffffff80166129>]{__link_path_walk+2425} [<ffffffff80182491>]{proc_info_read+113} [<ffffffff8015466f>]{sys_read+191} [<ffffffff80110143>]{system_call+119} Code: 49 8b 00 48 83 f8 01 75 0f 41 8d 49 ff 48 d3 e0 48 09 06 eb >>RIP; ffffffff801845b8 <collect_sigign_sigcatch+38/80> <===== Trace; ffffffff80184bf7 <proc_pid_stat+197/600> Trace; ffffffff8016f3e0 <new_inode+10/80> Trace; ffffffff80183343 <proc_base_lookup+233/250> Trace; ffffffff8016c5d1 <dput+21/160> Trace; ffffffff80182491 <proc_info_read+71/100> Trace; ffffffff80110143 <system_call+77/7c> Code; ffffffff801845b8 <collect_sigign_sigcatch+38/80> 0000000000000000 <_RIP>: Code; ffffffff801845b8 <collect_sigign_sigcatch+38/80> <===== 0: 49 8b 00 mov (%r8),%rax <===== Code; ffffffff801845bb <collect_sigign_sigcatch+3b/80> 3: 48 83 f8 01 cmp $0x1,%rax Code; ffffffff801845bf <collect_sigign_sigcatch+3f/80> 7: 75 0f jne 18 <_RIP+0x18> Code; ffffffff801845c1 <collect_sigign_sigcatch+41/80> 9: 41 8d 49 ff lea 0xffffffffffffffff(%r9),%ecx Code; ffffffff801845c5 <collect_sigign_sigcatch+45/80> d: 48 d3 e0 shl %cl,%rax Code; ffffffff801845c8 <collect_sigign_sigcatch+48/80> 10: 48 09 06 or %rax,(%rsi) Code; ffffffff801845cb <collect_sigign_sigcatch+4b/80> 13: eb 00 jmp 15 <_RIP+0x15> NMI Watchdog detected LOCKUP on CPU0, eip ffffffff80185d02, registers: CPU 0 Pid: 26375, comm: top Tainted: P RIP: 0010:[<ffffffff80185d02>]{.text.lock.array+7} RSP: 0018:000001007680dd80 EFLAGS: 00000086 RAX: 0000000000000000 RBX: 00000100a7294000 RCX: 0000000000000000 RDX: 000001007680ded8 RSI: 000001007680ded0 RDI: 00000100a7294000 RBP: 00000100570f45b8 R08: 0000010080000638 R09: 00000100828233d8 R10: 0000000000000001 R11: 0000000000000000 R12: 00000100570f4580 R13: 00000000003db000 R14: 0000000000000000 R15: 000000000051a780 FS: 00000000005260a0(0000) GS:ffffffff804bbf00(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000002a9556c000 CR3: 0000000000101000 CR4: 00000000000006e0 Process top (pid: 26375, stackpage=1007680d000) Stack: 000001007680dd80 0000000000000018 0000000000100000 ffffffff80117040 ffffffff80117130 0000000000000001 0000000000000000 0000000000000000 ffffffff803ca8e0 0000000000000000 0000000000000000 0000000000000000 Call Trace: <EOE> [<ffffffff80184bf7>]{proc_pid_stat+407} [<ffffffff802c8f98>]{sprintf+136} [<ffffffff80183343>]{proc_base_lookup+563} [<ffffffff8016c5d1>]{dput+33} [<ffffffff80166129>]{__link_path_walk+2425} [<ffffffff80182491>]{proc_info_read+113} [<ffffffff8015466f>]{sys_read+191} [<ffffffff80110143>]{system_call+119} Code: f3 90 7e f5 e9 84 e8 ff ff e8 70 1b 14 00 e9 80 e9 ff ff 41 >>RIP; ffffffff80185d02 <.text.lock.array+7/105> <===== Trace; ffffffff802c8f98 <sprintf+88/90> Trace; ffffffff8016c5d1 <dput+21/160> Trace; ffffffff80182491 <proc_info_read+71/100> Trace; ffffffff80110143 <system_call+77/7c> Code; ffffffff80185d02 <.text.lock.array+7/105> 0000000000000000 <_RIP>: Code; ffffffff80185d02 <.text.lock.array+7/105> <===== 0: f3 90 repz nop <===== Code; ffffffff80185d04 <.text.lock.array+9/105> 2: 7e f5 jle fffffffffffffff9 <_RIP+0xfffffffffffffff9> Code; ffffffff80185d06 <.text.lock.array+b/105> 4: e9 84 e8 ff ff jmpq ffffffffffffe88d <_RIP+0xffffffffffffe88d> Code; ffffffff80185d0b <.text.lock.array+10/105> 9: e8 70 1b 14 00 callq 141b7e <_RIP+0x141b7e> Code; ffffffff80185d10 <.text.lock.array+15/105> e: e9 80 e9 ff ff jmpq ffffffffffffe993 <_RIP+0xffffffffffffe993> Code; ffffffff80185d15 <.text.lock.array+1a/105> 13: 41 00 00 add %al,(%r8) 1 warning issued. Results may not be reliable.

1 0

RE: [suse-amd64] Kernel support for large arrays...
by richard.brunner＠amd.com 25 Feb '04

25 Feb '04

Physical memory available != virtual memory available for allocation. In an 8GB DRAM system, the BIOS gives the OS approximately 7.5GB (because of various I/O issues). You should be able to get the kernel to allocate a large amount but once you allocate larger than phys memory, you will page awfully. You don't say whether the app requesting the memory is 32-bit or 64-bit. I assume 64-bit. Which PGI compiler (F77? F90?) and which version (5.0? 5.1? 5.1-3?) are you using? How are you allocating the array? ] -Rich ... ] AMD Fellow ] richard.brunner at amd com > -----Original Message----- > From: JOSE LUIS RICARDO-CHAVEZ [mailto:ricardo@irsamc.ups-tlse.fr] > Sent: Tuesday, February 24, 2004 4:33 AM > To: Andreas Jaeger > Cc: suse-amd64(a)suse.com > Subject: Re: [suse-amd64] Kernel support for large arrays... > > > Andreas Jaeger wrote: > > >JOSE LUIS RICARDO-CHAVEZ <ricardo(a)irsamc.ups-tlse.fr> writes: > > > > > > > >>recently we have installed in our lab an Opteron system (Tyan 2882 > >>motherboard, two Opteron 244 processor, 8 GB memory) running SuSE > >>AMD64 9.0 Using the PGI compiler suite we did some memory > allocation > >>tests. We found a modest 4 GB > >>memory limit per allocated array. According to PGI engineers this is > >>not a compiler > >>fault, the limit is just set in kernel's mmap.c routine. > Would it be safe to > >>change this value and recompile the kernel or it would require > >>changing some other > >>routines? > >> > >> > > > >There's no such limit in the kernel. You should be allocate such an > >array without problems. > > > >Andreas > > > > > > Hi Andreas, > > You are right, I looked into the file > /usr/include/asm-x86-64/processor.h > and found the following: > > /* > * User space process size: 512GB - 1GB (default). > */ > #define TASK_SIZE (0x0000007fc0000000) > > /* This decides where the kernel will search for a free chunk of vm > * space during mmap's. > */ > #define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? > 0xc0000000 : 0xFFFFe000) > #define TASK_UNMAPPED_32 (PAGE_ALIGN(IA32_PAGE_OFFSET / 3)) > #define TASK_UNMAPPED_64 PAGE_ALIGN(TASK_SIZE/3) > #define TASK_UNMAPPED_BASE \ > (test_thread_flag(TIF_IA32) ? TASK_UNMAPPED_32 : > TASK_UNMAPPED_64) > > So the problem is not related to the way the OS maps > physical memory into virtual memory. > Could it be possible that the motherboard is tuned to support > mainly a 32-bit system and by that reason it uses the last > megabytes right before the 4 GB limit to allocate space for > drivers? I've heard that Tyan is considering to provide a > BIOS version designed to support only 64-bit operating > systems, I hate to wait but maybe that's the solution. > > Greeting from Toulose, > > - Jose Luis > > -- > JosÃ© Luis RICARDO-CHAVEZ Tel. +33-5-61-55-68-33 > Laboratoire de Physique Quantique Fax +33-5-61-55-60-65 > UniversitÃ© Paul Sabatier > 118 route de Narbonne > F-31062 Toulouse, France > > e-mail: ricardo(a)irsamc.ups-tlse.fr > > >

4 4

RE: [suse-amd64] updating /boot/grub/menu.1st
by marc.miller＠amd.com 25 Feb '04

25 Feb '04

I've had pretty good success with vi. :-P -----Original Message----- From: daniel.kidger(a)quadrics.com [mailto:daniel.kidger@quadrics.com] Sent: Tuesday, February 24, 2004 8:28 AM To: suse-amd64(a)suse.com Subject: [suse-amd64] updating /boot/grub/menu.1st Folks, I am building kernels as RPMs for use in installing across a large Opteron cluster. For this need a post-install script that will reliably updated and maintain /boot/grub/menu.1st A node may have say 2 or 3 bootable kernels active at any one time. With RedHat, I had the 'grubby' tool that could be used to add a new entry such that it inherited the kernel options etc. of whatever the current default kernel is. There doesn't appear to be an equivalent to Grubby in the SuSE distro - (but I guess there must me something related to grubby that creates the menu.lst file when first installing SuSE from say CD) So my question is - without me reinventing the wheel, what is the prefered way of adding (and removing)entries to /boot/grub/menu.1st ? Yours, Daniel. -------------------------------------------------------------- Dr. Dan Kidger, Quadrics Ltd. daniel.kidger(a)quadrics.com One Bridewell St., Bristol, BS1 2AA, UK 0117 915 5505 ----------------------- www.quadrics.com -------------------- -- Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help(a)suse.com

4 3

updating /boot/grub/menu.1st
by daniel.kidger＠quadrics.com 24 Feb '04

24 Feb '04

Folks, I am building kernels as RPMs for use in installing across a large Opteron cluster. For this need a post-install script that will reliably updated and maintain /boot/grub/menu.1st A node may have say 2 or 3 bootable kernels active at any one time. With RedHat, I had the 'grubby' tool that could be used to add a new entry such that it inherited the kernel options etc. of whatever the current default kernel is. There doesn't appear to be an equivalent to Grubby in the SuSE distro - (but I guess there must me something related to grubby that creates the menu.lst file when first installing SuSE from say CD) So my question is - without me reinventing the wheel, what is the prefered way of adding (and removing)entries to /boot/grub/menu.1st ? Yours, Daniel. -------------------------------------------------------------- Dr. Dan Kidger, Quadrics Ltd. daniel.kidger(a)quadrics.com One Bridewell St., Bristol, BS1 2AA, UK 0117 915 5505 ----------------------- www.quadrics.com --------------------

1 0

Kernel support for large arrays...
by JOSE LUIS RICARDO-CHAVEZ 24 Feb '04

24 Feb '04

Hello, recently we have installed in our lab an Opteron system (Tyan 2882 motherboard, two Opteron 244 processor, 8 GB memory) running SuSE AMD64 9.0 Using the PGI compiler suite we did some memory allocation tests. We found a modest 4 GB memory limit per allocated array. According to PGI engineers this is not a compiler fault, the limit is just set in kernel's mmap.c routine. Would it be safe to change this value and recompile the kernel or it would require changing some other routines? Thanks for your help, - Jose Luis -- JosÃ© Luis RICARDO-CHAVEZ Tel. +33-5-61-55-68-33 Laboratoire de Physique Quantique Fax +33-5-61-55-60-65 UniversitÃ© Paul Sabatier 118 route de Narbonne F-31062 Toulouse, France e-mail: ricardo(a)irsamc.ups-tlse.fr

2 2

Question regarding Ethernet compatibility
by Rick 24 Feb '04

24 Feb '04

I've ordered a AMD 64 3200 System that has a Realtek RTL8110S GigaBit LAN on the mother board, is this supported by Suse 9.0 AMD 64, if not can someone recommend an inexpensive solid Ethernet Card. I only require a 100MB. Thank you, Rick

2 1

Mystery crashes
by Eugene de Villiers 24 Feb '04

24 Feb '04

My dual opteron 242 K8W thunder with 4Gb of DDR400 Reg ECC has been running Suse 9.0 for a couple of weeks now. Everything seems to be working fine and memtest showed no problems. Unfortunately, every few days or so (it has happened 3 times now), the system just freezes up, and I mean completely. No logins, no escapes, no keyboard or mouse response at all. It still responds to pings though, which is strange since no other remote operations are successful. There are no messages in the logs (at least the ones I've checked), so I assume its probably hardware related. Any advice/checks I can try? Its not debilitating since, but it sure is worrisome. Eugene _________________________________________________________________ G-string or thermal underwear? Find out at MSN Weather! http://www.msn.co.za/weather/

7 9