Bug#857624: kernel warning/backtrace in parport/ppdev when running as a VM
Package: src:linux Version: 4.9.13-1 Severity: important Booting a freshly installed stretch system under (jessie's) qemu-kvm results in a couple of kernel warnings related to parport on every boot. I've experienced this on a few different systems now, in different infrastructures, so I'm guessing this may be easily reproducible. The qemu-kvm arguments to boot the VM, FWIW, are: /usr/bin/qemu-system-x86_64 -name hostname.example.org -m 1024 -smp 2 -pidfile /var/run/ganeti/kvm-hypervisor/pid/hostname.example.org -balloon virtio,id=balloon,bus=pci.0,addr=0x3 -daemonize -machine pc-i440fx-2.5,accel=kvm -monitor unix:/var/run/ganeti/kvm-hypervisor/ctrl/hostname.example.org.monitor,server,nowait -serial unix:/var/run/ganeti/kvm-hypervisor/ctrl/hostname.example.org.serial,server,nowait -usb -display none -uuid 74938386-ca2d-4af1-9878-3a07bd81f9df -netdev type=tap,id=hotnic-cc1c5606-pci-5,fd=10 -device virtio-net-pci,mac=aa:00:00:3b:60:cb,id=hotnic-cc1c5606-pci-5,bus=pci.0,addr=0x5,netdev=hotnic-cc1c5606-pci-5 -qmp unix:/var/run/ganeti/kvm-hypervisor/ctrl/hostname.example.org.qmp,server,nowait -qmp unix:/var/run/ganeti/kvm-hypervisor/ctrl/hostname.example.org.kvmd,server,nowait -boot c -device virtio-blk-pci,drive=hotdisk-7c7dc94d-pci-4,id=hotdisk-7c7dc94d-pci-4,bus=pci.0,addr=0x4 -drive file=/var/run/ganeti/instance-disks/hostname.example.org:0,format=raw,if=none,aio=native,id=hotdisk-7c7dc94d-pci-4,bus=0,unit=4 -S And the backtraces are: [7.095889] ppdev: user-space parallel port driver [7.101588] [ cut here ] [7.101605] WARNING: CPU: 1 PID: 227 at /build/linux-QtSjAP/linux-4.9.13/fs/sysfs/dir.c:31 sysfs_warn_dup+0x5d/0x70 [7.101606] sysfs: cannot create duplicate filename '/devices/pnp0/00:04/ppdev/parport0' [7.101607] Modules linked in: ppdev joydev evdev bochs_drm serio_raw ttm drm_kms_helper virtio_balloon sg pcspkr drm parport_pc(+) parport acpi_cpufreq tpm_tis tpm_tis_core tpm button ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 mbcache sr_mod cdrom ata_generic virtio_net virtio_blk ata_piix libata psmouse uhci_hcd floppy ehci_hcd scsi_mod i2c_piix4 usbcore virtio_pci virtio_ring virtio usb_common [7.101640] CPU: 1 PID: 227 Comm: systemd-udevd Not tainted 4.9.0-2-amd64 #1 Debian 4.9.13-1 [7.101641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [7.101643] 92728594 ace8c0483808 [7.101645] 92476dde 8fb379ea5000 ace8c0483860 8fb379f393c0 [7.101647] 8fb37db6c300 8fb37d943400 0630 92476e5f [7.101649] Call Trace: [7.101662] [] ? dump_stack+0x5c/0x78 [7.101668] [] ? __warn+0xbe/0xe0 [7.101670] [] ? warn_slowpath_fmt+0x5f/0x80 [7.101672] [] ? kernfs_path_from_node+0x4a/0x60 [7.101674] [] ? sysfs_warn_dup+0x5d/0x70 [7.101676] [] ? sysfs_create_dir_ns+0x70/0x80 [7.101679] [] ? kobject_add_internal+0x9d/0x320 [7.101680] [] ? kobject_add+0x75/0xd0 [7.101692] [] ? device_add+0x14e/0x620 [7.101695] [] ? device_create_groups_vargs+0xd9/0xf0 [7.101700] [] ? dead_read+0x10/0x10 [parport] [7.101702] [] ? device_create+0x51/0x70 [7.101711] [] ? klist_next+0x1b/0xf0 [7.101714] [] ? driver_check+0x13/0x20 [parport] [7.101715] [] ? bus_for_each_drv+0x62/0xb0 [7.101718] [] ? parport_announce_port+0xbc/0x100 [parport] [7.101722] [] ? parport_pc_probe_port+0x6ba/0xbb0 [parport_pc] [7.101724] [] ? _dev_info+0x6c/0x90 [7.101726] [] ? parport_pc_pnp_probe+0x13e/0x1e0 [parport_pc] [7.101729] [] ? parport_pc_pci_probe+0x260/0x260 [parport_pc] [7.101735] [] ? pnp_device_probe+0x5c/0xc0 [7.101737] [] ? driver_probe_device+0x21a/0x420 [7.101739] [] ? __driver_attach+0xda/0xe0 [7.101741] [] ? driver_probe_device+0x420/0x420 [7.101742] [] ? bus_for_each_dev+0x67/0xb0 [7.101744] [] ? bus_add_driver+0x16a/0x260 [7.101746] [] ? driver_register+0x57/0xc0 [7.101749] [] ? parport_pc_init+0x2cd/0xf2a [parport_pc] [7.101757] [] ? netlink_broadcast_filtered+0x14c/0x3d0 [7.101760] [] ? parport_parse_param.constprop.14+0xd6/0xd6 [parport_pc] [7.101762] [] ? do_one_initcall+0x4b/0x180 [7.101766] [] ? __vunmap+0x6d/0xc0 [7.101772] [] ? do_init_module+0x5b/0x1ed [7.101776] [] ? load_module+0x2523/0x2a00 [7.101777] [] ? __symbol_put+0x60/0x60 [7.101779] [] ? SYSC_finit_module+0xc6/0xf0 [7.101781] [] ? do_syscall_64+0x7c/0xf0 [7.101787] [] ? entry_SYSCALL64_slow_path+0x25/0x25 [7.101789] ---[ end trace 7d54979a5167cd9e ]--- [7.101790] [ cut here ] [7.101792] WARNING: CPU: 1 PID: 227 at /build/linux-QtSjAP/linux-4.9.13/lib/kobject.c:240 kobject_add_internal+0x2ab/0x320 [7.101793]
Re: Bug#776192: Linux null-pointer deref in 3.16.7-ctk2-1 (was: Bug#776192: upgrade-reports wheezy to jessie boot problem)
clone 776192 -1
reassign -1 systemd 215-17
fixed -1 217-1
tags -1 = patch
severity -1 important
owner -1 !
thanks
On Mon, Apr 06, 2015 at 08:50:58PM +0100, Ben Hutchings wrote:
It looks the same as this problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705
http://thread.gmane.org/gmane.linux.ubuntu.devel.kernel.general/39123/
I just encountered this bug while trying to install jessie on a Dell
PowerEdge R610 with a SAS 6/iR (fairly recent, much more than 1950s).
The kernel crashes while in d-i and installation fails. I also tried
with a nightly d-i with Linux 4.0 -- same issue.
Ironically, I found this bug report, clicked through the referenced
links, only to discover I had previously investigated this when
installling a similar server with Ubuntu 14.04 and I've even replied to
the Launchpad bug above... I can confirm it's the exact same bug. Note
that it was also covered by LWN(!): https://lwn.net/Articles/611226/
It's disappointing that this bug hasn't been fixed yet upstream and
especially the part where mptsas' error handling is broken and the
kernel crashes instead of gracefully failing. This is a different,
secondary, bug that is just triggered by the timeout.
In any case, there seems to have been /some/ improvement upstream on
this. systemd has increased the timeout from 30s to 60s (2e92633) and
subsequently to 180s (b5338a1), in commits that are both included in
v217. They have also made this a kernel command-line option
(udev.event-timeout rd.udev.event-timeout) but those are more invasive
patches.
My working servers with Ubuntu 12.04 14.04 indicate on their dmesg
that the probe time is somewhere between 18-31s, so 180s would
definitely fix the effect of this bug.
The commits above aren't directly backportable to v215 as the upstream
code has changed significantly but the very simple patch attached is the
equivalent fix for v215 (it's untested, though).
This affects a large number of Dell systems (~100 alone in my case) and
there is no practical workaround, so it'd be great if this was fixed in
a jessie point release.
Best,
Faidon
diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index a45d324..072499c 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -1415,7 +1415,7 @@ int main(int argc, char *argv[])
if (worker-state != WORKER_RUNNING)
continue;
-if ((now(CLOCK_MONOTONIC) - worker-event_start_usec) 30 * USEC_PER_SEC) {
+if ((now(CLOCK_MONOTONIC) - worker-event_start_usec) 180 * USEC_PER_SEC) {
log_error(worker [%u] %s timeout; kill it, worker-pid,
worker-event ? worker-event-devpath : idle);
kill(worker-pid, SIGKILL);
Bug#741686: linux-image-3.13-1-amd64: systemd-udevd kills long running mptsas module initailization, resulting in kernel oops
Hi, This regression is fairly complicated and it's high impact, as mptsas is being used to drive fairly popular controllers, including the entry-level ones in several generations of Dell PowerEdge servers. We've been debugging this for a while now over at Ubuntu's Launchpad[1] and the issue has been subsequently been raised on both the linux-scsi[2] systemd mailing lists[3]. In essence, there are four different behaviors/bugs here: 1) The kthread_create() semantics have changed in 3.13 with 786235ee by making kthreads killable. Not a bug on its own, but it's a breaks previously working userspace configuration kind of bug. Ubuntu has reverted this patch for trusty as a workaround. 2) mptsas, to probe the SAS bus, spawns a kthread that takes more than 30s to complete. The consensus on the list AIUI is that it's a bug and it should not take that long. 3) systemd-udev by default sends SIGKILL to kthreads that have been running for more than 30s. systemd developers do not consider this a bug but an intended behavior and refuse to fix this issue. Adding OPTIONS+=event_timeout=120 to the udev config would probably workaround this. 4) Unrelated to the bug at hand, mptsas is buggy in the error handling codepath, when the kthread spawning fails. It tries to clean up by dereferencing a NULL pointer and hence the kernel oopses, while otherwise it'd just continue running, just without any mptsas devices present. I've made an analysis of the buggy codepath on comment #27 on the LP bug above. This has always been a bug, it's just that that codepath was untested until now. The end result is that this regression is somewhere in the limbo land between kernel/systemd for the two features (1)/(2) that are valid on their own but reveal a regression in combination with (3) and each other. Issue (2) seems like a real bug and the root cause here, but one that probably can't be easily fixed in a point release -- I don't think it hasn't even been fixed in master yet. Issue (4) is easily fixable but it's orthogonal and not going to solve the real problem here. It will just downgrade this from an oops to just a system with no disk drives but an otherwise working kernel. Regards, Faidon 1: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705 2: https://lkml.org/lkml/2014/3/23/42 3: http://lists.freedesktop.org/archives/systemd-devel/2014-March/018007.html -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534277ce.2010...@debian.org
Bug#703607: Please include Cypress PS/2 Trackpad driver in linux-image-3.2.0-*
On Sun, Mar 24, 2013 at 06:20:01PM +, Ben Hutchings wrote: Control: severity -1 important This is a bit off-topic, but I'm not sure it warrants a different bug report (feel free to clone): I recently had to support a friend who bought a Dell E6230 and installed Wheezy, but couldn't get the touchpad working (it was detected as a regular PS2 Mouse). The E6230 is a May 2012 release laptop, otherwise identical to the E6220, which had a regular ALPS touchpad with support backported to wheezy in the first days of the freeze. It turns out that the E6230 has a Rushmore ALPS touchpad. Support for those was exists in upstream by 1302bac33d9e88cd43e482191a806998f3ed43cc, committed Feb 13, will be in 3.9. cd401204873101245287afc07271b39c79194d9c is probably part of that series too. The support is hence bleeding-edge, but the E6230/E6430/E6530 laptops are out for quite some time and are very popular -- it's basically the 12/14/15 inch Latitudes that are on sale now. I tried backporting that patch and failed miserably. I'm not sure how much more work would it be to apply them and if they'll be accepted into Debian if they have to pull a dozen more commits, esp. this late in the cycle. I'll let you be the judge of that, I was impressed you changed this to important :) FWIW, I built psmouse.ko straight of 3.9 and the touchpad works as a charm on that laptop. I can also do more extensive testing with a 3.2 + patches, albeit with a bit of an increased turnaround as I don't own that laptop. Thanks, Faidon -- 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/20130326143339.ga16...@tty.gr
Bug#686636: Please backport virtio-scsi to wheezy
Package: linux Version: 3.2.23-1 Severity: wishlist Virtio SCSI a new driver/transport for block storage for paravirtualized systems. It replaces the older limited in many ways virtio-blk and is implemented by basically passing through SCSI over virtio. Hence devices appear as regular SCSI devices like /dev/sda instead of /dev/vda, SCSI passthrough can be easily implemented, multiple LUNs can be supported without provisioning a PCI card for each etc. http://wiki.qemu.org/Features/VirtioSCSI On the host side, virtio-scsi is supported by qemu(-kvm) = 1.1 (in wheezy) or by a kernel vhost driver for LIO which is still experimental and merged in v3.6 as a staging driver. virtio-scsi is the guest driver for supporting such devices, i.e. it's needed in a guest system configured with one or more virtio-scsi devices. It was first included in Linux v3.4 with some features/bugfixes in v3.6: 59057fb [SCSI] virtio-scsi: Add vdrv-scan for post VIRTIO_CONFIG_S_DRIVER_OK LU 365a715 [SCSI] virtio-scsi: hotplug support for virtio-scsi 2bd37f0 [SCSI] virtio-scsi: split scatterlist per target bce750b [SCSI] virtio-scsi: release sg_lock after add_buf 139fe45 [SCSI] virtio-scsi: split locking per vq b5ee8f2 [SCSI] virtio-scsi: unlock during kick e4594bb [SCSI] virtio_scsi: fix TMF use-after-free 4fe74b1 [SCSI] virtio-scsi: SCSI driver for QEMU based virtual machines (the last two are v3.4, the rest are v3.6) I believe it's important for wheezy to support being a guest in such configurations, as I expect virtio-scsi to be gradually adopted during the wheezy lifecycle. The driver is mostly self-contained and straightforward to backport (I wouldn't ask otherwise): The above commits cherry-picked against v3.2.28 result in the following: drivers/scsi/Kconfig|8 + drivers/scsi/Makefile |1 + drivers/scsi/virtio_scsi.c | 803 + drivers/virtio/virtio.c |5 +- include/linux/virtio.h |1 + include/linux/virtio_ids.h |1 + include/linux/virtio_scsi.h | 123 + 7 files changed, 941 insertions(+), 1 deletion(-) The v3.6 could be risky, considering they haven't been released yet and haven't seen much testing. If you prefer merging just v3.4's 4fe74b1/e4594bb instead, the stat is: drivers/scsi/Kconfig|8 + drivers/scsi/Makefile |1 + drivers/scsi/virtio_scsi.c | 596 + include/linux/virtio_ids.h |1 + include/linux/virtio_scsi.h | 114 +++ 5 files changed, 720 insertions(+) Thanks, Faidon -- 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/20120904063255.ga19...@tty.gr
Bug#630730: marked as done (linux-image-2.6.32: GSO IPv6 issues)
found 630730 linux-2.6/2.6.32-38
thanks
I've checked with -38 and the fix doesn't seem to be there (i.e. I'm
still experiencing the effects). I'm looking at the source package and
even though the patches are in debian/patches, they do not seem to be
included from a series file.
I'm also checking SVN and specifically r18053, and it seems that the
patches were moved from features/all/{e1000e,igdb} to bugfix/all, the
lines for the former were removed from series/36 but no lines were added
on series/37 or anywhere else...
Best regards,
Faidon
--
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/20111021201347.ga6...@noc.grnet.gr
Bug#644212: linux-image-2.6.32-5-amd64: kernel BUG at kernel/exit.c:1035: invalid opcode: 0000
On Tue, Oct 04, 2011 at 03:29:50AM +0100, Ben Hutchings wrote: On Tue, 2011-10-04 at 03:51 +0300, Faidon Liambotis wrote: Package: linux-2.6 Version: 2.6.32-35 Severity: normal The stack trace can be seen below; if it matters, note that the machine a) is running under KVM, b) has relatively high CPU I/O load c) it's the first time it has BUGed, although it has been running with 2.6.32 since April and with 2.6.32-35 since early August. [...] Well this is pretty damn weird. This BUG message means that the scheduler reselected a task to run after it exited (i.e. it was a zombie). I can't find any related bug reports or fixes. I'm afraid we are unlikely to be able to progress this unless it is reproducible. Yeah, I figured it was weird... I don't think I'll be able to reproduce this, it wasn't even triggered by user action (the process that crashed it is a daemon) — and as I said, it's the first time it's being doing this in quite a while. If you have any ideas on how to reproduce it or get more info, I'm all ears :-) The machine is, surprisingly, still up and running although I'll have to reboot it (just to be safe) soon. Thanks, Faidon -- 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/20111004092036.ga9...@tty.gr
Bug#644212: linux-image-2.6.32-5-amd64: kernel BUG at kernel/exit.c:1035: invalid opcode: 0000
Package: linux-2.6 Version: 2.6.32-35 Severity: normal The stack trace can be seen below; if it matters, note that the machine a) is running under KVM, b) has relatively high CPU I/O load c) it's the first time it has BUGed, although it has been running with 2.6.32 since April and with 2.6.32-35 since early August. Thanks, Faidon -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011 ** Command line: root=/dev/vda1 ro rootflags=data=writeback ** Tainted: D (128) * Kernel has oopsed before. ** Kernel log: [0.751641] alloc irq_desc for 28 on node -1 [0.751643] alloc kstat_irqs on node -1 [0.751729] virtio-pci :00:04.0: irq 28 for MSI/MSI-X [0.752803] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [0.753517] vda: vda1 vda2 [0.754483] uhci_hcd: USB Universal Host Controller Interface driver [0.755860] uhci_hcd :00:01.2: PCI INT D - Link[LNKD] - GSI 10 (level, high) - IRQ 10 [0.757165] uhci_hcd :00:01.2: setting latency timer to 64 [0.757179] uhci_hcd :00:01.2: UHCI Host Controller [0.757848] uhci_hcd :00:01.2: new USB bus registered, assigned bus number 1 [0.759001] uhci_hcd :00:01.2: irq 10, io base 0xc020 [0.759766] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [0.760578] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.761610] usb usb1: Product: UHCI Host Controller [0.762233] usb usb1: Manufacturer: Linux 2.6.32-5-amd64 uhci_hcd [0.762898] usb usb1: SerialNumber: :00:01.2 [0.763658] usb usb1: configuration #1 chosen from 1 choice [0.764460] hub 1-0:1.0: USB hub found [0.765041] hub 1-0:1.0: 2 ports detected [0.916627] ata2.01: NODEV after polling detection [0.917011] ata2.00: ATAPI: QEMU DVD-ROM, 0.12.5, max UDMA/100 [0.918368] ata2.00: configured for MWDMA2 [0.919950] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 0.12 PQ: 0 ANSI: 5 [0.933123] sr0: scsi3-mmc drive: 4x/4x xa/form2 tray [0.933745] Uniform CD-ROM driver Revision: 3.20 [0.934503] sr 1:0:0:0: Attached scsi CD-ROM sr0 [0.939428] sr 1:0:0:0: Attached scsi generic sg0 type 5 [1.076048] usb 1-1: new full speed USB device using uhci_hcd and address 2 [1.256318] kjournald starting. Commit interval 5 seconds [1.256403] EXT3-fs: mounted filesystem with writeback data mode. [1.454962] usb 1-1: New USB device found, idVendor=0627, idProduct=0001 [1.49] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.456141] usb 1-1: Product: QEMU USB Tablet [1.456642] usb 1-1: Manufacturer: QEMU 0.12.5 [1.457125] usb 1-1: SerialNumber: 1 [1.457714] usb 1-1: configuration #1 chosen from 1 choice [2.217844] udev[363]: starting version 164 [2.433325] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [2.437711] ACPI: Power Button [PWRF] [2.473528] processor LNXCPU:00: registered as cooling_device0 [2.475711] processor LNXCPU:01: registered as cooling_device1 [2.480173] processor LNXCPU:02: registered as cooling_device2 [2.481195] processor LNXCPU:03: registered as cooling_device3 [2.482051] processor LNXCPU:04: registered as cooling_device4 [2.482870] processor LNXCPU:05: registered as cooling_device5 [2.547790] piix4_smbus :00:01.3: SMBus Host Controller at 0xb100, revision 0 [2.789415] input: PC Speaker as /devices/platform/pcspkr/input/input3 [2.819982] parport_pc 00:05: reported by Plug and Play ACPI [2.820917] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] [2.825668] usbcore: registered new interface driver hiddev [2.848259] input: QEMU 0.12.5 QEMU USB Tablet as /devices/pci:00/:00:01.2/usb1/1-1/1-1:1.0/input/input4 [2.849733] generic-usb 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Pointer [QEMU 0.12.5 QEMU USB Tablet] on usb-:00:01.2-1/input0 [2.850898] usbcore: registered new interface driver usbhid [2.851578] usbhid: v2.6:USB HID core driver [2.934005] Error: Driver 'pcspkr' is already registered, aborting... [3.143200] Adding 524280k swap on /dev/vda2. Priority:-1 extents:1 across:524280k [3.262849] EXT3 FS on vda1, internal journal [3.265337] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input5 [5.316689] ip_tables: (C) 2000-2006 Netfilter Core Team [5.398364] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [5.399658] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use [5.400773] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or [5.437435] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. [5.474827] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 14.745708] eth0: no IPv6 routers present [ 1110.094839] hrtimer:
Bug#630730: linux-image-2.6.32: GSO IPv6 issues
On Fri, Aug 26, 2011 at 01:10:25AM +0300, Faidon Liambotis wrote: After talking with Ben on IRC, I've prepared and sent a -longterm tree submission for the two commits. I'll update the bug report when I get a reply. I just got a reply that the patches were accepted to the stable review queue. Regards, Faidon -- 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/20110830221320.ga14...@tty.gr
Bug#630730: linux-image-2.6.32: GSO IPv6 issues
forwarded 630730 sta...@kernel.org thanks On Thu, Jul 28, 2011 at 04:48:58PM +0200, Faidon Liambotis wrote: What's the status of this? Have the patches been forwarded to -longterm maintainers? (is that Greg KH?); if not, I'd be happy to do it for you. After talking with Ben on IRC, I've prepared and sent a -longterm tree submission for the two commits. I'll update the bug report when I get a reply. Thanks, Faidon -- 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/20110825221025.ga24...@tty.gr
Bug#630730: linux-image-2.6.32: GSO IPv6 issues
On Tue, Jun 21, 2011 at 08:32:04PM -0700, David Miller wrote: From: Ben Hutchings b...@decadent.org.uk Date: Wed, 22 Jun 2011 04:20:13 +0100 David, these look like good candidates for longterm updates. What do you think? Sure but I don't do submissions for the longterm stuff, I only work on the -stable trees that Greg is actively maintaining. What's the status of this? Have the patches been forwarded to -longterm maintainers? (is that Greg KH?); if not, I'd be happy to do it for you. Best regards, Faidon -- 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/20110728144858.ga9...@tty.gr
Re: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]
severity 616301 critical thanks My system locks up whenever I click on a YouTube video link since yesterday. I can probably live without YouTube :), but in any case this shouldn't happen. This isn't a singled out case nor in exotic, possibly faulty, hardware. It's on a standard 1½-year old Dell OptiPlex 780 desktop with a Radeon HD card (one of the standard configurations) and this is on a stock squeeze system. The findings so far seem to suggest this is a Mesa issue; I'd probably file it under Linux kernel bugs (or even DoS bugs) but I'm not sure where to properly file such bugs in the post-KMS stack world. Regards, Faidon -- 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/20110304190158.ga13...@faidon.noc.grnet.gr
Bug#578005: Please consider backporting KVM_GET/SET_CLOCK to 2.6.32
Ben Hutchings wrote: This is definitely worthwhile but it does involve an ABI bump. So we will probably wait for a convenient time to do that. I saw that you (well, maks) just bumped the ABI to -5. Ping? :) Thanks, Faidon -- 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/4bd2b04c.9090...@debian.org
Bug#578005: Please consider backporting KVM_GET/SET_CLOCK to 2.6.32
maximilian attems wrote: tried 3cfc3092f40bc37c57ba556cfd8de4218f2135ab, ffde22ac53b6d6b1d7206f1172176a667eead778. none of them apply. ffde22ac53b6d6b1d7206f1172176a667eead778 (Xen-HVM) applies with some (manually checked, safe) fuzz/offset. On top of that, afbcf7ab8d1bc8c2d04792f6d9e786e0adeb328d (kvmclock) applies cleanly also with some minor fuzz. Alternatively, I've attached a backported kvmclock patch that applies without Xen-HVM, in case you don't want that. As for 3cfc3092f40bc37c57ba556cfd8de4218f2135ab (VCPU events), after applying the previous two, it has one minor conflict that is easily solvable with a one-liner. If it isn't obvious, I can attach a patch. (all of the above are tested with a git checkout of 2.6.32, haven't tried Debian's SVN although I don't expect it to be much different) Regards, Faidon -- 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/4bd33057.4050...@debian.org
Bug#578005: Please consider backporting KVM_GET/SET_CLOCK to 2.6.32
Package: linux-2.6
Version: 2.6.32-11
Severity: minor
Tags: patch, fixed-upstream
Hi,
(severity minor since this is something between a bug and a feature request)
Commit afbcf7ab8d1bc8c2d04792f6d9e786e0adeb328d, released with 2.6.33, reads:
[PATCH] KVM: allow userspace to adjust kvmclock offset
When we migrate a kvm guest that uses pvclock between two hosts, we may
suffer a large skew. This is because there can be significant differences
between the monotonic clock of the hosts involved. When a new host with
a much larger monotonic time starts running the guest, the view of time
will be significantly impacted.
Situation is much worse when we do the opposite, and migrate to a host with
a smaller monotonic clock.
This proposed ioctl will allow userspace to inform us what is the monotonic
clock value in the source host, so we can keep the time skew short, and
more importantly, never goes backwards. Userspace may also need to trigger
the current data, since from the first migration onwards, it won't be
reflected by a simple call to clock_gettime() anymore.
IOW, the API greatly helps KVM live migrations. Without it, there are fair
chances that after the migration the guest will crash. The API is used by
qemu-kvm = 0.12.1 and 0.12.3 is currently in squeeze.
The commit came on top of ffde22ac53b6d6b1d7206f1172176a667eead778, “KVM: Xen
PV-on-HVM guest support”, which is totally unrelated in functionality but
makes the patch to not apply cleanly on 2.6.32. The backport modifications are
trivial, the patch ready to be applied on 2.6.32 is attached. The (new) patch
has a diffstat of:
Documentation/kvm/api.txt | 36 ++
arch/x86/include/asm/kvm_host.h |1
arch/x86/kvm/x86.c | 42 +++-
include/linux/kvm.h | 10
4 files changed, 88 insertions(+), 1 deletion(-)
I understand that there are few users needing this; OTOH, the patch is very
simple and the maintainance burden should be much less than other things that
you've pulled, like Xen :)
BTW, while you're at it, perhaps you should have a look at the, also trivial,
3cfc3092f40bc37c57ba556cfd8de4218f2135ab (“KVM: x86: Add
KVM_GET/SET_VCPU_EVENTS”) too.
Thanks,
Faidon
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index 5a4bc8c..db3a706 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -593,6 +593,42 @@ struct kvm_irqchip {
} chip;
};
+4.27 KVM_GET_CLOCK
+
+Capability: KVM_CAP_ADJUST_CLOCK
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_clock_data (out)
+Returns: 0 on success, -1 on error
+
+Gets the current timestamp of kvmclock as seen by the current guest. In
+conjunction with KVM_SET_CLOCK, it is used to ensure monotonicity on scenarios
+such as migration.
+
+struct kvm_clock_data {
+ __u64 clock; /* kvmclock current value */
+ __u32 flags;
+ __u32 pad[9];
+};
+
+4.28 KVM_SET_CLOCK
+
+Capability: KVM_CAP_ADJUST_CLOCK
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_clock_data (in)
+Returns: 0 on success, -1 on error
+
+Sets the current timestamp of kvmclock to the valued specific in its parameter.
+In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios
+such as migration.
+
+struct kvm_clock_data {
+ __u64 clock; /* kvmclock current value */
+ __u32 flags;
+ __u32 pad[9];
+};
+
5. The kvm_run structure
Application code obtains a pointer to the kvm_run structure by
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index d838922..d759a1f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -412,6 +412,7 @@ struct kvm_arch{
unsigned long irq_sources_bitmap;
unsigned long irq_states[KVM_IOAPIC_NUM_PINS];
u64 vm_init_tsc;
+ s64 kvmclock_offset;
};
struct kvm_vm_stat {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ae07d26..adb7912 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -677,7 +677,8 @@ static void kvm_write_guest_time(struct kvm_vcpu *v)
/* With all the info we got, fill in the values */
vcpu-hv_clock.system_time = ts.tv_nsec +
- (NSEC_PER_SEC * (u64)ts.tv_sec);
+ (NSEC_PER_SEC * (u64)ts.tv_sec) + v-kvm-arch.kvmclock_offset;
+
/*
* The interface expects us to write an even number signaling that the
* update is finished. Since the guest won't see the intermediate
@@ -1224,6 +1225,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_PIT2:
case KVM_CAP_PIT_STATE2:
case KVM_CAP_SET_IDENTITY_MAP_ADDR:
+ case KVM_CAP_ADJUST_CLOCK:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
@@ -2421,6 +2423,44 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = 0;
break;
}
+ case KVM_SET_CLOCK: {
+ struct timespec now;
+ struct kvm_clock_data user_ns;
+ u64 now_ns;
+ s64 delta;
+
+ r = -EFAULT;
+ if (copy_from_user(user_ns, argp, sizeof(user_ns)))
+
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
Luis R. Rodriguez wrote: Can you guys upstream a package into Debian with a gitweb URL reference? If I'm understanding the question correctly, yes. We have Vcs-$VCS (i.e. Vcs-Git) and Vcs-Browser pseudo-headers. Both are optional. I agree with Kel here, git2cl et al are unimportant details. Kel, mail me in private when you have something ready for review upload, as usual. Regards, Faidon -- 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/4b8c7b7c.5010...@debian.org
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
Luis R. Rodriguez wrote: As per Paul Wise' advice I'd like to request for help with the crda/wireless-regdb package for Debian for the next release of Debian. I am the upstream crda maintainer and John Linville is the upstream wireless-regdb maintainer. Kel Modderman has already done most work required for the Debian package, if not all. What we now need is some Debian Developer to be willing to either upload the package as-is, or some help from some experienced package maintainers to address a few items. I should note Paul Wise has offered sponsorship for this package so I think we are on the last track to getting this package finalized and/or uploaded but he just noted a few changes required. Summary of review with Paul Wise: * Package could likely be uploaded into Debian as-is, just requires someone comfortable with it * We need more help with thepkg-wpa-devel group I'm a member of pkg-wpa-devel and I've been sponsoring Kel for almost 4 years. I have absolute trust in him and I've even offered to advocate him to the NM process multiple times. I'd be happy to review and sponsor the uploads of crda/wireless-regdb, if Paul doesn't have a problem with this. I usually prefer team maintenance, so I think it'd be best if this happened in pkg-wpa; my offer to sponsor is independent of that, though. Regards, Faidon -- 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/4b8995b6.5000...@debian.org
Re: Linux Kernel plans for the squeeze cycle
maximilian attems wrote: Also, I remember reading about an effort on merging dom0 to mailine. From your experience, is there a chance of that happening for 2.6.32? I don't think so. For the record, Xen upstream[1] mentions dom0 support, currently planned for Linux 2.6.32 or 2.6.33 (latest pv_ops dom0 patches can be found from jeremy's git tree, see instructions below). floating patches are not the maintainance that one expects for a stable release. use kvm. I wasn't suggesting to include those patches in Debian nor I find it a good idea; I merely referred to that quote from upstream for the planned for 2.6.32/33 part, which was the point of the discussion, as quoted above. Regards, Faidon -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Linux Kernel plans for the squeeze cycle
Ben Hutchings wrote: Removal of OpenVZ, Vserver and Xen packages These are large and intrusive patches which require significant upstream effort to adapt to each new kernel version. As a result, they generally lag availability of new kernel versions and may take much longer to stabilise, so they can only be frozen some time after the standard kernel. There is also no guarantee that the upstream projects will continue to support the kernel version we release with. For example, official Xen releases are still based on 2.6.18 with huge changes (though they will apparently move to a newer version soon). Although we were able to use SUSE's forward-port of Xen to 2.6.26, SLE 11 was eventually released with 2.6.27 and so we are on our own with 2.6.26+Xen. Currently, no-one appears to be ready to maintain these variants in squeeze. I'm pretty sure that you're referring to Xen *dom0*, since domU is merged into mainline and even available into lenny's unpatched kernel (i.e. the non-xen variant). Could you verify/clarify? Also, I remember reading about an effort on merging dom0 to mailine. From your experience, is there a chance of that happening for 2.6.32? (the version targetted for squeeze I presume?) If not, are there any plans of providing a migration path for our users like e.g. xenner? (sorry for discussing on -release, but seems applicable) Regards, Faidon -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500645: upstream patch
Hi,
Apparently the upstream fix is a two-liner and doesn't break ABI.
Seems easy to fix and test and live migration is an important feature.
Perhaps it could be part of the next upload?
Thanks,
Faidon
http://git.openvz.org/?p=linux-2.6.26-openvz;a=commit;h=6d18ba377cfa3e86ee830fe6a5fce52b8fd51039
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 5bfa408..2fbce13 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -146,6 +146,8 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum)
goto tb_not_found;
tb_found:
if (!hlist_empty(tb-owners)) {
+ if (sk-sk_reuse 1)
+ goto success;
if (tb-fastreuse 0
sk-sk_reuse sk-sk_state != TCP_LISTEN) {
goto success;
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494445: oops when loading nf_conntrack_ipv6
Vitaliy, hi, On Tue, Aug 12, 2008 at 02:55:56PM +0400, Vitaliy Gusev wrote: On 11 August 2008 19:39:35 maximilian attems wrote: hello, could you please take a look at: * oops on load of nf_conntrack_ipv6 http://bugs.debian.org/494445 IPv6 conntrack doesn't work yet. It will be finished in this week. I'm experiencing the oops on our latest kernel (2.6.26-7, seems to include openvz stuff up to 24cebf40). Do you have a fix for this? I'm only asking because you said you were fixing this back then. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494445: oops when loading nf_conntrack_ipv6
Vitaliy Gusev wrote: The linux-image-2.6.26-1-openvz doesn't have this fix. Latest 2.6.26-ovz has fix. For 2.6.27-ovz fix patches was sent To Pavel for review. Could you pinpoint the patch for 2.6.26 exactly, e.g. by a commit or by attaching it? If it's simple enough, perhaps the Debian kernel maintainers could add it to Debian's tree. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500645: Acknowledgement (linux-image-2.6.26-1-openvz-686: OpenVZ checkpointing does not work)
forwarded 500645 http://bugzilla.openvz.org/show_bug.cgi?id=1034 thanks Hi, Upstream contacted me; apparently the bug was (automatically?) forwarded to their bugzilla as #1034. They think that the bug was fixed in commit d588f384. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500645: linux-image-2.6.26-1-openvz-686: OpenVZ checkpointing does not work
Package: linux-image-2.6.26-1-openvz-686 Version: 2.6.26-6 Severity: normal 2.6.26-6 supposedly added OpenVZ checkpointing support -- and indeed the kernel option was enabled and /proc/cpt exists. I was unable, however, to perform an online migration or even a checkpoint/restore cycle on both 686 and amd64 kernels on different machines: hn:~# vzctl chkpnt 201 Setting up checkpoint... suspend... dump... kill... VE is unmounted Checkpointing completed succesfully hn:~# vzctl restore 201 Restoring VE ... Starting VE ... VE is mounted undump... Adding IP address(es): removed Setting CPU units: 1000 Configure meminfo: 49152 Error: undump failed: Address already in use Restoring failed: Error: open_listening_socket: bind: -98 Error: rst_sockets: open_listening_socket: -98 Error: rst_sockets: -98 VE start failed Stopping VE ... VE was stopped VE is unmounted hn:~# dmesg |tail -5 [ 1013.441803] CT: 201: started [ 1014.711018] CPT ERR: cdeae800,201 :open_listening_socket: bind: -98 [ 1014.712378] CPT ERR: cdeae800,201 :rst_sockets: open_listening_socket: -98 [ 1014.713732] CPT ERR: cdeae800,201 :rst_sockets: -98 [ 1014.725277] CT: 201: stopped The problem seems to be with bind(), obviously. I tried checkpointing a container that had all network services shutdown and it worked. I also tried veth instead of venet with no luck. I've searched the Internet and upstream's bugzilla with no relevant results. I can provide you with access on a kvm guest that has this problem in case you want to debug it further. Note that I reproduced this on real machines as well, so this has nothing to do with kvm. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
Robert Edmonds wrote: Any modification to the tg3 driver to produce a GR 2006-004 compliant driver would have to diverge from the kernel team's patch acceptance guidelines[0] since upstream is intransigent[1] on making tg3 firmware-free or firmware-optional. The kernel team does not appear to be interested in maintaining such a driver, and it appears future linux kernel source packages will be patched[2] to simply remove the blobs of firmware (I don't know why the driver isn't simply removed entirely since the result does not compile). This seems totally inappropriate. If the driver includes non-free firmwares these should be removed or split up from the driver source, not remove the driver entirely. If what you say is right, the driver *works* for most of the hardware without non-free blobs. Therefore, I can't understand how removing the driver serves our users. Any rationale behind that decision? I feel like I'm arguing for something completely obvious... Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian's Linux kernel continues to regress on freedom
Joerg Jaspert wrote: Oh well, the kernel team just lost its trust, which means new uploads of kernel-team packages dont get their old way of fasttracking in NEW, as I now need to check all of their uploads for such cases. I'm not sure I find this helpful. You're not checking for copyright violations or for non-free stuff in all other packages. I see no reason why you should check for Linux just because it passes through NEW at each release for unrelated technical reasons. The only reason that things like linux-2.6.XX pass through NEW is, from my POV, because noone stepped up to fix it so that old source packages don't have to pass through. If you/we have an issue with the way things are being done by the kernel team, it should be resolved with them and possibly with the help of tech-ctte if an agreement can't be made. IMHO, it's not the ftp-master's job to check with each upload if a number of DDs follow the social contract as they should. If there is indeed a problem, we should try to solve this once and forever, shouldn't we? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian's Linux kernel continues to regress on freedom
Sune Vuorela wrote: On 2007-09-12, Faidon Liambotis [EMAIL PROTECTED] wrote: Joerg Jaspert wrote: You're not checking for copyright violations or for non-free stuff in all other packages. I obviously meant all other *existing* source packages, i.e. all the uploads that don't pass through NEW. The only reason that things like linux-2.6.XX pass through NEW is, from my POV, because noone stepped up to fix it so that old source packages don't have to pass through. I don't consider it something needing fixing. It is a good way to have the copyright files occasionally reviewed. I don't think that old source packages are re-reviewed for copyright violations/non-freeness. But I could easily be wrong. Even if that is not the case, I don't think that Joerg's time should be spent that way, TBH -- but that not up to me :) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
