When I try to start KDE 2.0 with SMP builds
of 2.4.0-test11-ac2 and ac4, the system locks up
after "Loading Panel". Nothing odd gets logged
to /var/log/messages.
I can successfully run KDE 2.0 with UP builds
of any of these kernels.
I can successfully run Gnome or Fvwm1 with
either UP or SMP builds of any of these kernels.
This table summarizes my experience with KDE 2.0
with recent 2.4.0-test11 and later kernels:
UP SMP
test11 OK OK
test11-ac1 OK OK
test11-ac2 OK FAILS
test11-ac3 NOT TESTED
test11-ac4 OK FAILS
The 2.4.0-test11-ac1 SMP kernel which successfully
runs KDE 2.0 has my small patch to
linux/include/asm-i386/hardirq.h which allowed an
SMP kernel to be built for test11-ac1.
The base distribution of this system is
Linux-Mandrake 7.2. The hardware is a Dell
Precision 420 Dual P-III. All kernels are patched with
linux-2.4.0-test10-reiserfs-3.6.19-patch.
Steven
> When I try to start KDE 2.0 with SMP builds
> of 2.4.0-test11-ac2 and ac4, the system locks up
> after "Loading Panel". Nothing odd gets logged
> to /var/log/messages.
> Precision 420 Dual P-III. All kernels are patched with
> linux-2.4.0-test10-reiserfs-3.6.19-patch.
I don't test -ac kernel trees with reiserfs. I don't really have time. Can
you or others reproduce the same report on an unmodified tree.
Alan
On Monday 27 November 2000 13:08, Alan Cox wrote:
> > Precision 420 Dual P-III. All kernels are patched with
> > linux-2.4.0-test10-reiserfs-3.6.19-patch.
>
> I don't test -ac kernel trees with reiserfs. I don't really have time. Can
> you or others reproduce the same report on an unmodified tree.
>
> Alan
I will have to acquire another suitable disk to reproduce this problem
using an unmodified tree. If anyone can help, I'd appreciate it. Thanks
in advance. If not, I'll try to reproduce it when I can get the hardware.
For what its worth, on my single processor home machine, all kernels
2.4.0-test11-ac1,ac2,ac3, ac4 both UP and SMP run both Gnome and
KDE 2.0, with reiserfs-3.6.19. In other words, everything works with
everything.
Steven
> For what its worth, on my single processor home machine, all kernels
> 2.4.0-test11-ac1,ac2,ac3, ac4 both UP and SMP run both Gnome and
> KDE 2.0, with reiserfs-3.6.19. In other words, everything works with
> everything.
Nod. It actually puzzles me since from the kernel view I doubt kde and gnome
even look different at the syscall level. They may look different to X but
X isnt the thing that changed
Alan Cox wrote:
>
>> For what its worth, on my single processor home machine, all kernels
>> 2.4.0-test11-ac1,ac2,ac3, ac4 both UP and SMP run both Gnome and
>> KDE 2.0, with reiserfs-3.6.19. In other words, everything works with
>> everything.
>
>Nod. It actually puzzles me since from the kernel view I doubt kde and gnome
>even look different at the syscall level. They may look different to X but
>X isnt the thing that changed
Agreed. I suspect that this could be a rough spot with reiserfs-3.6.19.
I observed one similar freezup while doing
tar zxvf linux-2.4.0-test11.tar.gz
while running 2.4.0-test11-pre7, patched with reiserfs-3.6.19.
I and others have experienced some off-normal behaviour with
reiserfs, like crashing when saving a file on top of itself with StarOffice
5.2 when the file was on an NFS server. That particular bug
was fixed in reiserfs-3.6.14, IIRC. But even with the few rough edges,
reiserfs has become essential to our operations, with its ability to recover
so quickly after a UPS has caused problems. That's why I'm following the
2.4.0 development so closely with reiserfs.
I was never able to reproduce the tar freeze. The freeze which I
observed with test11-ac2,4 SMP and KDE 2.0 was very reproducable; I saw
it at least 6 times, always in exactly the same place of the startup of
KDE 2.0.
Tomorrow when I have access to the two-way P-III problem machine,
I'll repatch 2.4.0-test11-ac4 with reiserfs-3.6.18,
which is a little less bleeding edge than reiserfs-3.6.19.
Meanwhile, 2.4.0-test12-pre2 patched with reiserfs-3.6.19 is running
nicely with KDE 2.0 on the uniprocessor home machine.
Steven
Alan Cox wrote:
>
>Nod. It actually puzzles me since from the kernel view I doubt kde and gnome
>even look different at the syscall level. They may look different to X but
>X isnt the thing that changed
Steven Cole wrote:
>
>Tomorrow when I have access to the two-way P-III problem machine,
>I'll repatch 2.4.0-test11-ac4 with reiserfs-3.6.18,
>which is a little less bleeding edge than reiserfs-3.6.19.
2.4.0-test11-ac2 still freezes starting up KDE 2.0 when patched
with reiserfs-3.6.18.
2.4.0-test12-pre2 both SMP and UP builds also freeze when starting
up KDE 2.0 on this dual cpu box. Those test12-pre2 kernels are
patched with reiserfs-3.6.19.
I guess I'll have to switch over to using Gnome if I want to continue
using kernels later than 2.4.0-test11-ac1 and ReiserFS on this dual
P-III Dell 420.
Can someone else please see if this is reproducable?
The ingredients are:
Dual CPU P-III.
2.4.0-test11-ac2 or later (test12-pre2)
SMP build for -acX. (X > 1).
ReiserFS 3.6.18 or 3.6.19.
KDE 2.0
Thanks very much.
Steven