Cupertino test ring problem?

Cupertino test ring problem?

[James Bottomley]

The gateway machines to cupertino (gsyfrf11/10) have been inaccessible
for most of last week.  Can we get someone local to give them a poke and
see what's up with them?

James

Re: Cupertino test ring problem?

[Matthew Wilcox]

On Mon, Jul 28, 2008 at 09:19:05AM -0500, James Bottomley wrote:
> The gateway machines to cupertino (gsyfrf11/10) have been inaccessible
> for most of last week.  Can we get someone local to give them a poke and
> see what's up with them?

Dave Anglin asked me about it during OLS.  I suggested he poke Rick
Jones ...

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Cupertino test ring problem?

[Rick Jones]

Matthew Wilcox wrote:
> On Mon, Jul 28, 2008 at 09:19:05AM -0500, James Bottomley wrote:
> 
>>The gateway machines to cupertino (gsyfrf11/10) have been inaccessible
>>for most of last week.  Can we get someone local to give them a poke and
>>see what's up with them?
> 
> 
> Dave Anglin asked me about it during OLS.  I suggested he poke Rick
> Jones ...

That explains that mild ache in my side :)

The Cupertino test ring got moved last week from one machine room to 
another. This also included netperf.org and ftp.cup.hp.com. Shutdown was 
about 1600 Pacific time on the 23rd, and power was restored to the racks 
by about that time on Thursday.  I brought-up netperf.org, 
ftp.cup.hp.com and they talked fine and dandy on the network, so I 
simply powered-on the lp1000r gateway and ass-u-me-d it would work as 
well.  I guess it didn't :(  and I will try to take a look at them today.

rick jones

Re: Cupertino test ring problem?

[Matthew Wilcox]

On Mon, Jul 28, 2008 at 10:09:54AM -0700, Rick Jones wrote:
> well.  I guess it didn't :(  and I will try to take a look at them today.

Thanks, Rick!

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Cupertino test ring problem?

[Rick Jones]

A couple of the rx2600's were not powered-up, so I've powered them up. 
One of the rp34xx's does not seem "happy" and will need further 
diagnosis.  If there are other things still "not right" with the ring, 
please feel free to let me know the specifics.

rick jones

Re: Cupertino test ring problem?

[James Bottomley]

On Tue, 2008-07-29 at 13:03 -0700, Rick Jones wrote:
> A couple of the rx2600's were not powered-up, so I've powered them up. 
> One of the rp34xx's does not seem "happy" and will need further 
> diagnosis.  If there are other things still "not right" with the ring, 
> please feel free to let me know the specifics.

gsyprf11 and gsyprf10 are still not responding to pings ... could the IP
routings have changed or something?

James

Re: Cupertino test ring problem?

[Rick Jones]

> gsyprf11 and gsyprf10 are still not responding to pings ... could the
> IP routings have changed or something?

 > I can't connect to port 22 on any of gsyprf3, gsyprf10 or gsyprf11.

Well, the IP's have remained the same, but the systems are physically in 
a different building.  Both netperf.org and ftp.cup.hp.com have moved 
from the same starting point to the same end-point.  If folks cannot 
ping them or cannot get to port 22 on those then there is still 
something amis in the network.  Otherwise there is still something amis 
with gsyprf[3|10|11].

rick jones

Re: Cupertino test ring problem?

[James Bottomley]

On Tue, 2008-07-29 at 13:57 -0700, Rick Jones wrote:
> > gsyprf11 and gsyprf10 are still not responding to pings ... could the
> > IP routings have changed or something?
> 
>  > I can't connect to port 22 on any of gsyprf3, gsyprf10 or gsyprf11.
> 
> Well, the IP's have remained the same, but the systems are physically in 
> a different building.  Both netperf.org and ftp.cup.hp.com have moved 
> from the same starting point to the same end-point.  If folks cannot 
> ping them or cannot get to port 22 on those then there is still 
> something amis in the network.  Otherwise there is still something amis 
> with gsyprf[3|10|11].

gsyprf10 at least is one of the ia64 boxes.  Helpfully it identifies
itself as lp1000 or something at the login prompt.  gsyprf11 is a PA
A500 type box.  It should identify as gsyprf11 at the login prompt.  We
only need one up and running to begin diagnosing as we should be able to
then get to other remote consoles.

James

Re: Cupertino test ring problem?

[Grant Grundler]

On Tue, Jul 29, 2008 at 05:09:45PM -0500, James Bottomley wrote:
> On Tue, 2008-07-29 at 13:57 -0700, Rick Jones wrote:
> > > gsyprf11 and gsyprf10 are still not responding to pings ... could the
> > > IP routings have changed or something?
> > 
> >  > I can't connect to port 22 on any of gsyprf3, gsyprf10 or gsyprf11.
> > 
> > Well, the IP's have remained the same, but the systems are physically in 
> > a different building.  Both netperf.org and ftp.cup.hp.com have moved 
> > from the same starting point to the same end-point.  If folks cannot 
> > ping them or cannot get to port 22 on those then there is still 
> > something amis in the network.  Otherwise there is still something amis 
> > with gsyprf[3|10|11].
> 
> gsyprf10 at least is one of the ia64 boxes.  Helpfully it identifies
> itself as lp1000 or something at the login prompt.

gsyprf10 is an x86 machine (HP lp1000r netserver).

> gsyprf11 is a PA A500 type box.  It should identify as gsyprf11
> at the login prompt.  We
> only need one up and running to begin diagnosing as we should be able to
> then get to other remote consoles.

I'll check with Rick tomorrow to see when I can drop by to help resurrect
them.

I expected gsyprf10 to auto reboot on it's own.
I'll change gsyprf11 and gsyprf3 to also autoboot since I don't think they
do at the moment.

cheers,
grant

> 
> James
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Cupertino test ring problem?

[Rick Jones]

Grant Grundler wrote:
> On Tue, Jul 29, 2008 at 05:09:45PM -0500, James Bottomley wrote:
> 
>>On Tue, 2008-07-29 at 13:57 -0700, Rick Jones wrote:
>>
>>>>gsyprf11 and gsyprf10 are still not responding to pings ... could the
>>>>IP routings have changed or something?
>>>
>>> > I can't connect to port 22 on any of gsyprf3, gsyprf10 or gsyprf11.
>>>
>>>Well, the IP's have remained the same, but the systems are physically in 
>>>a different building.  Both netperf.org and ftp.cup.hp.com have moved 
>>>from the same starting point to the same end-point.  If folks cannot 
>>>ping them or cannot get to port 22 on those then there is still 
>>>something amis in the network.  Otherwise there is still something amis 
>>>with gsyprf[3|10|11].
>>
>>gsyprf10 at least is one of the ia64 boxes.  Helpfully it identifies
>>itself as lp1000 or something at the login prompt.
> 
> 
> gsyprf10 is an x86 machine (HP lp1000r netserver).
> 
> 
>>gsyprf11 is a PA A500 type box.  It should identify as gsyprf11
>>at the login prompt.  We
>>only need one up and running to begin diagnosing as we should be able to
>>then get to other remote consoles.
> 
> 
> I'll check with Rick tomorrow to see when I can drop by to help resurrect
> them.
> 
> I expected gsyprf10 to auto reboot on it's own.
> I'll change gsyprf11 and gsyprf3 to also autoboot since I don't think they
> do at the moment.

I can confirm that gsyperf3 was/is not set to autoboot.  I can also 
state that it cannot successfully boot.  During POST it spits-out FRU 
problem messages and during OS boot boatloads of Segmentation Fault 
output while it tries to boot, and end-up in busybox.

I'm not sure that gsyprf11 (pa) is connected to the external net.

I tried swapping the cables on gsyprf10 (the lp1000r)  I have to see if 
I can find the old monitor and keyboard to see what its boot state 
happens to be.

Grant - wrt times, I'm here all week, from about 0930 to about 0330 each 
day.  I'd be around later but this week I'm playing single-parent :)

rick jones

Re: Cupertino test ring problem?

[Grant Grundler]

