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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
