From: Jon Smirl <hidden> Date: 2004-05-16 15:57:57
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-16 22:08:35
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
From: Jon Smirl <hidden> Date: 2004-05-17 02:29:38
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:
quoted
I checked fbset from xterm on primary aty128fb, that works.
Then I checked fbset from xterm on radeon as my primary monitor, that
worlks.
quoted
So it seems to be an interaction when the fbdev is a secondary device. The
lock
quoted
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
From: Jon Smirl <hidden> Date: 2004-05-17 03:51:29
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-17 03:56:17
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
From: Jon Smirl <hidden> Date: 2004-05-17 04:12:58
--- 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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-17 04:20:56
On Mon, 2004-05-17 at 14:12, Jon Smirl wrote:
quoted hunk
--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
quoted
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 [off-list ref]
-------------------------------------------------------
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
From: Jon Smirl <hidden> Date: 2004-05-17 05:03:15
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
From: James Simmons <hidden> Date: 2004-05-17 22:56:19
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
From: Jon Smirl <hidden> Date: 2004-05-17 23:26:39
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
From: Jon Smirl <hidden> Date: 2004-05-18 03:00:08
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
From: Jon Smirl <hidden> Date: 2004-05-18 03:38:12
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-18 03:43:04
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
From: Jon Smirl <hidden> Date: 2004-05-18 03:53:57
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