* Re: Using s3virge card in Sun Blade 2000
@ 2011-01-03 21:36 ` Alex Buell
0 siblings, 0 replies; 37+ messages in thread
From: Alex Buell @ 2011-01-03 21:36 UTC (permalink / raw)
To: David Miller; +Cc: linux-fbdev, linux-kernel
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)
[size=64M]
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] [size=64K]
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Using s3virge card in Sun Blade 2000
2011-01-03 21:36 ` Alex Buell
@ 2011-01-03 22:36 ` David Miller
-1 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-03 22:36 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
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).
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
@ 2011-01-03 22:36 ` David Miller
0 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-03 22:36 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
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).
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-03 22:36 ` David Miller
(?)
@ 2011-01-04 15:57 ` Alex Buell
2011-01-04 17:26 ` David Miller
-1 siblings, 1 reply; 37+ messages in thread
From: Alex Buell @ 2011-01-04 15:57 UTC (permalink / raw)
To: David Miller; +Cc: linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-04 15:57 ` Alex Buell
@ 2011-01-04 17:26 ` David Miller
0 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-04 17:26 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
@ 2011-01-04 17:26 ` David Miller
0 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-04 17:26 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-04 17:26 ` David Miller
(?)
@ 2011-01-04 20:11 ` Alex Buell
2011-01-04 20:19 ` David Miller
-1 siblings, 1 reply; 37+ messages in thread
From: Alex Buell @ 2011-01-04 20:11 UTC (permalink / raw)
To: David Miller; +Cc: linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-04 20:11 ` Alex Buell
@ 2011-01-04 20:19 ` David Miller
0 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-04 20:19 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
@ 2011-01-04 20:19 ` David Miller
0 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-04 20:19 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-04 20:19 ` David Miller
(?)
@ 2011-01-04 20:38 ` Alex Buell
-1 siblings, 0 replies; 37+ messages in thread
From: Alex Buell @ 2011-01-04 20:38 UTC (permalink / raw)
To: David Miller; +Cc: linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-03 21:36 ` Alex Buell
@ 2011-01-05 19:07 ` David Miller
-1 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-05 19:07 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
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.
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Using s3virge card in Sun Blade 2000
@ 2011-01-05 19:07 ` David Miller
0 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-05 19:07 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
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)
> [size=64M]
> 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] [size=64K]
> 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.
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Using s3virge card in Sun Blade 2000
2011-01-05 19:07 ` David Miller
(?)
@ 2011-01-05 21:13 ` Alex Buell
2011-01-06 0:33 ` Alex Buell
-1 siblings, 1 reply; 37+ messages in thread
From: Alex Buell @ 2011-01-05 21:13 UTC (permalink / raw)
To: David Miller; +Cc: linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Using s3virge card in Sun Blade 2000
2011-01-05 21:13 ` Alex Buell
@ 2011-01-06 0:33 ` Alex Buell
2011-01-06 20:42 ` Francois Romieu
0 siblings, 1 reply; 37+ messages in thread
From: Alex Buell @ 2011-01-06 0:33 UTC (permalink / raw)
To: David Miller; +Cc: linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Using s3virge card in Sun Blade 2000
2011-01-06 0:33 ` Alex Buell
@ 2011-01-06 20:42 ` Francois Romieu
0 siblings, 0 replies; 37+ messages in thread
From: Francois Romieu @ 2011-01-06 20:42 UTC (permalink / raw)
To: Alex Buell; +Cc: David Miller, linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Using s3virge card in Sun Blade 2000
@ 2011-01-06 20:42 ` Francois Romieu
0 siblings, 0 replies; 37+ messages in thread
From: Francois Romieu @ 2011-01-06 20:42 UTC (permalink / raw)
To: Alex Buell; +Cc: David Miller, linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Using s3virge card in Sun Blade 2000
2011-01-06 20:42 ` Francois Romieu
(?)
@ 2011-01-06 20:50 ` Alex Buell
2011-01-06 22:24 ` Alex Buell
-1 siblings, 1 reply; 37+ messages in thread
From: Alex Buell @ 2011-01-06 20:50 UTC (permalink / raw)
To: Francois Romieu; +Cc: David Miller, linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-06 20:50 ` Alex Buell
@ 2011-01-06 22:24 ` Alex Buell
2011-01-06 22:29 ` David Miller
0 siblings, 1 reply; 37+ messages in thread
From: Alex Buell @ 2011-01-06 22:24 UTC (permalink / raw)
To: Francois Romieu; +Cc: David Miller, linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-06 22:24 ` Alex Buell
@ 2011-01-06 22:29 ` David Miller
0 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-06 22:29 UTC (permalink / raw)
To: alex.buell; +Cc: romieu, linux-fbdev, linux-kernel
You have to initialize par->state.vgabase in the s3fb driver to the
VGA area iomem pointer you calculated at boot time.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
@ 2011-01-06 22:29 ` David Miller
0 siblings, 0 replies; 37+ messages in thread
From: David Miller @ 2011-01-06 22:29 UTC (permalink / raw)
To: alex.buell; +Cc: romieu, linux-fbdev, linux-kernel
You have to initialize par->state.vgabase in the s3fb driver to the
VGA area iomem pointer you calculated at boot time.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-06 22:29 ` David Miller
@ 2011-01-06 23:25 ` Alex Buell
-1 siblings, 0 replies; 37+ messages in thread
From: Alex Buell @ 2011-01-06 23:25 UTC (permalink / raw)
To: David Miller; +Cc: romieu, linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Using s3virge card in Sun Blade 2000
@ 2011-01-06 23:25 ` Alex Buell
0 siblings, 0 replies; 37+ messages in thread
From: Alex Buell @ 2011-01-06 23:25 UTC (permalink / raw)
To: David Miller; +Cc: romieu, linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Using s3virge card in Sun Blade 2000
2011-01-06 22:29 ` David Miller
(?)
(?)
@ 2011-01-06 23:34 ` Alex Buell
-1 siblings, 0 replies; 37+ messages in thread
From: Alex Buell @ 2011-01-06 23:34 UTC (permalink / raw)
To: David Miller; +Cc: romieu, linux-fbdev, linux-kernel
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
^ permalink raw reply [flat|nested] 37+ messages in thread