[parisc-linux] Re: HP C180 video card

[parisc-linux] Re: HP C180 video card

[Grant Grundler]

On Sun, Jun 15, 2003 at 04:11:46PM +0000, Joel Soete wrote:
> I tried to use a "PGX64 alias Rage xl " pluged in the first slot of my 
> b180L. It seems to be well supported by kernel 2.4.21 (modeprobe 
> ati128fb; # modules were well loaded).

cool - that's a good first step. I don't know where to go from there.

> But no success to make XFree86 
> works (fbset /dev/fb0 not found)

Maybe it's as simple as "mknod /dev/fb0 ..." ?
if the driver loads without complaining, I'd expect fbset command
to work too.

> and even when I change console path to 
> graphics(1[a]) I never reach to obtain boot prompt on the screen (which 
> never seems to recieve init signal?).

PDC/IODC/STI won't know anything about the Rage XL card.
There's no way you can use that as a console.

> I do not understand, it seems to be a common pci gfx card? any idea?

I don't either really. Just guessing.

grant

RE: [parisc-linux] Re: HP C180 video card

[Joel Soete]

>>
>>On Sun, Jun 15, 2003 at 04:11:46PM +0000, Joel Soete wrote:
>> I tried to use a "PGX64 alias Rage xl " pluged in the first slot of my

>> b180L. It seems to be well supported by kernel 2.4.21 (modeprobe 
>> ati128fb; # modules were well loaded).

# lsmod
Module                  Size  Used by    Not tainted
aty128fb               20244   0  (unused)
fbcon-cfb32             5956   0  [aty128fb]
fbcon-cfb8              5244   0  [aty128fb]
fbcon-cfb24             5876   0  [aty128fb]
fbcon-cfb16             5828   0  [aty128fb]

>cool - that's a good first step. I don't know where to go from there.
>
>> But no success to make XFree86 
>> works (fbset /dev/fb0 not found)

>Maybe it's as simple as "mknod /dev/fb0 ..." ?

I do it (rm /dev/fb*; cd /dev ; MAKEDEV fb; fb* were well rebuild) but no
more success?

>> if the driver loads without complaining, I'd expect fbset command
>> to work too.

Hope so too.

Even "cat /proc/fb" don't show me anything?

>> and even when I change console path to 
>> graphics(1[a]) I never reach to obtain boot prompt on the screen (which

>> never seems to recieve init signal?).
>
>PDC/IODC/STI won't know anything about the Rage XL card.
>There's no way you can use that as a console.

Ok so I swicth to "path con serial_1"

>> I do not understand, it seems to be a common pci gfx card? any idea?

>I don't either really. Just guessing.

Just in case some more X(pert) read this mail, here is some more info:

root@fw02:/CVS/SRC.TMP# lspci
00:01.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
00:02.0 Serial controller: Equinox Systems, Inc.: Unknown device 90f0 (rev
04)
...

/var/log/XFree86.0.log:
[...]
(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:01:0: chip 1002,4752 card 0000,0000 rev 27 class 03,00,00 hdr
00
(II) PCI: 00:02:0: chip 113f,90f0 card 0000,0000 rev 04 class 07,00,80 hdr
00
(II) PCI: 00:13:0: chip 1000,000f card 0000,0000 rev 04 class 01,00,00 hdr
00
(II) PCI: 00:14:0: chip 1011,0019 card 103c,104f rev 41 class 02,00,00 hdr
00
(II) PCI: End of PCI scan
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x00 (VGA_EN is cleared)
(II) Bus 0 I/O range:
        [0] -1 0        0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 0 non-prefetchable memory range:
        [0] -1 0        0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
        [0] -1 0        0x00000000 - 0xffffffff (0x0) MX[B]
(--) PCI:*(0:1:0) ATI Mach64 GR rev 39, Mem @ 0xf1000000/24, 0xf0fec000/12,
I/O @ 0xfd00/8, BIOS @ 0xf0f80000/17
(II) Addressable bus resource ranges are
        [0] -1 0        0x00000000 - 0xffffffff (0x0) MX[B]
        [1] -1 0        0x00000000 - 0x0000ffff (0x10000) IX[B]
[...]
(II) FBDEV: driver for framebuffer: fbdev
(II) VGA: Generic VGA driver (version 4.0) for chipsets: generic
(II) v4l driver for Video4Linux
(II) Primary Device is: PCI 00:01:0
(EE) open /dev/fb0: No such device
(EE) No devices detected.

Fatal server error:
no screens found


Thanks for your attention,
    Joel


---------------------------------
Découvrez les 6 clés et gagnez le Club Med à Vie avec Tiscali
http://www.tiscali.be/nl/subs/tiscali4life/default.asp?lang=fr

[parisc-linux] ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Joel Soete]

Hi Grant,

Grant Grundler wrote:

>On Sun, Jun 15, 2003 at 04:11:46PM +0000, Joel Soete wrote:
>  
>
>>I tried to use a "PGX64 alias Rage xl " pluged in the first slot of my 
>>b180L. It seems to be well supported by kernel 2.4.21 (modeprobe 
>>ati128fb; # modules were well loaded).
>>    
>>
>
>cool - that's a good first step. I don't know where to go from there.
>  
>
Hmm in fact I obtain better results with atyfb + "Mach64 CT/VT/GT/LT 
(incl. 3D RAGE) support (NEW)";
this time I obtain such message for kernel advising me that 'atyfb' 
modules is loaded and some other info collected from the device itself.

>>But no success to make XFree86 
>>works (fbset /dev/fb0 not found)
>>    
>>
I also reach to get (not yet changing) default setup with "fbset -fb 
/dev/fb1" :-)
But not yet find the way to setup X using /dev/fb1 in place of fb0 ;-( ?

Let see later because my very problem is there:
a) if I rmmod atyfb the system crashes
b) if I do not include "Generic sti fb" in the config of my kernel, when 
I insmod atyfb the system crashes also
c) if I try to use Equinox serial mux (8P) (an oem HP product) module 
(with our without your patch Grant) the system crashes also?

The system is a B180 model using Dino GSCPCI bridge and in the two cases 
(even if messages are a bit different) the TOC shows always a pb on this 
bus (the analyse of toc after the crash of insmod eqnx point out a pb in 
timer_? routine). And in fact I figure out that I never have to use this 
bridge for another card?
Is somebody else used it successfuly or could it be broken?

Thanks again for any help,
    Joel

[parisc-linux] ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Joel Soete]

