tream or they will be gone. And without those bridges no
architecture support for it.
Note that riscv64 would already be there if ftpmaster allowed the
experimental upload out of NEW (there since November.)
Regards.
Rene
Weitergeleitete Nachricht
Betreff: Plan to remove
On Wed, 13 May 2020 at 14:44, Christian Zigotzky wrote:
>
> OpenGL version string: 1.5 Mesa 7.6
> OpenGL version string: 1.3 Mesa 7.2
>
> Screenshots:
>
> - http://www.supertuxkart.de/stk07ubuntu910ppc.png
> - http://www.supertuxkart.de/opensuse111-stk073.jpg
Those are *extremely old* (and I mean
Hello Christian!
On 5/13/20 3:44 PM, Christian Zigotzky wrote:
> AGP mode/support is deactivated on PowerPC and it doesn't work reliable
>
> And what does these lines mean:
AGP mode is actually disabled in the Radeon driver for PowerPC as Alex has
pointed
out earlier in this thread [1]. You
Hi All,
AGP mode/support is deactivated on PowerPC and it doesn't work reliable
And what does these lines mean:
PowerMac G5 Dual:
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RV350 4152) 20090101 AGP 8x
PowerPC 64/Altivec TCL
OpenGL version string: 1.5 Me
On Wed, 13 May 2020 at 11:58, Michel Dänzer wrote:
>
> How do you know you're hitting that particular issue?
Sorry, somehow I misread that. I was still thinking of the AGP hangs.
On 2020-05-13 12:39 p.m., Rui Salvaterra wrote:
> On Wed, 13 May 2020 at 11:27, Michel Dänzer wrote:
>>
>> The only theoretical problem there was that the kernel still had a
>> cacheable mapping of the same memory, and any access via that (e.g.
>> prefetch due to access to a neighbouring page) cou
On Wed, 13 May 2020 at 11:27, Michel Dänzer wrote:
>
> The only theoretical problem there was that the kernel still had a
> cacheable mapping of the same memory, and any access via that (e.g.
> prefetch due to access to a neighbouring page) could trigger a machine
> check. But I don't remember eve
On 2020-05-13 12:29 p.m., Daniel Vetter wrote:
> On Wed, May 13, 2020 at 12:26 PM Michel Dänzer wrote:
>>
>> On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
>>> On Wed, 13 May 2020 at 08:19, Daniel Vetter wrote:
i915 is even worse, we manually mess around with clflush. In
userspace
On Wed, May 13, 2020 at 12:26 PM Michel Dänzer wrote:
>
> On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
> > On Wed, 13 May 2020 at 08:19, Daniel Vetter wrote:
> >>
> >> i915 is even worse, we manually mess around with clflush. In
> >> userspace. So really there's 2 axis for dma memory: coherent
On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
> On Wed, 13 May 2020 at 08:19, Daniel Vetter wrote:
>>
>> i915 is even worse, we manually mess around with clflush. In
>> userspace. So really there's 2 axis for dma memory: coherent vs.
>> non-coherent (which is something the dma-api somewhat expos
On Wed, May 13, 2020 at 9:55 AM Christian König
wrote:
>
> Am 13.05.20 um 09:19 schrieb Daniel Vetter:
> > On Tue, May 12, 2020 at 8:22 PM Alex Deucher wrote:
> >> On Tue, May 12, 2020 at 12:38 PM Daniel Vetter wrote:
> >>> On Tue, May 12, 2020 at 3:22 PM Alex Deucher
> >>> wrote:
> On Tu
On Wed, 13 May 2020 at 08:19, Daniel Vetter wrote:
>
> i915 is even worse, we manually mess around with clflush. In
> userspace. So really there's 2 axis for dma memory: coherent vs.
> non-coherent (which is something the dma-api somewhat exposed), i.e.
> do you need to clflush or not, and cached
Am 13.05.20 um 09:19 schrieb Daniel Vetter:
On Tue, May 12, 2020 at 8:22 PM Alex Deucher wrote:
On Tue, May 12, 2020 at 12:38 PM Daniel Vetter wrote:
On Tue, May 12, 2020 at 3:22 PM Alex Deucher wrote:
On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
wrote:
Hi,
On Tue, 12 May
Am 12.05.20 um 22:12 schrieb Dave Airlie:
On Wed, 13 May 2020 at 04:21, Alex Deucher wrote:
On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra wrote:
On Tue, 12 May 2020 at 17:38, Daniel Vetter wrote:
Otherwise all agree, agp is a mighty mess and essentially just
crapshot outside of x86. It kin
On Tue, May 12, 2020 at 8:22 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 12:38 PM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 3:22 PM Alex Deucher wrote:
> > >
> > > On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On T
On Wed, 13 May 2020 at 04:21, Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra wrote:
> >
> > On Tue, 12 May 2020 at 17:38, Daniel Vetter wrote:
> > >
> > > Otherwise all agree, agp is a mighty mess and essentially just
> > > crapshot outside of x86. It kinda worked for the
On Tue, May 12, 2020 at 12:38 PM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 3:22 PM Alex Deucher wrote:
> >
> > On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, 12 May 2020, Rui Salvaterra wrote:
> > >
> > > > > FWIW, on my last-gen
On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra wrote:
>
> On Tue, 12 May 2020 at 17:38, Daniel Vetter wrote:
> >
> > Otherwise all agree, agp is a mighty mess and essentially just
> > crapshot outside of x86. It kinda worked for the much more static
> > allocations for dri1, but with in-kernel me
On Tue, 12 May 2020 at 17:38, Daniel Vetter wrote:
>
> Otherwise all agree, agp is a mighty mess and essentially just
> crapshot outside of x86. It kinda worked for the much more static
> allocations for dri1, but with in-kernel memory managers all the cache
> flushing issues showed up big time an
On Tue, May 12, 2020 at 3:22 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
> wrote:
> >
> > Hi,
> >
> > On Tue, 12 May 2020, Rui Salvaterra wrote:
> >
> > > > FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a
> > > > big performance diff
On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
wrote:
>
> Hi,
>
> On Tue, 12 May 2020, Rui Salvaterra wrote:
>
> > > FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a
> > > big performance difference between AGP and PCI GART. The latter was
> > > sort of usable for
Hi,
On Tue, 12 May 2020, Rui Salvaterra wrote:
> > FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a
> > big performance difference between AGP and PCI GART. The latter was
> > sort of usable for normal desktop operation, but not so much for
> > OpenGL apps (which were usable w
On Tue, 12 May 2020 at 08:58, Michel Dänzer wrote:
>
> FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big
> performance difference between AGP and PCI GART. The latter was sort of
> usable for normal desktop operation, but not so much for OpenGL apps
> (which were usable with
Hi David!
On 5/12/20 7:04 AM, David VANTYGHEM wrote:
> Im happy now that after your work, Debian and GRUB install fine on my
> iMac G3. But Xserver doesn't start, I've got an AMD Rage 128 Pro AGP 4x
> (see joined screenshot).
This is an unrelated problem as the reason why you don't have a working
Hi,
On Tue, 12 May 2020, Michel D?nzer wrote:
> > I still use powerbook G4/1.66 ( AGP4x)and
> > Pegasos 2 ( AGP x1) - I am not sure, maybe here it works in PCI mode?
> > Do you know how to check it?
>
> The radeon driver in current kernels disables AGP by default on PPC, so
> unless you're explic
On 2020-05-12 10:03 a.m., MH wrote:
>
> I still use powerbook G4/1.66 ( AGP4x)and
> Pegasos 2 ( AGP x1) - I am not sure, maybe here it works in PCI mode?
> Do you know how to check it?
The radeon driver in current kernels disables AGP by default on PPC, so
unless you're explicitly enabling it wit
ahead and remove the support from Radeon and
Nouveau and
then drop the necessary code from TTM.
For Radeon this means that we just switch over to the driver specific page
tables and
everything should more or less continue to work.
For Nouveau I'm not 100% sure, but from the code it of hand lo
Am 11.05.20 um 22:46 schrieb Alex Deucher:
On Mon, May 11, 2020 at 4:41 PM John Paul Adrian Glaubitz
wrote:
On 5/11/20 10:05 PM, Alex Deucher wrote:
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can
do it similar to Radeon.
Please comment what you think about this
On 2020-05-11 10:51 p.m., Alex Deucher wrote:
> On Mon, May 11, 2020 at 4:25 PM Rui Salvaterra wrote:
>> A segunda, 11/05/2020, 21:21, Alex Deucher escreveu:
>>>
>>> Note there is no loss of functionality here, at least on radeon
>>> hardware. It just comes down to which MMU gets used for access
Hi Alex!
On 5/11/20 10:46 PM, Alex Deucher wrote:
>>> Note there is no loss of functionality here, at least on radeon
>>> hardware. It just comes down to which MMU gets used for access to
>>> system memory, the AGP MMU on the chipset or the MMU built into the
>>> GPU. On powerpc hardware, AGP ha
A segunda, 11/05/2020, 22:23, Steve Burkhart
escreveu:
> I remember a time when GNU/Linux was something you installed on an old
> computer to make it useful again. If the Debian project wants to leave
> legacy hardware behind, I have no reason to use Debian.
>
Let's not overreact, there's no los
ng the DMA API on multiple occasions,
> need to distinct between
> > AGP and driver specific page tables etc etc...
>
> AGP isn't exclusively used on x86 but there are also a lot of PowerPC
> desktop machines (Apple
> PowerMac, Pegasos etc) that employ AGP graphics.
>
>
On Mon, May 11, 2020 at 4:25 PM Rui Salvaterra wrote:
>
>
>
> A segunda, 11/05/2020, 21:21, Alex Deucher escreveu:
>>
>>
>>
>> Note there is no loss of functionality here, at least on radeon
>> hardware. It just comes down to which MMU gets used for access to
>> system memory, the AGP MMU on the
On Mon, May 11, 2020 at 4:41 PM John Paul Adrian Glaubitz
wrote:
>
> On 5/11/20 10:05 PM, Alex Deucher wrote:
> >>> For Nouveau I'm not 100% sure, but from the code it of hand looks like we
> >>> can do it similar to Radeon.
> >>>
> >>> Please comment what you think about this.
> >>
> >> I would
only thing that works is, if the radeon driver is forced to use
PCIGART, which was even the default after install, if I remember
correctly.
Problem is that graphics acceleration over PCI is very, very slow... :-(
>>>> So the idea here is to just go ahead and remove the support from Radeon
On 5/11/20 10:05 PM, Alex Deucher wrote:
>>> For Nouveau I'm not 100% sure, but from the code it of hand looks like we
>>> can do it similar to Radeon.
>>>
>>> Please comment what you think about this.
>>
>> I would be against such a move as AGP graphics is still used by people
>> running the pow
test this on, but as far as I
know the Radeon AGP support for PowerPC is disabled for years already
because it didn't worked reliable.
So the idea here is to just go ahead and remove the support from Radeon and
Nouveau and
then drop the necessary code from TTM.
For Radeon this means that
A segunda, 11/05/2020, 21:21, Alex Deucher escreveu:
>
>
> Note there is no loss of functionality here, at least on radeon
> hardware. It just comes down to which MMU gets used for access to
> system memory, the AGP MMU on the chipset or the MMU built into the
> GPU. On powerpc hardware, AGP ha
ok G4 with Radeon graphics
enabled
on a current kernel and graphics stack and it runs fine. Not sure though whether
it currently employs all AGP features, but I would like to be able to continue
using it and so are the users on the debian-powerpc mailing list.
>>> So the idea here is to ju
ktop
> machines (Apple
> PowerMac, Pegasos etc) that employ AGP graphics.
>
> > So the idea here is to just go ahead and remove the support from Radeon and
> > Nouveau and
> > then drop the necessary code from TTM.
> > For Radeon this means that we just switch over to
iple occasions, need to
> distinct between
> AGP and driver specific page tables etc etc...
AGP isn't exclusively used on x86 but there are also a lot of PowerPC desktop
machines (Apple
PowerMac, Pegasos etc) that employ AGP graphics.
> So the idea here is to just go ahead and remove the s
On Thu, Jul 06, 2017 at 05:37:42AM -0600, Thomas Carlson wrote:
> I’m no longer using Debian on my PowerPC Mac, so would you please
> remove my email address from your list? Thanks.
You have to do this yourself:
> https://lists.debian.org/debian-powerpc/
--
.''`. John P
I’m no longer using Debian on my PowerPC Mac, so would you please remove my
email address from your list? Thanks.
Tom
__
Thomas Carlson
2319 La Senda St.
Santa Fe, NM 87505
Hi,
Marco d'Itri wrote:
> On Jan 10, Cyril Brulebois wrote:
> > We have a bug report with a patch by Marco against debootstrap (see
> > attachment), which changes how devices are generated; I can't really
> > tell how much this might affect all of you (especially with debootstrap
> It is not supp
On Jan 10, Cyril Brulebois wrote:
> We have a bug report with a patch by Marco against debootstrap (see
> attachment), which changes how devices are generated; I can't really
> tell how much this might affect all of you (especially with debootstrap
It is not supposed to, since both hurd and kfree
Hi ports people,
I'm not exactly sure what happened with debian-ports@ (I think there
were some planned changes but I don't remember the outcome), so I'm
explicitly sending this to bsd/hurd lists since I suspect the linux
ports are less likely to be affected by this.
We have a bug report with a p
gt; of waiting it eventually continued to run. The kernel messages
> shown below showed up around the time the OS continued to run.
>
> Any thoughts about that one?
>
> Thanks & best regards,
>
> Frank
>
>
> ########
rank
##
[ ... memory remove DLPAR here ... ]
[ 1718.704600] Trying to free nonexistent resource
<8f00-8fff>
[ 1966.342008] [ cut here ]
[ 1966.342043] WARNING: at
/usr
On Tue, Jan 3, 2012 at 11:15 PM, Frank Fegert wrote:
> Hello,
>
> On Sat, Dec 31, 2011 at 01:14:12PM +0100, nello martuscielli wrote:
>> why don't you directly build them from sources?
>> I cannot test drmgr as my old machines don't support it but i'm able
>> to build these utilities on a cruxppc
RATION=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_RPA=y
CONFIG_HOTPLUG_PCI_RPA_DLPAR=y
Within the kernel i've traced the call path of the memory remove
operation down to the __release_region function in ./kernel/resource.c.
At the moment it fails at this point (empty lines removed):
void
Hello,
On Sat, Dec 31, 2011 at 01:14:12PM +0100, nello martuscielli wrote:
> why don't you directly build them from sources?
> I cannot test drmgr as my old machines don't support it but i'm able
> to build these utilities on a cruxppc 64bit system
> thus, i guess, you can do the same.
well, that
From: nello martuscielli
To: Frank Fegert
Cc: "debian-powerpc@lists.debian.org"
Date: 31/12/2011 07:50 a.m.
Subject:Re: Remove memory DLPAR operation fails for Debian 6.0.3 on IBM
Power6 and Power7 Systems
On Fri, Dec 30, 2011 at 1:06 PM
On Fri, Dec 30, 2011 at 1:06 PM, Frank Fegert wrote:
> Hello all,
>
> i'm currently trying to get the whole DLPAR/LPM thing to work on our Debian
> (v6.0.3) Linux LPARs. So far i've sucessfully converted the following RPMs
> to DEB with alien:
> devices.chrp.base.servicerm_2.3.0.0-11231
> dy
rovided by the RPMs things look rather good now. I can sucessfully add
and remove processors, and i can successfully add memory. Upon memory removal i
get an error (see below) from the drmgr command. This is reproducible even if
drmgr is issued on the command line, so it's probably no
> --- a/include/asm-powerpc/unistd.h
> +++ b/include/asm-powerpc/unistd.h
> @@ -276,7 +276,7 @@ #endif
> #define __NR_rtas 255
> #define __NR_sys_debug_setcontext 256
> /* Number 257 is reserved for vserver */
> -/* 258 currently unused */
> +#define __NR_migrate_pages 258
> #
On Mon, 2006-10-30 at 15:40 +0100, Andi Kleen wrote:
> >
> > Andi, can you fix libnuma ? :)
>
> I fixed libnuma to return ENOSYS on ppc, still waiting for an official
> syscall number
>From a pending patch by Stephen:
--- a/include/asm-powerpc/unistd.h
+++ b/include/asm-powerpc/unistd.h
@@ -276
>
> Andi, can you fix libnuma ? :)
I fixed libnuma to return ENOSYS on ppc, still waiting for an official
syscall number
-Andi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Oct 30, 2006 at 04:55:20PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2006-10-30 at 16:29 +1100, Ian Wienand wrote:
> > On Mon, Oct 30, 2006 at 04:06:31PM +1100, Benjamin Herrenschmidt wrote:
> > > Or if not ,what is the exact missing bit ? numactl should work on
> > > powerpc and is us
On Mon, 2006-10-30 at 17:13 +1100, Ian Wienand wrote:
> On Mon, Oct 30, 2006 at 04:56:09PM +1100, Benjamin Herrenschmidt wrote:
> > Can't you just apply a debian patch fixing the syscall number and do a
> > build with that ? It doesn't need the syscall to work, and as I said, we
> > do use it regul
On Mon, Oct 30, 2006 at 04:56:09PM +1100, Benjamin Herrenschmidt wrote:
> Can't you just apply a debian patch fixing the syscall number and do a
> build with that ? It doesn't need the syscall to work, and as I said, we
> do use it regulary, I would be fairly annoyed if it disappeared
> completely
On Mon, 2006-10-30 at 16:29 +1100, Ian Wienand wrote:
> On Mon, Oct 30, 2006 at 04:06:31PM +1100, Benjamin Herrenschmidt wrote:
> > Or if not ,what is the exact missing bit ? numactl should work on
> > powerpc and is useful on it. It shouldn't be dropped just bcs there is a
> > temporary build fail
On Mon, 2006-10-30 at 16:29 +1100, Ian Wienand wrote:
> On Mon, Oct 30, 2006 at 04:06:31PM +1100, Benjamin Herrenschmidt wrote:
> > Or if not ,what is the exact missing bit ? numactl should work on
> > powerpc and is useful on it. It shouldn't be dropped just bcs there is a
> > temporary build fail
On Mon, Oct 30, 2006 at 04:06:31PM +1100, Benjamin Herrenschmidt wrote:
> Or if not ,what is the exact missing bit ? numactl should work on
> powerpc and is useful on it. It shouldn't be dropped just bcs there is a
> temporary build failure.
I wish to drop it for now firstly because (and this is m
On Mon, 2006-10-30 at 15:57 +1100, Ian Wienand wrote:
> On Mon, Oct 30, 2006 at 03:47:25PM +1100, Benjamin Herrenschmidt wrote:
> > Ugh ? Is there a replacement ? numactl is useful on 64 bits powerpc
> > machines. Or is numactl itself being replaced by something else ?
>
> The latest libnuma depen
7;t have the
> > kernel support to build the latest versions. It's very unlikely
> > anyone cares about this package on those architectures.
> >
> > Could you please remove them from unstable so the package can make it
> > into testing.
>
> Ugh ? Is there
On Mon, Oct 30, 2006 at 03:47:25PM +1100, Benjamin Herrenschmidt wrote:
> Ugh ? Is there a replacement ? numactl is useful on 64 bits powerpc
> machines. Or is numactl itself being replaced by something else ?
The latest libnuma depends on, in particular, the migrate_pages system
call, which isn't
cares about this package on those architectures.
>
> Could you please remove them from unstable so the package can make it
> into testing.
Ugh ? Is there a replacement ? numactl is useful on 64 bits powerpc
machines. Or is numactl itself being replaced by something else ?
Ben.
--
To UNS
Package: ftp.debian.org
Severity: normal
Hi,
I have dropped Alpha and PowerPC from numactl, as they don't have the
kernel support to build the latest versions. It's very unlikely
anyone cares about this package on those architectures.
Could you please remove them from unstable so t
Hi-
based on the exim system filter that i found here:
ftp://ftp.exim.org/pub/filter/system_filter.exim
and adding the following to my /etc/exim.conf file:
message_filter = /etc/exim/system_filter.exim
message_body_visible = 5000
exim seems to be rejecting messages that contain potentially h
Stop sending me junk.
Remove
Unsubscribe
_
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
On Sat, Aug 10, 2002 at 06:42:19PM +0200, Roland Wegmann wrote:
> Hello
>
> I have some old kernels that I want to remove. Can I do this manually simply
> by removing the kernel, its moduls and the system.map? Or are there other
> files that have to be deleted?
>
> I a
Hello
I have some old kernels that I want to remove. Can I do this manually simply
by removing the kernel, its moduls and the system.map? Or are there other
files that have to be deleted?
I ask, because I have an 2.2.19 kernel that dpkg doesn't know:
dpkg - warning; ignoring request to r
72 matches
Mail list logo
