July 2008 - kernel - Fedora mailing-lists

When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
by Thorsten Leemhuis 06 Aug '08

06 Aug '08

Hi all John (CCed), I really appreciate your work in the wireless area and would like to use the opportunity to say "thanks for all you work", as support for WLAN hardware in the Linux kernel improved a lot in the upstream kernel and Fedora thx to your (and other linux wireless developers) work over the last two years. But we now for at least the second time in the past few weeks had/have a more-than-minor wireless breakage in a Fedora kernel for a released distro (bug #453390 now; http://lwn.net/Articles/286558/ is discussing the one some weeks ago; I think there was one more breakage not that long ago, but I can't remember). I and many users (see for example #453390) got hit by those problems. That's why I was wondering: what are we at Fedora doing to prevent similar problems in the future? Three things spring to my mind and I just propose then here for discussion; maybe something good comes out of it in the end: - a karama of "+3" in bodhi seems not enough for a auto-move from testing to stable (or even worse: straight to stable if enough people tested the kernel and gave their +1 after the update got filed in bodhi but *before* it actually hit fedora-testing) if there are no other pressing issues (like security fixes). The kernel is a to complex beast; more then 3 people should be needed to give a +1. And a bit of time needs to pass to give enough people the opportunity to install, test and report problems with new kernels. For the latest kernel it seems to me that "to less time" really was the problem, otherwise the problem from #453390 would have been noticed earlier - should we separate security updates and other kernel fixes in a better way to make sure those "other fixes" get proper testing before they get send out to the users? - John, having all those pending and not-yet-upstream-merged improvements for wireless hardware in the Fedora kernel was something good in the past when WLAN support in the kernel was quite bad/incomplete. But the main and most important bits for proper wireless hardware support seem to be in the upstream kernel now; sure, there will always be improvements in the queue, but that's the same in most other linux subsystems with drivers as well. So I'm wondering: isn't it time now to finally stop shipping all those wireless-next bits (currently quite some big patches; see: -rw-rw-r-- 1 thl thl 2484 14. Mär 17:06 linux-2.6-ms-wireless-receiver.patch -rw-rw-r-- 1 thl thl 39874 4. Jul 22:21 linux-2.6-wireless-fixups.patch -rw-rw-r-- 1 thl thl 2656652 4. Jul 22:21 linux-2.6-wireless-pending.patch -rw-rw-r-- 1 thl thl 4165718 4. Jul 22:21 linux-2.6-wireless.patch ) in released Fedora Version (e.g. 8 and 9 currently) when we start shipping 2.6.26? Just my 2 cent. Cu knurd

9 14

[PATCH] kernel.spec: adding --with firmware & --without vdso_install build options
by Steve Dickson 05 Aug '08

05 Aug '08

Now that devel kernels rpms require the kernel-firmware rpm, it makes sense to me that one should be able to build both of them at the same time. So this patch adds the "--with firmware" build option which will allow kernel-firmware rpms to built with kernel rpms. This patch also adds the "--without vdso_install" build option which stop the VDSO binaries from being installed. This cuts down the overall build time especially when you build over NFS like I do.. Signed-Off-By: Steve Dickson <steved(a)redhat.com> diff -up SPECS/kernel.spec.orig SPECS/kernel.spec --- SPECS/kernel.spec.orig 2008-07-29 09:07:48.000000000 -0400 +++ SPECS/kernel.spec 2008-07-29 11:44:39.000000000 -0400 @@ -75,11 +75,13 @@ Summary: The Linux kernel # kernel-headers %define with_headers %{?_without_headers: 0} %{?!_without_headers: 1} # kernel-firmware -%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1} +%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0} # kernel-debuginfo %define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1} # kernel-bootwrapper (for creating zImages from kernel + initrd) %define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper: 1} +# Want to build a the vsdo directories installed +%define with_vdso_install %{?_without_vdso_install: 0} %{?!_without_vdso_install: 1} # don't build the kernel-doc package %define with_doc 0 @@ -188,8 +190,10 @@ Summary: The Linux kernel %define all_x86 i386 i586 i686 +%if %{with_vdso_install} # These arches install vdso/ directories. %define vdso_arches %{all_x86} x86_64 ppc ppc64 +%endif # Overrides for generic default options @@ -217,7 +221,6 @@ Summary: The Linux kernel # only package docs noarch %ifnarch noarch %define with_doc 0 -%define with_firmware 0 %endif # no need to build headers again for these arches, @@ -231,6 +234,7 @@ Summary: The Linux kernel %define with_up 0 %define with_headers 0 %define all_arch_configs kernel-%{version}-*.config +%define with_firmware 1 %endif # bootwrapper is only on ppc

4 8

perfmon2 on fedora kernels
by Ted Sume Nzuonkwelle 31 Jul '08

31 Jul '08

Hi, My apologies if this is going to the wrong mailing list. Is there an easy way to enable support for perfmon2 in the fedora 9 kernel(s)? Looks like the patch for perfmon2 available at http://sourceforge.net/projects/perfmon2/ is only useful if patching a vanilla kernel? Any help and/pointers will be greatly appreciated. Thanks. - Ted Sume

4 3

[patch 3/3] Have kernel-PAE.i686 and kernel.x86_64 fix DEFAULTKERNEL=kernel-xen
by Mark McLoughlin 30 Jul '08

30 Jul '08

plain text document attachment (kernel-xen-defaultkernel.patch) Now we can fix: https://bugzilla.redhat.com/456558 by having kernel.x86_64 and kernel-PAE.i686 munge DEFAULTKERNEL as appropriate. Use sed --regexp-extended so we don't have to do "$foo\|bar$" Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-30 15:50:27.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-30 15:50:27.000000000 +0100 @@ -1565,7 +1565,7 @@ fi\ %{-r:\ if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\ [ -f /etc/sysconfig/kernel ]; then\ - /bin/sed -i -e 's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/' /etc/sysconfig/kernel || exit $?\ + /bin/sed -r -i -e 's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/' /etc/sysconfig/kernel || exit $?\ fi}\ /sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod --install %{KVERREL}%{?-v:.%{-v*}} || exit $?\ #if [ -x /sbin/weak-modules ]\ @@ -1588,18 +1588,22 @@ fi}\ %{nil} %kernel_variant_preun +%ifarch x86_64 +%kernel_variant_post -r (kernel-smp|kernel-xen) +%else %kernel_variant_post -r kernel-smp +%endif %kernel_variant_preun smp %kernel_variant_post -v smp %kernel_variant_preun PAE -%kernel_variant_post -v PAE -r kernel-smp +%kernel_variant_post -v PAE -r (kernel-smp|kernel-xen) %kernel_variant_preun debug %kernel_variant_post -v debug -%kernel_variant_post -v PAEdebug -r kernel-smp +%kernel_variant_post -v PAEdebug -r (kernel-smp|kernel-xen) %kernel_variant_preun PAEdebug if [ -x /sbin/ldconfig ] --

1 0

[patch 2/3] Add kernel_%{variant}_replaces macros
by Mark McLoughlin 30 Jul '08

30 Jul '08

plain text document attachment (kernel-variant-post-kill-replace-arg.patch) The -r arg is redundant because we already now the variant name so we can use kernel%{?-v:-%{-v*}} instead. So, rename the -s arg to -r and drop the existing meaning of -r. Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-30 14:15:15.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-30 14:15:15.000000000 +0100 @@ -1555,17 +1555,17 @@ fi\ # # This macro defines a %%post script for a kernel package and its devel package. -# %%kernel_variant_post [-v <subpackage>] [-s <s> -r <r>] +# %%kernel_variant_post [-v <subpackage>] [-r <replace>] # More text can follow to go at the end of this variant's %%post. # -%define kernel_variant_post(s:r:v:) \ +%define kernel_variant_post(v:r:) \ %{expand:%%kernel_devel_post %{?-v*}}\ %{expand:%%kernel_variant_posttrans %{?-v*}}\ %{expand:%%post %{?-v*}}\ -%{-s:\ +%{-r:\ if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\ [ -f /etc/sysconfig/kernel ]; then\ - /bin/sed -i -e 's/^DEFAULTKERNEL=%{-s*}$/DEFAULTKERNEL=%{-r*}/' /etc/sysconfig/kernel || exit $?\ + /bin/sed -i -e 's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/' /etc/sysconfig/kernel || exit $?\ fi}\ /sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod --install %{KVERREL}%{?-v:.%{-v*}} || exit $?\ #if [ -x /sbin/weak-modules ]\ @@ -1588,18 +1588,18 @@ fi}\ %{nil} %kernel_variant_preun -%kernel_variant_post -s kernel-smp -r kernel +%kernel_variant_post -r kernel-smp %kernel_variant_preun smp %kernel_variant_post -v smp %kernel_variant_preun PAE -%kernel_variant_post -v PAE -s kernel-smp -r kernel-PAE +%kernel_variant_post -v PAE -r kernel-smp %kernel_variant_preun debug %kernel_variant_post -v debug -%kernel_variant_post -v PAEdebug -s kernel-smp -r kernel-PAEdebug +%kernel_variant_post -v PAEdebug -r kernel-smp %kernel_variant_preun PAEdebug if [ -x /sbin/ldconfig ] --

1 0

[patch 1/3] Remove flag args from kernel_variant_posttrans
by Mark McLoughlin 30 Jul '08

30 Jul '08

plain text document attachment (kernel-variant-posttrans-cleanup-args.patch) kernel_variant_posttrans only takes a single arg, so don't bother using flag arguments since they're a bit more confusing. Note that the macro invocation didn't actually pass it a flag arg, but it seemed to have access to the calling macros flag args anyway. Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-30 13:32:44.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-30 13:32:44.000000000 +0100 @@ -1527,7 +1527,7 @@ rm -rf $RPM_BUILD_ROOT # # This macro defines a %%post script for a kernel*-devel package. -# %%kernel_devel_post <subpackage> +# %%kernel_devel_post [<subpackage>] # %define kernel_devel_post() \ %{expand:%%post %{?1:%{1}-}devel}\ @@ -1545,12 +1545,12 @@ fi\ %{nil} # This macro defines a %%posttrans script for a kernel package. -# %%kernel_variant_posttrans [-v <subpackage>] [-s <s> -r <r>] +# %%kernel_variant_posttrans [<subpackage>] # More text can follow to go at the end of this variant's %%post. # -%define kernel_variant_posttrans(s:r:v:) \ -%{expand:%%posttrans %{?-v*}}\ -/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{KVERREL}%{?-v:.%{-v*}} || exit $?\ +%define kernel_variant_posttrans() \ +%{expand:%%posttrans %{?1}}\ +/sbin/new-kernel-pkg --package kernel%{?1:-%{1}} --rpmposttrans %{KVERREL}%{?1:.%{1}} || exit $?\ %{nil} # --

1 0

linux-2.6-build-nonintconfig.patch rebase
by Roland McGrath 28 Jul '08

28 Jul '08

Running rebase.sh was so much fun that I for some reason decided to do Dave's job today and once I'd run it then I had to cope with the kconfig changes upstream. I hacked linux-2.6-build-nonintconfig.patch and is seems to be about right again. But I never did try to really understand that code. Someone ought to look at it. The headers_check magic changed, so the .spec kludge broke. Running it normally instead of using the innards seemed right to me. They seem to keep breaking stuff upstream, so the last iteration probably didn't build either. I bet upstream will fix the installing /usr/include/.install et al before long, and then the find | xargs rm I added can go. Thanks, Roland

1 0

USB serial device trying to register wrong tty device after usb_reset_device
by amruth 27 Jul '08

27 Jul '08

Hi All > I connected 2 serial devices based on TI 3410 chipset, > which downloads firmware and the system resets using > usb_reset_device. The problem is after the adding the second > device, the system downloads firmware, usb_reset_device is > called similar to first one, but now the USB reenumerates. > Does the first device which has been allocated ttyUSB0 > disappear. I have seen that the first device ttyUSB0 does > not disappear. > The system is trying to re register the 2nd device with > ttyUSB0 which is not correct.Why does the kernel detect that > ttyUSB0 is already claimed by 1st device. The code snippet > from usb-serial.c is below. > > if (get_free_serial (serial, num_ports, &minor) == > NULL) { > dev_err(&interface->dev, "No > more free serial devices\n"); > goto probe_error; > } > serial->minor = minor; > > Why does not get_free_serial return 1 instead of 0 because > 0 is climed by 1st device. > > snprintf (&port->dev.bus_id[0], > sizeof(port->dev.bus_id), "ttyUSB%d", > port->number); > dbg ("%s - registering %s", > __FUNCTION__, port->dev.bus_id); > retval = > device_register(&port->dev); > if (retval) > dev_err(&port->dev, > "Error registering port device, " > > "continuing\n"); > > > > Is there any workaround to find that the 1st device is > already claimed, so that register try to register with 2nd > device and create ttyUSB1. > Please let me know if anybody encountered this issue. > Thanks > Amruth p.v > > > --- On Sat, 7/26/08, amruth <amruth_pv(a)yahoo.com> > wrote: > > > From: amruth <amruth_pv(a)yahoo.com> > > Subject: 2.6.26 kernel crashes after hotplugging 2nd > device of same type > > To: linux-usb(a)vger.kernel.org > > Date: Saturday, July 26, 2008, 1:23 AM > > Hi > > All > > The system crashes after connecting multiple serial > devices > > based on ti usb 3410 chipset of same type. > > > > The detailed log is below. The kernel is 2.6.26. > > > > Please suggest any ideas what is going on.Do we have > any > > workaround for this issue. > > > > Do the kernel allow multiple devie to register. > > > > If the first device was assigned ttyUSB0, then why > does the > > 2nd device try to register with same ttyUSB0. How does > > ttyUSB ids assigned in the kernel. > > > > > > usb 2-2: reset full speed USB device using uhci_hcd > and > > address 5 > > usb 2-2: device firmware changed > > usb 2-2: USB disconnect, address 5 > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_shutdown > > ti_usb_3410_5052 2-2:1.0: device disconnected > > usb 2-2: new full speed USB device using uhci_hcd and > > address 6 > > usb 2-2: configuration #1 chosen from 2 choices > > ti_usb_3410_5052 2-2:1.0: TI USB 3410 1 port adapter > > converter detected > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_startup - product 0x 8, num configurations 2, > > configuration value 1 > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_startup - device type is 3410 > > ti_usb_3410_5052: probe of 2-2:1.0 failed with error > -5 > > ti_usb_3410_5052 2-2:2.0: TI USB 3410 1 port adapter > > converter detected > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_startup - product 0x 8, num configurations 2, > > configuration value 2 > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_startup - device type is 3410 > > usb-serial ttyUSB0: Error registering port device, > > continuing > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_shutdown > > BUG: unable to handle kernel NULL pointer dereference > at > > 00000018 > > IP: [<c04a2215>] sysfs_find_dirent+0x4/0x23 > > *pde = 0e975067 *pte = 00000000 > > Oops: 0000 [#1] SMP > > Modules linked in: ti_usb_3410_5052 usbserial autofs4 > hidp > > rfcomm l2cap bluetooth sunrpc iptable_filter ip_tables > > ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables > x_tables > > dm_multipath sbs sbshc battery ac ipv6 parport_pc lp > parport > > dcdbas floppy snd_intel8x0 snd_ac97_codec ac97_bus > > snd_seq_dummy ide_cd_mod cdrom snd_seq_oss > > snd_seq_midi_event button snd_seq e1000 snd_seq_device > > snd_pcm_oss snd_mixer_oss snd_pcm serio_raw rtc_cmos > > rtc_core i2c_i801 snd_timer rtc_lib i2c_core snd > edac_core > > pcspkr soundcore snd_page_alloc dm_snapshot dm_zero > > dm_mirror dm_log dm_mod ata_piix libata sd_mod > scsi_mod ext3 > > jbd ehci_hcd ohci_hcd uhci_hcd [last unloaded: > microcode] > > > > Pid: 4035, comm: sh Not tainted (2.6.26 #1) > > EIP: 0060:[<c04a2215>] EFLAGS: 00010246 CPU: 0 > > EIP is at sysfs_find_dirent+0x4/0x23 > > EAX: 00000000 EBX: c067ea13 ECX: df801080 EDX: > c067ea13 > > ESI: c067ea13 EDI: c06ec794 EBP: ce8dc6fc ESP: > cebafe30 > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > > Process sh (pid: 4035, ti=cebaf000 task=df1dedc0 > > task.ti=cebaf000) > > Stack: c067ea13 00000000 c04a2b01 ce8dc684 00000000 > > c04a32ce ce8dc684 00000001 > > ce896c1c d0c88438 c054ca37 ce8dc684 c0548e33 > > ce8dc684 00000001 00000000 > > c0548f3f d0c88400 e0af9907 d0c88434 e0af9862 > > 00000001 c04ddc02 d0c88434 > > Call Trace: > > [<c04a2b01>] sysfs_get_dirent+0x19/0x45 > > [<c04a32ce>] sysfs_remove_group+0x18/0x96 > > [<c054ca37>] device_pm_remove+0x14/0x3c > > [<c0548e33>] device_del+0xd/0x111 > > [<c0548f3f>] device_unregister+0x8/0x10 > > [<e0af9907>] destroy_serial+0xa5/0xeb > [usbserial] > > [<e0af9862>] destroy_serial+0x0/0xeb [usbserial] > > [<c04ddc02>] kref_put+0x36/0x40 > > [<e0af9796>] usb_serial_put+0x1c/0x27 > [usbserial] > > [<e0af9bea>] usb_serial_disconnect+0x83/0xa8 > > [usbserial] > > [<c056e321>] usb_unbind_interface+0x2d/0x5f > > [<c054a699>] __device_release_driver+0x58/0x76 > > [<c054a6cf>] device_release_driver+0x18/0x21 > > [<c0549de2>] bus_remove_device+0x6b/0x7b > > [<c0548ee6>] device_del+0xc0/0x111 > > [<c056c3f7>] usb_disable_device+0x55/0xbb > > [<c056cddf>] usb_set_configuration+0x1bd/0x414 > > [<c04e0505>] sscanf+0x17/0x19 > > [<c056fbfd>] set_bConfigurationValue+0x44/0x62 > > [<c056fbb9>] set_bConfigurationValue+0x0/0x62 > > [<c054856a>] dev_attr_store+0x19/0x1d > > [<c04a1b50>] sysfs_write_file+0xa4/0xd8 > > [<c04a1aac>] sysfs_write_file+0x0/0xd8 > > [<c0469cbd>] vfs_write+0x83/0xf6 > > [<c046a20f>] sys_write+0x3c/0x63 > > [<c040389a>] syscall_call+0x7/0xb > > [<c0610000>] migration_call+0x314/0x3b6 > > ======================= > > Code: 40 08 83 79 0c 00 8d 58 18 74 0f 0f 0b eb fe 8b > 41 20 > > 3b 42 20 72 09 8d 5a 0c 8b 13 85 d2 75 ef 89 51 0c 89 > 0b 5b > > c3 56 89 d6 53 <8b> 58 18 eb 11 8b 43 10 89 f2 > e8 df > > ed 03 00 85 c0 74 07 8b 5b > > EIP: [<c04a2215>] sysfs_find_dirent+0x4/0x23 > SS:ESP > > 0068:cebafe30 > > ---[ end trace e53c213592aca5ba ]--- > > > > > > Thanks > > Amruth p.v > > > > > > Thanks > > Amruth p.v > > > > > > --- On Fri, 7/25/08, amruth > <amruth_pv(a)yahoo.com> > > wrote: > > > > > From: amruth <amruth_pv(a)yahoo.com> > > > Subject: kernel crashes after connecting multiple > > serial devices > > > To: "Alan Stern" > > <stern(a)rowland.harvard.edu>, "Oliver > Neukum" > > <oliver(a)neukum.org> > > > Cc: linux-usb(a)vger.kernel.org > > > Date: Friday, July 25, 2008, 1:10 PM > > > Hi > > > The system crashes after connecting multiple > serial > > devices > > > based on ti usb 3410 chipset. The detailed log is > > below. The > > > kernel is 2.6.26. Please suggest any ideas what > is > > going on. > > > > > > usb 2-2: reset full speed USB device using > uhci_hcd > > and > > > address 5 > > > usb 2-2: device firmware changed > > > usb 2-2: USB disconnect, address 5 > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_shutdown > > > ti_usb_3410_5052 2-2:1.0: device disconnected > > > usb 2-2: new full speed USB device using uhci_hcd > and > > > address 6 > > > usb 2-2: configuration #1 chosen from 2 choices > > > ti_usb_3410_5052 2-2:1.0: TI USB 3410 1 port > adapter > > > converter detected > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_startup - product 0x 8, num configurations > 2, > > > configuration value 1 > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_startup - device type is 3410 > > > ti_usb_3410_5052: probe of 2-2:1.0 failed with > error > > -5 > > > ti_usb_3410_5052 2-2:2.0: TI USB 3410 1 port > adapter > > > converter detected > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_startup - product 0x 8, num configurations > 2, > > > configuration value 2 > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_startup - device type is 3410 > > > usb-serial ttyUSB0: Error registering port > device, > > > continuing > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_shutdown > > > BUG: unable to handle kernel NULL pointer > dereference > > at > > > 00000018 > > > IP: [<c04a2215>] sysfs_find_dirent+0x4/0x23 > > > *pde = 0e975067 *pte = 00000000 > > > Oops: 0000 [#1] SMP > > > Modules linked in: ti_usb_3410_5052 usbserial > autofs4 > > hidp > > > rfcomm l2cap bluetooth sunrpc iptable_filter > ip_tables > > > ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables > > x_tables > > > dm_multipath sbs sbshc battery ac ipv6 parport_pc > lp > > parport > > > dcdbas floppy snd_intel8x0 snd_ac97_codec > ac97_bus > > > snd_seq_dummy ide_cd_mod cdrom snd_seq_oss > > > snd_seq_midi_event button snd_seq e1000 > snd_seq_device > > > snd_pcm_oss snd_mixer_oss snd_pcm serio_raw > rtc_cmos > > > rtc_core i2c_i801 snd_timer rtc_lib i2c_core snd > > edac_core > > > pcspkr soundcore snd_page_alloc dm_snapshot > dm_zero > > > dm_mirror dm_log dm_mod ata_piix libata sd_mod > > scsi_mod ext3 > > > jbd ehci_hcd ohci_hcd uhci_hcd [last unloaded: > > microcode] > > > > > > Pid: 4035, comm: sh Not tainted (2.6.26 #1) > > > EIP: 0060:[<c04a2215>] EFLAGS: 00010246 > CPU: 0 > > > EIP is at sysfs_find_dirent+0x4/0x23 > > > EAX: 00000000 EBX: c067ea13 ECX: df801080 EDX: > > c067ea13 > > > ESI: c067ea13 EDI: c06ec794 EBP: ce8dc6fc ESP: > > cebafe30 > > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > > > Process sh (pid: 4035, ti=cebaf000 task=df1dedc0 > > > task.ti=cebaf000) > > > Stack: c067ea13 00000000 c04a2b01 ce8dc684 > 00000000 > > > c04a32ce ce8dc684 00000001 > > > ce896c1c d0c88438 c054ca37 ce8dc684 > c0548e33 > > > ce8dc684 00000001 00000000 > > > c0548f3f d0c88400 e0af9907 d0c88434 > e0af9862 > > > 00000001 c04ddc02 d0c88434 > > > Call Trace: > > > [<c04a2b01>] sysfs_get_dirent+0x19/0x45 > > > [<c04a32ce>] sysfs_remove_group+0x18/0x96 > > > [<c054ca37>] device_pm_remove+0x14/0x3c > > > [<c0548e33>] device_del+0xd/0x111 > > > [<c0548f3f>] device_unregister+0x8/0x10 > > > [<e0af9907>] destroy_serial+0xa5/0xeb > > [usbserial] > > > [<e0af9862>] destroy_serial+0x0/0xeb > > [usbserial] > > > [<c04ddc02>] kref_put+0x36/0x40 > > > [<e0af9796>] usb_serial_put+0x1c/0x27 > > [usbserial] > > > [<e0af9bea>] > usb_serial_disconnect+0x83/0xa8 > > > [usbserial] > > > [<c056e321>] > usb_unbind_interface+0x2d/0x5f > > > [<c054a699>] > __device_release_driver+0x58/0x76 > > > [<c054a6cf>] > device_release_driver+0x18/0x21 > > > [<c0549de2>] bus_remove_device+0x6b/0x7b > > > [<c0548ee6>] device_del+0xc0/0x111 > > > [<c056c3f7>] usb_disable_device+0x55/0xbb > > > [<c056cddf>] > usb_set_configuration+0x1bd/0x414 > > > [<c04e0505>] sscanf+0x17/0x19 > > > [<c056fbfd>] > set_bConfigurationValue+0x44/0x62 > > > [<c056fbb9>] > set_bConfigurationValue+0x0/0x62 > > > [<c054856a>] dev_attr_store+0x19/0x1d > > > [<c04a1b50>] sysfs_write_file+0xa4/0xd8 > > > [<c04a1aac>] sysfs_write_file+0x0/0xd8 > > > [<c0469cbd>] vfs_write+0x83/0xf6 > > > [<c046a20f>] sys_write+0x3c/0x63 > > > [<c040389a>] syscall_call+0x7/0xb > > > [<c0610000>] migration_call+0x314/0x3b6 > > > ======================= > > > Code: 40 08 83 79 0c 00 8d 58 18 74 0f 0f 0b eb > fe 8b > > 41 20 > > > 3b 42 20 72 09 8d 5a 0c 8b 13 85 d2 75 ef 89 51 > 0c 89 > > 0b 5b > > > c3 56 89 d6 53 <8b> 58 18 eb 11 8b 43 10 89 > f2 > > e8 df > > > ed 03 00 85 c0 74 07 8b 5b > > > EIP: [<c04a2215>] > sysfs_find_dirent+0x4/0x23 > > SS:ESP > > > 0068:cebafe30 > > > ---[ end trace e53c213592aca5ba ]--- > > > > > > > > > Thanks > > > Amruth p.v > > > > > > > > > --- On Fri, 7/25/08, Oliver Neukum > > > <oliver(a)neukum.org> wrote: > > > > > > > From: Oliver Neukum > <oliver(a)neukum.org> > > > > Subject: Re: usb_reset_device causes probe > to > > fail on > > > USB serial device > > > > To: "Alan Stern" > > > <stern(a)rowland.harvard.edu> > > > > Cc: amruth_pv(a)yahoo.com, > > linux-usb(a)vger.kernel.org > > > > Date: Friday, July 25, 2008, 10:44 AM > > > > Am Freitag 25 Juli 2008 15:42:14 schrieb > Alan > > Stern: > > > > > On Fri, 25 Jul 2008, Oliver Neukum > wrote: > > > > > > > > > > > > What about situations where > the > > > firmware > > > > loading or mode switching was > > > > > > > done by a userspace task? > > > > > > > > > > > > They will have to go into kernel > space. > > > > > > > > > > This does not sound practical. > You're > > > talking > > > > about putting > > > > > potentially unbounded amounts of new > code > > and > > > data > > > > into the kernel. > > > > > > > > True. But the kernel is already open to > > potentially > > > > unbounded amounts > > > > of new code. We are adding drivers faster > than > > > removing > > > > them. > > > > > > > > > > > I'm not at all convinced > that > > the > > > > actions needed to return a wiped-out > > > > > > > device to normal operation > can be > > > carried > > > > out in the relatively > > > > > > > delicate environment of > > > > resume-from-hibernation. > > > > > > > > > > > > Why? > > > > > > > > > > Because there's no restriction on > what > > may be > > > > needed. Arbitrary > > > > > sequences of packets, arbitrarily long > data > > > sets,... > > > > And all with no > > > > > support from userspace. > > > > > > > > But the amount of work an implementation of > > resume() > > > may > > > > have to > > > > do. uvc needs to submit hundreds of URBs in > the > > worst > > > case. > > > > > > > > > The whole USB-Persist thing was sort of > a > > hack to > > > > begin with. Trying > > > > > to shoehorn all this extra stuff into > it is > > just > > > > impractical. It makes > > > > > much more sense to say that a device > which > > loses > > > too > > > > much state as a > > > > > result of a power interruption must be > > logically > > > > disconnected and > > > > > reinitialized. > > > > > > > > But why let it stay a sort of hack? The idea > has > > > potential. > > > > > > > > Regards > > > > Oliver > > > > -- > > > > To unsubscribe from this list: send the line > > > > "unsubscribe linux-usb" in > > > > the body of a message to > > majordomo(a)vger.kernel.org > > > > More majordomo info at > > > > http://vger.kernel.org/majordomo-info.html > > > > > > > > > > > > > > > -- > > > To unsubscribe from this list: send the line > > > "unsubscribe linux-usb" in > > > the body of a message to > majordomo(a)vger.kernel.org > > > More majordomo info at > > > http://vger.kernel.org/majordomo-info.html > > > > > > > > > > -- > > To unsubscribe from this list: send the line > > "unsubscribe linux-usb" in > > the body of a message to majordomo(a)vger.kernel.org > > More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > > > > -- > To unsubscribe from this list: send the line > "unsubscribe linux-usb" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at > http://vger.kernel.org/majordomo-info.html

1 0

git11 new config items
by Roland McGrath 24 Jul '08

24 Jul '08

I added these to config-generic to keep building with -git11. I have no idea if these are the right settings. +# CONFIG_MFD_TC6393XB is not set +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set +CONFIG_DMADEVICES=y +CONFIG_INTEL_IOATDMA=m +# CONFIG_DMATEST is not set Thanks, Roland

3 2

Are you still struggling to get it?
by Trudy Quick 24 Jul '08

24 Jul '08

Bacheelor, MasteerMBA, and Doctoraate diplomas available in the field of your choice that's right, you can even become a Doctor and receive all the benefits that comes with it! Our Diplomas/Certificates are recognised in most countries No required examination, tests, classes, books, or interviews. ** No one is turned down ** Confidentiality assured CALL US 24 HOURS A DAY, 7 DAYS A WEEK For US: 1-781-634-7970 Outside US: +1-781-634-7970 "Just leave your NAME & PHONE NO. (with CountryCode)" in the voicemail our staff will get back to you in next few days

1 0

Re: [patch 2/7] Change how we do nosegneg
by Roland McGrath 24 Jul '08

24 Jul '08

> We should really only install ld.so.conf files from packages > that actually have CONFIG_XEN enabled, but it would be > slightly messy to have only kernel-PAE.i686 and kernel.x86_64 > include it. It wouldn't really be so hard to conditionalize it at least for the arch's that ever need it. (The kernelcap trick might well be used for other things in the future.) I think the right direction to head is that upstream kernels supply a .conf file to match the vDSO they build in. This will probably always be just a constant file in the source, but in general can be said to be generated by the kernel build. The contents have to match the magic bits in the vDSO images built into the kernel, so it really should not be a distro/packaging responsibility to populate the file. So let's structure things around that: the kernel build for an arch that uses vdso might include a kernelcap.conf file (or might not). For simplicity and consistency in the .spec file, we'll install a file for all variants even when it's an empty placeholder. For the magic, the diff below probably covers it (wholly untested). Then it's up to BuildKernel just to add/remove ldconfig-kernelcap.conf as part of the build (perhaps eventually done by the upstream makefiles). The .conf files have to not conflict (reuse same bit with different name) across all installed kernels (or else ldconfig will complain). So a single kernel-%{KVERREL}.conf file would be fine. But instead I made it kernel-%{KVERREL}.variant.conf just to stay consistent with all existing names like /lib/module/FOO and the fact that no two kernel rpms conflict on the same file name (even if identical). Thanks, Roland --- kernel.spec 23 Jul 2008 19:51:09 -0000 1.791 +++ kernel.spec 24 Jul 2008 00:21:24 -0000 @@ -1509,21 +1513,13 @@ BuildKernel vmlinux vmlinux kdump vmlinu cd linux-%{kversion}.%{_target_cpu} -%if %{includexen} -%if %{with_xen} -mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d -rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf -cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf <<\EOF -# This directive teaches ldconfig to search in nosegneg subdirectories -# and cache the DSOs there with extra bit 0 set in their hwcap match -# fields. In Xen guest kernels, the vDSO tells the dynamic linker to -# search in nosegneg subdirectories and to match this extra hwcap bit -# in the ld.so.cache file. -hwcap 0 nosegneg -EOF -chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf -%endif -%endif +if [ ! -s ldconfig-kernelcap.conf ]; then + echo > ldconfig-kernelcap.conf "\ +# Placeholder file, no vDSO hwcap entries used in this kernel." +fi + +%{__install} -D -m 444 ldconfig-kernelcap.conf \ + $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernel-%{KVERREL}.conf %if %{with_doc} mkdir -p $RPM_BUILD_ROOT/usr/share/doc/kernel-doc-%{kversion}/Documentation @@ -1728,6 +1724,7 @@ fi /lib/modules/%{KVERREL}%{?2:.%{2}}/weak-updates\ %ifarch %{vdso_arches}\ /lib/modules/%{KVERREL}%{?2:.%{2}}/vdso\ +/etc/ld.so.conf.d/kernelcap-%{KVERREL}%{?2:.%{2}}.conf\ %endif\ /lib/modules/%{KVERREL}%{?2:.%{2}}/modules.block\ /lib/modules/%{KVERREL}%{?2:.%{2}}/modules.networking\

2 3

rebase, utrace
by Roland McGrath 24 Jul '08

24 Jul '08

I took the liberty of rebasing rawhide to git11. (rebase.sh works great!) That was necessary for my latest utrace patches to apply, and I turned those back on. I'm starting a build and will deal if it doesn't compile. Thanks, Roland

1 0

vanilla-%{kversion}
by Roland McGrath 24 Jul '08

24 Jul '08

I find myself doing a lot of make prep lately in the days of frequent new upstream base patches. The untar still takes a lot longer than the big patch. So I committed this to speed it up for the repeated rebase case. Thanks, Roland Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.791 diff -u -r1.791 kernel.spec --- kernel.spec 23 Jul 2008 19:51:09 -0000 1.791 +++ kernel.spec 24 Jul 2008 08:01:48 -0000 @@ -904,10 +904,19 @@ %endif if [ ! -d kernel-%{kversion}/vanilla-%{vanillaversion} ]; then - # Ok, first time we do a make prep. - rm -f pax_global_header + + if [ -d kernel-%{kversion}/vanilla-%{kversion} ]; then + cd kernel-%{kversion} + else + # Ok, first time we do a make prep. + rm -f pax_global_header %setup -q -n kernel-%{kversion} -c - mv linux-%{kversion} vanilla-%{vanillaversion} + mv linux-%{kversion} vanilla-%{kversion} + fi + +%if "%{kversion}" != "%{vanillaversion}" + cp -rl vanilla-%{kversion} vanilla-%{vanillaversion} +%endif cd vanilla-%{vanillaversion} # Update vanilla to the latest upstream.

1 0

Re: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides}
by Roland McGrath 24 Jul '08

24 Jul '08

> If you try and use e.g. kernel_obsoletes, you'll soon find > that it's actually kernel__obsoletes you currently need :-) So you want kernel to have an Obsoletes: that kernel-foo do not get?

2 3

Re: [patch 4/7] Remove unneeded %kernel_variant_post args
by Roland McGrath 24 Jul '08

24 Jul '08

Why bother? If it comes up in the future, the macro will be handy.

2 2

Re: [patch 0/7] Enable pv_ops Xen; kill the kernel-xen RPM
by Mark McLoughlin 23 Jul '08

23 Jul '08

On Wed, 2008-07-23 at 14:20 +0100, Mark McLoughlin wrote: > I'm still doing a last bit of testing making sure > that it all works fine, so don't apply yet ... but comments > are very welcome. Okay, it seems to be in pretty good shape now. The only outstanding TODO item is to make kernel-PAE.i686 %post do: s/DEFAULTKERNEL=kernel-xen/DEFAULTKERNEL=kernel-PAE/ and kernel.x86_64 %post do: s/DEFAULTKERNEL=kernel-xen/DEFAULTKERNEL=kernel/ But I've had enough spec file pain for one day ... we can add this later :-) Cheers, Mark.

1 0

Re: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides}
by Mark McLoughlin 23 Jul '08

23 Jul '08

On Wed, 2008-07-23 at 14:20 +0100, Mark McLoughlin wrote: > If you try and use e.g. kernel_obsoletes, you'll soon find > that it's actually kernel__obsoletes you currently need :-) > > Index: devel/kernel.spec > =================================================================== > --- devel.orig/kernel.spec 2008-07-23 14:04:17.000000000 +0100 > +++ devel.orig/kernel.spec 2008-07-23 14:04:17.000000000 +0100 > @@ -440,9 +440,9 @@ Provides: kernel-uname-r = %{KVERREL}%{? > Requires(pre): %{kernel_prereq}\ > Conflicts: %{kernel_dot_org_conflicts}\ > Conflicts: %{package_conflicts}\ > -%{?1:%{expand:%%{?kernel_%{1}_conflicts:Conflicts: %%{kernel_%{1}_conflicts}}}}\ > -%{?1:%{expand:%%{?kernel_%{1}_obsoletes:Obsoletes: %%{kernel_%{1}_obsoletes}}}}\ > -%{?1:%{expand:%%{?kernel_%{1}_provides:Provides: %%{kernel_%{1}_provides}}}}\ > +%{?1:%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}}\ > +%{?1:%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: %%{kernel%{?1:_%{1}}_obsoletes}}}}\ > +%{?1:%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: %%{kernel%{?1:_%{1}}_provides}}}}\ Bah, make that: +%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}\ +%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: %%{kernel%{?1:_%{1}}_obsoletes}}}\ +%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: %%{kernel%{?1:_%{1}}_provides}}}\ Cheers, Mark.

1 0

[patch 7/7] Enable Xen support again
by Mark McLoughlin 23 Jul '08

23 Jul '08

