Processed: Re: Bug#693762: linux-image-3.2.0-4-amd64: General Protection Fault
Processing control commands: tag -1 moreinfo Bug #693762 [src:linux] linux-image-3.2.0-4-amd64: General Protection Fault Added tag(s) moreinfo. -- 693762: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693762 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.b693762.135341651012431.transcr...@bugs.debian.org
Bug#693762: linux-image-3.2.0-4-amd64: General Protection Fault
Control: tag -1 moreinfo On Mon, 2012-11-19 at 21:49 -0500, Neal Murphy wrote: [...] Regardless of what I do as a mortal user, I shoudn't get a black screen of death. Absolutely. Attached is a jpg of the screen; I have the 15MP original if I removed too much detail. [...] This is a *great* picture, absolutely clear. So the code tells me that the processor was instructed to read from the address in RCX, and the dump shows me that the value is: RCX: f7ffc952c1d8 Current 64-bit x86 processors really only use 48-bit virtual addresses, which must begin with or . So this address seems to have been corrupted: a single bit has changed. This could be caused by a software bug but it looks much more like a hardware fault. You may be able to confirm a RAM fault with memtest86+. Unfortunately it doesn't reliably find faults, and it doesn't particularly stress the CPU or other parts of the system that could also be at fault. Ben. -- Ben Hutchings compatible: Gracefully accepts erroneous data from any source signature.asc Description: This is a digitally signed message part
Bug#688198: megasas: Failed to alloc kernel SGL buffer for IOCTL - Possible regression from 2.6.32.41~3
FYI - I'm seeing this same issue in Ubuntu 12.04: Linux deb015.pod02 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux -- 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/2cca949c-9192-47dd-91bb-7b3af80f7...@fleetstreetops.com
Bug#688198: megasas: Failed to alloc kernel SGL buffer for IOCTL - Possible regression from 2.6.32.41~3
Todd Fleisher t...@fleetstreetops.com writes:
FYI - I'm seeing this same issue in Ubuntu 12.04: Linux deb015.pod02
3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
Shit! I have a bad feeling I might be responsible here...
Looks like the fix I submitted a while ago results in leaking
dma_allocated memory instead of BUGing out. Maybe slightly better in a
short term, but slightly more difficult to notice. Does it take a while
before this error starts appearing? Do you run some smartctl commands
periodically?
I'd appreciate it if the good Debian kernel team could tak a look at
this before it goes upstream, but I believe something like the attached
patch might fix the bug. This patch is based on v3.2.34, but I'll
rebase it on current mainline and submit it upstream with Cc stable if
any of you confirms that this look sane
Bjørn
From 4c41818461c2604f859d2fecda2657827071f0d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= bj...@mork.no
Date: Tue, 20 Nov 2012 18:17:48 +0100
Subject: [PATCH] megaraid_sas: fix memory leak if SGL has 0 length entries
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
commit 98cb7e44 ([SCSI] megaraid_sas: Sanity check user
supplied length before passing it to dma_alloc_coherent())
introduced a memory leak. Memory allocated for entries
following zero length SGL entries will not be freed.
Signed-off-by: Bjørn Mork bj...@mork.no
---
drivers/scsi/megaraid/megaraid_sas_base.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index 7c471eb..f013432 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4886,8 +4886,9 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
sense, sense_handle);
}
- for (i = 0; i ioc-sge_count kbuff_arr[i]; i++) {
- dma_free_coherent(instance-pdev-dev,
+ for (i = 0; i ioc-sge_count; i++) {
+ if (kbuff_arr[i])
+ dma_free_coherent(instance-pdev-dev,
kern_sge32[i].length,
kbuff_arr[i], kern_sge32[i].phys_addr);
}
--
1.7.10.4
Re: Bug#690586: installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2
Control: severity -1 important Control: reassign -1 src:linux Control: found -1 3.2.23-1 Control: fixed -1 3.3-1~experimental.1 Am 20.11.2012 um 19:29 schrieb Andreas B. Mundt: On Tue, Nov 20, 2012 at 05:57:27PM +0100, Sven Joachim wrote: [...] Could you please try a 3.3 kernel from snapshot.debian.org¹? There were various i2c related nouveau commits in that version, so maybe it would be sufficient to backport them. ¹ http://snapshot.debian.org/archive/debian/20120322T225438Z/pool/main/l/linux-2.6/linux-image-3.3.0-trunk-amd64_3.3-1%7Eexperimental.1_amd64.deb This kernel works fine without any special handling, just installing and rebooting is sufficient. $ uname -a Linux lmz 3.3.0-trunk-amd64 #1 SMP Thu Mar 22 18:02:10 UTC 2012 x86_64 GNU/Linux Thank you. I'm reassigning the bug to the Linux kernel and hopefully mark it as fixed in 3.3 and later. Now the question is which commits would need to be backported to the wheezy kernel. Some candidates: , | $ git log --grep=nouveau.*i2c --pretty=oneline v3.2..v3.3 | 525895ba388c949aa906f26e3ec5cb1ab041f56b drm/nouveau/gem: fix fence_sync race / oops | 5d56fe5fd794a98c4f446f8665fd06b82e93ff64 Merge branch 'drm-nouveau-next' of git://anongit.freedeskto | f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d drm/nouveau/i2c: handle bit-banging ourselves | 9e3b6b99075a01ce47379eee74365aece14242f3 drm/nouveau/i2c: fix debug message | 2bdb06e3cff066c546fb41152bc582a5ec73e899 drm/nouveau/i2c: tidy up bit-bang helpers, also fixing nv50 | 486a45c2a6c19b159602d044ab601a92cd81f524 drm/nouveau/i2c: do parsing of i2c-related vbios info in no | 0f8067c7054d22f240fca376e01430eecdc112df drm/nouveau/bios: fold fixup_legacy_i2c ` But that's beyond my skills :-(, so I'm passing the ball to the Debian kernel team. Cheers, Sven -- 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/87mwyc5c73@turtle.gmx.de
Processed: Re: Bug#690586: installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2
Processing control commands: severity -1 important Bug #690586 [installation-reports] installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2 Severity set to 'important' from 'normal' reassign -1 src:linux Bug #690586 [installation-reports] installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2 Bug reassigned from package 'installation-reports' to 'src:linux'. Ignoring request to alter found versions of bug #690586 to the same values previously set Ignoring request to alter fixed versions of bug #690586 to the same values previously set found -1 3.2.23-1 Bug #690586 [src:linux] installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2 Marked as found in versions linux/3.2.23-1. fixed -1 3.3-1~experimental.1 Bug #690586 [src:linux] installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2 The source 'linux' and version '3.3-1~experimental.1' do not appear to match any binary packages Marked as fixed in versions linux/3.3-1~experimental.1. -- 690586: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690586 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.b690586.13534382185648.transcr...@bugs.debian.org
Processed: fixing version
Processing commands for cont...@bugs.debian.org: # The source 'linux' and version '3.3-1~experimental.1' do not appear to match any binary packages notfixed 690586 3.3-1~experimental.1 Bug #690586 [src:linux] installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2 The source 'linux' and version '3.3-1~experimental.1' do not appear to match any binary packages No longer marked as fixed in versions linux/3.3-1~experimental.1. # first version uploaded to experimental as linux rather than linux2.6 fixed 690586 3.4.4-1~experimental.1 Bug #690586 [src:linux] installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2 Marked as fixed in versions linux/3.4.4-1~experimental.1. thanks Stopping processing here. Please contact me if you need assistance. -- 690586: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690586 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.135343903010459.transcr...@bugs.debian.org
Bug#693735: marked as done (linux-image-3.2.0-4-amd64: keyboards don't work with USB 3.0)
Your message dated Tue, 20 Nov 2012 10:49:00 -0800 with message-id 1353437341.27671.20.ca...@corn.betterworld.us and subject line Re: Bug#693735: closing duplicate has caused the Debian Bug report #693735, regarding linux-image-3.2.0-4-amd64: keyboards don't work with USB 3.0 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 693735: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693735 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: src:linux Version: 3.2.32-1 Severity: normal Dear Maintainer, Like many others, I'm having trouble with USB 3.0. Since the problems render the keyboards completely inoperative all the time, this is potentially quite serious. Fortunately I have USB 2.0 ports and SSH, and so am able to get work done. Many of the USB 3.0 reports on Debian and the net are of intermittent problems with, e.g., mass storage devices. In contrast I always experience this problem. This is a new, Ivy bridge system with an Intel DH77DF motherboard and i3-2225 CPU, running diskless. Other connections are HDMI and wired LAN. Installed a minimal squeeze system and then upgraded to testing. There are other oddities, such as no login prompts, or anything else, displaying on the virtual screens, and no access to sound. * What led up to the situation? Attempt to use a keyboard, either MS Keyboard with USB cable or logitech wireless (k400, includes touchpad). * What exactly did you do (or not do) that was effective (or ineffective)? Tried booting the older, 2.6.32-5, kernel. No help. Tried using wireless keyboard on Windows laptop to verify the batteries worked (and also in case it needed to do some pairing). Worked fine. Tried reinserting USB connector when system was up. No help. Plugged USB cable into USB 2.0 port on this machine with this kernel; worked fine. Haven't tried the wireless keyboard and USB 2.0. * What was the outcome of this action? Works with USB 2.0 ports, not with 3.0. * What outcome did you expect instead? Just works. Here are some logs from earlier attempts with the keyboards plugged into the USB 3.0 ports; I think the relevant stuff is at the end, but included more in case it's relevant. Nov 18 14:50:57 htpc kernel: [1.265125] hub 1-0:1.0: USB hub found Nov 18 14:50:57 htpc kernel: [1.265186] hub 1-0:1.0: 2 ports detected Nov 18 14:50:57 htpc kernel: [1.265292] ehci_hcd :00:1d.0: setting latency timer to 64 Nov 18 14:50:57 htpc kernel: [1.265295] ehci_hcd :00:1d.0: EHCI Host Controller Nov 18 14:50:57 htpc kernel: [1.265358] ehci_hcd :00:1d.0: new USB bus registered, assigned bus number 2 Nov 18 14:50:57 htpc kernel: [1.265449] ehci_hcd :00:1d.0: debug port 2 Nov 18 14:50:57 htpc kernel: [1.269392] ehci_hcd :00:1d.0: cache line size of 64 is not supported Nov 18 14:50:57 htpc kernel: [1.269404] ehci_hcd :00:1d.0: irq 23, io mem 0xf7d37000 Nov 18 14:50:57 htpc kernel: [1.284652] ehci_hcd :00:1d.0: USB 2.0 started, EHCI 1.00 Nov 18 14:50:57 htpc kernel: [1.284744] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 Nov 18 14:50:57 htpc kernel: [1.284804] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Nov 18 14:50:57 htpc kernel: [1.284872] usb usb2: Product: EHCI Host Controller Nov 18 14:50:57 htpc kernel: [1.284929] usb usb2: Manufacturer: Linux 3.2.0-4-amd64 ehci_hcd Nov 18 14:50:57 htpc kernel: [1.284987] usb usb2: SerialNumber: :00:1d.0 Nov 18 14:50:57 htpc kernel: [1.285118] hub 2-0:1.0: USB hub found Nov 18 14:50:57 htpc kernel: [1.285178] hub 2-0:1.0: 2 ports detected Nov 18 14:50:57 htpc kernel: [1.285299] xhci_hcd :00:14.0: setting latency timer to 64 Nov 18 14:50:57 htpc kernel: [1.285302] xhci_hcd :00:14.0: xHCI Host Controller Nov 18 14:50:57 htpc kernel: [1.285370] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 3 Nov 18 14:50:57 htpc kernel: [1.285875] xhci_hcd :00:14.0: cache line size of 64 is not supported Nov 18 14:50:57 htpc kernel: [1.285880] xhci_hcd :00:14.0: irq 16, io mem 0xf7d2 Nov 18 14:50:57 htpc kernel: [1.285946] xhci_hcd :00:14.0: Failed to enable MSI-X Nov 18 14:50:57 htpc kernel: [1.286033] xhci_hcd :00:14.0: irq 41 for MSI/MSI-X Nov 18 14:50:57 htpc kernel: [1.286071] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 Nov 18 14:50:57 htpc kernel: [1.286130] usb usb3: New USB device strings: Mfr=3, Product=2,
Bug#688198: megasas: Failed to alloc kernel SGL buffer for IOCTL - Possible regression from 2.6.32.41~3
I get this periodically (seemingly random - but usually once it starts
happening it sticks around for a while, then disappears only to return later)
when I'm using LSI's MegaCli64 utility. When the kernel logs the error the
MegaCli64 command doesn't return any data either.
Ex:
root@deb015.pod02:~# MegaCli64 -PDList -aALL
Exit Code: 0x00
Which is paired with a kernel message:
Nov 20 20:29:50 deb015 kernel: [797020.797811] megasas: Failed to alloc kernel
SGL buffer for IOCTL
Other times that same command (or other MegaCli64 commands) will succeed and
return the associated data. When this happens, there is no megasas kernel
message.
-T
On Nov 20, 2012, at 9:24 AM, Bjørn Mork wrote:
Todd Fleisher t...@fleetstreetops.com writes:
FYI - I'm seeing this same issue in Ubuntu 12.04: Linux deb015.pod02
3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
Shit! I have a bad feeling I might be responsible here...
Looks like the fix I submitted a while ago results in leaking
dma_allocated memory instead of BUGing out. Maybe slightly better in a
short term, but slightly more difficult to notice. Does it take a while
before this error starts appearing? Do you run some smartctl commands
periodically?
I'd appreciate it if the good Debian kernel team could tak a look at
this before it goes upstream, but I believe something like the attached
patch might fix the bug. This patch is based on v3.2.34, but I'll
rebase it on current mainline and submit it upstream with Cc stable if
any of you confirms that this look sane
Bjørn
From 4c41818461c2604f859d2fecda2657827071f0d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= bj...@mork.no
Date: Tue, 20 Nov 2012 18:17:48 +0100
Subject: [PATCH] megaraid_sas: fix memory leak if SGL has 0 length entries
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
commit 98cb7e44 ([SCSI] megaraid_sas: Sanity check user
supplied length before passing it to dma_alloc_coherent())
introduced a memory leak. Memory allocated for entries
following zero length SGL entries will not be freed.
Signed-off-by: Bjørn Mork bj...@mork.no
---
drivers/scsi/megaraid/megaraid_sas_base.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 7c471eb..f013432 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4886,8 +4886,9 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
sense, sense_handle);
}
- for (i = 0; i ioc-sge_count kbuff_arr[i]; i++) {
- dma_free_coherent(instance-pdev-dev,
+ for (i = 0; i ioc-sge_count; i++) {
+ if (kbuff_arr[i])
+ dma_free_coherent(instance-pdev-dev,
kern_sge32[i].length,
kbuff_arr[i], kern_sge32[i].phys_addr);
}
--
1.7.10.4
--
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/84cd168f-0f6e-42e6-a3e2-a1ef620fa...@fleetstreetops.com
Bug#693851: Xen domU dynamic memory extension not working
Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-5 The dynamic memory extension is not working on PV domU kernel linux-image-2.6.32-5-xen-amd64 nor linux-image-2.6.32-5-amd64, but it's working once the domU is booting with linux-image-2.6.26-2-xen-amd64. During the investigation we discovered that the 'target' is updated correctly on dom0 and also /sys/devices/system/xen_memory/xen_memory0/target_kb file is correctly updated on domU - the only issue is that domU kernel do not make this memory 'change' effective. The shrink of memory is working well - only the increase above the initial memory value is not working - the same as expected on HVM guests. dom0 is booting linux-image-2.6.32-5-xen-amd64 and Debian's Xen 4.0.1 is installed on the system. There is long discussion [1] on the xen-users mailing list with no root cause found. Attached are domU and dom0 dmesg outputs. [1] http://lists.xen.org/archives/html/xen-users/2012-11/msg00104.html Best regards, -- Peter Viskup (XEN) Xen version 4.0.1 (Debian 4.0.1-5.4) (ultrot...@debian.org) (gcc version 4.4.5 (Debian 4.4.5-8) ) Sat Sep 8 19:15:46 UTC 2012 (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=756M numa=off loglvl=all guest_loglvl=all (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 6 MBR signatures (XEN) Found 6 EDD information structures (XEN) Xen-e820 RAM map: (XEN) - 00098000 (usable) (XEN) 00098000 - 0010 (reserved) (XEN) 0010 - dfcf (usable) (XEN) dfcf - dfd96000 (ACPI NVS) (XEN) dfd96000 - dfdfd000 (usable) (XEN) dfdfd000 - dfe5f000 (reserved) (XEN) dfe5f000 - dfe6a000 (usable) (XEN) dfe6a000 - dfedf000 (ACPI NVS) (XEN) dfedf000 - dfee7000 (usable) (XEN) dfee7000 - dfeff000 (ACPI data) (XEN) dfeff000 - dff0 (usable) (XEN) dff0 - e000 (reserved) (XEN) f000 - f400 (reserved) (XEN) fff8 - fff8c000 (reserved) (XEN) 0001 - 00022000 (usable) (XEN) ACPI: RSDP 000F03C0, 0024 (r2 INTEL ) (XEN) ACPI: XSDT DFEFE120, 009C (r1 INTEL S3200SHX0 INTL 113) (XEN) ACPI: FACP DFEFB000, 00F4 (r3 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: DSDT DFEF5000, 579C (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: FACS DFE6A000, 0040 (XEN) ACPI: APIC DFEF4000, 0090 (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: WDDT DFEF3000, 0040 (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: MCFG DFEF2000, 003C (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: SPCR DFEF1000, 0050 (r1 INTEL S3200SHX0 MSFT 113) (XEN) ACPI: DMAR DFEF, 0110 (r1 INTEL S3200SHX1 MSFT 113) (XEN) ACPI: SSDT DFEEF000, 0175 (r1 INTEL Cpu0Ist 10 MSFT 113) (XEN) ACPI: SSDT DFEEE000, 0175 (r1 INTEL Cpu1Ist 10 MSFT 113) (XEN) ACPI: SSDT DFEED000, 0175 (r1 INTEL Cpu2Ist 10 MSFT 113) (XEN) ACPI: SSDT DFEEC000, 0175 (r1 INTEL Cpu3Ist 10 MSFT 113) (XEN) ACPI: SSDT DFEEB000, 01BC (r1 INTEL CpuPm 10 MSFT 113) (XEN) ACPI: HEST DFEEA000, 00A8 (r1 INTEL S3200SHX1 INTL1) (XEN) ACPI: BERT DFEE9000, 0030 (r1 INTEL S3200SHX1 INTL1) (XEN) ACPI: ERST DFEE8000, 0230 (r1 INTEL S3200SHX1 INTL1) (XEN) ACPI: EINJ DFEE7000, 0130 (r1 INTEL S3200SHX1 INTL1) (XEN) System RAM: 8189MB (8385548kB) (XEN) NUMA turned off (XEN) Faking a node at -00022000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000fd1f0 (XEN) DMI 2.5 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x408 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0] (XEN) ACPI: wakeup_vec[dfe6a00c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee0 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 6:15 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) Processor #2 6:15 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) (XEN) Processor #1 6:15 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) (XEN) Processor #3 6:15 APIC version 20 (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1]) (XEN) ACPI: IOAPIC (id[0x05] address[0xfec0] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 5, version 32, address 0xfec0, GSI 0-23 (XEN) ACPI: IOAPIC (id[0x06]
Processed: tagging 674154
Processing commands for cont...@bugs.debian.org: tags 674154 + pending Bug #674154 [src:linux] wake-on-lan with 3.2.0-0.bpo.2 and r8169 Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 674154: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674154 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.135346027925369.transcr...@bugs.debian.org
Processed: Re: fixing version
Processing commands for cont...@bugs.debian.org: fixed 690586 linux-2.6/3.3-1~experimental.1 Bug #690586 [src:linux] installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2 Marked as fixed in versions linux-2.6/3.3-1~experimental.1. End of message, stopping processing here. Please contact me if you need assistance. -- 690586: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690586 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.13534676208737.transcr...@bugs.debian.org
Processed: Re: linux-image-3.2.0-4-amd64: keyboards don't work with USB 3.0
Processing commands for cont...@bugs.debian.org:
# dup, closed by submitter
notfound 693735 linux/3.2.32-1
Bug #693735 {Done: Ross Boylan rossboy...@stanfordalumni.org} [src:linux]
linux-image-3.2.0-4-amd64: keyboards don't work with USB 3.0
No longer marked as found in versions linux/3.2.32-1.
End of message, stopping processing here.
Please contact me if you need assistance.
--
693735: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693735
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.135346878315612.transcr...@bugs.debian.org
Bug#693762: linux-image-3.2.0-4-amd64: General Protection Fault
On Tuesday, November 20, 2012 08:01:40 AM Ben Hutchings wrote: RCX: f7ffc952c1d8 Current 64-bit x86 processors really only use 48-bit virtual addresses, which must begin with or . So this address seems to have been corrupted: a single bit has changed. This could be caused by a software bug but it looks much more like a hardware fault. You may be able to confirm a RAM fault with memtest86+. Unfortunately it doesn't reliably find faults, and it doesn't particularly stress the CPU or other parts of the system that could also be at fault. Ran memtst+ for 6 hours on the two 4GiB sticks. It found two problems. Tst Pass Fail AddrLocation Good Bad ErrCount 53 0002A453310 676.3MB ffe7 fff7 0010 1 53 0002E4532f0 740.3MB ffe7 fff7 0010 2 At least it's GSkill memory with lifetime warranty. Could this single bit error somehow correlate with the address in RCX? (If it's there, I don't recognize it.) -- 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/201211202240.29662.neal.p.mur...@alum.wpi.edu
Bug#688198: megasas: Failed to alloc kernel SGL buffer for IOCTL - Possible regression from 2.6.32.41~3
Todd Fleisher t...@fleetstreetops.com writes:
I get this periodically (seemingly random - but usually once it starts
happening it sticks around for a while, then disappears only to return later)
when I'm using LSI's MegaCli64 utility. When the kernel logs the error the
MegaCli64 command doesn't return any data either.
Ex:
root@deb015.pod02:~# MegaCli64 -PDList -aALL
Exit Code: 0x00
Which is paired with a kernel message:
Nov 20 20:29:50 deb015 kernel: [797020.797811] megasas: Failed to alloc
kernel SGL buffer for IOCTL
Other times that same command (or other MegaCli64 commands) will succeed and
return the associated data. When this happens, there is no megasas kernel
message.
Thanks. I don't know what the MegaCli64 utility does, but I assume it
use the driver specific ioctls to send passthrough commands like the
smartmontools do. That is consistent with your description.
But I was concluding too fast as usual. The bug I found needs to be
fixed, but it cannot be the cause of this problem. If it were then you
would most likely see many other effects on your system. And the same
bug has been backported to 2.6.32 as well. And if if had not been, and
you are in fact hit by it, then your system would have crashed instead.
So that cannot be the problem. And then I don't know what could have
changed between 2.6.32 and 3.2. Could be something outside this driver.
It would be interesting to know something about the size of the buffers
which cannot be allocated. But running with debug pacthes is maybe out
of the question? Otherwise you could try running with something like
this to get a better picture of why this is failing:
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index f013432..1c0fa1d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4797,6 +4797,7 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
if (!kbuff_arr[i]) {
printk(KERN_DEBUG megasas: Failed to alloc
kernel SGL buffer for IOCTL \n);
+ printk(KERN_DEBUG megasas: iov_len=%d\n,
ioc-sgl[i].iov_len);
error = -ENOMEM;
goto out;
}
Bjørn
--
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/87txsj5smj@nemi.mork.no
Bug#693863: linux-kbuild-3.5: link-vmlinux.sh is absent
Package: linux-kbuild-3.5 Version: 3.5-1~experimental.1 Severity: important Hello. The link-vmlinux.sh from scripts is absent in /usr/src/linux-kbuild-3.5/scripts. It's used in /usr/src/linux-headers-3.5-trunk-common/Makefile to 'make clean'. -- sergio. -- 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/20121121072552.14042.183.reportbug@gnusmas
