Peter Toth | 2 May 06:40 2010
Picon

Re: usb/146104: Samsung YP-U4 mp3 player USB_ERR_TIMEOUT

The following reply was made to PR usb/146104; it has been noted by GNATS.

From: "Peter Toth" <peter.toth198 <at> gmail.com>
To: bug-followup <at> freebsd.org, peter.toth198 <at> gmail.com
Cc:  
Subject: Re: usb/146104: Samsung YP-U4 mp3 player USB_ERR_TIMEOUT
Date: Sun, 02 May 2010 16:13:46 +1200

 I will install 8 stable on a spare box and report back.
FreeBSD bugmaster | 3 May 13:08 2010
Picon

Current problem reports assigned to freebsd-usb <at> FreeBSD.org

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o usb/146153   usb        [axe][usb] Hosts in network doesn't receive any packet
o usb/146104   usb        Samsung YP-U4 mp3 player USB_ERR_TIMEOUT
o usb/146054   usb        urtw driver potentially out of date
o usb/145513   usb        [usb8] New USB stack: no new devices after forced usb 
o usb/145455   usb        [usb8] [patch] USB debug support cannot be disabled
o usb/145415   usb        [umass] USB card reader does not create slices nodes
o usb/145265   usb        [patch] Freecom USB-IDE bridge
o usb/145237   usb        [usbdevs] [patch] Add support for Matrix Orbital MOU d
o usb/145184   usb        GENERIC can't mount root from USB on Asus EEE
o usb/145165   usb        [keyboard] ukbd_set_leds_callback: error=USB_ERR_STALL
f kern/144938  usb        [keyboard] [boot] Boot Failure with Apple (MB869LL/A) 
o usb/144751   usb        [ukbd] [usb8] kernel without keyboard support won't co
o usb/144423   usb        [usb8] [patch] if_run panic with USB-N13
o usb/144414   usb        [keyboard] [patch] Apple "Fn" key doesn't work properl
o usb/144387   usb        [run] [panic] if_run panic
f usb/144332   usb        [build] Kernel compile fails when aue is enabled but n
o usb/144043   usb        [umass] USB DLT tape drive throws random errors
o usb/143790   usb        [boot] can not boot from usb hdd
f usb/143634   usb        [umass] [usb8] Jetflash USB flash stick fails to mount
f usb/143620   usb        [cdce] [usb8] the module if_cdce doesn't support my Op
o usb/143448   usb        [usbdevs] [usb8] [patch] QUIRK: JMicron JM20336 USB/SA
(Continue reading)

hi5 | 4 May 17:04 2010

Jennifer has sent you a hi5 Friend Request


   hi5 Friend Request from Jennifer
   Hi ,
   I'd like to add you to my hi5 friends network. You have to confirm
   that we are friends, and we'll each get to meet more people. Please
   approve or reject my request by accessing the hi5 web site:
   [1]View Friend Request»
   Thanks,
   Jennifer

                         [2][FFVbfc132550-01.jpg] 

   ------------------------------------------------------
   Copyright 2002-2010 hi5 Networks, Inc. All rights reserved.
   55 Second Street, Suite 400, San Francisco, CA 94105
   [3]Privacy Policy | [4]Unsubscribe | [5]Terms of Service
   [to.do?loginid=&amp;smid=T0xEX1NNSUQ9XzIwN18mVkVSU0lPTj0xJkNPTlRBSU5TX
   0FEPWZhbHNlJlRPX0lEPTQ3MDk5MDgyNiZEQVRFX1NFTlQ9MjAxMDA0MjMwNyZTVUJUWVB
   FPSZNSUQ9YzBMM1p1OFRoSFVBV0s1N2RmUUQ3MjQwOTU5NzgmVFlQRT0yMDc.]

References

   1. http://www.myfreecams.com/?baf=3136810
   2. http://www.myfreecams.com/?baf=3136810
   3. http://www.myfreecams.com/?baf=3136810
   4. http://www.myfreecams.com/?baf=3136810
   5. http://www.myfreecams.com/?baf=3136810
Mike Tancsa | 4 May 22:27 2010
Picon

Re: USB serial device naming

At 04:48 AM 12/14/2009, Hans Petter Selasky wrote:
>On Monday 14 December 2009 08:42:04 Ed Schouten wrote:
> > Hello Trevor,
> >
> > * Trevor Blackwell <tlb <at> tlb.org> wrote:
> > > I can't seem to find a way to match USB serial ports & tty names. I
> > > have two serial USB devices, which I can distinguish easily from
> > > "usbconfig show_ifdrv"
> > >
> > >     <snip>
> > >
> > > and they result in two ttys:
> > >     /dev/cuaU0
> > >     /dev/cuaU1
> >
> > Be sure to keep in mind: the `real' TTY devices are ttyU0 and ttyU1. The
> > cua* devices are callout devices, which unlike the tty* devices don't
> > wait for a carrier detect signal during open().
> >
> > My opinion is that the USB serial driver shouldn't use a bitmask to keep
> > track of which unit number are available, because we've got a nice KPI
> > for that:
> >
> >       http://www.freebsd.org/cgi/man.cgi?query=new_unrhdr
> >
> > Unfortunately I cannot answer your question. Hopefully Hans can. ;-)
>
>That's OK, but the real problem is that TTY is not a visible child of UPLCOM
>for example. I would suggest adding a new IOCTL or maybe you have a better
>idea, where we can pass the "device_get_nameunit()" string, and then TTY can
(Continue reading)

Hans Petter Selasky | 5 May 09:52 2010
X-Face
Picon

Re: USB serial device naming

Hi,

Maybe you can make PR on the issue and assign it to USB. Currently there is no 
way of knowing which /dev/cuaUXXX belongs to which USB device. Probably we can 
add the USB bus and address number as a part of the device coordinates. So 
that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries. And then we can also 
remove the current unit number allocation structure I guess, if we use:

/dev/cuaU1.1.<iface_number>.<optional_sub_modem_unit>

The only problem is: Will we break any existing applications?

The second problem was that the USB attach event was generated before the 
modem was probed and the umodem and other modem drivers do not provide any 
information about their USB address in the pnpinfo. This can be fixed.

Old pnpinfo:

dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 
sernum="" release=0x0200 intclass=0x03 intsubclass=0x01

Suggested new pnpinfo (which is available from devd.conf I guess)

dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 
sernum="" release=0x0200 intclass=0x03 intsubclass=0x01 bus=1 addr=2 
ifaceidx=0

What do you think?

--HPS
(Continue reading)

Milan Obuch | 5 May 10:46 2010
X-Face
Picon

Re: USB serial device naming

On Wednesday 05 May 2010 09:52:15 Hans Petter Selasky wrote:
> Hi,
>
> Maybe you can make PR on the issue and assign it to USB. Currently there is
> no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably
> we can add the USB bus and address number as a part of the device
> coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries.
> And then we can also remove the current unit number allocation structure I
> guess, if we use:
>
> /dev/cuaU1.1.<iface_number>.<optional_sub_modem_unit>
>
> The only problem is: Will we break any existing applications?
>

Well, yes, to some extent :) Problem with this naming convention is name 
changes with every port change - that is, if you pull USB cable out and plug 
it in another port. There was already some older thread about naming on 
freebsd-usb list (end of April 2009). But if devd receives all necessary 
informations in attach event, then it is possible to rewrite config files or 
create symlink in /dev directory or something like this to handle this 
situation.

> The second problem was that the USB attach event was generated before the
> modem was probed and the umodem and other modem drivers do not provide any
> information about their USB address in the pnpinfo. This can be fixed.
>
> Old pnpinfo:
>
> dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00
(Continue reading)

Alexandr Rybalko | 5 May 11:18 2010
Picon

Re: USB serial device naming

Hi,

On Wed, 5 May 2010 10:46:30 +0200
Milan Obuch <freebsd-usb <at> dino.sk> wrote:

>> On Wednesday 05 May 2010 09:52:15 Hans Petter Selasky wrote:
>> > Hi,
>> >
>> > Maybe you can make PR on the issue and assign it to USB. Currently there is
>> > no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably
>> > we can add the USB bus and address number as a part of the device
>> > coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries.
>> > And then we can also remove the current unit number allocation structure I
>> > guess, if we use:
>> >
>> > /dev/cuaU1.1.<iface_number>.<optional_sub_modem_unit>
>> >
>> > The only problem is: Will we break any existing applications?
>> >
>> 
>> Well, yes, to some extent :) Problem with this naming convention is name 
>> changes with every port change - that is, if you pull USB cable out and plug 
>> it in another port. There was already some older thread about naming on 
>> freebsd-usb list (end of April 2009). But if devd receives all necessary 
>> informations in attach event, then it is possible to rewrite config files or 
>> create symlink in /dev directory or something like this to handle this 
>> situation.

I think better way is use device connection path in name.
User know to which port of hub they attach device, so name like /dev/cuaU.h0p1.h2p3 (root hub 0, port 1, hub
(Continue reading)

Hans Petter Selasky | 5 May 21:57 2010
X-Face
Picon

Re: USB serial device naming

Hi,

Thanks for all good ideas. Can you give some feedback on the following 
solution:

http://p4web.freebsd.org/ <at>  <at> 177779?ac=10

--HPS
Peter Toth | 6 May 09:50 2010
Picon

Re: usb/146104: Samsung YP-U4 mp3 player USB_ERR_TIMEOUT

The following reply was made to PR usb/146104; it has been noted by GNATS.

From: "Peter Toth" <peter.toth198 <at> gmail.com>
To: bug-followup <at> freebsd.org, peter.toth198 <at> gmail.com
Cc:  
Subject: Re: usb/146104: Samsung YP-U4 mp3 player USB_ERR_TIMEOUT
Date: Thu, 06 May 2010 19:44:36 +1200

 Just managed to try it on FreeBSD 8.0-STABLE/i386.

 Works fine, although it shows some errors, see bellow.

 
 ugen4.2: <Linux 2.4.20-stmp36xx with stmp36xx_udc> at usbus4
 umass0: <Linux 2.4.20-stmp36xx with stmp36xx_udc USB Mass Storage, class  
 0/0, rev 2.00/2.29, addr 2> on usbus4
 umass0:  SCSI over Bulk-Only; quirks = 0x0000
 umass0:0:0:-1: Attached to scbus0
 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
 da0: <Samsung YP-U4 0229> Removable Direct Access SCSI-2 device
 da0: 40.000MB/s transfers
 da0: 3816MB (7816992 512 byte sectors: 255H 63S/T 486C)
 (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0
 (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:c,2 (Write error -  
 auto reallocation failed)
 (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0
 (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:c,2 (Write error -  
 auto reallocation failed)
 (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0
 (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:c,2 (Write error -  
(Continue reading)

Hans Petter Selasky | 6 May 10:44 2010
X-Face
Picon

Re: usb/146104: Samsung YP-U4 mp3 player USB_ERR_TIMEOUT

On Thursday 06 May 2010 09:50:03 Peter Toth wrote:
> The following reply was made to PR usb/146104; it has been noted by GNATS.
> 
> From: "Peter Toth" <peter.toth198 <at> gmail.com>
> To: bug-followup <at> freebsd.org, peter.toth198 <at> gmail.com
> Cc:
> Subject: Re: usb/146104: Samsung YP-U4 mp3 player USB_ERR_TIMEOUT
> Date: Thu, 06 May 2010 19:44:36 +1200
> 
>  Just managed to try it on FreeBSD 8.0-STABLE/i386.
> 
>  Works fine, although it shows some errors, see bellow.
> 
> 
>  ugen4.2: <Linux 2.4.20-stmp36xx with stmp36xx_udc> at usbus4
>  umass0: <Linux 2.4.20-stmp36xx with stmp36xx_udc USB Mass Storage, class
>  0/0, rev 2.00/2.29, addr 2> on usbus4
>  umass0:  SCSI over Bulk-Only; quirks = 0x0000
>  umass0:0:0:-1: Attached to scbus0
>  da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>  da0: <Samsung YP-U4 0229> Removable Direct Access SCSI-2 device
>  da0: 40.000MB/s transfers
>  da0: 3816MB (7816992 512 byte sectors: 255H 63S/T 486C)
>  (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0
>  (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:c,2 (Write error -
>  auto reallocation failed)
>  (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0
>  (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:c,2 (Write error -
>  auto reallocation failed)
>  (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0
(Continue reading)


Gmane