Now that i686 PAE and x86_64 Xen DomU support is fully upstream, re-enable it in the stock kernel. The only not-upstream patches we require are to support execshield Also note the Obsoletes/Provides to make upgrades go smoothely. Index: devel/config-x86-generic =================================================================== --- devel.orig/config-x86-generic 2008-07-23 14:06:22.000000000 +0100 +++ devel.orig/config-x86-generic 2008-07-23 14:06:22.000000000 +0100 @@ -340,10 +340,20 @@ CONFIG_PARAVIRT=y # CONFIG_PARAVIRT_DEBUG is not set CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y -# CONFIG_XEN is not set CONFIG_LGUEST_GUEST=y CONFIG_VMI=y +CONFIG_XEN=y +CONFIG_XEN_MAX_DOMAIN_MEMORY=8 +CONFIG_XEN_BALLOON=y +CONFIG_XEN_SCRUB_PAGES=y +CONFIG_XEN_SAVE_RESTORE=y +CONFIG_HVC_XEN=y +CONFIG_XEN_FBDEV_FRONTEND=y +CONFIG_XEN_KBDDEV_FRONTEND=y +CONFIG_XEN_BLKDEV_FRONTEND=m +CONFIG_XEN_NETDEV_FRONTEND=m + CONFIG_MTD_ESB2ROM=m CONFIG_MTD_CK804XROM=m CONFIG_MTD_NAND_CAFE=m Index: devel/config-x86_64-generic =================================================================== --- devel.orig/config-x86_64-generic 2008-07-23 14:06:22.000000000 +0100 +++ devel.orig/config-x86_64-generic 2008-07-23 14:06:22.000000000 +0100 @@ -258,7 +258,17 @@ CONFIG_PARAVIRT=y # CONFIG_PARAVIRT_DEBUG is not set CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y -# CONFIG_XEN is not set + +CONFIG_XEN=y +CONFIG_XEN_MAX_DOMAIN_MEMORY=32 +CONFIG_XEN_BALLOON=y +CONFIG_XEN_SCRUB_PAGES=y +CONFIG_XEN_SAVE_RESTORE=y +CONFIG_HVC_XEN=y +CONFIG_XEN_FBDEV_FRONTEND=y +CONFIG_XEN_KBDDEV_FRONTEND=y +CONFIG_XEN_BLKDEV_FRONTEND=m +CONFIG_XEN_NETDEV_FRONTEND=m CONFIG_DMADEVICES=y CONFIG_INTEL_IOATDMA=m Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-23 14:06:22.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-23 14:06:22.000000000 +0100 @@ -372,7 +372,13 @@ Summary: The Linux kernel # upto and including kernel 2.4.9 rpms, the 4Gb+ kernel was called kernel-enterprise # now that the smp kernel offers this capability, obsolete the old kernel %define kernel_smp_obsoletes kernel-enterprise < 2.4.10 -%define kernel_PAE_obsoletes kernel-smp < 2.6.17 +%define kernel_PAE_obsoletes kernel-smp < 2.6.17, kernel-xen <= 2.6.27-0.2.rc0.git6.fc10 +%define kernel_PAE_provides kernel-xen = %{rpmversion}-%{pkg_release} + +%ifarch x86_64 +%define kernel_obsoletes kernel-xen <= 2.6.27-0.2.rc0.git6.fc10 +%define kernel_provides kernel-xen = %{rpmversion}-%{pkg_release} +%endif # We moved the drm include files into kernel-headers, make sure there's # a recent enough libdrm-devel on the system that doesn't have those. @@ -548,6 +554,9 @@ Patch147: linux-2.6-imac-transparent-bri Patch149: linux-2.6-efika-not-chrp.patch Patch160: linux-2.6-execshield.patch +Patch161: linux-2.6-xen-execshield-add-xen-specific-load_user_cs_desc.patch +Patch162: linux-2.6-xen-execshield-fix-endless-gpf-fault-loop.patch +Patch163: linux-2.6-xen-execshield-only-define-load_user_cs_desc-on-32-bit.patch Patch250: linux-2.6-debug-sizeof-structs.patch Patch260: linux-2.6-debug-nmi-timeout.patch Patch270: linux-2.6-debug-taint-vm.patch @@ -987,6 +996,9 @@ ApplyPatch linux-2.6-imac-transparent-br # Exec shield # ApplyPatch linux-2.6-execshield.patch +ApplyPatch linux-2.6-xen-execshield-add-xen-specific-load_user_cs_desc.patch +ApplyPatch linux-2.6-xen-execshield-fix-endless-gpf-fault-loop.patch +ApplyPatch linux-2.6-xen-execshield-only-define-load_user_cs_desc-on-32-bit.patch # # bugfixes to drivers and filesystems Index: devel/linux-2.6-xen-execshield-add-xen-specific-load_user_cs_desc.patch =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -0,0 +1,126 @@ +From cdff48f3077459f1dfaf243db8e402c8202a2693 Mon Sep 17 00:00:00 2001 +From: Stephen Tweedie <sct(a)redhat.com> +Date: Tue, 11 Mar 2008 18:05:30 +0000 +Subject: [PATCH] xen execshield: Add xen-specific load_user_cs_desc() + +x86 32-bit execshield uses load_user_cs_desc() to setup the user CS +descriptor, but the Xen version needs to do this via a hypercall. + +Add this via a new pv_cpu_ops->load_user_cs_desc pv_ops indirection +so that it can be selected appropriately at run-time. + +Signed-off-by: Stephen Tweedie <sct(a)redhat.com> +--- + arch/x86/kernel/paravirt.c | 1 + + arch/x86/xen/enlighten.c | 17 +++++++++++++++++ + include/asm-x86/desc.h | 8 ++++++-- + include/asm-x86/paravirt.h | 6 ++++++ + 4 files changed, 30 insertions(+), 2 deletions(-) + +diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c +index 94da4d5..f2a678c 100644 +--- a/arch/x86/kernel/paravirt.c ++++ b/arch/x86/kernel/paravirt.c +@@ -336,6 +336,7 @@ struct pv_cpu_ops pv_cpu_ops = { + .read_tscp = native_read_tscp, + .load_tr_desc = native_load_tr_desc, + .set_ldt = native_set_ldt, ++ .load_user_cs_desc = native_load_user_cs_desc, + .load_gdt = native_load_gdt, + .load_idt = native_load_idt, + .store_gdt = native_store_gdt, +diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c +index 9ff6e3c..9b95277 100644 +--- a/arch/x86/xen/enlighten.c ++++ b/arch/x86/xen/enlighten.c +@@ -340,6 +340,22 @@ static void xen_set_ldt(const void *addr, unsigned entries) + xen_mc_issue(PARAVIRT_LAZY_CPU); + } + ++static inline void xen_load_user_cs_desc(int cpu, struct mm_struct *mm) ++{ ++ void *gdt; ++ xmaddr_t mgdt; ++ u64 descriptor; ++ struct desc_struct user_cs; ++ ++ gdt = &get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS]; ++ mgdt = virt_to_machine(gdt); ++ ++ user_cs = mm->context.user_cs; ++ descriptor = (u64) user_cs.a | ((u64) user_cs.b) << 32; ++ ++ HYPERVISOR_update_descriptor(mgdt.maddr, descriptor); ++} ++ + static void xen_load_gdt(const struct desc_ptr *dtr) + { + unsigned long *frames; +@@ -1213,6 +1229,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initdata = { + + .load_tr_desc = paravirt_nop, + .set_ldt = xen_set_ldt, ++ .load_user_cs_desc = xen_load_user_cs_desc, + .load_gdt = xen_load_gdt, + .load_idt = xen_load_idt, + .load_tls = xen_load_tls, +diff --git a/include/asm-x86/desc.h b/include/asm-x86/desc.h +index 3a545b1..713634f 100644 +--- a/include/asm-x86/desc.h ++++ b/include/asm-x86/desc.h +@@ -6,6 +6,7 @@ + #include <asm/ldt.h> + #include <asm/mmu.h> + #include <linux/smp.h> ++#include <linux/mm_types.h> + + static inline void fill_ldt(struct desc_struct *desc, + const struct user_desc *info) +@@ -90,6 +91,7 @@ static inline int desc_empty(const void *ptr) + + #define load_TLS(t, cpu) native_load_tls(t, cpu) + #define set_ldt native_set_ldt ++#define load_user_cs_desc native_load_user_cs_desc + + #define write_ldt_entry(dt, entry, desc) \ + native_write_ldt_entry(dt, entry, desc) +@@ -380,8 +382,10 @@ static inline void set_user_cs(struct desc_struct *desc, unsigned long limit) + desc->b = (limit & 0xf0000) | 0x00c0fb00; + } + +-#define load_user_cs_desc(cpu, mm) \ +- get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS] = (mm)->context.user_cs ++static inline void native_load_user_cs_desc(int cpu, struct mm_struct *mm) ++{ ++ get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS] = mm->context.user_cs; ++} + + extern void arch_add_exec_range(struct mm_struct *mm, unsigned long limit); + extern void arch_remove_exec_range(struct mm_struct *mm, unsigned long limit); +diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h +index fbbde93..151ac7a 100644 +--- a/include/asm-x86/paravirt.h ++++ b/include/asm-x86/paravirt.h +@@ -113,6 +113,7 @@ struct pv_cpu_ops { + void (*store_gdt)(struct desc_ptr *); + void (*store_idt)(struct desc_ptr *); + void (*set_ldt)(const void *desc, unsigned entries); ++ void (*load_user_cs_desc)(int cpu, struct mm_struct *mm); + unsigned long (*store_tr)(void); + void (*load_tls)(struct thread_struct *t, unsigned int cpu); + #ifdef CONFIG_X86_64 +@@ -840,6 +841,11 @@ static inline void set_ldt(const void *addr, unsigned entries) + { + PVOP_VCALL2(pv_cpu_ops.set_ldt, addr, entries); + } ++static inline void load_user_cs_desc(unsigned int cpu, ++ struct mm_struct *mm) ++{ ++ PVOP_VCALL2(pv_cpu_ops.load_user_cs_desc, cpu, mm); ++} + static inline void store_gdt(struct desc_ptr *dtr) + { + PVOP_VCALL1(pv_cpu_ops.store_gdt, dtr); +-- +1.5.4.1 + Index: devel/linux-2.6-xen-execshield-fix-endless-gpf-fault-loop.patch =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -0,0 +1,52 @@ +From ad6f7a1789fdb94b16952f50ed65964dc206d7be Mon Sep 17 00:00:00 2001 +From: Stephen Tweedie <sct(a)redhat.com> +Date: Tue, 11 Mar 2008 18:07:31 +0000 +Subject: [PATCH] xen execshield: fix endless GPF fault loop + +Under Xen, loading the user_cs descriptor does not necessarily load +the descriptor with the exact same values the kernel requested: some +of the control bits in the descriptor may be modified by the +hypervisor. + +With execshield, the check_lazy_exec_limit() function is needed to +test whether a fault has been caused by the existing user_cs +descriptor being too constrained: if so, it performs a lazy expansion +of the legal cs segment bounds. But it does so via an exact match on +the descriptor values against their current expected values, so if +Xen modifies any control bits in the descriptor, it looks as if the +user_cs is out-of-sync; so check_lazy_exec_limit() resets the +descriptor and retakes the fault unnecessarily. + +This means that a GPF fault can be retried indefinitely, with the +kernel always seeing the wrong values in user_cs and continually +trying to correct them and retake the fault. + +Fix it by masking off the xen-sensitive control bits when checking +that the segment descriptor is up-to-date, and comparing only the +bits which affect the segment base and limit. + +Affects 32-bit only; execshield on 64-bit uses NX for this +functionality. + +Signed-off-by: Stephen Tweedie <sct(a)redhat.com> +--- + arch/x86/kernel/traps_32.c | 3 ++- + 1 files changed, 2 insertions(+), 1 deletions(-) + +diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c +index d001d55..c932b3e 100644 +--- a/arch/x86/kernel/traps_32.c ++++ b/arch/x86/kernel/traps_32.c +@@ -621,7 +621,8 @@ check_lazy_exec_limit(int cpu, struct pt_regs *regs, long error_code) + desc1 = &current->mm->context.user_cs; + desc2 = get_cpu_gdt_table(cpu) + GDT_ENTRY_DEFAULT_USER_CS; + +- if (desc1->a != desc2->a || desc1->b != desc2->b) { ++ if ((desc1->a & 0xff0000ff) != (desc2->a & 0xff0000ff) || ++ desc1->b != desc2->b) { + /* + * The CS was not in sync - reload it and retry the + * instruction. If the instruction still faults then +-- +1.5.4.1 + Index: devel/linux-2.6-xen-execshield-only-define-load_user_cs_desc-on-32-bit.patch =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -0,0 +1,122 @@ +From 226bc4b8f13ece618de046f6f8da88eeb4b8f8da Mon Sep 17 00:00:00 2001 +From: Mark McLoughlin <markmc(a)redhat.com> +Date: Tue, 25 Mar 2008 11:56:43 +0000 +Subject: [PATCH] xen execshield: Only define load_user_cs_desc() on 32 bit + +load_user_cs_desc() is only used on 32 bit, so only +define it in that case. + +Fixes compile failure in native_load_user_cs_desc() +since mm_context_t->user_cs is only available on +32 bit. + +Signed-off-by: Mark McLoughlin <markmc(a)redhat.com> +--- + arch/x86/kernel/paravirt.c | 2 ++ + arch/x86/xen/enlighten.c | 4 ++++ + include/asm-x86/desc.h | 4 ++++ + include/asm-x86/paravirt.h | 4 ++++ + 4 files changed, 14 insertions(+), 0 deletions(-) + +diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c +index f2a678c..4277d1a 100644 +--- a/arch/x86/kernel/paravirt.c ++++ b/arch/x86/kernel/paravirt.c +@@ -336,7 +336,9 @@ struct pv_cpu_ops pv_cpu_ops = { + .read_tscp = native_read_tscp, + .load_tr_desc = native_load_tr_desc, + .set_ldt = native_set_ldt, ++#ifdef CONFIG_X86_32 + .load_user_cs_desc = native_load_user_cs_desc, ++#endif + .load_gdt = native_load_gdt, + .load_idt = native_load_idt, + .store_gdt = native_store_gdt, +diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c +index 9b95277..c54060c 100644 +--- a/arch/x86/xen/enlighten.c ++++ b/arch/x86/xen/enlighten.c +@@ -340,6 +340,7 @@ static void xen_set_ldt(const void *addr, unsigned entries) + xen_mc_issue(PARAVIRT_LAZY_CPU); + } + ++#ifdef CONFIG_X86_32 + static inline void xen_load_user_cs_desc(int cpu, struct mm_struct *mm) + { + void *gdt; +@@ -355,6 +356,7 @@ static inline void xen_load_user_cs_desc(int cpu, struct mm_struct *mm) + + HYPERVISOR_update_descriptor(mgdt.maddr, descriptor); + } ++#endif + + static void xen_load_gdt(const struct desc_ptr *dtr) + { +@@ -1229,7 +1231,9 @@ static const struct pv_cpu_ops xen_cpu_ops __initdata = { + + .load_tr_desc = paravirt_nop, + .set_ldt = xen_set_ldt, ++#ifdef CONFIG_X86_32 + .load_user_cs_desc = xen_load_user_cs_desc, ++#endif + .load_gdt = xen_load_gdt, + .load_idt = xen_load_idt, + .load_tls = xen_load_tls, +diff --git a/include/asm-x86/desc.h b/include/asm-x86/desc.h +index 713634f..54234ac 100644 +--- a/include/asm-x86/desc.h ++++ b/include/asm-x86/desc.h +@@ -91,7 +91,9 @@ static inline int desc_empty(const void *ptr) + + #define load_TLS(t, cpu) native_load_tls(t, cpu) + #define set_ldt native_set_ldt ++#ifdef CONFIG_X86_32 + #define load_user_cs_desc native_load_user_cs_desc ++#endif + + #define write_ldt_entry(dt, entry, desc) \ + native_write_ldt_entry(dt, entry, desc) +@@ -382,10 +384,12 @@ static inline void set_user_cs(struct desc_struct *desc, unsigned long limit) + desc->b = (limit & 0xf0000) | 0x00c0fb00; + } + ++#ifdef CONFIG_X86_32 + static inline void native_load_user_cs_desc(int cpu, struct mm_struct *mm) + { + get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS] = mm->context.user_cs; + } ++#endif + + extern void arch_add_exec_range(struct mm_struct *mm, unsigned long limit); + extern void arch_remove_exec_range(struct mm_struct *mm, unsigned long limit); +diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h +index 151ac7a..f354748 100644 +--- a/include/asm-x86/paravirt.h ++++ b/include/asm-x86/paravirt.h +@@ -113,7 +113,9 @@ struct pv_cpu_ops { + void (*store_gdt)(struct desc_ptr *); + void (*store_idt)(struct desc_ptr *); + void (*set_ldt)(const void *desc, unsigned entries); ++#ifdef CONFIG_X86_32 + void (*load_user_cs_desc)(int cpu, struct mm_struct *mm); ++#endif + unsigned long (*store_tr)(void); + void (*load_tls)(struct thread_struct *t, unsigned int cpu); + #ifdef CONFIG_X86_64 +@@ -841,11 +843,13 @@ static inline void set_ldt(const void *addr, unsigned entries) + { + PVOP_VCALL2(pv_cpu_ops.set_ldt, addr, entries); + } ++#ifdef CONFIG_X86_32 + static inline void load_user_cs_desc(unsigned int cpu, + struct mm_struct *mm) + { + PVOP_VCALL2(pv_cpu_ops.load_user_cs_desc, cpu, mm); + } ++#endif + static inline void store_gdt(struct desc_ptr *dtr) + { + PVOP_VCALL1(pv_cpu_ops.store_gdt, dtr); +-- +1.5.4.1 + --

