Package: libc6
Version: 2.5-9
Severity: critical
Justification: breaks the whole system
The following command leads to a system crash:
[EMAIL PROTECTED]:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
The command hangs after the first line of output is printed. It
is
John David Anglin a écrit :
Package: libc6
Version: 2.5-9
Severity: critical
Justification: breaks the whole system
The following command leads to a system crash:
[EMAIL PROTECTED]:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
The command hangs after the
Is the libc6 the only thing that you updated? I am using the same libc
here, paer.debian.org also uses it in the sid chroot, and I am unable to
reproduce the problem.
No, some other packages were updated. Here are the most recent
packages in /var/cache/apt/archives:
-rw-r--r-- 1 root root
Is the libc6 the only thing that you updated? I am using the same libc
here, paer.debian.org also uses it in the sid chroot, and I am unable to
reproduce the problem.
This is on a PA8800 machine.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 1110 Not tainted
r00-03 00ff0806ff0f 4036c000 40104edc
c0601048
r04-07 403d79d4 403d89d4 0002c258
r08-11 0002a3f4
John David Anglin a écrit :
Is the libc6 the only thing that you updated? I am using the same libc
here, paer.debian.org also uses it in the sid chroot, and I am unable to
reproduce the problem.
No, some other packages were updated. Here are the most recent
packages in
It looks like you are using a hand built kernel. Do you use the patch to
disable LWS CAS debugging [1] ?
Yes, but I've been told by Kyle that it's too old. Syscall 298 was
added in 2.6.21.
I haven't disabled LWS CAS.
My attempts at modifying the kernel to return ENOSYS so far haven't
been
John David Anglin a écrit :
It looks like you are using a hand built kernel. Do you use the patch to
disable LWS CAS debugging [1] ?
Yes, but I've been told by Kyle that it's too old. Syscall 298 was
added in 2.6.21.
I found really strange that this version of the glibc is using this
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40005000
read(3, /dev/sda3 / ext3 rw,errors=remou..., 4096) = 339
read(3, , 4096) = 0
close(3)= 0
I found really strange that this version of the glibc is using this
syscall. It has been released 6 months ago, when 2.6.19 was still not
released... How did you get this syscall number?
It's in register r20 of the register dump that I posted.
Dave
--
J. David Anglin
John David Anglin a écrit :
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40005000
read(3, /dev/sda3 / ext3 rw,errors=remou..., 4096) = 339
read(3, , 4096) = 0
close(3)
It really looks like a bug in the kernel.
Yes, see
http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031651.html
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
--
To
It really looks like a bug in the kernel.
Yes, see
http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031651.html
The change posted here fixes the df problem:
http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031652.html
So, this bug report can be closed.
Dave
--
13 matches
Mail list logo
