Bug#1022276: linux-image-6.0.0-1-amd64: Debian kernels since 5.19 drop Solarflare SFC9000 (SFN5xxx SFN6xxx) support.
Package: src:linux Version: 6.0.2-1+b1 Severity: normal Tags: patch X-Debbugs-Cc: t...@seoss.co.uk Firstly, thanks for the work on the Debian kernel packaging! Upstream kernel v5.19 incorporated a patch which split out Solarflare SFC9000 (NIC model SFN5000 and SFN6000 series) driver support from the main Solarflare driver. Debian stable currently supports these NICs, so this patch adds the necessary config entries to continue driver support for these NICs. These NICs are reasonably commonplace, with used models being frequently traded online (being a good value low-power-consumption 10GB Ethernet NIC), so I think reinstating support for these cards is the right thing to do. Upstream patch set which necessitates this patch: https://lore.kernel.org/netdev/165063937837.27138.6911229584057659609.st...@palantir17.mph.net/ Mainline kernel tree commit set circa c5a13c319e10e Thanks! Tim. --- debian/config/config | 9 + 1 file changed, 9 insertions(+) diff --git a/debian/config/config b/debian/config/config index cf17f586eaba..bfb897386cdc 100644 --- a/debian/config/config +++ b/debian/config/config @@ -3633,6 +3633,15 @@ CONFIG_SFC_MCDI_LOGGING=y CONFIG_SFC_FALCON=m CONFIG_SFC_FALCON_MTD=y +## +## file: drivers/net/ethernet/sfc/siena/Kconfig +## +CONFIG_SFC_SIENA=m +CONFIG_SFC_SIENA_MTD=y +CONFIG_SFC_SIENA_MCDI_MON=y +CONFIG_SFC_SIENA_SRIOV=y +CONFIG_SFC_SIENA_MCDI_LOGGING=y + ## ## file: drivers/net/ethernet/silan/Kconfig ## -- 2.30.2
Bug#779628: bcache: task bcache_writebac blocked for more than 240 seconds, system load high when module used
On 05/02/16 23:14, Ben Hutchings wrote: >> https://lkml.org/lkml/2015/12/30/331 >> >> It would be good to get this set into Stretch, and possibly a Jessie >> point release too (IIRC, it will apply cleanly to the Jessie kernel). > That whole patch series was included in 4.3.3-6, but I have yet to > apply them and the earlier fixes to the jessie branch. Great, thanks. If you do apply those to Jessie and you'd like some testing carried out, please let me know. Tim.
Bug#779628: bcache: task bcache_writebac blocked for more than 240 seconds, system load high when module used
Package: src:linux Version: 3.16.7-ckt20-1+deb8u3 Followup-For: Bug #779628 I think this patch fixes this issue: https://github.com/torvalds/linux/commit/627ccd20b4ad3ba836472468208e2ac4dfadbf03 It's included in this set which got merged in the 4.5 window. See this thread: https://lkml.org/lkml/2015/12/30/331 It would be good to get this set into Stretch, and possibly a Jessie point release too (IIRC, it will apply cleanly to the Jessie kernel). Tim.
Bug#702876: linux-image-2.6.32-5-openvz-amd64: OpenVZ 'vzctl start VEID --wait' hangs.
Package: linux-image-2.6.32-5-openvz-amd64 Version: 2.6.32-48squeeze1 Severity: normal Tags: When using the squeeze openvz kernel, the --wait feature of 'vzctl' seems to wait forever. Broken with: + Squeeze hardware node + Squeeze guests + vzctl 3.0.24 and also 3.0.30 + kernel 2.6.32-5-openvz-amd64 #1 SMP Mon Feb 25 01:16:25 UTC 2013 x86_64 GNU/Linux but works with: + As above, but using RHEL6 kernel from http://download.openvz.org/kernel/branches/rhel6-2.6.32/042stab074.10/vzkernel-2.6.32-042stab074.10.x86_64.rpm instead of the Debian kernel. I'm guessing that this is probably a won't fix at this stage in Squeeze, but thought I should flag it up to save time for anyone else chasing this bug. Tim. -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-2.6.32-5-openvz-amd64 depends on: ii debconf [debconf 1.5.36.1Debian configuration management sy ii initramfs-tools 0.98.8 tools for generating an initramfs ii linux-base 2.6.34-1~experimental.2 Linux image base package ii module-init-tool 3.12-2 tools for managing Linux kernel mo ii vzctl3.0.24-12 server virtualization solution - c Versions of packages linux-image-2.6.32-5-openvz-amd64 recommends: ii firmware-linux-free2.6.32-48squeeze1 Binary firmware for various driver Versions of packages linux-image-2.6.32-5-openvz-amd64 suggests: pn grub | lilo none (no description available) pn linux-doc-2.6.32 none (no description available) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130312123623.4279.43109.report...@ermintrude.seoss.co.uk
Bug#655385: [squeeze openvz] Cannot allocate memory when doing cat, /proc/self/mountinfo inside a vm
Hmm, I just re-read http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#deprecated and it says Debian GNU/Linux 6.0 will be the last release to include Linux kernel virtualization featuresets outside of mainline. This means that the OpenVZ and Linux-Vserver featuresets should be considered deprecated OK, that's fair enough, but it doesn't say and support will be dropped about a year after Squeeze is released, but before wheezy is ready, unless there's some fine-print I'm missing somewhere... Doesn't that look like dropping Debian+OpenVZ users in it a bit? Suddenly they have to switch to a non-Debian kernel (or otherwise a completely different virtualisation technology) half way through a stable release with no notice, and then manually track security updates outside of the Debian security infrastructure etc.? Is LXC considered to be a practical OpenVZ replacement by now? It doesn't really seem to be getting much attention, and I can't say I know anyone who's using it... Tim. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4feee1d7.6030...@seoss.co.uk
Bug#584881: Lockups under heavy disk IO; md (RAID) resync/check implicated
FWIW, I was only able to reproduce the problem which I was seeing on lenny+openvz (running the same workload on lenny+chroot, or squeeze+openvz didn't trigger it). The fix you attached does sound like a plausible fix for the issue I was seeing (having spent a day or two peering at the code and sprinkling printks all over it, but not ultimately getting anywhere), but I don't think I still have my test environment archived anywhere. If I remember correctly, things always ended up deadlocking with 1 request sitting in md's queue. Tim. -- South East Open Source Solutions Limited Registered in England and Wales with company number 06134732. Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7988e6.3060...@seoss.co.uk
Bug#604469: Update check
On 20/06/11 06:19, Ola Lundqvist wrote: I would like you to check if the issue you reported in 604469 is solved in the squeeze release. Well, I can't say for certain, but I couldn't reproduce the issue using the squeeze kernel. Tim. -- South East Open Source Solutions Limited Registered in England and Wales with company number 06134732. Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dff1823.4080...@seoss.co.uk
Bug#604469: linux-image-2.6.26-2-openvz-amd64: openvz - deadlock during RAID rebuild with container backing store on LVM+snapshot
Package: linux-image-2.6.26-2-openvz-amd64 Version: 2.6.26-25lenny1 Severity: normal On Lenny, I have observed the following behaviour: An I/O deadlock occurs under the following conditions: . OpenVZ container data stored on an LVM for which the PV is an md RAID1 . RAID1 md undergoing a rebuild or check . An LVM snapshot is active for the logical volume (in order to take a backup) . I/O occurs within the container The RAID resync then stops, as does all other I/O to the filesystem which is mounted upon the LVM. Adding various debug to the md raid1 driver shows that when the system gets to this state, there are a number of bio requests which are still pending (or at least their callback never gets executed). http://marc.info/?t=12847354111r=1w=2 Adding the debug printks and atomic counters appears to make the deadlock occur more readily (within seconds rather than minutes of starting the openvz container). My guess was that this is some sort of a priority inversion deadlock, I/O in the container is triggering I/O outside of the container (via LVM snapshot) which must complete first (because of the OpenVZ scheduling rules or otherwise), and possibly the md barrier code is enforcing the opposite ordering. .. but when I tried: echo 0 /sys/block/sda/queue/iosched/virt_mode echo 0 /sys/block/sdb/queue/iosched/virt_mode prior to starting the container, didn't seem to change things. So maybe that's not the problem. Simply using the container private directory as a chroot, and placing reasonably heavy I/O load does not seem to cause the same deadlock to occur. I haven't seen the deadlock occur on 2.6.32, but haven't tried to insert the same debugging statements. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-2.6.26-2-openvz-amd64 depends on: ii debconf [debconf-2.0] 1.5.36 Debian configuration management sy ii initramfs-tools [linux-initra 0.98.5 tools for generating an initramfs ii module-init-tools 3.12-1 tools for managing Linux kernel mo ii vzctl 3.0.24-10 server virtualization solution - c linux-image-2.6.26-2-openvz-amd64 recommends no packages. Versions of packages linux-image-2.6.26-2-openvz-amd64 suggests: pn grub | lilo none (no description available) pn linux-doc-2.6.26 none (no description available) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101122131743.2836.76269.report...@ermintrude.seoss.co.uk
Bug#603903: Documentation for modules=list in initramfs.conf is unclear
Package: initramfs-tools Version: 0.98.5 Severity: normal How's this? --- initramfs.conf.5.orig 2010-11-18 10:08:00.093469868 + +++ initramfs.conf.52010-11-22 16:47:45.692926195 + @@ -22,16 +22,24 @@ .TP \fB MODULES Specifies the modules for the initramfs image. -The default setting is \fImost\fP. + +Modules listed in \fI/etc/initramfs-tools/modules\fP and +\fI/usr/share/initramfs-tools/modules.d/*\fP are always included in the +initramfs, and are loaded early in the boot process. + + +\fIlist\fP doesn't load any additional modules at boot time, other than those +listed in the above files. \fImost\fP adds most file system, all ide, sata, scsi and usb drivers. -\fIdep\fP tries to guess which modules are necessary for the running box. +\fIdep\fP tries to guess which modules are necessary for the running box and +adds those modules. + +\fInetboot\fP adds the base and network modules, but skips block devices. -\fInetboot\fP adds the base modules, network modules, but skips block devices. -\fIlist\fP includes only modules from the additional modules list to load them -early. +The default setting is \fImost\fP. .TP \fB BUSYBOX -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101122165505.11412.47176.report...@ermintrude.seoss.co.uk
Bug#603903: initramfs-tools: Documentation for modules=list in initramfs.conf is unclear
Package: initramfs-tools Version: 0.98.5 Severity: normal Tags: patch The documentation is vague about how the list of modules is derived. Hopefully this makes things clearer without requiring the user to delve into the source code Cheers, Tim. --- /tmp/initramfs.conf.orig2010-11-18 10:12:43.176859335 + +++ /tmp/initramfs.conf 2010-11-18 10:26:11.172917839 + @@ -8,13 +8,16 @@ # # MODULES: [ most | netboot | dep | list ] # +# Modules listed in /etc/initramfs-tools/modules and +# /usr/share/initramfs-tools/modules.d/* are always loaded. +# # most - Add most filesystem and all harddrive drivers. # # dep - Try and guess which modules to load. # # netboot - Add the base modules, network modules, but skip block devices. # -# list - Only include modules from the 'additional modules' list +# list - Only modules explicity listed in /etc/initramfs-tools/modules etc. # MODULES=most --- /tmp/initramfs.conf.5.orig 2010-11-18 10:08:00.093469868 + +++ /tmp/initramfs.conf.5 2010-11-18 10:27:48.585080195 + @@ -22,6 +22,10 @@ .TP \fB MODULES Specifies the modules for the initramfs image. + +Modules listed in \fI/etc/initramfs-tools/modules\fP and +\fI/usr/share/initramfs-tools/modules.d/*\fP are always loaded. + The default setting is \fImost\fP. \fImost\fP adds most file system, all ide, sata, scsi and usb drivers. @@ -30,8 +34,8 @@ \fInetboot\fP adds the base modules, network modules, but skips block devices. -\fIlist\fP includes only modules from the additional modules list to load them -early. +\fIlist\fP don't load any additional modules beyond those contained in +\fI/etc/initramfs-tools/modules\fP etc. .TP \fB BUSYBOX -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118102935.13178.52075.report...@ermintrude.seoss.co.uk
Bug#600299: Openvz kernels appear to log unitialised memory to the console with log_buf_len=XX
Package: linux-2.6
Version: 2.6.32-23
Severity: normal
Thanks, tested and confirmed working against svn sid (686), and svn
lenny (amd64) and applies cleanly to both.
Tested-By: t...@seoss.co.uk
Would you like me to check upstream OpenVZ, and open a bug in their
tracker if relevant?
BTW, I fixed up the test-patches script so that it works for patches
like the one you supplied (i.e. patches which need to be applied only
when a particular featureset is being built). HTH.
Cheers,
Tim.
Index: debian/bin/test-patches
===
--- debian/bin/test-patches (revision 16455)
+++ debian/bin/test-patches (working copy)
@@ -19,12 +19,15 @@
featureset=none
fi
-eval set -- $(getopt -n $0 -- f:j:s: $@)
+restrictfeature=
+
+eval set -- $(getopt -n $0 -- f:j:s:r: $@)
while true; do
case $1 in
-f) flavour=$2; shift 2 ;;
-j) export DEBIAN_KERNEL_JOBS=$2; shift 2 ;;
-s) featureset=$2; shift 2 ;;
+ -r) restrictfeature= featureset=$2; shift 2 ;;
--) shift 1; break ;;
esac
done
@@ -36,6 +39,8 @@
-f flavour specify the 'flavour' of kernel to build, e.g. 686
-j jobsspecify number of compiler jobs to run in parallel
-s featureset specify an optional featureset to apply, e.g. xen
+ -r featureset specify that the patch should only apply to a given
+ featureset
EOF
exit 2
fi
@@ -56,6 +61,15 @@
fi
debversion=${version##*-}
+echo X $debversion
+
+if [ $restrictfeature != ]; then
+#debversion=${debversion%a~test}-extraa~test
+debversion=${debversion}-extra
+fi
+
+echo XX $debversion
+
# Copy all patches into a new directory
rm -rf debian/patches/test/
mkdir debian/patches/test
@@ -64,7 +78,8 @@
# Generate patch series for the new version
debian/patches/series/$debversion
for patch in $@; do
-echo + test/$(basename $patch) debian/patches/series/$debversion
+echo echo + test/$(basename $patch)${restrictfeature} TO
debian/patches/series/$debversion
+echo + test/$(basename $patch)${restrictfeature}
debian/patches/series/$debversion
done
# Regenerate control and included rules
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20101018183359.17419.18014.report...@ermintrude.seoss.co.uk
Bug#600299: Openvz kernels appear to log unitialised memory to the console with log_buf_len=XX
Package: linux-2.6
Version: 2.6.32-23
Severity: normal
Hmm, forgot to regen the patch - sorry about that :-(
Index: debian/bin/test-patches
===
--- debian/bin/test-patches (revision 16455)
+++ debian/bin/test-patches (working copy)
@@ -19,12 +19,15 @@
featureset=none
fi
-eval set -- $(getopt -n $0 -- f:j:s: $@)
+restrictfeature=
+
+eval set -- $(getopt -n $0 -- f:j:s:r: $@)
while true; do
case $1 in
-f) flavour=$2; shift 2 ;;
-j) export DEBIAN_KERNEL_JOBS=$2; shift 2 ;;
-s) featureset=$2; shift 2 ;;
+ -r) restrictfeature= featureset=$2; shift 2 ;;
--) shift 1; break ;;
esac
done
@@ -36,6 +39,8 @@
-f flavour specify the 'flavour' of kernel to build, e.g. 686
-j jobsspecify number of compiler jobs to run in parallel
-s featureset specify an optional featureset to apply, e.g. xen
+ -r featureset specify that the patch should only apply to a given
+ featureset
EOF
exit 2
fi
@@ -56,6 +61,10 @@
fi
debversion=${version##*-}
+if [ $restrictfeature != ]; then
+debversion=${debversion}-extra
+fi
+
# Copy all patches into a new directory
rm -rf debian/patches/test/
mkdir debian/patches/test
@@ -64,7 +73,7 @@
# Generate patch series for the new version
debian/patches/series/$debversion
for patch in $@; do
-echo + test/$(basename $patch) debian/patches/series/$debversion
+echo + test/$(basename $patch)${restrictfeature}
debian/patches/series/$debversion
done
# Regenerate control and included rules
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20101018185150.23988.29744.report...@ermintrude.seoss.co.uk
Bug#600299: linux-image-2.6.32-5-openvz-amd64: Openvz kernels appear to log unitialised memory to the console with log_buf_len=XX
Package: linux-2.6 Version: 2.6.32-23 Severity: normal When passing log_buf_len=2M to the kernel, the kernel logs nulls, or other aparently unitialised RAM to the console, and netconsole. Checked on: lenny 2.6.26-openvz amd64 (Dell PE300) lenny 2.6.32-openvz-bp amd64 (Dell PE300) squeeze 2.6.32-openvz i386 (under kvm) Make debugging other kernel issues difficult :-( -- Package-specific info: ** Version: Linux version 2.6.32-5-openvz-amd64 (Debian 2.6.32-23) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-3) ) #1 SMP Fri Sep 17 21:53:51 UTC 2010 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101015170058.12552.87843.report...@ermintrude.seoss.co.uk
Bug#598633: linux-image-2.6.32-5-amd64: /proc/sys/dev/raid/speed_limit_max defaults to 200000 without apparent reason
On 30/09/10 18:43, Bastian Blank wrote: On Thu, Sep 30, 2010 at 05:14:44PM +0100, Tim Small wrote: /proc/sys/dev/raid/speed_limit_max defaults to 20 - unnecessarily limiting software RAID performance, I can't see a reason for this limit which seems a bit arbitrary Please explain. This limits the bandwidth allocated for for rebuild and check. Sorry for the terse report. On machines which are readily purchasable, this default will unnecessarily cap the rebuild and check speeds for md RAID arrays. e.g. a 4 drive RAID10 made with 7200rpm SATA drives is likely to exceed this cap with an unlimited rebuild/check speed of 24 or so, as would a RAID1 with two ~100 usd SSDs. During the lifetime of squeeze, this limit is likely to be hit more and more frequently... AFAIK it has defaulted to 20 for ages, it's only now that commonly available hardware is starting to hit this limit. Tim. -- South East Open Source Solutions Limited Registered in England and Wales with company number 06134732. Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cadbb50.1030...@seoss.co.uk
Bug#598633: linux-image-2.6.32-5-amd64: /proc/sys/dev/raid/speed_limit_max defaults to 200000 without apparent reason
Package: linux-2.6 Version: 2.6.32-23 Severity: normal /proc/sys/dev/raid/speed_limit_max defaults to 20 - unnecessarily limiting software RAID performance, I can't see a reason for this limit which seems a bit arbitrary -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100930161444.21472.50935.report...@ermintrude.seoss.co.uk
Bug#598103: linux-image-2.6.32-5-openvz-amd64: Kernel warning when mii-tool called on downed interface (3c905C)
Package: linux-2.6 Version: 2.6.32-23 Severity: normal I have this in: pre-up /sbin/mii-tool ethInet -F 10baseT-FD /etc/network/interfaces, on boot I get: [8.958841] [ cut here ] [8.960858] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_amd64_openvz/kernel/softirq.c:145 _local_bh_enable_ip+0x41/0x8f() [8.963057] Hardware name: Studio XPS 8100 [8.965145] Modules linked in: bridge stp ext3 jbd ext2 coretemp loop dm_crypt snd_hda_codec_intelhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_ oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event gspca_zc3xx gspca_main snd_seq radeon videodev v4l1_compat ttm snd_timer v4l2_compat_ioctl32 snd_seq_device drm_kms_helper joydev dc dbas pcspkr i2c_i801 snd evdev drm psmouse i2c_algo_bit serio_raw soundcore snd_page_alloc i2c_core button processor ext4 mbcache jbd2 crc16 raid1 md_mod dm_mirror dm_region_hash dm_log dm _mod btrfs zlib_deflate crc32c libcrc32c sg sr_mod sd_mod cdrom crc_t10dif hid_microsoft usb_storage usbhid hid ahci broadcom libata tg3 firewire_ohci libphy scsi_mod firewire_core crc_itu _t ehci_hcd 3c59x mii thermal usbcore thermal_sys nls_base [last unloaded: scsi_wait_scan] [8.974905] Pid: 1548, comm: mii-tool Not tainted 2.6.32-5-openvz-amd64 #1 [8.977363] Call Trace: [8.979924] [8105303b] ? _local_bh_enable_ip+0x41/0x8f [8.982398] [8105303b] ? _local_bh_enable_ip+0x41/0x8f [8.984828] [8104ce60] ? warn_slowpath_common+0x77/0xa3 [8.987235] [8105303b] ? _local_bh_enable_ip+0x41/0x8f [8.989641] [a004f663] ? mdio_read+0x113/0x12e [3c59x] [8.992037] [a00494c6] ? generic_mii_ioctl+0x65/0x101 [mii] [8.994548] [a0051fa5] ? vortex_ioctl+0x76/0xbe [3c59x] [8.996896] [8123be5d] ? dev_ioctl+0x51b/0x64e [8.999262] [8122a278] ? sock_ioctl+0x208/0x216 [9.001628] [810fb59a] ? vfs_ioctl+0x21/0x6c [9.003999] [810fbae8] ? do_vfs_ioctl+0x48d/0x4cb [9.006343] [812ea215] ? do_page_fault+0x2e0/0x2fc [9.008691] [810fbb63] ? sys_ioctl+0x3d/0x5c [9.011197] [81010c12] ? system_call_fastpath+0x16/0x1b [9.013565] ---[ end trace 71a5e52c46c0aee2 ]--- [9.024793] ethInet: setting full-duplex. -- Package-specific info: ** Version: Linux version 2.6.32-5-openvz-amd64 (Debian 2.6.32-23) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-3) ) #1 SMP Fri Sep 17 21:53:51 UTC 2010 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-openvz-amd64 root=LABEL=root ro console=tty0 ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 2243.515088] usb 2-1.5: New USB device found, idVendor=413c, idProduct=3012 [ 2243.515092] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2243.515096] usb 2-1.5: Product: Dell USB Optical Mouse [ 2243.515099] usb 2-1.5: Manufacturer: Dell [ 2243.515170] usb 2-1.5: configuration #1 chosen from 1 choice [ 2243.517653] input: Dell Dell USB Optical Mouse as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/input/input8 [ 2243.517708] generic-usb 0003:413C:3012.0004: input,hidraw0: USB HID v1.11 Mouse [Dell Dell USB Optical Mouse] on usb-:00:1d.0-1.5/input0 [ 2275.232709] tg3 :04:00.0: irq 35 for MSI/MSI-X [ 2275.254709] ADDRCONF(NETDEV_UP): ethLAN: link is not ready [ 2275.916482] tg3: ethLAN: Link is down. [ 2278.911202] tg3: ethLAN: Link is up at 1000 Mbps, full duplex. [ 2278.911206] tg3: ethLAN: Flow control is off for TX and off for RX. [ 2278.911548] ADDRCONF(NETDEV_CHANGE): ethLAN: link becomes ready [ 2282.116818] device ethLAN entered promiscuous mode [ 2282.116857] brint: port 1(ethLAN) entering learning state [ 2284.113858] brint: port 1(ethLAN) entering forwarding state [ 2289.132745] ethLAN: no IPv6 routers present [ 2372.749321] tg3: ethLAN: Link is down. [ 2372.764666] brint: port 1(ethLAN) entering disabled state [ 2374.745942] tg3: ethLAN: Link is up at 10 Mbps, full duplex. [ 2374.745945] tg3: ethLAN: Flow control is on for TX and on for RX. [ 2374.746293] brint: port 1(ethLAN) entering learning state [ 2376.741417] brint: port 1(ethLAN) entering forwarding state [ 2384.728591] tg3: ethLAN: Link is down. [ 2384.759854] brint: port 1(ethLAN) entering disabled state [ 2385.726717] tg3: ethLAN: Link is up at 1000 Mbps, full duplex. [ 2385.726720] tg3: ethLAN: Flow control is on for TX and on for RX. [ 2385.727092] brint: port 1(ethLAN) entering learning state [ 2387.722368] brint: port 1(ethLAN) entering forwarding state [ 2403.695598] tg3: ethLAN: Link is down. [ 2403.714949] brint: port 1(ethLAN) entering disabled state [ 2406.690309] tg3: ethLAN: Link is up at 1000 Mbps, full duplex. [ 2406.690314] tg3: ethLAN: Flow control is on for TX and on for RX. [ 2406.690872] brint: port 1(ethLAN) entering learning state [ 2408.685254] brint: port 1(ethLAN) entering forwarding state [ 2494.537210] tg3: ethLAN: Link
Bug#584881: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
Hi, I recently posted the below message to linux-raid, but perhaps it should have gone here first... Perhaps Neil Brown will have some bright ideas. Common factors on all three pieces of hardware seeing the problem seem to have been: Lenny 2.6.26 kernel Serial console md with lvm snapshots Dell hardware 4 or more cores HTH, Tim. Hi, I have a box with a relatively simple setup: sda + sdb are 1TB SATA drives attached to an Intel ICH10. Three partitions on each drive, three md raid1s built on top of these: md0 / md1 swap md2 LVM PV During resync about a week ago, processes seemed to deadlock on I/O, the machine was still alive but with a load of 100+. A USB drive happened to be mounted, so I managed to save /var/log/kern.log At the time of the problem, the monthly RAID check was in progress. On reboot, a rebuild commenced, and the same deadlock seemed to occur between roughly 2 minutes and 15 minutes after boot. At this point, the server was running on a Dell PE R300 (12G RAM, quad-core), with an LSI SAS controller and 2x 500G SATA drives. I shifted all the data onto a spare box (Dell PE R210, ICH10R, 1x1TB drive, 8G RAM, quad-core+HT), with only a single drive, so I created the md RAID1s with just a single drive in each. The original box was put offline with the idea of me debugging it soon. This morning, I added in a second 1TB drive, and during the resync (approx 1 hour in), the deadlock up occurred again. The resync had stopped, and any attempt to write to md2 would deadlock the process in question. I think it was doing an rsnaphot backup to a USB drive at the time the initial problem occurred - this creates an LVM snapshot device on top of md2 for the duration of the backup for each filesystem backed up (there are two at the moment), and I suppose this results in lots of read-copy-update operations - the mounting of the snapshots shows up in the logs as the fs-mounts, and subsequent orphan_cleanups. As the snapshot survives the reboot, I assume this is what triggers the subsequent lockup after the machine has rebooted. I got a couple of 'echo w /proc/sysrq-trigger' sets of output this time... Edited copies of kern.log are attached - looks like it's barrier related. I'd guess the combination of the LVM CoW snapshot, and the RAID resync are tickling this bug. Any thoughts? Maybe this is related to Debian bug #584881 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584881 ... since the kernel is essentially the same. I can do some debugging on this out-of-office-hours, or can probably resurrect the original hardware to debug that too. Logs are here: http://buttersideup.com/files/md-raid1-lockup-lvm-snapshot/ I think vger binned the first version of this email (with the logs attached) - so apologies if you've ended up with two copies of this email... Tim. -- South East Open Source Solutions Limited Registered in England and Wales with company number 06134732. Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9394dd.80...@seoss.co.uk
Bug#591415: linux-image-2.6.32-5-amd64: md software raid raid10 deadlocks
Package: linux-2.6 Version: 2.6.32-15 Severity: normal Tags: upstream squeeze patch Just a heads-up, this appears to be an upstream bug which can trigger deadlocks in raid10 under heavy load on 2.6.32+. I haven't verified that the relevant code is in the squeeze kernel, but from the look of the other reports, it probably is... Relevant upstream mailing list postings: http://marc.info/?l=linux-raidm=128078147925156w=2 http://marc.info/?l=linux-raidm=128071814629356w=2 Cheerio, Tim. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100802212716.3816.55070.report...@ermintrude.seoss.co.uk
Bug#581392: linux-image-2.6.26-2-amd64: A couple of RAID4/RAID6 fixes from upstream.
Package: linux-2.6 Version: 2.6.26-21lenny4 Severity: normal Tags: patch -- Package-specific info: ** Version: Linux version 2.6.26-2-amd64 (Debian 2.6.26-21lenny4) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Tue Mar 9 22:29:32 UTC 2010 Here are a couple of md software RAID fixes from upstream: 1. Would attempt a RAID4 reshape on an array with insufficient devices - bit of a corner case as not many people use RAID4, but still. 2. Would fail to attempt to scrub an unreadable sector on a singly-degraded RAID6 (would drop to a doubly-degraded array instead). This is reasonably likely to be hit on large arrays, and leads to loss of redundancy (the larger the array, the more likely this is to result in end-user data-loss). Both are in Linus-git... Thanks, Tim. *** raid6-degraded-scrub-raid4-reshape-lenny.patch --- /e2/lenny-amd64/root/build/linux-2.6-2.6.26/drivers/md/raid5.c 2008-07-13 22:51:29.0 +0100 +++ drivers/md/raid5.c 2010-05-12 16:33:09.0 +0100 @@ -1163,7 +1163,7 @@ clear_bit(R5_UPTODATE, sh-dev[i].flags); atomic_inc(rdev-read_errors); - if (conf-mddev-degraded) + if (conf-mddev-degraded = conf-max_degraded) printk_rl(KERN_WARNING raid5:%s: read error not correctable (sector %llu on %s).\n, @@ -4202,7 +4202,7 @@ */ sector_t here_new, here_old; int old_disks; - int max_degraded = (mddev-level == 5 ? 1 : 2); + int max_degraded = (mddev-level == 6 ? 2 : 1); if (mddev-new_level != mddev-level || mddev-new_layout != mddev-layout || -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100512154512.30554.39353.report...@zebedee.config
Bug#581001: linux-image-2.6.26-2-amd64: Broadcom 5709 lockup with message-signalled-interrupts
Package: linux-2.6 Version: 2.6.26-21lenny4 Severity: normal Tags: patch Hi, We've seen what I suspect was this problem under Lenny on one box. Fix is upstream, and also in RHEL5 now... http://bugs.centos.org/view.php?id=3832 https://rhn.redhat.com/errata/RHSA-2010-0398.html http://marc.info/?l=linux-netdevm=127240304211909w=2 Cheers, Tim. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100510141920.27466.25570.report...@zebedee.config
Bug#565353: Info received (Bug#565353: Offer of testing)
Transferred about a terabyte over NFS over 3 days whilst under disk/CPU load - with no apparent problems, thanks. Tim. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565353: Offer of testing
You can build a package from svn with the following commands: Thanks for the instructions, but I'd just about managed to find the svn, and cobble together something similar a few hours before your email to get some 2.6.26-22 packages built. Seems good so-far - I'm leaving the machine doing some tests over the weekend - a couple of continuous find | xargs cat /dev/null on NFS shares, whilst under additional disk and CPU load... Will let you know on Monday a.m. GMT. Tim. -- South East Open Source Solutions Limited Registered in England and Wales with company number 06134732. Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566295: initramfs-tools: Deviation from Documentation/filesystems/nfs/nfsroot.txt WRT multiple net devs
Package: initramfs-tools Version: 0.93.4 Severity: normal Tags: patch /usr/share/initramfs-tools/scripts/functions attempts to follow the semantics described in Documentation/filesystems/nfs/nfsroot.txt with respect to IP autoconfiguration, however a significant departure from the behaviour is that nfsroot.txt says: device Name of network device to use. Default: If the host only has one device, it is used. Otherwise the device is determined using autoconfiguration. This is done by sending autoconfiguration requests out of all devices, and using the device that received the first reply. initramfs-tools currently requires a device to be hard-coded, but this is not much use if the network device is not known ahead of time. If the device specified in either /etc/initramfs-tools/initramfs.conf or on the ip=xxx kernel command line. Moreover a combination of the kernel commandline and the contents of /etc/initramfs-tools/initramfs.conf is currently used which can be misleading. With the attached patch, it is possible to specify either: DEVICE=all or DEVICE= in the /etc/initramfs-tools/initramfs.conf The patch is against lenny, I've not had a chance to test it on sid but it looks like it should apply (modulo the change of the relevant env variable). Many Thanks, Tim. -- Package-specific info: -- /proc/cmdline root=/dev/md0 ro console=tty0 -- /proc/filesystems ext3 vfat fuseblk -- lsmod Module Size Used by ftdi_sio 57736 0 pl2303 21508 0 ark311616004 0 usbserial 36592 3 ftdi_sio,pl2303,ark3116 dm_hp_sw7168 0 dm_multipath 21392 1 dm_hp_sw dm_mirror 20608 0 dm_log 13956 1 dm_mirror battery16904 0 usbhid 45920 0 hid41792 1 usbhid ff_memless 9224 1 usbhid fuse 54176 1 enclosure 13632 0 ipt_REDIRECT6272 1 nls_utf86272 0 nls_cp437 11136 0 vfat 14976 0 fat51128 1 vfat nls_base 12932 4 nls_utf8,nls_cp437,vfat,fat radeon133920 2 drm91360 3 radeon vzethdev 14720 0 vznetdev 24456 1 simfs 8944 1 vzrst 122920 0 vzcpt 106424 0 tun15492 2 vzrst,vzcpt vzdquota 42740 1 [permanent] vzmon 31376 5 vzethdev,vznetdev,vzrst,vzcpt vzdev 7568 4 vzethdev,vznetdev,vzdquota,vzmon xt_length 6400 0 ipt_ttl 6144 0 xt_tcpmss 6656 0 xt_dscp 7168 0 iTCO_wdt 15696 1 authenc 9984 2 esp4 10880 2 aead 11904 2 authenc,esp4 xfrm4_mode_tunnel 6912 4 deflate 7424 0 zlib_deflate 24088 1 deflate zlib_inflate 18944 1 deflate ctr 8832 0 twofish11136 0 twofish_common 18560 1 twofish camellia 25216 0 serpent23296 0 blowfish 13056 0 des_generic21376 0 cbc 7936 2 aes_x86_64 12416 2 aes_generic32552 1 aes_x86_64 xcbc8968 0 sha256_generic 13696 0 sha1_generic6912 0 crypto_null 7680 2 af_key 32280 0 xt_tcpudp 7680 88 xt_DSCP 7808 34 ipt_MASQUERADE 6528 2 iptable_nat11652 1 nf_nat_ftp 7296 0 nf_nat 22548 4 ipt_REDIRECT,ipt_MASQUERADE,iptable_nat,nf_nat_ftp xt_TCPMSS 8576 3 ipt_LOG10372 46 ipt_REJECT 7552 0 iptable_mangle 8704 1 iptable_filter 8320 1 xt_multiport7424 0 xt_state6656 13 xt_limit7172 50 xt_conntrack8704 0 nf_conntrack_ftp 12728 1 nf_nat_ftp nf_conntrack_ipv4 24352 16 iptable_nat,nf_nat nf_conntrack 82688 7 iptable_nat,nf_nat_ftp,nf_nat,xt_state,xt_conntrack,nf_conntrack_ftp,nf_conntrack_ipv4 ip_tables 21776 3 iptable_nat,iptable_mangle,iptable_filter x_tables 25736 17 ipt_REDIRECT,xt_length,ipt_ttl,xt_tcpmss,xt_dscp,xt_tcpudp,xt_DSCP,ipt_MASQUERADE,iptable_nat,xt_TCPMSS,ipt_LOG,ipt_REJECT,xt_multiport,xt_state,xt_limit,xt_conntrack,ip_tables nfs 252336 1 lockd 70448 1 nfs nfs_acl 7552 1 nfs sunrpc202216 11 nfs,lockd,nfs_acl ipv6 296256 79 vzrst,vzcpt,vzmon bridge 54952 0 loop 64148 0 dm_crypt 17032 0
Bug#541715: linux-image-2.6-openvz-amd64: Can't set io scheduling class from within a VE.
Package: linux-image-2.6-openvz-amd64 Version: 2.6.26+17+lenny1 Severity: normal It is impossible to set the io scheduling class of a process from within a VE: eris:~# ionice -c 3 /bin/bash ioprio_set: Operation not permitted ... it should be possible to drop the priority of tasks with in a VE - as in the example above. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6-openvz-amd64 depends on: ii linux-image-2.6.26-2-ope 2.6.26-17lenny1 Linux 2.6.26 image on AMD64, OpenV linux-image-2.6-openvz-amd64 recommends no packages. linux-image-2.6-openvz-amd64 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#383486: PATCH to /usr/share/initramfs-tools/hook-functions
--- /usr/share/initramfs-tools/hook-functions.orig2006-08-18 13:21:56.0 +0100 +++ /usr/share/initramfs-tools/hook-functions2006-08-18 13:19:46.0 +0100 @@ -169,7 +169,7 @@ scsi) for x in 3w-9xxx 3w- a100u2x aacraid advansys ahci \ aic79xx aic7xxx arcmsr ata_piix atari_scsi atp870u BusLogic \ -cciss ch cpqarray dac960 dc395x dmx3191d dpt_i2o eata fdomain \ +cciss ch cpqarray DAC960 dc395x dmx3191d dpt_i2o eata fdomain \ gdth hptiop ibmvscsic initio ipr ips isp1020 lpfc max_scsi \ mac53c94 megaraid megaraid_mbox megaraid_mm mesh mptfc \ mptscsih mptsas mptspi nsp32 osst qla1280 qla2100 qla2200 \ --- /usr/share/initramfs-tools/hook-functions.orig 2006-08-18 13:21:56.0 +0100 +++ /usr/share/initramfs-tools/hook-functions 2006-08-18 13:19:46.0 +0100 @@ -169,7 +169,7 @@ scsi) for x in 3w-9xxx 3w- a100u2x aacraid advansys ahci \ aic79xx aic7xxx arcmsr ata_piix atari_scsi atp870u BusLogic \ - cciss ch cpqarray dac960 dc395x dmx3191d dpt_i2o eata fdomain \ + cciss ch cpqarray DAC960 dc395x dmx3191d dpt_i2o eata fdomain \ gdth hptiop ibmvscsic initio ipr ips isp1020 lpfc max_scsi \ mac53c94 megaraid megaraid_mbox megaraid_mm mesh mptfc \ mptscsih mptsas mptspi nsp32 osst qla1280 qla2100 qla2200 \
