openSUSE PPC September 2013

ppc@lists.opensuse.org

8 participants
8 discussions

[opensuse-ppc] Thank you very much indeed for openSUSE 12.2

by Christian Zigotzky

Hi list, Thank you very much indeed for openSUSE 12.2 PowerPC. It runs very well on my Power Mac G5 2003, 2.0GHz, 4 GB RAM, ATi Radeon 9600 128 MB with sound and X11 support. Unfortunately Firefox doesn't work. I use the Firefox by ppcnux.de. Are there any updates available for openSUSE 12.2 PowerPC e.g. Firefox 16? Cheers, Christian -- To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org

5 years, 8 months

[opensuse-ppc] Factory CD boot problem

by Andreas Färber

Hello, Since a number of weeks I am unsuccessful in using the ppc64 install media on my POWER5+ box. Below is output from latest openSUSE-NET64-ppc64-Build0023-Media.iso. In qemu-system-ppc64 it proceeds okay, and Factory boots okay (below). The only difference is me entering SMS menu to select booting from IDE CD. I notice that the booting system loads an Elf64 kernel while the ppc64 iso loads an Elf32 kernel. Any ideas? Thanks, Andreas CD: yaboot starting: loaded at 00040000 00065a88 (0/0/02039a68; sp: 02cbffd0) Config file 'yaboot.cnf' read, 285 bytes Welcome to openSuSE Factory! Type "install" to start the YaST installer on this CD/DVD Type "slp" to start the YaST install via network Type "rescue" to start the rescue system on this CD/DVD Welcome to yaboot version r22.8-r1190.SuSE booted from '/pci@800000020000003/pci@2,3/ide@1/disk@0:1,\suseboot\yaboot.ibm' running with firmware 'IBM,SF240_284' on model 'IBM,9111-285', serial 'IBM,*********', partition '06-C903E' Enter "help" to get some basic usage information boot: install slp rescue boot: install Please wait, loading kernel... Allocated 02f00000 bytes for executable @ 03000000 Elf32 kernel loaded... SuSE Linux zImage starting: loaded at 03000000-05dc0d30 (4000000/0/02039a68; sp: 02cbfd90) uncompressing ELF header done. (00000100 bytes) Allocated 018461cc bytes for kernel @ 05f00000 Leave 027c7fc4 bytes for initrd @ 035ecece uncompressing kernel done. (01240ef8 bytes) entering kernel at 05f10000(35ecece/27c7fc4/02039a68) OF stdout device is: /vdevice/vty@30000000 Preparing to boot Linux version 3.10.1-3.g0cd5432-default (geeko@buildhost) (gcc version 4.8.1 20130711 [gcc-4_8-branch revision 200903] (SUSE Linux) ) #1 SMP Fri Jul 19 14:39:31 UTC 2013 (0cd5432) Detected machine type: 0000000000000101 Max number of cores passed to firmware: 512 (NR_CPUS = 1024) Calling ibm,client-architecture-support... not implemented command line: quiet sysrq=1 insmod=sym53c8xx insmod=ipr memory layout at init: memory_limit : 0000000000000000 (16 MB aligned) alloc_bottom : 0000000007470000 alloc_top : 0000000008000000 alloc_top_hi : 0000000077000000 rmo_top : 0000000008000000 ram_top : 0000000077000000 found display : /pci@800000020000002/display@1, opening... done Could not allocate memory for RTAS EXIT called ok 0 > Disk: yaboot starting: loaded at 00040000 00065a88 (0/0/02039a68; sp: 02cbffd0) Config file 'yaboot.cnf' read, 611 bytes Welcome to yaboot version r22.8-r1190.SuSE booted from '/pci@800000020000003/pci@2,4/pci1069,b166@1/scsi@0/sd@8,0:1,yaboot' running with firmware 'IBM,SF240_284' on model 'IBM,9111-285', serial 'IBM,*********', partition '06-C903E' Enter "help" to get some basic usage information boot: Linux_4 Using 01401f9c bytes for initrd buffer Please wait, loading kernel... Allocated 01700000 bytes for kernel @ 03000000 Elf64 kernel loaded... Loading ramdisk... ramdisk loaded 01401f9c @ 04700000 OF stdout device is: /vdevice/vty@30000000 Preparing to boot Linux version 3.10.1-3.g0cd5432-default (geeko@buildhost) (gcc version 4.8.1 20130711 [gcc-4_8-branch revision 200903] (SUSE Linux) ) #1 SMP Fri Jul 19 14:39:31 UTC 2013 (0cd5432) Detected machine type: 0000000000000101 Max number of cores passed to firmware: 512 (NR_CPUS = 1024) Calling ibm,client-architecture-support... not implemented command line: root=/dev/disk/by-uuid/671e0a08-2bb3-4fae-b606-287d887e2060 quiet sysrq=1 insmod=sym53c8xx insmod=ipr memory layout at init: memory_limit : 0000000000000000 (16 MB aligned) alloc_bottom : 0000000005b10000 alloc_top : 0000000008000000 alloc_top_hi : 0000000077000000 rmo_top : 0000000008000000 ram_top : 0000000077000000 found display : /pci@800000020000002/display@1, opening... done instantiating rtas at 0x00000000076a0000... done Querying for OPAL presence... not there. boot cpu hw idx 0 copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x0000000005b20000 -> 0x0000000005b21372 Device tree struct 0x0000000005b30000 -> 0x0000000005b40000 no ibm,pcie-link-speed-stats property no ibm,pcie-link-speed-stats property no ibm,pcie-link-speed-stats property /home/abuild/rpmbuild/BUILD/kernel-default-3.10.1/linux-3.10/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) doing fast boot [...] -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org

