Bug#740070: Updating the sendmail Maintainer field
Debian's Sendmail package has been orphaned for several years. The amount of work which might be involved in maintainership is a little scary, but I should like to take it on. To control unwanted mail, I primarily use milters. In the early years (I've used Sendmail in production for more than 25 years) I tried many milters, but after a decade or so I settled on about seven, which did most of what I wanted - but with varying degrees of pain, because of differences in design, configuration syntax etc. Finally I wrote my own milter (in Perl), which replaced all the rest, and which I've now been using for about four years. I won't bore you with the details of the milter's capabilities unless you're interested in them, but it is now nearing the point where I could let someone else see it. :) For those who would like to use milters but who have perhaps found the Sendmail Milter API daunting, I hope that my milter will make things easier. Coding a milter in Perl is much easier, and much safer, and very much quicker and more productive than is coding a milter in C. Hopefully one day my milter might be incorporated into a teaching aid. My Perl milter uses a CPAN module, Sendmail::PMilter, which provides the Perl interface to Sendmail's Milter API. Sendmail::PMilter is in the development stages, but I have been using the latest development version for a year. A couple of years ago I took on maintainership of Sendmail::PMilter myself, initially so that I could remove dependence on another CPAN module, Sendmail::Milter. That module is in a very unsatisfactory state, having been unmaintained for well over 15 years. For more than a year I tried to take on the CPAN maintainership of the Sendmail::Milter module too, but it seemed that the present maintainer was being deliberately obstructive and I abandoned that effort. The Sendmail::PMilter development version no longer uses Sendmail::Milter, and I think I've fixed all the outstanding Sendmail::PMilter issues, although it could all use a lot more testing (especially the threaded interface, which I have not used at all - it blew up spectacularly at my first attempt, and although I've patched it according to others who have used it, I've never been back there). Eventually I should like Sendmail, Sendmail::PMilter and my own milter all to install and work together seamlessly on a Debian installation. Although I'm comfortable with C, Perl and building software generally, on the subject of Debian packaging I am a novice and the documentation that I have found about using the bug tracking system seems to me to be inadequate. Andreas has offered to help me get up to speed with the Debian specifics, and this gives me much more confidence of being able to handle the maintainership. I should not expect that Andreas would need to do very much more than answer occasional emails from me in the early stages of my involvement; thereafter he can expect to be able to take a seat at the back if he so wishes. There are offers of help from several others in this thread (740070) too. Anyone who'd like to chip in will be very welcome, even if it's just installing the odd .deb now and again for testing; I'll be more than happy to act as a concentration/triage point. 73, Ged.
Bug#953545: linux-image-4.19: System unusably slow after Debian upgrade.
Package: linux-image Version: 4.19.0-8-amd64 Severity: critical Tags: patch Justification: breaks the whole system Dear Maintainer, Please see debian-bugs mailing list thread below, but please be aware that the threading of the messages could be improved upon. https://lists.debian.org/debian-user/2020/03/msg00338.html Briefly, after an upgrade from Jessie via Stretch to Buster the system (an old Intel E3815-based New Unit of Computing) became unusably slow. Command line operations were about ten times slower and GUI operations were hundreds of times slower. Until this upgrade, the system had performed flawlessly for some years. This system supports the administration office of a large working farm in England. The business, in addition to being a working farm, also supplies agricultural machinery, equipment, provisions and maintenance to farms in the English Midlands. After what I initially described to the office staff as an "upgrade" on grounds of security from Jessie to Buster, the staff began to call it a "downgrade" and refused to use it. As an emergency fix I moved the home directory from the broken machine to an old Jessie system which was running on another machine on site, and replaced the broken machine with that. This temporary situation stands at present. The issue seems to be solved by compiling a custom kernel. The kernel configuration which solves the problem is attached. In a crude test of performance (copying a file from disc to RAM using rsync) the 4.19 custom kernel outperforms the stock Jessie 3.16 kernel by about 50%, even though the Jessie kernels had seemed to be performing adequately for some years. Unfortunately the number of changes from the stock configuration is large; most of the changes will be irrelevant (such as the removal of modules which would never in any case be used on this system); and at the moment I do not have time to narrow down the problem further. Note that this seems to be a progressive issue. Kernel 4.19 is much slower than kernel 4.9, which is much slower than kernel 3.16, all running on the same Buster installation. I briefly tried a V5 kernel but in the very little time I had to spend on it I did not manage to get it to go beyond loading an initial ramdisc on Buster. Kernel 3.16 did at least boot the Buster system, but X would not run under 3.16 so it was not useful. -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Stock Buster Linux 4.19 (linux-image-4.19.0-8-amd64_4.19.98-1_amd64.deb) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.19.98 Kernel Configuration # # # Compiler: gcc (Debian 8.3.0-6) 8.3.0 # CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=80300 CONFIG_CLANG_VERSION=0 CONFIG_CC_HAS_ASM_GOTO=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="ff2" CONFIG_LOCALVERSION_AUTO=y CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="franderground-1" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set #
Bug#857304: Subject: iptables-persistent: netfilter-persistent save fails if run from cron because full paths are not given in scripts.
Package: iptables-persistent Severity: critical Tags: security patch ipv6 Justification: root security hole Dear Maintainer, * What led up to the situation? Running '/usr/sbin/netfilter-persistent save' from root's crontab. * What was the outcome of this action? A mail message from cron, explaining that 'iptables' could not be found. * What outcome did you expect instead? I expected a file to be written which contained the current iptables rules. Unfortunately the result of this error left the iptables ruleset empty on iptables-restore after a reboot today, hence the classification of this bug as a security issue. -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) This isn't the system on which I installed netfilter-persistent, but that's irrelevant - they're both up-to-date Debian Jessie on AMD. PATCH - the same is needed for 25-ip6tables --- 15-ip4tables~ 2016-01-02 21:18:13.0 + +++ 15-ip4tables2017-03-09 18:22:39.206872371 + @@ -20,7 +20,7 @@ if [ ! -f /etc/iptables/rules.v4 ]; then echo "Warning: skipping IPv4 (no rules to load)" else - iptables-restore < /etc/iptables/rules.v4 2> /dev/null + /sbin/iptables-restore < /etc/iptables/rules.v4 2> /dev/null if [ $? -ne 0 ]; then rc=1 fi @@ -37,7 +37,7 @@ elif [ -x /sbin/iptables-save ]; then touch /etc/iptables/rules.v4 chmod 0640 /etc/iptables/rules.v4 - iptables-save > /etc/iptables/rules.v4 + /sbin/iptables-save > /etc/iptables/rules.v4 if [ $? -ne 0 ]; then rc=1 fi
Bug#857301: Subject: iptables-persistent: netfilter-persistent save fails if run from cron because full paths are not given in scripts.
Package: iptables-persistent Severity: critical Tags: security patch ipv6 Justification: root security hole Dear Maintainer, * What led up to the situation? Running '/usr/sbin/netfilter-persistent save' from root's crontab. * What was the outcome of this action? A mail message from cron, explaining that 'iptables' could not be found. * What outcome did you expect instead? I expected a file to be written which contained the current iptables rules. Unfortunately the result of this error left the iptables ruleset empty on iptables-restore after a reboot today, hence the classification of this bug as a security issue. -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) This isn't the system on which I installed netfilter-persistent, but that's irrelevant - they're both up-to-date Debian Jessie on AMD. PATCH - the same is needed for 25-ip6tables --- 15-ip4tables~ 2016-01-02 21:18:13.0 + +++ 15-ip4tables2017-03-09 18:22:39.206872371 + @@ -20,7 +20,7 @@ if [ ! -f /etc/iptables/rules.v4 ]; then echo "Warning: skipping IPv4 (no rules to load)" else - iptables-restore < /etc/iptables/rules.v4 2> /dev/null + /sbin/iptables-restore < /etc/iptables/rules.v4 2> /dev/null if [ $? -ne 0 ]; then rc=1 fi @@ -37,7 +37,7 @@ elif [ -x /sbin/iptables-save ]; then touch /etc/iptables/rules.v4 chmod 0640 /etc/iptables/rules.v4 - iptables-save > /etc/iptables/rules.v4 + /sbin/iptables-save > /etc/iptables/rules.v4 if [ $? -ne 0 ]; then rc=1 fi
Bug#779384: Bug is serious.
Hi there, When I upgraded my laptop from Wheezy to Jessie the JME driver failed. When I was running Wheezy the Debian-supplied version did not work at all, leaving me with no Ethernet connection. So I would routinely replace the JME driver supplied by Debian with one from JMicron which I compiled myself. A week or so ago, when I upgraded to Jessie, the Debian-supplied driver again failed, but the driver which I have been using with Wheezy does not compile under Jessie's updated build system. It would be much easier to switch to a different distribution than to find out why it won't compile and fix it, so I trawled the 'net with the search engines and found this Ubuntu list post which describes a workaround: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/880316 This workaround is to reduce the speed at which the interface operates from 1Gbit/s to 100Mbit/s. Obviously to find this post I had to use a different a computer, since mine wasn't able to connect to the network. 'Upgrading' my laptop to Jessie felt like a definite downgrade as it prevented me from using my computer. So I'd call this bug SERIOUS. -- 73, Ged. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635691: Memory leak.
Confirmed that this fault is still present three years on. The app leaks huge quantities of memory even when it is not used. In this example it appears bad enough to use up all available swap (2GiB) in about a month and so kill the machine: http://www.jubileegroup.co.uk/JOS/misc/free_swap_graph_one_year.png The maintainer seems to have left the building: http://projecthamster.wordpress.com/2013/05/13/hamster-is-looking-for-a-new-maintainer/ Perhaps this package should be dropped from Debian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645713: apt: Could not perform immediate configuration on 'openjdk-6-jre'
Package: apt Version: 0.9.7.9+deb7u1 Followup-For: Bug #645713 Dear Maintainer, * What led up to the situation? apt-get dist-upgrade, Squeeze-Wheezy. * What exactly did you do (or not do) that was effective (or ineffective)? http://www.howtoforge.com/how-to-upgrade-debian-squeeze-to-wheezy Note in particular the part which calls for aptitude to declare that No packages are scheduled to be installed, removed or upgraded, which is exactly what it did. * What was the outcome of this action? win7host02:~# apt-get dist-upgrade [hours later] Get:1630 http://ftp.de.debian.org/debian/ wheezy/main xbrlapi amd64 4.4-10+deb7u1 [153 kB] Fetched 1,114 MB in 2h 23min 3s (130 kB/s) E: Could not perform immediate configuration on 'openjdk-6-jre'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) win7host02:~# * What outcome did you expect instead? In the output above I expected the line beginning with E: to be missing and a lot of other lines to exist - things like packages being replaced, configurations being bollixed, that kind of stuff. -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (/etc/apt/sources.list) -- # ftp.uk.debian.org failed big-time so I tried .de. deb http://ftp.de.debian.org/debian wheezy main contrib non-free deb http://ftp.de.debian.org/debian wheezy-updates main contrib non-free deb http://ftp.de.debian.org/debian-security wheezy/updates main contrib non-free -- System Information: I am reporting this bug on a system that still works. Obviously the System Information is no use to anyone because this is not the system which has just been broken by dist-upgrade. Please feel free to ask for more information, which I will provide as promptly as possible (under the circumstances). -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583200: cdrom: Installing on fourth disk of a four disk system overwrites MBR of first disk
Package: cdrom Followup-For: Bug #583200 Dear Maintainer, Using the Debian 7.0 AMD64 network install CDROM. Attempted to create a Debian Wheezy system on /dev/sdd of a system which already contains a Debian Squeeze installation on /dev/sda. Two other drives in the system. All are 3-Terabyte SATA drives which contain encrypted LVM2 partitions. No changes to Grub templates etc. from the defaults. Installation proceeded as expected on /dev/sdd right up to the point where it said it was installing grub onto the MBR of /dev/sda. I was too slow to reach the power switch before it had done it. :( I had hoped that (1) Unless otherwise directed, the MBR to be written will be the MBR of the drive on which the system is being installed. (2) If the MBR of any drive is to be overwritten, a backup of the original MBR would be made and would not overwrite any other MBR backup which might exist anywhere on the system. (3) If the MBR of any drive other than the install drive is to be overwritten, at least a prompt for confirmation will be issued. It took more than 24 hours to recover the trashed system. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692559: general: Information missing from man page for rcS
Hi there, On Thu, 8 Nov 2012, Roger Leigh wrote: On Wed, Nov 07, 2012 at 06:05:32PM +, G.W. Haywood wrote: logs as a time series and not one big pile of jumbled messages: [1.017969] nv_probe: set workaround bit for reversed mac addr [1.022092] SCSI subsystem initialized [1.027508] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.053243] libata version 3.00 loaded. [1.053355] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.066972] tg3.c:v3.116 (December 3, 2010) Please do note that the above messages are from kernel initialisation of modules. This happens either before init is started, or are triggered by udev, and by their nature will be run in parallel. This will take effect irrespective of the CONCURRENCY option Yes, of course. This was just an example of the non-deterministic mess that we have already. My point is that I'd prefer its getting worse to be optional. -- 73, Ged. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692559: general: Information missing from man page for rcS
Package: initscripts Severity: normal The man page for rcS is dated 16 January 2006. The parallel boot system added at least one option which is not mentioned in the rcS man page, 'CONCURRENCY'. This option is mentioned in for example http://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html but it takes a bit of finding (and, given the values found for the existing defaults, the value suggested there is implausible). -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692559: general: Information missing from man page for rcS
Hi there, On Wed, 7 Nov 2012, Roger Leigh wrote: On Wed, Nov 07, 2012 at 01:02:57PM +, G.W. Haywood wrote: ... The parallel boot system added at least one option which is not mentioned in the rcS man page, 'CONCURRENCY'. ... This is intentionally undocumented. In previous stable releases, concurrent boot was optional, and if you wanted to try out parallel boot, you had to enable it using CONCURRENCY. Correct. Nowadays, parallel startup using startpar is the default. Disabling this is not something which is useful ... Not correct. The option could well be removed entirely in future releases. This would be an inconvenience, at least to me. -- 73, Ged. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692559: general: Information missing from man page for rcS
Hi there, On Wed, 7 Nov 2012, Roger Leigh wrote: On Wed, Nov 07, 2012 at 04:25:51PM +, G.W. Haywood wrote: On Wed, 7 Nov 2012, Roger Leigh wrote: Nowadays, parallel startup using startpar is the default. Disabling this is not something which is useful ... Not correct. The option could well be removed entirely in future releases. This would be an inconvenience, at least to me. Regarding the above, it would be useful to have some concrete examples to explain why this is the case. The particular case which faces me at the moment may be faulty hardware, incorrect interrupt routing, conflicting interrupts or possibly none of the above. However it will aid greatly in discovering what is going on if I can (a) determine exactly what will happen when at boot time and (b) see debug output in the logs as a time series and not one big pile of jumbled messages: [1.017969] nv_probe: set workaround bit for reversed mac addr [1.022092] SCSI subsystem initialized [1.027508] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.053243] libata version 3.00 loaded. [1.053355] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.066972] tg3.c:v3.116 (December 3, 2010) -- 73, Ged. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516150: more information
Hi there, 2009/7/26 Moritz Muehlenhoff j...@inutil.org: On Thu, Feb 19, 2009 at 05:47:55PM +0100, Bastian Blank wrote: Please provide more information: - uname -a - the complete kernel log (dmesg) - cat /sys/devices/system/clocksource/clocksource0/* Dimitri, can you provide the mentioned information? Sorry, I missed one of the February messages... it must have gone into the spam trap. I sent the output of 'uname -a' here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515978#62 The system from which the information below was taken now appears to be working fine, as per my message http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515978#57 More info, in case it helps: - tornado:~$ date Sun Jul 26 22:01:29 BST 2009 - tornado:~$ uname -a Linux tornado 2.6.26-2-amd64 #1 SMP Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux - Output of dmesg is attached. - tornado:~$ cat /sys/devices/system/clocksource/clocksource0/* jiffies tsc tsc Please let me know if you need any other information. I'll keep a closer eye on the spam traps for a few days. :) -- 73, Ged.[0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.26-2-amd64 (Debian 2.6.26-15) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Mar 27 04:02:59 UTC 2009 [0.00] Command line: auto BOOT_IMAGE=Debian-2.6.26-2 ro root=fe01 irqfixup rootdelay=9 clock=tsc [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f000 (usable) [0.00] BIOS-e820: 0009f000 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - c000 (usable) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] BIOS-e820: 0001 - 0001c000 (usable) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 786432) 1 entries of 3200 used [0.00] Entering add_active_range(0, 1048576, 1835008) 2 entries of 3200 used [0.00] max_pfn_mapped = 1835008 [0.00] init_memory_mapping [0.00] DMI 2.3 present. [0.00] ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080321] [0.00] Scanning NUMA topology in Northbridge 24 [0.00] Number of nodes 2 [0.00] Node 0 MemBase Limit 0001c000 [0.00] Entering add_active_range(0, 0, 159) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 786432) 1 entries of 3200 used [0.00] Entering add_active_range(0, 1048576, 1835008) 2 entries of 3200 used [0.00] Skipping disabled node 1 [0.00] NUMA: Using 63 for the hash shift. [0.00] Using node hash shift of 63 [0.00] Intel MultiProcessor Specification v1.4 [0.00] MPTABLE: OEM ID: OEM0 Product ID: PROD 6MPTABLE: Product ID: PROD 6MPTABLE: APIC at: 0xFEE0 [0.00] Bootmem setup node 0 -0001c000 [0.00] NODE_DATA [0001 - 00014fff] [0.00] bootmap [00015000 - 0004cfff] pages 38 [0.00] early res: 0 [0-fff] BIOS data page [0.00] early res: 1 [6000-7fff] TRAMPOLINE [0.00] early res: 2 [20-673397] TEXT DATA BSS [0.00] early res: 3 [396-40ef05e] RAMDISK [0.00] early res: 4 [9f000-f] BIOS reserved [0.00] early res: 5 [8000-] PGTABLE [0.00] [e200-e200025f] PMD - [81000120-8100037f] on node 0 [0.00] [e2000260-e200061f] PMD - [81000420-810006ff] on node 0 [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1835008 [0.00] Movable zone start PFN for each node [0.00] early_node_map[3] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 786432 [0.00] 0: 1048576 - 1835008 [0.00] On node 0 totalpages: 1572767 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1249 pages reserved [0.00] DMA zone: 2694 pages, LIFO batch:0 [0.00] DMA32 zone: 14280 pages used for memmap [0.00] DMA32 zone: 768056 pages, LIFO batch:31 [0.00] Normal zone: 10752 pages used for memmap [0.00] Normal zone: 775680 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] Nvidia board detected. Ignoring ACPI timer override. [0.00] If you got timer trouble try acpi_use_timer_override [0.00] Intel MultiProcessor Specification v1.4 [
Bug#515978: traceroute giving false latencies for both icmp and udp
Hi all, This problem is a symptom of a library issue. The 'ping' utility has the a similar problem. Until upgrading from 'Etch' to 'Lenny' on AMD64 (dual Opteron) we had no problems with either. The system runs 'Smokeping' tp monitor our networks. Now it is basically useless. The results from gettimoefday() are incorrect. The values have a granularity of 4 milliseconds on our system, which I guess relates to the 250Hz timer tick. Unfortunately ping uses the gettimeofday() function to measure RTT in microseconds, and obviously this isn't going to work with a4ms granularity in the returned value. I can confirm that the problem is not in 'ping' itself, the same binary which works fine on an Athlon system fails in the same way on the Opteron. A simple 'C' program to print time increments by using the gettimeofday() function shows the same problems as ping. tornado:~$ ping lightning PING lightning.local.jubileegroup.co.uk (192.168.44.236) 56(84) bytes of data. 64 bytes from lightning.local (192.168.44.236): icmp_seq=1 ttl=64 time=4.00 ms 64 bytes from lightning.local (192.168.44.236): icmp_seq=2 ttl=64 time=0.000 ms 64 bytes from lightning.local (192.168.44.236): icmp_seq=3 ttl=64 time=0.000 ms 64 bytes from lightning.local (192.168.44.236): icmp_seq=4 ttl=64 time=0.000 ms ^C --- lightning.local.jubileegroup.co.uk ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3007ms rtt min/avg/max/mdev = 0.000/1.000/4.000/1.732 ms tornado:~$ ssh lightning Enter passphrase for key '/home/ged/.ssh/id_dsa': g...@lightning's password: Linux lightning 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Feb 18 20:01:38 2009 from laptop.local g...@lightning:~$ ping tornado PING tornado.local.jubileegroup.co.uk (192.168.44.47) 56(84) bytes of data. 64 bytes from tornado.local.jubileegroup.co.uk (192.168.44.47): icmp_seq=1 ttl=64 time=0.133 ms 64 bytes from tornado.local.jubileegroup.co.uk (192.168.44.47): icmp_seq=2 ttl=64 time=0.147 ms 64 bytes from tornado.local.jubileegroup.co.uk (192.168.44.47): icmp_seq=3 ttl=64 time=0.145 ms 64 bytes from tornado.local.jubileegroup.co.uk (192.168.44.47): icmp_seq=4 ttl=64 time=0.163 ms 64 bytes from tornado.local.jubileegroup.co.uk (192.168.44.47): icmp_seq=5 ttl=64 time=0.157 ms ^C --- tornado.local.jubileegroup.co.uk ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4014ms rtt min/avg/max/mdev = 0.133/0.149/0.163/0.010 ms -- 73, Ged. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515978: traceroute giving false latencies for both icmp and udp
Hello again, Apparently this issue has been around for quite a while. What a pity it hasn't been properly put to bed yet. https://bugzilla.redhat.com/show_bug.cgi?id=128428 For the time being I've added clock=tsc to my kernel boot command line as a workaround. This resolves my immediate 'ping' problem but I have no idea how many other worms are in the can, nor what they might look like. -- 73, Ged. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515978: traceroute giving false latencies for both icmp and udp
Hello again, On Thu, Feb 19, 2009 at 02:01:11PM +0100, Daniel Baumann wrote: reassign 515978 libc6 thanks G.W. Haywood wrote: This problem is a symptom of a library issue. The GNU libc simply calls the gettimeofday syscall, so it doesn't come from here, but must probably from the kernel. Given you are using a 2.6.26-1-486 kernel from Lenny I think that was somebody else. :) I guess you also upgraded the kernel in your upgrade. Correct, from Debian's 2.6.18-6 to 2.6.26-1 You are using a -486 kernel on an i686 machine. The -486 kernel doesn't use the high resolution timers, which may explain your problem. This is from the Debian distribution for the AMD64, so I'm using the amd64 kernel (not the OP's 486 kernel:). tornado:~$ uname -a Linux tornado 2.6.26-1-amd64 #1 SMP Sat Jan 10 17:57:00 UTC 2009 x86_64 GNU/Linux What was your previous kernel? 2.6.18-6-amd64. That was the latest stable kernel in 'Etch'. The system did not suffer from this problem when running 'Etch'. I have not attempted to run the 2.6.18-6 kernel on the machine now that it is running 'Lenny'. Incidentally this system uses lvm and encrypted volumes. The 'Lenny' install also built an incorrect initramfs and left the system in an unbootable state. I had to modify the scripts in scripts/local-top and rebuild the initramfs in order to boot it. If you can let me know where I should report the problem I'd be grateful. -- 73, Ged. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
