Jurij Smakov a écrit :
On Mon, 24 Apr 2006, BERTRAND Joël wrote:
I have tested your patch with a SuperSPARC-II/smp workstation and
I cannot obtain any error. I have seen that the last release candidate
(2.6.17-rc2) is given with this patch. Thus, I have tried to boot in
smp configuration, but kernel panics very early.
Ok, just to be absolutely clear: when you say "with your patch", do you
mean "with the locking change reverted"? Does it work fine with UP
kernel on an SMP workstation? At this point I don't care too much about
SMP kernels :-), just want to positively establish that reverting the
locking change does have positive effects on UP kernels.
I use a patched kernel tree (2.6.17-rc1 with smp patch and locking
change reverted). I have built this kernel without smp and test it with
two SuperSPARC-II, 384 Mbytes and a CG6 framebuffer. With smp support
(up to 4 processors), the same kernel boots fine. It panics when I
remove the CG6 framebuffer to use a CG14.
With one or two HyperSPARC/200, the same kernel boots but is very
instable : tar xvfj linux-2.6.16.10.tar.bz2 for exemple returns a
ssegmentation fault. Some ESP DMA errors are now returned by kernel...
If I only use 128 MBytes without HIGHMEM, this kernel is more stable,
but not very very stable ;-)
I have tried to boot the following configuration : two HyperSPARC/200,
kernel that works on UP-SuperSPARC with lock reverted, and cachesize=0
on the kernel command line. Same result. Thus, I'm pretty sure that the
bug I can seen come from HyperSPARC specific MMU and not from the cache.
I expect that cachesize option works on sparc kernel...
I don't know where we can use a Sparc(/STATION/SERVER/) sun4m with
HyperSPARC. Thus, I will install SuperSPARC on one of my SS20 to test
the last stable kernel with the lock patch. Have you seen that the
rc-1/2 can not be used with CG14 (or prom console...) ?
Regards,
JKB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
