[parisc-linux] Re: partial success with matroxfb

[parisc-linux] Re: partial success with matroxfb

[Petr Vandrovec]

On 20 Sep 02 at 2:27, Andreas Seltenreich wrote:

> Bus    HPA       Module Type      Path  Slt Md Sev  Estat Requestor  Responder
> --- ---------- ---------------- -------- -- -- ---- ----- ---------- ----------
>  0  0xfff88000 I/O Adapter      8         2  0  he   0x3d 0xf2000000 0x000a1000 
>  0  0xfff8a000 I/O Adapter      10        2  2  he   0x0d 0x00000000 0x00000000 

> anotherhpmachien:~# cat /proc/iomem 
> 00000000-0fffffff : System RAM
> f2000000-f3ffffff : GSC Bus [8/]

Hi Andreas,
  boot with 'video=matrox:novga'. It looks like that Matrox responded
to the access to legacy VGA region 0xA0000-0xBFFFF. It does not happen
when CPU accesses this memory because of Matrox does not see this access
at all in such situation, because of host bridge directs it immediately 
to the system ram, without accessing PCI. But when access originated from 
some PCI busmaster, other PCI devices sees this access, and Mystique
claims it.

  And now both host bridge (for system RAM) and Mystique (for VGA region)
accepted bus cycle, and hardware went mad...

  I have no idea what second error reports, but it may be just triggered
by previous one.
                                                            Petr Vandrovec
                                                            

Re: [parisc-linux] Re: partial success with matroxfb

[Andreas Seltenreich]

Hi Petr,
	
* Petr Vandrovec <VANDROVE@vc.cvut.cz> [2002-09-20 12:12]:
>   boot with 'video=matrox:novga'. It looks like that Matrox responded

No success with novga or no_pci_retry either. It results in the same crash. 

> Can you print DAC registers 0x4C,0x4D,0x4E,0x4F after this message?
> 0x4C..0x4E should contain 8,7E,3, and 0x4F should contain 0 when
> PLL is not locked, and 0x40 if PLL is locked.

Ok, the code around the message now looks like this:

     if (!tmout)
	printk(KERN_ERR "matroxfb: Pixel PLL not locked after 5 secs\n");	
     for (i=0x4c; i<0x50; i++)
        printk(KERN_INFO "DAC register %02x=%x\n", i, inDAC1064(i));

It looks like m1064_compute() is called twice and succeeds the second 
time:

==========
anotherhpmachien:/usr/src/linux# modprobe matroxfb_base noinit=0 no_pci_retry=1  novga=1
Warning: /lib/momatroxfb: Matrox Mystique 220 (PCI) detected
dules/2.4.19-pa1post_shift_max: 3
7/kernel/driversref_freq: 14318
/video/matrox/mafreq: 133333
troxfb_base.o syvco_freq_min: 62000
mbol for parametin_div_min: 1
er mtrr not founin_div_max: 31
d
feed_div_min: 100
feed_div_max: 127
fmax: 220000
clk: 0C 78 00 14318 133267 66666
requested 640*480/8bpp (640*6547)
matroxfb: 640x480x8bpp (virtual: 640x6547)
matroxfb: framebuffer at 0xF3000000, mapped to 0xf3000000, size
4194304
requested 640*480/8bpp (640*6547)
post_shift_max: 3
ref_freq: 14318
freq: 25175
vco_freq_min: 62000
in_div_min: 1
in_div_max: 31
feed_div_min: 100
feed_div_max: 127
fmax: 220000
clk: 08 7E 03 14318 202042 50350
matroxfb: Pixel PLL not locked after 5 secs
DAC register 4c=8
DAC register 4d=7e
DAC register 4e=1f
DAC register 4f=0
MiscOutReg: 8B
SEQ regs:   00:01:0F:00:0E:
GDC regs:   00:00:00:00:00:40:05:0F:FF:
CRTC regs:  5F:4F:4F:83:51:9D:0B:3E:00:40:00:00:00:00:00:00:E9:2B:DF:28:00:DF:0C:C3:FF:
ATTR regs:  00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:41:FF:0F:00:00:
requested 640*480/8bpp (640*6547)
post_shift_max: 3
ref_freq: 14318
freq: 25175
vco_freq_min: 62000
in_div_min: 1
in_div_max: 31
feed_div_min: 100
feed_div_max: 127
fmax: 220000
clk: 08 7E 03 14318 202042 50350
DAC register 4c=8
DAC register 4d=7e
DAC register 4e=1f
DAC register 4f=40
MiscOutReg: 8B
SEQ regs:   00:01:0F:00:0E:
GDC regs:   00:00:00:00:00:40:05:0F:FF:
CRTC regs:  5F:4F:4F:83:51:9D:0B:3E:00:40:00:00:00:00:00:00:E9:2B:DF:28:00:DF:0C:C3:FF:
ATTR regs:  00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:41:FF:0F:00:00:
Console: switching to colour frame buffer device 80x30
fb0: MATROX VGA frame buffer device
anotherhpmachien:/usr/src/linux# sync
anotherhpmachien:/usr/src/linux# ping -f athlon
PING athlon (192.168.0.11): 56 data bytes
............

