Re: Installing on a Dual CPU G5 Powermac?
"Sven" == Sven Luther <[EMAIL PROTECTED]> writes: >> >> I'd be happy to help where I can if something needs testing on >> a dual G5. Sven> [ ...lots of good advice which is well taken by me... ] Sven> Also, once we get ppc64 kernels rolling, it would be nice to Sven> get them tested too and so on, do you know how to build a Sven> kernel ? Yes, I can build kernels. However right now I don't have a system on which I can do this which is really frustrating (my old AMD K7 based workhorse had a motherboard failure, the dual G5 is the replacement as a gift from my wife ). I got a Gentoo image (2.6.9 smp) that boots the G5 nicely. I tried to use it to get debootstrap or d-i going but I'm not there yet. Is there a way to use a rescue kernel (in this case the Gentoo kernel booted from a Mac HD using OpenFirmware) to start the d-i on the Sarge CD? (My guess is not, but then I'm not very familiar with internals of d-i). I even started an attempt to rebuild the Gentoo and/or Debian initrd on my old i686 machine so I could boot and run d-i or debootstrap on the G5. Imagine the frustration: the Debian ppcinitrd is big endian, and my little endian i686 kernel cannot loop mount it!(?). The Gentoo initrd is ext2, which I can take apart and rebuild on the 686 machine, but since I can't look into the debian-installer initrd I don't know what changes I need to make :-) This i686 laptop is too slow and constrained for me to install a cross compilation toolchain even if I wanted to. At any rate, I'm starting to enjoy the powerpc experience. In the five days since I got this machine I've got a little grip on Yaboot and OpenFirmware, and I think I see how I might use my wife's G4 (on which I am *prohibited* from installing Linux :-) to install on the G5 in target disk mode. Tomorrow is another day. Thanks for all the help! Shyamal
Re: installing sarge
> On Dec 22, 2004, at 1:56 PM, vinai wrote: > > > By "basic install" - does that include running Tasksel? I don't remember - it's been a really long time since I last had to do a basic installation. People can correct me if I'm wrong, but I think you can do a very minimal install (of the "Base System") without having to go through Tasksel or selecting packages. > can you point me to a HowTo that tells how to do this? Take a look in /etc/apt. I'm not at my Debian machine anymore, and won't be till next week, but there should be a file in there called sources.list. Edit this file and change instances of "stable" in that file to "testing" After this, you should run "apt-get update" so that your packing list and dependencies are for "testing" and then "apt-get upgrade" to actually upgrade the software packages. Then, you will be able to "apt-get install " packages you want. cheers vinai PS: I'm subscribed to the list, so no need to also 'cc' me on the notes.
Re: [PATCH] Fix Alsa issues including Oopses with OSS emulation
the pmac driver has issues on my imac dv, it works but alas
it doesnt know what to do when plugging in headphones
not to mention lack of input sensors for my ibook (clamshell)
i realise though that if you cant get specs and no one
wants to tinker around stuff wont get implemented.
but if its in OSS...
*shrug*
ben (and others) do a great job though.
Dean
Martin-Éric Racine wrote:
Nice to know that work is being done on the pmac ALSA driver. :)
However, I still cannot get ALSA to work at all on this iMac's Burgundy:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=306
The old OSS driver still works, so I know that the hardware is not at
fault; this is clearly an ALSA driver problem.
Has anybody managed to get this to work on similar hardware?
On Wed, 22 Dec 2004, Benjamin Herrenschmidt wrote:
This patch (which will be send upstream separately by the Alsa folks) fixes
an signed vs. unsigned char problem in Alsa which was the cause of the Oops
people were experiencing on ppc with OSS emulation and possibly other issues.
Index: linux-work/sound/core/pcm_misc.c
===
--- linux-work.orig/sound/core/pcm_misc.c 2004-11-22 01:51:09.0
+0100
+++ linux-work/sound/core/pcm_misc.c2004-12-22 19:11:26.297518336 +0100
@@ -26,10 +26,10 @@
#define SND_PCM_FORMAT_UNKNOWN (-1)
struct pcm_format_data {
- char width; /* bit width */
- char phys; /* physical bit width */
- char le;/* 0 = big-endian, 1 = little-endian, -1 = others */
- char signd; /* 0 = unsigned, 1 = signed, -1 = others */
+ signed char width; /* bit width */
+ signed char phys; /* physical bit width */
+ signed char le; /* 0 = big-endian, 1 = little-endian, -1 =
others */
+ signed char signd; /* 0 = unsigned, 1 = signed, -1 = others */
unsigned char silence[8]; /* silence data to fill */
};
Qemu and i386 Software on an iBook
Hello I would like to run the package MuPAD/Scilab on my iBook-Linux-Box. Unfortunately the producer of MuPAD doesn't distribute binaries for powerpc linux; but there is a i386 binary package. Can I use Qemu in order to run the MuPAD i386 binary on my powerpc g4-1.2GHz-ibook. kind regards, Roland btw: very merry christmas and (in a little while) a happy new year :-)
Re: [PATCH] Fix Alsa issues including Oopses with OSS emulation
Nice to know that work is being done on the pmac ALSA driver. :)
However, I still cannot get ALSA to work at all on this iMac's Burgundy:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=306
The old OSS driver still works, so I know that the hardware is not at
fault; this is clearly an ALSA driver problem.
Has anybody managed to get this to work on similar hardware?
On Wed, 22 Dec 2004, Benjamin Herrenschmidt wrote:
> This patch (which will be send upstream separately by the Alsa folks) fixes
> an signed vs. unsigned char problem in Alsa which was the cause of the Oops
> people were experiencing on ppc with OSS emulation and possibly other issues.
>
> Index: linux-work/sound/core/pcm_misc.c
> ===
> --- linux-work.orig/sound/core/pcm_misc.c 2004-11-22 01:51:09.0
> +0100
> +++ linux-work/sound/core/pcm_misc.c 2004-12-22 19:11:26.297518336 +0100
> @@ -26,10 +26,10 @@
> #define SND_PCM_FORMAT_UNKNOWN (-1)
>
> struct pcm_format_data {
> - char width; /* bit width */
> - char phys; /* physical bit width */
> - char le;/* 0 = big-endian, 1 = little-endian, -1 = others */
> - char signd; /* 0 = unsigned, 1 = signed, -1 = others */
> + signed char width; /* bit width */
> + signed char phys; /* physical bit width */
> + signed char le; /* 0 = big-endian, 1 = little-endian, -1 =
> others */
> + signed char signd; /* 0 = unsigned, 1 = signed, -1 = others */
> unsigned char silence[8]; /* silence data to fill */
> };
>
>
>
>
>
--
Martin-Éric Racine, ICT Consultant
http://www.iki.fi/q-funk/
Re: Installing on a Dual CPU G5 Powermac?
On Wed, Dec 22, 2004 at 02:12:13PM -0800, shyamal wrote: > "Sven" == Sven Luther <[EMAIL PROTECTED]> writes: > > Sven> Please fill a bug report against the power4 kernel-image > Sven> package. > > Done #286761 against kernel-image-2.6.8-power4-di > > I'd be happy to help where I can if something needs testing on a dual > G5. Jens used to have a dual G5 2.0 Ghz, and he did kernel builds on it, and much of the testing, including d-i. He doesn't have access to it anymore though. Mostly what needs testing is the kernels (and posting on debian-kernel, cross posted to debian-powerpc, and doing bug report is the best way to help there. Also there is #debian-kernel on freenode), and debian-installer (and posting on debian-boot and the #debian-boot on freenode irc channel is the best way to help out). I am a bit out of touch of these things until after christmas though, but there may be other people who could ask stuff and so. Also, once we get ppc64 kernels rolling, it would be nice to get them tested too and so on, do you know how to build a kernel ? Friendly, Sven Luther
Re: installing sarge
On Dec 22, 2004, at 1:56 PM, vinai wrote: On Wed, 22 Dec 2004, Daniel R. Killoran,Ph.D. wrote: I want to install sarge in my Old-World Mac 9500. I know I need to use BootX, and that I should copy linux.bin and ramdisk.image.gz into the "Linux Kernels" folder, but I can't find those files on the ISO images of the sarge distribution. Should I use the corresponding files from woody? At what point do I use the sarge disks? Take a look here for kernel image files: http://www.debian.org/releases/stable/powerpc/ch-appendix.en.html What I'd suggest, go with Woody - do a basic install, By "basic install" - does that include running Tasksel? then update your apt sources list can you point me to a HowTo that tells how to do this? so that "stable" becomes "testing". After this, you should be able to "apt-get update" and "apt-get upgrade" ... Thanks, Dan Killoran
Re: Installing on a Dual CPU G5 Powermac?
"Sven" == Sven Luther <[EMAIL PROTECTED]> writes: Sven> Please fill a bug report against the power4 kernel-image Sven> package. Done #286761 against kernel-image-2.6.8-power4-di I'd be happy to help where I can if something needs testing on a dual G5. Thanks, Shyamal
Re: installing sarge
On (22/12/04 12:56), vinai wrote: > On Wed, 22 Dec 2004, Daniel R. Killoran,Ph.D. wrote: > > > I want to install sarge in my Old-World Mac 9500. > > I know I need to use BootX, and that I should copy linux.bin and > > ramdisk.image.gz into the "Linux Kernels" folder, but I can't find > > those files on the ISO images of the sarge distribution. > > Should I use the corresponding files from woody? > > At what point do I use the sarge disks? On the d-i rc2 sarge netinstall iso the are two files: initrd.gz and vmlinux (look in /install/powerpc) Copy those to your Linux Kernels folder on the Mac side and away you go. Just remember to copy the installed initrd.gz and vmlinux files to the mac side after the base install before rebooting so that you can subsitute these for those from the installer. > Take a look here for kernel image files: > > http://www.debian.org/releases/stable/powerpc/ch-appendix.en.html > > What I'd suggest, go with Woody - do a basic install, then update your > apt sources list so that "stable" becomes "testing". After this, you > should be able to "apt-get update" and "apt-get upgrade" ... IMHO you're much better off with the new installer - I've used both on old Macs and the sarge installer is just way easier and quicker. YMMV Regards Clive -- www.clivemenzies.co.uk ... ...strategies for business
atheros chip set on D-Link AG660
I just purchased and been trying to compile the source for the atheros chip set and keep on getting errors. I found a link on the debian users list to a guy who have made some packages for the debian system in the atheros chip set. I have been trying to compile the code from that and directly from madwifi and each in its own give me errors. compiling code from madwifi: 1. downloaded the tarball (I have not yet uesed cvs) 2. cd into the madwifi directly in /usr/src 3. make # make for i in ./ath_hal ath_rate/onoe ./net80211 ./ath; do \ (cd $i; make) || exit 1; \ done make[1]: Entering directory `/usr/src/madwifi/ath_hal' cp ./../hal/linux/ah_osdep.c ah_osdep.c uudecode ./../hal/linux/powerpc-be-eabi.hal.o.uu cp ./../hal/linux/powerpc-be-eabi.opt_ah.h opt_ah.h make -C /lib/modules/2.6.9.pb2/build SUBDIRS=/usr/src/madwifi/ath_hal modules make[2]: Entering directory `/usr/src/linux-2.6.9' CC [M] /usr/src/madwifi/ath_hal/ah_osdep.o /bin/sh: /pub/gnu/bin/powerpc-eabi-gcc: No such file or directory make[3]: *** [/usr/src/madwifi/ath_hal/ah_osdep.o] Error 1 make[2]: *** [_module_/usr/src/madwifi/ath_hal] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.9' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/madwifi/ath_hal' make: *** [all] Error 1 I think the error is the '/pub/gnu/bin/powerpc-eabi-gcc' I have no such /pub directory. Before that the error was hal/linux/powerpc-be-eabi: No such file or directory so I made a link lrwxrwxrwx 1 root root 19 Dec 22 01:56 powerpc-be-eabi -> powerpc-be-eabi.inc and now I have the above error. 2. using deb packages cd cd madwifi-1.6/ # fakeroot dpkg-buildpackage dpkg-buildpackage: source package is madwifi dpkg-buildpackage: source version is 1.6-1 dpkg-buildpackage: source maintainer is Martin List-Petersen <[EMAIL PROTECTED]> dpkg-buildpackage: host architecture is powerpc debian/rules clean dh_testdir #dh_testroot rm -f build-arch-stamp build-indep-stamp patch-stamp rm -rf madwifi dh_clean dpkg-source -b madwifi-1.6 dpkg-source: building madwifi in madwifi_1.6-1.tar.gz dpkg-source: building madwifi in madwifi_1.6-1.dsc debian/rules build dh_testdir tar -xzf madwifi.tar.gz touch patch-stamp dh_testdir /usr/bin/make -C madwifi/tools TARGET=powerpc-eabi make[1]: Entering directory `/usr/src/madwifi-1.6/madwifi/tools' ../Makefile.inc:166: ../hal/linux/powerpc-eabi.inc: No such file or directory make[1]: *** No rule to make target `../hal/linux/powerpc-eabi.inc'. Stop. make[1]: Leaving directory `/usr/src/madwifi-1.6/madwifi/tools' make: *** [build-arch-stamp] Error 2 I see that the error here is relitiv the same as the other step as in the '/hal/linux/powerpc-eabi.inc: No such file or directory' but when I go in the directory to make a link and fakeroot dpkg-buildpackage but in doing that the directory is updated from the current cvs and my change is lost. I have been reasearching the net all over the place and searching many different ways on the debian-ppc list and debian-users list. Has anyone else have had some successful success in compiling the code for the atheros chip set? If I can't get this to work I would like to be able to return my PCMIA card before I can't. -Adam
Re: installing sarge
On Wed, 22 Dec 2004, Daniel R. Killoran,Ph.D. wrote: > I want to install sarge in my Old-World Mac 9500. > I know I need to use BootX, and that I should copy linux.bin and > ramdisk.image.gz into the "Linux Kernels" folder, but I can't find > those files on the ISO images of the sarge distribution. > Should I use the corresponding files from woody? > At what point do I use the sarge disks? Take a look here for kernel image files: http://www.debian.org/releases/stable/powerpc/ch-appendix.en.html What I'd suggest, go with Woody - do a basic install, then update your apt sources list so that "stable" becomes "testing". After this, you should be able to "apt-get update" and "apt-get upgrade" ... cheers vinai
Re: [PATCH] Fix Alsa issues including Oopses with OSS emulation
On Wed, 2004-12-22 at 19:13 +0100, Benjamin Herrenschmidt wrote:
> This patch (which will be send upstream separately by the Alsa folks) fixes
> an signed vs. unsigned char problem in Alsa which was the cause of the Oops
> people were experiencing on ppc with OSS emulation and possibly other issues.
Ok, actually, the one that will be commited upstream is a bit different,
here it is:
Summary: [ALSA] Fix the wrong sign of format data entries
Fix suggested by Benjamin Herrenschmidt <[EMAIL PROTECTED]>
On architectures like PPC, char is handled as "unsigned char", thus the
pcm_format_data table entries with -1 give a positive 255. This causes
Oops with OSS-emulation on such architectures.
The patch simply adds the right signed/unsigned prefix to fix this problem.
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
--- linux/sound/core/pcm_misc.c 8 Jun 2004 16:57:28 - 1.12
+++ linux/sound/core/pcm_misc.c 22 Dec 2004 18:07:29 - 1.14
@@ -25,11 +25,14 @@
#include
#define SND_PCM_FORMAT_UNKNOWN (-1)
+/* NOTE: "signed" prefix must be given below since the default char is
+ * unsigned on some architectures!
+ */
struct pcm_format_data {
- char width; /* bit width */
- char phys; /* physical bit width */
- char le;/* 0 = big-endian, 1 = little-endian, -1 = others */
- char signd; /* 0 = unsigned, 1 = signed, -1 = others */
+ unsigned char width;/* bit width */
+ unsigned char phys; /* physical bit width */
+ signed char le; /* 0 = big-endian, 1 = little-endian, -1 = others */
+ signed char signd; /* 0 = unsigned, 1 = signed, -1 = others */
unsigned char silence[8]; /* silence data to fill */
};
Re: Problem netbooting a prep machine
On Wed, Dec 22, 2004 at 12:13:29PM +0100, Philippe Guyot wrote:
> [snip...]
>
> [snip...]
> >
> > A few hexdump later
> >
> > All seems fine in the headers I have examined.
> > Entry point offset points to smthing I believe the start of code (no
> > desassembly yet..)
> > Load image length
> > Flags ( showing big endian for the code)
> > Similar for file vmlinuz, file zImage from Leigh, x41 boot partition
> > of my 43P-140 (whith addition of "root=..." done whith preptools), memory
> > after loading using OF .
>
> I had a look on the boot partition native AIX.
>
> Besides the AIX logical volume control block, things are the same as
> described
> in Leigh's doc : PC compatibility blok, Entry point offset, Load image length
> and so on.
>
> Once loaded ("load disk"), the memory mapping is the same, flags are the
> same,
> registers are ok (ppc points on entry point ). Image loaded is greater than
> vmlinuz. so I don't think its a size problem.
>
> And AIX boots, of course.
>
> Remembering that yaboot (ELF) loads and goes (not very fine) I have no idea
> more.
> Just a difference/bug in this OF whith the client interface ? Something in
> Linux code not accepted here ?
> Should it be this strange thing: RSPC between PReP and CHRP ?
>
> >
> > I am wondering if I could be able to write a little piece of code for
> > testing if it could be load-and-go'ed but I have no experience of that. May
> > I use some makefile or equivalent ?
>
> That seems rather difficult for me but I am searching.
Notice that i heard rumors that some PReP boxes are not able to boot kernels
(including initrd) bigger than 4MB. Could you try the netboot-small kernel (it
will nto work, probably, but it should boot).
Friendly,
Sven Luther
[PATCH] Fix Alsa issues including Oopses with OSS emulation
This patch (which will be send upstream separately by the Alsa folks) fixes
an signed vs. unsigned char problem in Alsa which was the cause of the Oops
people were experiencing on ppc with OSS emulation and possibly other issues.
Index: linux-work/sound/core/pcm_misc.c
===
--- linux-work.orig/sound/core/pcm_misc.c 2004-11-22 01:51:09.0
+0100
+++ linux-work/sound/core/pcm_misc.c2004-12-22 19:11:26.297518336 +0100
@@ -26,10 +26,10 @@
#define SND_PCM_FORMAT_UNKNOWN (-1)
struct pcm_format_data {
- char width; /* bit width */
- char phys; /* physical bit width */
- char le;/* 0 = big-endian, 1 = little-endian, -1 = others */
- char signd; /* 0 = unsigned, 1 = signed, -1 = others */
+ signed char width; /* bit width */
+ signed char phys; /* physical bit width */
+ signed char le; /* 0 = big-endian, 1 = little-endian, -1 =
others */
+ signed char signd; /* 0 = unsigned, 1 = signed, -1 = others */
unsigned char silence[8]; /* silence data to fill */
};
Re: Fwd: Debian installer: partman-prep
Am Mittwoch, 22. Dezember 2004 14:24 schrieb Colin Watson: > On Wed, Dec 22, 2004 at 01:40:20PM +0100, Cajus Pollmeier wrote: > > I've prepared a partman-prep package which should add support for PPC > > PReP boot partitions to the installer. The package has been forked from > > partman-palo. Now, short before testing, I'm wondering about the > > mechanism which takes care about loading this module. > > > > I've grep'ed through the complete installer source, but got stuck in > > the partman code. So - what do I have to do, that the partman-prep udeb > > gets loaded on installation time? > > Same as partman-newworld: Priority: standard is enough to have it > installed automatically. Make sure to use proper Architecture: and > XB-Subarchitecture: fields to make sure it's not installed where it's > inappropriate, and if necessary an isinstallable file in the control > area. Ah - thanks for your answer. I didn't set the XB-Subarchitecture field, because it wasn't set in the control file. In case of the newworld example, I can't find where powermac_newworld comes from. What to do if I only want to have this loaded when using the pseries flavor added by me in the linux-kernel-di-powerpc's kernel-versions file? -- While looking for the way to set the correct subarch, I found that in base-installer's postinst, line 438 the CPU variable is filled by: CPU=`grep '^cpu[[:space:]]*:' /proc/cpuinfo | cut -d: -f2 | sed 's/^ *//; s/[, ].*//' | tr A-Z a-z` The following case doesn't seem to work with more than one CPU. In my case CPU contains "power4+ power4+". CPU=`grep '^cpu[[:space:]]*:' /proc/cpuinfo | cut -d: -f2 | sed 's/^ *//; s/[, ].*//; q' | tr A-Z a-z` fixes the problem. Cheers, Cajus
Re: debian ppc64
On Tue, Dec 21, 2004 at 06:56:18PM -0800, David Schleef wrote: > On Mon, Dec 20, 2004 at 11:10:53PM +0100, Sven Luther wrote: > > Actually, as i recall, the 64bit code should be slower, since all pointers > > are > > now 64bit, and thus you have to transfer double amount of code from the ram > > and so on. > > AIUI, 64-bit powerpc code is generally only slightly larger than > 32-bit powerpc code. Like, say, 1%. (I'd be interested in actual > numbers, including differences in the sizes of individual sections > in a binary.) Since the memory bandwidth of processors greatly > exceeds its usage by typical code (i.e., non-altivec and not > optimized by hand), I don't see the extra size of pointers > contributing to a memory bottleneck. One exception is if you are > copying around massive arrays of pointers (or to a lesser extent, > structures containing pointers), which although not uncommon, is > probably not an interesting optimization case[1]. > > However, for a given cache size, any data containing pointers will > take up a larger chunk of cache. 64-bit processors generally have > larger caches to compensate for this, but for a given cache size, > one would expect 32-bit code manipulating lots of pointers to have > a higher hit-ratio, thus being faster. Such increases would be > algorithm-dependent, hard to measure, and small (except in corner > cases). > > I can really only think of two cases where 64-bit code could be > faster (not that it _would_ be in practise) -- 1) arithmetic on > 64-bit types, and 2) optimized versions of strlen(). Well, for 2), altivec should be a better optimizer, right ? Friendly, Sven Luther
installing sarge
I want to install sarge in my Old-World Mac 9500. I know I need to use BootX, and that I should copy linux.bin and ramdisk.image.gz into the "Linux Kernels" folder, but I can't find those files on the ISO images of the sarge distribution. Should I use the corresponding files from woody? At what point do I use the sarge disks? TIA Dan Killoran
Re: Hard Drive light
On Wed, Dec 22, 2004 at 05:12:22PM +0100, Colin Leroy wrote: > On 22 Dec 2004 at 17h12, Benjamin Herrenschmidt wrote: > > > Oh, and to add to this ... I prefer having it ON by default so users > > avoid moving their laptop around while the HD is busy... > > Is it dangerous? It will always be a bit more dangerous to hit the laptop while the disks are spinning and the heads are over the platter than when they are parked and the disk still. J -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.28|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 And then he ran into my knife... he ran into my knife ten times. --June (Chicago)
Re: MLton on PowerPC: voltaire's Christmas wish?
On Wed, Dec 22, 2004 at 04:25:18PM +0100, Ingo Juergensmann wrote: > > I am not planning on porting MLton to any platform with less memory. > > PowerPC is the exception; lots of people use it and it can handle the RAM. > > I've already done hppa and sparc. amd64, ia64, and alpha need some 64bit > > cleanups, so I was planning on doing that after the easier 32bit ports. > > Maybe you want to get the other archs listed in N-F-U. Or just not list them in the Architecture: i386, sparc, ... list? > > Well, I'm in contact with the developers of MLton, and they seem to think > > this is an inherent disadvantage of whole-program optimization. Their (valid > > imo) argument is that requiring a powerful build machine is better than > > requiring a powerful machine to run the resulting binary. > > Sure, but I wonder where to draw the line? Maybe next week another program > want to have 2G of RAM or 1 TB of disk space to build... ;) I don't think you can draw a line; the line is always moving. As computer get more powerful, so should the autobuilders. However, 320->512MB is not a big step. 1G is not necessary. I think there is always a tension between what a program needs and what it provides. I had hoped to show that for ppc, MLton is desirable. =) -- Wesley W. Terpstra
Re: Hard Drive light
On 22 Dec 2004 at 17h12, Benjamin Herrenschmidt wrote: Hi, > > Having it enabled by default will let people know that it exists. I > > know too many Mac users that badly want a LED to show them when > > "it's working and I should wait"... > > Oh, and to add to this ... I prefer having it ON by default so users > avoid moving their laptop around while the HD is busy... Is it dangerous? A metallic chair failed on my ibook G4 a few monthes ago (don't ask why it was on the floor...), it only fucked a bit of plastic at the bottom of the screen - not the screen, not the keyboard, not the HD, nothing! and I was pretty impressed by the fact i didn't destroy the whole thing. -- Colin
Re: debian ppc64
On Tue, 2004-12-21 at 18:56 -0800, David Schleef wrote: > I can really only think of two cases where 64-bit code could be > faster (not that it _would_ be in practise) -- 1) arithmetic on > 64-bit types, and 2) optimized versions of strlen(). > > All in all, I'd consider it a wash, and would not be too concerned > about whether the system I was running was 32-bit native or 64-bit > native. It would bother me (slightly), however, if there were two > versions of libraries competing for cache/RAM/disk space. The typical biarch setup is to have 2 versions of most libs, but pretty much everything running 32 bits by default, only specific apps that take benefit of beeing 64 bits beeing built 64 bits... It would be useful to use gentoo to do a more complete performance and size comparison though, since they have both fully 32 and fully 64 bits ppc environments. Ben.
Re: Hard Drive light
On Tue, 2004-12-21 at 14:21 +0100, Colin Leroy wrote: > On 22 Dec 2004 at 00h12, Cedric Pradalier wrote: > > Hi, > > > >No, not at this point. Beside, i'd like to have it enabled by > > >default, not disabled by default :) > > > > > > > I don't really agree with that. Blinking led is not really relevant > > for default user. I would say that if someone feels geek enough ;) to > > want it, it is good to make it available. On the other hand, I would > > not bother unconcerned people with this blinking. > > Having it enabled by default will let people know that it exists. I know > too many Mac users that badly want a LED to show them when "it's > working and I should wait"... Oh, and to add to this ... I prefer having it ON by default so users avoid moving their laptop around while the HD is busy... Ben.
Re: Hard Drive light
On Tue, 2004-12-21 at 14:21 +0100, Colin Leroy wrote: > On 22 Dec 2004 at 00h12, Cedric Pradalier wrote: > > Hi, > > > >No, not at this point. Beside, i'd like to have it enabled by > > >default, not disabled by default :) > > > > > > > I don't really agree with that. Blinking led is not really relevant > > for default user. I would say that if someone feels geek enough ;) to > > want it, it is good to make it available. On the other hand, I would > > not bother unconcerned people with this blinking. > > Having it enabled by default will let people know that it exists. I know > too many Mac users that badly want a LED to show them when "it's > working and I should wait"... Heh, in fact, I regulary have OS X users asking me for a similar feature in Darwin :) Ben.
Re: MLton on PowerPC: voltaire's Christmas wish?
On Wed, Dec 22, 2004 at 03:59:55PM +0100, Wesley W. Terpstra wrote: > On Wed, Dec 22, 2004 at 09:42:01AM +0100, Ingo Juergensmann wrote: > > Well, having more RAM is always nice, but IMHO there's something wrong with > > MLton when it needs that much RAM for building. > It's a whole-program optimizing compiler... > That means it analyzes all of the source code at once. > When compiling a large project (MLton is ~145k lines) it needs memory. > I agree that this is unfortunate; however, if you check out the runtime > performance of MLton compiled applications, you'll see the advantages. =) Well, if it's an advantage if you can't use it because you can't compile it, is argueable, I think... ;) > > buildd=> select distinct ram, count(*) from status group by ram; > > ram | count | arch > > --+---+- > >48 | 1 | m68k > >64 | 6 | arm mipsel m68k mips > >80 | 1 | m68k > >90 | 1 | mips > >96 | 3 | mips m68k > > 128 |11 | arm mips m68k > > 132 | 1 | m68k > > 136 | 1 | m68k > > 144 | 2 | m68k > > 256 | 4 | m68k mips s390 > > 320 | 1 | powerpc > > 512 | 6 | amd64 sparc alpha > > 768 | 1 | hppa > > 1024 | 2 | alpha hppa > > 1536 | 1 | amd64 > > 2048 | 1 | sparc > > 4096 | 2 | alpha ia64 > Thanks a lot for this list! I've been trying to find it for a month. > Where did you get this? It's the database used on buildd.net. Not all of those are "official" buildds, but it reflects the buildds used for non-free, backports and experimentel as well. > > As you can see, many buildds are low on RAM. How do you want to solve that? > I am not planning on porting MLton to any platform with less memory. > PowerPC is the exception; lots of people use it and it can handle the RAM. > I've already done hppa and sparc. amd64, ia64, and alpha need some 64bit > cleanups, so I was planning on doing that after the easier 32bit ports. Maybe you want to get the other archs listed in N-F-U. > > but maybe it's possible for MLton as well to lower the RAM requirements? > > Of course you would need to know where and why the RAM is needed... > Well, I'm in contact with the developers of MLton, and they seem to think > this is an inherent disadvantage of whole-program optimization. Their (valid > imo) argument is that requiring a powerful build machine is better than > requiring a powerful machine to run the resulting binary. Sure, but I wonder where to draw the line? Maybe next week another program want to have 2G of RAM or 1 TB of disk space to build... ;) -- Ciao... // Ingo \X/ Please note that year 2004 is coming to an end and the year 2005 is near - even in my mail address!
unsubscribe
unsubscribe
Re: MLton on PowerPC: voltaire's Christmas wish?
On Wed, Dec 22, 2004 at 09:42:01AM +0100, Ingo Juergensmann wrote: > Well, having more RAM is always nice, but IMHO there's something wrong with > MLton when it needs that much RAM for building. It's a whole-program optimizing compiler... That means it analyzes all of the source code at once. When compiling a large project (MLton is ~145k lines) it needs memory. I agree that this is unfortunate; however, if you check out the runtime performance of MLton compiled applications, you'll see the advantages. =) > buildd=> select distinct ram, count(*) from status group by ram; > ram | count | arch > --+---+- >48 | 1 | m68k >64 | 6 | arm mipsel m68k mips >80 | 1 | m68k >90 | 1 | mips >96 | 3 | mips m68k > 128 |11 | arm mips m68k > 132 | 1 | m68k > 136 | 1 | m68k > 144 | 2 | m68k > 256 | 4 | m68k mips s390 > 320 | 1 | powerpc > 512 | 6 | amd64 sparc alpha > 768 | 1 | hppa > 1024 | 2 | alpha hppa > 1536 | 1 | amd64 > 2048 | 1 | sparc > 4096 | 2 | alpha ia64 Thanks a lot for this list! I've been trying to find it for a month. Where did you get this? > As you can see, many buildds are low on RAM. How do you want to solve that? I am not planning on porting MLton to any platform with less memory. PowerPC is the exception; lots of people use it and it can handle the RAM. I've already done hppa and sparc. amd64, ia64, and alpha need some 64bit cleanups, so I was planning on doing that after the easier 32bit ports. > but maybe it's possible for MLton as well to lower the RAM requirements? > Of course you would need to know where and why the RAM is needed... Well, I'm in contact with the developers of MLton, and they seem to think this is an inherent disadvantage of whole-program optimization. Their (valid imo) argument is that requiring a powerful build machine is better than requiring a powerful machine to run the resulting binary. -- Wesley W. Terpstra
Re: Problem netbooting a prep machine
[snip...]
[snip...]
>
> A few hexdump later
>
> All seems fine in the headers I have examined.
> Entry point offset points to smthing I believe the start of code (no
> desassembly yet..)
> Load image length
> Flags ( showing big endian for the code)
> Similar for file vmlinuz, file zImage from Leigh, x41 boot partition
> of my 43P-140 (whith addition of "root=..." done whith preptools), memory
> after loading using OF .
I had a look on the boot partition native AIX.
Besides the AIX logical volume control block, things are the same as described
in Leigh's doc : PC compatibility blok, Entry point offset, Load image length
and so on.
Once loaded ("load disk"), the memory mapping is the same, flags are the same,
registers are ok (ppc points on entry point ). Image loaded is greater than
vmlinuz. so I don't think its a size problem.
And AIX boots, of course.
Remembering that yaboot (ELF) loads and goes (not very fine) I have no idea
more.
Just a difference/bug in this OF whith the client interface ? Something in
Linux code not accepted here ?
Should it be this strange thing: RSPC between PReP and CHRP ?
>
> I am wondering if I could be able to write a little piece of code for
> testing if it could be load-and-go'ed but I have no experience of that. May
> I use some makefile or equivalent ?
That seems rather difficult for me but I am searching.
Friendly.
Felipe
Re: MLton on PowerPC: voltaire's Christmas wish?
On Wed, Dec 22, 2004 at 03:44:12AM +0100, Wesley W. Terpstra wrote: > The problem is that debian powerpc autobuilder, voltaire, has 320MB of RAM. > If you read http://mlton.org/SelfCompiling you will see that a build needs > 512MB. Swap is no substitute for RAM with this build! A build on one of my > machines did not terminate after two days with 256MB of RAM, but completed > in 10 minutes with 1GB. I find it very surprising that voltaire has so > little memory since I imagine most modern PPCs have much more than this, > and RAM is very inexpensive these days. Well, having more RAM is always nice, but IMHO there's something wrong with MLton when it needs that much RAM for building. buildd=> select distinct ram, count(*) from status group by ram; ram | count | arch --+---+- 48 | 1 | m68k 64 | 6 | arm mipsel m68k mips 80 | 1 | m68k 90 | 1 | mips 96 | 3 | mips m68k 128 |11 | arm mips m68k 132 | 1 | m68k 136 | 1 | m68k 144 | 2 | m68k 256 | 4 | m68k mips s390 320 | 1 | powerpc 512 | 6 | amd64 sparc alpha 768 | 1 | hppa 1024 | 2 | alpha hppa 1536 | 1 | amd64 2048 | 1 | sparc 4096 | 2 | alpha ia64 As you can see, many buildds are low on RAM. How do you want to solve that? Of course it would be nice to have 1 G in all buildds, but some are already maxed out at 128 MB or 256 MB. There already were packages that consumed an insane amount of RAM during build time, but sometimes that could be solved with changing the way of how those packages are being built (unfortunately the names slipped away from my mind, currently ;), but maybe it's possible for MLton as well to lower the RAM requirements, too? Of course you would need to know where and why the RAM is needed... -- Ciao... // Ingo \X/ Please note that year 2004 is coming to an end and the year 2005 is near - even in my mail address!