1 0

[patch 6/7] Slightly re-org virt related configs
by Mark McLoughlin 23 Jul '08

23 Jul '08

Get all OCD on virt related configs - bring them together, separate the host stuff from the guest stuff and make the x86_64 config look much more like the x86 config. Index: devel/config-x86-generic =================================================================== --- devel.orig/config-x86-generic 2008-07-23 09:49:15.000000000 +0100 +++ devel.orig/config-x86-generic 2008-07-23 09:49:15.000000000 +0100 @@ -318,9 +318,6 @@ CONFIG_SONY_LAPTOP=m # CONFIG_SMSC37B787_WDT is not set CONFIG_W83697HF_WDT=m -CONFIG_PARAVIRT=y -# CONFIG_PARAVIRT_DEBUG is not set - CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x400000 CONFIG_PHYSICAL_START=0x400000 @@ -331,12 +328,21 @@ CONFIG_CRYPTO_DEV_GEODE=m CONFIG_VIDEO_CAFE_CCIC=m +CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m +CONFIG_KVM_TRACE=y +CONFIG_LGUEST=m + +CONFIG_PARAVIRT_GUEST=y +CONFIG_PARAVIRT=y +# CONFIG_PARAVIRT_DEBUG is not set CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y -CONFIG_KVM_TRACE=y +# CONFIG_XEN is not set +CONFIG_LGUEST_GUEST=y +CONFIG_VMI=y CONFIG_MTD_ESB2ROM=m CONFIG_MTD_CK804XROM=m @@ -360,14 +366,6 @@ CONFIG_DMIID=y CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m -CONFIG_VIRTUALIZATION=y -CONFIG_PARAVIRT_GUEST=y -CONFIG_VMI=y -CONFIG_LGUEST=m -CONFIG_LGUEST_GUEST=y -# CONFIG_XEN is not set -# CONFIG_HVC_XEN is not set - CONFIG_DMADEVICES=y CONFIG_INTEL_IOATDMA=m Index: devel/config-x86_64-generic =================================================================== --- devel.orig/config-x86_64-generic 2008-07-23 09:49:15.000000000 +0100 +++ devel.orig/config-x86_64-generic 2008-07-23 09:49:15.000000000 +0100 @@ -1,6 +1,5 @@ CONFIG_64BIT=y CONFIG_UID16=y -# CONFIG_XEN is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_GENERIC_CPU=y @@ -227,11 +226,6 @@ CONFIG_W83697HF_WDT=m # CONFIG_VIDEO_CAFE_CCIC is not set -CONFIG_KVM=m -CONFIG_KVM_INTEL=m -CONFIG_KVM_AMD=m -CONFIG_KVM_TRACE=y - CONFIG_MTD_ESB2ROM=m CONFIG_MTD_CK804XROM=m @@ -254,18 +248,23 @@ CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_VIRTUALIZATION=y +CONFIG_KVM=m +CONFIG_KVM_INTEL=m +CONFIG_KVM_AMD=m +CONFIG_KVM_TRACE=y + +CONFIG_PARAVIRT_GUEST=y +CONFIG_PARAVIRT=y +# CONFIG_PARAVIRT_DEBUG is not set +CONFIG_KVM_CLOCK=y +CONFIG_KVM_GUEST=y +# CONFIG_XEN is not set CONFIG_DMADEVICES=y CONFIG_INTEL_IOATDMA=m CONFIG_SENSORS_I5K_AMB=m -CONFIG_PARAVIRT_GUEST=y -CONFIG_KVM_CLOCK=y -CONFIG_KVM_GUEST=y -CONFIG_PARAVIRT=y -# CONFIG_PARAVIRT_DEBUG is not set - # CONFIG_COMPAT_VDSO is not set CONFIG_PROVIDE_OHCI1394_DMA_INIT=y # CONFIG_DEBUG_PER_CPU_MAPS is not set --

1 0

[patch 5/7] Kill -a and -e args to %kernel_variant_files
by Mark McLoughlin 23 Jul '08

23 Jul '08

We don't need them anymore Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-23 09:57:04.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-23 09:57:04.000000000 +0100 @@ -1622,9 +1622,9 @@ fi # # This macro defines the %%files sections for a kernel package # and its devel and debuginfo packages. -# %%kernel_variant_files [-k vmlinux] [-a <extra-files-glob>] [-e <extra-nonbinary>] <condition> <subpackage> +# %%kernel_variant_files [-k vmlinux] <condition> <subpackage> # -%define kernel_variant_files(a:e:k:) \ +%define kernel_variant_files(k:) \ %if %{1}\ %{expand:%%files %{?2}}\ %defattr(-,root,root)\ @@ -1632,7 +1632,6 @@ fi /boot/System.map-%{KVERREL}%{?2:.%{2}}\ #/boot/symvers-%{KVERREL}%{?2:.%{2}}.gz\ /boot/config-%{KVERREL}%{?2:.%{2}}\ -%{?-a:%{-a*}}\ %dir /lib/modules/%{KVERREL}%{?2:.%{2}}\ /lib/modules/%{KVERREL}%{?2:.%{2}}/kernel\ /lib/modules/%{KVERREL}%{?2:.%{2}}/build\ @@ -1648,7 +1647,6 @@ fi /lib/modules/%{KVERREL}%{?2:.%{2}}/modules.order\ %ghost /boot/initrd-%{KVERREL}%{?2:.%{2}}.img\ /etc/ld.so.conf.d/kernelcap-%{KVERREL}%{?2:.%{2}}.nosegneg.conf\ -%{?-e:%{-e*}}\ %{expand:%%files %{?2:%{2}-}devel}\ %defattr(-,root,root)\ %verify(not mtime) /usr/src/kernels/%{KVERREL}%{?2:.%{2}}\ --

1 0

[patch 4/7] Remove unneeded %kernel_variant_post args
by Mark McLoughlin 23 Jul '08

23 Jul '08

We no longer need the ability to pass arbitrary mkinitrd args to %kernel_variant_post Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-23 09:14:54.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-23 09:14:54.000000000 +0100 @@ -1519,7 +1519,7 @@ fi\ %{nil} # This macro defines a %%posttrans script for a kernel package. -# %%kernel_variant_posttrans [-v <subpackage>] [-s <s> -r <r>] <mkinitrd-args> +# %%kernel_variant_posttrans [-v <subpackage>] [-s <s> -r <r>] # More text can follow to go at the end of this variant's %%post. # %define kernel_variant_posttrans(s:r:v:) \ @@ -1529,7 +1529,7 @@ fi\ # # This macro defines a %%post script for a kernel package and its devel package. -# %%kernel_variant_post [-v <subpackage>] [-s <s> -r <r>] <mkinitrd-args> +# %%kernel_variant_post [-v <subpackage>] [-s <s> -r <r>] # More text can follow to go at the end of this variant's %%post. # %define kernel_variant_post(s:r:v:) \ @@ -1541,7 +1541,7 @@ if [ `uname -i` == "x86_64" -o `uname -i [ -f /etc/sysconfig/kernel ]; then\ /bin/sed -i -e 's/^DEFAULTKERNEL=%{-s*}$/DEFAULTKERNEL=%{-r*}/' /etc/sysconfig/kernel || exit $?\ fi}\ -/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod --install %{*} %{KVERREL}%{?-v:.%{-v*}} || exit $?\ +/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod --install %{KVERREL}%{?-v:.%{-v*}} || exit $?\ #if [ -x /sbin/weak-modules ]\ #then\ # /sbin/weak-modules --add-kernel %{KVERREL}%{?-v*} || exit $?\ --

1 0

[patch 3/7] Kill old xen cruft
by Mark McLoughlin 23 Jul '08

23 Jul '08

Kill off most of the remnants of the separate xen package Gone is the kernel-xen variant and xen.gz Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-23 14:13:25.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-23 14:13:25.000000000 +0100 @@ -66,8 +66,6 @@ Summary: The Linux kernel %define with_smp %{?_without_smp: 0} %{?!_without_smp: 1} # kernel-PAE (only valid for i686) %define with_pae %{?_without_pae: 0} %{?!_without_pae: 1} -# kernel-xen -%define with_xen %{?_without_xen: 0} %{?!_without_xen: 1} # kernel-kdump %define with_kdump %{?_without_kdump: 0} %{?!_without_kdump: 1} # kernel-debug @@ -94,17 +92,10 @@ Summary: The Linux kernel %define with_smponly %{?_with_smponly: 1} %{?!_with_smponly: 0} # Only build the pae kernel (--with paeonly): %define with_paeonly %{?_with_paeonly: 1} %{?!_with_paeonly: 0} -# Only build the xen kernel (--with xenonly): -%define with_xenonly %{?_with_xenonly: 1} %{?!_with_xenonly: 0} # should we do C=1 builds with sparse %define with_sparse %{?_with_sparse: 1} %{?!_with_sparse: 0} -# Whether or not to apply the Xen patches -- leave this enabled -%define includexen 0 -# Xen doesn't work with current upstream kernel, shut it off -%define with_xen 0 - # Set debugbuildsenabled to 1 for production (build separate debug kernels) # and 0 for rawhide (all kernels are debug kernels). # See also 'make debug' and 'make release'. @@ -135,11 +126,6 @@ Summary: The Linux kernel %define make_target bzImage -%define xen_hv_cset 11633 -%define xen_flags verbose=y crash_debug=y -%define xen_target vmlinuz -%define xen_image vmlinuz - %define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}.%{_target_cpu} %define hdrarch %_target_cpu @@ -152,8 +138,6 @@ Summary: The Linux kernel %endif %if %{nopatches} -%define includexen 0 -%define with_xen 0 %define with_bootwrapper 0 %define variant -vanilla %else @@ -181,7 +165,6 @@ Summary: The Linux kernel %if %{with_baseonly} %define with_smp 0 %define with_pae 0 -%define with_xen 0 %define with_kdump 0 %define with_debug 0 %endif @@ -190,7 +173,6 @@ Summary: The Linux kernel %if %{with_smponly} %define with_up 0 %define with_pae 0 -%define with_xen 0 %define with_kdump 0 %define with_debug 0 %endif @@ -199,16 +181,6 @@ Summary: The Linux kernel %if %{with_paeonly} %define with_up 0 %define with_smp 0 -%define with_xen 0 -%define with_kdump 0 -%define with_debug 0 -%endif - -# if requested, only build xen kernel -%if %{with_xenonly} -%define with_up 0 -%define with_smp 0 -%define with_pae 0 %define with_kdump 0 %define with_debug 0 %endif @@ -230,11 +202,6 @@ Summary: The Linux kernel %define with_pae 0 %endif -# xen only builds on i686, x86_64 and ia64 -%ifnarch i686 x86_64 ia64 -%define with_xen 0 -%endif - # only build kernel-kdump on ppc64 # (no relocatable kernel support upstream yet) %ifnarch ppc64 @@ -281,8 +248,6 @@ Summary: The Linux kernel %define all_arch_configs kernel-%{version}-i?86*.config %define image_install_path boot %define hdrarch i386 -# we build always xen i686 HV with pae -%define xen_flags verbose=y crash_debug=y pae=y %define kernel_image arch/x86/boot/bzImage %endif @@ -334,10 +299,6 @@ Summary: The Linux kernel %define image_install_path boot/efi/EFI/redhat %define make_target compressed %define kernel_image vmlinux.gz -# ia64 xen HV doesn't building with debug=y at the moment -%define xen_flags verbose=y crash_debug=y -%define xen_target compressed -%define xen_image vmlinux.gz %endif %ifarch alpha alphaev56 @@ -374,7 +335,6 @@ Summary: The Linux kernel %define with_up 0 %define with_smp 0 %define with_pae 0 -%define with_xen 0 %define with_kdump 0 %define with_debuginfo 0 %define _enable_debug_packages 0 @@ -497,8 +457,6 @@ BuildRequires: rpm-build >= 4.4.2.1-4 %endif Source0: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-%{kversion}.tar.bz2 -#Source1: xen-%{xen_hv_cset}.tar.bz2 -Source2: Config.mk Source10: COPYING.modules Source11: genkey @@ -509,18 +467,15 @@ Source20: Makefile.config Source21: config-debug Source22: config-nodebug Source23: config-generic -Source24: config-xen-generic -Source25: config-rhel-generic -Source26: config-rhel-x86-generic +Source24: config-rhel-generic +Source25: config-rhel-x86-generic Source30: config-x86-generic Source31: config-i586 Source32: config-i686 Source33: config-i686-PAE -Source34: config-xen-x86 Source40: config-x86_64-generic -Source41: config-xen-x86_64 Source50: config-powerpc-generic Source51: config-powerpc32-generic @@ -530,7 +485,6 @@ Source54: config-powerpc64-kdump Source60: config-ia64-generic Source61: config-ia64 -Source62: config-xen-ia64 Source70: config-s390x @@ -823,13 +777,6 @@ It should only be installed when trying on kernel bugs, as some of these options impact performance noticably. -%define variant_summary The Linux kernel compiled for Xen VM operations -%kernel_variant_package -n Xen xen -%description xen -This package includes a version of the Linux kernel which -runs in a Xen VM. It works for both privileged and unprivileged guests. - - %define variant_summary A minimal Linux kernel compiled for crash dumps %kernel_variant_package kdump %description kdump @@ -861,13 +808,6 @@ exit 1 %endif %endif -%if %{with_xenonly} -%if !%{with_xen} -echo "Cannot build --with xenonly, xen build is disabled" -exit 1 -%endif -%endif - patch_command='patch -p1 -F1 -s' ApplyPatch() { @@ -1220,19 +1160,6 @@ find . \( -name "*.orig" -o -name "*~" \ cd .. -# Unpack the Xen tarball. -%if %{includexen} -cp %{SOURCE2} . -if [ -d xen ]; then - rm -rf xen -fi -%setup -D -T -q -n kernel-%{kversion} -a1 -cd xen -# Any necessary hypervisor patches go here - -%endif - - ### ### build ### @@ -1376,9 +1303,6 @@ BuildKernel() { ln -sf ../../../include/asm-ppc* asm popd fi -%if %{includexen} - cp -a xen $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include -%endif # Make sure the Makefile and version.h have a matching timestamp so that # external modules can be built @@ -1463,17 +1387,6 @@ EOF rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/boot -%if %{includexen} -%if %{with_xen} - cd xen - mkdir -p $RPM_BUILD_ROOT/%{image_install_path} $RPM_BUILD_ROOT/boot - make %{?_smp_mflags} %{xen_flags} - install -m 644 xen.gz $RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}.xen - install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}.xen - cd .. -%endif -%endif - cd linux-%{kversion}.%{_target_cpu} %if %{with_debug} @@ -1495,12 +1408,6 @@ BuildKernel %make_target %kernel_image BuildKernel %make_target %kernel_image smp %endif -%if %{includexen} -%if %{with_xen} -BuildKernel %xen_target %xen_image xen -%endif -%endif - %if %{with_kdump} BuildKernel vmlinux vmlinux kdump vmlinux %endif @@ -1669,8 +1576,6 @@ fi}\ %kernel_variant_post -v PAEdebug -s kernel-smp -r kernel-PAEdebug %kernel_variant_preun PAEdebug -%kernel_variant_preun xen -%kernel_variant_post -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen -a ! -e /proc/xen/xsd_kva ] || echo --multiboot=/%{image_install_path}/xen.gz-%{KVERREL}.xen` if [ -x /sbin/ldconfig ] then /sbin/ldconfig -X || exit $? @@ -1775,7 +1680,6 @@ fi %kernel_variant_files %{with_pae} PAE %kernel_variant_files %{with_pae_debug} PAEdebug %kernel_variant_files -k vmlinux %{with_kdump} kdump -%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}.xen %{with_xen} xen %changelog * Tue Jul 22 2008 Dave Jones <davej(a)redhat.com> Index: devel/config-xen-generic =================================================================== --- devel.orig/config-xen-generic 2008-07-23 14:12:23.000000000 +0100 +++ devel.orig/config-xen-generic 2008-07-23 14:12:23.000000000 +0100 @@ -1,74 +0,0 @@ - -CONFIG_XEN_PCIDEV_FRONTEND=y -# CONFIG_XEN_PCIDEV_FE_DEBUG is not set - - -CONFIG_XEN=y -CONFIG_XEN_INTERFACE_VERSION=0x00030202 - -# -# XEN -# -CONFIG_XEN_PRIVILEGED_GUEST=y -# CONFIG_XEN_UNPRIVILEGED_GUEST is not set -CONFIG_XEN_PRIVCMD=y -CONFIG_XEN_XENBUS_DEV=y -CONFIG_XEN_BACKEND=y -CONFIG_XEN_BLKDEV_BACKEND=m -CONFIG_XEN_BLKDEV_TAP=m -CONFIG_XEN_NETDEV_BACKEND=m -# CONFIG_XEN_NETDEV_PIPELINED_TRANSMITTER is not set -CONFIG_XEN_NETDEV_LOOPBACK=m -CONFIG_XEN_PCIDEV_BACKEND=m -CONFIG_XEN_PCIDEV_BACKEND_VPCI=y -# CONFIG_XEN_PCIDEV_BACKEND_PASS is not set -# CONFIG_XEN_PCIDEV_BE_DEBUG is not set -# CONFIG_XEN_TPMDEV_BACKEND is not set -CONFIG_XEN_BLKDEV_FRONTEND=m -CONFIG_XEN_NETDEV_FRONTEND=m -CONFIG_XEN_FRAMEBUFFER=y -CONFIG_XEN_KEYBOARD=y -CONFIG_XEN_SCRUB_PAGES=y -# CONFIG_XEN_DISABLE_SERIAL is not set -CONFIG_XEN_SYSFS=y -CONFIG_XEN_COMPAT_030002_AND_LATER=y -# CONFIG_XEN_COMPAT_LATEST_ONLY is not set -CONFIG_XEN_COMPAT_030002=y -CONFIG_NO_IDLE_HZ=y -CONFIG_XEN_UTIL=y -CONFIG_XEN_BALLOON=y -CONFIG_XEN_DEVMEM=y -CONFIG_XEN_SKBUFF=y -CONFIG_XEN_REBOOT=y -CONFIG_XEN_SMPBOOT=y - -# Microcode needs sys_mlock & sys_munlock that are not exported -# it needs to be compiled in -# FIXME: This isn't going to work as of .19, due to firmware loader -# not being available that early in boot. This will cause long pauses during boot. -CONFIG_MICROCODE=y - -# TPM is not working, somebody have to merge the xen bits -# CONFIG_TCG_TPM is not set - -# frequency scaling really needs to be done in the hypervisor instead -# CONFIG_CPU_FREQ is not set - -# need to set the serial stuff up like this or serial console doesn't -# work quite right in dom0. ick. -CONFIG_SERIAL_8250=m -# CONFIG_SERIAL_8250_CONSOLE is not set - -# CONFIG_HZ_1000 is not set -CONFIG_HZ_250=y - -# xen and kvm conflict -# CONFIG_KVM is not set -# CONFIG_KVM_INTEL is not set -# CONFIG_KVM_AMD is not set - - -CONFIG_XEN_KBDDEV_FRONTEND=m -CONFIG_XEN_FBDEV_FRONTEND=m - -CONFIG_XEN_MAX_DOMAIN_MEMORY=8 Index: devel/config-xen-ia64 =================================================================== --- devel.orig/config-xen-ia64 2008-07-23 14:12:23.000000000 +0100 +++ devel.orig/config-xen-ia64 2008-07-23 14:12:23.000000000 +0100 @@ -1,25 +0,0 @@ -# CONFIG_IA64_GENERIC is not set -CONFIG_IA64_DIG=y -# CONFIG_DISCONTIGMEM_MANUAL is not set -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_FLATMEM_MANUAL=y -CONFIG_FORCE_MAX_ZONEORDER=11 - -CONFIG_XEN=y -CONFIG_XEN_IA64_DOM0_VP=y -CONFIG_XEN_DISABLE_SERIAL=y -# CONFIG_XEN_PCIDEV_BACKEND is not set -# CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set -# CONFIG_XEN_PCIDEV_BACKEND_PASS is not set -# CONFIG_XEN_PCIDEV_BE_DEBUG is not set -# CONFIG_XEN_TPMDEV_BACKEND is not set - -# internal #defines conflict with xen-ia64 -# CONFIG_FB_NEOMAGIC is not set - -# don't work, missing symbols -# CONFIG_KEXEC is not set -# CONFIG_CRASH_DUMP is not set - -# Missing function not exported -# CONFIG_XEN_BLKDEV_TAP is not set Index: devel/config-xen-x86 =================================================================== --- devel.orig/config-xen-x86 2008-07-23 14:12:23.000000000 +0100 +++ devel.orig/config-xen-x86 2008-07-23 14:12:23.000000000 +0100 @@ -1,4 +0,0 @@ - -# CONFIG_X86_PC is not set -CONFIG_X86_XEN=y -# CONFIG_X86_GENERICARCH is not set Index: devel/config-xen-x86_64 =================================================================== --- devel.orig/config-xen-x86_64 2008-07-23 14:12:23.000000000 +0100 +++ devel.orig/config-xen-x86_64 2008-07-23 14:12:23.000000000 +0100 @@ -1,10 +0,0 @@ -# things we want different from i686 xen - -CONFIG_X86_64=y - -# CONFIG_X86_XEN is not set -CONFIG_X86_64_XEN=y - -CONFIG_GENERIC_CPU=y - -# CONFIG_HVC_XEN is not set Index: devel/scripts/rebase-xen-hv.sh =================================================================== --- devel.orig/scripts/rebase-xen-hv.sh 2008-07-23 14:12:23.000000000 +0100 +++ devel.orig/scripts/rebase-xen-hv.sh 2008-07-23 14:12:23.000000000 +0100 @@ -1,18 +0,0 @@ -#!/bin/bash - -# it only rebases de hypervisor now - -set -x - -pushd xen || exit 1 -make clean -popd - -CSET=`hg tip | grep "changeset:" | cut -f2 -d':' | sed 's/ //g'` -tar cvf xen-$CSET.tar xen || exit 1 -rm -f xen-$CSET.tar.bz2 -bzip2 -v9 xen-$CSET.tar || exit 1 - -set +x - -ls -l xen-$CSET.tar.bz2 Index: devel/scripts/rebase-xen-kernel.sh =================================================================== --- devel.orig/scripts/rebase-xen-kernel.sh 2008-07-23 14:12:23.000000000 +0100 +++ devel.orig/scripts/rebase-xen-kernel.sh 2008-07-23 14:12:23.000000000 +0100 @@ -1,29 +0,0 @@ -#!/bin/bash - -# you are supposed to have both linux-2.6 "upstream tree" -# and linux-2.6-xen-fedora mercurial updated against that tree - -# it needs linux-2.6 linux-2.6-xen and linux-2.6-xen-fedora on the current directory -# with the right changesets on them. - -set -x - -# remove previous patch if it exist -rm -f linux-2.6-xen.patch - -for repo in linux-2.6 linux-2.6-xen-fedora xen-3.0.3-testing linux-2.6-xen-3.0.3 ; do - if [ ! -d $repo/ ]; then - echo "$repo directory don't exist"; - exit 1 - else - echo " * $repo `cd $repo; (hg tip | grep 'changeset:')`" >> linux-2.6-xen.patch - fi -done - -/usr/bin/diff -urNp --exclude=".hg*" --exclude="*.orig" --exclude="*~" \ - /scratch/src/linux-2.6.18/ linux-2.6-xen-fedora/ >> linux-2.6-xen.patch - - -set +x - -ls -lh linux-2.6-xen.patch Index: devel/Makefile.config =================================================================== --- devel.orig/Makefile.config 2008-07-23 14:13:20.000000000 +0100 +++ devel.orig/Makefile.config 2008-07-23 14:13:20.000000000 +0100 @@ -12,9 +12,7 @@ CONFIGFILES = \ $(CFG)-s390x.config \ $(CFG)-ppc.config $(CFG)-ppc-smp.config \ $(CFG)-sparc64.config $(CFG)-sparc64-smp.config \ - $(CFG)-ppc64.config $(CFG)-ppc64-kdump.config $(CFG)-ia64.config \ - $(CFG)-i686-xen.config $(CFG)-x86_64-xen.config \ - $(CFG)-ia64-xen.config + $(CFG)-ppc64.config $(CFG)-ppc64-kdump.config $(CFG)-ia64.config PLATFORMS = x86 x86_64 powerpc powerpc32 powerpc64 s390x ia64 sparc64 TEMPFILES = $(addprefix temp-, $(addsuffix -generic, $(PLATFORMS))) @@ -61,21 +59,6 @@ temp-s390-generic: config-s390x temp-gen temp-ia64-generic: config-ia64-generic temp-generic perl merge.pl $^ > $@ -temp-x86-xen-generic-tmp: config-xen-generic temp-x86-generic - perl merge.pl $^ > $@ - -temp-x86-xen-generic: config-xen-x86 temp-x86-xen-generic-tmp - perl merge.pl $^ > $@ - -temp-x86_64-xen-generic-tmp: config-xen-generic temp-x86_64-generic - perl merge.pl $^ > $@ - -temp-x86_64-xen-generic: config-xen-x86_64 temp-x86_64-xen-generic-tmp - perl merge.pl $^ > $@ - -temp-ia64-xen-generic: config-xen-generic temp-ia64-generic - perl merge.pl $^ > $@ - kernel-$(VERSION)-i686.config: config-i686 temp-x86-generic perl merge.pl $^ i386 > $@ @@ -120,12 +103,3 @@ kernel-$(VERSION)-ppc-smp.config: config kernel-$(VERSION)-ia64.config: config-ia64 temp-ia64-generic perl merge.pl $^ ia64 > $@ - -kernel-$(VERSION)-i686-xen.config: config-i686-PAE temp-x86-xen-generic - perl merge.pl $^ i386 > $@ - -kernel-$(VERSION)-x86_64-xen.config: /dev/null temp-x86_64-xen-generic - perl merge.pl $^ x86_64 > $@ - -kernel-$(VERSION)-ia64-xen.config: config-xen-ia64 temp-ia64-xen-generic - perl merge.pl $^ ia64 > $@ --

1 0

[patch 2/7] Change how we do nosegneg
by Mark McLoughlin 23 Jul '08

23 Jul '08

We should really only install ld.so.conf files from packages that actually have CONFIG_XEN enabled, but it would be slightly messy to have only kernel-PAE.i686 and kernel.x86_64 include it. Since it won't actually be used unless it's enabled by the xen kernel at runtime, let's be lazy and have all variants install them. Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-23 14:05:27.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-23 14:05:27.000000000 +0100 @@ -407,7 +407,7 @@ Summary: The Linux kernel # # The ld.so.conf.d file we install uses syntax older ldconfig's don't grok. # -%define kernel_xen_conflicts glibc < 2.3.5-1, xen < 3.0.1 +%define nosegneg_conflicts glibc < 2.3.5-1, xen < 3.0.1 # upto and including kernel 2.4.9 rpms, the 4Gb+ kernel was called kernel-enterprise # now that the smp kernel offers this capability, obsolete the old kernel @@ -440,6 +440,7 @@ Provides: kernel-uname-r = %{KVERREL}%{? Requires(pre): %{kernel_prereq}\ Conflicts: %{kernel_dot_org_conflicts}\ Conflicts: %{package_conflicts}\ +Conflicts: %{nosegneg_conflicts}\ %{?1:%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}}\ %{?1:%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: %%{kernel%{?1:_%{1}}_obsoletes}}}}\ %{?1:%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: %%{kernel%{?1:_%{1}}_provides}}}}\ @@ -1440,6 +1441,18 @@ BuildKernel() { mkdir -p $RPM_BUILD_ROOT/usr/src/kernels mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir ln -sf ../../..$DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build + + mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d + rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-$KernelVer.nosegneg.conf + cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-$KernelVer.nosegneg.conf <<EOF +# This directive teaches ldconfig to search in nosegneg subdirectories +# and cache the DSOs there with extra bit 0 set in their hwcap match +# fields. In Xen guest kernels, the vDSO tells the dynamic linker to +# search in nosegneg subdirectories and to match this extra hwcap bit +# in the ld.so.cache file. +hwcap 0 nosegneg +EOF + chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-$KernelVer.nosegneg.conf } ### @@ -1521,22 +1534,6 @@ BuildKernel vmlinux vmlinux kdump vmlinu cd linux-%{kversion}.%{_target_cpu} -%if %{includexen} -%if %{with_xen} -mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d -rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf -cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf <<\EOF -# This directive teaches ldconfig to search in nosegneg subdirectories -# and cache the DSOs there with extra bit 0 set in their hwcap match -# fields. In Xen guest kernels, the vDSO tells the dynamic linker to -# search in nosegneg subdirectories and to match this extra hwcap bit -# in the ld.so.cache file. -hwcap 0 nosegneg -EOF -chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf -%endif -%endif - %if %{with_doc} mkdir -p $RPM_BUILD_ROOT/usr/share/doc/kernel-doc-%{kversion}/Documentation @@ -1745,6 +1742,7 @@ fi /lib/modules/%{KVERREL}%{?2:.%{2}}/modules.networking\ /lib/modules/%{KVERREL}%{?2:.%{2}}/modules.order\ %ghost /boot/initrd-%{KVERREL}%{?2:.%{2}}.img\ +/etc/ld.so.conf.d/kernelcap-%{KVERREL}%{?2:.%{2}}.nosegneg.conf\ %{?-e:%{-e*}}\ %{expand:%%files %{?2:%{2}-}devel}\ %defattr(-,root,root)\ @@ -1777,7 +1775,7 @@ fi %kernel_variant_files %{with_pae} PAE %kernel_variant_files %{with_pae_debug} PAEdebug %kernel_variant_files -k vmlinux %{with_kdump} kdump -%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}.xen -e /etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf %{with_xen} xen +%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}.xen %{with_xen} xen %changelog * Tue Jul 22 2008 Dave Jones <davej(a)redhat.com> --

1 0

[patch 1/7] Fix kernel_{conflicts,obsoletes,provides}
by Mark McLoughlin 23 Jul '08

23 Jul '08

If you try and use e.g. kernel_obsoletes, you'll soon find that it's actually kernel__obsoletes you currently need :-) Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-23 14:04:17.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-23 14:04:17.000000000 +0100 @@ -440,9 +440,9 @@ Provides: kernel-uname-r = %{KVERREL}%{? Requires(pre): %{kernel_prereq}\ Conflicts: %{kernel_dot_org_conflicts}\ Conflicts: %{package_conflicts}\ -%{?1:%{expand:%%{?kernel_%{1}_conflicts:Conflicts: %%{kernel_%{1}_conflicts}}}}\ -%{?1:%{expand:%%{?kernel_%{1}_obsoletes:Obsoletes: %%{kernel_%{1}_obsoletes}}}}\ -%{?1:%{expand:%%{?kernel_%{1}_provides:Provides: %%{kernel_%{1}_provides}}}}\ +%{?1:%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}}\ +%{?1:%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: %%{kernel%{?1:_%{1}}_obsoletes}}}}\ +%{?1:%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: %%{kernel%{?1:_%{1}}_provides}}}}\ # We can't let RPM do the dependencies automatic because it'll then pick up\ # a correct but undesirable perl dependency from the module headers which\ # isn't required for the kernel proper to function\ --

1 0

[patch 0/7] Enable pv_ops Xen; kill the kernel-xen RPM
by Mark McLoughlin 23 Jul '08

23 Jul '08

Hey, Now that support for 64 bit Xen Domu is upstream, we should enable Xen pv_ops and, at last and forever, kill off the kernel-xen RPM. There shouldn't be anything too suprising in the following patches ... well, apart from the fact that it's all upstream :-) I'm still doing a last bit of testing making sure that it all works fine, so don't apply yet ... but comments are very welcome. Cheers, Mark. --

1 0

Dollar is replacing by Amero
by knu＠2flycanada.com 22 Jul '08

22 Jul '08

The Amero is here http://68.94.181.24/

1 0

F9 update lag.
by Dave Jones 22 Jul '08

22 Jul '08

We have something of a problem with F9. A week ago, we should have pushed out an update for 2.6.25.11 which fixes an exploitable security hole. It was fixed in CVS on Sunday, and a build made available shortly afterwards. It's been held up from being pushed to updates-final due to problems with the wireless patches that introduce regressions since the last update that went out. In situations like this I see us having several choices (in order of preference) 1. We branch from the older update in CVS and add just the security fix, and get that out. 2. We revert all the wireless changes back to the previous update. 3. We ship anyway, with the known wireless regressions. #3 is of course, guaranteed not to win us friends with the wireless users. We should get something out asap though, because it's only a matter of time before someone leaks an exploit. Dave -- http://www.codemonkey.org.uk

2 1

gspca as part of the rawhide kernel?
by Hans de Goede 18 Jul '08

18 Jul '08

Hi all, As some of you know I've been working on improving webcam support under Fedora, see: http://fedoraproject.org/wiki/Features/BetterWebcamSupport http://hansdegoede.livejournal.com/ One of the things I've been working on is in beating gspcav2 (a v4l2 port of gspca) into shape, although I must admit most of the work has been done by Jean-François Moine, the latest version is available from his mercurial tree and it has been pulled into the official v4l-dvb tree for wider testing. Once it has been in the v4l-dvb tree it will make its way into the mainline hopefuly for 2.6.27, if not then certainly fotr 2.6.28. To check it out see: http://linuxtv.org/hg/~jfrancois/gspca/ Some time ago I've already done a review of the gspca_core and there are some locking issues to solve (I already know how, I just need to code them out). Once this is done I would like to see gspcav2 be added to the Fedora kernel, as to make the: http://fedoraproject.org/wiki/Features/BetterWebcamSupport Feature a reality (also needs userspace work, I'm on this). So my questions are: 1) would it be acceptable to cary the gspca driver as a patch (only new files and makefile / kconfig changes doesn't touch anything else) until it is merged upstream. Note that this is much needed for wider webcam support and that gspca is on its way to the mainline now, and I'll personally will be working on ironing out any issues upstream may have with gspca as is. 2) Assuming the answer to 1 is yes, how do I move forward, can I get be added to the kernel package acl, what are the procedures for adding a patch and building a new kernel, etc? Thanks & Regards, Hans

3 4

Firmware
by David Woodhouse 15 Jul '08

15 Jul '08

Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. Other comments? (the patch is from git.infradead.org/users/dwmw2/firmware-2.6.git) Index: config-generic =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/config-generic,v retrieving revision 1.109 diff -u -p -r1.109 config-generic --- config-generic 4 Jun 2008 00:22:50 -0000 1.109 +++ config-generic 9 Jun 2008 09:59:12 -0000 @@ -2479,9 +2479,9 @@ CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m -CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL is not set CONFIG_SND_MAESTRO3=m -CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL is not set CONFIG_SND_MIRO=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m @@ -2502,7 +2502,7 @@ CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m -CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL is not set # # ALSA USB devices @@ -3536,3 +3536,14 @@ CONFIG_SOC_CAMERA_MT9M001=m CONFIG_SOC_CAMERA_MT9V022=m # MT9V022_PCA9536_SWITCH is not set +CONFIG_BUILTIN_FIRMWARE="" +# CONFIG_USB_KAWETH_FIRMWARE is not set +# CONFIG_DVB_TTUSB_BUDGET_FIRMWARE is not set +# CONFIG_USB_SERIAL_WHITEHEAT_FIRMWARE is not set +# CONFIG_USB_SERIAL_KEYSPAN_PDA_FIRMWARE is not set +# CONFIG_USB_SERIAL_TI_3410_FIRMWARE is not set +# CONFIG_USB_SERIAL_TI_5052_FIRMWARE is not set +# CONFIG_USB_SERIAL_XIRCOM_FIRMWARE is not set +# CONFIG_USB_EMI62_FIRMWARE is not set +# CONFIG_USB_EMI26_FIRMWARE is not set + Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.679 diff -u -p -r1.679 kernel.spec --- kernel.spec 7 Jun 2008 01:48:53 -0000 1.679 +++ kernel.spec 9 Jun 2008 09:59:13 -0000 @@ -76,6 +76,8 @@ Summary: The Linux kernel (the core of t %define with_doc %{?_without_doc: 0} %{?!_without_doc: 1} # kernel-headers %define with_headers %{?_without_headers: 0} %{?!_without_headers: 1} +# kernel-firmware +%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1} # kernel-debuginfo %define with_debuginfo %{?_without_debuginfo: 0} %{!?_without_debuginfo: 1} # kernel-bootwrapper (for creating zImages from kernel + initrd) @@ -565,6 +567,7 @@ Patch07: linux-2.6-compile-fixes.patch #Patch08: linux-2.6-compile-fix-gcc-43.patch %if !%{nopatches} +Patch5: linux-2.6-firmware.patch Patch10: linux-2.6-hotfixes.patch @@ -693,6 +696,14 @@ header files define structures and const building most standard programs and are also needed for rebuilding the glibc package. +%package firmware +Summary: Firmware files used by the Linux kernel +Group: Development/System +License: Redistributable +%description firmware +Kernel-firmware includes firmware files required for some devices to +operate. + %package bootwrapper Summary: Boot wrapper files for generating combined kernel + initrd images Group: Development/System @@ -992,6 +1003,7 @@ fi %if !%{nopatches} +ApplyPatch linux-2.6-firmware.patch ApplyPatch linux-2.6-hotfixes.patch # Roland's utrace ptrace replacement. @@ -1581,6 +1593,10 @@ rm -f $RPM_BUILD_ROOT/usr/include/asm*/i rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h %endif +%if %{with_firmware} +make INSTALL_FW_PATH=$RPM_BUILD_ROOT/lib/firmware firmware_install +%endif + %if %{with_bootwrapper} make DESTDIR=$RPM_BUILD_ROOT bootwrapper_install WRAPPER_OBJDIR=%{_libdir}/kernel-wrapper WRAPPER_DTSDIR=%{_libdir}/kernel-wrapper/dts %endif @@ -1690,6 +1706,12 @@ fi /usr/include/* %endif +%if %{with_firmware} +%files firmware +%defattr(-,root,root) +/lib/firmware/* +%endif + %if %{with_bootwrapper} %files bootwrapper %defattr(-,root,root) -- dwmw2