kernel BUG at printk.c:489!
* box reboots
`àINIT C4CC
INIT C4CF
INIT C4CD
[...]
Main Menu: Enter command > ser pim

PROCESSOR PIM INFORMATION

-----------------  Processor 0 HPMC Information ------------------

Timestamp =   Fri Sep  20 13:55:23 GMT 2002    (20:02:09:20:13:55:23)

HPMC Chassis Codes = 0xcbf0  0x5002  0x540f  0x5508  0xcbfb  

General Registers 0 - 31
00-03   0000000000000000  0000000010368010  000000001024382c  0000000000000001
04-07   0000000000000006  000000001031e810  00000000103c0918  00000000103e2010
08-11   000000000000000f  000000000000004d  000000000004000e  000000001037c5ac
12-15   0000000000000000  0000000000000000  00000000103e3010  00000000103e3010
16-19   00000000103e2810  00000000103e2cdc  000000001031f810  00000000f3fffc0a
20-23   000000000000000e  000000000000000e  0000000000000001  0000000000919dda
24-27   0000000000000001  0000000000000001  00000000ffffff9d  0000000010304010
28-31   0000000000000010  0000000000004001  00000000103c0a40  00000000103e2010

<Press any key to continue (q to quit)> 

Control Registers 0 - 31
00-03   0000000000000000  0000000000000000  0000000000000000  0000000000000000
04-07   0000000000000000  0000000000000000  0000000000000000  0000000000000000
08-11   000000000000057a  0000000000000000  00000000000000c0  000000000000000a
12-15   0000000000000000  0000000000000000  0000000000107000  00000000f0000000
16-19   0000000712615173  0000000000000000  0000000010243858  0000000000141860
20-23   000000009207ffcf  c0000000fffffc00  000000000004010c  0000000000000000
24-27   0000000000326000  000000000f6d1000  00000000ffffffff  00000000ffffffff
28-31   00000000ffffffff  00000000ffffffff  00000000103c0000  00000000103c8000

Space Registers 0 - 7
00-03   00000000          00000000          00000000          000002bd
04-07   00000000          00000000          00000000          00000000

<Press any key to continue (q to quit)> 

IIA Space                    = 0x0000000000000000
IIA Offset                   = 0x000000001024385c
Check Type                   = 0x20000000
CPU State                    = 0x9e000004
Cache Check                  = 0x00000000
TLB Check                    = 0x00000000
Bus Check                    = 0x00305004
Assists Check                = 0x00000000
Assist State                 = 0x00000000
Path Info                    = 0x00000000
System Responder Address     = 0x000000fff3fffc0a
System Requestor Address     = 0xfffffffffffa0000
Check Summary                = 0x8000000810004000
Available Memory             = 0x0000000000000000
CPU Diagnose Register 2      = 0x0501000000000004
CPU Status Register 0        = 0x1420c20000000000
CPU Status Register 1        = 0x8000000800000000
SADD LOG                     = 0x0f0810940f481094
Read Short LOG               = 0xc14200fff3fffc0a

<Press any key to continue (q to quit)> 

Memory Error Log Information:

Timestamp =   Fri Sep  20 13:55:23 GMT 2002    (20:02:09:20:13:55:23)

   No memory errors logged


I/O Module Error Log Information:

Timestamp =   Fri Sep  20 13:55:25 GMT 2002    (20:02:09:20:13:55:25)

Bus    HPA       Module Type      Path  Slt Md Sev  Estat Requestor  Responder
--- ---------- ---------------- -------- -- -- ---- ----- ---------- ----------
 0  0xfff88000 I/O Adapter      8         2  0  he   0x3d 0xf2000000 0x000a1000 
 0  0xfff8a000 I/O Adapter      10        2  2  he   0x0d 0x00000000 0x00000000 

regards
andreas

Re: [parisc-linux] Re: partial success with matroxfb

[Petr Vandrovec]

On 20 Sep 02 at 17:50, Andreas Seltenreich wrote:
> * Petr Vandrovec <VANDROVE@vc.cvut.cz> [2002-09-20 12:12]:
> >   boot with 'video=matrox:novga'. It looks like that Matrox responded
> 
> No success with novga or no_pci_retry either. It results in the same crash. 

Can you verify (with lspci -xxx) that PCI dword register 0x40 in matroxfb
configuration space has not set bit 8 (it is lowest bit in register
0x41). 0=>disable legacy VGA, 1=>enable legacy VGA. Old Millennium I
always responded to framebuffer accesses, and it was fixed in Millennium II.
I thought that it was fixed in Mystique too. You can fix it with
setpci, if matroxfb gets it wrong.

> > Can you print DAC registers 0x4C,0x4D,0x4E,0x4F after this message?
> > 0x4C..0x4E should contain 8,7E,3, and 0x4F should contain 0 when
> > PLL is not locked, and 0x40 if PLL is locked.
> 
> Ok, the code around the message now looks like this:

> DAC register 4c=8
> DAC register 4d=7e
> DAC register 4e=1f
> DAC register 4f=0

Strange. Stalls it for 5 seconds here, or goes it through immediately?

> DAC register 4c=8
> DAC register 4d=7e
> DAC register 4e=1f
> DAC register 4f=40

                                                            Petr
                                                            

Re: [parisc-linux] Re: partial success with matroxfb

[Andreas Seltenreich]

* Petr Vandrovec <VANDROVE@vc.cvut.cz> [2002-09-20 18:12]:
> Can you verify (with lspci -xxx) that PCI dword register 0x40 in
> matroxfb
> configuration space has not set bit 8 (it is lowest bit in register
> 0x41). 0=>disable legacy VGA, 1=>enable legacy VGA. Old Millennium I
> always responded to framebuffer accesses, and it was fixed in
> Millennium II.
> I thought that it was fixed in Mystique too. You can fix it with
> setpci, if matroxfb gets it wrong.

apparently it is set:
40: 00 01 00 5f 00 00 00 00 ff ff ff ff 00 00 00 00

If I modporbe it without setting it, the bit keeps set:
40: 21 4f 09 df 00 3c 00 00 06 ff ff 06 00 00 00 00

after manually setting it to 0 and modprobing matroxfb it kept the zero:
40: 21 4e 09 df 00 3c 00 00 10 ff ff 10 00 00 00 00

but the crash still occured.

> Strange. Stalls it for 5 seconds here, or goes it through immediately?

I can't notice any delay when it passes the second time.

regards
andreas