5 years, 10 months

Re: [opensuse-ppc] servergy

by Peter Czanik

Hello, On 09/20/2013 11:11 PM, Brandon Moore wrote: > Alexander: Thank you so much, sir > > Peter: > > Thank you so much for your interest in Servergy! We did receive your > request and we are currently finalizing pricing and availability for > both the CTS-1000 and P-Cubed at this time. Wow, that's great news! > However, i can answer your questions from your request: > >> P-cubed, if it has at least two Ethernet ports > > The current plan for the P-Cubed is an single ethernet port. A second Ethernet port would make it great board for security / networking guys. >> I have two plans with the machine: porting the Zorp proxy firewall >> (developed by BalaBit) and see how it performs compared to x86. > > Can you tell me more about your timeframes for porting, testing > (success criteria and plan) and evaluation? Actually there is no timeframe. It is not an official BalaBit plan, at least not an official company goal. On the other hand many of my colleagues support the idea and find it very interesting. Zorp is often running now on huge x86 servers, and many of us think, that QorIQ would do the same job at a fraction of the size or energy requirements. And a successful PoC could turn it into a company project on the long run. > >> And as an openSUSE fan, I'd like to bring up the openSUSE Power port >> on it (which I used earlier on Genesi PowerPC machines). > > We have created live-fs of our own port of SUSE, as well as other > applications/utilities for Linux like OpenStack and memcached. I > would be interested what other things you would want to > explore with our platform. We are definitely looking for more > software contributions compiled for our platform. Personally I did Linux distro QA for a couple of PowerPC machines for about five years (I must admit, that I did boot my Pegasos2 this year only once...). This included creating installers, reporting bugs, asking for features to make life of distro users easier. I did it mostly for openSUSE and Ubuntu, sometimes other distributions. My other interests are different IDS softwares, like Bro, Suricata, etc. Bye, CzP -- To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org

7 years, 3 months

[opensuse-ppc] servergy

by Peter Czanik

Hello, Does anybody know Servergy? It's a US company producing Freescale QorIQ based machines, and they even have an openSUSE logo at a couple of places on their website. For example http://www.servergy.com/p-cubed/ My problem is, that they don't seem to respond to anything. Do you know anything about this company or have access to one of their machines? The Cleantech server is just what the doctor prescribed me :-) Bye, CzP -- To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org

7 years, 4 months

[opensuse-ppc] Drop ppc32 from Factory

by Dinar Valeev

We have more and more devel projects which have Factory:PowerPC build targets enabled. Is there anybody who uses 32bit, can we drop it to save build power? Have fun, Dinar -- To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org

7 years, 4 months

[opensuse-ppc] Offering help / Testing builds

by manni86＠gmx.net

