Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

2006-12-04 Thread Jurij Smakov
On Mon, Dec 04, 2006 at 07:52:43AM +0100, BERTRAND Joël wrote:

   I don't try with debian package, only with official linux kernel. I 
 have tested the 2.6.19 but sunlance doesn't work for me in a SS20 that 
 runs with two sunlance (eth0/1)and one hme (eth2) interfaces... I don't 
 know the difference between the debian and official kernels.

It should be relatively minor, the only sparc-related patches included 
are backports of some essential bugfixes.

   Is your kernel SMP ? Do you use HIGHMEM ?

CONFIG_HIGHMEM is set. CONFIG_SMP is not, since it has not been deemed 
mature enough. Current plan is that etch is not going to support SMP 
on sparc32, so we are building only one, uniprocessor, flavour. You 
can find the complete config used when building Debian kernel at

http://www.wooyd.org/misc/config-2.6.18-3-sparc32

In general, if the problem is not reproducible with the Debian's stock 
kernel, then the bug clearly should not be RC. Please let me know if 
that's the case, or lower the severity yourself, if applicable.

   I have a 2.25 from Sun in one, a 2.25R from ROSS in another one and 
   a 2.25W (?) from an HyperSTATION in the third one. Tested modules are 
 single and dual RT-626 with a VSIMM (4 and 8MB) and 448 MB. I think it 
 is not an hardware trouble because all configurations I have tried 
 return exactly the same error. Hardware of the main station I use for 
 tests are validated with Solaris9 and without any trouble during several 
 days (but I cannot use three or four CPU with Solaris9 without having 
 Watchdog reset!, all combinaisons with more than two CPU are not 
 stable. Same results on the three stations. If I have time, I shall try 
 to install a Solaris 2.7...).

Sorry that I cannot be more helpful. As much as I would like to see 
working SMP on sparc32, I don't have neither skills nor time to work 
on improving it.

Best regards,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC



Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

2006-12-03 Thread Guillem Jover
reassign 400372 linux-image-2.6.18-3-sparc32
thanks

Included most of the relevant discussion for the kernel team's benefit.