Hi Grant,

Grant Grundler wrote:

>On Sun, Jun 15, 2003 at 04:11:46PM +0000, Joel Soete wrote:
>  
>
>>I tried to use a "PGX64 alias Rage xl " pluged in the first slot of my 
>>b180L. It seems to be well supported by kernel 2.4.21 (modeprobe 
>>ati128fb; # modules were well loaded).
>>    
>>
>
>cool - that's a good first step. I don't know where to go from there.
>  
>
Hmm in fact I obtain better results with atyfb + "Mach64 CT/VT/GT/LT 
(incl. 3D RAGE) support (NEW)";
this time I obtain such message for kernel advising me that 'atyfb' 
modules is loaded and some other info collected from the device itself.

>>But no success to make XFree86 
>>works (fbset /dev/fb0 not found)
>>    
>>
I also reach to get (not yet changing) default setup with "fbset -fb 
/dev/fb1" :-)
But not yet find the way to setup X using /dev/fb1 in place of fb0 ;-( ?

Let see later because my very problem is there:
a) if I rmmod atyfb the system crashes
b) if I do not include "Generic sti fb" in the config of my kernel, when 
I insmod atyfb the system crashes also
c) if I try to use Equinox serial mux (8P) (an oem HP product) module 
(with our without your patch Grant) the system crashes also?