Hello everyone, I'm looking for a way to help you building openSUSE for PowerPC. I have an iMac G5/2.1GHz 20-Inch 2.5GB-RAM (iSight) which is waiting for a task. On the website you wrote that you are "actively looking for people to test" your builds. (http://en.opensuse.org/Portal:PowerPC) So if you have any test iso images, or builds then please let me know how I may help you out in testing. I'm not very skilled in programming, so actual software development is not a task for me, but I can do some tests. I did already some testing with MintPPC/Debian, especially regarding some problems with 3D hardware acceleration under PPC. I explained some of the problems which I did run into in the forum of MintPPC (http://www.mintppc.org/forums/viewtopic.php?f=18&t=1281). I also already tried openSUSE in past, but just for a very short time and I can't remember the outcome of my last tests anymore, I just tried too much back then. However, since MintPPC won't see any further development from it's original developer, I would like now to switch to openSUSE and help you out if I can. So if you have any test iso, or something that I might be able to help you with, please let me know. I wish you all a nice day. -Manuel -- To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org

7 years, 4 months

[opensuse-ppc] Fwd: glibc segfault analysis

by Alexander Graf

Hey guys, I've tried to run openSUSE 12.3 on a Freescale e5500 system and it immediately segfaults on every binary. Turns out the root cause is that glibc is configured to power4 compatibility which hardcodes the cache line size to 128 bytes while e5500 has a 64 byte cache line size. There are 2 things I think we should do here: - compile the non-target-optimized glibc without --with-cpu=power4. We already have accelerated versions for power5 and above, so I don't think it's necessary to optimize the base variant for anything but a generic target - fix glibc to work on non-128byte cache line size even when --with-cpu=power4 is specified. I doubt there really is any non-negligible performance difference for the memset() case where dcbz gets used. But if there is, why don't we just binary patch the cache line size into memset()'s li instruction and always be fast? Alex Begin forwarded message: > From: Yang James-RA8135 <RA8135(a)freescale.com> > Subject: RE: glibc segfault analysis > Date: 12. September 2013 11:44:20 GMT-05:00 > To: Yang James-RA8135 <RA8135(a)freescale.com>, Graf Alexander-B36701 <B36701(a)freescale.com>, Yoder Stuart-B08248 <B08248(a)freescale.com> > Cc: Wienskoski Edmar-RA8797 <RA8797(a)freescale.com>, Newton Peter-RA3823 <RA3823(a)freescale.com> > > I talked to Alex this morning and he confirms that the glibc is power4-targeted. > > Alex also tried hexediting the libc.so but that still resulted in segfault > > I took a look at doing it, and I have found that it is not just the libc.so's memset that needs to be patched, but that ld.so itself has its own copy of memset. > > Once both are patched to force 64-byte dcbz, the program runs without segfault. > > > > -----Original Message----- > From: Yang James-RA8135 > Sent: Thursday, September 12, 2013 3:25 AM > To: Graf Alexander-B36701; Yoder Stuart-B08248 > Cc: Wienskoski Edmar-RA8797; Newton Peter-RA3823 > Subject: glibc segfault analysis > > OK, I think I have figured out the cause of the problem with the segfaulting in SUSE glibc. Edmar, you probably know of this already (and maybe it is also the same reason as the other email thread from Peter's problem from last year). > > It boils down to the powerpc64 memset in glibc in the libc-2.17.so is one of the powerX versions rather than the generic powerpc64 one. The powerX versions, such as power4, hard code a 128 byte cache line size without reading the global variable that is set up to tell you what the cache line size is, even though that variable is set up for 64 bytes (which is what it is on e5500/e6500). Here is a link to the code in glibc top of tree (assuming SUSE sets up glibc to target power4): > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/powerpc64/… > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/powerpc64/… > > relevant diff -u: > > @@ -160,22 +155,15 @@ > /* If the remaining length is less the 32 bytes, don't bother getting > the cache line size. */ > beq L(medium) > - ld rCLS,.LC0@toc(r2) > - lwz rCLS,0(rCLS) > -/* If the cache line size was not set just goto to L(nondcbz) which is > - safe for any cache line size. */ > - cmpldi cr1,rCLS,0 > - beq cr1,L(nondcbz) > - > + li rCLS,128 /* cache line size is 128 */ > > > > Here is the imem showing the memset loop (dcbz) > > instaddr branch target #times instruction > 000000002df7d8a0< 000000002df7d960> 4 beq- 0x00c0 0.00% 0.00% 0.00% 100.00% > 000000002df7d8a4 4 addi r8,r0,0x0080 // XXX: here is the hard-coded 128-byte stride > 000000002df7d8a8 4 dcbt r0,r6 > 000000002df7d8ac< 9 cmpldi cr1,r5,0x0020 > 000000002df7d8b0 9 andi. r0,r6,0x007f > 000000002df7d8b4 000000002df7d8f0> 9 blt- cr1,0x003c 0.00% 12.50% 25.00% 62.50% > 000000002df7d8b8 000000002df7d8d8> 7 beq- 0x0020 16.67% 16.67% 16.67% 50.00% > 000000002df7d8bc 5 addi r6,r6,0x0020 > 000000002df7d8c0 5 addi r5,r5,0xffe0 > 000000002df7d8c4 5 std r4,-32(r6) > 000000002df7d8c8 5 std r4,-24(r6) > 000000002df7d8cc 5 std r4,-16(r6) > 000000002df7d8d0 5 std r4,-8(r6) > 000000002df7d8d4 000000002df7d8ac> 5 b 0xffffffd8 100.00% 0.00% 0.00% 0.00% > 000000002df7d8d8< 30 cmpld cr1,r5,r8 > 000000002df7d8dc 000000002df7d8f0> 30 blt- cr1,0x0014 0.00% 3.45% 6.90% 89.66% > 000000002df7d8e0 28 dcbz r0,r6 > 000000002df7d8e4 28 subf r5,r8,r5 > 000000002df7d8e8 28 add r6,r6,r8 // XXX: here is the dcbz stride increment of 128 bytes > 000000002df7d8ec 000000002df7d8d8> 28 b 0xffffffec 100.00% 0.00% 0.00% 0.00% > 000000002df7d8f0< 4 rlwinm. r7,r5,0,0,26 > 000000002df7d8f4 000000002df7d838> 4 b 0xffffff44 100.00% 0.00% 0.00% 0.00% > .... > > And the dcbz EA (first column of 64-bit hex) at 128-byte stride from tte_dump: > > ra8135@squirrel:/mnt$ tte_dump on-squirrel-217.tte | grep dcbz > 00000fffb7fe9900 14757 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9980 14763 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9a00 14769 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9a80 14775 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9b00 14781 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9b80 14787 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9c00 14793 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9c80 14799 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9d00 14805 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9d80 14811 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9e00 14817 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9e80 14823 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9f00 14829 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7fe9f80 14835 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe000 20532 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe080 20538 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe100 20544 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe180 20550 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe200 20556 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe280 20562 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe300 20568 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe380 20574 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe400 20580 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe480 20586 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe500 20592 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe580 20598 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe600 20604 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > 00000fffb7ffe680 20610 <000000002df7d8e0-7C0037EC> * dcbz r0,r6 > > In contrast, Debian's eglibc 2.11.3 has a working memset (or at least it's not choosing the power4 one by default): > > ra8135@squirrel:/mnt$ tte_dump on-squirrel-211.tte | grep dcbz > 00000fffb7fbb200 19348 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb240 19354 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb280 19360 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb2c0 19366 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb300 19372 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb340 19378 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb380 19384 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb3c0 19390 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb400 19396 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb440 19402 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb480 19408 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb4c0 19414 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb500 19420 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb540 19426 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb580 19432 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > 00000fffb7fbb5c0 19438 <00000fffb7fe6530-7C0037EC> * dcbz r0,r6 > etc etc etc > > > Since memset is used to initialize the bss, the broken version skips zeroing every other cache line. The leaf function that causes the segfault, __new_exitfn() in stdlib/cxa_atexit.c, walks over a linked list of destructor functions to register them. The initial list is supposed to be empty, and it is declared in the same file as " static struct exit_function_list initial;", i.e. allocated in bss, which the memset code is supposed to clear but actually doesn't. The first element of the initial list happens to have a non-zero next pointer value of 8, which it then tries to fetch the next element of the list from, resulting in the segfault. > > struct exit_function * > __new_exitfn (struct exit_function_list **listp) { > struct exit_function_list *p = NULL; > struct exit_function_list *l; > struct exit_function *r = NULL; > size_t i = 0; > > __libc_lock_lock (lock); > > for (l = *listp; l != NULL; p = l, l = l->next) > { > for (i = l->idx; i > 0; --i) > if (l->fns[i - 1].flavor != ef_free) > break; > > if (i > 0) > break; > > /* This block is completely unused. */ > l->idx = 0; > } > // ... > > 0000000b 00000003 0000001c 00000fff b7fd7490 // Operand r28 holds 0x00000fffb7fd7490 > 00000fffb7fd7490 135663 <00000fffb7e76e90-EBBC0000> * ld r29,0(r28) // l = *listp > 0000000b 00000003 0000001d 00000fff b7fe9e60 // Operand r29 holds 0x00000fffb7fe9e60 > 135664 <00000fffb7e76e94-2FBD0000> * cmpdi cr7,r29,0x0000 // l != NULL? > 0000001c 00000001 22000424 // Operand CR holds 0x22000424 > 00000fffb7e76e9c 135665 <00000fffb7e76e98-419E0154> * beq- cr7,0x0154 > 0000000b 00000003 0000001d 00000fff b7fe9e60 // Operand r29 holds 0x00000fffb7fe9e60 > 0000000b 00000003 0000001d 00000fff b7fe9e60 // Operand r29 holds 0x00000fffb7fe9e60 > 135666 <00000fffb7e76e9c-7FA6EB78> * or r6,r29,r29 // l = *listp copy > 135667 <00000fffb7e76ea0-38600000> * addi r3,r0,0x0000 > 135668 <00000fffb7e76ea4-38800000> * addi r4,r0,0x0000 > 0000000b 00000003 00000000 00000fff b7e7708c // Operand r0 holds 0x00000fffb7e7708c > 135669 <00000fffb7e76ea8-60000000> * ori r0,r0,0x0000 > 0000000b 00000003 00000000 00000fff b7e7708c // Operand r0 holds 0x00000fffb7e7708c > 135670 <00000fffb7e76eac-60000000> * ori r0,r0,0x0000 > 0000000b 00000003 00000006 00000fff b7fe9e60 // Operand r6 holds 0x00000fffb7fe9e60 > 00000fffb7fe9e68 135671 <00000fffb7e76eb0-E8E60008> * ld r7,8(r6) // i = l->idx > 0000000b 00000003 00000007 00000000 00000000 // Operand r7 holds 000000000000000000 > 135672 <00000fffb7e76eb4-2FA70000> * cmpdi cr7,r7,0x0000 // i > 0 ? > 0000001c 00000001 22000422 // Operand CR holds 0x22000422 > 00000fffb7e76f0c ! 135673 <00000fffb7e76eb8-419E0054> * beq- cr7,0x0054 > 0000000b 00000003 00000006 00000fff b7fe9e60 // Operand r6 holds 0x00000fffb7fe9e60 > 00000fffb7fe9e60 135674 <00000fffb7e76f0c-E9260000> * ld r9,0(r6) // temp_l = l->next > 0000000b 00000003 00000004 00000000 00000000 // Operand r4 holds 000000000000000000 > 0000000b 00000003 00000006 00000fff b7fe9e60 // Operand r6 holds 0x00000fffb7fe9e60 > 00000fffb7fe9e68 135675 <00000fffb7e76f10-F8860008> * std r4,8(r6) // l->idx = 0 > 0000000b 00000003 00000006 00000fff b7fe9e60 // Operand r6 holds 0x00000fffb7fe9e60 > 0000000b 00000003 00000006 00000fff b7fe9e60 // Operand r6 holds 0x00000fffb7fe9e60 > 135676 <00000fffb7e76f14-7CC33378> * or r3,r6,r6 > 0000000b 00000003 00000009 00000000 00000008 // Operand r9 holds 000000000000000008 // XXX: temp_l address is 8 > 135677 <00000fffb7e76f18-2FA90000> * cmpdi cr7,r9,0x0000 > 0000001c 00000001 22000424 // Operand CR holds 0x22000424 > 00000fffb7e76f20 135678 <00000fffb7e76f1c-419E009C> * beq- cr7,0x009c > 0000000b 00000003 00000009 00000000 00000008 // Operand r9 holds 000000000000000008 > 0000000b 00000003 00000009 00000000 00000008 // Operand r9 holds 000000000000000008 > 135679 <00000fffb7e76f20-7D264B78> * or r6,r9,r9 > 00000fffb7e76eb0 ! 135680 <00000fffb7e76f24-4BFFFF8C> * b 0xffffff8c > 0000000b 00000003 00000006 00000000 00000008 // Operand r6 holds 000000000000000008 > 0000000000000010 135681 <00000fffb7e76eb0-E8E60008> * ld r7,8(r6) // XXX: *temp_l causes segfault > > > So, yeah, I doubt SUSE necessarily say they support P5020 or really any powerpc that has 64-byte dcbz, but wouldn't it be nice if glibc had a way of indicating that the detected cache line size doesn't match what it has been tuned for? > -- To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org

7 years, 4 months

[opensuse-ppc] yaboot package rework and installation media

by Dinar Valeev

Hi, recently dropped inst{32,64} generation. Now only initrd and kernel are available to boot. Looking at yaboot (lilo) package it still requires gcc-32bit runtime dependency. Looked briefly through the code it seems only boot from iSCSI needs it. maybe embedding yaboot.conf into a binary. Once it will be reworked, finally yaboot will not require gcc-32bit. JFYI Have fun, Dinar -- To unsubscribe, e-mail: opensuse-ppc+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ppc+owner(a)opensuse.org

7 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

openSUSE PPC September 2013