Bug#895381: Severity
Hello Sergio, I'm reviewing bugs that are currently release critical at our local bug squashing party, and I stumbled on yours. I'm not disputing this bug exists, I'm just trying to determine why it is you set the severity to "Serious". As you are probably aware, this severity indicates that this is a sever violation of Debian policy (violates a "must" or "required" directive), or in the package maintainer's opinion, makes the package unsuitable for release. Can you specify what part of debian policy this issue makes this bug severity "Serious"? Thanks! -- micah
Bug#781685: cryptsetup: prompt for password if device exists, otherwise don't block for it to appear
Package: initramfs-tools Version: 0.119 Severity: wishlist I have an encrypted USB drive that is not always attached to my system. With the default cryptsetup configuration, when the system boots, it asks me for the passphrase and everything is fine. If the device is not connected, then booting takes a long time because a 1min30second timeout is triggered waiting for the disk to show up. If I set 'noauto' in crypttab, then I wont be asked for the disk passphrase on boot, even if the device is there, but then the system wont block waiting for the device if it is not there. I would like it if I were prompted for passphrase for this disk, if it is there, otherwise don't spend 1min30seconds blocking boot for it. I understand some people might want the long timeout, but it is pretty frustrating when you do not want it. Perhaps this could be an option in crypttab? micah -- 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/20150401150405.25508.68189.report...@muck.riseup.net
Bug#699311: [wheezy] oops when unplugged USB audio headset
Hi Jonathan, Jonathan Nieder jrnie...@gmail.com writes: severity 699311 important quit Hi Micah, micah anderson wrote: I had plugged in a USB headset and I used it for various things. At some point I decided to remove it from the computer, so I pulled it out. Immediately the system oops'd presenting me with the traceback that you can see by looking at the two photos that I am attaching to this bug report. Thanks for reporting it. Reproducible? I have managed to reproduce it, and have pictures of when that happened if you would like them. It doesn't seem to happen every time I pull the cable out, but it has happened a few times now. micah -- 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/87y5e9r9pm@minnow.riseup.net
Bug#661151: [apparmor] Bug#661151: linux-2.6: lacks AppArmor kernel/userspace interface
Hi all, Its been 2 months without a reply on this issue, and we are getting close to a freeze. Kees and John it looks like there are some pending questions for you below, it would be great if you could chime in with your opinons: If the Debian kernel team was willing to carry some kind of AppArmor kernel/userspace interface patch, I'm now unsure if the old or new ones would be better suited. (I assume AppArmor 2.8 is released long enough before the Wheezy freeze, so that we can ship it in there, and are given this choice.) On the one hand, the old compat' patches are confidence inspiring, as they are small and have been shipped by Ubuntu for a while. My opinon: the 2.4 compat patch is tiny, and it works well, and has been tested for some time, I think it makes the most sense to include this one. On the other hand, it seems the new patches are being upstreamed, which makes them more appealing somehow than the older ones. The newer patch is bigger, some of it must be backported from Linux 3.4, some from Ubuntu, it is much less tested and I suspect because of that will encounter much more resistance from Debian's kernel team to include it. Presumably this will eventually be the one that will be upstreamed, but it isn't there yet. This is why I think the 2.4 compat patch is the way to go with Wheezy, when the newer patch is upstreamed that can be swapped out then. John, I think it would help if you could please point us more precisely to the commits of the new interface that have been upstreamed already, and to the ones that have not been, so that we can get a rough idea of where things are at. Kees, others, what do you think? micah -- -- 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/87mx4pr9k9@algae.riseup.net
Bug#674424: linux-image-3.2.0-0.bpo.2-686-pae: hangs requiring power cycle
Package: linux-2.6 Version: 3.2.15-1~bpo60+1 Severity: normal *** Please type your report below this line *** We are experiencing periodic lock-ups since upgrading to the latest backport kernel. Its happened two nights in a row now, and previously happened two days before. The machine is a relatively heavily I/O loaded backup server. Please find below the last two serial console outputs captured after the machine was hung. [1249211.944027] Pid: 3978, comm: kworker/1:1 Not tainted 3.2.0-0.bpo.2-686-pae #1 [1249211.944027] Call Trace: [1249211.944027] [c103b929] ? warn_slowpath_common+0x6a/0x7b [1249211.944027] [c107d600] ? watchdog_overflow_callback+0x81/0x8d [1249211.944027] [c107d57f] ? watchdog_timer_fn+0x12d/0x12d [1249211.944027] [c103b9a0] ? warn_slowpath_fmt+0x28/0x2c [1249211.944027] [c107d600] ? watchdog_overflow_callback+0x81/0x8d [1249211.944027] [c109b3c3] ? __perf_event_overflow+0x159/0x1ce [1249211.944027] [c1015c2b] ? x86_perf_event_set_period+0x1af/0x1b9 [1249211.944027] [c109b857] ? perf_event_overflow+0xd/0xf [1249211.944027] [c1017597] ? p4_pmu_handle_irq+0x14b/0x198 [1249211.944027] [c1037acd] ? check_preempt_wakeup+0xf3/0x14f [1249211.944027] [c12d74a0] ? perf_event_nmi_handler+0x14/0x15 [1249211.944027] [c12d6ee8] ? do_nmi+0x83/0x2f1 [1249211.944027] [c116d9ac] ? radix_tree_tag_clear+0x77/0xe2 [1249211.944027] [c12d67dc] ? nmi_stack_correct+0x2f/0x34 [1249211.944027] [c1058381] ? ktime_get+0x24/0x98 [1249211.944027] [c10a35c2] ? test_clear_page_writeback+0xb5/0xbe [1249211.944027] [c1054fea] ? hrtimer_interrupt+0x3b/0x1ed [1249211.944027] [f876fa6d] ? ext4_end_bio+0x1b6/0x21e [ext4] [1249211.944027] [c10203a2] ? smp_apic_timer_interrupt+0x64/0x73 [1249211.944027] [c12d64f1] ? apic_timer_interrupt+0x31/0x38 [1249211.944027] [c11f71d4] ? add_timer_randomness+0x5f/0xcc [1249211.944027] [c115b42b] ? blk_update_bidi_request+0x43/0x4c [1249211.944027] [c115b448] ? blk_end_bidi_request+0x14/0x47 [1249211.944027] [c115b4a6] ? blk_end_request+0x7/0x9 [1249211.944027] [f8260f6f] ? scsi_io_completion+0x1b4/0x41a [scsi_mod] [1249211.944027] [f825b40a] ? scsi_finish_command+0xa1/0xb9 [scsi_mod] [1249211.944027] [c10407f1] ? irq_enter+0x49/0x49 [1249211.944027] [c115efb1] ? blk_done_softirq+0x51/0x5d [1249211.944027] [c104088c] ? __do_softirq+0x9b/0x14e [1249211.944027] [c10407f1] ? irq_enter+0x49/0x49 [1249211.944027] IRQ [c10406d4] ? irq_exit+0x2f/0x91 [1249211.944027] [c100d486] ? do_IRQ+0x73/0x84 [1249211.944027] [c12daa30] ? common_interrupt+0x30/0x38 [1249211.944027] [c11500d8] ? crypto_alg_tested+0x167/0x170 [1249211.944027] [f82a4cea] ? serpent_encrypt+0xb77/0xd79 [serpent] [1249211.944027] [f8243214] ? crypt+0x92/0xe0 [xts] [1249211.944027] [f82432de] ? encrypt+0x3b/0x41 [xts] [1249211.944027] [f82a4173] ? serpent_setkey+0x2173/0x2173 [serpent] [1249211.944027] [f82a4173] ? serpent_setkey+0x2173/0x2173 [serpent] [1249211.944027] [c1151af3] ? async_encrypt+0x2f/0x35 [1249211.944027] [f8251cab] ? crypt_convert+0x21f/0x2b7 [dm_crypt] [1249211.944027] [f825202a] ? kcryptd_crypt+0x2e7/0x2fb [dm_crypt] [1249211.944027] [c104e814] ? process_one_work+0x17b/0x258 [1249211.944027] [f8251d43] ? crypt_convert+0x2b7/0x2b7 [dm_crypt] [1249211.944027] [c104e9e4] ? worker_thread+0xf3/0x1f4 [1249211.944027] [c104e8f1] ? process_one_work+0x258/0x258 [1249211.944027] [c10517ab] ? kthread+0x63/0x68 [1249211.944027] [c1051748] ? kthread_worker_fn+0x114/0x114 [1249211.944027] [c12daa3e] ? kernel_thread_helper+0x6/0x10 [1249211.944027] ---[ end trace 8671cd0afe3ecc53 ]--- [1249211.944027] [ cut here ] [1249211.944027] WARNING: at /build/buildd-linux-2.6_3.2.15-1~bpo60+1-i386-e lCmeb/linux-2.6-3.2.15/debian/build/source_i386_none/kernel/watchdog.c:241 watchdog_overflow_callback+0x81/0x8d() [1249211.944027] Hardware name: X5DP8 [1249211.944027] Watchdog detected hard LOCKUP on cpu 3 [1249211.944027] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs reiserfs ext2 joydev st ext4 jbd2 crc16 loop snd_pcm parport_pc snd_timer snd soundcore snd_page_alloc parport e7xxx_edac i2c_i801 tpm_tis tpm tpm_bios processor edac_core pcspkr serio_raw evdev i2c_core thermal_sys intel_rng rng_core container button shpchp ext3 jbd mbcache serpent xts gf128mul dm_crypt dm_mod sd_mod crc_t10dif sg sr_mod cdrom ata_generic ata_piix uhci_hcd ehci_hcd sata_mv libata aic79xx scsi_transport_spi usbcore scsi_mod usb_common floppy e1000 [last unloaded: scsi_wait_scan] [1249211.944027] Pid: 14279, comm: rdiff-backup Tainted: GW 3.2.0-0.bpo.2-686-pae #1 [1249211.944027] Call Trace: [1249211.944027] [c103b929] ? warn_slowpath_common+0x6a/0x7b [1249211.944027] [c107d600] ? watchdog_overflow_callback+0x81/0x8d [1249211.944027] [c107d57f] ? watchdog_timer_fn+0x12d/0x12d [1249211.944027] [c103b9a0] ? warn_slowpath_fmt+0x28/0x2c [1249211.944027] [c107d600] ?
Re: Bug#605090: Linux 3.2 in wheezy
On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez cor...@debian.org wrote: On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote: On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote: (adding few CC:s to keep track on the bug) On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote: On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote: [...] Now, I still think having a hardened Debian kernel inside the distribution is helpful [...] I agree and I would like to see hardening of *all* our configurations, where the performance cost is not too much. That's going to protect all our users rather than just people who seek out a special paranoid configuration. Would you agree that there are some small hardening things that can be done that don't impact performance that much? In particular the privilege boundries mentioned earlier does not seem to introduce any particular performance cost worth worrying about. So I think it's perfectly clear that nor Debian nor Grsecurity are really interested in Debian shipping a Grsecurity kernel. Well, I don't think its fair to say Debian is not interested in shipping a Grsecurity kernel. I think its more accurate to say that the current configuration of the Debian kernel team doesn't find the time to deal with it... but I'm not sure that speaks for all of Debian. I find that sad, because I do think there are users of both which would benefit from that, and not only people who seek out a special paranoid configuration. I agree. On some machines, I would gladly trade perfomance for a hardened kernel where that is more important and it is unfortunate that the attempt to appeal to all possible configurations at the same time results in a kernel that doesn't allow for specialized configurations that people want/need. Anyway, I'll keep updating the current setup for interested people, but without any interest from either party, that definitely looks like a dead end. What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. micah pgpTuJUbNvqex.pgp Description: PGP signature
Re: Linux 3.2 in wheezy
Ben Hutchings b...@decadent.org.uk writes: (See the complaints about removing OpenVZ in wheezy despite 4 years' advance notice of this.) There were complaints when this was originally decided four years ago by the kernel team. What is disturbing is that the complaints then (lxc is not even close to being a drop-in replacement for Linux-Vservers) are still true now. When I said this four years ago, I was somewhat placated by the fact that there was a long period of time still remaining that could result in lxc becoming a good replacement... now that we are getting closer to the wire, its becoming more obvious that this is not going to be the case. micah -- 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/87pqdz3la6@algae.riseup.net
Re: Outdated linux-2.6 backport
On Mon, 23 Jan 2012 16:30:29 +0100, Alexander Wirt formo...@formorer.de wrote: Ben Hutchings schrieb am Montag, den 23. Januar 2012: On Mon, 2012-01-23 at 08:16 +0100, Marcus Osdoba wrote: Am 18.01.2012 04:42, schrieb Ben Hutchings: cpufrequtils (007-2) A separate build-container for each architecture was used to be sure, that there are only stable packages installed. I reverted the compiler back to gcc 4.4. Cpufrequtils is needed for newer kernels to have the cpufreq modules work properly. I had forgotten that. Thanks. I have found linux-2.6 in the bpo upload Q today. Thanks for this. Please keep cpufrequtils-007-2 for kernels = 3.0 in mind. btw. regarding CVE-2012-0056 - feel free to upload after the fix hits unstable. I believe that 2.6.39 left unstable some time ago, to be replaced by 3.x, so I'm not sure how that will work exacty? micah pgpfOn8kCog8Y.pgp Description: PGP signature
Bug#638231: linux-image-2.6.32-5-686-bigmem: instability when using ext4
Package: linux-image-2.6.32-5-686-bigmem
Version: 2.6.32-35
Severity: important
Tags: squeeze
I have two machines that I upgraded to squeeze and migrated their ext3
filesystems to ext4 due to very high i/o and deep directory hierarchy. These two
machines have been crashing regularly since the ext4 upgrade. The other machines
that I have that are running the squeeze kernel and ext3 are not crashing at
all.
When I upgraded the two crashy machines to the backports kernel, the crashes
stopped. The crashes were happening at least 2x a week, sometimes much more
frequently. Since the upgrade to the BPO kernel, the machines haven't crashed
once in two months.
Both machines were showing console logs when they crashed that were similar:
either they had nothing on them at all, or they had the following (in some cases
magic-sysrq worked, sometimes it didn't).
It seems pretty clear to me that there are some instability issues with ext4
in the squeeze kernel. After discussion with Ted Tso on the subject, he
indicated
that there were a number of ext4 fixes that have been done that have not been
backported to the squeeze kernel.
What follows are a few of the different things we saw on the console when the
machine hung:
1.
hoopoe login: [51589.926858] Uniform Multi-Platform E-IDE driver
[51589.943819] ide-cd driver 5.00
[51589.982978] ide-gd driver 1.18
[51590.039277] st: Version 20081215, fixed bufsize 32768, s/g segs 256
[51590.262980] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[51590.269224] EDD information not available.
[137993.853645] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[137993.860140] EDD information not available.
[138361.949699] INFO: task rdiff-backup:28337 blocked for more than 120 seconds.
[138361.957345] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables
this message.
[138361.965791] rdiff-backup D f6967700 0 28337 28335 0x
[138361.972772] e8df2640 00200086 c5808e20 f6967700 f696772c c143de20 c143de20
c1439354
[138361.999573] e8df27fc c5808e20 c143de20 ea15f800 c5808e20 ea15f800
c127eb36
[138362.008374] c5804354 e8df27fc 020e12de c143de20 c143de20
[138362.034480] Call Trace:
[138362.037276] [c127eb36] ? schedule+0x78f/0x7dc
[138362.042407] [c127f28f] ? __mutex_lock_common+0xe8/0x13b
[138362.048233] [c127f2f1] ? __mutex_lock_slowpath+0xf/0x11
[138362.054239] [c127f382] ? mutex_lock+0x17/0x24
[138362.059403] [c127f382] ? mutex_lock+0x17/0x24
[138362.081061] [c10d40c5] ? sync_filesystems+0xf/0xbb
[138362.104668] [c10d41a3] ? sys_sync+0xe/0x29
[138362.109660] [c100813b] ? sysenter_do_call+0x12/0x28
2.
hoopoe login: [17163.173748] Uniform Multi-Platform E-IDE driver
[17163.187023] ide-cd driver 5.00
[17163.216390] ide-gd driver 1.18
[17163.269327] st: Version 20081215, fixed bufsize 32768, s/g segs 256
[17163.425212] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[17163.431412] EDD information not available.
[32426.998664] ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[32427.005956] ata4.00: failed command: WRITE FPDMA QUEUED
[32427.011225] ata4.00: cmd 61/08:00:57:a2:33/00:00:3a:00:00/40 tag 0 ncq 4096
out
[32427.011227] res 40/00:01:09:4f:c2/00:00:00:00:00/00 Emask 0x4
(timeout)
[32427.026096] ata4.00: status: { DRDY }
[32427.029818] ata4: hard resetting link
[32427.509533] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[32427.553582] ata4.00: configured for UDMA/133
[32427.557906] ata4: EH complete
3.
[16003.244636] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x18 action
0x6 frozen
[16003.252347] ata3.00: edma_err_cause=0020 pp_flags=,
SError=0018
[16003.259766] ata3: SError: { 10B8B Dispar }
[16003.263910] ata3.00: failed command: SMART
[16003.268082] ata3.00: cmd b0/d5:01:09:4f:c2/00:00:00:00:00/00 tag 0 pio
512 in
[16003.268083] res c0/00:01:09:4f:c2/00:00:00:00:00/00 Emask 0x12
(ATA bus error)
[16003.283450] ata3.00: status: { Busy }
[16008.800013] ata3: link is slow to respond, please be patient (ready=0)
[67924.593021] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x18 action
0x6 frozen
[67924.600848] ata3.00: edma_err_cause=0020 pp_flags=,
SError=0018
[67924.608344] ata3: SError: { 10B8B Dispar }
[67924.612512] ata3.00: failed command: SMART
[67924.616783] ata3.00: cmd b0/d5:01:09:4f:c2/00:00:00:00:00/00 tag 0 pio
512 in
[67924.616786] res c0/00:01:09:4f:c2/00:00:00:00:00/00 Emask 0x12
(ATA bus error)
[67924.632299] ata3.00: status: { Busy }
[67930.208513] ata3: link is slow to respond, please be patient (ready=0)
4.
] Call Trace:
[8.612001] [c1091433] ? drain_local_pages+0x0/0xb
[8.612001] [c1091433] ? drain_local_pages+0x0/0xb
[8.612001] [c105969e] ? smp_call_function+0x19/0x1f
[8.612001] [c103b677] ? on_each_cpu+0xc/0x24
[8.612001] [c1092a1f] ? __alloc_pages_nodemask+0x36e/0x4d9
[8.612001] [c1092b96] ? __get_free_pages+0xc/0x17
[8.612001]
Bug#605090: Updated patch
On Wed, 9 Feb 2011 18:51:02 +0100, maximilian attems m...@stro.at wrote: first of all merging a patch that deviates from mainline for an eternety and shows zero interest of upstream merging is not a good candidate. You get longterm plenty of cost versus allmost no benefit. There's no interest in upstreaming from grsec/pax teams but some other people are indeed interested in upstreaming those kind of features. In the meantime, having a featureset is a nice way to move along. That is a wrong look at the problem, once it's upstream everybody profits. So this looks more like a dead end road. So instead of having things that are nice, we should wait until upstream has them? Considering that SELinux is inside the kernel it be much better time investment to polish that. What makes you think that a Debian Hardened with proper SELinux wouldn't be really appreciated!? It would be. So would a proper grsecurity kernel. Third beside security theatre what is gained by it? I think the whole point of the “Grsecurity” patchset is “security”. I like the way you put it under brackets and think that security is gained by just applying this patchset. Can you show that grsecurity does not provide any additional security? Fourth why not invest the time for Wheezy and have finally the mainline and security backed SELinux ready. This seems like a much better time investment. Trying to push some bits upstream is indeed a good time investment (though it takes time and I really think moving forward now is a good idea). But Grsecurity isn't a drop-in replacement for SELinux. Some features like RBAC and auditing have some similarities, but all the hardening and memory protection really have nothing to do with that. Be more precise in what SELinux can't do for you? (Emulating NX for bad hardware doesn't count these days). For some SELinux is the right choice, for others grsecurity. Its obvious which you prefer, but not everyone is the same as you. Yves-Alexis is interested in doing the work on something that you do not want to do the work on, that seems like a good thing. micah pgpc8N0q6MwIa.pgp Description: PGP signature
Bug#603927: solved
It looks like the solution to this problem was to turn on ACPI in the BIOS, things boot fine again. Closing the bug, full details on xen-devel list. micah -- pgpvC6yiQl1QI.pgp Description: PGP signature
Bug#603927: linux-image-2.6.32-5-xen-686: booting with xen enabled fails to bring up ATA devices
Hi Ian, On Tue, 23 Nov 2010 13:23:41 +, Ian Campbell i...@hellion.org.uk wrote: I am assuming that this the same issue as you reported on xen-devel in the aic79xx failures with pvops dom0 2.6.32.25[0] / ATA driver failures with pvops dom0[1] thread recently? Indeed, I got some purchase with upstream Xen folks, and decided to keep discussing it there. I had meant to update this bug report once I had gotten something useful. If not please let me know otherwise I'll just monitor that thread, although please let this ticket know if you reach a resolution on the list. Sounds good, thanks for checking in! micah pgplfVD9XASIh.pgp Description: PGP signature
Bug#601625: linux-patch-debian-2.6.32: unapplying 18 fails
Package: linux-patch-debian-2.6.32 Version: 2.6.32-26 Severity: normal r...@cassowary:/usr/src/linux-source-2.6.32# /usr/src/kernel-patches/all/2.6.32/unpatch/debian all -- 19 fully unapplied. -- Try to unapply 18. (+) OK bugfix/all/3c59x-Fix-call-to-mdio_sync-with-the-wrong-argument.patch (+) OK debian/revert-x86-paravirt-Add-a-global-synchronization-point.patch (+) OK bugfix/all/sched-fix-over-scheduling-bug.patch (+) OK bugfix/x86/drm-i915-add-reclaimable-to-i915-self-reclaimable-pa.patch (+) OK features/all/rt28x0/0042-Staging-rt2860-add-Belkin-F5D8055-Wireless-N-USB-Don.patch (+) OK features/all/rt28x0/0041-Staging-rt2860-correct-onstack-wait_queue_head-decla.patch (+) OK features/all/rt28x0/0040-Staging-rt-2860-2870-sta-Use-request_firmware-to-loa.patch (+) OK features/all/rt28x0/0039-Staging-rt2870sta-constify-RTUSBMultiWrite-RTUSBFirm.patch (+) OK features/all/rt28x0/0038-Staging-rt2860-sta_ioctl.c-Two-branches-the-same-in-.patch (+) OK features/all/rt28x0/0037-Staging-rt2860-Use-skb_tail_pointer.patch (+) OK features/all/rt28x0/0036-Staging-rt2870-Remove-unnecessary-forward-declaratio.patch (+) OK features/all/rt28x0/0035-Staging-rt2870-rtusb_probe-should-be-in-section-__de.patch (+) OK features/all/rt28x0/0034-Staging-rt2860-test-off-by-one-in-RtmpAsicSendComman.patch (+) OK features/all/rt28x0/0033-Staging-rt28x0-remove-no-longer-needed-common-cmm_da.patch (+) OK features/all/rt28x0/0032-Staging-rt2860-reduce-superfluous-exclamation-marks.patch (+) OK features/all/rt28x0/0031-Staging-rt28x0-fix-comments-in-chip-mac_pci.h.patch (+) OK features/all/rt28x0/0030-Staging-rt2860-remove-superfluous-newlines.patch (+) OK features/all/rt28x0/0029-Staging-rt2860-remove-remainders-of-etc-reading-stuf.patch (+) OK features/all/rt28x0/0028-Staging-rt28x0-remove-typedefs-part-three.patch (+) OK features/all/rt28x0/0027-Staging-rt28x0-remove-typedefs-part-two.patch (+) OK features/all/rt28x0/0026-Staging-rt28x0-remove-typedefs-part-one.patch (+) OK features/all/rt28x0/0025-Staging-rt28x0-fix-comments-in-.h-files.patch (+) OK features/all/rt28x0/0024-Staging-rt28x0-fix-comments-in-sta-.c-files.patch (+) OK features/all/rt28x0/0023-Staging-rt28x0-fix-comments-in-common-.c-files.patch (+) OK features/all/rt28x0/0022-Staging-rt28x0-fix-comments-in-.c-files.patch (+) OK features/all/rt28x0/0021-Staging-rt28x0-run-.h-files-through-Lindent.patch (+) OK features/all/rt28x0/0020-Staging-rt28x0-run-sta-.c-files-through-Lindent.patch (+) OK features/all/rt28x0/0019-Staging-rt28x0-run-common-.c-files-through-Lindent.patch (+) OK features/all/rt28x0/0018-Staging-rt28x0-run-.c-files-through-Lindent.patch (+) OK features/all/rt28x0/0017-Staging-rt28x0-remove-__LINE__-instances.patch (+) OK features/all/rt28x0/0016-Staging-rt28x0-remove-dead-code.patch (+) OK features/all/rt28x0/0015-Staging-rt28x0-remove-unused-SHA256-code.patch (+) OK features/all/rt28x0/0014-Staging-rt28x0-remove-dead-code-from-rtmp_phy.h.patch (+) OK features/all/rt28x0/0013-Staging-rt28x0-remove-optional-cmm-profile-parameter.patch (+) OK features/all/rt28x0/0012-Staging-rt28x0-fix-some-build-warnings.patch (+) OK features/all/rt28x0/0011-Staging-rt28x0-remove-optional-loading-of-EEPROM-fro.patch (+) OK features/all/rt28x0/0010-Staging-rt28x0-remove-support-for-private-driver-par.patch (+) OK features/all/rt28x0/0009-Staging-rt28x0-remove-private-WEXT-handlers.patch (+) OK features/all/rt28x0/0008-Staging-rt28x0-remove-private-RTPRIV_IOCTL_GSITESURV.patch (+) OK features/all/rt28x0/0007-Staging-rt28x0-remove-private-RTPRIV_IOCTL_SET-ioctl.patch (+) OK features/all/rt28x0/0006-Staging-rt28x0-remove-unused-code-from-common-ee_efu.patch (+) OK features/all/rt28x0/0005-Staging-rt28x0-remove-unused-eewrite-methods.patch (X) FAIL features/all/rt28x0/remove-rt3090-driver.commands Error: -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-patch-debian-2.6.32 depends on: ii bzip2 1.0.5-6 high-quality block-sorting file co ii linux-support-2.6.32-5 2.6.32-26Support files for Linux 2.6.32 ii python 2.6.6-3+squeeze1 interactive high-level object-orie linux-patch-debian-2.6.32 recommends no packages. Versions of packages linux-patch-debian-2.6.32 suggests: ii linux-source-2.6.32 2.6.32-26 Linux kernel source for version 2. -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Bug#570382: after upgrade: vlogin: openpty(): No such file or directory
On Mon, 23 Aug 2010 21:56:17 +0200 (CEST), Tomas Pospisek t...@sourcepole.ch wrote: On a different note: the last update to the most recent DSA kernels [2] went completely smoothly - that is all vservers restarted without a hickup. Makes me wonder if that was caused by a change in the 2.6.26-24lenny1 kernel? We'll see at the next upgrade. I noticed this too, last DSA went perfectly. Before I would get at least one guest on each machine that would exhibit this problem, this time I got none. However, I *did* get one on my amd64 box. All the others were i386 micah pgpNLGDLqcRcL.pgp Description: PGP signature
Bug#570382: after upgrade: vlogin: openpty(): No such file or directory]
I can confirm that this manifested with the 2.6.26-21lenny3 security
upgrade in Feburary (DSA-1996). It seems like what happens is when the
system boots, it runs the /etc/init.d/util-vserver script, which
attempts to automatically start all the guests which have the 'default'
mark. Sometimes things are fine, sometimes some guests give the 'vlogin:
openpty()' error when you try to 'vserver guest enter' them. You also
will get an error trying to ssh to the guest, or anything else related
to pty.
Its not reliable which guests get this problem, sometimes its none of
them, sometimes its all of them. When you restart the machine, the only
thing you can do is attempt to enter each guest, and those which give
the openpty() problem, you need to issue a 'vserver guest stop;
vserver guest start' to get them back. This resolves it every time.
I looked to see if the guest has /dev/pts and /dev/ptmx when first
trying to enter it by doing:
vnamespace -e guest ls -l /vservers/guest/dev/{ptmx,pts}
this shows me that on an affected guests /dev/pts is empty, but has a
'0' on those that do not have a problem. The /dev/ptmx exists like
normal:
crw-rw-rw- 1 root root 5, 2 2006-11-10 16:07 /vservers/test/dev/ptmx
So the guests that have this problem have no /dev/pts/0, they have a
/dev/pts, just nothing in it. Typically /dev/pts/0 doesn't get created
until you do 'vserver guest enter' or use ssh to enter, or something
else allocates a tty. It seems like a 'vserver guest enter' doesn't
seem to be able to create it.
Looking at the /proc/mounts in the guest's namespace, with the
folliowing:
vnamespace -e guest cat /proc/mounts
I see this:
total 0
rootfs / rootfs rw 0 0
/dev/md0 / ext3 rw,errors=remount-ro,data=ordered 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
/dev/md1 /usr ext3 rw,errors=continue,data=ordered 0 0
/dev/md2 /var ext3 rw,errors=continue,data=ordered 0 0
/dev/loop3 /vservers ext3 rw,errors=continue,data=ordered 0 0
none /vservers/test/proc proc rw,nodev 0 0
/dev/loop3 /vservers/test ext3 rw,errors=continue,data=ordered 0 0
If I look at the way the initscript does the starting, I see that it is
invoked in the following way:
/usr/lib/util-vserver/vserver-wrapper start /dev/tty8 /dev/tty8 2/dev/tty8
Looking at /dev/tty8, i see a segfault in
/usr/lib/util-vserver/vserver.functions line 907. This is using the
lenny version of the user-space utilities (0.30.216~r2772-6), and line
907 is the opening curly brace as follows:
function _mountVserverInternal
{
Micah
pgpT4Z1zwWqgN.pgp
Description: PGP signature
Bug#576838: KVM: networking stack tanks after page allocation failure
On Sat, 10 Apr 2010 11:13:11 -0400, micah anderson mi...@debian.org wrote: On Sat, 10 Apr 2010 12:17:51 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2010-04-09 at 23:38 -0400, micah anderson wrote: On Sat, 10 Apr 2010 01:48:24 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2010-04-08 at 12:41 -0400, micah anderson wrote: On 2010-04-08, micah anderson wrote: On Wed, 2010-04-07 at 11:52 -0400, Micah Anderson wrote: Package: linux-image-2.6.32-2-amd64 Version: 2.6.32-8~bpo50+1 Severity: important I'm running a tor exit node on a kvm instance, it runs for a little while (between an hour and 3 days), doing 30-40mbit/sec and then suddenly 'swapper: page allocation failure' happens, and the entire networking stack of the kvm instance is dead. It stops responding on the net completely. No ping in or out, no traffic can be observed using tcpdump, the counters on the interface no longer change (although the interface stays up). [...] It sounds like there might be a memory leak. Please send the contents of /proc/meminfo and /proc/slabinfo from a 'normal' state and the broken state. I noticed this time when it crashed something different that I had not seen in previous 2.6.30/2.6.26 kernels: [ 7962.841287] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [ 7962.841287] cache: kmalloc-1024, object size: 1024, buffer size: 1024, default order: 1, min order: 0 [ 7962.841287] node 0: slabs: 606, objs: 4544, free: 0 and then the normal: [ 7963.102476] swapper: page allocation failure. order:0, mode:0x4020 [ 7963.105743] Pid: 0, comm: swapper Not tainted 2.6.32-bpo.2-amd64 #1 [ 7963.106418] Call Trace: [ 7963.106418] IRQ [810b947d] ? __alloc_pages_nodemask+0x55b/0x5ce etc. As requested here is a normal state /proc/meminfo and /proc/slabinfo. See below for the broken state [...] There's no sign of a memory leak and there's actually much more free memory in the broken state, perhaps because any network servers have lost all their clients and freed session state. My guess is that the driver just doesn't handle allocation failure gracefully. Which network driver are you using in the guest? I started with virtio, but had a hunch that maybe switching to e100e might be more stable, but sadly both produce the same results. [...] There's no such thing as e100e - Linux has e100, e1000 and e1000e drivers; QEMU only emulates e1000. Please run lsmod inside the guest to check what's really being used. Indeed... it looks like regardless if I have specified 'e100e' in the domain.xml, its ignoring that failure and providing me with: virtio_net 10433 0 virtio 3277 5 virtio_rng,virtio_balloon,virtio_net,virtio_blk,virtio_pci The host is running: e1000e109487 0 So i guess I can try that... Ok, I've been testing this for a couple of weeks now, and I can now say, with confidence, that the virtio net driver seems to be the culprit. When I run with the e1000e driver, I do not get this page fault at all. So that is a good work-around, but not a solution. It seems as if Redhat encountered and fixed this bug back in January: https://bugzilla.redhat.com/show_bug.cgi?id=554078 micah pgp6XiIn1HSzW.pgp Description: PGP signature
Bug#576838: KVM: networking stack tanks after page allocation failure
On Sat, 10 Apr 2010 12:17:51 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2010-04-09 at 23:38 -0400, micah anderson wrote: On Sat, 10 Apr 2010 01:48:24 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2010-04-08 at 12:41 -0400, micah anderson wrote: On 2010-04-08, micah anderson wrote: On Wed, 2010-04-07 at 11:52 -0400, Micah Anderson wrote: Package: linux-image-2.6.32-2-amd64 Version: 2.6.32-8~bpo50+1 Severity: important I'm running a tor exit node on a kvm instance, it runs for a little while (between an hour and 3 days), doing 30-40mbit/sec and then suddenly 'swapper: page allocation failure' happens, and the entire networking stack of the kvm instance is dead. It stops responding on the net completely. No ping in or out, no traffic can be observed using tcpdump, the counters on the interface no longer change (although the interface stays up). [...] It sounds like there might be a memory leak. Please send the contents of /proc/meminfo and /proc/slabinfo from a 'normal' state and the broken state. I noticed this time when it crashed something different that I had not seen in previous 2.6.30/2.6.26 kernels: [ 7962.841287] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [ 7962.841287] cache: kmalloc-1024, object size: 1024, buffer size: 1024, default order: 1, min order: 0 [ 7962.841287] node 0: slabs: 606, objs: 4544, free: 0 and then the normal: [ 7963.102476] swapper: page allocation failure. order:0, mode:0x4020 [ 7963.105743] Pid: 0, comm: swapper Not tainted 2.6.32-bpo.2-amd64 #1 [ 7963.106418] Call Trace: [ 7963.106418] IRQ [810b947d] ? __alloc_pages_nodemask+0x55b/0x5ce etc. As requested here is a normal state /proc/meminfo and /proc/slabinfo. See below for the broken state [...] There's no sign of a memory leak and there's actually much more free memory in the broken state, perhaps because any network servers have lost all their clients and freed session state. My guess is that the driver just doesn't handle allocation failure gracefully. Which network driver are you using in the guest? I started with virtio, but had a hunch that maybe switching to e100e might be more stable, but sadly both produce the same results. [...] There's no such thing as e100e - Linux has e100, e1000 and e1000e drivers; QEMU only emulates e1000. Please run lsmod inside the guest to check what's really being used. Indeed... it looks like regardless if I have specified 'e100e' in the domain.xml, its ignoring that failure and providing me with: virtio_net 10433 0 virtio 3277 5 virtio_rng,virtio_balloon,virtio_net,virtio_blk,virtio_pci The host is running: e1000e109487 0 So i guess I can try that... micah pgpzTKkr0wR8q.pgp Description: PGP signature
Bug#576838: KVM: networking stack tanks after page allocation failure
On Sat, 10 Apr 2010 01:48:24 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2010-04-08 at 12:41 -0400, micah anderson wrote: On 2010-04-08, micah anderson wrote: On Wed, 2010-04-07 at 11:52 -0400, Micah Anderson wrote: Package: linux-image-2.6.32-2-amd64 Version: 2.6.32-8~bpo50+1 Severity: important I'm running a tor exit node on a kvm instance, it runs for a little while (between an hour and 3 days), doing 30-40mbit/sec and then suddenly 'swapper: page allocation failure' happens, and the entire networking stack of the kvm instance is dead. It stops responding on the net completely. No ping in or out, no traffic can be observed using tcpdump, the counters on the interface no longer change (although the interface stays up). [...] It sounds like there might be a memory leak. Please send the contents of /proc/meminfo and /proc/slabinfo from a 'normal' state and the broken state. I noticed this time when it crashed something different that I had not seen in previous 2.6.30/2.6.26 kernels: [ 7962.841287] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [ 7962.841287] cache: kmalloc-1024, object size: 1024, buffer size: 1024, default order: 1, min order: 0 [ 7962.841287] node 0: slabs: 606, objs: 4544, free: 0 and then the normal: [ 7963.102476] swapper: page allocation failure. order:0, mode:0x4020 [ 7963.105743] Pid: 0, comm: swapper Not tainted 2.6.32-bpo.2-amd64 #1 [ 7963.106418] Call Trace: [ 7963.106418] IRQ [810b947d] ? __alloc_pages_nodemask+0x55b/0x5ce etc. As requested here is a normal state /proc/meminfo and /proc/slabinfo. See below for the broken state [...] There's no sign of a memory leak and there's actually much more free memory in the broken state, perhaps because any network servers have lost all their clients and freed session state. My guess is that the driver just doesn't handle allocation failure gracefully. Which network driver are you using in the guest? I started with virtio, but had a hunch that maybe switching to e100e might be more stable, but sadly both produce the same results. Here is the domain.xml: domain type='kvm' namewagtail.example.net/name uuidcfdd8232-be2f-4ac5-9cbd-dbc6f6956d77/uuid memory524 288/memory currentMemory524 288/currentMemory vcpu1/vcpu os type arch='x86_64' machine='pc'hvm/type boot dev='hd'/ boot dev='cdrom'/ /os features acpi/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/bin/kvm/emulator disk type='file' device='cdrom' source file='/root/grub-rescue/grub-rescue.iso'/ target dev='hdc' bus='ide'/ readonly/ /disk disk type='block' device='disk' source dev='/dev/disk/by-id/dm-name-khyber-micah_wagtail.example.net'/ target dev='vda' bus='virtio'/ /disk interface type='ethernet' mac address='52:54:00:43:ae:3d'/ target dev='wagtail'/ script path='/bin/true'/ model type='e100e'/ /interface serial type='pty' target port='0'/ /serial serial type='unix' source mode='bind' path='/home/micah/wagtail.example.net/ttyS1'/ target port='1'/ /serial console type='pty' target port='0'/ /console graphics type='vnc' autoport='true'/ /devices /domain pgprGti0PXun0.pgp Description: PGP signature
Bug#576838: KVM: networking stack tanks after page allocation failure
On 2010-04-08, micah anderson wrote: On Wed, 2010-04-07 at 11:52 -0400, Micah Anderson wrote: Package: linux-image-2.6.32-2-amd64 Version: 2.6.32-8~bpo50+1 Severity: important I'm running a tor exit node on a kvm instance, it runs for a little while (between an hour and 3 days), doing 30-40mbit/sec and then suddenly 'swapper: page allocation failure' happens, and the entire networking stack of the kvm instance is dead. It stops responding on the net completely. No ping in or out, no traffic can be observed using tcpdump, the counters on the interface no longer change (although the interface stays up). [...] It sounds like there might be a memory leak. Please send the contents of /proc/meminfo and /proc/slabinfo from a 'normal' state and the broken state. I noticed this time when it crashed something different that I had not seen in previous 2.6.30/2.6.26 kernels: [ 7962.841287] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [ 7962.841287] cache: kmalloc-1024, object size: 1024, buffer size: 1024, default order: 1, min order: 0 [ 7962.841287] node 0: slabs: 606, objs: 4544, free: 0 and then the normal: [ 7963.102476] swapper: page allocation failure. order:0, mode:0x4020 [ 7963.105743] Pid: 0, comm: swapper Not tainted 2.6.32-bpo.2-amd64 #1 [ 7963.106418] Call Trace: [ 7963.106418] IRQ [810b947d] ? __alloc_pages_nodemask+0x55b/0x5ce etc. As requested here is a normal state /proc/meminfo and /proc/slabinfo. See below for the broken state r...@wagtail:~# cat /proc/meminfo MemTotal: 251280 kB MemFree: 70280 kB Buffers:2292 kB Cached:87936 kB SwapCached:11324 kB Active: 103808 kB Inactive: 44656 kB Active(anon): 37576 kB Inactive(anon):20680 kB Active(file): 66232 kB Inactive(file):23976 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2093048 kB SwapFree:2077516 kB Dirty:12 kB Writeback: 0 kB AnonPages: 50536 kB Mapped: 7244 kB Shmem:20 kB Slab: 21112 kB SReclaimable: 5432 kB SUnreclaim:15680 kB KernelStack: 408 kB PageTables: 1060 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit: 2218688 kB Committed_AS: 56024 kB VmallocTotal: 34359738367 kB VmallocUsed:3876 kB VmallocChunk: 34359726560 kB HardwareCorrupted: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB DirectMap4k:8172 kB DirectMap2M: 253952 kB r...@wagtail:~# cat /proc/slabinfo slabinfo - version: 2.1 # nameactive_objs num_objs objsize objperslab pagesperslab : tunables limit batchcount sharedfactor : slabdata active_slabs num_slabs sharedavail ext3_inode_cache1750 1750792 102 : tunables000 : slabdata175175 0 ext3_xattr 0 0 88 461 : tunables000 : slabdata 0 0 0 journal_handle 170170 24 1701 : tunables000 : slabdata 1 1 0 journal_head 36 36112 361 : tunables000 : slabdata 1 1 0 revoke_table 256256 16 2561 : tunables000 : slabdata 1 1 0 revoke_record128128 32 1281 : tunables000 : slabdata 1 1 0 dm_raid1_read_record 0 0 1064 154 : tunables000 : slabdata 0 0 0 kcopyd_job 0 0368 111 : tunables000 : slabdata 0 0 0 dm_uevent 0 0 2608 128 : tunables000 : slabdata 0 0 0 dm_rq_target_io0 0376 212 : tunables000 : slabdata 0 0 0 dm_io614714 40 1021 : tunables000 : slabdata 7 7 0 ip6_dst_cache 19 24320 121 : tunables000 : slabdata 2 2 0 UDPLITEv6 0 096082 : tunables000 : slabdata 0 0 0 UDPv6 8 896082 : tunables000 : slabdata 1 1 0 tw_sock_TCPv6 12 12320 121 : tunables000 : slabdata 1 1 0 TCPv6 9 9 179294 : tunables000 : slabdata 1 1 0 cfq_queue 36 48168 241 : tunables000 : slabdata 2 2 0 bsg_cmd0 0312 131 : tunables000 : slabdata 0 0 0 mqueue_inode_cache 9 989692 : tunables000 : slabdata 1 1 0 hugetlbfs_inode_cache
Bug#576838: KVM: networking stack tanks after page allocation failure
Package: linux-image-2.6.32-2-amd64 Version: 2.6.32-8~bpo50+1 Severity: important I'm running a tor exit node on a kvm instance, it runs for a little while (between an hour and 3 days), doing 30-40mbit/sec and then suddenly 'swapper: page allocation failure' happens, and the entire networking stack of the kvm instance is dead. It stops responding on the net completely. No ping in or out, no traffic can be observed using tcpdump, the counters on the interface no longer change (although the interface stays up). To get things back, I have to restart the kvm instance, no amount of module reloading, networking reconfiguring will bring things back, it is one unhappy camper. No, there is no firewall involved. Hardware has been replaced, in case that is the issue, but so far nothing has improved. This is a stable system, it was running the stable kernel, but in an effort to resolve this problem we've bumped up the kernel rev to use the backported 2.6.32-2 linux-image package on both the host system as well as the kvm guest. The host is running qemu-kvm 0.12.3+dfsg-4~bpo50+1. This is what the interface looks like when it is down: eth0 Link encap:Ethernet HWaddr 52:54:00:43:ae:3d inet addr:77.109.139.87 Bcast:77.109.139.95 Mask:255.255.255.240 inet6 addr: 2001:1620:2018:2::4d6d:8b57/64 Scope:Global inet6 addr: fe80::5054:ff:fe43:ae3d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12059348 errors:0 dropped:0 overruns:0 frame:0 TX packets:12971887 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8170402534 (7.6 GiB) TX bytes:8712200168 (8.1 GiB) There is a kernel crash that is produced everytime, here is a copy of one of them: [ 3072.359063] swapper: page allocation failure. order:0, mode:0x20 [ 3072.361787] Pid: 0, comm: swapper Not tainted 2.6.32-bpo.2-amd64 #1 [ 3072.363844] Call Trace: [ 3072.366282] IRQ [810b947d] ? __alloc_pages_nodemask+0x55b/0x5ce [ 3072.369134] [8123c244] ? __alloc_skb+0x69/0x15a [ 3072.370758] [a01ffe52] ? try_fill_recv+0x8b/0x18b [virtio_net] [ 3072.373234] [a02008ca] ? virtnet_poll+0x543/0x5c9 [virtio_net] [ 3072.375757] [81012ffa] ? do_IRQ+0xa0/0xb6 [ 3072.377212] [812432c7] ? net_rx_action+0xae/0x1c9 [ 3072.378481] [81053979] ? __do_softirq+0xdd/0x1a0 [ 3072.379939] [a01ff153] ? skb_recv_done+0x28/0x34 [virtio_net] [ 3072.381612] [81011cac] ? call_softirq+0x1c/0x30 [ 3072.383547] [81013903] ? do_softirq+0x3f/0x7c [ 3072.384691] [810537e8] ? irq_exit+0x36/0x76 [ 3072.385776] [81012ffa] ? do_IRQ+0xa0/0xb6 [ 3072.387341] [810114d3] ? ret_from_intr+0x0/0x11 [ 3072.388578] EOI [8102c568] ? native_safe_halt+0x2/0x3 [ 3072.390608] [81017cb9] ? default_idle+0x34/0x51 [ 3072.391869] [8100fe90] ? cpu_idle+0xa2/0xda [ 3072.393453] [814d4140] ? early_idt_handler+0x0/0x71 [ 3072.394749] [814d4cd7] ? start_kernel+0x3d0/0x3dc [ 3072.396820] [814d43b7] ? x86_64_start_kernel+0xf9/0x106 [ 3072.398280] Mem-Info: [ 3072.398935] Node 0 DMA per-cpu: [ 3072.399933] CPU0: hi:0, btch: 1 usd: 0 [ 3072.401066] Node 0 DMA32 per-cpu: [ 3072.402484] CPU0: hi: 90, btch: 15 usd: 92 [ 3072.403969] active_anon:22648 inactive_anon:22730 isolated_anon:0 [ 3072.403971] active_file:526 inactive_file:461 isolated_file:0 [ 3072.403972] unevictable:0 dirty:0 writeback:0 unstable:0 [ 3072.403973] free:414 slab_reclaimable:1417 slab_unreclaimable:7837 [ 3072.403974] mapped:796 shmem:4 pagetables:626 bounce:0 [ 3072.411252] Node 0 DMA free:984kB min:120kB low:148kB high:180kB active_anon:5720kB inactive_anon:5864kB active_file:204kB inactive_file:168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15368kB mlocked:0kB dirty:0kB writeback:0kB mapped:308kB shmem:4kB slab_reclaimable:80kB slab_unreclaimable:2100kB kernel_stack:8kB pagetables:280kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:128 all_unreclaimable? no [ 3072.419404] lowmem_reserve[]: 0 236 236 236 [ 3072.420993] Node 0 DMA32 free:672kB min:1904kB low:2380kB high:2856kB active_anon:84872kB inactive_anon:85056kB active_file:1900kB inactive_file:1676kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:242380kB mlocked:0kB dirty:0kB writeback:0kB mapped:2876kB shmem:12kB slab_reclaimable:5588kB slab_unreclaimable:29248kB kernel_stack:480kB pagetables:2224kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 3072.429732] lowmem_reserve[]: 0 0 0 0 [ 3072.431042] Node 0 DMA: 10*4kB 0*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 984kB [ 3072.434088] Node 0 DMA32:
Bug#504805: anoher iret exception
[136556.763720] iret exception: [#1] SMP [136556.763803] Modules linked in: xt_tcpudp xt_physdev iptable_filter ip_tables x_tables tun netloop bridge ipv6 loop serio_raw psmouse container pcspkr button i2c_i801 intel_rng i2c_core rng_core shpchp e7xxx_edac pci_hotplug edac_core joydev evdev ext3 jbd mbcache serpent xts gf128mul dm_crypt crypto_blkcipher dm_mirror dm_log dm_snapshot dm_mod raid1 md_mod ide_cd_mod cdrom ide_disk ata_generic libata dock ide_pci_generic usbhid hid ff_memless floppy piix ide_core aic79xx scsi_transport_spi scsi_mod e1000 uhci_hcd usbcore thermal processor fan thermal_sys [last unloaded: scsi_wait_scan] [136556.764787] [136556.764821] Pid: 0, comm: swapper Not tainted (2.6.26-2-xen-686 #1) [136556.764868] EIP: 0061:[ee11f12d] EFLAGS: 0286 CPU: 0 [136556.764935] EIP is at ide_outb+0x4/0x5 [ide_core] [136556.764979] EAX: 00f0 EBX: c0389e74 ECX: ee1304f0 EDX: 01f6 [136556.765021] ESI: ee1302c0 EDI: ee1302d8 EBP: ee1304f0 ESP: c0389e24 [136556.765063] DS: 007b ES: 007b FS: 00d8 GS: SS: 0069 [136556.765105] Process swapper (pid: 0, ti=c0388000 task=c035a1a0 task.ti=c0388000) [136556.765150] Stack: ee11f3c4 ee1304ec ee11f129 0056090c c0389e74 ee1304ec ee1302c0 ee125320 [136556.765329]ee12280d c0389e74 c0389e94 ee1304ec ee0c7e49 ee1304ec [136556.765488]e9d39ef8 00080140 0001 ee1302c0 0100 3defaf08 3500 [136556.765638] Call Trace: [136556.765703] [ee11f3c4] ide_tf_load+0x161/0x169 [ide_core] [136556.765775] [ee11f129] ide_outb+0x0/0x5 [ide_core] [136556.765854] [ee12280d] do_rw_taskfile+0x58/0x1d3 [ide_core] [136556.765932] [ee0c7e49] ide_do_rw_disk+0x208/0x258 [ide_disk] [136556.766016] [ee11df05] ide_do_request+0x634/0x847 [ide_core] [136556.766099] [ee11d58c] ide_end_request+0x56/0x5f [ide_core] [136556.766175] [ee121f2b] task_end_request+0x40/0x51 [ide_core] [136556.766252] [ee11e3ab] ide_intr+0x1a1/0x1c8 [ide_core] [136556.766336] [c0149995] handle_IRQ_event+0x36/0x6e [136556.766427] [c014aaa9] handle_level_irq+0x90/0xed [136556.766493] [c0105b00] do_IRQ+0x4d/0x65 [136556.766556] [c023d747] evtchn_do_upcall+0xfa/0x191 [136556.766619] [c010412c] hypervisor_callback+0x3c/0x44 [136556.766706] [c0105f52] xen_safe_halt+0x9f/0xb3 [136556.766768] [c01028ab] xen_idle+0x1b/0x46 [136556.766814] [c0102810] cpu_idle+0xa8/0xc0 [136556.766879] === [136556.766918] Code: 03 83 fe f0 b8 2a 5e 12 ee ba 1b 5e 12 ee 0f 45 d0 89 d8 e8 1c f3 ff ff 89 07 59 89 f0 5b 5e 5f c3 0f b6 c0 88 02 c3 0f b6 c0 ee c3 55 89 cd 57 56 53 83 ec 08 8b 50 2c 8a 40 62 8b 5c 24 1c 8b [136556.767747] EIP: [ee11f12d] ide_outb+0x4/0x5 [ide_core] SS:ESP 0069:c0389e24 [136556.767747] Kernel panic - not syncing: Fatal exception in interrupt (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504805: some more crash logs
Excerpts from micah anderson's message of Tue Nov 24 20:20:51 -0500 2009: Excerpts from Ben Hutchings's message of Tue Nov 24 18:51:45 -0500 2009: On Tue, 2009-11-24 at 18:17 -0500, micah anderson wrote: I keep getting them, so I'll keep sending them: Which kernel version are you using? Version 2.6.26-20 in stable-proposed-updates fixes a crash bug in xen_spin_wait(), though I don't think that accounts for all of the crashes you're seeing. linux-image-2.6.26-2-xen-686 2.6.26-19lenny2 along with xen-linux-system-2.6.26-2-xen-686 2.6.26-19lenny2 I can give the SPU kernel a try, wouldn't hurt. Sadly, that wasn't a magic bullet, two machines went down last night (both nodes of a fail-over cluster too, ouch). I was only able to capture the console output of one of them. This one doesn't seem to mention iret exceptions: (XEN) domain_crash_sync called from entry.S (ff188600) (XEN) Domain 0 (vcpu#2) crashed on cpu#2: (XEN) [ Xen-3.2-1 x86_32p debug=n Not tainted ] (XEN) CPU:2 (XEN) EIP:0061:[c01013a7] (XEN) EFLAGS: 0246 CONTEXT: guest (XEN) eax: ebx: 0001 ecx: edx: ed449f90 (XEN) esi: 0002 edi: 0002 ebp: esp: ed449f84 (XEN) cr0: 8005003b cr4: 06f0 cr3: 001ddc80 cr2: b7fdadbd (XEN) ds: 007b es: 007b fs: 00d8 gs: ss: 0069 cs: 0061 (XEN) Guest stack trace from esp=ed449f84: (XEN)c0105f52 0002 61b0bd7a 1dfa (XEN)c01028ab c0102810 (XEN) 00d8 (XEN) ed43e880 (XEN)c035c460 0003 c0126f1a (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. micah signature.asc Description: PGP signature
Bug#504805: some more crash logs
I keep getting them, so I'll keep sending them: [366904.120247] iret exception: [#1] SMP [366904.120332] Modules linked in: xt_tcpudp xt_physdev iptable_filter ip_tables x_tables tun netloop bridge ipv6 loop serio_raw i2c_i801 psmouse intel_rng rng_core i2c_core pcspkr container button shpchp pci_hotplug e7xxx_edac edac_core joydev evdev ext3 jbd mbcache serpent xts gf128mul dm_crypt crypto_blkcipher dm_mirror dm_log dm_snapshot dm_mod raid1 md_mod ide_disk ide_cd_mod cdrom ata_generic libata dock ide_pci_generic usbhid hid ff_memless floppy e1000 piix ide_core aic79xx scsi_transport_spi scsi_mod uhci_hcd usbcore thermal processor fan thermal_sys [last unloaded: scsi_wait_scan] [366904.120449] [366904.120449] Pid: 0, comm: swapper Not tainted (2.6.26-2-xen-686 #1) [366904.120449] EIP: 0061:[c01013a7] EFLAGS: 0046 CPU: 1 [366904.120506] EIP is at 0xc01013a7 [366904.120506] EAX: EBX: 0003 ECX: ed467f04 EDX: 00014c92 [366904.120506] ESI: 0106 EDI: ed467f14 EBP: c1536b40 ESP: ed467f00 [366904.120506] DS: 007b ES: 007b FS: 00d8 GS: SS: 0069 [366904.120506] Process swapper (pid: 0, ti=ed466000 task=ed45f0c0 task.ti=ed466000) [366904.120506] Stack: c023d022 ed467f14 0001 ce5fd739 00014c92 0007 c153672c 00da [366904.120506]c023f80f dad9 c1536b40 dad9 0001 ed45f0c0 c02cbd87 c1536b40 [366904.120506] c02ca34a ed467f4c 0001 ed45f24c c1536b40 0001 [366904.120506] Call Trace: [366904.120506] [c023d022] xen_poll_irq+0x57/0x65 [366904.120506] [c023f80f] xen_spin_wait+0xcb/0xff [366904.120506] [c02cbd87] _spin_lock+0x31/0x38 [366904.120506] [c02ca34a] schedule+0xc6/0x6b1 [366904.120506] [c0105f52] xen_safe_halt+0x9f/0xb3 [366904.120506] [c0102826] cpu_idle+0xbe/0xc0 [366904.120506] === [366904.120506] Code: cc cc cc cc b8 1c 00 00 00 cd 82 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 1d 00 00 00 cd 82 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [366904.120506] EIP: [c01013a7] 0xc01013a7 SS:ESP 0069:ed467f00 [366904.122516] [ cut here ] [366904.122642] kernel BUG at drivers/xen/core/spinlock.c:69! [366904.122765] invalid opcode: [#2] SMP [366904.123089] Modules linked in: guillemot kernel: [366904.120247] iret exception: [#1] SMP xt_tcpudp xt_physdev iptable_filter ip_tables x_tables tun netloop bridge ipv6 loop serio_raw i2c_i801 psmouse intel_rng rng_core i2c_core pcspkr container button shpchp pci_hotplug e7xxx_edac edac_core joydev evdev ext3 jbd mbcache serpent xts gf128mul dm_crypt crypto_blkcipher dm_mirror dm_log dm_snapshot dm_mod raid1 md_mod ide_disk ide_cd_mod cdrom ata_generic libata dock ide_pci_generic usbhid hid ff_memless floppy e1000 piix ide_core aic79xx scsi_transport_spi scsi_mod uhci_hcd usbcore thermal processor fan thermal_sys [last unloaded: scsi_wait_scan] [366904.123229] [366904.123232] Pid: 0, comm: swapper Tainted: G D (2.6.26-2-xen-686 #1) [366904.123236] EIP: 0061:[c023f77b] EFLAGS: 00010046 CPU: 1 [366904.123242] EIP is at xen_spin_wait+0x37/0xff [366904.123244] EAX: c1536b40 EBX: c153672c ECX: 01177000 EDX: dbda [366904.123247] ESI: 0106 EDI: EBP: c1536b40 ESP: ed467ca0 [366904.123249] DS: 007b ES: 007b FS: 00d8 GS: SS: 0069 [366904.123252] Process swapper (pid: 0, ti=ed466000 task=ed45f0c0 task.ti=ed466000) [366904.123254] Stack: dbda c1536b40 dbda 0001 c02cbd87 c1536b40 [366904.123260]c011bef0 ed45f0c0 0001 0002 003d0900 c0106987 [366904.123265]007a1200 c03bb050 003d0900 00871b88 [366904.123271] Call Trace: [366904.123279] [c02cbd87] _spin_lock+0x31/0x38 [366904.123287] [c011bef0] scheduler_tick+0x39/0xd4 [366904.123301] [c0106987] timer_interrupt+0x57a/0x59c [366904.123323] [c022d37b] notify_update+0x1f/0x22 [366904.123355] [c0149949] handle_IRQ_event+0x36/0x6e [366904.123367] [c014aa5d] handle_level_irq+0x90/0xed [366904.123376] [c0105b00] do_IRQ+0x4d/0x65 [366904.123385] [c023d76f] evtchn_do_upcall+0xfa/0x191 [366904.123400] [c010412c] hypervisor_callback+0x3c/0x44 [366904.123434] [c023cc81] force_evtchn_callback+0xa/0xc [366904.123444] [c0104a9d] die+0x15e/0x1a1 [366904.123455] [c0104b9d] do_iret_error+0x0/0x89 [366904.124148] [c0104c1d] do_iret_error+0x80/0x89 [366904.124170] [c011fbe4] profile_tick+0x43/0x5e [366904.124181] [c010699c] timer_interrupt+0x58f/0x59c (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. and then another: XEN) domain_crash_sync called from entry.S (ff188600) (XEN) Domain 0 (vcpu#3) crashed on cpu#1: (XEN) [ Xen-3.2-1 x86_32p debug=n Not tainted ] (XEN) CPU:1 (XEN) EIP:0061:[c01013a7] (XEN) EFLAGS: 0246 CONTEXT: guest (XEN) eax: ebx: 0001 ecx: edx: ed44bf90 (XEN) esi: 0003 edi: 0003 ebp:
Bug#504805: some more crash logs
Excerpts from Ben Hutchings's message of Tue Nov 24 18:51:45 -0500 2009: On Tue, 2009-11-24 at 18:17 -0500, micah anderson wrote: I keep getting them, so I'll keep sending them: Which kernel version are you using? Version 2.6.26-20 in stable-proposed-updates fixes a crash bug in xen_spin_wait(), though I don't think that accounts for all of the crashes you're seeing. linux-image-2.6.26-2-xen-686 2.6.26-19lenny2 along with xen-linux-system-2.6.26-2-xen-686 2.6.26-19lenny2 I can give the SPU kernel a try, wouldn't hurt. micah signature.asc Description: PGP signature
Bug#504805: Changed hardware, still happening
Hi, Yesterday we completely swapped the entire machine, where this was happening, with another identical machine. We just took the disks out of the one that had been crashing and put them into this other machine. Today, on the new hardware, it crashed again: [64631.057499] iret exception: [#1] SMP [64631.057567] Modules linked in: xt_tcpudp xt_physdev iptable_filter ip_tables x_tables tun netloop bridge ipv6 loop serio_raw psmouse pcspkr i2c_i801 i2c_core intel_rng rng_core container button e7xxx_edac shpchp pci_hotplug edac_core joydev evdev ext3 jbd mbcache serpent xts gf128mul dm_crypt crypto_blkcipher dm_mirror dm_log dm_snapshot dm_mod raid1 md_mod ide_cd_mod cdrom ide_disk ata_generic libata dock ide_pci_generic usbhid hid ff_memless floppy aic79xx scsi_transport_spi scsi_mod piix ide_core uhci_hcd usbcore e1000 thermal processor fan thermal_sys [last unloaded: scsi_wait_scan] [64631.058548] [64631.058548] Pid: 0, comm: swapper Not tainted (2.6.26-2-xen-686 #1) [64631.058548] EIP: 0061:[c0101427] EFLAGS: 0086 CPU: 0 [64631.058548] EIP is at 0xc0101427 [64631.058548] EAX: EBX: 000c ECX: c0389f1c EDX: f5656000 [64631.058548] ESI: 0037 EDI: ec4975e0 EBP: c03796f0 ESP: c0389f0c [64631.058548] DS: 007b ES: 007b FS: 00d8 GS: SS: 0069 [64631.058548] Process swapper (pid: 0, ti=c0388000 task=c035a1a0 task.ti=c0388000) [64631.058548] Stack: c023cf54 0037 ec4975e0 0037 c03796c0 c03796c0 0037 [64631.058548]ec4975e0 c014aa96 14a0 c03796c0 0037 c0105b00 [64631.058548]0001 001f c023d76f 0020 0002 f5656000 f5656000 [64631.058548] Call Trace: [64631.058548] [c023cf54] startup_pirq+0xe6/0xef [64631.058548] [c014aa96] handle_level_irq+0xc9/0xed [64631.058548] [c0105b00] do_IRQ+0x4d/0x65 [64631.058548] [c023d76f] evtchn_do_upcall+0xfa/0x191 [64631.058548] [c010412c] hypervisor_callback+0x3c/0x44 [64631.058548] [c0105f52] xen_safe_halt+0x9f/0xb3 [64631.058548] [c01028ab] xen_idle+0x1b/0x46 [64631.058548] [c0102810] cpu_idle+0xa8/0xc0 [64631.058548] === [64631.058548] Code: cc cc cc cc b8 20 00 00 00 cd 82 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 21 00 00 00 cd 82 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [64631.058548] EIP: [c0101427] 0xc0101427 SS:ESP 0069:c0389f0c [64631.058548] Kernel panic - not syncing: Fatal exception in interrupt (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504805: Another crash
(XEN) domain_crash_sync called from entry.S (ff188600) (XEN) Domain 0 (vcpu#1) crashed on cpu#0: (XEN) [ Xen-3.2-1 x86_32p debug=n Not tainted ] (XEN) CPU:0 (XEN) EIP:0061:[c01013a7] (XEN) EFLAGS: 0246 CONTEXT: guest (XEN) eax: ebx: 0001 ecx: edx: ed467f90 (XEN) esi: 0001 edi: 0001 ebp: esp: ed467f84 (XEN) cr0: 8005003b cr4: 06f0 cr3: 00be2c80 cr2: b7dea7b0 (XEN) ds: 007b es: 007b fs: 00d8 gs: ss: 0069 cs: 0061 (XEN) Guest stack trace from esp=ed467f84: (XEN)c0105f52 0001 3159ccca 6026 (XEN)c01028ab c0102810 (XEN) 00d8 (XEN) (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. micah -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504805: and another....
Can I provide more information, or is there anything else I can do to help fix this? (XEN) domain_crash_sync called from entry.S (ff188600) (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) [ Xen-3.2-1 x86_32p debug=n Not tainted ] (XEN) CPU:0 (XEN) EIP:0061:[c01013a7] (XEN) EFLAGS: 0246 CONTEXT: guest (XEN) eax: ebx: 0001 ecx: edx: c0389fc8 (XEN) esi: edi: ebp: esp: c0389fbc (XEN) cr0: 8005003b cr4: 06f0 cr3: 001dec80 cr2: bfba0a10 (XEN) ds: 007b es: 007b fs: 00d8 gs: ss: 0069 cs: 0061 (XEN) Guest stack trace from esp=c0389fbc: (XEN)c0105f52 c05669bb 9b7f 0020 (XEN)c01028ab c0102810 0020 c20ee000 c038f88b c03ac580 0002080b (XEN) c038f5c3 c038f5cb c038f5d3 c0102374 c010263c c01027c8 c0102981 (XEN)c0102fd7 c0102ff8 c0103480 c0103520 c0103609 c0103a81 c0103b3d c0103bfa (XEN)c0103c59 c0103d03 c01042f9 c010430c c0104332 c010433f c01043db c0104999 (XEN)c0104a5c c010506c c01050ec c01051bc c0105ebf c0105eff c0105f58 c0106238 (XEN)c0106323 c010664a c0106a80 c0106be4 c039453d c0394546 c0108085 c0108093 (XEN)c0108108 c0108116 c0395faf c0395fc2 c01085ef c0108679 c010934c c0109547 (XEN)c0109572 c010957b c010985d c0109865 c010a3ae c010a425 c010a434 c010a468 (XEN)c010a4a2 c010a4ab c010a4b4 c02c5f1d c02c60c1 c02c6118 c02c6138 c02c62fe (XEN)c02c63c2 c02c67ea c03962cb c03962d3 c02c6d11 c0396429 c0396432 c039643b (XEN)c0396444 c0396453 c039645c c039646b c0396474 c02c6df1 c02c6e5a c02c6fbd (XEN)c02c7033 c02c708d c02c7093 c02c72d1 c02c7317 c02c738f c02c739f c02c741b (XEN)c02c742f c02c753c c02c754d c02c7554 c02c76d3 c02c7962 c02c7b49 c02c7b9a (XEN)c02c7c3a c02c7c3f c02c7c4d c02c7d80 c02c7d95 c02c7fea c02c8037 c02c80bf (XEN)c02c80e0 c02c81c7 c02c81d6 c02c81e5 c02c8206 c02c8215 c010b59e c010b5c7 (XEN)c010b5ef c010bbad c010bbe0 c010bc47 c010bc9d c010bccf c010bd07 c010bd91 (XEN)c010be10 c010be59 c010c0e7 c039753b c039755e c039798f c010ce93 c010de56 (XEN)c039867c c03986a3 c0398797 c0398a78 c010e3f9 c010f656 c010fec4 c0110fb9 (XEN)c0110fc3 c0ba c0c4 c01116a8 c0111a69 c0111ab0 c0111b39 c0111cba (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504805: more information about this problem
And another crash today, slightly different: (XEN) domain_crash_sync called from entry.S (ff188600) (XEN) Domain 0 (vcpu#1) crashed on cpu#1: (XEN) [ Xen-3.2-1 x86_32p debug=n Not tainted ] (XEN) CPU:1 (XEN) EIP:0061:[c01013a7] (XEN) EFLAGS: 0246 CONTEXT: guest (XEN) eax: ebx: 0001 ecx: edx: ed467f90 (XEN) esi: 0001 edi: 0001 ebp: esp: ed467f84 (XEN) cr0: 8005003b cr4: 06f0 cr3: 001ddc80 cr2: b7de0ad0 (XEN) ds: 007b es: 007b fs: 00d8 gs: ss: 0069 cs: 0061 (XEN) Guest stack trace from esp=ed467f84: (XEN)c0105f5a 0001 b9075da0 f911 (XEN)c01028ab c0102810 (XEN) 00d8 (XEN) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504805: more information about this problem
I too have been a victim of this problem, on a number of machines. I fed the lines into addr2line -e vmlinux after rebuilding the kernel with this flavor to get the vmlinux. This looks clearly like a xen bug, the kernel does some I/O, which gets queued, but for some reason the request causes a violation in xen. I also looked up the other crashes that people have reported here, they all seem to be either irq or scheduling related (involving the serial_core, or ipmi in those cases) and all seem to reference the following common point: /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/arch/x86/kernel/head_32-xen.S:72 Please see below for the specific line numbers associated with this. First the crash: [ 6930.059040] iret exception: [#1] SMP [ 6930.059123] Modules linked in: xt_tcpudp xt_physdev iptable_filter ip_tables x_tables netloop tun bridge ipv6 loop evdev container button i2c_i801 i2c_core intel_rng rng_core pcspkr shpchp pci_hotplug e7xxx_edac edac_core ext3 jbd mbcache serpent xts gf128mul dm_crypt crypto_blkcipher dm_mirror dm_log dm_snapshot dm_mod raid1 md_mod ide_disk ide_cd_mod cdrom ata_generic libata dock ide_pci_generic floppy aic79xx scsi_transport_spi scsi_mod piix ide_core e1000 uhci_hcd usbcore thermal processor fan thermal_sys [ 6930.060105] [ 6930.060146] Pid: 1241, comm: md1_resync Not tainted (2.6.26-1-xen-686 #1) [ 6930.060196] EIP: 0061:[c01011a7] EFLAGS: 0002 CPU: 0 [ 6930.060246] EIP is at 0xc01011a7 [ 6930.060283] EAX: EBX: ecfa3df0 ECX: 0001 EDX: 0001 [ 6930.060331] ESI: ecfa3df0 EDI: c1118e20 EBP: ece26040 ESP: ecfa3db4 [ 6930.060378] DS: 007b ES: 007b FS: 00d8 GS: SS: 0069 [ 6930.060420] Process md1_resync (pid: 1241, ti=ecfa2000 task=ece26040 task.ti=ec806000) [ 6930.060472] Stack: c0102eb7 c1118e20 ece26040 ece2628c c111906c 0001 ed4cac84 [ 6930.060501]ecd98ef0 ed4cac80 ebc08cac 0003 c01db664 ebc08cac ecfa3e10 0003 [ 6930.060501] 0068 ecfa3ff8 db744000 0002 ecfa8f00 c10c2038 1000 [ 6930.060501] Call Trace: [ 6930.060501] [c0102eb7] __switch_to+0x376/0x42e [ 6930.060501] [c01db664] cfq_add_rq_rb+0x5c/0x6b [ 6930.060501] [c01cf34e] elv_merged_request+0x28/0x30 [ 6930.060501] [c01d2140] __make_request+0x294/0x36e [ 6930.060502] [c01d0eb1] generic_make_request+0x34d/0x37b [ 6930.060502] [c0105f7c] get_nsec_offset+0xe/0x6a [ 6930.060573] [c0106151] get_runstate_snapshot+0x69/0xec [ 6930.060573] [c0115353] update_curr+0x47/0x79 [ 6930.060573] [c01160a3] dequeue_entity+0x13/0x9b [ 6930.060573] [c0115fa3] __dequeue_entity+0x1f/0x71 [ 6930.060573] [c02ca3a2] schedule+0x616/0x6b1 [ 6930.060573] [c0105b0d] do_IRQ+0x52/0x65 [ 6930.060573] [c02ca5dd] schedule_timeout+0x13/0x86 [ 6930.060573] [c012ed33] prepare_to_wait+0x12/0x49 [ 6930.060573] [ee1a6411] md_thread+0x9c/0xcd [md_mod] [ 6930.060573] [c012ec28] autoremove_wake_function+0x0/0x2d [ 6930.060573] [ee1a6375] md_thread+0x0/0xcd [md_mod] [ 6930.060573] [c012eb65] kthread+0x38/0x5f [ 6930.060573] [c012eb2d] kthread+0x0/0x5f [ 6930.060573] [c0104267] kernel_thread_helper+0x7/0x10 [ 6930.060573] === [ 6930.060573] Code: cc cc cc cc b8 0c 00 00 00 cd 82 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 0d 00 00 00 cd 82 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [ 6930.060573] EIP: [c01011a7] 0xc01011a7 SS:ESP 0069:ecfa3db4 Then, I fed each of the [] numbers through addr2line, including the EIP, which gives us: lenny:~/kernel/linux-2.6-2.6.26# addr2line -e ./debian/build/build_i386_xen_686/vmlinux c0102eb7 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/include/xen/hypercall.h:13 c01db664 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/block/cfq-iosched.c:1464 c01cf34e /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/block/elevator.c:118 c01d2140 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/block/blk-core.c:413 c01d0eb1 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/block/blk-core.c:1228 c0105f7c /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/arch/x86/kernel/time_32-xen.c:235 c0106151 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/arch/x86/kernel/time_32-xen.c:206 c0115353 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/kernel/sched_fair.c:433 c01160a3 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/kernel/sched_fair.c:738 c0115fa3 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/kernel/sched.c:1260 c02ca3a2 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/kernel/sched.c:3435 c0105b0d /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/include/asm/irq_regs_32.h:24 c02ca5dd /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/kernel/sched_stats.h:195 c012ed33 /root/kernel/linux-2.6-2.6.26/debian/build/build_i386_xen_686/kernel/wait.c:125
Bug#544756: [Secure-testing-team] Bug#544756: linux-image-2.6.26-2-686: Kernel still vulnerable by dsa-1862
* Christoph Siess c...@geekhost.info [2009-09-02 14:57-0400]: Package: linux-image-2.6.26-2-686 Version: 2.6.26-17lenny2 Severity: critical Tags: security Justification: root security hole Hi, according to http://www.debian.org/security/2009/dsa-1862 this Version of the 2.6.26-2 Kernel should not be vulnerable to CVE-2009-2692. Unfortunately I'm still able to break my system: c...@server:~$ gcc exploit.c -o exploit c...@server:~$ ./exploit sh-3.2# id uid=0(root) gid=0(root) groups=115(wheel),1000(chs) I got the exploit from http://www.risesecurity.org/exploits/linux-sendpage.c Correct my if I got something wrong, but according to my understanding this shouldn't be possible with version 2.6.26-17lenny2. I'm afraid this doesn't work on any of the systems i am running 2.6.26-17lenny2 on: mi...@tern:~$ wget http://www.risesecurity.org/exploits/linux-sendpage.c Saving to: `linux-sendpage.c' 100%[] 2009-09-03 19:01:43 (24.2 KB/s) - `linux-sendpage.c' saved [9380/9380] mi...@tern:~$ gcc linux-sendpage.c -o exploit mi...@tern:~$ ./exploit sh-3.2$ id uid=1001(micah) gid=1007(micah) groups=4(adm),20(dialout),33(www-data),100(users),1007(micah) micah signature.asc Description: Digital signature
Re: Stable Linux-Vserver patch plans
Micah Anderson mi...@riseup.net writes: I wanted to start a discussion about the plans for the stable kernel in the next point release, specifically where it relates to the Linux-Vserver patch-set. *taps microphone* So... one month went by since I sent this message, the new stable release of Lenny came out, but I'm still wanting to have this discussion. Perhaps this was lost in the noise? micah -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Stable Linux-Vserver patch plans
Hi, I wanted to start a discussion about the plans for the stable kernel in the next point release, specifically where it relates to the Linux-Vserver patch-set. As we all know, the 2.6.26 kernel is the version that Lenny ended up with and the Linux-Vserver patch that was under development (and was still highly experimental and not complete) at that time was *not* released for that kernel, and so the version of the patch that Debian used was a backport of a snapshot of where things were at the latest point. It was decided by the Linux-Vserver project to do long-term maintenance of the 2.6.27 patches, to coincide with the long-term maintenance of mainline 2.6.27. The reasons why this situation arose was related to the heavy virtualization changes in upstream kernel, causing major patch changes. As a result of this unfortunate timing situation, the remains in the Lenny kernel some significant issues that continually come up in upstream support channels, as well as in the Debian BTS. The main problem is the wrong filesystem attributes being used which cause major grief for people switching to or from that kernel. However there are a number of other issues that are also significant: - the missing TB scheduler - the PID 1 parent being wrong (initpid) - netnamespace (not a big deal, as it is broken in 2.6.26 mainline anyway, so it cannot really be used) - signalling fix (delta-sigkill-fix01.diff) - memory info (delta-cached-fix01.diff) Most of these issues could be solved by backporting the Linux-Vserver patches to resolve them to 2.6.26, leaving only the mainline 2.6.26 issues. So I am writing to ask what we can do to fix these issues, if the issues were backported, could we get them included in a point release? Or are there other plans that would resolve these problems? With a diff against mainline, this could be sorted out, but I don't know if such work would be used? Thanks, micah -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517449: Experiencing this problem also
I experienced this problem on a machine with 12gigs of memory when I added a failed disk back into a mdadm array, output included below. The machine basically was totally frozen for 10 minutes or so until the raid array finished its sync, and then everything returned to normal. Pretty ugly, would love to see this merged in to a lenny kernel. I got pages and pages of the following, so I'm only showing the end: [1540865.693902] INFO: task sshd:15082 blocked for more than 120 seconds. [1540865.693956] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [1540865.694002] sshd D ed0b2780 0 15082 23253 [1540865.694077]ec4450c0 00200282 c018d895 ed0b2780 c01b7f2e ec445248 c153fb40 0003 [1540865.694213]ec5cb080 ec4450c0 16ed73c7 ed43eacc ec44530c eccad200 c1679020 [1540865.694361]ed1cc0d4 c018d8c6 2c2c e7f11d8c c7fb7dbc [1540865.694509] Call Trace: [1540865.694576] [c018d895] __find_get_block+0x198/0x1a2 [1540865.694636] [c01b7f2e] security_inode_alloc+0x16/0x17 [1540865.694704] [c018d8c6] __getblk+0x27/0x26f [1540865.694757] [ee1ef6a0] do_get_write_access+0x1b6/0x367 [jbd] [1540865.694829] [c012ec51] wake_bit_function+0x0/0x3c [1540865.694882] [ee1ef869] journal_get_write_access+0x18/0x26 [jbd] [1540865.694942] [ee22e5df] __ext3_journal_get_write_access+0x13/0x32 [ext3] [1540865.695012] [ee2237e2] ext3_reserve_inode_write+0x2d/0x5d [ext3] [1540865.695067] [ee223823] ext3_mark_inode_dirty+0x11/0x27 [ext3] [1540865.695132] [ee225fcc] ext3_dirty_inode+0x50/0x63 [ext3] [1540865.695194] [c018a3f5] __mark_inode_dirty+0x21/0x148 [1540865.695245] [c0181c29] touch_atime+0xc7/0xce [1540865.695294] [c015022c] generic_file_aio_read+0x493/0x4da [1540865.695370] [c016fd62] do_sync_read+0xbf/0xfe [1540865.695436] [c012ec24] autoremove_wake_function+0x0/0x2d [1540865.695495] [ee230a51] ext3_xattr_security_get+0x31/0x3b [ext3] [1540865.695562] [c01b7f6f] security_file_permission+0xc/0xd [1540865.695621] [c016fca3] do_sync_read+0x0/0xfe [1540865.695674] [c01704ea] vfs_read+0x81/0x11e [1540865.695724] [c01738d4] kernel_read+0x32/0x43 [1540865.695775] [c01739a5] prepare_binprm+0xc0/0xc4 [1540865.695827] [c0174960] do_execve+0xd2/0x1c6 [1540865.695879] [c0102366] sys_execve+0x2a/0x4a [1540865.695926] [c0103f76] syscall_call+0x7/0xb [1540865.695988] [c02c] pci_bus_size_bridges+0x32a/0x3a0 [1540865.696044] === [1540869.985790] INFO: task sshd:15078 blocked for more than 120 seconds. [1540869.985845] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [1540869.988032] sshd D ed0b2780 0 15078 23253 [1540869.988110]ec4af140 00200286 c018d895 ed0b2780 c01b7f2e ec4af2c8 c153fb40 0003 [1540869.988236]eca48300 ec4af140 16ecfe8f ed43eacc ec4af38c eccad200 c1679020 [1540869.988379]ed1cc0d4 c018d8c6 2929 ec38dd8c c7fb7dbc [1540869.988529] Call Trace: [1540869.988595] [c018d895] __find_get_block+0x198/0x1a2 [1540869.988653] [c01b7f2e] security_inode_alloc+0x16/0x17 [1540869.988720] [c018d8c6] __getblk+0x27/0x26f [1540869.988772] [ee1ef6a0] do_get_write_access+0x1b6/0x367 [jbd] [1540869.988847] [c012ec51] wake_bit_function+0x0/0x3c [1540869.988899] [ee1ef869] journal_get_write_access+0x18/0x26 [jbd] [1540869.988960] [ee22e5df] __ext3_journal_get_write_access+0x13/0x32 [ext3] [1540869.989033] [ee2237e2] ext3_reserve_inode_write+0x2d/0x5d [ext3] [1540869.989093] [ee223823] ext3_mark_inode_dirty+0x11/0x27 [ext3] [1540869.989159] [ee225fcc] ext3_dirty_inode+0x50/0x63 [ext3] [1540869.989218] [c018a3f5] __mark_inode_dirty+0x21/0x148 [1540869.989276] [c0181c29] touch_atime+0xc7/0xce [1540869.989326] [c015022c] generic_file_aio_read+0x493/0x4da [1540869.989384] [c016fd62] do_sync_read+0xbf/0xfe [1540869.989384] [c012ec24] autoremove_wake_function+0x0/0x2d [1540869.989384] [ee230a51] ext3_xattr_security_get+0x31/0x3b [ext3] [1540869.989384] [c01b7f6f] security_file_permission+0xc/0xd [1540869.989384] [c016fca3] do_sync_read+0x0/0xfe [1540869.989384] [c01704ea] vfs_read+0x81/0x11e [1540869.989384] [c01738d4] kernel_read+0x32/0x43 [1540869.989384] [c01739a5] prepare_binprm+0xc0/0xc4 [1540869.989384] [c0174960] do_execve+0xd2/0x1c6 [1540869.989384] [c0102366] sys_execve+0x2a/0x4a [1540869.989384] [c0103f76] syscall_call+0x7/0xb [1540869.989384] [c02c] pci_bus_size_bridges+0x32a/0x3a0 [1540869.989384] === [1540874.198475] md: md2: recovery done. Login timed out after 60 seconds. [1540874.405091] RAID1 conf printout: [1540874.405173] --- wd:2 rd:3 [1540874.405210] disk 0, wo:0, o:1, dev:sdb4 [1540874.405260] disk 1, wo:0, o:1, dev:sdc4 Debian GNU/Linux 5.0 waxwing hvc0 signature.asc Description: Digital signature
Re: Scheduling linux-2.6 2.6.26-3
Hi release team, I'm writing to request that a hint be added to allow util-vserver 0.30.216~r2772-1 to enter testing. As discussed on debian-kernel, this version of the util-vserver user-space utilities is necessary in order to work with the kernel targetted for lenny, and so I am requesting a release exception to sync these up: * Micah Anderson [EMAIL PROTECTED] [2008-08-21 15:31-0400]: * dann frazier [EMAIL PROTECTED] [2008-08-21 10:51-0400]: On Thu, Aug 21, 2008 at 01:43:44PM -0400, Micah Anderson wrote: * dann frazier [EMAIL PROTECTED] [2008-08-20 17:59-0400]: This is a user-space issue, not a kernel issue. Using an older version of the user-space utilities work, and the kernel tests pass. I am working with upstream to determine the fix for this. Cool, thank you! Upstream expects a fix in approximately 2 days, will track this and request a release exception for lenny. Thanks for your hard work! Micah signature.asc Description: Digital signature
Re: Scheduling linux-2.6 2.6.26-3
* dann frazier [EMAIL PROTECTED] [2008-08-20 17:59-0400]: On Mon, Aug 18, 2008 at 02:40:41AM -0600, dann frazier wrote: On Fri, Aug 15, 2008 at 09:51:33PM +0200, Bastian Blank wrote: Hi folks I'd like to schedule the upload of linux-2.6 2.6.26-3 for monday. The following things are still missing: - VServer support for alpha, ia64, s390 and sparc. s390 does not build. Others untested. It should at least include all arches which had them in Etch. fyi, vserver builds fine on ia64, but I haven't been able to boot test it yet. I'm debugging another problem on my test box at the moment, but should hopefully be able to boot test later today. vserver flavour boots fine on ia64, but I'm not sure how to test it. When I attempt to start a vserver, it fails with: dl380g5:/home/dannf# vserver vserver1 start vc_migrate_context(): Function not implemented /proc/uptime can not be accessed. Usually, this is caused by procfs-security. Please read the FAQ for more details http://linux-vserver.org/Proc-Security Failed to start vserver 'vserver1' I tried messing w/ the proc security attributes as described in the link, but that didn't get me anywhere. I see the same thing on my amd64 install, so its not an ia64-specific issue. This is a user-space issue, not a kernel issue. Using an older version of the user-space utilities work, and the kernel tests pass. I am working with upstream to determine the fix for this. Micah signature.asc Description: Digital signature
Re: Bug#495009: closed by Bastian Blank wa...@debian.org (Re: Bug#495009: please update vserver patch and re enable it)
maximilian attems [EMAIL PROTECTED] writes: Hi all, On Thu, Aug 14, 2008 at 12:30:05PM +0300, Arturas K. wrote: * I know you guys are busy - so am I, but I am eager to try and help on this particular feature. please stop waffling. if you checked current sid repo you'd see that waldi turned on vserver feature with latest patch, plus there was a mail/irc request for testing snapshots. I saw the additioin of this in the commit, but I didn't see any mail/irc requests for testing snapshots (I'm on #debian-kernel, and did not see it here on the list). Can you please provide a reference for those? I'd like to test. Thanks for your hard work, its appreciated, micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489387: vserver patch available for 2.6.26
* Micah Anderson [EMAIL PROTECTED] [2008-08-13 16:26-0400]: There is a working patch available as of yesterday for 2.6.25 and 2.6.25.2 which fixes both ext4 and xfs. It has had the 'dontuse' flag removed and is considered pre5. Err, my mistake, I meant to write 2.6.26 and 2.6.26.2 here. Micah signature.asc Description: Digital signature
Bug#489387: vserver patch available for 2.6.26
There is a working patch available as of yesterday for 2.6.25 and 2.6.25.2 which fixes both ext4 and xfs. It has had the 'dontuse' flag removed and is considered pre5. micah signature.asc Description: Digital signature
Re: Bug#489387: Please do not replace vserver with openvz.
Bastian Blank [EMAIL PROTECTED] writes: On Fri, Aug 08, 2008 at 04:42:03PM -0500, William Pitcock wrote: It appears the plan is to drop vserver in favour of openvz, offering openvz as an alternative and perhaps default is a good option, but please do not remove vservers, as there are real people who depend on this feature. No. OpenVZ is an alternative. VServer is currently not supported because upstream is lets say in hibernation. There is simply no working patch available. There is a working patch available as of yesterday for 2.6.25 and 2.6.25.2 which fixes both ext4 and xfs. It has had the 'dontuse' flag removed and is considered pre5. micah pgp6CQAgs5EhJ.pgp Description: PGP signature
Bug#357545: linux-source-2.6.15: local redeclaration of name_to_dev_t in drivers/mtd/devices/blkmtd.c
Package: linux-source-2.6.15
Version: 2.6.15-8
Severity: normal
Tags: patch
There is a local redeclaration of name_to_dev_t in
drivers/mtd/devices/blkmtd.c:617 which is inconsistant with the function in
mount.h.
The way to fix this would be to remove the declaration and include the
mount.h as the attached patch does.
Note: this issue appears in the upstream kernel as well, and I believe
it should be fixed there as well. I hope that coming from the debian
kernel people it will be received.
Micah
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages linux-source-2.6.15 depends on:
ii binutils 2.16.1cvs20060117-1 The GNU assembler, linker and bina
ii bzip21.0.3-2 high-quality block-sorting file co
Versions of packages linux-source-2.6.15 recommends:
ii gcc 4:4.0.2-2 The GNU C compiler
ii libc6-dev [libc-dev] 2.3.6-3 GNU C Library: Development Librari
ii make 3.80+3.81.rc1-1 The GNU version of the make util
-- no debconf information
--- drivers/mtd/devices/blkmtd.c 2006-01-02 22:21:10.0 -0500
+++ /usr/src/linux-source-2.6.15/drivers/mtd/devices/blkmtd.c 2006-03-17 19:03:21.0 -0500
@@ -29,6 +29,7 @@
#include linux/list.h
#include linux/init.h
#include linux/mtd/mtd.h
+#include linux/mount.h
#define err(format, arg...) printk(KERN_ERR blkmtd: format \n , ## arg)
@@ -614,8 +615,6 @@
}
-extern dev_t __init name_to_dev_t(const char *line);
-
static struct blkmtd_dev *add_device(char *devname, int readonly, int erase_size)
{
struct block_device *bdev;
Re: automatic custom kernels?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Barth wrote: I usually want to have some flavoured kernels, i.e. they should contain certain (custom) patches. Now, there are the official source packages, and of course binaries from them. However, if I need my own kernel, it takes some time to compile in each instance - but technically, this doesn't really require interaction with me. But especially if kernels are required for more than one arch, this task can become quite cumbersome. So, my question is: Is there some way to tell everytime a new kernels appears at $location, please apply all patches in $directory, and compile it with this and that config for me? If not, which would be the way to do this? I've been thinking about how we could use autobuilders to automatically apply kernel-patch packages and auto-build them as soon as new kernels and patches are available. Many people want to just install kernel-images with certain patches (I get a lot of requests for images of the vserver kernel-patch), rather than have to get the source, the patch, learn how to do the patching and building of kernels and then install that. Additionally, each time the patch or the kernel gets updated, everyone needs to go through this process again. I believe that if this process were scripted, it could serve as a good method to provide QA for the existing kernel-patch packages (many of which are not kept up because there is hardly any feedback), as well as providing images that people can install instead of having to go through the hassle. In my mind the procedure would be something like as follows: 1. Automatically obtain the latest list of kernel-patch packages (patch packages can be hinted out that are known to be problematic, or only apply to upstream vanilla) 2. Automatically obtain the latest list of linux-source packages 3. If either #1 or #2 has new items, proceed 4. Individually attempt to apply each patch (verbose) to source making patch logs available, if failure is detected do not proceed 5. If indicated somewhere attempt to apply a second patch (allowing for kernels with grsecurity+vserver patches for example) 6. Attempt to build images for all architectures, putting build logs up as normal autobuilder logs 7. If images are built, then they can be hinted to be uploaded 8. Repeat steps regularly The only problem I've seen with this method so far is the linux-image space would become very polluted with kernel images with various patches... and people already have difficulty knowing which kernel to install. The solution to this could be having a separate repository for these patched kernel images, so you would have to make a conscious decision to use this repository and thus would know what you are getting into. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlIz29n4qXRzy1ioRApuxAJ0U0KqpCwV/OIbJl13GizH8lQmFiACggbNX OFhxjBC8uGxnJzBKYB9MJis= =rtbk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332381: This problem has broader implications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Although the original report says, After 250 days, the jiffies overflow and ipt_recent do not work anymore and is for 2.4, I've actually found that the code included in 2.6.8 (and probably any kernel version that includes ipt_recent) causes unexpected issues related to the jiffies as well, other than the 250 days issue. If you have rules that block based on ipt_recent you will find that they will block much too early at odd times. For example, I have a rule that will DROP ssh connections if there have been more than 6 seen in the last 60 seconds, but (seemingly) randomly I will get DROPped on the first connection. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDigIG9n4qXRzy1ioRAgDaAJ9g3uzHBKkSewx2CL0YkRs0ksFFoACgqR5D rRv5+cm8MbV9KH95NsY6Y2I= =3jfv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] DTSA for 2.6.8 and 2.4.27
Moritz Muehlenhoff schrieb am Friday, den 09. September 2005: Micah Anderson wrote: Neither of these advisories is a typical DTSA, as we normally we only do advisories for things that are blocked from reaching testing by some other issue, but I think that it would be good to do these two advisories because of the sheer number of security holes fixed as well as the necessary upgrade path that people need to take if they wish to maintain the integrity of their machines. Good idea, but I'd suggest to make a clean-sweep run over all kernel issues before. Some entries definitely need updating, (wrt to 2.4/2.6 You mean cross reference all the entries in CAN/list to make sure there isn't anything missing or still has a TODO label? mapping and IIRC Horms has some mails pending as well, he told me some days ago. I'll check with horms about any additional pending fixes. Also several more issues should receive a CVE mapping. What do you refer to here? I was thinking that the issues that do not have CVE numbers should possibily be submitted so that they do, although I'm not sure how long that will take and if it is worth holding up an advisory. Wrt keeping a complete history we should also move the entries based on older kernel-source packages to linux-2.6, as this will be the new permanent source package for 2.6 kernels. I'm not following you here -- do you mean change all the entries in CAN/list that are for kernel-source-#.#.# to be linux-2.6? If so, why? Thanks! Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DTSA for 2.6.8 and 2.4.27
Horms schrieb am Friday, den 09. September 2005: On Thu, Sep 08, 2005 at 09:17:25PM -0500, Micah Anderson wrote: Hi, I think it would be a good idea to get a DTSA (Debian Testing Security Advisory) issued for 2.4.27 and 2.6.8. That seems fine to me, at a glance. Though there have been some aditional bugs fixed in SVN. I have added the relevant patches to all trees that were effected, though as only 2.4.27 and 2.6.12 are reevant to this discussion. It might be a good time to spin 2.4.27-12 and get that into unstable. And linux-2.6 2.6.12-6, which was released earleier this week, should be up to date. If there are new security issues in SVN, definately spin out a new 2.4.27-12, but this brings up a question -- We haven't being doing DTSAs for every security hole that is fixed in unstable and naturally migrates to testing, at this point we are only doing them for those packages which can't enter testing on their own because they are blocked by something. The reason I was suggesting doing one for 2.4.27-11 was because there are a significant number of holes fixed in that release compared to previous, but since it migrates fine from unstable to testing, perhaps we shouldn't do a DTSA on it at all? Notifying testing users of security holes in all packages that enter testing from unstable is useful, but it may be too much of a burden on the team to issue advisories on them all. Do we want to be doing DTSAs for every new kernel version that comes out with security holes? If we do, we need to make a policy decision. Either we: 1. make it our policy to always do DTSAs for kernel security issues regardless if they enter testing naturally or not; or 2. make it our policy to do a DTSA for all packages that fix a significant number[1] of security issues because the significance of the threat is large enough to draw attention to the fix. Thoughts? Issuing an advisory for 2.6.8 still seems to make sense to me, since the transition to 2.6.12 is not so obvious. Micah 1. The definition of significant number is up to the team or the person willing to write the DTSA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DTSA for 2.6.8 and 2.4.27
Hi, I think it would be a good idea to get a DTSA (Debian Testing Security Advisory) issued for 2.4.27 and 2.6.8. 2.4.27-11 is already in testing, but the number of security bugs fixed in this version is significant: there are 9 CAN numbers for 2.4.27-11[1]; and 4 other security patches that do not have CVE entries[2]. It seems that it would be a good idea to do an advisory to alert people that these security holes have been fixed and that they need to upgrade and reboot if they haven't already 2.6.8 is scheduled to be removed from sid, and consequentially in testing as well, however it may be good to do an advisory to alert those who are running 2.6.8 to upgrade to linux-2.6 (2.6.12) as the kernel they are running is not being supported (and the transition is not super obvious) and the number of security holes for the version in testing (2.6.8-16) adds up to a whopping 13 CAN numbers[3] and 21 other security patches[4]. Neither of these advisories is a typical DTSA, as we normally we only do advisories for things that are blocked from reaching testing by some other issue, but I think that it would be good to do these two advisories because of the sheer number of security holes fixed as well as the necessary upgrade path that people need to take if they wish to maintain the integrity of their machines. I have begun the work to prepare this advisory for release, we basically need 2.6.8 to leave the archvie and the 2.6.12 packages to enter testing before the 2.6.8 DTSA can be released. The DTSA would just list the normal testing repositories for the upgrade (rather than the secure-testing repositories). Micah 1. CAN-2005-2458, CAN-2005-2459, CAN-2005-1767, CAN-2005-2456, CAN-2005-1768, CAN-2005-0756 CAN-2005-0757, CAN-2005-1762, CAN-2005-1768 2. 184_arch-x86_64-ia32-ptrace32-oops.diff, 174_net-ipv4-netfilter-nat-mem.diff, 178_fs_ext2_ext3_xattr-sharing.diff, 179_net-ipv4-netfilter-ip_recent-last_pkts.diff 3. CAN-2005-1763, CAN-2005-1762, CAN-2005-0756, CAN-2005-1265, CAN-2005-0757, CAN-2005-1765, CAN-2005-1761, CAN-2005-2456, CAN-2005-2548, CAN-2004-2302, CAN-2005-1767, CAN-2005-2458, CAN-2005-2459 4. mckinley_icache.dpatch, arch-x86_64-kernel-smp-boot-race.dpatch, arch-x86_64-mm-ioremap-page-lookup.dpatch, fs-exec-ptrace-core-exec-race.dpatch, fs-exec-ptrace-deadlock.dpatch, fs-exec-posix-timers-leak-1.dpatch, fs-exec-posix-timers-leak-2.dpatch, fs-hfs-oops-and-leak.dpatch, net-bridge-netfilter-etables-smp-race.dpatch, net-bridge-forwarding-poison-2.dpatch, net-rose-ndigis-verify.dpatch, sound-usb-usbaudio-unplug-oops.dpatch, net-ipv4-ipvs-conn_tab-race.dpatch, arch-ia64-ptrace-getregs-putregs.dpatch, ppc32-time_offset-misuse.dpatch, netfilter-NAT-memory-corruption.dpatch, netfilter-ip_conntrack_untracked-refcount.dpatch, sys_get_thread_area-leak.dpatch, fs_ext2_ext3_xattr-sharing.dpatch, net-ipv4-netfilter-ip_recent-last_pkts.dpatch, arch-x86_64-mm-ioremap-page-lookup-fix.dpatch signature.asc Description: Digital signature
Bug#319629: [CAN-2005-1768]: Race condition in ia32 compatability code for execve causes local DoS
Package: kernel-source-2.4.27 Version: 2.4.27-10 Severity: normal Tags: security http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1768 reads: Race condition in the ia32 compatibility code for the execve system call in Linux kernel 2.4 before 2.4.31 and 2.6 before 2.6.6 allows local users to cause a denial of service (kernel panic) and possibly execute arbitrary code via a concurrent thread that increments a pointer count after the nargs function has counted the pointers, but before the count is copied from user space to kernel space, which leads to a buffer overflow. I looked in the pending Changelog for 2.4.27 and did not see this CAN number listed. Please be sure to reference this CAN number in the changelog when fixed, as you always do. Additional reference: http://marc.theaimsgroup.com/?l=bugtraqm=112110120216116w=2 Micah -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (300, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kernel-source-2.4.27 depends on: ii binutils 2.16.1-2 The GNU assembler, linker and bina ii bzip2 1.0.2-7high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities Versions of packages kernel-source-2.4.27 recommends: ii gcc 4:4.0.0-2The GNU C compiler ii libc6-dev [libc-dev]2.3.2.ds1-22 GNU C Library: Development Librari ii make3.80-9 The GNU version of the make util -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303424: kernel-source-2.6.8: spinlock assert can crash kernel when compiled with up/spinlock_debug
Package: kernel-source-2.6.8 Version: 2.6.8-15 Severity: normal Tags: patch If you set in the config CONFIG_DEBUG_SPINLOCK=y and have CONFIG_SMP=n then the various spinlock checks in the kernel can cause the kernel to crash, an example of one of these spinlock checks is the code: BUG_ON(!spin_is_locked(some_lock)); the BUG() will kill the kernel in this scenario. These spinlock checks are in Debian's 2.6.8, a patch was accepted into mainline that fixes this problem, it is located at this URL: http://www.ussg.iu.edu/hypermail/linux/kernel/0501.3/1026.html The Debian kernel configurations do not have this combination of configs set for the kernel-images, so this is not incredibly critical, but someone building their own kernel could set this configuration and run into this problem. micah -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kernel-source-2.6.8 depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii bzip2 1.0.2-5high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303426: kernel-source-2.6.8: ext3 xattr/dquot reports incorrect quota
Package: kernel-source-2.6.8 Version: 2.6.8-15 Severity: normal Tags: patch There is a subtle bug in error handling of ext2 and ext3 xattrs. When ext2_sync_inode() or ext3_xattr_block_set() fails because it could not write the inode's dirty data (ENOSPC), it doesn't keep the xattrs in a consistent state and fails to release the old block properly. This results in incorrect quota in ext2 and ext3... this is problematic in disk limit accounting environments (quota, vservers, etc.) A patch that fixes this in both ext2 and ext3 has been accepted in mainline 2.6.11, and appears to be very simple. The following is the simple patch to ext2 to fix this: http://lkml.org/lkml/diff/2005/1/27/68/1 The following is the simple patch to ext3 to fix this: http://lkml.org/lkml/diff/2005/1/26/174/2 Micah -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kernel-source-2.6.8 depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii bzip2 1.0.2-5high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300162: [CAN-2004-1191]: Improper command checking for CDs, allowing local users to conduct unauthorized writes to firmware
Package: kernel-source-2.6.8 Version: 2.6.8-14 Severity: normal Tags: security patch Hello, CAN-2004-1190 reads: SUSE Linux before 9.1 and SUSE Linux Enterprise Server before 9 do not properly check commands sent to CD devices that have been opened read-only, which could allow local users to conduct unauthorized write activities to modify the firmware of associated SCSI devices. The Suse Advisory is here: http://www.novell.com/linux/security/advisories/2004_42_kernel.html It unfortunately doesn't provide much detail, so I have been in contact with the Suse security team to track down what this is, and how they fixed it. Apparantly there was a patched introduced in 2.6.8 to avoid firmware overwrites happening with read-only opened /dev/cdrom devices. Some burner programs opened those devices with O_RDONLY but then started to burn or blank the CDs, but the more severe problem is that unpriviledged users could destroy the firmware of SCSI related devices, rendering the devices completely useless. Although the fix was put into 2.6.8, it was found afterwards that these were not a complete solution to the security problem, so there were bug fixes done in later patches. Version 2.6.10 is completely fixed, but there are some missing patches from 2.6.8 that leave this unfixed in our 2.6.8, as far as I can determine. According to the Suse security people, the details in the chagelog at this location show what needs to be patched: http://linux.bkbits.net:8080/linux-2.6/hist/drivers/block/scsi_ioctl.c along with the thread on this subject here: http://groups-beta.google.com/group/linux.kernel/browse_frm/thread/5cfe44b11c8a99c5/ed58b3d4b1cfa39b?q=scsi_ioctl+firmware#ed58b3d4b1cfa39b Taking these two, I've compared our kernel-source-2.6.8 tree and found that the following patches should be applied: http://linux.bkbits.net:8080/linux-2.6/diffs/drivers/block/[EMAIL PROTECTED]/drivers/block/scsi_ioctl.c http://linux.bkbits.net:8080/linux-2.6/diffs/drivers/block/[EMAIL PROTECTED]/drivers/block/scsi_ioctl.c http://linux.bkbits.net:8080/linux-2.6/diffs/drivers/block/[EMAIL PROTECTED]/drivers/block/scsi_ioctl.c http://linux.bkbits.net:8080/linux-2.6/diffs/drivers/block/[EMAIL PROTECTED]/drivers/block/scsi_ioctl.c I should note that I do not fully understand this issue, I simply have done the legwork to determine that these patches have not been applied to kernel-source-2.6.8 and that according to Suse, the last relevant patch for this issue is the 1.61 revision patch (the last one in the list of four above). N.B.: There is one changeset in the bkbits.net site from 10 weeks ago, that has the changelog entry, fix exploitable hole -- according to Suse, this is misleading and incorrect (and is not included in the patches above). Micah -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kernel-source-2.6.8 depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii bzip2 1.0.2-5high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300163: [CAN-2004-1191]: Race condition could allow local users to read unauthorized memory from foreign memory pages.
Package: kernel-source-2.6.8 Version: 2.6.8-14 Severity: normal Tags: security patch CAN-2004-1191 reads: Race condition ... when run on SMP systems that have more than 4GB of memory, could allow local users to read unauthorized memory from foreign memory pages. Apparantly it also allows remote attackers to obtain sensitive information, caused by a vulnerability in the smb_recv_trans2 function, could also send a specially-crafted TRANS2 SMB packet to cause a kernel memory leak. More information about this is here: http://www.novell.com/linux/security/advisories/2004_42_kernel.html http://xforce.iss.net/xforce/xfdb/18137 2.6.8 needs both these patches: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]@1.1938.197.15 http://linux.bkbits.net:8080/linux-2.6/cset%4041e9a86bi4MvUzMJ8Ru62gdkFgHKtg The second patch has been applied to Debian's kernel-source-2.6.8, but the first is also needed. Micah -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kernel-source-2.6.8 depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii bzip2 1.0.2-5high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296700: Suspect this is in 2.6.10 as well
According the upstream folks, this problem only is a problem with kernels that have been patched with the 4G/4G patch, which is not in the mainline. If Debian does not use that patch, then we can close this out and remove those patches, and I'll make a note of it in the CAN list. Here is the thread for reference: http://groups-beta.google.com/group/linux.kernel/browse_thread/thread/1fd2bd7a57fac50c/197ace52b8cf3b8b Thanks, micah On Thu, 24 Feb 2005, Horms wrote: On Thu, Feb 24, 2005 at 12:43:14AM -0600, Micah Anderson wrote: I looked over the 2.6.10 changelogs and do not see this being either fixed, or that particular file being changed. Although I do see that it has changed slightly, the piece that is replaced in this patch is not replaced here. As a result, I am not able to determine myself if 2.6.10 is also susceptible, but instead hope you can determine this. I think so too, it does not seem to have been applied upstream at all. Do you want to ping LKML and find out if there is a reason why? In the mean time I will go ahead and add it to 2.6.8 and 2.6.10. As for 2.4.27, i am not sure either. I will investigate further and report back. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296700: [CAN-2005-0204]: AMD64, allows local users to write to privileged IO ports via OUTS instruction
Package: kernel-source-2.6.8
Version: 2.6.8-13
Severity: normal
Tags: security patch
Hello,
CAN-2005-0204 reads:
Linux kernel before 2.6.9, when running on the AMD64 and Intel EM64T
architectures, allows local users to write to privileged IO ports via
the OUTS instruction.
Although this says before 2.6.9 this *includes* both 2.6.8 and 2.6.9.
REDHAT:RHSA-2005:092
URL:http://www.redhat.com/support/errata/RHSA-2005-092.html
The RedHat bug associated with this is located at:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=148855
A patch to fix the problem is attached to this bugreport, it is
located here (also linked to the RedHat bug):
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=110424action=view
This apparantly only affects AMD64 and EM64T, and applies to 2.6.8 as
well as 2.6.9.
Kernel 2.4.27 appears to have a similar vulnerability, although this
patch would not apply cleanly to that tree, but looks relatively
trivial to modify appropriately.
Please include this CAN number in changelog entries about this problem.
Thanks,
Micah
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages kernel-source-2.6.8 depends on:
ii binutils 2.15-5 The GNU assembler, linker and bina
ii bzip2 1.0.2-1A high-quality block-sorting file
ii coreutils [fileutils] 5.2.1-2The GNU core utilities
ii fileutils 5.2.1-2The GNU file management utilities
-- no debconf information
--- linux-2.6.9/include/asm-x86_64/desc.h~ 2005-01-30 20:08:12.799247944
-0800
+++ linux-2.6.9/include/asm-x86_64/desc.h 2005-01-30 20:08:12.799247944
-0800
@@ -128,7 +128,7 @@
{
set_tssldt_descriptor(cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned
long)addr,
DESC_TSS,
- sizeof(struct tss_struct) - 1);
+ IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 7);
}
static inline void set_ldt_desc(unsigned cpu, void *addr, int size)
Bug#296700: Suspect this is in 2.6.10 as well
I looked over the 2.6.10 changelogs and do not see this being either fixed, or that particular file being changed. Although I do see that it has changed slightly, the piece that is replaced in this patch is not replaced here. As a result, I am not able to determine myself if 2.6.10 is also susceptible, but instead hope you can determine this. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
