new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Mon, 07 Jun 2010 03:22:46 -0400 (EDT), sean finney wrote: On Mon, Jun 07, 2010 at 01:44:05AM +0400, William Pitcock wrote: Have fun. When you have a release that actually has merit, it can be reconsidered for inclusion in Debian. In the meantime, the original plan continues. actually, i don't think you have any say about what software can and can not be in debian, that is the sole privilege of ftp-master. your options are (a) to claim you still want to maintain the package and continue to do so, or (b) ask for its removal by ftp-master. given your comments here i think if you were to claim (a) there would be a decent case for someone to take to the tech-ctte. ftp-master, if they're aware of this argument, may just say why not orphan it instead?. but regardless, if someone else is interested they can just follow that removal with a new upload using their name as Maintainer, and then again it's up to ftp-master to accept or deny it. given that there may be an active upstream and maintainer, and the software is otherwise DFSG-compatible, i don't see why they would deny such a new upload. of course, it would be a lot nicer if you could just hand over the reins of the current package to those who have been asking for them, to avoid some un-needed overhead... sean Perhaps I can offer a solution here. Since William obviously doesn't wish to maintain this package any longer, I am willing to take over his responsibilities as a Debian package maintainer for lilo under two conditions: (1) The kernel team fixes bug number 505609, and (2) Debian ceases its attempts to remove lilo from the distribution. What do you say, William? Do you have any objections? Does anyone else have any objections? If so, speak now, or forever hold your peace. Keep in mind that I have never been a Debian package maintainer before. This will be my first package. Please be patient with me as I learn the ropes, so to speak. As for whether or not lilo continues to be offered as an alternate boot loader by the Debian installer, that is entirely up to them. I would think that the path of least resistance would be to maintain the status quo, but if they want to remove lilo from the Debian installer menu that's their call, as far as I am concerned. I just don't want to see lilo removed from the distribution. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1196418916.5745.1275918400688.javamail.r...@md01.wow.synacor.com
Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Mon, 07 Jun 2010 10:33:52 -0400 (EDT), Holger Levsen wrote: Hi Stephen, thanks for stepping up maintaining lilo in Debian! I hope you'll manage this well. Um, thanks; but I don't understand the reassignment of bug number 505609 to package initramfs-tools. If you read my previous posts to the bug log, it is clear that this problem started with a change to the maintainer scripts between Etch and Lenny. Please read my posts again carefully. Then consider whether this is really a bug in initramfs-tools or a bug in the kernel maintainer scripts. initramfs-tools only gets involved when update-initramfs -u is issued. And it *does* invoke the boot loader under these conditions, if do_bootloader = yes is present in /etc/kernel-img.conf and lilo is installed. But for a kernel install or reconfigure, it is the responsibility of the kernel maintainer scripts to invoke the bootloader. See also, for example, linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader on line 38. This really is an open and shut case, if only I can the kernel people to actually look at it! Please look at it! -- .''`. Stephen Powell : :' : `. `'` `- -- 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/120369280.10411.1275925077969.javamail.r...@md01.wow.synacor.com
Bug#505609: [SOLVED] Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
After examining the maintainer scripts, this does appear to be a bug in the maintainer scripts. I compared output of dpkg-reconfigure between two different systems: one running Etch and the other running Lenny. Both had lilo installed as the boot loader. In both cases, the contents of /etc/kernel-img.conf were as follows: -- # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = yes do_bootfloppy = no do_initrd = yes link_in_boot = yes -- Here is the output of dpkg-reconfigure on Etch: -- # dpkg-reconfigure linux-image-2.6.18-5-686 Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-13 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-13 was configured last, according to dpkg) You already have a LILO configuration in /etc/lilo.conf Running boot loader as requested Testing lilo.conf ... Testing successful. Installing the partition boot sector... Running /sbin/lilo ... Installation successful. # -- Here is the output of dpkg-reconfigure on Lenny: -- # dpkg-reconfigure linux-image-2.6.26-2-686 Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) # -- Notice the absence of any information about running the boot loader in the Lenny output! The boot loader simply was not run, despite a request in /etc/kernel-img.conf to run it. I compared the two relevant maintainer scripts: /var/lib/dpkg/info/linux-image.2.6.18-5-686.postinst and /var/lib/dpkg/info/linux-image.2.6.26-2-686.postinst and quickly discovered the reason. The maintainer scripts for the 2.6.26 kernel define the $loader variable to be the null string. The 2.6.18 maintainer script defines the $loader variable to be lilo. To be specific, line 38 of /var/lib/dpkg/info/linux-image-2.6.26-2-686.postinst currently says: my $loader= ; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo I changed it to say: my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo The new output is as follows: -- # dpkg-reconfigure linux-image-2.6.26-2-686 Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) You already have a LILO configuration in /etc/lilo.conf Running boot loader as requested Testing lilo.conf ... Testing successful. Installing the partition boot sector... Running /sbin/lilo ... Installation successful. # -- There is no conflict with grub version 1 or grub version 2 here. If the user has either version of grub installed, then the user will set do_bootloader = no in /etc/kernel-img.conf. In the case of grub version 1, he will also add postinst_hook = update-grub postrm_hook = update-grub A similar change should be made to the preinst, prerm, and postrm scripts for consistency. The Squeeze and Sid scripts have the same problem. OK, I solved the mystery. Now someone on the kernel team actually has to fix it. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/162468144.291167.1275665046115.javamail.r...@md01.wow.synacor.com
Bug#582281: Fwd: Re: Fw: Partition starting sector and size incorrect for reserved CMS minidisk on FBA DASD with blocksize 512 using DIAG driver
Initial reply from upstream: - Forwarded Message - From: Heiko Carstens h.carst...@de.ibm.com To: Stefan Haberland1 stefan.haberl...@de.ibm.com, Stefan Weinhuber w...@de.ibm.com Cc: Martin Schwidefsky martin.schwidef...@de.ibm.com, Susanne Wintenberger swin...@de.ibm.com, Stephen Powell zlinux...@wowway.com Sent: Tue, 25 May 2010 08:11:56 -0400 (EDT) Subject: Re: Fw: Partition starting sector and size incorrect for reserved CMS minidisk on FBA DASD with blocksize 512 using DIAG driver Hi Stephen, thanks for your bug report. Stefan Weinhuber or Stefan Haberland should look into this, since they both know the partition code and the DASD driver. Best regards, Heiko Carstens Linux on System z Development IBM Deutschland Research Development GmbH, Vorsitzender des Aufsichtsrats: Martin Jetter, Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 | | From: | | --| |BOEBLINGEN LINUX390/Germany/IBM | --| | | To:| | --| |Martin Schwidefsky/Germany/i...@ibmde, Heiko Carstens/Germany/i...@ibmde | --| | | Date: | | --| |25-05-2010 13:36 | --| | | Subject: | | --| |Fw: Partition starting sector and size incorrect for reserved CMS minidisk on FBA DASD with blocksize 512 using DIAG driver | --| Hallo Martin, Heiko könnt Ihr dazu Stellung nehmen - danke PS: For code donations and analyzed bug reports contact linux...@de.ibm.com For technical support please contact IBM Global Services: USA/Canada: http://ps.software.ibm.com For platform specific technical news and downloads see: http://www.ibm.com/developerworks/linux/linux390/index.html http://www.s390.ibm.com/linux/ -- .''`. Stephen Powell : :' : `. `'` `- -- 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/95118627.37530.1274797893244.javamail.r...@md01.wow.synacor.com
Bug#582281: Promised utility now available
On Fri, 21 May 2010 16:48:38 -0400 (EDT), Jonathan Nieder wrote: I am not the kernel team, but for issues in upstream code, it is _always_ a good idea to go to upstream directly[1]. To the Debian Kernel Team: Upon the advice of Jonathan Nieder, I will pursue this directly with upstream, but I will keep you informed of what's going on by updates to this bug log. If you have a problem with that, please say so. On Fri, 21 May 2010 16:48:38 -0400 (EDT), Jonathan Nieder wrote: $ grep '^[0-9]*)' Documentation/SubmittingPatches 1) diff -up 2) Describe your changes. 3) Separate your changes. 4) Style check your changes. 5) Select e-mail destination. 6) Select your CC (e-mail carbon copy) list. 7) No MIME, no links, no compression, no attachments. Just plain text. 8) E-mail size. 9) Name your kernel version. 10) Don't get discouraged. Re-submit. 11) Include PATCH in the subject 12) Sign your work 13) When to use Acked-by: and Cc: 14) Using Reported-by:, Tested-by: and Reviewed-by: 15) The canonical patch format 16) Sending git pull requests (from Linus emails) 1) Read Documentation/CodingStyle 2) #ifdefs are ugly 3) 'static inline' is better than a macro 4) Don't over-design. $ scripts/get_maintainer.pl -f fs/partitions/ibm.c Martin K. Petersen martin.peter...@oracle.com Jens Axboe jens.ax...@oracle.com linux-ker...@vger.kernel.org Summary: the best thing is to send your patch as a _unified_ diff (i.e. generated with diff -u), and include it inline in a message to the addresses listed above, with the following format: some timeless words about the patch Signed-off-by line (see Documentation/SubmittingPatches for what this means and why) --- some timely words about the patch the patch (diff -up output) It seems I have only been able to make more work for you lately. Sorry. I would also be willing to pass on the patch myself, but at minimum this requires your signed-off-by line, and it might be good to get to know the process anyway. You can see lots of examples at http://news.gmane.org/gmane.linux.kernel Hope that helps, Jonathan [1] The corresponding Debian bug report is still useful, as a way to track the status of the bug in Debian (e.g., what versions have the patch applied). To Jonathan: I'm willing to do this. But there are a couple of practical considerations why I don't think I'll go that route. First of all, I have never been able to successfully send or receive in-line patches using my e-mail client. (You may recall my inability to successfully receive some patches for parted that you sent me earlier.) Somehow or other, my e-mail client hoses them up. I don't know if its the handling of tabs or wrapping long lines, or just what the problem is. Second, although my patch works, there is a potential data access issue involved here. My little stand-alone utility program will fix that problem, but it relies on knowledgeable human intervention in advance to prevent data from becoming unreadable. IBM may prefer a more sophisticated solution. For example, they may prefer a solution that checks for a valid file system or swap space on the block that a non-reserved minidisk would use, and, if that is the case, and if a valid filesystem or swap space is not found on the block that a reserved minidisk would use, it may automatically set the disk offset field in the CMS disk label to zero and update the label. That would involve more work, and is probably beyond my capabilities at this point, but IBM may choose that as a solution. From my research, this bug was probably introduced between kernel 2.6.30.10 and and 2.6.31. That's when they changed the definition of blocksize from dbev_hardsect_size(bdev) to bdev_logical_block_size(bdev). That apparently fixed one problem and caused another (this one). I previously found a bug in the DIAG driver (could not bring read-only minidisks online) and wrote a zap to fix the problem. But IBM's solution was more elegant and added several more kernel messages. Their fix was better than mine. And their fix to this problem may be better than mine too. So I'm going to send an e-mail to linux...@de.ibm.com to report the bug and see what happens. In the meantime, my patch is available for users who want to build a custom kernel with my patch applied to fix the problem. Wish me luck! -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1734739580.342738.1274546298656.javamail.r...@md01.wow.synacor.com
Bug#582281: Partition starting sector and size incorrect for reserved CMS minidisk on FBA DASD with blocksize 512 using DIAG driver
Dear IBM Linux Kernel development team, This is an official bug report. See Debian bug report number 582281 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582281 for details. From my research it appears that this bug was introduced between Linux kernel version 2.6.30.10 and 2.6.31. That is when blocksize in fs/partitions/ibm.c, function ibm_partition, was changed from blocksize = bdev_hardsect_size(bdev) to blocksize = bdev_logical_block_size(bdev) This apparently solved one problem but caused another one. A link to a patch which fixes the problem is present in the Debian bug log. Please copy 582...@bugs.debian.org on correspondence. Respectfully submitted, Stephen Powell -- .''`. Stephen Powell : :' : `. `'` `- -- 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/464168684.343085.1274547550975.javamail.r...@md01.wow.synacor.com
Bug#582281: Promised utility now available
As promised in my original post, I have written a little utility program to zap the disk labels of minidisks corrupted by this bug. Running it against all affected disks will allow existing data to be accessed safely by both types of Linux kernels: those that have the bug and those that have the fix applied. The utility can be found here: http://www.wowway.com/~zlinuxman/kernel/ZAPLABEL.ASM This is s390 assembler language source code for the utility. The comments explain how to assemble and use it. It is designed to be assembled and used under CMS. Now, how do you want to work this? Do you (the Debian Kernel Team) want to function as an intermediary between me and upstream? Or would you prefer that I report the problem to upstream myself? -- .''`. Stephen Powell : :' : `. `'` `- -- 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/274713590.319959.1274455956217.javamail.r...@md01.wow.synacor.com
Bug#582281: Partition starting sector and partition size calculated incorrectly for reserved CMS minidisk on FBA DASD with blocksize 512 using DIAG driver (s390 architecture only)
Package: linux-source-2.6.32 Version: 2.6.32-12 I have discovered a bug in the Linux kernel. The partition starting sector and partition size are miscalculated under certain conditions. These conditions are as follows: (1) The Linux kernel is executing on the s390/s390x architecture (2) The Linux kernel is executing in a virtual machine under z/VM (3) The disk is FBA DASD (4) The disk is CMS formatted (the only disk format supported on FBA DASD) (5) The CMS logical block size is greater than 512 (6) the CMS RESERVE command has been issued to allocate all available space to a single CMS file (7) The DIAG driver (as opposed to the FBA driver) is being used for that disk. Under these conditions, the Linux kernel will treat the CMS RESERVEd minidisk as a non-reserved minidisk. Thus, once a file system or a swap space has been built on the disk by the Linux kernel, the CMS metadata gets clobbered, and the CMS minidisk can no longer be accessed by CMS. The problem is in fs/partitions/ibm.c, function ibm_partition. The algorithm used to calculate the sector in which the volume label is stored is incorrect. For FBA DASD, the volume label is always stored in the second physical 512-byte block (block number one with the blocks numbered starting with zero). This is true regardless of the logical block size. The FBA driver always uses a logical block size of 512 internally, regardless of the CMS logical block size; but the DIAG driver honors the CMS logical block size. As a result, if the CMS logical block size is greater than 512, the sector number of the disk label is calculated incorrectly, and garbage is read in for the disk label. For FBA DASD, one must always read sector number 1 to get the disk label, regardless of the logical block size. The following patch fixes the problem: http://www.wowway.com/~zlinuxman/kernel/ibm.c.diff This patch used the source code for kernel 2.6.32 as a base, but it will probably apply to multiple versions, since this routine doesn't get much maintenance. There is one down side to fixing this problem: data on existing partitions, if they are affected by the miscalculation, may become unreadable. Fortunately, there is a simple fix for this problem, and it can be applied beforehand. Set the disk_offset field of the volume label to zero. This will cause the disk to be treated as a non-reserved CMS minidisk, and the partition location and size will be calculated as before. I am working on a little utility to do this and will post it to my web site when I am finished. Please send this upstream. Or, if you prefer, I can send it upstream myself. Nevertheless, I wanted a Debian bug report created to serve as a problem log. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/409713699.268027.1274293120373.javamail.r...@md01.wow.synacor.com
Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
Package: initramfs-tools Version: 0.94.4 Severity: serious (Note: I opened this bug report with a severity of serious, since it prevents my system from booting. In my humble opinion this makes the package unsuitable for release in a stable release. But I am not a package maintainer nor the release manager; so you can argue with me about the severity if you think it is warranted.) I run Debian testing (Squeeze) on the s390 architecture. I just performed an aptitude update and aptitude full-upgrade sequence, and among the updates was a new version of initramfs-tools: 0.94.4. (I noticed that Debian bug report 576603 was opened with a severity of serious with the apparent goal of keeping the package from migrating from Sid to Squeeze, and the bug has not been marked as resolved, nevertheless the package did migrate to Squeeze within the past few days.) The new package completely broke my system's ability to boot. Allow me to explain the boot mechanism that the old version successfully accomplished, and then explain how the new version fails. I have four different disks, one partition each, that are mounted on four different mount points, as follows: Device Mount Point 0200 / 0201 /boot 0202 /home 0203 swap I have a file called /etc/modprobe.d/dasd which contains the following statement: options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag) This accomplishes two things: (1) it guarantees the correspondence of Linux devices names to s390 device numbers as follows: Device 0200 /dev/dasda 0201 /dev/dasdb 0202 /dev/dasdc 0203 /dev/dasdd and (2) it specifies the device driver used for each disk as follows: -- .''`. Stephen Powell : :' : `. `'` `- -- 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/738852436.193388.1274110769225.javamail.r...@md01.wow.synacor.com
Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
Oops! I accidentally sent the e-mail prematurely. Allow me to continue ... and (2) it specifies the device driver used for each disk as follows: Device Device Name Driver -- - /dev/dasda dasd_diag_mod /dev/dasdb dasd_eckd_mod /dev/dasdc dasd_diag_mod /dev/dasdd dasd_diag_mod I run Debian GNU/Linux in a virtual machine under IBM's z/VM operating system, of course. Otherwise, the DIAG driver cannot be used. The way the module dependencies work, the modules must be loaded in the following order: (1) dasd_mod (no dependencies on another module) (2) dasd_diag_mod (dependency on dasd_mod) (3) dasd_eckd_mod or dasd_fba_mod (both have a dependency on dasd_mod) Although strictly speaking neither dasd_eckd_mod nor dasd_fba_mod have a dependency on dasd_diag_mod, nevertheless dasd_diag_mod must be loaded *before* either dasd_eckd_mod or dasd_fba_mod if a dasd of that type is to use the DIAG driver. To guarantee this I have the following lines in /etc/initramfs-tools/modules: dasd_mod dasd_diag_mod in that order. Neither dasd_eckd_mod nor dasd_fba_mod are listed here, since they are loaded as needed by the hot plug system (i.e. udev). I do not use sysconfig-hardware touch files (i.e. /etc/sysconfig/hardware/config-ccw-0.0.0200, /etc/sysconfig/hardware/config-ccw-0.0.0201, etc.), since I have had trouble in the past getting one of these devices varied offline dynamically if they are brought online at boot time via this method. Instead, I bring the devices online at boot time via the dasd option passed to the dasd_mod module via the /etc/modprobe.d/dasd file. All of this has been working flawlessly through a number of releases until now. All of a sudden, nothing works. The boot process times out waiting for the permanent root file system and drops me into an ash shell while the initial RAM filesystem is still mounted as /. I investigated and found that /etc/modprobe.d/dasd was not included in the initial RAM filesystem. That's a problem! Seeing that all other files that were included in /etc/modprobe.d had an extension of .conf, I renamed /etc/modprobe.d/dasd to /etc/modprobe.d/dasd.conf, rebuilt the initial RAM filesystem, re-ran zipl, and rebooted. This time it tried to bring the devices online but got errors of the form: dasd: 0.0.0200 Setting the DASD online failed because of missing DIAG discipline dasd: 0.0.0200: Setting the DASD online failed with rc=-19 0.0.0201 (/dev/dasdb) was the only device that it could get online. I knew immediately what was the cause of this: dasd_diag_mod was not loaded soon enough. By the time it dropped me into an ash shell, dasd_diag_mod was loaded, but at the time that dasd_eckd_mod was trying to bring the devices online, dasd_diag_mod was not loaded. The modules listed in /etc/initramfs-tools/modules must be loaded *before* udev is allowed to do its thing. The message udev: starting version 154 occurs in the log before Begin: Loading essential drivers ... done. To further complicate matters, it appears that the entire /etc/initramfs-tools directory, including /etc/initramfs-tools/modules, is absent from the initial RAM filesystem. How would it even know what modules need to be loaded as essential drivers if this file is not present? A new kernel, linux-image-2.6.32-5-s390x, was also included in the upgrade; so perhaps this is part of the problem as well. Previously, I was using linux-image-2.6.32-3-s390x. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1715772729.195258.1274113995407.javamail.r...@md01.wow.synacor.com
Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
I just tried a couple of things. First, I thought this might be related to the new dependency-based boot sequencing. I tried adding the line CONCURRENCY=none to /etc/default/rcS to disable parallel booting. But it didn't do the trick. I then rebuilt the initial RAM filesystem and re-ran the boot loader after making the above change. It still didn't fix the problem. Then I booted the old kernel. It booted just fine. But when I rebuilt the initial RAM filesystem for the old kernel with update-initramfs -uk 2.6.32-3-s390x and re-ran the boot loader, then the old kernel wouldn't boot either. So this is not related to the kernel. It is definitely related to the new version of initramfs-tools. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1209128820.198253.1274118663770.javamail.r...@md01.wow.synacor.com
Bug#582002: [SOLVED] Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
On Mon, 17 May 2010 13:33:05 -0400 (EDT), Maximilian Attems wrote: you can use modprobe config here again see man modprobe.conf and the softdep line. That did the trick! I changed /etc/modprobe.d/dasd (now called /etc/modprobe.d/dasd.conf) as follows: options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag) softdep dasd_eckd_mod pre: dasd_diag_mod softdep dasd_fba_mod pre: dasd_diag_mod I also removed the two lines from /etc/initramfs-tools/modules dasd_mod dasd_diag_mod since they are no longer needed. I then rebuilt the initial RAM filesystem and re-ran the boot loader (zipl). It's working now! Thanks for your help. I'll leave this problem record open though, to remind you that files in /etc/modprobe.d which do not have an extension of .conf need to be re-enabled (at least for a while longer) to prevent migration problems. But my system is bootable again, now that I've made the changes indicated above. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/964759525.199155.1274120274698.javamail.r...@md01.wow.synacor.com
Bug#550898: [stable] Appeal to backport dasd_diag fix to stable update for
On 2010-01-04 at 14:52:19 -0800, Greg KH wrote: On Mon, Dec 21, 2009 at 10:26:38AM -0500, Stephen Powell wrote: Hello upstream kernel team! A fix was recently published for drivers/s390/block/dasd_diag.c to fix a problem with an inability to get read-only minidisks online to Linux via the dasd_diag driver. This fix was published for kernel release 2.6.33. (See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=22825ab7693fd29769518a0d25ba43c01a50092a for the git commit.) Here is a description of the problem: Now queued up, thanks for the information. greg k-h Thanks, Greg. This is much appreciated! -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550898: Appeal to backport dasd_diag fix to stable update for 2.6.32
Hello upstream kernel team! A fix was recently published for drivers/s390/block/dasd_diag.c to fix a problem with an inability to get read-only minidisks online to Linux via the dasd_diag driver. This fix was published for kernel release 2.6.33. (See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=22825ab7693fd29769518a0d25ba43c01a50092a for the git commit.) Here is a description of the problem: -- [S390] dasd: support DIAG access for read-only devices author Stefan Weinhuber w...@de.ibm.com Mon, 7 Dec 2009 11:51:48 + (12:51 +0100) committer Martin Schwidefsky s...@mschwide.boeblingen.de.ibm.com Mon, 7 Dec 2009 11:51:34 + (12:51 +0100) When a DASD device is used with the DIAG discipline, the DIAG initialization will indicate success or error with a respective return code. So far we have interpreted a return code of 4 as error, but it actually means that the initialization was successful, but the device is read-only. To allow read-only devices to be used with DIAG we need to accept a return code of 4 as success. Re-initialization of the DIAG access is also part of the DIAG error recovery. If we find that the access mode of a device has been changed from writable to read-only while the device was in use, we print an error message. Signed-off-by: Stefan Weinhuber w...@de.ibm.com Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com -- I am the one who originally reported this problem to my Linux distributor (Debian), and I'd like to thank you all for your quick response to this problem. However, I'd also like to make an appeal to have this fix backported to your next stable release update for 2.6.32. It appears likely at this point that 2.6.32 will be adopted as the kernel used by Debian's next release (6.0.0, codename Squeeze). Having this fix in the kernel when Squeeze is first released will be a great benefit. This is an important fix for the s390 architecture. Other distributions have recognized this and have backported the fix as far back as 2.6.16 kernels (SLES10). Regards, Steve Powell -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550898: DASD DIAG driver doesn't work for read-only minidisks (s390, s390x only)
An official fix has now been published for this problem by upstream development for kernel 2.6.33. See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=22825ab7693fd29769518a0d25ba43c01a50092a Please consider backporting it to 2.6.32 so that when Squeeze freezes, this fix will be included. Also please consider backporting it to 2.6.26 (Lenny) in the next stable point release or in a security update. Suse considered this fix important enough to backport it to 2.6.27 (SLES11) and 2.6.16 (SLES10). (See http://lists.debian.org/debian-s390/2009/12/msg00013.html) For the security argument, please see http://lists.debian.org/debian-s390/2009/12/msg00025.html. This posting also contains a link to my unofficial backport of the fix to 2.6.26. As the author, I hereby grant permission to anyone to use it for any purpose whatsoever. Or, if you prefer, you can do your own backport. I will try to get upstream to include the patch in one of their stable updates for 2.6.32 as well, but it would help if I had some allies at Debian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Custom Kernel Building in Debian
I'm afraid that's beyond my area of recent experience. The last time I built an out-of-tree module was back in the days when the ALSA drivers were not part of the kernel source tree, and I was using Woody, I think, with a 2.4 kernel. But make-pkpg could do that back then, and I would hope that it still can. I have no experience at all with DKMS. I do mention building out-of-tree modules in passing in my document, but I give no examples because I have none to offer in my recent experience. FYI it can't. The DKMS using modules (vmware specifically) don't build with make-kpkg or module-assistant. That is actualy the reason for the mail. Well then let's hope that someone out there who is willing and able to do something about it is listening. I'm afraid that's beyond my level of expertise right now. Regards, Steve -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Custom Kernel Building in Debian
I would like to suggest addressing the building of out-of-tree modules as well. This is kind of a moving target, as Debian does not currently offer a way to build deb packages from out-of-tree modules which have been (prematurely, IMO) converted to DKMS. I'm afraid that's beyond my area of recent experience. The last time I built an out-of-tree module was back in the days when the ALSA drivers were not part of the kernel source tree, and I was using Woody, I think, with a 2.4 kernel. But make-pkpg could do that back then, and I would hope that it still can. I have no experience at all with DKMS. I do mention building out-of-tree modules in passing in my document, but I give no examples because I have none to offer in my recent experience. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Custom Kernel Building in Debian
first of all you shall build your linux-2.6 in ~/src/ no compellent reason to do it in /usr/src second you shall use make deb-pkg no need to use kernel-package on a recent linux-2.6 tarball (= 2.6.31). it will just produce the linux-image. Thank you for your feedback. In response to your feedback I have created a new section in my document called Alternatives. It's at the end. If you visit the site and don't see it, be sure to manually reload the page to make sure you are not looking at an obsolete cached version of the page. Here's the link again. http://www.wowway.com/~zlinuxman/Kernel.htm Regards, Steve -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Custom Kernel Building in Debian
here the pointer to the historic mail from linus, quite dated already http://lkml.indiana.edu/hypermail/linux/kernel/0007.3/0587.html Thanks. I have read the e-mail. I am not a C programmer, despite managing to hack out a kernel patch for dasd_diag.c. But I do know other programming languages, and I am familiar with the concept of including a structure declaration from a library, which is what these headers appear to be to me. And I think that I understand, at least in principle, the problem that Linus is trying to address in this e-mail. It appears to me that Debian has long ago solved the problem that Linus is trying to work around in this e-mail. For example, on Debian Lenny, /usr/include/asm is no longer a symlink to /usr/src/linux/include/asm, or to any other directory for that matter. /usr/include/asm is a stand-alone directory in its own right. Linus' recommendation that kernel builders put their source code elsewhere, in particular he recommended ~/src, was a workaround for the symlink problem, which no longer exists. That's my take on it. Am I missing something here? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Custom Kernel Building in Debian
Maybe I'm re-inventing the wheel here, but I have recently collected and organized my notes on custom kernel building in Debian and have put them on the web at the following URL: http://www.wowway.com/~zlinuxman/Kernel.htm Maybe it will be useful to somebody. If there is anything incorrect on this page, regardless of how small or inconsequential, please tell me. If it's out-of-date, please tell me. If it's redundant, or if there's better documentation somewhere else, please tell me. I welcome all feedback. I am subscribed to debian-s390, but not to debian-kernel; so if you post to debian-kernel please cc me. I welcome any and all feedback. Commence firing. Fire at will. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Custom Kernel Building in Debian
On Mon, Nov 16 2009, Manoj Srivastava wrote: I like that, and would like to be able to incorporate this HOWTO in the kernel-package package. What license are you distributing the document under? If it is a free license, I would like it to be in the kernel-package docs for Squeeze. I'm glad you like it. As stated in the disclaimer section, the license is public domain. Use whatever you want. A little blurb of attribution would be nice though. Regards, Steve -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550898: DASD DIAG driver doesn't work for read-only minidisks (s390, s390x only)
However ... This fix also creates (or more likely exposes) another problem. When this fix is on, devices which are manually taken offline immediately come online again! I had this problem once before in an earlier kernel, but the problem eventually went away with maintenance. False alarm. I can now reproduce this error in kernels without the patch too. It just doesn't happen all the time (with or without the patch). Further research is needed on this problem. In any case, I am convinced that these two problems are totally unrelated. FYI: The DASD device driver maintainers are aware of this problem and will provide a fix for the upstream version of the Linux kernel with the next merge window (2.6.33). Should you need the fix for an earlier version, someone at Debian will need to port that fix back to the respective levels. Regards, Peter Oberparleiter Since upstream development has accepted this as a bug and has agreed to provide a fix in the next merge window, I respectfully request that this patch be included in the next stable release of Debian for s390 (6.0.0 -- Squeeze). If you could include it in the next update of the stable release (5.0.4 -- Lenny), that would be good too. In the meantime I will need to build a custom kernel with every security update that hits the kernel, which I don't like to have to do. Here is my version of the patch: -- *** dasd_diag.c 2008-07-13 17:51:29.0 -0400 --- /usr/src/linux-source-2.6.26/drivers/s390/block/dasd_diag.c 2009-10-14 09:30:26.0 -0400 *** *** 111,116 --- 111,120 rc = dia250(iib, INIT_BIO); + /* Fix for read-only minidisk */ + if (rc == 4) rc = 0; + /* End fix for read-only minidisk */ + if ((rc 3) == 0 end_block) *end_block = iib-end_block; -- This is a context diff with three lines of context. I don't know if this is the standard way of producing patch files or not. Forgive me; I'm new at this. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550898: DASD DIAG driver doesn't work for read-only minidisks (s390, s390x only)
I have come up with a patch that seems to solve my problem.
The mdsk_init_io internal subroutine of drivers/s390/block/dasd_diag.c
currently looks like this:
--
/* Initialize block I/O to DIAG device using the specified blocksize and
* block offset. On success, return zero and set end_block to contain the
* number of blocks on the device minus the specified offset. Return non-zero
* otherwise. */
static inline int
mdsk_init_io(struct dasd_device *device, unsigned int blocksize,
blocknum_t offset, blocknum_t *end_block)
{
struct dasd_diag_private *private;
struct dasd_diag_init_io *iib;
int rc;
private = (struct dasd_diag_private *) device-private;
iib = private-iib;
memset(iib, 0, sizeof (struct dasd_diag_init_io));
iib-dev_nr = private-dev_id.devno;
iib-block_size = blocksize;
iib-offset = offset;
iib-flaga = DASD_DIAG_FLAGA_DEFAULT;
rc = dia250(iib, INIT_BIO);
if ((rc 3) == 0 end_block)
*end_block = iib-end_block;
return rc;
}
--
After the rc = dia250(iib, INIT_BIO); statement I add a
statement that sets rc to zero if it is 4. The resulting code
looks like this:
--
/* Initialize block I/O to DIAG device using the specified blocksize and
* block offset. On success, return zero and set end_block to contain the
* number of blocks on the device minus the specified offset. Return non-zero
* otherwise. */
static inline int
mdsk_init_io(struct dasd_device *device, unsigned int blocksize,
blocknum_t offset, blocknum_t *end_block)
{
struct dasd_diag_private *private;
struct dasd_diag_init_io *iib;
int rc;
private = (struct dasd_diag_private *) device-private;
iib = private-iib;
memset(iib, 0, sizeof (struct dasd_diag_init_io));
iib-dev_nr = private-dev_id.devno;
iib-block_size = blocksize;
iib-offset = offset;
iib-flaga = DASD_DIAG_FLAGA_DEFAULT;
rc = dia250(iib, INIT_BIO);
/* Fix for read-only minidisk */
if (rc == 4) rc = 0;
/* End fix for read-only minidisk */
if ((rc 3) == 0 end_block)
*end_block = iib-end_block;
return rc;
}
--
This fix solves the problem. I can now get read-only minidisks to come online.
However ...
This fix also creates (or more likely exposes) another problem. When this fix
is on, devices which are manually taken offline immediately come online again!
I had this problem once before in an earlier kernel, but the problem eventually
went away with maintenance. But with this fix on, the original problem of
getting disks offline is back. The only way I can get around it is to
immediately detach the disk with CP. For example:
# echo 0 /sys/bus/ccw/devices/0.0.0404/online;vmcp DETACH VIRTUAL 0404
If the device isn't there, it can't be brought online! But I shouldn't have
to resort to something like this. Someone really needs to take a closer
look at this.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550898: DASD DIAG driver doesn't work for read-only minidisks (s390, s390x only)
Package: linux-image-2.6.26-2-s390x Version: 2.6.26-19 X-Debbugs-CC: debian-s...@lists.debian.org This bug report applies to the s390 and s390x Linux kernel architectures only. I am reasonably certain that this is not a Debian-specific bug but applies to all distributions. Nevertheless, since I am using Debian I will report it to Debian. Please call this bug report to the attention of the appropriate upstream kernel development team. When using the DASD DIAG driver with a read-only minidisk, the initialize function of DIAG X'250' fails. The error message produced goes something like this: dasd(diag) 0.0.0404: DIAG initialization failed (rc=4) dasd_generic couldn't online device 0.0.0404 with discipline DIAG rc=-5 Consulting the IBM manual CP Programming Services for DIAG X'250', I find the following explanation for return code 4 for the initialize function: Initialization for DIAGNOSE code X'250' to the specified virtual device is complete. The virtual device is read-only. The starting block number and the ending block number have been stored in the BIOPL. In other words, this is a normal condition, not an error. It is simply a warning that this minidisk is read-only. The correct response by the program should be to treat a return code of 4 the same as a return code of 0, provided that the device really is read-only. A return code of 4 for a device that is supposedly read-write is a sanity-check error that you might want to check for. Otherwise, a return code of 4 is a normal and expected condition. I don't claim to be a C programmer, but it appears to me that the mdsk_init_io internal subroutine of /drivers/s390/block/dasd_diag.c is the culprit. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
I issued the mkinitramfs command with the exact options you specified,
then re-ran zipl, then rebooted. No change in results. But the
custom kernel built with kernel-package works just fine. Could this be
some kind of cross-compilation problem, perhaps? Do you build your
s390 kernels on an s390 platform? Or do you use a common platform
(such as i386) to build kernel images for all platforms? Has the
Debian installer been rebuilt with the new kernel image? If so, I'll
try it out to see if it works.
I doubt that this has anything to do with the problem, but I'll
mention it anyway just for grins because I'm running out of ideas.
There are a couple of departures in my environment from the typical
plain vanilla Debian install. First of all, the minidisks that I
use are CMS-formatted minidisks, not Linux cdl minidisks. They
have been processed under CMS with the FORMAT and RESERVE commands,
which creates a single implicit partition on the minidisk consisting
of the reserved CMS file. The dasdfmt and fdasd commands under
Linux are therefore not used in preparing these minidisks. mke2fs
is used, however, to create a file system on the implicit partition.
(In the case of the swap disk, mkswap is used instead of mke2fs.) Second,
with the exception of the /boot partition, which is controlled by
the dasd_eckd_mod driver, all other partitions are controlled by
the dasd_diag_mod driver. Here is my setup:
--
vdev Linux device Partition Mount Point Driver
- --- -
0200 dasda dasda1 /dasd_diag_mod
0201 dasdb dasdb1 /bootdasd_eckd_mod
0202 dasdc dasdc1 /homedasd_diag_mod
0203 dasdd dasdd1 swap dasd_diag_mod
--
I would use dasd_diag_mod for all of the minidisks, if I could;
but zipl requires that the /boot partition use the ECKD
discipline. The dasd_diag_mod driver can only be used in a
virtual machine under z/VM. When I IPL, I use the CP command
IPL 0201
I know from experience that it is absolutely critical that
dasd_diag_mod get loaded BEFORE dasd_mod. Otherwise, the
permanent root file system cannot be mounted. Is it possible that
anything in the stock kernel might cause dasd_mod to be loaded
before dasd_diag_mod?
Here are some pertinent files that control this:
/etc/modprobe.d/dasd:
--
options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag)
--
/etc/initramfs-tools/modules:
--
dasd_diag_mod
dasd_eckd_mod
dasd_mod
--
/etc/fstab:
--
# file system mount point type options dump pass
proc/proc procdefaults0 0
/dev/dasda1 / ext3defaults,errors=remount-ro 0 1
/dev/dasdb1 /boot ext3defaults0 2
/dev/dasdc1 /home ext3defaults0 2
/dev/dasdd1 noneswapsw 0 0
--
/etc/zipl.conf
--
[defaultboot]
defaultmenu = menu
:menu
target = /boot
1 = debian
2 = old
default = 1
prompt = 1
timeout = 10
[debian]
target = /boot
image = /boot/vmlinuz
ramdisk = /boot/initrd.img
parameters = root=/dev/dasda1 vmhalt=LOGOFF vmpoff=LOGOFF
[old]
target = /boot
image = /boot/vmlinuz.old
ramdisk = /boot/initrd.img.old
parameters = root=/dev/dasda1 vmhalt=LOGOFF vmpoff=LOGOFF
optional = 1
--
Currently, /boot/vmlinuz is a symbolic link to
/boot/vmlinuz-2.6.26-custom2c-s390,
/boot/initrd.img is a symbolic link to /boot/initrd.img-2.6.26-custom2c-s390,
/boot/vmlinuz.old is a symbolic link to /boot/vmlinuz-2.6.26-2-s390, and
/boot/initrd.img.old is a symbolic link to /boot/initrd.img-2.6.26-2-s390.
This makes debian, the default system, point to the kernel image that works,
2.6.26-custom2c-s390; and old, which can be selected by request with
#CP VINPUT VMSG 2
from the zipl menu points to the stock kernel that doesn't work, 2.6.26-2-s390.
The reason that I have not bothered to give these details before is that
(a) linux-image-2.6.26-1-s390 works and (b) linux-image-2.6.26-2-s390x works.
Both of these images work in the same setup as above. We need to concentrate
on that. Why would the above two images work but not linux-image-2.6.26-2-s390?
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
I notice that the fix for this bug (div64.c) has finally made it into the official Debian kernel source code. However, the latest stock kernel, 2.6.26-2-s390, revision 2.6.26-17, still won't boot in my virtual machine under z/VM 5.4.0, running in an IFL LPAR on a z/890. I still have to build a custom kernel, as described earlier in this problem log, in order to get a kernel that will work. Either there is a problem with the way the latest stock kernel was built, or it wasn't built from a copy of the source that contains the fix, or this divide bug isn't my problem. But when I compile a custom kernel using kernel-package, using the exact same .config file as the one which comes with the stock kernel, it works fine. This shouldn't be necessary. What's going on here? Any ideas? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527963: Regression bug - xirc2ps_cs kernel module works under Etch, fails under Lenny
When I closed this bug report, it appeared that my Compaq Netelligent 10/100 PC Card Ethernet adapter WOULD work with Ethernet cables which have no soft plastic boot protecting the hard plastic hook, but WOULD NOT work with cables which have boots. Subsequent testing, however, has disproved this. I've found cables with boots that work, and I've found cables without boots that don't work. I've done quite a bit of testing since then, and I now believe that the problem is a combination of cable length and router/switch quality. When attaching the dongle directly to my home router, which is a Trendnet TW100-S4W1CA 4-port Cable/DSL Broadband Router, via a single length of cable, I have found that the card works fine with shorter cables, such as ten-foot lengths, regardless of whether the cable has boots or not. The amber link integrity light on the dongle comes on and remains on. When using longer cables, such as 25-foot lengths, the card does not work. The amber link integrity light on the dongle flashes on and off. This is true regardless of whether the cable has boots on its plugs to protect the hooks or not. On the other hand, when I take the machine into the office and attach the dongle to the wall jack, behind which is a commercial-grade switch, I can use the longer 25-foot cables successfully, whether they have boots on them or not. My current theory is that the Compaq Netelligent 10/100 PC Card Ethernet adapter draws a lot of current from the router or switch that it is connected to, in comparison to other PC Card Ethernet adapters, and that the voltage drop across the longer cables is enough to make the voltage out of spec as seen by the card when it is connected to my cheap home router. When it is connected to a commercial-grade switch, which has a lower internal resistance, the voltage drop is not sufficient to make the voltage out of spec, even with the longer cables, and the card therefore works fine. But that is just a guess. What I do know is (1) when using my home router, 10-foot cables work with the card and 25-foot cables do not work with the card, boots or no boots. (2) When using a 3Com card that I have, either length of cable works fine with my home router, boots or no boots. (3) When using a commercial grade switch at the office, both 10- and 25-foot cables work fine with the Compaq card, boots or no boots. They also work with the 3Com card. In any case, my difficulties with the card are not related to changes made to the xirc2ps_cs driver between kernel releases 2.6.18 and 2.6.26. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529697: linux-image-2.6.26-2-686: Crystal 4237b audio card not working and causing kernel freeze during boot
perhaps this means the severity should be lowered I can't speak to that. I'm not a member of the Debian kernel team. I'm just an ordinary end user who happened to notice a reference to the same kind of sound chip that I have and thought I might be able to help. The problem, as I see it, is two-fold. First, there is apparently a bug in the snd-cs4232 driver that causes a kernel oops. That bug has apparently been fixed in 2.6.27. But in your situation (and mine), that driver shouldn't have been loaded in the first place. There is another problem that requires a design change to fix, and I don't know how it's going to be addressed. The idea behind the hot plug system is that kernel modules would be given aliases corresponding to the device ids that they are to be drivers for. These device ids can be listed by lspnp (in the pnputils package), lspci, lspcmcia, etc. If the hot plug system finds a kernel module with an alias which matches a device id that it has been able to detect, it loads that kernel module. That works most of the time. Unfortunately, Crystal Semiconductor used the same device id, CSC, for too many dissimilar devices. There are therefore three different drivers that have this alias: snd-cs4232, snd-cs4236, and snd-wavefront. In any given situation, only one of them should be loaded. The question is, which one? It is currently the design of the hot plug system to load all drivers that have an alias matching the device id. That means it tries to load all three of them. Either some additional smarts must be added to the hot plug system to figure out which one is the right driver in this situation and load only that one, or else the drivers themselves need to be smarter, so that they won't touch a sound chip that another driver should be used for. And that's not a bug: that's a design change. In the meantime, the work-around is to blacklist the drivers that you don't want. This is not too bad when you're INSTALLING Linux, provided that you understand what's going on and how to work around it. A smarter installer could solve that problem. But how would Debian Live systems, which must figure out everything on the fly, know which driver to load? The kernel people need to take a look at this. In a perfect world, it would be nice if Linux knew how to configure ISA PnP devices on older IBM ThinkPads too, such as the 600. It is apparently done in some kind of non-standard way. But I'm not holding my breath. Anyway, I believe that you can get full functionality out of your CS4237B sound chip, even under the standard Lenny kernel, if you read my web site carefully. It won't happen automatically. But with the right configuration steps, it can be done. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523831: linux-image-2.6.26-2-686: Boot hangs with message 'Loading kernel modules...'
Dear Mr. Hansen, I am not a member of the Debian Kernel Team, or any other team for that matter. I am just an ordinary end user. But I noticed the message Clocksource tsc unstable (delta = -244351700 ns) in the kernel log file and wondered if that might be part of your problem. You yourself have speculated that this might be a timing issue. That is a huge delta, especially since you're still booting. I'm curious to see if the following kernel boot parameters will solve your problem: clocksource=pit notsc For a more detailed discussion, see my web site, http://www.wowway.com/~zlinuxman/tp600.htm, under the heading Clock Sources. Even if it does not solve your problem, you should disable any clock source that is reported as unstable in a message of the form Clocksource xxx unstable if that is possible, with a kernel boot parameter. In this case, notsc does it. I am not subscribed to this bug report; so if you reply, please copy me separately. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
Yes, 15lenny2 was a security update. This fix is queued for 2.6.26-16 which should be included in Debian 5.0.2. Well, I guess that makes sense; since the kernel that is packaged with the Debian installer needs to be replaced too. Even s390x kernels, which are not affected by this bug, are installed with an s390-kernel- based installation system, which is affected by the bug. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529697: linux-image-2.6.26-2-686: Crystal 4237b audio card not working and causing kernel freeze during boot
I had a similar problem installing Lenny on an IBM ThinkPad 600 Model 2645-51U, which also has a built-in Crystal Semiconductor CS4237B sound chip. You might want to check out my web site, http://www.wowway.com/~zlinuxman/tp600.htm, to see how I handled the problem. One thing in particular that I noticed is that you blacklisted snd-cs4232, which is good, but you did not blacklist snd-wavefront, which is bad. You need to blacklist snd-wavefront too. There are many other sound tips in there too, including how to get the FM synthesizer to work. Hope this helps. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527963: Regression bug - xirc2ps_cs kernel module works under Etch, fails under Lenny
In the process of collecting additional supporting data, I have stumbled upon the problem. As mentioned earlier, there are two laptops involved here. One runs Etch (kernel 2.6.18) and the other runs Lenny (kernel 2.6.26). The Compaq Netelligent 10/100 PC Card adapter works in the Etch machine and fails in the Lenny machine. I concluded therefore that something must have changed in the driver (xirc2ps_cs) between Etch and Lenny that caused it to fail. Well, there are differences in the driver between the two releases. But that's not the problem. The problem turns out to be the Ethernet cable / dongle connection. The cable that runs to the Etch machine uses an older style of connector. The cable that runs to the Lenny machine uses a newer style of connector. The cable that runs to the Lenny machine has a flexible plastic sheath around the back of the hard plastic snap clip. It is intended to protect the hard plastic snap clip. In particular it is intended to keep the hard plastic snap clip from snagging on something and breaking off when the cable is being pulled out from under the floor, or otherwise being treated roughly. The cable that runs to the Etch machine does not have this protective plastic sheath. As it turns out, the newer style of connector with the protective plastic sheath does not mate securely with the RJ-45 connector in the short patch cable, sometimes called a dongle, that transitions from the miniature connector on the edge of the credit card adapter to a standard RJ-45 connector, into which the Ethernet cable is plugged. There is nothing wrong with the card. There is nothing wrong with the patch cable (dongle). There is nothing wrong with the Ethernet cable. But the patch cable (dongle) does not mate properly with that kind of Ethernet cable. Substituting a different Ethernet cable with the older style of connector (no protective plastic sheath) solved the problem. In other words, it's a hardware problem, not a software problem. Sorry to bother you. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
The latest kernel update, revision 2.6.26-15lenny2, still does not contain the fix for this problem. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527963: Regression bug - xirc2ps_cs kernel module works under Etch, fails under Lenny
If you need more information on my system and how it is set up, please see http://www.wowway.com/~zlinuxman/tp600.htm.
Bug#527963: Regression bug - xirc2ps_cs kernel module works under Etch, fails under Lenny
I tried installing linux-image-2.6.29-bpo.2-686 from lenny-backports to see if the latest linux kernel would fix the problem, but it does not. The symptom is the same. The card is recognized and configured, but I/O does not work. Therefore, DHCP configuration fails. Here is the output of lspcmcia -v: -- Socket 0 Bridge:[yenta_cardbus] (bus ID: :00:02.0) Configuration: state: on ready: yes Voltage: 5.0V Vcc: 5.0V Vpp: 0.0V Socket 0 Device 0: [xirc2ps_cs](bus ID: 0.0) Configuration: state: on Product Name: Compaq Netelligent 10/100 PC Card CPQ-10/100 1.00 Identification: manf_id: 0x0183 card_id: 0x010a function: 6 (network) prod_id(1): Compaq (0x54f7c49c) prod_id(2): Netelligent 10/100 PC Card (0xefe96769) prod_id(3): CPQ-10/100 (0x7a590ccf) prod_id(4): 1.00 (0x83dbf271) Socket 1 Bridge:[yenta_cardbus] (bus ID: :00:02.1) Configuration: state: on ready: yes -- The exact same card works fine in another laptop running Etch, and a different 16-bit card which uses a different driver (3c574_cs) works fine under Lenny using both kernels linux-image-2.6.26-2-686 and linux-image-2.6.29-bpo.2-686.
Bug#527963: Regression bug - xirc2ps_cs kernel module works under Etch, fails under Lenny
Package: linux-image-2.6.26-2-686 Version: 2.6.26-15 Severity: normal I have two laptops. One is an IBM ThinkPad 390E running Debian Etch (kernel linux-image-2.6.18-6-686). The other is an IBM ThinkPad 600 running Debian Lenny (kernel linux-image-2.6.26-2-686). I have a 16-bit PC Card 10/100 Ethernet adapter that works in the Etch machine but does not work in the Lenny machine. The card has COMPAQ 10/100 PC CARD and 292811-008 on the front and various things on the back such as COMPAQ, With Integrated 100Mbps Transceiver, 292811-009, Series NNB108, N260, CE, PC Card, and some other stuff. I am using the patch cable (or dongle, or whatever you want to call it) that came with the card. Linux recognizes the card as fully supported and loads kernel module xirc2ps_cs to drive it. Under Etch, the card works fine. Under Lenny, the failure occurrs with a timeout of DHCP configuration. I can use other 16-bit and 32-bit Ethernet cards successfully in the Lenny machine, but not the Compaq card. lspcmcia -v lists the card as a Compaq Netelligent 10/100 card, though the word Netelligent is not physically printed on the card anywhere.
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
Actually, I decided to go ahead and do the plan I had outlined, just for grins, while I was waiting on an answer. If it didn't work, and Frans said yes, do that, I could then say it didn't work right away and save time. But it did work! Here is what I did, as close as I can remember it. I was logged in as root. linux-image-2.6.26-1-s390 and linux-image-2.6.26-2-s390 are both installed at this point, linux-image-2.6.26-2-s390 is the default kernel image, and linux-image-2.6.26-1-s390 is the currently running kernel. kernel-package and all its prerequisites have previously been installed. aptitude install linux-source-2.6.26 aptitude clean cd /usr/src tar -xjf linux-source-2.6.26.tar.bz2 rm linux-source-2.6.26.tar.bz2 cd linux-source-2.6.26 cp -a /boot/config-2.6.26-2-s390 .config cd arch/s390/lib vi div64.c [change alr %1,%2\n to ahi %1,1\n, file it] cd /boot aptitude purge linux-image-2.6.26-2-s390 linux-image-s390 ln -s vmlinuz-2.6.26-1-s390 vmlinuz ln -s initrd.img-2.6.26-1-s390 initrd.img rm initrd.img.old rm vmlinuz.old zipl cd /usr/src/linux-source-2.6.26 make menuconfig [Exit without making any configuration changes] make-kpkg clean make-kpkg --append-to-version -custom2-s390 --revision 1 --initrd kernel_image cd .. dpkg -i linux-image-2.6.26-custom2-s390_1_s390.deb [zipl is run during the installation of the package] rm linux-image-2.6.26-custom2-s390_1_s390.deb shutdown -r now;exit The machine shutdown and rebooted with linux-image-2.6.26-custom2-s390 as the running kernel. It came up perfectly! Wow! What a nasty bug! When the divide instruction doesn't work properly, anything can happen anywhere! I will continue to run this custom kernel image until there is an official Debian kernel image available which contains this fix. Please leave this bug report open until such is the case. And please get this fix into the official kernel ASAP!
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
Correction. The s390 server did not have two virtual CPUs. It had a *LIMIT* of two virtual CPUs. In other words, its CP directory entry contained MACH XA 2 This statement creates only one virtual CPU, but allows a second one to be defined, if desired, by means of the CP DEFINE CPU command. I changed it to MACH XA and observed the change in behavior. However, this merely caused it to fail in a different way. Also, I just upgraded from z/VM 5.3.0 to z/VM 5.4.0, with current maintenance (about one month old), and the problem remains.
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
Could http://bugs.debian.org/511334 be related to your problem? There's a link to patch in one of the last messages. See especially messages #57 and #65. It's possible that they may be related. The difference, though, is that the user in problem number 511334 was running in a virtual machine under z/VM 5.2.0, which in turn was running on Flex-ES or Hercules machines, both of which are mainframe emulators. I am running on a real IBM mainframe. It is an Integrated Facility for Linux (IFL) processor on a z/890 (2086) machine, dedicated to an IFL-only LPAR. z/VM 5.4.0 runs under that, and my Linux virtual machine runs under that. His boots were hanging much earlier in the boot process until he applied the patch. After applying the patch, he was able to get up to the point where the DASD drivers are supposed to load, but was not able to get further than that. The user was optimistic that his problem from that point on was simply a matter of a faulty RAM disk, but I see no evidence that he was able to get the permanent root file system mounted under any scenario. I predict that he is still stuck at that point. My problem, on the other hand, has always been that the kernel hangs right before the permanent root file system gets mounted. I've always been able to get that far but no farther. For me, the key is that the s390x kernel works flawlessly, but the s390 kernel hangs. I suspect that the problem is that an instruction which is only valid in z/Architecture mode is being issued in ESA mode, and that is what is causing the problem. That's just a hunch.
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
Can you boot the old kernel and unpack the initramfs to see if the needed modules got added? See the DEBUG section of initramfs-tools(8) for a command to do the unpacking. As you know, the initial RAM file system is not included with the kernel image package but is built dynamically during kernel image installation. Furthermore, update-initramfs only keeps one backup copy per kernel image, and I have played around with several iterations of building initial RAM file system images; so the original one built during initial kernel installation is no longer available. But none of my subsequent initial RAM file system builds works either. I can verify that all of them did include the three dasd modules (dasd_mod, dasd_eckd_mod, and dasd_diag_mod). I issued the following command: update-initramfs -uvvk 2.6.26-2-s390 update-initramfs.log5 Here is the contents of update-initramfs.log5: -- Keeping /boot/initrd.img-2.6.26-2-s390.dpkg-bak update-initramfs: Generating /boot/initrd.img-2.6.26-2-s390 Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/s390/block/dasd_mod.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/s390/block/dasd_diag_mod.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/s390/block/dasd_eckd_mod.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/s390/char/vmcp.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/block/loop.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/mbcache.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/ext2/ext2.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/jbd/jbd.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/ext3/ext3.ko Adding module /lib/modules/2.6.26-2-s390/kernel/lib/crc16.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/jbd2/jbd2.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/ext4/ext4dev.ko Adding module /lib/modules/2.6.26-2-s390/kernel/lib/zlib_inflate/zlib_inflate.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/nls/nls_base.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/isofs/isofs.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/jfs/jfs.ko Adding module /lib/modules/2.6.26-2-s390/kernel/net/sunrpc/sunrpc.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/nfs_common/nfs_acl.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/lockd/lockd.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/nfs/nfs.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/reiserfs/reiserfs.ko Adding module /lib/modules/2.6.26-2-s390/kernel/lib/crc-itu-t.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/udf/udf.ko Adding module /lib/modules/2.6.26-2-s390/kernel/fs/xfs/xfs.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/net/eql.ko Copying module directory kernel/drivers/scsi Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/scsi_mod.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/scsi_transport_sas.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/st.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/osst.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/scsi_transport_iscsi.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/libiscsi.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/raid_class.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/ch.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/scsi_tgt.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/sd_mod.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/scsi_transport_spi.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/cdrom/cdrom.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/sr_mod.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/sg.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/scsi_transport_fc.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/iscsi_tcp.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/scsi_wait_scan.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/base/firmware_class.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/libsas/libsas.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/misc/enclosure.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/scsi/ses.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/s390/scsi/zfcp.ko Copying module directory kernel/drivers/block Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/block/nbd.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/block/aoe/aoe.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/block/cryptoloop.ko Adding module /lib/modules/2.6.26-2-s390/kernel/drivers/s390/block/dasd_fba_mod.ko Adding binary /usr/share/initramfs-tools/init Adding binary /etc/initramfs-tools/initramfs.conf Adding binary /etc/initramfs-tools/conf.d/resume Adding binary /bin/busybox Adding library /lib/libm.so.6 Adding library /lib/libc.so.6
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
I just tried re-building the initial RAM file system for the 2.6.26-1-s390 kernel image, rerunning zipl, and rebooting. It came up fine. It does not appear to be a problem with the build process for the initial RAM file system. If it is, it is a build problem which is specific to the new kernel image for some reason.
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
By the way, I have another server that runs the 64-bit version of the kernel image (linux-image-2.6.26-2-s390x), and it works fine. Either the bug affects only the 31-bit version of the kernel, or there is an environmental difference of some kind.
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
I have found an environmental difference between the two servers, one of which runs linux-image-2.6.26-2-s390x (and will boot) and the other of which runs linux-image-2.6.26-2-s390 (and will not boot). The s390x server has only one virtual CPU. The s390 server has two virtual CPUs. I changed the s390 version to have only one virtual CPU and tried again. This time it fails in a different way. With two virtual CPUs I get a kernel panic and the virtual machine loads a disabled wait PSW. With one virtual CPU the kernel goes into an infinite loop. The last message written to the console prior to the loop is NET: Registered protocol family 17 During the infinite loop the kernel produces no messages. The loop was detected by monitoring software on z/VM. Of course it should work with 1 or 2 virtual CPUs, since the kernel has SMP support. But it doesn't work with either. It does fail differently, however, between the two scenarios. linux-image-2.6.26-1-s390 continues to work fine. The s390 server has MACH XA in its CP directory entry. The s390x server has MACH ESA in its CP directory entry. If I change the s390 server to use MACH ESA, like the s390x server, it goes back to the original mode of failure (kernel panic, disabled wait) even with only one virtual CPU.
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
Package: linux-image-2.6.26-2-s390 Version: 2.6.26-15 Severity: critical This particular Linux kernel image will not boot on a virtual machine in ESA mode under z/VM. I have not tried other platforms (LPAR, for example). Here is the boot log: -- Booting default (debian)... [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.26-2-s390 (Debian 2.6.26-15) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Mar 27 03:31:55 UTC 2009 [0.00] We are running under VM (31 bit mode) [0.00] This machine has an IEEE fpu [0.00] Zone PFN ranges: [0.00] Normal 0 - 131072 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 - 131071 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130047 [0.00] Kernel command line: root=/dev/dasda1 vmhalt=LOGOFF vmpoff=LOGOFF BOOT_IMAGE=0 [0.00] PID hash table entries: 2048 (order: 11, 8192 bytes) [17179568.184350] console [ttyS0] enabled [17179569.185299] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [17179568.186409] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [17179569.195235] Memory: 510848k/524288k available (2272k kernel code, 0k reserved, 844k data, 148k init) [17179569.195254] Write protected kernel read-only data: 0x12000 - 0x2eefff [17179568.196240] Security Framework initialized [17179569.196258] SELinux: Disabled at boot. [17179568.196276] Capability LSM initialized [17179568.196413] Mount-cache hash table entries: 512 [17179569.197399] Initializing cgroup subsys ns [17179569.197420] Initializing cgroup subsys cpuacct [17179568.197484] Initializing cgroup subsys devices [17179569.320946] CPUs: 1 configured, 0 standby [17179569.471072] cpu 0 phys_idx=0 vers=FF ident=0503CC machine=2086 unused=8000 [17179568.472235] Brought up 1 CPUs [17179569.472695] net_namespace: 660 bytes [17179569.473175] NET: Registered protocol family 16 [17179569.557633] IP route cache hash table entries: 16384 (order: 4, 65536 bytes) [17179569.557633] TCP established hash table entries: 65536 (order: 7, 524288 bytes) [17179569.560173] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [17179569.562589] TCP: Hash tables configured (established 65536 bind 65536) [17179569.562616] TCP reno registered [17179568.574245] NET: Registered protocol family 1 [17179568.574569] checking if image is initramfs... it is [17179570.461614] Freeing initrd memory: 3824k freed [17179570.463293] audit: initializing netlink socket (disabled) [17179570.463321] type=2000 audit(1239646960.408:1): initialized [17179570.464285] VFS: Disk quotas dquot_6.5.1 [17179570.464409] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [17179570.464471] msgmni has been set to 1005 [17179570.464744] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) [17179570.464768] io scheduler noop registered [17179570.464788] io schedulter anticipatory registered [17179570.464810] io scheduler deadline registered [17179570.464882] io scheduler cfq registered (default) [17179570.470664] brd: module loaded [17179570.470774] cio: Channel measurement facility using extended format (autodetected) [17179570.470804] qdio: loading QDIO base support version 2 [17179570.473469] TCP cubic registered [17179570.473657] NET: Registered protocol family 10 [17179570.476252] lo: Disabled Privacy Extensions [17179570.477111] Mobile IPv6 [17179570.477143] NET: Registered protocol family 17 [17179570.477793] registered taskstats version 1 [17179570.478468] Freeing unused kernel memory: 148k freed [17179570.479271] Kernel panic - not syncing: Attempted to kill init! HCPGIR450W CP entered; disabled wait PSW 000A 8001E8FA -- In comparing this boot to the (successful) boot of its predecessor, linux-image-2.6.26-1-s390, version 2.6.26-13lenny2, the previous version loads essential modules at this point: -- Loading, please wait... Begin: Loading essential drivers ... -- at which point the modules listed in /etc/initramfs-tools/modules are loaded. In my case, these modules are dasd_diag_mod dasd_eckd_mod dasd_mod vmcp loop Without the dasd modules, the permanent root file system cannot be mounted. I tried re-running update-initramfs for this specific kernel version, but it made no difference.
Please set CONFIG_DASD_DIAG=m for s390 and s390x linux kernel images
Hello Debian kernel team. I am an IBM mainframe systems programmer. I support and maintain the z/VM operating system at my installation which provides the virtualization that allows multiple virtual Linux servers to share the same LPAR (mainframe partition). I would like to make an appeal for the default Linux kernel configuration in Debian for the s390- and s390x-based kernels to specify CONFIG_DASD_DIAG=m instead of # CONFIG_DASD_DIAG is not set. If you are using MAKE MENUCONFIG, you can find this option listed under Block Devices as Support for DIAG access to disks. I could probably use a stock Linux kernel image if it weren't for that one setting. Since I need it, I have to re-fetch the kernel source code and re-compile a custom kernel every time a security vulnerability fix causes a kernel update. I don't see how this change could HARM anybody. If the module isn't needed, it WON'T be loaded. But if the module isn't there, it CAN'T be loaded! This module (dasd_diag_mod) won't be loaded unless loaded explicitly or unless it is implicitly requested via an option provided to the dasd_mod module when it is loaded. This change should not affect anyone who may be running Linux natively (i.e. running directly in an LPAR and not under z/VM). I would also like to see this change made in the kernels used by the Debian installer. This would improve the installer's usefulness, both for initial installs and also for use as a rescue floppy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Please set CONFIG_DASD_DIAG=m for s390 and s390x linux kernel images
It is enabled in the current Debian kernel images for 2.6.24 and above. However it is not enabled in the Etch 2.6.18. 2.6.24 is currently in proposed-updates and will reach stable in the next days (hopefully). Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
