From: Alex Buell <hidden> Date: 2011-01-03 16:38:54
Hi!
I hope the fbdev list is still in use. I have just been experimenting
with using my old S3ViRGE PCI card in my Sun Blade 2000 as its primary
display adapter has no X11 driver available for it.
I put the card into my SPARC and booted up, after compiling in the s3fb
driver into the kernel.
On boot-up, it uses the e3d framebuffer driver, and detects the s3fb
card but ignores it as seen in dmesg:
s3fb 0000:00:03.0: ignoring secondary device
I then pulled out the primary graphic card (XVR-500) and rebooted. I got
the following lines in dmesg:
vgaarb: device added: PCI:0000:00:03.0,decodes=io
+mem,owns=mem,locks=none
vgaarb: loaded
s3fb 0000:00:03.0: ignoring secondary device
It seems a bit odd that it is still ignoring the S3ViRGE card given that
it is now the only graphic adapter in the system.
I then commented out the following code in drivers/video/s3fb.c:
if (! svga_primary_device(dev)) {
dev_info(&(dev->dev), "ignoring secondary device\n");
return -ENODEV;
}
and rebooted.
It got as far as the switching to console device before it hung.
I'm aware the s3fb driver has big endian issues, I can help fix those
issues so I can get the card working. Or in other words, I'd welcome
advice on how to proceed with this.
Thanks!
--
Tactical Nuclear Kittens
From: David Miller <davem@davemloft.net> Date: 2011-01-03 18:57:57
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 16:32:16 +0000
I'm aware the s3fb driver has big endian issues, I can help fix those
issues so I can get the card working. Or in other words, I'd welcome
advice on how to proceed with this.
It's not endian issues, this driver has other problems.
It uses the VGA register accessors with a NULL regbase, which is not
going to work on sparc64.
It needs to access the VGA register space relative to the I/O space
of the PCI controller domain it is behind.
Probably if you replace the NULL values passes to vga_r*() and
vga_w*() with the I/O space resource base of the chip (should be
resource "1") it might work.
From: Alex Buell <hidden> Date: 2011-01-03 19:40:24
On Mon, 2011-01-03 at 10:58 -0800, David Miller wrote:
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 16:32:16 +0000
quoted
I'm aware the s3fb driver has big endian issues, I can help fix those
issues so I can get the card working. Or in other words, I'd welcome
advice on how to proceed with this.
It's not endian issues, this driver has other problems.
It uses the VGA register accessors with a NULL regbase, which is not
going to work on sparc64.
It needs to access the VGA register space relative to the I/O space
of the PCI controller domain it is behind.
Probably if you replace the NULL values passes to vga_r*() and
vga_w*() with the I/O space resource base of the chip (should be
resource "1") it might work.
I've had a look at linux/include/video/vga.h, and yes I see what you
mean now.
Secondly, is Linux fully capable of handling different graphic cards
simultaneously? For example, plug in a pair of monitors and have
consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
etc?
--
Tactical Nuclear Kittens
From: David Miller <davem@davemloft.net> Date: 2011-01-03 19:42:31
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 19:39:01 +0000
Secondly, is Linux fully capable of handling different graphic cards
simultaneously? For example, plug in a pair of monitors and have
consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
etc?
Technically I don't think it can do it currently. Maybe just for
kernel message logging, but not for actual login consoles.
One TTY device is marked as the "console" and that's where all
tty[0-9]+ devices get instantiated upon.
From: Alex Buell <hidden> Date: 2011-01-03 20:34:45
On Mon, 2011-01-03 at 11:43 -0800, David Miller wrote:
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 19:39:01 +0000
quoted
Secondly, is Linux fully capable of handling different graphic cards
simultaneously? For example, plug in a pair of monitors and have
consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
etc?
Technically I don't think it can do it currently. Maybe just for
kernel message logging, but not for actual login consoles.
One TTY device is marked as the "console" and that's where all
tty[0-9]+ devices get instantiated upon.
Hmm, maybe it would be nice to introduce that capability. How doable
would it be? I understand the BKL is going away, perhaps it would now be
easier to introduce such a facility?
I've just started digging into the innards of the s3fb driver, my first
attempt provoked this, simply by commenting out the check to see if it's
not the primary device and exits with -ENODEV:
Jan 3 20:16:29 sodium kernel: ERROR(1): Cheetah error trap taken
afsr[0030100000000000] afar[00000000000003d0] TL1(0)
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC[105918d8] TNPC[105918dc]
O7[10591884] TSTATE[4411001606]
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC<s3_pci_probe+0x194/0x63c
[s3fb]>
Jan 3 20:16:29 sodium kernel: ERROR(1): M_SYND(0), E_SYND(0), Multiple
Errors, Privileged
Jan 3 20:16:29 sodium kernel: ERROR(1): Highest priority error
(0000100000000000) "Unmapped error from system bus"
Jan 3 20:16:29 sodium kernel: ERROR(1): D-cache idx[0]
tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): D-cache data0[0000000000000000]
data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): I-cache idx[0]
tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
u[0000000000000000] l[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): I-cache INSN0[0000000000000000]
INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): I-cache INSN4[0000000000000000]
INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): E-cache idx[3c0]
tag[000000000b040000]
Jan 3 20:16:29 sodium kernel: ERROR(1): E-cache data0[000c5aa000000011]
data1[000f43d800000040] data2[0000000000000109] data3[0000000000000000]
Jan 3 20:16:29 sodium kernel: Kernel panic - not syncing: Irrecoverable
deferred error trap.
Heh. ;)
--
Tactical Nuclear Kittens
From: David Miller <davem@davemloft.net> Date: 2011-01-03 20:39:11
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 20:33:21 +0000
On Mon, 2011-01-03 at 11:43 -0800, David Miller wrote:
quoted
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 19:39:01 +0000
quoted
Secondly, is Linux fully capable of handling different graphic cards
simultaneously? For example, plug in a pair of monitors and have
consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
etc?
Technically I don't think it can do it currently. Maybe just for
kernel message logging, but not for actual login consoles.
One TTY device is marked as the "console" and that's where all
tty[0-9]+ devices get instantiated upon.
Hmm, maybe it would be nice to introduce that capability. How doable
would it be? I understand the BKL is going away, perhaps it would now be
easier to introduce such a facility?
It has nothing to do with the big kernel lock.
I've just started digging into the innards of the s3fb driver, my first
attempt provoked this, simply by commenting out the check to see if it's
not the primary device and exits with -ENODEV:
Jan 3 20:16:29 sodium kernel: ERROR(1): Cheetah error trap taken
afsr[0030100000000000] afar[00000000000003d0] TL1(0)
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC[105918d8] TNPC[105918dc]
O7[10591884] TSTATE[4411001606]
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC<s3_pci_probe+0x194/0x63c
[s3fb]>
Jan 3 20:16:29 sodium kernel: ERROR(1): M_SYND(0), E_SYND(0), Multiple
Errors, Privileged
I know, this is what happens if you call vga_*() with a NULL first parameter
on sparc64. It's accessing garbage addresses.
From: Alex Buell <hidden> Date: 2011-01-03 21:37:40
On Mon, 2011-01-03 at 12:39 -0800, David Miller wrote:
quoted
I've just started digging into the innards of the s3fb driver, my first
attempt provoked this, simply by commenting out the check to see if it's
not the primary device and exits with -ENODEV:
Jan 3 20:16:29 sodium kernel: ERROR(1): Cheetah error trap taken
afsr[0030100000000000] afar[00000000000003d0] TL1(0)
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC[105918d8] TNPC[105918dc]
O7[10591884] TSTATE[4411001606]
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC<s3_pci_probe+0x194/0x63c
[s3fb]>
Jan 3 20:16:29 sodium kernel: ERROR(1): M_SYND(0), E_SYND(0), Multiple
Errors, Privileged
I know, this is what happens if you call vga_*() with a NULL first parameter
on sparc64. It's accessing garbage addresses.
OK.
# lspci -vvxx -s 0:0:03
0000:00:03.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01)
(prog-if 00 [VGA controller])
Subsystem: S3 Inc. ViRGE/DX
Physical Slot: PCI 3
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 23
Region 0: Memory at 14000000 (32-bit, non-prefetchable)
[sizedM]
Region 1: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 2: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 3: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 4: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 5: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Expansion ROM at 00130000 [disabled] [sizedK]
Kernel driver in use: s3fb
Kernel modules: s3fb
00: 33 53 01 8a 02 00 00 02 01 00 00 03 00 40 00 00
10: 00 00 00 14 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 33 53 01 8a
30: 00 00 13 00 00 00 00 00 00 00 00 00 00 01 04 ff
Those are 32 bit addresses, so I suppose I should be getting the base
address for the registers accesses from region 1, right?
--
Tactical Nuclear Kittens
From: Alex Buell <hidden> Date: 2011-01-04 15:58:41
On Mon, 2011-01-03 at 14:36 -0800, David Miller wrote:
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 21:36:13 +0000
quoted
Those are 32 bit addresses, so I suppose I should be getting the base
address for the registers accesses from region 1, right?
Yes, and pre-computed addresses exist in pci_region_start(pdev, 1).
Do you have any tips for reducing the amount of reboots I have to do
whenever I try loading the s3fb module after changing code?
--
Tactical Nuclear Kittens
From: David Miller <davem@davemloft.net> Date: 2011-01-04 17:26:08
From: Alex Buell <redacted>
Date: Tue, 04 Jan 2011 15:57:07 +0000
On Mon, 2011-01-03 at 14:36 -0800, David Miller wrote:
quoted
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 21:36:13 +0000
quoted
Those are 32 bit addresses, so I suppose I should be getting the base
address for the registers accesses from region 1, right?
Yes, and pre-computed addresses exist in pci_region_start(pdev, 1).
Do you have any tips for reducing the amount of reboots I have to do
whenever I try loading the s3fb module after changing code?
You should build s3fb as a module, block it from auto-loading in
/etc/modules.conf, and then load it explicitly by hand as you
make changes and recompile.
From: Alex Buell <hidden> Date: 2011-01-04 20:12:51
On Tue, 2011-01-04 at 09:26 -0800, David Miller wrote:
From: Alex Buell <redacted>
Date: Tue, 04 Jan 2011 15:57:07 +0000
quoted
On Mon, 2011-01-03 at 14:36 -0800, David Miller wrote:
quoted
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 21:36:13 +0000
quoted
Those are 32 bit addresses, so I suppose I should be getting the base
address for the registers accesses from region 1, right?
Yes, and pre-computed addresses exist in pci_region_start(pdev, 1).
Do you have any tips for reducing the amount of reboots I have to do
whenever I try loading the s3fb module after changing code?
You should build s3fb as a module, block it from auto-loading in
/etc/modules.conf, and then load it explicitly by hand as you
make changes and recompile.
I'm already doing that. In the instances where it results in a crash and
reboots are impossible, dropping into the OpenPROM results in a total
system freeze, cannot type anything in, this means a big red switch
time. Solaris didn't have this problem. Any ideas why Linux does this to
the OpenPROM?
--
Tactical Nuclear Kittens
From: David Miller <davem@davemloft.net> Date: 2011-01-04 20:19:29
From: Alex Buell <redacted>
Date: Tue, 04 Jan 2011 20:11:17 +0000
I'm already doing that. In the instances where it results in a crash and
reboots are impossible, dropping into the OpenPROM results in a total
system freeze, cannot type anything in, this means a big red switch
time. Solaris didn't have this problem. Any ideas why Linux does this to
the OpenPROM?
First of all, the machine dies because those illegal I/O accesses
generate an unrecoverable asynchronous memory error, we cannot recover
from it so we have to panic the entire machine.
Secondly, the keyboard doesn't work because I never implemented the
monstrous amount of code necessary to allow USB keyboard to work with
OpenPROM after booting up.
You have to essentially reset the entire USB host controller, unload
all of the pending queued URBs in the host controller, put it into a
quiescent state, and then asynchronously process all USB keyboard
device events via USB host controller polling implemented via OpenPROM
backcalls into the kernel, and from there feed the characters to
OpenPROM so it can see the keypresses. Upon return from OpenPROM you
have to reload all of the unloaded URBs back onto the USB host
controller queues so the kernel can use USB again.
I never considered this enormous amount of work worth doing, the
payback is just too small.
From: Alex Buell <hidden> Date: 2011-01-04 20:39:56
On Tue, 2011-01-04 at 12:19 -0800, David Miller wrote:
First of all, the machine dies because those illegal I/O accesses
generate an unrecoverable asynchronous memory error, we cannot recover
from it so we have to panic the entire machine.
Secondly, the keyboard doesn't work because I never implemented the
monstrous amount of code necessary to allow USB keyboard to work with
OpenPROM after booting up.
You have to essentially reset the entire USB host controller, unload
all of the pending queued URBs in the host controller, put it into a
quiescent state, and then asynchronously process all USB keyboard
device events via USB host controller polling implemented via OpenPROM
backcalls into the kernel, and from there feed the characters to
OpenPROM so it can see the keypresses. Upon return from OpenPROM you
have to reload all of the unloaded URBs back onto the USB host
controller queues so the kernel can use USB again.
I never considered this enormous amount of work worth doing, the
payback is just too small.
Thank you for that explanation, it's much appreciated.
--
Tactical Nuclear Kittens
From: David Miller <davem@davemloft.net> Date: 2011-01-05 19:06:35
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 21:36:13 +0000
On Mon, 2011-01-03 at 12:39 -0800, David Miller wrote:
quoted
quoted
I've just started digging into the innards of the s3fb driver, my first
attempt provoked this, simply by commenting out the check to see if it's
not the primary device and exits with -ENODEV:
Jan 3 20:16:29 sodium kernel: ERROR(1): Cheetah error trap taken
afsr[0030100000000000] afar[00000000000003d0] TL1(0)
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC[105918d8] TNPC[105918dc]
O7[10591884] TSTATE[4411001606]
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC<s3_pci_probe+0x194/0x63c
[s3fb]>
Jan 3 20:16:29 sodium kernel: ERROR(1): M_SYND(0), E_SYND(0), Multiple
Errors, Privileged
I know, this is what happens if you call vga_*() with a NULL first parameter
on sparc64. It's accessing garbage addresses.
OK.
# lspci -vvxx -s 0:0:03
0000:00:03.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01)
(prog-if 00 [VGA controller])
Subsystem: S3 Inc. ViRGE/DX
Physical Slot: PCI 3
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 23
Region 0: Memory at 14000000 (32-bit, non-prefetchable)
[sizedM]
Region 1: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 2: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 3: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 4: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 5: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Expansion ROM at 00130000 [disabled] [sizedK]
Kernel driver in use: s3fb
Kernel modules: s3fb
00: 33 53 01 8a 02 00 00 02 01 00 00 03 00 40 00 00
10: 00 00 00 14 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 33 53 01 8a
30: 00 00 13 00 00 00 00 00 00 00 00 00 00 01 04 ff
Those are 32 bit addresses, so I suppose I should be getting the base
address for the registers accesses from region 1, right?
Actually, I take back what I said earlier. Region 1 is a Memory
region not an I/O region.
It looks like you'll have to find a way to get at the implicit
I/O space for the PCI domain this framebuffer is behind and
construct the implicit VGA addresses by hand.
There is a way to do this, via pcibios_bus_to_resource(). You could
do something like:
struct s3fb_info {
...
void __iomem *vga_iobase;
...
static int __devinit s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
struct pci_bus_region bus_reg;
struct resource vga_res;
...
bus_reg.start = 0;
bus_reg.end = 64 * 1024;
vga_res.flags = IORESOURCE_IO;
pcibios_bus_to_resource(dev, &bus_reg, &vga_res);
par->vga_iobase = (void __iomem *) vga_res.start;
Then replace all NULL vga_*() initial arguments in the driver
with par->vga_iobase.
From: Alex Buell <hidden> Date: 2011-01-05 21:15:28
On Wed, 2011-01-05 at 11:07 -0800, David Miller wrote:
quoted
Those are 32 bit addresses, so I suppose I should be getting the
base
quoted
address for the registers accesses from region 1, right?
Actually, I take back what I said earlier. Region 1 is a Memory
region not an I/O region.
It looks like you'll have to find a way to get at the implicit
I/O space for the PCI domain this framebuffer is behind and
construct the implicit VGA addresses by hand.
There is a way to do this, via pcibios_bus_to_resource(). You could
do something like:
struct s3fb_info {
...
void __iomem *vga_iobase;
...
static int __devinit s3_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
{
struct pci_bus_region bus_reg;
struct resource vga_res;
...
bus_reg.start = 0;
bus_reg.end = 64 * 1024;
vga_res.flags = IORESOURCE_IO;
pcibios_bus_to_resource(dev, &bus_reg, &vga_res);
par->vga_iobase = (void __iomem *) vga_res.start;
Then replace all NULL vga_*() initial arguments in the driver
with par->vga_iobase.
No wonder it was crashing, there was nothing to access with region 1! I
will do as you suggest, and see if it works. Thank you!
--
Tactical Nuclear Kittens
The above code seems to work, and crashes after this point:
/* Identify chip type */
par->chip = id->driver_data & CHIP_MASK;
par->rev = vga_rcrt(par->vga_iobase, 0x2f);
if (par->chip & CHIP_UNDECIDED_FLAG)
par->chip = s3_identification(par->chip);
^^^^^^^^^ ?
Sorry for the obvious but you modified s3_identification() so that it
stops emitting vga_rcrt(NULL, ...), right ?
--
Ueimor
From: Alex Buell <hidden> Date: 2011-01-06 20:52:32
On Thu, 2011-01-06 at 21:42 +0100, Francois Romieu wrote:
Alex Buell [off-list ref] :
[...]
quoted
The above code seems to work, and crashes after this point:
/* Identify chip type */
par->chip = id->driver_data & CHIP_MASK;
par->rev = vga_rcrt(par->vga_iobase, 0x2f);
if (par->chip & CHIP_UNDECIDED_FLAG)
par->chip = s3_identification(par->chip);
^^^^^^^^^ ?
Sorry for the obvious but you modified s3_identification() so that it
stops emitting vga_rcrt(NULL, ...), right ?
I must have missed that one - thank you for pointing that one out to me!
Regards
Alex
--
Tactical Nuclear Kittens
From: Alex Buell <hidden> Date: 2011-01-06 22:26:10
On Thu, 2011-01-06 at 20:50 +0000, Alex Buell wrote:
quoted
Sorry for the obvious but you modified s3_identification() so that
it
quoted
stops emitting vga_rcrt(NULL, ...), right ?
I must have missed that one - thank you for pointing that one out to
me!
Sweet smell of success:
Jan 6 22:09:20 sodium kernel: fb1: S3 Virge/GX on 0000:00:03.0, 6 MB
RAM, 14 MHz MCLK
s3fb now loads OK and correctly identifies the graphic adapter, now that
I fixed s3_identification and others.
It now crashes elsewhere when the framebuffer device is opened, the logs
shows that:
ERROR(0): Cheetah error trap taken afsr[0010100000000000] afar[00000000000003c0] TL1(0)
Jan 6 22:10:05 sodium kernel: ERROR(0): TPC[10575140] TNPC[10575144] O7[105750e8] TSTATE[4411001604]
Jan 6 22:10:05 sodium kernel: ERROR(0): TPC<save_vga+0x8c/0xf90 [vgastate]>
Jan 6 22:10:05 sodium kernel: ERROR(0): M_SYND(0), E_SYND(0), Privileged
Jan 6 22:10:05 sodium kernel: ERROR(0): Highest priority error (0000100000000000) "Unmapped error from system bus"
Jan 6 22:10:05 sodium kernel: ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): E-cache idx[3c0] tag[0000000313924924]
Jan 6 22:10:05 sodium kernel: ERROR(0): E-cache data0[6c6f6e672e682069] data1[6e636c7564652f6c] data2[696e75782f706f73] data3[69785f7479706573]
Jan 6 22:10:05 sodium kernel: Kernel panic - not syncing: Irrecoverable deferred error trap.
Looks like there's a bug in save_vga which is in
drivers/video/vgastate.c. I'll be sprinkling printk()s through
save_vga() to find the offending line of code.
Still, I'm pleased the module loads.
--
Tactical Nuclear Kittens
From: Alex Buell <hidden> Date: 2011-01-06 23:27:17
On Thu, 2011-01-06 at 14:29 -0800, David Miller wrote:
You have to initialize par->state.vgabase in the s3fb driver to the
VGA area iomem pointer you calculated at boot time.
Thanks for that, I've just got past that, now it's changing modes that
crashes the driver. I can load and unload the driver, and it
automatically selects 640x480.
How do I track down the offending line of code from the following entry
in the logs:
TPC<s3fb_set_par+0x1a0/0xf78 [s3fb]>
Also, oddly enough, before calling save_vga it clears par->state, which
was why it was crashing. Explicitly setting the par->state.vgabase to
the vga_iobase address solved the problem as below. I also noticed that
having VGA_SAVE_FONTS crashes the driver, so I left it out - a quick
look through the code in vgastate.c indicate it needs rework to make it
work but I've left that for later.
(in s3fb_open)
if (par->ref_count = 0) {
memset(&(par->state), 0, sizeof(struct vgastate));
/* save_vga/restore_vga needs this to function */
par->state.vgabase = par->vga_iobase;
/*par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS | VGA_SAVE_CMAP;*/
par->state.flags = VGA_SAVE_MODE | VGA_SAVE_CMAP;
par->state.num_crtc = 0x70;
par->state.num_seq = 0x20;
save_vga(&(par->state));
Thanks, seems it's starting to work bit by bit!
--
Tactical Nuclear Kittens
From: Alex Buell <hidden> Date: 2011-01-06 23:36:26
On Thu, 2011-01-06 at 14:29 -0800, David Miller wrote:
You have to initialize par->state.vgabase in the s3fb driver to the
VGA area iomem pointer you calculated at boot time.
I just had a look through the svgalib.c. It makes a lot of calls to
vgastate with the NULL parameter for the vga iobase, I guess that's
definitely why it's crashing the driver.
Also, svga.h has inline functions that needs modifying. Looks like a big
change to let it work with the vga iobase or NULL. Perhaps just passing
the par->state.vgabase into those functions could make it work. Usually
this gets initialised as zero at boot or driver load so the default
could be NULL anyway for those drivers that assume it is located at 0.
--
Tactical Nuclear Kittens
From: Dave Airlie <airlied@gmail.com> Date: 2011-01-03 20:37:19
On Tue, Jan 4, 2011 at 5:39 AM, Alex Buell [off-list ref] wrote:
On Mon, 2011-01-03 at 10:58 -0800, David Miller wrote:
quoted
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 16:32:16 +0000
quoted
I'm aware the s3fb driver has big endian issues, I can help fix those
issues so I can get the card working. Or in other words, I'd welcome
advice on how to proceed with this.
It's not endian issues, this driver has other problems.
It uses the VGA register accessors with a NULL regbase, which is not
going to work on sparc64.
It needs to access the VGA register space relative to the I/O space
of the PCI controller domain it is behind.
Probably if you replace the NULL values passes to vga_r*() and
vga_w*() with the I/O space resource base of the chip (should be
resource "1") it might work.
I've had a look at linux/include/video/vga.h, and yes I see what you
mean now.
Secondly, is Linux fully capable of handling different graphic cards
simultaneously? For example, plug in a pair of monitors and have
consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
etc?
Not currently, since you would also need some way to sanely route input.
You can put different VTs on different consoles but thats about it.
Dave.
On Mon, Jan 3, 2011 at 19:58, David Miller [off-list ref] wrote:
From: Alex Buell <redacted>
Date: Mon, 03 Jan 2011 16:32:16 +0000
quoted
I'm aware the s3fb driver has big endian issues, I can help fix those
issues so I can get the card working. Or in other words, I'd welcome
advice on how to proceed with this.
It's not endian issues, this driver has other problems.
It uses the VGA register accessors with a NULL regbase, which is not
going to work on sparc64.
It needs to access the VGA register space relative to the I/O space
of the PCI controller domain it is behind.
Probably if you replace the NULL values passes to vga_r*() and
vga_w*() with the I/O space resource base of the chip (should be
resource "1") it might work.
Probably s3fb also relies on a card having been initialized by the VGA BIOS.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds