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