mode setting and console locking

mode setting and console locking

[Jon Smirl]

I have two video cards installed. I run X on the primary and fbdev on the
secondary.  I'm having a problem setting the mode to the fbdev device from an
xterm window. This was working six months ago in 2.6 but it is broken currently.

If I load fbdev on my primary card, then run X on it, fbset will work on the
primary card fron the xterm window.

if I load fbdev on my secondary card (it is reset and fbdev loads without
problem) then fbset from an xterm window will lock my box. fbset from a console
window works fine. I have tried this both ways, swapping the primary and
secondary cards, so it doesn't seem to be the card drivers.

Is there some locking going on in fbdev mode setting that is interacting with X?
My X server does not have the fbdev driver loaded. The only thing I can think of
is that the console is marked at being in KD_GRAPHICs. Any ideas?

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: mode setting and console locking

[Benjamin Herrenschmidt]

On Mon, 2004-05-17 at 01:57, Jon Smirl wrote:
> I have two video cards installed. I run X on the primary and fbdev on the
> secondary.  I'm having a problem setting the mode to the fbdev device from an
> xterm window. This was working six months ago in 2.6 but it is broken currently.
> 
> If I load fbdev on my primary card, then run X on it, fbset will work on the
> primary card fron the xterm window.
> 
> if I load fbdev on my secondary card (it is reset and fbdev loads without
> problem) then fbset from an xterm window will lock my box. fbset from a console
> window works fine. I have tried this both ways, swapping the primary and
> secondary cards, so it doesn't seem to be the card drivers.
> 
> Is there some locking going on in fbdev mode setting that is interacting with X?
> My X server does not have the fbdev driver loaded. The only thing I can think of
> is that the console is marked at being in KD_GRAPHICs. Any ideas?

No, there is currently no locking. There is locking between printk (fbcon)
and mode setting but not with userland clients. 

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: mode setting and console locking

[Jon Smirl]

After about 100 reboots I have narrowed it down. The problem is coming from the
VT switch to get to XFree, not Xfree. I have a bare fbdev loaded on a secondary
device without a console attached to it. It should not be processing VT switches
but it is.

The bogus VT switch is causing it to restore garbage into the registers. When I
then set the mode from the xtern radeonfb gets hung in a loop in the write_pll
routine. The PLL write isn't completing because the chip state has been messed
up from the garbage restore.

I need to do more debugging to figure out why it is getting VT switch events.
How does a fbdev get notified of a VT switch?

The fbdev design is still broken. fbdev should not be touching the console
semaphore. The console semaphore should be handled in vga/fbconsole. If an fbdev
wants to protect against reentrancy each fbdev should have it's own semaphore
but printk is a console function and should be controlled from the console
driver, not the fbdev. An fbdev should function standalone and have no ties into
the VT system or console semaphore.

Think about the case of two or three video cards each with an fbdev loaded. It's
obvious then that an fbdev should have no ties to VT and console. 

What about this case?
x86 running vga console
then load fbdev

I think the fbdev should be inactive at this point. The only way to activate it
is to disable the vgacon. You can deactivate vgacon by loading fbcon or doing
something to move the console to a different device.

--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Mon, 2004-05-17 at 01:25, Jon Smirl wrote:
> > I checked fbset from xterm on primary aty128fb, that works.
> > Then I checked fbset from xterm on radeon as my primary monitor, that
> worlks.
> > 
> > So it seems to be an interaction when the fbdev is a secondary device. The
> lock
> > up happens 100% of the time. Any ideas on what could be causing it?
> > 
> > Mode setting to CRT connected panel is broken every case I try.
> 
> I supose XFree and fbdev fighting each other, no ?
> 
> Ben.
> 
> 


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking

[Benjamin Herrenschmidt]

