On Wed, Jul 27, 2011 at 10:24:44AM +0300, Gasha wrote:
> Hi list,
>
> just a short introduction...
> i'm a long time unix/linux user, and finally decided to join some
> linux development mailing lists.
>
> recently we got new Power7 machine, and i tried
> latest-squeeze-netinst.iso yesterday.
> L
On Mon, Oct 04, 2010 at 08:32:54PM -0700, Brian Morris wrote:
> If you are using double precision floating point, the speed of a
> program compiled 32bit on a 64bit machine is much much slower (maybe
> 1/10). The 64bit kernel supports 64bit operation Only if the program
> is compile 64 bit ! Moreo
On Fri, Sep 17, 2010 at 02:49:35PM +0200, Mathieu Malaterre wrote:
> How can I test this ? I tried to suspend-to-ram using:
>
> $ sudo apt-get install uswsusp
> $ sudo s2ram
> Switching from vt7 to vt1
> s2ram_do: No such device
> switching back to vt7
>
> with:
>
> $ sudo s2ram -n
>
>
On Mon, May 24, 2010 at 11:59:30PM -0400, Rick Thomas wrote:
>
> The package page for Yaboot at http://packages.debian.org/squeeze/
> yaboot lists Aurélien GÉRÔME and Sven Luther as the maintainers.
>
> Sven has been unable to participate for some years now, and the last
> time I saw Aurélien's n
On Mon, May 10, 2010 at 01:33:12AM -0400, Rick Thomas wrote:
> I sent the enclosed message to erben...@alaska.net, which is listed
> in /usr/share/doc/yaboot/BUGS as the place to send bug reports. But
> it bounced.
>
> Can someone tell me where to send this patch for further processing
> and val
Julien BLACHE writes:
> Stephane Louise wrote:
>
> Hi,
>
> > marie:/home/luigi# grep -i inotify /boot/config-2.6.30-2-powerpc64
> > CONFIG_INOTIFY=y
> > CONFIG_INOTIFY_USER=y
> > marie:/home/luigi# grep -i signalfd /boot/config-2.6.30-2-powerpc64
> > CONFIG_SIGNALFD=y
>
> udev's preinst checks
Amit Uttamchandani writes:
> I'm learning the PPC architecture and I have a PowerBook G4 (7410)
> 500MHz. Looking at the datasheet for the processor, it has support for
> hardware speculation which allows out-of-order execution.
>
> I wanted to test program run times by compiling using gcc with f
Rogério Brito writes:
> In the past, there were some problems with the PREEMPT option of the
> kernel and PowerPC and I remember that BenH just recommended that we
> disabled it when compiling kernels from his tree (gee, that was quite
> some time ago).
>
> Does anybody know what the current stat
Javier Serrano Polo writes:
> I've been working in a repository to support i386 applications on amd64
> (see debian-amd64 for details, same subject). The last direction was to
> extend this to work on qemu supported archs (like powerpc). But since I
> haven't found yet any affordable way to get a
Albert Cahalan writes:
> Running a 32-bit userspace on a 64-bit kernel is
> however gross, foul, bad, nasty, and wrong.
Rubbish. It makes a lot of sense for most userspace programs to be
32-bit on a 64-bit PowerPC system. Unless a program needs to do
64-bit integer arithmetic or access more tha
Anthony Henson writes:
> I run quik, I reboot, I set my real-base to F0, boot-device to
Why F0?
> ide0/[EMAIL PROTECTED]:9 bootfile to /vmlinux root=/dev/hda9 reset-all, when
> it comes
> back to OF, I type boot, I get the boot: prompt, I type linux, and I get
> "Read error on block 637
Rick Thomas writes:
> However, after rebooting following the install, and logging in to
> gnome, it seems to be repeatedly trying to start/re-start something
> having to do with the appearance of the desktop. Things are very
> slow (as if a process in continually crashing and restarting) an
Gabriel Paubert writes:
> I agree, but I don't know why you believe it would cause
> a machine check (0x200): from my docs, it is an ISI (0x400).
I don't believe it would cause a machine check either, but that is
what Matt Sealey was saying. I don't know where he got that idea.
> BTW, there i
Matt Sealey writes:
> Book I compatible PowerPC's have had a "no-executable" bit in
> the page protection flags since the dark ages.. see page 7-38
> and 7-39 of the 'Programming Environments Manual for 32-Bit
> Microprocessors'.. this document predates even the G3.
What are you referring to? I
Albert Cahalan writes:
> The first is to avoid taking the initial fault on the segment
> which contains the instruction pointer.
Good idea.
> The second is to avoid cache or TLB invalidates or flushes
> in certain circumstances. OpenBSD developers report that
> this type of optimization is of gr
Albert Cahalan writes:
> If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
> in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
> I'd love to hear if anybody can get X to start with this change.
In general I would expect dynamically-linked programs to fail unless
you compi
Albert Cahalan writes:
> This kernel patch implements no-execute protection (like x86 "NX bit")
> for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
> PowerPC processors in the 6xx, 7xx, and 7xxx families.
I'd be interested in benchmark comparisons with/without this patch, if
anyone
Albert Cahalan writes:
> VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
> default is important for security. If gcc on PowerPC ever
> does generate code which puts trampolines on the stack,
> then that can be fixed by converting to legal C code or
> by adding the fragile marking to the defective e
Albert Cahalan writes:
> gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
OK, so I think that version should have the new -msecure-plt flag,
which changes the ppc32 ABI so that the PLT no longer has to be
writable and executable. Previously the dynamic linker would rewrite
each PLT entry
Albert Cahalan writes:
> I just ran paxtest on a Mac G4 Cube. Ouch. The results are shameful.
What gcc version, what binutils version, what kernel version?
Paul.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Benjamin Herrenschmidt writes:
> The 970 version bloats the exception prolog significantly... I
Four instructions, in the external and decrementer interrupt entry
paths - I don't think that's really significant bloat.
> understand now why you were talking about putting the code in the exit
> pat
Benjamin Herrenschmidt writes:
> Looks good to me except that we need the same for ppc64 since the 970
> theorically has the same problem...
OK, does this look OK to everyone, before I send it off to Linus? I
now use a bit in the thread_info rather than using the HID0 bits
themselves to indicate
Olof Johansson writes:
> Where is cr0 set now -- you took the dot off of rlwinm?
transfer_to_handler does mfspr r11,SPRN_HID0; mtcr r11 before jumping
to power_save_6xx_restore. The rlwinm. was wrong anyway since it was
setting cr0.eq based on all the *other* bits in HID0, not HID0_NAP
(doh!).
Becky Bruce writes:
> Actually, I think the problem is that the code linux is using to turn
> on nap mode is not guaranteed to put the processor in nap mode by the
> time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch fixes it for me. Comments, anyone?
Paul.
diff -urN powerpc-me
Benjamin Herrenschmidt writes:
> > _GLOBAL(power_save_6xx_restore)
> > mfspr r11,SPRN_HID0
> > rlwinm r11,r11,0,10,8 /* Clear NAP */
> > mtspr SPRN_HID0,r11
> > b transfer_to_handler_cont
> >
> > If I take out that rlwinm, it boots. Bizaare.
>
> Gack ? Didn't
Benjamin Herrenschmidt writes:
> From my quick tests here (I'm travelling, so no much time), it looks
> like it's dying on the first msleep() (either radeonfb or whatever else
> if you play with driver order), which makes me strongly suspect the idle
> loop changes. I'll try to fix that when I'm b
Benjamin Herrenschmidt writes:
> Ok, does not using NTP fixes it ?
Try this patch. With this the values from gettimeofday() or the VDSO
should stay exactly in sync with xtime even if NTP is adjusting the
clock.
This patch still has quite a few debugging printks in it, so it's not
final by any m
I'm replying to Peter's reply because I didn't see Daniel's original
message.
Peter Bergner writes:
>
> Bürgin Daniel (KTSS 1) wrote:
> > I installed Debian Woody on my 44p Box with the How-to's
> > from Rolf Brudeseth mailto:[EMAIL PROTECTED]
> > That works fine, but with a old Kernel 2.4.16 fro
Martin Costabel writes:
> I did some tests with the 2 useful modes of the 6400: 1024x768x8bit at
> 72Hz (vmode 15, cmode 8) and 800x600x16bit at 60Hz (vmode 10, cmode 16).
>
> The results, with or without Tom's patch, were the same as they always
> were:
> The vmode of MacOS is used by the Linu
Martin Costabel writes:
> For the valkyriefb driver on my Pmac 6400, I can confirm from a first
> short test that it still works. This is with your patch applied to
> today's 2.4.17-pre1-ben0 kernel.
Do you still have macos on the 6400? If so can you confirm whether,
if you set the screen resolu
s off my tivo) and Anton Blanchard hacked this into xine. I also
have altivec-enabled motion compensation routines for libmpeg2.
Hope this is useful...
Paul.
# idct_vec.S
#
# Copyright (C) Aaron Holtzman <[EMAIL PROTECTED]> - Nov 1999
# Copyright (C) Paul Mackerras <[EMAIL PROTECT
31 matches
Mail list logo