On Thu, Jul 31, 2008 at 10:26:24AM -0700, Rick Jones wrote:
...
> I can confirm that gsyperf3 was/is not set to autoboot.  I can also state 
> that it cannot successfully boot.  During POST it spits-out FRU problem 
> messages and during OS boot boatloads of Segmentation Fault output while it 
> tries to boot, and end-up in busybox.

Debian kernel didn't find it's root disk...older kernel I built booted fine.
It's up and I restored the default to a kernel that boots. I can test
other debian kernels on other machines and update gsyprf3 once those
are proven to work.

Rick and I swapped gsyprf3 (1.5Ghz proto CPUs and pre-production mother
board and case) for a production unit (1.3 Ghz CPUs and 8GB of RAM).

> I'm not sure that gsyprf11 (pa) is connected to the external net.

It wasn't and the default debian kernel didn't boot either.
I've set the default kernel to jda's 2.6.22.19 patched kernel.

> I tried swapping the cables on gsyprf10 (the lp1000r)  I have to see if I 
> can find the old monitor and keyboard to see what its boot state happens to 
> be.

again, bad 2.6.24 debian kernel. Rebooting to older (2.6.21) debian
kernel worked. Updated the machine but not willing to try a newer
kernel on this box unless I'm sitting in front of it with a console.

> Grant - wrt times, I'm here all week, from about 0930 to about 0330 each 
> day.  I'd be around later but this week I'm playing single-parent :)

thanks for helping this morning.
Getting the three key systems up was critical.
I can continue to muck with the rest.


cheers,
grant

>
> rick jones
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Cupertino test ring problem?

[Thibaut VARENE]

On Sat, Aug 2, 2008 at 1:31 AM, Grant Grundler
<grundler@parisc-linux.org> wrote:

> It wasn't and the default debian kernel didn't boot either.
> I've set the default kernel to jda's 2.6.22.19 patched kernel.

Is there a source tarball of that, or a list of applied patches? I
would very much like to use that "homebrew" kernel on my cluster as
well, until newer kernels are proven reliable enough...

Thx

T-Bone

Re: Cupertino test ring problem?

[John David Anglin]

> Is there a source tarball of that, or a list of applied patches? I
> would very much like to use that "homebrew" kernel on my cluster as
> well, until newer kernels are proven reliable enough...

I built a tar ball, linux-2.6.22.19-jda.tar.gz.  It is in my home directory
on gsyprf11.  The source is also there.  The most important patch is
compat_sys_getdents.d from Kyle.  The base is linux-2.6.22.19.tar.bz2
from kernel.org.  The .config file was derived from some earlier config
file on this machine (can't remember which).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Cupertino test ring problem?

[Thibaut VARENE]

On Mon, Aug 4, 2008 at 5:34 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> Is there a source tarball of that, or a list of applied patches? I
>> would very much like to use that "homebrew" kernel on my cluster as
>> well, until newer kernels are proven reliable enough...
>
> I built a tar ball, linux-2.6.22.19-jda.tar.gz.  It is in my home directory
> on gsyprf11.  The source is also there.  The most important patch is
> compat_sys_getdents.d from Kyle.  The base is linux-2.6.22.19.tar.bz2
> from kernel.org.  The .config file was derived from some earlier config
> file on this machine (can't remember which).

Thanks a lot, I'll fetch that later on!

T-Bone

X won't start with VisEG and 2.6.22.19

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

> > It wasn't and the default debian kernel didn't boot either.
> > I've set the default kernel to jda's 2.6.22.19 patched kernel.
> 
> Is there a source tarball of that, or a list of applied patches? I
> would very much like to use that "homebrew" kernel on my cluster as
> well, until newer kernels are proven reliable enough...

I should mention that I've had a problem with starting X with lenny
and 2.6.22.  This has been a problem for sometime.  I've tried simplifying
the xorg.conf file and adding the mode helper to the kernel, but I
haven't found the magic incantation that works.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

[-- Attachment #2: xorg.conf --]
[-- Type: text/plain, Size: 1740 bytes --]

# xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "Files"
EndSection

Section "InputDevice"
	Identifier	"Generic Keyboard"
	Driver		"kbd"
	Option		"CoreKeyboard"
	Option		"XkbRules"	"xorg"
	Option		"XkbModel"	"pc104"
	Option		"XkbLayout"	"us"
EndSection

Section "InputDevice"
	Identifier	"Configured Mouse"
	Driver		"mouse"
	Option		"CorePointer"
	Option		"Device"		"/dev/input/mice"
	Option		"Protocol"		"ImPS/2"
	Option		"Emulate3Buttons"	"true"
EndSection

Section "Device"
	Identifier	"HP VisEG"
	Driver		"fbdev"
	BusID		"PCI:2:3:0"
#	Option		"UseFBDev"		"true"
EndSection

Section "Monitor"
	Identifier	"NEC LCD1980SX"
	Option		"DPMS"			"true"
	HorizSync	20-107
	VertRefresh	50-85
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Device		"HP VisEG"
	Monitor		"NEC LCD1980SX"
	DefaultDepth	8
#	SubSection "Display"
#		Modes		"1280x1024"
#	EndSubSection
EndSection

Section "ServerLayout"
	Identifier	"Default Layout"
	Screen		"Default Screen"
	InputDevice	"Generic Keyboard"
	InputDevice	"Configured Mouse"
EndSection

Section "ServerFlags"
	Option "AIGLX"	"false"
#	Option "DisableVidModeExtension"  "true"
#	Option "NoTrapSignals"  "true"
EndSection

[-- Attachment #3: Xorg.0.log --]
[-- Type: text/plain, Size: 19437 bytes --]


X.Org X Server 1.4.2
Release Date: 11 June 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian (xorg-server 2:1.4.2-2)
Current Operating System: Linux hiauly6 2.6.22.19 #17 Tue Aug 5 18:17:30 EDT 2008 parisc
Build Date: 22 July 2008  02:19:19PM
 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Aug  5 18:23:03 2008
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) |   |-->Monitor "NEC LCD1980SX"
(**) |   |-->Device "HP VisEG"
(**) |-->Input Device "Generic Keyboard"
(**) |-->Input Device "Configured Mouse"
(**) Option "AIGLX" "false"
(==) Automatically adding devices
(==) Automatically enabling devices
(==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/cyrillic,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) No APM support in BIOS or kernel
(II) Loader magic: 0x1cbcd4
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.3
	X.Org Video Driver: 2.0
	X.Org XInput driver : 2.0
	X.Org Server Extension : 0.3
	X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: "pcidata"
(II) Loading /usr/lib/xorg/modules//libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
	compiled for 1.4.2, module version = 1.0.0
	ABI class: X.Org Video Driver, version 2.0
(++) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:0c:0: chip 1011,0019 card 103c,104f rev 41 class 02,00,00 hdr 00
(II) PCI: 00:0d:0: chip 11d4,1889 card 11d4,1889 rev 00 class 04,01,00 hdr 00
(II) PCI: 00:0e:0: chip 100b,0002 card 0000,0000 rev 03 class 01,01,8f hdr 80
(II) PCI: 00:0e:1: chip 100b,000e card 0000,0000 rev 01 class 06,80,00 hdr 80
(II) PCI: 00:0e:2: chip 100b,0012 card 0000,0000 rev 02 class 0c,03,10 hdr 80
(II) PCI: 00:0f:0: chip 1000,000b card 1000,1000 rev 07 class 01,00,00 hdr 80
(II) PCI: 00:0f:1: chip 1000,000b card 1000,1000 rev 07 class 01,00,00 hdr 80
(II) PCI: 01:06:0: chip 1000,0021 card 1000,1070 rev 01 class 01,00,00 hdr 80
(II) PCI: 01:06:1: chip 1000,0021 card 1000,1070 rev 01 class 01,00,00 hdr 80
(II) PCI: 02:03:0: chip 103c,1005 card 0000,0000 rev 03 class 03,80,00 hdr 00
(II) PCI: End of PCI scan
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (0,0,0), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 0 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) Host-to-PCI bridge:
(II) Bus 1: bridge is at (0:0:0), (1,1,0), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 1 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 1 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 1 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) Host-to-PCI bridge:
(II) Bus 2: bridge is at (0:0:0), (2,2,0), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 2 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 2 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 2 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(--) PCI:*(2:3:0) Hewlett-Packard Company A4977A Visualize EG rev 3, Mem @ 0xfa000000/25, BIOS @ 0xf6000000/16
(II) Addressable bus resource ranges are
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
	[1] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) OS-reported resource ranges:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) Active PCI resource ranges:
	[0] -1	0	0xf4800000 - 0xf4801fff (0x2000) MX[B]
	[1] -1	0	0xf4804000 - 0xf48043ff (0x400) MX[B]
	[2] -1	0	0xf4802000 - 0xf4803fff (0x2000) MX[B]
	[3] -1	0	0xf4805000 - 0xf48053ff (0x400) MX[B]
	[4] -1	0	0xf4000000 - 0xf4001fff (0x2000) MX[B]
	[5] -1	0	0xf4004000 - 0xf40043ff (0x400) MX[B]
	[6] -1	0	0xf4002000 - 0xf4003fff (0x2000) MX[B]
	[7] -1	0	0xf4005000 - 0xf40053ff (0x400) MX[B]
	[8] -1	0	0xf4006000 - 0xf4006fff (0x1000) MX[B]
	[9] -1	0	0xf4007000 - 0xf4007fff (0x1000) MX[B]
	[10] -1	0	0xf4009000 - 0xf400900f (0x10) MX[B]
	[11] -1	0	0xf400a000 - 0xf400a00f (0x10) MX[B]
	[12] -1	0	0xf400b000 - 0xf400b00f (0x10) MX[B]
	[13] -1	0	0xf400c000 - 0xf400c1ff (0x200) MX[B]
	[14] -1	0	0xf4008000 - 0xf40083ff (0x400) MX[B]
	[15] -1	0	0xf6000000 - 0xf600ffff (0x10000) MX[B](B)
	[16] -1	0	0xfa000000 - 0xfbffffff (0x2000000) MX[B](B)
	[17] -1	0	0x00012000 - 0x000120ff (0x100) IX[B]
	[18] -1	0	0x00012100 - 0x000121ff (0x100) IX[B]
	[19] -1	0	0x00000800 - 0x000008ff (0x100) IX[B]
	[20] -1	0	0x00000900 - 0x000009ff (0x100) IX[B]
	[21] -1	0	0x00000a00 - 0x00000a0f (0x10) IX[B]
	[22] -1	0	0x00000b00 - 0x00000b03 (0x4) IX[B]
	[23] -1	0	0x00000d00 - 0x00000d07 (0x8) IX[B]
	[24] -1	0	0x00000e00 - 0x00000e03 (0x4) IX[B]
	[25] -1	0	0x00000f00 - 0x00000f07 (0x8) IX[B]
	[26] -1	0	0x00001000 - 0x0000107f (0x80) IX[B]
