kernel July 2008

kernel@lists.fedoraproject.org

34 participants
44 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel July 2008