Re: USB stack (was: USB scanner unrecognized ...)
On Wed, 16 Jan 2008 16:20:42 +0200, Hasso Tepper wrote: > Simon 'corecode' Schubert wrote: >> Then devices should be probed and if there is a better match than ugen >> and if the ugen device is not open, it should be detached from ugen and >> attached to the new driver. Do you think this would be possible? > > There is a lot of things that suck in USB stack all BSD's are using at > the moment. This particular one is one of smallest ones I worry about > ;). > > There is a light though. There is a new USB stack known as HPS or > usb4bsd under development in FreeBSD. This particular problem is already > resolved there as well. Also two biggest problems with current stack - > sucking isochronous transfer support and sucking ugen. > > See these for details: > http://www.turbocat.net/~hselasky/usb4bsd/ > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/ usb/src/sys/dev/usb > > Volunteers to port needed ;P. See here: http://lists.freebsd.org/pipermail/freebsd-current/2008-January/081682.html Cheers, Mezz
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
On Wed, Jan 16, 2008 at 12:45:49PM +0200, Hasso Tepper wrote: > Francois Tigeot wrote: > > However, I found out there's was a difference between a standalone > > uscanner module and one compiled in the kernel. > > > > Standalone module: > > - original -> nothing > > - patched -> nothing > > Note that loading module doesn't rescan devices. You have to unplug and > plug again the device to rescanning happen. Ok. I'm not sure I did that with standalone modules. > > Uscanner in kernel: > > - original -> some kernel messages appear at startup > > > > # dmesg | grep uscanner > > uscanner0: > 2> on uhub0 uscanner0: at uhub0 port 2 (addr 2) disconnected > > uscanner0: detached > > It's a disconnect message only. > > > - patched -> some messages about ugen0 > > ugen0: at uhub0 port 2 (addr 2) disconnected > > ugen0: detached > > It's a disconnect message again only. And it shows that there is no need > for patch. Show me the full dmesg with verbose booting, please. I have put a dmesg dump here (uscanner in kernel) : http://www.wolfpond.org/dmesg-dfly-1.11-verbose.txt I have disconnected and reconnected the scanner just after dumping this file. There were only this additional messages: uscanner0: at uhub0 port 2 (addr 2) disconnected uscanner: ops removed uscanner0: detached -- Francois Tigeot
Re: USB stack
Hasso Tepper wrote: Simon 'corecode' Schubert wrote: Then devices should be probed and if there is a better match than ugen and if the ugen device is not open, it should be detached from ugen and attached to the new driver. Do you think this would be possible? There is a lot of things that suck in USB stack all BSD's are using at the moment. This particular one is one of smallest ones I worry about ;). There is a light though. There is a new USB stack known as HPS or usb4bsd under development in FreeBSD. This particular problem is already resolved there as well. Also two biggest problems with current stack - sucking isochronous transfer support and sucking ugen. See these for details: http://www.turbocat.net/~hselasky/usb4bsd/ http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/usb/src/sys/dev/usb Volunteers to port needed ;P. Here is a just-discovered oddity to also look for - though I haven't tested it on a 'real' *BSD yet. OS X 10.3.9 PowerBook 17" G4 - USB external kbd. -- If directly attached to the PowerBook, kbd works when coming out of 'sleep'. -- If kbd is attached via an unpowered USB hub, it is ignored when coming out of 'sleep', and has to be unplugged/replugged (either kbd-to-hub or the hub-to-PowerBook. This apparently relates to powering-down USB when sleeping, but I cannot fathom why there should be the difference exhibited once it awakens. Anyone able to test for that on DFLY? Bill
USB stack (was: USB scanner unrecognized ...)
Simon 'corecode' Schubert wrote: > Then devices should be probed and if there is a better match than ugen > and if the ugen device is not open, it should be detached from ugen and > attached to the new driver. Do you think this would be possible? There is a lot of things that suck in USB stack all BSD's are using at the moment. This particular one is one of smallest ones I worry about ;). There is a light though. There is a new USB stack known as HPS or usb4bsd under development in FreeBSD. This particular problem is already resolved there as well. Also two biggest problems with current stack - sucking isochronous transfer support and sucking ugen. See these for details: http://www.turbocat.net/~hselasky/usb4bsd/ http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/usb/src/sys/dev/usb Volunteers to port needed ;P. -- Hasso
Re: cvsup
On Wed, Jan 16, 2008 at 02:35:48AM +, Vincent Stemen wrote: > I am not clear how to access it. Try something like the attached script. Joerg update.sh Description: Bourne shell script
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
Sepherosa Ziehau wrote: On Jan 16, 2008 8:14 PM, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: Hasso Tepper wrote: Francois Tigeot wrote: However, I found out there's was a difference between a standalone uscanner module and one compiled in the kernel. Standalone module: - original -> nothing - patched -> nothing Note that loading module doesn't rescan devices. You have to unplug and plug again the device to rescanning happen. That sucks. We should do that, or at least operate on the previously detected devices. I think USB devices are different than PCI/cardbus devices; Unrecognized devices are taken by ugen. Then devices should be probed and if there is a better match than ugen and if the ugen device is not open, it should be detached from ugen and attached to the new driver. Do you think this would be possible? cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
On Jan 16, 2008 8:14 PM, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > Hasso Tepper wrote: > > Francois Tigeot wrote: > >> However, I found out there's was a difference between a standalone > >> uscanner module and one compiled in the kernel. > >> > >> Standalone module: > >> - original -> nothing > >> - patched -> nothing > > > > Note that loading module doesn't rescan devices. You have to unplug and > > plug again the device to rescanning happen. > > That sucks. We should do that, or at least operate on the previously > detected devices. I think USB devices are different than PCI/cardbus devices; Unrecognized devices are taken by ugen. Best Regards, sephe -- Live Free or Die
Re: cvsup
Vincent Stemen wrote: On 2008-01-15, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: Yes. There are a couple of mirrors which serve the cvs repo via rsync. For instance use chlamydia.fs.ei.tum.de. There are more, I guess. Thanks. I just checked the list, but most of the sites say they only mirror _Daily snapshots and official ISOs_. The rsync link to the one you mentioned, *chlamydia.fs.ei.tum.de*, does take you to a web page that says they have the cvsup collections, but they do not provide the full path to access them via rsync. I guess you're expected to find out with rsync yourself :) You know that you can get a listing with rsync? sweatshorts % rsync chlamydia.fs.ei.tum.de:: dflysnapDragonFlyBSD daily snapshots dragonfly-cvs DragonFly CVS repository freebsd-cvs FreeBSD CVS repository netbsd-cvs NetBSD CVS repository openbsd-cvs OpenBSD CVS repository sweatshorts % rsync chlamydia.fs.ei.tum.de::dragonfly-cvs drwxr-xr-x 512 2007/05/07 23:38:22 . -rwxrwxr-x 321 2003/07/15 06:17:23 fixme drwxrwxr-x1536 2008/01/16 12:33:43 CVSROOT drwxrwxr-x 512 2006/06/28 22:24:29 dfports drwxrwxr-x 512 2007/04/06 22:03:43 doc drwxrwxr-x 512 2007/12/21 06:39:21 site drwxrwxr-x 512 2004/06/18 13:23:48 src.sys.alpha.old drwxrwxr-x1024 2008/01/14 13:39:27 src Rsync is very slow when you tag a repo, because all the files change, but only one line. It's not really optimized for this task. But this doesn't happen very often, though. That is interesting. The rsync docs claim to be very fast and say this The rsync remote-update protocol allows rsync to transfer just the dif- ferences between two sets of files across the network connection, using an efficient checksum-search algorithm ... Well, of course in general it is fast. But CVS repos are a special case, consisting of hundreds of thousands of small RCS text files, which only get one line added when the repo is tagged. A general solution is bound to perform worse than a special case solution. I ran a test transfering 8 text files over the internet that are each about 450K and the performance seems pretty good when I changed just one line in each file. In my test I told rsync to use ssh, so the transfer was also encrypted. CVS repos are different: Imagine 10 files with an average size of 4-8KB. I think rsync has to do 10 network roundtrips to negotiate on the changesets to be sent. Total bytes sent: 31162 Total bytes received: 26842 Considering the fact that you only changed one line per file, that's quite a lot. Plus it doesn't say how many round trips it was needing. As you can see, it took 9 seconds for a full download, but only less than 1.5 seconds to update them. That seems reasonably fast to me. Is cvsup really faster than that? I am sceptical that it could be much faster. Yes, cvsup is way faster in such a case. Maybe not necessarily for 8 files, but for 800 for sure. It pipelines communication, so that there is no need to wait for immediate replies, thus saving network roundtrip times. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
Hasso Tepper wrote: Francois Tigeot wrote: However, I found out there's was a difference between a standalone uscanner module and one compiled in the kernel. Standalone module: - original -> nothing - patched -> nothing Note that loading module doesn't rescan devices. You have to unplug and plug again the device to rescanning happen. That sucks. We should do that, or at least operate on the previously detected devices. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
Francois Tigeot wrote: > However, I found out there's was a difference between a standalone > uscanner module and one compiled in the kernel. > > Standalone module: > - original -> nothing > - patched -> nothing Note that loading module doesn't rescan devices. You have to unplug and plug again the device to rescanning happen. > Uscanner in kernel: > - original -> some kernel messages appear at startup > > # dmesg | grep uscanner > uscanner0: 2> on uhub0 uscanner0: at uhub0 port 2 (addr 2) disconnected > uscanner0: detached It's a disconnect message only. > - patched -> some messages about ugen0 > ugen0: at uhub0 port 2 (addr 2) disconnected > ugen0: detached It's a disconnect message again only. And it shows that there is no need for patch. Show me the full dmesg with verbose booting, please. -- Hasso
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
On Tue, Jan 15, 2008 at 02:23:15PM +, Steve O'Hara-Smith wrote: > On Tue, 15 Jan 2008 15:02:33 +0100 > Matthias Schmidt <[EMAIL PROTECTED]> wrote: > > > * Steve O'Hara-Smith wrote: > > > > > > It may help to know that I am running a recent 1.11.0 (Jan 12 or > > > thereabouts) which does recognise my Perfection 1240U and it works > > > (quick test, I haven't had to use it in a while). > > > > Could you please post the dmesg output (if there is any :)? > > Sure - there's not a lot: > > uscanner0: on > uhub3 > > Also from usbdevs -v > > port 2 addr 6: full speed, self powered, config 1, Perfection1240 > (0x010b), EPSON(0x04b8), rev 1.04 On my setup, even with a kernel printing an uscanner0 line in dmesg, the scanner never appears in the usbdevs output: # usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical Mouse(0xc012), Logitech(0x046d), rev 13.20 Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered -- Francois Tigeot
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
On Tue, Jan 15, 2008 at 11:06:21AM +0100, Matthias Schmidt wrote:
>
> * Francois Tigeot wrote:
> >
> > I recently upgraded a machine from Dragonfly 1.10.1 to a recent
> > 1.11.0-DEVELOPMENT (as of today).
> >
> > An Epson Perfection 1240U USB scanner which worked fine with 1.10.1 is now
> > unrecognized. Pluging and unpluging the USB cord doesn't result in any
> > kernel message visible in dmesg.
>
> According to the sources we have an entry for your model:
>
> {{ USB_DEVICE(0x04b8, 0x010b) }, 0 }, /* Perfection 1240U/1240Photo */
>
> I'm currently preparing a mass update of USB quirks and it seems like
> the vendor ID of Epson has changed. The new entry from FreeBSD device
> ID list looks like this:
>
> {{ USB_DEVICE(0x03f8, 0x010b) }, 0 }, /* Epson Perfection 1240U / */
>
> Note the difference between 0x04b8 and 0x03f8. To check that I'm not
> wrong, you could change the ID in the uscanner source, recompile the
> module, reload it and check again if the scanner is detected:
I tried it and it didn't change anything: no kernel messages either.
However, I found out there's was a difference between a standalone
uscanner module and one compiled in the kernel.
Standalone module:
- original -> nothing
- patched -> nothing
Uscanner in kernel:
- original -> some kernel messages appear at startup
# dmesg | grep uscanner
uscanner0:
on uhub0
uscanner0: at uhub0 port 2 (addr 2) disconnected
uscanner0: detached
- patched -> some messages about ugen0
ugen0: at uhub0 port 2 (addr 2) disconnected
ugen0: detached
There's definitely something fishy going there.
--
Francois Tigeot
