Bug#683807: AMI BIOS detected: BIOS may corrupt low RAM, working around it.
Hi, i've found this in a syslog on my debian stable installation /var/log directory: Aug 21 17:11:35 *** kernel: [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it. Could this message indicate the root of all these corruption/instability problems? And what could it mean? My bios is corrupted and it is also corrupting memory? 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/12473533.8948551346143647789.JavaMail.defaultUser@defaultHost
Bug#686080: linux-image-3.2.0-3-686-pae: none
Package: src:linux Version: 3.2.0-3-686-pae Severity: normal Dear Maintainer, I have installed linux-image-3.2.0-3-686-pae , xserver-xorg-video-radeon and all firmware packets and i had a logs in xorg similar to (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch. [dri] This chipset requires a kernel module version of 1.17.0, [dri] but the kernel reports a version of 2.0.0.[dri] If using legacy modesetting, upgrade your kernel. [dri] If using kernel modesetting, make sure your module is [dri] loaded prior to starting X, and that this driver was built [dri] with support for KMS. [dri] Disabling DRI so i found this side http://www.x.org/wiki/radeonBuildHowTo#Troubleshooting i was trying loaded radeon kernel-module with KMS enabled before X is started echo 'GRUB_CMDLINE_LINUX=radeon.modeset=1' /etc/default/grub but this didn't work next is that, kernel config needs CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware CONFIG_EXTRA_FIRMWARE=radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin radeon/CYPRESS_me.bin radeon/CYPRESS_pfp.bin radeon/CYPRESS_rlc.bin radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/JUNIPER_rlc.bin radeon/R600_rlc.bin radeon/R700_rlc.bin radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/REDWOOD_rlc.bin i added this and radeon/RS690_cp.bin, recomplie kernel and it's working so i think it can be bug Dawid Juszczyszyn -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information not available ** Network interface configuration: auto lo iface lo inet loopback allow-hotplug eth1 iface eth1 inet static address 192.168.1.2 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 dns-nameservers 85.14.85.2 85.14.85.14 ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] nee ATI RS690 Host Bridge [1002:7910] Subsystem: Giga-byte Technology Device [1458:5000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 32 00:01.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RS690 PCI to PCI Bridge (Internal gfx) [1002:7912] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 99 Bus: primary=00, secondary=01, subordinate=01, sec-latency=68 I/O behind bridge: e000-efff Memory behind bridge: fde0-fdff Prefetchable memory behind bridge: d800-dfff Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied 00:12.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB600 Non-Raid-5 SATA [1002:4380] (prog-if 01 [AHCI 1.0]) Subsystem: Giga-byte Technology Device [1458:b002] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 Interrupt: pin A routed to IRQ 22 Region 0: I/O ports at ff00 [size=8] Region 1: I/O ports at fe00 [size=4] Region 2: I/O ports at fd00 [size=8] Region 3: I/O ports at fc00 [size=4] Region 4: I/O ports at fb00 [size=16] Region 5: Memory at fe02f000 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied Kernel driver in use: ahci 00:13.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI0) [1002:4387] (prog-if 10 [OHCI]) Subsystem: Giga-byte Technology Device [1458:5004] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32, Cache Line Size: 4 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at fe02e000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:13.1 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI1) [1002:4388] (prog-if 10 [OHCI]) Subsystem: Giga-byte Technology Device [1458:5004] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32, Cache Line Size: 4 bytes Interrupt: pin B routed to IRQ 17 Region 0: Memory at fe02d000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:13.2 USB controller
Bug#684441: [PATCH v2] [media] rc: ite-cir: Initialise ite_dev::rdev earlier
On Mon, Aug 20, 2012 at 12:32:27AM +0100, Ben Hutchings wrote: ite_dev::rdev is currently initialised in ite_probe() after rc_register_device() returns. If a newly registered device is opened quickly enough, we may enable interrupts and try to use ite_dev::rdev before it has been initialised. Move it up to the earliest point we can, right after calling rc_allocate_device(). I believe this is the same bug: https://bugzilla.kernel.org/show_bug.cgi?id=46391 And the bug is present in other IR devices as well. I've sent a proposed fix: http://marc.info/?l=linux-kernelm=134590803109050w=2 Cheers, -- Luis References: http://bugs.debian.org/684441 Reported-and-tested-by: YunQiang Su wzss...@gmail.com Signed-off-by: Ben Hutchings b...@decadent.org.uk Cc: sta...@vger.kernel.org --- Unlike the previous version, this will apply cleanly to the media staging/for_v3.6 branch. Ben. drivers/media/rc/ite-cir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c index 36fe5a3..24c77a4 100644 --- a/drivers/media/rc/ite-cir.c +++ b/drivers/media/rc/ite-cir.c @@ -1473,6 +1473,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id rdev = rc_allocate_device(); if (!rdev) goto failure; + itdev-rdev = rdev; ret = -ENODEV; @@ -1604,7 +1605,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id if (ret) goto failure3; - itdev-rdev = rdev; ite_pr(KERN_NOTICE, driver has been successfully loaded\n); return 0; -- 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/20120828114409.GA3191@zeus
Bug#685972: [Fwd: Re: Bug#685972: Acknowledgement (linux-image-3.2.0-3-amd64: kernel BUG at /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/pci/msi.c:316!)]
Forwarded Message From: mario dix ma...@madix.de To: Ben Hutchings b...@decadent.org.uk Subject: Re: Bug#685972: Acknowledgement (linux-image-3.2.0-3-amd64: kernel BUG at /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/pci/msi.c:316!) Date: Tue, 28 Aug 2012 10:41:52 +0200 On 08/28/2012 02:09 AM, Ben Hutchings wrote: Does this happen every time networking is brought up? Does it still happen if you remove VMware? Ben. Hi, So far it happened only once when resuming from suspend mode. It's a Lenovo T420s. Perhaps, it was just an one-off hiccup. Mario -- 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/1346164381.15747.3.ca...@deadeye.wl.decadent.org.uk
Processed: tagging 685972, tagging 685972
Processing commands for cont...@bugs.debian.org: tags 685972 - moreinfo Bug #685972 [src:linux] linux-image-3.2.0-3-amd64: kernel BUG at /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/pci/msi.c:316! Removed tag(s) moreinfo. tags 685972 + unreproducible Bug #685972 [src:linux] linux-image-3.2.0-3-amd64: kernel BUG at /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/pci/msi.c:316! Added tag(s) unreproducible. thanks Stopping processing here. Please contact me if you need assistance. -- 685972: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685972 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.13461644053025.transcr...@bugs.debian.org
Bug#684516: Bug#683807: AMI BIOS detected: BIOS may corrupt low RAM, working around it.
On Tue, 2012-08-28 at 10:47 +0200, asronche...@libero.it wrote: Hi, i've found this in a syslog on my debian stable installation /var/log directory: Aug 21 17:11:35 *** kernel: [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it. Could this message indicate the root of all these corruption/instability problems? Don't think so. And what could it mean? My bios is corrupted and it is also corrupting memory? It's a known bug in many versions of the AMI BIOS code, but it only affects specific areas of memory. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#686080: radeon: This chipset requires a kernel module version of 1.17.0
przypadek wrote: I have installed linux-image-3.2.0-3-686-pae , xserver-xorg-video-radeon What version of xserver-xorg-video-radeon do you have? [...] [dri] This chipset requires a kernel module version of 1.17.0, [dri] but the kernel reports a version of 2.0.0. It sounds like it is slightly out of date (and the modesetting ABI is unfortunately still not as stable as we would like it to be). Curious, 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/20120828144716.GA927@mannheim-rule.local
Bug#686080: radeon: This chipset requires a kernel module version of 1.17.0
On Die, 2012-08-28 at 07:47 -0700, Jonathan Nieder wrote: przypadek wrote: I have installed linux-image-3.2.0-3-686-pae , xserver-xorg-video-radeon What version of xserver-xorg-video-radeon do you have? [...] [dri] This chipset requires a kernel module version of 1.17.0, [dri] but the kernel reports a version of 2.0.0. It sounds like it is slightly out of date [...] Not necessarily. The above means that KMS is enabled in the kernel, but the X driver is using UMS. This cannot work properly. Make sure the radeon kernel module is loaded before X starts. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- 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/1346165492.2924.737.camel@thor.local
Bug#686080: radeon: This chipset requires a kernel module version of 1.17.0
Hi, Michel Dänzer wrote: On Die, 2012-08-28 at 07:47 -0700, Jonathan Nieder wrote: przypadek wrote: [dri] This chipset requires a kernel module version of 1.17.0, [dri] but the kernel reports a version of 2.0.0. It sounds like it is slightly out of date [...] Not necessarily. The above means that KMS is enabled in the kernel, but the X driver is using UMS. Good catch. Sorry for the nonsense. This cannot work properly. Make sure the radeon kernel module is loaded before X starts. Now that you mention it, I seem to remember this coming up before once (for a different reason). The X server message is not very clear; is that fixable? Dawid wrote: next is that, kernel config needs CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware CONFIG_EXTRA_FIRMWARE=radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin radeon/CYPRESS_me.bin radeon/CYPRESS_pfp.bin radeon/CYPRESS_rlc.bin radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/JUNIPER_rlc.bin radeon/R600_rlc.bin radeon/R700_rlc.bin radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/REDWOOD_rlc.bin i added this and radeon/RS690_cp.bin, recomplie kernel and it's working so i think it can be bug Dawid, could you provide a full kernel log (dmesg output) from booting a woorking and a non-working kernel? Sorry for the confusion, 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/20120828150330.GA998@mannheim-rule.local
Bug#686080: radeon: This chipset requires a kernel module version of 1.17.0
On 28.08.2012 17:03, Jonathan Nieder wrote: Dawid, could you provide a full kernel log (dmesg output) from booting a woorking and a non-working kernel? Sorry for the confusion, Jonathan No I can't, because I checked old kernel, and now is also working I removed this modeset option from grub, reload, and all is fine I'm providing logs anyway, maybe it will help new http://pastebin.com/zRsyMPDQ old http://pastebin.com/y002ykkL -- 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/503cf8fd.7090...@vp.pl
Bug#684441: [PATCH v2] [media] rc: ite-cir: Initialise ite_dev::rdev earlier
On Tue, 2012-08-28 at 12:44 +0100, Luis Henriques wrote: On Mon, Aug 20, 2012 at 12:32:27AM +0100, Ben Hutchings wrote: ite_dev::rdev is currently initialised in ite_probe() after rc_register_device() returns. If a newly registered device is opened quickly enough, we may enable interrupts and try to use ite_dev::rdev before it has been initialised. Move it up to the earliest point we can, right after calling rc_allocate_device(). I believe this is the same bug: https://bugzilla.kernel.org/show_bug.cgi?id=46391 And the bug is present in other IR devices as well. I've sent a proposed fix: http://marc.info/?l=linux-kernelm=134590803109050w=2 It might be a worthwhile fix. But it doesn't fix this bug - after that patch, the driver will still enable its IRQ before initialising ite_dev::rdev. Ben. Cheers, -- Luis References: http://bugs.debian.org/684441 Reported-and-tested-by: YunQiang Su wzss...@gmail.com Signed-off-by: Ben Hutchings b...@decadent.org.uk Cc: sta...@vger.kernel.org --- Unlike the previous version, this will apply cleanly to the media staging/for_v3.6 branch. Ben. drivers/media/rc/ite-cir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c index 36fe5a3..24c77a4 100644 --- a/drivers/media/rc/ite-cir.c +++ b/drivers/media/rc/ite-cir.c @@ -1473,6 +1473,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id rdev = rc_allocate_device(); if (!rdev) goto failure; + itdev-rdev = rdev; ret = -ENODEV; @@ -1604,7 +1605,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id if (ret) goto failure3; - itdev-rdev = rdev; ite_pr(KERN_NOTICE, driver has been successfully loaded\n); return 0; -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#685864: linux-image-3.2.0-3-amd64: Commande halt or halt -p and shutdown = reboot system. Cm :gigabyte z77x-ud5h
Forwarded Message From: novice gavo...@panthere-noire.com To: Ben Hutchings b...@decadent.org.uk Subject: Re: Bug#685864: linux-image-3.2.0-3-amd64: Commande halt or halt -p and shutdown = reboot system. Cm :gigabyte z77x-ud5h Date: Tue, 28 Aug 2012 03:06:46 +0200 Le 28. 08. 12 01:49, Ben Hutchings a écrit : [Please reply to all, including the address 685...@bugs.debian.org] On Sun, 2012-08-26 at 12:33 +0200, novice wrote: Le 26. 08. 12 02:49, Ben Hutchings a écrit : On Sat, 2012-08-25 at 17:25 +0200, novice wrote: Package: src:linux Version: 3.2.23-1 What was the last version where you could halt successfully? Severity: important Use root : command: halt halt -p shutdown (all paramettre tested) result: reboot, Is the system booted through BIOS or UEFI? (There is a known bug like this when using UEFI.) UFEI not available Bios: 08/26/2012: bios id 8A01AG0E option approaching: Pci Rom priority: 2 value Legacy Rom EFI compatible Rom 2 value = reboot Do you mean that you tried both values for that option? yes [...] ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. [...] ** Loaded modules: [...] nvidia(P) [...] Does this happen if you use nouveau instead of nvidia? Ben. nvidia , im tested , and console only , close kde, or use mode rescue in grub (tty1) result [while now restart] I don't understand what you're saying. I want you to try this: 1. Uninstall the nvidia driver (or somehow stop it from loading) yes . I also tested modprobe -r nvidia 2. Reboot reboot . 3. Run 'shutdown' Ben. use: shutdown -h nows result reboot. thank you for your patience -- 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/1346173919.15747.30.ca...@deadeye.wl.decadent.org.uk
Processed: tagging 686040
Processing commands for cont...@bugs.debian.org: tags 686040 + pending Bug #686040 [src:linux] linux-image-3.5-trunk-amd64: lpc_ich: Resource conflict(s) found affecting iTCO_wdt and gpio_ich Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 686040: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686040 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.134617707731527.transcr...@bugs.debian.org
Processed: tagging 685894
Processing commands for cont...@bugs.debian.org: tags 685894 + pending Bug #685894 [src:linux] linux FTBFS on alpha: gcc-4.5 no longer available Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 685894: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685894 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.13461775152807.transcr...@bugs.debian.org
Bug#686080: radeon: This chipset requires a kernel module version of 1.17.0
On Die, 2012-08-28 at 08:03 -0700, Jonathan Nieder wrote: Michel Dänzer wrote: On Die, 2012-08-28 at 07:47 -0700, Jonathan Nieder wrote: przypadek wrote: [dri] This chipset requires a kernel module version of 1.17.0, [dri] but the kernel reports a version of 2.0.0. It sounds like it is slightly out of date [...] Not necessarily. The above means that KMS is enabled in the kernel, but the X driver is using UMS. Good catch. Sorry for the nonsense. This cannot work properly. Make sure the radeon kernel module is loaded before X starts. Now that you mention it, I seem to remember this coming up before once (for a different reason). The X server message is not very clear; is that fixable? It was improved upstream in the meantime, but current upstream no longer supports UMS anyway. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- 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/1346178210.2924.757.camel@thor.local
Bug#685864: linux-image-3.2.0-3-amd64: Commande halt or halt -p and shutdown = reboot system. Cm :gigabyte z77x-ud5h
[Please reply to all, including the address 685...@bugs.debian.org] vrom: novice gavo...@panthere-noire.com Date: Tue, 28 Aug 2012 03:06:46 +0200 1. Uninstall the nvidia driver (or somehow stop it from loading) yes . I also tested modprobe -r nvidia `modprobe -r nvidia` removes the nvidia kernel module from memory. It is the undo of `modprobe nvidia`, which loads it in memory. BUT: modprode is MORE then just load and unload, there is also programcode from the kernel module executed. During load there is initialization done. The request is uninstall the nvidia module. To remove it from disk. With the effect to stop it from loading and executing init code. 2. Reboot reboot . That reboot is to clear initialiastion the nvidia driver could have done. 3. Run 'shutdown' Ben. use: shutdown -h nows result reboot. That is the reason for this ticket :-/ thank you for your patience This E-mail is / was about telling that uninstall is more then `modprobe -r modulename` Groeten Geert Stappers -- And is there a policy on top-posting vs. bottom-posting? Yes. -- 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/20120828195929.gw22...@gpm.stappers.nl
Bug#686080: radeon: This chipset requires a kernel module version of 1.17.0
xorg version: 1:7.5+8 I was thinking what else i did, and i remind my self that meantime kernel compilation, there was a massage that I maybe need packet module-init-tools, and I installed it. Maybe that is a problem? -- 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/503d29f3.6090...@vp.pl
Bug#684441: [PATCH v2] [media] rc: ite-cir: Initialise ite_dev::rdev earlier
On Tue, Aug 28, 2012 at 10:09:55AM -0700, Ben Hutchings wrote: On Tue, 2012-08-28 at 12:44 +0100, Luis Henriques wrote: On Mon, Aug 20, 2012 at 12:32:27AM +0100, Ben Hutchings wrote: ite_dev::rdev is currently initialised in ite_probe() after rc_register_device() returns. If a newly registered device is opened quickly enough, we may enable interrupts and try to use ite_dev::rdev before it has been initialised. Move it up to the earliest point we can, right after calling rc_allocate_device(). I believe this is the same bug: https://bugzilla.kernel.org/show_bug.cgi?id=46391 And the bug is present in other IR devices as well. I've sent a proposed fix: http://marc.info/?l=linux-kernelm=134590803109050w=2 It might be a worthwhile fix. But it doesn't fix this bug - after that patch, the driver will still enable its IRQ before initialising ite_dev::rdev. You're absolutely right, sorry for the noise. I should have taken a closer look at your patch. Cheers, -- Luis Ben. Cheers, -- Luis References: http://bugs.debian.org/684441 Reported-and-tested-by: YunQiang Su wzss...@gmail.com Signed-off-by: Ben Hutchings b...@decadent.org.uk Cc: sta...@vger.kernel.org --- Unlike the previous version, this will apply cleanly to the media staging/for_v3.6 branch. Ben. drivers/media/rc/ite-cir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c index 36fe5a3..24c77a4 100644 --- a/drivers/media/rc/ite-cir.c +++ b/drivers/media/rc/ite-cir.c @@ -1473,6 +1473,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id rdev = rc_allocate_device(); if (!rdev) goto failure; + itdev-rdev = rdev; ret = -ENODEV; @@ -1604,7 +1605,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id if (ret) goto failure3; - itdev-rdev = rdev; ite_pr(KERN_NOTICE, driver has been successfully loaded\n); return 0; -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein -- 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/20120828204823.GE3191@zeus
Bug#685894: linux FTBFS on alpha: gcc-4.5 no longer available
On Sun, 2012-08-26 at 15:01 +1200, Michael Cree wrote: [...] So if you could remove the requirement to build the kernel with gcc-4.5 and apply the attached patch to switch to the large data model for the next linux source upload, I should be grateful. Applied, thanks. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#686080: radeon: This chipset requires a kernel module version of 1.17.0
przypadek wrote: xorg version: 1:7.5+8 I was thinking what else i did, and i remind my self that meantime kernel compilation, there was a massage that I maybe need packet module-init-tools, and I installed it. Maybe that is a problem? Sure, can you reproduce this using kmod instead of module-init-tools? But I expect it's related to the set of installed firmware. -- 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/20120828210455.ga...@mannheim-rule.att.net
Processed: severity of 683047 is important
Processing commands for cont...@bugs.debian.org: severity 683047 important Bug #683047 [src:linux] usbip: Kernel oops when attaching device with usbip Severity set to 'important' from 'grave' thanks Stopping processing here. Please contact me if you need assistance. -- 683047: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683047 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.134618810815735.transcr...@bugs.debian.org
Processed: severity of 685726 is serious, tagging 685726
Processing commands for cont...@bugs.debian.org: severity 685726 serious Bug #685726 [src:linux] linux-image-3.2.0-3-amd64: return error when trying to format image file (mkfs -t ext4 file.img) Severity set to 'serious' from 'critical' tags 685726 + security Bug #685726 [src:linux] linux-image-3.2.0-3-amd64: return error when trying to format image file (mkfs -t ext4 file.img) Added tag(s) security. thanks Stopping processing here. Please contact me if you need assistance. -- 685726: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685726 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.134619329621484.transcr...@bugs.debian.org
Bug#685726: linux-image-3.2.0-3-amd64: return error when trying to format image file (mkfs -t ext4 file.img)
On Sun, 2012-08-26 at 00:56 +0400, hr...@infotech.am wrote: On Fri, 2012-08-24 at 03:30 +0400, Hrayr Grigoryan wrote: Package: src:linux Version: 3.2.23-1 Severity: critical Tags: lfs Justification: causes serious data loss Dear Maintainer, When I'm trying to format file image with the command mkfs -t ext4 file.img, it returns the following errors [ 142.328065] EXT4-fs error (device sdb1): ext4_ext_map_blocks:3769: inode #12: comm mkfs.ext4: bad extent address lblock: 1022, depth: 2 pblock 0 [ 142.328387] EXT4-fs error (device sdb1): ext4_ext_map_blocks:3769: inode #12: comm mkfs.ext4: bad extent address lblock: 1023, depth: 2 pblock 0 [ 142.328699] EXT4-fs error (device sdb1): ext4_ext_map_blocks:3769: inode #12: comm mkfs.ext4: bad extent address lblock: 9254, depth: 2 pblock 0 [ 142.329018] EXT4-fs error (device sdb1): ext4_ext_map_blocks:3769: inode #12: comm mkfs.ext4: bad extent address lblock: 1057, depth: 2 pblock 0 [...] Have you tested this on any other kernel versions (earlier or later)? Yes, I have tested with the earlier versions, all earlier versions of 3.x.x kernels have this bug. I talked to the ext4 maintainer about this. He recognised the problem and said you can work around this by adding the option '-E nodiscard' when running mke2fs. This is supposed to be fixed in Linux 3.5.3 (not yet available in Debian). We will try to get it fixed in Linux 3.2.y soon. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#685726: linux-image-3.2.0-3-amd64: return error when trying to format image file (mkfs -t ext4 file.img)
As discussed, Linux 3.2.y needs a backport of the fixes for this, which I think are: 968dee7 ext4: fix hole punch failure when depth is greater than 0 89a4e48 ext4: fix kernel BUG on large-scale rm -rf commands Ben. On Sun, 2012-08-26 at 00:56 +0400, hr...@infotech.am wrote: On Fri, 2012-08-24 at 03:30 +0400, Hrayr Grigoryan wrote: Package: src:linux Version: 3.2.23-1 Severity: critical Tags: lfs Justification: causes serious data loss Dear Maintainer, When I'm trying to format file image with the command mkfs -t ext4 file.img, it returns the following errors [ 142.328065] EXT4-fs error (device sdb1): ext4_ext_map_blocks:3769: inode #12: comm mkfs.ext4: bad extent address lblock: 1022, depth: 2 pblock 0 [ 142.328387] EXT4-fs error (device sdb1): ext4_ext_map_blocks:3769: inode #12: comm mkfs.ext4: bad extent address lblock: 1023, depth: 2 pblock 0 [ 142.328699] EXT4-fs error (device sdb1): ext4_ext_map_blocks:3769: inode #12: comm mkfs.ext4: bad extent address lblock: 9254, depth: 2 pblock 0 [ 142.329018] EXT4-fs error (device sdb1): ext4_ext_map_blocks:3769: inode #12: comm mkfs.ext4: bad extent address lblock: 1057, depth: 2 pblock 0 So you have an ext4 filesystem in file.img, on top of an ext4 filesystem on /dev/sdb1? yes, all are ext4, no other file systems I have on that machine. The problem visible only for big images f.x. 160Gb and more. I did the tests on different hardwares, but result the same. [...] How is test.img created, before you run mkfs? Is it a sparse file or does it have all data blocks allocated? No it is not sparse file, test.img was created with the following command dd if=/dev/zero of=test.img bs=1M count=160k Have you tested this on any other kernel versions (earlier or later)? Yes, I have tested with the earlier versions, all earlier versions of 3.x.x kernels have this bug. Hrayr. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
Bug#674243: #674243,linux-image-3.2.0-2-amd64: Kernel crash when closing the lid
Hello, After a lot of tries, I found out which module causes the crash, it's CONFIG_HOTPLUG_PCI_ACPI (module acpiphp). When it's built as a module, it's not loaded by default on my machine, and closing the lid works. But if I load it, it crashes. What else could I do to get more information about this crash? maybe fill a report upstream? Sylvain -- 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/503d6abf.8040...@laposte.net
