Xorg fails on ATI after update (mmio aperture)

[Riccardo Mottola]

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) 1002:4c4e:0000:0000 rev 100, Mem @
0x91000000/16777216, 0x90000000/4096, I/O @ 0x00000400/256, BIOS @
0x????????/
131072
[ 392.691] (II) LoadModule: "glx"
[ 392.698] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 392.803] (II) Module glx: vendor="X.Org Foundation"
[ 392.804] compiled for 1.19.1, module version = 1.0.0
[ 392.804] ABI class: X.Org Server Extension, version 10.0
[ 392.804] (II) LoadModule: "ati"
[ 392.806] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[ 392.813] (II) Module ati: vendor="X.Org Foundation"
[ 392.813] compiled for 1.19.0, module version = 7.8.0
[ 392.813] Module class: X.Org Video Driver
[ 392.813] ABI class: X.Org Video Driver, version 23.0
[ 392.813] (II) LoadModule: "mach64"
[ 392.815] (II) Loading /usr/lib/xorg/modules/drivers/mach64_drv.so
[ 392.823] (II) Module mach64: vendor="X.Org Foundation"
[ 392.823] compiled for 1.19.0, module version = 6.9.5
[ 392.823] Module class: X.Org Video Driver
[ 392.823] ABI class: X.Org Video Driver, version 23.0
[ 392.824] (II) MACH64: Driver for ATI Mach64 chipsets
[ 392.826] (II) MACH64(0): Creating default Display subsection in
Screen section
"Default Screen" for depth/fbbpp 24/32
[ 392.827] (**) MACH64(0): Depth 24, (--) framebuffer bpp 32
[ 392.827] (**) MACH64(0): Option "Noaccel" "True"
[ 392.827] (**) MACH64(0): Option "force_pci_mode" "True"
[ 392.827] (**) MACH64(0): Option "shadow_fb" "True"
[ 392.829] (EE) Unable to map mmio aperture. Invalid argument (22)
[ 392.829] (WW) MACH64: Mach64 in slot 0:16:0 could not be detected!
[ 392.833] (II) UnloadModule: "mach64"
[ 392.834] (EE) Screen(s) found, but none have a usable configuration.
[ 392.834] (EE)
Fatal server error:
[ 392.834] (EE) no screens found(EE)
[ 392.834] (EE)

[Riccardo Mottola]

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

Post by Riccardo Mottola
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
0x????????/
131072
[ 392.691] (II) LoadModule: "glx"
[ 392.698] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 392.803] (II) Module glx: vendor="X.Org Foundation"
[ 392.804] compiled for 1.19.1, module version = 1.0.0
[ 392.804] ABI class: X.Org Server Extension, version 10.0
[ 392.804] (II) LoadModule: "ati"
[ 392.806] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[ 392.813] (II) Module ati: vendor="X.Org Foundation"
[ 392.813] compiled for 1.19.0, module version = 7.8.0
[ 392.813] Module class: X.Org Video Driver
[ 392.813] ABI class: X.Org Video Driver, version 23.0
[ 392.813] (II) LoadModule: "mach64"
[ 392.815] (II) Loading /usr/lib/xorg/modules/drivers/mach64_drv.so
[ 392.823] (II) Module mach64: vendor="X.Org Foundation"
[ 392.823] compiled for 1.19.0, module version = 6.9.5
[ 392.823] Module class: X.Org Video Driver
[ 392.823] ABI class: X.Org Video Driver, version 23.0
[ 392.824] (II) MACH64: Driver for ATI Mach64 chipsets
[ 392.826] (II) MACH64(0): Creating default Display subsection in
Screen section
"Default Screen" for depth/fbbpp 24/32
[ 392.827] (**) MACH64(0): Depth 24, (--) framebuffer bpp 32
[ 392.827] (**) MACH64(0): Option "Noaccel" "True"
[ 392.827] (**) MACH64(0): Option "force_pci_mode" "True"
[ 392.827] (**) MACH64(0): Option "shadow_fb" "True"
[ 392.829] (EE) Unable to map mmio aperture. Invalid argument (22)
[ 392.829] (WW) MACH64: Mach64 in slot 0:16:0 could not be detected!
[ 392.833] (II) UnloadModule: "mach64"
[ 392.834] (EE) Screen(s) found, but none have a usable configuration.
[ 392.834] (EE)
[ 392.834] (EE) no screens found(EE)
[ 392.834] (EE)

[John Paul Adrian Glaubitz]

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 and lspci commands?

Thanks,
Adrian

[Riccardo Mottola]

Hi John Paul,

Post by John Paul Adrian Glaubitz
Can you please post the output of the dmesg and lspci commands?

if course, this is lspci:
0000:00:0b.0 Host bridge: Apple Inc. UniNorth AGP
0000:00:10.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Device 4c4e (rev 64)
0001:10:0b.0 Host bridge: Apple Inc. UniNorth PCI
0001:10:17.0 Unassigned class [ff00]: Apple Inc. KeyLargo Mac I/O (rev 02)
0001:10:18.0 USB controller: Apple Inc. KeyLargo USB
0001:10:19.0 USB controller: Apple Inc. KeyLargo USB
0002:20:0b.0 Host bridge: Apple Inc. UniNorth Internal PCI
0002:20:0f.0 Ethernet controller: Apple Inc. UniNorth GMAC (Sun GEM)

which looks consistent with:
[ 392.688] (--) PCI:*(0:0:16:0) 1002:4c4e:0000:0000 rev 100, Mem @
0x91000000/16777216, 0x90000000/4096, I/O @ 0x00000400/256, BIOS @
0x????????/

and below my dmesg

One warning looks menacious
[ 0.214392] pci 0001:10:18.0: enabling device (0000 -> 0002)
[ 0.272354] Apple USB OHCI 0001:10:19.0 disabled by firmware
[ 0.272407] pci 0001:10:19.0: Can't enable PCI device, BIOS handoff
failed.
[ 0.272476] PCI: CLS mismatch (32 != 1020), using 32 bytes

However :10:19 looks like an USB controller, the video is on :0:10

Riccardo

