Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Diamond Stealth 2500 working but locks up



Hi,

Sorry for this very long email, but I am getting desperate with my new
PC.

A few weeks ago I bought a new PC to replace my older 486-33 machine.
It has been working okay most of the time (the increase in speed is
great), but I am having a problem with (I think) the video card.  The
symptom is that in X-Windows, every now and then the machine locks up.
I've tried a couple of things to figure out what going on.

The machine in questions is a Pentium 166 MHz, with 32MB of RAM, and a
Diamond Stealth 2500 video card (which seems to be a relatively new
card from Diamond).  I am running Kernel 2.0.30 with the PCI options
enabled, etc. (I first used 2.0.29, then 2.0.30 to see if the trouble
would go away; it didn't.)

The video card was not recognized at start up.  Here is the "dmesg"
listing: 

> Console: 16 point font, 400 scans
> Console: colour VGA+ 80x25, 1 virtual console (max 63)
> pcibios_init : BIOS32 Service Directory structure at 0x000fad20
> pcibios_init : BIOS32 Service Directory entry at 0xfb1a0
> pcibios_init : PCI BIOS revision 2.10 entry at 0xfb1d0
> Probing PCI hardware.
> Warning : Unknown PCI device (1142:6424).  Please read include/linux/pci.h 
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Calibrating delay loop.. ok - 66.76 BogoMIPS
> Memory: 31124k/32768k available (572k kernel code, 384k reserved, 688k data)
> Swansea University Computer Society NET3.035 for Linux 2.0
> NET3: Unix domain sockets 0.13 for Linux NET3.035.
> Swansea University Computer Society TCP/IP for NET3.034
> IP Protocols: ICMP, UDP, TCP
> Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.
> Checking 'hlt' instruction... Ok.
> Linux version 2.0.30 (root at fortepiano) (gcc version 2.7.2.1) #9 Wed Apr 23 01:28:30 EDT 1997
> Serial driver version 4.13 with no serial options enabled
> tty00 at 0x03f8 (irq = 4) is a 16550A
> tty01 at 0x02f8 (irq = 3) is a 16550A
> ide: i82371 PIIX (Triton) on PCI bus 0 function 57
>     ide0: BM-DMA at 0xf000-0xf007
>     ide1: BM-DMA at 0xf008-0xf00f
> hda: FUJITSU M1638TAU, 2452MB w/128kB Cache, LBA, CHS=622/128/63, DMA
> hdc: TOSHIBA CD-ROM XM-5702B, ATAPI CDROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> Floppy drive(s): fd0 is 1.44M
> Started kswapd v 1.4.2.2 
> FDC 0 is an 8272A
> Partition check:
>  hda: hda1 hda2 hda3 hda4
> VFS: Mounted root (ext2 filesystem) readonly.
> Adding Swap: 32252k swap-space (priority -1)

The "unknown PCI device" in question is the video card, where 1142 is
the Vender ID, and 6424 is the Device ID.  I haven't tried the latest
beta kernels yet, but looking at the pci.h file in 2.1.35, it shows
that 1142 refers to Alliance, and 6422 (not 6424) refers to the
Alliance Provideo chip:

> #define PCI_VENDOR_ID_ALLIANCE 0x1142
> #define PCI_DEVICE_ID_ALLIANCE_PROMOTIO 0x3210
> #define PCI_DEVICE_ID_ALLIANCE_PROVIDEO 0x6422

I am using XFree 3.2A (beta version of X11R6.3).  (I started with
XFree 3.2, and then 3.2A to try fix the problem.)  The new 3.2A
detects the chipset as an Alliance ProMotion chip.  Here is an excerpt
from the listing at startup of X:

> XFree86 Version 3.2A / X Window System
> (protocol Version 11, revision 0, vendor release 6300)
> Release Date: Jan 28 1997
> 	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/FAQ)
> Operating System: Linux 2.0.28 i586 [ELF] 
                          ^^^^^^ (and not 2.0.30?)
> Configured drivers:
>   SVGA: server for SVGA graphics adaptors (Patchlevel 0):
 ....
