Bug#684364: target: reports vfs_writev() returned -28 on iscsi activity
Hello, Dne Sunday 12 August 2012 23:09:35, Ben Hutchings napsal(a): On Thu, 2012-08-09 at 09:40 +0200, root wrote: Package: linux-image-3.2.0-3-amd64 Version: 3.2.21-3 Severity: normal Hello, i'm using this virtual machine to export iscsi targets for windows machines to backup. It has 620GB btrfs partition with 550GB iscsi file_io LUN exported. I'm using btrfs snapshots to transport (consistent copy of) this big file to secondary backup storage (qnap and usb disk) - it takes around 12 hours to transport - thats reason to use snapshots. Everything was working fine, until i run out of space on btrfs (because of snapshot and fullbackup from windows combination). Since than, i have created fresh filesystem and create empty new file to export over iscsi. Now, around 250GB of writen data do iscsi file, kern.log starts to fill with these messages vfs_writev() returned -28 It keeps to show on every access to iscsi (even rescan disk operation in windows triggers it) Any read access may change the image file's access time (atime) if you don't use the 'noatime' mount option. On btrfs, metadata changes may allocate more disk space. You are right, i forgot noatime option on mount I was suspecting btrfs, but there is no oops in kern.log. I tried to google this error and found nothing relevant. Error 28 is ENOSPC: No space left on device. I tried to reset everything (new filesystem, empty file, remove/add target from windows) and this errors comes back after writing approx. 250GB of data. (Before problem, file was filled to around 540GB). Size now: # du -cms iscsiSBS 244561 iscsiSBS [...] What does 'btrfs filesystem df /btrfs' say (substitute the actual mountpoint for the btrfs volume)? It said (i saved this before running balance) Data: total=578.01GB, used=263.03GB System, DUP: total=8.00MB, used=72.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.73GB, used=1.03GB Metadata: total=8.00MB, used=0.00 I tried this - is it ok, it doesn't free used after rm? # dd if=/dev/zero of=/mnt/tmp/1 bs=100M count=10 # rm /mnt/tmp/1 # btrfs filesystem df /mnt/tmp/ Data: total=1.01GB, used=0.00 System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=1.27MB Metadata: total=8.00MB, used=0.00 # dd if=/mnt/backupWin/iscsi/iscsiSBS of=/mnt/tmp/1 bs=100M count=10 10+0 records in 10+0 records out 1048576000 bytes (1.0 GB) copied, 22.0851 s, 47.5 MB/s # btrfs filesystem df /mnt/tmp/ Data: total=1.01GB, used=1000.00MB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=1.41MB Metadata: total=8.00MB, used=0.00 # rm /mnt/tmp/1 # btrfs filesystem df /mnt/tmp/ Data: total=1.01GB, used=1000.00MB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=1.41MB Metadata: total=8.00MB, used=0.00 # dd if=/mnt/backupWin/iscsi/iscsiSBS of=/mnt/tmp/1 bs=100M count=90 dd: writing `/mnt/tmp/1': No space left on device 82+0 records in 81+0 records out 8560574464 bytes (8.6 GB) copied, 280.973 s, 30.5 MB/s # btrfs filesystem df /mnt/tmp/ Data: total=7.97GB, used=7.97GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=11.39MB Metadata: total=8.00MB, used=0.00 # rm /mnt/tmp/1 # btrfs filesystem df /mnt/tmp/ Data: total=7.97GB, used=5.65GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=8.06MB Metadata: total=8.00MB, used=0.00 Ben. Libor signature.asc Description: This is a digitally signed message part.
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
Dear Andi, thank you for your response. Am Sonntag, den 12.08.2012, 06:10 -0700 schrieb Andi Kleen: On Sat, Aug 11, 2012 at 03:17:19PM +0200, Paul Menzel wrote: This really depends on what operations you want to do, and how buggy the CPU microcode installed by the BIOS is. If you care that much about it, you can blacklist it. Understood. Although I do not understand from where the updated microcode is fetched. The only way for desktop users were BIOS upgrades if I remember correctly. Linux does not ship the microcode, does not it. So I do not see what purpose this module has for desktop users. Intel regularly releases microcode updates and distributions are supposed to do regular package updates with the latest microcode file. You should get those with your normal update mechanism. In general it's recommended to run with the latest microcode. Looking into this some more, this seems unlikely in Debian because the microcode packages are in non-free [1] and therefore not available for Debian users not having enabled non-free repositories. Because of that the microcode packages are also non-essential, that means not installed by default even when non-free packages are allowed. And normal users will never install them by themselves. So currently I am pretty sure 99, % of Debian users do not have it installed. With the latest mainline kernel the microcode driver should be automatically loaded by CPUID probing through udev. How can I find out, if the microcode provided by my BIOS is older than the one provided by the processor vendor? I am pretty sure, that for example Intel does not release any updates for the Celeron CPU in my ASUS Eee PC 701 4G. Thanks, Paul [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=intel-microcode;dist=unstable signature.asc Description: This is a digitally signed message part
Bug#684636: CDROM fail to mount
Hi, service hal stop makes that the CD/DVD NEC drive now works fine. But with or without hal, LG drive does not appear in the list of drive of Nautilus. This issue is randomly from one session to another. Perhaps same issue that 620278. mount /dev/sr1 /media/cdrom Without hal, mount command line with LG drive only have the same bug than this : about one minute to work with numbered SCSI errors. After that LG drive works fine with mount only durong this session. -- Alain Rpnpif -- 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/20120813093758.337b4100...@chro.home
Bug#684636: CDROM fail to mount
OK : mount -t iso9660 /dev/sr1 /media/cdrom works fine ! So the auto mode of mount is the cause of this issue. Is linux-image package or mount package the responsable of this bug ? -- Alain Rpnpif -- 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/20120813101038.14fa0100...@chro.home
Re: Byte queue limits in Linux for wheezy / linux kernel ABI bumps
On Sun, Aug 05, 2012 at 07:43:50PM +0200, Bastian Blank wrote: On Sat, Aug 04, 2012 at 10:06:48PM +0100, Ben Hutchings wrote: A possible solution would be something like: 1. Keep multiple versions of udebs in the same suite (currently possible for arch:all, but maybe not supported for arch-dependent packages) Breaks the expectations within d-i. This is listed on my TODO. 4. Make anna try older package versions if dependencies can't be reolved for the newest version Versions in dependencies will be ignored. The packages stuff used in d-i is limited. It only allows one version of a package, which produced problems with cdebootstrap. In addition it disallows several other constructs: Breaks, Conflicts and ignores all versions in relations. I have the problem with multiple version on my list for a larger rewrite, which will make it need more memory. It can't be fixed in a backward compatible way. Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, Friday's Child, stardate 3497.2 -- 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/20120813104949.ga19...@wavehammer.waldi.eu.org
Processed: tagging 681637
Processing commands for cont...@bugs.debian.org: tags 681637 + pending Bug #681637 [src:linux] xen-linux-system: depend on a concrete xen-hypervisor-$flavour Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 681637: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681637 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13448557793158.transcr...@bugs.debian.org
Bug#684364: target: reports vfs_writev() returned -28 on iscsi activity
Hello, i have just noticed oops, which happend during experiments this morning Libor [141443.054425] btrfs: block rsv returned -28 [141443.054428] [ cut here ] [141443.054466] WARNING: at /build/buildd-linux_3.2.21-3-amd64- l_qIBB/linux-3.2.21/fs/btrfs/extent-tree.c:5985 btrfs_alloc_free_block+0xd7/0x284 [btrfs]() [141443.054470] Hardware name: VMware Virtual Platform [141443.054472] Modules linked in: autofs4 tcm_loop tcm_fc iscsi_target_mod target_core_pscsi target_core_file target_core_iblock target_core_mod des_generic ecb md4 hmac nls_utf8 cifs libfc scsi_transport_fc scsi_tgt configfs vmsync(O) vmhgfs(O) nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc dm_multipath scsi_dh loop coretemp crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 parport_pc joydev parport usbhid snd_pcm snd_page_alloc snd_timer snd vmw_balloon soundcore hid aes_generic cryptd psmouse serio_raw pcspkr processor ac evdev power_supply thermal_sys i2c_piix4 i2c_core container shpchp vmci(O) button ext4 crc16 jbd2 mbcache btrfs crc32c libcrc32c zlib_deflate dm_mod sr_mod cdrom ata_generic sd_mod crc_t10dif uhci_hcd floppy ehci_hcd usbcore usb_common e1000 ata_piix mptspi scsi_transport_spi mptscsih mptbase libata scsi_mod [last unloaded: autofs4] [141443.054526] Pid: 28983, comm: btrfs-transacti Tainted: G O 3.2.0-3-amd64 #1 [141443.054529] Call Trace: [141443.054537] [81046901] ? warn_slowpath_common+0x78/0x8c [141443.054550] [a01441fe] ? btrfs_alloc_free_block+0xd7/0x284 [btrfs] [141443.054566] [a01690fe] ? read_extent_buffer+0x94/0xed [btrfs] [141443.054575] [a01377bf] ? __btrfs_cow_block+0x102/0x33a [btrfs] [141443.054585] [a0137aee] ? btrfs_cow_block+0xf7/0x143 [btrfs] [141443.054595] [a013a546] ? btrfs_search_slot+0x225/0x64e [btrfs] [141443.054608] [a0148750] ? btrfs_del_csums+0xc8/0x252 [btrfs] [141443.054618] [a013ff9c] ? __btrfs_free_extent+0x54f/0x5c8 [btrfs] [141443.054630] [a0142fc9] ? run_clustered_refs+0x65e/0x6aa [btrfs] [141443.054642] [a01430de] ? btrfs_run_delayed_refs+0xc9/0x176 [btrfs] [141443.054647] [8134a0a0] ? mutex_lock+0xd/0x2d [141443.054661] [a0150153] ? btrfs_commit_transaction+0x8f/0x6f9 [btrfs] [141443.054667] [8105f5f3] ? add_wait_queue+0x3c/0x3c [141443.054679] [a014faba] ? join_transaction.isra.24+0x5a/0x1f3 [btrfs] [141443.054692] [a0150bd5] ? start_transaction+0x1ed/0x242 [btrfs] [141443.054705] [a014a7ad] ? transaction_kthread+0x156/0x20f [btrfs] [141443.054717] [a014a657] ? btrfs_congested_fn+0x7b/0x7b [btrfs] [141443.054720] [8105efad] ? kthread+0x76/0x7e [141443.054725] [81351cf4] ? kernel_thread_helper+0x4/0x10 [141443.054729] [8105ef37] ? kthread_worker_fn+0x139/0x139 [141443.054732] [81351cf0] ? gs_change+0x13/0x13 [141443.054734] ---[ end trace 2684d70a838e2d6c ]--- signature.asc Description: This is a digitally signed message part.
Bug#684618: linux-image-3.2.0-3-686-pae: e1000 wake-on-lan does not work
On 08/12/2012 04:22 PM, Ben Hutchings wrote: On Sun, 2012-08-12 at 22:16 +0100, Ben Hutchings wrote: On Sun, 2012-08-12 at 00:01 +0200, Richard Kojedzinszky wrote: Package: src:linux Version: 3.2.23-1 Severity: important Tags: patch upstream In linux kernel commit d5bc77a223b0e9b9dfb002048d2b34a79e7d0b48 made wol does not work on e1000 cards. Later, in b868179c47e9e8eadcd04c1f3105998e528988a3 it has been fixed, but has not been ported back to 3.2 series, but that would be nice to include it in debian. [...] Can I queue this up for 3.2.y? Hmm, since this already had a 'Cc: stable', and applies cleanly, I wonder why it wasn't added earlier. Did it cause a regression that requires a further fix-up? I don't see anything like that in mainline. I'm not aware of any regression caused by this patch. It is addressing a regression that was introduced by commit d5bc77a223b0e9b9, which has been added to 3.2.y. So in my opinion this patch should definitely go into 3.2.y as well. (I don't know why it wasn't added earlier.) Dean -- 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/5028eb74.5010...@redhat.com
Bug#683807: bbswitch
Hi Ben, I've seen the title has changed. The first title (segfault while using mv ... ) was chaotic , i know. But bbswitch causes instability is not a correct title. Indeed i tried: a) use with nvidia driver + bbswitch . This lead to a crash. b) i tried uninstalling nvidia stuff, bbswitch and bumblebee (aka normal system. It's like a fresh installation). It crashed. c) i tried reinstalling bumblebee but disabling bbswitch (aka always use nvidia driver without the auto-remove-driver feature known as bbswitch). It crashed again. then, d) i tried to use debian stable (i installed it on another partition on the very same hard disk). It still crashes. So i think the problem is *not* bbswitch. The problem must be something hardware related. My notebook (Asus K52jc) must have some bad supported piece of hardware, i think that the problem is in some module(s). This/these module/s is/are part of either 3.2.x kernels and 2.6.x kernels. Atm this notebook is almost inusable :( I really appreciate your activity here, please tell me if more information is needed to find where the bug is. Thanks, Asdrubale -- 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/32369776.1075821344864775821.JavaMail.defaultUser@defaultHost
Bug#684636: CDROM fail to mount
I found that is blkid_do_safeprobe(blprobe) function (line 147) in fsprobe.c in mount package (util-linux-2.17.2) that triggers I/O errors. -- Alain Rpnpif -- 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/20120813133823.0a9f4100...@chro.home
Bug#684745: linux-headers-3.5-trunk-686-pae depends on linux-kbuild-3.5, which is not available
Package: linux-headers-3.5-trunk-686-pae Severity: important As reported by dselect: linux-headers-3.5-trunk-686-pae depends on linux-kbuild-3.5 linux-kbuild-3.5 does not appear to be available -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (1001, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.5-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-headers-3.5-trunk-686-pae depends on: ii gcc-4.6 4.6.3-8 pn linux-headers-3.5-trunk-common none pn linux-kbuild-3.5none linux-headers-3.5-trunk-686-pae recommends no packages. linux-headers-3.5-trunk-686-pae suggests no packages. -- 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/20120813143504.3668.71047.report...@henna.lan
Bug#684750: please add support for /etc/initramfs-tools/modules
Package: initramfs-tools Severity: wishlist now that we finally have a mechanism to load system modules with kmod by including snippets from other packages (or the sysadmin), the same would be nice to be able to do for modules during initramfs stage. therefore, please support something like /etc/initamfs-tools/modules.d in initramfs-tools. Regards, Daniel -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- 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/50291027.4070...@progress-technologies.net
Bug#684666: corrupted transmisison
Ben Hutchings - Date: Sun, 12 Aug 2012 21:02:42 +0100 'Breaks the whole system' does not mean the system crashed; please see http://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.1.2. Sorry, i'm a noob of the bug system (i started to submit bugs only recently). Thanks for the link! anyway, i see that 'Important' is related to new hardware: important We include lack of support for new hardware that is generally available. is my notebook considered new hardware? I bought it on late 2010 but it came to the market in the first months of 2010. also, as i said, this bug is related (the same) to the one in 683807. This bug causes data corruption in memory and *communications*, as in 'grave': grave: ...or causes data loss... We exclude loss of data in memory due to a crash. Only corruption of data in storage or communication, or silent failure to write data, qualifies. I had the very same errors with sshfs while copying data from this notebook to the sshfs server. Last night (i'm still using stable) i had that ssh error (with disconnection) . I couldnt copy a file to the sshfs shared directory. So i used nc to transmit the file and then i noticed that the md5sum of the origin and the one at the destination was different (aka corrupted transmission). The original file was *not* on a ramdisk. It was on the hard disk (SSD). I upgraded the hardisk some months ago. I bought an SSD disk. Could it be the cause of the problem? Is there some special setting i have to use to correctly use SSD on debian? Or is a simple 'mount and than reboot' enough ? Thanks, Asdrubale -- 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/3542937.1397731344873119144.JavaMail.defaultUser@defaultHost
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
On Mon, 13 Aug 2012, Paul Menzel wrote: Looking into this some more, this seems unlikely in Debian because the microcode packages are in non-free [1] and therefore not available for Debian users not having enabled non-free repositories. Because of that the microcode packages are also non-essential, that means not installed by default even when non-free packages are allowed. And normal users will never install them by themselves. So currently I am pretty sure 99, % of Debian users do not have it installed. That is correct, yes. We may change the Debian installer to offer to install the microcode packages for AMD and/or Intel to users that enable non-free. We could also document the availability of the microcode packages in the release documentation, I suppose. But Debian really isn't big on the non-free stuff. With the latest mainline kernel the microcode driver should be automatically loaded by CPUID probing through udev. How can I find out, if the microcode provided by my BIOS is older than the one provided by the processor vendor? I am pretty sure, that for example Intel does not release any updates for the Celeron CPU in my ASUS Eee PC 701 4G. The easiest way, by far, is to attempt to update to the latest microcode in the microcode distribution. Assuming you're using Debian testing/unstable, install the intel-microcode package (in unstable, install also package iucode-tool to avoid bloating the initramfs). Then grep for microcode in the kernel logs. The 3.2 kernel will log the fact that it had to update the processor microcode. If it doesn't log anything, either no microcode for that processor model is available, or you're already running newer microcode. In Debian stable, it works the same way but I am not sure the kernel will log anything of value. If you want to do it the hard way: iucode-tool --scan-system will tell you your processor's signature (requires the cpuid module to be loaded first). If you're running Debian stable, wait a few days for the Squeeze backport to hit the mirrors. You can get the pf_mask and current version of microcode on each core from /sys/devices/system/cpu/cpu*/microcode/, and you can check the intel-microcode package changelog for your processor's signature to see if a higher revision is available. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120813163215.ga3...@khazad-dum.debian.net
Processed: [bts-link] source package src:linux
Processing commands for cont...@bugs.debian.org: # # bts-link upstream status pull for source package src:linux # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). # remote status report for #683167 (http://bugs.debian.org/683167) # Bug title: linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system # * https://bugs.freedesktop.org/show_bug.cgi?id=53222 # * remote status changed: NEW - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 683167 + fixed-upstream Bug #683167 [src:linux] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Added tag(s) fixed-upstream. usertags 683167 - status-NEW Usertags were: status-NEW. Usertags are now: . usertags 683167 + status-RESOLVED resolution-FIXED There were no usertags set. Usertags are now: status-RESOLVED resolution-FIXED. thanks Stopping processing here. Please contact me if you need assistance. -- 683167: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683167 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.134487555722884.transcr...@bugs.debian.org
[bts-link] source package src:linux
# # bts-link upstream status pull for source package src:linux # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #683167 (http://bugs.debian.org/683167) # Bug title: linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system # * https://bugs.freedesktop.org/show_bug.cgi?id=53222 # * remote status changed: NEW - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 683167 + fixed-upstream usertags 683167 - status-NEW usertags 683167 + status-RESOLVED resolution-FIXED thanks -- 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/20120813163228.1777.37088.btsl...@sonntag.debian.org
Bug#683167: Attempting to start X with intel driver hangs system
clone 683167 -1 reassign 683167 libdrm-intel1 2.4.33-3 forcemerge 683167 684650 tags 683167 + upstream patch notforwarded -1 reassign -1 src:linux 3.2.23-1 found -1 linux-2.6/2.6.32-45 retitle -1 kernel: missing support for Ivy Bridge GT2 Server # cc22a938fc1d (drm/i915: add Ivy Bridge GT2 Server entries) tags -1 = upstream patch moreinfo quit Hi, Maik Zumstrull wrote: This is on an Ivy Bridge Xeon E3 with GPU. I thought it was the X driver, because i915 KMS works fine for the console, it only crashes when trying to bring up X. But I pulled in the 2.20.2 driver today and it still happens. So I now think the problem is in the kernel. [...] 3.2 crashes as well, but not as hard as 3.4. With 3.2, X doesn't come up, but you can switch to a console and reboot. 3.4 needs the reset button. Jonathan Nieder wrote: Support for this GPU seems to have been added by cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries which was merged in 3.4-rc2. Chris Wilson wrote: Aha! Indeed libdrm is out-of-date, you need libdrm 2.4.34 (or a backport of the PCI ID patch, or a backport of the assertion removal). commit e057a56448e2e785f74bc13dbd6ead8572ebed91 Author: Eugeni Dodonov eug...@dodonov.net Date: Thu Mar 29 21:03:29 2012 -0300 intel: add Ivy Bridge GT2 server variant [...] commit 9a2b57d229fe3e6a1c9799e8cd5397969202d223 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Jul 25 16:28:59 2012 +0100 intel: Bail gracefully if we encounter an unknown Intel device Otherwise we end up with X hitting a fail-loop as the embedded libGL stacks asserts whilst initialising. Reassigning. Thanks, Jonathan -- 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/20120813164707.GA5951@mannheim-rule.local
Processed: Re: Attempting to start X with intel driver hangs system
Processing commands for cont...@bugs.debian.org: clone 683167 -1 Bug #683167 [src:linux] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Bug 683167 cloned as bug 684767 reassign 683167 libdrm-intel1 2.4.33-3 Bug #683167 [src:linux] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Bug reassigned from package 'src:linux' to 'libdrm-intel1'. No longer marked as found in versions linux/3.4.4-1~experimental.1 and linux/3.5-1~experimental.1. Ignoring request to alter fixed versions of bug #683167 to the same values previously set Bug #683167 [libdrm-intel1] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Marked as found in versions libdrm/2.4.33-3. forcemerge 683167 684650 Bug #683167 [libdrm-intel1] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Bug #684650 [libdrm-intel1] libdrm-intel1: X dies hard on Ivy Bridge GT2 Server graphics Set Bug forwarded-to-address to 'https://bugs.freedesktop.org/show_bug.cgi?id=53222'. Added tag(s) fixed-upstream. Merged 683167 684650 tags 683167 + upstream patch Bug #683167 [libdrm-intel1] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Bug #684650 [libdrm-intel1] libdrm-intel1: X dies hard on Ivy Bridge GT2 Server graphics Added tag(s) upstream and patch. Added tag(s) upstream and patch. notforwarded -1 Bug #684767 [src:linux] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Unset Bug forwarded-to-address reassign -1 src:linux 3.2.23-1 Bug #684767 [src:linux] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Ignoring request to reassign bug #684767 to the same package Bug #684767 [src:linux] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Marked as found in versions linux/3.2.23-1; no longer marked as found in versions linux/3.4.4-1~experimental.1 and linux/3.5-1~experimental.1. found -1 linux-2.6/2.6.32-45 Bug #684767 [src:linux] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Marked as found in versions linux-2.6/2.6.32-45. retitle -1 kernel: missing support for Ivy Bridge GT2 Server Bug #684767 [src:linux] linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system Changed Bug title to 'kernel: missing support for Ivy Bridge GT2 Server' from 'linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system' # cc22a938fc1d (drm/i915: add Ivy Bridge GT2 Server entries) tags -1 = upstream patch moreinfo Bug #684767 [src:linux] kernel: missing support for Ivy Bridge GT2 Server Added tag(s) upstream, moreinfo, and patch; removed tag(s) fixed-upstream. quit Stopping processing here. Please contact me if you need assistance. -- 683167: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683167 684650: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684650 684767: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684767 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.134487641930064.transcr...@bugs.debian.org
Processed: [bts-link] source package linux-2.6
Processing commands for cont...@bugs.debian.org: # # bts-link upstream status pull for source package linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). # remote status report for #639092 (http://bugs.debian.org/639092) # Bug title: Kernel-oops while find_busiest_group # * http://bugzilla.kernel.org/show_bug.cgi?id=16991 # * remote status changed: NEW - RESOLVED # * remote resolution changed: (?) - CODE-FIX # * closed upstream tags 639092 + fixed-upstream Bug #639092 [linux-2.6] Kernel-oops while find_busiest_group Bug #636797 [linux-2.6] linux-image-2.6.32-5-amd64: avoid divide-by-zero (divide error: ) in scheduler Added tag(s) fixed-upstream. Added tag(s) fixed-upstream. usertags 639092 - status-NEW Usertags were: status-NEW. Usertags are now: . usertags 639092 + status-RESOLVED resolution-CODE-FIX There were no usertags set. Usertags are now: resolution-CODE-FIX status-RESOLVED. # remote status report for #639092 (http://bugs.debian.org/639092) # Bug title: Kernel-oops while find_busiest_group # * http://bugzilla.kernel.org/show_bug.cgi?id=16991 # * remote status changed: NEW - RESOLVED # * remote resolution changed: (?) - CODE-FIX # * closed upstream tags 639092 + fixed-upstream Bug #639092 [linux-2.6] Kernel-oops while find_busiest_group Bug #636797 [linux-2.6] linux-image-2.6.32-5-amd64: avoid divide-by-zero (divide error: ) in scheduler Ignoring request to alter tags of bug #639092 to the same tags previously set Ignoring request to alter tags of bug #636797 to the same tags previously set usertags 639092 - status-NEW Usertags were: resolution-CODE-FIX status-RESOLVED. Usertags are now: resolution-CODE-FIX status-RESOLVED. usertags 639092 + status-RESOLVED resolution-CODE-FIX Usertags were: resolution-CODE-FIX status-RESOLVED. Usertags are now: resolution-CODE-FIX status-RESOLVED. thanks Stopping processing here. Please contact me if you need assistance. -- 636797: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636797 639092: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639092 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.134487648830390.transcr...@bugs.debian.org
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
On Mon, Aug 13, 2012 at 09:44:48AM +0200, Paul Menzel wrote: Looking into this some more, this seems unlikely in Debian because the microcode packages are in non-free [1] and therefore not available for Debian users not having enabled non-free repositories Because of that the microcode packages are also non-essential, that means not installed by default even when non-free packages are allowed. And normal users will never install them by themselves. Sounds like a problem. They actually fix bugs so it's recommended. BIOSes are not normally updated regularly, so the microcode update gives you a faster path to that. So currently I am pretty sure 99, % of Debian users do not have it installed. With the latest mainline kernel the microcode driver should be automatically loaded by CPUID probing through udev. How can I find out, if the microcode provided by my BIOS is older than the one provided by the processor vendor? I am pretty sure, that for example Intel does not release any updates for the Celeron CPU in my ASUS Eee PC 701 4G. The newer kernels report the microcode version in /proc/cpuinfo If not you can probably use some tool like x86info. Check version. Load the latest microcode. Compare versions. -Andi -- 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/20120813164459.go2...@tassilo.jf.intel.com
[bts-link] source package linux-2.6
# # bts-link upstream status pull for source package linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #639092 (http://bugs.debian.org/639092) # Bug title: Kernel-oops while find_busiest_group # * http://bugzilla.kernel.org/show_bug.cgi?id=16991 # * remote status changed: NEW - RESOLVED # * remote resolution changed: (?) - CODE-FIX # * closed upstream tags 639092 + fixed-upstream usertags 639092 - status-NEW usertags 639092 + status-RESOLVED resolution-CODE-FIX # remote status report for #639092 (http://bugs.debian.org/639092) # Bug title: Kernel-oops while find_busiest_group # * http://bugzilla.kernel.org/show_bug.cgi?id=16991 # * remote status changed: NEW - RESOLVED # * remote resolution changed: (?) - CODE-FIX # * closed upstream tags 639092 + fixed-upstream usertags 639092 - status-NEW usertags 639092 + status-RESOLVED resolution-CODE-FIX thanks -- 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/20120813163228.1777.84720.btsl...@sonntag.debian.org
Bug#684569: microcode module loaded on Celeron CPU
Andi Kleen wrote: On Mon, Aug 13, 2012 at 09:44:48AM +0200, Paul Menzel wrote: Looking into this some more, this seems unlikely in Debian because the microcode packages are in non-free [1] and therefore not available for Debian users not having enabled non-free repositories Because of that the microcode packages are also non-essential, that means not installed by default even when non-free packages are allowed. And normal users will never install them by themselves. Sounds like a problem. They actually fix bugs so it's recommended. BIOSes are not normally updated regularly, so the microcode update gives you a faster path to that. You can see why an OS distributor would be stuck in this situation, though. If the microcode updates are installed by default, Debian is taking responsibility for their effect (in the sense of receiving bug reports and providing updates when appropriate to address them). And that is very hard to do without the corresponding source code. At least when updates come through the BIOS the OS distributor does not have to be involved. The non-free packages also allow users to use the updates from Intel without too much fuss when they want them. Hoping that clarifies, Jonathan -- 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/20120813170436.GA5995@mannheim-rule.local
Bug#684569: microcode module loaded on Celeron CPU
At least when updates come through the BIOS the OS distributor does not have to be involved. The non-free packages also allow users to use the updates from Intel without too much fuss when they want them. One alternative would be to offer a downloader. Just hiding them from the user is not a good policy. Microcode updates can contain security updates (among other fixes), so you should have some mechanism to distribute them to your users. If you don't want to offer these updates you should at least clearly explain those tradeoffs to your users. -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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/20120813173246.gp2...@tassilo.jf.intel.com
Bug#684569: microcode module loaded on Celeron CPU
On Mon, 13 Aug 2012, Jonathan Nieder wrote: You can see why an OS distributor would be stuck in this situation, though. If the microcode updates are installed by default, Debian is taking responsibility for their effect (in the sense of receiving bug reports and providing updates when appropriate to address them). And that is very hard to do without the corresponding source code. It is not the lack of source code[1] that is the problem. It is the absolute lack of any sort of release guidance whatsoever from Intel when a new microcode update is made available. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120813183119.gc3...@khazad-dum.debian.net
Bug#684636: linux-image-3.2.0-0.bpo.2-686-pae: Fixed with mount 2.20.1-5.1 and depends
Package: src:linux Severity: normal After upgraded mount package with its depends to 2.20.1-5.1 testing version, now mounting cdrom works fine with mount. reassign 684636 mount thank you -- 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/20120813201051.11058.21767.report...@chro.home
Processed: reassign 684636 to mount
Processing commands for cont...@bugs.debian.org: reassign 684636 mount Bug #684636 [src:linux] linux-image-3.2.0-0.bpo.2-686-pae: CDROM fail to mount randomly Bug reassigned from package 'src:linux' to 'mount'. No longer marked as found in versions linux/3.2.20-1~bpo60+1. Ignoring request to alter fixed versions of bug #684636 to the same values previously set thank you Stopping processing here. Please contact me if you need assistance. -- 684636: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684636 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13440026068.transcr...@bugs.debian.org
Bug#684352: Wifi kill switch always on unless ACPI=off is used
With acpi=off Miho:/home/david# rfkill list all 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no Without using acpi=off Miho:/home/david# rfkill list all 0: hp-wifi: Wireless LAN Soft blocked: yes Hard blocked: no 1: phy0: Wireless LAN Soft blocked: yes Hard blocked: yes Miho:/home/david# This where it says the wireless is hard blocked, which is incorrect as I can just do this with software... Miho:/home/david# rfkill unblock all Miho:/home/david# rfkill list all 0: hp-wifi: Wireless LAN Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no Then it shows that it is not hard blocked. After that, the wireless now seems to be working. I press the hardware switch to disable the wireless and then I get... Miho:/home/david# rfkill list all 0: hp-wifi: Wireless LAN Soft blocked: no Hard blocked: yes 1: phy0: Wireless LAN Soft blocked: no Hard blocked: yes Miho:/home/david# Which is correct as expected... Aside from the fact that it appears I have two wireless devices when I do not. 1) The problem seems to be that every time the PC is started for the first time, rfkill says the wireless is both hardware and software blocked, but really it is just software blocked. 2) rfkill seems to suggest I have two wireless LAN network cards, this is incorrect. One of my wireless LAN connections disappears when I boot with ACPI=off, the wireless is not hardware or software blocked, and the wireless works.