On Sun, 2006-11-26 at 10:19:39 +0100, BERTRAND Joël wrote:
 Guillem Jover a écrit :
 On Sat, 2006-11-25 at 19:19:58 +0100, BERTRAND Joël wrote:
   Package: dpkg
   Version: 1.13.24
   Architecture: sparc
   Severity: grave

   I have some SparcSTATION 20 with one or two SuperSPARC-II and 448 MB
   of memory (thus, HIGHMEM is used). On these workstations, dpkg works fine.
   If I replace SuperSPARC-II by one, two or four ROSS RT-626, I cannot use
   dpkg because it craches with a random error when it tries to configure
   the package (it cannot read the configuration script due to a data
   corruption. Sometimes, an EOF in the middle of the script...).
  
   I have tested dpkg on three SS20 that perfectly work with SuperSPARC
   and with four different HyperSPARC modules, and with and without HIGHMEM.
  
   Results : in all configurations (with and without HIGHMEM), dpkg
   crashes with HyperSPARC and works with SuperSPARC. I don't understand
   this memory corruption because the workstations work fine in all
   configurations I have tested ! Kernels are 2.6.18.x.

  Given that this happens when changing the CPU, and that this does not
  happen anywhere else, I'd say it's a hw or kernel problem. Also given
  the mails[0] in debian-sparc about past state of HyperSparc support I
  would say this is not related to dpkg, and the bug would need closing
  or to be reassigned. But I've CCed debian-sparc for comments.
 
  [0] http://lists.debian.org/debian-sparc/2006/04/msg3.html
 http://lists.debian.org/debian-sparc/2006/04/msg00018.html
 http://lists.debian.org/debian-sparc/2006/06/msg00030.html

   I know these mails and I have contributed to the sparc32 smp support 
 (and ESP module debug). Today, the ESP works fine (since 2.6.18) and the 
 HyperSPARC support seems to works too. Only on trouble with a 2.6.18 
 kernel with pipes() :
 
 Nov 23 14:26:47 hilbert kernel: Unable to handle kernel NULL pointer 
 dereference
 Nov 23 14:26:48 hilbert kernel: tsk-{mm,active_mm}-context = 5058
 Nov 23 14:26:48 hilbert kernel: tsk-{mm,active_mm}-pgd = fc12d000
 Nov 23 14:26:48 hilbert kernel:   \|/  \|/
 Nov 23 14:26:48 hilbert kernel:   @'/ ,. \`@
 Nov 23 14:26:48 hilbert kernel:   /_| \__/ |_\
 Nov 23 14:26:48 hilbert kernel:  \__U_/
 Nov 23 14:26:48 hilbert kernel: tar(13387): Oops [#1]
 Nov 23 14:26:48 hilbert kernel: PSR: 40c2 PC: f008bd8c NPC: f008bd90 Y: 
 Not tainted
 Nov 23 14:26:48 hilbert kernel: PC: pipe_readv+0xac/0x440
 Nov 23 14:26:48 hilbert kernel: %%G: 1000 fbbfea14  003c 0030  
 fbbfea00 73635f6c  f93be000 
 Nov 23 14:26:48 hilbert kernel: %%O: f0a0d900 f0a0d900  fcffb000 63616368  
 6536345f 70616765  f93bfd88 f008c030
 Nov 23 14:26:48 hilbert kernel: RPC: pipe_readv+0x350/0x440
 Nov 23 14:26:48 hilbert kernel: %%L:    fbbfea50 fbbfea00  
  fcffc000  0001 0001
 Nov 23 14:26:48 hilbert kernel: %%I: f93bfe60 0003  f93bfe60 1800  
 fcffb000   f93bfe00 f008c140
 Nov 23 14:26:48 hilbert kernel: Caller[f008c140]: pipe_read+0x20/0x28
 Nov 23 14:26:48 hilbert kernel: Caller[f007dee8]: vfs_read+0xa0/0x16c
 Nov 23 14:26:48 hilbert kernel: Caller[f007eb38]: sys_read+0x38/0x64
 Nov 23 14:26:48 hilbert kernel: Caller[f0015a3c]: 
 syscall_is_too_hard+0x3c/0x40
 Nov 23 14:26:48 hilbert kernel: Caller[0003df90]: 0x3df98
 
   But whit bug is very strange, it only occurs with dpkg. It is not a 
 material failure because I can see it with all couple off HyperSPARC, 
 memory and motherboard. And I cannot see any trace in the logs. All 
 daemons, all programs I use work fine on the same station.

I don't think you can expect userland to cope well if pipe is crashing
in the kernel, thus reassigning.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Processed: Re: Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

2006-12-03 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 reassign 400372 linux-image-2.6.18-3-sparc32
Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor
Bug reassigned from package `dpkg' to `linux-image-2.6.18-3-sparc32'.

 thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

2006-12-03 Thread Jurij Smakov
Hi Joel,

Sorry, I cannot reproduce the behavior you are describing. I have a 
SS20 box, running sid with Debian's linux-image-2.6.18-3-sparc32 
(version 2.6.18-6) kernel:

debian:~# uname -a
Linux debian 2.6.18-3-sparc32 #1 Fri Nov 24 16:10:16 GMT 2006 sparc GNU/Linux
debian:~# cat /proc/version 
Linux version 2.6.18-3-sparc32 (Debian 2.6.18-6) ([EMAIL PROTECTED]) (gcc 
version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 Fri Nov 
24 16:10:16 GMT 2006
debian:~# cat /proc/cpuinfo 
cpu : ROSS HyperSparc RT625 or RT626
fpu : ROSS HyperSparc combined IU/FPU
promlib : Version 3 Revision 2
prom: 2.25
type: sun4m
ncpus probed: 2
ncpus active: 1
CPU0Bogo: 133.12
CPU0ClkTck  : 13300
MMU type: ROSS HyperSparc
contexts: 4096
nocache total   : 2252800
nocache used: 492800

To stress-test dpkg I've just ran 'apt-get install kde' on an unstable 
system. That a pretty big update:

[..]
0 upgraded, 400 newly installed, 0 to remove and 2 not upgraded.
Need to get 242MB of archives.
After unpacking 678MB of additional disk space will be used.

and it completed without any problems. I also do not recall having any 
problems with dpkg recently. 

What OBP version do you have in these machines? ISTR that to run 
latest HyperSPARC CPUs from Ross you need either 2.25 from Sun, or 
2.25R from Ross. If you are running anything lower, I suggest you try 
to upgrade your firmware, see http://www.sunshack.org/data/bootroms.html
for details.

Best regards,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

2006-12-03 Thread BERTRAND Joël

Jurij Smakov a écrit :

Hi Joel,


Hello Jurij,

Sorry, I cannot reproduce the behavior you are describing. I have a 
SS20 box, running sid with Debian's linux-image-2.6.18-3-sparc32 
(version 2.6.18-6) kernel:


	I don't try with debian package, only with official linux kernel. I 
have tested the 2.6.19 but sunlance doesn't work for me in a SS20 that 
runs with two sunlance (eth0/1)and one hme (eth2) interfaces... I don't 
know the difference between the debian and official kernels.



debian:~# uname -a
Linux debian 2.6.18-3-sparc32 #1 Fri Nov 24 16:10:16 GMT 2006 sparc GNU/Linux
debian:~# cat /proc/version 
Linux version 2.6.18-3-sparc32 (Debian 2.6.18-6) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 Fri Nov 
24 16:10:16 GMT 2006
debian:~# cat /proc/cpuinfo 
cpu : ROSS HyperSparc RT625 or RT626

fpu : ROSS HyperSparc combined IU/FPU
promlib : Version 3 Revision 2
prom: 2.25
type: sun4m
ncpus probed: 2
ncpus active: 1
CPU0Bogo: 133.12
CPU0ClkTck  : 13300
MMU type: ROSS HyperSparc
contexts: 4096
nocache total   : 2252800
nocache used: 492800

To stress-test dpkg I've just ran 'apt-get install kde' on an unstable 
system. That a pretty big update:


Is your kernel SMP ? Do you use HIGHMEM ?


[..]
0 upgraded, 400 newly installed, 0 to remove and 2 not upgraded.
Need to get 242MB of archives.
After unpacking 678MB of additional disk space will be used.

and it completed without any problems. I also do not recall having any 
problems with dpkg recently. 


What OBP version do you have in these machines?


	I have a 2.25 from Sun in one, a 2.25R from ROSS in another one and a 
2.25W (?) from an HyperSTATION in the third one. Tested modules are 
single and dual RT-626 with a VSIMM (4 and 8MB) and 448 MB. I think it 
is not an hardware trouble because all configurations I have tried 
return exactly the same error. Hardware of the main station I use for 
tests are validated with Solaris9 and without any trouble during several 
days (but I cannot use three or four CPU with Solaris9 without having 
Watchdog reset!, all combinaisons with more than two CPU are not 
stable. Same results on the three stations. If I have time, I shall try 
to install a Solaris 2.7...).


ISTR that to run 
latest HyperSPARC CPUs from Ross you need either 2.25 from Sun, or 
2.25R from Ross. If you are running anything lower, I suggest you try 
to upgrade your firmware, see http://www.sunshack.org/data/bootroms.html

for details.


	Maybe this trouble is related to the trouble I see with two 
SuperSPARC's (Oops in readv_pipe). I don't know...


Regards,

JKB



Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

2006-11-26 Thread BERTRAND Joël

Guillem Jover a écrit :

Hi,

On Sat, 2006-11-25 at 19:19:58 +0100, BERTRAND Joël wrote:


Package: dpkg
Version: 1.13.24
Architecture: sparc
Severity: grave




I have some SparcSTATION 20 with one or two SuperSPARC-II and 448 MB
of memory (thus, HIGHMEM is used). On these workstations, dpkg works fine.
If I replace SuperSPARC-II by one, two or four ROSS RT-626, I cannot use
dpkg because it craches with a random error when it tries to configure
the package (it cannot read the configuration script due to a data
corruption. Sometimes, an EOF in the middle of the script...).

I have tested dpkg on three SS20 that perfectly work with SuperSPARC
and with four different HyperSPARC modules, and with and without HIGHMEM.

Results : in all configurations (with and without HIGHMEM), dpkg
crashes with HyperSPARC and works with SuperSPARC. I don't understand
this memory corruption because the workstations work fine in all
configurations I have tested ! Kernels are 2.6.18.x.



Given that this happens when changing the CPU, and that this does not
happen anywhere else, I'd say it's a hw or kernel problem. Also given
the mails[0] in debian-sparc about past state of HyperSparc support I
would say this is not related to dpkg, and the bug would need closing
or to be reassigned. But I've CCed debian-sparc for comments.

[0] http://lists.debian.org/debian-sparc/2006/04/msg3.html
http://lists.debian.org/debian-sparc/2006/04/msg00018.html
http://lists.debian.org/debian-sparc/2006/06/msg00030.html


	I know these mails and I have contributed to the sparc32 smp support 
(and ESP module debug). Today, the ESP works fine (since 2.6.18) and the 
HyperSPARC support seems to works too. Only on trouble with a 2.6.18 
kernel with pipes() :


Nov 23 14:26:47 hilbert kernel: Unable to handle kernel NULL pointer 
dereference

Nov 23 14:26:48 hilbert kernel: tsk-{mm,active_mm}-context = 5058
Nov 23 14:26:48 hilbert kernel: tsk-{mm,active_mm}-pgd = fc12d000
Nov 23 14:26:48 hilbert kernel:   \|/  \|/
Nov 23 14:26:48 hilbert kernel:   @'/ ,. \`@
Nov 23 14:26:48 hilbert kernel:   /_| \__/ |_\
Nov 23 14:26:48 hilbert kernel:  \__U_/
Nov 23 14:26:48 hilbert kernel: tar(13387): Oops [#1]
Nov 23 14:26:48 hilbert kernel: PSR: 40c2 PC: f008bd8c NPC: f008bd90 
Y: Not tainted

Nov 23 14:26:48 hilbert kernel: PC: pipe_readv+0xac/0x440
Nov 23 14:26:48 hilbert kernel: %%G: 1000 fbbfea14  003c 
0030  fbbfea00 73635f6c  f93be000 
Nov 23 14:26:48 hilbert kernel: %%O: f0a0d900 f0a0d900  fcffb000 
63616368  6536345f 70616765  f93bfd88 f008c030

Nov 23 14:26:48 hilbert kernel: RPC: pipe_readv+0x350/0x440
Nov 23 14:26:48 hilbert kernel: %%L:    fbbfea50 
fbbfea00   fcffc000  0001 0001
Nov 23 14:26:48 hilbert kernel: %%I: f93bfe60 0003  f93bfe60 
1800  fcffb000   f93bfe00 f008c140

Nov 23 14:26:48 hilbert kernel: Caller[f008c140]: pipe_read+0x20/0x28
Nov 23 14:26:48 hilbert kernel: Caller[f007dee8]: vfs_read+0xa0/0x16c
Nov 23 14:26:48 hilbert kernel: Caller[f007eb38]: sys_read+0x38/0x64
Nov 23 14:26:48 hilbert kernel: Caller[f0015a3c]: 
syscall_is_too_hard+0x3c/0x40

Nov 23 14:26:48 hilbert kernel: Caller[0003df90]: 0x3df98

	But whit bug is very strange, it only occurs with dpkg. It is not a 
material failure because I can see it with all couple off HyperSPARC, 
memory and motherboard. And I cannot see any trace in the logs. All 
daemons, all programs I use work fine on the same station.


Regards,

JKB



Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

2006-11-25 Thread BERTRAND Joël

Package: dpkg
Version: 1.13.24
Architecture: sparc
Severity: grave

Hello,

	I have some SparcSTATION 20 with one or two SuperSPARC-II and 448 MB of 
memory (thus, HIGHMEM is used). On these workstations, dpkg works fine. 
If I replace SuperSPARC-II by one, two or four ROSS RT-626, I cannot use 
dpkg because it craches with a random error when it tries to configure 
the package (it cannot read the configuration script due to a data 
corruption. Sometimes, an EOF in the middle of the script...).


	I have tested dpkg on three SS20 that perfectly work with SuperSPARC 
and with four different HyperSPARC modules, and with and without HIGHMEM.


	Results : in all configurations (with and without HIGHMEM), dpkg 
crashes with HyperSPARC and works with SuperSPARC. I don't understand 
this memory corruption because the workstations work fine in all 
configurations I have tested ! Kernels are 2.6.18.x.


Any idea ?

Regards,

JKB


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

2006-11-25 Thread Guillem Jover
Hi,

On Sat, 2006-11-25 at 19:19:58 +0100, BERTRAND Joël wrote:
 Package: dpkg
 Version: 1.13.24
 Architecture: sparc
 Severity: grave

 I have some SparcSTATION 20 with one or two SuperSPARC-II and 448 MB
 of memory (thus, HIGHMEM is used). On these workstations, dpkg works fine.
 If I replace SuperSPARC-II by one, two or four ROSS RT-626, I cannot use
 dpkg because it craches with a random error when it tries to configure
 the package (it cannot read the configuration script due to a data
 corruption. Sometimes, an EOF in the middle of the script...).

 I have tested dpkg on three SS20 that perfectly work with SuperSPARC
 and with four different HyperSPARC modules, and with and without HIGHMEM.

 Results : in all configurations (with and without HIGHMEM), dpkg
 crashes with HyperSPARC and works with SuperSPARC. I don't understand
 this memory corruption because the workstations work fine in all
 configurations I have tested ! Kernels are 2.6.18.x.

Given that this happens when changing the CPU, and that this does not
happen anywhere else, I'd say it's a hw or kernel problem. Also given
the mails[0] in debian-sparc about past state of HyperSparc support I
would say this is not related to dpkg, and the bug would need closing
or to be reassigned. But I've CCed debian-sparc for comments.

[0] http://lists.debian.org/debian-sparc/2006/04/msg3.html
http://lists.debian.org/debian-sparc/2006/04/msg00018.html
http://lists.debian.org/debian-sparc/2006/06/msg00030.html

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]