May 2011 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] kernel-default-base-2.6.29-5.2.x86_64 rpm errors
by Dave Plater 18 Jul '24

18 Jul '24

Hi, I'm busy updating to the latest factory kernel and have received the following errors from kernel-default-base installation (I did insert a blank dvd during the installation of the rpm by zypper):- WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sd_mod.ko needs unknown symbol crc_t10dif WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol register_cdrom WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_ioctl WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_media_changed WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_get_media_event WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_release WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_open WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol unregister_cdrom WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_number_of_slots And then these errors which I think IIRC happened before when the kernel was first split into three:- Kernel image: /boot/vmlinuz-2.6.29-rc8-5-default Initrd image: /boot/initrd-2.6.29-rc8-5-default Root device: /dev/disk/by-id/ata-WDC_WD800JB-00JJC0_WD-WMAM9RA78067-part3 (/dev/sda3) (mounted on / as xfs) Resume device: /dev/disk/by-id/ata-WDC_WD800JB-00JJC0_WD-WMAM9RA78067-part2 (/dev/sda2) FATAL: Module processor not found. WARNING: no dependencies for kernel module 'processor' found. FATAL: Module thermal not found. WARNING: no dependencies for kernel module 'thermal' found. FATAL: Module ata_generic not found. WARNING: no dependencies for kernel module 'ata_generic' found. FATAL: Module piix not found. WARNING: no dependencies for kernel module 'piix' found. FATAL: Module ide_pci_generic not found. WARNING: no dependencies for kernel module 'ide_pci_generic' found. FATAL: Module fan not found. WARNING: no dependencies for kernel module 'fan' found. FATAL: Module xfs not found. WARNING: no dependencies for kernel module 'xfs' found. FATAL: Module usbhid not found. WARNING: no dependencies for kernel module 'usbhid' found. Kernel Modules: scsi_mod libata ata_piix edd ahci sd_mod usbcore ohci-hcd ehci-hcd uhci-hcd WARNING: /dev/shm/mkinitramfs.0drQsZ/mnt/lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sd_mod.ko needs unknown symbol crc_t10dif Features: block usb resume.userspace resume.kernel Bootsplash: openSUSE (1280x1024) 22669 blocks Should I open a bug report about the errors which are possibly from inserting a dvd while the kernel rpm was installing? Regards Dave P -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 2