(II) Active PCI resource ranges after removing overlaps:
	[0] -1	0	0xf4800000 - 0xf4801fff (0x2000) MX[B]
	[1] -1	0	0xf4804000 - 0xf48043ff (0x400) MX[B]
	[2] -1	0	0xf4802000 - 0xf4803fff (0x2000) MX[B]
	[3] -1	0	0xf4805000 - 0xf48053ff (0x400) MX[B]
	[4] -1	0	0xf4000000 - 0xf4001fff (0x2000) MX[B]
	[5] -1	0	0xf4004000 - 0xf40043ff (0x400) MX[B]
	[6] -1	0	0xf4002000 - 0xf4003fff (0x2000) MX[B]
	[7] -1	0	0xf4005000 - 0xf40053ff (0x400) MX[B]
	[8] -1	0	0xf4006000 - 0xf4006fff (0x1000) MX[B]
	[9] -1	0	0xf4007000 - 0xf4007fff (0x1000) MX[B]
	[10] -1	0	0xf4009000 - 0xf400900f (0x10) MX[B]
	[11] -1	0	0xf400a000 - 0xf400a00f (0x10) MX[B]
	[12] -1	0	0xf400b000 - 0xf400b00f (0x10) MX[B]
	[13] -1	0	0xf400c000 - 0xf400c1ff (0x200) MX[B]
	[14] -1	0	0xf4008000 - 0xf40083ff (0x400) MX[B]
	[15] -1	0	0xf6000000 - 0xf600ffff (0x10000) MX[B](B)
	[16] -1	0	0xfa000000 - 0xfbffffff (0x2000000) MX[B](B)
	[17] -1	0	0x00012000 - 0x000120ff (0x100) IX[B]
	[18] -1	0	0x00012100 - 0x000121ff (0x100) IX[B]
	[19] -1	0	0x00000800 - 0x000008ff (0x100) IX[B]
	[20] -1	0	0x00000900 - 0x000009ff (0x100) IX[B]
	[21] -1	0	0x00000a00 - 0x00000a0f (0x10) IX[B]
	[22] -1	0	0x00000b00 - 0x00000b03 (0x4) IX[B]
	[23] -1	0	0x00000d00 - 0x00000d07 (0x8) IX[B]
	[24] -1	0	0x00000e00 - 0x00000e03 (0x4) IX[B]
	[25] -1	0	0x00000f00 - 0x00000f07 (0x8) IX[B]
	[26] -1	0	0x00001000 - 0x0000107f (0x80) IX[B]
(II) OS-reported resource ranges after removing overlaps with PCI:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) All system resource ranges:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0xf4800000 - 0xf4801fff (0x2000) MX[B]
	[5] -1	0	0xf4804000 - 0xf48043ff (0x400) MX[B]
	[6] -1	0	0xf4802000 - 0xf4803fff (0x2000) MX[B]
	[7] -1	0	0xf4805000 - 0xf48053ff (0x400) MX[B]
	[8] -1	0	0xf4000000 - 0xf4001fff (0x2000) MX[B]
	[9] -1	0	0xf4004000 - 0xf40043ff (0x400) MX[B]
	[10] -1	0	0xf4002000 - 0xf4003fff (0x2000) MX[B]
	[11] -1	0	0xf4005000 - 0xf40053ff (0x400) MX[B]
	[12] -1	0	0xf4006000 - 0xf4006fff (0x1000) MX[B]
	[13] -1	0	0xf4007000 - 0xf4007fff (0x1000) MX[B]
	[14] -1	0	0xf4009000 - 0xf400900f (0x10) MX[B]
	[15] -1	0	0xf400a000 - 0xf400a00f (0x10) MX[B]
	[16] -1	0	0xf400b000 - 0xf400b00f (0x10) MX[B]
	[17] -1	0	0xf400c000 - 0xf400c1ff (0x200) MX[B]
	[18] -1	0	0xf4008000 - 0xf40083ff (0x400) MX[B]
	[19] -1	0	0xf6000000 - 0xf600ffff (0x10000) MX[B](B)
	[20] -1	0	0xfa000000 - 0xfbffffff (0x2000000) MX[B](B)
	[21] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[22] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[23] -1	0	0x00012000 - 0x000120ff (0x100) IX[B]
	[24] -1	0	0x00012100 - 0x000121ff (0x100) IX[B]
	[25] -1	0	0x00000800 - 0x000008ff (0x100) IX[B]
	[26] -1	0	0x00000900 - 0x000009ff (0x100) IX[B]
	[27] -1	0	0x00000a00 - 0x00000a0f (0x10) IX[B]
	[28] -1	0	0x00000b00 - 0x00000b03 (0x4) IX[B]
	[29] -1	0	0x00000d00 - 0x00000d07 (0x8) IX[B]
	[30] -1	0	0x00000e00 - 0x00000e03 (0x4) IX[B]
	[31] -1	0	0x00000f00 - 0x00000f07 (0x8) IX[B]
	[32] -1	0	0x00001000 - 0x0000107f (0x80) IX[B]
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 1.4.2, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.3
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"
(II) Loading /usr/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 1.4.2, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.3
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
	compiled for 1.4.2, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.3