> 
> The only difference I can see is that the X term is in KD_GRAPHICS. When the VT
> is swapped from a console in KD_TEXT to one in KD_GRAPHICS a signal must be sent
> to radeonfb. This signal is being handled wrong and the wrong data is loaded
> into the registers. But what is really wrong is that this signal shouldn't be
> sent to radeonfb at all since my radeonfb is not the primary console device and
> it shouldn't be touched on a VT swap.
> 
> I haven't figured out what happens in an fbdev driver on a KD_TEXT/KD_GRAPHICS
> transition yet.

The kernel VT subsystem issue a special blank call to the console driver
(I recently fixed issues there to catch those properly). fbcon will for
a set mode when getting one of those going from gfx->text

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking

[Jon Smirl]

My current conclusion is that a VT switch to/from X is destroying the radeon's
registers.  But I don't think X is doing the destroying. My X app does not have
the radeon driver loaded and I checked /proc/maps and the radeon hardware is not
mapped to the X process. 

Some test cases....
radeonfb is always being run on the secondary device
console and X are always on the primary device

modprobe radeonfb from console
VT swap to X
fbset from xterm - fails

modprobe radeonfb from xterm
VT swap to console and back to X
fbset from xterm - works

modprobe radeonfb from console
VT swap to X and back to console
fbset from console - works

modprobe radeonfb from console
VT swap to another console
fbset from console - works

The only difference I can see is that the X term is in KD_GRAPHICS. When the VT
is swapped from a console in KD_TEXT to one in KD_GRAPHICS a signal must be sent
to radeonfb. This signal is being handled wrong and the wrong data is loaded
into the registers. But what is really wrong is that this signal shouldn't be
sent to radeonfb at all since my radeonfb is not the primary console device and
it shouldn't be touched on a VT swap.

I haven't figured out what happens in an fbdev driver on a KD_TEXT/KD_GRAPHICS
transition yet.



--- Jon Smirl <jonsmirl@yahoo.com> wrote:
> After about 100 reboots I have narrowed it down. The problem is coming from
> the
> VT switch to get to XFree, not Xfree. I have a bare fbdev loaded on a
> secondary
> device without a console attached to it. It should not be processing VT
> switches
> but it is.


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking

[Jon Smirl]

--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> The kernel VT subsystem issue a special blank call to the console driver
> (I recently fixed issues there to catch those properly). fbcon will for
> a set mode when getting one of those going from gfx->text

I don't have fbcon loaded, I'm using vgacon. 

I'll try adding a printk on the radeonfb blank call and see if I am getting one
on VT swap.

The special blank call is probably what is failing. It's the primary card that
is transitioning from gfx->text, not the secondary radeonfb card. Telling the
secondary card it is transitioning when it really isn't will probably mess it up.

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking

[Benjamin Herrenschmidt]

On Mon, 2004-05-17 at 14:12, Jon Smirl wrote:
> --- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > The kernel VT subsystem issue a special blank call to the console driver
> > (I recently fixed issues there to catch those properly). fbcon will for
> > a set mode when getting one of those going from gfx->text
> 
> I don't have fbcon loaded, I'm using vgacon. 
> 
> I'll try adding a printk on the radeonfb blank call and see if I am getting one
> on VT swap.

There is no possible connection between the fbdev and the VT subsystem
if you don't have fbcon. It's the only link between those.

> The special blank call is probably what is failing. It's the primary card that
> is transitioning from gfx->text, not the secondary radeonfb card. Telling the
> secondary card it is transitioning when it really isn't will probably mess it up.
> 
> =====
> Jon Smirl
> jonsmirl@yahoo.com
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! - Internet access at a great low price.
> http://promo.yahoo.com/sbc/
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking, nvidia failure

[Jon Smirl]

I'll debug this more in the morning. I tried swapping a Geforce2 for my Radeon
just to see if I got the same failure. I can't tell since every mode I tried
setting on the Geforce2 faults the drivers.

