Re: Status of USB subsystem.
Oops. "Josef". Sorry; my spelling is atrocious. -- Terry Terry Lambert wrote: > > Riccardo Torrini wrote: > > On 03-May-2002 (13:22:48/GMT) Josef Karthauser wrote: > > > If anyone has any others that they've not revealed I'd like to know > > > please. > > > > I don't really know if is related, but gphoto2 doesn't work with my > > camera because of different linux<->freebsd usb channel usage (i think). > > I think this is the pipes problem; I think this was the first > thing in Joseph's "not working" list. It's well enough known > that there are people passing around patches for a workaround > (not a real fix) on -hackers for the VOIP hardware. > > According to the author of the patch and the VOIP drivers, it's > a problem in NetBSD that FreeBSD has inherited from having the > NetBSD framework. > > Also according to the same person, FreeBSD wouldn't have support > for the VOIP hardware at all, if it weren't for Joseph's work. > > Keep up the good work, Joseph! > > -- Terry > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of USB subsystem.
Riccardo Torrini wrote: > On 03-May-2002 (13:22:48/GMT) Josef Karthauser wrote: > > If anyone has any others that they've not revealed I'd like to know > > please. > > I don't really know if is related, but gphoto2 doesn't work with my > camera because of different linux<->freebsd usb channel usage (i think). I think this is the pipes problem; I think this was the first thing in Joseph's "not working" list. It's well enough known that there are people passing around patches for a workaround (not a real fix) on -hackers for the VOIP hardware. According to the author of the patch and the VOIP drivers, it's a problem in NetBSD that FreeBSD has inherited from having the NetBSD framework. Also according to the same person, FreeBSD wouldn't have support for the VOIP hardware at all, if it weren't for Joseph's work. Keep up the good work, Joseph! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of USB subsystem.
Joe, Thank you for taking the time to document your work-in-progress. I, for one, vastly appreciate what you're doing with the USB subsystem. I think a lot of our "community" issues could be greatly improved by more people doing exactly what you've done here. OK, back to the peanut gallery. ==ml On Fri, May 03, 2002 at 02:22:48PM +0100, Josef Karthauser wrote: > Dear all, > > I wanted to write to talk about the status of our USB stack in > -current because there has been some concern expressed over the > last week about where were are at with it, and more importantly > when the bugs are going to be ironed out. In particular there has > been a call to backout it all out back to a time when it worked. > > The background is that I've been porting the developments that > NetBSD has had into FreeBSD. In some cases we were two years behind > the state of the art. Today we're in a much better shape; most of > the controller code and device API is pretty much the same as > NetBSD's now, and that means that it should be relatively easy to > port the ehci USB2 controller code. A lot of the devices are now > synced too, although in general these have diverged over the period > a lot more than the controller code has. > > With a prevailing wind behind us we should now have been in a much > better position than we were when I started this work at the beginning > of the year. I think that we almost are, but there are a few bugs > that at the moment are eluding me, they could be because the bug > exists in NetBSD, or because of some FreeBSDism that I've not > realised, or just because of some code that's not been ported yet. > I don't know, but I am working on it. > > Here are the issues that I know about: > > * There's a disconnect bug, which I've tied down to interupt pipes not > cancelling properly when a device is unplugged. What this leads > to is an xfer that repeats, and locks the usb subsystem. I've > experienced it with uhub and ums, but it's possible, and probably, > that other devices are effected to. I made some headway on this > last night, and am in communication with the NetBSD author who's > helping me track the problem down. > > * There's an attach problem with the aue network device, and possibly > cue and kue too. This bug appears to have been around for a while > but has just been revealed by the recent memory manager changes. > It caused an attach time panic due to a bad memory allocation. > NetBSD's aue driver is different from ours and possibly doesn't > have the same problem. > > * Problems with ulpt. These appear to be in NetBSD also. I've got > a usb printer (HP office jet) and so potentially have the resources > to track the problem down, but as it's not entirely broken for all > users, this problem is less important than the two about IMO. > > If anyone has any others that they've not revealed I'd like to know > please. > > Also, if anyone particularly fancies helping out I'd be very grateful. > This is my first bout into the kernel, and although I've got all > the tools (remote debugger etc) I'm still a little slow with using > them. Mail me privately if you've got the time and energy to help > out. > > I'm prepared to back everything out if required, but my feeling is > that we're a stone's throw away from solving these problems; it's > just I'm throwing stones slower than a seasoned kernel hacker would. > It would be a shame to take such a large step backwards if it's > just a small step forwards that's required. > > The last known good date was just before the uma commit, i.e. > -D20020319\ 0900. Of course there have been some kernel infrastructure > changes since then so it's not just a matter of backing out the > sys/dev/usb directory to that date. There are some changes that > need to be retained, but they should be obvious for anyone who wants to > do this locally. > > I ask for your patience in getting to the bottom of these problems, and > wanted people to know that I am taking these issues serious, something > that might not be clear because I've not communicated much about it on > the lists. > > The good news is that once these issues have been resolved we are > in a good position to port the drivers that NetBSD have but we've > not seen yet. There are lots, like uaudio and uvisor, that we should > take avantage of. I hope that these will follow in the not too > distant future. > > Regards, > Joe > > p.s. I'm away for the weekend and so if you don't get a reply to any > email until the early part of next week it's not because I'm ignoring > you. -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.nostarch.com/abs_bsd.htm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Status of USB subsystem.
On 03-May-2002 (13:22:48/GMT) Josef Karthauser wrote: > If anyone has any others that they've not revealed I'd like to know > please. I don't really know if is related, but gphoto2 doesn't work with my camera because of different linux<->freebsd usb channel usage (i think). > Also, if anyone particularly fancies helping out I'd be very grateful. > [...] I'm prepared to back everything out if required ... If this can lead me to have a working usb driver for my digital camera (a cheaper agfa cl18) with gphoto2 (or something _much_ light, like a command line tool or a kernel driver to mount as a filesystem) I can help you with all my free time for testing any (non destructive) change. > I ask for your patience... You are welcome :-) Riccardo. PS: Please don't break uscanner, I use it with an Epson Perfection 1200U. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of USB subsystem.
In message <[EMAIL PROTECTED]>, Josef Karthauser writes: >I'm prepared to back everything out if required, but my feeling is >that we're a stone's throw away from solving these problems; it's >just I'm throwing stones slower than a seasoned kernel hacker would. Don't even think about it! I am very impressed that you have managed to make your way through the diff between FreeBSD and NetBSD, and I would expect that everybody with USB devices recognize the advantage of having a new USB-stuckee in FreeBSD totally balances out any inconvenience the current problems might cause. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Status of USB subsystem.
Dear all, I wanted to write to talk about the status of our USB stack in -current because there has been some concern expressed over the last week about where were are at with it, and more importantly when the bugs are going to be ironed out. In particular there has been a call to backout it all out back to a time when it worked. The background is that I've been porting the developments that NetBSD has had into FreeBSD. In some cases we were two years behind the state of the art. Today we're in a much better shape; most of the controller code and device API is pretty much the same as NetBSD's now, and that means that it should be relatively easy to port the ehci USB2 controller code. A lot of the devices are now synced too, although in general these have diverged over the period a lot more than the controller code has. With a prevailing wind behind us we should now have been in a much better position than we were when I started this work at the beginning of the year. I think that we almost are, but there are a few bugs that at the moment are eluding me, they could be because the bug exists in NetBSD, or because of some FreeBSDism that I've not realised, or just because of some code that's not been ported yet. I don't know, but I am working on it. Here are the issues that I know about: * There's a disconnect bug, which I've tied down to interupt pipes not cancelling properly when a device is unplugged. What this leads to is an xfer that repeats, and locks the usb subsystem. I've experienced it with uhub and ums, but it's possible, and probably, that other devices are effected to. I made some headway on this last night, and am in communication with the NetBSD author who's helping me track the problem down. * There's an attach problem with the aue network device, and possibly cue and kue too. This bug appears to have been around for a while but has just been revealed by the recent memory manager changes. It caused an attach time panic due to a bad memory allocation. NetBSD's aue driver is different from ours and possibly doesn't have the same problem. * Problems with ulpt. These appear to be in NetBSD also. I've got a usb printer (HP office jet) and so potentially have the resources to track the problem down, but as it's not entirely broken for all users, this problem is less important than the two about IMO. If anyone has any others that they've not revealed I'd like to know please. Also, if anyone particularly fancies helping out I'd be very grateful. This is my first bout into the kernel, and although I've got all the tools (remote debugger etc) I'm still a little slow with using them. Mail me privately if you've got the time and energy to help out. I'm prepared to back everything out if required, but my feeling is that we're a stone's throw away from solving these problems; it's just I'm throwing stones slower than a seasoned kernel hacker would. It would be a shame to take such a large step backwards if it's just a small step forwards that's required. The last known good date was just before the uma commit, i.e. -D20020319\ 0900. Of course there have been some kernel infrastructure changes since then so it's not just a matter of backing out the sys/dev/usb directory to that date. There are some changes that need to be retained, but they should be obvious for anyone who wants to do this locally. I ask for your patience in getting to the bottom of these problems, and wanted people to know that I am taking these issues serious, something that might not be clear because I've not communicated much about it on the lists. The good news is that once these issues have been resolved we are in a good position to port the drivers that NetBSD have but we've not seen yet. There are lots, like uaudio and uvisor, that we should take avantage of. I hope that these will follow in the not too distant future. Regards, Joe p.s. I'm away for the weekend and so if you don't get a reply to any email until the early part of next week it's not because I'm ignoring you. msg37984/pgp0.pgp Description: PGP signature