(**) AIGLX disabled
(II) Loading extension GLX
(II) LoadModule: "freetype"
(II) Loading /usr/lib/xorg/modules//fonts/libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
	compiled for 1.4.2, module version = 2.1.0
	Module class: X.Org Font Renderer
	ABI class: X.Org Font Renderer, version 0.5
(II) Loading font FreeType
(II) LoadModule: "record"
(II) Loading /usr/lib/xorg/modules/extensions//librecord.so
(II) Module record: vendor="X.Org Foundation"
	compiled for 1.4.2, module version = 1.13.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.3
(II) Loading extension RECORD
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.4.2, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.3
(II) Loading extension XFree86-DRI
(II) LoadModule: "fbdev"
(II) Loading /usr/lib/xorg/modules/drivers//fbdev_drv.so
(II) Module fbdev: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 0.4.0
	ABI class: X.Org Video Driver, version 2.0
(II) LoadModule: "kbd"
(II) Loading /usr/lib/xorg/modules/input//kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.3.1
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 2.0
(II) LoadModule: "mouse"
(II) Loading /usr/lib/xorg/modules/input//mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.3.0
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 2.0
(II) FBDEV: driver for framebuffer: fbdev
(II) Primary Device is: PCI 02:03:0
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Loading /usr/lib/xorg/modules/linux//libfbdevhw.so
(II) Module fbdevhw: vendor="X.Org Foundation"
	compiled for 1.4.2, module version = 0.0.2
	ABI class: X.Org Video Driver, version 2.0
(II) resource ranges after xf86ClaimFixedResources() call:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0xf4800000 - 0xf4801fff (0x2000) MX[B]
	[5] -1	0	0xf4804000 - 0xf48043ff (0x400) MX[B]
	[6] -1	0	0xf4802000 - 0xf4803fff (0x2000) MX[B]
	[7] -1	0	0xf4805000 - 0xf48053ff (0x400) MX[B]
	[8] -1	0	0xf4000000 - 0xf4001fff (0x2000) MX[B]
	[9] -1	0	0xf4004000 - 0xf40043ff (0x400) MX[B]
	[10] -1	0	0xf4002000 - 0xf4003fff (0x2000) MX[B]
	[11] -1	0	0xf4005000 - 0xf40053ff (0x400) MX[B]
	[12] -1	0	0xf4006000 - 0xf4006fff (0x1000) MX[B]
	[13] -1	0	0xf4007000 - 0xf4007fff (0x1000) MX[B]
	[14] -1	0	0xf4009000 - 0xf400900f (0x10) MX[B]
	[15] -1	0	0xf400a000 - 0xf400a00f (0x10) MX[B]
	[16] -1	0	0xf400b000 - 0xf400b00f (0x10) MX[B]
	[17] -1	0	0xf400c000 - 0xf400c1ff (0x200) MX[B]
	[18] -1	0	0xf4008000 - 0xf40083ff (0x400) MX[B]
	[19] -1	0	0xf6000000 - 0xf600ffff (0x10000) MX[B](B)
	[20] -1	0	0xfa000000 - 0xfbffffff (0x2000000) MX[B](B)
	[21] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[22] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[23] -1	0	0x00012000 - 0x000120ff (0x100) IX[B]
	[24] -1	0	0x00012100 - 0x000121ff (0x100) IX[B]
	[25] -1	0	0x00000800 - 0x000008ff (0x100) IX[B]
	[26] -1	0	0x00000900 - 0x000009ff (0x100) IX[B]
	[27] -1	0	0x00000a00 - 0x00000a0f (0x10) IX[B]
	[28] -1	0	0x00000b00 - 0x00000b03 (0x4) IX[B]
	[29] -1	0	0x00000d00 - 0x00000d07 (0x8) IX[B]
	[30] -1	0	0x00000e00 - 0x00000e03 (0x4) IX[B]
	[31] -1	0	0x00000f00 - 0x00000f07 (0x8) IX[B]
	[32] -1	0	0x00001000 - 0x0000107f (0x80) IX[B]
(**) FBDEV(0): claimed PCI slot 2:3:0
(II) FBDEV(0): using default device
(II) resource ranges after probing:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0xf4800000 - 0xf4801fff (0x2000) MX[B]
	[5] -1	0	0xf4804000 - 0xf48043ff (0x400) MX[B]
	[6] -1	0	0xf4802000 - 0xf4803fff (0x2000) MX[B]
	[7] -1	0	0xf4805000 - 0xf48053ff (0x400) MX[B]
	[8] -1	0	0xf4000000 - 0xf4001fff (0x2000) MX[B]
	[9] -1	0	0xf4004000 - 0xf40043ff (0x400) MX[B]
	[10] -1	0	0xf4002000 - 0xf4003fff (0x2000) MX[B]
	[11] -1	0	0xf4005000 - 0xf40053ff (0x400) MX[B]
	[12] -1	0	0xf4006000 - 0xf4006fff (0x1000) MX[B]
	[13] -1	0	0xf4007000 - 0xf4007fff (0x1000) MX[B]
	[14] -1	0	0xf4009000 - 0xf400900f (0x10) MX[B]
	[15] -1	0	0xf400a000 - 0xf400a00f (0x10) MX[B]
	[16] -1	0	0xf400b000 - 0xf400b00f (0x10) MX[B]
	[17] -1	0	0xf400c000 - 0xf400c1ff (0x200) MX[B]
	[18] -1	0	0xf4008000 - 0xf40083ff (0x400) MX[B]
	[19] -1	0	0xf6000000 - 0xf600ffff (0x10000) MX[B](B)
	[20] -1	0	0xfa000000 - 0xfbffffff (0x2000000) MX[B](B)
	[21] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
	[22] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
	[23] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
	[24] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[25] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[26] -1	0	0x00012000 - 0x000120ff (0x100) IX[B]
	[27] -1	0	0x00012100 - 0x000121ff (0x100) IX[B]
	[28] -1	0	0x00000800 - 0x000008ff (0x100) IX[B]
	[29] -1	0	0x00000900 - 0x000009ff (0x100) IX[B]
	[30] -1	0	0x00000a00 - 0x00000a0f (0x10) IX[B]
	[31] -1	0	0x00000b00 - 0x00000b03 (0x4) IX[B]
	[32] -1	0	0x00000d00 - 0x00000d07 (0x8) IX[B]
	[33] -1	0	0x00000e00 - 0x00000e03 (0x4) IX[B]
	[34] -1	0	0x00000f00 - 0x00000f07 (0x8) IX[B]
	[35] -1	0	0x00001000 - 0x0000107f (0x80) IX[B]
	[36] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
	[37] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]
(II) Setting vga for screen 0.
(II) FBDEV(0): Creating default Display subsection in Screen section
	"Default Screen" for depth/fbbpp 8/8
(**) FBDEV(0): Depth 8, (--) framebuffer bpp 8
(==) FBDEV(0): Default visual is PseudoColor
(==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0)
(II) FBDEV(0): hardware: stifb (video memory: 2048kB)
(II) FBDEV(0): checking modes against framebuffer device...
(II) FBDEV(0): checking modes against monitor...
(--) FBDEV(0): Virtual size is 1280x1024 (pitch 1280)
(**) FBDEV(0):  Built-in mode "current": 28000.0 MHz, 21875.0 kHz, 21362.3 Hz
(II) FBDEV(0): Modeline "current"x0.0  28000.00  1280 1280 1280 1280  1024 1024 1024 1024 -hsync -vsync -csync (21875.0 kHz)
(==) FBDEV(0): DPI set to (96, 96)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/lib/xorg/modules//libfb.so
(II) Module fb: vendor="X.Org Foundation"
	compiled for 1.4.2, module version = 1.0.0
	ABI class: X.Org ANSI C Emulation, version 0.3
(**) FBDEV(0): using shadow framebuffer
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/lib/xorg/modules//libshadow.so
(II) Module shadow: vendor="X.Org Foundation"
	compiled for 1.4.2, module version = 1.1.0
	ABI class: X.Org ANSI C Emulation, version 0.3
