January 2009 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] Interrupts from the i915 module
by Volker Krueger 30 Jan '09

30 Jan '09

Hi, in the 2.6.27.13-9 kernel, the i915 still generates a lot of interrupts which eventually costs on a laptop valuable energy (up to 20% difference on my laptop at least) I heard in the thinpad forum that this is actually a bug and that it is fixed in 2.6.28. However, it seems that in Ubuntu, the fix was propagated as a patch into 2.6.27 (intrepid-proposed, 2.6.27-11-generic x86_64?) Is there any plan to propagate that change into the 2.6.27 suse kernel as well? best, Volker -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 4

[opensuse-kernel] Disk space requirement of KOTD build from source
by Markus Koßmann 29 Jan '09

29 Jan '09

Today I run out if diskpscae when building a KOTD with "default" configuration from sources. I found that the build now nees 3.5G disk space. the same build of 2.6.27.7-9 only needs 888M. The installation also need much more spae than before : rw-r--r-- 1 root root 2511648 29. Jan 04:35 vmlinuz-2.6.27.13- HEAD_20090128193548_5c4d0ded-default -rw-r--r-- 1 root root 2576096 5. Dez 03:52 vmlinuz-2.6.27.7-9-default and the modules and in /lib/modules: 84M 2.6.27.7-9-default 893M 2.6.27.13-HEAD_20090128193548_5c4d0ded-default Is that change intended ? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 6

[opensuse-kernel] bug in kernel-source-2.6.27.13-2.1 from http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/
by Rainer Klier 28 Jan '09

28 Jan '09

hi list, i think, there is a bug in the latest factory-kernel 2.6.27.13-2 from http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/. at least the kernel source has a bug, i think. i tried to install latest nvidia-driver 180.22 on an opensuse11.1 x86_64 system. former kernel 2.6.27.12-1 had no problems with this. but this time, it was not possible to load nvidia kernel module. the installation-script stopped, and told me that the built kernel module can't be loaded. there were also warnings about missing symbols at compile time. this is the relevant part of dmesg-output when loading the driver: nvidia: Unknown symbol pv_mmu_ops nvidia: Unknown symbol pv_cpu_ops nvidia: Unknown symbol pv_irq_ops nvidia: Unknown symbol pv_lock_ops it seems, the above symbols are missing. this was not the case with 2.6.27.12-1. i had to downgrade kernel to latest available 2.6.27.7-9 from oss-repo. with this version building the nvidia driver also was no problem. right now i am writing this mail with this setup. there must have been some changes between 2.6.27.12-1 and 2.6.27.13-2 which have something to do with these missing symbols. does anybody know anything about this error? -- einen schönen Tag noch DI Rainer Klier Und bitte keine TOFU-Mails (http://de.wikipedia.org/wiki/TOFU) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

8 27

[opensuse-kernel] KOTD 2.6.27.12-HEAD_20090122183653_0d7eb945-default
by Markus Koßmann 26 Jan '09

26 Jan '09

When booting 2.6.27.12-HEAD_20090122183653_0d7eb945-default x86_64 on my system the system freezes immediately with black screen. With both normal and safe settings. Nothing on the screen, nothing in the logs. 2.6.27.12- HEAD_20090120200141_5646759d works fine on that system. How to get useful information for a bug report in that case ? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

5 12

[opensuse-kernel] problems with wireless iwlagn
by Volker Krueger 21 Jan '09

21 Jan '09

Hi, I have problems with my wireless driver iwlagn. all I can say is that it is not possible to log onto our university network. with Ubuntu, however, I _can_ long on. I was told that Ubuntu has patched that driver. So, my problem seems to be a known problem. Does anyone know anything about this? best, Volker -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

6 11

[opensuse-kernel] 2.6.29-rc2 update
by Jeff Mahoney 19 Jan '09

19 Jan '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - Just a quick FYI that I've updated and renamed the v2.6.28-staging tree. It is now known as the HEAD_STAGING tree. The HEAD_STAGING directory will replace the v2.6.28-staging directory on KOTD. The tree is now at 2.6.29-rc2. As usual for an early RC, there are some caveats: - - Xen is still disabled. - - AppArmor is disabled. - - KDB is disabled. It boots on my x86-64 system and I'm waiting for the build logs to tell me where it fails. As those logs arrive, I'll update the tree. This is the bleeding edge, folks. :) - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkly09wACgkQLPWxlyuTD7LRrQCfUAFxXzr4q3tK9YtP5kcA/dpJ 1RcAn2fGAHPG44WqL4pAwvAqCJAOXB6A =UTCz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 2

[opensuse-kernel] Creating a new kernel flavor
by Matt Sealey 18 Jan '09

18 Jan '09

