Current problem reports assigned to you
Current FreeBSD problem reports Critical problems S Tracker Resp. Description o usb/84750usb[hang] 6-BETA2 reboot/shutdown with root_fs on externa o usb/91629usbusbd_abort_pipe() may result in infinite loop 2 problems total. Serious problems S Tracker Resp. Description o usb/46176usb[panic] umass causes kernel panic if device removed be o i386/46371 usbUSB controller cannot be initialized on IBM Netfinity o usb/57085usb[umass] umass0 problems, with Sony Vio/USB memory stic o bin/57255usbusbd and multi-function devices o usb/62088usb[usb] Logitech Cordless/Optical Mouse not working o usb/63621usb[usb] USB MemoryStick Reader stalls/crashes system o usb/69006usb[patch] Apple Cinema Display hangs USB ports o usb/71155usb[usb] misbehaving usb-printer hangs processes, causes o usb/73307usb[panic] Kernel panics on USB disconnect o usb/74771usb[umass] mounting write-protected umass device as read/ o usb/75705usb[panic] da0 attach / Optio S4 (with backtrace) o usb/75797usb5.3-STABLE(2005 1/4) detect USB headset, But can not f o usb/76395usbUSB printer does not work, usbdevs says addr 0 should o usb/77184usb[panic] kernel panic on USB device disconnect o usb/77294usb[ulpcom] [panic] ucom + ulpcom panic o usb/79269usbUSB ohci da0 plug/unplug causes crashes and lockups. o usb/79287usb[uhci] UHCI hang after interrupt transfer o usb/79524usbprinting to Minolta PagePro 1[23]xxW via USB fails wit a usb/79656usb[usb] RHSC interrupts lost o usb/79722usb[usb] wrong alignments in ehci.h o usb/80040usb[hang] Use of sound mixer causes system freeze with ua o usb/80361usb[patch] mounting of usb-stick fails o usb/80829usbpossible panic when loading USB-modules o usb/80862usb[patch] USB locking issues: missing some Giant calls o usb/82350usb[usb] null pointer dereference in USB stack o usb/82520usbReboot when USL101 connected s usb/82569usb[usb] USB mass storage plug/unplug causes system panic o usb/82660usb[umass] [panic] EHCI: I/O stuck in state 'physrd'/pani o usb/83563usb[panic] Page Fault while detaching Mpman Usb device o usb/83677usb[usb] usb controller often not detected (Sun W2100z) o usb/83756usb[ums] [patch] Microsoft Intellimouse Explorer 4.0A doe o usb/83977usb[ucom] [panic] ucom1: open bulk out error (addr 2): IN o usb/84326usb[umass] Panic trying to connect SCSI tape drive via US o usb/84336usb[usb] [reboot] instant system reboot when unmounting a o usb/86031usbneed support usb nic rt2500 in my 5.4 STABLE o usb/86767usb[usb] [patch] bogus slice starts beyond end of the di o usb/88743usb[hang] USB makes kernel hang at boot (regression in 6. o usb/88966usb[modules] kldunload ucom.ko returns Device busy erro o usb/89003usbLaCie Firewire drive not properly supported under 6.0 o usb/89954usb[usb] USB Disk driver race condition? o usb/90700usb[umass] [panic] Kernel panic on connect/mount/use umas o usb/91238usb[umass] USB tape unit fails to write a second tape fil o usb/91283usbbooting very slow with usb devices connection (regress o usb/91538usb[ulpt] [patch] Unable to print to EPSON CX3500 o usb/91906usb[hang] FreeBSD hangs while booting with USB legacy sup o usb/92052usb[unlpt] usbd causes defunct process with busy file-han o usb/92083usb[ural] [panic] panic using WPA on ural NIC in 6.0-RELE o usb/92142usbSET_ADDR_FAILED and SHORT_XFER errors from usb drivers o usb/92171usb[panic] panic unplugging Vodafone Mobile Connect (UMTS o usb/93155usb[ulpt] /dev/ulpt0: device busy, USB printer does not w o usb/93408usb[mouse] hw.acpi.cpu.cx_lowest=C3 on AMD Turion causes o usb/93640usb[irq] device ehci causes interrupt storm on this MSI a o usb/93828usb[panic] ohci causes panic on boot (HP Pavillion d4100e o usb/94166usbbtx halted with a flashcard plugged o usb/94384usb[panic] kernel panic with usb2 hardware o usb/94717usb[ulpt] Reading from /dev/ulpt can break work of a UHCI o usb/94813usb[umass] mounting write-protected umass device freezes o usb/94897usb[panic] Kernel Panic when cleanly unmounting USB disk o usb/95131usb[install] Boot/setup process does not accept key strok o usb/95348usb[kbd] USB keyboard
Re: usb/107642: [patch] add Ralink Technology RT2501USB/RT2601USB chipset driver from OpenBSD
Mark Linimon wrote: Synopsis: [patch] add Ralink Technology RT2501USB/RT2601USB chipset driver from OpenBSD Responsible-Changed-From-To: freebsd-usb-kevlo Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 6 08:30:46 UTC 2007 Responsible-Changed-Why: kevlo: is this an MFC candidate? If not, I will go ahead and close this PR. Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=107642 No. Please close this PR, thanks. Kevin ___ 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 Sunday 08 July 2007 02:25, Xiaofan Chen wrote:
On 7/5/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
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.
The following is part of the usb firmware from Micrcohip.
Somehow it masks EP0 in the handler to SET CLEAR FEATURES
requesrs. Is this the problem?
if((SetupPkt.bFeature == ENDPOINT_HALT)
(SetupPkt.Recipient == RCPT_EP)
(SetupPkt.EPNum != 0))
/**
* Function:void USBStdFeatureReqHandler(void)
*
* PreCondition:None
*
* Input: None
*
* Output: None
*
* Side Effects:None
*
* Overview:This routine handles the standard SET CLEAR FEATURES
* requests
*
* Note:None
***
**/ void USBStdFeatureReqHandler(void)
{
if((SetupPkt.bFeature == DEVICE_REMOTE_WAKEUP)
(SetupPkt.Recipient == RCPT_DEV))
{
ctrl_trf_session_owner = MUID_USB9;
if(SetupPkt.bRequest == SET_FEATURE)
usb_stat.RemoteWakeup = 1;
else
usb_stat.RemoteWakeup = 0;
}//end if
if((SetupPkt.bFeature == ENDPOINT_HALT)
(SetupPkt.Recipient == RCPT_EP)
(SetupPkt.EPNum != 0))
{
ctrl_trf_session_owner = MUID_USB9;
/* Must do address calculation here */
pDst.bRam = (byte*)ep0Bo+(SetupPkt.EPNum*8)+(SetupPkt.EPDir*4);
if(SetupPkt.bRequest == SET_FEATURE)
*pDst.bRam = _USIE|_BSTALL;
else
{
if(SetupPkt.EPDir == 1) // IN
*pDst.bRam = _UCPU;
else
*pDst.bRam = _USIE|_DAT0|_DTSEN;
}//end if
}//end if
}//end USBStdFeatureReqHandler
Perhaps what happens is that the *pDst.bRam = _UCPU; command clears the FIFO
contents of the USB interrupt endpoint in addition to clearing the stall!?
If the sequence is like this:
Write to interrupt endpoint.
Reply command is written to FIFO.
Clear interrupt endpoint stall.
There is no data to read, because the FIFO has been emptied as a part of the
stall command.
Xiaofan Chen: Could you check the datasheet for the chip that is used, what
the stall command actually does?
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with libusb on FreeBSD?
Hi, I'm trying to use GPSBabel on FreeBSD 6.2-STABLE with a Garmin Edge 305 hooked to the USB port and it looks like usb_bulk_write does not work properly. This is what I get when I try to get waypoints with GPSBabel: gpsbabel -D9 -i garmin -f usb: -o gpx -F blah.gpx GPSBabel Version: 1.3.3 Bad cmdsend r -5 sz 12 usb_bulk_write failed. 'error writing to bulk endpoint /dev/ugen1.2: Input/output error' gpsbabel in free(): error: junk pointer, too high to make sense Abort (core dumped) I have looked through the GPSBabel code and it looks like it is failing at the very first call of usb_bulk_write() when the initialization packet is sent to the device. Is this a known bug with libusb on FreeBSD 6.2? Thanks! Pierre-Luc Drouin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New USB stack and Zero copy.
On Saturday 07 July 2007 12:14:24 pm Hans Petter Selasky wrote: On Friday 06 July 2007 22:41, John Baldwin wrote: On Friday 06 July 2007 02:59:39 am Hans Petter Selasky wrote: On Friday 06 July 2007 01:35, John Baldwin wrote: On Thursday 05 July 2007 04:25:17 pm John Baldwin wrote: On Thursday 05 July 2007 03:31:59 am Hans Petter Selasky wrote: On Wednesday 04 July 2007 19:35, John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Wed, Jul 04, 2007 at Huh? The bounce pages are preallocated, so bus_dmamap_load() isn't going to be allocating things. When are they allocated ? UTSL. bus_dma_tag_create() (if you pass BUS_DMA_ALLOCNOW) or bus_dmamap_create() for the first map belonging to a tag. -- John Baldwin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with libusb on FreeBSD?
On Mon, Jul 09, 2007 at 01:33:48PM -0400, Pierre-Luc Drouin wrote: I have looked through the GPSBabel code and it looks like it is failing at the very first call of usb_bulk_write() when the initialization packet is sent to the device. Is this a known bug with libusb on FreeBSD 6.2? Just a quick suggestion - do you have rw access to the ugen(4) device node(s)? This is often overlooked, it seems. FWIW, I am using usb_bulk_write() in quite a few local projects without any problems. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpMlSy56nKWr.pgp Description: PGP signature
Re: Problem with libusb on FreeBSD?
Yep, I have tried to run GPSBabel both as a normal user and as root. Henrik Brix Andersen wrote: On Mon, Jul 09, 2007 at 01:33:48PM -0400, Pierre-Luc Drouin wrote: I have looked through the GPSBabel code and it looks like it is failing at the very first call of usb_bulk_write() when the initialization packet is sent to the device. Is this a known bug with libusb on FreeBSD 6.2? Just a quick suggestion - do you have rw access to the ugen(4) device node(s)? This is often overlooked, it seems. FWIW, I am using usb_bulk_write() in quite a few local projects without any problems. Regards, Brix ___ 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 7/9/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: Perhaps what happens is that the *pDst.bRam = _UCPU; command clears the FIFO contents of the USB interrupt endpoint in addition to clearing the stall!? If the sequence is like this: Write to interrupt endpoint. Reply command is written to FIFO. Clear interrupt endpoint stall. There is no data to read, because the FIFO has been emptied as a part of the stall command. Xiaofan Chen: Could you check the datasheet for the chip that is used, what the stall command actually does? I need to look further but what you mentioned seem to make sense. *pDst.bRam = _UCPU seems to clear the buffer. The following are the definitions for for the Buffer Descriptor Status Register. /* Buffer Descriptor Status Register Initialization Parameters */ #define _BSTALL 0x04//Buffer Stall enable #define _DTSEN 0x08//Data Toggle Synch enable #define _INCDIS 0x10//Address increment disable #define _KEN0x20//SIE keeps buff descriptors enable #define _DAT0 0x00//DATA0 packet expected next #define _DAT1 0x40//DATA1 packet expected next #define _DTSMASK0x40//DTS Mask #define _USIE 0x80//SIE owns buffer #define _UCPU 0x00//CPU owns buffer FYI: Datasheet of PIC18F2550 USB MCU: http://ww1.microchip.com/downloads/en/DeviceDoc/39632D.pdf bit 7 UOWN: USB Own bit(1) 0 = The microcontroller core owns the BD and its corresponding buffer 1 = SIE owns the BD and its corresponding buffer Note: This bit must be initialized by the user to the desired value prior to enabling the USB module. bit 6 DTS: Data Toggle Synchronization bit(2) 1 = Data 1 packet 0 = Data 0 packet Note: This bit is ignored unless DTSEN = 1 bit 5 KEN: BD Keep Enable bit 1 = USB will keep the BD indefinitely once UOWN is set (required for SPP endpoint configuration) 0 = USB will hand back the BD once a token has been processed bit 4 INCDIS: Address Increment Disable bit 1 = Address increment disabled (required for SPP endpoint configuration) 0 = Address increment enabled bit 3 DTSEN: Data Toggle Synchronization Enable bit 1 = Data toggle synchronization is enabled; data packets with incorrect Sync value will be ignored except for a SETUP transaction, which is accepted even if the data toggle bits do not match 0 = No data toggle synchronization is performed bit 2 BSTALL: Buffer Stall Enable bit 1 = Buffer stall enabled; STALL handshake issued if a token is received that would use the BD in the given location (UOWN bit remains set, BD value is unchanged) 0 = Buffer stall disabled bit 1-0 BC9:BC8: Byte Count 9 and 8 bits The byte count bits represent the number of bytes that will be transmitted for an IN token or received during an OUT token. Together with BC7:0, the valid byte counts are 0-1023. What Warner mentioned before might also be correct. On 7/8/07, M. Warner Losh [EMAIL PROTECTED] wrote: : I never learned the details, but a client of mine was able to get : fixes from Microchip for their product. The exact problem was that : endpoint stall clearing didn't work for these devices and it was a : firmware bug. I need to look it up, but I believe that a clear endpoint stall also resets the toggle, and that was the bug that was tracked down. FYI: the Firmware source code for PICkit 2, an HID device is here. http://ww1.microchip.com/downloads/en/DeviceDoc/FirmwareV2.10.00.zip I am still in the process of understanding the firmware so I may misunderstand something. But I will try to dig further. Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with libusb on FreeBSD?
On 7/9/07, Pierre-Luc Drouin [EMAIL PROTECTED] wrote: I have looked through the GPSBabel code and it looks like it is failing at the very first call of usb_bulk_write() when the initialization packet is sent to the device. Is this a known bug with libusb on FreeBSD 6.2? Maybe you can try the new USB stack by Hans. I've problems to get PICkit 2 working under the original USB stack with libusb. With Hans's new USB stack, it is working on FreeBSD 6.2. Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with libusb on FreeBSD?
I have tried the new stack and I still get the same error... Thanks P-L Xiaofan Chen wrote: On 7/9/07, Pierre-Luc Drouin [EMAIL PROTECTED] wrote: I have looked through the GPSBabel code and it looks like it is failing at the very first call of usb_bulk_write() when the initialization packet is sent to the device. Is this a known bug with libusb on FreeBSD 6.2? Maybe you can try the new USB stack by Hans. I've problems to get PICkit 2 working under the original USB stack with libusb. With Hans's new USB stack, it is working on FreeBSD 6.2. Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
