Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Hi all, latest Squeeze Kernel (2.6.32-39squeeze1, Update avail today) re-introduces kind the same bug, i.e. smartmontools not usable with megaraid. smartmontools cannot open the device: Smartctl open device: /dev/sda [megaraid_disk_01] failed: INQUIRY failed Smartctl open device: /dev/sg0 [megaraid_disk_00] failed: INQUIRY failed Kernel 2.6.32-39 (the one before squeeze1) just works. Am 18.05.2011 um 14:00:05 Uhr schrieb Bjørn Mork bj...@mork.no: Marc-Christian Petersen m@gmx.de writes: so, what's up guys? may we get this patch into Debian this year (2011)? or should we wait for 21.12.2012? ;- Uhm, yeah. Sorry about that. I never figured it would be this difficult to get the fix into ustream, which is a requirement for getting it into the stable kernels. And then upstream managed to refactor/rename the files involved before the fix was applied, and the version that finally went in (to 2.6.39) also missed the stable Cc... But I've now sent a backported version of the upstream fix to stable, so that it hopefully will end up in 2.6.32.x Real Soon Now(tm). That should also make it appear in Debian squeeze. 2.6.38 might still require special handling. The fix from 2.6.39 upstream will apply directly, but I don't know if I care enough to actually push it. I assume 2.6.38.x stable will be dead in a while anyway. 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/4f147af6.8040...@gmx.de
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
please forget it. I should go to bed first ;( Am 16.01.2012 um 20:31:02 Uhr schrieb Marc-Christian Petersen m@gmx.de: Hi all, latest Squeeze Kernel (2.6.32-39squeeze1, Update avail today) re-introduces kind the same bug, i.e. smartmontools not usable with megaraid. smartmontools cannot open the device: Smartctl open device: /dev/sda [megaraid_disk_01] failed: INQUIRY failed Smartctl open device: /dev/sg0 [megaraid_disk_00] failed: INQUIRY failed Kernel 2.6.32-39 (the one before squeeze1) just works. -- 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/4f147bf6.9070...@gmx.de
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Marc-Christian Petersen m@gmx.de writes: so, what's up guys? may we get this patch into Debian this year (2011)? or should we wait for 21.12.2012? ;- Uhm, yeah. Sorry about that. I never figured it would be this difficult to get the fix into ustream, which is a requirement for getting it into the stable kernels. And then upstream managed to refactor/rename the files involved before the fix was applied, and the version that finally went in (to 2.6.39) also missed the stable Cc... But I've now sent a backported version of the upstream fix to stable, so that it hopefully will end up in 2.6.32.x Real Soon Now(tm). That should also make it appear in Debian squeeze. 2.6.38 might still require special handling. The fix from 2.6.39 upstream will apply directly, but I don't know if I care enough to actually push it. I assume 2.6.38.x stable will be dead in a while anyway. 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/87r57w5id6@nemi.mork.no
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
On Wed, 2011-05-18 at 14:00 +0200, Bjørn Mork wrote: Marc-Christian Petersen m@gmx.de writes: so, what's up guys? may we get this patch into Debian this year (2011)? or should we wait for 21.12.2012? ;- Uhm, yeah. Sorry about that. I never figured it would be this difficult to get the fix into ustream, which is a requirement for getting it into the stable kernels. And then upstream managed to refactor/rename the files involved before the fix was applied, and the version that finally went in (to 2.6.39) also missed the stable Cc... But I've now sent a backported version of the upstream fix to stable, so that it hopefully will end up in 2.6.32.x Real Soon Now(tm). That should also make it appear in Debian squeeze. [...] Thanks Bjørn. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
so, what's up guys? may we get this patch into Debian this year (2011)? or should we wait for 21.12.2012? ;- thanks! Am 15.02.2011 um 8:32:48 Uhr schrieb Bjørn Mork bj...@mork.no: Ben Hutchings b...@decadent.org.uk writes: On Tue, 2011-01-25 at 09:24 +0100, Bjørn Mork wrote: Marc-Christian Petersen m@gmx.de writes: so, what's up with this fix? Any chance to get it into Debians kernel tree? It's kind of uncomfortable to rebuild the whole kernel, with this applied, when Debian releases a new kernel which happens frequently ;- I fully understand. I must admit that I thought it would be a no-brainer to verify this and get it into the upstream and the 2.6.32.x stable tree. [...] Your patch removes the initialisation of kern_sge32[i] when ioc-sgl[i].iov_len is zero. I think it should at least set the length to zero. Yes, you are of course right. I just considered it's usage in that function, where it won't be used as long as kbuff_arr[i] is 0, but kern_sge32[i] should be set to be absolutely safe with the firmware. Perhaps it's safest to pass max(ioc-sgl[i].iov_len, 1) as the length parameter to dma_alloc_coherent(). I agree that it would fix things, and that may be appropriate for a Debian specific workaround where the workaround context always is clear, but I don't think it's good as a permanent fix. Reading the patched code would be very confusing. Not allocating 0 is self-explanatory. 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/4dd18aa9.5010...@gmx.de
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
On Tue, 2011-01-25 at 09:24 +0100, Bjørn Mork wrote: Marc-Christian Petersen m@gmx.de writes: so, what's up with this fix? Any chance to get it into Debians kernel tree? It's kind of uncomfortable to rebuild the whole kernel, with this applied, when Debian releases a new kernel which happens frequently ;- I fully understand. I must admit that I thought it would be a no-brainer to verify this and get it into the upstream and the 2.6.32.x stable tree. [...] Your patch removes the initialisation of kern_sge32[i] when ioc-sgl[i].iov_len is zero. I think it should at least set the length to zero. Perhaps it's safest to pass max(ioc-sgl[i].iov_len, 1) as the length parameter to dma_alloc_coherent(). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Ben Hutchings b...@decadent.org.uk writes: On Tue, 2011-01-25 at 09:24 +0100, Bjørn Mork wrote: Marc-Christian Petersen m@gmx.de writes: so, what's up with this fix? Any chance to get it into Debians kernel tree? It's kind of uncomfortable to rebuild the whole kernel, with this applied, when Debian releases a new kernel which happens frequently ;- I fully understand. I must admit that I thought it would be a no-brainer to verify this and get it into the upstream and the 2.6.32.x stable tree. [...] Your patch removes the initialisation of kern_sge32[i] when ioc-sgl[i].iov_len is zero. I think it should at least set the length to zero. Yes, you are of course right. I just considered it's usage in that function, where it won't be used as long as kbuff_arr[i] is 0, but kern_sge32[i] should be set to be absolutely safe with the firmware. Perhaps it's safest to pass max(ioc-sgl[i].iov_len, 1) as the length parameter to dma_alloc_coherent(). I agree that it would fix things, and that may be appropriate for a Debian specific workaround where the workaround context always is clear, but I don't think it's good as a permanent fix. Reading the patched code would be very confusing. Not allocating 0 is self-explanatory. 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/878vxh3g7z@nemi.mork.no
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Moin Bjørn, On Tue, 25 Jan 2011 09:24:55 +0100, Bjørn Mork bj...@mork.no wrote: But after nagging about it recently, it appears that the driver maintainer didn't really understand the issue. The last I heard from LSI was this: http://marc.info/?l=linux-scsim=129549117927641 which wouldn't be so bad if it weren't for the fact that it was sent well *after* that I already had done exactly that, as FUJITA Tomonori helpfully pointed out in a reply to that message lol :) So I honestly don't know. Looks like getting it upstream will still take some time. Maybe the Debian kernel maintainers can take it as a temporary bugfix until it gets there? The fix is rather obvious (in my eyes at least :-). I hope that the Debian Kernel Maintainers will catch up this patch and will include it in the next update. Thanks for your work Bjørn! Well done. And I repeat: the patch works! I have lots of machines with such kind of controller and all machines are working fine after I have applied the patch. -- ciao, Marc -- 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/4d429a93.3050...@gmx.de
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Marc-Christian Petersen m@gmx.de writes: so, what's up with this fix? Any chance to get it into Debians kernel tree? It's kind of uncomfortable to rebuild the whole kernel, with this applied, when Debian releases a new kernel which happens frequently ;- I fully understand. I must admit that I thought it would be a no-brainer to verify this and get it into the upstream and the 2.6.32.x stable tree. But after nagging about it recently, it appears that the driver maintainer didn't really understand the issue. The last I heard from LSI was this: http://marc.info/?l=linux-scsim=129549117927641 which wouldn't be so bad if it weren't for the fact that it was sent well *after* that I already had done exactly that, as FUJITA Tomonori helpfully pointed out in a reply to that message So I honestly don't know. Looks like getting it upstream will still take some time. Maybe the Debian kernel maintainers can take it as a temporary bugfix until it gets there? The fix is rather obvious (in my eyes at least :-). 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/87ei81pezs@nemi.mork.no
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Hi Bjørn, all On Mon, 29 Nov 2010 12:41:02 +0100, Marc-Christian Petersen m@gmx.de wrote: On Mon, 29 Nov 2010 11:55:01 +0100, Bjørn Mork bj...@mork.no wrote: Does the selftest actually work? Artem Bokhan reports that the patch fixes the visible error, but that the selftest does not start. I really don't understand why, as AFAICS the patch does not change or modify any part of the command from smartctl. It only ensures that a command with dxfer_len == 0 doesn't cause an attempt to dma_alloc_coherent zero bytes (which will fail). yep, the selftest works: SMART Self-test log Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ] Description number (hours) # 1 Background long Self test in progress ... - NOW - [- --] # 2 Background short Completed -6921 - [- --] ... and after completed: SMART Self-test log Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ] Description number (hours) # 1 Background long Completed -6922 - [- --] # 2 Background short Completed -6921 - [- --] so, what's up with this fix? Any chance to get it into Debians kernel tree? It's kind of uncomfortable to rebuild the whole kernel, with this applied, when Debian releases a new kernel which happens frequently ;- Thanks. -- ciao, Marc -- 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/4d3e74b4.3080...@gmx.de
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Moin Bjørn, On Tue, 23 Nov 2010 15:25:44 +0100, Bjørn Mork bj...@mork.no wrote: Please see if this is fixed by the patch I recently posted to the linux-scsi list: http://permalink.gmane.org/gmane.linux.ide/47847 I believe you are seeing another symptom of the same bug: The driver happily forwards a 0 length from userspace to dma_alloc_coherent(). smartctl will trigger this when trying to enable the self tests. I've attached the patch for simplicity. Note that I haven't yet received any ack on this, but it did fix the problems for the other user reporting similar issues. first: sorry for the late answer! That patch also fixes my problems. Very cool :-D Many thanks! now, how do we get that patch into the official Debian Kernel? ;) -- ciao, Marc -- 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/4cf37bab.7000...@gmx.de
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Marc-Christian Petersen m@gmx.de writes: On Tue, 23 Nov 2010 15:25:44 +0100, Bjørn Mork bj...@mork.no wrote: Please see if this is fixed by the patch I recently posted to the linux-scsi list: http://permalink.gmane.org/gmane.linux.ide/47847 I believe you are seeing another symptom of the same bug: The driver happily forwards a 0 length from userspace to dma_alloc_coherent(). smartctl will trigger this when trying to enable the self tests. I've attached the patch for simplicity. Note that I haven't yet received any ack on this, but it did fix the problems for the other user reporting similar issues. first: sorry for the late answer! That patch also fixes my problems. Very cool :-D Does the selftest actually work? Artem Bokhan reports that the patch fixes the visible error, but that the selftest does not start. I really don't understand why, as AFAICS the patch does not change or modify any part of the command from smartctl. It only ensures that a command with dxfer_len == 0 doesn't cause an attempt to dma_alloc_coherent zero bytes (which will fail). Many thanks! now, how do we get that patch into the official Debian Kernel? ;) I believe that is as easy as getting it into an upstream kernel, which will trigger stable, which will be included in Debian automatically. But I haven't received any feedback from the driver maintainers yet. I don't know if I should expect any... They seem to collect a number of changes in internal releases, which are then pushed upstream. 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/87r5e4l7qy@nemi.mork.no
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Moin Bjørn, On Mon, 29 Nov 2010 11:55:01 +0100, Bjørn Mork bj...@mork.no wrote: Does the selftest actually work? Artem Bokhan reports that the patch fixes the visible error, but that the selftest does not start. I really don't understand why, as AFAICS the patch does not change or modify any part of the command from smartctl. It only ensures that a command with dxfer_len == 0 doesn't cause an attempt to dma_alloc_coherent zero bytes (which will fail). yep, the selftest works: SMART Self-test log Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ] Description number (hours) # 1 Background long Self test in progress ... - NOW - [- --] # 2 Background short Completed -6921 - [- --] ... and after completed: SMART Self-test log Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ] Description number (hours) # 1 Background long Completed -6922 - [- --] # 2 Background short Completed -6921 - [- --] -- ciao, Marc -- 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/4cf3914e.9010...@gmx.de
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Marc-Christian Petersen m@gmx.de writes:
I am unable to do short and long tests initiated with smartd/smartctl.
calling 'smartctl -d megaraid,0 /dev/sda -t short' gives:
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Short offline self test failed [Cannot allocate memory]
megasas: Failed to alloc kernel SGL buffer for IOCTL
Please see if this is fixed by the patch I recently posted to the
linux-scsi list: http://permalink.gmane.org/gmane.linux.ide/47847
I believe you are seeing another symptom of the same bug: The driver
happily forwards a 0 length from userspace to dma_alloc_coherent().
smartctl will trigger this when trying to enable the self tests.
I've attached the patch for simplicity. Note that I haven't yet
received any ack on this, but it did fix the problems for the other user
reporting similar issues.
Bjørn
---BeginMessage---
The ioc-sgl[i].iov_len value is supplied by the ioctl caller, and can be
zero in some cases. Assume that's valid and continue without error.
Fixes:
[ 69.162538] [ cut here ]
[ 69.162806] kernel BUG at /build/buildd/linux-2.6.32/lib/swiotlb.c:368!
[ 69.163134] invalid opcode: [#1] SMP
[ 69.163570] last sysfs file:
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[ 69.163975] CPU 0
[ 69.164227] Modules linked in: fbcon tileblit font bitblit softcursor
vga16fb vgastate ioatdma radeon ttm drm_kms_helper shpchp drm i2c_algo_bit lp
parport floppy pata_jmicron megaraid_sas igb dca
[ 69.167419] Pid: 1206, comm: smartctl Tainted: GW 2.6.32-25-server
#45-Ubuntu X8DTN
[ 69.167843] RIP: 0010:[812c4dc5] [812c4dc5]
map_single+0x255/0x260
[ 69.168370] RSP: 0018:88081c0ebc58 EFLAGS: 00010246
[ 69.168655] RAX: 0003bffc RBX: RCX: 0002
[ 69.169000] RDX: RSI: RDI: 88001dffe000
[ 69.169346] RBP: 88081c0ebcb8 R08: R09: 88030840
[ 69.169691] R10: 0010 R11: R12:
[ 69.170036] R13: R14: 0001 R15: 0020
[ 69.170382] FS: 7fb8de189720() GS:88001de0()
knlGS:
[ 69.170794] CS: 0010 DS: ES: CR0: 80050033
[ 69.171094] CR2: 7fb8dd59237c CR3: 00081a79 CR4: 06f0
[ 69.171439] DR0: DR1: DR2:
[ 69.171784] DR3: DR6: 0ff0 DR7: 0400
[ 69.172130] Process smartctl (pid: 1206, threadinfo 88081c0ea000, task
88081a76)
[ 69.194513] Stack:
[ 69.205788] 0034 0002817e3390
88081c0ebe00
[ 69.217739] 0 0003bffc
[ 69.241250] 0 88081c5b4080
88081c0ebe00
[ 69.277310] Call Trace:
[ 69.289278] [812c52ac] swiotlb_alloc_coherent+0xec/0x130
[ 69.301118] [81038b31] x86_swiotlb_alloc_coherent+0x61/0x70
[ 69.313045] [a002d0ce] megasas_mgmt_fw_ioctl+0x1ae/0x690
[megaraid_sas]
[ 69.336399] [a002d748] megasas_mgmt_ioctl_fw+0x198/0x240
[megaraid_sas]
[ 69.359346] [a002f695] megasas_mgmt_ioctl+0x35/0x50 [megaraid_sas]
[ 69.370902] [81153b12] vfs_ioctl+0x22/0xa0
[ 69.382322] [8115da2a] ? alloc_fd+0x10a/0x150
[ 69.393622] [81153cb1] do_vfs_ioctl+0x81/0x410
[ 69.404696] [8155cc13] ? do_page_fault+0x153/0x3b0
[ 69.415761] [811540c1] sys_ioctl+0x81/0xa0
[ 69.426640] [810121b2] system_call_fastpath+0x16/0x1b
[ 69.437491] Code: fe ff ff 48 8b 3d 74 38 76 00 41 bf 00 00 20 00 e8 51 f5
d7 ff 83 e0 ff 48 05 ff 07 00 00 48 c1 e8 0b 48 89 45 c8 e9 13 fe ff ff 0f 0b
eb fe 0f 1f 80 00 00 00 00 55 48 89 e5 48 83 ec 20 4c 89
[ 69.478216] RIP [812c4dc5] map_single+0x255/0x260
[ 69.489668] RSP 88081c0ebc58
[ 69.500975] ---[ end trace 6a2181b634e2abc7 ]---
Reported-by: Bokhan Artem ap...@ngs.ru
Signed-off-by: Bjørn Mork bj...@mork.no
Cc: sta...@kernel.org
---
drivers/scsi/megaraid/megaraid_sas.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.c
b/drivers/scsi/megaraid/megaraid_sas.c
index eb29d50..72713c5 100644
--- a/drivers/scsi/megaraid/megaraid_sas.c
+++ b/drivers/scsi/megaraid/megaraid_sas.c
@@ -4359,6 +4359,11 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
* For each user buffer, create a mirror buffer and copy in
*/
for (i = 0; i ioc-sge_count; i++) {
+ if (ioc-sgl[i].iov_len == 0) {
+ kbuff_arr[i] = NULL;
+ continue;
+ }
+
kbuff_arr[i] =
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Package: linux-2.6 Version: 2.6.32-27 Severity: important Hi, I am unable to do short and long tests initiated with smartd/smartctl. calling 'smartctl -d megaraid,0 /dev/sda -t short' gives: smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Short offline self test failed [Cannot allocate memory] megasas: Failed to alloc kernel SGL buffer for IOCTL calling 'smartctl -i -d megaraid,0 /dev/sda' gives: smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Device: HITACHI HUS153014VLS300 Version: A5C0 Serial number: Device type: disk Transport protocol: SAS Local Time is: Tue Nov 23 08:29:25 2010 CET Device supports SMART and is Enabled Temperature Warning Enabled dmesg info: --- megasas: 00.00.04.01 Thu July 24 11:41:51 PST 2008 megasas: 0x1000:0x0060:0x1000:0x1013: bus 96:slot 0:func 0 megaraid_sas :60:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 megaraid_sas :60:00.0: setting latency timer to 64 lspci info: --- 60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04) Subsystem: LSI Logic / Symbios Logic Device 1013 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at dfa4 (64-bit, non-prefetchable) [size=256K] I/O ports at 3000 [size=256] Memory at dfa0 (64-bit, non-prefetchable) [size=256K] [virtual] Expansion ROM at 4010 [disabled] [size=64K] Capabilities: [b0] Express Endpoint, MSI 00 Capabilities: [c4] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable- Capabilities: [d4] MSI-X: Enable- Mask- TabSize=4 Capabilities: [e0] Power Management version 2 Capabilities: [ec] Vital Product Data ? Capabilities: [100] Power Budgeting ? Kernel driver in use: megaraid_sas Kernel modules: megaraid_sas It seems I am not alone with this problem: http://www.mail-archive.com/linux-powere...@dell.com/msg02575.html and lots of hits from 2007 and 2008 from RHEL. -- Package-specific info: ** Kernel log: boot messages should be attached -- System Information: Debian Release: squeeze/sid Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.32-5-amd64 depends on: ii debconf [debconf-2.0] 1.5.36 Debian configuration management sy ii initramfs-tools [linux-initra 0.98.5 tools for generating an initramfs ii linux-base2.6.32-27 Linux image base package ii module-init-tools 3.12-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.32-5-amd64 recommends: ii firmware-linux-free 2.6.32-27 Binary firmware for various driver Versions of packages linux-image-2.6.32-5-amd64 suggests: pn grub | lilo none (no description available) pn linux-doc-2.6.32 none (no description available) Versions of packages linux-image-2.6.32-5-amd64 is related to: pn firmware-bnx2 none (no description available) pn firmware-bnx2xnone (no description available) pn firmware-ipw2x00 none (no description available) pn firmware-ivtv none (no description available) pn firmware-iwlwifi none (no description available) pn firmware-linuxnone (no description available) pn firmware-linux-nonfreenone (no description available) pn firmware-qlogic none (no description available) pn firmware-ralink none (no description available) pn xen-hypervisornone (no description available) -- debconf information excluded -- 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/20101123074832.32293.54775.report...@lokalhorst.gotdns.com
