Re: Xorg fails on ATI after update (mmio aperture)
On Fri, Mar 24, 2017 at 02:43:56PM +0100, Riccardo Mottola wrote: > Hi, > > John Paul Adrian Glaubitz wrote: > > Quoting: > > > > > >If this option is disabled, you allow userspace (root) access to all > > > >io-memory regardless of whether a driver is actively using that range. > > > >Accidental access to this is obviously disastrous, but specific access > > > >can be used by people debugging kernel drivers. > > Allowing this configuration in the default kernel sounds like a very bad > > idea and I don't think Debian's kernel maintainers will agree to change > > this setting. > > > > I'm afraid you will have to keep building your kernel from source. > If it is a security options which has a serious impact on user laptop or > desktop machines. We are saying that most probably default instal without a > kernel rebuild is without X for many users of cards with legacy drivers. > On a laptop I have less security concerns than on a server and run dangerous > applications like X11 and a browser like firefox! > > Can it be kept on on PPC 32bit only? Especially since we know it has a > larger legacy hardware base than others. Probably on 64bit nobody has such > video cards, I imagine I am not the only one running Xorg legacy. > > Compiling a kernel is not really difficult but quite time consuming. > > I still think a bug should be opened thus - where should I do it, now that > we aren't a release arch anymore? > > Riccardo Can you boot the default Debian kernel (the one with CONFIG_IO_STRICT_DEVMEM=y) with the following boot parameter and see if it works for you? iomem=relaxed If that works, you are open to some "security" issues, but no need to build a new kernel. Maybe adding that option by default on a system with such a card would be a nice-to-have on the Debian Installer, but that's it. Cascardo.
Re: POWER6 not seeing memory above 2Gb
On Wed, Mar 22, 2017 at 09:07:49PM -0400, Adam Stouffer wrote: > Hello all, I'm new to the list and just installed jessie on my IBM > 8203-E4A box. It's a dual core 4.2Ghz with 16Gb of memory. > > But anyhow like the subject says the kernel is only reporting 2Gb of > available memory. I tried appending "mem=16G" as a boot argument but > no change. I assume this is an LPAR. How is it configured? Do you have an HMC or IVM connected to it? Cascardo. > > Here is the output from dmesg with kernel 3.16.0 > > [0.00] physicalMemorySize= 0x8000 > [0.00] Node 0 Memory: 0x0-0x8000 > [0.00] Early memory node ranges > [0.00] Memory: 1899264K/2097152K available (7360K kernel code, > 1792K rwdata, 1840K rodata, 960K init, 2071K bss, 197888K reserved) > [0.023173] Initializing cgroup subsys memory > [1.036652] Freeing initrd memory: 16384K (c348 - > c448) > [1.242857] Freeing unused kernel memory: 960K (c091 - > c0a0) > > Any ideas? Thanks. >
Re: apt http backend hangs in LXC container on ppc64el
On January 22, 2017 2:34:09 PM GMT-02:00, Antonio Terceiro
wrote:
>Hi,
>
>[sorry for the large cross-post, but I don't really know where the
>problem could be; please keep me in Cc: since I'm not debian-powerpc@
>not on deity@]
>
>The Campinas IBM team has generously made a few VMs available to run
>the
>Debian CI (https://ci.debian.net) on ppc64el. I am having some trouble
>to get it working properly due to an issue with LXC. I have done this
>countless times on amd64 and arm64, and never had any issues like this
>one, so that is why I suspect it's ppc64el-specific.
>
>`apt update` inside a LXC container hangs forever like this:
>
># apt update
>0% [Waiting for headers]^C
>
>Running `apt update` under strace shows this infinite loop at the end:
>
>_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=50}) = 0 (Timeout)
>rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
>rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>0% [Waiting for headers]) = 25aders]", 25
>_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=50}) = 0 (Timeout)
>rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
>rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>0% [Waiting for headers]) = 25aders]", 25
>_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=50}) = 0 (Timeout)
>rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
>rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>0% [Waiting for headers]) = 25aders]", 25
>_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=50}) = 0 (Timeout)
>rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
>rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>0% [Waiting for headers]) = 25aders]", 25
>_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=50}) = 0 (Timeout)
>rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
>rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>0% [Waiting for headers]) = 25aders]", 25
>_newselect(6, [5], [], NULL, {tv_sec=0, tv_usec=50}^Cstrace:
>Process 127 detached
>
>
>The host is a ppc64el VM running jessie. I tried LXC guests running
>both
>jessie and sid, and I get the same result on both.
>
>I have also tried all of the following:
>
>- running `apt update` from the host, when chroot'ed to the container
> rootfs; just works normally
>
>- upgrading the kernel on the host to the latest one in
>jessie-backports
> (4.8); did not help
>
>- upgrading LXC to the latest version from jessie-backports (2.0), and
> starting the container with it; did not help
What is file descriptor 5? I would assume it's the http connection. Does
wget/curl work fine inside the container? How is the network behavior in
general? Are you using veth plus NAT? What if you set a namespace with unshare
-n, setup a veth pair and set the same network setup? Does it work?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Using 4KiB page size by default on buildds
On Mon, Nov 14, 2016 at 09:17:56AM +0100, Mathieu Malaterre wrote: > Hi, > > On Sat, Nov 12, 2016 at 12:02 PM, Thadeu Lima de Souza Cascardo > wrote: > > Hi, > > > > While recently investigating the mariadb bug, I found out the culprit is > > in fact jemalloc. This library assumes the system page size is the one > > that it found when building it. The version in Jessie was built on a > > 4KiB-page size system. So, when using it on a 64KiB-page size system, we > > might see crashes. That's why building mariadb for Jessie on partch > > fails. mariadb uses jemalloc and during make check, a crash induces a > > deadlock. > > Nice ! added usertags 'powerpc': > > https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=powerpc&user=debian-powerpc%40lists.debian.org Thanks. > > > To give some context, I used to work fixing drivers for IBM Power > > Systems, which used 64KiB-page size kernels on most situations. And we > > found many issues due to people assuming 4KiB page sizes. > > > > Even though we could debate about the value of using any page size > > different from 4KiB, the fact is that there are systems out there using > > different page sizes, and even Debian ships with some kernels and uses > > it on its buildds. > > > > I, for one, believe we should support such different page sizes on the > > entire archive. This means fixing jemalloc, device drivers, other memory > > allocators and any other software that might break or work suboptimally > > on such systems. > > > > However, the current state of things has meant that powerpc has been > > dropped from squeeze and while I would agree that jemalloc might have > > been an exception, who knows what else might break because of such > > differences? We might look for things like page.*size/i in the archive, > > but upstream fixes might not always be an easy and quick path. Consider > > the jemalloc case, where upstream has diverged a lot from the current > > version in Debian, and I am not sure how they might take a fix for the > > version in Jessie. > > > > So, my proposal here is that we decide on a default page size for > > buildds and kernels shipped with Debian, give the option for the > > different page size for other users, but state there might be breakages > > when using it. That doesn't mean it's not supported, and shipping it is > > a way of giving the chance for it to be tested. It's not broken either, > > most things should work, but some things here and there are broken, and > > we could even have a list of known issues (that we want to fix > > eventually, though in future releases). > > > > Given that most users I see on this list are using 10+ year old > > hardware, which likely have low memory capacity and some support only > > 32-bit kernels, I'd say we default to 4KiB page size, and that's where > > most software will work, while 64KiB page size will impact much more > > broken software. > > > > Next steps here are getting a 64-bit kernel built with 4KiB page size > > available in the archives, and using those kernels on those buildds that > > currently run a 64-bit kernel. > > The old ppc64 was this way, see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826796 > Yeah, when I talked about drivers, I was thinking about nouveau, as I have read before on this list that it was a problem on 64KiB page size kernels. > > What are the thoughts of the Debian powerpc community? > > As you know 'powerpc' has been removed from the release archs. So > instead I would suggest that you get in touch with reproducible people > instead. Ideally the autopkg test should (could?) be run on a kernel > with different page size. > Good point bringing up that the package would produce different binaries, hence the reproducible build folks might take an interest. But I don't think we should it *instead*. We should it *too*. powerpc has been removed from Stretch. It may be included in Stretch+1, or at least I would expect ports.d.o to pick it up. Does it make sense? > But I fail to see how you can address something like: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819711 > > The page size is hardcoded (at built time) to 64K, so that it passes > on both partch.d.o (64K page) as well as my old G4 (4K page)... You mean that it will produce the same binaries no matter the build system? But does it run fine on 4KiB page size systems? I agree scenarios where the software builds assuming a 64KiB page size because it's PPC will not be handled by my proposal. I still think such software is broken
Re: Using 4KiB page size by default on buildds
On Mon, Nov 14, 2016 at 12:23:17AM +0200, Aaro Koskinen wrote: > On Sat, Nov 12, 2016 at 09:02:37AM -0200, Thadeu Lima de Souza Cascardo wrote: > > So, my proposal here is that we decide on a default page size for > > buildds and kernels shipped with Debian, give the option for the > > different page size for other users, but state there might be breakages > > when using it. > > If a program needs to know about page size, it should query/adopt to it > runtime, not buildtime. > > A. Sure, that's the long term plan: fixing all software. In the case of jemalloc, we have identified there is a problem and can start working on fixing it right away. However, what about all the other hidden bugs we haven't identified yet? Even in the case of jemalloc, a quick and dirty fix on Debian sid is easy. A proper fix acceptable upstream for the old version present in Jessie that won't impact that much all the other architectures is another thing. My point is: I agree with you that we should properly fix the broken software, I just think that we should have a change now that might prevent bugs like this from impacting users in the meanwhile. Cascardo. signature.asc Description: PGP signature
Using 4KiB page size by default on buildds
Hi, While recently investigating the mariadb bug, I found out the culprit is in fact jemalloc. This library assumes the system page size is the one that it found when building it. The version in Jessie was built on a 4KiB-page size system. So, when using it on a 64KiB-page size system, we might see crashes. That's why building mariadb for Jessie on partch fails. mariadb uses jemalloc and during make check, a crash induces a deadlock. To give some context, I used to work fixing drivers for IBM Power Systems, which used 64KiB-page size kernels on most situations. And we found many issues due to people assuming 4KiB page sizes. Even though we could debate about the value of using any page size different from 4KiB, the fact is that there are systems out there using different page sizes, and even Debian ships with some kernels and uses it on its buildds. I, for one, believe we should support such different page sizes on the entire archive. This means fixing jemalloc, device drivers, other memory allocators and any other software that might break or work suboptimally on such systems. However, the current state of things has meant that powerpc has been dropped from squeeze and while I would agree that jemalloc might have been an exception, who knows what else might break because of such differences? We might look for things like page.*size/i in the archive, but upstream fixes might not always be an easy and quick path. Consider the jemalloc case, where upstream has diverged a lot from the current version in Debian, and I am not sure how they might take a fix for the version in Jessie. So, my proposal here is that we decide on a default page size for buildds and kernels shipped with Debian, give the option for the different page size for other users, but state there might be breakages when using it. That doesn't mean it's not supported, and shipping it is a way of giving the chance for it to be tested. It's not broken either, most things should work, but some things here and there are broken, and we could even have a list of known issues (that we want to fix eventually, though in future releases). Given that most users I see on this list are using 10+ year old hardware, which likely have low memory capacity and some support only 32-bit kernels, I'd say we default to 4KiB page size, and that's where most software will work, while 64KiB page size will impact much more broken software. Next steps here are getting a 64-bit kernel built with 4KiB page size available in the archives, and using those kernels on those buildds that currently run a 64-bit kernel. What are the thoughts of the Debian powerpc community? Regards. Cascardo. signature.asc Description: PGP signature
Re: Release Architectures for Debian 9 'Stretch'
On Fri, Nov 04, 2016 at 07:16:00PM +0100, Christoph Biedl wrote: > luigi burdo wrote... > > > Im thinking to start a petition about ... "dont kill debian penguins on > > powerpc" > > Don't. The release team folks are not politicians who get convinced by > a lot of noise. Unless I completely misunderstand their position, the > only question that matters is: Can we (as the Debian project) be sure > powerpc will have backing until EOL stretch (somewhen 2020)? > > The right answer is to create trust for this, not whining around. > > The best thing that could happen right now was a company approaching > Debian, emphasizing the importance of the powerpc architecture for > their business, and declaring they will hire two Debian Developers who > will contribute to the project as part of their job. But let's not > hope for a miracle. > > A remaining idea was was to appeal and ask for a grace peroid. This > appeal requires substantiation: Several people would have to sign > this, people who are well-established contributors to the Debian > project so it is certain they can do the job and their enthusiasm > will last (I wouldn't expect I would qualify for that). And during > that grace period, some two or three weeks, we, the powerpc people, > show significant progress by fixing all the open issues. The fact > #832931 did not get resolved in due course was one of things that hit > the reputation quite badly. I just got a G4 machine last week and did a succesful build of mariadb. I sent an update to the bug report and will try to do the build on a porter box. Cascardo. > > Even if the appeal is unsuccessful on any stage, a clean backlog will > certainly help to have jessie-LTS for powerpc, and re-entry as well. > So please start cracking. > > Christoph
Re: Release Architectures for Debian 9 'Stretch'
On Mon, Oct 31, 2016 at 04:34:15PM -0700, Herminio Hernandez, Jr. wrote: > I have they in the past kept and architecture that was dropped as a release > arch? GNU/kFreeBSD was released as a technology preview for squeeze, kept as TP in wheezy, then not made part of the jessie. I can't find it in testing, but I see it in sid. So, it doesn't have any chance of being part of a new release, as far as I understand, but it's still kept in the archive. Cascardo. signature.asc Description: PGP signature
Re: Release Architectures for Debian 9 'Stretch'
On Mon, Oct 31, 2016 at 11:58:31PM +0100, Riccardo Mottola wrote: > Hi, > > > On 31/10/2016 18:44, Lennart Sorensen wrote: > > I am not a DD, or a DM, but I have certainly helped fix problems for > > powerpc, including in language runtimes for languages I don't use. > > Unfortunately it seems the upstream for most things don't care much for > > anything other than x86 and arm these days which makes it harder for > > other architectures to stay working. > > since I am "upstream" for certain software I assure that I do care. Actually > I am one of the persons who tested GNUstep stuff on PPC. I know of other > people happily using GNUstep on PPC. To do that, I need a usable operating > system of course... up to know it was debian. What could it be int he > future? > Perhaps not all upstream counts and we don't even need al possible packages > on PPC. But it is still possible today to have a ncie usable desktop setup. > > This Debian decision will make a dim future for PowerPC developers, not just > users: a chicken-egg problem. > > Riccardo > Well, as I understand, the release team decided there is not going to be a Debian Stretch release for PowerPC. We can still ask the ftp-masters and DSA to keep powerpc for testing and sid, and we will have to do our own release. It's harder without all the infrastructure and work the release team puts into a release. But it's still something we could do. In the worst case, we can try to publish some install media and use the debian-ports infrastructure that is going to use a rolling release, based on sid. The only powerpc I had until now was a Nintendo Wii, and though there are patches around that would make D-I usable, I was still playing with some other hacks before I could try to push for them in Debian proper, and it was not on my top priority. Too bad I couldn't foresee that if I got much more involved long before, I could say to the release team I was already doing porter work. But since I was not, it looked like any volunteering from my part would have made no difference at all. However, I just ordered and old iBook G4, and I hope I can at least test D-I images I could maybe help prepare. Would that help you keep testing your code on PPC? :-) By the way, thanks a lot for helping all these years with the ppc port. I have watched from a distance, which was a mistake. Hope I can help with keeping up the port alive somehow. Best regards. Cascardo. signature.asc Description: PGP signature
Re: retrieving passwords
On Sun, Oct 30, 2016 at 09:54:33AM +0100, Christophe De Natale wrote: > Le 29/10/2016 à 22:07, Klaus Becker a écrit : > > On samedi 29 octobre 2016 21:11:25 CEST Klaus Becker wrote: > > > Hi, > > > > > > I installed Debian 8 on an Ibook G4 but I forgot passwords. > > > > > > I know how to create a new password with grub, but not with yaboot. Is > > > there > > > any way or do I have to reinstall the system? > > > > > > Is it possible while using the installation CD at > > > http://cdimage.debian.org/ > > > debian-cd/8.6.0/powerpc/iso-cd/debian-8.6.0-powerpc-netinst.iso? > > > > > > I installed Debian there is a long time, I did not use the macbook and I > > > forgot a lot. Will the macbook boot on the CD or is there any manipulation > > > necessary? > > > > > > nice we > > > > > > Klaus > > Meanwhile I downloaded the above image and I tried to boot on it by: > > > > - alt-pomme-o-f > > > > - boot cd:,\install\yaboot > > > > I get the message " Can't open device or file". > > > > Klaus > > > Hi Klaus, > > Did you give a try by pushing "c" key to boot on the cd ? > Otherwise with "option" key (alt) in order to display all booting capable > media. > > Regards, > > Christophe > And the install media should have an option to mount the installed system and execute a rescue shell, where you can chroot to your installed system and then change your password, so no need to reinstall. Cascardo.
Re: Problem with gem network card
On Fri, Oct 14, 2016 at 10:24:41AM -0400, Lennart Sorensen wrote: > On Fri, Oct 14, 2016 at 08:25:43AM +0200, Mathieu Malaterre wrote: > > On Fri, Oct 14, 2016 at 12:14 AM, Christian Groessler > > > After > > > > > > $ ip link set eth0 down > > > $ ip link set eth0 up > > > > > > it's working again. > > > > > > But I have to be physically at the machine for this, so it's not a real > > > solution. > > > > You can put that in a script, or use screen: > > > > http://serverfault.com/questions/278838/restarting-network-through-ssh > > You can't ssh if you have no networking. Screen only helps if you have > networking working but you want to restart networking remotely. > > -- > Len Sorensen > 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. Cascardo. signature.asc Description: PGP signature
Re: Problem with gem network card
On Tue, Oct 11, 2016 at 07:51:30PM +0200, Christian Groessler wrote: > Hi, > > on my Mac G5 I see loss of network connectivity when doing big downloads or > uploads. > > The machine cannot be pinged anymore then and also cannot ping out. > > When it's happening I see the following messages: > > Oct 11 10:45:13 g5 kernel: [ 430.477967] gem 0001:04:0f.0 eth0: RX MAC fifo > overflow smac[03810400] > Oct 11 10:45:17 g5 kernel: [ 434.141957] gem 0001:04:0f.0 eth0: RX MAC fifo > overflow smac[03810400] > Does setting the interface down, then up works? Like ifdown eth0; ifup eth0. Or ip link set eth0 down; ip link set eth0 up, and verifying the address and route are restablished (in case you are using NetworkManager, for example). If it doesn't, does reloading the module work? rmmod sungem; modprobe sungem. Cascardo. > > Previous messages, for information: > > ... > Oct 11 10:38:36 g5 kernel: [1.684536] gem 0001:04:0f.0 eth0: Sun GEM > (PCI) 10/100/1000BaseT Ethernet 00:0d:93:4c:f5:b0 > ... > Oct 11 10:38:37 g5 kernel: [ 34.578556] gem 0001:04:0f.0 eth0: Found > BCM5421-K2 PHY > ... > Oct 11 10:38:40 g5 kernel: [ 36.994117] gem 0001:04:0f.0 eth0: Link is up > at 100 Mbps, half-duplex > Oct 11 10:38:40 g5 kernel: [ 36.994246] gem 0001:04:0f.0 eth0: Pause is > disabled > ... > > > > > $ lspci > :f0:0b.0 Host bridge: Apple Inc. U3H AGP Bridge > :f0:10.0 VGA compatible controller: Advanced Micro Devices, Inc. > [AMD/ATI] RV360 [Radeon 9600/X1050 Series] > 0001:00:00.0 Host bridge: Apple Inc. U3 HT Bridge > 0001:00:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] AMD-8131 PCI-X > Bridge (rev 12) > 0001:00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] AMD-8131 PCI-X > Bridge (rev 12) > 0001:00:03.0 PCI bridge: Apple Inc. K2 HT-PCI Bridge > 0001:00:04.0 PCI bridge: Apple Inc. K2 HT-PCI Bridge > 0001:00:05.0 PCI bridge: Apple Inc. K2 HT-PCI Bridge > 0001:00:06.0 PCI bridge: Apple Inc. K2 HT-PCI Bridge > 0001:00:07.0 PCI bridge: Apple Inc. K2 HT-PCI Bridge > 0001:01:07.0 Unassigned class [ff00]: Apple Inc. K2 KeyLargo Mac/IO (rev 60) > 0001:01:08.0 USB controller: Apple Inc. K2 KeyLargo USB > 0001:01:09.0 USB controller: Apple Inc. K2 KeyLargo USB > 0001:02:01.0 Network controller: Broadcom Corporation BCM4306 802.11b/g > Wireless LAN Controller (rev 03) > 0001:02:0b.0 USB controller: NEC Corporation OHCI USB Controller (rev 43) > 0001:02:0b.1 USB controller: NEC Corporation OHCI USB Controller (rev 43) > 0001:02:0b.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller > (rev 04) > 0001:03:0d.0 Unassigned class [ff00]: Apple Inc. K2 ATA/100 > 0001:03:0e.0 FireWire (IEEE 1394): Apple Inc. K2 FireWire > 0001:04:0f.0 Ethernet controller: Apple Inc. K2 GMAC (Sun GEM) > 0001:05:0c.0 IDE interface: Broadcom K2 SATA > $ uname -a > Linux g5 3.16.0-4-powerpc64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) > ppc64 GNU/Linux > $ cat /proc/version > Linux version 3.16.0-4-powerpc64 (debian-ker...@lists.debian.org) (gcc > version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) > $ > > > Any ideas? > > regards, > chris >
Re: Debian PowerPC and PowerPC Notebook.
On Fri, Dec 04, 2015 at 04:05:18PM -0500, Lennart Sorensen wrote: > On Fri, Dec 04, 2015 at 08:55:12PM +, Fadi Osman wrote: > > Hello Len, > > I am checking with the others before answering you questions. > > But I remember one of the reasons is that we were worried that powerpc > > would be eventually dropped in favor of ppc64 and ppc64el... > > Well I see very little happening on ppc64 (ppc64el is doing fine), and > powerpc is doing fine. There are a lot of 32 bit powerpc systems still > out there and as I was asking, I doubt ppc64 in general is actually an > improvement over powerpc for most userspace code. > > ppc64el on the other hand is targetting very large machines running very > large data talking to little endian accalarator cards, so it makes sense > to go all 64bit (and little endian there), while I just don't see ppc64 > making sense in the same way. > ppc64el also had a lot of improvements in ABI, which they could make, since they didn't have to keep compatibility anyway. Cascardo. > -- > Len Sorensen > signature.asc Description: PGP signature
Re: Debian PowerPC and PowerPC Notebook.
On Fri, Dec 04, 2015 at 10:26:47AM -0500, Lennart Sorensen wrote: > On Fri, Dec 04, 2015 at 06:09:28AM +, Fadi Osman wrote: > > Hello, > > I'm contacting you on the behalf of the PowerPC Notebook project > > team.(http://www.powerpc-notebook.org) > > As you might already know, we are a group of volunteers collaborating > > towards building a notebook around the Freescale e6500 core (ALTIVEC and > > PowerIsa 2.07).We are aiming at making the hardware FSF compliant (or at > > least Open). > > We will be using Debian ppc64 as our Operating System. > > > > Is it possible for us to join you, essentially for the ppc64 port? > > (development/bug fixing/testing...) > > > > We would eventually also like to run ppc64el (but from my understanding, > > that would be without ALTIVEC). > > Please contact us if you think there are subjects/packages we can work on. > > > > Thanks a lot,and hoping to be of help.The PowerPC Notebook project team. > > > > (NOTE: Some of us already have 32bit and 64bit PowerPC hardware running > > Debian.) > > I am curious why you want to run ppc64 rather than powerpc? What benefit > is there to going 64bit for everything rather than just a few select > things (like a database perhaps that needs the memory space)? After all > doubling the pointer size increases cache usage and memory bandwidth > usage, and on most architectures does not gain you anything except a > larger address space (x8a_646 being a huge exception since it doubled the > register count and dropped x87 and various other good things). > > -- > Len Sorensen > To access more physical memory? But sure, they could run a 64-bit kernel with a 32-bit userspace. But since this is going to be used as a laptop, I am thinking: 'Browsers!'. Cascardo. signature.asc Description: PGP signature
Re: Help with the arm64 and ppc64el installation-guides needed
On Sun, Apr 12, 2015 at 09:43:07PM -0400, Lennart Sorensen wrote: > On Sun, Apr 12, 2015 at 08:45:50PM -0300, Thadeu Lima de Souza Cascardo wrote: > > When it comes to IBM latest servers, that are three options for > > platforms: OPAL (powernv in Linux), as PowerKVM guest, and PowerVM LPAR > > (both pseries platform in Linux). > > > > OPAL has petitboot built-in, PowerKVM uses SLOF and PowerVM uses IBM > > Open Firmware. The three are capable of booting from optical media, USB, > > and netboot. With the exception of KVM guests, when a supported > > graphical card is used, graphical installation should be an option as > > well. For KVM guests, there is offb, which should work with VNC. Should > > we enable graphical installation in the media? Or is just netboot images > > missing graphical support on d-i? > > So does this mean that PowerVM LPAR is the same as running on the bare > metal (which is the only way I have run debian on IBM pSeries systems, > specifically a p520 power6+ and a p710 power7). Certainly openfirmware > booting with grub2 is the only method I have ever used. IBM support > people sure do seem confused when they hear you have no HMC or VM or > anything else on your pSeries. Just Debian on the bare metal. > Well, bare metal has been mistakenly used to describe what I would call dedicated partition of single partition mode. People may call it bare metal, because there is no virtualized IO (in fact, there is the console), and CPU and memory resources are not shared with other partitions. But there is still a Hypervisor under the OS. It's still a PowerVM LPAR, and boot capabilities still apply as though you were sharing the server with other partitions. Hope that clarifies. Cascardo. > -- > Len Sorensen signature.asc Description: Digital signature
Re: Help with the arm64 and ppc64el installation-guides needed
On Sun, Apr 12, 2015 at 11:06:08PM +0200, Samuel Thibault wrote: > Aurelien Jarno, le Sun 12 Apr 2015 22:08:44 +0200, a écrit : > > On 2015-04-12 20:22, Samuel Thibault wrote: > > > Since petitboot runs inside a running linux kernel, that only shifts the > > > problem of booting that linux kernel :) > > > > Petitboot is the default bootloader on this machine when configured to > > run Linux. It's the interface the user see when powering up the machine. > > Uh. Interesting :D > > Thanks, > Samuel Sorry for jumping in. I would like the chance to complement and clarify some things about ppc64el platform. As Aurelien pointed out, when used in OPAL mode, the system will boot a system running petitboot, which is capable of netboot, booting from disk, and install media. So, will it boot from USB media? Yes. When it comes to IBM latest servers, that are three options for platforms: OPAL (powernv in Linux), as PowerKVM guest, and PowerVM LPAR (both pseries platform in Linux). OPAL has petitboot built-in, PowerKVM uses SLOF and PowerVM uses IBM Open Firmware. The three are capable of booting from optical media, USB, and netboot. With the exception of KVM guests, when a supported graphical card is used, graphical installation should be an option as well. For KVM guests, there is offb, which should work with VNC. Should we enable graphical installation in the media? Or is just netboot images missing graphical support on d-i? One caveat: I may be mistaken on the current state of support for USB and netboot on SLOF. But considering it's a KVM guest using qemu, there is much more flexibility, if things are downloaded on the host. I would say that is one of the things that we should document on the installation-guide. Is that right? As for wireless network adapters, the systems don't ship with any, and I haven't heard of any testing with any drivers. Nonetheless, those systems support PCI 3.0 and USB 3.0, so there is no reason those adapters shouldn't work, giving enough testing and fixes. But I would leave that out. As for other systems supporting ppc64el, OpenPower members have been releasing new systems using Power8 and supporting little-endian from the start. As already mentioned, older IBM systems could be capable as well, but I wouldn't say that is supported. As for chips from Freescale, I can't tell much. For 64-bit capable old Macs, I suppose firmware could be a problem. For those systems, adopting ppc64 (BE) would offer an option. Why 64-bit? Well, the same answer applies for all platforms. Address space. I suppose some people cannot even run web browsers these days without 64-bit :-). Of course, that has some disadvantages, like the memory footprint because of pointers, that x32 tries to address. Regards. Cascardo. signature.asc Description: Digital signature
Re: Help with the arm64 and ppc64el installation-guides needed
On Sat, Apr 11, 2015 at 12:24:58AM +0200, Samuel Thibault wrote: > Hello, > > Breno Leitao, le Fri 10 Apr 2015 17:44:01 -0300, a écrit : > > On 04/09/2015 01:13 PM, Karsten Merker wrote:> Hello everybody, > > > the release date for Jessie is near, but the installation-guide > > > does not seem to contain any arm64/ppc64el-specific information > > > yet. > > We have created this installation guide, but unfortunatelly it was not > > integrated yet. > > > > It is still on my github repository. Can you import it? > > Uh. I requested this very kind of information in september and > november, why wasn't this work (done in december) ever submitted > before? We can integrate it in the installation manual, but it will > most probably not get translated for the release... > > I'll however be unable to integrate things like "blablabla" (sic)... > > Samuel > Also, most of the content is oriented towards updating the machine software itself, not Debian. How does one install Debian on bare-metal, using petitboot? How does one install Debian as a KVM guest with SLOF? How about Debian on a LPAR on PowerVM? Which systems would support it in that mode? Cascardo. signature.asc Description: Digital signature
Re: Impact of [linux-any] when pbuilding packages on powerpc for squeeze
Hi, e20100633. The problem is really pbuilder's version. If you checked the changelog, you would notice that version 0.199+nmu2 fixed bug #363193, which shows the linux-any issue as one of its first messages. This is not a powerpc issue. You should use a newer version of pbuilder on your powerpc box. Regards. Cascardo. signature.asc Description: Digital signature
Helping with PPC64 port: missing coreutils in sid
Hi, folks. I would like to start contributing to the PPC64 port, since I have access to some machines. When trying to debootstrap from debian-ports, I find that the sid Packages file has coreutils (and maybe all other packages in unreleased?) missing. unreleased, on the other hand, does not have util-linux or mount. So, I can't really use debootstrap from debian-ports.org. I see that the coreutils in the unreleased dist comes from Yamamoto, who also has a repo. His package has an additional changelog entry, with unreleased as the dist, so that may explain why it has gone into the unreleased dist Packages, instead of sid/unstable. What is the procedure here in pushing packages into the unstable dist? And why do we have any changes in coreutils at all? Regards. Cascardo. -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120507211801.ga11...@oc1711230544.ibm.com
