Re: Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor
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/msg00003.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 = 00005058
> 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: 400000c2 PC: f008bd8c NPC: f008bd90 Y: 00000000 Not tainted
> Nov 23 14:26:48 hilbert kernel: PC: <pipe_readv+0xac/0x440>
> Nov 23 14:26:48 hilbert kernel: %%G: 00001000 fbbfea14 0000003c 00000030 fbbfea00 73635f6c f93be000 00000000
> 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: 00000000 00000000 fbbfea50 fbbfea00 00000000 fcffc000 00000001 00000001
> Nov 23 14:26:48 hilbert kernel: %%I: f93bfe60 00000003 f93bfe60 00001800 fcffb000 00000000 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
Reply to: