January 2009 - openSUSE Kernel - openSUSE Mailing Lists

[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