I have a very similar machine... quad P6/200, 256mb ram, buslogic
SCSI, S3 Virge/VX video... it all works flawlessly. My first suspect
would be your video card. Some are distinctly flakey as 4 cpus can
get the machine busy enough to perhaps throw off bus timing just a tad
and getting the card in a snit...
I'd try another video card first, as the machine and 2.2.x seems to work
find here...
Bob
Robert Hyatt Computer and Information Sciences
[EMAIL PROTECTED] University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
On 7 Sep 1999 [EMAIL PROTECTED] wrote:
>
> i am having significant trouble getting X to run on my machine.
> (i posted this to various newsgroups with no useful response.)
>
> specs are as follows
>
> ALR revolution quad6 w/ 4 ppro-200s
> 256MB RAM
> diamond stealth 3d 2000 (s3 virge 325)
> dec tulip ethernet (21140)
> adaptec 2940uw (aic7881rev1) scsi adapter
> fujitsu hard disk model: M2949E-512
>
> mostly stock redhat 6.0 system
>
> i have been using this machine since 2.1.124 and have had great
> success using it as a server. however, i have recently wanted to
> retire my old UP box and get X running on this one.
>
> i can get X running fine with a uniprocessor kernel. this is with
> 2.2.5 and 2.2.11. i haven't tried the other kernel versions, but i
> assume they work too.
>
> when i use SMP, i have a severe problem. X comes up. the window
> manager (fvwm1) works. i can move the mouse; i can bring down menus
> from the root. however, when i go to move a window (opaque move if
> that makes any difference), the screen *immediately* locks (every time
> 100% repeatable). occasionally, the window will have moved to some
> random place on the screen. most (nearly all) of the time, the
> keyboard is hosed. i think it must be some kind of mouse/X/fvwm SMP
> race condition. but how to debug?
>
> i can log in remotely and kill the window manager which takes down X.
> the keyboard remains hosed. is there some way i can restore/reset the
> keyboard?
>
> if i kill xinit, nothing happens. if i kill Xwrapper (as root), the
> machine freezes hard (no logs alas).
>
> is there some kind hardware conflict or strange interaction between X
> and SMP?
>
> here are my interrupts
>
> # cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 0: 87911 77862 127247 87661 IO-APIC-edge timer
> 1: 56 60 39 56 IO-APIC-edge keyboard
> 2: 0 0 0 0 XT-PIC cascade
> 8: 0 1 0 1 IO-APIC-edge rtc
> 10: 7531 7537 7583 7575 IO-APIC-level aic7xxx
> 11: 3445 3527 3604 3576 IO-APIC-level eth0
> 12: 24 23 25 24 IO-APIC-level PS/2 Mouse
> 13: 1 0 0 0 XT-PIC fpu
> NMI: 0
> ERR: 0
>
> i can produce dmesg dumps &c if anyone is interested.
>
>
> --------
>
>
> also another oddity is with redhat 6.0. i have managed to fix it but
> i am damned if i know why it happens in the first place.
>
> redhat 5.2 with glibc-2.0 and glibc-2.1 worked fine with all kernels
> from 2.1.124 through 2.2.9.
>
> at that point i installed redhat 6.0. the stock redhat kernel works
> fine. i also wanted to compile my own kernel (like always...). i
> compile 2.2.5 with aic7xxxx built into the monolith. i have only one
> module tulip.o (and dummy.o but that isn't loaded as far as i can
> tell). since i put the scsi driver in the kernel, i am not using
> initrd. my own compiled 2.2.5 kernel works fine.
>
> i upgrade to 2.2.6 and things are still good.
>
> i go to 2.2.7 and my disk access gets *very slow*. running bonnie
> shows that char-wise read/write is about 40K/sec (down from 3000K/sec
> for working kernel). interestingly, block read/write is nearly the
> same as a good kernel. there isn't any disk data corruption, just
> slow access. disk access is similarly slow for all of 2.2.8, 2.2.9
> and 2.2.10.
>
> i note that the aic7xxx driver is *identitical* in both 2.2.6 and
> 2.2.7. very little changes wrt smp and disk or file system occur
> between these versions.
>
> dmesg looks the same for all the kernels. while some version number
> change, there are no errors or warnings printed.
>
> i tried out 2.2.10 in uniprocessor and get rotten disk performance
> too. although now, it's not nearly as bad as under SMP. i have about
> 300KB/sec transfer rates. about an order of magnitude better than SMP
> new kernel with built-in scsi but an order of magnitude worse than
> redhat's kernel.
>
> i am suspicious of an irq conflict (this can cause slow modems) since
> each scsi adapter and disk access is being punished by a fixed
> amount (independent on the size of the data block being moved).
>
> remember, kernel 2.2.7 and 2.2.9 worked fine before (with redhat 5.2
> using both glibc-2.0 and glibc-2.1). i suspect something wacky is
> happening during the boot sequence (since i can't figure out anything
> else to blame).
>
> watching the boot, i notice a slow down right after it talks about
> entering run-level 3 and the init script starts its `daemon loading
> ok' spew.
>
> i managed to fix this by making scsi modules and using initrd. has
> something with redhat's initscripts changed to require this? i
> couldn't figure it out. i am just throwing this to the list to see
> what anyone else makes of it.
>
>
> thank you in advance for any light you all can shed upon these issues.
>
> --
> J o h a n K u l l s t a m
> [[EMAIL PROTECTED]]
> Don't Fear the Penguin!
> -
> Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
> To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
>
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