Hi, We're working on creating a new kernel flavor here so we can maintain a few patches against the standard -default kernel without trashing peoples' installations (i.e. while you can't have -default and -genesi at the same time because of the cleanup in post-install, at least if it stops working or there's a weird bug, you can still go back to -default without forcing packages, and there would be no package conflicts if someone added our repo, and it had a higher version of -default..) However I've stumbled across some real weirdness in kernel-source.src - which I then gather builds kernel-source.ppc which then can be used somehow to build kernel-genesi.ppc and .src. For instance, every kernel-$flavor.spec seems to be built from the same source somewhere, with identical changelogs and 99% identical code (the difference being the swapping of the flavor in many places, but that's it). So far I have just hacked up a kernel-genesi.spec myself which is building fine now, but I wondered, where do these files get generated and how can I make my kernel build take part in this process to build an automated spec file? Modifying config.conf, series.conf, adding patches is something I've been doing for a while so that has never been a problem to make a custom kernel-default, I would just like to move away from it. Is there any special documentation or a cheat sheet for how to make a new kernel flavor? What was the process to create kernel-ps3, for example, a few versions ago, and how does it get maintained with the rest? -- Matt Sealey <matt(a)genesi-usa.com> Genesi, Manager, Developer Relations -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 21

[opensuse-kernel] 2.6.27 kernel for 11.0?
by Felix Miata 16 Jan '09

16 Jan '09

http://download.opensuse.org/repositories/home:/ilya_41/openSUSE_11.0/i586/ has these. Anyone know reasons for or against trying to use any of them on a production server? My problem is https://bugzilla.novell.com/show_bug.cgi?id=406035 which is marked fixed, but for 11.1, not 11.0. For the reasons listed in the thread http://lists.opensuse.org/opensuse/2008-12/msg01969.html I'd rather not be forced into 11.1 if possible. Can anyone tell why the above bug's owner claims its fix amounts to a new feature preventing fix's inclusion in 11.0 updates? I installed .27 on an old ICH4 P4 GX260 PATA host I use for testing. Its 11.0 partition is on hda21, and so using piix legacy driver. After a while it locked hard while in runlevel 3. Then I installed .27 on a newer ICH7 P4 RAID1 SATA host "big31" using libata (not my new ICH8 server, but similar in being almost as new). So far big31 hasn't done the same. Can anyone look in the boot.msg & messages logs in http://fm.no-ip.com/tmp/SUSE/110/ and tell me if the lockup might have been due to the .27 kernel rather than piix driver or hardware failure? -- "Train a child in the way he should go, and when he is old he will not turn from it." Proverbs 22:6 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 3

[opensuse-kernel] no suspend for XEN?
by Volker Krueger 16 Jan '09

16 Jan '09

Hi, is it normal that the xen kernel of suse 11.1 is not able to suspend? best, Volker -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 3

Re: [opensuse-kernel] Squashfs
by Rob OpenSuSE 15 Jan '09

15 Jan '09

2009/1/15 Jeff Mahoney <jeffm(a)suse.de>: > > Rob OpenSuSE wrote: >> 2009/1/15 Matt Sealey <matt(a)genesi-usa.com>: >>> On Thu, Jan 15, 2009 at 8:53 AM, Rob OpenSuSE >>> <rob.opensuse.linux(a)googlemail.com> wrote: >> There are end user benefits to mountable initrd's, and would have been >> a much better workround for one bug, than what I actually had to do. > > Actually you would have been just as stuck with squashfs. It's a > read-only file system. You can't loopback mount it and change it. In the > end, you end up having to do the same thing you'd have to do with cpio - > you just replace "zcat initrd | cpio -id" with "mount -o loop". If it's RO and you can't alter it, then there wouldn't seem to be any end user benefit apart from casual browsing, to overcome the "if it ain't broke don't fix it". Just developer benefit through supporting fewer formats. This is what led me to believe, SquashFS was permitting easier modification, I think I misunderstood that. 2009/1/14 Matt Sealey <matt(a)genesi-usa.com>: > >> What advantages do you know of? > > Appending files is a breeze compared to a cpio archive. Replacing the same > file in a cpio usually means dumping and remaking it. mksquashfs can get rid > of the original file and relink the new one at the end.. it would mean you > can do clever tricks like building half the initrd or filesystem image, > doing something else based on that result, and then appending further > processed data. Though mounting, copying to disk, and then re-building the formatted file, is more like making iso files. "zcat initrd | cpio -id" and then rebuilding, wasn't obvious enough to get suggested when I had an issue with replacing the driver with mkinintrd on a live system. It is still a nice to have, as udev generating it's own module list, to be combined with INITRD_MODULES, doesn't make the change methodology clear to the sysadmin. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 4

[opensuse-kernel] Squashfs
by Matt Sealey 15 Jan '09

15 Jan '09

