On 03/24/2017 06:13 PM, Riccardo Mottola wrote:
> yes, that works even when using the stock kernel and I can stop disabling the
> atyfb.
That's great to hear!
> Very good - we have a better solution than compiling different kernels!
> Perhaps it
> could be at least be mentioned or best
Hi Cascardo,
Thadeu Lima de Souza Cascardo wrote:
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
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.
> > >
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
On 03/24/2017 11:34 AM, John Paul Adrian Glaubitz wrote:
> That's actually a difficult question. Looking at what the option does,
> it's actually a security feature [1] and disabling it would take away
> security for a lot of users.
Sorry, forgot to provide the link:
>
Hi Riccardo!
On 03/24/2017 10:30 AM, Riccardo Mottola wrote:
> I used the debian supplied config except the IO strict devmem setting.
> It took almost 2 days to build on the iBook using a SSD! :)
>
> X11 now works, so this is the proof.
> Furthermore the description says that the setting is
On 24/03/17 06:30 PM, Riccardo Mottola wrote:
> Michel Dänzer wrote:
>>> >[ 175.085] (EE) MACH64(0): Unable to map linear aperture. Invalid
>>> >argument (22)
>> This could still be due to CONFIG_IO_STRICT_DEVMEM, assuming offb
>> registers the linear VRAM aperture.
>>
>> Note that I wouldn't
Hi,
Michel Dänzer wrote:
>[ 175.085] (EE) MACH64(0): Unable to map linear aperture. Invalid
>argument (22)
This could still be due to CONFIG_IO_STRICT_DEVMEM, assuming offb
registers the linear VRAM aperture.
Note that I wouldn't count on the kernel package maintainers honing a
request to
On 16/03/17 08:21 AM, Riccardo Mottola wrote:
>
> X11 doesn't start, but the error message changed and goes further.
> Before it essentially failed to detect my card, now I see in Xorg.log:
[...]
> [ 175.085] (EE) MACH64(0): Unable to map linear aperture. Invalid
> argument (22)
This could
Hi Adrian,
John Paul Adrian Glaubitz wrote:
Yes, you would need to file a bug report against src:linux.
I can do that if it turns out to fix your issue.
do yo have means of quickly generating a current kernel with that
options back off? I would test it.
In the meanwhile I tried to turn
On 03/15/2017 10:09 AM, Riccardo Mottola wrote:
> could we turn that option back (if proven that it is it)?
Yes, you would need to file a bug report against src:linux.
I can do that if it turns out to fix your issue.
> To test this I would need to run the new kernel without
> the kernel atyfb
Hi Michel,
Michel Dänzer wrote:
Could CONFIG_IO_STRICT_DEVMEM=y be the issue?
Looks like that's it. According to the description of that option, it
prevents userspace from accessing I/O memory ranges which are already
claimed by a kernel driver. I.e. you have to choose whether you want to
let
On 15/03/17 08:44 AM, Riccardo Mottola wrote:
> Michel Dänzer wrote:
>>> Can you provide the two /boot/config-4.8* files? If you attach them
>>> > directly, maybe compress them e.g. with gzip to avoid running into
>>> > mailing list size limits.
>> Or maybe just attach the output of diff -u for
On 03/15/2017 12:44 AM, Riccardo Mottola wrote:
> Interesting is that this is 4.8.0-1 while the header advertises 4.8.5!
Not really. 4.8.0 is the ABI version while 4.8.5 is the kernel version.
This means that modules built for a 4.8.3 kernel will also work for a
4.8.5 kernel without having to
Hi,
Michel Dänzer wrote:
Can you provide the two /boot/config-4.8* files? If you attach them
> directly, maybe compress them e.g. with gzip to avoid running into
> mailing list size limits.
Or maybe just attach the output of diff -u for the two files.
attached (well, I forgot unified, but it
Hi,
Michel Dänzer wrote:
Can you provide the two /boot/config-4.8* files? If you attach them
> directly, maybe compress them e.g. with gzip to avoid running into
> mailing list size limits.
Or maybe just attach the output of diff -u for the two files.
attached (well, I forgot unified, but it
On 09/03/17 10:34 AM, Michel Dänzer wrote:
> On 09/03/17 04:19 AM, Riccardo Mottola wrote:
>>
>> Did debian change something in the kernel between rc8 and -1 (patches,
>> config options) or did we uncover an upstream kernel bug?
>
> Can you provide the two /boot/config-4.8* files? If you attach
On 09/03/17 04:19 AM, Riccardo Mottola wrote:
> On 03/07/17 13:11, Riccardo Mottola wrote:
>>
>> For the 4.8 series instead:
>>
>> 4.8.0-rc8-powerpc #1 Debian 4.8~rc8-1~exp1 (2016-09-26)
>> 4.8.0-1 Debian 4.8.5 -> broken
>>
>> Since I saw no other 4.7 series, I can see that the breakage happened
Hi,
On 03/07/17 13:11, Riccardo Mottola wrote:
For the 4.8 series instead:
4.8.0-rc8-powerpc #1 Debian 4.8~rc8-1~exp1 (2016-09-26)
4.8.0-1 Debian 4.8.5 -> broken
Since I saw no other 4.7 series, I can see that the breakage happened
already in the 4.8 series:, somewhere between:
On 03/07/2017 01:11 PM, Riccardo Mottola wrote:
> How can I know when an update was available? Or, better which intermediate
> versions are or have been available between my two kernels versions?
You search for the "linux" source package on the snapshots page:
>
Hi,
John Paul Adrian Glaubitz wrote:
Then you need to provide as many datapoints as possible. Trying to
bisect the
kernel version which broke the driver is already the right idea.
I would start working with snapshot.debian.org to find the Debian kernel
version which broke the driver. Then we
Hi,
Michel Dänzer wrote:
AFAICT Option "Noaccel" completely disables hardware acceleration.
Together with Option "shadow_fb", it should operate more or less the
same way the fbdev driver does. If you're still seeing a difference in
performance between the two drivers, having a more detailed
On 06/03/17 07:04 PM, Riccardo Mottola wrote:
>
> don't fight over kernel modules :) le'ts just get the thing working again.
Right, that's always my intent. :)
>> Anyway, I looked at Riccardo's original post again and noticed that his
>> xorg.conf has options disabling all hardware
On 06/03/17 10:08 PM, John Paul Adrian Glaubitz wrote:
> On Mon, Mar 06, 2017 at 02:00:03PM +0100, Wolfgang Pfeiffer wrote:
>> No. He wasn't rude. Not a bit.
>
> Yes, *I* perceived that as rude.
>
>> He simply was - as most of the time here
>> - very specific, terse and up to the relevant
On Mon, Mar 06, 2017 at 02:00:03PM +0100, Wolfgang Pfeiffer wrote:
> No. He wasn't rude. Not a bit.
Yes, *I* perceived that as rude.
> He simply was - as most of the time here
> - very specific, terse and up to the relevant technical points.
He was talking to me as if I was an idiot. It is
On Mon, 2017-03-06 at 08:59 +0100, John Paul Adrian Glaubitz wrote:
>
> >
> > On Mar 6, 2017, at 8:36 AM, Michel Dänzer
> > wrote:
> >
> > >
> > > On 06/03/17 04:20 PM, John Paul Adrian Glaubitz wrote:
> > > Correct me if I'm wrong, but in order to use atyfb you have to
>
On 03/06/2017 11:04 AM, Riccardo Mottola wrote:
> Exactly, that "proof" means that the changes comes from the kernel or
> that the driver needs updating to work with the new kernel.
Or the kernel needs to be fixed in case it's a regression.
> Compiling kernels is a bit tight on this iBook. What
Hi,
John Paul Adrian Glaubitz wrote:
Your machine is loading the framebuffer kernel driver which will only work
when you configure X.Org to use the "fbdev" driver. You can either set your
display driver to "fbdev" (see further below) or disable the framebuffer driver
on the kernel command line
Hi guys,
don't fight over kernel modules :) le'ts just get the thing working again.
Michel Dänzer wrote:
But in any case, using fbdev should always work. The "mach64" driver
>may be broken because it's more or less orphaned.
Except for the part where Riccardo says that the same userspace
On 03/06/2017 09:06 AM, Michel Dänzer wrote:
>> On a sidenote: Please be more polite on this list. There is no need to
>> be that rude and condescending.
>
> What specifically did you find rude and condescending? It's an honest
> question. I know my writing tends to be too concise, but I'm
On 06/03/17 04:59 PM, John Paul Adrian Glaubitz wrote:
>> On Mar 6, 2017, at 8:36 AM, Michel Dänzer wrote:
>>
>> Anyway, I looked at Riccardo's original post again and noticed that his
>> xorg.conf has options disabling all hardware acceleration of
>> xserver-xorg-video-mach64
> On Mar 6, 2017, at 8:36 AM, Michel Dänzer wrote:
>
>> On 06/03/17 04:20 PM, John Paul Adrian Glaubitz wrote:
>> Correct me if I'm wrong, but in order to use atyfb you have to use
>> the fbdev xorg driver. That's my main point.
>
> If you mean for Xorg to use atyfb,
On 06/03/17 04:20 PM, John Paul Adrian Glaubitz wrote:
> Correct me if I'm wrong, but in order to use atyfb you have to use
> the fbdev xorg driver. That's my main point.
If you mean for Xorg to use atyfb, that's technically correct, but I'm
not sure how it's relevant.
> I was talking about the
Correct me if I'm wrong, but in order to use atyfb you have to use the fbdev
xorg driver. That's my main point.
Regarding "mach64" I just said it *may* not work properly when atyfb is loaded
because it needs to access the hardware itself, so I would try disabling atyfb
for a test. If I
On 06/03/17 02:29 PM, John Paul Adrian Glaubitz wrote:
> Please re-read what I wrote. I never claimed it's a KMS driver.
Nor did I claim that you claimed that. Just what you wrote would make
sense if mach64 was a KMS driver, but it doesn't because it's not.
--
Earthling Michel Dänzer
Please re-read what I wrote. I never claimed it's a KMS driver.
> On Mar 6, 2017, at 4:05 AM, Michel Dänzer wrote:
>
>> On 04/03/17 04:49 AM, John Paul Adrian Glaubitz wrote:
>>> On 03/02/2017 07:44 PM, Riccardo Mottola wrote:
>>> [4.174055] atyfb :00:10.0: enabling
On 04/03/17 04:49 AM, John Paul Adrian Glaubitz wrote:
> On 03/02/2017 07:44 PM, Riccardo Mottola wrote:
>> [4.174055] atyfb :00:10.0: enabling device (0086 -> 0087)
>> [4.174138] atyfb: using auxiliary register aperture
>> [4.174809] atyfb: 3D RAGE Mobility L (Mach64 LN, AGP 2x)
On 03/03/2017 08:49 PM, John Paul Adrian Glaubitz wrote:
> Then it should be possible to use the "mach64" driver *if* the kernel has
> support for the hardware. However, looking at the information available in
> the X.Org wiki [1], it seems the mach64 DRM module is currently not part of
> the
Hi!
On 03/02/2017 07:44 PM, Riccardo Mottola wrote:
> [4.174055] atyfb :00:10.0: enabling device (0086 -> 0087)
> [4.174138] atyfb: using auxiliary register aperture
> [4.174809] atyfb: 3D RAGE Mobility L (Mach64 LN, AGP 2x) [0x4c4e rev 0x64]
> [4.174896] atyfb: 4M SDRAM (2:1)
Hi,
luigi burdo wrote:
another thing.
is the gpu in slot 0:16:0 ?
can you share an lspci ?
Yes it is (should be actually AGP). I already posted dmesg and lspci
with the "new" kernel.
This is with the working one. Looks identical to me:
:00:0b.0 Host bridge: Apple Inc. UniNorth AGP
(mmio aperture)
Hi Riccardo,
can it be something related the kernel?
Ciao
Luigi
Da: Riccardo Mottola <riccardo.mott...@libero.it>
Inviato: giovedì 2 marzo 2017 10.01
A: debian-powerpc@lists.debian.org
Oggetto: Re: Xorg fails on ATI after update (mmio apert
Hi,
luigi burdo wrote:
can it be something related the kernel?
I fear it is! I still had 4.7.0-1 instead of 4.9.0-2 and booted that.
All the rest being equals, X starts and works.
So either it is a kernel issue or still a bad X-kernel interaction.
Maybe John Paul gets wiser?
This lspci
Hi John Paul,
John Paul Adrian Glaubitz wrote:
Can you please post the output of the dmesg and lspci commands?
if course, this is lspci:
:00:0b.0 Host bridge: Apple Inc. UniNorth AGP
:00:10.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Device 4c4e (rev 64)
On 03/02/2017 10:01 AM, Riccardo Mottola wrote:
> any clue about this? I saw some updates, but no X package and the issue still
> happens.
> It looks like my card can't be detected at all.
> Anybody else is running on Mac hardwware with ATI currently?
Can you please post the output of the dmesg
Hi Riccardo,
can it be something related the kernel?
Ciao
Luigi
Da: Riccardo Mottola <riccardo.mott...@libero.it>
Inviato: giovedì 2 marzo 2017 10.01
A: debian-powerpc@lists.debian.org
Oggetto: Re: Xorg fails on ATI after update (mmio aperture)
Hi all
Hi all,
any clue about this? I saw some updates, but no X package and the issue
still happens.
It looks like my card can't be detected at all.
Anybody else is running on Mac hardwware with ATI currently?
Riccardo
Riccardo Mottola wrote:
Hi,
I did update debian on my iBook G3 with
Hi,
I did update debian on my iBook G3 with current.
X doesn't start and in the xorg log I see the section below.
How can I solve this? What happened?
Riccardo
[ 392.682] (II) systemd-logind: took control of session
/org/freedesktop/login1/session/_31
[ 392.688] (--) PCI:*(0:0:16:0)
47 matches
Mail list logo