rivafb: nVidia device/chipset 10DE0150
rivafb: RIVA MTRR set to ON
rivafb: PCI nVidia NV10 framebuffer ver 0.9.5b (nVidiaGeForce2-G, 32MB @ 0xF0000
000)
divide error: 0000 [#1]
SMP
Modules linked in: snd_mixer_oss rivafb vgastate cfbimgblt snd_intel8x0 snd_ac97
_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_devi
ce snd soundcore lm85 i2c_i801 eeprom i2c_sensor ipv6 parport_pc lp parport auto
fs4 sunrpc e1000 ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables ide_
cd cdrom floppy sg ohci1394 ieee1394 8250 serial_core nls_iso8859_1 nls_cp437 vf
at fat joydev evdev usbhid ehci_hcd uhci_hcd usbcore thermal processor fan butto
n raid1 md ata_piix libata sd_mod scsi_mod
CPU:    0
EIP:    0060:[<f8ae3d10>]    Not tainted
EFLAGS: 00010202   (2.6.6)
EIP is at nv10CalcArbitration+0xf6/0x352 [rivafb]
eax: 03a2c940   ebx: 00000000   ecx: 00000000   edx: 00000000
esi: 01036640   edi: 0fffffff   ebp: ed195c14   esp: ed195bb4
ds: 007b   es: 007b   ss: 0068
Process fbset (pid: 4381, threadinfo=ed194000 task=f70ae640)
Stack: c16ebae0 01036640 0000003d 01e84800 00030f00 c16ebae0 00000001 00000001
       00000011 ed195c14 00000000 00000000 000061e0 00000000 00000200 00000001
       00000013 00000008 00000000 00000002 00000010 0fffff0f 00000000 0fffffff
Call Trace:
 [<c0106b4b>] show_stack+0x80/0x96
 [<c0106ce2>] show_registers+0x15f/0x1ae
 [<c0106e57>] die+0x8d/0xfb
 [<c0106f83>] do_divide_error+0xbe/0xdd
 [<c01067f1>] error_code+0x2d/0x38
 [<f8ae404e>] nv10UpdateArbitrationSettings+0xe2/0x11d [rivafb]
 [<f8ae44d1>] CalcStateExt+0x1d6/0x2b5 [rivafb]
 [<f8ae07f2>] riva_load_video_mode+0x473/0x625 [rivafb]
 [<f8ae1000>] rivafb_set_par+0x1d/0x54 [rivafb]
 [<c02315f2>] fb_set_var+0xe8/0xea
 [<c02317fc>] fb_ioctl+0x10f/0x28c
 [<c0161781>] sys_ioctl+0xfe/0x258
 [<c0105d35>] sysenter_past_esp+0x52/0x71
 
Code: f7 7d d4 8b 55 e0 69 d2 40 42 0f 00 89 45 bc 89 d0 99 f7 7d
  


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking, nvidia failure

[Jon Smirl]

There is nothing wrong with fbset on rivafb. It's the same problem I'm having
with radeonfb. Swaping between text->gfx on the primary monitor mess up the chip
registers of the secondary card. In this case the PLL reads zero after the VT
swap and that causes the divide by zero.

This has got to be some problem in fb since I am sure my X does not have an
Nvidia driver loaded.

Now I'm really going to bed.

--- Jon Smirl <jonsmirl@yahoo.com> wrote:
> I'll debug this more in the morning. I tried swapping a Geforce2 for my Radeon
> just to see if I got the same failure. I can't tell since every mode I tried
> setting on the Geforce2 faults the drivers.


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking, nvidia failure

[James Simmons]

> There is nothing wrong with fbset on rivafb. It's the same problem I'm having
> with radeonfb. Swaping between text->gfx on the primary monitor mess up the chip
> registers of the secondary card. In this case the PLL reads zero after the VT
> swap and that causes the divide by zero.
> 
> This has got to be some problem in fb since I am sure my X does not have an
> Nvidia driver loaded.

Jon are you using a vanilla 2.6.6 kernel. If you are could you try this 
patch.

http://phoenix.infradead.org/~jsimmons/mode.diff

It might solve your problem. It might be a cons2fb mapping issue.





-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking, nvidia failure

[Jon Smirl]

I'll on vanilla 2.6 bk so I'll get the patch a try.

This is another theory I had but it doesn't seem to be true....

My new theory is that when I reset the secondary card it left two active VGA
devices. Then when I VT swap vgacon writes to the primary one but it is really
setting the registers to both cards. 

But I have some data against this theory.
1) I compiled vgacon out, compiled fbcon in. problem still happens
2) If it both VGAs were active, why can I switch from X to console and back to X
and still have fbset from xterm work?  The two VT switches would have caused the
primary card's VGA setting to get written into the secondary card.

