Using s3virge card in Sun Blade 2000

Using s3virge card in Sun Blade 2000

[Alex Buell]

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

Re: Using s3virge card in Sun Blade 2000

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
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.

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

On Mon, 2011-01-03 at 10:58 -0800, David Miller wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> 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.

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

Re: Using s3virge card in Sun Blade 2000

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
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.

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

On Mon, 2011-01-03 at 11:43 -0800, David Miller wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> 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.

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

Re: Using s3virge card in Sun Blade 2000

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
Date: Mon, 03 Jan 2011 20:33:21 +0000

> On Mon, 2011-01-03 at 11:43 -0800, David Miller wrote:
>> From: Alex Buell <alex.buell@munted.org.uk>
>> 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.
> 
> 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.

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

On Mon, 2011-01-03 at 12:39 -0800, David Miller wrote:

> > 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

Re: Using s3virge card in Sun Blade 2000

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
Date: Mon, 03 Jan 2011 21:36:13 +0000

> 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).

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

On Mon, 2011-01-03 at 14:36 -0800, David Miller wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> Date: Mon, 03 Jan 2011 21:36:13 +0000
> 
> > 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

Re: Using s3virge card in Sun Blade 2000

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
Date: Tue, 04 Jan 2011 15:57:07 +0000

> On Mon, 2011-01-03 at 14:36 -0800, David Miller wrote:
>> From: Alex Buell <alex.buell@munted.org.uk>
>> Date: Mon, 03 Jan 2011 21:36:13 +0000
>> 
>> > 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.

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

On Tue, 2011-01-04 at 09:26 -0800, David Miller wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> Date: Tue, 04 Jan 2011 15:57:07 +0000
> 
> > On Mon, 2011-01-03 at 14:36 -0800, David Miller wrote:
> >> From: Alex Buell <alex.buell@munted.org.uk>
> >> Date: Mon, 03 Jan 2011 21:36:13 +0000
> >> 
> >> > 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

Re: Using s3virge card in Sun Blade 2000

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
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.

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

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

Re: Using s3virge card in Sun Blade 2000

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
Date: Mon, 03 Jan 2011 21:36:13 +0000

> On Mon, 2011-01-03 at 12:39 -0800, David Miller wrote:
> 
>> > 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.

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

On Wed, 2011-01-05 at 11:07 -0800, David Miller wrote:
> > 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. 

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

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

On Wed, 2011-01-05 at 21:13 +0000, Alex Buell wrote:

> > 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!

After doing as you suggested:

	printk(KERN_INFO "s3fb: vga io base = 0x%p\n", par->vga_iobase);

        /* Unlock regs */
        cr38 = vga_rcrt(par->vga_iobase, 0x38);
        cr39 = vga_rcrt(par->vga_iobase, 0x39);
        vga_wseq(par->vga_iobase, 0x08, 0x06);
        vga_wcrt(par->vga_iobase, 0x38, 0x48);
        vga_wcrt(par->vga_iobase, 0x39, 0xA5);

        printk(KERN_INFO "s3fb ok...\n");

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);

The logs shows:

Jan  5 23:16:29 sodium kernel: s3fb: vga io base = 0x000007ffef000000
Jan  5 23:16:29 sodium kernel: s3fb ok...
Jan  5 23:16:29 sodium kernel: ERROR(0): Cheetah error trap taken
afsr[0030100000000000] afar[00000000000003d0] TL1(0)
Jan  5 23:16:29 sodium kernel: ERROR(0): TPC[10583b54] TNPC[10583b58]
O7[10583a3c] TSTATE[9911001606]
Jan  5 23:16:29 sodium kernel: ERROR(0): TPC<s3_pci_probe+0x410/0x93c
[s3fb]>
Jan  5 23:16:29 sodium kernel: ERROR(0): M_SYND(0),  E_SYND(0), Multiple
Errors, Privileged
Jan  5 23:16:29 sodium kernel: ERROR(0): Highest priority error
(0000100000000000) "Unmapped error from system bus"
Jan  5 23:16:29 sodium kernel: ERROR(0): D-cache idx[0]
tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
Jan  5 23:16:29 sodium kernel: ERROR(0): D-cache data0[0000000000000000]
data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
Jan  5 23:16:29 sodium kernel: ERROR(0): I-cache idx[0]
tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
u[0000000000000000] l[0000000000000000]
Jan  5 23:16:29 sodium kernel: ERROR(0): I-cache INSN0[0000000000000000]
INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
Jan  5 23:16:29 sodium kernel: ERROR(0): I-cache INSN4[0000000000000000]
INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
Jan  5 23:16:29 sodium kernel: ERROR(0): E-cache idx[3c0]
tag[0000000002249249]
Jan  5 23:16:29 sodium kernel: ERROR(0): E-cache data0[787072745f756e72]
data1[656769737465725f] data2[7472616e73706f72] data3[7400787072745f72]
Jan  5 23:16:29 sodium kernel: Kernel panic - not syncing: Irrecoverable
deferred error trap.

I'm still thinking that it probably isn't the right io_base if it's
crashing trying to identify the s3 chipset. 
-- 
Tactical Nuclear Kittens

Re: Using s3virge card in Sun Blade 2000

[Francois Romieu]

Hi Alex,

Alex Buell <alex.buell@munted.org.uk> :
[...]
> 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

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

On Thu, 2011-01-06 at 21:42 +0100, Francois Romieu wrote:
> Alex Buell <alex.buell@munted.org.uk> :
> [...]
> > 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

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

On Thu, 2011-01-06 at 20:50 +0000, Alex Buell wrote:
> > 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! 

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

Re: Using s3virge card in Sun Blade 2000

[David Miller]

You have to initialize par->state.vgabase in the s3fb driver to the
VGA area iomem pointer you calculated at boot time.

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

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

Re: Using s3virge card in Sun Blade 2000

[Alex Buell]

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

Re: Using s3virge card in Sun Blade 2000

[Dave Airlie]

On Tue, Jan 4, 2011 at 5:39 AM, Alex Buell <alex.buell@munted.org.uk> wrote:
> On Mon, 2011-01-03 at 10:58 -0800, David Miller wrote:
>> From: Alex Buell <alex.buell@munted.org.uk>
>> 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.
>
> 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.

Re: Using s3virge card in Sun Blade 2000

[Geert Uytterhoeven]

On Mon, Jan 3, 2011 at 19:58, David Miller <davem@davemloft.net> wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> 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.

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