Bug 151978

Summary: R128 driver does not find framebuffer device
Product: [Fedora] Fedora Reporter: Ralf Ertzinger <redhat-bugzilla>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: byte, pfrields
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-25 00:41:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 121179    
Attachments:
Description Flags
Xorg.0.log
none
xorg.conf none

Description Ralf Ertzinger 2005-03-23 23:43:52 UTC
Description of problem:
X fails to start, leaving the followig message in Xorg.0.log (full file in
attachment):

[....]

(**) R128(0): Using framebuffer device
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Reloading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(WW) open /dev/fb1: No such file or directory
(WW) open /dev/fb2: No such file or directory
(WW) open /dev/fb3: No such file or directory
(WW) open /dev/fb4: No such file or directory
(WW) open /dev/fb5: No such file or directory
(WW) open /dev/fb6: No such file or directory
(WW) open /dev/fb7: No such file or directory
(EE) R128(0): Failed to open framebuffer device, consult warnings and/or errors
above for possible reasons
        (you may have to look at the server log to see warnings)

These files do indeed not exist, /dev/fb0 exists, however. This
machine does not work without R128 using the framebuffer.


Version-Release number of selected component (if applicable):
xorg-x11-6.8.2-10


How reproducible:
Always

Steps to Reproduce:
1. Try to start X on an iBook (or other machine which uses R128)
2.
3.
  
Actual results:
X fails to start

Expected results:
X starts

Additional info:

Comment 1 Ralf Ertzinger 2005-03-23 23:43:52 UTC
Created attachment 112283 [details]
Xorg.0.log

Comment 2 Ralf Ertzinger 2005-03-23 23:45:21 UTC
Created attachment 112284 [details]
xorg.conf

Comment 3 Mike A. Harris 2005-03-24 00:54:49 UTC
If the driver can't open the kernel framebuffer device, that isn't a fault
of the driver or X server.  It does not create kernel devices, it just
tries to open and use them.  It is the kernel's responsibility to provide
a framebuffer driver, and udev's responsibility to make sure the nodes
are there.

I'm assuming the kernel does have the driver, and that udev is just not
creating the device nodes, and reassigning this to udev.

Comment 4 Ralf Ertzinger 2005-03-24 01:32:37 UTC
Nope, turns out this is a kernel issue. Because I got a picture at all (console)
I assumed that the FB driver is there, Macs do not have a real text mode. Seems
there is a fallback framebuffer driver that grabs the buffer if the "real" (ATY)
driver is not loaded. Which is the case, since:

grep ATY /boot/config-2.6.11-1.1191_FC4 
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set

My bad. Reassigning to kernel.
Please reenable FB_ATY*, at least for the PPC builds.

Version-Release number of selected component (if applicable):
kernel-2.6.11-1.1191_FC4

Comment 5 David Woodhouse 2005-03-29 17:50:49 UTC
These were disabled on 2005-03-19 because they didn't build. 

drivers/built-in.o(.text+0x2017c):drivers/video/aty/atyfb_base.c:2509: undefined
reference to `mac_vmode_to_var'
drivers/built-in.o(.text+0x2066c):drivers/video/aty/atyfb_base.c:2502: undefined
reference to `mac_map_monitor_sense'

drivers/video/aty/aty128fb.c:1771: undefined reference to `mac_find_mode'
drivers/built-in.o(.init.text+0x2bb0):drivers/video/aty/aty128fb.c:1807:
undefined reference to `mac_vmode_to_var'


Someone needs to try turning them back on and see if they work again now. If
not, chase the bug upstream and make them work in Linus' tree.

Comment 6 Colin Charles 2005-04-22 17:25:34 UTC
Is this still a bug? It seems to be re-enabled in modern kernels...