Re: [Xpert] V_BIOS woes

2003-01-06 Thread Egbert Eich
Thomas Winischhofer writes:
  Adam Goode wrote:
   One last thing I noticed: 
   
   Sometimes XFree86 prints this:
   (II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x
   
   and sometimes this:
   (II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03b0, hwp-PIOOffset is 0x
   
   (For the Radeon, hwp-IOBase is sometimes 0x03d0 and sometimes 0x03b0.)
   
   The SiS is always 0x03d0. Does this mean anything? At first I thought
   the Radeon was at was 0x03b0 when it failed, but it turned out that it
   can be 0x03b0 even when it works (and 0x03d0 when it fails).
  
  0x3b0 is the IOBase for monochrome mode, 0x3d0 for color mode.
  
  The fact that the ati driver chooses the monochrome base might have 
  something to do with reading an incorrect MISC register (which is 
  responsible for choosing either color or mono).

Yes, this is quite likely when the ATi Card isn't posted correctly.
If the card is secondary and the Xserver cannot find the BIOS this
is quite likely.

  
  Perhaps I am mislead myself, but shouldn't this setup require RAC (which 
  is not being used according to the log)?

Hm, not necessarily. Depends on how the resources are registered.

The real question is why isn't the BIOS found?
I fixed a PCIROM read problem in the ATi Radeon driver
a while ago, this fix should be in CVS, though.
I don't have the log so I cannot check if this says
something about the nature of the BIOS problems.

Egbert.

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert



Re: [Xpert] V_BIOS woes

2003-01-04 Thread Thomas Winischhofer
Adam Goode wrote:

One last thing I noticed: 

Sometimes XFree86 prints this:
(II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x

and sometimes this:
(II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03b0, hwp-PIOOffset is 0x

(For the Radeon, hwp-IOBase is sometimes 0x03d0 and sometimes 0x03b0.)

The SiS is always 0x03d0. Does this mean anything? At first I thought
the Radeon was at was 0x03b0 when it failed, but it turned out that it
can be 0x03b0 even when it works (and 0x03d0 when it fails).

0x3b0 is the IOBase for monochrome mode, 0x3d0 for color mode.

The fact that the ati driver chooses the monochrome base might have 
something to do with reading an incorrect MISC register (which is 
responsible for choosing either color or mono).

Perhaps I am mislead myself, but shouldn't this setup require RAC (which 
is not being used according to the log)?

Is the amount of video RAM detected by the SiS driver (4096K) correct?

Is there any particular reason for why you're using a mixture of modules 
compiled for 4.2.1 and 4.2.99?

Thomas


--
Thomas Winischhofer
Vienna/Austria
mailto:[EMAIL PROTECTED]  *** http://www.winischhofer.net

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert


[Xpert] Re: [Xpert]V_BIOS woes

2003-01-03 Thread Adam Goode
All right, I've tried a few things. First, I set the SiS to be primary,
though I would prefer the ATI to be primary, since I've got a nicer
monitor on that one. But no problem.

Second, I tried the (HEAD/SiS) case after a fresh power-down, with the
same results. The RADEON driver can't find the V_BIOS. I'm attaching
this log (fresh power down with HEAD as of an hour or so ago).

As for the third point, yes. I meant that the system locks up hard,
but the SiS seems to work fine by itself. I was trying to get HEAD
working to see if the Xinerama lockup goes away, but it won't read the
non-primary ATI V_BIOS...


One last thing I noticed: 

Sometimes XFree86 prints this:
(II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x

and sometimes this:
(II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03b0, hwp-PIOOffset is 0x

(For the Radeon, hwp-IOBase is sometimes 0x03d0 and sometimes 0x03b0.)

The SiS is always 0x03d0. Does this mean anything? At first I thought
the Radeon was at was 0x03b0 when it failed, but it turned out that it
can be 0x03b0 even when it works (and 0x03d0 when it fails).



Thanks for any help,

Adam



On Mon, Dec 30, 2002 at 05:57:59PM -0700, Marc Aurele La France wrote:
 A few thoughts here:
 
 a) It would appear the SiS's BIOS is imbedded in the system BIOS.  Thus
the SiS should always be the primary.
 b) Did you try each of the above cases after a fresh power-down/reboot?  I
suspect that if this is done, case 1 (HEAD/SiS) would produce the same
results as case 3 (Debian/SiS).
 c) I see no evidence of crashes in these logs.  Do you instead mean
lockups?  Does the SiS work by itself?
 
 Marc.
 


This is a pre-release version of XFree86, and is not supported in any
way.  Bugs may be reported to [EMAIL PROTECTED] and patches submitted
to [EMAIL PROTECTED]  Before reporting bugs in pre-release versions,
please check the latest version in the XFree86 CVS repository
(http://www.XFree86.Org/cvs)

XFree86 Version 4.2.99.3 / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 30 December 2002
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems.  (See http://www.XFree86.Org/)
Build Operating System: Linux 2.4.21-pre2 i686 [ELF] 
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/XFree86.0.log, Time: Thu Jan  2 20:37:56 2003
(==) Using config file: /etc/X11/XF86Config-4
(==) ServerLayout Default Layout
(**) |--Screen Default Screen (0)
(**) |   |--Monitor Generic Monitor
(**) |   |--Device Generic Video Card
(**) |--Screen Screen 2 (1)
(**) |   |--Monitor Crappy Monitor
(**) |   |--Device SIS Crapola
(**) |--Input Device Generic Keyboard
(**) Option XkbRules xfree86
(**) XKB: rules: xfree86
(**) Option XkbModel pc104
(**) XKB: model: pc104
(**) Option XkbLayout us
(**) XKB: layout: us
(==) Keyboard: CustomKeycode disabled
(**) |--Input Device Configured Mouse
(WW) The directory /usr/lib/X11/fonts/cyrillic does not exist.
Entry deleted from font path.
(**) FontPath set to 
unix/:7100,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi
(==) RgbPath set to /usr/X11R6/lib/X11/rgb
(==) ModulePath set to /usr/X11R6/lib/modules
(**) Option Xinerama true
(**) Xinerama: enabled
(++) using VT number 7

(II) Open APM successful
(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.2
XFree86 Video Driver: 0.6
XFree86 XInput driver : 0.4
XFree86 Server Extension : 0.2
XFree86 Font Renderer : 0.4
(II) Loader running on linux
(II) LoadModule: bitmap
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor=The XFree86 Project
compiled for 4.2.1.1, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.3
(II) Loading font Bitmap
(II) LoadModule: pcidata
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor=The XFree86 Project
compiled for 4.2.99.3, module version = 1.0.0
ABI class: XFree86 Video Driver, version 0.6
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x8070, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1039,0650 card 1039,0650 rev 01 class 06,00,00 hdr 80
(II) PCI: 00:01:0: chip 1039,0001 card , rev 00 class 06,04,00 hdr 01
(II) PCI: 00:02:0: chip 1039,0008 card , rev 00 class 06,01,00 hdr 80
(II) PCI: 00:02:2: chip 1039,7001 card 1039,7001 rev 07 class 0c,03,10 hdr 00
(II) PCI: 

Re: [Xpert]V_BIOS woes

2002-12-30 Thread Marc Aurele La France
On Sun, 29 Dec 2002, Adam Goode wrote:

 I have an SS50 mini PC from Shuttle, and it has on board SiS 6325 AGP
 video, as well as a Radeon 7500 PCI which I added.

 There are 2 versions of XFree86 which I've tried: 4.2.1-4 from Debian,
 and CVS HEAD. The only change I have made to the Debian version is
 adding the sis driver from Thomas Winischhofer
 http://www.winischhofer.net/sis/sis_drv.o_4.2.1_261102-1.tar.gz
 to get the sis card recognized. I've tried the HEAD version as is, downloaded
 yesterday.

 I am trying to get Xinerama to work, which it almost does, but then
 crashes.

 There are 2x2 configurations I'm using. One dimension is setting in my
 BIOS setup which video card is initialized as primary: ATI or SiS.
 The other dimension is the XFree86 version: Debian or HEAD.

 The only configuration which initializes all the cards and displays
 a picture across both of them is Debian-SiSPrimary. That is, I set
 the BIOS to initalize the SiS card first, and rtun the 4.2.1-4 Debian
 version. Unfortunately, this crashes very soon after I login and
 start to move windows between the two screens.

 In the other 3 configurations, I get trouble with not finding V_BIOS
 and the non-primary card doesn't get initalized at all. A quick
 table:

 Version  PrimaryResult
 -
 HEAD SiSSiS works, ATI driver can't find V_BIOS or init the card
 HEAD ATIATI works, SiS driver can't find V_BIOS or init the card
 4.2.1-4  SiSBoth cards work, int10 finds both V_BIOSes
 4.2.1-4  ATIATI works, SiS driver can't find V_BIOS or init the card

 I'm sure something odd is happening deep with int10, and something between
 4.2.1.1 and HEAD has broken at least some previously working configurations.

 I'm attaching lspci -vvv for both configurations, with ATI as primary
 card and SiS as primary card.

 I'm also attaching all 4 XFree86 logs for the configurations in the
 table above.

 It would be nice to get int10 working to find V_BIOS in all situations.
 Any help would be appreciated, and I'll be happy to do anything necessary
 to provide information to smart int10/pci hackers.

A few thoughts here:

a) It would appear the SiS's BIOS is imbedded in the system BIOS.  Thus
   the SiS should always be the primary.
b) Did you try each of the above cases after a fresh power-down/reboot?  I
   suspect that if this is done, case 1 (HEAD/SiS) would produce the same
   results as case 3 (Debian/SiS).
c) I see no evidence of crashes in these logs.  Do you instead mean
   lockups?  Does the SiS work by itself?

Marc.

+--+---+
|  Marc Aurele La France   |  work:   1-780-492-9310   |
|  Computing and Network Services  |  fax:1-780-492-1729   |
|  352 General Services Building   |  email:  [EMAIL PROTECTED]  |
|  University of Alberta   +---+
|  Edmonton, Alberta   |   |
|  T6G 2H1 | Standard disclaimers apply|
|  CANADA  |   |
+--+---+
XFree86 Core Team member.  ATI driver and X server internals.


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert



RE: [Xpert]V_BIOS woes

2002-12-29 Thread Meesh and Kai
thanks for your response, adam

i'll try the winishhofer driver...

meesh

--
From:   Adam Goode[SMTP:[EMAIL PROTECTED]]
Sent:   Sunday, December 29, 2002 9:19 PM
To: [EMAIL PROTECTED]
Subject:[Xpert]V_BIOS woes

I have an SS50 mini PC from Shuttle, and it has on board SiS 6325 AGP
video, as well as a Radeon 7500 PCI which I added.

There are 2 versions of XFree86 which I've tried: 4.2.1-4 from Debian,
and CVS HEAD. The only change I have made to the Debian version is
adding the sis driver from Thomas Winischhofer 
http://www.winischhofer.net/sis/sis_drv.o_4.2.1_261102-1.tar.gz
to get the sis card recognized. I've tried the HEAD version as is, downloaded
yesterday.

I am trying to get Xinerama to work, which it almost does, but then
crashes.

There are 2x2 configurations I'm using. One dimension is setting in my
BIOS setup which video card is initialized as primary: ATI or SiS.
The other dimension is the XFree86 version: Debian or HEAD.

The only configuration which initializes all the cards and displays
a picture across both of them is Debian-SiSPrimary. That is, I set
the BIOS to initalize the SiS card first, and rtun the 4.2.1-4 Debian
version. Unfortunately, this crashes very soon after I login and
start to move windows between the two screens.

In the other 3 configurations, I get trouble with not finding V_BIOS
and the non-primary card doesn't get initalized at all. A quick
table:

Version  PrimaryResult
-
HEAD SiSSiS works, ATI driver can't find V_BIOS or init the card
HEAD ATIATI works, SiS driver can't find V_BIOS or init the card
4.2.1-4  SiSBoth cards work, int10 finds both V_BIOSes
4.2.1-4  ATIATI works, SiS driver can't find V_BIOS or init the card


I'm sure something odd is happening deep with int10, and something between
4.2.1.1 and HEAD has broken at least some previously working configurations.

I'm attaching lspci -vvv for both configurations, with ATI as primary
card and SiS as primary card.

I'm also attaching all 4 XFree86 logs for the configurations in the
table above.

It would be nice to get int10 working to find V_BIOS in all situations.
Any help would be appreciated, and I'll be happy to do anything necessary
to provide information to smart int10/pci hackers.


Thanks,

Adam Goode

File: ATT1.att

application/ms-tnef