(II) do I need RAC?  No, I don't.
(II) resource ranges after preInit:
	[0] 0	0	0xfa000000 - 0xfbffffff (0x2000000) MX[B]
	[1] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[2] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[3] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[4] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[5] -1	0	0xf4800000 - 0xf4801fff (0x2000) MX[B]
	[6] -1	0	0xf4804000 - 0xf48043ff (0x400) MX[B]
	[7] -1	0	0xf4802000 - 0xf4803fff (0x2000) MX[B]
	[8] -1	0	0xf4805000 - 0xf48053ff (0x400) MX[B]
	[9] -1	0	0xf4000000 - 0xf4001fff (0x2000) MX[B]
	[10] -1	0	0xf4004000 - 0xf40043ff (0x400) MX[B]
	[11] -1	0	0xf4002000 - 0xf4003fff (0x2000) MX[B]
	[12] -1	0	0xf4005000 - 0xf40053ff (0x400) MX[B]
	[13] -1	0	0xf4006000 - 0xf4006fff (0x1000) MX[B]
	[14] -1	0	0xf4007000 - 0xf4007fff (0x1000) MX[B]
	[15] -1	0	0xf4009000 - 0xf400900f (0x10) MX[B]
	[16] -1	0	0xf400a000 - 0xf400a00f (0x10) MX[B]
	[17] -1	0	0xf400b000 - 0xf400b00f (0x10) MX[B]
	[18] -1	0	0xf400c000 - 0xf400c1ff (0x200) MX[B]
	[19] -1	0	0xf4008000 - 0xf40083ff (0x400) MX[B]
	[20] -1	0	0xf6000000 - 0xf600ffff (0x10000) MX[B](B)
	[21] -1	0	0xfa000000 - 0xfbffffff (0x2000000) MX[B](B)
	[22] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
	[23] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
	[24] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
	[25] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[26] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[27] -1	0	0x00012000 - 0x000120ff (0x100) IX[B]
	[28] -1	0	0x00012100 - 0x000121ff (0x100) IX[B]
	[29] -1	0	0x00000800 - 0x000008ff (0x100) IX[B]
	[30] -1	0	0x00000900 - 0x000009ff (0x100) IX[B]
	[31] -1	0	0x00000a00 - 0x00000a0f (0x10) IX[B]
	[32] -1	0	0x00000b00 - 0x00000b03 (0x4) IX[B]
	[33] -1	0	0x00000d00 - 0x00000d07 (0x8) IX[B]
	[34] -1	0	0x00000e00 - 0x00000e03 (0x4) IX[B]
	[35] -1	0	0x00000f00 - 0x00000f07 (0x8) IX[B]
	[36] -1	0	0x00001000 - 0x0000107f (0x80) IX[B]
	[37] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
	[38] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]
(EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode
(EE) FBDEV(0): mode initialization failed

Fatal server error:
AddScreen/ScreenInit failed for driver 0

Re: X won't start with VisEG and 2.6.22.19

[Guy Martin]

Hi Dave,

This has been introduced in latest Xorg. When it modify the fb device,
Xorg query the kernel again to make sure changes are the expected ones.
Apparently, stifb doesn't return what it was expecting.

You'll find the Xorg code in hw/xfree86/fbdevhw/fbdevhw.c,
fbdevHWSetMode().


Cheers,
  Guy


On Tue, 5 Aug 2008 21:42:08 -0400
John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:

> > > It wasn't and the default debian kernel didn't boot either.
> > > I've set the default kernel to jda's 2.6.22.19 patched kernel.
> > 
> > Is there a source tarball of that, or a list of applied patches? I
> > would very much like to use that "homebrew" kernel on my cluster as
> > well, until newer kernels are proven reliable enough...
> 
> I should mention that I've had a problem with starting X with lenny
> and 2.6.22.  This has been a problem for sometime.  I've tried
> simplifying the xorg.conf file and adding the mode helper to the
> kernel, but I haven't found the magic incantation that works.
> 
> Dave


-- 
Guy Martin
Gentoo Linux - HPPA port lead

Re: X won't start with VisEG and 2.6.22.19

[Helge Deller]

Guy, thanks for the hint, and yes I see this problem as well.

The problem is really caused by hw/xfree86/fbdevhw/fbdevhw.c.

The driver sets a video mode and then checks if the syscall modified the 
parameters with the function fbdev_modes_equal():

--snip--
/* static*/ Bool
fbdev_modes_equal(struct fb_var_screeninfo *set, struct 
fb_var_screeninfo *req)
{
         return (set->xres_virtual >= req->xres_virtual &&
                 set->yres_virtual >= req->yres_virtual &&
                 set->bits_per_pixel == req->bits_per_pixel &&
                 set->red.length == req->red.length &&
                 set->green.length == req->green.length &&
                 set->blue.length == req->blue.length &&
                 set->xres == req->xres && set->yres == req->yres &&
                 set->pixclock == req->pixclock &&
                 set->right_margin == req->right_margin &&
                 set->hsync_len == req->hsync_len &&
                 set->left_margin == req->left_margin &&
                 set->lower_margin == req->lower_margin &&
                 set->vsync_len == req->vsync_len &&
                 set->upper_margin == req->upper_margin &&
                 set->sync == req->sync && set->vmode == req->vmode);
}
--snip--

Tracing with gdb gives the following:

Breakpoint 1, fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8)
     at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
256     }
(gdb) p *set
$1 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
xoffset = 0, yoffset = 0,
   bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
msb_right = 0}, green = {offset = 0,
     length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
msb_right = 0}, transp = {offset = 0,
     length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
width = 0, accel_flags = 0,
   pixclock = 0, left_margin = 0, right_margin = 0, upper_margin = 0, 
lower_margin = 0, hsync_len = 0,
   vsync_len = 0, sync = 0, vmode = 0, reserved = {0, 0, 0, 0, 0, 0}}

(gdb) p *req
$2 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
xoffset = 0, yoffset = 0,
   bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
msb_right = 0}, green = {offset = 0,
     length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
msb_right = 0}, transp = {offset = 0,
     length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
width = 0, accel_flags = 0,
   pixclock = 22271, left_margin = 56, right_margin = 8, upper_margin = 
41, lower_margin = 0,
   hsync_len = 176, vsync_len = 8, sync = 3, vmode = 1, reserved = {0, 
0, 0, 0, 0, 0}}

(gdb) bt
#0  fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8) at 
../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
#1  0x40bcfb64 in fbdevHWSetMode (pScrn=0x2142a0, mode=<value optimized 
out>, check=1)
     at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:528
#2  0x40bd07e8 in fbdevHWSetVideoModes (pScrn=0x2142a0) at 
../../../../hw/xfree86/fbdevhw/fbdevhw.c:568
#3  0x40cf5bec in ?? () from /usr/lib/xorg/modules/drivers//fbdev_drv.so
#4  0x00074e88 in InitOutput ()
#5  0x00039d04 in main ()

