usb patch
I have an RCA VR5320 digital voice recorder. It has a usb connector, but isn't recognized by SL 5.6. I get log messages of the form kernel: usb 1-5: new high speed USB device using ehci_hcd and address 4 kernel: usb 1-5: ep0 maxpacket = 32 This is evidently a known problem and there is a patch for drivers/usb/core/hub.c with the comment "A few devices (such as the RCA VR5220 voice recorder) are so non-compliant with the USB spec that they have invalid maxpacket sizes for endpoint 0. Nevertheless, as long as we can safely use them, we may as well do so." I think this patch is incorporated in 2.6.32 kernels. Q1: Am I correct in thinking that I would have to compile a whole new kernel, as opposed to just a module, to incorporate a patch to hub.c? Q2: Is there any sort of module or userspace hack I could try instead? I don't want to get into a position of maintaining my own kernel. I'd rather wait until I catch up with 2.6.32 and impose on friends with newer kernels or windows machines in the meantime. Thanks. Stephen Isard
Re: usb patch
On Sunday, October 30, 2011, Stephen Isard elucidated thus: > I have an RCA VR5320 digital voice recorder. It has a usb connector, > but isn't recognized by SL 5.6. I get log messages of the form > > kernel: usb 1-5: new high speed USB device using ehci_hcd and address > 4 kernel: usb 1-5: ep0 maxpacket = 32 > > This is evidently a known problem and there is a patch for > drivers/usb/core/hub.c with the comment "A few devices (such as the > RCA VR5220 voice recorder) are so non-compliant with the USB spec > that they have invalid maxpacket sizes for endpoint 0. > Nevertheless, as long as we can safely use them, we may as well do > so." I think this patch is incorporated in 2.6.32 kernels. > > Q1: Am I correct in thinking that I would have to compile a whole new > kernel, as opposed to just a module, to incorporate a patch to hub.c? > > Q2: Is there any sort of module or userspace hack I could try > instead? > > I don't want to get into a position of maintaining my own kernel. > I'd rather wait until I catch up with 2.6.32 and impose on friends > with newer kernels or windows machines in the meantime. A1: Yes, it is a single module, but you'd need to pull the source from the new kernel, since it is a kernel module. You may be able compile it with the source of the current kernel, but since you're pulling from a new kernel, it might have dependencies in the newer kernel. In other words, you're welcome to try. A2: No userspace hack that I know of, as USB operations are a kernel- level thing. j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A
Re: usb patch
On 30 October 2011 17:55, Stephen Isard <7p03xy...@sneakemail.com> wrote: > I have an RCA VR5320 digital voice recorder. It has a usb connector, but > isn't recognized by SL 5.6. > I don't want to get into a position of maintaining my own kernel. I'd > rather wait until I catch up with 2.6.32 and impose on friends with newer > kernels or windows machines in the meantime. Hi Stephen, You will have a very long wait. The SL 5.x kernels will remain to be based on 2.6.18 until EOL. ;) That is how TUV maintain a stable kernel ABI for the life of EL5. If you would like to have a SL kernel based on 2.6.32, please install SL 6.x :) Regards, Alan.
Re: usb patch
On Sun, Oct 30, 2011 at 2:00 PM, Alan Bartlett wrote: > On 30 October 2011 17:55, Stephen Isard <7p03xy...@sneakemail.com> wrote: >> I have an RCA VR5320 digital voice recorder. It has a usb connector, but >> isn't recognized by SL 5.6. > > > >> I don't want to get into a position of maintaining my own kernel. I'd >> rather wait until I catch up with 2.6.32 and impose on friends with newer >> kernels or windows machines in the meantime. > > Hi Stephen, > > You will have a very long wait. The SL 5.x kernels will remain to be > based on 2.6.18 until EOL. ;) That is how TUV maintain a stable kernel > ABI for the life of EL5. > > If you would like to have a SL kernel based on 2.6.32, please install SL 6.x > :) > > Regards, > Alan. I was rather surprised that Alan did not mention ELRepo's kernel-ml. :-O kernel-ml-2.6.35 does have the patch referenced here: https://lkml.org/lkml/2010/11/19/609 I should also note that kernel-ml is not for production use but it's been quite stable and Alan has been doing a good job of keeping it up to date. :-) http://elrepo.org/tiki/kernel-ml Akemi
Re: usb patch
On Sun, 30 Oct 2011 21:00:39 +, Alan Bartlett wrote: > > >> I don't want to get into a position of maintaining my own kernel. I'd >> rather wait until I catch up with 2.6.32 and impose on friends with newer >> kernels or windows machines in the meantime. > >Hi Stephen, > >You will have a very long wait. The SL 5.x kernels will remain to be >based on 2.6.18 until EOL. ;) That is how TUV maintain a stable kernel >ABI for the life of EL5. >If you would like to have a SL kernel based on 2.6.32, please install SL 6.x Right, I really meant "until I go over to SL6". There are two reasons I haven't yet: first, up until now, SL5 has been doing everything I've asked of it and second, I have two machines that I'd like to run the same operating system on for convenience, and one of them is a non-pae laptop, that, so far, SL6 won't run on. However, there is this cool guy named Alan Bartlett who says on the ELREPO list that he is getting close to producing a non-pae kernel for SL6 :-) . So I had been thinking of switching over when he does. Regards, Stephen Isard
Re: usb patch
On Sun, 30 Oct 2011 15:02:47 -0700, Akemi Yagi wrote: >> If you would like to have a SL kernel based on 2.6.32, please install SL 6.x :) >> >> Regards, >> Alan. > >I was rather surprised that Alan did not mention ELRepo's kernel-ml. :-O > >kernel-ml-2.6.35 does have the patch referenced here: > >https://lkml.org/lkml/2010/11/19/609 > >I should also note that kernel-ml is not for production use but it's >been quite stable and Alan has been doing a good job of keeping it up >to date. :-) > >http://elrepo.org/tiki/kernel-ml Thanks very much, Akemi. That looks like a good solution apart from the known bug in iptables, which is a bit scary. I'll have to check into whether I use any of the commands that trigger the bug and cause iptables to stop working. Regards, Stephen Isard
Re: usb patch
On 10/30/2011 03:02 PM, Akemi Yagi wrote: On Sun, Oct 30, 2011 at 2:00 PM, Alan Bartlett wrote: On 30 October 2011 17:55, Stephen Isard<7p03xy...@sneakemail.com> wrote: I have an RCA VR5320 digital voice recorder. It has a usb connector, but isn't recognized by SL 5.6. I don't want to get into a position of maintaining my own kernel. I'd rather wait until I catch up with 2.6.32 and impose on friends with newer kernels or windows machines in the meantime. Hi Stephen, You will have a very long wait. The SL 5.x kernels will remain to be based on 2.6.18 until EOL. ;) That is how TUV maintain a stable kernel ABI for the life of EL5. If you would like to have a SL kernel based on 2.6.32, please install SL 6.x :) Regards, Alan. I was rather surprised that Alan did not mention ELRepo's kernel-ml. :-O kernel-ml-2.6.35 does have the patch referenced here: https://lkml.org/lkml/2010/11/19/609 I should also note that kernel-ml is not for production use but it's been quite stable and Alan has been doing a good job of keeping it up to date. :-) http://elrepo.org/tiki/kernel-ml Akemi Could you kindly clarify what you mean by "kernel-ml is not for production use" in reference to kernel 2.6.35? From URL: http://www.kernel.org/ as of 31 Oct 2011: stable: 3.0.4 2011-08-29 stable: 2.6.39.42011-08-03 stable: 2.6.38.82011-06-03 stable: 2.6.37.62011-03-27 longterm: 2.6.35.14 2011-08-01 longterm: 2.6.34.10 2011-06-26 longterm: 2.6.33.19 2011-08-29 longterm: 2.6.32.46 2011-08-29 longterm: 2.6.27.59 2011-04-30 Based upon the above, 2.6.35 appears to in the longterm (long in the tooth?) stable branch. Is the "not for production use" in reference to not having the upstream vendor (why is everyone so loath to use the name Red Hat that is all over the source code for SL?) kernel application binary interface for EL 5? Yasha Karant
Re: usb patch
On Mon, 2011-10-31 at 17:24 -0700, Yasha Karant wrote: > (why is everyone so loath to use the name Red Hat that > is all over the source code for SL?) Because Red Hat lawyers badly frightened (bullied probably) Centos and might have done the same to SL too. Red Hat does not want recompilations of its sources being regarded by potential customers as having a Red Hat connection. Paul England EU.
Re: usb patch
On 10/31/2011 07:10 PM, Always Learning wrote: On Mon, 2011-10-31 at 17:24 -0700, Yasha Karant wrote: (why is everyone so loath to use the name Red Hat that is all over the source code for SL?) Because Red Hat lawyers badly frightened (bullied probably) Centos and might have done the same to SL too. Red Hat does not want recompilations of its sources being regarded by potential customers as having a Red Hat connection. Paul England EU. No connection -- just the actual source under the GPL and Linux licenses. Red Hat is required under these licenses to release the full source, including any source (scripts) required to build the full binary executables that are covered by either license -- that excludes the trademark art work (logos). The release requirement includes updates and modifications. What is wrong with discussing the name Red Hat given these licenses? Yasha Karant
Re: usb patch
On Mon, Oct 31, 2011 at 7:23 PM, Yasha Karant wrote: > On 10/31/2011 07:10 PM, Always Learning wrote: >> >> On Mon, 2011-10-31 at 17:24 -0700, Yasha Karant wrote: >> >>> (why is everyone so loath to use the name Red Hat that >>> is all over the source code for SL?) I ask everyone NOT to post followups to this thread/branch. This thread is about "usb patch". The topic was not only hijacked but also it is no longer technique-related discussion. As I quoted Troy's post sometime ago, the SL mailing list is not the place to talk about non-technical stuff. Thanks for your cooperation, Akemi
kernel-ml is not for production use (was: Re: usb patch)
On 10/30/2011 03:02 PM, Akemi Yagi wrote: > On Sun, Oct 30, 2011 at 2:00 PM, Alan Bartlett wrote: >> On 30 October 2011 17:55, Stephen Isard<7p03xy...@sneakemail.com> wrote: >>> I have an RCA VR5320 digital voice recorder. It has a usb connector, >>> but >>> isn't recognized by SL 5.6. >> >> >>kernel-ml is not for production use >>> I don't want to get into a position of maintaining my own kernel. I'd >>> rather wait until I catch up with 2.6.32 and impose on friends with >>> newer >>> kernels or windows machines in the meantime. >> >> Hi Stephen, >> >> You will have a very long wait. The SL 5.x kernels will remain to be >> based on 2.6.18 until EOL. ;) That is how TUV maintain a stable kernel >> ABI for the life of EL5. >> >> If you would like to have a SL kernel based on 2.6.32, please install >> SL 6.x :) >> >> Regards, Alan. > > I was rather surprised that Alan did not mention ELRepo's kernel-ml. :-O > > kernel-ml-2.6.35 does have the patch referenced here: > > https://lkml.org/lkml/2010/11/19/609 > > I should also note that kernel-ml is not for production use but it's > been quite stable and Alan has been doing a good job of keeping it up > to date. :-) > > http://elrepo.org/tiki/kernel-ml > > Akemi NB: In response to Akemi Yagi, I have removed any commentary or questions that are not pure technology -- no scientific, or fundamental engineering questions, including any relation to the ACM Code of Ethics or other societal relevance; pure technology discussions seem to be the only thing allowed on this list. The following post is pure technology. In the future, I will not be baited by responses, nor will I address any issue on this list other than technology. I have done a search for "production" on http://elrepo.org/tiki/FAQ, with one result: 2. What is the advantage of a kABI-tracking kmod over a DKMS enabled driver Dynamic Kernel Module Support (DKMS) is another packaging method for delivering automatic 3rd party kernel driver updates. The main disadvantage of DKMS for Enterprise Linux is that the driver is automatically recompiled (by the DKMS utility) for each new kernel meaning that the system must contain the appropriate development packages and compiler, something that is not always desirable on a production Enterprise Linux system. Is the above all you mean by "kernel-ml is not for production use" in reference to kernel 2.6.35? If so, can kABI-tracking kmod be disabled, using only the stable production upstream vendor methods? From URL: http://www.kernel.org/ as of 31 Oct 2011: stable: 3.0.4 2011-08-29 stable: 2.6.39.4 2011-08-03 stable: 2.6.38.8 2011-06-03 stable: 2.6.37.6 2011-03-27 longterm: 2.6.35.14 2011-08-01 longterm: 2.6.34.10 2011-06-26 longterm: 2.6.33.19 2011-08-29 longterm: 2.6.32.46 2011-08-29 longterm: 2.6.27.59 2011-04-30 Based upon the above, 2.6.35 appears to in the longterm (long in the tooth?) stable branch. Is the "not for production use" in reference to not having the upstream vendor binary interface for EL 5 or something else? Yasha Karant
Re: kernel-ml is not for production use (was: Re: usb patch)
On Mon, Oct 31, 2011 at 8:34 PM, Yasha Karant wrote: > On 10/30/2011 03:02 PM, Akemi Yagi wrote: >> I should also note that kernel-ml is not for production use but it's >> been quite stable and Alan has been doing a good job of keeping it up >> to date. :-) >> >> http://elrepo.org/tiki/kernel-ml >> >> Akemi > I have done a search for "production" on http://elrepo.org/tiki/FAQ, with > one result: > > 2. What is the advantage of a kABI-tracking kmod over a DKMS enabled driver > Dynamic Kernel Module Support (DKMS) is another packaging method for > delivering automatic 3rd party kernel driver updates. The main disadvantage > of DKMS for Enterprise Linux is that the driver is automatically recompiled > (by the DKMS utility) for each new kernel meaning that the system must > contain the appropriate development packages and compiler, something that is > not always desirable on a production Enterprise Linux system. > > Is the above all you mean by "kernel-ml is not for > production use" in reference to kernel 2.6.35? No, I was not referring to the mainline kernel available from kernel.org. It was about the *kernel-ml* package from elrepo.org. I was hoping everybody would read the link I provided in my post before using the kernel-ml package. Here once again: http://elrepo.org/tiki/kernel-ml In the Notes section: "These packages are provided As-Is with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service." That is what meant by "not for production use". Of course you can use it as far as you know what you are doing/using. The kernel-ml package was intended for hardware testing that may not be covered by the kmod packages. However, further discussion regarding the ELRepo packages must go to the elrepo mailing lists: http://elrepo.org/tiki/MailingLists Akemi
