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]
