At 06:51 PM 9/7/99 -0400, [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]
>
Johan,
I don't quite understand the detail of the trouble shooting. But just for
your information, I have one dual Pentium MMX 200 with SMP kernel level
2.2.5 running X windows OK. They also work together OK with a previous
kernel version 2.0.30. I cannot sure whether it will work on a 4
processors machine but seems the problem is not simply SMP and X conflict
problem.
S.L.Mo
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