[opensuse-kernel] [patch #2 0/5] scripts/sequence-patch.sh: Add some useful options
by Jeff Mahoney 05 Oct '11

05 Oct '11

Hi all - There are a few things I do every time I expand the source tree with sequence-patch.sh. Or, rather, things I should do and forget to do a lot. The first I always remember to do: Copy the config I want to test with to my build directory. The second I forget more often than not: Expand the kABI references into my build directory. One of the things that bites me occasionally is when there are kABI changes that go un-noticed until the automated build checker flags them and sends me an email yelling at me for my carelessness. This patch adds three options to scripts/sequence-patch.sh to take care of these automatically. --build-dir=PATH allows you to specify the build directory you'll be using. It will create the directory if it doesn't exist. It defaults to $PATCH_DIR. --config=ARCH-FLAVOR allows you to specify the config you'll use. It will copy the config to your build directory. It is not a fatal error if the config does not exist. It will just not copy one. --kabi allows you to direct sequence-patch to expand the kABI references into your build directory. Since the references are arch/flavor specific, it depends on --config=ARCH-FLAVOR. It is not a fatal error if the kABI reference doesn't exist since this is always the case in the master branch. The --build-dir PATH is subject to shell expansion. It is expanded late enough in the script that most variables should be available. There are also three new variables available when --config is used: $CONFIG contains the --config contents. $CONFIG_ARCH contains the arch part of the config. $CONFIG_FLAVOR contains the flavor part. For reference, I have this in my .bashrc: export SEQUENCE_PATCH_ARGS="--config=x86_64-desktop --build-dir=~/src/scratch/build/\$CONFIG_ARCH/linux-\$SRCVERSION-\$TAG-\$CONFIG_FLAVOR --kabi" I've also added patches for --ctags and --cscope which will automatically generate the databases for either of those tools in the build directory after the source tree is expanded. - Issues addressed in patchset #2: - Help text is now a here document for easy addition of more documentation - Explanation of which variables are allowed by --build-dir - Missing rpm/modversions script is not an error on older branches - Missing symvers files are not errors - Uses true/false for simple feature flags -Jeff -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

5 13

[opensuse-kernel] question on tcsetattr
by Andreas Jaeger 27 May '11

27 May '11

we have in glibc a patch that reverts this commit: 2003-02-20 Ulrich Drepper <drepper(a)redhat.com> * sysdeps/unix/sysv/linux/tcsetattr.c (tcsetattr): Remove obsolete patch to check for system call errors. I don't have a comment why the patch is needed. Both Fedora and us have the patch in their current glibc versions. Can any of you comment on whether we still need this with recent (2.6.32 or newer) kernels or not? Andreas Index: sysdeps/unix/sysv/linux/tcsetattr.c =================================================================== --- sysdeps/unix/sysv/linux/tcsetattr.c.orig +++ sysdeps/unix/sysv/linux/tcsetattr.c @@ -49,6 +49,7 @@ tcsetattr (fd, optional_actions, termios { struct __kernel_termios k_termios; unsigned long int cmd; + int retval; switch (optional_actions) { @@ -80,6 +81,35 @@ tcsetattr (fd, optional_actions, termios memcpy (&k_termios.c_cc[0], &termios_p->c_cc[0], __KERNEL_NCCS * sizeof (cc_t)); - return INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios); + retval = INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios); + + if (retval == 0 && cmd == TCSETS) + { + /* The Linux kernel has a bug which silently ignore the invalid + c_cflag on pty. We have to check it here. */ + int save = errno; + retval = INLINE_SYSCALL (ioctl, 3, fd, TCGETS, &k_termios); + if (retval) + { + /* We cannot verify if the setting is ok. We don't return + an error (?). */ + __set_errno (save); + retval = 0; + } + else if ((termios_p->c_cflag & (PARENB | CREAD)) + != (k_termios.c_cflag & (PARENB | CREAD)) + || ((termios_p->c_cflag & CSIZE) + && ((termios_p->c_cflag & CSIZE) + != (k_termios.c_cflag & CSIZE)))) + { + /* It looks like the Linux kernel silently changed the + PARENB/CREAD/CSIZE bits in c_cflag. Report it as an + error. */ + __set_errno (EINVAL); + retval = -1; + } + } + } + + return retval; -- Andreas Jaeger, Program Manager openSUSE aj(a){novell.com,suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 2

[opensuse-kernel] openSUSE Kernel: Push Patches Upstream
by Jeff Mahoney 26 May '11

26 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys - We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific. Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so? Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later. Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature - - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic [these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch Brandon Philips: - - patches.drivers/bnx2-entropy-source.patch - - patches.drivers/e1000-entropy-source.patch - - patches.drivers/e1000e-entropy-source.patch - - patches.drivers/igb-entropy-source.patch - - patches.drivers/ixgbe-entropy-source.patch - - patches.drivers/tg3-entropy-source.patch - - patches.drivers/tg3-5785-and-57780-asic-revs-not-working.patch - - patches.suse/uvcvideo-ignore-hue-control-for-5986-0241.patch Greg Haskins: - - patches.fixes/ia64-configure-HAVE_UNSTABLE_SCHED_CLOCK-for-SGI_SN.patch Greg KH: - - patches.suse/linux-2.6.29-dont-wait-for-mouse.patch - - patches.suse/linux-2.6.29-even-faster-kms.patch - - patches.suse/linux-2.6.29-kms-after-sata.patch - - patches.suse/linux-2.6.29-jbd-longer-commit-interval.patch - - patches.suse/linux-2.6.29-touchkit.patch Hannes Reinecke: (or James Bottomley) - - patches.suse/kbd-ignore-gfx.patch - - patches.fixes/scsi-inquiry-too-short-ratelimit - - patches.suse/scsi-netlink-ml - - patches.fixes/scsi-dh-queuedata-accessors - - patches.fixes/scsi-dh-alua-retry-UA - - patches.fixes/scsi-add-tgps-setting [disabled since 2.6.39] - - patches.fixes/scsi-dh-alua-send-stpg - - patches.fixes/scsi-dh-rdac-add-stk - - patches.fixes/scsi-retry-alua-transition-in-progress - - patches.fixes/scsi-check-host-lookup-failure - - patches.drivers/megaraid-mbox-fix-SG_IO - - patches.suse/scsi-error-test-unit-ready-timeout [Kurt] - - patches.fixes/scsi-scan-blist-update - - patches.suse/no-partition-scan [Is this even necessary since we boot with 'quiet' as default now?] - - patches.suse/dm-emulate-blkrrpart-ioctl - - patches.fixes/dm-mpath-reattach-dh - - patches.suse/dm-mpath-leastpending-path-update [Has this been replaced by dm-queue-length upstream?] - - patches.suse/dm-mpath-accept-failed-paths [disabled since 2.6.38] - - patches.suse/dm-mpath-detach-existing-hardware-handler [disabled since 2.6.38] - - patches.fixes/dm-table-switch-to-readonly - - patches.suse/dm-mpath-evaluate-request-result-and-sense [disabled since 2.6.39] - - patches.fixes/dm-release-map_lock-before-set_disk_ro [added by Nikanth] - - patches.suse/dm-mpath-no-activate-for-offlined-paths [and patches.suse/mpath-fix] - - patches.suse/dm-mpath-no-partitions-feature - - Jan Beulich: - - patches.fixes/bridge-module-get-put.patch Jan Kara: - - patches.suse/readahead-request-tunables.patch - - patches.suse/raw_device_max_minors_param.diff Jeff Mahoney: [deleted a bunch] - - patches.fixes/netfilter-implement-rfc-1123-for-ftp-conntrack - - patches.fixes/proc-scsi-scsi-fix.diff - - patches.fixes/flexcop-fix-registering-braindead-stupid-names - - patches.fixes/misdn-add-support-for-group-membership-check - - patches.suse/dm-raid45-26-Nov-2009.patch [Unsure what's happening here. It hasn't been updated in ages.] Jiri Benc: - - patches.suse/panic-on-io-nmi-SLE11-user-space-api.patch [disabled since 2.6.33] [does anyone even use the binary sysctl interface for this?] Jiri Bohac: - - patches.arch/x86_64-hpet-64bit-timer.patch [disabled since 2.6.33] - - patches.suse/netfilter-ip_conntrack_slp.patch Jiri Kosina: - - patches.drivers/elousb.patch - - patches.fixes/input-add-acer-aspire-5710-to-nomux.patch - - patches.fixes/hid-add-noget-quirk-for-symboltec.patch Jiri Slaby: - - patches.suse/wireless-no-aes-select - - patches.fixes/iwlwifi-fix-tx-power-configuration-on-3945-and-4965-devices Mel Gorman / Michal Hocko: - - patches.fixes/grab-swap-token-oops - - patches.suse/files-slab-rcu.patch - - patches.suse/mm-devzero-optimisation.patch [against SLES10, issue may not exist anymore] - - patches.suse/mm-devzero-optimisation.patch - - patches.fixes/aggressive-zone-reclaim.patch [disabled since 2.6.36] Neil Brown: - - patches.fixes/nfs-slot-table-alloc - - patches.fixes/nfsd-06-sunrpc-cache-retry-cache-lookups-that-return-ETIMEDO.patch [disabled since 2.6.37] Olaf Hering: - - patches.suse/led_classdev.sysfs-name.patch [ppc] - - patches.suse/radeon-monitor-jsxx-quirk.patch [ppc] - - patches.suse/8250-sysrq-ctrl_o.patch [ppc] - - patches.suse/led_classdev.sysfs-name.patch [ppc] - - patches.arch/ppc-pegasos-console-autodetection.patch [ppc] - - patches.suse/ppc-powerbook-usb-fn-key-default.patch [ppc] - - patches.drivers/ppc64-adb [ppc] - - patches.suse/suse-ppc64-branding [ppc] - - patches.arch/ppc64-xmon-dmesg-printing.patch [ppc] - - patches.arch/ppc-prom-nodisplay.patch [ppc] - - patches.fixes/ptrace-getsiginfo [technically schwab] [ppc] - - patches.fixes/scsi-ibmvscsi-show-config.patch - - patches.fixes/scsi-ibmvscsi-module_alias.patch - - patches.drivers/ehea-modinfo.patch Olaf Kirch: - - patches.fixes/remount-no-shrink-dcache - - patches.fixes/tulip-quad-NIC-ifdown - - patches.fixes/parport-mutex [This doesn't seem like the right fix - the driver looks like it needs help.] Oliver Neukum: - - patches.fixes/sd_liberal_28_sense_invalid.diff Rafael Wysocki: - - patches.arch/x86-mcp51-no-dac [rejected by Alan Cox, Mar 2009] - - patches.fixes/tg3-fix-default-wol.patch Suresh Jayaraman: - - patches.suse/sched-revert-latency-defaults [disabled since 2.6.33, after SLE11SP1] - - patches.suse/mm-tune-dirty-limits.patch [we may want to revisit per-flavor sysctl files] Takashi Iwai: - - patches.arch/ppc-ipic-suspend-without-83xx-fix [ppc] - - patches.arch/x86-hpet-pre-read [disabled since 2.6.37] - - patches.drivers/input-Add-LED-support-to-Synaptics-device - - patches.drivers/alsa-hda-0019-Increase-default-buffer-size Thomas Renninger: - - patches.arch/x86-apic-force-bigsmp-apic-on-IBM-EXA3-4.patch - - patches.arch/acpi_thinkpad_introduce_acpi_root_table_boot_param.patch - - patches.arch/acpi_thermal_passive_blacklist.patch - - patches.arch/acpi_fix_fadt_32_bit_zero_length.patch - - patches.arch/acpi_ec_provide_non_interrupt_mode_boot_param.patch [disabled since 2.6.32] - - patches.arch/acpi_srat-pxm-rev-store.patch - - patches.arch/acpi_srat-pxm-rev-ia64.patch - - patches.arch/acpi_srat-pxm-rev-x86-64.patch - - patches.fixes/acpi_ec_sys_access_user_space_with_get_user.patch - - patches.fixes/cpufreq_ondemand_performance_optimise_default_settings.patch - - patches.arch/perf_timechart_fix_zero_timestamps.patch - - patches.fixes/intel_idle_lapic_param.patch [less than two weeks old] - - patches.fixes/intel_idle_add_flush_tlb_param.patch [less than two weeks old] Tony Jones: - - patches.suse/kdump-dump_after_notifier.patch - - patches.fixes/oprofile_bios_ctr.patch [ Up for discussion ] - - patches.suse/file-capabilities-disable-by-default.diff [never submitted] - - patches.suse/connector-read-mostly - - patches.suse/ext3-barrier-default - - patches.suse/reiserfs-barrier-default - - patches.suse/SUSE-bootsplash Thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25pVEACgkQLPWxlyuTD7JC5gCdGl2k8d2PeHQVaF5WO5Yv25V+ PE8An07vC7R5YH5iJWHhKZUJDIzuVUHG =W1WH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

20 49

[opensuse-kernel] announcing kernel.opensuse.org
by Michal Marek 26 May '11

26 May '11

Hi, The opensuse kernel git trees have a new home at http://kernel.opensuse.org/?a=git . It should be more reliable than gitorious, which sometimes has problems cloning the nearly 1GB repository. We continue to sync to gitorious as well, so nothing should break for anyone. If you want to switch an existing clone to kernel.opensuse.org, however, it's as simple as git config remote.origin.url \ git://kernel.opensuse.org/kernel-source.git and analogously for the kernel.git repository. We will add more stuff to kernel.opensuse.org website in near future, next in the todo list is LXR and either gitweb or cgit. Have fun! Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

Fwd: Re: [opensuse-kernel] PATA devices being configured with wrong UDMA
by Basil Chupin 25 May '11

25 May '11

-------- Original Message -------- Subject: Re: [opensuse-kernel] PATA devices being configured with wrong UDMA Date: Mon, 23 May 2011 17:47:48 +1000 From: Basil Chupin <blchupin(a)iinet.net.au> To: opensuse-kernel(a)opensuse.org On 21/05/11 01:35, Jean Delvare wrote: > Hi Basil, > > Le vendredi 20 mai 2011 16:36, Basil Chupin a écrit : >> (Won't go into reasons, but it has to do with openSUSE and audio and >> pulseaudio and getting different results when installing the same copy >> of 11.4/KDE on the same system.......but let's not get into this one >> right now, OK? :-D .) > Don't tell me about sound and pulseaudio :( I won't ever again, I promise (until the next time) :-) . > More seriously, comparisons like this are very difficult to > establish, and are often biased by personal experience. > > Out of curiosity, did you try a different operating system on the > same hardware, to see if it was doing any better with UDMA speed > detection? I had no intention of this going into some sort of a bun-fight over what seems to be a simple matter - and I still have no intention of this going into such a state. I asked a simple question which was about what was the correct format to use in the "libata.force" statement to get both PATA channels working with an 80-wire cable; to show why I was asking the question I gave an extract from the boot.msg log file as well as making the comment that this hassle with the kernel incorrectly deciding that the machine was using a 40-wire cable has been known since at least 2008. I received from you the answer as to what was the correct format to use for this over-riding kernel parameter. Wonderful! But then the (unintended) "fight" started :-D . To save space and time what I deliberately omitted from my original post was that I had the following configuration a couple of weeks before I posted my question: PATA #1 : WD HD with UDMA 133 LG CDROM with UDMA 33 PATA #2: Seagate with UDMA 100 Pioneer DVD-RW UDMA 100 and the kernel was giving me the correct UDMA settings for PATA #1 (UDMA 133/33) [NOTE: 133/33] *without* any "libata fix" but I had to use "libata.force=2:80c" to get the correct UDMA set for PATA #2. This was all fine until I had to replace the LG CDROM (UDMA 33) with the new Pioneer DVD-RW which has UDMA 100. (And this one is for Stefan: NOTE that the UDMA was set correctly on PATA #1 *without* any "libata" fiddles for #1 - so, the chip is working fine, right?) When I did replace the LG CDROM on PATA #1 with a new Pioneer DVD-RW - so that I now had the Maxtor UDMA 133 with the DVD-RW UDMA 100 - the kernel decided that I had a 40-wire cable connected on PATA #1 and made both devices UDMA 33. PATA #2 was still correctly set (to 100/100) by the entry of "libata.force=2:80c".) This is when I posted my message of help for the correct format of the wording to get BOTH channels set to the correct UDMA by the kernel. Now, 2 things are associated with this: (1) how did I learn that the kernel required the fiddle of "libata.force=..."? because I searched the net and found many references to this problem but the one which gave me the most acceptable solution (others where to recompile the kernel after setting the appropriate parameter already existing in the kernel, and applying a patch to the kernel) was the one I found here: http://viktorbalogh.net/blog/other/libata-workaround-limited-to-udma33-due-… ; (2) why did I ask my question here and not in some "kernel upstream" list? I did so because there is a self-appointed "mail list cop" who inhabits opensuse help mail list and told me off for asking the question about KDE in the opensuse help list but which have been asked in the KDE mail list - which meant that "as good little soldier" I should ask my question about the kernel in *this* mail list to avoid the wrath of that "list cop" :-) . And, secondly, I don't know any "upstream kernel" list nor did I think that I needed to do so just to have a simple question about the correct wording format to use to get the "fix" working. My real problem was in adding my comments about this kernel problem being known for at least 3 years and for which I shall now go and put on my hair-shirt, kneel on a bed of hot ashes and flagellate myself for......oh, I don't know - perhaps several nano seconds or so? :-) . Lastly, you asked if I had this hassle on other distros. The answer is YES - and at least one uses a more up-to-date version of the kernel (eg, Ubuntu). In all cases the only "libata fix" I had to use was to set PATA #2 to be correct, because I still had the LG CDROM on PATA #1 and the UDMA for devices on PATA #1 were being set correctly. However, since getting the new RW on #1 I have not used the other distros so cannot say what the results would be if I did. (I wouldn't be having this drawn out discussion to justify my results/question if I hadn't had to replace the LG CDROM on PATA #1 with the Pioneer DVD-RW :'( . But life wouldn't be so interesting without such little PITAs, would it? :-D ) BC -- "The time has been That, when the brains were out, the man would die," "Macbeth", Shakespeare -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

4 3

[opensuse-kernel] kernel-firmware package wierdness
by Greg KH 24 May '11

24 May '11

In openSUSE:Tumbleweed we have the latest kernel-firmware package, which should be something like kernel-firmware-20101214 or so. But something else is generating the package, kernel-firmware-2.6.38-34.2.noarch which should be older and not used anymore. It's odd that the kernel version number shows up here as well. I can't seem to figure out what is doing this, anyone have any ideas? confused, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 5

[opensuse-kernel] Kernel:v2.6.35 -- delete?
by Jiri Slaby 23 May '11

23 May '11

Hi, while I was looking at the Kernel:* repositories, I spotted there is v2.6.35 kernel. It seems to be broken and quite outdated. So in fact, it only wastes the BS power. I think the repository should be deleted. What do you think? Is there anything why it is preserved? thanks, -- js suse labs -- 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] Kernel Logs
by Günther J. Niederwimmer 21 May '11

21 May '11

Hello, is this a normal Log in the last Kernels? ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A I have a lot of this in my Log files -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

5 6

[opensuse-kernel] PATA devices being configured with wrong UDMA
by Basil Chupin 20 May '11

20 May '11

I am running 32-bit openSUSE 11.4 (have both KDE and Gnome installed on separate sets of HDs); installed as fresh installations. The kernel used is the one installed by 11.4. I am using both ATA controllers each with same model HDs and same model DVDRWs sitting on 80-wire cables and set for Cable Select. Before I do a "fiddle" - see below - the HDs and the DVDRWs on both channels are set during boot to UDMA 33 because the kernel decides that I am using a 40-wire cable on each controller. I found a reference going back to 2008 that this is a known problem in the kernel and that adding "libata.force=X:80c" to the kernel parameters in menu.lst works around this annoyance. Putting in "libata.force=1:80c" gives me the correct UDMAs for what is on controller #1 but what is on #2 is set to UDMA 33. So I put in "libata.force=1,2:80c" 'cause I read that one uses a comma as a separator in such "libata" statement but this don't work and only the second controller is configured correctly :-( . Here is an extract from boot.msg showing this: 1.482242] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14 1.482246] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15 1.617516] usb 2-1: New USB device found, idVendor=03f0, idProduct=bb02 1.617520] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 1.617523] usb 2-1: Product: Photosmart 8400 series 1.617525] usb 2-1: Manufacturer: HP 1.617527] usb 2-1: SerialNumber: CN52N211850469 1.620813] scsi2 : usb-storage 2-1:1.2 1.688318] ata1.00: HPA unlocked: 490232639 -> 490234752, native 490234752 1.688324] ata1.00: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133 <===========XXXXXXXXXXXXXX 1.688328] ata1.00: 490234752 sectors, multi 16: LBA48 1.688335] ata1.01: ATAPI: PIONEER DVD-RW DVR-118L, 1.02, max UDMA/100 <======XXXXXXXXXXXXXX 1.688344] ata1: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000 (0xc7c6c7c6) ACPI=0x7f01f (15:20:0x1f) 1.688347] ata1.00: limited to UDMA/33 due to 40-wire cable 1.688352] ata1: nv_mode_filter: 0x3f39f&0x3f39f->0x3f39f, BIOS=0x3f000 (0xc7c6c7c6) ACPI=0x3f01f (15:20:0x1f) 1.688355] ata1.01: limited to UDMA/33 due to 40-wire cable 1.695812] ata1.00: configured for UDMA/33 <==============XXXXXXXXXXXXXX 1.717242] ata1.01: configured for UDMA/33 <==============XXXXXXXXXXXXXX 1.717784] scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250R0 BAH4 PQ: 0 ANSI: 5 1.721008] sd 0:0:0:0: [sda] 490234752 512-byte logical blocks: (251 GB/233 GiB) 1.721070] scsi 0:0:1:0: CD-ROM PIONEER DVD-RW DVR-118L 1.02 PQ: 0 ANSI: 5 1.721335] sd 0:0:0:0: [sda] Write Protect is off 1.721339] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 1.721368] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA 1.808862] sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 > 1.809367] sd 0:0:0:0: [sda] Attached SCSI disk 1.878316] ata2: FORCE: cable set to 80c <=============ZZZZZZZZZZZZZZZZZZZ 1.879907] ata2.00: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133 <===ZZZZZZZZZZZZZZZZZZZ 1.879910] ata2.00: 490234752 sectors, multi 16: LBA48 1.879917] ata2.01: ATAPI: PIONEER DVD-RW DVR-118L, 1.02, max UDMA/100 <==ZZZZZZZZZZZZZZZZ 1.879925] ata2: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000 (0xc7c6c7c6) ACPI=0x7f01f (15:20:0x1f) 1.879930] ata2: nv_mode_filter: 0x3f39f&0x3f39f->0x3f39f, BIOS=0x3f000 (0xc7c6c7c6) ACPI=0x3f01f (15:20:0x1f) 1.881012] usb 2-2: new low speed USB device using ohci_hcd and address 3 1.887783] ata2.00: configured for UDMA/133 <===========ZZZZZZZZZZZZZZZ 1.909241] ata2.01: configured for UDMA/100 <===========ZZZZZZZZZZZZZZZ Could someone please tell me what the correct words to use to get both all the devices configured with the correct UDMA? Perhaps there is another way of doing this other than what was provided way back 3 years ago? (Such a bug in the kernel still around after 3 years?) BTW, HDPARM for /dev/sda and sdb supports the results shown above in boot.msg BC -- "The older the violin the sweeter the music." -- 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] osc build spec - with a new config question?
by Greg Freemyer 13 May '11

13 May '11

All, I'm trying to patch in a new module for my testing. osc build is failing both on OBS and locally because the config question is unexpected How do I pre-answer that question? === log of failure The Extended 4 (ext4) filesystem (EXT4_FS) [M/n/y/?] m Ext4 extended attributes (EXT4_FS_XATTR) [Y/n/?] y Ext4 POSIX Access Control Lists (EXT4_FS_POSIX_ACL) [Y/n/?] y Ext4 Security Labels (EXT4_FS_SECURITY) [Y/n/?] y EXT4 debugging support (EXT4_DEBUG) [N/y/?] n EXT4 snapshots (Experimental) (EXT4_FS_SNAPSHOT) [N/y/?] (NEW) aborted! Console input/output is redirected. Run 'make oldconfig' to update configuration. make[2]: *** [silentoldconfig] Error 1 make[1]: *** [silentoldconfig] Error 2 make: *** [sub-make] Error 2 make: Leaving directory `/usr/src/packages/BUILD/kernel-desktop-2.6.38.5/linux-2.6.38' error: Bad exit status from /var/tmp/rpm-tmp.qOSXbc (%prep) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.qOSXbc (%prep) The buildroot was: /var/tmp/build-root ======== Greg -- 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] Retrieving patch rejects file from OBS
by Greg Freemyer 12 May '11

12 May '11

All, re: Adding ext4+ snapshots capability to a branched 2.6.38 kernel I branched 2.6.38.5 from Tumbleweed. home:next4 : next4-devel > kernel-source I've attempted to add a large patch to my project, but it is not applying: == from the build log + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /usr/src/packages/BUILD/kernel-source-2.6.38.5/patches.ext4+/ext4_snapshot.patch 1 out of 74 hunks FAILED -- saving rejects to file fs/ext4/inode.c.rej 1 out of 33 hunks FAILED -- saving rejects to file fs/ext4/super.c.rej == Is there an easy way to get those to rej files out of OBS. Or do I have to figure out how to do a full local kernel build? (Since the source package is not building, that doesn't seem trivial.) Thanks Greg -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 8

[opensuse-kernel] Kernel:/stable/* repos
by Brian K. White 10 May '11

10 May '11

What happened to http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_11.2 http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_11.3 http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_11.4 The rpm's are gone ? -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 13

[opensuse-kernel] kernel-syms recommend instead of require kernel-*-devel?
by Stefan Seyfried 10 May '11

10 May '11

Hi, while upgrading my kernel to 2.6.39-rc6 (thanks, that will hopefully fix bnc#687998 for me), I found that zypper did not want to update kernel-syms et al due to missing kernel-xen-devel. I then selected "break kernel-syms by ignoring some deps" and "remove kernel-xen-devel". I know that I'll probably never need kernel-xen-devel (because I have perfectly fine Hardware, capable of KVM, there is no need to have a XEN kernel running on it), so it would be nice to save the download bandwidth and disk space of all those unnecessary kernel-*-devel by making them "recommended" instead of "required" IMHO. Opinions? -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 2

[opensuse-kernel] Is hiding the build host really needed?
by Jeff Mahoney 08 May '11

08 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - For quite some time we've carried a patch to obscure the build host in /proc/version so that it's always the same. It will always show up as (geeko@buildhost), even if it's not actually built for distribution. I looked at Ubuntu and Fedora, and they don't bother to obscure it. Is there any reason we should carry this patch indefinitely if nobody else bothers? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3EgkkACgkQLPWxlyuTD7KFjwCgh5DzvykRtyVC/Eh52GFm9Vh8 QukAnjVBkDlpBDFOPgxW3yY4vPTQFcGC =5iZQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

4 5

[opensuse-kernel] [PATCH] Add support for per-kernel sysctl.conf files
by Jeff Mahoney 06 May '11

06 May '11

This patch adds support for per-kernel sysctl.conf files installed in /boot/sysctl.conf-$(uname -r). Since we don't really want to maintain yet another tree of mostly identical files, I implemented simple inheritance. The order of operation is, for flavor x86_64-desktop: - sysctl/defaults - sysctl/x86_64/arch-defaults - sysctl/x86_64/desktop I didn't bother implementing filtering, so using the example files below: - All flavors will get kernel.hung_task_timeout=0. - All x86_ flavors will also get vm.dirty_ratio=40. - x86-desktop will /also/ get vm.dirty_ratio=20. Since the sysctl lines are processed and overridden in order, this is fine. I have a separate (simple) patch to boot.sysctl to implement that part of it. Signed-off-by: Jeff Mahoney <jeffm(a)suse.com> --- rpm/kernel-binary.spec.in | 4 ++++ rpm/kernel-source.spec.in | 1 + scripts/tar-up.sh | 20 ++++++++++++++++++++ sysctl/defaults | 1 + sysctl/x86_64/arch-defaults | 1 + sysctl/x86_64/desktop | 1 + 6 files changed, 28 insertions(+), 0 deletions(-) diff --git a/rpm/kernel-binary.spec.in b/rpm/kernel-binary.spec.in index 3a82dee..9bed9a9 100644 --- a/rpm/kernel-binary.spec.in +++ b/rpm/kernel-binary.spec.in @@ -452,6 +452,10 @@ ln -s $image$suffix %buildroot/boot/$image$suffix ln -s initrd$suffix %buildroot/boot/initrd$suffix cp -p .config %buildroot/boot/config-%kernelrelease-%build_flavor +if [ -f %my_builddir/sysctl/%cpu_arch_flavor ]; then + cp -p %my_builddir/sysctl/%cpu_arch_flavor \ + %buildroot/boot/sysctl.conf-%kernelrelease-%build_flavor +fi %if %install_vdso # Install the unstripped vdso's that are linked in the kernel image diff --git a/rpm/kernel-source.spec.in b/rpm/kernel-source.spec.in index 6560706..1156d2a 100644 --- a/rpm/kernel-source.spec.in +++ b/rpm/kernel-source.spec.in @@ -101,6 +101,7 @@ Source111: patches.rt.tar.bz2 Source112: patches.trace.tar.bz2 Source113: patches.kabi.tar.bz2 Source120: kabi.tar.bz2 +Source121: sysctl.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-build BuildArch: noarch Prefix: /usr/src diff --git a/scripts/tar-up.sh b/scripts/tar-up.sh index ffa4532..7ee43f3 100755 --- a/scripts/tar-up.sh +++ b/scripts/tar-up.sh @@ -311,6 +311,26 @@ done echo "kabi.tar.bz2" stable_tar $build_dir/kabi.tar.bz2 kabi +echo "sysctl.tar.bz2" +for config in $(scripts/guards --list < config.conf); do + arch=${config%%/*} + flavor=${config##*/} + + mkdir -p $tmpdir/sysctl/$arch + for file in sysctl/defaults sysctl/$arch/arch-defaults \ + sysctl/$arch/$flavor; do + if [ -f "$file" ]; then + cat $file + fi + done > $tmpdir/sysctl/$arch/$flavor +done + +# We don't need to ship empty files or directories +find $tmpdir/sysctl -size 0 -exec rm -f {} \; +rmdir $tmpdir/sysctl/* 2> /dev/null + +stable_tar -C $tmpdir $build_dir/sysctl.tar.bz2 sysctl + # Create empty dummys for any *.tar.bz2 archive mentioned in the spec file # not already created: patches.addon is empty by intention; others currently # may contain no patches. diff --git a/sysctl/defaults b/sysctl/defaults new file mode 100644 index 0000000..ac9d6d9 --- /dev/null +++ b/sysctl/defaults @@ -0,0 +1 @@ +kernel.hung_task_timeout=0 diff --git a/sysctl/x86_64/arch-defaults b/sysctl/x86_64/arch-defaults new file mode 100644 index 0000000..b6f94d4 --- /dev/null +++ b/sysctl/x86_64/arch-defaults @@ -0,0 +1 @@ +sys.vm.dirty_ratio=40 diff --git a/sysctl/x86_64/desktop b/sysctl/x86_64/desktop new file mode 100644 index 0000000..ef6e377 --- /dev/null +++ b/sysctl/x86_64/desktop @@ -0,0 +1 @@ +sys.vm.dirty_ratio=20 -- Jeff Mahoney SUSE Labs -- 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] Crash with disk destroy
by Günther J. Niederwimmer 05 May '11

05 May '11

Hello, Is it possible to find this Problem in the Kernel ? openSUSE 11.4 when I like to change to console "Strg+Alt+F?" in the most time my system have a total crash with disk destroy? Only possible way is a "reset" After the restart I have a long list of "Inode" reconstruct entries from my "home" Partition ( /dev/md126p9) My System is a full Disk Raid 1 (Intel Board) -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 1

[opensuse-kernel] RFC: Use tarballs for -rc and stable releases?
by Michal Marek 04 May '11

04 May '11

Hi, currently, -rc and stable release updates are done by adding patches to patches.kernel.org/. Especially the -rc1 patches are *huge* and cannot be paired with any other object in the repository, so their gzip-compressed size adds to the total repository size: $ git cat-file -p b9044e3353ff21f12a86788a18cf36ba1071b6ab:patches.kernel.org/patch-2.6.37-rc1 | gzip -c -9 | wc -c 14627847 that is almost 14 megabytes. So I would like to propose to more or less discontinue patches.kernel.org and instead use the SRCVERSION variable in rpm/config.sh. This is already used in the vanilla and linux-next branches and it works. Code changes are more easily reviewed in the kernel.git nowadays, tar-up.sh and sequence-patch also work if you don't have the tarball around (it generates one from git, which is arguably slower, but works), so I think it's worth doing it. Opinions? Michal -- 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] GCC 4.6 for 12.1
by Jeff Mahoney 02 May '11

02 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - I know someone else mentioned this briefly WRT to Tumbleweed, but I'd like to bring up for discussion the adoption of gcc 4.6 for Factory. A bit of background. We currently maintain a kernel-trace flavor to allow people to make use of the tracing facilities. Historically, there has been overhead associated with these, which is why they were in their own flavor. Most users don't care about them, so there's no sense in slowing everyone down to satisfy them. Over time, the maintainers of these facilities have worked to lower the overhead to the point where now dynamic ftrace only adds memory overhead. It uses gcc's profiling facility to call out to a function at the beginning of every function call to allow tracking. At boot, this is a function that returns immediately but during the boot process those calls are hot-patched to nop operations so that they carry virtually zero runtime overhead. This sounds great, right? There's one last bit, and that is actually the reason why ftrace is still disabled in our regular kernel flavors. The compiler's profiling feature calls the profiling function after the function prologue. That means that the stack pointer has already been advanced and since it can advance a different amount based on the needs of each function, we don't have an easy way to get the caller's stack frame back. It's needed to resolve where the caller was called from and the only way to do that is to dedicate a register to track the start of the current stack frame. Dedicating a register for this increases register contention and forces more accesses to CPU cache or main memory, slowing everything down. So, it's not worth it when most users will never actually take advantage of the feature that requires it. For some time, I've been trying to come up with ways to work around this so that the fast path stays fast and the tracing path takes any performance hit necessary. Until recently, the performance hit would've been too big to make it worthwhile. With gcc 4.6, we have the -mfentry option which moves the call to the profiling function *before* the function's prologue. This means that the caller's stack frame is still intact and we can resolve the caller's parent without issue. I've spent the past few days working up a proof of concept that takes advantage of this and doesn't require a dedicated register. It turns out that Steven Rostedt has already posted a patch set to do exactly this and he's targeting 2.6.40 for inclusion in the mainline kernel. For now it looks like it's x86-64 only but it should be ok for i386 as well. This would go a long way to eliminate the -trace flavor from our kernel packages. The benefits are multiple: It eliminates the maintenance of another kernel flavor, but it also allows everyone to use tracing facilities without installing a separate kernel release to do so. One last bit is needed, though, and that is for gcc to allow using -pg - -mfentry with -fomit-frame-pointers. Once that bit is taken care of then we can rid the kernel of the frame pointer requirement for ftrace and eliminate the -trace flavor entirely. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk263RwACgkQLPWxlyuTD7JhyQCfXcCcDjH0dYmnoguTCe+7J2FH YWkAn3+K1qintX3acivGSmUYCDVnDuqi =3BMz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

8 13

[opensuse-kernel] A libre version of the kernel to openSUSE
by José Luis Maqueda 01 May '11

01 May '11

Hi. I am working to package a libre version of the kernel to openSUSE. I use a clean tarball of Linux-libre project [ http://linux-libre.fsfla.org/ ] I invite others to collaborate. This is a repo: http://download.opensuse.org/repositories/home:/maquedam:/ And my OBS project: https://build.opensuse.org/project/show?project=home%3Amaquedam%3AKernel-li… Regards! -- José Luis A tlamaki (libre) developer. :-) http://hackers.tlamaki.org/author/joseluis/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0