As you can see, the main video parameters are OK, while the 
monitor/modeline values (pixclock, left_margin, right_margin, 
upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
were changed to zero.

Interestingly the stifb driver does not touch those values at all. 
Everything is done inside the main fbmem.c core driver, so it seems it 
could become a generic problem for other framebuffer drivers as well.

I don't see a reason, why a framebuffer driver should care about 
modelines (except for resolution and bpp) at all. OK, on a i386 with 
e.g. vgafb you might be able to change the resolution, but on the hppa 
architecture with the stifb driver this is not the case. It's a fixed 
resolution with (often) a fixed frequency monitor which can't be changed 
at runtime from inside the OS.

Any ideas?
Should I open a debian bug report?
Maybe the fbdev_modes_equal() function should just ignore any changes to 
  the timings?

Helge


xorg log file:
(II) LoadModule: "fbdevhw"
(II) Loading /usr/lib/xorg/modules/linux//libfbdevhw.so
(II) Module fbdevhw: vendor="X.Org Foundation"
         compiled for 1.4.2, module version = 0.0.2
         ABI class: X.Org Video Driver, version 2.0
(II) FBDEV(0): using /dev/fb0
(II) Running in FRAMEBUFFER Mode
(**) FBDEV(0): Depth 8, (--) framebuffer bpp 8
(==) FBDEV(0): Default visual is PseudoColor
(==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0)
(II) FBDEV(0): hardware: stifb (video memory: 1536kB)
(**) FBDEV(0): Option "fbdev" "/dev/fb0"
(II) FBDEV(0): checking modes against framebuffer device...
(II) FBDEV(0):  mode "1024x768" test failed
(II) FBDEV(0): checking modes against monitor...
(--) FBDEV(0): Virtual size is 1024x768 (pitch 1024)
(**) FBDEV(0):  Built-in mode "current": 28000.0 MHz, 27343.8 kHz, 
35603.8 Hz
(II) FBDEV(0): Modeline "current"x0.0  28000.00  1024 1024 1024 1024 
768 768 768 768 -hsync -vsync -csync (27343.8 kHz)
(==) FBDEV(0): DPI set to (96, 96)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/lib/xorg/modules//libfb.so
(II) Module fb: vendor="X.Org Foundation"
         compiled for 1.4.2, module version = 1.0.0
         ABI class: X.Org ANSI C Emulation, version 0.3
(**) FBDEV(0): using shadow framebuffer
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/lib/xorg/modules//libshadow.so
(II) Module shadow: vendor="X.Org Foundation"
         compiled for 1.4.2, module version = 1.1.0
         ABI class: X.Org ANSI C Emulation, version 0.3
(EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode
(EE) FBDEV(0): mode initialization failed

Fatal server error:
AddScreen/ScreenInit failed for driver 0




Guy Martin wrote:
> Hi Dave,
> 
> This has been introduced in latest Xorg. When it modify the fb device,
> Xorg query the kernel again to make sure changes are the expected ones.
> Apparently, stifb doesn't return what it was expecting.
> 
> You'll find the Xorg code in hw/xfree86/fbdevhw/fbdevhw.c,
> fbdevHWSetMode().
> 
> 
> Cheers,
>   Guy
> 
> 
> On Tue, 5 Aug 2008 21:42:08 -0400
> John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> 
>>>> It wasn't and the default debian kernel didn't boot either.
>>>> I've set the default kernel to jda's 2.6.22.19 patched kernel.
>>> Is there a source tarball of that, or a list of applied patches? I
>>> would very much like to use that "homebrew" kernel on my cluster as
>>> well, until newer kernels are proven reliable enough...
>> I should mention that I've had a problem with starting X with lenny
>> and 2.6.22.  This has been a problem for sometime.  I've tried
>> simplifying the xorg.conf file and adding the mode helper to the
>> kernel, but I haven't found the magic incantation that works.
>>
>> Dave
> 
> 

Re: X won't start with VisEG and 2.6.22.19

[John David Anglin]

> The problem is really caused by hw/xfree86/fbdevhw/fbdevhw.c.
> 
> The driver sets a video mode and then checks if the syscall modified the 
> parameters with the function fbdev_modes_equal():

The maintainers for the fbdevhw.c and fbmem.c files need to be contacted
to determine what fbmem.c is allowed to change and what what fbdev_modes_equal
should be checking.  It's possible Debian is messing with the code as well,
so a Debian bug report wouldn't hurt.

Thanks for looking into this.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: X won't start with VisEG and 2.6.22.19

[Helge Deller]

John David Anglin wrote:
>> The problem is really caused by hw/xfree86/fbdevhw/fbdevhw.c.
>>
>> The driver sets a video mode and then checks if the syscall modified the 
>> parameters with the function fbdev_modes_equal():
> 
> The maintainers for the fbdevhw.c and fbmem.c files need to be contacted
> to determine what fbmem.c is allowed to change and what what fbdev_modes_equal
> should be checking.  It's possible Debian is messing with the code as well,
> so a Debian bug report wouldn't hurt.

I've opened a xorg bugzilla for now:
https://bugs.freedesktop.org/show_bug.cgi?id=17153

Helge

Re: X won't start with VisEG and 2.6.22.19

[John David Anglin]

> The driver sets a video mode and then checks if the syscall modified the 
> parameters with the function fbdev_modes_equal():
> 
> --snip--
> /* static*/ Bool
> fbdev_modes_equal(struct fb_var_screeninfo *set, struct 
> fb_var_screeninfo *req)
> {
>          return (set->xres_virtual >= req->xres_virtual &&
>                  set->yres_virtual >= req->yres_virtual &&
>                  set->bits_per_pixel == req->bits_per_pixel &&
>                  set->red.length == req->red.length &&
>                  set->green.length == req->green.length &&
>                  set->blue.length == req->blue.length &&
>                  set->xres == req->xres && set->yres == req->yres &&
>                  set->pixclock == req->pixclock &&
>                  set->right_margin == req->right_margin &&
>                  set->hsync_len == req->hsync_len &&
>                  set->left_margin == req->left_margin &&
>                  set->lower_margin == req->lower_margin &&
>                  set->vsync_len == req->vsync_len &&
>                  set->upper_margin == req->upper_margin &&
>                  set->sync == req->sync && set->vmode == req->vmode);

The is the kernel's implementation:

int fb_mode_is_equal(const struct fb_videomode *mode1,
                     const struct fb_videomode *mode2)
{
     return (mode1->xres         == mode2->xres &&
     mode1->yres         == mode2->yres &&
     mode1->pixclock     == mode2->pixclock &&
     mode1->hsync_len    == mode2->hsync_len &&
     mode1->vsync_len    == mode2->vsync_len &&
     mode1->left_margin  == mode2->left_margin &&
     mode1->right_margin == mode2->right_margin &&
     mode1->upper_margin == mode2->upper_margin &&
     mode1->lower_margin == mode2->lower_margin &&
     mode1->sync         == mode2->sync &&
     mode1->vmode        == mode2->vmode);
}

> Tracing with gdb gives the following:
> 
> Breakpoint 1, fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8)
>      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
> 256     }
> (gdb) p *set
> $1 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
> xoffset = 0, yoffset = 0,
>    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
> msb_right = 0}, green = {offset = 0,
>      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
> msb_right = 0}, transp = {offset = 0,
>      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
> width = 0, accel_flags = 0,
>    pixclock = 0, left_margin = 0, right_margin = 0, upper_margin = 0, 
> lower_margin = 0, hsync_len = 0,
>    vsync_len = 0, sync = 0, vmode = 0, reserved = {0, 0, 0, 0, 0, 0}}
> 
> (gdb) p *req
> $2 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
> xoffset = 0, yoffset = 0,
>    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
> msb_right = 0}, green = {offset = 0,
>      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
> msb_right = 0}, transp = {offset = 0,
>      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
> width = 0, accel_flags = 0,
>    pixclock = 22271, left_margin = 56, right_margin = 8, upper_margin = 
> 41, lower_margin = 0,
>    hsync_len = 176, vsync_len = 8, sync = 3, vmode = 1, reserved = {0, 
> 0, 0, 0, 0, 0}}
> 
> (gdb) bt
> #0  fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8) at 
> ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
> #1  0x40bcfb64 in fbdevHWSetMode (pScrn=0x2142a0, mode=<value optimized 
> out>, check=1)
>      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:528
> #2  0x40bd07e8 in fbdevHWSetVideoModes (pScrn=0x2142a0) at 
> ../../../../hw/xfree86/fbdevhw/fbdevhw.c:568
> #3  0x40cf5bec in ?? () from /usr/lib/xorg/modules/drivers//fbdev_drv.so
> #4  0x00074e88 in InitOutput ()
> #5  0x00039d04 in main ()
> 
> As you can see, the main video parameters are OK, while the 
> monitor/modeline values (pixclock, left_margin, right_margin, 
> upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
> were changed to zero.

> Any ideas?

Given that the kernel considers the above as part of the video mode,
I believe that this is a kernel bug.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Cupertino test ring problem?

[Matthew Wilcox]

On Tue, Jul 29, 2008 at 01:03:10PM -0700, Rick Jones wrote:
> A couple of the rx2600's were not powered-up, so I've powered them up. 
> One of the rp34xx's does not seem "happy" and will need further 
> diagnosis.  If there are other things still "not right" with the ring, 
> please feel free to let me know the specifics.

I can't connect to port 22 on any of gsyprf3, gsyprf10 or gsyprf11.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Cupertino test ring problem?

[Grant Grundler]

On Tue, Jul 29, 2008 at 02:26:03PM -0600, Matthew Wilcox wrote:
> On Tue, Jul 29, 2008 at 01:03:10PM -0700, Rick Jones wrote:
> > A couple of the rx2600's were not powered-up, so I've powered them up. 
> > One of the rp34xx's does not seem "happy" and will need further 
> > diagnosis.  If there are other things still "not right" with the ring, 
> > please feel free to let me know the specifics.
> 
> I can't connect to port 22 on any of gsyprf3, gsyprf10 or gsyprf11.

should all be working now.

thanks,
grant

> 
> -- 
> Intel are signing my paycheques ... these opinions are still mine
> "Bill, look, we understand that you're interested in selling us this
> operating system, but compare it to ours.  We can't possibly take such
> a retrograde step."
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: X won't start with VisEG and 2.6.22.19

[John David Anglin]

> > Tracing with gdb gives the following:
> > 
> > Breakpoint 1, fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8)
> >      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
> > 256     }
> > (gdb) p *set
> > $1 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
> > xoffset = 0, yoffset = 0,
> >    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
> > msb_right = 0}, green = {offset = 0,
> >      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
> > msb_right = 0}, transp = {offset = 0,
> >      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
> > width = 0, accel_flags = 0,
> >    pixclock = 0, left_margin = 0, right_margin = 0, upper_margin = 0, 
> > lower_margin = 0, hsync_len = 0,
> >    vsync_len = 0, sync = 0, vmode = 0, reserved = {0, 0, 0, 0, 0, 0}}
> > 
> > (gdb) p *req
> > $2 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
> > xoffset = 0, yoffset = 0,
> >    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
> > msb_right = 0}, green = {offset = 0,
> >      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
> > msb_right = 0}, transp = {offset = 0,
> >      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
> > width = 0, accel_flags = 0,
> >    pixclock = 22271, left_margin = 56, right_margin = 8, upper_margin = 
> > 41, lower_margin = 0,
> >    hsync_len = 176, vsync_len = 8, sync = 3, vmode = 1, reserved = {0, 
> > 0, 0, 0, 0, 0}}
> > 
> > (gdb) bt
> > #0  fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8) at 
> > ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
> > #1  0x40bcfb64 in fbdevHWSetMode (pScrn=0x2142a0, mode=<value optimized 
> > out>, check=1)
> >      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:528
> > #2  0x40bd07e8 in fbdevHWSetVideoModes (pScrn=0x2142a0) at 
> > ../../../../hw/xfree86/fbdevhw/fbdevhw.c:568
> > #3  0x40cf5bec in ?? () from /usr/lib/xorg/modules/drivers//fbdev_drv.so
> > #4  0x00074e88 in InitOutput ()
> > #5  0x00039d04 in main ()
> > 
> > As you can see, the main video parameters are OK, while the 
> > monitor/modeline values (pixclock, left_margin, right_margin, 
> > upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
> > were changed to zero.

It would appear that none of these values are relevant to the stifb.
The stifb.c code uses kzalloc to allocate the struct stifb_info, so
I think the above values should be zero.  Some code is clearly computing
values for pixclock, etc.  I don't see that this code is in the kernel.
It may be X that's making up these values.

I see in the log:

(II) FBDEV(0): hardware: stifb (video memory: 2048kB)
(II) FBDEV(0): checking modes against framebuffer device...
(II) FBDEV(0):  mode "1280x1024" test failed
(II) FBDEV(0): checking modes against monitor...
(--) FBDEV(0): Virtual size is 1280x1024 (pitch 1280)
(**) FBDEV(0):  Built-in mode "current": 28000.0 MHz, 21875.0 kHz, 21362.3 Hz
(II) FBDEV(0): Modeline "current"x0.0  28000.00  1280 1280 1280 1280  1024 1024 
1024 1024 -hsync -vsync -csync (21875.0 kHz)
(==) FBDEV(0): DPI set to (96, 96)

Could X be requesting a mode with invalid mode parameters?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: X won't start with VisEG and 2.6.22.19

[Helge Deller]

John David Anglin wrote:
>>> Tracing with gdb gives the following:
>>>
>>> Breakpoint 1, fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8)
>>>      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
>>> 256     }
>>> (gdb) p *set
>>> $1 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
>>> xoffset = 0, yoffset = 0,
>>>    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
>>> msb_right = 0}, green = {offset = 0,
>>>      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
>>> msb_right = 0}, transp = {offset = 0,
>>>      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
>>> width = 0, accel_flags = 0,
>>>    pixclock = 0, left_margin = 0, right_margin = 0, upper_margin = 0, 
>>> lower_margin = 0, hsync_len = 0,
>>>    vsync_len = 0, sync = 0, vmode = 0, reserved = {0, 0, 0, 0, 0, 0}}
>>>
>>> (gdb) p *req
>>> $2 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
>>> xoffset = 0, yoffset = 0,
>>>    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
>>> msb_right = 0}, green = {offset = 0,
>>>      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
>>> msb_right = 0}, transp = {offset = 0,
>>>      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
>>> width = 0, accel_flags = 0,
>>>    pixclock = 22271, left_margin = 56, right_margin = 8, upper_margin = 
>>> 41, lower_margin = 0,
>>>    hsync_len = 176, vsync_len = 8, sync = 3, vmode = 1, reserved = {0, 
>>> 0, 0, 0, 0, 0}}
>>>
>>> (gdb) bt
>>> #0  fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8) at 
>>> ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
>>> #1  0x40bcfb64 in fbdevHWSetMode (pScrn=0x2142a0, mode=<value optimized 
>>> out>, check=1)
>>>      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:528
>>> #2  0x40bd07e8 in fbdevHWSetVideoModes (pScrn=0x2142a0) at 
>>> ../../../../hw/xfree86/fbdevhw/fbdevhw.c:568
>>> #3  0x40cf5bec in ?? () from /usr/lib/xorg/modules/drivers//fbdev_drv.so
>>> #4  0x00074e88 in InitOutput ()
>>> #5  0x00039d04 in main ()
>>>
>>> As you can see, the main video parameters are OK, while the 
>>> monitor/modeline values (pixclock, left_margin, right_margin, 
>>> upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
>>> were changed to zero.
> 
> It would appear that none of these values are relevant to the stifb.
> The stifb.c code uses kzalloc to allocate the struct stifb_info, so
> I think the above values should be zero.  Some code is clearly computing
> values for pixclock, etc.  I don't see that this code is in the kernel.
> It may be X that's making up these values.
> 
> I see in the log:
> 
> (II) FBDEV(0): hardware: stifb (video memory: 2048kB)
> (II) FBDEV(0): checking modes against framebuffer device...
> (II) FBDEV(0):  mode "1280x1024" test failed
> (II) FBDEV(0): checking modes against monitor...
> (--) FBDEV(0): Virtual size is 1280x1024 (pitch 1280)
> (**) FBDEV(0):  Built-in mode "current": 28000.0 MHz, 21875.0 kHz, 21362.3 Hz
> (II) FBDEV(0): Modeline "current"x0.0  28000.00  1280 1280 1280 1280  1024 1024 
> 1024 1024 -hsync -vsync -csync (21875.0 kHz)
> (==) FBDEV(0): DPI set to (96, 96)
> 
> Could X be requesting a mode with invalid mode parameters?

In general X behaves correctly if you have a fb device, which is able to 
set sync timings.
But stifb and a few other fb drivers are not able to set sync timings, 
and for those X behaves IMHO wrong. For those X should assume that the 
timings set by the driver are correct as long as the resolution and bit 
depth are correct.

This is what happens:
1. In xorg.conf you configured a pixel resolution and bpp (e.g. 
1280x1024-16)
2. In xorg.conf you might have configured a monitor (with or without 
some timing/sync informations)
3. X reads those config parameters and try to set them through kernel calls.
4. Kernel returns that it now has set up the mode (1280x1024-16) and has 
set up the timings. Since stifb does not support timing modes, it 
returns zeros in those values (IMHO thats correct behavior if you look 
at the comments in skeletonfb.c)
5. X verifies the returned values and aborts since the timing values are 
different to what it fed to the kernel, although the resolution 
(1280x1024-16) is correctly set and returned like that.

I think X is right in noticing that the timing/sync values are not what 
it expected. Nevertheless, I would prefer that it would just warn (in 
the fbdev drivers only!) that the timings are incorrect instead of 
aborting completely. X is right to abort, if the pixel resolution and 
bpp can not be set.
So, X's tests should be like that:
a) resolution and bpp different -> abort
b) resolution and bpp correct, but sync timings/monitor timings 
different -> warn but continue