The system is a B180 model using Dino GSCPCI bridge and in the two cases 
(even if messages are a bit different) the TOC shows always a pb on this 
bus (the analyse of toc after the crash of insmod eqnx point out a pb in 
timer_? routine). And in fact I figure out that I never have to use this 
bridge for another card?
Is somebody else used it successfuly or could it be broken?

Thanks again for any help,
    Joel

[parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Grant Grundler]

On Sat, Jun 21, 2003 at 02:24:41PM +0000, Joel Soete wrote:
...
> c) if I try to use Equinox serial mux (8P) (an oem HP product) module 
> (with our without your patch Grant) the system crashes also?

I haven't tested the Serial 8p PCI card under parisc yet.
To date, that card has always lived in a x86 host. I just
haven't had time to play with it under parisc - I've needed it
working to get other things done.


> The system is a B180 model using Dino GSCPCI bridge and in the two cases 
> (even if messages are a bit different) the TOC shows always a pb on this 
> bus (the analyse of toc after the crash of insmod eqnx point out a pb in 
> timer_? routine).

The symptom is very likely only similar and not identical.
I'd find it very odd if both cards crashed for the same reason.

AFAICT, eqnx driver doesn't call pci_enable_device().  The bug I'd be
looking for is a PCI "resource" (BAR) to be accessed before it was enabled.
Try adding a pci_enable_device() to eqnx_init() or eqx_pci_buspresent().
[ *gag* I'm surprised this code even works on x86. ]

PARISC "hard fails" when reading from disabled or non-existant PCI
address space while x86 "soft fails".  ie x86 gets garbage back on
a "bad" read while PARISC will crash.

The crash in the timer routine is interesting and would make it
interesting for me to move the equinox card to an a500.
Randolph, Paul (Bame), and I occcasionally try to track down the
timer problems that plague SMP under 64-bit parisc kernels.


> And in fact I figure out that I never have to use this 
> bridge for another card?

GSCtoPCI connects the PCI slot to the rest of the system.
Try "lspci" and see what you have connected.

> Is somebody else used it successfuly or could it be broken?

Dino worked fine before.
I ran B180 as my desktop for over a year (my desktop is now a C3000).

grant

Re: [parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Matthew Wilcox]

On Sun, Jun 22, 2003 at 11:04:50PM -0600, Grant Grundler wrote:
> AFAICT, eqnx driver doesn't call pci_enable_device().  The bug I'd be
> looking for is a PCI "resource" (BAR) to be accessed before it was enabled.
> Try adding a pci_enable_device() to eqnx_init() or eqx_pci_buspresent().
> [ *gag* I'm surprised this code even works on x86. ]

x86 typically doesn't need to call pci_enable_device, so people who've
never tried their driver on any other box may have missed it.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Joel Soete]

Matthew Wilcox wrote:

>On Sun, Jun 22, 2003 at 11:04:50PM -0600, Grant Grundler wrote:
>  
>
>>AFAICT, eqnx driver doesn't call pci_enable_device().  The bug I'd be
>>looking for is a PCI "resource" (BAR) to be accessed before it was enabled.
>>Try adding a pci_enable_device() to eqnx_init() or eqx_pci_buspresent().
>>[ *gag* I'm surprised this code even works on x86. ]
>>    
>>
>
>x86 typically doesn't need to call pci_enable_device, so people who've
>never tried their driver on any other box may have missed it.
>
>  
>
 From the very last relase 4.05 (dated April 7 iirc) it support also 
"Intel IA-64 platforms".
But I will have a look in more details and also post the toc analyse.

Thanks for help and attention,
    Joel

Re: [parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Grant Grundler]

On Mon, Jun 23, 2003 at 12:18:36PM +0100, Matthew Wilcox wrote:
> x86 typically doesn't need to call pci_enable_device, so people who've
> never tried their driver on any other box may have missed it.

Happen to know if that is true for hotplug support?
ie does x86 requires something like pci_enable_device() for hotplug to work?

BTW, my comment was actually intended for other parts of the code I
was digging though, not the just lack of pci_enable_device().

grant

Re: [parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Grant Grundler]

On Mon, Jun 23, 2003 at 04:00:08PM +0000, Joel Soete wrote:
> From the very last relase 4.05 (dated April 7 iirc) it support also 
> "Intel IA-64 platforms".

Those behave the same way as ia32 boxes.
Wonder if I can get a "sample card" to test an HP IA64 platform
(ZX1).... :^)


> But I will have a look in more details and also post the toc analyse.

yes, please do.

thanks,
grant

Re: [parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Grant Grundler]

On Mon, Jun 23, 2003 at 04:00:08PM +0000, Joel Soete wrote:
> From the very last relase 4.05 (dated April 7 iirc) it support also 
> "Intel IA-64 platforms".


Joel,
Could you post a URL or make the eqnx-4.05 linux driver available?
I didn't see it here:
ftp://guest:guest@www.equinox.com/library/legacy%20drivers/sst/

Last one I found was the 4.01 from last year...

thanks,
grant

Re: [parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Joel Soete]

Hi Grant,

> Joel,
> Could you post a URL or make the eqnx-4.05 linux driver available?
> didn't see it here:
> ftp://guest:guest@www.equinox.com/library/legacy%20drivers/sst/
>
> Last one I found was the 4.01 from last year...
>
Yes I now, they change the way to proceed the download and I also spend a
certain time to find it:
- on the main page (http://www.equinox.com/) you have a "Download Drivers"
pointing to <http://www.equinox.com/Download_Drivers129.html>
- ont he middle of this page "Enter Downloadable Files Database" <http://www.equinox.com/Driver_Search152.cfm>
- at the bottom of this one "SST driver for Linux" driving you to <http://www.equinox.com/Driver_Search_Results153.cfm?uid=309>
- here you are at the top: 
<http://www.equinox.com/DownloadFile.cfm?File=eqnx-4.05.tar.Z>

[Just show you the way because I am not sure that they are fixed references
:)]

btw, I also have a look into aty module and if I well fond pci_enable_device()
in module aty128fb (which load and unload well but useless for my card),
otc I do not find it into atifb. So I will also look this way for this driver.

Finaly here is the toc, dump and corresponding 'analyses'

===== ATYFB ====
===  Dump  ===

Stack Dump:
 1631ca80:  0004ff0e 1
327120 00000001 16a37840
 1631ca70:  163e1ac0 10125d70 1631c7e8 17c73280
 1631ca60:  17cc08e0 16a37840 17c732ec 00000001
 1631ca50:  1631c8d8 16500900 0000001b 00000000
 1631ca40:  ffffffff 103a6b00 00000000 103a6810
 1631ca30:  103a6810 103a6810 
000000f 4017e33c

Kernel addresses on the stack:
 [<10125d70>]  [<10122458>]  [<10122308>]  [<10122050>]
 [<10174650>]  [<10109078>]  [<102b6aa0>]  [<1016d268>]
 [<101684f4>]  [<10132cf0>]  [<1013f7b4>]  [<1013e2e4>]
 [<1014e9c0>]  [<101364c4>]  [<101684f4>]  [<101364c4>]
 [<10133004>]  [<1012006c>]  [<101684f4>]  [<1013ed34>]
 [<10147e2c>]  [<10109f90>]  [<10109084>]  [<10109d4c>]
 [<1013f7b4>]  [<1013e2e4>]  [<1014e9c0>]  [<10121318>]


Kernel Fault: Code=26 regs=1631ca80 (Addr=00000010


     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001110 Not tainted
r00-03  00000000 103a7810 10125d70 103a8010
r04-07  103a8010 103a6810 1631ca08 103a6810
r08-11  103a7810 4017e33c bff016e0 00043230
r12-15  0002d000 103a78
0 103a7010 000e0d08
r16-19  1631c6c0 00000000 00028d90 00000010
r20-23  105b6de0 16a37840 16a37850 00000000
r24-27  00000000 103a7010 00000000 102f2010
r28-31  00001000 00000000 1631ca80 10122458
sr0-3   00000000 000002a4 00000000 000002a4
sr4-7 
 00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10125ee0 10125ee4
 IIR: 0e741280    ISR: 00000000  IOR: 00000010
 CPU:        0   CR30: 1631c000 CR31: 10390000
 ORIG_R28: 102bb0a0
.

===  Analyse  ===
IAOQ = 10125ee0
Func:
timer_bh, Off: 1cc, Addr: 0x10125ee0
10125ee0:	0e 74 12 80 	stw r20,0(sr0,r19)
10125ee4:	0e 93 12 88 	stw r19,4(sr0,r20)
10125ee8:	0e a0 12 80 	stw r0,0(sr0,r21)
10125eec:	0e a0 12 88 	stw r0,4(sr0,r21)

GR0 = 00000000

GR1 = 103a7810
Func: tv
, Off: 1a8, Addr: 0x103a7810

GR2 = 10125d70
Func: timer_bh, Off: 5c, Addr: 0x10125d70
10125d70:	00 01 0d 60 	ssm 1,r0
10125d74:	2b 68 30 00 	addil 11800,dp,%r1
10125d78:	48 33 03 88 	ldw 1c4(r1),r19
10125d7c:	08 73 04 13 	sub r19,r3,r19

GR3 
 103a8010
Func: tv1, Off: 7a4, Addr: 0x103a8010

GR4 = 103a8010
Func: tv1, Off: 7a4, Addr: 0x103a8010

GR5 = 103a6810
Func: log_buf, Off: 3e68, Addr: 0x103a6810

GR6 = 1631ca08

GR7 = 103a6810
Func: log_buf, Off: 3e68, Addr: 0x103a6810

G
8 = 103a7810
Func: tv2, Off: 1a8, Addr: 0x103a7810

GR9 = 4017e33c

GR10 = bff016e0

GR11 = 00043230

GR12 = 0002d000

GR13 = 103a7870
Func: tv1, Off: 4, Addr: 0x103a7870

GR14 = 103a7010
Func: event, Off: 0, Addr: 0x103a7010

GR15 = 0
0e0d08

GR16 = 1631c6c0

GR17 = 00000000

GR18 = 00028d90

GR19 = 00000010

GR20 = 105b6de0

GR21 = 16a37840

GR22 = 16a37850

GR23 = 00000000

GR24 = 00000000

GR25 = 103a7010
Func: event, Off: 0, Addr: 0x103a7010

GR26 = 000000
0

GR27 = 102f2010
Func: $global$, Off: 0, Addr: 0x102f2010

GR28 = 00001000

GR29 = 00000000

GR30 = 1631ca80

GR31 = 10122458
Func: bh_action, Off: 40, Addr: 0x10122458
1012243c:	8e 60 20 18 	cmpib,<> 0,r19,10122450 <bh_action+0x38>
101
2450:	e6 c0 20 00 	be,l 0(sr4,r22),%sr0,%r31
10122454:	08 1f 02 42 	copy r31,rp
10122458:	e8 1f 1f d5 	b,l 10122448 <bh_action+0x30>,r0
1012245c:	4b c2 3f 59 	ldw -54(sp),rp

Kernel symbols on the stack:
[<10125d70>]: Func: timer_bh, Off: 5c, Add
: 0x10125d70
[<10122458>]: Func: bh_action, Off: 40, Addr: 0x10122458
[<10122308>]: Func: tasklet_hi_action, Off: 7c, Addr: 0x10122308
[<10122050>]: Func: do_softirq, Off: ec, Addr: 0x10122050
[<10174650>]: Func: journal_dirty_metadata, Off: 12c, A
dr: 0x10174650
[<10109078>]: Func: intr_check_resched, Off: 0, Addr: 0x10109078
[<102b6aa0>]: Func: number, Off: 3c0, Addr: 0x102b6aa0
[<1016d268>]: Func: ext3_do_update_inode, Off: 238, Addr: 0x1016d268
[<101684f4>]: Func: ext3_file_write, Off: 20
 Addr: 0x101684f4
[<10132cf0>]: Func: generic_file_write, Off: 1cc, Addr: 0x10132cf0
[<1013f7b4>]: Func: chrdev_open, Off: 64, Addr: 0x1013f7b4
[<1013e2e4>]: Func: dentry_open, Off: f4, Addr: 0x1013e2e4
[<1014e9c0>]: Func: locate_fd, Off: 120, Addr
 0x1014e9c0
[<101364c4>]: Func: kfree, Off: 48, Addr: 0x101364c4
[<101684f4>]: Func: ext3_file_write, Off: 20, Addr: 0x101684f4
[<101364c4>]: Func: kfree, Off: 48, Addr: 0x101364c4
[<10133004>]: Func: generic_file_write, Off: 4e0, Addr: 0x10133004

[<1012006c>]: Func: s_show, Off: 60, Addr: 0x1012006c
[<101684f4>]: Func: ext3_file_write, Off: 20, Addr: 0x101684f4
[<1013ed34>]: Func: sys_write, Off: a4, Addr: 0x1013ed34
[<10147e2c>]: Func: sys_fstat64, Off: 5c, Addr: 0x10147e2c
[<10109f90>]: F
nc: syscall_exit, Off: 0, Addr: 0x10109f90
[<10109084>]: Func: intr_check_sig, Off: 0, Addr: 0x10109084
[<10109d4c>]: Func: child_return, Off: 0, Addr: 0x10109d4c
[<1013f7b4>]: Func: chrdev_open, Off: 64, Addr: 0x1013f7b4
[<1013e2e4>]: Func: dentry
open, Off: f4, Addr: 0x1013e2e4
[<1014e9c0>]: Func: locate_fd, Off: 120, Addr: 0x1014e9c0
[<10121318>]: Func: it_real_fn, Off: 0, Addr: 0x10121318

Done.

============ another info about aty test ==================
Here is also the end of a toc 
 got before adding stifb console support
and wich made so simply crash the kernel as soon as insmod atifb:
Timestamp =   Fri Jun  20 09:17:56 GMT 2003    (20:03:06:20:09:17:56)

   No memory errors logged


I/O Module Error Log Information:

T
mestamp =   Fri Jun  20 09:17:57 GMT 2003    (20:03:06:20:09:17:57)

Bus    HPA       Module Type      Path  Slt Md Sev  Estat Requestor  Responder
--- ---------- ---------------- -------- -- -- ---- ----- ---------- ----------
 1  0xfff80000 Bus Bridge (PCI)                      0x09 0xfffbe000 0x00000000



PCI Error Summary

An error related to the GSC bus occurred. The
processor was the requestor. It could have been
a data parity error, an address parity error or a
GSC timeout. On PA
300 systems, check the MIOC
DIOERR register listed above.

I couldn't get more because addresses didn't matches any System nor vmlinux
addresses

===== Eqnx =====
===  TOC  ===

PROCESSOR PIM INFORMATION

-----------------  Processor 0 HPMC 
nformation ------------------

Timestamp =   Fri Jun  20 10:25:53 GMT 2003    (20:03:06:20:10:25:53)

HPMC Chassis Codes = 0xcbf0  0x505f  0xcbfb

General Registers 0 - 31
 0 -  3  0x00000000  0x1039f010  0x1011093c  0x0000ffff
 4 -  7  0x00000
01  0x00000000  0x0086d000  0x00000004
 8 - 11  0x00000000  0x00842010  0x00000000  0x00000000
12 - 15  0x00000000  0x0000001f  0x0000113f  0x00842010
16 - 19  0x000000ff  0x00842810  0x0004e158  0xfff8006c
20 - 23  0x0000000e  0x0000000f  0x1024fe
8  0x00000001
24 - 27  0x00000cfc  0x00000000  0x10079160  0x102f2010
28 - 31  0x0000fff8  0x00000940  0x15b807c0  0x1011093c

Control Registers 0 - 31
 0 -  3  0x00000000  0x00000000  0x00000000  0x00000000
 4 -  7  0x00000000  0x00000000  0x000
0000  0x00000000
 8 - 11  0x0000000c  0x00000000  0x000000c0  0x0000001f
12 - 15  0x00000000  0x00000000  0x00108800  0xe0000000
16 - 19  0x144d0fac  0x00000000  0x1024ff28  0x00141860
20 - 23  0x00000000  0xfff8006c  0x0006000e  0x80000000
24 - 2
  0x0030a000  0x05d2c000  0xffffffff  0xffffffff
28 - 31  0xaaaaaaaa  0x11111111  0x15b80000  0x10390000

Space Registers 0 - 7
 0 -  3  0x00000000  0x00000000  0x00000000  0x00000006
 4 -  7  0x00000000  0x00000000  0x00000000  0x00000000

IIA 
pace                    = 0x00000000
IIA Offset                   = 0x1024ff2c
Check Type                   = 0x20000000
CPU State                    = 0x9e000004
Cache Check                  = 0x00000000
TLB Check                    = 0x00000000

Bus Check                    = 0x00310000
Assists Check                = 0x00000000
Assist State                 = 0x00000000
System Responder Address     = 0xfff8006c
System Requestor Address     = 0xfffbe000
Path Info                    = 0x0000
000
Physical Memory              = 0x08000000
Available Memory             = 0x08000000

CPU Diagnose Register 0      = 0x600048fc
MIOC Status Register         = 0x00001802
MIOC Control Register        = 0xb8050000
MIOC MDERRADD Error Address  =
0x00000008
MIOC DMAERR DMA Error Reg    = 0xfffffeff
MIOC DIOERR IO Error Reg     = 0xfff8006c

Memory Error Log Information:

Timestamp =   Fri Jun  20 10:25:53 GMT 2003    (20:03:06:20:10:25:53)

   No memory errors logged


I/O Module Err
r Log Information:

Timestamp =   Fri Jun  20 10:25:53 GMT 2003    (20:03:06:20:10:25:53)

Bus    HPA       Module Type      Path  Slt Md Sev  Estat Requestor  Responder
--- ---------- ---------------- -------- -- -- ---- ----- ---------- --------
-
 1  0xfff80000 Bus Bridge (PCI)                      0x0a 0x00000000 0x00000000



PCI Error Summary

The PCI bridge is in fatal mode.
This may be due to an error in a different component.

===  Analyse  ===
IAOQ = 0x1024ff2c
Func: analyz
_sbs, Off: 4cc, Addr: 0x1024ff2c
1024ff20:	0e a8 10 93 	ldw 4(sr0,r21),r19
1024ff24:	82 79 20 4a 	cmpb,=,n r25,r19,1024ff50 <analyze_sbs+0x4f0>
1024ff28:	08 16 02 57 	copy r22,r23
1024ff2c:	08 0a 02 56 	copy r10,r22

GR0 = 0x00000000

GR1 = 0x1
39f010
Func: hp_hardware_list, Off: 17500, Addr: 0x1039f010

GR2 = 0x1011093c
Func: inb, Off: 0, Addr: 0x1011093c
101108d4:	86 60 20 b0 	cmpib,= 0,r19,10110934 <pcxl_proc_info+0x1a4>
10110930:	4f c8 3f 01 	ldw,mb -80(sp),r8
10110934:	e8 57 0d dd
	b,l 10100028 <_text+0x28>,rp
10110938:	34 42 3f 41 	ldo -60(rp),rp
1011093c <inb>:
1011093c:	6b c2 3f d9 	stw rp,-14(sp)

GR3 = 0x0000ffff

GR4 = 0x00000001

GR5 = 0x00000000

GR6 = 0x0086d000

GR7 = 0x00000004

GR8 = 0x00000000

GR9 
 0x00842010

GR10 = 0x00000000

GR11 = 0x00000000

GR12 = 0x00000000

GR13 = 0x0000001f

GR14 = 0x0000113f

GR15 = 0x00842010

GR16 = 0x000000ff

GR17 = 0x00842810

GR18 = 0x0004e158

GR19 = 0xfff8006c

GR20 = 0x0000000e

GR21 =
0x0000000f

GR22 = 0x1024fef8
Func: analyze_sbs, Off: 498, Addr: 0x1024fef8
1024fef0:	49 88 00 28 	ldw 14(r12),r8
1024fef4:	08 08 02 58 	copy r8,r24
1024fef8:	08 08 02 43 	copy r8,r3
1024fefc:	0d 00 10 88 	ldw 0(sr0,r8),r8

GR23 = 0x00000001


GR24 = 0x00000cfc

GR25 = 0x00000000

GR26 = 0x10079160

GR27 = 0x102f2010
Func: __kstrtab_in_group_p, Off: 8, Addr: 0x102f2010

GR28 = 0x0000fff8

GR29 = 0x00000940

GR30 = 0x15b807c0

GR31 = 0x1011093c
Func: inb, Off: 0, Addr: 0x1011
93c
101108d4:	86 60 20 b0 	cmpib,= 0,r19,10110934 <pcxl_proc_info+0x1a4>
10110930:	4f c8 3f 01 	ldw,mb -80(sp),r8
10110934:	e8 57 0d dd 	b,l 10100028 <_text+0x28>,rp
10110938:	34 42 3f 41 	ldo -60(rp),rp
1011093c <inb>:
1011093c:	6b c2 3f d9 	stw
rp,-14(sp)


Done.
=================================================================================

But elsewhere you said other important thing to do, so do not spend to much
time (I just learn it for my own education :) )

Thanks again for
all,
    Joel


PS: I hope that what you will recieve will be still readable (this new webmail
interface has a strange behaviour, sorry)



---------------------------------
Tiscali ADSL: 19,50 euros/mois...abonnez-vous sur www.tiscali.be

Re: [parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Alan Cox]

On Maw, 2003-06-24 at 04:44, Grant Grundler wrote:
> On Mon, Jun 23, 2003 at 12:18:36PM +0100, Matthew Wilcox wrote:
> > x86 typically doesn't need to call pci_enable_device, so people who've
> > never tried their driver on any other box may have missed it.
> 
> Happen to know if that is true for hotplug support?
> ie does x86 requires something like pci_enable_device() for hotplug to work?

Yes

Re: [parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Joel Soete]

Hi Grant,

> BTW, my comment was actually intended for other parts of the code I
> was digging though, not the just lack of pci_enable_device().

Do you know where can I get more info on what have todo (naturaly only pci_enable_device()
doesn't help)?

Thanks,
    Joel



---------------------------------
Tiscali ADSL: 19,50 euros/mois...abonnez-vous sur www.tiscali.be

Re: [parisc-linux] Re: ATY RAGE XL progress or Dino gscpci bridge pb?[was: Re: HP C180 video card]

[Grant Grundler]

On Wed, Jun 25, 2003 at 11:43:51AM +0200, Joel Soete wrote:
> Do you know where can I get more info on what have todo
> (naturaly only pci_enable_device() doesn't help)?

Track down where in the code the MMIO read fails.
If it's crashing *after* pci_enable_device() is called,
then need to make sure the driver isn't directly reading
PCI BARs and is using struct resources in the pci_dev.

grant