Re: USB port power control
On Wednesday 14 December 2005 11:19, Philip Lykke Carlsen wrote: .. I just wondered if it might be possible to shut down the power of a USB-port.. It would be rather handy to be able to control No, there is no utility for that. But it might be an idea to make a small utility, usbconfig, that can do such things. Currently I see that it is also necessary to be able to set the config of some USB devices manually. For example if an IPod device should attach as umass or uhid. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/79656: [usb] RHSC interrupts lost
On Saturday 25 February 2006 04:55, Ian Dowse wrote:
Synopsis: [usb] RHSC interrupts lost
State-Changed-From-To: open-feedback
State-Changed-By: iedowse
State-Changed-When: Sat Feb 25 03:53:50 UTC 2006
State-Changed-Why:
If possible, could you provide information about how to reproduce
this problem, and a patch to fix it?
http://www.freebsd.org/cgi/query-pr.cgi?pr=79656
Symptom: You plug a USB device and it is not detected at all.
I am not using the old USB driver, but basically what you need to do is this:
ehci.c
==
void
ehci_pcd_enable(void *v_sc)
{
ehci_softc_t *sc = v_sc;
ehci_pcd_able(sc, 1);
+/* acknowledge any PCD interrupt */
+EOWRITE4(sc, EHCI_USBSTS, EHCI_STS_PCD);
+ehci_pcd(sc, sc-sc_intrxfer);
}
ohci.c
==
void
ohci_rhsc_enable(void *v_sc)
{
ohci_softc_t *sc = v_sc;
int s;
s = splhardusb();
ohci_rhsc_able(sc, 1);
splx(s);
+/* acknowledge any RHSC interrupt */
+OWRITE4(sc, OHCI_INTERRUPT_STATUS, OHCI_RHSC);
+ohci_rhsc(sc, sc-sc_intrxfer);
}
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
New USB driver API, now on NetBSD 3.0
Hi, I just want to let you know that my new USB driver is now compiling and working on NetBSD 3.0. The first goal of my driver is to get the USB drivers out of Giant/spl. Another goal is that NetBSD and FreeBSD should share some device drivers line by line, without any #ifdefs nor macros. That would help bring down the amount of maintainance, not having to port patches forth and back. And to avoid separate branches for drivers. Theoretically, any USB device driver that creates a device in /dev/, like ulpt, can now easily be ported from FreeBSD to NetBSD. Currently ported to NetBSD + my new USB API: - New ugen USB device driver (http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb2/_ugen.c) - ISDN4BSD USB device drivers (http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/i4b/layer1/ihfc2/*usb*) Sources: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb2/ There has been a major cleanup in usb_port.h. The new USB driver supports _all_ transfer types on EHCI, OHCI, and UHCI. NOTE: the code compiles and loads on Sparc64, but it does not work properly yet. This is being worked on. Maybe someone wants to help? Host processors currently supported i386, amd64 and alike. FreeBSD kernel emulator for NetBSD == http://www.turbocat.net/~hselasky/isdn4bsd/sources/module/ How to download NetBSD version (You need subversion installed): === Follow the instructions in the README.TXT for how to install on NetBSD and FreeBSD. svn --username anonsvn --password anonsvn checkout svn://svn.turbocat.net/i4b Some documentation has been put here: = http://www.turbocat.net/~hselasky/usb4bsd --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
uplcom.c
Hi, I am currently working on converting uplcom.c to my new USB API. In that regard I have a question: Is anyone using option UPLCOM_INTR_INTERVAL or sysctl hw.usb.uplcom.interval, or can this be left to the default interrupt interval? /* * The uplcom.c driver supports several USB-to-RS232 serial adapters * driven by Prolific PL-2303, PL-2303X and probably PL-2303HX USB-to-RS232 * bridge chip. The adapters are sold under many different brand * names. */ --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: uplcom.c
On Monday 12 June 2006 21:39, Ulrich Spoerlein wrote: Hans Petter Selasky wrote: Hi, I am currently working on converting uplcom.c to my new USB API. In that regard I have a question: Is anyone using option UPLCOM_INTR_INTERVAL or sysctl hw.usb.uplcom.interval, or can this be left to the default interrupt interval? /* * The uplcom.c driver supports several USB-to-RS232 serial adapters * driven by Prolific PL-2303, PL-2303X and probably PL-2303HX USB-to-RS232 * bridge chip. The adapters are sold under many different brand * names. */ I have such a device and am using it. The question is, what is that option supposed to do? It sets how often the USB host controller should query the USB device for an interrupt packet. Could you have done some testing of the new driver? Maybe not right now, but in one or two weeks. I will provide you with a nice tarball, that you can install on FreeBSD 6/7. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: High speed USB 2.0
On Tuesday 13 June 2006 10:31, Василий Петров wrote: I'm using some USB 2.0 devices. They was tested in windows and transfer rates was about 10Mbps. However under my FreeBSD installation (FreeBSD 6.0) transfer rates are only up to 800Kbps (like for USB 1.0). I've checked that all required drivers (ehci especially) are built into kernel. usbdevs shows that device is high speed and is connected to high speed bus. However transfer rates are low as mentioned. How to get high transfer rates? What kind of device? umass, serial port, paralell port ? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: High speed USB 2.0
Hi, On Tuesday 13 June 2006 17:05, Василий Петров wrote: Yet I don't understand, must high-speed devices work with bundled FreeBSD drivers and it is my conf problem or this is not supported by them? I haven't found any mentions about it in mailing lists nor PRs. Your config is supported by FreeBSD 6.0-RELEASE. I've done dd tests and got VERY strange results. When I try to read from device itself (/dev/da0 or /dev/da0s1) I have 27Mb/sec. However when I mount NTFS partition, that resides on that drive, big file is read from that partition at 600Kb/sec. I understand, that there is some overhead, but not that much of course. So it seems that problem not with USB, but with what then? One of the upper layers are probably reading too small chunks of data at a time. Probably it has got something to do with the implementation of the NTFS driver. I think you will get better results with UFS and FAT32, for example. I am not an expert at file systems. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: uplcom.c
On Tuesday 13 June 2006 18:06, Ulrich Spoerlein wrote: Hans Petter Selasky wrote: On Monday 12 June 2006 21:39, Ulrich Spoerlein wrote: Hans Petter Selasky wrote: UPLCOM_INTR_INTERVAL I have such a device and am using it. The question is, what is that option supposed to do? It sets how often the USB host controller should query the USB device for an interrupt packet. I might be making a fool out of myself, but how come you have to query for an interrupt? Shouldn't and interrupt fire itself? Besides, since this is used for serial devices (=115200 bit/s) where's the point in tuning? That is what I thought too. The USB descriptors provided with the device already give the default interrupt interval, so there should not be any need for tuning. Could you have done some testing of the new driver? Maybe not right now, but in one or two weeks. I will provide you with a nice tarball, that you can install on FreeBSD 6/7. Sure thing, just post patches to the usual mailing lists or email me directly. Btw, do you know if the NetBSD folks are interested in your USB stack? I think it's a shame if we get three (four) BSDs with three different USB stacks. There are already too few people working on it ... I don't know. We'll see when my work is finished. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ugen partial write() amount
On Friday 16 June 2006 23:24, Anish Mistry wrote: I'm trying to reliably recover from a write() timeout using ugen. The problem that I'm having is that when using write() to write data to an endpoint and the write times out there seems no way to figure out the amount of that data that was actually written. This is a problem when trying to write data to a printer and the paper runs out. write() will timeout and you are left with no way to figure out where to start sending data since you don't know how much was received by the device before the paper ran out. It seems this could be possible by modifying the driver by adding and ioctl that would allow you to call bulk transfer and then return the number of bytes written. Is there a better way of doing? What about disabling the timeout ? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to connect an O2 XDA Phone (or HTC Tornado)?
On Tuesday 27 June 2006 22:31, Frank J. Beckmann wrote: Hi, I would like connect my brand new O2 XDA Phone (a kind of HTC Tornade without WLAN) to my FreeBSD 6.1 box. The Phone doesn't have WLAN and my PC doesn't have Bluetooth. So I tried USB. FreeBSD applied the ugen driver, but in the ports I found the uppc-kmod. The supplied setup utility configured the phone, but attaching ist doesn't work. FreeBSD complains: ucom0: failed to set configuration, err=STALLED device_attach: ucom0 attach returned 6 The OS of the phone is Windows CE 5.10 (70), Windows Mobile 5.0 for smartphones. Connection to a Windows 98 box also doesn't work, the required ActiveSync needs Windows 200 or XP. :-( I am not sure if it helps, but you maybe want to try out my USB driver at: http://www.turbocat.net/~hselasky/usb4bsd --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lowering USB Transfer Rate?
On Thursday 06 July 2006 10:27, nocturnal wrote: Hi I'm not sure if that's what i want to do but the story is i lost the USB cable for my mp3 player and i honestly have no idea if it was USB 1 or 2. So i took the cable from my lacie hdd and tried to mount the mp3 player but the system locked up and was rebooted. Each of these devices work just fine with their original cables. I suspected maybe that the lacie usb cable was usb 2.0 and that the transfer rate was too high, i honestly have no idea but it sounds like different usb protocols need different cables. Does anyone know what the problem is and is it possible to force usb 1.0 transfer? If you don't load the ehci module then all devices will attach as USB 1.x. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
USB bluetooth dongles
Hi, Is there anyone on this list using USB Bluetooth dongles, that can test my new USB system and the USB Bluetooth driver? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB bluetooth dongles
On Thursday 13 July 2006 21:50, Anish Mistry wrote: On Thursday 13 July 2006 15:41, Hans Petter Selasky wrote: On Thursday 13 July 2006 20:53, Anish Mistry wrote: On Thursday 13 July 2006 14:25, Hans Petter Selasky wrote: Hi, Is there anyone on this list using USB Bluetooth dongles, that can test my new USB system and the USB Bluetooth driver? Yeah, I have access to one. Do you have an updated snapshot? I will probably finish the rewrite tomorrow. I will post the details for how you can install the new driver on FreeBSD 6/7, when I am finished. Maybe you can install Subversion in the meanwhile, if you have not got it installed already. See /usr/ports/devel/subversion What is the SVN location? NOTE: The UBT code is not there yet. svn --username anonsvn --password anonsvn checkout svn://svn.turbocat.net/i4b See: i4b/trunk/i4b/FreeBSD.usb There you type: make S=../src package --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB bluetooth dongles
On Thursday 13 July 2006 22:08, Hans Petter Selasky wrote: On Thursday 13 July 2006 21:50, Anish Mistry wrote: On Thursday 13 July 2006 15:41, Hans Petter Selasky wrote: On Thursday 13 July 2006 20:53, Anish Mistry wrote: On Thursday 13 July 2006 14:25, Hans Petter Selasky wrote: Hi, Is there anyone on this list using USB Bluetooth dongles, that can test my new USB system and the USB Bluetooth driver? Yeah, I have access to one. Do you have an updated snapshot? I will probably finish the rewrite tomorrow. I will post the details for how you can install the new driver on FreeBSD 6/7, when I am finished. Maybe you can install Subversion in the meanwhile, if you have not got it installed already. See /usr/ports/devel/subversion What is the SVN location? NOTE: The UBT code is not there yet. svn --username anonsvn --password anonsvn checkout svn://svn.turbocat.net/i4b See: i4b/trunk/i4b/FreeBSD.usb There you type: make S=../src package I just committed the UBT driver. Can you run svn update from the root directory. Then again: cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install # you can specify a destination directory by using S=XXX Then copy the following files to /usr/src/sys/netgraph/bluetooth/drivers/ubt/ (for example) i4b/trunk/i4b/src/sys/netgraph/bluetooth/drivers/ubt/TODO i4b/trunk/i4b/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c i4b/trunk/i4b/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt_var.h Then build a kernel with the following options: device netgraph_bluetooth_ubt device netgraph_bluetooth device netgraph Then I hope it works, after that you have installed the new kernel. Else send me dmesg from the panics you get, like usual :-) Thanks, --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB bluetooth dongles
On Friday 14 July 2006 23:52, Alexandre Sunny Kovalenko wrote: On Fri, 2006-07-14 at 16:45 +0200, Hans Petter Selasky wrote: On Thursday 13 July 2006 22:08, Hans Petter Selasky wrote: On Thursday 13 July 2006 21:50, Anish Mistry wrote: On Thursday 13 July 2006 15:41, Hans Petter Selasky wrote: On Thursday 13 July 2006 20:53, Anish Mistry wrote: On Thursday 13 July 2006 14:25, Hans Petter Selasky wrote: Hi, Is there anyone on this list using USB Bluetooth dongles, that can test my new USB system and the USB Bluetooth driver? snip cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install # you can specify a destination directory by using S=XXX Then copy the following files to /usr/src/sys/netgraph/bluetooth/drivers/ubt/ (for example) i4b/trunk/i4b/src/sys/netgraph/bluetooth/drivers/ubt/TODO i4b/trunk/i4b/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c i4b/trunk/i4b/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt_var.h Then build a kernel with the following options: device netgraph_bluetooth_ubt device netgraph_bluetooth device netgraph Then I hope it works, after that you have installed the new kernel. Else send me dmesg from the panics you get, like usual :-) Thanks, --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED] Error below is what I get with -CURRENT of July 9th. I am building all USB stuff as modules though, would that be a problem? No. It seems like I have forgot a small patch. Could you try the following patch (just apply it manually): --- usb_port.h Fri Mar 17 17:56:07 2006 +++ /sys/dev/usb/usb_port.hSat Jul 8 11:14:00 2006 @@ -43,6 +43,7 @@ # ifdef __FreeBSD__ # include sys/conf.h +# include machine/bus.h /* bus_space_xxx() */ # include machine/resource.h /* SYS_XXX */ # include sys/bus.h /* device_xxx() */ # ifdef INCLUDE_PCIXXX_H Then try to build again. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB bluetooth dongles
On Sunday 16 July 2006 17:54, Alexandre Sunny Kovalenko wrote: On Sat, 2006-07-15 at 17:47 +0200, Hans Petter Selasky wrote: On Saturday 15 July 2006 14:54, Alexandre Sunny Kovalenko wrote: On Thursday 13 July 2006 14:25, Hans Petter Selasky wrote: Hi, Is there anyone on this list using USB Bluetooth dongles, that can test my new USB system and the USB Bluetooth driver? cut Here is what I get upon insertion of the dongle #2 (3Com 3CREB96): usbd_fill_iface_data: invalid wMaxPacketSize, addr=126! usbd_fill_iface_data: invalid wMaxPacketSize, addr=126! ^^^ this means that wMaxPacketsSize is zero - strange ubt0: 3Com Bluetooth dongle, class 224/1, rev 1.10/1.15, addr 126 ubt0:ubt_intr_read_complete:881: Invalid HCI event frame size, length=0, pktlen=7 ubt0:ubt_intr_read_complete:881: Invalid HCI event frame size, length=0, pktlen=7 ubt0:ubt_intr_read_complete:881: Invalid HCI event frame size, length=0, pktlen=7 ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout I found a bug in the code. Could you try to do a svn update. Then copy the following files to /usr/src/sys/netgraph/bluetooth/drivers/ubt/ (for example) i4b/trunk/i4b/src/sys/netgraph/bluetooth/drivers/ubt/TODO i4b/trunk/i4b/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c i4b/trunk/i4b/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt_var.h Then rebuild your kernel, and try again. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb/ugen interrupt read question
On Friday 21 July 2006 21:46, rnilsson wrote: I am working on porting owfs over to FreeBSD, and I've run into a strange issue when I'm trying to read the status of a device (DS2490 http://pdfserv.maxim-ic.com/en/ds/DS2490.pdf) on EP 1, an interrupt IN endpoint. One of the routines (a data request) writes data to ep 2, sends a control message that indicates a read from bus operation, and then gets status on EP 1, waiting for a register to reflect the proper number of bytes available for read. EP 1 can return up to 32 bytes of data, but will only provide 16 bytes unless there is an error condition. On Linux this works correctly. Each call to read EP1 will return when there is new data available from the device. On the FreeBSD side, from the time a control message is issued, status messages on EP1 start queuing up. Each read will return 32 bytes of data (or more if I make the buffer larger) until I exhaust the buffer - the only way I can get only the 16 expected. This can take anywhere from 5 to 50 loops reading EP1 to clear out the data, depending on the time between the control command and the read. I thought the USB device (INTERRUPT mode endpoint) was supposed to wait until data was requested to send it's information. This is running through libusb, and I've turned on debug in the ugen driver to make sure it really is interrupt driven. Is there some setting that causes this type of queing of interrupt data? I've seen other messages about the timeout not working with interrupt reads, so is this device related? Where can I go from here? The buffer you allocate should be 32 bytes long. Then you must use the flag USBD_SHORT_XFER_OK. Then you check the xfer-actlen after that the transfer has happened. Isn't this 16 bytes ? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Testers wanted (again)
Hi, I need testers for ata-usb.c and if_aue.c. If you have such a device please install subversion, /usr/ports/devel/subversion, and then run the following commands: svn --username anonsvn --password anonsvn checkout svn://svn.turbocat.net/i4b cd i4b/trunk/i4b/FreeBSD.usb make S=../src package # you can specify a destination directory, XXX, by using make S=XXX install make install Then copy the following files to /usr/src/sys/dev/ata (for example) i4b/trunk/i4b/src/sys/dev/ata/ata-usb.c Then copy the following files to /usr/src/sys/dev/usb (for example) i4b/trunk/i4b/src/sys/dev/usb/if_aue.c i4b/trunk/i4b/src/sys/dev/usb/if_auereg.h Compile a new kernel with modules. Hope it works. You need FreeBSD 6 or 7. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Testers wanted (again)
On Saturday 05 August 2006 19:39, Alexandre Sunny Kovalenko wrote: On Sat, 2006-08-05 at 17:46 +0200, Hans Petter Selasky wrote: Hi Alexandre, On Saturday 05 August 2006 16:43, Alexandre Sunny Kovalenko wrote: On Sat, 2006-08-05 at 11:52 +0200, Hans Petter Selasky wrote: Hi, I need testers for ata-usb.c and if_aue.c. If you have such a device please install subversion, /usr/ports/devel/subversion, and then run the following commands: ... First, the disclaimer: this device normally would wedge my laptop solid and has been doing it for as long as I had it. With your stack it reports timeouts, but proceeds albeit at the very slow pace. ... If there is anything, I can turn on or look into, please, let me know. If you can wait till Christmas, there will be a rewritten umass driver. Maybe you can test again then. --HPS I can certainly wait until Christmas. Just for my education -- what kind of devices did you want tested? Today, just ADMtek AN986 Pegasus USB Ethernet devices and IDE mass storage devices, not device umass, but device atausb. But if you want, you can test USB functionality in general. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Testers wanted (again)
On Sunday 06 August 2006 16:02, Alexandre Sunny Kovalenko wrote:
On Sat, 2006-08-05 at 20:56 +0200, Hans Petter Selasky wrote:
On Saturday 05 August 2006 19:39, Alexandre Sunny Kovalenko wrote:
...
I can certainly wait until Christmas. Just for my education -- what
kind of devices did you want tested?
Today, just ADMtek AN986 Pegasus USB Ethernet devices and IDE mass
storage devices, not device umass, but device atausb. But if you
want, you can test USB functionality in general.
--HPS
Oops, I am being silly here -- to quote Release Notes:
The ata(4) driver now supports USB mass storage class devices. To
enable it, a line device atausb in the kernel configuration file or
loading the atausb kernel module is needed. Note that this functionality
cannot coexist with the umass(4) driver. ... sigh.
So I have built a kernel with the device atausb inside -- configuration
is available at
Ok. Interesting.
I found some bugs in ata-usb.c which I have now fixed and committed to SVN.
You still cannot do atacontrol attach ata2 nor atacontrol detach ata2 on
USB devices. I hope that SOS can fix this.
Could you have done a svn update, then re-copy ata-usb.c to
/usr/src/sys/dev/ata/, then rebuild your kernel and try again?
In ata-usb.c there is a variable, atausbdebug which you can set non-zero
to enable debugging, if the driver does not work.
--HPS
For SOS:
RabbitsDen#
and attempt to do atacontrol attach ata2
crashes kernel with the following trace:
RabbitsDen# kgdb ./usr/src/sys/USB/kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode
threads: /usr/lib/libthread_db.so: Undefined sym bol
ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc059fd56
stack pointer = 0x28:0xd90e1b08
frame pointer = 0x28:0xd90e1b08
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 868 (atacontrol)
Physical memory: 599 MB
Dumping 54 MB: 39 23 7
#0 doadump () at pcpu.h:166
166 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:166
#1 0xc04778bc in db_fncall (dummy1=0, dummy2=0, dummy3=1999,
dummy4=0xd90e18c8 w\202��\030\016�)
at /usr/src/sys/ddb/db_command.c:481
#2 0xc0477665 in db_command (last_cmdp=0xc0826e24, cmd_table=0x0)
at /usr/src/sys/ddb/db_command.c:396
#3 0xc047773a in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:448
#4 0xc0479835 in db_trap (type=12, code=0)
at /usr/src/sys/ddb/db_main.c:221
#5 0xc059aac5 in kdb_trap (type=0, code=0, tf=0x0)
at /usr/src/sys/kern/subr_kdb.c:502
#6 0xc07774fc in trap_fatal (frame=0xd90e1ac8, eva=4)
at /usr/src/sys/i386/i386/trap.c:858
#7 0xc0777205 in trap_pfault (frame=0xd90e1ac8, usermode=0, eva=4)
at /usr/src/sys/i386/i386/trap.c:776
#8 0xc0776d63 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1025473280, tf_esi =
-1023739392, tf_ ebp = -653387000, tf_isp = -653387020, tf_ebx =
-1025473280, tf_edx = -1065420148, tf_ecx = -1031237632, tf_eax = 0,
tf_trapno = 12, tf_err = 4, tf_eip = -1067844266, tf_cs = 32, tf_eflags
= 66178, tf_esp = -653386896, tf_ss = -1068859020})
at /usr/src/sys/i386/i386/trap.c:461
#9 0xc07619ea in calltrap () at /usr/src/sys/i386/i386/exception.s:138
#10 0xc059fd56 in rman_get_bustag (r=0x0)
at /usr/src/sys/kern/subr_rman.c:722
#11 0xc04a8174 in ata_generic_reset (dev=0xc2e08500) at bus.h:515
#12 0xc049203a in ata_attach (dev=0xc2e08500) at ata_if.h:55
#13 0xc0492caa in ata_ioctl (dev=0xc2886400, cmd=0, data=0xc07efa8c
[EMAIL PROTECTED]:,
flag=3, td=0xc2be5bd0) at /usr/src/sys/dev/ata/ata-all.c:383
#14 0xc05452b8 in giant_ioctl (dev=0xc2886400, cmd=0, data=0x0, fflag=0,
td=0x0)
at /usr/src/sys/kern/kern_conf.c:288
#15 0xc0517d29 in devfs_ioctl_f (fp=0xc2e0cb40, com=2147770627,
data=0xc2992970,
cred=0xc2e0d400, td=0xc2be5bd0)
at /usr/src/sys/fs/devfs/devfs_vnops.c:410
#16 0xc05a7061 in kern_ioctl (td=0xc2be5bd0, fd=3, com=2147770627,
data=0xc2992970 \002) at file.h:265
#17 0xc05a6be7 in ioctl (td=0x0, uap=0xd90e1d04)
at /usr/src/sys/kern/sys_generic.c:575
#18 0xc07778da in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134521610, tf_esi =
-1077940770, tf_e bp
Re: USB_ATTACH_SETUP macros question
Made a little test which shows that this code is going to be executed only once.How did i miss that :) Now the other question comes next: Why don not we use just: #define USB_ATTACH_SETUP \ sc-sc_dev = self; \ device_set_desc_copy(self, devinfo); \ device_printf(self, %s\n, devinfo); Because that is dangerous. Consider the following: if (1) USB_ATTACH_SETUP; What is the meaning of the statement above? What is going to get executed? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with Mitsumi 7-in-1 USB Card Reader/Floppy combo
On Tuesday 05 September 2006 03:16, Indigo 23 wrote: Thanks for the reply. I already tried that, but unfortunetly the same thing happens :( Any other suggestions? Maybe you want to try my new Giant free USB driver: # # How to install the new USB driver: # # # First get all the sources # (you need /usr/ports/devel/subversion installed): # svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD 6.x/7.x: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install # # Then build a new kernel (with modules) # --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with Mitsumi 7-in-1 USB Card Reader/Floppy combo
On Tuesday 05 September 2006 13:28, Indigo 23 wrote: Thanks for that excellent suggestion. It worked perfectly. I just have a few questions. 1) Any idea when this will be imported in to RELENG_6? I don't know. If I am right, you will see my driver in freebsd-current some time after Christmas. 2) I have to do this everytime I update my sources, correct? Yes. 3) This is relatively stable, correct? (I did test it out a bit, but of course not thorougly enough to see how stable it is) Yes, it is stable, but be aware that if your system runs low on memory, you can get a panic saying, sleeping with mutex XXX locked, or something alike. That is because the umass device driver is still under the USB emulation layer of the old USB API, which is depreciated, and will be removed once I have completed the conversion of all USB device drivers. This will most likely happen before the end of this month. Then I need some help testing all the rewritten USB device drivers. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/103046: [patch] ulpt event driven I/O with select(2) and nonblock
On Saturday 09 September 2006 19:50, Jan-Espen Pettersen wrote: The following reply was made to PR usb/103046; it has been noted by GNATS. From: Jan-Espen Pettersen [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/103046: [patch] ulpt event driven I/O with select(2) and nonblock Date: Sat, 09 Sep 2006 19:42:11 +0200 I've updated the patch as I spotted errors in the original patch. The url will still be http://www.radiotube.org/ulpt_poll.diff Fixes were: * Forgot to start transfer (in other words forgot to call usbd_transfer) for the background read. * Panic in read callback at pipe abort. What I am interested to know about is how this works with printers that actually do return any backchannel data, since my dumb laser printer does= not return data at all. Hi, My new ulpt.c already supports ULPT polling. Maybe you want to try that, and give me some feedback. # # How to install the new USB driver: # # # First get all the sources # (you need /usr/ports/devel/subversion installed): # svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD 6.x/7.x: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install # # Then build a new kernel (with modules) # --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ehci.c : uncommited patch fixes DRAC5 problems
On Tuesday 19 September 2006 23:45, Bill Moran wrote: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/ehci.c?rev=1.42conte nt-type=text/x-cvsweb-markup I'm one of those people who've been having trouble with Dell's DRAC5 keyboards not working in 6.1. Grabbing the above version of ehci.c fixes the problem (except that I had to comment out line 766) The commit note suggests that this should have been MFCed back in April. Can we get this MFCed before 6.2 comes out? Hi, Could you have checked if my new USB driver has the same problem? # # First get all the sources # (you need /usr/ports/devel/subversion installed) # svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install # # Then build a new kernel (with modules). # --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass0: BBB reset failed, TIMEOUT (again)
On Wednesday 20 September 2006 03:11, Juergen Lock wrote: Today for the first time since this box got a new board I tried to copy data onto the usb cardreader, and after copying for a while it suddenly stopped (led stopped flashing, no further io), and after some time i had the above in dmesg. And that was it, cp process hung, no way to kill it. Unplugged the thing, and got the expected panic: vinvalbuf: dirty bufs. Tried the same thing from linux (after dosfsck), and there copying stopped for a while too, but it then continued and finished. Is this is some kind of new hardware quirk of the new board's ehci controller, that linux recovers from? (via, there already is a `dropped interrupt' fix for it, which helped with my last board...) I also tried building a RELENG_6 kernel (one of the PRs I looked at also suggested this), but it behaved the same. Just in case, I took a dump of that too, but I don't really know for what to look in there so you'd have to tell me... Could you have tried my new USB driver and see if the problem is the same? # # First get all the sources # (you need /usr/ports/devel/subversion installed) # svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install # # Then build a new kernel (with modules). # When the device hangs, turn on USB debugging: sysctl hw.usb.umass.debug=-1 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ehci.c : uncommited patch fixes DRAC5 problems
On Wednesday 20 September 2006 16:40, Bill Moran wrote: In response to Hans Petter Selasky [EMAIL PROTECTED]: On Tuesday 19 September 2006 23:45, Bill Moran wrote: Is this the new USB stuff that Tom Rhodes has been involved with? Yes. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ehci.c : uncommited patch fixes DRAC5 problems
On Wednesday 20 September 2006 20:50, Bill Moran wrote: In response to Hans Petter Selasky [EMAIL PROTECTED]: Ok. Just add: #ifndef TS_CALLOUT #define TS_CALLOUT MINOR_CALLOUT #endif If you get more errors, then just compile with the -k option to get all errors. Before line 186. I'll let you know, but I may not get to this until tomorrow. Looks like my patch failed. Try this instead: #ifndef TS_CALLOUT #define TS_CALLOUT NULL, unit, MINOR_CALLOUT /* compile fix for FreeBSD 6.x */ #endif --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass0: BBB reset failed, TIMEOUT (again)
On Friday 22 September 2006 00:04, Juergen Lock wrote: On Wed, Sep 20, 2006 at 11:18:32AM +0200, Hans Petter Selasky wrote: On Wednesday 20 September 2006 03:11, Juergen Lock wrote: Today for the first time since this box got a new board I tried to copy data onto the usb cardreader, and after copying for a while it suddenly stopped (led stopped flashing, no further io), and after some time i had the above in dmesg. And that was it, cp process hung, no way to kill it. Unplugged the thing, and got the expected panic: vinvalbuf: dirty bufs. Tried the same thing from linux (after dosfsck), and there copying stopped for a while too, but it then continued and finished. Is this is some kind of new hardware quirk of the new board's ehci controller, that linux recovers from? (via, there already is a `dropped interrupt' fix for it, which helped with my last board...) We can easily check for dropped interrupts. If you run: sysctl hw.usb.ehci.debug=15 sysctl hw.usb.umass.debug=-1 When your device hangs. And then send me the log again. Ok. This time writing worked, but reading back to verify (cmp) seemed to hang. Did the sysctl (see below), then a while later I got an IO error. Tried to umount, got another IO error, tried umount -f, got a panic (probably expected.) I have now installed mtools and won't mount umass devices on this box anymore... :/ (Btw when I later tried to mcopy the file off the thing using the original kernel I noticed the led was off after it hung, dunno if that also was the case when I tried it with the new code but I would suspect so. At least this time, since it wasnt mounted, I could unplug it without getting a panic...) Oh, one thing that occured to me: Even when you may be able to get around (what appars to be) hardware quirks like this by retrying IO or resetting the device, that probably wont work when you have an umass tape drive (sa), since with tape you can't just retry a read/write, and resetting it may even rewind, with the next write erasing everything on the tape. Just a thought... Anyway, here's the syslog of the `experiment', beginning after the sysctl: From the log I see that it looks like the statemachine of your device has locked up. Even the reset command is timing out. That should not happen. We could try to reconfigure the device, when reset fails. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd usb hub issue
On Thursday 21 September 2006 22:56, M. Warner Losh wrote: I have a dell server that I'm having usb problems with. I have usb enabled in the BIOS, but none of the usb ports appears to work. In dmesg, I see: CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3000.12-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf47 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MC A,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x649dSSE3,RSVD2,MON,DS_CPL,EST,CNTX-ID,CX16,XTPR AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 2 usable memory = 4282433536 (4084 MB) avail memory = 4137197568 (3945 MB) ACPI APIC Table: DELL PE850 ... uhci0: UHCI (generic) USB controller port 0xbce0:0x20 irq 20 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 device_attach: uhub0 attach returned 6 usb0: port 0, set config at addr 1 failed usb0: root hub problem, error=4 with the same messages repeated for each uhub for each uchi that I have. Ideas? In /sys/dev/uhub.c you might want to change: int uhubdebug = 0; Into: int uhubdebug = 15; Then see what errors show up. Do you get the same error with the latest version of the new USB stack ? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB modems for freeBSD 6
On Monday 09 October 2006 03:48, [EMAIL PROTECTED] wrote: I want to add a USB modem to a FreeBSD 6. What are the USB modems (Make and Model) that work well with FreeBSD 6? Thanks -- Hari There are so-called driver-less modems, supported by umodem. Else grep for ucom and tty under /sys/dev/usb/ --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/105186: USB 2.0/ehci on FreeBSD 6.2-PRE/AMD64 crashes box
The following reply was made to PR usb/105186; it has been noted by GNATS. From: Hans Petter Selasky [EMAIL PROTECTED] To: Undisclosed.Recipients: ; Cc: O. Hartmann [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: usb/105186: USB 2.0/ehci on FreeBSD 6.2-PRE/AMD64 crashes box Date: Mon, 6 Nov 2006 09:56:07 +0100 On Sunday 05 November 2006 22:31, O. Hartmann wrote: Number: 105186 Category: usb Synopsis: USB 2.0/ehci on FreeBSD 6.2-PRE/AMD64 crashes box Confidential: no Severity: critical Priority: high Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun Nov 05 21:40:26 GMT 2006 Closed-Date: Last-Modified: Originator: O. Hartmann Release:FreeBSD 6.2-PRE/AMD64 Organization: Freie Universit=E4t Berlin Environment: FreeBSD foo.org 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #8: Sat Nov 4 11:23:20 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FOO amd64 Description: FreeBSD 6.2-PRE/AMD64 crashes after first access of USB 2.0 devices, like external disk attached via USB or USB stick. The crash occurs very rapidly after a fresh start of the box and accessing a backup drive (see appropriate dmesg output) writing data. Also accessing a USB stick very often results in a crash of the box! One can alos trigger a crash by accessing the USB 2.0 device while box is under heavy load. Doesn't matter whether SCHED_ULE or SCHED_4BSD is used. Kernel uses ehci for performance reasons. Crashes occur in most cases on our AMD64 based boxes, the i386 based 32 B= it boxes with same OS version seem to be more robust. As USB is widely used and many colleagues use USB sticks and USB backup/exchange external drives, usability and stability of USB becomes important. dmesg part of USB device controller: usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: NVIDIA nForce4 USB 2.0 controller mem 0xdcdfbc00-0xdcdfbcff irq = 22 at device 11.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: NVIDIA nForce4 USB 2.0 controller on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered umass0: Macpower Tytech Tech USB2.0 Enclosure, rev 2.00/1.00, addr 2 dmesg part of USB 2.0 external HD: da0 at umass-sim0 bus 0 target 0 lun 0 da0: SAMSUNG S07GJ10Y304470 VM10 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 190782MB (390721968 512 byte sectors: 255H 63S/T 24321C) dmesg USB stick: umass1: vendor 0x0457 USB Mass Storage Device, rev 2.00/1.00, addr 3 da1 at umass-sim1 bus 1 target 0 lun 0 da1: TinyDisk 2006-09-11 0.00 Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 1000MB (2048000 512 byte sectors: 64H 32S/T 1000C) GEOM_LABEL: Label for provider da1 is msdosfs/STICK01. How-To-Repeat: Attach USB 2.0 device to AMD64 box and do a lot of I/O ... Fix: Nothing known. Switching back to USB 1.0/1.1 via ohci isn't a solution due to the worse performance. Release-Note: Audit-Trail: Unformatted: Hi, Could you have tried my new USB driver and see if it has the same problem: # # First install /usr/ports/devel/subversion # Then: # svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=3D../src package make install The source is also available from perforce: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects/us= bHIDEDEL=3DNO =2D-HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb to serial
On Thursday 09 November 2006 18:29, Maxim Konovalov wrote: [ iedowse CC'ed ] Hello, On Fri, 5 May 2006, 11:04-0400, David Coder wrote: thx for the suggestions, guys. with device uftdi device uplcom in the kernel config the adapter shows up as ugen0: ArkMicroChips USB-UART Controller, rev 1.10/0.01, addr 2 no specific com port shows up, however, so i must need something else. Alex Rodin have ported uark(4) driver from OpenBSD. I made code cleanup and intergation in the tree. You can gettest patches for HEAD and RELENG_6 there: http://maxim.int.ru/stuff/uark.diff http://maxim.int.ru/stuff/uark.diff.6 Ian, could you please review the patches? Hi, do you think that you could also port the serial driver to the new USB stack, and send me a patch file? Please see: http://www.turbocat.net/~hselasky/usb4bsd Download the SVN version, and type svn diff to generate a patch when you are finished. Look at the other serial drivers in my SVN tree, how the USB/UCOM stuff is done. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pen Drive Problem
On Wednesday 15 November 2006 18:55, Luigi Palmieri wrote: Last week i bought a pen drive of 1GB, unfortunatelly, it doesn't work on my Freebsd 6.1. every time i gave mount and camcontrol rescan all,camcontrol devlist e dsmsg comands the system returned these: tryng to mount root from ufs:/dev/ad0s1a uhub0: device problem (SET_ADDR_FAILED), disabling port 2. Maybe you want to try another USB-Pen or my new USB driver: # # Install /usr/ports/devel/subversion, then # svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install # # Then build a new kernel. # --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Test (belated) of new umass driver
On Sunday 26 November 2006 00:21, Peter Carah wrote: I just noticed today your call from a couple of months ago to try the new umass driver; just did so and noticed only a 2-3% improvement. the sys and int times were all over the map so couldn't tell what to say about them. (likely from running X doing all this :-) If you have a faster memory stick, you should see more improvement. The problem removing active umass devices applies to *all* usb that have secondary drivers, though I presume you all know about that... Yes. I have asked Scott Long to come up with a solution for it. So far no solution. umodem, uftdi, uplcom all panic on removal if the secondary device is open. Have you tried this with the new USB stack? I tried to fix these issues with all the drivers in the UCOM layer. Maybe you could send me a backtrace, if it still panics. I presume this is due to a lack of callbacks into the secondary driver to cause it to clean up before the lower-level driver does. Unfortunately I don't know what the inter-layer linkages look like and don't at the moment have much time to look into it. The problem is simply that many abstraction layers in the kernel where not designed to allow device detach. (the worst one of these is my verizon card which adds yet another extra layer - the usb ohci is a cardbus device...) (and it used to panic whether or not the tty layer was open; something (probably newbus and the bus-dma stuff) fixed that). Also I haven't seen anything about this on the mailing list for the last month or so. At least the new driver works. I also have problems with data transfers on libusb+ugen, on every device I have that needs libusb; this includes two cameras, a scanner, and a tripp-lite ups. The device opens properly but transfers either time out or fail. I don't know if the new structure is likely to help there... (btw this happens on 3 different computers with totally different I/O structures; this laptop, whose dmesg appears below, one with an Intel 865 board, and a soekris (on which I've only tried the ups...) UMASS works fine with one of the cameras, so I think this is a fbsd-side problem. Did you have the same problems before with libusb+ugen ? Thanks for testing, --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Fixing USB ethernet for FreeBSD 7.0.
On Friday 01 December 2006 20:43, Alfred Perlstein wrote: * M. Warner Losh [EMAIL PROTECTED] [061201 11:30] wrote: Have you looked at the usb work that Hans Petter Selasky at http://www.turbocat.net/~hselasky/usb4bsd yet? I just did, while it solves a lock order problem, this doesn't appear to solve the programmitic issues, namely multiple usb IOs requiring callbacks and how to issue a series of complex usb IOs from interrupt context. Basically, I need to be able to do USB IO as if I was doing normal BUS IO, usb does not offer this in interrupt context except as a series of callbacks that appear to be programmatically impossible to implement. Yes, yes, this is supported. See the USBD_USE_POLLING flag. Have a look at if_aue.c, then look at any of the error cases that might be called from interrupt context, they wind up doing sync IO to the device which is illegal (sleeping while holding a driver lock). Hans Petter Selasky's work is nice, however it doesn't solve these issues, the lock would still have to be held. You don't want to do things without holding a lock. Do you understand that I'm trying to give usb ethernet the same ease of programming that other devices on a fast bus have? Yes, but that comes at an expense. Higher CPU usage, more delay. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem on Acer Aspire WLMi 5102 with AMD Turion 64 X2
On Wednesday 20 December 2006 16:58, Paul Argentoff wrote: Hello, world. It's my first experience of installing FreeBSD on a notebook and also a first problem with USB devices. Here's the report: [EMAIL PROTECTED] /home/paul]# uname -r 6.1-RELEASE-p11 [EMAIL PROTECTED] /home/paul]# uname -p i386 [EMAIL PROTECTED] /home/paul]# uname -s FreeBSD dmesg: Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE-p11 #1: Tue Dec 19 20:15:13 MSK 2006 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/PAULBOOK acpi_alloc_wakeup_handler: can't alloc wake memory Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-50 (1596.01-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x40f82 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MC A,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow+,3DNow AMD Features2=0x1fLAHF,CMP,b2,b3,CR8 Cores per package: 2 real memory = 468254720 (446 MB) avail memory = 451375104 (430 MB) ACPI APIC Table: PTLTDAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 2.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: PTLTD RSDT on motherboard acpi0: Power Button (fixed) acpi_ec0: Embedded Controller: GPE 0x10 port 0x62,0x66 on acpi0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 32-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 cpu0: ACPI CPU on acpi0 powernow0: PowerNow! K8 on cpu0 cpu1: ACPI CPU on acpi0 powernow1: PowerNow! K8 on cpu1 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 acpi_video0: ACPI video extension port 0x9000-0x90ff mem 0xd400-0xd7ff,0xd010-0xd010 irq 17 at device 5.0 on pci1 pcib2: ACPI PCI-PCI bridge at device 4.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 5.0 on pci0 pci4: ACPI PCI bus on pcib3 ohci0: ATI SB400 USB Controller mem 0xd0004000-0xd0004fff irq 19 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: ATI SB400 USB Controller on ohci0 usb0: USB revision 1.0 uhub0: ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ohci1: ATI SB400 USB Controller mem 0xd0005000-0xd0005fff irq 19 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: ATI SB400 USB Controller on ohci1 usb1: USB revision 1.0 uhub1: ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 4 ports with 4 removable, self powered pci0: serial bus, USB at device 19.2 (no driver attached) pci0: serial bus, SMBus at device 20.0 (no driver attached) atapci0: ATI IXP400 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8410-0x841f irq 16 at device 20.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: multimedia at device 20.2 (no driver attached) isab0: PCI-ISA bridge at device 20.3 on pci0 isa0: ISA bus on isab0 pcib4: ACPI PCI-PCI bridge at device 20.4 on pci0 pci6: ACPI PCI bus on pcib4 pci6: network, ethernet at device 1.0 (no driver attached) pci6: network, ethernet at device 2.0 (no driver attached) pci6: bridge, PCI-CardBus at device 4.0 (no driver attached) pci6: memory, flash at device 4.1 (no driver attached) pci6: base peripheral at device 4.2 (no driver attached) pci6: memory, flash at device 4.3 (no driver attached) pci6: memory, flash at device 4.4 (no driver attached) acpi_tz0: Thermal Zone on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 battery0: ACPI Control Method Battery on acpi0 acpi_acad0: AC Adapter on acpi0 pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xc-0xcefff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec ad0: 95396MB HTS541010G9AT00 MBZOA60A at ata0-master UDMA100 acd0: DVDR PIONEER DVD-RW DVR-K16RS/1.35 at ata0-slave UDMA33 pass0 at ata0 bus 0 target 1 lun 0 pass0: PIONEER DVD-RW DVR-K16RS 1.35 Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers SMP: AP CPU #1 Launched! Trying to mount root from
Re: any way to detect usb detached from a device driver ?
On Tuesday 09 January 2007 17:34, Luigi Rizzo wrote: [sorry for the repost, not sure it went through] On Tue, Jan 09, 2007 at 08:16:29AM -0800, Luigi Rizzo wrote: I am modifying a kernel device driver for webcams (see http://info.iet.unipi.it/~luigi/FreeBSD/usb-cameras.html) packing together various projects around, and i was wondering how to handle the situation of a device being detached while in use. If you look at the my USB driver for FreeBSD, http://www.turbocat.net/~hselasky/usb4bsd , there has been created a new device system, usb_cdev, with that goal in mind that you should not have to worry about detaching devices, hence this is somewhat complicated: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_cdev.c For example, have a look a the new URIO driver: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/urio.c Right now the code (from ports/multimedia/pwcbsd) detects that the device is in use while the driver-specific USB_DETACH routine is called, however then it goes on without doing anything. Very bad! In another driver in the dree (urio.c) i see the driver calls usb_detach_wait() to wait up to 60s for the drivers to complete. However that function is not documented and used a bit inconsistently in the rest of /sys/dev/usb --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: some issues with the USB tree
On Thursday 18 January 2007 22:14, Kip Macy wrote: On 1/18/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: On Thursday 18 January 2007 05:00, Kip Macy wrote: I wanted to try out the new USB stack but I'm finding that X won't start and em0 periodically needs to be reset - I don't see either of these problems on HEAD. Has anything outside of /dev/usb been changed? Did you download from perforce or SVN ? Perforce. How did you install the driver? em is statically compiled into the kernel. What processor are you using? hw.machine: i386 hw.model: Intel(R) Pentium(R) D CPU 3.20GHz hw.ncpu: 2 Could you connect a umass device in console mode, and do some dd benchmarking? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: some issues with the USB tree
On Friday 19 January 2007 06:28, Kip Macy wrote: Could you connect a umass device in console mode, and do some dd benchmarking? I'll have to dig out a USB hard drive to make any meaningful measurements, the write speed on my flash drive is the same as in HEAD - a fairly paltry 550-600kB/s. Is there anything in particular you want to see other than sustained write throughput? It is some time since the USB p4 tree was integrated with HEAD. I don't know if that is the reason em and X11 is not working. Could you also try to checkout HEAD, then install the driver from SVN: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no data from USB wireless mouse
On Friday 19 January 2007 07:55, Andrew Tamm wrote: I am having no success at all in getting a Microsoft Optical Wireless Desktop Pro mouse to work in FreeBSD 6.2-RC2. The kernel sees it as: ums0: Microsoft Microsoft Wireless Optical Desktop ums0: 5 buttons and Z dir and a TILT dir. cat /dev/usm0 gives no data, no matter what buttons are pushed on the mouse. After looking online, I saw a few things to try, the first of which to recompile the kernel with USB_dEBUG option enabled. After doing this, and cranking hw.usb.usm.debug up to 10, I still can get nothing out of the usm0, however, typing cat /dev/usm0 and then hitting ^C gives this following message: (note the system has been rebooted with a second wired mouse attached at usm0, so the offending device has moved to usm1 ) ums_intr: sc=0xc50bf000 status=6 ums_intr: data = 00 00 00 00 00 00 Could you try my new USB stack: # You need /usr/ports/devel/subversion installed svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install When the kernel is built, enable the ums debug sysctl. Set it to 15. Then repeat your tests, if the mouse doesn't work. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/107496: USB device problem on RELENG_6_2 (SHORT_XFER) (regression)
Hi Fred! On Saturday 03 February 2007 17:50, fred wrote: The following reply was made to PR usb/107496; it has been noted by GNATS. From: fred [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: usb/107496: USB device problem on RELENG_6_2 (SHORT_XFER) (regression) Date: Sat, 03 Feb 2007 17:27:36 +0100 Hi, I submit a followup because I wan to add some useful information concerning my problem. First of all, whith EHCI device disabled in kern conf, it works fine. Second, I have these problems with my two flash drives, Kingston Corsair: Kingston DataTraveler: 0x08ec:0008 Corsair FlashVoyager: 0x067b:2515/2517 Third, I have testet HPS fix (http://groups.google.com/group/lucky.freebsd.hardware/browse_frm/thread/9a 46031ab186cfa8/6237d337d9d7cb04#6237d337d9d7cb04) but it still fails. What SVN/P4 version did you test? Recently I have added a lot of sync code to help out on non-x86 processors. What kind of processor are you using? Could you do something like sysctl hw.usb.debug=15 before you plug your memory sticks. Then afterwards sysctl hw.usb.debug=0. Post or send me the resulting debug output. usb2: EHCI (generic) USB 2.0 controller on ehci0 usb0: USB revision 1.0 usb1: USB revision 1.0 usb2: USB revision 2.0 usbd_fill_iface_data: invalid wMaxPacketSize=0x, addr=126! usbd_fill_iface_data: invalid wMaxPacketSize=0x, addr=126! usbd_fill_iface_data: invalid wMaxPacketSize=0x, addr=126! This error clearly indicates that something is wrong. wMaxPacketSize should never be zero with a few rare exceptions. uhub_explore: usb_new_device failed, error=USBD_TIMEOUT uhub2: device problem (USBD_TIMEOUT), disabling port 6 The transfer timed out. How nice. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with USB devices connecting to UHCI instead of EHCI
On Sunday 11 March 2007 02:04, Kevin Oberman wrote: If I load umass after plugging in a disk or flash fob, it will be connected as a UHCI device. If I load umass and then connect the device, it is properly connected as EHCI. When connected as a UHCI device, it is too slow to be useful. Looks like a race condition as the EHCI is the last USB device probed. I suspect that the disk is already connected to a UHCI device before an EHCI device is found. uhci0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0x1860-0x187f irq 11 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801FB (ICH6) USB 2.0 controller mem 0xb000-0xb3ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801FB (ICH6) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb4 uhub4: 8 ports with 8 removable, self powered Any idea if this is fixable? Not a huge problem, but an annoying one. Will the new USB system (hopefully coming soon) deal with this? It might have something to do with the probe order. Did you try the new USB stack. I recommend you install it on 6-stable, because on 7-current it needs some small patches to compile, due to some changes in the kernel API lately. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with USB devices connecting to UHCI instead of EHCI
On Sunday 11 March 2007 21:19, Kevin Oberman wrote: From: Hans Petter Selasky [EMAIL PROTECTED] Date: Sun, 11 Mar 2007 19:25:14 +0100 On Sunday 11 March 2007 02:04, Kevin Oberman wrote: If I load umass after plugging in a disk or flash fob, it will be connected as a UHCI device. If I load umass and then connect the device, it is properly connected as EHCI. When connected as a UHCI device, it is too slow to be useful. Looks like a race condition as the EHCI is the last USB device probed. I suspect that the disk is already connected to a UHCI device before an EHCI device is found. uhci0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0x1860-0x187f irq 11 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801FB (ICH6) USB 2.0 controller mem 0xb000-0xb3ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801FB (ICH6) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb4 uhub4: 8 ports with 8 removable, self powered Any idea if this is fixable? Not a huge problem, but an annoying one. Will the new USB system (hopefully coming soon) deal with this? It might have something to do with the probe order. Did you try the new USB stack. I recommend you install it on 6-stable, because on 7-current it needs some small patches to compile, due to some changes in the kernel API lately. Yes, I suspect the probe order is significant, but the only system I use USB devices on is my laptop and I really don't want to roll it back to stable. I can continue to work around it until you have a set of current patches for me to try. I'm really anxious to try out the new stack as I am hoping it will make USB behave better in terma of power management on my laptop. That's why i don't build USB into my kernel, but just load it when I need it. I don't normally read usb@, so I may drop you a note in a couple of weeks to see if the stack has been updated for current. If you install the SVN version of my USB stack, and you are running the latest 7-CURRENT, then you need to patch the following by hand: Insert a NULL argument, to all bus_setup_intr() functions you find under /sys/dev/usb/, like shown below ? error = bus_setup_intr(dev, sc-sc_irq_res, INTR_TYPE_TTY, - si_intr, sc, ih); + NULL, si_intr, sc, ih); That's it. Then it should compile. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB error
On Monday 12 March 2007 00:15, Rick Mullis wrote: Hi Hans, I have been using and testing your new usb and today I have been getting an error. First of all I am using amd64 with the Intel DG965RY mainboard, dou core 2 prcessor with 4 gb of ram. After discussing a problem with you, you recommended I insert NULL in all of the files that have bus_setup_intr which ended up being 3 files ehci_pci.c, ohci_pci.c and uhci_pci.c and that fixed the problem until today when I svn the latest src from you and the latest 7-current src and recompiled. Below is the last few lines before error. cc -c -O -pipe -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/uart/uart_tty.c cc -c -O -pipe -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/usb/ehci.c *** Error code 1 Did you do things in this order: 1) cvsup 2) svn update 3) make S=../src package 4) make install 5) build new kernel --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB
On Monday 12 March 2007 00:36, Rick Mullis wrote: /usr/src/sys/sys/systm.h They defined msleep() like this: +#definemsleep(chan, mtx, pri, wmesg, timo) \ + _sleep((chan), (mtx)-mtx_object, (pri), (wmesg), (timo)) Arg. Well, I think the new _sleep() has the same problem like the old one. It doesn't take Giant as a sleeping mutex argument. Try definition msleep() like this in /sys/dev/usb/usb_port.h: #undef msleep #define msleep(i,m,p,w,t) _sleep(i,(((m) == Giant) ? NULL : (m)-mtx_object),p,w,t) --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Devices
Hi John, On Monday 19 March 2007 08:07, John Andrewartha wrote: Hi, A small problem that I need assistance with please. I a now the proud owner of a 3G+ 850 MHz USB modem from CMOTECH it uses a real usb hub. In AU it's called NextG wireless Internet, every where else something else. I was able to modify my old usbdevs and usb_quirks.c to make a modem card from the same vendor work with FreeBSD 6.1. I posted the diff for that mid last year. The following from usbdevs -v for the new device I can't get to attach. addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 addr 2: full speed, power 500 mA, config 1, CMOTECH CDMA Technologies(0x6280), CMOTECH CO., LTD.(0x16d8), rev 0.00 port 2 powered Device that does work addr 1: full speed, self powered, config 1, OHCI root hub(0x), (0x11c1) (0x), rev 1.00 port 1 addr 2: full speed, power 100 mA, config 1, CMOTECH CDMA Technologies(0x5523), CMOTECH CO., LTD.(0x16d8), rev 0.00 port 2 powered This card is just that a PCM card that reports as a usb device. I cheated and changed usbdevs entry for CMOTECH from 0x5523 to 0x6280, rebuilt the kernel, and, failed. Any suggestions and hints appreciated. If you load ugen, and run /usr/ports/sysutils/udesc_dump ? What do you get then ? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDCE
On Friday 23 March 2007 08:29, Anne wrote: Hi again, Am I on the correct list for this question? Yes. New peice of hardware, no specs, is a HPSDA wireless modem from Cmotech device id 0x6280. Cmotech have not yet listed it. I have modified if_cdce.c to recognise the new hardware, I have 3 cdcd ifaces. I need to treat the virtuel ethernet (cdce) as a serial device. I have to attach a tty with cua?? to the CDCE. How do I do it. PPPoE wont work. I have to create ttys. I have spent 4 days on this a solution would make my day. John Hi John, Could you maybe install /usr/ports/sysutils/udesc_dump Then kldload ugen. Make sure that your device attaches like ugen, and post the USB descriptors of your device? That is the output from udesc_dump. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EHCI and Isochronous transfer support in FreeBSD
On Friday 23 March 2007 22:14, Antonio Vivaldi wrote: Hello, I'd like to know what is the status about the support of USB isochronous transfers (used by many video devices for realtime streaming) in the current version of FreeBSD. Hi Antonio, You are encouraged to write drivers for the new USB driver, see http://www.turbocat.net/~hselasky/usb4bsd .. if you need good isochronous support. The new USB driver supports, high and full speed isochronous pipes. Currently it does not compile with the latest 7-Current, but I compiles fine with 6.x. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
USB Summer Of Code
Hi, If someone here is interested in doing a summer on the USB project, as a part of Google Summer of Code, then please contact Luigi Rizzo [EMAIL PROTECTED] before the 26th of March. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full
On Monday 26 March 2007 16:13, Markus Henschel wrote: Number: 110855 Category: usb Synopsis: ugen: interrupt in msgs are truncated when buffer is full Confidential: no Severity: serious Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 Closed-Date: Last-Modified: Originator: Markus Henschel Release:6.2 custom kernel Organization: Bally Wulff Automaten GmbH Environment: FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 21:28:38 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BALLYWULFF i386 Description: We use ugen for some user space drivers. When an interrupt in endpoint is used ugen creates a queue that is filled by the kernel. The user space driver is responsible for reading data from the device file. If this happens too slow the queue is full and new msgs arriving from the usb device are lost. This behavior is OK. The problem is that the queue is not a multiple of the interrupt in endpoints msgs size. So it is possible that the last msg in the queue is truncated. This is very hard to detect for a user space driver. The data stream seen by the user space driver will contain an incomplete msgs directly followed by the next message without knowing truncation happened (except when using some data corruption detection mechanism). It would be much better if ugen would fill the queues of interrupt in endpoints until there is no more space for a complete msg. This way the user space driver will not loose sync with the incoming msgs. The new USB stack has this fixed already. What I do is that the USB driver stops polling the interrupt endpoint when the user-land application does not read data. When the user-land application has read a packet, the interrupt endpoint is started again. The only problem is that some devices, like a Microsoft mouse I have, stops working immediately when its internal buffer overflows. Bad hardware design. But if your hardware is not like that, the new ugen, which is part of the new USB driver, will work great for you. Also packet alignment is kept between reads: Only one packet per read. See: http://www.turbocat.net/~hselasky/usb4bsd --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full
The following reply was made to PR usb/110855; it has been noted by GNATS. From: Hans Petter Selasky [EMAIL PROTECTED] To: freebsd-usb@freebsd.org Cc: Markus Henschel [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full Date: Mon, 26 Mar 2007 16:30:23 +0200 On Monday 26 March 2007 16:13, Markus Henschel wrote: Number: 110855 Category: usb Synopsis: ugen: interrupt in msgs are truncated when buffer is full Confidential: no Severity: serious Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 Closed-Date: Last-Modified: Originator: Markus Henschel Release:6.2 custom kernel Organization: Bally Wulff Automaten GmbH Environment: FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 21:28:38 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BALLYWULFF i386 Description: We use ugen for some user space drivers. When an interrupt in endpoint is used ugen creates a queue that is filled by the kernel. The user space driver is responsible for reading data from the device file. If this happens too slow the queue is full and new msgs arriving from the usb device are lost. This behavior is OK. The problem is that the queue is not a multiple of the interrupt in endpoints msgs size. So it is possible that the last msg in the queue is truncated. This is very hard to detect for a user space driver. The data stream seen by the user space driver will contain an incomplete msgs directly followed by the next message without knowing truncation happened (except when using some data corruption detection mechanism). It would be much better if ugen would fill the queues of interrupt in endpoints until there is no more space for a complete msg. This way the user space driver will not loose sync with the incoming msgs. The new USB stack has this fixed already. What I do is that the USB driver stops polling the interrupt endpoint when the user-land application does not read data. When the user-land application has read a packet, the interrupt endpoint is started again. The only problem is that some devices, like a Microsoft mouse I have, stops working immediately when its internal buffer overflows. Bad hardware design. But if your hardware is not like that, the new ugen, which is part of the new USB driver, will work great for you. Also packet alignment is kept between reads: Only one packet per read. See: http://www.turbocat.net/~hselasky/usb4bsd --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full
The following reply was made to PR usb/110855; it has been noted by GNATS. From: Hans Petter Selasky [EMAIL PROTECTED] To: Markus Henschel [EMAIL PROTECTED] Cc: freebsd-usb@freebsd.org, [EMAIL PROTECTED] Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full Date: Tue, 27 Mar 2007 18:43:08 +0200 On Tuesday 27 March 2007 11:30, Markus Henschel wrote: Hans Petter Selasky schrieb: On Monday 26 March 2007 16:13, Markus Henschel wrote: Number: 110855 Category: usb Synopsis: ugen: interrupt in msgs are truncated when buffer is full Confidential: no Severity: serious Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 Closed-Date: Last-Modified: Originator: Markus Henschel Release:6.2 custom kernel Organization: Bally Wulff Automaten GmbH Environment: FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 21:28:38 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BALLYWULFF i386 Description: We use ugen for some user space drivers. When an interrupt in endpoint is used ugen creates a queue that is filled by the kernel. The user space driver is responsible for reading data from the device file. If this happens too slow the queue is full and new msgs arriving from the usb device are lost. This behavior is OK. The problem is that the queue is not a multiple of the interrupt in endpoints msgs size. So it is possible that the last msg in the queue is truncated. This is very hard to detect for a user space driver. The data stream seen by the user space driver will contain an incomplete msgs directly followed by the next message without knowing truncation happened (except when using some data corruption detection mechanism). It would be much better if ugen would fill the queues of interrupt in endpoints until there is no more space for a complete msg. This way the user space driver will not loose sync with the incoming msgs. The new USB stack has this fixed already. What I do is that the USB driver stops polling the interrupt endpoint when the user-land application does not read data. When the user-land application has read a packet, the interrupt endpoint is started again. The only problem is that some devices, like a Microsoft mouse I have, stops working immediately when its internal buffer overflows. Bad hardware design. But if your hardware is not like that, the new ugen, which is part of the new USB driver, will work great for you. Also packet alignment is kept between reads: Only one packet per read. See: http://www.turbocat.net/~hselasky/usb4bsd --HPS Thanks, I gave it a try and it seems to work fine :-). Could you please explain how reading an interrupt in endpoint works internally with the new ugen? Is there still a buffer that recieves data from the endpoint or is each read request from user land synchronously triggering a read data request on the interrupt endpoint? Yes, there is a buffer, but the buffer is packet-based, and not a ring based, so you will never get problem with packet alignment. Why isn't O_NONBLOCK working anymore? It is implemented, and it should work. Can you explain more what is not working? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full
On Tuesday 27 March 2007 18:55, Markus Henschel wrote: Hans Petter Selasky schrieb: On Tuesday 27 March 2007 11:30, Markus Henschel wrote: Hans Petter Selasky schrieb: On Monday 26 March 2007 16:13, Markus Henschel wrote: Number: 110855 Category: usb Synopsis: ugen: interrupt in msgs are truncated when buffer is full Confidential: no Severity: serious Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 Closed-Date: Last-Modified: Originator: Markus Henschel Release:6.2 custom kernel Organization: Bally Wulff Automaten GmbH Environment: FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 21:28:38 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BALLYWULFF i386 Description: We use ugen for some user space drivers. When an interrupt in endpoint is used ugen creates a queue that is filled by the kernel. The user space driver is responsible for reading data from the device file. If this happens too slow the queue is full and new msgs arriving from the usb device are lost. This behavior is OK. The problem is that the queue is not a multiple of the interrupt in endpoints msgs size. So it is possible that the last msg in the queue is truncated. This is very hard to detect for a user space driver. The data stream seen by the user space driver will contain an incomplete msgs directly followed by the next message without knowing truncation happened (except when using some data corruption detection mechanism). It would be much better if ugen would fill the queues of interrupt in endpoints until there is no more space for a complete msg. This way the user space driver will not loose sync with the incoming msgs. The new USB stack has this fixed already. What I do is that the USB driver stops polling the interrupt endpoint when the user-land application does not read data. When the user-land application has read a packet, the interrupt endpoint is started again. The only problem is that some devices, like a Microsoft mouse I have, stops working immediately when its internal buffer overflows. Bad hardware design. But if your hardware is not like that, the new ugen, which is part of the new USB driver, will work great for you. Also packet alignment is kept between reads: Only one packet per read. See: http://www.turbocat.net/~hselasky/usb4bsd --HPS Thanks, I gave it a try and it seems to work fine :-). Could you please explain how reading an interrupt in endpoint works internally with the new ugen? Is there still a buffer that recieves data from the endpoint or is each read request from user land synchronously triggering a read data request on the interrupt endpoint? Yes, there is a buffer, but the buffer is packet-based, and not a ring based, so you will never get problem with packet alignment. Why isn't O_NONBLOCK working anymore? It is implemented, and it should work. Can you explain more what is not working? --HPS With the old ugen I did something like: int iDevice=open(/dev/ugen0.4, O_RDONLY); fcntl(iDevice, F_SETFL, O_NONBLOCK); I've just committed a patch for that to the P4 tree. It will be in SVN in not too long. It was just the matter of a missing IOCTL that F_SETFL uses. Usually the following works when you want to set/clear non-blocking mode: int t = 1; fcntl(iDevice, FIONBIO, t) Now the fcntl call fails. But instead this works and does the same: int iDevice=open(/dev/ugen0.4, O_RDONLY|O_NONBLOCK); I thought the O_NONBLOCK flag was just for the open call itself?!? Whatever, it does what I need :-) The only thing that keeps me from using the new usb stack is umass now. When inserting an usb flash memory stick it is detected and says umass attached to ii but then it takes ages (more that 30s) for the device files to become available. A camcontrol rescan all hangs during this time too.Is it possible to use the old umass with the new stack or just revert umass to an older version from you like 1.6.1? If you use the SVN version, reverting won't help much. Could you turn on debugging: sysctl hw.usb.umass.debug=-1 And see what is going on when you plug your umass device. BTW: The performance of the new usb stack is great. umass throughput with the memory stick nearly increased by 50%!! Cool. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full
The following reply was made to PR usb/110855; it has been noted by GNATS. From: Hans Petter Selasky [EMAIL PROTECTED] To: Markus Henschel [EMAIL PROTECTED] Cc: freebsd-usb@freebsd.org, [EMAIL PROTECTED] Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full Date: Tue, 27 Mar 2007 21:33:37 +0200 On Tuesday 27 March 2007 18:55, Markus Henschel wrote: Hans Petter Selasky schrieb: On Tuesday 27 March 2007 11:30, Markus Henschel wrote: Hans Petter Selasky schrieb: On Monday 26 March 2007 16:13, Markus Henschel wrote: Number: 110855 Category: usb Synopsis: ugen: interrupt in msgs are truncated when buffer is full Confidential: no Severity: serious Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 Closed-Date: Last-Modified: Originator: Markus Henschel Release:6.2 custom kernel Organization: Bally Wulff Automaten GmbH Environment: FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 21:28:38 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BALLYWULFF i386 Description: We use ugen for some user space drivers. When an interrupt in endpoint is used ugen creates a queue that is filled by the kernel. The user space driver is responsible for reading data from the device file. If this happens too slow the queue is full and new msgs arriving from the usb device are lost. This behavior is OK. The problem is that the queue is not a multiple of the interrupt in endpoints msgs size. So it is possible that the last msg in the queue is truncated. This is very hard to detect for a user space driver. The data stream seen by the user space driver will contain an incomplete msgs directly followed by the next message without knowing truncation happened (except when using some data corruption detection mechanism). It would be much better if ugen would fill the queues of interrupt in endpoints until there is no more space for a complete msg. This way the user space driver will not loose sync with the incoming msgs. The new USB stack has this fixed already. What I do is that the USB driver stops polling the interrupt endpoint when the user-land application does not read data. When the user-land application has read a packet, the interrupt endpoint is started again. The only problem is that some devices, like a Microsoft mouse I have, stops working immediately when its internal buffer overflows. Bad hardware design. But if your hardware is not like that, the new ugen, which is part of the new USB driver, will work great for you. Also packet alignment is kept between reads: Only one packet per read. See: http://www.turbocat.net/~hselasky/usb4bsd --HPS Thanks, I gave it a try and it seems to work fine :-). Could you please explain how reading an interrupt in endpoint works internally with the new ugen? Is there still a buffer that recieves data from the endpoint or is each read request from user land synchronously triggering a read data request on the interrupt endpoint? Yes, there is a buffer, but the buffer is packet-based, and not a ring based, so you will never get problem with packet alignment. Why isn't O_NONBLOCK working anymore? It is implemented, and it should work. Can you explain more what is not working? --HPS With the old ugen I did something like: int iDevice=open(/dev/ugen0.4, O_RDONLY); fcntl(iDevice, F_SETFL, O_NONBLOCK); I've just committed a patch for that to the P4 tree. It will be in SVN in not too long. It was just the matter of a missing IOCTL that F_SETFL uses. Usually the following works when you want to set/clear non-blocking mode: int t = 1; fcntl(iDevice, FIONBIO, t) Now the fcntl call fails. But instead this works and does the same: int iDevice=open(/dev/ugen0.4, O_RDONLY|O_NONBLOCK); I thought the O_NONBLOCK flag was just for the open call itself?!? Whatever, it does what I need :-) The only thing that keeps me from using the new usb stack is umass now. When inserting an usb flash memory stick it is detected and says umass attached to ii but then it takes ages (more that 30s) for the device files to become available. A camcontrol rescan all hangs during this time too.Is it possible to use the old umass with the new stack or just revert umass to an older version from you like 1.6.1? If you use the SVN version, reverting won't help much. Could you turn on debugging: sysctl hw.usb.umass.debug=-1 And see what is going on when you plug your umass device. BTW: The performance of the new usb stack is great. umass throughput with the memory
Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full
On Wednesday 28 March 2007 11:41, Markus Henschel wrote: Hans Petter Selasky schrieb: The following reply was made to PR usb/110855; it has been noted by GNATS. Hi, Could you edit /sys/dev/usb/umass.c Then lookup: usbd_delay_ms(uaa-device, 1000); Change it into: usbd_delay_ms(uaa-device, 5000); Then lookup in the function umass_attach(): sc-sc_last_xfer_index = UMASS_T_BBB_COMMAND; and change it into: sc-sc_last_xfer_index = UMASS_T_BBB_RESET2; Compile a new kernel and see what happens when you plug the stick again. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110989: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken
On Thursday 29 March 2007 02:17, Michael Gmelin wrote: Number: 110989 Category: usb Synopsis: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken Confidential: no Severity: serious Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu Mar 29 00:30:09 GMT 2007 Closed-Date: Last-Modified: Originator: Michael Gmelin Release:FreeBSD 6.2-RELEASE-p3 i386 Organization: /bin/done digital solutions GmbH Environment: FreeBSD bombat.bindone.de 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #21: Wed Mar 28 04:08:44 CEST 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/bombat i386 Description: I had to add a new device to usbdevs/umass.c which requires the IGNORE_RESIDUE quirk to be set (extra PR will follow). It didn't work, because IGNORE_RESIDUE isn't handled properly in umass.c (it isn't really handled at all, since Residue is set in lines are 1668-1672 in umass.c in the following was: int Residue; Residue = UGETDW(sc-csw.dCSWDataResidue); if (Residue == 0 sc-transfer_datalen - sc-transfer_actlen != 0) Residue = sc-transfer_datalen - sc-transfer_actlen; The patch below fixes this issue (tested and proven to work). How-To-Repeat: Use a really broken USB device which returns random values for sc-csw.dCSWDataResidue (like devices that use the SuperTop IDEDEVICE USB controller, e.g. the ICY BOX IB-220U-Wh). Every attempt to use the device will lead to error messages, like: dd if=/dev/zero of=/dev/da0 count=10 da0: end of device or disklabel da0 read: Unknown error etc. Fix: Apply the attached patch, which forces residue to be calculated if IGNORE_RESIDUE is set. Patch attached with submission follows: --- umass.c.orig Thu Mar 29 02:07:04 2007 +++ umass.c Thu Mar 29 02:08:06 2007 @@ -1666,7 +1666,10 @@ } int Residue; - Residue = UGETDW(sc-csw.dCSWDataResidue); + if (sc-quirks IGNORE_RESIDUE) + Residue = 0; + else + Residue = UGETDW(sc-csw.dCSWDataResidue); if (Residue == 0 sc-transfer_datalen - sc-transfer_actlen != 0) Residue = sc-transfer_datalen - sc-transfer_actlen; Release-Note: Audit-Trail: Unformatted: The new USB stack doesn't have this fix either, but could you have tried the new USB stack, and then turn on debugging, sysctl hw.usb.umass.debug=-1, so that we can see what the wrong residues look like. See: http://www.turbocat.net/~hselasky/usb4bsd I recommend the SVN version on a 6-STABLE box. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: about usb of freeBSD
On Friday 30 March 2007 10:42, Alexander Leidinger wrote: Quoting PS [EMAIL PROTECTED] (from Fri, 30 Mar 2007 00:51:47 -0700 (PDT)): Dear all, I just read the usb source code of freeBSD, but I can't understand it clearly. Can anybody give me the simple analyse or structure of it ? Have a look at http://www.leidinger.net/FreeBSD/src_docs/ there's dev_usb.pdf. It is the result of a doxygen run over our usb code. It's all we can provide in this regard. Could you generate the same PDF for the new USB stack ? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card)
On Saturday 31 March 2007 00:02, Hofmann, Laurent wrote: Hello, I have a strange problem with my USB Sound Card. I found some records using Google, but they are all old and never answered. I'm using the kernel module snd_uaudio to use an USB Sound Card (kldload uaudio) on Freebsd 6.2-RELEASE. Usb Sound Card is a Hercule Muse Pocket LT. When playing audio (using PulseAudio), after around 2 hours, I get a kernel panic followed by a system reboot : 19:33:14 dolphin kernel: usb0: isoc TD alloc failed And/Or Mar 30 17:56:58 dolphin kernel: panic: kmem_malloc(12288): kmem_map too small: 42278912 total allocated. I can reproduce it as needed. How can we try to deal with this problem and find out what is wrong ? The new USB stack has got a new uaudio driver also. I would try that first. How to get the latest sources: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install Then edit the file install_uaudio.sh and change it as needed, if you are not installing to /usr/src. ./install_uaudio.sh I am not sure what patches they MFC'ed from head to 6.2 release, regarding the sound system, so it might be that my uaudio.c won't compile. But that can easily be fixed if you send me the compile log where it breaks. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a41x/v32x driver
On Saturday 31 March 2007 11:51, 3s3_l00n3y wrote:
would u be able to send me the a41x/v32x driver
I see this in usb_quirks.c:
{ USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_A41XV32X,
ANY, { UQ_ASSUME_CM_OVER_DATA }},
I think your device should be detected by umodem. Try kldload umodem.
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call For Testers: axe(4) with Ax88178 and Ax88772 support
On Friday 30 March 2007 20:50, J.R. Oldroyd wrote: On Feb 15, 19:33, J.R. Oldroyd wrote: I have updated the axe(4) driver with Ax88178 and Ax88772 support. Go here to get it: http://opal.com/jr/freebsd/sys/dev/usb/ My original version of these Ax88178 and Ax88772 enhancements (back in February) did not use the chips' input frame bursting because the FreeBSD usb_ether framework does not support it. I have now enhanced the driver, removing its use of the usb_ether framework, and doing its own buffer management with large input buffers which can handle bursts of multiple input frames in one buffer. The diffs and files on the web page referenced above have been updated for this new version. The driver appears to work, and I have set it to burst up to 4096 bytes. The device can actually burst up to 16384 bytes. However, if I set it to burst more than 4096 bytes, the usb layer (ehci on my test system) stalls, and all input stops after just a few input frames. I'd appreciate feedback from anyone if larger burst sizes work for you. See the notes on that web page for details of how to change the driver's burst size. This sounds like a problem with the EHCI driver. If I pull your changes into the new USB stack, which will take some hours, can you do some work to install and test it? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card)
On Saturday 31 March 2007 13:01, Hofmann, Laurent wrote: Thanks. I did what you told me, but when I compile the kernel, it crashes compiling umass.c (Don't know how it is related ?) Just do a SVN update and try again. By a mistake I removed a patch for FreeBSD 6.2. By the way, if someone needs uaudio driver files for FreeBSD 7-current, then feel free to contact me, hence they made some changes to the FreeBSD 7-current sound API. When I did make install it merged a lot of things in my /usr/src/sys, not only audio... Is that normal ? Yes, that is normal. The new USB stack contains rewritten USB drivers of all kinds. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card)
On Saturday 31 March 2007 14:30, Hofmann, Laurent wrote: -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Hans Petter Selasky Envoyé : samedi 31 mars 2007 13:16 À : freebsd-usb@freebsd.org Objet : Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) Just do a SVN update and try again. By a mistake I removed a patch for FreeBSD 6.2. --HPS Thank you very much. It compiled like a charm. I also included the driver in the kernel instead of using it as a module. I'm now playing some music, I will tell you if the kernel panic still occur... Ok. Just one more remark : The driver is not detected as before : uaudio0: Guillemot USB Audio, class 0/0, rev 1.10/1.00, addr 126 uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format uaudio0: No midi sequencer uaudio0: WARNING: Unplugging the device while it is in use will cause a panic! pcm0: USB audio on uaudio0 dolphin# cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: USB audio at ? (1p/1r/0v channels duplex default) Before I had more lines, one of these lines was indicating a 6 channel device. Now I have the feeling that only the front channels are available ? I don't know if the current audio system supports more than 2 channels. There is a knob in uaudio.c that you can tune: static u_int8_t uaudio_default_channels = 2; But you probably have to add some code to tell the upper sound layers that there is more than 2 channels! PS : Do you know when these drivers will be included in Freebsd ? I hoped before 7.0 was out, but it might be later. I am not the one deciding that. But if many people like you turn up and tell the list how much faster and how much more solid the new USB stack is, then it might happen faster ;-) --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I make the USB Devices?
On Sunday 01 April 2007 15:50, SEan Strand wrote: Hi-Ho, am running i386on an HP Pavilion t3345.uk amd machine. When I first loaded this machine it would mount my IOMega drives - no problems. Now, since I recompiled the kernel it will not make the devices. So I reloaded and remake the filesystems. So How do I re-make the usb devices, so I can mount the external IOMega drives? Oh there are no reported controllers working, but this is being typed from a wireless usb keyboard and mouse. Any help would be most welcome, Did you load umass and usb ? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
axe(4) with Ax88178 and Ax88772 support (update)
Hi,
I have just updated if_axe.c to support Ax88178 and Ax88772.
If you have one of the following products:
{ USB_VENDOR_ABOCOM, USB_PRODUCT_ABOCOM_UF200, 0 },
{ USB_VENDOR_ACERCM, USB_PRODUCT_ACERCM_EP1427X2, 0 },
{ USB_VENDOR_ASIX, USB_PRODUCT_ASIX_AX88172, 0 },
{ USB_VENDOR_ASIX, USB_PRODUCT_ASIX_AX88178, AXE_FLAG_178 },
{ USB_VENDOR_ASIX, USB_PRODUCT_ASIX_AX88772, AXE_FLAG_772 },
{ USB_VENDOR_ATEN, USB_PRODUCT_ATEN_UC210T, 0 },
{ USB_VENDOR_BELKIN, USB_PRODUCT_BELKIN_F5D5055 , AXE_FLAG_178 },
{ USB_VENDOR_BILLIONTON, USB_PRODUCT_BILLIONTON_USB2AR, 0},
{ USB_VENDOR_CISCOLINKSYS, USB_PRODUCT_CISCOLINKSYS_USB200MV2, AXE_FLAG_772 },
{ USB_VENDOR_COREGA, USB_PRODUCT_COREGA_FETHER_USB2_TX , 0},
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DUBE100, 0 },
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DUBE100B1 , AXE_FLAG_772 },
{ USB_VENDOR_GOODWAY, USB_PRODUCT_GOODWAY_GWUSB2E, 0 },
{ USB_VENDOR_IODATA, USB_PRODUCT_IODATA_ETGUS2, AXE_FLAG_178 },
{ USB_VENDOR_JVC, USB_PRODUCT_JVC_MP_PRX1, 0 },
{ USB_VENDOR_LINKSYS2, USB_PRODUCT_LINKSYS2_USB200M, 0 },
{ USB_VENDOR_LINKSYS4, USB_PRODUCT_LINKSYS4_USB1000, AXE_FLAG_178 },
{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_LUAU2KTX, 0 },
{ USB_VENDOR_NETGEAR, USB_PRODUCT_NETGEAR_FA120, 0 },
{ USB_VENDOR_OQO, USB_PRODUCT_OQO_ETHER01PLUS, AXE_FLAG_772 },
{ USB_VENDOR_PLANEX3, USB_PRODUCT_PLANEX3_GU1000T , AXE_FLAG_178 },
{ USB_VENDOR_SITECOM, USB_PRODUCT_SITECOM_LN029, 0 },
{ USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_LN028 , AXE_FLAG_178 },
{ USB_VENDOR_SYSTEMTALKS, USB_PRODUCT_SYSTEMTALKS_SGCX2UL, 0 },
Could you install the new USB stack and see if your AXE device works?
svn --username anonsvn --password anonsvn \
checkout svn://svn.turbocat.net/i4b
#
# The following commands will
# install the driver on FreeBSD:
#
cd i4b/trunk/i4b/FreeBSD.usb
make S=../src package
make install
Thanks,
--HPS
To J.R. Oldroyd: You've got homework ;-)
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
On Tuesday 03 April 2007 13:27, Xiaofan Chen wrote: I was redirected to this list as per the suggestion from the libusb mailing list. It will be greatly appreciated that someone can suggest how to debug this problem? With the new USB stack installed, do like this: sysctl hw.usb.debug=15 Then run you program. Then get all the lines with ugen() in the debug output. sysctl hw.usb.debug=0 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
Hi, I think that your device is broken, and goes bad when it receives a clear-stall request for the interrupt pipe. That is not very uncommon. Could you try the attached patch. Just apply the patch by hand if patch won't take it. The file in question is /sys/dev/usb/ugen.c . After that, compile a new ugen module or kernel. If you are using the ugen module, then you can simply do like this after that you have re-installed it: kldunload ugen kldload ugen --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
On Wednesday 04 April 2007 01:55, Xiaofan Chen wrote: On 4/3/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: Hi, I think that your device is broken, and goes bad when it receives a clear-stall request for the interrupt pipe. That is not very uncommon. Could you be more clearer? I'd like to communicate this problem to the firmware developer of PICKit 2 inside Microchip. Thanks. The chip does not handle a clear-stall request on the control pipe to clear-stall on the interrupt pipe. The result is that the interrupt pipe stops, or at least all buffers are cleared. I could be more detailed, but I think the developers will understand what I mean. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Siemens C75 uplcom no support
Hi, Could you install the new USB stack, and then apply the attached patch. Maybe you have to apply the patch by hand. The files you find under /sys/dev/usb . # # Install /usr/ports/devel/subversion first # svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install PS: I am not 100% sure if your device should be TYPE_PL2303 or TYPE_PL2303X. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: msleep redefined error in hselasky/usb4bsd/ svn patch against -current
On Wednesday 04 April 2007 19:41, Mark Atkinson wrote: I get the following error when trying to compile the proposed usb4bsd stack against current. In file included from /usr/src/sys/dev/usb/ehci.c:67: /usr/src/sys/dev/usb/usb_port.h:293:1: msleep redefined In file included from /usr/src/sys/dev/usb/ehci.c:58: /usr/src/sys/sys/systm.h:313:1: this is the location of the previous definition *** Error code 1 Sure enough, it is intentionally redefined: sys/dev/usb/usb_port.h:290-293 /* preliminary fix for a bug in msleep on FreeBSD, * which cannot sleep with Giant: */ #define msleep(i,m,p,w,t) msleep(i,(((m) == Giant) ? NULL : (m)),p,w,t) When I integrate my driver against FreeBSD-7 current, I will add some #if statements for those issues. Until further: In /sys/dev/usb/usb_port.h, use the following: /* preliminary fix for a bug in msleep on FreeBSD, * which cannot sleep with Giant: */ #undef msleep #define msleep(i,m,p,w,t) _sleep(i,(((m) == Giant) ? \ NULL : (m)-mtx_object),p,w,t) After this patch you have to insert a NULL argument, to all bus_setup_intr() functions you find in the files /sys/dev/usb/*pci.c like shown below ? error = bus_setup_intr(dev, sc-sc_irq_res, INTR_TYPE_TTY, - si_intr, sc, ih); + NULL, si_intr, sc, ih); Hope that is not too much patching. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110988: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken
On Wednesday 04 April 2007 16:09, grem wrote: Hi, is there any way to get this into the source tree? Yes, I can take this patch into the P4 tree if you change it a little bit. I want this invalid residue detection to be all automatic: If the first residue you get is invalid, then it should use the USB transfer counts for residue for the rest of the lifetime of the device. Else it should use the standard invalid residue check. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: msleep redefined error in hselasky/usb4bsd/ svn patch against -current
On Thursday 05 April 2007 16:47, Mark Atkinson wrote: Hans Petter Selasky wrote: On Wednesday 04 April 2007 19:41, Mark Atkinson wrote: I get the following error when trying to compile the proposed usb4bsd stack against current. In file included from /usr/src/sys/dev/usb/ehci.c:67: /usr/src/sys/dev/usb/usb_port.h:293:1: msleep redefined In file included from /usr/src/sys/dev/usb/ehci.c:58: /usr/src/sys/sys/systm.h:313:1: this is the location of the previous definition *** Error code 1 Sure enough, it is intentionally redefined: sys/dev/usb/usb_port.h:290-293 /* preliminary fix for a bug in msleep on FreeBSD, * which cannot sleep with Giant: */ #define msleep(i,m,p,w,t) msleep(i,(((m) == Giant) ? NULL : (m)),p,w,t) When I integrate my driver against FreeBSD-7 current, I will add some #if statements for those issues. Until further: In /sys/dev/usb/usb_port.h, use the following: /* preliminary fix for a bug in msleep on FreeBSD, * which cannot sleep with Giant: */ #undef msleep #define msleep(i,m,p,w,t) _sleep(i,(((m) == Giant) ? \ NULL : (m)-mtx_object),p,w,t) After this patch you have to insert a NULL argument, to all bus_setup_intr() functions you find in the files /sys/dev/usb/*pci.c like shown below ? error = bus_setup_intr(dev, sc-sc_irq_res, INTR_TYPE_TTY, - si_intr, sc, ih); + NULL, si_intr, sc, ih); Hope that is not too much patching. --HPS Not enough patching.. :-) Even with these changes, it still generates warnings on this macro. Since kernel compiles are with -Werr and -Wnested-externs, this kills the compile when dereferencing msleep() /usr/src/sys/dev/usb/ugen.c: In function `ugenwrite': /usr/src/sys/dev/usb/ugen.c:1260: warning: nested extern declaration of `msleep' /usr/src/sys/dev/usb/ugen.c:562: warning: redundant redeclaration of 'msleep' /usr/src/sys/dev/usb/ugen.c:562: warning: previous implicit declaration of 'msleep' was here *** Error code 1 Could you send me your /usr/src/sys/dev/usb/usb_port.h . Are you sure that you applied my patch correctly? msleep() should not be undefined. Rather msleep() should expand to _sleep() . --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: axe(4) with Ax88178 and Ax88772 support (update)
On Tuesday 10 April 2007 21:58, J.R. Oldroyd wrote: On Apr 02, 23:00, Hans Petter Selasky wrote: Could you install the new USB stack and see if your AXE device works? I have tested the Ax88772 import in your new USB stack. It does move packets, but rx is very slow. Tx gets me around 650-750 kB/s on a large file scp. Rx gets me only 35 kB/s on the same file. By comparisson, this driver in the current USB stack in 6-stable gets me full speed for both tx and rx. Haven't had time to debug but will try to over the next few days. Good that it works. You know that there is a sysctl, hw.usb.axe.debug, that you can set to 15, to see what is going on. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: axe(4) with Ax88178 and Ax88772 support (update)
On Tuesday 10 April 2007 22:07, Hans Petter Selasky wrote: On Tuesday 10 April 2007 21:58, J.R. Oldroyd wrote: On Apr 02, 23:00, Hans Petter Selasky wrote: Could you install the new USB stack and see if your AXE device works? I have tested the Ax88772 import in your new USB stack. It does move packets, but rx is very slow. Tx gets me around 650-750 kB/s on a large file scp. Rx gets me only 35 kB/s on the same file. By comparisson, this driver in the current USB stack in 6-stable gets me full speed for both tx and rx. Haven't had time to debug but will try to over the next few days. Good that it works. You know that there is a sysctl, hw.usb.axe.debug, that you can set to 15, to see what is going on. It might have something to do with me setting burst size to the maximum, which didn't work at all, according to you, in the old USB stack. Hope to hear from you soon. --HPS PS: If you didn't know, you can save some debugging time by loading/unloading the if_axe module instead of building a new kernel every time you make a change to the source code. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FBSD 6.0 UGEN
On Thursday 12 April 2007 08:29, Z3tbl4 [] wrote: Greetings everyone! Could someone ,please, advice me a solution to solve such problem- i have an usb device, which is present in my FBSD 6.0 as /dev/ugen0 and /dev/ugen0.1 i need to send to this device 5 bytes and read from it 3 bytes but i'm not good in usb protocol and i don't get a right result . here is my test code in C. Thank you. There are many ways to write data to an USB device. Do you have the documentation for your USB device? And what does it say? What endpoint should be used? [control, bulk or isochronous] --HPS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ASAP, Help with driver Motorola Razr V3c usb phone freebsd6.0
Hi, What do you want to do with your phone? --HPS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: did you ever get the usb driver
On Tuesday 17 April 2007 21:50, Aaron bryant wrote: I'm also looking for the a41x driver What kind of device is that? A mobile phone? What services do you want to use over USB? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110988: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken
On Thursday 19 April 2007 02:54, grem wrote: Hans Petter Selasky wrote: On Friday 06 April 2007 16:56, grem wrote: Hans Petter Selasky wrote: On Wednesday 04 April 2007 16:09, grem wrote: Hi, is there any way to get this into the source tree? Yes, I can take this patch into the P4 tree if you change it a little bit. I want this invalid residue detection to be all automatic: If the first residue you get is invalid, then it should use the USB transfer counts for residue for the rest of the lifetime of the device. Else it should use the standard invalid residue check. --HPS Imho we should support both, so that devices which are so broken that we can't detect the invalid residue (like I tried to point out before) still have the quirk so force it manually. Ok, no problem, but like Alexander Leidinger pointed out, the current flag does not do anything, and should be removed from a couple of devices. Can you do the autodetection on your own or do you want me to do the change to the patch and repost it so you can review? I have only one broken USB device, so if anyone out there has access to more it would be extremely helpful. I can make a patch for this, and send it to you for testing, during the next week. --HPS Any progress? :) Hence I started in a new job this week, I have postponed this to the weekend. I will make a posting to the list when I have got something finished. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass0: BBB reset failed, TIMEOUT on internal card reader
On Thursday 19 April 2007 20:13, Mike Durian wrote: I just installed a Shuttle PC22 22-in-1 Card Reader and get umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, TIMEOUT umass0: BBB bulk-out clear stall failed, TIMEOUT errors without any media inserted. From dmesg: umass0: USB2.0 CardReader, rev 2.00/91.44, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: USB2.0 CF CardReader 9144 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: USB2.0 SM CardReader 9144 Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 target 0 lun 2 da2: USB2.0 SD CardReader 9144 Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: USB2.0 MS CardReader 9144 Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present From usbdevs -v: addr 1: high speed, self powered, config 1, EHCI root hub(0x), VIA(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 addr 2: high speed, power 500 mA, config 1, CardReader(0x0500), USB2.0 (0x07cc), rev 91.44 port 6 powered port 7 powered port 8 powered It looks like the device is using a Carry WIN II chip. I believe the part number for this chip is 0639MMTQM03-07G. There is also a smaller ST chip on the board. Otherwise it is just physical connectors and discretes. I suspect umass.c needs a umass_devdescrs entry for this device. How does one go about determining the necessary proto and quirk values? I would suggest you install the new USB stack from: http://www.turbocat.net/~hselasky/usb4bsd/ How to get the latest sources: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install Install on FreeBSD 6.x . When you have rebooted your computer, then you turn on debugging: sysctl hw.usb.umass.debug=-1 Then post the dmesg you get. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/107642: [patch]Ralink Technology RT2501USB/RT2601USB chipset driver
On Monday 30 April 2007 18:41, Valery V.Chikalov wrote:
Hans Petter Selasky wrote:
On Monday 30 April 2007 14:34, Valery V.Chikalov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Lo пишет:
Valery V.Chikalov wrote:
Hans Petter Selasky wrote:
On Sunday 29 April 2007 15:02, Valery V.Chikalov wrote:
Kevin Lo wrote:
Valery V.Chikalov wrote:
The following reply was made to PR usb/107642; it has been noted
by GNATS.
From: Valery V.Chikalov [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: usb/107642: [patch]Ralink Technology
RT2501USB/RT2601USB chipset driver
Date: Sun, 22 Apr 2007 11:32:18 +0300
This is a multi-part message in MIME format.
--030900090303000507070905
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
if_rum(4) for 7.0-CURRENT
replaced amrr_* functions by standard ones already existed in
net80211/ieee80211_amrr.c
Hi Valery,
I guess you wasn't aware that I've already ported rum(4) to
FreeBSD. The patch is available at:
http://people.freebsd.org/~kevlo/patch-rum Maybe you can test my
patch? Thanks.
Kevin
Hi, Kevin,
Your driver not working for me. Fortunately, the errors that I see
exactly the same which i fight when I made my driver.
$ uname -a
FreeBSD tiger.novakom.dp.ua 7.0-CURRENT FreeBSD 7.0-CURRENT #6: Sun
Apr 29 13:58:48 EEST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TIGER64 amd64
$ sysctl kern.osreldate
kern.osreldate: 700037
cvsup'ed 29.04.2007
kernel with:
makeoptions DEBUG=-g
options KDB
options DDB
options INVARIANTS
options INVARIANT_SUPPORT
options WITNESS
At first, when I make kldload if_rum, I get kernel panic.
But I cant get saved core, as ddb just hangs during call doadump
I have a solution for all of this locking stuff!
So I add
#define RUM_LOCK(sc)do { ((sc) = (sc)); mtx_lock(Giant); }
while (0)
#define RUM_UNLOCK(sc) mtx_unlock(Giant)
in if_rumvar.h
I spend a lot of time in attempts get rid of Giant ant always got
only panics.
You _cannot_ do that with the old USB stack, because you must lock
Giant before calling into the usbxxx functions. Then in the USB
callback, Giant is locked, and then you cannot lock RUM_LOCK()! That
means you will most likely end up with a deadlock pretty soon, if you
see that.
Thanks, for explanations. I suspected that thing are like that, and I
have tried make porting by analogue with other drivers which I can
find in dev/usb, but I was not can find the description of doing
right way locking before.
Firstly, thanks for taking the time to test my patch.
I think your issue is related to watchdog timers. The revised patch is
at http://people.freebsd.org/~kevlo/patch-rum
Besides, I don't get a panic during high load when getting a file about
400MB via ftp.
Sorry, but the error that I see the same, just after inserting dongle,
or if it was inserted before - after kldload if_rum:
panic: sleeping without a lock
the top of stack:
at usbd_transfer +0x1fe
rum_ioctl
And I cant get saved kernel coredump at the end.
I have not serial console configured so it was just subscribed by hand.
Of course I can reproduce it again and subscribe what you will ask.
I have SMP kernel and use AMD64 architecture, maybe this are the reasons
why we are getting different results.
Can you please, explain me in two words(or give a reference) why you are
dropping mtx_lock(Giant). Yes I have seen the same in if_ural.c and as
i have wrote before unsuccessfully have tried repeat it in if_rum. I
know that current USB stack is not Giant free, and Hans noted that this
is impossible (if I understand him right). Maybe exists some tunable or
kernel option or another trick that allows drivers working without the
Giant under current USB stack, which I must use.
Thank you for your time and patience.
Sorry for my english.
Valery.
After that I get hangs,
which i resolved by modifying rum_ioctl:
I'm almost finished converting if_rum.c() to the new USB stack.
In some hours I will update it with support for if_rum.
If you can test that and forget about the old USB stack, I will be
very happy :-)
I will do it with pleasure. I was almost ready to do it (converting to
new USB stack) by myself, but I was stopped by the fact that I cant
make it compiled under CURRENT. I have seen your mail that your are
working on this. Is new the USB stack ready for CURRENT now?
Valery.
--HPS
http://www.turbocat.net/~hselasky/usb4bsd
Kevin
Hi,
I have just imported if_rum.c to SVN and my P4 tree.
Just do a SVN update. Build a new USB package install that.
cp -r i4b/trunk/i4b/src/sys/modules/rum /usr/src/sys/modules/rum
make -C /usr/src/sys/modules/rum all
Re: usb/107642: [patch]Ralink Technology RT2501USB/RT2601USB chipset driver
On Monday 30 April 2007 21:19, Valery V.Chikalov wrote:
Hans Petter Selasky wrote:
On Monday 30 April 2007 18:41, Valery V.Chikalov wrote:
Hans Petter Selasky wrote:
On Monday 30 April 2007 14:34, Valery V.Chikalov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Lo пишет:
Valery V.Chikalov wrote:
Hans Petter Selasky wrote:
On Sunday 29 April 2007 15:02, Valery V.Chikalov wrote:
Kevin Lo wrote:
Valery V.Chikalov wrote:
The following reply was made to PR usb/107642; it has been noted
by GNATS.
From: Valery V.Chikalov [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: usb/107642: [patch]Ralink Technology
RT2501USB/RT2601USB chipset driver
Date: Sun, 22 Apr 2007 11:32:18 +0300
This is a multi-part message in MIME format.
--030900090303000507070905
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
if_rum(4) for 7.0-CURRENT
replaced amrr_* functions by standard ones already existed in
net80211/ieee80211_amrr.c
Hi Valery,
I guess you wasn't aware that I've already ported rum(4) to
FreeBSD. The patch is available at:
http://people.freebsd.org/~kevlo/patch-rum Maybe you can test my
patch? Thanks.
Kevin
Hi, Kevin,
Your driver not working for me. Fortunately, the errors that I see
exactly the same which i fight when I made my driver.
$ uname -a
FreeBSD tiger.novakom.dp.ua 7.0-CURRENT FreeBSD 7.0-CURRENT #6:
Sun Apr 29 13:58:48 EEST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TIGER64 amd64
$ sysctl kern.osreldate
kern.osreldate: 700037
cvsup'ed 29.04.2007
kernel with:
makeoptions DEBUG=-g
options KDB
options DDB
options INVARIANTS
options INVARIANT_SUPPORT
options WITNESS
At first, when I make kldload if_rum, I get kernel panic.
But I cant get saved core, as ddb just hangs during call doadump
I have a solution for all of this locking stuff!
So I add
#define RUM_LOCK(sc)do { ((sc) = (sc)); mtx_lock(Giant); }
while (0)
#define RUM_UNLOCK(sc) mtx_unlock(Giant)
in if_rumvar.h
I spend a lot of time in attempts get rid of Giant ant always got
only panics.
You _cannot_ do that with the old USB stack, because you must lock
Giant before calling into the usbxxx functions. Then in the USB
callback, Giant is locked, and then you cannot lock RUM_LOCK()!
That means you will most likely end up with a deadlock pretty soon,
if you see that.
Thanks, for explanations. I suspected that thing are like that, and
I have tried make porting by analogue with other drivers which I can
find in dev/usb, but I was not can find the description of doing
right way locking before.
Firstly, thanks for taking the time to test my patch.
I think your issue is related to watchdog timers. The revised patch
is at http://people.freebsd.org/~kevlo/patch-rum
Besides, I don't get a panic during high load when getting a file
about 400MB via ftp.
Sorry, but the error that I see the same, just after inserting dongle,
or if it was inserted before - after kldload if_rum:
panic: sleeping without a lock
the top of stack:
at usbd_transfer +0x1fe
rum_ioctl
And I cant get saved kernel coredump at the end.
I have not serial console configured so it was just subscribed by
hand. Of course I can reproduce it again and subscribe what you will
ask.
I have SMP kernel and use AMD64 architecture, maybe this are the
reasons why we are getting different results.
Can you please, explain me in two words(or give a reference) why you
are dropping mtx_lock(Giant). Yes I have seen the same in if_ural.c
and as i have wrote before unsuccessfully have tried repeat it in
if_rum. I know that current USB stack is not Giant free, and Hans
noted that this is impossible (if I understand him right). Maybe
exists some tunable or kernel option or another trick that allows
drivers working without the Giant under current USB stack, which I
must use.
Thank you for your time and patience.
Sorry for my english.
Valery.
After that I get hangs,
which i resolved by modifying rum_ioctl:
I'm almost finished converting if_rum.c() to the new USB stack.
In some hours I will update it with support for if_rum.
If you can test that and forget about the old USB stack, I will be
very happy :-)
I will do it with pleasure. I was almost ready to do it (converting
to new USB stack) by myself, but I was stopped by the fact that I
cant make it compiled under CURRENT. I have seen your mail that your
are working on this. Is new the USB stack ready for CURRENT now?
Valery.
--HPS
http://www.turbocat.net/~hselasky/usb4bsd
Kevin
Hi,
I have just imported if_rum.c to SVN and my P4 tree.
Just do a SVN update. Build a new USB package install that.
cp -r i4b
Re: New USB drivers
On Friday 04 May 2007 20:06, Kevin Oberman wrote: I have now been running the Hans Petter's USB drivers for about a week and they have been working pretty well. That said, I have seen two things that concern me. 1. Today I connected a USB disk to the system. It ran fine, but then I dismounted it (using nautilus and hald), the window informing me that the device could be safely removed popped up and I unplugged the drive. At that point, my system live-locked. I did see some updates to windows, but I could not change focus to a different window nor could I move to a different desktop. I tried CTRL-ALT-BS to kill X, but it would not work. I tried CTRL-ALT-DEL to reboot the system. No joy. The system was at least partly alive as the disk activity LED would flash now and then. I eventually had to power-cycle it. :-( As a result I have pretty much no information to help track this one down. This is a problem in the CAM layer. It does not really support detaching the SIM I think. Scott: When will this issue be fixed ? 2. I use dd to mirror my system disk on a weekly basis. I track the performance of dd during this operation and, with no other changes than the USB stack being added to the kernel, the average transfer rate dropped from 17.43 MB to 17.15 MB. Not huge, but quite noticeable when copying an 80 GB drive. I run this in single-user mode with no partitions mounted (except root mounted read-only), so USB previously had not even been loaded, so the old drivers may have had even a greater impact. And the difference may not be the USB stack, but nothing else was changed. It will take more time to tell if there is a real problem here, but I wanted to provide a little (very little, I admit) information on my experience. Ok. Thanks, Hans, for all of your work on this. You're welcome. There will be more USB stack changes coming soon. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/112461: ehci USB 2.0 doesn't work on nforce4
On Sunday 06 May 2007 13:51, Igor Popov wrote: Number: 112461 Category: usb Synopsis: ehci USB 2.0 doesn't work on nforce4 Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun May 06 12:00:11 GMT 2007 Closed-Date: Last-Modified: Originator: Igor Popov Release:6.0, 6.1, 6.2 Organization: Environment: FreeBSD unix.my.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL i386 Description: I have motherboard(Asus A8N-E) that built on nforce4 chipset, it has usb 2.0 ports, but under FreeBSD with usb 2.0 flashdrive max speed near 1.2Mb/s on file copying (my custom kernel has ehci driver), that is usb1.[01] speed. But under both linux an windows with the same flashdrive speed is near 10Mb/s. Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL ACPI APIC Table: Nvidia AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff2 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA ,CM OV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow AMD Features2=0x1LAHF real memory = 536805376 (511 MB) avail memory = 507523072 (484 MB) ioapic0 Version 1.1 irqs 0-23 on motherboard wlan: mac acl policy registered ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: Nvidia AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: memory at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 nfsmb0: nForce2/3/4 MCP SMBus Controller port 0xe400-0xe41f,0x4c00-0x4c3f,0x4c 40-0x4c7f irq 20 at device 1.1 on pci0 smbus0: System Management Bus on nfsmb0 smb0: SMBus generic I/O on smbus0 nfsmb1: nForce2/3/4 MCP SMBus Controller on nfsmb0 smbus1: System Management Bus on nfsmb1 smb1: SMBus generic I/O on smbus1 ohci0: OHCI (generic) USB controller mem 0xd3104000-0xd3104fff irq 21 at devic e 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: NVIDIA nForce4 USB 2.0 controller mem 0xfeb0-0xfeb000ff irq 22 at d evice 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: NVIDIA nForce4 USB 2.0 controller on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered pcm0: nVidia nForce4 port 0xdc00-0xdcff,0xe000-0xe0ff mem 0xd3103000-0xd3103ff f irq 23 at device 4.0 on pci0 pcm0: Avance Logic ALC850 AC97 Codec atapci0: nVidia nForce CK804 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0 x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: nVidia nForce CK804 SATA300 controller port 0x9f0-0x9f7,0xbf0-0xbf3,0 x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd3102000-0xd3102fff irq 21 at device 7.0 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 atapci2: nVidia nForce CK804 SATA300 controller port 0x9e0-0x9e7,0xbe0-0xbe3,0 x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd3101000-0xd3101fff irq 22 at device 8.0 on pci0 ata4: ATA channel 0 on atapci2 ata5: ATA channel 1 on atapci2 pcib1: ACPI PCI-PCI bridge at device 9.0 on pci0 pci5: ACPI PCI bus on pcib1 ath0: Atheros 5212 mem 0xd300-0xd300 irq 16 at device 6.0 on pci5 ath0: Ethernet address: 00:15:e9:a4:58:9b ath0: mac 7.9 phy 4.5 radio 5.6 nfe0: NVIDIA nForce4 CK804 MCP9 Networking Adapter port 0xb000-0xb007 mem 0xd3 10-0xd3100fff irq 23 at device 10.0 on pci0 miibus0: MII bus on nfe0 e1000phy0: Marvell 88E Gigabit PHY on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX,
Re: usb/112461: ehci USB 2.0 doesn't work on nforce4
The following reply was made to PR usb/112461; it has been noted by GNATS. From: Hans Petter Selasky [EMAIL PROTECTED] To: freebsd-usb@freebsd.org Cc: Igor Popov [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: usb/112461: ehci USB 2.0 doesn't work on nforce4 Date: Sun, 6 May 2007 14:24:56 +0200 On Sunday 06 May 2007 13:51, Igor Popov wrote: Number: 112461 Category: usb Synopsis: ehci USB 2.0 doesn't work on nforce4 Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun May 06 12:00:11 GMT 2007 Closed-Date: Last-Modified: Originator: Igor Popov Release:6.0, 6.1, 6.2 Organization: Environment: FreeBSD unix.my.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL i386 Description: I have motherboard(Asus A8N-E) that built on nforce4 chipset, it has usb 2.0 ports, but under FreeBSD with usb 2.0 flashdrive max speed near 1.2Mb/s on file copying (my custom kernel has ehci driver), that is usb1.[01] speed. But under both linux an windows with the same flashdrive speed is near 10Mb/s. Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL ACPI APIC Table: Nvidia AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff2 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA ,CM OV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow AMD Features2=0x1LAHF real memory = 536805376 (511 MB) avail memory = 507523072 (484 MB) ioapic0 Version 1.1 irqs 0-23 on motherboard wlan: mac acl policy registered ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: Nvidia AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: memory at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 nfsmb0: nForce2/3/4 MCP SMBus Controller port 0xe400-0xe41f,0x4c00-0x4c3f,0x4c 40-0x4c7f irq 20 at device 1.1 on pci0 smbus0: System Management Bus on nfsmb0 smb0: SMBus generic I/O on smbus0 nfsmb1: nForce2/3/4 MCP SMBus Controller on nfsmb0 smbus1: System Management Bus on nfsmb1 smb1: SMBus generic I/O on smbus1 ohci0: OHCI (generic) USB controller mem 0xd3104000-0xd3104fff irq 21 at devic e 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: NVIDIA nForce4 USB 2.0 controller mem 0xfeb0-0xfeb000ff irq 22 at d evice 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: NVIDIA nForce4 USB 2.0 controller on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered pcm0: nVidia nForce4 port 0xdc00-0xdcff,0xe000-0xe0ff mem 0xd3103000-0xd3103ff f irq 23 at device 4.0 on pci0 pcm0: Avance Logic ALC850 AC97 Codec atapci0: nVidia nForce CK804 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0 x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: nVidia nForce CK804 SATA300 controller port 0x9f0-0x9f7,0xbf0-0xbf3,0 x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd3102000-0xd3102fff irq 21 at device 7.0 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 atapci2: nVidia nForce CK804 SATA300 controller port 0x9e0-0x9e7,0xbe0-0xbe3,0 x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd3101000-0xd3101fff irq 22 at device 8.0 on pci0 ata4: ATA channel 0 on atapci2 ata5: ATA channel 1 on atapci2 pcib1: ACPI PCI-PCI bridge at device 9.0 on pci0 pci5: ACPI PCI bus on pcib1 ath0: Atheros 5212
Re: usb/112461: ehci USB 2.0 doesn't work on nforce4
On Monday 07 May 2007 08:09, Igor Popov wrote: Good morning. On Sunday 06 May 2007 13:51, Igor Popov wrote: Number: 112461 Category: usb Synopsis: ehci USB 2.0 doesn't work on nforce4 Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun May 06 12:00:11 GMT 2007 Closed-Date: Last-Modified: Originator: Igor Popov Release:6.0, 6.1, 6.2 Organization: Environment: FreeBSD unix.my.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL i386 Description: I have motherboard(Asus A8N-E) that built on nforce4 chipset, it has usb 2.0 ports, but under FreeBSD with usb 2.0 flashdrive max speed near 1.2Mb/s on file copying (my custom kernel has ehci driver), that is usb1.[01] speed. But under both linux an windows with the same flashdrive speed is near 10Mb/s. Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL ACPI APIC Table: Nvidia AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff2 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE ,M CA ,CM OV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow AMD Features2=0x1LAHF real memory = 536805376 (511 MB) avail memory = 507523072 (484 MB) ioapic0 Version 1.1 irqs 0-23 on motherboard wlan: mac acl policy registered ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: Nvidia AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: memory at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 nfsmb0: nForce2/3/4 MCP SMBus Controller port 0xe400-0xe41f,0x4c00-0x4c3f,0x4c 40-0x4c7f irq 20 at device 1.1 on pci0 smbus0: System Management Bus on nfsmb0 smb0: SMBus generic I/O on smbus0 nfsmb1: nForce2/3/4 MCP SMBus Controller on nfsmb0 smbus1: System Management Bus on nfsmb1 smb1: SMBus generic I/O on smbus1 ohci0: OHCI (generic) USB controller mem 0xd3104000-0xd3104fff irq 21 at devic e 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: NVIDIA nForce4 USB 2.0 controller mem 0xfeb0-0xfeb000ff irq 22 at d evice 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: NVIDIA nForce4 USB 2.0 controller on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered pcm0: nVidia nForce4 port 0xdc00-0xdcff,0xe000-0xe0ff mem 0xd3103000-0xd3103ff f irq 23 at device 4.0 on pci0 pcm0: Avance Logic ALC850 AC97 Codec atapci0: nVidia nForce CK804 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0 x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: nVidia nForce CK804 SATA300 controller port 0x9f0-0x9f7,0xbf0-0xbf3,0 x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd3102000-0xd3102fff irq 21 at device 7.0 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 atapci2: nVidia nForce CK804 SATA300 controller port 0x9e0-0x9e7,0xbe0-0xbe3,0 x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd3101000-0xd3101fff irq 22 at device 8.0 on pci0 ata4: ATA channel 0 on atapci2 ata5: ATA channel 1 on atapci2 pcib1: ACPI PCI-PCI bridge at device 9.0 on pci0 pci5: ACPI PCI bus on pcib1 ath0: Atheros 5212 mem 0xd300-0xd300 irq 16 at device 6.0 on pci5 ath0: Ethernet address: 00:15:e9:a4:58:9b ath0: mac 7.9 phy 4.5
Re: usb/112461: ehci USB 2.0 doesn't work on nforce4
The following reply was made to PR usb/112461; it has been noted by GNATS. From: Hans Petter Selasky [EMAIL PROTECTED] To: Igor Popov [EMAIL PROTECTED] Cc: freebsd-usb@freebsd.org, [EMAIL PROTECTED] Subject: Re: usb/112461: ehci USB 2.0 doesn't work on nforce4 Date: Mon, 7 May 2007 15:12:50 +0200 On Monday 07 May 2007 08:09, Igor Popov wrote: Good morning. On Sunday 06 May 2007 13:51, Igor Popov wrote: Number: 112461 Category: usb Synopsis: ehci USB 2.0 doesn't work on nforce4 Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun May 06 12:00:11 GMT 2007 Closed-Date: Last-Modified: Originator: Igor Popov Release:6.0, 6.1, 6.2 Organization: Environment: FreeBSD unix.my.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL i386 Description: I have motherboard(Asus A8N-E) that built on nforce4 chipset, it has usb 2.0 ports, but under FreeBSD with usb 2.0 flashdrive max speed near 1.2Mb/s on file copying (my custom kernel has ehci driver), that is usb1.[01] speed. But under both linux an windows with the same flashdrive speed is near 10Mb/s. Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL ACPI APIC Table: Nvidia AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff2 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE ,M CA ,CM OV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow AMD Features2=0x1LAHF real memory = 536805376 (511 MB) avail memory = 507523072 (484 MB) ioapic0 Version 1.1 irqs 0-23 on motherboard wlan: mac acl policy registered ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: Nvidia AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: memory at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 nfsmb0: nForce2/3/4 MCP SMBus Controller port 0xe400-0xe41f,0x4c00-0x4c3f,0x4c 40-0x4c7f irq 20 at device 1.1 on pci0 smbus0: System Management Bus on nfsmb0 smb0: SMBus generic I/O on smbus0 nfsmb1: nForce2/3/4 MCP SMBus Controller on nfsmb0 smbus1: System Management Bus on nfsmb1 smb1: SMBus generic I/O on smbus1 ohci0: OHCI (generic) USB controller mem 0xd3104000-0xd3104fff irq 21 at devic e 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: NVIDIA nForce4 USB 2.0 controller mem 0xfeb0-0xfeb000ff irq 22 at d evice 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: NVIDIA nForce4 USB 2.0 controller on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered pcm0: nVidia nForce4 port 0xdc00-0xdcff,0xe000-0xe0ff mem 0xd3103000-0xd3103ff f irq 23 at device 4.0 on pci0 pcm0: Avance Logic ALC850 AC97 Codec atapci0: nVidia nForce CK804 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0 x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: nVidia nForce CK804 SATA300 controller port 0x9f0-0x9f7,0xbf0-0xbf3,0 x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd3102000-0xd3102fff irq 21 at device 7.0 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 atapci2: nVidia nForce CK804 SATA300 controller port 0x9e0
Re: No scanners were identified, with new USB driver
On Tuesday 08 May 2007 23:28, Andrew Muhametshin wrote: Hello I have tried to take advantage of new usb-driver (http://www.turbocat.net/~hselasky/usb4bsd/index.html). But there were problems -- program (sane) cannot find out the device... Did you try kldload uscanner ? Then re-plug your scanner and see if it doesn't show up. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/106621: [usb] DLINK DUB-E100 support broken
On Monday 14 May 2007 14:02, Ingo Bormuth wrote:
Hi usb team,
just wondering whether there is any progress on this one.
If not, I'd be glad to do my best trying to fix it myself.
Coming from linux though I'm pretty new to freebsd's internals
and politics. Eventually I might need some assistance.
Is there any prior work outside of the official cvs?
Which would be the best irc channel to contact relevant peers?
Thanks
Ingo
Hi,
In my if_axe.c :
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DUBE100, 0 },
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DUBE100B1 , AXE_FLAG_772 },
So it is not working?
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: All-in-one printer/scanner dilemma
Hi, On Wednesday 16 May 2007 21:30, Mikhail T. wrote: Hans Petter Selasky wrote: You mean, sane may be able to access the scanner part, even if ulpt is attached? Yes, but that may [or can be] change[d]. I'm confused, are you saying, it may be possible to share the functionality /now/? So, which device should I give to sane? The /dev/ulpt0? No, you need to change uscanner.c so that it does not grab the complete device, but rather just one interface. Also you need some information which interface is the scanner and which is the printer. We're talking some time this year. Great -- the sooner the better, thank you! (Frankly, it is embarrassing, that we did not have it 3 years ago :-( Not to point any fingers at anyone in particular.) --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Linux USB emulation layer now committed to my new USB stack for FreeBSD
Hi, If you are interested, the files are: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.c http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.h It is almost finished now. And it is not very much code. Also I have a preliminary patch for Luigi's webcam driver! But it does not compile yet. NOTE: Before you use a Linux USB endpoint you have to call: usb_setup_endpoint() with the buffer size you want. For isoc transfers the buffer size is ignored. Just set a dummy value. Do you have time to fix the rest Luigi? The Linux USB compat layer is in SVN and P4. http://www.turbocat.net/~hselasky/usb4bsd --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux USB emulation layer now committed to my new USB stack for FreeBSD
On Friday 18 May 2007 13:53, Luigi Rizzo wrote:
On Fri, May 18, 2007 at 01:04:17PM +0200, Hans Petter Selasky wrote:
Hi,
If you are interested, the files are:
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_co
mpat_linux.c
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_co
mpat_linux.h
It is almost finished now.
And it is not very much code.
Also I have a preliminary patch for Luigi's webcam driver! But it does
not compile yet.
NOTE: Before you use a Linux USB endpoint you have to call:
usb_setup_endpoint() with the buffer size you want. For isoc transfers
the buffer size is ignored. Just set a dummy value.
Do you have time to fix the rest Luigi?
not now, sorry.
But seeing the patch that you attach, let me kindly comment once
again (i have already told you multiple time) that this approach
of ignoring compatibility with existing code (usb stack/api/emulation
layer, linux device drivers) and not commenting code at all is really a
showstopper for getting your code tested and/or accepted.
That documentation you want has been moved to the README and to
usb_compat_linux.{c,h}. The rest has been stripped off. It simply not needed!
And it describes stuff that is no longer valid.
Feel free to add documentation to my _new_ driver, and spend some time on that
instead. The old USB stack will be supported when I have time to make an
emulation for that also.
E.g. see usb_compat_linux.c in the url above - basically the only
comment is the copyright - way too little for anyone to understand
what is done there.
It is so simple that comments are just in the way. When I started out reading
your Linux USB compatibility layer, I didn't understand anything until most
of the comments where stripped away.
usb_compat_linux.h is just a copy of stuff in the existing linux
usb emulation, _but_ without any comments at all (and there was a
lot of them in the existing code).
Way too many comments.
Undocumented code is almost useless for us, and nobody has the
time to reverse engineer your code and document its architecture.
It is around 1000 lines of code read.
Again, send me a patch with the comments you feel are missing, and I will add
it to my driver. And make sure that your comments are up to date.
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
On Sunday 27 May 2007 22:54, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : I've got some reports back that some USB host controllers do not support : transferring memory from a location higher than 2GB. : : What should we do about this? : : Should we limit all USB DMA allocations to the lower 2GB of the memory? busdma should be managing this behind the scenes. You shouldn't care, as the problematical usb controllers, if any, can do the bouncing as required. We need to get the hierarchical bus tagging stuff more fully integrated, then we'd get this for free. Yes, I just changed the lowaddr when I allocated the tag, and that did the trick! Of course, you'd have to stop using contigmalloc to allocate all the memory for usb. That won't work on some of the embedded platforms we have, for example, because memory on them isn't as fungible as it is on i386 and amd64. My new USB stack has been using bus_dmamem for quite a while. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
On Sunday 27 May 2007 23:53, John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Sun, May 27, 2007 at 22:35 +0200: I've got some reports back that some USB host controllers do not support transferring memory from a location higher than 2GB. What should we do about this? Should we limit all USB DMA allocations to the lower 2GB of the memory? No, a quirk table should be setup and pass the restriction to bus_dma at tag initalization time when a broken controller is detected.. Yes, I can do that. But I am also thinking about a static quirk, like a sysctl you can set at boot time. I hope that this is not a wide-spread problem. And I am not surprised that hardware manufacturers are not specification compliant, which really makes me wonder if they support a true 64-bit address bus on the EHCI controller at all. I would maybe cost too much money? And therefore we should just stick with 32-bit addressing on 32-bit platforms aswell. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/112461: ehci USB 2.0 doesn't work on nforce4
On Monday 28 May 2007 08:50, Igor Popov wrote: В сообщении от Sunday 13 May 2007 23:35:56 Hans Petter Selasky написал(а): On Tuesday 08 May 2007 08:19, Igor Popov wrote: В сообщении от Monday 07 May 2007 16:12:50 Hans Petter Selasky написал(а): On Monday 07 May 2007 08:09, Igor Popov wrote: Good morning. On Sunday 06 May 2007 13:51, Igor Popov wrote: Hi, I have recompiled kernel with new USB stack, now on files copying speed is about 3.8Mb/s, but it is still slower than linux or windows (~10Mb/s), may be it is by debug options in usb code. Could you supply some more details: How much ram has your system got? What filesystem is on your disks? What version of FreeBSD are you using? What is the dmesg when you boot? Hint: Simply run the dmesg command and pipe the output to a file. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ucom0: could not set data multiplex mode
On Monday 28 May 2007 11:39, Nikolay Pavlov wrote: Hi folks. I have an issue with CCU-550 CDMA modem (http://www.cmotech.com/eproduct6-1.htm) on recent current. Every time i am reattaching it i see this error: ucom0: could not set data multiplex mode So in order to work with it i have to reboot after each detache procedure. The only known workaround for this is to delete the goto bad; code in /usr/src/sys/dev/usb/umodem.c: printf(%s: could not set data multiplex mode\n, devname); goto bad; Could someone comment on this? P.S. Please cc me, becuase i am not subscribe to freebsd-usb or freebsd-mobile I'm not sure if it will help, but there is a new USB stack that you can try: http://www.turbocat.net/~hselasky/usb4bsd Download the SVN version. I recommend installing on FreeBSD 6-stable, hence there is a small bug in the memory allocation code on FreeBSD 7-current, that will cause regular panics. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UMASS pbm at startup
On Monday 28 May 2007 20:01, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : On Monday 28 May 2007 18:52, Aymeric MUNTZ (Cerbere3) wrote: : Hi, : : I have a pbm with my usb disk-key under freebsd. : When i start the system (FreeBSD 5.2) with the key already plugged, it : is not recognised. If I unplug and replug it, it is recognised. : With an other motherboard, I do not have this problem. : : Is there a way to rescan for usb devices? I already tried camcontrol : rescan all with no success. : : Have you tried the SVN version of the new USB stack with FreeBSD 6.2 : installed? Let's just change one thing at a time... Try going to 6.2 first. changing both the usb stack and the freebsd version at one time might not be wise. We also need to track down problems in the current USB stack, since we are never going to put hps' stack into RELENG_6. Since it hasn't yet been committed to current and there's a freeze coming up shortly, it is doubtful that it will be in RELENG_7 either. We need to not view hps' stack as this magical thing that solves all problems because we have at least RELENG_6 to support for a while, and may have to support the current stack in RELENG_7 too. To be honest, I really wish Hans would be more pro-active in merging changes to the old stack so that the delta between it and his would be more manageable. I've said this plenty of times privately, but no fixes to the old stack have been forthcoming, not even new vendor IDs for existing drivers... My schedule is full. I'm tracking all changes going into HEAD at least. There are some deltas that could have been backported, but I do not specifically keep track of all the small things I fix. I would need a secretary for that :-) Any volunteers ;-) With regard to the topic of this thread I know about some specific issues that leaves the result that attached devices are not detected. This is related to missed PCD interrupts. You have to fake a PCD interrupt every time you enable the PCD again, to catch any missed PCD interrupts. The problem is the same with OHCI, but there this interrupt is called something else. The PCD interrupt is connected to the root interrupt endpoint on the root HUB, which is a virtual device. I think that this is the problem. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ucom0: could not set data multiplex mode
On Wednesday 06 June 2007 16:28, Nikolay Pavlov wrote: On Wednesday, 6 June 2007 at 13:48:43 +0400, Махматханов Руслан Казбекович wrote: Nikolay Pavlov пишет: Hi Warner and Ruslan. Warner i have found that Ruslan is the originator of the patches for umodem.c: http://www.freebsd.org/cgi/query-pr.cgi?pr=109838 So there is already a few CMOTECH devices there. In any case guys here is my usbdevs -v output: Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 addr 2: full speed, power 100 mA, config 1, CMOTECH CDMA Technologies(0x5533), CMOTECH CO., LTD.(0x16d8), rev 0.00 port 2 powered I am open to any test ;) Please, try attached patch: # cd /usr/src/sys/dev/usb # patch /path/to/ccu550.diff Then rebuild and reinstall kernel, reboot and try to use CCU550 with that new kernel. Patch is applying cleanly against in -CURRENT: - usb_quirks.c 1.41.2.8 - usbdevs 1.296 so update your sources if you have earlier versions of this files or adapt this patch for your files versions. Yes. This patch works for me. Thank you Ruslan. I can attach and detach the device for now: Jun 6 17:00:00 orion kernel: ucom0: CMOTECH CO., LTD. CMOTECH CDMA Technologies, class 2/0, rev 2.00/0.00, addr 2 on uhub1 Jun 6 17:00:00 orion kernel: ucom0: CMOTECH CO., LTD. CMOTECH CDMA Technologies, rev 2.00/0.00, addr 2, iclass 2/2 Jun 6 17:00:00 orion kernel: ucom0: data interface 1, has CM over data, has break Jun 6 17:00:00 orion kernel: ucom0: status change notification available Jun 6 17:02:08 orion kernel: ucom0: at uhub1 port 1 (addr 2) disconnected Jun 6 17:02:08 orion kernel: ucom0: detached Jun 6 17:02:44 orion root: Unknown USB device: vendor 0x16d8 product 0x5533 bus uhub1 Jun 6 17:02:44 orion kernel: ucom0: CMOTECH CO., LTD. CMOTECH CDMA Technologies, class 2/0, rev 2.00/0.00, addr 2 on uhub1 Jun 6 17:02:44 orion kernel: ucom0: CMOTECH CO., LTD. CMOTECH CDMA Technologies, rev 2.00/0.00, addr 2, iclass 2/2 Jun 6 17:02:44 orion kernel: ucom0: data interface 1, has CM over data, has break Jun 6 17:02:44 orion kernel: ucom0: status change notification available And it works. :) Is this possible to commit this Warner? However i have found one issue. If i am trying to detach it while mpd session is running i see this message from kernel: Jun 6 17:03:04 orion kernel: WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Jun 6 17:03:09 orion kernel: Sleeping on usbdly with the following non-sleepable locks held: Jun 6 17:03:09 orion kernel: exclusive sleep mutex ng_tty node+queue r = 0 (0xc712b6a0) locked @ /usr/src/sys/modules/netgraph/tty/../../../netgraph/ng_tt y.c:207 Jun 6 17:03:09 orion kernel: KDB: stack backtrace: Jun 6 17:03:09 orion kernel: db_trace_self_wrapper(c0a2f828,e69179d8,c07798cd,c0a2fbeb,e69179ec,...) at db_trace_self_wrapper+0x26 Jun 6 17:03:09 orion kernel: kdb_backtrace(c0a2fbeb,e69179ec,4,1,0,...) at kdb_backtrace+0x29 Jun 6 17:03:09 orion kernel: witness_warn(5,0,c0a2d773,c0a21ac6,0,...) at witness_warn+0x1cd Jun 6 17:03:09 orion kernel: _sleep(c0b36e14,0,0,c0a21ac6,3,...) at _sleep+0x5f Jun 6 17:03:09 orion kernel: pause(c0a21ac6,3,e6917a7c,c06b7ae3,c4002000,...) at pause+0x47 Jun 6 17:03:09 orion kernel: usb_delay_ms(c4002000,2,c4e23e98,c0adc224,c7109c62,...) at usb_delay_ms+0x5e Jun 6 17:03:09 orion kernel: uhci_abort_xfer(e6917a98,c06c831e,c68efc00,c4a08700,c4008800,...) at uhci_abort_xfer+0x163 Jun 6 17:03:09 orion kernel: uhci_device_bulk_abort(c68efc00,c4a08700,c4008800,e6917aa4,c0d0adc3,...) at uhci_device_bulk_abort+0x10 Jun 6 17:03:09 orion kernel: usbd_abort_pipe(c694dc80,e6917ab8,c0d0b56f,c4008800,3,...) at usbd_abort_pipe+0x1e Jun 6 17:03:09 orion kernel: ucomstopread(c4008800,3,2,e6917ad4,c0788436,...) at ucomstopread+0x23 Jun 6 17:03:09 orion kernel: ucomstop(c4008800,3,c712b680,0,c712b6a0,...) at ucomstop+0x5f Jun 6 17:03:09 orion kernel: ttyflush(c4008800,3,c7142095,c71420bd,1,...) at ttyflush+0x46 Jun 6 17:03:09 orion kernel: ngt_open(c5a36100,c4008800,368,367,c0b3d494,...) at ngt_open+0x16b Jun 6 17:03:09 orion kernel: ttioctl(c4008800,8004741b,c6732000,7,c4e23e00,...) at ttioctl+0xdf8 Jun 6 17:03:09 orion kernel: ttyioctl(c5a36100,8004741b,c6732000,7,c4e23e00,...) at ttyioctl+0x11a Jun 6 17:03:09 orion kernel: giant_ioctl(c5a36100,8004741b,c6732000,7,c4e23e00,...) at giant_ioctl+0x56 Jun 6 17:03:09 orion kernel: devfs_ioctl_f(c560e870,8004741b,c6732000,c6512c00,c4e23e00,...) at devfs_ioctl_f+0xc9 Jun 6 17:03:09 orion kernel: kern_ioctl(c4e23e00,9,8004741b,c6732000,917d38,...) at kern_ioctl+0x243 Jun 6 17:03:09 orion kernel: ioctl(c4e23e00,e6917cfc,c,c4e23e00,c0ad6430,...) at ioctl+0x134 Jun 6 17:03:09 orion kernel: syscall(e6917d38) at syscall+0x293 Jun 6 17:03:09 orion kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jun 6 17:03:09 orion
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
On Monday 28 May 2007 09:59, Julian Elischer wrote: John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Mon, May 28, 2007 at 08:53 +0200: On Sunday 27 May 2007 23:53, John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Sun, May 27, 2007 at 22:35 +0200: I've got some reports back that some USB host controllers do not support transferring memory from a location higher than 2GB. What should we do about this? Should we limit all USB DMA allocations to the lower 2GB of the memory? No, a quirk table should be setup and pass the restriction to bus_dma at tag initalization time when a broken controller is detected.. Yes, I can do that. But I am also thinking about a static quirk, like a sysctl you can set at boot time. The only issue w/ this is that it would also effect add in USB PCI cards that aren't effected by the bug... Which means a sysctl would limit the hardware to the lowest common denominator... I hope that this is not a wide-spread problem. And I am not surprised that hardware manufacturers are not specification compliant, which really makes me wonder if they support a true 64-bit address bus on the EHCI controller at all. I would maybe cost too much money? And therefore we should just stick with 32-bit addressing on 32-bit platforms aswell. Don't forget we have PAE for i386... so restricting to 32bit addressing for i386 would have an impact... As for it being an intermediate bus being the issue, I'd be surprised as that would mean that pci bridge to the USB controller is seriously broken... At least dealing w/ a intermediate bus is easier now that was have bus_get_dma_tag... I'd rather it were a screwed up MB than a screwed up chip :-) Ok. Here are the PCI ID's: [EMAIL PROTECTED]:11:0:class=0x0c0310 card=0x818a1043 chip=0x003b10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP04 USB Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:11:1:class=0x0c0310 card=0x818a1043 chip=0x003b10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP04 USB Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:11:2:class=0x0c0320 card=0x818a1043 chip=0x003c10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP04 USB Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:7:0: class=0x0c0310 card=0x00351033 chip=0x00351033 rev=0x41 hdr=0x00 vendor = 'NEC Electronics Hong Kong' device = 'uPD9210FGC-7EA / B5PD720101 USB 1.0 Host Controller (OHCI compliant)' class = serial bus subclass = USB [EMAIL PROTECTED]:7:1: class=0x0c0310 card=0x00351033 chip=0x00351033 rev=0x41 hdr=0x00 vendor = 'NEC Electronics Hong Kong' device = 'uPD9210FGC-7EA / B5PD720101 USB 1.0 Host Controller (OHCI compliant)' class = serial bus subclass = USB [EMAIL PROTECTED]:7:2: class=0x0c0320 card=0x29280e55 chip=0x00e01033 rev=0x02 hdr=0x00 vendor = 'NEC Electronics Hong Kong' device = 'uPD720100A/101 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB Can anyone find out if the USB hardware or the mainboard is not supporting 32 address lines from the text above? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
On Tuesday 12 June 2007 19:29, Julian Elischer wrote: Hans Petter Selasky wrote: On Monday 28 May 2007 09:59, Julian Elischer wrote: I'd rather it were a screwed up MB than a screwed up chip :-) Ok. Here are the PCI ID's: [EMAIL PROTECTED]:11:0:class=0x0c0310 card=0x818a1043 chip=0x003b10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP04 USB Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:11:1:class=0x0c0310 card=0x818a1043 chip=0x003b10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP04 USB Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:11:2:class=0x0c0320 card=0x818a1043 chip=0x003c10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP04 USB Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:7:0: class=0x0c0310 card=0x00351033 chip=0x00351033 rev=0x41 hdr=0x00 vendor = 'NEC Electronics Hong Kong' device = 'uPD9210FGC-7EA / B5PD720101 USB 1.0 Host Controller (OHCI compliant)' class = serial bus subclass = USB [EMAIL PROTECTED]:7:1: class=0x0c0310 card=0x00351033 chip=0x00351033 rev=0x41 hdr=0x00 vendor = 'NEC Electronics Hong Kong' device = 'uPD9210FGC-7EA / B5PD720101 USB 1.0 Host Controller (OHCI compliant)' class = serial bus subclass = USB [EMAIL PROTECTED]:7:2: class=0x0c0320 card=0x29280e55 chip=0x00e01033 rev=0x02 hdr=0x00 vendor = 'NEC Electronics Hong Kong' device = 'uPD720100A/101 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB Can anyone find out if the USB hardware or the mainboard is not supporting 32 address lines from the text above? is the problem with the nvidia or the NEC? I will try to find out. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass0: BBB reset failed, TIMEOUT on internal card reader
On Thursday 14 June 2007 18:31, Mike Durian wrote: On Saturday 26 May 2007, Mike Durian wrote: On Tuesday 24 April 2007, Hans Petter Selasky wrote: On Friday 20 April 2007 17:36, Mike Durian wrote: On Friday 20 April 2007, Hans Petter Selasky wrote: I would suggest you install the new USB stack from: http://www.turbocat.net/~hselasky/usb4bsd/ How to get the latest sources: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install Install on FreeBSD 6.x . When you have rebooted your computer, then you turn on debugging: sysctl hw.usb.umass.debug=-1 Then post the dmesg you get. --HPS I have found a small data-toggle bug in my EHCI driver. I assume that your device is USB2.0. Could you do a svn update, repeat the install procedure, and then build a new kernel. Then send me the dmesg with sysctl hw.usb.umass.debug=-1, when you plug your device. --HPS I've cvsup'd my source tree and svn updated the i4b code (both as of May 26, 2007) but I'm still not having any luck with the card reader. It seemed to work in single user mode, but fails in multi-user mode. It didn't detect card insertion in single user mode either. I had to unplug the entire card reader, insert the compact flash card and then plug-in the card reader to get it to detect the card in single user mode. I'm attaching two debug outputs. One from single user mode and the other from multi-user mode. mike Since I've hit a wall with the experimental USB code with regards to the card reader, perhaps it is time to return to my original question. How does one determine which proto and quirk values are necessary for finicky umass devices? mike You need to turn on umass debugging and see what fails. sysctl hw.usb.umass.debug=-1 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
