Re: Patch that fixes usb4bsd stack build on the recent -CURRENT
Hi Eygene !
Thanks for the patch.
It should be committed now to my SVN repo.
--HPS
On Tuesday 03 July 2007 14:00, Eygene Ryabinkin wrote:
Hans, good day.
Tried to build the usb4bsd stack on the recent (yesterday's -CURRENT)
and it failed due to the cam subsystem API changes introduced in
xpt_bus_register: now it takes three values.
The following patch cures the situation:
-
Index: trunk/i4b/src/sys/dev/usb/umass.c
===
--- trunk/i4b/src/sys/dev/usb/umass.c (revision 529)
+++ trunk/i4b/src/sys/dev/usb/umass.c (working copy)
@@ -2305,7 +2305,11 @@
mtx_lock((sc-sc_mtx));
#endif
+#if (__FreeBSD_version = 700048)
+ if(xpt_bus_register(sc-sc_sim, sc-sc_dev, sc-sc_unit) != CAM_SUCCESS)
{ +#else
if(xpt_bus_register(sc-sc_sim, sc-sc_unit) != CAM_SUCCESS) {
+#endif
#if (__FreeBSD_version = 700037)
mtx_unlock((sc-sc_mtx));
#endif
-
It was tested on my system: I am writing from the USB keyboard
and my USB flash is burned by the dd. My naughty 2Gb Transcend
flash, as usual, buries the system completely. So all is going
as expected ;))
The original umass.c from the fresh -CURRENT uses 'NULL' instead
of 'sc-sc_dev'. The commit comment for the cam_xpt.c tells us
-
Prepare for future integration between CAM and newbus. xpt_bus_register
now takes a device_t to be the parent of the bus that is being created.
Most SIMs have been updated with a reasonable argument, but a few
exceptions just pass NULL for now. This argument isn't used yet and the
newbus integration likely won't be ready until after 7.0-RELEASE.
-
I don't know why umass.c is using NULL, but I had tried both ways
and there is no difference for my hardware.
I had chosen the check for the __FreeBSD_version of 700048, because
the cam changes were done at 2007/06/17 05:55:53:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c?rev=1.189;conte
nt-type=text%2Fplain and the latest changes in the param.h occured at
2007/06/12 16:24:54
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/param.h?rev=1.303;content
-type=text%2Fplain Users that updated the -CURRENT after June 12th, but
before June 17th will suffer from the uncompilable stack, but I hope that
this timeframe is small and -CURRENT users are periodically upgrading the
sources.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
New USB stack and Zero copy.
Hi, I want to get rid of the copying between DMA'able memory and non-DMA'able memory. Currently I allocate N memory-pages for each USB transfer like separate pages. The bus-dma system then assigns all of these pages each their virtual address. What I see is that when I allocate more than PAGE_SIZE bytes using bus-dma, I get physically contiguous memory. I don't need that for the USB stack. The question is: Should we change bus-dma to support so called scatter and gather allocations, where the physical allocation is non-contiguous, and the virtual allocation is contiguous accross all the scattered pages ? Also: How is the easiest way to load memory pages into DMA ? And I want that the loadig works like this, that when the page must be bounced it should not allocate a bounce buffer, hence I already have a bounce buffer. I only need to know which pages I can forward directly to the USB hardware, and the rest I will bounce somewhere else. --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 4/4/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
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.
Sorry to dig out this again. I read a bit more on the firmware source code
and I found the following. Seems a bit dubious. The USB controller used
is Microchip 18F2550.
Any comments? Thanks in advance.
/**
* Function:void USBStallHandler(void)
*
* PreCondition:A STALL packet is sent to the host by the SIE.
*
* Input: None
*
* Output: None
*
* Side Effects:None
*
* Overview:The STALLIF is set anytime the SIE sends out a STALL
* packet regardless of which endpoint causes it.
* A Setup transaction overrides the STALL function. A stalled
* endpoint stops stalling once it receives a setup packet.
* In this case, the SIE will accepts the Setup packet and
* set the TRNIF flag to notify the firmware. STALL function
* for that particular endpoint pipe will be automatically
* disabled (direction specific).
*
* There are a few reasons for an endpoint to be stalled.
* 1. When a non-supported USB request is received.
* Example: GET_DESCRIPTOR(DEVICE_QUALIFIER)
* 2. When an endpoint is currently halted.
* 3. When the device class specifies that an endpoint must
* stall in response to a specific event.
* Example: Mass Storage Device Class
* If the CBW is not valid, the device shall
* STALL the Bulk-In pipe.
* See USB Mass Storage Class Bulk-only Transport
* Specification for more details.
*
* Note:UEPn.EPSTALL can be scanned to see which endpoint causes
* the stall event.
* If
*/
void USBStallHandler(void)
{
/*
* Does not really have to do anything here,
* even for the control endpoint.
* All BDs of Endpoint 0 are owned by SIE right now,
* but once a Setup Transaction is received, the ownership
* for EP0_OUT will be returned to CPU.
* When the Setup Transaction is serviced, the ownership
* for EP0_IN will then be forced back to CPU by firmware.
*
* NOTE: Above description is not quite true at this point.
* It seems the SIE never returns the UOWN bit to CPU,
* and a TRNIF is never generated upon successful
* reception of a SETUP transaction.
* Firmware work-around is implemented below.
*/
if(UEP0bits.EPSTALL == 1)
{
USBPrepareForNextSetupTrf();// Firmware Work-Around
UEP0bits.EPSTALL = 0;
}
UIRbits.STALLIF = 0;
}//end USBStallHandler
/**
* Function:void USBPrepareForNextSetupTrf(void)
*
* PreCondition:None
*
* Input: None
*
* Output: None
*
* Side Effects:None
*
* Overview:The routine forces EP0 OUT to be ready for a new Setup
* transaction, and forces EP0 IN to be owned by CPU.
*
* Note:None
*/
void USBPrepareForNextSetupTrf(void)
{
ctrl_trf_state = WAIT_SETUP;// See usbctrltrf.h
ep0Bo.Cnt = EP0_BUFF_SIZE; // Defined in usbcfg.h
ep0Bo.ADR = (byte*)SetupPkt;
ep0Bo.Stat._byte = _USIE|_DAT0|_DTSEN; // EP0 buff dsc init, see usbmmap.h
ep0Bi.Stat._byte = _UCPU; // EP0 IN buffer initialization
}//end USBPrepareForNextSetupTrf
/** EOF usbctrltrf.c */
___
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.
Hans Petter Selasky wrote this message on Wed, Jul 04, 2007 at 09:01 +0200: I want to get rid of the copying between DMA'able memory and non-DMA'able memory. Currently I allocate N memory-pages for each USB transfer like separate pages. How do you allocate these pages? With malloc(9) or w/ bus_dmamem_alloc(9)? The bus-dma system then assigns all of these pages each their virtual address. What I see is that when I allocate more than PAGE_SIZE bytes using bus-dma, I get physically contiguous memory. I don't need that for the USB stack. That is a limitation of how bus_dma currently allocates memory... It calls contigmalloc, which doesn't handle multi-segment memory allocations yet.. The question is: Should we change bus-dma to support so called scatter and gather allocations, where the physical allocation is non-contiguous, and the virtual allocation is contiguous accross all the scattered pages ? You can already support this by using malloc, and loading that buffer into your bus_dma map... or using the passing in userland buffer, and loading that into the map... Also: How is the easiest way to load memory pages into DMA ? And I want that the loadig works like this, that when the page must be bounced it should not allocate a bounce buffer, hence I already have a bounce buffer. I only need to know which pages I can forward directly to the USB hardware, and the rest I will bounce somewhere else. Why do you not want to let bus_dma do the bouncing for you? If it's to save a copy to another buffer, why don't you load the final buffer into bus_dma? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
usb/114310: USB hub attachment panics kernel during libusb device scan
Number: 114310
Category: usb
Synopsis: USB hub attachment panics kernel during libusb device scan
Confidential: no
Severity: critical
Priority: medium
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Thu Jul 05 03:00:09 GMT 2007
Closed-Date:
Last-Modified:
Originator: Victor Liu
Release:5.4-RELEASE
Organization:
Fastsoft
Environment:
FreeBSD x 5.4-RELEASE FreeBSD 5.4-RELEASE #44: Mon Jul
2 18:25:07 PDT 2007 [EMAIL
PROTECTED]:/usr/src/sys/i386/compile/x i386
Description:
When attaching a USB hub (anything from a generic DLink to a keyboard with
integrated hub) while a userspace libusb query is going on, the kernel panics
(trap 12, fault virtual address = 0xdeadc0e6) at usbd_device_fillinfo:1350;
p-device is 0xdeadc0de.
I have experimented several times, I think the cause is during hub attachment,
there is a tsleep when waiting for power to settle (uhub.c:288). In this time,
libusb's usb_find_devices happens to request an ioctl for a device exploration.
At this point, the port structures of the hub are not yet initialized.
I have a temporary fix that just initializes p-device to NULL before the
sleep, but this doesn't solve a similar problem exists during hub detachment
(which I haven't been able to narrow it down much further).
How-To-Repeat:
Run a program that continuously polls for USB devices using libusb's
usb_find_devices(), while attaching a USB hub. This won't cause it to crash
everytime, but it is likely that out of 20 attachments, there will be at least
one panic.
A piece of code along the lines of
while(1){
DPRINTF((before usb_init\n));
usb_init();
DPRINTF((before usb_find_busses\n));
usb_find_busses();
DPRINTF((before usb_find_devices\n));
usb_find_devices();
}
should do the trick of producing something like the log.
Fix:
Proposed patch (only a hackish fix for the attachment problem):
@@ -284,6 +284,15 @@
goto bad;
}
+ // Fixes crash on hub attachment
+ // Need to init device to NULL before delay sleep;
+ // otherwise exploration could hit an uninit'd port
+ for (p = 0; p nports; p++) {
+ struct usbd_port *up = hub-ports[p];
+ up-device = NULL;
+ }
+ // end changes
+
/* Wait with power off for a while. */
usbd_delay_ms(dev, USB_POWER_DOWN_TIME);
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/114310: USB hub attachment panics kernel during libusb device scan
The following reply was made to PR usb/114310; it has been noted by GNATS. From: M. Warner Losh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: usb/114310: USB hub attachment panics kernel during libusb device scan Date: Wed, 04 Jul 2007 22:03:35 -0600 (MDT) Would you happen to know if this happens on FreeBSD -current? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/99419: commit references a PR
The following reply was made to PR usb/99419; it has been noted by GNATS. From: [EMAIL PROTECTED] (dfilter service) To: [EMAIL PROTECTED] Cc: Subject: Re: usb/99419: commit references a PR Date: Thu, 5 Jul 2007 04:06:05 + (UTC) imp 2007-07-05 04:05:52 UTC FreeBSD src repository Modified files: sys/dev/usb umass.c usbdevs Log: Add support for Western Digital MyBook external enclosures. They need this quirk to work. Submitted by: Dierk Sacher PR: usb/99419 Approved by: re (blanket) Revision ChangesPath 1.159 +4 -0 src/sys/dev/usb/umass.c 1.317 +6 -0 src/sys/dev/usb/usbdevs ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/79893: [umass] [patch] new usbdevs/umass quirks derived from Linux
Synopsis: [umass] [patch] new usbdevs/umass quirks derived from Linux State-Changed-From-To: open-patched State-Changed-By: imp State-Changed-When: Wed Jul 4 23:26:30 MDT 2007 State-Changed-Why: committed http://www.freebsd.org/cgi/query-pr.cgi?pr=79893 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