I just noticed that while squashfs 3.4 kernel module is used on the -default kernel, the squashfs tools on both PowerPC and x86 repos are stuck at 3.2 neko@frodo:~> mksquashfs -version mksquashfs version 3.2-r2 (2007/01/15) Is there any particular reason for this? Is there an update planned? Also, more for the kernel guys.. is there any reason why the mkinitrd etc. stuff relies on cpio archives when the SUSE kernel is built with squashfs (granted as a module), all the rescue/install images are squashfs? It does not provide any remarkably better compression - in fact I tested 100k larger filesystem with mksquashfs 3.2 but then mksquashfs 3.2 refuses to use large block sizes so the compression is lower than it could be, also mksquashfs 3.4 supposes a 10% improvement and unsquashfs supposes a 40% improvement in speed in creation and extraction (we will ignore the kernel improvements as, they are in the kernel already).. .. But a few tests in performance usually always show that accessing a squashfs initrd mounted to RAM is faster than a cpio initrd in RAM. It also has a few extra little advantages here and there but I do not know if they are worth it, but I do know that managing squashfs filesystems is a billion times easier than pushing cpio archives around. Since squashfs is going to be in the kernel mainline at some point (it's in Linus' tree) and everyone and his dog makes squashfs initrds, are we going to see a move to it at some point and have the thing built in with more use of the format? -- Matt -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

5 22

[opensuse-kernel] Bashing my head against the desk re kernel-flavors
by Matt Sealey 15 Jan '09

15 Jan '09

I can't take it anymore. Development on a new kernel flavor is just so complicated and rife with little things to "take care of" which are simply hindering development and making life a misery of little mistakes, and forgetful actions, and even when something comes out right, building an RPM includes untarring 250MB of source code just to tell me the config is bad within the first 4 files compiled or so. The one thing that is really tiring me, though, is the layout of /usr/src/packages. In the way SUSE has it, kernel-source, kernel-flavor and every other thing installed from an SRPM install into exactly the same directory. This has some effects that are annoying me to some degree I am not comfortable with 1) broken packages which maintainers are unwilling to fix which blithely untar every *.tar.bz2 in /usr/src/packages/SOURCES (xorg-x11-libs!) 2) kernel-source, kernel-flavor SRPMS overwrite each other if they are installed. ARGH! 3) kernel-flavor .spec file is actually in SOURCES and not SPECS when it gets installed. WHAT? I really need to know, what kind of design decision is it that all RPMs get dumped into the same directory? Now, in a sane system like the /usr/share/doc/packages directory each package has it's basename in there. Each package is separate and self-contained. Docs for one do not go in the folder for docs for another.. :) Why was this never brought across to RPM builds? Is it because people are used to using build chroots and so on? Even in that scenario building a source RPM sort of requires the whole shebang to be in place right? What am I doing wrong here and how can I stop using /usr/src/packages for RPM development, and if this IS possible AND recommended, why does this method still even exist? If not doing anything wrong, why on earth can't we split RPM sources into their own package directories in /usr/src/packages like /usr/src/packages/kernel-source /usr/src/packages/kernel-whatever (yes of course it will duplicate files with the above but it's all compressed) /usr/src/packages/xorg-x11-libs etc.? -- Matt Sealey, Genesi, Manager Developer Relations -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

6 10

[opensuse-kernel] drives attached via OS11.0 sata_sil24 driver not mounted or seen
by PGNet 12 Jan '09

12 Jan '09

I've a PCI sata/multilane card (Sil 3124 chipset) installed in a x86_64 box running OS 11.0. After boot, I see no trace of the drives (sdc/sdd) in /dev, in Partitioner, or via 'fdisk -l'. However, booting from non-Suse OS, e.g., gParted LiveCD, all's fine -- I can see/mount, partition, manage the drives. This seems like a kernel/driver issue to me, but not at all certain. I've submitted a bug with more detail here, https://bugzilla.novell.com/show_bug.cgi?id=463829 I'm hoping for any additional 'exposure' on this list, if anyone can spare a moment ... Thanks. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 9

[opensuse-kernel] BIOS Upgrade Causes 10.3 Kernel To Use Only 1 Core
by Rob OpenSuSE 12 Jan '09

12 Jan '09

Dell Inspiron 531 which is an AMD 64 X2 5,600+ 2.8Hz box. It was certifed for SLE with Dell's 1.03 BIOS. The box is dual booted with Vista, for applications that are poorly supported under Linux so generally was following Dell recommendations on driver & firmware updates. In late November 2007, Dell were pushing an "urgent" BIOS upgrade 1.08, but the ACPI was compiled by M$ tool and 10.3's kernel couldn't see 2nd CPU, nor power off the machine on halt. Downgrading the BIOS bricked the mobo, when Vista glitched during the Flash process, and then actually forced a shutdown claiming piracy on an attempt to flash again! The M$ ACPI code was according to the word on the net, non-standard so it would seem to be a problem for Dell, as they'd had the machine certified for SLE. Dell replaced the mobo, sending an engineer. Trying the 1.12 BIOS, the ACPI issues are still present. But, the 2.6.27 11.1 kernel, does see both CPUs, power off, and have CPUFREQ stuff working to, and when looking into a bug report, I've been advised to be using the latest BIOS version. In long run, I want to migrate to 11.1 and it seems to be working. So it appears that the kernel has been enhanced or had a bug fix, to cope with these BIOS features. I haven't been following kernel changes closely enough to be sure the BIOS update works due to enhancements, rather than "luck". Could someone advise me, if I should be raising an issue with Dell, or if it makes more sense to move the kernel used by 10.3, to 2.6.27 (or 2.6.25?) as an interim solution? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0