Bug#401236: backtrace from varmon
Hi, I've compiled varmon again with -ggdb from vanilla source. Here is the progress: hostname:~/varmon-1.2.0# make clean rm -f *.o core varmon hostname:~/varmon-1.2.0# make varmon gcc -o varmon varmon.c -Wall -lncurses -ggdb varmon.c: In function ‘get_backplane_info’: varmon.c:166: warning: pointer targets in passing argument 8 of ‘v2_SCSI_cmd’ differ in signedness varmon.c:206: warning: pointer targets in passing argument 8 of ‘v2_SCSI_cmd’ differ in signedness varmon.c:234: warning: pointer targets in assignment differ in signedness varmon.c: In function ‘detect_backplane’: varmon.c:496: warning: pointer targets in passing argument 2 of ‘strncpy’ differ in signedness varmon.c:505: warning: pointer targets in passing argument 1 of ‘strncmp’ differ in signedness varmon.c:506: warning: pointer targets in passing argument 1 of ‘strncmp’ differ in signedness varmon.c:511: warning: pointer targets in passing argument 1 of ‘strncmp’ differ in signedness hostname:~/varmon-1.2.0# gdb ./varmon GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as alpha-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: varmon Scanning for VA safety backplane. Please wait a few moments... DAC960: Ctrlr 0, PCI 00:0d:00, IRQ 22, Channels 3 DAC960: Model DAC960PU, Firmware 2.73-0-00 Scanning Controller[0], Channel[0], ID[0] Program received signal SIGSEGV, Segmentation fault. 0x000120003eb0 in detect_backplane () at varmon.c:501 501 tmp[index] = inq.ProductIdentification[index]; (gdb) bt #0 0x000120003eb0 in detect_backplane () at varmon.c:501 #1 0x000120018ad8 in main (argc=1128612896, argv=0x53432d4243315a52) at varmon.c:3490 (gdb) Strange enough, it runs like a charm when compiled with -O2 ?!? If you need more information, please let me know. Regards, Dimitri Puzin aka Tristan-777
Bug#401236: backtrace from varmon
On Tue, Dec 05, 2006 at 07:12:51PM +0100, Julien Danjou wrote: At 1165341916 time_t, Dimitri Puzin wrote: Strange enough, it runs like a charm when compiled with -O2 ?!? If you need more information, please let me know. Could you try to (gdb) print index $1 = 2108 (gdb) print inq.ProductIdentification[index] $2 = 32 ' ' (gdb) print *tmp $3 = 82 'R' Is there any chance I could get access to this box ? This is currently bit difficult :( we're having connectivity problems... -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401236: varmon segfaults on alpha
Package: varmon
Version: 1.2.0-3
Severity: grave
Hi,
varmon is unusable on alpha. It segfaults with following message
hostname:~# varmon
Scanning for VA safety backplane.
Please wait a few moments...
DAC960: Ctrlr 0, PCI 00:0d:00, IRQ 22, Channels 3
DAC960: Model DAC960PU, Firmware 2.73-0-00
Scanning Controller[0], Channel[0], ID[0] Segmentation fault
The relevant strace:
lseek(3, 0, SEEK_SET) = 0
getdents64(3, /* 4 entries */, 8192)= 104
getdents64(3, /* 0 entries */, 8192)= 0
lseek(3, 0, SEEK_SET) = 0
getdents64(3, /* 4 entries */, 8192)= 104
getdents64(3, /* 0 entries */, 8192)= 0
open(/proc/rd/c0/current_status, O_RDONLY) = 4
read(4, * DAC960 RAID Driver Version..., 4096) = 1308
read(4, , 4096) = 0
close(4)= 0
open(/proc/rd/c0/current_status, O_RDONLY) = 4
read(4, * DAC960 RAID Driver Version..., 4096) = 1308
read(4, , 4096) = 0
close(4)= 0
uname({sys=Linux, node=hostname, ...}) = 0
close(3)= 0
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x201c000
uname({sys=Linux, node=hostname, ...}) = 0
open(/dev/dac960_gam, O_RDWR|O_NONBLOCK) = 3
ioctl(3, 0xdac001, 0) = 1
ioctl(3, 0xdac002, 0x11f94d9b0) = 0
ioctl(3, 0xdac003, 0x11f94d698) = 0
write(1, \nScanning for VA safety backplan..., 201
Scanning for VA safety backplane.
Please wait a few moments...
DAC960: Ctrlr 0, PCI 00:0d:00, IRQ 22, Channels 3
DAC960: Model DAC960PU, Firmware 2.73-0-00
^MScanning Controller[0], Channel[0], ID[0] ) = 201
ioctl(3, 0xdac003, 0x11f94d688) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 11699 detached
Regards,
-Dimitri Puzin aka Tristan-777
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395931: libapache2-mod-auth-kerb: Apache2 segfaults when loading the module
Package: libapache2-mod-auth-kerb
Version: 5.1-1
Severity: grave
After upgrade to apache 2.0 and libapache2-mod-auth-kerb 5.1
apache2 segfaults when loading the module. Removing the symlink from
/etc/apache2/mods-enabled makes apache start normally however without
kerberos auth support
relevant part of strace
time(NULL) = 1162064323
stat64(/etc/krb5.conf, {st_mode=S_IFREG|0644, st_size=769, ...}) = 0
open(/etc/krb5.conf, O_RDONLY)= 11
access(/etc/krb5.conf, W_OK) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=769, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7ee5000
read(11, [libdefaults]\n\tdefault_realm = L..., 4096) = 769
read(11, , 4096) = 0
close(11) = 0
munmap(0xb7ee5000, 4096)= 0
time(NULL) = 1162064323
stat64(/usr/etc/krb5.conf, 0xbf864fd0) = -1 ENOENT (No such file or
directory)open(/dev/urandom, O_RDONLY) = 11
fstat64(11, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
read(11, t\325\6lk\321\267\310\242\3675\235\303\326\214_jr4\306...,
20) = 20
close(11) = 0
futex(0xb7704988, FUTEX_WAKE, 2147483647) = 0
gettimeofday({1162064323, 452111}, NULL) = 0
time(NULL) = 1162064323
time(NULL) = 1162064323
time(NULL) = 1162064323
time(NULL) = 1162064323
time(NULL) = 1162064323
time(NULL) = 1162064323
time(NULL) = 1162064323
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 26631 detached
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.1
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to de_DE.UTF-8)
Versions of packages libapache2-mod-auth-kerb depends on:
ii apache2.2-common 2.2.3-2 Next generation, scalable, extenda
ii krb5-config 1.10Configuration files for Kerberos V
ii libc62.3.6.ds1-4 GNU C Library: Shared libraries
ii libcomerr2 1.39-1 common error description library
ii libkrb53 1.4.4-3 MIT Kerberos runtime libraries
libapache2-mod-auth-kerb recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386305: iacd won't start if the pidfile already exists
Package: iacd Version: 0.0.26-5 Severity: grave Hello, the current version of iacd won't remove its pidfile, even on normal shutdown of the daemon. The daemon won't start if the pidfile already exists. This prevents the daemon from starting up the next time via initscript. The init script terminates silently without error. This bug renders the package effectively unusable. The cause for this behavior is the privilege drop which appears to happen after the pidfile was created. The pidfile then belongs to root and cannot be removed by the daemon which runs under uid/gid of irc. One possible solution to this bug could be the removal of the pidfile inside the init script after termination of the daemon. Bug #268636 also deserves some attention, please. It took quite some time to figure it out. This could also be of severity grave. Regards, -Dimitri Puzin aka Tristan-777 signature.asc Description: OpenPGP digital signature
Bug#294404: udev and mdadm mess
Package: mdadm Version: 1.9.0-1 Followup-For: Bug #294404 Hello, I've been trying to setup md-raid on a system using udev and ran across the problem described in this bug. AFAICS udev won't create device nodes as long as there is no device initialized in the kernel. OTOH mdadm insists on having a device node for the RAID before it is built. So far my understanding of the problem. Now my solution. mdadm 1.9.0 has the auto option for the mdadm.conf file. However it seems to be picky about the position of that statement inside the conf file. So far, it has worked for me only if auto=md was the last statement for the ARRAY definition. Another problem: it seems that DEVICE partitions in mdadm.conf doesn't properly detect all raid partitions. I've replaced that line with the old-style def. Here my working mdadm.conf: DEVICE /dev/sda*, /dev/sdb* ARRAY /dev/md0 level=raid1 num-devices=2 UUID= devices=/dev/sda1,/dev/sdb1 auto=md This works nicely on a couple of machines here. The partitions are type 0xFD (raid autodetect). Hope that helps. Warm regards, -Dimitri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
