Bug#886506: linux-image-4.14.0-3-686-pae: Kernel panic during reboot - since 4.14.0-2 - 4.14.0-1 works normal and boots
If you downgrade glibc to 2.25-4 and rebuild the initrd then linux-image-4.14.0-3-686-pae will also work. -- ciao, Marc
Bug#886630: linux-image-3.2.0-5-amd64 Kernel panic after upgrading when use hidepid Debian wheezy
This bug hit me too. All my servers are using hidepid as default. So every system I rebooted was unusable after reboot, everything starting at boot gave the trace output, ssh'ing to the system gave the trace output without successful ssh login :-( -- ciao, Marc
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 : > 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
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 : > Marc-Christian Petersen 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
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 : > Ben Hutchings writes: >> On Tue, 2011-01-25 at 09:24 +0100, Bjørn Mork wrote: >>> Marc-Christian Petersen 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
Moin Bjørn, On Tue, 25 Jan 2011 09:24:55 +0100, Bjørn Mork 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-scsi&m=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
Hi Bjørn, all On Mon, 29 Nov 2010 12:41:02 +0100, Marc-Christian Petersen wrote: > On Mon, 29 Nov 2010 11:55:01 +0100, Bjørn Mork 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 Mon, 29 Nov 2010 11:55:01 +0100, Bjørn Mork 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
Moin Bjørn, On Tue, 23 Nov 2010 15:25:44 +0100, Bjørn Mork 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
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(no description available) pn linux-doc-2.6.32 (no description available) Versions of packages linux-image-2.6.32-5-amd64 is related to: pn firmware-bnx2 (no description available) pn firmware-bnx2x (no description available) pn firmware-ipw2x00 (no description available) pn firmware-ivtv (no description available) pn firmware-iwlwifi (no description available) pn firmware-linux (no description available) pn firmware-linux-nonfree (no description available) pn firmware-qlogic(no description available) pn firmware-ralink(no description available) pn xen-hypervisor (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