After I reset the secondary card I can look at VGA bus routing using lspci and
see that VGA is still routed to my primary card and only a single VGA routing is
enabled.


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking, nvidia failure

[Jon Smirl]

This patch didn't fix it. How does VGA routing work on the PCI bus, what gets
routed? Memory at A000 plus IO ports, just mem???

My top choice is still two enabled VGA devices. I suspect that X libvgahw is
writing to the registers and both cards are seeing the writes.

The bug has a very specific profile - a VT switch from X to console or vice
versa triggers it. But it also has the unique characteristic that if you switch
X to console to X things work ok. Same for console to X to console.

It is easy to recreate you need one PCI and one AGP card. Run without
framebuffer on the primary card. Reset the secondary card with a reset program
(you can use X to reset it). Load fbdev on secondary. Start X. fbset from an
xterm. System dies. This works for every combo of cards I own so it does not
seem to be driver specific.

--- James Simmons <jsimmons@infradead.org> wrote:
> Jon are you using a vanilla 2.6.6 kernel. If you are could you try this 
> patch.
> 
> http://phoenix.infradead.org/~jsimmons/mode.diff
> 
> It might solve your problem. It might be a cons2fb mapping issue.

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking, nvidia failure

[Benjamin Herrenschmidt]

> One part of this has got to be a problem with the console semaphore.  That
> semaphore should not be accessed from an fbdev driver. If you need to access if
> from an fbdev driver then the fbdev design is broken. Think about the case with
> multiple fbdev's loaded. Since we only have one console all of the fbdev can't
> play with the semaphore. That semaphore needs to be controlled from fb/vgacon
> and lock only the fbdev that is displaying the console, not the others.
> 
> Next experiment is to remove all reference to the console semaphore from my
> fbdev driver.

You should try to understand things rather...

You should _not_ touch the console semaphore from your driver except in
special known circumstances like the PM code path. It will make sure you
don't get called by fbcon, but it's perfectly safe to take it even when
you aren't beeing called by fbcon. However, you should not take it on
normal fbdev operations since you will be called with it already held by
the common fbmem code. The only case where you may want to bother is the
PM callback.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking, nvidia failure

[Jon Smirl]

I have a new clue.

From console:
modprobe radeonfb
rmmod radeonfb
works, there is a one line printk on rmmod displayed on console

From X:
modprobe radeonfb
rmmod radeonfb
works, there is a one line printk on rmmod logged

From X:
modprobe radeonfb
VT switch to console
rmmod radeonfb
system hangs, but is a little active Ctrl-Alt-Del prints a line.

Now remove the code that does the printk on exit
From X:
modprobe radeonfb
VT switch to console
rmmod radeonfb
works, line from printk is displayed.

One part of this has got to be a problem with the console semaphore.  That
semaphore should not be accessed from an fbdev driver. If you need to access if
from an fbdev driver then the fbdev design is broken. Think about the case with
multiple fbdev's loaded. Since we only have one console all of the fbdev can't
play with the semaphore. That semaphore needs to be controlled from fb/vgacon
and lock only the fbdev that is displaying the console, not the others.

Next experiment is to remove all reference to the console semaphore from my
fbdev driver.

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: mode setting and console locking, nvidia failure

[Jon Smirl]

It's your fbdev driver but taking out all console semaphore references didn't
make a difference. It was the ones in fbmem.c I though were the problem, not the
ones in the pm code.

I have this case, rmmod with printk in module remove routine causes hang. Get
rid of the printk and rmmod will succeed. 

How do you debug this?

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click