dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack):
Hi folks, Would anyone know what to do with perotto.d.n ? Thanks Here is what I get today: % sessionid=$(schroot -b -c sid) % dd-schroot-cmd -c $sessionid apt-get update % dd-schroot-cmd -c $sessionid apt-get upgrade [..] Preparing to unpack .../usr-is-merged_38_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_38_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Command apt-get --assume-yes -o Dpkg::Options::=--force-confnew upgrade exited with exit code 1.
Tracking a bug on POWER10
Hi there, I vaguely remember someone mentioning a service where one could ssh onto ppc64el machines. I need access to a POWER10 machine to track a bug. platti.d.o is POWER8 AFAIK. Thanks !
Re: Need for manual link to libatomic on powerpc?
On Tue, Aug 23, 2022 at 3:34 PM Jeffrey Walton wrote: > > Hi Everyone, > > I'm trying to track down a Crypto++ 8/GCC 12 bug at [1,2]. Our Debian > maintainer, who is helping with testing, mentioned we were missing > libatomic during link when using santiziers on powerpc and hppa.[3,4] > That kind of caught me off-guard. > > On Fedora (but not Debian in the past), we needed to install gcc, g++, > libasan, libubsan and friends. Libraries for Asan and Ubsan are > separate installs on Fedora (but not Debian). However, once installed, > the compiler driver added the necessary libs (like libubsan and > libatomic) when it encountered an option like -fsanitize=undefined. > > My question is, are libasan, libubsan and friends a separate install > for Debian on powerpc and hppa? > > If not, does anyone know why libatomic might not be added by the > compiler driver when needed on Debian powerpc? Last time I asked, I was reminded the status: * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104248#c4 Long story short, gcc will not automatically add -latomic for you .. end of story :(
Re: red background always during install
On Mon, Mar 28, 2022 at 10:00 AM Dennis Clarke wrote: > > On 3/28/22 03:56, Mathieu Malaterre wrote: > > On Mon, Mar 28, 2022 at 9:52 AM Dennis Clarke wrote: > >> > >> > >> Red background always during install : > >> > >> https://i.imgur.com/ja5SI2x.png > >> > >> Strange but true :\ > >> > >> Same thing I saw last year and the year before that etc ... > > > > Can you check that radeonfb module was loaded ? I believe Alt+F2 gives > > you a shell during the install. > > > > https://bugs.debian.org/826629 > > > > Thanks > > Computer says no. :) sorry. > > I checked /proc/modules and there is no radeon to be seen at all. How about: $ dmesg | grep radeon
Re: red background always during install
On Mon, Mar 28, 2022 at 9:52 AM Dennis Clarke wrote: > > > Red background always during install : > > https://i.imgur.com/ja5SI2x.png > > Strange but true :\ > > Same thing I saw last year and the year before that etc ... Can you check that radeonfb module was loaded ? I believe Alt+F2 gives you a shell during the install. https://bugs.debian.org/826629 Thanks
Re: Poll: Is anyone using nouveau driver on ppc64 system?
John, On Mon, Oct 11, 2021 at 10:34 PM John Ogness wrote: > > Hi Mathieu, > > On 2021-10-07, Mathieu Malaterre wrote: > > One of the kernel maintainers is wondering if the nouveau driver is > > completely broken with 64K pages ? > > > > So my question is simply: is anyone out there using a ppc64 system > > with nouveau on a default linux-image-powerpc64 debian system (64K > > page). I am only interested in ppc64be system only. > > My main desktop machine at home is a PowerMac G5 (Dual PPC970, > PowerMac7,2), so it gets lots of daily use for audio, video, and web > browsing. The graphic card is: > > :f0:10.0 VGA compatible controller: NVIDIA Corporation NV34 [GeForce FX > 5200 Ultra] (rev a1) Thanks for your report ! In case you have not seen it before, this is known as: * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790690 It is unlikely that the root issue will ever be solved, so we need to provide a 4K page kernel for the affected users. As you've seen from another user report, it appears that nouveau may work under certain work load: * https://lists.debian.org/debian-powerpc/2021/10/msg00068.html -M
Re: Poll: Is anyone using nouveau driver on ppc64 system?
Hi Stephen ! On Fri, Oct 8, 2021 at 8:34 AM Stephen Harker wrote: > > Hi Mathieu, > > > One of the kernel maintainers is wondering if the nouveau driver is > > completely broken with 64K pages ? > > > > So my question is simply: is anyone out there using a ppc64 system > > with nouveau on a default linux-image-powerpc64 debian system (64K > > page). I am only interested in ppc64be system only. > > I have debian running as below. I am emailing from my old Fedora 28 > partition as I had not got around to enabling email from Debian. I > have had no problems with X11 using a GeForce 6600 LE (until recently > I was using a 7600GTX 512 and, despite not fixing some boot settings, > it is working with the 6600). The glxinfo below may be partly > incorrect due to those settings. > > uname -a output: > > Linux 5.10.0-8-powerpc64 #1 SMP Debian 5.10.46-4 (2021-08-03) ppc64 > GNU/Linux > > cat /proc/cpuinf:o > > processor : 0 > cpu : PPC970MP, altivec supported > clock : 2000.00MHz > revision: 1.1 (pvr 0044 0101) > > processor : 1 > cpu : PPC970MP, altivec supported > clock : 2000.00MHz > revision: 1.1 (pvr 0044 0101) > > timebase: > platform: PowerMac > model : PowerMac11,2 > machine : PowerMac11,2 > motherboard : PowerMac11,2 MacRISC4 Power Macintosh > detected as : 337 (PowerMac G5 Dual Core) > pmac flags : > L2 cache: 1024K unified > pmac-generation : NewWorld > > glxinfo (partly cut for space): > > name of display: :0 > display: :0 screen: 0 > direct rendering: Yes > server glx vendor string: SGI > server glx version string: 1.4 > server glx extensions: > GLX_ARB_create_context, GLX_ARB_create_context_no_error, > GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, > GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, > GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, > GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, > GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_no_config_context, > GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, > GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, > GLX_SGI_swap_control > client glx vendor string: Mesa Project and SGI > client glx version string: 1.4 > client glx extensions: > GLX_ARB_context_flush_control, GLX_ARB_create_context, > GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, > GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, > GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, > GLX_ATI_pixel_format_float, GLX_EXT_buffer_age, > GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, > GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, > GLX_EXT_import_context, GLX_EXT_no_config_context, GLX_EXT_swap_control, > GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, > GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, > GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_NV_float_buffer, > GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, > GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, > GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync > GLX version: 1.4 > GLX extensions: > GLX_ARB_create_context, GLX_ARB_create_context_no_error, > GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, > GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, > GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, > GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, > GLX_EXT_import_context, GLX_EXT_no_config_context, GLX_EXT_swap_control, > GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, > GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, > GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, > GLX_SGI_swap_control, GLX_SGI_video_sync > Extended renderer info (GLX_MESA_query_renderer): > Vendor: nouveau (0x10de) > Device: NV43 (0x142) > Version: 21.2.3 > Accelerated: yes > Video memory: 108MB > Unified memory: no > Preferred profile: compat (0x2) > Max core profile version: 0.0 > Max compat profile version: 2.1 > Max GLES1 profile version: 1.1 > Max GLES[23] profile version: 2.0 > OpenGL vendor string: nouveau > OpenGL renderer string: NV43 > OpenGL version string: 2.1 Mesa 21.2.3 > OpenGL shading language version string: 1.20
Poll: Is anyone using nouveau driver on ppc64 system?
Hi all, One of the kernel maintainers is wondering if the nouveau driver is completely broken with 64K pages ? So my question is simply: is anyone out there using a ppc64 system with nouveau on a default linux-image-powerpc64 debian system (64K page). I am only interested in ppc64be system only. Thanks for your time,
Re: X stopped working with 5.14 on iBook
On Thu, Oct 7, 2021 at 10:21 AM John Paul Adrian Glaubitz wrote: > > On 10/7/21 06:16, Stan Johnson wrote: > > Compiling the downloaded kernel-source using Debian's .config file > > "config.powerpc_none_powerpc.xz" resulted in a 200 MB kernel (perhaps > > because it included all possible options), and I couldn't get it to boot > > (but I also didn't compile or install any modules). But compiling using > > the same .config file (see attached) that I've been using for testing > > 5.13 kernels, and that I also used for the above kernels that worked, > > results in a working 12 MB kernel, and X is also working: > > > > # uname -a > > Linux ppc-cube 5.14.9-pmac #2 SMP Wed Oct 6 21:38:58 MDT 2021 ppc GNU/Linux > > # ls -l vmlinux > > -rwxr-xr-x 1 root root 12382136 Oct 6 15:39 vmlinux > > > > So I think the problem with the default kernel in Debian SID (5.14.0-2) > > has already been fixed, or perhaps there was an issue with the options > > that were selected for the .config file. Either way, it doesn't appear > > that a bisect is needed. > > Well, we still have the Debian stock kernel not working. So we might be > missing a kernel option that is required for X to work on the PowerMacs. This one ? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790690 > Did you try building a custom kernel with the config file located in the > /boot directory? > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: Altivec in baseline for ppc64?
On Tue, Jul 13, 2021 at 7:21 PM Sébastien Villemot wrote: > > Hi Mathieu, > > Le mardi 13 juillet 2021 à 18:56 +0200, Mathieu Malaterre a écrit : > > > > On Tue, Jul 13, 2021 at 2:04 PM Sébastien Villemot > > wrote: > > > > > > The wiki page that synthesizes architecture specificities indicates > > > that Altivec is included in the baseline for the ppc64 port: > > > https://wiki.debian.org/ArchitectureSpecificsMemo#ppc64 > > > > > > However my understanding is that this port supports any powerpc64 CPU, > > > including some that don’t have Altivec (e.g. POWER4 or POWER5). This is > > > also what the main wiki page for PPC64 says: > > > https://wiki.debian.org/PPC64 > > > > > > Can someone please clarify the situation? > > > > > > (I’m asking because I’m the maintainer of the openblas package, and > > > knowing whether Altivec is available or not, and more generally what is > > > in the baseline, is essential for proper packaging). > > > > I do not believe that you can do much as a packager. You cannot assume > > anything on the target arch. You need to do the same thing as ffmpeg > > is doing for avx2/sse4 on amd64, you need to do runtime detection. So > > unless upstream is doing something very clever you cannot compile blas > > using any of the fancy altivec instructions :( > > > > The man page for ld.so mentions something about optimized libraries > > (search for "/usr/lib/sse2/"), but this is currently not in use in > > Debian (AFAIK). > > Actually OpenBLAS has its own runtime detection mechanism, which is > used to select the best linear algebra kernel for the current CPU > (those kernels are mainly written in assembly, and take advantage of > available ISA extensions). This mechanism is used on several archs, > including ppc64el (so at runtime, OpenBLAS chooses between a POWER8 and > a POWER9 kernel; there is even a POWER10 kernel already available). > > However, I cannot enable this mechanism on ppc64 and powerpc, because > the runtime detection only works for POWER6 and above, and my > understanding is that for these two ports the baseline is lower. Hence > on these two archs, only one kernel is included in the package binaries > (currently POWER4 for ppc64 and PPCG4 for powerpc). For optimal > performance, users should recompile OpenBLAS locally (as indicated in > the package description and in README.Debian). There are plenty of people on this mailing list that could test/verify that. Is there a quick way to check that your openblas package is compiled correctly for ppc32 and ppc64 (like a verbose mode) ? Did you do any experiment on perotto.debian.net ? > I am however not sure that my current choices for the ppc64 and powerpc > baselines are optimal, hence this thread. > > -- > ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer > ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name > ⠈⠳⣄ https://www.debian.org >
Re: Altivec in baseline for ppc64?
Hi Sébastien, On Tue, Jul 13, 2021 at 2:04 PM Sébastien Villemot wrote: > > Hi, > > The wiki page that synthesizes architecture specificities indicates > that Altivec is included in the baseline for the ppc64 port: > https://wiki.debian.org/ArchitectureSpecificsMemo#ppc64 > > However my understanding is that this port supports any powerpc64 CPU, > including some that don’t have Altivec (e.g. POWER4 or POWER5). This is > also what the main wiki page for PPC64 says: > https://wiki.debian.org/PPC64 > > Can someone please clarify the situation? > > (I’m asking because I’m the maintainer of the openblas package, and > knowing whether Altivec is available or not, and more generally what is > in the baseline, is essential for proper packaging). I do not believe that you can do much as a packager. You cannot assume anything on the target arch. You need to do the same thing as ffmpeg is doing for avx2/sse4 on amd64, you need to do runtime detection. So unless upstream is doing something very clever you cannot compile blas using any of the fancy altivec instructions :( The man page for ld.so mentions something about optimized libraries (search for "/usr/lib/sse2/"), but this is currently not in use in Debian (AFAIK). 2cts
Re: Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2
Salvatore, On Sun, May 2, 2021 at 8:59 AM Salvatore Bonaccorso wrote: > > Control: tags -1 + moreinfo > > Hi Mathieu, > > This bug thread was by the time very long but stoppend in 2016. Are > the issues still relevant for us or should we close this bug by now? Thanks for your triaging. It turns out Adrian was able to release an updated d-i for debian-power. So now all mac/ppc32 that were affected with the color inversion are now loading the radeonfb driver instead of the offb one. The bug is no longer visible to users but to (long beard) developers... I am going to close it, no chance upstream will ever fix it.
Re: iMac G5 "windfarm"
Hi Riccardo, On Wed, Dec 30, 2020 at 9:57 AM Riccardo Mottola wrote: > > Hi, > > it is my first time I run linux on an iMac G5 and have some doubts about > its cooling. There was a regression at some point, did you check: * https://lists.debian.org/debian-powerpc/2020/03/msg00035.html What's your kernel version ? > I noticed that while installing Debian, the fan spins at full speed and > it really deserves the term "windfarm", it is as loud as a vacuum cleaner. > > Once Linux is fully installed, the system runs quiet when doing nothing > (console prompt) and remains quiet when doing several things (also > unexpected ones). > > However, e.g. opening GIMP, the fans whir up, just to slow down > immediately. Then, running a filter is smooth (a bit unexpected). > > What I find strange is that fans run shortly full-speed, then stop after > a second or sometimes two! > > I have never run MacOS on this system so I can't tell if this is normal > and if the fan has any intermediate speeds, but this behavior seems strange. > > 1) if the CPU is under "slight load" I would expect the fans to > stabilize to a low speed to keep it cool > > 2) if the CPU has high load indeed, then it probably takes more than > just 1-2 seconds to clear it! > > > in dmesg I see: > > [54879.528590] windfarm: Overtemp condition cleared ! > [55034.523862] windfarm: Clamping CPU frequency to minimum ! > [55034.570358] windfarm: Overtemp condition detected ! > [55036.462349] windfarm: CPU frequency unclamped ! > [55036.513668] windfarm: Overtemp condition cleared ! > > Here it looks that my CPU frequency is temporarily reduced (at the same > time I hear the fan spinning) and if you see the intervals are very > short (only one cycle copy-pasted here, dmesg is much longer) > > > Riccardo >
Re: Possible lex issue for ppc64el (Was: Bug#976906: libpll: FTBFS on ppc64el: lex_utree.l:22:10: fatal error: parse_utree.h: No such file or directory)
"make -j160" that would be my guess :) remove parallel from the dh option, and try again (fixes symptoms) On Thu, Dec 10, 2020 at 10:49 AM Andreas Tille wrote: > > Control: tags -1 help > > Hi, > > I tried to investigate the situation below and my guess is that lex has > somehow problems to create the missing header files. I've found the > files in upstreams .gitignore file so these need to be created but this > does not seem to work on ppc64el (any more - since the package has build > successfully before). > > Any hint to tackle this is welcome > > Andreas. > > On Wed, Dec 09, 2020 at 09:37:42AM +0100, Lucas Nussbaum wrote: > > Source: libpll > > Version: 0.3.2-3 > > Severity: serious > > Justification: FTBFS on ppc64el > > Tags: bullseye sid ftbfs > > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed to build > > on ppc64el. At the same time, it did not fail on amd64. > > > > I'm marking this bug as severity:serious since your package currently has > > ppc64el binary packages in unstable (so this is a regression). > > > > Relevant part (hopefully): > > > /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > > > -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE > > > -std=c99 -O3 -fPIC -g -c -o libpll_la-lex_utree.lo `test -f 'lex_utree.c' > > > || echo './'`lex_utree.c > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c fasta.c -fPIC -DPIC -o .libs/libpll_la-fasta.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c pll.c -fPIC -DPIC -o .libs/libpll_la-pll.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c likelihood.c -fPIC -DPIC -o .libs/libpll_la-likelihood.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c maps.c -fPIC -DPIC -o .libs/libpll_la-maps.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c output.c -fPIC -DPIC -o .libs/libpll_la-output.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c utree.c -fPIC -DPIC -o .libs/libpll_la-utree.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c utree_moves.c -fPIC -DPIC -o .libs/libpll_la-utree_moves.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c models.c -fPIC -DPIC -o .libs/libpll_la-models.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c parsimony.c -fPIC -DPIC -o .libs/libpll_la-parsimony.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c core_partials.c -fPIC -DPIC -o .libs/libpll_la-core_partials.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c derivatives.c -fPIC -DPIC -o .libs/libpll_la-derivatives.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c utree_svg.c -fPIC -DPIC -o .libs/libpll_la-utree_svg.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c gamma.c -fPIC -DPIC -o .libs/libpll_la-gamma.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c rtree.c -fPIC -DPIC -o .libs/libpll_la-rtree.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c list.c -fPIC -DPIC -o .libs/libpll_la-list.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c partials.c -fPIC -DPIC -o .libs/libpll_la-partials.o > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > > -g -c compress
Re: G5 Video issue
On Thu, Jun 4, 2020 at 10:50 PM Rui Salvaterra wrote: > > Hi, Adrian, > > A quinta, 4/06/2020, 21:17, John Paul Adrian Glaubitz > escreveu: >> >> >> We should revert to 4k pages on ppc64be then. There is no reason to enable >> 64k pages for us. That may be well the case for ppc64el though. > > > To be honest, I believe there should be two ppc64 kernel flavours. 4 kiB > pages for smaller, mostly desktop systems (say, Power Mac G5 and IBM > IntelliStation systems) and 64 kiB for bigger iron. Would that be feasible? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826796 > Cheers, > Rui
Re: G5 Video issue
On Thu, Jun 4, 2020 at 5:36 PM Scott Thompson wrote: > > I have a Power Mac G5 dual 2.3GHz with 8GB of ram model PowerMac11,2 > with a Nvidia GeForce 6600. The machine is triple booted with OS X > Leopard, Ubuntu 16.04.6, and Debian booting via GRUB. Video works fine > under Leopard and Ubuntu but is basically unusable under Debian once the > desktop is loaded. As one can see in the dmesg file there seems to be > nouveau interrupt issues. [0.00] Linux version 5.6.0-2-powerpc64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-12)) #1 SMP Debian 5.6.14-1 (2020-05-23) Most likely: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767969 > Thanks > > Scott Thompson > > > -- Mathieu
Re: [PATCH 1/2] drm/radeon: disable AGP by default
On Wed, May 13, 2020 at 1:21 PM Christian König wrote: > > Always use the PCI GART instead. Reviewed-by: Mathieu Malaterre > Signed-off-by: Christian König > --- > drivers/gpu/drm/radeon/radeon_drv.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c > b/drivers/gpu/drm/radeon/radeon_drv.c > index bbb0883e8ce6..a71f13116d6b 100644 > --- a/drivers/gpu/drm/radeon/radeon_drv.c > +++ b/drivers/gpu/drm/radeon/radeon_drv.c > @@ -171,12 +171,7 @@ int radeon_no_wb; > int radeon_modeset = -1; > int radeon_dynclks = -1; > int radeon_r4xx_atom = 0; > -#ifdef __powerpc__ > -/* Default to PCI on PowerPC (fdo #95017) */ > int radeon_agpmode = -1; > -#else > -int radeon_agpmode = 0; > -#endif > int radeon_vram_limit = 0; > int radeon_gart_size = -1; /* auto */ > int radeon_benchmarking = 0; > -- > 2.17.1 > -- Mathieu
Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
On Sun, May 10, 2020 at 10:01 PM Paul Gevers wrote: > > Hi Adrian, > > On 10-05-2020 15:25, Paul Gevers wrote: > > I'm running another check on "cannot allocate memory in static TLS > > block" now, will take a while. > > Also for this one, only vtkplotter showed up. Did you check #951704 ? This affect python3 package using jemalloc. > Paul > -- Mathieu
Cross building debian kernel package: scripts/Kconfig.include:39: compiler ' powerpc-linux-gnu-gcc-9' not found
Hi there, I am following instructions from: * https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html So basically I end up doing from my x86_64 arch: $ dpkg-architecture -apowerpc -c fakeroot make -f debian/rules.gen setup_powerpc_none_powerpc64 [...] gcc -o scripts/kconfig/conf scripts/kconfig/conf.o scripts/kconfig/confdata.o scripts/kconfig/expr.o scripts/kconfig/lexer.lex.o scripts/kconfig/parser.tab.o scripts/kconfig/preprocess.o scripts/kconfig/symbol.o scripts/kconfig/util.o scripts/kconfig/conf --listnewconfig Kconfig scripts/Kconfig.include:39: compiler ' powerpc-linux-gnu-gcc-9' not found Which seems to be consistent with the fact that: $ apt-cache policy gcc-powerpc-linux-gnu gcc-powerpc-linux-gnu: Installed: 4:8.3.0-1 Candidate: 4:8.3.0-1 Version table: *** 4:8.3.0-1 500 500 http://deb.debian.org/debian buster/main amd64 Packages 100 /var/lib/dpkg/status Suggestion anyone ?
Re: debian netinst 2020-04-18 claims No space left on device
Le dim. 19 avr. 2020 09:15, Mathieu Malaterre a écrit : > > > Le dim. 19 avr. 2020 08:45, John Paul Adrian Glaubitz < > glaub...@physik.fu-berlin.de> a écrit : > >> On 4/19/20 8:39 AM, John Paul Adrian Glaubitz wrote: >> > It might just be that we will have to increase the size of the HFS boot >> > partition as GRUB requires for disk space these days. >> > >> > Not sure though whether the partition is allowed to be larger by the >> > firmware. >> >> It seems that Gentoo recommends a partition size for the boot partition >> of 128 MB [1]. >> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691207 > Wrong bug report : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610206 I am fine with 128MB also > > Adrian >> >> > [1] https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC) >> >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer - glaub...@debian.org >> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de >> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >> >>
Re: debian netinst 2020-04-18 claims No space left on device
Le dim. 19 avr. 2020 08:45, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> a écrit : > On 4/19/20 8:39 AM, John Paul Adrian Glaubitz wrote: > > It might just be that we will have to increase the size of the HFS boot > > partition as GRUB requires for disk space these days. > > > > Not sure though whether the partition is allowed to be larger by the > > firmware. > > It seems that Gentoo recommends a partition size for the boot partition > of 128 MB [1]. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691207 Adrian > > > [1] https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC) > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: [PATCH v2 4/5] Patch the CHRP boot script
On Tue, Nov 21, 2017 at 3:10 PM Nathan Fontenot wrote: > > On 11/21/2017 03:27 AM, Benjamin Herrenschmidt wrote: > > On Tue, 2017-11-21 at 09:56 +0100, Mathieu Malaterre wrote: > >> Hi Ben, > >> > >> Sorry for the direct question, but I assumed you would know the > >> answer. We are currently trying to replace yaboot with grub-ieee1275 > >> in debian-installer, but are facing a very small issue, namely with OF > >> path handling. It appears that on Apple hardware only `ofpath` from > >> Yaboot returns the correct path. Are you using grub on any of your > >> Apple hardware ? Thanks much for comments. > > > > +Nathan > > > > I have used grub on Apple systems in the past but it's quite possible > > that I ended up fixing up the path by hand. To be honest I haven't > > booted any of my Apple systems in a while, but I still have some I > > can dig out to test if needed. > > > > Some more comments below... > > > >> See below for full context. > >> > >> On Tue, Nov 21, 2017 at 7:51 AM, Frank Scheiner > >> wrote: > >>> Hi Rick, > >>> > >>> On 11/21/2017 02:48 AM, Rick Thomas wrote: > >>>> > >>>> If you can tell me *exactly* what to do, and I don’t have to set up an > >>>> installation environment to do it, I’ll be happy to test ofpathname vs > >>>> ofpath vs devalias on my PowerPC test machine farm. > >>> > >>> > >>> Well, to be on the safe side, I think you need to use the latest versions > >>> of > >>> ofpath and ofpathname, hence running Debian Sid could be the easiest way > >>> to > >>> make sure this is the case. > >>> > >>> You need to have a disk installed, because ofpath and IIC also ofpathname > >>> do > >>> not or cannot translate non existing device aliases to OF paths. > >>> > >>> In general the commands I ran for the p5 520Q below should do. Assuming > >>> that > >>> the output of ofpathname will always be wrong for Power Macs, it should be > >>> sufficient to check only one partition. > >>> > >>> I think devalias does only save/return OF paths up to the disk level, but > >>> not up to the partition level. But the disk level should already be > >>> sufficient to detect differences to ofpath and/or ofpathname. > >>> > >>> You have to go to OF to run devalias, but with a glass console you won't > >>> be > >>> able to copy the output. There are ways to interact with the OF via telnet > >>> from another machine (see [1] and possibly [2]), but I haven't tried this > >>> yet. > >>> > >>> [1]: > >>> https://web.archive.org/web/20040202053614/http://developer.apple.com/technotes/tn/tn2004.html > >>> > >>> [2]: > >>> https://web.archive.org/web/20040202060137/http://developer.apple.com:80/technotes/tn/tn2023.html > >>> > >>>> > >>>> I have the following machines: > >>>> Power Mac G5 11,2, > >>>> Power Mac G5 7,2 (I think — it’s turned off right now) > >>>> Mac mini G4 10,1 > >>> > >>> > >>> I have these types available, too, "except" for the 7,3 which currently > >>> won't start up correctly. > >>> > >>> Here's the output of ofpath and ofpathname for /dev/sda2 on the my Mac > >>> mini > >>> (10,1): > >>> ``` > >>> root@mac-mini:~# ofpath /dev/sda2 > >>> /pci@f400/ata-6@d/@0:2 > >>> > >>> root@mac-mini:~# ofpathname /dev/sda2 > >>> /usr/sbin/ofpathname: line 812: warning: command substitution: ignored > >>> null > >>> byte in input > >>> /pci@f400/ata-6@d/scsi@0/sd@0,0 > > > > So here, ofpathname gets confused by the fact that Linux shows ATA > > devices as scsi (which is a Linux'ism). ofpath has workarounds to deal > > with that which should probably be ported over. > > > >>> > >>> Also interesting, it looks like ofpathname cannot even give a "correct" > >>> result for an IBM machine, at least not for my p5 520Q: > >>> ``` > >>> root@p5-520q:~# lsblk > >>> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > >>> sda 8:00 136.7G 0 disk > >>> ├─sda1 8:10
Re: 64-bit subtract from vector unsigned int
Jeffrey, On Wed, Apr 8, 2020 at 11:56 AM Jeffrey Walton wrote: > > On Tue, Apr 7, 2020 at 8:27 AM Lennart Sorensen > wrote: > > > > On Tue, Apr 07, 2020 at 05:51:54AM -0400, Jeffrey Walton wrote: > > > Hi Everyone, > > > > > > I'm porting a 64-bit algorithm to 32-bit PowerPC (an old PowerMac). > > > The algorithm is simple when 64-bit is available, but it gets a little > > > ugly under 32-bit. > > > > > > PowerPC has a "Vector Subtract Carryout Unsigned Word" (vsubcuw), > > > https://www.nxp.com/docs/en/reference-manual/ALTIVECPEM.pdf. The > > > altivec intrinsics are vec_vsubcuw and vec_subc. > > > > > > The problem is, I don't know how to use it. I've been experimenting > > > with it but I don't see the use (yet). > > > > > > How does one use vsubcuw to implement a subtract with borrow? > > > > Does your 32 bit powerpc have altivec? A lot do not. It is certainly > > not a universal feature. As far as I remember, G4 and G5 powermacs have > > it, but nothing older. > > Yes, this is an old PowerMac G4 with Power4. It has a Altivec unit, > but it is only 32-bit. Add, subtract, shift and rotate (and friends) > on 64-bit values are missing. > > As old as the hardware is (circa 2000), that old PowerPC chip > outperforms some modern hardware, like Atoms, Celerons and low-end ARM > cpu's in modern gadgets. > > Testing some algorithms, like Simon-128 and Speck-128, show a need for > Altivec. For example, Integer-based Speck-128 was running at about 70 > cpb. Altivec-based Speck-128 dropped to 10 cpb even with me doing all > the 64-bit fixups. (Speck-128 runs around 2.5 cpb when the native > hardware supports 64-bit operations, like on Power8). [Somewhat off-topic here.] Did you ever tried crc32 with altivec ? crc32 with altivec in the kernel is only for ppc64.
Re: blaauw: pyFloatGrid.cc.o: 'No space left on device'
On Mon, Feb 17, 2020 at 9:47 AM John Paul Adrian Glaubitz wrote: > > On 2/17/20 8:01 AM, Mathieu Malaterre wrote: > > Could someone please have a look at openvdb build failure: > > > > https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=powerpc&ver=6.2.1-4&stamp=1581890957&raw=0 > > > > I do not know who is responsible for those buildd machines ? > > James and I are responsible. Added: https://wiki.debian.org/Teams/DSA/non-DSA-HW?action=diff > blaauw has crashed multiple times due to a kernel bug that has been > reported and I forgot to clean up the schroot sessions which > kept filling up the filesystem. Right, nice bug report. > > Running "schroot --end-session --all-sessions" now. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
blaauw: pyFloatGrid.cc.o: 'No space left on device'
Dear powerpc team, Could someone please have a look at openvdb build failure: https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=powerpc&ver=6.2.1-4&stamp=1581890957&raw=0 I do not know who is responsible for those buildd machines ? ref: sbuild (Debian sbuild) 0.79.0 (05 February 2020) on blaauw Thanks much
Re: Xorg non starting (was : Re: Updated installation images for Debian Ports 2019-11-22)
On Wed, Dec 25, 2019 at 2:09 AM Bertrand Dekoninck wrote: > > On 24/12/2019 22:39, John Paul Adrian Glaubitz wrote: > > On 12/24/19 10:15 PM, bertrand.dekoni...@gmail.com wrote: > >>> How did you do that. > >> umount /dev/sda2 > >> fsck.hfs /dev/sda2 > >> > >> And then I had got an error. > > What error did you get? FWIW, the hfsprogs package also needs to be updated > > to a newer upstream version - something which is on my TODO list as well. > > Here's a backtrace in gdb : (gdb) run > Starting program: /usr/sbin/fsck.hfs /dev/sdb2 > ** /dev/sdb2 > ** Checking HFS volume. > > Program received signal SIGSEGV, Segmentation fault. > hfs_swap_HFSBTInternalNode (fcb=0x10051920, fcb=0x10051920, > direction=kSwapBTNodeBigToHost, src=0x7fffc9e8) at hfs_endian.c:936 > 936hfs_endian.c: Aucun fichier ou dossier de ce type. > (gdb) print > print print-object printf > (gdb) print > The history is empty. > (gdb) bt > #0 hfs_swap_HFSBTInternalNode (fcb=0x10051920, fcb=0x10051920, > direction=kSwapBTNodeBigToHost, src=0x7fffc9e8) at hfs_endian.c:936 > #1 hfs_swap_BTNode (src=0x7fffc9e8, fcb=0x10051920, > direction=) at hfs_endian.c:307 > #2 0x10022bd4 in GetNode (btreePtr=0x10051ed8, > nodeNum=, nodePtr=0x7fffc9e8) at BTreeNodeOps.c:147 > #3 0x10024e60 in SearchTree (btreePtr=0x10051ed8, > searchKey=0x7fffcc9c, treePathTable=0x7fffcb18, > nodeNum=0x7fffcae4, nodePtr=0x7fffcaf8, > returnIndex=0x7fffcae0) > at BTreeTreeOps.c:231 > #4 0x100203f0 in BTSearchRecord (filePtr=, > searchIterator=0x7fffcc80, heuristicHint=, > record=0x7fffcc68, recordLen=0x7fffcf52, > resultIterator=0x10051f90) > at BTree.c:761 > #5 0x100285c8 in SearchBTreeRecord (fcb=0x10051920, > key=, hint=, foundKey=0x0, > data=, dataSize=0x7fffcf52, newHint=0x0) at > SBTree.c:93 > #6 0x10009624 in CreateCatalogBTreeControlBlock > (GPtr=0x7fffd570) > at SVerify1.c:1171 > #7 0x10004f68 in ScavCtrl (GPtr=GPtr@entry=0x7fffd570, > ScavOp=ScavOp@entry=2, ScavRes=ScavRes@entry=0x7fffd56e) > at SControl.c:395 > #8 0x10005830 in CheckHFS (fsReadRef=, > fsWriteRef=, checkLevel=2, repairLevel=2, > logLevel=, guiControl=, > lostAndFoundMode=, canWrite=, > modified=0x10042384 ) at SControl.c:145 > #9 0x10002014 in checkfilesys (filesys=) > at fsck_hfs.c:323 > #10 main (argc=, argv=0x7188) at fsck_hfs.c:217 > > > It's with hfsprogs/unstable,now 332.25-11+b3 ppc64. > > I may remember that someone on this list did mention this kind of crash > before. -> https://lists.debian.org/debian-powerpc/2019/01/msg00039.html > > Bertrand > >
Re: Updated installation images for Debian Ports 2019-11-22
On Mon, Nov 25, 2019 at 3:29 AM Dennis Clarke wrote: > > On 11/24/19 4:06 PM, John Paul Adrian Glaubitz wrote: > > Hello! > > > >> On Nov 24, 2019, at 4:20 PM, roberto.guardato > >> wrote: > >> > >> Hi Adrian, > >> i've tested the image for ppc64 on powermac G5, it has the same problem > >> installing the bootloader. > > > > Yes, as I have communicated here already I have not worked on this issue > > yet due to lack of time. > > > > But so far people keep insisting using Yaboot which is unmaintained and > > buggy instead of willing to work on ofpathname. So the ofpathname issue > > won’t be worked on until I have time for it. > > > > I don’t mean to be snarky, I’m just explaining the current situation and > > why the issue isn’t yet fixed. > > > > Yaboot isn’t an option. It’s no longer maintained, has build dependencies > > on libraries no longer maintained either and removed from Debian and also > > doesn’t support modern ext4 filesystem features. > > > > So, unless Yaboot gets a new upstream maintainer to fix all these issues, > > it’s not an option. > > > > Also, for anyone with a Mac, I have left the Yaboot images in the “10.0” > > folder. > > > > Adrian > > > > I appreciate the work that you do and wonder if I can help a bit here. > > The issue seems to be that the open firmware data is being > misrepresented or misunderstood to the grub boot loader or is there > a nice bug report somewhere I can look at ? > You should find a portion of the history at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882076 Maybe Adrian has a different link, since he is in favor of patching the tool from the powerpc-ibm-utils package (my understanding is that the issue should be fixed in grub-ieee1275). > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > GreyBeard and suspenders optional >
Re: 5.3.7 64-bits kernel doesn't boot on G5 Quad
Salut Romain, On Thu, Nov 7, 2019 at 9:34 AM John Paul Adrian Glaubitz wrote: > > Hi Romain! > > On 11/7/19 9:18 AM, Romain Dolbeau wrote: > > Any suggestion on how to identify/fix the bug ? > > The answer here would be git bisect [1]. I would first start downloading > the current kernel source tarball for 5.3.7 from upstream and build the > kernel with "make localmodconfig" to see whether it's an upstream or Debian > problem. I suspect this is upstream and even before 5.3.7. The original report by Christian has been discussed on linuxpcc-dev: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg155248.html Here are the steps I suggested at the time: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg155794.html > If the upstream kernel doesn't work either, then you have to bisect to > find which commit broke it. > > Adrian > > > [1] https://www.kernel.org/doc/html/v4.15/admin-guide/bug-bisect.html > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: Status of OpenGL on Mac
Hi Riccardo, On Wed, Sep 18, 2019 at 8:14 PM Riccaro Mottola wrote: > > Hi Mathieu, > > On 2019-09-18 08:56:08 +0200 Mathieu Malaterre > wrote: > > > > > >> Hi all! > > > >> is anybody capable of using OpenGL on their PowerMacs? > > > > Do you mean on your PowerBook G4 ? That's odd it should work. Can you > > dump more context, eg, running through gdb or strace. > > first, I noticed something very strange: if I connect remotely to the > PowerBook, then set DISPLAY :0 which shows things on the screen, > glxgears run! You're doing a software rendering in this case. > But running it in a real local xterm, doesn't work. This is the crash: > > Starting program: /usr/bin/glxgears > [Thread debugging using libthread_db enabled] > Using host libthread_db library > "/lib/powerpc-linux-gnu/libthread_db.so.1". > > Program received signal SIGILL, Illegal instruction. > 0xb6c2c270 in ?? () from /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so Nice ! You have a reprodicble example. Please follow: https://wiki.debian.org/HowToGetABacktrace and add the missing dbgsym packages to have proper context. Then submit a bug (reportbug with powerpc tag). Thanks ! > (gdb) bt > #0 0xb6c2c270 in ?? () from > /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so > #1 0xb6c2c3e0 in ?? () from > /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so > #2 0xb77c0824 in __pthread_once_slow (once_control=0xb7217d74, > init_routine=0xb6c2c380) at pthread_once.c:116 > #3 0xb6c2c470 in ?? () from > /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so > #4 0xb649e7c4 in ?? () from > /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so > #5 0xb63ce628 in ?? () from > /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so > #6 0xb6496f8c in ?? () from > /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so > #7 0xb6496ce0 in ?? () from > /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so > #8 0xb63d1ff0 in ?? () from > /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so > #9 0xb63d0174 in ?? () from > /usr/lib/powerpc-linux-gnu/dri/swrast_dri.so > #10 0xb7689cf0 in ?? () from /lib/powerpc-linux-gnu/libGLX_mesa.so.0 > #11 0xb76781e0 in ?? () from /lib/powerpc-linux-gnu/libGLX_mesa.so.0 > #12 0xb7671b48 in ?? () from /lib/powerpc-linux-gnu/libGLX_mesa.so.0 > #13 0xb7672a7c in ?? () from /lib/powerpc-linux-gnu/libGLX_mesa.so.0 > #14 0xb790489c in glXChooseVisual () from > /lib/powerpc-linux-gnu/libGLX.so.0 > #15 0x001e64b0 in glXChooseVisual () from > /lib/powerpc-linux-gnu/libGL.so.1 > #16 0x00402dc0 in ?? () > #17 0x004014c8 in ?? () > #18 0xb7b9cf74 in generic_start_main (main=0x401310, argc=1, > argv=0xb4c4, auxvec=0xb56c, init=, > rtld_fini=, > stack_end=, fini=) at > ../csu/libc-start.c:308 > #19 0xb7b9d16c in __libc_start_main (argc=, > argv=, ev=, auxvec=, > rtld_fini=, >
Re: Status of OpenGL on Mac
Hi, On Wed, Sep 18, 2019 at 8:21 AM Riccardo Mottola wrote: > > Hi all! > > is anybody capable of using OpenGL on their PowerMacs? Do you mean on your PowerBook G4 ? That's odd it should work. Can you dump more context, eg, running through gdb or strace. > I noticed that just starting glxgears causes a "Bus error". I don't > think this is a good sign. > > According to lspci, my card is detected as Mobility Radeon 9600. > > Any special configuration to do? I already put myself part of the video > group. > > Thanks, > Riccardo >
Re: Trying ppc64 install / USB / G5
On Mon, Sep 2, 2019 at 1:42 PM Mathieu Malaterre wrote: > > So I am trying the netinst iso from a USB key, on a used PowerMac7,2 > from a yard sale (system was sold without disk). All I can get is the > rescue prompt. All other installs seems to fail (eventually the system > start the fan quite loudly). > > Message is: > > Invalid memory access at %SRR0: .0200ba34 %SRR1: 9000.3030 > Apple PowerMac7,2 5.1.4f0 BootROM built on 11/21/03 at 17:41:40 Turns out this is a known issue with bad RAM. Remove all of them, put back in only a pair, now I can boot a kernel ! ref: https://forum.macbidouille.com/index.php?showtopic=186616 Sorry for the noise > > Doing a quick google search reveal: > > * https://bugzilla.redhat.com/show_bug.cgi?id=182180 > > Comments/Suggestions ?
IBM Gives Away PowerPC; Goes Open Source
Just discovered this today: * https://www.eejournal.com/article/ibm-gives-away-powerpc-goes-open-source/ So good news / bad news ?
mini.iso ?
Hi there, Does anyone know if there is a new location for netboot iso for powerpc ? The old one does not work anymore: http://ftp.debian.org/debian/dists/sid/main/installer-powerpc/current/images/powerpc/netboot/mini.iso Thanks
Re: eMac G4/1.25 GHz support for Debian Sid?
Alex, On Fri, Jul 26, 2019 at 4:10 PM Alex McKeever wrote: > > How hard would it be to get it working on this machine? Mine was manufactured > at around the same time as my PowerMac G5 2.0 DP. I don’t understand why the > eMac is not supported by Ports anymore... why’d they not add support for the > Radeon 9200 for KMS? The PowerMac G5 is running Fienix Lite, a spin of a > community supported distribution based on Sid with MATE, but uses LXQT > instead. > > > Sent from Yahoo Mail for iPhone An actual bug report would be nice. Here is what I see from my MacMini G4: $ cat /proc/cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 1416.61MHz revision : 1.2 (pvr 8003 0102) bogomips : 83.24 timebase : 41620997 platform : PowerMac model : PowerMac10,1 machine : PowerMac10,1 motherboard : PowerMac10,1 MacRISC3 Power Macintosh detected as : 287 (Mac mini) pmac flags : 0010 L2 cache : 512K unified pmac-generation : NewWorld Memory : 512 MB
Fwd: [PATCH 06/10] powerpc: macintosh: Switch to QoS requests instead of cpufreq notifier
Just FYI
-- Forwarded message -
Subject: [PATCH 06/10] powerpc: macintosh: Switch to QoS requests
instead of cpufreq notifier
The cpufreq core now takes the min/max frequency constraints via QoS
requests and the CPUFREQ_ADJUST notifier shall get removed later on.
Switch over to using the QoS request for maximum frequency constraint
for windfarm_cpufreq_clamp driver.
Signed-off-by: Viresh Kumar
---
drivers/macintosh/windfarm_cpufreq_clamp.c | 77 ++
1 file changed, 50 insertions(+), 27 deletions(-)
diff --git a/drivers/macintosh/windfarm_cpufreq_clamp.c
b/drivers/macintosh/windfarm_cpufreq_clamp.c
index 52fd5fca89a0..705c6200814b 100644
--- a/drivers/macintosh/windfarm_cpufreq_clamp.c
+++ b/drivers/macintosh/windfarm_cpufreq_clamp.c
@@ -3,9 +3,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
@@ -16,36 +18,24 @@
static int clamped;
static struct wf_control *clamp_control;
-
-static int clamp_notifier_call(struct notifier_block *self,
- unsigned long event, void *data)
-{
- struct cpufreq_policy *p = data;
- unsigned long max_freq;
-
- if (event != CPUFREQ_ADJUST)
- return 0;
-
- max_freq = clamped ? (p->cpuinfo.min_freq) : (p->cpuinfo.max_freq);
- cpufreq_verify_within_limits(p, 0, max_freq);
-
- return 0;
-}
-
-static struct notifier_block clamp_notifier = {
- .notifier_call = clamp_notifier_call,
-};
+static struct dev_pm_qos_request qos_req;
+static unsigned int min_freq, max_freq;
static int clamp_set(struct wf_control *ct, s32 value)
{
- if (value)
+ unsigned int freq;
+
+ if (value) {
+ freq = min_freq;
printk(KERN_INFO "windfarm: Clamping CPU frequency to "
"minimum !\n");
- else
+ } else {
+ freq = max_freq;
printk(KERN_INFO "windfarm: CPU frequency unclamped !\n");
+ }
clamped = value;
- cpufreq_update_policy(0);
- return 0;
+
+ return dev_pm_qos_update_request(&qos_req, freq);
}
static int clamp_get(struct wf_control *ct, s32 *value)
@@ -74,27 +64,60 @@ static const struct wf_control_ops clamp_ops = {
static int __init wf_cpufreq_clamp_init(void)
{
+ struct cpufreq_policy *policy;
struct wf_control *clamp;
+ struct device *dev;
+ int ret;
+
+ policy = cpufreq_cpu_get(0);
+ if (!policy) {
+ pr_warn("%s: cpufreq policy not found cpu0\n", __func__);
+ return -EPROBE_DEFER;
+ }
+
+ min_freq = policy->cpuinfo.min_freq;
+ max_freq = policy->cpuinfo.max_freq;
+ cpufreq_cpu_put(policy);
+
+ dev = get_cpu_device(0);
+ if (unlikely(!dev)) {
+ pr_warn("%s: No cpu device for cpu0\n", __func__);
+ return -ENODEV;
+ }
clamp = kmalloc(sizeof(struct wf_control), GFP_KERNEL);
if (clamp == NULL)
return -ENOMEM;
- cpufreq_register_notifier(&clamp_notifier, CPUFREQ_POLICY_NOTIFIER);
+
+ ret = dev_pm_qos_add_request(dev, &qos_req, DEV_PM_QOS_MAX_FREQUENCY,
+max_freq);
+ if (ret < 0) {
+ pr_err("%s: Failed to add freq constraint (%d)\n", __func__,
+ ret);
+ goto free;
+ }
+
clamp->ops = &clamp_ops;
clamp->name = "cpufreq-clamp";
- if (wf_register_control(clamp))
+ ret = wf_register_control(clamp);
+ if (ret)
goto fail;
clamp_control = clamp;
return 0;
fail:
+ dev_pm_qos_remove_request(&qos_req);
+
+ free:
kfree(clamp);
- return -ENODEV;
+ return ret;
}
static void __exit wf_cpufreq_clamp_exit(void)
{
- if (clamp_control)
+ if (clamp_control) {
wf_unregister_control(clamp_control);
+ dev_pm_qos_remove_request(&qos_req);
+ }
}
--
2.21.0.rc0.269.g1a574e7a288b
Re: ofpath vs ofpathname vs grub-ofpathname
Adrian, On Thu, Jun 20, 2019 at 3:47 PM John Paul Adrian Glaubitz wrote: > > Hi! > > In order to collect data for fixing the limitations we have with > grub-ofpathname, > I have done some initial testing on our POWER8 buildd by comparing the output > of Yaboot's ofpath [1], ofpathname from powerpc-utils [2] and grub-ofpathname > [3]. > > Interestingly, all three return different path names on the POWER machine: > > root@redpanda:~# ./powerpc-utils/scripts/ofpathname /dev/sda1 > /vdevice/v-scsi@3004/disk@8100 > root@redpanda:~# /srv/glaubitz/grub/grub-ofpathname /dev/sda1 > /vdevice/v-scsi@3004/disk@8100:a > root@redpanda:~# ./yaboot-test/usr/sbin/ofpath /dev/sda1 > /vdevice/v-scsi@3004/@1:1 > root@redpanda:~# > > Could someone test this on a Mac, please? Yaboot and powerpc-utils just need > to > be checked out from git and the scripts can be run directly, GRUB just needs > to be built with the usual ./bootstrap && ./configure && make. System: Mac Mini G4 Using master branch from: $ git clone g...@github.com:ibm-power-utilities/powerpc-utils.git $ git clone git://ozlabs.org/srv/projects/yaboot/yaboot.git $ git clone git://git.savannah.gnu.org/grub.git Leads to: $ sudo scripts/ofpathname /dev/sda1 /pci@f400/ata-6@d/scsi@0/sd@0,0 $ ybin/ofpath /dev/sda1 ofpath: /dev/sda: Device not configured $ ./grub-ofpathname /dev/sda1 /pci@f400/ata-6@d/disk@0:a In case this is needed, here is the current ofpath (with Milan's patch): $ /usr/sbin/ofpath /dev/sda1 /pci@f400/ata-6@d/@0:1 > > Thanks, > Adrian > > > [1] http://git.ozlabs.org/?p=yaboot.git This does not includes Milan's patch to ofpath. > > [2] https://github.com/ibm-power-utilities/powerpc-utils > > [3] http://git.savannah.gnu.org/cgit/grub.git > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: USB-RS232 with G4 (mac mini)
On Thu, May 23, 2019 at 11:03 AM John Paul Adrian Glaubitz wrote: > > On 5/23/19 11:01 AM, Mathieu Malaterre wrote: > >> You can always plug in a USB-RS232 converter and pass "console=ttyUSB0" > >> on the kernel command line. There is no need to use the built-in serial > > > > I am curious about that comment. I do not understand how one would > > actually (physically) plug a USB-RS232 on a Mac Mini G4 ? > > > > Here is a picture of such device (at least how I interpret your comment): > > > > https://raspberrypi.stackexchange.com/questions/15819/how-to-identify-the-usb-to-serial-wire-mismatched > > > > Where do you plug the red/black/white/green cable on your Mac ? > > You misunderstood what I said. I would use the converter the other way > around, with the USB plug on the Mac side and the RS-232 cable on the > PC side. That should work for a simple serial console for the kernel, > you won't be able to see any OpenFirmware messages though. Right I misunderstood that part. I still feel dumb, where do you get a serial port on any modern laptop these days ? > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
USB-RS232 with G4 (mac mini)
Adrian, On Thu, May 9, 2019 at 8:01 AM John Paul Adrian Glaubitz wrote: > > On 5/8/19 7:20 PM, Frank Scheiner wrote: > > Not for the 11,2 type G5s. AFAIK there never was an adapter available > > that would allow access to the - existing - serial console port(s). > > You can always plug in a USB-RS232 converter and pass "console=ttyUSB0" > on the kernel command line. There is no need to use the built-in serial I am curious about that comment. I do not understand how one would actually (physically) plug a USB-RS232 on a Mac Mini G4 ? Here is a picture of such device (at least how I interpret your comment): https://raspberrypi.stackexchange.com/questions/15819/how-to-identify-the-usb-to-serial-wire-mismatched Where do you plug the red/black/white/green cable on your Mac ? > console as a terminal. If that still fails, you can always use netconsole > as I mentioned earlier, see [1], which works on any machine with networking > available. > > Adrian > > > [1] https://wiki.archlinux.org/index.php/Netconsole > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: G5 Suddenly Can't Boot Into GRUB
Hi Adrian, On Thu, Apr 18, 2019 at 4:30 PM John Paul Adrian Glaubitz wrote: > > On 4/18/19 1:10 AM, Frank Scheiner wrote: > > @Adrian, Mathieu: > > > > We could use this opportunity to evaluate Mathieu's patches from [1] and > > [2]. This will also require changes to `grub-install`, but in the end > > could be the "best" solution as `grub-ofpathname` would be included in > > the GRUB packages. > > Yes, I agree. We need to include a working ofpathname in the GRUB package. > > Best would be, of course, to fix the ofpathname from the IBM utils package. Could you give more details as to why you believe this would be 'best' ? While I never had feedback from neither IBM group nor GRUB group about my (WIP) patches, I believe grub path is the way to go. 2cts > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [powerpc/ppc64] Fix d-i/grub-installer for NewWorld Power Macs (now with HFS bootstrap!)
On Wed, Mar 13, 2019 at 12:56 AM Frank Scheiner wrote:
>
> Dear all,
>
> by popular demand for a working d-i/grub-installer on NewWorld Power
> Macs **with** HFS bootstrap method, I made this happen - again. :-D This
> time with a reduced footprint compared to the patches proposed in late
> 2017 (see [1]).
>
> [1]: https://lists.debian.org/debian-powerpc/2017/11/msg00068.html
>
> I created two MRs on salsa.d.o that in combination provide the fix:
>
> * https://salsa.debian.org/installer-team/partman-auto/merge_requests/3
>
> * https://salsa.debian.org/installer-team/grub-installer/merge_requests/2
Did you get a chance at least to try patch from #916830 ? Would be
nice to confirm that grub-ofpathname is a replacement for ofpath or
not ? (I am still hoping that syntax is compatible with Mac and thus
916864 may not be required).
Thanks for your hard work !
> These changes were tested to work on a Mac mini G4 and a Power Mac G5
> (11,2). I used a normal mode installation and the atomic partitioning
> layout and an empty hard disk.
>
> Please check the MRs for all details. Reviews and comments are much welcome.
>
>
>
> These patches can be tested in a live installation as follows:
>
> 1. In a normal mode installation wait for the installer to hold on the
> partitioning step and switch to a shell
>
> 2. Download or patch the recipes in
> `/lib/partman/recipes-{powerpc|ppc64}-powermac_newworld` accordingly
> (e.g. using `nano`). It's sufficient to only patch the recipe that you
> actually intend to use in the partitioning step.
>
> 3. Also download or patch `/usr/bin/grub-installer`
>
> 4. Download or create `/usr/lib/grub-installer/mkhfs-bootstrap.sh`
>
> 5. Continue the installation
>
> I served `grub-installer` and `mkhfs-bootstrap.sh` from a local web
> server and downloaded them into the installation environment with
> `wget`. Make sure to change the file permissions to allow execution
> afterwards.
>
> Cheers,
> Frank
Re: linux 5.0 and altivec
On Sun, Mar 10, 2019 at 7:17 PM Elimar Riesebieter wrote: > > * Mathieu Malaterre [2019-03-10 18:40 +0100]: > > > On Sun, Mar 10, 2019 at 1:36 PM Elimar Riesebieter > > wrote: > > > > > > * Elimar Riesebieter [2019-03-09 09:56 +0100]: > > > > > > > Hi all, > > > > > > > > I tried to compile linux 5.0 on my G4 powerbook 7447A altivec supported: > > > > > > > > arch/powerpc/kernel/ptrace.c: In function ‘vr_get’: > > > > arch/powerpc/kernel/ptrace.c:567:5: note: ‘vrsave’ declared here > > > > } vrsave; > > > >^~ > > > > cc1: error: AltiVec not supported in this target > > > > make[5]: *** [scripts/Makefile.build:277: arch/powerpc/lib/xor_vmx.o] > > > > Error 1 > > > > make[4]: *** [scripts/Makefile.build:492: arch/powerpc/lib] Error 2 > > > > make[3]: *** [Makefile:1046: arch/powerpc] Error > > > > > > > > Doesn't 5.0 support altivec anymore? > > > > > > Have had to set "CONFIG_GENERIC_CPU=y" instead of > > > "CONFIG_E300C2_CPU=y". Sorry for the noise. > > > > Just in case you are actually using 5.x, pay attention you can now use: > > > > CONFIG_G4_CPU=y > > > > See: > > > > bbb7f84b0bbb powerpc: Allow CPU selection of G4/74xx variant > > Hmm, can't find that option in 5.0.1 nor in linux-powerpc? There is no tag yet, so you'll need git/master. https://github.com/torvalds/linux/commit/bbb7f84b0bbb
Re: linux 5.0 and altivec
On Sun, Mar 10, 2019 at 1:36 PM Elimar Riesebieter wrote: > > * Elimar Riesebieter [2019-03-09 09:56 +0100]: > > > Hi all, > > > > I tried to compile linux 5.0 on my G4 powerbook 7447A altivec supported: > > > > arch/powerpc/kernel/ptrace.c: In function ‘vr_get’: > > arch/powerpc/kernel/ptrace.c:567:5: note: ‘vrsave’ declared here > > } vrsave; > >^~ > > cc1: error: AltiVec not supported in this target > > make[5]: *** [scripts/Makefile.build:277: arch/powerpc/lib/xor_vmx.o] > > Error 1 > > make[4]: *** [scripts/Makefile.build:492: arch/powerpc/lib] Error 2 > > make[3]: *** [Makefile:1046: arch/powerpc] Error > > > > Doesn't 5.0 support altivec anymore? > > Have had to set "CONFIG_GENERIC_CPU=y" instead of > "CONFIG_E300C2_CPU=y". Sorry for the noise. Just in case you are actually using 5.x, pay attention you can now use: CONFIG_G4_CPU=y See: bbb7f84b0bbb powerpc: Allow CPU selection of G4/74xx variant
Re: Installation of Debian on an iMac PowerPC
Adrian, On Sun, Feb 17, 2019 at 10:53 PM John Paul Adrian Glaubitz wrote: > > On 2/17/19 10:45 PM, Dennis Clarke wrote: > > However having said that I have had great results from installing Debian > > testing/buster into a PowerMac G5 with no major issues. Sure the boot > > loader is a tad crusty but the machine works well enough. > > Frank Scheiner has already written patches to add GRUB support for Macs, > those just need to be cleaned up, tested and merged. > > First, the issue with ofpath inside powerpc-utils needs to be fixed [1] > which might just be a matter of updating the powerpc-utils package > in Debian. The version currently in Debian is a tad old. > > Adrian > > > [1] https://github.com/ibm-power-utilities/powerpc-utils/issues/30 IMHO a much simpler solution is at: * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916864 The attached patch wont change a bit on sparc* system. Fixing the shell script in powerpc-utils wont happen in the near future (again IMHO). I was hoping even to get my patch upstream in GRUB. Technically I still fail to understand why the implementation on Mac does not cope with both syntax, or else the bug has been present in GRUB upstream since day one. Comments ?
Re: nvram / boing startup sound / mac mini g4
On Tue, Jan 8, 2019 at 3:36 PM Matti Palmström wrote: > > On Tue, Jan 8, 2019 at 12:09 PM Mathieu Malaterre wrote: >> >> Has anyone tried to remove the annoying boing startup ound on a Mac >> Mini G4 system. I have deleted the macosx partition on this machine. > > pmac-utils (or powerpc-utils from Jessie) has the tool nvsetvol to change the > volume of the chime. Thanks very much ! That worked out well.
Re: List of powerpc / pmac specific package for debian-ports
On Tue, Jan 8, 2019 at 4:17 PM John Paul Adrian Glaubitz wrote: > > Hi! > > On 1/8/19 4:15 PM, Mathieu Malaterre wrote: > > Maybe it is time to create a debian-powerpc group on salsa.d.o. And > > upload the latest of pmac-utils as project over there ? > > I think it would make more sense to use a debian-ports group for that. > Not sure whether we already have one. I can only find this one: https://salsa.debian.org/debian-ports-team I doubt pmac-utils could fit there, comments ? > FWIW, it would be great if anyone who hasn't yet could join #debian-ports > on OFTC on IRC. > > Oh, and feel free to test build the other packages we're missing and provide > patches if necessary. So I can pick those as well and upload. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: List of powerpc / pmac specific package for debian-ports
On Tue, Jan 8, 2019 at 4:05 PM John Paul Adrian Glaubitz wrote: > > Hi Mark! > > On 1/8/19 3:33 PM, Mark Cave-Ayland wrote: > > The attached patch fixes the build for me: it removes the __USE_GNU > > definition from > > nwnvsetenv for tidiness and fixes up the main issue which is that > > autoboot.sgml fails > > to build (presumably because checks on bad markup have become more strict > > in newer > > versions of the documentation tools). > > > > Finally I also bumped debian/compat from 7 to 9 with no obvious ill-effects > > since > > every dpkg command was emitting warnings about compat level 7 being > > deprecated. > > Successfully built and uploaded to unreleased. Will take up to 6 hours until > the > packages become available due to the way unreleased works. > > On a sidenote, is there still some upstream repository somewhere where all the > changes can be merged? Looks like Michael Schmitz has been the maintainer in > Debian in the past. Maybe it is time to create a debian-powerpc group on salsa.d.o. And upload the latest of pmac-utils as project over there ?
nvram / boing startup sound / mac mini g4
Hi there, Has anyone tried to remove the annoying boing startup ound on a Mac Mini G4 system. I have deleted the macosx partition on this machine. Thanks,
Re: List of powerpc / pmac specific package for debian-ports
On Tue, Jan 8, 2019 at 11:10 AM John Paul Adrian Glaubitz wrote: > > On 1/8/19 8:21 AM, Mathieu Malaterre wrote: > >> Updated list: > >> > >> - ps3-utils > >> - pmac-utils > >> - partman-newworld > >> - spu-tools > >> - pbbuttonsd > > - b43-fwcutter (contrib) > > Would probably a good idea to put the list on a wiki. I currently https://wiki.debian.org/PowerPC/ppc32 > don't have the time to work on that. Some packages like pmac-utils > no longer build so someone needs to fix them. I see. That's really annoying to not be able to track those FTBFS normally with BTS. I'll work on that next.
Re: List of powerpc / pmac specific package for debian-ports
On Tue, Nov 13, 2018 at 8:18 AM Mathieu Malaterre wrote: > > On Tue, Sep 4, 2018 at 10:27 AM John Paul Adrian Glaubitz > wrote: > > > > On 09/04/2018 09:36 AM, Mathieu Malaterre wrote: > > > In that case: > > > > > > - pmac-utils > > > > That's not the whole list. There were other packages like partman-newworld > > that got recently removed which are far more important as they are required > > for debian-installer. > > > > See: https://lists.debian.org/debian-boot/2018/09/msg7.html > > Updated list: > > - ps3-utils > - pmac-utils > - partman-newworld > - spu-tools > - pbbuttonsd - b43-fwcutter (contrib)
Re: Any progress with grub-installer?
Adrian, On Sun, Jan 6, 2019 at 8:52 PM John Paul Adrian Glaubitz wrote: > > Hi! > > I haven't been following the discussion regarding GRUB on PowerPC lately > as I was busy with upstream fixes on Rust, LibreOffice and some Debian > packages, so please apologize for my ignorance. > > Has there been any progress made regarding GRUB on PowerPC? In particular, > do we have a solution for the "ofpath" script or should we just include the > working on from Yaboot into the Debian GRUB package. > > Please note, you can just open pull request in Debian's Salsa project if you > have a patch ready :-). That was my question in #916830 & #916864. Should I submit a PR instead (to get things moving) ? > I think I will work on GRUB on SPARC next to address the build issues there. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > -- Mathieu
Re: Problems with hfsprogs on G5 Power Macs
On Sun, Jan 6, 2019 at 9:48 PM Frank Scheiner wrote: > > Hi Mathieu, > > On 1/4/19 08:51, Mathieu Malaterre wrote: > > On Thu, Jan 3, 2019 at 5:54 PM Frank Scheiner wrote: > >> On 1/3/19 12:10, Mathieu Malaterre wrote: > >>> The way you describe this bug makes me think of a 64bits vs 32bits > >>> issue. Next time this happen to you, use a foreign powerpc > >>> installation to run ppc32 binary on your G5. > >> > >> That's a good idea and I think we don't even have to wait for the next > >> time this issue hits me, as even for a clean HFS the `fsck.hfs` > >> segfaults. The significance of the result of such a test will not be the > >> same as for checking a borked HFS, but could show a tendency. > > > > Right ! Good point. > > > >> Say, will a powerpc64 kernel from arch ppc64 work with a userland from > >> arch powerpc or do I need the powerpc64 kernel from arch powerpc? Or are > >> these kernels actually identical? > > > > If I understand your sentence, the answer is yes: they are identical. > > The only (main?) difference with amd64/i386 world is that you cannot > > run a ppc32 kernel on a ppc64 machine. > > Ok. It works to use the powerpc64 kernel from arch ppc64 and a userland > from arch powerpc with kernel modules of the powerpc64 kernel of arch > powerpc. Hence I assume the powerpc64 kernels of arch ppc64 and powerpc > are actually identical. > > Back to the testing of the powerpc version of `fsck.hfs`. I first > checked the HFS bootstrap FS on a Mac mini G4 to have a known state for > later testing: > > ``` > root@mac-mini:~# fsck.hfs -d -f /dev/sdb2 > ** /dev/sdb2 > Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. > ** Checking HFS volume. > ** Checking Extents Overflow file. > ** Checking Catalog file. > Reserved fields in the catalog record have incorrect data > (4, 185) > Reserved fields in the catalog record have incorrect data > (4, 2) > Reserved fields in the catalog record have incorrect data > (4, 2) > ** Checking Catalog hierarchy. > ** Checking volume bitmap. > ** Checking volume information. > Verify Status: VIStat = 0x, ABTStat = 0x EBTStat = 0x >CBTStat = 0x0200 CatStat = 0x > ** Repairing volume. > ** Rechecking volume. > ** Checking HFS volume. > ** Checking Extents Overflow file. > ** Checking Catalog file. > ** Checking Catalog hierarchy. > ** Checking volume bitmap. > ** Checking volume information. > ** The volume bootstrap was repaired successfully. > > root@mac-mini:~# echo $? > 0 > > root@mac-mini:~# fsck.hfs -d -f /dev/sdb2 > ** /dev/sdb2 > Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. > ** Checking HFS volume. > ** Checking Extents Overflow file. > ** Checking Catalog file. > ** Checking Catalog hierarchy. > ** Checking volume bitmap. > ** Checking volume information. > ** The volume bootstrap appears to be OK. > > root@mac-mini:~# echo $? > 0 > ``` > > ...then tested the ppc64 version on the 11,2 G5 with the expected result > (segfault): > > ``` > root@powermac-g5:~# dpkg -l hfsprogs > Desired=Unknown/Install/Remove/Purge/Hold > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==---=== > ii hfsprogs 332.25-11+b3 ppc64mkfs and fsck for HFS and > HFS+ file systems > > root@powermac-g5:~# file /sbin/fsck.hfs > /sbin/fsck.hfs: symbolic link to fsck.hfsplus > > root@powermac-g5:~# file /sbin/fsck.hfsplus > /sbin/fsck.hfsplus: ELF 64-bit MSB executable, 64-bit PowerPC or cisco > 7500, version 1 (SYSV), dynamically linked, interpreter > /lib64/ld64.so.1, for GNU/Linux 3.2.0, > BuildID[sha1]=9e14a88ea04ea0fc8a89f3d79b039cf1daa6f3ed, stripped > > root@powermac-g5:~# fsck.hfs -d -f /dev/sda2 > ** /dev/sda2 > Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. > ** Checking HFS volume. > Segmentation fault > ``` > > But then testing with the powerpc version on the 11,2 G5 actually seems > to work: > > ``` > root@powermac-g5:~# dpkg -l hfsprogs > Desired=Unknown/Install/Remove/Purge/Hold > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==---==
Re: Problems with hfsprogs on G5 Power Macs
On Thu, Jan 3, 2019 at 5:54 PM Frank Scheiner wrote: > > On 1/3/19 12:10, Mathieu Malaterre wrote: > > On Sun, Dec 30, 2018 at 9:54 PM Frank Scheiner > > wrote: > >> So one actually cannot repair that issue from a G5 - or maybe not even > >> any issue with an HFS at all, because the same also happens when trying > >> to check a clean HFS with `fsck.hfs`. The result is that an existing > >> GRUB installation can no longer be upgraded on a G5 as soon as someone > >> hits that problem. Actually I'm also unsure if my HFS problems were > >> created by an unclean shutdown at all. > >> > >> One could solve this by recreating the HFS partition from scratch and > >> restoring the contents (incl. file blessing and file types (i.e. > >> `tbxi`)). Or maybe by rewriting a `dd`ed image from a clean HFS - if you > >> have one at hand. Trying to repair the partition with `fsck.hfs` from a > >> Mac mini G4 (via SATA to USB adapter) worked for me also. But all these > >> workarounds are unhandy to the least. > > > > The way you describe this bug makes me think of a 64bits vs 32bits > > issue. Next time this happen to you, use a foreign powerpc > > installation to run ppc32 binary on your G5. > > That's a good idea and I think we don't even have to wait for the next > time this issue hits me, as even for a clean HFS the `fsck.hfs` > segfaults. The significance of the result of such a test will not be the > same as for checking a borked HFS, but could show a tendency. Right ! Good point. > Say, will a powerpc64 kernel from arch ppc64 work with a userland from > arch powerpc or do I need the powerpc64 kernel from arch powerpc? Or are > these kernels actually identical? If I understand your sentence, the answer is yes: they are identical. The only (main?) difference with amd64/i386 world is that you cannot run a ppc32 kernel on a ppc64 machine. > Because such a configuration I could setup easily by just changing the > root FS that the machine uses when network booting. > > Cheers, > Frank
Re: Problems with hfsprogs on G5 Power Macs
On Sun, Dec 30, 2018 at 9:54 PM Frank Scheiner wrote:
>
> Dear all,
>
> I experienced some major problems with hfsprogs on G5 Power Macs.
>
> Once in a while (already seen multiple times on 11,2 and 7,3 type Power
> Macs) the OS refuses to mount the NewWorld bootstrap - or simply HFS -
> partition that hosts the GRUB installation at startup in read-write
> mode. Trying to check the HFS with `fsck.hfs` always leads to
> segmentation faults (details below).
>
> So one actually cannot repair that issue from a G5 - or maybe not even
> any issue with an HFS at all, because the same also happens when trying
> to check a clean HFS with `fsck.hfs`. The result is that an existing
> GRUB installation can no longer be upgraded on a G5 as soon as someone
> hits that problem. Actually I'm also unsure if my HFS problems were
> created by an unclean shutdown at all.
>
> One could solve this by recreating the HFS partition from scratch and
> restoring the contents (incl. file blessing and file types (i.e.
> `tbxi`)). Or maybe by rewriting a `dd`ed image from a clean HFS - if you
> have one at hand. Trying to repair the partition with `fsck.hfs` from a
> Mac mini G4 (via SATA to USB adapter) worked for me also. But all these
> workarounds are unhandy to the least.
The way you describe this bug makes me think of a 64bits vs 32bits
issue. Next time this happen to you, use a foreign powerpc
installation to run ppc32 binary on your G5.
> The last changelog entry for `hfsprogs` is already from 2013 and the
> used source code from Apple seems to be even older than that (e.g. check
> the used version 332.25 against the versions available from [1]). There
> seems to be some recent progress in Arch Linux (following the discussion
> on [2]) but I'm unsure if this will also apply to NewWorld Power Macs.
> So I dare to say that we have a situation with hfsprogs similar to the
> situation we have with yaboot, maybe even worse, as a critical
> functionality just doesn't work on G5 Power Macs.
>
> [1]: https://opensource.apple.com/source/diskdev_cmds/
> [2]: https://aur.archlinux.org/packages/hfsprogs/
>
> Cheers,
> Frank
>
>
>
> ```
> root@powermac-g5-2:~# dmesg | grep hfs
> [ 16.234586] hfs: filesystem was not cleanly unmounted, running
> fsck.hfs is recommended. mounting read-only.
>
> root@powermac-g5-2:~# fsck.hfs -d /dev/sda2
> ** /dev/sda2
> Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
> ** Checking HFS volume.
> Segmentation fault
>
> root@powermac-g5-2:~# strace fsck.hfs -d /dev/sda2
> execve("/sbin/fsck.hfs", ["fsck.hfs", "-d", "/dev/sda2"], 0x76dd0670
> /* 17 vars */) = 0
> brk(NULL) = 0x2d21
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=38472, ...}) = 0
> mmap(NULL, 38472, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fffbb2d
> close(3)= 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/lib/powerpc64-linux-gnu/libbsd.so.0",
> O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\2\345h"...,
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0644, st_size=133368, ...}) = 0
> mmap(NULL, 200880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0x7fffbb29
> mmap(0x7fffbb2b, 131072, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x7fffbb2b
> close(3)= 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/lib/powerpc64-linux-gnu/libc.so.6",
> O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\2\2\1\3\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\36\326\300"...,
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=2046080, ...}) = 0
> mmap(NULL, 2119632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0x7fffbb08
> mprotect(0x7fffbb25, 65536, PROT_NONE) = 0
> mmap(0x7fffbb26, 196608, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d) = 0x7fffbb26
> close(3)= 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/lib/powerpc64-linux-gnu/librt.so.1",
> O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\2\2\1\3\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\1\367\370"...,
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0644, st_size=69392, ...}) = 0
> mmap(NULL, 134872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0x7fffbb05
> mmap(0x7fffbb06, 131072, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7fffbb06
> close(3)= 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> opena
Re: Problems with hfsprogs on G5 Power Macs
On Sun, Dec 30, 2018 at 9:54 PM Frank Scheiner wrote:
>
> Dear all,
>
> I experienced some major problems with hfsprogs on G5 Power Macs.
I vaguely recall also some data corruption when playing with HFS back then:
https://lists.debian.org/debian-powerpc/2016/04/msg00103.html
ISO 9660 works just fine for me, so I am ok moving away from HFS at
least in the short term (gets things moving). I suspect dual
installation people may want HFS at some point.
> Once in a while (already seen multiple times on 11,2 and 7,3 type Power
> Macs) the OS refuses to mount the NewWorld bootstrap - or simply HFS -
> partition that hosts the GRUB installation at startup in read-write
> mode. Trying to check the HFS with `fsck.hfs` always leads to
> segmentation faults (details below).
>
> So one actually cannot repair that issue from a G5 - or maybe not even
> any issue with an HFS at all, because the same also happens when trying
> to check a clean HFS with `fsck.hfs`. The result is that an existing
> GRUB installation can no longer be upgraded on a G5 as soon as someone
> hits that problem. Actually I'm also unsure if my HFS problems were
> created by an unclean shutdown at all.
>
> One could solve this by recreating the HFS partition from scratch and
> restoring the contents (incl. file blessing and file types (i.e.
> `tbxi`)). Or maybe by rewriting a `dd`ed image from a clean HFS - if you
> have one at hand. Trying to repair the partition with `fsck.hfs` from a
> Mac mini G4 (via SATA to USB adapter) worked for me also. But all these
> workarounds are unhandy to the least.
>
> The last changelog entry for `hfsprogs` is already from 2013 and the
> used source code from Apple seems to be even older than that (e.g. check
> the used version 332.25 against the versions available from [1]). There
> seems to be some recent progress in Arch Linux (following the discussion
> on [2]) but I'm unsure if this will also apply to NewWorld Power Macs.
> So I dare to say that we have a situation with hfsprogs similar to the
> situation we have with yaboot, maybe even worse, as a critical
> functionality just doesn't work on G5 Power Macs.
>
> [1]: https://opensource.apple.com/source/diskdev_cmds/
> [2]: https://aur.archlinux.org/packages/hfsprogs/
>
> Cheers,
> Frank
>
>
>
> ```
> root@powermac-g5-2:~# dmesg | grep hfs
> [ 16.234586] hfs: filesystem was not cleanly unmounted, running
> fsck.hfs is recommended. mounting read-only.
>
> root@powermac-g5-2:~# fsck.hfs -d /dev/sda2
> ** /dev/sda2
> Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
> ** Checking HFS volume.
> Segmentation fault
>
> root@powermac-g5-2:~# strace fsck.hfs -d /dev/sda2
> execve("/sbin/fsck.hfs", ["fsck.hfs", "-d", "/dev/sda2"], 0x76dd0670
> /* 17 vars */) = 0
> brk(NULL) = 0x2d21
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=38472, ...}) = 0
> mmap(NULL, 38472, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fffbb2d
> close(3)= 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/lib/powerpc64-linux-gnu/libbsd.so.0",
> O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\2\345h"...,
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0644, st_size=133368, ...}) = 0
> mmap(NULL, 200880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0x7fffbb29
> mmap(0x7fffbb2b, 131072, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x7fffbb2b
> close(3)= 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/lib/powerpc64-linux-gnu/libc.so.6",
> O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\2\2\1\3\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\36\326\300"...,
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=2046080, ...}) = 0
> mmap(NULL, 2119632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0x7fffbb08
> mprotect(0x7fffbb25, 65536, PROT_NONE) = 0
> mmap(0x7fffbb26, 196608, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d) = 0x7fffbb26
> close(3)= 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/lib/powerpc64-linux-gnu/librt.so.1",
> O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\2\2\1\3\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\1\367\370"...,
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0644, st_size=69392, ...}) = 0
> mmap(NULL, 134872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> = 0x7fffbb05
> mmap(0x7fffbb06, 131072, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7fff
Re: linux 4.20-rc?
Try that https://patchwork.kernel.org/patch/10718111/ Let me know if this works for you Le dim. 23 déc. 2018 14:09, Elimar Riesebieter a écrit : > Hi all, > > I tried to run linux-4.20-rc7 on my powerbook G4. It doesn't boot. > It stops booting after verifying memory. There are no logs available. > > I did a 'make oldconfig' with a properly working 4.19.12 kernel > config and compiled with gcc (Debian 8.2.0-13) 8.2.0 in a sid > environment. > > Did anybody here ever tried 4.20 on a G4 platform? > Hints for debugging are welcome! > > > Thanks in advance > Elimar > -- > Alles, was viel bedacht wird, wird bedenklich!;-) > Friedrich Nietzsche > >
Re: Enable GRUB installation for powerpc/ppc64 Macs (was: Re: News about Firefox for PowerPC)
Hi Frank, On Fri, Dec 21, 2018 at 10:38 PM Frank Scheiner wrote: > > Hi Adrian, > > On 12/11/18 00:00, John Paul Adrian Glaubitz wrote: > > @Frank: Could you repost your patches for grub-installer rebased for the > > current > > version? Maybe also include the ofpath script from the yaboot > > package > > (download from > > http://snapshot.debian.org/archive/debian/20160607T104140Z/pool/main/y/yaboot/yaboot_1.3.17-4.dsc). > > Noticed this by chance. Just for reference, please consider using patches from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916830 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916864 That way we'll replace yaboot/ofpath with grub-ofpathname. Thanks much for your work ! > Although I'm subscribed to this list, I actually don't read every mail > on it (completely) or all mails in time. Maybe better put me in TO or CC > next time or address me directly at the beginning. Not sure if I missed > something else, though. > > Thanks for your insistence :-), actually I haven't forgotten about > enabling GRUB installation for powerpc/ppc64 Macs, but missed the time > for it until now, as it actually requires a bigger effort. I hope I can > bring this forward in the next weeks but I can't give a promise. > > In addition I plan to deviate from the patches I created in late 2017, > maybe even start from scratch. One of the main things I want to keep out > of d-i/grub-installer this time is the HFS stuff related to FS creation > and such. Unfortunately this is not done by d-i/partman-newworld but was > always done by d-i/yaboot-installer or d-i/grub-installer with my > patches from late 2017. To fix that I plan to create a d-i/partman-hfs > (based on d-i/partman-ext3 but adapted for hfs) which should take care > of the FS related tasks and maybe later replace d-i/partman-newworld. > This should shrink the amount of changes needed for d-i/grub-installer > considerably. I also like to "save space" by focusing on successful > operation for the simplest case possible only - i.e. empty disk or prior > OS installation on disk is thrown away - at first, instead of trying to > support special cases. > > The plan then is as follows: > > 1. Increase size of HFS partitions in d-i/partman-auto to 10 to 20 MB to > prepare for future GRUB installations. More details on [1]. > > [1]: https://salsa.debian.org/installer-team/partman-auto/merge_requests/2 > > 2. Create d-i/partman-hfs to handle all FS related stuff for HFS > > 3. Patch d-i/grub-installer to support a GRUB installation for > powerpc/ppc64 Macs for the simplest case. > > This time I also plan to do the development on powerpc and use ppc64 for > verification. > > Cheers, > Frank >
Re: ofpathname is bash only
Hi Milan, On Tue, Dec 18, 2018 at 4:47 PM Milan Kupcevic wrote: > > On 12/18/18 10:20 AM, Mathieu Malaterre wrote: > > [...] > > > > > Turns out the patch will be more difficult than I thought. The shell > > script ofpathname is written for bash. It bails out with error when > > using dash. So I suspect this is a no-go for using ofpathname during > > installation. > > > > > As ofpathname is typically needed at the end of OS installation process > consider using 'in-target' to run it within the installed environment > where bash can be readily available. I see that you patched ofpath in the past. Could you give me some reference materials on where you found out those convention ? It seems that grub-ofpathname has always lived happily with: $ /usr/sbin/grub-ofpathname /dev/sda2 /pci@f400/ata-6@d/disk@0:b The patch is quite trivial to make to make it behave like yaboot/ofpath, but I'd like to polish the patch before sending it upstream. Is this something that is known to be different in between IBM, sparc64 vs powerpc (powermac) in OpenFirmware implementation ? Thanks
ofpathname is bash only
Adrian, On Mon, Dec 17, 2018 at 9:42 PM John Paul Adrian Glaubitz wrote: > > Hi Mathieu! > > On 12/17/18 9:34 PM, Mathieu Malaterre wrote: > > OK. I see some difference in between ofpath and ofpathname now. I've > > reported it upstream: > > > > https://github.com/ibm-power-utilities/powerpc-utils/issues/30 > > > > Let's see how upstream is interested, hopefully we'll be able to make > > some progress there. > Great, thanks a lot for tracking this down. If we can fix this issue so that > GRUB's own ofpathname can be used, we don't need to rip out ofpath out of > Yaboot in order to get a usable grub-installer for PPC Macs. Turns out the patch will be more difficult than I thought. The shell script ofpathname is written for bash. It bails out with error when using dash. So I suspect this is a no-go for using ofpathname during installation. Would it be possible to make pmac-utils mandatory package, and steal ofpath from yaboot onto pmac-utils package instead ? -M
Re: [PATCH v2 4/5] Patch the CHRP boot script
On Tue, Nov 21, 2017 at 10:27 AM Benjamin Herrenschmidt wrote: > > On Tue, 2017-11-21 at 09:56 +0100, Mathieu Malaterre wrote: > > Hi Ben, > > > > Sorry for the direct question, but I assumed you would know the > > answer. We are currently trying to replace yaboot with grub-ieee1275 > > in debian-installer, but are facing a very small issue, namely with OF > > path handling. It appears that on Apple hardware only `ofpath` from > > Yaboot returns the correct path. Are you using grub on any of your > > Apple hardware ? Thanks much for comments. > > +Nathan > > I have used grub on Apple systems in the past but it's quite possible > that I ended up fixing up the path by hand. To be honest I haven't > booted any of my Apple systems in a while, but I still have some I > can dig out to test if needed. > > Some more comments below... > > > See below for full context. > > > > On Tue, Nov 21, 2017 at 7:51 AM, Frank Scheiner > > wrote: > > > Hi Rick, > > > > > > On 11/21/2017 02:48 AM, Rick Thomas wrote: > > > > > > > > If you can tell me *exactly* what to do, and I don’t have to set up an > > > > installation environment to do it, I’ll be happy to test ofpathname vs > > > > ofpath vs devalias on my PowerPC test machine farm. > > > > > > > > > Well, to be on the safe side, I think you need to use the latest versions > > > of > > > ofpath and ofpathname, hence running Debian Sid could be the easiest way > > > to > > > make sure this is the case. > > > > > > You need to have a disk installed, because ofpath and IIC also ofpathname > > > do > > > not or cannot translate non existing device aliases to OF paths. > > > > > > In general the commands I ran for the p5 520Q below should do. Assuming > > > that > > > the output of ofpathname will always be wrong for Power Macs, it should be > > > sufficient to check only one partition. > > > > > > I think devalias does only save/return OF paths up to the disk level, but > > > not up to the partition level. But the disk level should already be > > > sufficient to detect differences to ofpath and/or ofpathname. > > > > > > You have to go to OF to run devalias, but with a glass console you won't > > > be > > > able to copy the output. There are ways to interact with the OF via telnet > > > from another machine (see [1] and possibly [2]), but I haven't tried this > > > yet. > > > > > > [1]: > > > https://web.archive.org/web/20040202053614/http://developer.apple.com/technotes/tn/tn2004.html > > > > > > [2]: > > > https://web.archive.org/web/20040202060137/http://developer.apple.com:80/technotes/tn/tn2023.html > > > > > > > > > > > I have the following machines: > > > > Power Mac G5 11,2, > > > > Power Mac G5 7,2 (I think — it’s turned off right now) > > > > Mac mini G4 10,1 > > > > > > > > > I have these types available, too, "except" for the 7,3 which currently > > > won't start up correctly. > > > > > > Here's the output of ofpath and ofpathname for /dev/sda2 on the my Mac > > > mini > > > (10,1): > > > ``` > > > root@mac-mini:~# ofpath /dev/sda2 > > > /pci@f400/ata-6@d/@0:2 > > > > > > root@mac-mini:~# ofpathname /dev/sda2 > > > /usr/sbin/ofpathname: line 812: warning: command substitution: ignored > > > null > > > byte in input > > > /pci@f400/ata-6@d/scsi@0/sd@0,0 > > So here, ofpathname gets confused by the fact that Linux shows ATA > devices as scsi (which is a Linux'ism). ofpath has workarounds to deal > with that which should probably be ported over. OK. I see some difference in between ofpath and ofpathname now. I've reported it upstream: https://github.com/ibm-power-utilities/powerpc-utils/issues/30 Let's see how upstream is interested, hopefully we'll be able to make some progress there. > > > > > > Also interesting, it looks like ofpathname cannot even give a "correct" > > > result for an IBM machine, at least not for my p5 520Q: > > > ``` > > > root@p5-520q:~# lsblk > > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > > > sda 8:00 136.7G 0 disk > > > ├─sda1 8:10 7M 0 part > > > ├─sda2 8:20 131.1G 0 part > > > ├─sda3 8:30 1K 0 part > >
Re: Bug#915046: mariadb-10.3: Please build with -latomic where necessary
On Fri, Nov 30, 2018 at 1:05 PM John Paul Adrian Glaubitz wrote: > > Hi! > > Attaching a proof-of-concept patch which fixes the issue for me. > > The patch shouldn't be used as-is as it links against libatomic > unconditionally while it should only link against it when necessary. src:tbb is unconditionally using -latomic for a few Debian releases now and this has not been an issue. libatomic will default to using the correct intrinsics on supported hardware, so the link step should even be able to drop totally deps to that lib.
Timeout of 1h on buildd/powerspe ?
Hi there, I cannot remember: could someone remind me if there is a maximum time allocated for compilation on powerspe ? I cannot make sense otherwise of the following FTBFS on powerspe: https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=powerpcspe&ver=5.2.0-2&stamp=1542215111&raw=0 Thanks
Re: List of powerpc / pmac specific package for debian-ports
On Tue, Sep 4, 2018 at 10:27 AM John Paul Adrian Glaubitz wrote: > > On 09/04/2018 09:36 AM, Mathieu Malaterre wrote: > > In that case: > > > > - pmac-utils > > That's not the whole list. There were other packages like partman-newworld > that got recently removed which are far more important as they are required > for debian-installer. > > See: https://lists.debian.org/debian-boot/2018/09/msg7.html Updated list: - ps3-utils - pmac-utils - partman-newworld - spu-tools - pbbuttonsd
give back for ffmpeg on powerpc ?
Hi there, Could someone let me know why buildd(s) insist on using libx265-160 on powerpc ? https://buildd.debian.org/status/package.php?p=ffmpeg&suite=sid or else gb ffmpeg_7:4.0.2-2 . powerpc Thanks
List of powerpc / pmac specific package for debian-ports
[Anyone please reply to this thread to construct such list] On Mon, Sep 3, 2018 at 2:10 PM John Paul Adrian Glaubitz wrote: > > On 09/03/2018 02:09 PM, Mathieu Malaterre wrote: > > Does anyone knows if we can upload package to debian parts ? It seems > > the main Debian archive is getting rid of pmac related packages (even > > in sid). > > Yes, we can and I will. I haven't had the time yet to do that. > > If someone can compose a list, I will take care of all the packages. In that case: - pmac-utils Thanks,
Fwd: Bug#774840 closed by Andreas Beckmann (pmac-utils has been removed from Debian unstable)
Hi there, Does anyone knows if we can upload package to debian parts ? It seems the main Debian archive is getting rid of pmac related packages (even in sid). -- Forwarded message - Subject: Bug#774840 closed by Andreas Beckmann (pmac-utils has been removed from Debian unstable)
Re: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly
Hi Rick, On Tue, Apr 12, 2016 at 12:08 PM Mathieu Malaterre wrote: > > Dear all, > > I am looking for testers for the following patch: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741663#20 > > Wolfram (CC here) is looking for feedback from users for this patch. Wolfram is still looking for feedback from user on the patch applied recently upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/macintosh/therm_windtunnel.c?id=3e7bed52719de4b5b5fb900869e293eae0bc3f3e Could you give it a try ? Thanks
Re: PowerMac G5 fans run out of control with kernel 4.17.0-3-powerpc64 but not with 4.16.0-1-powerpc64
On Sat, Aug 25, 2018 at 3:41 AM Rick Thomas wrote: > > > I just loaded the latest Debian-ports powerpc64 installer on a PowerMac > dual-core G5 that I had lying around. > > It installed kernel 4.16.0-1-powerpc64 from the CD. After the install > finished, I did an update/upgrade and that installed kernel > 4.17.0-3-powerpc64. > > A few minutes after rebooting with the new kernel the “wind tunnel” fans > started up. I then rebooted with the old (4.16) kernel. The fans did not > start up. > > Back in the old days of Linux kernel 3.x, the fix for wind tunnel fans was to > load the “i2c_powermac" kernel module. Nowadays, that module is built-in so > it isn’t necessary (or even possible) to manually load it. I checked the > config files, and it is still built-in on both the 4.16 and the 4.17 kernels. > > Anybody know what changed and what can be done about it? Is this the same: https://bugzilla.kernel.org/show_bug.cgi?id=199471 [Credit: Wolfram] > Thanks! for any help you can give, > Rick
Re: Problem with gem network card
Christian, On Mon, Oct 17, 2016 at 9:32 AM Mathieu Malaterre wrote: > > Hi, > > On Fri, Oct 14, 2016 at 4:45 PM, Thadeu Lima de Souza Cascardo > wrote: > > There is certainly a way to automate this, but my question on whether > > that sequence would fix the problem was intended to more easily fix a > > real bug in the driver. > > > > I can try to help fix the driver on my free time as a volunteer. > > Christian, would you be willing to test patches to the driver? That > > would require some back and forth between us and some patience of yours, > > as I would be doing it on my spare time, considering I have family and > > other projects I would like to attend to as well. > > > > I don't have a PPC Macbook of my own, but I used to fix Linux drivers on > > PPC64 for a living not too long ago. > > That's a good news ! Feel free to use the bug report #841044 to send > your patch (and/or updates). Any update on the patch ? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841044#30
Re: PowerMac G5 fans run out of control with kernel4.17.0-3-powerpc64 but not with 4.16.0-1-powerpc64
On Sun, Aug 26, 2018 at 2:15 PM Linux User #330250 wrote: > > Am 26.08.18 um 14:07 schrieb Frank Scheiner: > > On 08/26/2018 01:35 PM, Linux User #330250 wrote: > >> Am 26.08.18 um 12:48 schrieb John Paul Adrian Glaubitz: > >>> One of the most pressing problems on Debian powerpc/ppc64 is > >>> the deprecation of Yaboot. Yaboot is completely unmaintained these > >>> days and should > >>> have been replaced with GRUB long time ago. If you install Debian > >>> powerpc/ppc64 on > >>> an IBM-based system (CHRP-IBM or whatever it's called), the > >>> installer will actually > >>> install GRUB. On Mac systems (NewWorld), it will install Yaboot with > >>> the various > >>> problems that people are experiencing. > >>> > >>> Getting GRUB work on PPC Macs requires an extra utility which is > >>> currently part > >>> of the Yaboot package so this needs some extra work. But we have > >>> worked on this > >>> in the past and we hope to get this finished soon. Then we have one > >>> annoyance > >>> less to worry about. > >> > >> > >> What is this tool that is missing? > > > > A working device-to-ofpath translator. > > > > AFAIR during testing in late 2017 the only tool that worked reliably > > on most NewWorld PowerMac and Xserve machines was `ofpath` which is > > part of the yaboot package as Adrian already mentioned. So not > > maintained (because part of yaboot) and missing when yaboot is dropped. > > > > The other available tool `ofpathname` is meant for IBM machines and > > gives wrong results on Apple machines (and also on IBM machines). The > > tool `grub-ofpathname` from GRUB didn't work as expected during my > > testing. > > > > See e.g. [1] for some background. > > > > [1]: https://lists.debian.org/debian-powerpc/2017/11/msg00086.html > > > > Thanks, but why use ofpath when GRUB2 core.elf can figure that out all > by itself without the use of open firmware stuff? Just use the UUID of > the partition where the second main GRUB2 is installed, and use the > first GRUB2 only as the first stage core.elf. The actual bug was reported here: https://bugs.debian.org/882076 The other grub-related powerpc issues can be found from: https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=powerpc&user=debian-powerpc%40lists.debian.org > Example: your /boot UUID is 12345678-abcd-ef01-1234-abcdef012345, > grub.cfg on the HFS partition together with core.elf from GRUB2, blessed > (:tbxi) using hattrib: > > search --no-floppy --fs-uuid --set=root > 12345678-abcd-ef01-1234-abcdef012345 > > set prefix=($root)/boot/grub > > configfile /boot/grub/grub.cfg > > This will load grub.cfg from the real /boot partition and continue from > there, no need to get the ofpath. > > At least that was how I did it on a Power Mac G4. > > > Linux User #330250 >
Re: How to read CPU temp from TAU?
On Mon, May 28, 2018 at 12:50 AM, Matti Palmström wrote: > On Sun, May 27, 2018 at 7:59 AM, Mathieu Malaterre wrote: >> What's the output of >> $ cat /proc/cpuinfo >> ? > > $ cat /proc/cpuinfo > processor : 0 > cpu : 7447A, altivec supported > clock : 1499.94MHz > revision: 1.5 (pvr 8003 0105) > bogomips: 83.20 > > timebase: 41600571 > platform: PowerMac > model : PowerMac10,2 > machine : PowerMac10,2 > motherboard : PowerMac10,2 MacRISC3 Power Macintosh > detected as : 287 (Mac mini (Late 2005)) > pmac flags : 0010 > L2 cache: 512K unified > pmac-generation : NewWorld > Memory : 1024 MB Temperature would have been displayed right there if your CPU had this option. -M
Re: How to read CPU temp from TAU?
On Sun, May 27, 2018 at 12:18 AM, Matti Palmström wrote: > Hi > > How do you read the cpu temperature from TAU on an iMac mini G4 (MPC7447a)? > > According to /boot/config-4.16.0-1-powerpc it is compiled with TAU on > CONFIG_TAU=y > but I can't find a way to read it. I've tried with lm-sensors but no go > there. What's the output of $ cat /proc/cpuinfo ? > Regards > /M
Re: radeon 0000:00:10.0: ring 0 stalled for more than 10240msec
On Tue, Apr 24, 2018 at 11:11 PM, Mick wrote: > On Tue, 24 Apr 2018 22:45:47 +0200 > John Paul Adrian Glaubitz wrote: > >> On 04/24/2018 10:35 PM, Mick wrote: >> > That's exactly what happened with lubuntu 16.04 PPC on my ibook G4 (with >> > a radeon graphic card). And that's the reason why I rolled back to 14.04. >> > And that's also why I subscribe to this list! >> >> Feel free to install Debian sid on your iBook G4 [1]. You will have something >> supported (unofficially through Debian Ports) and up-to-date for your >> iBook. >> > Encouraging words! I will do assoon as possible,thanks. > >> I'm not sure what Mathieu was referring to in his second mail though >> when talking about PCI vs AGP. I think the Radeon in the G4 was AGP. >> > The radeon is on AGP bus, but I heard that the driver does not work well in > agp mode. The only way I found to let the system stay up is to pass to the > kernel the parameter radeon.agpmode=-1, which means use the card in PCI mode. > I suppose he was referring to it. I had been working on radeonfb for a while and totally forgot that I commented out: $ cat /etc/modprobe.d/radeon.conf #options radeon agpmode=-1 So I (re)submitted an old patch to change the default behavior: https://patchwork.kernel.org/patch/10360887/ > -- > Mick >
Re: radeon 0000:00:10.0: ring 0 stalled for more than 10240msec
Answering myself On Tue, Apr 24, 2018 at 9:16 PM, Mathieu Malaterre wrote: > Hi there, > > Does anyone still have a running Mac Mini G4 (ATI RV280) ? It seems > like the latest kernel are not very stable after a couple of second > running X I get (*). I'd be interested in your latest running kernel > to get a good starting point for a git bisect (X session stable). > > Thanks much > > (*) > [ 1228.795711] radeon :00:10.0: ring 0 stalled for more than 10240msec I did not pay attention I used AGP instead of PCI... > [ 1228.795725] radeon :00:10.0: GPU lockup (current fence id > 0x02cd last fence id 0x02ce on ring 0) > [ 1228.942139] radeon: wait for empty RBBM fifo failed! Bad things might > happen. > [ 1229.081818] Failed to wait GUI idle while programming pipes. Bad > things might happen. > [ 1229.084385] radeon :00:10.0: Saved 27 dwords of commands on ring 0. > [ 1229.084403] radeon :00:10.0: (r100_asic_reset:2562) > RBBM_STATUS=0x8006C139 > [ 1229.581939] radeon :00:10.0: (r100_asic_reset:2583) > RBBM_STATUS=0x8002C139 > [ 1230.075498] radeon :00:10.0: (r100_asic_reset:2591) > RBBM_STATUS=0x8002C139 > [ 1230.075524] radeon :00:10.0: GPU reset succeed > [ 1230.075529] radeon :00:10.0: GPU reset succeeded, trying to resume > [ 1230.075542] radeon :00:10.0: (r100_asic_reset:2562) > RBBM_STATUS=0x8002C139 > [ 1230.573058] radeon :00:10.0: (r100_asic_reset:2583) > RBBM_STATUS=0x8002C139 > [ 1231.066614] radeon :00:10.0: (r100_asic_reset:2591) > RBBM_STATUS=0x8002C139 > [ 1231.066636] radeon :00:10.0: GPU reset succeed > [ 1231.066705] radeon :00:10.0: WB disabled > [ 1231.066718] radeon :00:10.0: fence driver on ring 0 use gpu > addr 0x and cpu addr 0xfe23ec9e > [ 1231.206211] radeon: wait for empty RBBM fifo failed! Bad things might > happen. > [ 1231.345701] Failed to wait GUI idle while programming pipes. Bad > things might happen. > [ 1231.345746] [drm] radeon: ring at 0x1000 > [ 1231.359946] [drm] ring test succeeded in 0 usecs > [ 1232.440347] [drm:r100_ib_test [radeon]] *ERROR* radeon: fence wait timed > out. > [ 1232.440423] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: > failed testing IB on GFX ring (-110). > [ 1232.580028] radeon: wait for empty RBBM fifo failed! Bad things might > happen. > [ 1232.719635] Failed to wait GUI idle while programming pipes. Bad > things might happen. > [ 1232.740206] radeon :00:10.0: Saved 239259 dwords of commands on ring 0. > [ 1232.740235] radeon :00:10.0: (r100_asic_reset:2562) > RBBM_STATUS=0x8002C135 > [ 1233.237763] radeon :00:10.0: (r100_asic_reset:2583) > RBBM_STATUS=0x8002C135 > [ 1233.731322] radeon :00:10.0: (r100_asic_reset:2591) > RBBM_STATUS=0x8002C135 > [ 1233.731350] radeon :00:10.0: GPU reset succeed > [ 1233.731355] radeon :00:10.0: GPU reset succeeded, trying to resume > [ 1233.731367] radeon :00:10.0: (r100_asic_reset:2562) > RBBM_STATUS=0x8002C135 > [ 1234.228884] radeon :00:10.0: (r100_asic_reset:2583) > RBBM_STATUS=0x8002C135 > [ 1234.722505] radeon :00:10.0: (r100_asic_reset:2591) > RBBM_STATUS=0x8002C135 > [ 1234.722532] radeon :00:10.0: GPU reset succeed > [ 1234.722602] radeon :00:10.0: WB disabled > [ 1234.722616] radeon :00:10.0: fence driver on ring 0 use gpu > addr 0x and cpu addr 0xfe23ec9e > [ 1234.862104] radeon: wait for empty RBBM fifo failed! Bad things might > happen. > [ 1235.001568] Failed to wait GUI idle while programming pipes. Bad > things might happen. > [ 1235.001613] [drm] radeon: ring at 0x1000 > [ 1235.017321] [drm] ring test succeeded in 0 usecs
radeon 0000:00:10.0: ring 0 stalled for more than 10240msec
Hi there, Does anyone still have a running Mac Mini G4 (ATI RV280) ? It seems like the latest kernel are not very stable after a couple of second running X I get (*). I'd be interested in your latest running kernel to get a good starting point for a git bisect (X session stable). Thanks much (*) [ 1228.795711] radeon :00:10.0: ring 0 stalled for more than 10240msec [ 1228.795725] radeon :00:10.0: GPU lockup (current fence id 0x02cd last fence id 0x02ce on ring 0) [ 1228.942139] radeon: wait for empty RBBM fifo failed! Bad things might happen. [ 1229.081818] Failed to wait GUI idle while programming pipes. Bad things might happen. [ 1229.084385] radeon :00:10.0: Saved 27 dwords of commands on ring 0. [ 1229.084403] radeon :00:10.0: (r100_asic_reset:2562) RBBM_STATUS=0x8006C139 [ 1229.581939] radeon :00:10.0: (r100_asic_reset:2583) RBBM_STATUS=0x8002C139 [ 1230.075498] radeon :00:10.0: (r100_asic_reset:2591) RBBM_STATUS=0x8002C139 [ 1230.075524] radeon :00:10.0: GPU reset succeed [ 1230.075529] radeon :00:10.0: GPU reset succeeded, trying to resume [ 1230.075542] radeon :00:10.0: (r100_asic_reset:2562) RBBM_STATUS=0x8002C139 [ 1230.573058] radeon :00:10.0: (r100_asic_reset:2583) RBBM_STATUS=0x8002C139 [ 1231.066614] radeon :00:10.0: (r100_asic_reset:2591) RBBM_STATUS=0x8002C139 [ 1231.066636] radeon :00:10.0: GPU reset succeed [ 1231.066705] radeon :00:10.0: WB disabled [ 1231.066718] radeon :00:10.0: fence driver on ring 0 use gpu addr 0x and cpu addr 0xfe23ec9e [ 1231.206211] radeon: wait for empty RBBM fifo failed! Bad things might happen. [ 1231.345701] Failed to wait GUI idle while programming pipes. Bad things might happen. [ 1231.345746] [drm] radeon: ring at 0x1000 [ 1231.359946] [drm] ring test succeeded in 0 usecs [ 1232.440347] [drm:r100_ib_test [radeon]] *ERROR* radeon: fence wait timed out. [ 1232.440423] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-110). [ 1232.580028] radeon: wait for empty RBBM fifo failed! Bad things might happen. [ 1232.719635] Failed to wait GUI idle while programming pipes. Bad things might happen. [ 1232.740206] radeon :00:10.0: Saved 239259 dwords of commands on ring 0. [ 1232.740235] radeon :00:10.0: (r100_asic_reset:2562) RBBM_STATUS=0x8002C135 [ 1233.237763] radeon :00:10.0: (r100_asic_reset:2583) RBBM_STATUS=0x8002C135 [ 1233.731322] radeon :00:10.0: (r100_asic_reset:2591) RBBM_STATUS=0x8002C135 [ 1233.731350] radeon :00:10.0: GPU reset succeed [ 1233.731355] radeon :00:10.0: GPU reset succeeded, trying to resume [ 1233.731367] radeon :00:10.0: (r100_asic_reset:2562) RBBM_STATUS=0x8002C135 [ 1234.228884] radeon :00:10.0: (r100_asic_reset:2583) RBBM_STATUS=0x8002C135 [ 1234.722505] radeon :00:10.0: (r100_asic_reset:2591) RBBM_STATUS=0x8002C135 [ 1234.722532] radeon :00:10.0: GPU reset succeed [ 1234.722602] radeon :00:10.0: WB disabled [ 1234.722616] radeon :00:10.0: fence driver on ring 0 use gpu addr 0x and cpu addr 0xfe23ec9e [ 1234.862104] radeon: wait for empty RBBM fifo failed! Bad things might happen. [ 1235.001568] Failed to wait GUI idle while programming pipes. Bad things might happen. [ 1235.001613] [drm] radeon: ring at 0x1000 [ 1235.017321] [drm] ring test succeeded in 0 usecs
Removal of POWER4 support, (was: [GIT PULL] Please pull powerpc/linux.git powerpc-4.17-1 tag)
Hi G5 users, Could someone shed some lights on POWER4 removal. I thought G5 were POWER4 ? (see below) ... - Removal of POWER4 support, which was accidentally broken in 2016 and no one noticed, and blocked use of some modern instructions. ... See commit 471d7ff8b51b63521c8ea35c51966ab4caa434ee in powerpc/next.
Re: initrd fails load with "ERROR: claim of 0xfe49172 in range 0x1340000-0x10000000 failed"
On Sun, Mar 4, 2018 at 4:11 AM, Dennis Clarke wrote: > > Dear PPC types : > > So I carefully built kernel 4.15.6 and created the needed > initrd.img-4.15.6 in /boot with update-initramfs and checked it > carefully against the pre-existing initrd.img-4.13.0-1-powerpc64 for > Debian buster/sid. Everything looks great and my objective was to > poke around the RFI flush of L1-D cache issue. Which may exist. No > one really knows ( yet ): > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa8a5e0062ac940f7659394f4817c948dc8c0667 > > I had to take a picture of the screen but really it seems to say that my > new initrd will not load into memory for some reason. Perhaps too darn > big? This is an old yet well loved PowerMac G5 and I am wondering if > there is an nvram or maybe an openfirmware command magic incantation to > utter? I have 8G of memory and surely no reason to not load in a very > large initrd image? Maybe I am missing the whole point here. But why don't you built the bindeb target ? (not tested): make ARCH=powerpc g5_defconfig make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- bindeb-pkg When you dpkg -i the package, make sure the initrd / vmlinux links are updated (I do ln -sf manually). > What I see on the screen seems fairly clear : > > Welcome to yaboot version 1.3.17 > Enter "help" to get some basic usage information > boot: Linux > Please wait, loading kernel... >Elf64 kernel loaded... > Loading ramdisk... > ERROR: claim of 0xfe49172 in range 0x134-0x1000 failed > Claim failed for initrd memory > ramdisk load failed ! > > Apple PowerMac11,2 5.2.7f1 BootROM built on 09/30/05 at 15:31:03 > Copyright 1994-2005 Apple Computer, Inc. > All Rights Reserved. > > Welcome to Open Firmware, the system time and date is: 03/03/2018 23:31:47 > > > etc etc and the usual "0 >" prompt wherein I went looking for nvram > data with printenv. I won't retype all that. I am hoping that the > variable load-base may be of help here. > > Any thoughts? > > > Dennis > > ps: yaboot conf is trivial : > > > > nix# cat /etc/yaboot.conf > ## yaboot.conf generated by debian-installer > ## > ## run: "man yaboot.conf" for details. Do not make changes until you have!! > ## see also: /usr/share/doc/yaboot/examples for example configurations. > ## > ## For a dual-boot menu, add one or more of: > ## bsd=/dev/hdaX, macos=/dev/hdaY, macosx=/dev/hdaZ > > boot="/dev/disk/by-id/ata-Hitachi_HDS725050KLA360_KRVN23ZAHA5DBD-part2" > device=/ht@0,f200/pci@9/k2-sata-root@c/@0/@0 > partition=3 > root="/dev/sda3" > timeout=50 > install=/usr/lib/yaboot/yaboot > magicboot=/usr/lib/yaboot/ofboot > enablecdboot > > image=/boot/vmlinux > label=Linux > read-only > initrd=/boot/initrd.img > > image=/boot/vmlinux.old > label=old > read-only > initrd=/boot/initrd.img.old > nix# > > However I did add in these : > > nix# diff /etc/yaboot.conf_20180303232549 /etc/yaboot.conf > 20a21,22 >> append="verbose ipv6.disable=1" >> pause-after > nix# >
Re: Jessie boot appears to hang on Pegasos 2 G4 after "returning from prom_init"
Hi Gabor, On Sun, Feb 25, 2018 at 3:05 PM, Gabor Samu wrote: > Hello, > > I'm the proud owner of a Genesi Pegasos 2 G4 system. I previously had > Debian 7 (Wheezy) installed on the system. It worked perfectly, including > XWindows, etc. > > I decided to upgrade the system from Debian 7 to Debian 8 this weekend via > apt-get dist-upgrade (with requisite repo changes, etc). > > The upgrade process itself took a while, but did complete without errors. > > Upon reboot however, the system appears to hang right after startup. I've > transcribed this from a photo I took of the screen: > > === > Finalizing device tree... using OF tree (promptr=01003bc4) > OF stdout device is: /bootconsole > Preparing to boot Linux version 3.16.0-4-powerpc > (debian-ker...@lists.debian.org) > (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.51-3 (2017-12-13) > Detected machine type : 0500 > command line: root=/dev/mapper/pegasos2-root video=radeonfb:off > memory layout at init: > memory_limit : (16 MB aligned) > alloc_bottom : 02431000 > alloc_top: 3000 > alloc_top_hi : 4000 > rmo_top : 3000 > ram_top : 4000 > instantiating rtas at 0x0fbfd000... done > Fixing up missing ISA range on Pegasos... > Fixing up missing IDE interrupt on Pegasos... > Fixing up IDE class-code on Pegasos... > copying OF device tree... > Building dt strings... > Building dt structure... > Device tree strings 0x02432000 -> 0x024327a9 > Device tree struct 0x02433000 -> 0x02456000 > Calling quiesce... > returning from prom_init > > > > I've tried both with and without the video=radeonfb:off kernel boot option, > but the result is the same. > I'd really like to keep my Pegasos running and would appreciate it if > anybody has tips to address. > > Not sure if it matters, but my system has a ATI Radeon 9200 series card (I > believe it's designation RV280). Did you see the thread: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782058#31
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
On Tue, Feb 13, 2018 at 11:38 AM, John Paul Adrian Glaubitz wrote: > On 02/13/2018 11:27 AM, Mathieu Malaterre wrote: >> >> The fixed version: >> >> https://packages.debian.org/sid/e2fslibs1.41-dev >> >> is in archive, and currently build just fine. You can consider as if >> yaboot had its own convenient copy of e2fslibs. >> >> Does that answer your question ? Or did I miss the point ? > > > Then why was Mark unable to build Yaboot if the fixed version is > in the archive? If it's just a matter of building in a clean > sid chroot, why wasn't that done in the first place as I suggested? My guess (crystal ball) is that he used the non-fixed version: https://packages.debian.org/sid/e2fslibs-dev I'll leave the full answer to Mark :) -M
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
On Tue, Feb 13, 2018 at 11:06 AM, John Paul Adrian Glaubitz wrote: > On 02/13/2018 11:03 AM, Mathieu Malaterre wrote: >>> >>> I can upload a version of Yaboot today with this patch reverted provided >>> that Yaboot still builds fine on unstable without the hack you used. >> >> >> I call it a hack, but really this is the best long term solution there >> is. Yaboot is filled with empty stub, that one had to add over and >> over. Using a fixed version of e2fslib made the symptoms go away. >> Please check with milan@d.o for the gory details, hopefully I am not >> too far from the reality. I would not spent any time on yaboot anyway. > > > If I need to hack e2fslib to get Yaboot to build, then I can not easily > update the Yaboot package. e2fslib is a package in the archives, I can't > just hijack the package and add some hacks to get a bootloader for a non- > release architecture fixed. The fixed version: https://packages.debian.org/sid/e2fslibs1.41-dev is in archive, and currently build just fine. You can consider as if yaboot had its own convenient copy of e2fslibs. Does that answer your question ? Or did I miss the point ? -M
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
Adrian, On Tue, Feb 13, 2018 at 10:16 AM, John Paul Adrian Glaubitz wrote: > >> On Feb 13, 2018, at 7:39 AM, Mark Cave-Ayland >> wrote: >> >>> On 12/02/18 10:55, John Paul Adrian Glaubitz wrote: >>> >>>> On 02/12/2018 11:52 AM, Mathieu Malaterre wrote: >>>> From the look at the error message, I thought this was the hack >>>> milan@d.o used with: >>>> >>>> https://packages.debian.org/sid/e2fslibs1.41-dev >>> Again, we're talking about booting the CD, not the installed system. >>> There is no ext2/3/4 involved here. The bug you mentioned exists >>> because Yaboot doesn't handle ext4. >> >> The above package provided the key: the link error I was seeing was because >> the default e2fslibs package only provides .so libraries. Extracting the >> static library from the above package was enough to get my compile to >> succeed. > > Ok, I wasn’t paying too much attention to the linker errors. We have to > verify then that Yaboot actually still builds on unstable. > >> Anyhow I can confirm that the bug I see is present in 1.3.17 and not 1.3.16, >> and with the magic of git bisect I managed to isolate it down to this commit: > > I can upload a version of Yaboot today with this patch reverted provided that > Yaboot still builds fine on unstable without the hack you used. I call it a hack, but really this is the best long term solution there is. Yaboot is filled with empty stub, that one had to add over and over. Using a fixed version of e2fslib made the symptoms go away. Please check with milan@d.o for the gory details, hopefully I am not too far from the reality. I would not spent any time on yaboot anyway. >> http://git.ozlabs.org/?p=yaboot.git;a=commitdiff;h=b5f28817d6d68c2cb2a3e5eaefe4633b085557b6 >> >> The first thing to notice is that prom_claim_chunk_top() introduced in the >> previous commit has an obvious mistake which means it allocates memory >> outside the top of its region. This is easily fixed, but doesn't appear to >> solve my problem. >> >> Building a full debug version and stepping through with gdb shows that the >> problem is the failure of strdup() to copy the incoming configuration here: >> http://git.ozlabs.org/?p=yaboot.git;a=blob;f=second/file.c;h=fd081a3010d3ba4710349144da54ac73fe23cb3f;hb=0e48da7ef41c6fc36f80f44e5e4a329000412f88#l485. >> >> From what I can tell the malloc() succeeds, however the memory being >> returned doesn't appear to be writeable(!). That's about as far as I managed >> to get last night, but it might be that this particular bug is related to >> something in the OpenBIOS memory layout. >> >> >> ATB, >> >> Mark. > Thanks
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
On Mon, Feb 12, 2018 at 11:55 AM, John Paul Adrian Glaubitz wrote: > On 02/12/2018 11:52 AM, Mathieu Malaterre wrote: >> >> From the look at the error message, I thought this was the hack >> milan@d.o used with: >> >> https://packages.debian.org/sid/e2fslibs1.41-dev > > > Again, we're talking about booting the CD, not the installed system. Hum, sorry. I was 100% convinced that yaboot failed to compiled on recent e2fslib so an old package was required to be used. > There is no ext2/3/4 involved here. The bug you mentioned exists > because Yaboot doesn't handle ext4. Sorry for the noise, I really tried to help here. -M
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
On Mon, Feb 12, 2018 at 11:47 AM, John Paul Adrian Glaubitz wrote: > On 02/12/2018 11:44 AM, Mark Cave-Ayland wrote: >> >> Hmmm so I can't seem to even build yaboot-1.3.16 using an installation >> from the official Jessie powerpc ISO in QEMU. >> >> I've done a basic install of Jessie, then added in various build packages >> including "apt-get source yaboot" to get all the dependencies installed. >> >> When I try "dpkg-buildpackage" on yaboot it all goes fine up until the >> final link: >> (...) >> Is there something else I'm missing here? > > > Try building using sbuild and build in a jessie chroot. > > Building outside a chroot isn't really the best way and > prone to various problems. >From the look at the error message, I thought this was the hack milan@d.o used with: https://packages.debian.org/sid/e2fslibs1.41-dev -M
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
On Sun, Feb 11, 2018 at 6:43 PM, Mark Cave-Ayland wrote: > On 10/02/18 16:07, Frank Scheiner wrote: > >> On 02/10/2018 03:29 PM, John Paul Adrian Glaubitz wrote: >>> >>> On 02/10/2018 10:22 AM, Mark Cave-Ayland wrote: My existing Jessie test image (debian-8.5.0-powerpc-netinst.iso) works fine, so it looks like there is a regression somewhere in the boot loader configuration. Does anyone know what has changed between these two images that could cause this to break? >>> >>> >>> Possibly relevant discussion: >>> https://lists.debian.org/debian-powerpc/2017/10/msg00089.html https://lists.debian.org/debian-powerpc/2017/10/msg00118.html >> >> >> Yeah, maybe it's just the yaboot versions (1.3.16 for Jessie, 1.3.17 for >> Sid), that makes the difference. > > > It's annoying that something has regressed here though: is there an official > git repo for yaboot to check out the differences between 1.3.16 and 1.3.17? > > The fact that it still works on real hardware suggests that something has > changed here: is it possible to generate a test ISO using 1.3.16 yaboot to > see if that starts working under QEMU again? That would narrow things down > immensely. The main thing that changed was: https://bugs.debian.org/825110 But I thought this had been fixed in the installer now.
Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500
On Sun, Feb 11, 2018 at 4:30 AM, Dennis Clarke wrote: > This is something that needs to be discussed. A single user alone shouldn't warrant such major change in a port. You always have to keep in mind that changing the default compiler options also has potential impact on the performance on more modern ppc64 systems like Apple Macintosh. >>> >>> >>> >>> Not sure how modern an Apple Mac is but here is a photo I took only a >>> few minutes ago: >>> >>> https://i.imgur.com/6UbviKb.jpg >>> >>> >>> I have this old Mac G5 running as a fine example of a big-endian machine >>> and the PPC970MP processors in it seem to work very well. However it is >>> certainly becoming difficult to get results from it that can compare to >>> what I get from some other machines like Fujitsu SPARC for example. The >>> biggest complaint is with floating point wherein the data representation >>> may be actual IEEE 754-2008 style or some new IBM variant that I am not >>> at all familiar with. In fact, some code, trivial, won't compile at all >>> if I try to use "IEEE extended precision long double" with very few ways >>> to get around that : >>> >>> gcc -mcpu=970 -mno-altivec -m64 -std=iso9899:1999 -Wfatal-errors \ >>> -pedantic-errors -mabi=ieeelongdouble ... >>> >>> The gcc that I am using claims to be : >>> >>>GNU C99 (Debian 7.2.0-17) version 7.2.1 20171205 (powerpc64-linux-gnu) >>> compiled by GNU C version 7.2.1 20171205, GMP version 6.1.2, >>> MPFR version 3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP >>> >>> ... snip ... > > >> This is quite well known, for a long time, IBM on Power (not on >> mainframes) used a non IEEE format for long doubles. Actually these are >> two IEEE doubles "concatenated", so: >> - the mantissa is somewhat less precise, 2 times 53 bits instead of 112 >> - the exponent range is way smaller, in powers of 10 the range is >>roughly ±308 (same as double) instead of ±4932. > > > That seems to make sense looking at the in memory values. I can't make > heads or tails out of it in terms of IEEE754-2008 formats. As for the > IBM mainframes, well gee, that is a long lost love of mine as I was an > IBM systems admin for the 3090 MVS/ESA systems and they were a real joy > with Fortran IV. A million years ago. > >> >> The fact the the in memory representation is completely different is not >> surprising when you take this into account. >> >> This was somewhat faster than a full emulation of IEEE quad math, but >> now IBM has switched to real IEEE quad (in hardware even on Power9, I >> suspect most Sparc do it in software). > > > I can assure you that every sparc does it in software emulation. The > 64-bit floating point is pure hardware and works very well. > >> I'm away from my Power machine right now and it is switched off, so I >> can't try your code and play with compiler options. >> > > Thank you for getting back to me and I look forwards to seeing what your > IBM Power system has to say from that code snippit. One shorted example from SO recently: const constexpr long double DEGREE_TO_RAD = 0.0174532925199432954743716805978693; const constexpr long double RAD_TO_DEGREE = 1. / DEGREE_TO_RAD; https://stackoverflow.com/questions/48553127/error-with-long-doubles-on-powerpc-when-compiling-with-gcc
Re: [extcontact] Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500
Hi all, On Fri, Feb 9, 2018 at 1:12 PM, Luuk van Dijk wrote: > I apologize for the 'reply in 48 hours' spam my extcontacts mailinglist > caused for any of you that replied here. I asked bas to keep us posted but > i didn't realize it would send this out. I switched it off. > > thanks for all your hard work. > > /Luuk > > On Fri, Feb 9, 2018 at 12:56 PM Bas Vermeulen wrote: >> >> diff of gcc -dM -E - without and with the patch applied: >> >> --- gcc-default 2018-01-28 18:06:14.11600 + >> +++ gcc-powerpc64 2018-01-28 18:03:06.57200 + >> @@ -34,7 +34,6 @@ >> #define __FLT64_DECIMAL_DIG__ 17 >> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2 >> #define pixel pixel >> -#define _ARCH_PPCSQ 1 >> #define bool bool >> #define __UINT_FAST64_MAX__ 0xUL >> #define __SIG_ATOMIC_TYPE__ int >> @@ -78,7 +77,6 @@ >> #define __USER_LABEL_PREFIX__ >> #define __STDC_HOSTED__ 1 >> #define __LDBL_HAS_INFINITY__ 1 >> -#define _ARCH_PWR4 1 >> #define __builtin_vsx_xvmaddmsp __builtin_vsx_xvmaddsp >> #define __CMODEL_MEDIUM__ 1 >> #define __FLT32_DIG__ 6 >> >> gcc -Q --help=target (default vs with the patch applied): >> >> --- gcc-Q-default 2018-01-28 18:08:29.23200 + >> +++ gcc-Q-powerpc64 2018-01-28 18:07:39.98400 + >> @@ -35,7 +35,7 @@ >>-mcmodel=medium >>-mcmpb [disabled] >>-mcompat-align-parm [disabled] >> - -mcpu= [default] >> + -mcpu= powerpc64 >>-mcrypto[disabled] >>-mdebug= >>-mdirect-move[disabled] >> @@ -70,7 +70,7 @@ >>-mlong-double-128 >>-mlongcall [disabled] >>-mlra[enabled] >> - -mmfcrf [enabled] >> + -mmfcrf [disabled] >>-mmfpgpr[disabled] >>-mminimal-toc[disabled] >>-mmodulo[disabled] >> @@ -89,7 +89,7 @@ >>-mpointers-to-nested-functions [enabled] >>-mpopcntb[disabled] >>-mpopcntd[disabled] >> - -mpower8-fusion [enabled] >> + -mpower8-fusion [disabled] >>-mpower8-fusion-sign[disabled] >>-mpower8-vector [disabled] >>-mpower9-dform [enabled] >> @@ -101,9 +101,9 @@ >>-mpower9-vector [disabled] >>-mpowerpc >>-mpowerpc-gfxopt[enabled] >> - -mpowerpc-gpopt [enabled] >> + -mpowerpc-gpopt [disabled] >>-mpowerpc64 [enabled] >> - -mprioritize-restricted-insns= 1 >> + -mprioritize-restricted-insns= 0 >>-mprofile-kernel[disabled] >>-mprototype [disabled] >>-mquad-memory[disabled] >> @@ -145,7 +145,7 @@ >>-mtoc[disabled] >>-mtoc-fusion[disabled] >>-mtraceback=[default] >> - -mtune= [default] >> + -mtune= powerpc64 >>-muclibc[disabled] >>-mupdate[enabled] >>-mupper-regs[enabled] The diff looks a bit odd to me, I do not understand why we would be moving away from the default mtune. Anyway you have my vote. I know Adrian gets sometime inspiration from fedora team, maybe time to reach a consensus with them also. IBM seems to be going toward ppc64el anyway, so I believe that should not affect too many people. 2cts, -M
Hardware info in Mac Mini G4
Just for posterity, I realized that system_profiler and /sys do not provide exactly the same representation for the same information. For comparison: system_profiler: Boot ROM Version: 4.8.9f4 Serial Number: YM5306NSTYX But: $ hexdump -C "/sys/firmware/devicetree/base/rom@ff80/boot-rom@fff0/BootROM-version" 24 30 30 30 34 2e 38 39 66 34 00 |$0004.89f4.| 000b $ hexdump -C "/sys/firmware/devicetree/base/serial-number" 54 59 58 00 00 00 00 00 00 00 00 00 00 59 4d 35 |TYX..YM5| 0010 33 30 36 4e 53 54 59 58 00 00 00 00 00 00 00 00 |306NSTYX| 0020 00 00 00 00 00 00 00 00 00 00 00 |...| 002b
Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500
On Fri, Feb 9, 2018 at 11:34 AM, John Paul Adrian Glaubitz wrote: > On 02/09/2018 11:30 AM, Bas Vermeulen wrote: >> >> mator on #debian-ports compiled gcc-7 for me with the attached patch. >> With the resulting gcc, I compiled glibc and got a library I can use >> sqrtf without running into an illegal instruction exception. >> >> Would it be possible to get this applied by default? The resulting >> binaries work on e6500, and ought to work on all supported CPUs >> for the ppc64 port. > > > This is something that needs to be discussed. A single user alone shouldn't > warrant such major change in a port. You always have to keep in mind that > changing the default compiler options also has potential impact on the > performance on more modern ppc64 systems like Apple Macintosh. > > So, while I'm generally not against such a change, I would like to hear > some voices first. uh, could someone please actually list the diff ? I am guessing something like: $ echo | gcc -dM -E - or maybe: $ gcc -Q --help=target
[ppc32] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118
Hi there, Could someone please shed some light on the following warning I am seeing on git/master (4.15) [*]. I fail to understand the impact of this, and I also fail to understand if the config: CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y is inconsistent. Thanks for comment, [*] -- Forwarded message -- From: Mathieu Malaterre Date: Fri, Feb 2, 2018 at 2:11 PM Subject: [ppc32] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118 To: linuxppc-dev Cc: Christoph Hellwig Hi there, What is this warning all about (system is Mac Mini G4) ? Thanks [3.265537] pata-macio 0.0002:ata-3: Activating pata-macio chipset KeyLargo ATA-3, Apple bus ID 0 [3.272686] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118 [3.280031] Modules linked in: [3.283660] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0+ #333 [3.287314] NIP: c0643f5c LR: c0643ec8 CTR: [3.290920] REGS: df4f1c00 TRAP: 0700 Not tainted (4.15.0+) [3.294499] MSR: 00029032 CR: 28228428 XER: 2000 [3.298056] GPR00: c0643ec8 df4f1cb0 df4ee940 de15de50 de15de5c GPR08: c08e4d88 24228484 c0004cc8 GPR16: c0c9 GPR24: c0b4fdd0 c0c3d6e0 de00beec 1020 014000c0 de15de50 de017c18 [3.315308] NIP [c0643f5c] dmam_alloc_coherent+0xd8/0x118 [3.318724] LR [c0643ec8] dmam_alloc_coherent+0x44/0x118 [3.322073] Call Trace: [3.325399] [df4f1cb0] [c0643ec8] dmam_alloc_coherent+0x44/0x118 (unreliable) [3.328858] [df4f1cd0] [c06a5f4c] pata_macio_port_start+0x48/0x98 [3.332294] [df4f1cf0] [c068b25c] ata_host_start.part.9+0x108/0x220 [3.335706] [df4f1d10] [c06912d8] ata_host_activate+0x70/0x15c [3.339084] [df4f1d30] [c06a6a8c] pata_macio_common_init+0x300/0x568 [3.342459] [df4f1d90] [c06a6ef4] pata_macio_attach+0xe4/0x18c [3.345862] [df4f1db0] [c06582bc] macio_device_probe+0x64/0xf8 [3.349218] [df4f1dd0] [c062c5e8] driver_probe_device+0x334/0x4b4 [3.352537] [df4f1e00] [c062c884] __driver_attach+0x11c/0x120 [3.355822] [df4f1e20] [c0629a14] bus_for_each_dev+0x70/0xc0 [3.359074] [df4f1e50] [c062b338] bus_add_driver+0x180/0x2dc [3.362277] [df4f1e70] [c062d620] driver_register+0x94/0x13c [3.365415] [df4f1e80] [c0b937f8] pata_macio_init+0x68/0x90 [3.368474] [df4f1ea0] [c0004af4] do_one_initcall+0x4c/0x178 [3.371471] [df4f1f00] [c0b50774] kernel_init_freeable+0x138/0x1d0 [3.374421] [df4f1f30] [c0004cec] kernel_init+0x24/0x118 [3.377337] [df4f1f40] [c0018304] ret_from_kernel_thread+0x5c/0x64 [3.380249] --- interrupt: 0 at (null) LR = (null) [3.385965] Instruction dump: [3.388713] 7fc4f378 7fe3fb78 93be0004 913e0008 939e 4bfecd79 7fa3eb78 80010024 [3.391513] bb61000c 38210020 7c0803a6 4e800020 <0fe0> 812a 2f89 409eff98 [3.394280] ---[ end trace a4431b67b2b33261 ]--- [3.397425] scsi host1: pata_macio
Re: Bug#886973: kronosnet: FTBFS on ppc64: knet_handle_new not found in binary lib
Control: tags -1 upstream On Wed, Jan 17, 2018 at 11:32 AM, Mathieu Malaterre wrote: > On Sun, Jan 14, 2018 at 4:47 PM, Aaron M. Ucko wrote: >> Ferenc Wágner writes: >> >>> The test looks for the exported API function names in the text (T) >>> section, but the ppc64 nm reports them in the data (D) section: >>> >>> $ nm -B -D libknet.so.1.0.0 >>> A LIBKNET >>> [...] >>> 0003ec40 D knet_handle_new >>> [...] >>> >>> Is this a known ppc64 peculiarity or a binutils bug? >> >> Good question. Porters? > > Does not make any sense to me: > > https://sourceware.org/bugzilla/show_bug.cgi?id=22720 > > Let see what upstream has to say https://sourceware.org/bugzilla/show_bug.cgi?id=22720#c1 [...] PowerPC64 ELFv1 ABI defines the address of a function as that of a function descriptor defined in .opd, a data section. [...] So upstream should relax the nm test a bit to consider "D" section also (at least on PPC64). As a side note since the Debian package provides a symbol file, I would simply comment out the test...
Re: Bug#886973: kronosnet: FTBFS on ppc64: knet_handle_new not found in binary lib
On Sun, Jan 14, 2018 at 4:47 PM, Aaron M. Ucko wrote: > Ferenc Wágner writes: > >> The test looks for the exported API function names in the text (T) >> section, but the ppc64 nm reports them in the data (D) section: >> >> $ nm -B -D libknet.so.1.0.0 >> A LIBKNET >> [...] >> 0003ec40 D knet_handle_new >> [...] >> >> Is this a known ppc64 peculiarity or a binutils bug? > > Good question. Porters? Does not make any sense to me: https://sourceware.org/bugzilla/show_bug.cgi?id=22720 Let see what upstream has to say
Re: [PATCH v2 4/5] Patch the CHRP boot script
Hi, On Tue, Nov 21, 2017 at 8:36 AM, Rick Thomas wrote: > > On Nov 20, 2017, at 10:51 PM, Frank Scheiner wrote: > >> Well, to be on the safe side, I think you need to use the latest versions of >> ofpath and ofpathname, hence running Debian Sid could be the easiest way to >> make sure this is the case. > > As both ofpath and ofpathname are shell scripts, would it be possible to just > install Sid on one of the machines and copy the scripts to each of the other > machines? > > Mostly all of these machines are currently running Jessie, and it would be a > lot of work to upgrade each to Sid, run the experiments, then downgrade back > to Jessie. > > Alternatively, could we make a Sid live (or rescue mode installer) CD that I > could boot to run the experiments? > > On a third hand, all of these machines have a Firewire port that they can > boot from. Can I install Sid on a single Firewire external drive and boot > each machine in turn from it… It would have to be two Firewire drives, one > for the G4 machines, and the other for the G5s. Would that work? One last comment, do not use `ofpathname` from package `powerpc-ibm-utils` since the package has been removed. The issue should be solved within the command lines tools provided by grub-ieee1275.
Re: [PATCH v2 4/5] Patch the CHRP boot script
Hi Ben, Sorry for the direct question, but I assumed you would know the answer. We are currently trying to replace yaboot with grub-ieee1275 in debian-installer, but are facing a very small issue, namely with OF path handling. It appears that on Apple hardware only `ofpath` from Yaboot returns the correct path. Are you using grub on any of your Apple hardware ? Thanks much for comments. See below for full context. On Tue, Nov 21, 2017 at 7:51 AM, Frank Scheiner wrote: > Hi Rick, > > On 11/21/2017 02:48 AM, Rick Thomas wrote: >> >> If you can tell me *exactly* what to do, and I don’t have to set up an >> installation environment to do it, I’ll be happy to test ofpathname vs >> ofpath vs devalias on my PowerPC test machine farm. > > > Well, to be on the safe side, I think you need to use the latest versions of > ofpath and ofpathname, hence running Debian Sid could be the easiest way to > make sure this is the case. > > You need to have a disk installed, because ofpath and IIC also ofpathname do > not or cannot translate non existing device aliases to OF paths. > > In general the commands I ran for the p5 520Q below should do. Assuming that > the output of ofpathname will always be wrong for Power Macs, it should be > sufficient to check only one partition. > > I think devalias does only save/return OF paths up to the disk level, but > not up to the partition level. But the disk level should already be > sufficient to detect differences to ofpath and/or ofpathname. > > You have to go to OF to run devalias, but with a glass console you won't be > able to copy the output. There are ways to interact with the OF via telnet > from another machine (see [1] and possibly [2]), but I haven't tried this > yet. > > [1]: > https://web.archive.org/web/20040202053614/http://developer.apple.com/technotes/tn/tn2004.html > > [2]: > https://web.archive.org/web/20040202060137/http://developer.apple.com:80/technotes/tn/tn2023.html > >> >> I have the following machines: >> Power Mac G5 11,2, >> Power Mac G5 7,2 (I think — it’s turned off right now) >> Mac mini G4 10,1 > > > I have these types available, too, "except" for the 7,3 which currently > won't start up correctly. > > Here's the output of ofpath and ofpathname for /dev/sda2 on the my Mac mini > (10,1): > ``` > root@mac-mini:~# ofpath /dev/sda2 > /pci@f400/ata-6@d/@0:2 > > root@mac-mini:~# ofpathname /dev/sda2 > /usr/sbin/ofpathname: line 812: warning: command substitution: ignored null > byte in input > /pci@f400/ata-6@d/scsi@0/sd@0,0 > ``` > > Also interesting, it looks like ofpathname cannot even give a "correct" > result for an IBM machine, at least not for my p5 520Q: > ``` > root@p5-520q:~# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:00 136.7G 0 disk > ├─sda1 8:10 7M 0 part > ├─sda2 8:20 131.1G 0 part > ├─sda3 8:30 1K 0 part > └─sda5 8:50 5.6G 0 part > sr0 11:01 1024M 0 rom > > root@p5-520q:~# ofpath /dev/sda1 > /pci@8002003/pci@2,4/pci1069,b166@1/scsi@0/@3:1 > > root@p5-520q:~# ofpathname /dev/sda1 > /pci@8002003/pci@2,4/pci1069,b166@1/scsi@0/sd@3,0 > > root@p5-520q:~# ofpath /dev/sda2 > /pci@8002003/pci@2,4/pci1069,b166@1/scsi@0/@3:2 > > root@p5-520q:~# ofpathname /dev/sda2 > /pci@8002003/pci@2,4/pci1069,b166@1/scsi@0/sd@3,0 > ``` > > Please notice that ofpathname returns the same result for two different > partitions. :-/ > >> Mac G4 3,4 >> Mac G4 dual core 3,6 > > > Results for these machines would be helpful. It should work to > install/upgrade to Debian Sid on one machine only and just move the disk to > the other machine later on for testing. > > Cheers, > Frank
Re: [PATCH v2 4/5] Patch the CHRP boot script
Adrian, I actually discover the issue only today, and was a bit surprised too. I think this is related to the powerpc downgrade to port, and was part of the large packages autoremoval done at the time (ppc64el was added only in 1.2.19-1). But I think we can revive this package simply because it is needed on ppc64el. powerpc-ibm-utils packagers, would you consider fixing the package so that it transition back to testing again or should I report an explicit bug ? Thanks, On Tue, Nov 21, 2017 at 10:13 AM, John Paul Adrian Glaubitz wrote: > Was the removal of powerpc-ibm-utils coordinated somewhere? I‘m asking > because it’s still in the package list of debian-installer for > powerpc/ppc64/ppc64el in debian-cd [1]. > > I can’t seem to find the removal bug report. > > Adrian > >> [1] >> https://anonscm.debian.org/cgit/debian-cd/debian-cd.git/tree/tools/generate_di+k_list > > On Nov 21, 2017, at 10:02 AM, Mathieu Malaterre wrote: > > Hi, > > On Tue, Nov 21, 2017 at 8:36 AM, Rick Thomas wrote: > > > On Nov 20, 2017, at 10:51 PM, Frank Scheiner wrote: > > > Well, to be on the safe side, I think you need to use the latest versions of > ofpath and ofpathname, hence running Debian Sid could be the easiest way to > make sure this is the case. > > > As both ofpath and ofpathname are shell scripts, would it be possible to > just install Sid on one of the machines and copy the scripts to each of the > other machines? > > > Mostly all of these machines are currently running Jessie, and it would be a > lot of work to upgrade each to Sid, run the experiments, then downgrade back > to Jessie. > > > Alternatively, could we make a Sid live (or rescue mode installer) CD that I > could boot to run the experiments? > > > On a third hand, all of these machines have a Firewire port that they can > boot from. Can I install Sid on a single Firewire external drive and boot > each machine in turn from it… It would have to be two Firewire drives, one > for the G4 machines, and the other for the G5s. Would that work? > > > One last comment, do not use `ofpathname` from package > `powerpc-ibm-utils` since the package has been removed. The issue > should be solved within the command lines tools provided by > grub-ieee1275.
Re: [PATCH v2 4/5] Patch the CHRP boot script
Frank, On Sat, Nov 18, 2017 at 2:01 PM, Frank Scheiner wrote: > Hi Mathieu, > > On 11/18/2017 01:17 PM, Mathieu Malaterre wrote: >> >> Hi Frank, >> >> On Sat, Nov 18, 2017 at 11:52 AM, Frank Scheiner >> wrote: >>> >>> This patch requires the ofpath tool which is part of the yaboot package, >>> as both ofpathname (part of powerpc-ibm-utils package) and >>> grub-ofpathname (not available packaged but part of the GRUB source >>> code) do not translate a given device node into a working OF path on >>> type 11,2 and 7,3 G5 Power Macs. >> >> >> Sorry if this sound silly, but are you sure you want to use a tool >> from the yaboot package, while the original intent is to get rid of >> the yaboot package ? > > > I originally didn't knew that the ofpath tool was part of the yaboot > package. It was available in-target when starting the GRUB installation in > expert mode (i.e. despite skipping the yaboot installation) hence I assumed > it might be part of some DEB package installed by default on ppc64 and in > addition it also was the only device-node-to-OF-path-translation-tool that > worked "correctly" for the tested G5 Power Macs, so I just used it. > > E.g. for /dev/sda ofpathname returned > "/ht@0,f200/pci@9/k2-sata-root@c/scsi@0/sd@0,0" while devalias in OF > says it's "/ht/pci@9/k2-sata-root/k2-sata@0/disk@0". > > And for /dev/sda2: > > * I unfortunately don't have a result for ofpathname currently > > * grub-ofpathname returned "/ht@0,f200/pci@9/k2-sata-root@c/disk@0:b" > which didn't work > > * ofpath returned "/ht@0,f200/pci@9/k2-sata-root@c/@0/@0:2" which worked > > It's of course not ideal, and we should maybe try to fix either ofpathname > or grub-ofpathname or include ofpath (which btw is just a shell script) in > another package (e.g. grub-installer already has an additional tool for PReP > boot devices or integration in powerpc-ibm-utils (for ppc64/newworld alone) > or powerpc-utils (for both powerpc/ and ppc64/newworld). > > Up until now yaboot was the "only" boot loader for powerpc and ppc64, so it > made some sense to include ofpath there (also because it came from the same > developer). With an additional boot loader, it would IMHO make more sense to > include ofpath in another DEB package to be able to share it's > functionality. Well that's surprising. Thanks for the detailed explanation. I've filled #882076 and forwarded upstream. I fail to understand how people would install grub on ppc64 if grub-ofpathname does not return the correct path. -M
Re: [PATCH v2 4/5] Patch the CHRP boot script
Hi Frank, On Sat, Nov 18, 2017 at 11:52 AM, Frank Scheiner wrote: > This patch requires the ofpath tool which is part of the yaboot package, > as both ofpathname (part of powerpc-ibm-utils package) and > grub-ofpathname (not available packaged but part of the GRUB source > code) do not translate a given device node into a working OF path on > type 11,2 and 7,3 G5 Power Macs. Sorry if this sound silly, but are you sure you want to use a tool from the yaboot package, while the original intent is to get rid of the yaboot package ? Thanks for comments
Re: [PATCH v2 1/2] Fix formatting for subarchitecture matching for powerpc, and ppc64
On Fri, Nov 17, 2017 at 12:04 AM, John Paul Adrian Glaubitz wrote: > On 11/16/2017 08:00 AM, Frank Scheiner wrote: >> Not sure if the commit message gets through correctly, Thunderbird >> makes a "," out of the newline before " and ppc64". > > Try setting up a local MTA for use with "git-email", see: > >> https://wiki.debian.org/GmailAndExim4 In case that help, use git-send-email directly: https://git-scm.com/docs/git-send-email#_use_gmail_as_the_smtp_server HTH
Hardware donation / Apple G4
Hi there, I can hardly find some time for toying with these anymore, so is anyone interested in my ppc32 hardware: * Mac Mini G4 * Power Mac Gigabit Ethernet I can bring them to Toulouse MiniDebConf 2017, as paying for shipping for such old machines do not make much sense. -M
Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64
On Fri, Sep 29, 2017 at 12:40 PM, Gabriel Paubert wrote: > On Fri, Sep 29, 2017 at 12:10:20PM +0200, Christian Zigotzky wrote: >> On 29 September 2017 at 11:42AM, Gabriel Paubert wrote: >> > Hi Christian, >> > >> > The right mouse button, i.e., the one that pops up a menu. >> > >> I understand. Yes, you're right. There is a problem. I can open the menu but >> selecting a menu point doesn't work. Thanks for the hint. > > Ok, in my case it is way more drastic: SIGSEGV causing > InstantProcessDeath(TM). > > There is a trace in the kernel log, with a blurb about "invalid signal > frame" and not much more. > > This is with v4.13/v4.14 kernels. Could you please report the bug with the content of syslog. Thanks
Re: PS3?
Hi Simon, On Fri, Sep 22, 2017 at 4:32 PM, Simon Richter wrote: > Hi, > > I'm trying to get a PS3 to boot with the powerpc64 kernel in stretch, > but had no luck so far. kexec from the boot menu happens, then the > screen goes blank and stays that way. I have a 3.5 kernel that boots and > works fine. > > Does anyone have a working setup with a standard kernel? I can't remember exactly the linux kernel version number, but that smell just like the CONFIG_PPC_64K_PAGES=y change. I would try rebuild the linux kernel with CONFIG_PPC_64K_PAGES=n and see if that solve your booting issue. Otherwise git-bisect or post to linuxppc-...@ozlabs.org :) -M
Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
Hi Adrian, On Thu, Sep 21, 2017 at 2:21 PM, John Paul Adrian Glaubitz wrote: > Hi! > > I would help with this transition to use GRUB on powerpc as well > as on ppc64 which we are now providing unofficial installation > for in Debian Ports [1]. Missing link '1'. > I do have commit access to debian-installer and its components > as well as access to an IBM POWER7 instance which can be used > to test both powerpc as well as ppc64 installation images. > > I would like to get rid of yaboot because it is no longer maintained > upstream and switching to GRUB also helps reduce the maintenance > burden in debian-installer. > > What we need are people who are willing to extensively test d-i > images with GRUB on powerpc and ppc64 and report back. Also, I'm > not yet sure whether I have understood how exactly GRUB is properly > configured and used on powerpc and ppc64. Sure ! I still have a PowerMac G4 & Mac Mini to test. Both work booting d-i from a USB key. Thanks for your work -M