[ 0.000000] Total memory = 160MB; using 512kB for hash table (at
c1680000)
[ 0.000000] Linux version 4.9.0-2-powerpc
(debian-***@lists.debian.org) (gcc version 6.3.0 20170221 (Debian
6.3.0-8) ) #1 Debian 4.9.13-1 (2017-02-27)
[ 0.000000] Found initrd at 0xc1700000:0xc2712000
[ 0.000000] Found UniNorth memory controller & host bridge @
0xf8000000 revision: 0x03
[ 0.000000] Mapped at 0xff7c0000
[ 0.000000] Found a Keylargo mac-io controller, rev: 2, mapped at
0xff740000
[ 0.000000] PowerMac motherboard: iBook (first generation)
[ 0.000000] via-pmu: Server Mode is disabled
[ 0.000000] PMU driver v2 initialized for Core99, firmware: 0c
[ 0.000000] Using PowerMac machine description
[ 0.000000] bootconsole [udbg0] enabled
[ 0.000000] -----------------------------------------------------
[ 0.000000] Hash_size = 0x80000
[ 0.000000] phys_mem_size = 0xa000000
[ 0.000000] dcache_bsize = 0x20
[ 0.000000] icache_bsize = 0x20
[ 0.000000] cpu_features = 0x0000000000220472
[ 0.000000] possible = 0x0000000005a6fd7f
[ 0.000000] always = 0x0000000000020000
[ 0.000000] cpu_user_features = 0x8c000001 0x00000000
[ 0.000000] mmu_features = 0x00000001
[ 0.000000] Hash = 0xc1680000
[ 0.000000] Hash_mask = 0x1fff
[ 0.000000] -----------------------------------------------------
[ 0.000000] Found UniNorth PCI host bridge at 0x00000000f0000000.
Firmware bus number: 0->0
[ 0.000000] PCI host bridge /***@f0000000 ranges:
[ 0.000000] MEM 0x00000000f1000000..0x00000000f1ffffff ->
0x00000000f1000000
[ 0.000000] IO 0x00000000f0000000..0x00000000f07fffff ->
0x0000000000000000
[ 0.000000] MEM 0x0000000090000000..0x000000009fffffff ->
0x0000000090000000
[ 0.000000] Found UniNorth PCI host bridge at 0x00000000f2000000.
Firmware bus number: 0->0
[ 0.000000] PCI host bridge /***@f2000000 (primary) ranges:
[ 0.000000] MEM 0x00000000f3000000..0x00000000f3ffffff ->
0x00000000f3000000
[ 0.000000] IO 0x00000000f2000000..0x00000000f27fffff ->
0x0000000000000000
[ 0.000000] MEM 0x0000000080000000..0x000000008fffffff ->
0x0000000080000000
[ 0.000000] Found UniNorth PCI host bridge at 0x00000000f4000000.
Firmware bus number: 0->0
[ 0.000000] PCI host bridge /***@f4000000 ranges:
[ 0.000000] MEM 0x00000000f5000000..0x00000000f5ffffff ->
0x00000000f5000000
[ 0.000000] IO 0x00000000f4000000..0x00000000f47fffff ->
0x0000000000000000
[ 0.000000] nvram: Checking bank 0...
[ 0.000000] nvram: gen0=994, gen1=995
[ 0.000000] nvram: Active bank is: 1
[ 0.000000] nvram: OF partition at 0x210
[ 0.000000] nvram: XP partition at 0x1220
[ 0.000000] nvram: NR partition at 0x1320
[ 0.000000] Top of RAM: 0xa000000, Total RAM: 0xa000000
[ 0.000000] Memory hole size: 0MB
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x0000000009ffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000009ffffff]
[ 0.000000] Initmem setup node 0 [mem
0x0000000000000000-0x0000000009ffffff]
[ 0.000000] On node 0 totalpages: 40960
[ 0.000000] free_area_init_node: node 0, pgdat c0840d1c, node_mem_map
c9e7c000
[ 0.000000] DMA zone: 360 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 40960 pages, LIFO batch:7
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 40600
[ 0.000000] Kernel command line:
root=UUID=e6f9d31d-8122-4900-ad44-9963eeff5310 ro ramdisk_size=8192
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072
bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Sorting __ex_table...
[ 0.000000] Memory: 135004K/163840K available (5992K kernel code,
548K rwdata, 1588K rodata, 420K init, 1407K bss, 28836K reserved, 0K
cma-reserved, 0K highmem)
[ 0.000000] Kernel virtual memory layout:
[ 0.000000] * 0xfffcf000..0xfffff000 : fixmap
[ 0.000000] * 0xff800000..0xffc00000 : highmem PTEs
[ 0.000000] * 0xfdebc000..0xff800000 : early ioremap
[ 0.000000] * 0xcb000000..0xfdebc000 : vmalloc & ioremap
[ 0.000000] NR_IRQS:512 nr_irqs:512 16
[ 0.000000] mpic: Resetting
[ 0.000000] mpic: Setting up MPIC " MPIC 1 " version 1.2 at
80040000, max 1 CPUs
[ 0.000000] mpic: ISU size: 64, shift: 6, mask: 3f
[ 0.000000] mpic: Initializing for 64 sources
[ 0.000000] GMT Delta read from XPRAM: 120 minutes, DST: on
[ 0.000000] time_init: decrementer frequency = 16.644583 MHz
[ 0.000000] time_init: processor frequency = 299.999997 MHz
[ 0.000036] clocksource: timebase: mask: 0xffffffffffffffff
max_cycles: 0x3d6b85d44, max_idle_ns: 440795202281 ns
[ 0.000834] clocksource: timebase mult[3c14611a] shift[24] registered
[ 0.001279] clockevent: decrementer mult[442d1c4] shift[32] cpu[0]
[ 0.002517] Console: colour dummy device 80x25
[ 0.002913] console [tty0] enabled
[ 0.003283] bootconsole [udbg0] disabled
[ 0.003774] pmac_zilog: serial modem detected
[ 0.004269] pid_max: default: 32768 minimum: 301
[ 0.004735] Security Framework initialized
[ 0.004774] Yama: disabled by default; enable with sysctl kernel.yama.*
[ 0.004869] AppArmor: AppArmor disabled by boot time parameter
[ 0.005042] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.005083] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.007223] ftrace: allocating 19998 entries in 59 pages
[ 0.073291] devtmpfs: initialized
[ 0.074570] OF: Duplicate name in PowerPC,***@0, renamed to "l2-cache#1"
[ 0.083997] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.084081] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 0.085337] NET: Registered protocol family 16
[ 0.089151] KeyWest i2c @0x80018000 irq 26
/***@f2000000/mac-***@17/***@18000
[ 0.089207] channel 0 bus <multibus>
[ 0.089275] PMU i2c /***@f2000000/mac-***@17/via-***@16000
[ 0.089306] channel 1 bus <multibus>
[ 0.089361] channel 2 bus <multibus>
[ 0.090492] PCI: Probing PCI hardware
[ 0.090957] PCI host bridge to bus 0000:00
[ 0.091021] pci_bus 0000:00: root bus resource [io
0x802000-0x1001fff] (bus address [0x0000-0x7fffff])
[ 0.091104] pci_bus 0000:00: root bus resource [mem
0xf1000000-0xf1ffffff]
[ 0.091152] pci_bus 0000:00: root bus resource [mem
0x90000000-0x9fffffff]
[ 0.091205] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.091256] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
[ 0.091367] pci 0000:00:0b.0: [106b:0020] type 00 class 0x060000
[ 0.091976] pci 0000:00:10.0: [1002:4c4e] type 00 class 0x030000
[ 0.092028] pci 0000:00:10.0: reg 0x10: [mem 0x91000000-0x91ffffff]
[ 0.092051] pci 0000:00:10.0: reg 0x14: [io 0x802400-0x8024ff]
[ 0.092074] pci 0000:00:10.0: reg 0x18: [mem 0x90000000-0x90000fff]
[ 0.092123] pci 0000:00:10.0: reg 0x30: [mem 0x90020000-0x9003ffff pref]
[ 0.092267] pci 0000:00:10.0: supports D1 D2
[ 0.092862] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[ 0.093274] PCI host bridge to bus 0001:10
[ 0.093341] pci_bus 0001:10: root bus resource [io 0x0000-0x7fffff]
[ 0.093388] pci_bus 0001:10: root bus resource [mem
0xf3000000-0xf3ffffff]
[ 0.093435] pci_bus 0001:10: root bus resource [mem
0x80000000-0x8fffffff]
[ 0.093483] pci_bus 0001:10: root bus resource [bus 10-ff]
[ 0.093529] pci_bus 0001:10: busn_res: [bus 10-ff] end is updated to ff
[ 0.093613] pci 0001:10:0b.0: [106b:001f] type 00 class 0x060000
[ 0.094122] pci 0001:10:17.0: [106b:0022] type 00 class 0xff0000
[ 0.094160] pci 0001:10:17.0: reg 0x10: [mem 0x80000000-0x8007ffff]
[ 0.094645] pci 0001:10:18.0: [106b:0019] type 00 class 0x0c0310
[ 0.094680] pci 0001:10:18.0: reg 0x10: [mem 0x80080000-0x80080fff]
[ 0.095146] pci 0001:10:19.0: [106b:0019] type 00 class 0x0c0310
[ 0.095180] pci 0001:10:19.0: reg 0x10: [mem 0x00000000-0x00000fff]
[ 0.095879] pci_bus 0001:10: busn_res: [bus 10-ff] end is updated to 10
[ 0.096319] PCI host bridge to bus 0002:20
[ 0.096391] pci_bus 0002:20: root bus resource [io
0xff7fe000-0xffffdfff] (bus address [0x0000-0x7fffff])
[ 0.096455] pci_bus 0002:20: root bus resource [mem
0xf5000000-0xf5ffffff]
[ 0.096504] pci_bus 0002:20: root bus resource [bus 20-ff]
[ 0.096550] pci_bus 0002:20: busn_res: [bus 20-ff] end is updated to ff
[ 0.096634] pci 0002:20:0b.0: [106b:001e] type 00 class 0x060000
[ 0.097150] pci 0002:20:0f.0: [106b:0021] type 00 class 0x020000
[ 0.097190] pci 0002:20:0f.0: reg 0x10: [mem 0xf5200000-0xf53fffff]
[ 0.097252] pci 0002:20:0f.0: reg 0x30: [mem 0xf5000000-0xf50fffff pref]
[ 0.097855] pci_bus 0002:20: busn_res: [bus 20-ff] end is updated to 20
[ 0.098009] PCI 0000:00 Cannot reserve Legacy IO [io 0x802000-0x802fff]
[ 0.098055] pci_bus 0000:00: resource 4 [io 0x802000-0x1001fff]
[ 0.098070] pci_bus 0000:00: resource 5 [mem 0xf1000000-0xf1ffffff]
[ 0.098085] pci_bus 0000:00: resource 6 [mem 0x90000000-0x9fffffff]
[ 0.098109] pci_bus 0001:10: resource 4 [io 0x0000-0x7fffff]
[ 0.098123] pci_bus 0001:10: resource 5 [mem 0xf3000000-0xf3ffffff]
[ 0.098138] pci_bus 0001:10: resource 6 [mem 0x80000000-0x8fffffff]
[ 0.098158] pci_bus 0002:20: resource 4 [io 0xff7fe000-0xffffdfff]
[ 0.098172] pci_bus 0002:20: resource 5 [mem 0xf5000000-0xf5ffffff]
[ 0.108912] vgaarb: device added:
PCI:0000:00:10.0,decodes=io+mem,owns=mem,locks=none
[ 0.109011] vgaarb: loaded
[ 0.109038] vgaarb: bridge control possible 0000:00:10.0
[ 0.109828] SCSI subsystem initialized
[ 0.110228] libata version 3.00 loaded.
[ 0.112210] clocksource: Switched to clocksource timebase
[ 0.189330] VFS: Disk quotas dquot_6.6.0
[ 0.189644] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096
bytes)
[ 0.211382] NET: Registered protocol family 2
[ 0.213008] TCP established hash table entries: 2048 (order: 1, 8192
bytes)
[ 0.213155] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.213282] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.213522] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.213623] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.214106] NET: Registered protocol family 1
[ 0.214392] pci 0001:10:18.0: enabling device (0000 -> 0002)
[ 0.272354] Apple USB OHCI 0001:10:19.0 disabled by firmware
[ 0.272407] pci 0001:10:19.0: Can't enable PCI device, BIOS handoff
failed.
[ 0.272476] PCI: CLS mismatch (32 != 1020), using 32 bytes
[ 0.273040] Unpacking initramfs...
[ 2.872430] Freeing initrd memory: 16456K (c1700000 - c2712000)
[ 2.873493] Thermal assist unit
[ 2.873523] using timers,
[ 2.873563] shrink_timer: 500 jiffies
[ 2.875786] audit: initializing netlink subsys (disabled)
[ 2.876044] audit: type=2000 audit(1488472034.843:1): initialized
[ 2.877302] Initialise system trusted keyrings
[ 2.877828] workingset: timestamp_bits=14 max_order=16 bucket_order=2
[ 2.878037] zbud: loaded
[ 4.172244] Key type asymmetric registered
[ 4.172322] Asymmetric key parser 'x509' registered
[ 4.172522] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 252)
[ 4.172899] io scheduler noop registered
[ 4.172944] io scheduler deadline registered
[ 4.173105] io scheduler cfq registered (default)
[ 4.174055] atyfb 0000: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) (32-bit), 14.31818 MHz XTAL, 230
MHz PLL, 70 Mhz MCLK, 53 MHz XCLK
[ 4.180172] aty: Backlight initialized (atybl0)
[ 4.180787] atyfb: monitor sense=0, mode 20
[ 4.236515] Console: switching to colour frame buffer device 100x37
[ 4.247636] atyfb: fb0: ATY Mach64 frame buffer device on PCI
[ 4.249507] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 4.252330] pmac_zilog: 0.6 (Benjamin Herrenschmidt
<***@kernel.crashing.org>)
[ 4.252730] Serial: MPC52xx PSC UART driver
[ 4.253048] Generic non-volatile memory driver v1.1
[ 4.253583] Linux agpgart interface v0.103
[ 4.253865] agpgart-uninorth 0000:00:0b.0: Apple UniNorth chipset
[ 4.257882] agpgart-uninorth 0000:00:0b.0: configuring for size idx: 64
[ 4.258532] agpgart-uninorth 0000:00:0b.0: AGP aperture is 256M @ 0x0
[ 4.259284] MacIO PCI driver attached to Keylargo chipset
[ 4.264891] 0.00013020:ch-a: ttyPZ0 at MMIO 0x80013020 (irq = 22,
base_baud = 230400) is a Z85c30 ESCC - Internal modem
[ 4.273508] 0.00013000:ch-b: ttyPZ1 at MMIO 0x80013000 (irq = 50,
base_baud = 230400) is a Z85c30 ESCC - Serial port
[ 4.290750] adb: starting probe task...
[ 4.533329] random: fast init done
[ 4.549838] adb devices:
[ 4.550944] [2]: 2 c4
[ 4.558653] [3]: 3 1
[ 4.559779] [7]: 7 1f

[ 4.576938] ADB keyboard at 2, handler 1
[ 4.583885] Detected ADB keyboard, type
[ 4.584045] ISO, swapping keys.
[ 4.591487] input: ADB keyboard as /devices/virtual/input/input0
[ 4.599099] input: ADB Powerbook buttons as /devices/virtual/input/input1
[ 4.621371] ADB mouse at 3, handler set to 4
[ 4.622855] (trackpad)

[ 4.694994] input: ADB mouse as /devices/virtual/input/input2
[ 4.702097] adb: finished probe task...
[ 5.340252] pata-macio 0.0001f000:ata-4: Activating pata-macio
chipset KeyLargo ATA-4, Apple bus ID 2
[ 5.357036] scsi host0: pata_macio
[ 5.365231] ata1: PATA max UDMA/66 irq 19
[ 5.535078] ata1.00: ATA-9: KingSpec KSD-PA18.6-032MS, 20131018, max
UDMA/133
[ 5.542626] ata1.00: 62377984 sectors, multi 0: LBA48
[ 5.549990] ata1.00: limited to UDMA/33 due to 40-wire cable
[ 5.562206] ata1.00: configured for UDMA/33
[ 5.570762] scsi 0:0:0:0: Direct-Access ATA KingSpec KSD-PA1
1018 PQ: 0 ANSI: 5
[ 6.428244] pata-macio 0.00020000:ata-3: Activating pata-macio
chipset KeyLargo ATA-3, Apple bus ID 0
[ 6.445342] scsi host1: pata_macio
[ 6.453484] ata2: PATA max MWDMA2 irq 20
[ 6.622834] ata2.00: ATAPI: MATSHITA CR-175, 5AAE, max MWDMA2
[ 6.635178] ata2.00: configured for MWDMA2
[ 6.645758] scsi 1:0:0:0: CD-ROM MATSHITA CD-ROM CR-175
5AAE PQ: 0 ANSI: 5
[ 7.516250] pata-macio 0.00021000:ata-3: Activating pata-macio
chipset KeyLargo ATA-3, Apple bus ID 1
[ 7.533780] scsi host2: pata_macio
[ 7.542218] ata3: PATA max MWDMA2 irq 21
[ 7.552043] mousedev: PS/2 mouse device common for all mice
[ 7.560586] rtc-generic rtc-generic: rtc core: registered rtc-generic
as rtc0
[ 7.568585] PowerMac i2c bus pmu 2 registered
[ 7.576228] PowerMac i2c bus pmu 1 registered
[ 7.583684] PowerMac i2c bus mac-io 0 registered
[ 7.591009] ledtrig-cpu: registered to indicate activity on CPUs
[ 7.599039] NET: Registered protocol family 10
[ 7.608141] mip6: Mobile IPv6
[ 7.615545] NET: Registered protocol family 17
[ 7.622916] mpls_gso: MPLS GSO support
[ 7.631799] registered taskstats version 1
[ 7.639025] Loading compiled-in X.509 certificates
[ 7.673822] alg: No test for pkcs1pad(rsa,sha256)
(pkcs1pad(rsa-generic,sha256))
[ 7.688896] Loaded X.509 cert 'Debian Project: Ben Hutchings:
008a018dca80932630'
[ 7.696383] zswap: loaded using pool lzo/zbud
[ 7.705071] input: PMU as /devices/virtual/input/input3
[ 7.713275] rtc-generic rtc-generic: setting system clock to
2017-03-02 18:27:19 UTC (1488479239)
[ 7.722427] PM: Hibernation image not present or could not be loaded.
[ 7.726625] Freeing unused kernel memory: 420K (c076b000 - c07d4000)
[ 7.734092] This architecture does not have kernel memory protection.
[ 8.456555] sd 0:0:0:0: [sda] 62377984 512-byte logical blocks: (31.9
GB/29.7 GiB)
[ 8.492355] sd 0:0:0:0: [sda] Write Protect is off
[ 8.499865] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8.548427] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[ 8.722516] sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6
[ 8.754861] sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x cd/rw xa/form2
cdda tray
[ 8.762484] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 8.770122] sungem.c:v1.0 David S. Miller <***@redhat.com>
[ 8.796716] sd 0:0:0:0: [sda] Attached SCSI disk
[ 8.811674] gem 0002:20:0f.0 eth0: Sun GEM (PCI) 10/100/1000BaseT
Ethernet 00:0a:27:8e:3a:1c
[ 8.868977] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 9.079823] usbcore: registered new interface driver usbfs
[ 9.114989] usbcore: registered new interface driver hub
[ 9.147926] usbcore: registered new device driver usb
[ 9.320022] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 9.387564] gem 0002:20:0f.0 enP2p32s15f0: renamed from eth0
[ 9.472069] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 9.563057] ehci-pci: EHCI PCI platform driver
[ 9.622931] ohci-pci: OHCI PCI platform driver
[ 9.649721] ohci-pci 0001:10:18.0: OHCI PCI host controller
[ 9.672639] ohci-pci 0001:10:18.0: new USB bus registered, assigned
bus number 1
[ 9.695907] ohci-pci 0001:10:18.0: irq 27, io mem 0x80080000
[ 9.884005] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[ 9.891989] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 9.899552] usb usb1: Product: OHCI PCI host controller
[ 9.906905] usb usb1: Manufacturer: Linux 4.9.0-2-powerpc ohci_hcd
[ 9.914319] usb usb1: SerialNumber: 0001:10:18.0
[ 9.952580] hub 1-0:1.0: USB hub found
[ 9.972515] hub 1-0:1.0: 2 ports detected
[ 10.000941] Apple USB OHCI 0001:10:19.0 disabled by firmware
[ 10.195355] PM: Starting manual resume from disk
[ 10.202692] PM: Hibernation image partition 8:3 present
[ 10.202701] PM: Looking for hibernation image.
[ 10.204471] PM: Image not found (code -22)
[ 10.204481] PM: Hibernation image not present or could not be loaded.
[ 10.883534] EXT4-fs (sda4): mounting ext2 file system using the ext4
subsystem
[ 10.897920] EXT4-fs (sda4): mounted filesystem without journal. Opts:
(null)
[ 14.750418] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 14.901130] sr 1:0:0:0: Attached scsi generic sg1 type 5
[ 15.188077] i2c /dev entries driver
[ 17.312340] orinoco 0.15 (David Gibson
<***@gibson.dropbear.id.au>, Pavel Roskin <***@gnu.org>, et al)
[ 17.445494] airport 0.15 (Benjamin Herrenschmidt
<***@kernel.crashing.org>)
[ 17.445990] airport: Physical address 80030000
[ 18.340672] sungem_phy: PHY ID: 406212, addr: 0
[ 18.340858] gem 0002:20:0f.0 enP2p32s15f0: Found BCM5201 PHY
[ 18.341704] IPv6: ADDRCONF(NETDEV_UP): enP2p32s15f0: link is not ready
[ 18.672966] airport 0.00030000:radio: Hardware identity
0005:0001:0001:0002
[ 18.673499] airport 0.00030000:radio: Station identity
001f:0001:0008:0046
[ 18.673808] airport 0.00030000:radio: Firmware determined as
Lucent/Agere 8.70
[ 18.681277] airport 0.00030000:radio: firmware: failed to load
agere_sta_fw.bin (-2)
[ 18.681655] airport 0.00030000:radio: Direct firmware load for
agere_sta_fw.bin failed with error -2
[ 18.682951] airport 0.00030000:radio: firmware: failed to load
agere_sta_fw.bin (-2)
[ 18.683287] airport 0.00030000:radio: Direct firmware load for
agere_sta_fw.bin failed with error -2
[ 18.683793] airport 0.00030000:radio: Hardware identity
0005:0001:0001:0002
[ 18.684256] airport 0.00030000:radio: Station identity
001f:0001:0008:0046
[ 18.684564] airport 0.00030000:radio: Firmware determined as
Lucent/Agere 8.70
[ 18.684866] airport 0.00030000:radio: Ad-hoc demo mode supported
[ 18.685125] airport 0.00030000:radio: IEEE standard IBSS ad-hoc mode
supported
[ 18.685428] airport 0.00030000:radio: WEP supported, 104-bit key
[ 20.764487] gem 0002:20:0f.0 enP2p32s15f0: Link is up at 100 Mbps,
full-duplex
[ 20.765118] gem 0002:20:0f.0 enP2p32s15f0: Pause is disabled
[ 20.765492] IPv6: ADDRCONF(NETDEV_CHANGE): enP2p32s15f0: link becomes
ready
[ 21.466979] Adding 976556k swap on /dev/sda3. Priority:-1 extents:1
across:976556k SSFS
[ 21.764042] EXT4-fs (sda4): re-mounted. Opts: errors=remount-ro
[ 24.887056] loop: module loaded
[ 25.333508] input: PowerMac Beep as
/devices/pci0001:10/0001:10:17.0/input/input4
[ 26.212501] EXT4-fs (sda5): mounting ext2 file system using the ext4
subsystem
[ 26.348641] EXT4-fs (sda5): mounted filesystem without journal. Opts:
(null)
[ 47.980305] input: Mouseemu virtual keyboard as
/devices/virtual/input/input5
[ 47.992986] input: Mouseemu virtual mouse as
/devices/virtual/input/input6
[ 173.737950] random: crng init done
[ 187.113341] systemd-logind[1996]: New seat seat0.
[ 187.154820] systemd-logind[1996]: Failed to start user service,
ignoring: Unknown unit: ***@1000.service

[John Paul Adrian Glaubitz]

Hi!

Post by Riccardo Mottola
[ 4.174055] atyfb 0000: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) (32-bit), 14.31818 MHz XTAL, 230 MHz PLL, 70 Mhz MCLK, 53 MHz XCLK
[ 4.180172] aty: Backlight initialized (atybl0)
[ 4.180787] atyfb: monitor sense=0, mode 20

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 with:

video=atyfb:off

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 Linux kernel, so the fbdev driver might be your only option.

To use the "fbdev" driver, add the following to /etc/X11/xorg.conf.d/00-fbdev.conf:

Section "Device"
Driver "fbdev"
Option "fbdev" "/dev/fb0"
EndSection

After reboot, X should work.

Adrian

[John Paul Adrian Glaubitz]

Post by John Paul Adrian Glaubitz
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 Linux kernel, so the fbdev driver might be your only option.
[1] https://dri.freedesktop.org/wiki/ATIMach64/

[Michel Dänzer]

Post by John Paul Adrian Glaubitz

Post by Riccardo Mottola
[ 4.174055] atyfb 0000: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) (32-bit), 14.31818 MHz XTAL, 230 MHz PLL, 70 Mhz MCLK, 53 MHz XCLK
[ 4.180172] aty: Backlight initialized (atybl0)
[ 4.180787] atyfb: monitor sense=0, mode 20

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
video=atyfb:off
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 Linux kernel, so the fbdev driver might be your only option.

John, what you're writing would apply if mach64 was a KMS kernel driver,
but it's not; it predated KMS by a long shot.

xf86-video-mach64 works without the mach64 kernel driver. It may or may
not work with the atyfb kernel driver — there's no particular reason why
it couldn't.

Somebody should probably try isolating the kernel change which broke
Riccardo's setup.

[John Paul Adrian Glaubitz]

Please re-read what I wrote. I never claimed it's a KMS driver.

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz

Post by Riccardo Mottola
[ 4.174055] atyfb 0000: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) (32-bit), 14.31818 MHz XTAL, 230 MHz PLL, 70 Mhz MCLK, 53 MHz XCLK
[ 4.180172] aty: Backlight initialized (atybl0)
[ 4.180787] atyfb: monitor sense=0, mode 20

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
video=atyfb:off
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 Linux kernel, so the fbdev driver might be your only option.

John, what you're writing would apply if mach64 was a KMS kernel driver,
but it's not; it predated KMS by a long shot.
xf86-video-mach64 works without the mach64 kernel driver. It may or may
not work with the atyfb kernel driver — there's no particular reason why
it couldn't.
Somebody should probably try isolating the kernel change which broke
Riccardo's setup.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer

[Michel Dänzer]

Post by John Paul Adrian Glaubitz
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.

[John Paul Adrian Glaubitz]

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 remember correctly, it uses offb for early startup console on Open Firmware systems anyway. I did not claim you need a KMS kernel module for "mach64". I was talking about the missing DRM module as explained in the linked article on the X.Org wiki.

But in any case, using fbdev should always work. The "mach64" driver may be broken because it's more or less orphaned.

Adrian

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz
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 | http://www.amd.com
Libre software enthusiast | Mesa and X developer

[Michel Dänzer]

Post by John Paul Adrian Glaubitz
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.

Post by John Paul Adrian Glaubitz
I was talking about the missing DRM module as explained in the linked
article on the X.Org wiki.

The kernel module is only needed for DRI 3D hardware acceleration, for
which the needed Mesa driver isn't available in Debian (or even current
upstream Mesa) anyway.

Post by John Paul Adrian Glaubitz
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 works
with an older kernel.


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 anyway. In that case there's no benefit in
using that vs xserver-xorg-video-fbdev.

[John Paul Adrian Glaubitz]

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz
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.

It's relevant because using the FB driver is always a working fallback solution.

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz
I was talking about the missing DRM module as explained in the linked
article on the X.Org wiki.

The kernel module is only needed for DRI 3D hardware acceleration, for
which the needed Mesa driver isn't available in Debian (or even current
upstream Mesa) anyway.

I know DRM is required for 3D acceleration. I was not sure if the driver would allow to be loaded with the DRM module missing.

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz
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 works
with an older kernel.

I missed that part completely.

Post by Michel Dänzer
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 anyway. In that case there's no benefit in
using that vs xserver-xorg-video-fbdev.

On a sidenote: Please be more polite on this list. There is no need to be that rude and condescending.

Thank you!

Adrian

[Michel Dänzer]

Post by John Paul Adrian Glaubitz

Post by Michel Dänzer
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 anyway. In that case there's no benefit in
using that vs xserver-xorg-video-fbdev.

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 honestly
always trying to be respectful and stick to technical facts, certainly
not to be rude and condescending.

[John Paul Adrian Glaubitz]

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz
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 honestly
always trying to be respectful and stick to technical facts, certainly
not to be rude and condescending.

You are constantly implying ignorance instead of mistakes.

I know that mach64 doesn't support KMS, but I missed the part where
Riccardo said it was working on an older kernel. That was a mistake
on my side, but that doesn't mean you have to assume I don't know
the difference between UMS, KMS and the FB driver.

I have installed Debian's PowerPC port on almost identical hardware
in the past and I have debugged similar X.Org issues on these machines.

You, being MESA and X upstream, have certainly more in-depth knowledge
than I do. But it doesn't automatically invalidate my suggestions
like using FB as a fallback driver.

Thanks,
Adrian

[Wolfgang Pfeiffer]

Post by John Paul Adrian Glaubitz

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz
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.

It's relevant because using the FB driver is always a working
fallback solution.

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz
I was talking about the missing DRM module as explained in the linked
article on the X.Org wiki.

The kernel module is only needed for DRI 3D hardware acceleration, for
which the needed Mesa driver isn't available in Debian (or even current
upstream Mesa) anyway.

I know DRM is required for 3D acceleration. I was not sure if the
driver would allow to be loaded with the DRM module missing.

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz
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 works
with an older kernel.

I missed that part completely.

Post by Michel Dänzer
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 anyway. In that case there's no benefit in
using that vs xserver-xorg-video-fbdev.

On a sidenote: Please be more polite on this list. There is no need
to be that rude and condescending.

No. He wasn't rude. Not a bit. He simply was - as most of the time here
- very specific, terse and up to the relevant technical points. And
yes: I miss Michel's postings here a little bit. He's a pro, and I
definitively trust him a lot when he's commenting here or elsewhere.

Here's an example of what might be understood as rude. It was written
by me, years ago, on this list:

"Situations like that is why I say that Debian-Linux does not work for
people with a girl-friend or a family, or for folks who need to get a
job done on a computer in a reasonable amount of time. Or for folks who
simply like watching shadows on the wall (John Lennon :) or the stars
above them.

I'd guess it's a system for folks not knowing what to do with their
lives if they had a working OS on their computer."

Whole message:
https://lists.debian.org/debian-powerpc/2003/08/msg00559.html


I admit: I miss postings like that previous one a bit ... :)

Post by John Paul Adrian Glaubitz
Thank you!

No worries, Adrian: I'm immensely grateful to all Debian developers,
maintainers etc. for their work  - and to every single one of them. I'd
suggest to not destroy the fun of working on it by being too sensitive
about what people *might* have had in their minds when posting here ..

Love you all .... :)

Wolfgang

Post by John Paul Adrian Glaubitz
Adrian

[John Paul Adrian Glaubitz]

Post by Wolfgang Pfeiffer
No. He wasn't rude. Not a bit.

Yes, *I* perceived that as rude.

Post by Wolfgang Pfeiffer
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 alright to correct
someone if they make a mistake. It's not to okay to automatically
assume they're ignorant.

Post by Wolfgang Pfeiffer
Here's an example of what might be understood as rude. It was written
(...)

I don't think you can justify that by proving that people can behave
even worse. I also don't think it's good idea to continue the
discussion in this direction. That never ends well.

Thanks,
Adrian

[Michel Dänzer]

Post by John Paul Adrian Glaubitz

Post by Wolfgang Pfeiffer
No. He wasn't rude. Not a bit.

Yes, *I* perceived that as rude.

Post by Wolfgang Pfeiffer
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.

That's a pretty wild accusation. I pointed out that your knowledge about
constraints of KMS based drivers doesn't apply to mach64.


Anyway, I'm glad that the actual thread seems to be going in more
productive directions now.

[Riccardo Mottola]

Hi guys,

don't fight over kernel modules :) le'ts just get the thing working again.

Post by Michel Dänzer

Post by John Paul Adrian Glaubitz
But in any case, using fbdev should always work. The "mach64" driver

Post by John Paul Adrian Glaubitz
may be broken because it's more or less orphaned.

Except for the part where Riccardo says that the same userspace works
with an older kernel.

Exactly, that "proof" means that the changes comes from the kernel or
that the driver needs updating to work with the new kernel.

Compiling kernels is a bit tight on this iBook. What road can i follow
to help you track down changes? Can I get easily a dpkg package of
intermediate kernel versions to bisect things?

Are there changes in the kernel configuration itself? We go from 4.7.0-1
to 4.9.0-2

If you can point me to an intermediate version I'd like to try it!

Post by Michel Dänzer
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 anyway. In that case there's no benefit in
using that vs xserver-xorg-video-fbdev.

Not all acceleration, but most of it - that is the best I could get
about a year ago withotu having very strange display issues.
I remember this was quite a still bette than "accel off" or fbdev which
is quite horribly slow. I'd love to nable some of it again and gain
again some speed which was usable about 2 years ago.

Of course the goal is to get most features and acceleration working (again),


Riccardo

[John Paul Adrian Glaubitz]

Post by Riccardo Mottola
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.

Post by Riccardo Mottola
Compiling kernels is a bit tight on this iBook. What road can i follow
to help you track down changes? Can I get easily a dpkg package of intermediate kernel
versions to bisect things?

You can just cross-compile the kernel from a fast amd64 machine. If you
are on Stretch or Unstable, you can install a cross-compiler for PowerPC
with:

# apt install gcc-6-powerpc-linux-gnu

and you will most likely also need things like the ncurses development
headers if you want to use things like "make menuconfig". So, I'd just
install the build dependencies for the Linux kernel:

# apt build-dep --arch-only linux

Post by Riccardo Mottola
Are there changes in the kernel configuration itself? We go from 4.7.0-1 to 4.9.0-2
https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/config
http://metadata.ftp-master.debian.org/changelogs/main/l/linux/unstable_changelog
If you can point me to an intermediate version I'd like to try it!
http://snapshot.debian.org/

Follow the instructions on the webpage on how to add a sources list entry for
a certain snapshot date. Then run "apt update" with verification disabled
and install the kernel version of your choice.

Post by Riccardo Mottola
Not all acceleration, but most of it - that is the best I could get about a year ago withotu having very strange display issues.
I remember this was quite a still bette than "accel off" or fbdev which is quite horribly slow. I'd love to nable some of it again and gain again some speed
which was usable about 2 years ago.
Of course the goal is to get most features and acceleration working (again),

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 can inspect the changes for the
first bad version and possibly continue with "git bisect" if we cannot find
any obvious change.

Adrian

[Riccardo Mottola]

Hi,

Post by John Paul Adrian Glaubitz
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 can inspect the changes for the
first bad version and possibly continue with "git bisect" if we cannot find
any obvious change.

Avoiding doing all setup to compile my own kernels would be welcome! I
thus proceeded with snapshots


How can I know when an update was available? Or, better which
intermediate versions are or have been available between my two kernels
versions?

I tested both 4.7 and 4.8 series I found in snapshots.

4.7.5.1 -> original, worked
4.7.8.1 -> works

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:
linux-image-4.8.0-rc8-powerpc_4.8~rc8-1~exp1_powerpc.deb : 2016-09-29
04:29:33
linux-image-4.8.0-1-powerpc_4.8.5-1_powerpc.deb : 2016-11-02 03:31:50

I couldn't find any intermediate version to test (or later series of the
4.7.x) , if there is one, please tell me. Does this however gives you
already a clue?
It could be of course both in the kernel itself as in some configuration.

Riccardo

[John Paul Adrian Glaubitz]

How can I know when an update was available? Or, better which intermediate versions are or have been available between my two kernels versions?
http://snapshot.debian.org/package/linux/

Since some source versions may have failed to build from source on
powerpc, you can verify which versions of the linux package actually

https://buildd.debian.org/status/logs.php?pkg=linux&arch=powerpc

There are several 4.7.x package releases. How did you actually search
snapshot.debian.org? I wonder how you managed to miss them.

I couldn't find any intermediate version to test (or later series of the 4.7.x) ,

See above.

if there is one, please tell me. Does this however gives you already a clue?

It's some progress, but we still need to get to the place that we find
the package version which introduced the problem.

Adrian

[Riccardo Mottola]

Hi,

Post by Riccardo Mottola
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
linux-image-4.8.0-rc8-powerpc_4.8~rc8-1~exp1_powerpc.deb : 2016-09-29
04:29:33
linux-image-4.8.0-1-powerpc_4.8.5-1_powerpc.deb : 2016-11-02 03:31:50
I couldn't find any intermediate version to test (or later series of
the 4.7.x) , if there is one, please tell me. Does this however gives
you already a clue?

sorry to ping - but I got no reply. Does this rough check give a clue?
Any intermediate version to further check? I couldn't find any.

Did debian change something in the kernel between rc8 and -1 (patches,
config options) or did we uncover an upstream kernel bug?

Riccardo

[Michel Dänzer]

Post by Riccardo Mottola
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 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.

[Riccardo Mottola]

Hi,

Post by Michel Dänzer

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 is readable enough I hope)

Could CONFIG_IO_STRICT_DEVMEM=y be the issue?

the only other stuff is Hardening configs.

Interesting is that this is 4.8.0-1 while the header advertises 4.8.5!

Riccardo

[Riccardo Mottola]

Hi,

Post by Michel Dänzer

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 is readable enough I hope)

Could CONFIG_IO_STRICT_DEVMEM=y be the issue?

the only other stuff is Hardening configs.

Interesting is that this is 4.8.0-1 while the header advertises 4.8.5!

Riccardo

(This time with diff)

[John Paul Adrian Glaubitz]

Post by Riccardo Mottola
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 recompile the kernel modules.

The ABI version is bumped for every minor kernel release and is currently
at 4.9.0 in Debian unstable, see the output of uname:

***@ikarus:~$ uname -a
Linux ikarus 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux
***@ikarus:~$

Adrian

[Michel Dänzer]

Post by Riccardo Mottola

Post by Michel Dänzer

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 is readable enough I hope)
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 the kernel atyfb driver or the Xorg mach64 driver access the GPU's
MMIO register aperture.

[Riccardo Mottola]

Hi Michel,

Post by Michel Dänzer

Post by Riccardo Mottola
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 the kernel atyfb driver or the Xorg mach64 driver access the GPU's
MMIO register aperture.

could we turn that option back (if proven that it is it)?

To test this I would need to run the new kernel without the kernel atyfb
and see if then Xorg starts.
I asked for advice on how to, if it were grub or lilo I would know how
to change the kernel parameters, but with Mac I'm less easy.

Thanks,

Riccardo

[John Paul Adrian Glaubitz]

Post by Riccardo Mottola
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.

Post by Riccardo Mottola
To test this I would need to run the new kernel without
the kernel atyfb and see if then Xorg starts.
I asked for advice on how to

I actually mentioned that in my first post:

video=atyfb:off

You should just be able to append this on the yaboot command line.

Adrian

[Riccardo Mottola]

Hi Adrian,

Post by John Paul Adrian Glaubitz
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 the framebuffer off.

Post by John Paul Adrian Glaubitz

Post by Riccardo Mottola
To test this I would need to run the new kernel without
the kernel atyfb and see if then Xorg starts.
I asked for advice on how to

video=atyfb:off
You should just be able to append this on the yaboot command line.

I changed my yaboot.conf with:
append="video=atyfb:off"


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.081] (**) MACH64(0): Option "shadow_fb" "True"
[ 175.081] (==) MACH64(0): Using XAA acceleration architecture
[ 175.082] (II) MACH64: Mach64 in slot 0:16:0 detected.
[ 175.082] (II) MACH64(0): BIOS Data: BIOSSize=0x0000, ROMTable=0x0000.
[ 175.083] (II) MACH64(0): BIOS Data: ClockTable=0x0000,
FrequencyTable=0x0000.
[ 175.083] (II) MACH64(0): BIOS Data: LCDTable=0x0000.
[ 175.083] (II) MACH64(0): BIOS Data: VideoTable=0x0000,
HardwareTable=0x0000.
[ 175.083] (II) MACH64(0): BIOS Data: I2CType=0x00, Tuner=0x00,
Decoder=0x00, Audio=0x0F.
[ 175.083] (--) MACH64(0): ATI 3D Rage Mobility graphics controller
detected.
[ 175.083] (--) MACH64(0): Chip type 4C4E "LN", version 4, foundry
TSMC, class 0, revision 0x01.
[ 175.083] (--) MACH64(0): AGP bus interface detected.
[ 175.083] (--) MACH64(0): ATI Mach64 adapter detected.
[ 175.084] (!!) MACH64(0): For information on using the multimedia
capabilities
of this adapter, please see http://gatos.sf.net.
[ 175.084] (--) MACH64(0): Internal RAMDAC (subtype 1) detected.
[ 175.084] (==) MACH64(0): RGB weight 565
[ 175.084] (==) MACH64(0): Default visual is TrueColor
[ 175.084] (==) MACH64(0): Using gamma correction (1.0, 1.0, 1.0)
[ 175.084] (II) MACH64(0): Using Mach64 accelerator CRTC.
[ 175.084] (--) MACH64(0): 800x600 panel detected.
[ 175.084] (--) MACH64(0): Panel clock is 39.992 MHz.
[ 175.084] (II) MACH64(0): Using digital flat panel interface.
[ 175.085] (II) MACH64(0): Storing hardware cursor image at 0x913FFC00.
[ 175.085] (II) MACH64(0): Using 8 MB linear aperture at 0x91800000.
[ 175.085] (!!) MACH64(0): Virtual resolutions will be limited to 4095 kB
due to linear aperture size and/or placement of hardware cursor image
area.
[ 175.085] (II) MACH64(0): Using Block 0 MMIO aperture at 0x90000400.
[ 175.085] (II) MACH64(0): Using Block 1 MMIO aperture at 0x90000000.
[ 175.085] (EE) MACH64(0): Unable to map linear aperture. Invalid
argument (22)
[ 175.089] (II) UnloadModule: "mach64"

I think I don't have enough space for a native kernel build, I'd need to
build in a separate partition, else I need to go all the way to build a
PPC kernel from my x86 Debian laptop where perhaps I need additional
assistance for.

Riccardo

[Michel Dänzer]

Post by Riccardo Mottola
X11 doesn't start, but the error message changed and goes further.

[...]

Post by Riccardo Mottola
[ 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 disable CONFIG_IO_STRICT_DEVMEM again, as it's desirable from
a security/safety perspective. But I guess you can try.

[Riccardo Mottola]

Hi,

Post by Michel Dänzer

Post by Riccardo Mottola
[ 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 disable CONFIG_IO_STRICT_DEVMEM again, as it's desirable from
a security/safety perspective. But I guess you can try.

I did a full native build of the 4.9.13 kernel using this guide:

https://www.debian.org/releases/jessie/i386/ch08s06.html.en

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 incompatible with
with legacy Xorg, which is the one I am using.

Maybe with an updated ATI driver the usage of legacy is not necessary
anymore? I doubt somebody works/worked on these older Mach drivers though.

Adrian, can you open the bug or should I, where ?

Riccardo

[Michel Dänzer]

Post by Riccardo Mottola

Post by Michel Dänzer

Post by Riccardo Mottola
[ 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 disable CONFIG_IO_STRICT_DEVMEM again, as it's desirable from
a security/safety perspective. But I guess you can try.

https://www.debian.org/releases/jessie/i386/ch08s06.html.en
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 incompatible with
with legacy Xorg, which is the one I am using.
Maybe with an updated ATI driver the usage of legacy is not necessary
anymore? I doubt somebody works/worked on these older Mach drivers though.

Yeah, no such luck. This would require rewriting the mach64 kernel and
Xorg drivers based on KMS, which is unlikely to ever happen (even for
r128, which would be comparatively easy due to similarity between
Rage128 and early Radeon GPUs).

[John Paul Adrian Glaubitz]

Hi Riccardo!

Post by Riccardo Mottola
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 incompatible with with legacy Xorg, which is the one I am using.

Yes, indeed. Thanks for verifying this. Glad to hear you figured out
how to get X.Org working on your machine again.

Post by Riccardo Mottola
Adrian, can you open the bug or should I, where ?

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.

Post by Riccardo Mottola
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.

Adrian

[John Paul Adrian Glaubitz]

Post by John Paul Adrian Glaubitz
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.
http://cateee.net/lkddb/web-lkddb/IO_STRICT_DEVMEM.html

Adrian

[Riccardo Mottola]

Hi,

Post by John Paul Adrian Glaubitz

Post by Riccardo Mottola
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

[Thadeu Lima de Souza Cascardo]

Post by Riccardo Mottola
Hi,

Post by John Paul Adrian Glaubitz

Post by Riccardo Mottola
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.

[Riccardo Mottola]

Hi Cascardo,

Post by Thadeu Lima de Souza Cascardo
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.

yes, that works even when using the stock kernel and I can stop
disabling the atyfb.

Very good - we have a better solution than compiling different kernels!
Perhaps it could be at least be mentioned or best pre-configured in
yaboot or so?

Riccardo

[John Paul Adrian Glaubitz]

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 pre-configured in yaboot or so?

I agree on the documentation part. Adding it to the release notes or the wiki sounds
like a reasonable idea. There is a wiki page where it could be added, see [1].

I disagree on the default setting though. Again, enabling this setting makes the
system potentially more insecure, so it should be disabled by default.

[1] https://wiki.debian.org/AtiHowTo

[Michel Dänzer]

Post by Riccardo Mottola

Post by Riccardo Mottola
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
linux-image-4.8.0-rc8-powerpc_4.8~rc8-1~exp1_powerpc.deb : 2016-09-29
04:29:33
linux-image-4.8.0-1-powerpc_4.8.5-1_powerpc.deb : 2016-11-02 03:31:50
I couldn't find any intermediate version to test (or later series of
the 4.7.x) , if there is one, please tell me. Does this however gives
you already a clue?

sorry to ping - but I got no reply. Does this rough check give a clue?
Any intermediate version to further check? I couldn't find any.

Did you see John's followup? It had some suggestions for finding
intermediate versions.

Post by Riccardo Mottola
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 them
directly, maybe compress them e.g. with gzip to avoid running into
mailing list size limits.

[Michel Dänzer]

Post by Riccardo Mottola
don't fight over kernel modules :) le'ts just get the thing working again.

Right, that's always my intent. :)

Post by Riccardo Mottola

Post by Michel Dänzer
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 anyway. In that case there's no benefit in
using that vs xserver-xorg-video-fbdev.

Not all acceleration, but most of it - that is the best I could get
about a year ago withotu having very strange display issues.
I remember this was quite a still bette than "accel off" or fbdev which
is quite horribly slow.

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 description
of the difference and seeing the full Xorg log files corresponding to
both cases would be interesting.

[Riccardo Mottola]

Hi,

Post by Michel Dänzer
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 description
of the difference and seeing the full Xorg log files corresponding to
both cases would be interesting.

well - i Idsabled things to avoid some bugs I do not remember :)

Currently my working setup is:

Section "Device"
Identifier "Configured Video Device"
Driver "ati"
Option "ForcePCIMode" "True"
Option "EXANoComposite" "True"
Option "NoAccel" "True"
Option "ShadowFB" "True"
EndSection

I just tried removing the "NoAccel" line and things seem to work fine. I
seem to recall two ugly bugs in ATI
- 16bit color issues (yes the interna display should run as such to be
accelerated, but then it advertises wrong modes which confuse GNUstep),
I force it to 24bit
- bad font displays with cairo and freetype

Removing also EXANoComposite seems fine too.

Maybe some bugs were fixes. I keep it that way and test further and I
left in old workarounds.

To further test stuff, I installed the fbdev driver and indeed it
"works" and it isn't so much slower (in the sense that it is slow, but
the ATI became slow too). Moving windows is slower, but just a teeny bit.

Then I tried on the 4.9 kernel the fbdev framebuffer and it works.

So.. well the best way would be still get of course current kernel with
as much as ATI accel back! I will investigate 4.8 today.

Later,
Riccardo

[Riccardo Mottola]

Hi,

Post by John Paul Adrian Glaubitz
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
video=atyfb:off

If it is not something added in the kernel update, it was most probably
working before. However, a try might be worth it.
How can I test it ? I know my moves in Lilo and grub, however the PPC
loader is a bit harder for me.
Can I modify the parameters for just a single boot to test it?

It might be good to know if the framebuffer driver is interfering with X
right now.

Riccardo

[Riccardo Mottola]

Hi,

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 from the older kernel.
0000:00:0b.0 Host bridge: Apple Inc. UniNorth AGP
0000:00:10.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Device 4c4e (rev 64)
0001:10:0b.0 Host bridge: Apple Inc. UniNorth PCI
0001:10:17.0 Unassigned class [ff00]: Apple Inc. KeyLargo Mac I/O (rev 02)
0001:10:18.0 USB controller: Apple Inc. KeyLargo USB
0001:10:19.0 USB controller: Apple Inc. KeyLargo USB
0002:20:0b.0 Host bridge: Apple Inc. UniNorth Internal PCI
0002:20:0f.0 Ethernet controller: Apple Inc. UniNorth GMAC (Sun GEM)


Riccardo

[Riccardo Mottola]

Hi,

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:

0000:00:0b.0 Host bridge: Apple Inc. UniNorth AGP
0000:00:10.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Device 4c4e (rev 64)
0001:10:0b.0 Host bridge: Apple Inc. UniNorth PCI
0001:10:17.0 Unassigned class [ff00]: Apple Inc. KeyLargo Mac I/O (rev 02)
0001:10:18.0 USB controller: Apple Inc. KeyLargo USB
0001:10:19.0 USB controller: Apple Inc. KeyLargo USB
0002:20:0b.0 Host bridge: Apple Inc. UniNorth Internal PCI
0002:20:0f.0 Ethernet controller: Apple Inc. UniNorth GMAC (Sun GEM)


Rechner