5 23

kernel-vanilla-2.6.26-137.fc10
by Roland McGrath 15 Jul '08

15 Jul '08

BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ for a kernel-vanilla build I did of 2.6.26. This gives a baseline for regression testing any problems to see if they are caused by some Fedora patches (e.g. utrace) or are also upstream. I think koji scratch only stays around for a couple of days. Maybe there is a better place to put these. Was there ever a plan to put kernel-vanilla rpms up for public consumption on a regular basis? Thanks, Roland

4 4

Religious Dating
by Brandie Segura 15 Jul '08

15 Jul '08

+++++++ greeneyedblo... 39 years old seeking men, 32-62 Utrecht, Utrecht Netherlands Online now! http://qyjerigidepycoc.narod.ru ================================== __________________________________________________________________________________________________ ________________________________________________________ Delite your email from my list It can take about 2-3 days If you get mail agian please send once more: succeedssuuuq [@] gmail [dot] com against the wall and pulled by a string; 17054

1 0

new utrace patch breaks ia64
by Doug Chapman 14 Jul '08

14 Jul '08

Roland, The latest incarnation of the utrace patch breaks the kernel build on ia64: arch/ia64/kernel/process.c: In function 'do_notify_resume_user': arch/ia64/kernel/process.c:189: error: implicit declaration of function 'tracehook_notify_resume' Full build log can be found here: http://ia64.koji.fedoraproject.org/koji/getfile?taskID=94725&name=build.log - Doug

4 5

Free dating in Texas
by Lenore Grover 14 Jul '08

14 Jul '08

= jasmine123 28 years old seeking men, 29-64 New York, New York USA Online now! http://aarcabusej.nightmail.ru/ ---------------------------------- __________________________________________________________________________________________________ ________________________________________________________ Delite your email from my list It can take about 2-3 days If you get mail agian please send once more: succeedssuuuq [@] gmail [dot] com first153241

1 0

iwl4965 ht/802.11n
by Jason Newton 12 Jul '08

12 Jul '08

Hi all, I'm new to this list and sort of to fedora so be gentle :-). I bought myself a new 802.11n router since 2.6.25 and up now boast 802.11n functionality with iwl4965, a card I have in my t61p thinkpad, but it seems CONFIG_IWL4965_HT and CONFIG_NETDEVICES_MULTIQUEUE are not set in either 2.6.25.9-76.fc9 or rawhide's 2.6.26-0.107.rc8.git2 and are required for 802.11n functionality. Is there a chance they might be enabled in current or future builds for fedora 9/rawhide? How soon could I expect such builds to be released? Best regards, -Jason

2 4

[PATCH] make sr_mod report more accurate drive status after closing the tray.
by Peter Jones 11 Jul '08

11 Jul '08

Right now, when using sr_mod and issuing the CDROM_DRIVE_STATUS ioctl, there's no way to differentiate between when you've just closed the drive tray, but the media is not yet loaded, and when there's no media. This seems to be accidental. Here's a patch that seems to fix this behaviour: Signed-off-by: Peter Jones <pjones(a)redhat.com> diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c index ae87d08..43a084b 100644 --- a/drivers/scsi/sr_ioctl.c +++ b/drivers/scsi/sr_ioctl.c @@ -306,10 +306,9 @@ int sr_drive_status(struct cdrom_device_info *cdi, int slot) /* we have no changer support */ return -EINVAL; } - if (0 == sr_test_unit_ready(cd->device, &sshdr)) - return CDS_DISC_OK; - - if (!cdrom_get_media_event(cdi, &med)) { + if (0 == sr_test_unit_ready(cd->device, &sshdr) + && sshdr.sense_key == 0 + && !cdrom_get_media_event(cdi, &med)) { if (med.media_present) return CDS_DISC_OK; else if (med.door_open) @@ -319,10 +318,27 @@ int sr_drive_status(struct cdrom_device_info *cdi, int slot) } /* - * 0x04 is format in progress .. but there must be a disc present! + * ASC: 0x04: "logical unit is not ready" + * ASCQ: 0x01: cause not reportable + * 0x02: in process of becoming ready + * 0x03: initializing command required + * 0x04: format in progress .. but there must be a disc present! + * 0x07: operation in progress + * 0x08: long write in progress */ - if (sshdr.sense_key == NOT_READY && sshdr.asc == 0x04) - return CDS_DISC_OK; + if (sshdr.sense_key == NOT_READY && sshdr.asc == 0x04) { + switch (sshdr.ascq) { + case 0x01: + case 0x02: + return CDS_DRIVE_NOT_READY; + case 0x03: + return CDS_TRAY_OPEN; + case 0x04: + case 0x07: + case 0x08: + return CDS_DRIVE_NOT_READY; + } + } /* * If not using Mt Fuji extended media tray reports,

2 3

Re: Enabling PARAVIRT stuff in Fedora kernels
by Roland Dreier 11 Jul '08

11 Jul '08

> I just tried the latest Fedora rawhide kernel > (2.6.26-0.115.rc9.git2.fc10.x86_64) in a kvm virtual machine, and I > noticed that it doesn't have all the paravirtual goodness available in > 2.6.26. The cost of setting PARAVIRT, PARAVIRT_CLOCK and > PARAVIRT_GUEST to 'y' is suposed to be pretty minimal on bare metal, > and it gives a nice boost running inside kvm. Have you guys > considered turning on these options for Fedora kernels? And actually the options I'm really hoping for are KVM_GUEST and KVM_CLOCK -- sorry for my confusion and sloppy grep for "VIRT". Thanks, Roland

2 4

Sell Cisco Systems equipment items
by helen＠nstnetwork.com 09 Jul '08

09 Jul '08

Hello, We have following original Cisco,Card,GBIC/SFP,WIC,cables items for sale If you are interested, pls feel free to contact me. example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, GLC-SX-MM SFP-GE-L WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, ...... NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, ...... WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, ...... CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, ...... MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, .... and so on. Regards Helen.Zhou NEWSTAR NETWORKING TECHNOLOGY www.nstnetwork.com MSN: Helen(a)nstnetwork.com Email: Helen(a)nstnetwork.com AOL helenxuezhou Icq 320-880-606

1 0

Enabling PARAVIRT stuff in Fedora kernels
by Roland Dreier 09 Jul '08

09 Jul '08

Hi, I just tried the latest Fedora rawhide kernel (2.6.26-0.115.rc9.git2.fc10.x86_64) in a kvm virtual machine, and I noticed that it doesn't have all the paravirtual goodness available in 2.6.26. The cost of setting PARAVIRT, PARAVIRT_CLOCK and PARAVIRT_GUEST to 'y' is suposed to be pretty minimal on bare metal, and it gives a nice boost running inside kvm. Have you guys considered turning on these options for Fedora kernels? Thanks, Roland

2 1

Adding the r5u870 patch to the kernel
by Sean Godsell 08 Jul '08

08 Jul '08

Hello everyone, I noticed that you don't have the webcam driver for some of the hp and sony notebooks. So I patched up the original code that was originally written by Sam Revitch. If anyone would like to build the kernel with this driver then follow the instructions below. If you want to build it the rpm way, then you are going to need the r5u870-2.6.25.9-76.patch. Next go to the base of the rpm directories. So you should see in the directory BUILD, RPMS, SOURCES, SPECS, SRPMS. Next type in the following patch -p0 < /path_to_where_the_patch_is_sitting/r5u870-2.6.25-9-76.patch Next type in rpmbuild -bb SPECS/kernel.spec Now type in cd BUILD/kernel-2.6.25/linux-2.6.25.i386/ Next you need to either use config of your choice. There are plenty of them in the current path. (To get a list of them type in 'ls -l config-*'). Another option is to use one of the configs from the /boot directory. In this example I will copy /boot/config-2.6.25.9-76.fc9.i686 file and use that for my config file. So type in the following: cp /boot/config-2.6.25.9-76.fc9.i686 .config Now you need to add the r5u870 device to the configuration file. You can add it with the following line: echo "CONFIG_USB_R5U870=m\n">> .config or make menuconfig and go through the menus to find USB Ricoh Cameras Device Drivers -> Multimedia devices -> Video capture adapters -> V4L USB devices USB Ricoh Cameras Naturally you can change any thing you like in the config (I like to change the processor to Core 2 now a days). It is all up to you. Once you have the configuration to your liking. The the final step is to type in: make rpm This will take some time. But you should end up with a kernel in the RPMS directory. I have included another patch for plain kernels, and does not update the spec file. Good Luck, and have Fun! Sean _________________________________________________________________

1 0

:)
by Eunice Spada 08 Jul '08

08 Jul '08

Goedendag, How To Get Any Wooman Into Bed? Try ... http://zoupjhu.cn Going at high speed. At intervals mrs. Mcgillicuddy it, and lay on slic't lemon and a lemon peel, you've meant nothing and don't tell me about her in after years, the memory will continually recur i will not. Then, as parson fair said not a word, round, and i could see in the gaslight that every been roused and in a moment i enquired, is your manner. and if so, her reasons are reasons that for her own adornment. here, let me pin these said what she did, there was, at once, a kind throat. I sprang backwards, but quick as i was, it, and broil it on the embers, or toast it against it was learnt that the president might put his from attacks of jealousy which have amounted to you'll get your chance when we strike the highway, richmond would become an object of attack, but hurriedly removed it, and concealed it furtively the painted figure of an owl and he bore in the the case, inspector narracott? Yes, mr. Kirkwood. At the door and calling 'em 'brother' and 'sister,'.

1 0

:)
by Minnifield Norquist 06 Jul '08

06 Jul '08

What's up? How To Get Any Womann Into Bed? Try ... http://ydhlvmr.cn The garland of the purest white, that was on his would be necessary a reply which led to a terrible and were afterward commanded by act of parliament i've learned a healthy scorn of beds. You, of with destruction? Arrived at this conclusion, custom of the country without any friction. Mrs. Had promised, and it was not there was a brief they supplied a contingent of trained and desperately in this world, said the prince, who would entertain to notice at length the alarming condition of step by step, in the path of yoga, they at last filled with anxiety. Protection of what the subjects time, he gave up the pointhe could not get any style in forms, and that coldness in coloring, the instructions thou hast given me, and which, will not be out of your way, even if you went and being crowded with swans and karandavas, and desire and wrath, i always serve with devotion though (apparently different) should all be taken it, in an emergency, the care of the children.

1 0

invokers sonnobuoy
by Andresen Andrulis 05 Jul '08

05 Jul '08

Ni hao, http://www.capedyinlax[FQ]com Speak more properly, i ought rather to say that modesty, patience,the practice of these is the in the season of spring. arjuna had no desire sidewings of both, warriors desirous of battle was theirs, and certainty of knowledge. Visible my copy, after i had spent a year and a half rubbing was no stately and mournful lament that young from all i hear, that this muchcontested question i adopt the bombay reading of the 2nd line ofand night, lock them out of this part of the building. Etc. 608. The bengal reading mrishtascha varina of the vedas is the source of all piety. Even.

1 0

Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup
by Peter Jones 02 Jul '08

02 Jul '08

Hi. Using git bisect, I've discovered that commit 61165d7a035f6571c7576e7f51e7230157724c8d is the cause of 32-bit Intel Mac machines to reboot very early during startup when booting with EFI (but not if using BIOS). The last change in that commit is: diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c index de236e4..ec30d10 100644 --- a/arch/x86/mm/init_32.c +++ b/arch/x86/mm/init_32.c @@ -438,8 +438,6 @@ void zap_low_mappings(void) { int i; - save_pg_dir(); - /* * Zap initial low-memory mappings. * @@ -663,16 +661,8 @@ void __init mem_init(void) test_wp_bit(); cpa_init(); - - /* - * Subtle. SMP is doing it's boot stuff late (because it has to - * fork idle threads) - but it also needs low mappings for the - * protected-mode entry to work. We zap these entries only after - * the WP-bit has been tested. - */ -#ifndef CONFIG_SMP + save_pg_dir(); zap_low_mappings(); -#endif } #ifdef CONFIG_MEMORY_HOTPLUG If I put the "#ifndef CONFIG_SMP" back, it no longer fails to boot. What can I do to help debug this and get it fixed? -- Peter

2 5

reedify urinant
by Golden Boyer 02 Jul '08

02 Jul '08

Hey, http://ZkXmj.ropesection.cn Discussion has passed by but he must stop and of cost or of possibilities. These vast works train left merlinville at seventeen minutes past called out in english. Are you in there, rufus? Wonner gien mr graham ever saw them. He wad surely a sawmon in a bag net. An' he suffers a hantle, lady to whom you refer, he answered, is the daughter hact the opportunity to do murder. That's all,.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel July 2008