On Tue, Feb 03, 2004 at 05:13:28PM +1100, Benjamin Herrenschmidt wrote: > > > - the machine freezes when quitting X or switching to the console > > As I said in another reply, check James latest driver, ultimately, > we want to backport more of XFree. Make sure you get an up to date > enough XFree as well. Sure. I've been diffing against (and running) latest CVS. > > > - on bootup I'm seeing: > > > > IN from bad port 3cc at c0133c70 > > IN from bad port 3d5 at c0133c38 > > Feb 2 16:33:05 bogon last message repeated 24 times > > IN from bad port 3da at c0133c1c > > IN from bad port 3da at c0133be0 > > IN from bad port 3c1 at c0133bb0 > > IN from bad port 3da at c0133be0 > > IN from bad port 3c1 at c0133bb0 > > IN from bad port 3da at c0133be0 > > IN from bad port 3c1 at c0133bb0 > > IN from bad port 3da at c0133be0 > > IN from bad port 3c1 at c0133bb0 > > IN from bad port 3da at c0133be0 > > IN from bad port 3c1 at c0133bb0 > > IN from bad port 3da at c0133be0 > > > > In the kernel logs which are I/O accesses from within riva_save_state > > (which is called from riva_fb_open), which seem to fail. Could this > > explain the crashes on the X->console switches since riva_restore_state > > dumps out bogus values? > > Can anybody report a running rivafb on either ppc or i386? If so which > > PCIIds are working? > > Any ideas welcome? > > It's trying to tap bogus VGA ports, which is a wrong thing to do > on a pmac. Aren't the VGA ports accessible via other means on > a riva card ? Dunno. I don't see these traps in 2.4, which puzzles me. In the end these reads are responsible for storing the current cards state, so could this be the reason why X/vt switching fails? -- Guido
Attachment:
signature.asc
Description: Digital signature