Right now X's tests are:
resolution, bpp or sync/monitor timings different -> abort.

Of course it's easily possible to change stifb in that it just takes any 
timing values, but that is not how it is documented in skeletonfb.

Helge

Re: X won't start with VisEG and 2.6.22.19

[John David Anglin]

> >>> As you can see, the main video parameters are OK, while the 
> >>> monitor/modeline values (pixclock, left_margin, right_margin, 
> >>> upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
> >>> were changed to zero.

The skeletonfb.c code makes it very clear that the only place where
a mode can be changed is in xxxfb_check_var:

*      Exception to the above rule:  Some drivers have a fixed mode, ie,
*      the hardware is already set at boot up, and cannot be changed.  In
*      this case, it is more acceptable that this function just return
*      a copy of the currently working var (info->var). Better is to not
*      implement this function, as the upper layer will do the copying
*      of the current var for you.
*
*      Note:  This is the only function where the contents of var can be
*      freely adjusted after the driver has been registered. If you find
*      that you have code outside of this function that alters the content
*      of var, then you are doing something wrong.  Note also that the
*      contents of info->var must be left untouched at all times after
*      driver registration.

As xxxfb_check_var is not implemented in stifb.c, it must be the upper
level that is changing the parameters.  Possibly, something to try is
the following:

 *      However, even if your hardware does not support mode changing,
 *      a set_par might be needed to at least initialize the hardware to
 *      a known working state, especially if it came back from another
 *      process that also modifies the same hardware, such as X.
 *
 *      If this is the case, a combination such as the following should work:
 *
 *      static int xxxfb_check_var(struct fb_var_screeninfo *var,
 *                                struct fb_info *info)
 *      {
 *              *var = info->var;
 *              return 0;
 *      }
 *
 *      static int xxxfb_set_par(struct fb_info *info)
 *      {
 *              init your hardware here
 *      }

> But stifb and a few other fb drivers are not able to set sync timings, 
> and for those X behaves IMHO wrong. For those X should assume that the 
> timings set by the driver are correct as long as the resolution and bit 
> depth are correct.
> 
> This is what happens:
> 1. In xorg.conf you configured a pixel resolution and bpp (e.g. 
> 1280x1024-16)
> 2. In xorg.conf you might have configured a monitor (with or without 
> some timing/sync informations)
> 3. X reads those config parameters and try to set them through kernel calls.
> 4. Kernel returns that it now has set up the mode (1280x1024-16) and has 
> set up the timings. Since stifb does not support timing modes, it 
> returns zeros in those values (IMHO thats correct behavior if you look 
> at the comments in skeletonfb.c)
> 5. X verifies the returned values and aborts since the timing values are 
> different to what it fed to the kernel, although the resolution 
> (1280x1024-16) is correctly set and returned like that.
> 
> I think X is right in noticing that the timing/sync values are not what 
> it expected. Nevertheless, I would prefer that it would just warn (in 
> the fbdev drivers only!) that the timings are incorrect instead of 
> aborting completely. X is right to abort, if the pixel resolution and 
> bpp can not be set.
> So, X's tests should be like that:
> a) resolution and bpp different -> abort
> b) resolution and bpp correct, but sync timings/monitor timings 
> different -> warn but continue
> 
> Right now X's tests are:
> resolution, bpp or sync/monitor timings different -> abort.
> 
> Of course it's easily possible to change stifb in that it just takes any 
> timing values, but that is not how it is documented in skeletonfb.

