Re: usb product identified as ugen
On 28-Feb-2002 (19:33:04/GMT) Riccardo Torrini wrote: > port 2 addr 2: full speed, power 400 mA, config 1, \ > product 0x07d1(0x07d1), ScanLogic(0x04ce), rev 1.05 >ugen0 [...] > port 2 addr 2: full speed, self powered, config 1, \ > USB to IDE(0x0002), USB to IDE(0x04ce), rev 2.60 >umass0 Do you know why 'power 400 mA' changed to 'self powered' ? Is this important? External HD case has only USB cable... And why product changed from 0x07d1 to 0x0002? If I understand correctly those numbers are product ID and manufacturer, and the object attacched is the same from wed. Any other idea? In the meantime I make a new world :) ...FreeBSD 5.0-CURRENT #19: Fri Mar 1 03:57:49 CET 2002 Riccardo. PS: Next week I must return this device to my friend :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usb product identified as ugen
On 28-Feb-2002 (06:57:50/GMT) Riccardo Torrini wrote:
> The only difference in /dev was -ugen{0,0.1,0.2} +xpt0 :(
>
># camcontrol rescan 0
> Re-scan of bus 0 was successful
>
># camcontrol devlist -v
> scbus0 on umass-sim0 bus 0:
> scbus-1 on xpt0 bus 0:
> < >at scbus-1 target -1 lun -1 (xpt0)
I notice also that usbdevs changed output from:
# usbdevs -v -d
Controller /dev/usb0:
addr 1: self powered, config 1, UHCI root hub(0x), \
VIA(0x), rev 1.00
uhub0
port 1 powered
port 2 addr 2: full speed, power 400 mA, config 1, \
product 0x07d1(0x07d1), ScanLogic(0x04ce), rev 1.05
ugen0
to:
# usbdevs -d -v
Controller /dev/usb0:
addr 1: self powered, config 1, UHCI root hub(0x), \
VIA(0x), rev 1.00
uhub0
port 1 powered
port 2 addr 2: full speed, self powered, config 1, \
USB to IDE(0x0002), USB to IDE(0x04ce), rev 2.60
umass0
Riccardo.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: usb product identified as ugen
On 28-Feb-2002 (05:05:40/GMT) Scott Long wrote:
>> Anyway, ugen0 disappear from /dev/ but _no_ umass0 appear,
>> only xpt0...
> The debug trace looks very good.
I think this is the only good news...
> No umass0 device should appear in /dev. Instead, you should
> get a da device. Do 'camcontrol devlist -v' and you should
> see the bus (represented as umass-sim) and a 'da' and 'pass'
> device for the drive.
The only difference in /dev was -ugen{0,0.1,0.2} +xpt0 :(
# camcontrol rescan 0
Re-scan of bus 0 was successful
# camcontrol devlist -v
scbus0 on umass-sim0 bus 0:
scbus-1 on xpt0 bus 0:
< >at scbus-1 target -1 lun -1 (xpt0)
> It also sounds like you have other issues with the device
> not always attaching or detaching correctly.
You mean broken usb, broken device or bad luck?
> This is a weakness of the umass driver, so you'll have to
> experiment a bit to see what works for you.
I'm here. I can _any_ sort of experiment you may need (except
opening case of external hd :-)
Riccardo.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: usb product identified as ugen
On Thu, Feb 28, 2002 at 01:39:55AM +0100, Riccardo Torrini wrote: > On 27-Feb-2002 (23:17:15/GMT) Scott Long wrote: > > > Is the umass device compiled into the kernel, or loaded as a > > module? If it's a module, is it loaded before you attach the > > drive? The usb daemon isn't smart enough yet to load it... > > Now I have all compiled in. Something happens... > > [...] > > Anyway, ugen0 disappear from /dev/ but _no_ umass0 appear, > only xpt0... > > > Riccardo. > The debug trace looks very good. No umass0 device should appear in /dev. Instead, you should get a da device. Do 'camcontrol devlist -v' and you should see the bus (represented as umass-sim) and a 'da' and 'pass' device for the drive. It also sounds like you have other issues with the device not always attaching or detaching correctly. This is a weakness of the umass driver, so you'll have to experiment a bit to see what works for you. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usb product identified as ugen
On 27-Feb-2002 (23:17:15/GMT) Scott Long wrote: > Is the umass device compiled into the kernel, or loaded as a > module? If it's a module, is it loaded before you attach the > drive? The usb daemon isn't smart enough yet to load it... Now I have all compiled in. Something happens... -8<-[ from my kernel ]-8<- options DEBUG #Guess :) # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device pass# Passthrough device (direct SCSI access) # USB support device uhci# UHCI PCI->USB interface device usb # USB Bus (required) device ugen# Generic device umass # Disks/Mass storage - Requires scbus+da device uscanner# Scanners # Hints from Scott Long options USB_DEBUG options UGEN_DEBUG options UMASS_DEBUG -8<-[ dmesg ]-8<- uhci0: port 0xe400-0xe41f irq 10 \ at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: ScanLogic product 0x07d1, rev 1.00/1.05, addr 2 All test with and without verbose boot, single or normal has no differences but when I detached usb cable _after_ boot it show up as umass0 (at least into the /var/log/messages). Also doing a manual camcontrol rescan 0 have same results. I attach (part of) messages (compressed), sorry for that. Anyway, ugen0 disappear from /dev/ but _no_ umass0 appear, only xpt0... Riccardo. messages.gz Description: messages.gz
Re: usb product identified as ugen
On 27-Feb-2002 (23:17:15/GMT) Scott Long wrote: I forgot this piece of messages, it happens only once, when I manually detached usb cable but never again when I rescan it. -8<-[ messages ]-8<- ...kernel: ugen0: at uhub0 port 2 (addr 2) disconnected ...kernel: ugen0: detached ...kernel: usbd_new_device: addr=2, getting first desc failed ...kernel: uhub0: device problem, disabling port 2 ...kernel: umass0: USB to IDE USB to IDE, rev 1.10/2.60, \ addr 2, 8070i (ATAPI) over Bulk-Only ...kernel: umass0: Max Lun is 0 ...kernel: umass-sim:0:-1:-1:XPT_PATH_INQ:. ...kernel: umass0:0:0:-1: Attached to scbus0 as device 0 ...kernel: scbus0: scanning for umass0:0:0:-1 ...kernel: umass-sim:0:-1:-1:XPT_PATH_INQ:. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usb product identified as ugen
On Wed, 2002-02-27 at 16:07, Riccardo Torrini wrote: > On 27-Feb-2002 (18:35:18/GMT) Scott long wrote: > > > You don't mention how your kernel is presently configured > > or what other troubleshooting you've done, so all you can > > hope to receive are wild guesses like: > > Usually I don't make stupid questions (I think), sorry for > wasting your time, but after 4 auto-reboot on last 24 hours > I'm not sure of nothing, even of my name :) Yes, I've had those kinds of days also =-) > > > > - Configure a kernel with the umass, scbus, and da devices, > > along with the standard usb devices. This is documented > > in both the GENERIC config file and NOTES... > > Sorry, last time I checked comment I got (for device umass): > USB Iomega Zip 100 Drive (Requires scbus and da) so I think > that was only for Zip, not for all. > It's commented in the 'device umass' line in GENERIC, but that's not a big deal. Is the umass device compiled into the kernel, or loaded as a module? If it's a module, is it loaded before you attach the drive? The usb daemon isn't smart enough yet to load it, it seems. Thus, you must load it manually, else the ugen driver will claim the device. > > > (as I assume that you are running -current) > > Yes, of course (from 3.0). I missing only da devices :( > Going to rebuild world and kernel... > The da device is certainly required, though not having would give you different symptoms, or so I think. Try adding the da device and see what happens. > [...after 4 hours...] > > puff, puff, pant, pant... reboot... > > :( The same, ugen0, ugen0.1 and ugen0.2 but build seems fine, > it compile all world and kernel without need of NO_WERROR. > > > > - There may be a bug. > > A bug would be better than a need for a custom driver for win. > Have you any idea of what can I check now? The USB_DEBUG, UGEN_DEBUG, and UMASS_DEBUG kernel options might be helpful. Scott > > > Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usb product identified as ugen
On 27-Feb-2002 (18:35:18/GMT) Scott long wrote: > You don't mention how your kernel is presently configured > or what other troubleshooting you've done, so all you can > hope to receive are wild guesses like: Usually I don't make stupid questions (I think), sorry for wasting your time, but after 4 auto-reboot on last 24 hours I'm not sure of nothing, even of my name :) > - Configure a kernel with the umass, scbus, and da devices, > along with the standard usb devices. This is documented > in both the GENERIC config file and NOTES... Sorry, last time I checked comment I got (for device umass): USB Iomega Zip 100 Drive (Requires scbus and da) so I think that was only for Zip, not for all. > (as I assume that you are running -current) Yes, of course (from 3.0). I missing only da devices :( Going to rebuild world and kernel... [...after 4 hours...] puff, puff, pant, pant... reboot... :( The same, ugen0, ugen0.1 and ugen0.2 but build seems fine, it compile all world and kernel without need of NO_WERROR. > - There may be a bug. A bug would be better than a need for a custom driver for win. Have you any idea of what can I check now? Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usb product identified as ugen
You don't mention how your kernel is presently configured or what other troubleshooting you've done, so all you can hope to receive are wild guesses like: - Configure a kernel with the umass, scbus, and da devices, along with the standard usb devices. This is documented in both the GENERIC config file and NOTES (as I assume that you are running -current) - The device may not declare itself as a mass-storage device. It may need some custom driver that only exists for Windows. - There may be a bug. Scott On Wed, 2002-02-27 at 11:08, Riccardo Torrini wrote: > A friend of mime give me (only for some days) an external > usb hard disk device (a normal ide 2.5" with an interface > from ide to usb, self powered). > > When I attach I got this info, I need it show as umass to > mount the msdos (fat32) file system on it, right? > > Need I some special kernel configuration? Like adding the > scsi subsystem or that misterious device is not supported? > Or other stuff that don't get loaded automagically? > > (I manually wrapped long lines) > > # usbdevs -v -d > Controller /dev/usb0: > addr 1: self powered, config 1, UHCI root hub(0x), \ > VIA(0x), rev 1.00 > uhub0 > port 1 powered > port 2 addr 2: full speed, power 400 mA, config 1, \ > product 0x07d1(0x07d1), ScanLogic(0x04ce), rev 1.05 >ugen0 > > > TIA, > Riccardo. > > 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
usb product identified as ugen
A friend of mime give me (only for some days) an external usb hard disk device (a normal ide 2.5" with an interface from ide to usb, self powered). When I attach I got this info, I need it show as umass to mount the msdos (fat32) file system on it, right? Need I some special kernel configuration? Like adding the scsi subsystem or that misterious device is not supported? Or other stuff that don't get loaded automagically? (I manually wrapped long lines) # usbdevs -v -d Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), \ VIA(0x), rev 1.00 uhub0 port 1 powered port 2 addr 2: full speed, power 400 mA, config 1, \ product 0x07d1(0x07d1), ScanLogic(0x04ce), rev 1.05 ugen0 TIA, Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
