Re: Processed: Re: Bug#737701: mount: When I execute 'mount -o remount,acl /' . This command dont work.
Bug#713943: Not fixed for me
Hi Rick, for you so much for your quick answer. I had tried the same in /etc/modules. I've just removed it and tried your local.conf setting. No success. I have still the same message in dmesg : [0.961200] PowerMac i2c bus pmu 2 registered [0.961236] PowerMac i2c bus pmu 1 registered [0.961272] PowerMac i2c bus mac-io 0 registered [0.961667] PowerMac i2c bus u3 1 registered [0.961725] i2c i2c-3: i2c-powermac: modalias failure on /u3@0,f800/i2c@f8001000/cereal@1c0 [0.961764] PowerMac i2c bus u3 0 registered and [1.361462] Detected fan controls: [1.361467] 0: PWM fan, id 1, location: BACKSIDE,SYS CTRLR FAN [1.361472] 1: RPM fan, id 2, location: DRIVE BAY [1.361477] 2: PWM fan, id 2, location: SLOT,PCI FAN [1.361482] 3: RPM fan, id 3, location: CPU A INTAKE [1.361488] 4: RPM fan, id 4, location: CPU A EXHAUST [1.361493] 5: RPM fan, id 5, location: CPU B INTAKE [1.361498] 6: RPM fan, id 6, location: CPU B EXHAUST [1.361538] i2c i2c-0: therm_pm72: attach_adapter method is deprecated [1.361545] i2c i2c-0: Please use another way to instantiate your i2c_client [1.361553] i2c i2c-1: therm_pm72: attach_adapter method is deprecated [1.361558] i2c i2c-1: Please use another way to instantiate your i2c_client [1.361566] i2c i2c-2: therm_pm72: attach_adapter method is deprecated [1.361572] i2c i2c-2: Please use another way to instantiate your i2c_client [1.361580] i2c i2c-3: therm_pm72: attach_adapter method is deprecated [1.361585] i2c i2c-3: Please use another way to instantiate your i2c_client [1.361596] i2c i2c-3: Failed to register i2c client therm_pm72 at 0x2f (-16) [1.361602] therm_pm72: Failed to attach to i2c ID 0x15e [1.361609] i2c i2c-4: therm_pm72: attach_adapter method is deprecated [1.361615] i2c i2c-4: Please use another way to instantiate your i2c_client [1.361671] i2c i2c-4: Failed to register i2c client therm_pm72 at 0x2c (-16) [1.361677] therm_pm72: Failed to attach to i2c ID 0x58 Not all fans seem to be registered. I also have random kernel panics, but i think it is unrelated to this bug : something about radeon-kms (and I only have a software rasterizer for opengl, even if I boot with the video=offb:off video=radeonfb:off kernel argument.). Thank you again. Le 22/04/2014 05:18, Rick Thomas a écrit : On Apr 21, 2014, at 1:49 PM, Bertrand Dekoninck bdekoni...@free.fr wrote: I've installed jessie with linux-3.13.7-1 last night on my powermac7,3 (2x2.0 ghz). The fans are still crazy, even if i2c-powermac is build-in (and not a module anymore). Hi Bertrand, Have you tried echo 'i2c-powermac' /etc/modules-load.d/local.conf then reboot? I know it's supposed to be compiled-in with this version of the kernel, but maybe it just needs a little push? Rick -- 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/53562408.1040...@free.fr
Bug#713943: Not fixed for me
H... I'm planning to try it on my G5 soon. I'll let you know what I find out. It may be that we need a parameter on the module load line? Rick On Apr 22, 2014, at 1:10 AM, Bertrand Dekoninck bdekoni...@free.fr wrote: Hi Rick, for you so much for your quick answer. I had tried the same in /etc/modules. I've just removed it and tried your local.conf setting. No success. I have still the same message in dmesg : [0.961200] PowerMac i2c bus pmu 2 registered [0.961236] PowerMac i2c bus pmu 1 registered [0.961272] PowerMac i2c bus mac-io 0 registered [0.961667] PowerMac i2c bus u3 1 registered [0.961725] i2c i2c-3: i2c-powermac: modalias failure on /u3@0,f800/i2c@f8001000/cereal@1c0 [0.961764] PowerMac i2c bus u3 0 registered and [1.361462] Detected fan controls: [1.361467] 0: PWM fan, id 1, location: BACKSIDE,SYS CTRLR FAN [1.361472] 1: RPM fan, id 2, location: DRIVE BAY [1.361477] 2: PWM fan, id 2, location: SLOT,PCI FAN [1.361482] 3: RPM fan, id 3, location: CPU A INTAKE [1.361488] 4: RPM fan, id 4, location: CPU A EXHAUST [1.361493] 5: RPM fan, id 5, location: CPU B INTAKE [1.361498] 6: RPM fan, id 6, location: CPU B EXHAUST [1.361538] i2c i2c-0: therm_pm72: attach_adapter method is deprecated [1.361545] i2c i2c-0: Please use another way to instantiate your i2c_client [1.361553] i2c i2c-1: therm_pm72: attach_adapter method is deprecated [1.361558] i2c i2c-1: Please use another way to instantiate your i2c_client [1.361566] i2c i2c-2: therm_pm72: attach_adapter method is deprecated [1.361572] i2c i2c-2: Please use another way to instantiate your i2c_client [1.361580] i2c i2c-3: therm_pm72: attach_adapter method is deprecated [1.361585] i2c i2c-3: Please use another way to instantiate your i2c_client [1.361596] i2c i2c-3: Failed to register i2c client therm_pm72 at 0x2f (-16) [1.361602] therm_pm72: Failed to attach to i2c ID 0x15e [1.361609] i2c i2c-4: therm_pm72: attach_adapter method is deprecated [1.361615] i2c i2c-4: Please use another way to instantiate your i2c_client [1.361671] i2c i2c-4: Failed to register i2c client therm_pm72 at 0x2c (-16) [1.361677] therm_pm72: Failed to attach to i2c ID 0x58 Not all fans seem to be registered. I also have random kernel panics, but i think it is unrelated to this bug : something about radeon-kms (and I only have a software rasterizer for opengl, even if I boot with the video=offb:off video=radeonfb:off kernel argument.). Thank you again. Le 22/04/2014 05:18, Rick Thomas a écrit : On Apr 21, 2014, at 1:49 PM, Bertrand Dekoninck bdekoni...@free.fr wrote: I've installed jessie with linux-3.13.7-1 last night on my powermac7,3 (2x2.0 ghz). The fans are still crazy, even if i2c-powermac is build-in (and not a module anymore). Hi Bertrand, Have you tried echo 'i2c-powermac' /etc/modules-load.d/local.conf then reboot? I know it's supposed to be compiled-in with this version of the kernel, but maybe it just needs a little push? Rick -- To unsubscribe, send mail to 713943-unsubscr...@bugs.debian.org. -- 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/5bd7be0f-2181-4414-85c9-dd2ee35a8...@pobox.com
Bug#742184: linux-image-3.13-0.bpo.1-686-pae: qemu-kvm unusable with 3.13.7 kernel, oops appears
I think I'm seeing this bug too, need to check the logs later. Its definitely some kind of oops using KVM on 3.13. CPU: Athlon64 X2, 4Gb RAM Kernel: linux-image-3.13-1-686-pae (3.13.10-1 and 3.13.7-1) in Jessie/i386 Bug can be avoided by booting the old 3.12 kernel. Symptoms: Works normally, but if I start a VM, the VM freezes quickly, usually within in BIOS or GRUB. Can be killed regularly. Kernel messages after a while. -- 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/6967de9b6da05f12d684b43bd4910ad0.squir...@www.lan
Bug#741584: booting T440p with Debian testing - problems
Hi, My workaround was to (boot in recovery mode and) blacklist nouveau, as in: # echo 'blacklist nouveau' /etc/modprobe.d/blacklist-nouveau.conf After that, reboot in normal mode. It seems that the 3.13.x kernel is trying to load drivers for both the Intel and NVIDIA cards, and there's a BIOS-related bug that makes the NVIDIA card misbehave when on Linux. Previous versions of the kernel didn't do that. I hope that helps. -- John. On Tue, 2014-04-22 at 14:13 +0300, Mr Smith wrote: I found that you had a very similar problem as myself: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741584 I have bought new Thinkpad T440p and aimed to install dualboot Win7/Debian testing. I have tried the Debian alpha-installer amd64 from 19 March 2014 but the system does not boot correctly (no GUI; login not reacting etc) Is there any workaround? Any help would be appreciated very much! MS
Bug#741584: booting T440p with Debian testing - problems
Thanks John for your prompt response! you are the HERO! your suggestion worked instantly!!! being quite new with Linux I have almost given up after several rounds of installation... I assume this bug will not change even with the stable Debian 7 release (?) - where to find out if this problem will be solved and how? best greetings and Many thanks again!!! MS 2014-04-22 14:30 GMT+03:00 John M. jwmwal...@gmail.com: Hi, My workaround was to (boot in recovery mode and) blacklist nouveau, as in: # echo 'blacklist nouveau' /etc/modprobe.d/blacklist-nouveau.conf After that, reboot in normal mode. It seems that the 3.13.x kernel is trying to load drivers for both the Intel and NVIDIA cards, and there's a BIOS-related bug that makes the NVIDIA card misbehave when on Linux. Previous versions of the kernel didn't do that. I hope that helps. -- John. On Tue, 2014-04-22 at 14:13 +0300, Mr Smith wrote: I found that you had a very similar problem as myself: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741584 I have bought new Thinkpad T440p and aimed to install dualboot Win7/Debian testing. I have tried the Debian alpha-installer amd64 from 19 March 2014 but the system does not boot correctly (no GUI; login not reacting etc) Is there any workaround? Any help would be appreciated very much! MS
Processed: found 742184 in 3.13.7-1, found 742184 in 3.13.10-1
Processing commands for cont...@bugs.debian.org: found 742184 3.13.7-1 Bug #742184 [src:linux] linux-image-3.13-0.bpo.1-686-pae: qemu-kvm unusable with 3.13.5 kernel, oops appears Marked as found in versions linux/3.13.7-1. found 742184 3.13.10-1 Bug #742184 [src:linux] linux-image-3.13-0.bpo.1-686-pae: qemu-kvm unusable with 3.13.5 kernel, oops appears Marked as found in versions linux/3.13.10-1. thanks Stopping processing here. Please contact me if you need assistance. -- 742184: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742184 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: https://lists.debian.org/handler.s.c.139818126821176.transcr...@bugs.debian.org
Bug#742184: linux-image-3.13-0.bpo.1-686-pae: qemu-kvm unusable with 3.13.7 kernel, oops appears
On Tue, 2014-04-22 at 12:00 +0200, Udo Richter wrote: I think I'm seeing this bug too, need to check the logs later. Its definitely some kind of oops using KVM on 3.13. CPU: Athlon64 X2, 4Gb RAM Kernel: linux-image-3.13-1-686-pae (3.13.10-1 and 3.13.7-1) in Jessie/i386 Bug can be avoided by booting the old 3.12 kernel. Symptoms: Works normally, but if I start a VM, the VM freezes quickly, usually within in BIOS or GRUB. Can be killed regularly. Kernel messages after a while. You can report this upstream (k...@vger.kernel.org) but I will say that KVM on i386 generally doesn't get a lot of developer attention. You can install an amd64 kernel and still use i386 userland (I've been doing it for years). There are occasional bugs in this but they tend to be fixed quickly. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Bug#605090: Proposing amd64-hardened architecture for Debian
On Mon, 2014-04-21 at 05:28 +0200, Carlos Alberto Lopez Perez wrote: On 17/04/14 00:23, Aaron Zauner wrote: Now shipping grsec is a really good idea. I'd like to see that as well. There has been an attempt to provide an official grsec-flavour of the Debian kernel, but it didn't worked: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090 For those interested, Corsac provides packages: https://wiki.debian.org/grsecurity There was a recent discussion on -private where I think there was some consensus that a grsecurity kernel package could be included in Debian as a separate source package. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Bug#742184: linux-image-3.13-0.bpo.1-686-pae: qemu-kvm unusable with 3.13.7 kernel, oops appears
For reference, my oops:
INFO: rcu_sched self-detected stall on CPU { 0} (t=5250 jiffies g=7643
c=7642 q=2543)
sending NMI to all CPUs:
NMI backtrace for cpu 0
CPU: 0 PID: 5205 Comm: qemu-system-x86 Not tainted 3.13-1-686-pae #1 Debian
3.13.10-1
Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./ALiveN570SLI-eSATA2, BIOS P1.20 04/12/2008
task: efe4e920 ti: f0aa6000 task.ti: f0aa6000
EIP: 0060:[c1221a83] EFLAGS: 0016 CPU: 0
EIP is at __const_udelay+0x3/0x20
EAX: 01062560 EBX: 2710 ECX: f000 EDX: f000
ESI: c1578440 EDI: c1578440 EBP: ESP: f0aa7cd0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: CR3: 2febb000 CR4: 07f0
Stack:
c103932d c14cdc87 f79b7840 c109a3ea c14dbde0 1482 1ddb 1dda
09ef 002a f79b7840 c1578440 c15b51ac 0092
efe4e920 002a c1059084 f0aa7df4 f0aa7df4 f8df3a83
Call Trace:
[c103932d] ? arch_trigger_all_cpu_backtrace+0x4d/0x70
[c109a3ea] ? rcu_check_callbacks+0x37a/0x5b0
[c1059084] ? update_process_times+0x34/0x60
[c10a492c] ? tick_sched_handle.isra.12+0x1c/0x50
[c10a498f] ? tick_sched_timer+0x2f/0x60
[c106b4f7] ? __remove_hrtimer+0x27/0x80
[c106b6fb] ? __run_hrtimer+0x6b/0x190
[c10a4960] ? tick_sched_handle.isra.12+0x50/0x50
[c106c311] ? hrtimer_interrupt+0x201/0x2c0
[c10374a7] ? local_apic_timer_interrupt+0x27/0x50
[c1051e9d] ? irq_enter+0xd/0x60
[c103763b] ? smp_apic_timer_interrupt+0x2b/0x50
[c14108fc] ? apic_timer_interrupt+0x34/0x3c
[f99cbc67] ? kvm_arch_vcpu_ioctl_run+0x267/0x10a0 [kvm]
[f98b6894] ? svm_compute_tsc_offset+0x14/0xb0 [kvm_amd]
[f99c8bec] ? kvm_arch_vcpu_load+0x18c/0x1f0 [kvm]
[f99baead] ? kvm_vcpu_ioctl+0x3fd/0x4a0 [kvm]
[f99baab0] ? vcpu_put+0x20/0x20 [kvm]
[c1151dc7] ? do_vfs_ioctl+0x307/0x500
[c10a8c5c] ? SyS_futex+0x8c/0x160
[c1152020] ? SyS_ioctl+0x60/0x80
[c1416fcd] ? sysenter_do_call+0x12/0x28
Code: 00 8d bc 27 00 00 00 00 48 75 fd 48 c3 8d 74 26 00 8d bc 27 00 00 00 00
ff 15 30 2c 59 c1 f3 c3 90 8d b4 26 00 00 00 00 c1 e0 02 64 8b 15 9c de 63
c1 6b d2 3e f7 e2 8d 42 01 ff 15 30 2c 59 c1
NMI backtrace for cpu 1
CPU: 1 PID: 5096 Comm: kwin Not tainted 3.13-1-686-pae #1 Debian 3.13.10-1
Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./ALiveN570SLI-eSATA2, BIOS P1.20 04/12/2008
task: f09feda0 ti: eff98000 task.ti: eff98000
EIP: 0073:[b73ea1bc] EFLAGS: 00200202 CPU: 1
EIP is at 0xb73ea1bc
EAX: 09a63a90 EBX: b751d000 ECX: 09a83940 EDX: b751d434
ESI: b751d42c EDI: 09a63a90 EBP: b751d420 ESP: bfb0ff20
DS: 007b ES: 007b FS: GS: 0033 SS: 007b
I've tried the 3.13-1-486 and the 3.13-1-amd64 kernels of Jessie/i386,
and both seem to work. For now I'm staying on the -amd64 kernel, wanted
to do this anyway.
--
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/5356c326.3040...@gmx.de
Re: Bug#605090: Proposing amd64-hardened architecture for Debian
Ben Hutchings b...@decadent.org.uk schrieb: There was a recent discussion on -private where I think there was some consensus that a grsecurity kernel package could be included in Debian as a separate source package. Ack. Quoting myself from the thread on -private for public discussion: | If grsec is introduced, then it needs to be separate source package to | remain as close to upstream as possible (modulo DFSG firmware bits). | | If it is a different source package (and not building linux-libc-dev) | I don't see much of a problem if the grsec kernel is two or three | revisions behind src:linux. | | As far as security triage for grsec is concerned it will be sufficient to | follow the grsec releases in stable. Ubuntu 14.04 LTS will be based on | 3.13, so all important bugfixes will land in 3.13.x longterm (plus | several vulnerabilities will be moot in grsec) As for the proposal on amd64-hardened: I would prefer if we focus on the hardening features available for all (making everyone profit from enhanced security). Some of the plans mentioned in https://lists.debian.org/debian-devel-announce/2014/03/msg4.html could use someone driving the effort to speed things up: - GCC 4.9 has been released today, organise an archive rebuild with gcc-defaults pointing to 4.9 and dpkg-buildflags emitting -fstack-protector-strong - Work on hidepid=1 by default, post debs for people to test-drive and fixup regressions in userland Cheers, Moritz -- 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/slrnlldj9o.2ie@inutil.org
Re: Arm64 port live on debian-ports
On Mon, 2014-04-21 at 13:40 -0600, dann frazier wrote: On Sun, Apr 20, 2014 at 05:29:13PM +0100, Ian Campbell wrote: On Sun, 2014-04-20 at 09:08 -0700, Vagrant Cascadian wrote: On Sun, Apr 20, 2014 at 04:28:45PM +0100, Ian Campbell wrote: On Sun, 2014-04-20 at 16:13 +0100, Ben Hutchings wrote: Given that, it seems like a good time to add arm64 to src:linux with a configuration that will run on at least a typical QEMU ARM64 emulation. AIUI qemu 2.0 only does qemu-aarch64-user, with the system emulation portion slated to be merged shortly[0]. Not sure if it works, but qemu-system-aarch64 is in the 2.0 packages in sid: https://packages.debian.org/search?suite=sidsearchon=contentskeywords=qemu-system-aarch64 $ qemu-system-aarch64 No machine specified, and there is no default. Use -machine help to list supported machines! $ qemu-system-aarch64 -machine ? [... a long list of 32-bit arm = v7 machines, AFAICT ...] I've not actually tried it, but it doesn't look likely to work. Yeah - at this point qemu-system is only usable for KVM accelerated VMs on said mythical hardware. Only broadly available test platform for a kernel would be the ARM fast model. Some instructions for generating a bootable image for that are here: https://wiki.ubuntu.com/ARM64/FoundationModel Thanks, that's pretty much what I was planning to do. Ian. -- 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/1398198264.27649.40.ca...@dagon.hellion.org.uk
Re: Bug#605090: Proposing amd64-hardened architecture for Debian
Moritz Mühlenhoff j...@inutil.org schrieb: all (making everyone profit from enhanced security). Some of the plans mentioned in https://lists.debian.org/debian-devel-announce/2014/03/msg4.html could use someone driving the effort to speed things up: Also: - Work on rootless Xorg for jessie (http://lwn.net/Articles/590296/). Cheers, Moritz -- 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/slrnlldjlj.316@inutil.org
Bug#605090: Proposing amd64-hardened architecture for Debian
On Tue, Apr 22, 2014 at 08:30:01PM +0100, Ben Hutchings wrote: On Mon, 2014-04-21 at 05:28 +0200, Carlos Alberto Lopez Perez wrote: On 17/04/14 00:23, Aaron Zauner wrote: Now shipping grsec is a really good idea. I'd like to see that as well. There has been an attempt to provide an official grsec-flavour of the Debian kernel, but it didn't worked: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090 For those interested, Corsac provides packages: https://wiki.debian.org/grsecurity There was a recent discussion on -private where I think there was some consensus that a grsecurity kernel package could be included in Debian as a separate source package. I'm a bit unsure about that consensus. Right now there are two attempts to provide a grsecurity package for Debian: - mine, which is about adding a grsec featureset to the src:linux package (so basically adding grsec patch on top of the Debian patches, and re-using everything else). This attempt was already NACK-ed by the kernel team; - the Mempo/SameKernel attempt, which is about using a vanilla kernel and adding grsecurity on top of it (and, I guess, a .config which looks like the src:linux one) The latter is much easier in term of management since all the integration is done by spender (he's actually working on providing .deb builds of grsec packages), so I didn't really consider it worthy to investigate time on it since basically everyone can do it with a simple script. NOTE: I don't want to dismiss Mempo attempts, especially the reproducible build part, and I also think it's valuable to provide our users a grsec kernel as part of the distribution, just that I prefered to go the featureset way. I had the impression that adding a new copy of the linux sources was not really something appreciated by the project, and re-using linux-source (binary) package means the patch porting needs to be done anyway. But if I'm wrong or if things have changed since them, and there's indeed a consensus for the vanilla + grsecurity + make deb-pkg as an easy way to provide grsec kernels in the Debian archive, then I'm all for it. Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Processing of linux_3.2.57-3_multi.changes
linux_3.2.57-3_multi.changes uploaded successfully to localhost along with the files: linux_3.2.57-3.dsc linux_3.2.57-3.debian.tar.xz linux-support-3.2.0-4_3.2.57-3_all.deb linux-doc-3.2_3.2.57-3_all.deb linux-manual-3.2_3.2.57-3_all.deb linux-source-3.2_3.2.57-3_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1wcijn-0002h9...@franck.debian.org