My sense in looking at the PR is that the freedesktop people won't
accept this approach.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: X won't start with VisEG and 2.6.22.19

[Helge Deller]

John David Anglin wrote:
>>>>> As you can see, the main video parameters are OK, while the 
>>>>> monitor/modeline values (pixclock, left_margin, right_margin, 
>>>>> upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
>>>>> were changed to zero.
> 
> The skeletonfb.c code makes it very clear that the only place where
> a mode can be changed is in xxxfb_check_var:
> 
> *      Exception to the above rule:  Some drivers have a fixed mode, ie,
> *      the hardware is already set at boot up, and cannot be changed.  In
> *      this case, it is more acceptable that this function just return
> *      a copy of the currently working var (info->var). Better is to not
> *      implement this function, as the upper layer will do the copying
> *      of the current var for you.
> *
> *      Note:  This is the only function where the contents of var can be
> *      freely adjusted after the driver has been registered. If you find
> *      that you have code outside of this function that alters the content
> *      of var, then you are doing something wrong.  Note also that the
> *      contents of info->var must be left untouched at all times after
> *      driver registration.
> 
> As xxxfb_check_var is not implemented in stifb.c, it must be the upper
> level that is changing the parameters.  Possibly, something to try is
> the following:
> 
>  *      However, even if your hardware does not support mode changing,
>  *      a set_par might be needed to at least initialize the hardware to
>  *      a known working state, especially if it came back from another
>  *      process that also modifies the same hardware, such as X.
>  *
>  *      If this is the case, a combination such as the following should work:
>  *
>  *      static int xxxfb_check_var(struct fb_var_screeninfo *var,
>  *                                struct fb_info *info)
>  *      {
>  *              *var = info->var;
>  *              return 0;
>  *      }
>  *
>  *      static int xxxfb_set_par(struct fb_info *info)
>  *      {
>  *              init your hardware here
>  *      }


Yes, exactly that would be the patch to make it work.


>> But stifb and a few other fb drivers are not able to set sync timings, 
>> and for those X behaves IMHO wrong. For those X should assume that the 
>> timings set by the driver are correct as long as the resolution and bit 
>> depth are correct.
>>
>> This is what happens:
>> 1. In xorg.conf you configured a pixel resolution and bpp (e.g. 
>> 1280x1024-16)
>> 2. In xorg.conf you might have configured a monitor (with or without 
>> some timing/sync informations)
>> 3. X reads those config parameters and try to set them through kernel calls.
>> 4. Kernel returns that it now has set up the mode (1280x1024-16) and has 
>> set up the timings. Since stifb does not support timing modes, it 
>> returns zeros in those values (IMHO thats correct behavior if you look 
>> at the comments in skeletonfb.c)
>> 5. X verifies the returned values and aborts since the timing values are 
>> different to what it fed to the kernel, although the resolution 
>> (1280x1024-16) is correctly set and returned like that.
>>
>> I think X is right in noticing that the timing/sync values are not what 
>> it expected. Nevertheless, I would prefer that it would just warn (in 
>> the fbdev drivers only!) that the timings are incorrect instead of 
>> aborting completely. X is right to abort, if the pixel resolution and 
>> bpp can not be set.
>> So, X's tests should be like that:
>> a) resolution and bpp different -> abort
>> b) resolution and bpp correct, but sync timings/monitor timings 
>> different -> warn but continue
>>
>> Right now X's tests are:
>> resolution, bpp or sync/monitor timings different -> abort.
>>
>> Of course it's easily possible to change stifb in that it just takes any 
>> timing values, but that is not how it is documented in skeletonfb.
> 
> My sense in looking at the PR is that the freedesktop people won't
> accept this approach.

Sadly I have the same feeling.
But just scan yourself through the kernel fb drivers and look how many 
drivers haven't implemented this workaround with check_var and set_par.
All those fb drivers are probably broken due to this X behavior.

Helge