Bug 150246

Summary: SaX2 doesn't start
Product: [openSUSE] SUSE Linux 10.1 Reporter: Vinay Khaitan <vkhaitan>
Component: SaX2Assignee: Marcus Schaefer <ms>
Status: VERIFIED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None    
Version: Beta 3   
Target Milestone: ---   
Hardware: i686   
OS: SuSE Linux 10.1   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: the output of lspci -nvv

Description Vinay Khaitan 2006-02-12 17:57:38 UTC
The Sax2 start and a possible X server begins then it close without the usual Sax gui.
After that CPU goes to 100% and memore starts leaking upto the point swap runs out.
By some investigation, I fond that the problem is in
sysp -s xstuff , which is the real program causing all the trouble.

With strace -p <PID> , I saw that after system hangs, it goes on to call brk<address> repeatedly until the memory runs out. 
Perhaps this is the call because of which memore runs out!

So finally, I dont have any good gui configurator :(
xorgconfig works but not so good, obviously.
Comment 1 Marcus Schaefer 2006-02-13 08:27:38 UTC
Hmm, sounds critical. Could you provide more information of the
system ? how many cards, what kind of cards. The information from
sax2 -p ?

Thanks
Comment 2 Vinay Khaitan 2006-02-13 08:35:50 UTC
sax2 -p
Chip: 0  is -> VESA Framebuffer Graphics       00:09:0 0x1102 0x0002 PCI fbdev
Chip: 1  is -> NVidia Vanta/Vanta LT           01:00:0 0x10de 0x002c AGP nv

That says about my card. My card is actually RivaTNT2. Only one card. 
shree:~ # sysp -s server
Card0     =>  DomainId   : 0x0
Card0     =>  BusId      : 0x0
Card0     =>  SlotId     : 0x09
Card0     =>  FuncId     : 0x0
Card0     =>  Vendor     : VESA
Card0     =>  Device     : Framebuffer Graphics
Card0     =>  VID        : 0x1102
Card0     =>  DID        : 0x0002
Card0     =>  Module     : fbdev
Card0     =>  BusType    : PCI
Card0     =>  Detected   : 2
Card0     =>  Flag       : DEFAULT
Card0     =>  SUB-VID    : 0x1102
Card0     =>  SUB-DID    : 0x8027
Card0     =>  DrvProfile : <undefined>

Card1     =>  DomainId   : 0x0
Card1     =>  BusId      : 0x1
Card1     =>  SlotId     : 0x00
Card1     =>  FuncId     : 0x0
Card1     =>  Vendor     : NVidia
Card1     =>  Device     : Vanta/Vanta LT
Card1     =>  VID        : 0x10de
Card1     =>  DID        : 0x002c
Card1     =>  Module     : nv
Card1     =>  BusType    : AGP
Card1     =>  Detected   : 2
Card1     =>  Flag       : DEFAULT
Card1     =>  SUB-VID    : 0x1043
Card1     =>  SUB-DID    : 0x0201
Card1     =>  DrvProfile : Depth24,NVidia



One more point, if that is of any use, My sound card SBLIve is recognised as VGA device(strange!). And that interferes with nvidia too. 

I dont think, that is any reason, because that is not reported in any output I have tried.

Actually My sound card is being reported in windowsxp too as vga card. I have lost hope of its solution 2 years ago already. 
If there is any way to manually provide information to linux that sound card is actually sound card, not vga, I will be extremely thankful.
Comment 3 Marcus Schaefer 2006-02-13 08:47:25 UTC
Thanks for the information; The problem is the wrong detected card
I assume the soundcard has PCI class 0x300 which is reserved
for VGA devices only. In such a case this is a hardware bug. You can
send me the information of 

  lspci -nvv

so I can have a look at the PCI specs

To fix your problem call:

  sax2 -c 1

which will only use Chip 1 (nv) for the config
Comment 4 Vinay Khaitan 2006-02-13 10:37:05 UTC
Created attachment 67923 [details]
the output of lspci -nvv
Comment 5 Vinay Khaitan 2006-02-13 10:39:59 UTC
Yes, my problem is solve and I can use now SaX2.
The output of lspci -nvv is attached .
btw, if sound card is detected wrongly, cant I manually prove that it is not vga card ?

Because of this problem I cant change to vt1-6 from Xserver when soundcard is loaded, cant even shutdown. So I remove soundcard module before I logout.
The problem is that it intereferes with framebuffer severly.
Comment 6 Vinay Khaitan 2006-02-13 10:43:27 UTC
And Important point is that, the sound card class is not 0x300 .
In fact, actually, it used to work correctly earlier (2 year ago), but suddenly started identify as vga card one day in both OS.
Comment 7 Marcus Schaefer 2006-02-13 10:48:42 UTC
Is this your sound card:

00:09.0 Class 0001: 1102:0002 (rev 08)
	Subsystem: 1102:8027
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at a400 [disabled] [size=32]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-


if yes I can fix it :-)
Comment 8 Vinay Khaitan 2006-02-13 10:50:27 UTC
Yes, that IS the sound card! TIA if you fix it :)
Comment 9 Marcus Schaefer 2006-02-13 10:53:12 UTC
It's fixed now, I will submit the package today evening so hopefully
you can test with the next beta
Comment 10 Vinay Khaitan 2006-02-13 11:16:20 UTC
Can you let me know the reason behind the problem? 

Does this fix means that in the next beta, My sound card will be detected and  it will not interfere with the vesafb or nvidia ?
Comment 11 Marcus Schaefer 2006-02-13 13:44:54 UTC
sorry of course I will explain the fix. Your sound card has PCI
class 0x0001 which was used on older graphics cards to classify
a sub device of a primary chip. Those cards doesn't exist on the
market and even the vendors doesn't exist anymore. Therefore I
decided to remove the 0x0001 class to be a valid graphics card.

According to this your sound card will no longer be used as
graphics card under linux :-) This was the good news the bad one
is I think the PCI class of your sound card is still not quite
correct so the problem on Windows may stay.  
Comment 12 Vinay Khaitan 2006-02-13 16:38:16 UTC
Thanks.
Is there any way through which I can change the class_name parameter of sound card ?
setpci doesn't work. it doesn't give any error, but still nothing happens.

What I suspect is that, when I change the class_name, the hotplug event undo the manual change. So, there should be a way to stop specific pci card to be configured via hotplug ??
Comment 13 Marcus Schaefer 2006-02-13 16:48:07 UTC
setpci writes into the PCI configuration address space, be carefull
at that point. I'm sorry but I never had the need to do that and I
think I'm not of great help here. By the way it's outside of the
meaning of this bug report. I'm pretty sure you will achieve better
results on research@suse.de

Thanks