>       ark2000pv, ark2000mt, mx, realtek, AP6422, AT24, generic
                                           ^^^^^^  ^^^^
 .....
> (--) SVGA: PCI: Alliance Semiconductor ProMotion AT24 rev 0, Memory @ 0xe0000000, I/O @ 0x6100
> (--) SVGA: CHIPS: wrong chipID: 6424
> (--) SVGA: chipset:  AT24
> (**) SVGA: videoram: 2048k
 .....
> (--) SVGA: Virtual resolution set to 1280x1024
> (--) SVGA: SpeedUp code selection modified because virtualX != 1024
> (--) SVGA: AT24: Using linear framebuffer at 0xE0000000 (PCI bus)
> (--) SVGA: AT24: 786432 bytes off-screen video memory available
> (--) SVGA: Using XAA (XFree86 Acceleration Architecture)
> (--) SVGA: XAA: No acceleration primitives defined.
> PEX extension module not loaded
> XIE extension module not loaded

>From reading the README files in XFree 3.2A, the chipset is detected,
but treated the same way as the AP6422 chip (whatever that may be).

As mentioned before, the lock-up only occurs every now and then.  When
it happens, the screen freezes, with no response at all from the
keyboard (not even from caps-lock or num-lock).  So far, the only sure
way of reprodudcing the lock-up is by running the xlockmore (3.11)
screen saver.  This will always lock up the machine after a while (not
always the same).  I wrote a script that would sync the disk every 15
seconds, and output "date" to a file.  When lock-up occurs, the disk
syncing would stop.  The second time, I ran "top" and saved the output
to a file.  After the machine locked-up and I rebooted the machine (by
pressing the reset button; I had no way of unmounting the disks!) I
went through the "top" listing.  As far as I could tell, nothing
unusual happened.  The first listing showed:

> 12:11am  up 42 min,  5 users,  load average: 0.04, 0.08, 0.02
> 33 processes: 32 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states:  1.9% user,  1.9% system,  0.0% nice, 96.2% idle
> Mem:  31124K av, 26824K used,  4300K free, 16240K shrd,  4260K buff
> Swap: 32252K av,    28K used, 32224K free               13128K cached

and the last entry (presumably before the machine locked up) was 

> 2:25am  up  2:56,  3 users,  load average: 0.04, 0.08, 0.12
> 35 processes: 32 sleeping, 1 running, 2 zombie, 0 stopped
> CPU states:  0.2% user,  0.1% system,  0.0% nice, 99.9% idle
> Mem:  31124K av, 29500K used,  1624K free, 16040K shrd,  5220K buff
> Swap: 32252K av,    28K used, 32224K free               13604K cached

In the middle, there were several occurrences where the load went up
to 99+ percent:

> 12:42am  up  1:13,  5 users,  load average: 0.53, 0.23, 0.12
> 33 processes: 31 sleeping, 2 running, 0 zombie, 0 stopped
> CPU states: 99.2% user,  0.7% system,  0.0% nice,  0.2% idle
> Mem:  31124K av, 27232K used,  3892K free, 16392K shrd,  4452K buff
> Swap: 32252K av,    28K used, 32224K free               13268K cached
> 
>   PID USER     PRI  NI SIZE  RES SHRD STAT %CPU %MEM  TIME COMMAND
>   109 root      14   0 6912 3032 1632 R    98.4  9.7  3:20 X :0
>   364 sid        0   0 3280 2376  868 S     1.3  7.6  0:26 xlock -mode random -

I don't know if this is normal or not, but this was not the case just
before the machine died (as far as I can tell).

			      **********

A few extra notes: the machine has never died out on me under Windows
95, or outside of X.  I tried running a small program under Linux all
night without X, and the next morning, it was still alive.  Of course,
it was just a simple program, ... 

So, any suggestions as to what I should do?  Should I try the new beta
kernels?  Or get a new video card?  Is the video card to blame?  Any
other tests that anybody can suggest?

Thanks.

Sidney Li
lih at polaroid.com




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org