[linux-usb-devel] Latest software that can BLAST your emails!!
Dear Friend, Each day people ask me how they can advertise their sites or affiliate web sites without investing large sums of money. I recommend my latest tool called Blog Blaster to them - its only a very small investment - but delivers instant results and puts your ad out - spam free - to more than 2 million web sites. http://shrinkster.com/nut This software is not complicated - it's as easy as 1,2 - 3 I'm not pulling your leg! Discover the new way of advertising on the Internet! This Tool is one of the hottest - if not the hottest - marketing tools available! So check out this site now: http://snipurl.com/1h699 Thank you, Lilian Brewer If you are not interested of this opportunity then just send your reply to this email [EMAIL PROTECTED] with the subjectremove me.. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Please reactivate your Yahoo! Groups email address
Dear Yahoo! Groups member, You belong to one or more email groups provided by Yahoo! Groups (groups.yahoo.com). Recently, messages sent to you from Yahoo! Groups have been returned to us as undeliverable. As a result, we have temporarily turned off message delivery to this email address. If you are reading this message, the delivery problem appears to be fixed. To start receiving your groups messages by email again and turn your account back on, please visit: http://groups.yahoo.com/unbounce?adj=232689933,37943p=1182160537 (You can also copy and paste this link into your browser, and hit the 'Return' key.) Once you reactivate your Yahoo! Groups account by clicking the link above, you will receive messages from your group(s) again. Tip: You can read messages you might have missed while delivery was turned off by visiting your groups here: http://groups.yahoo.com/mygroups Thank you for using Yahoo! Groups! Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] handling ENOMEM in usb sg handling
Hi,
I am looking at usb_sg_init().
void usb_sg_wait (struct usb_sg_request *io)
{
int i, entries = io-entries;
/* queue the urbs. */
spin_lock_irq (io-lock);
for (i = 0; i entries !io-status; i++) {
int retval;
io-urbs [i]-dev = io-dev;
retval = usb_submit_urb (io-urbs [i], GFP_ATOMIC);
/* after we submit, let completions or cancelations fire;
* we handshake using io-status.
*/
spin_unlock_irq (io-lock);
switch (retval) {
/* maybe we retrying will recover */
case -ENXIO:// hc didn't queue this one
case -EAGAIN:
case -ENOMEM:
io-urbs[i]-dev = NULL;
retval = 0;
i--;
yield ();
break;
In essence this leaves handling a persistent failure to the generic
scsi layer, which will timeout and abort the request. Is there any objection
to report the URB where it failed to the immediate user and let him
retry the remainder or handle the error any other way?
I dimly remember discussing this routine in the past.
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [usb-storage] handling ENOMEM in usb sg handling
Maybe we can retry at this situation.
On 6/18/07, Oliver Neukum [EMAIL PROTECTED] wrote:
Hi,
I am looking at usb_sg_init().
void usb_sg_wait (struct usb_sg_request *io)
{
int i, entries = io-entries;
/* queue the urbs. */
spin_lock_irq (io-lock);
for (i = 0; i entries !io-status; i++) {
int retval;
io-urbs [i]-dev = io-dev;
retval = usb_submit_urb (io-urbs [i], GFP_ATOMIC);
/* after we submit, let completions or cancelations fire;
* we handshake using io-status.
*/
spin_unlock_irq (io-lock);
switch (retval) {
/* maybe we retrying will recover */
case -ENXIO:// hc didn't queue this one
case -EAGAIN:
case -ENOMEM:
io-urbs[i]-dev = NULL;
retval = 0;
i--;
yield ();
break;
In essence this leaves handling a persistent failure to the generic
scsi layer, which will timeout and abort the request. Is there any objection
to report the URB where it failed to the immediate user and let him
retry the remainder or handle the error any other way?
I dimly remember discussing this routine in the past.
Regards
Oliver
___
Usb-storage mailing list
[EMAIL PROTECTED]
https://lists.one-eyed-alien.net/mailman/listinfo/usb-storage
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Zonet ZUN2210
Jon Smirl wrote: Has anyone tried the Zonet ZUN2210 USB to Ethernet adapter? What chipset is it using? http://www.zonetusa.com/DispProduct.asp?ProductID=81 Googling doesn't give a conclusive answer if it works with Linux. Based on the vendor/product info in the windows driver .inf file, I'd say it uses a moschip 7830 and the mcs7830 driver. --Jamie - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Zonet ZUN2210
On 6/18/07, James Painter [EMAIL PROTECTED] wrote: Jon Smirl wrote: Has anyone tried the Zonet ZUN2210 USB to Ethernet adapter? What chipset is it using? http://www.zonetusa.com/DispProduct.asp?ProductID=81 Googling doesn't give a conclusive answer if it works with Linux. Based on the vendor/product info in the windows driver .inf file, I'd say it uses a moschip 7830 and the mcs7830 driver. I ordered one, I'll let people know if it works. I found reports of people saying that it didn't work but that was probably before the mcs7830 driver was added to the kernel. Just for fun I ordered one of these generic ones: http://store.shentech.com/hiusb2010usb.html $5.88 No clue what chip it is using. I'm looking for a low cost way to optionally add an Ethernet port to an embedded design with USB2.0. -- Jon Smirl [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Possible bug in isp116x-hcd
On Thu, 14 Jun 2007, Olav Kongas wrote: Hi Alan, Index: usb-2.6/drivers/usb/host/isp116x-hcd.c === --- usb-2.6.orig/drivers/usb/host/isp116x-hcd.c +++ usb-2.6/drivers/usb/host/isp116x-hcd.c @@ -583,12 +583,15 @@ static void finish_atl_transfers(struct unpack_fifo(isp116x); postproc_atl_queue(isp116x); I think it is guaranteed that at this point all the ep's in active ATL queue have their urb_list non-empty. There's a relevant BUG_ON() in postproc_atl_queue(). The list_empty() check below would be unnecessary. Olav, What would be involved in refactoring isp116x-hcd so that the driver called usb_hcd_giveback_urb() as soon as the URB was completed? If I understand the current code correctly, postproc_atl_queue() goes through all the active endpoints and stores the status for the completed URBs, and then later finish_atl_transfers() gives them back. It looks like this shouldn't present any difficulty except for one thing: When you get a short Control-IN transfer with URB_SHORT_NOT_OK set, the error status gets stored while the URB's status stage executes. That would have to be changed so that the status stage was skipped entirely. Doing this shouldn't cause any problems in practice; the other HCDs skip the status stage when this sort of error occurs. The point of making this change is that it would allow the driver to avoid saving values in urb-status, leading eventually to the possibility of removing the status field from struct urb. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] handling ENOMEM in usb sg handling
On Mon, 18 Jun 2007, Oliver Neukum wrote: Hi, I am looking at usb_sg_init(). In essence this leaves handling a persistent failure to the generic scsi layer, which will timeout and abort the request. Is there any objection to report the URB where it failed to the immediate user and let him retry the remainder or handle the error any other way? I dimly remember discussing this routine in the past. You could make usb_sg_wait just wait until the part already submitted was finished, then go back and retry the remainder. I think that would be simpler. If for any reason you can't transmit the entire buffer, then the entire transfer needs to be aborted by the SCSI error handler anyway. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] handling ENOMEM in usb sg handling
On Monday 18 June 2007, Alan Stern wrote: On Mon, 18 Jun 2007, Oliver Neukum wrote: Hi, I am looking at usb_sg_init(). In essence this leaves handling a persistent failure to the generic scsi layer, which will timeout and abort the request. Is there any objection to report the URB where it failed to the immediate user and let him retry the remainder or handle the error any other way? I dimly remember discussing this routine in the past. You could make usb_sg_wait just wait until the part already submitted was finished, then go back and retry the remainder. I think that would be simpler. Which resembles what that code excerpt is *supposed* to be doing. Although yield() is now known to behave rudely, so msleep(1) would be better. (Previously noted in the last week or so...) It doesn't actually need to wait for anything more than enough memory becoming available. Which you can tell by succeeding on the next pass through the submit loop. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] handling ENOMEM in usb sg handling
Am Montag, 18. Juni 2007 schrieb Alan Stern: On Mon, 18 Jun 2007, Oliver Neukum wrote: Hi, I am looking at usb_sg_init(). In essence this leaves handling a persistent failure to the generic scsi layer, which will timeout and abort the request. Is there any objection to report the URB where it failed to the immediate user and let him retry the remainder or handle the error any other way? I dimly remember discussing this routine in the past. You could make usb_sg_wait just wait until the part already submitted was finished, then go back and retry the remainder. I think that would be simpler. It does retry continously, so it'll retry when the earlier URBs are completed. Maybe you are right and at some place we must trust the mm to keep a sufficient reserve. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] handling ENOMEM in usb sg handling
Am Montag, 18. Juni 2007 schrieb David Brownell: On Monday 18 June 2007, Alan Stern wrote: On Mon, 18 Jun 2007, Oliver Neukum wrote: Hi, I am looking at usb_sg_init(). In essence this leaves handling a persistent failure to the generic scsi layer, which will timeout and abort the request. Is there any objection to report the URB where it failed to the immediate user and let him retry the remainder or handle the error any other way? I dimly remember discussing this routine in the past. You could make usb_sg_wait just wait until the part already submitted was finished, then go back and retry the remainder. I think that would be simpler. Which resembles what that code excerpt is *supposed* to be doing. Although yield() is now known to behave rudely, so msleep(1) would be better. (Previously noted in the last week or so...) I'll do that. It doesn't actually need to wait for anything more than enough memory becoming available. Which you can tell by succeeding on the next pass through the submit loop. OK, it seems to me that I looked at the problem from the wrong angle. Indeed this code will eventually succeed if enough memory is available to submit the worst fragment. However, we allocate all URBs before we submit any of them. This seems to be almost designed to suck up all reserves without achieving progress. I think there needs to be a fallback if the sg stuff cannot get all the URBs it wants. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] medical data for your review
I was told that you were looking for marketing databases of the medical community. Until the end of next week (June 22/2007) we have this deal on the go: Directories for the USA: - Physicians: 700 thousand doctors in the US. Data is provided in Excel format and sortable by state or specialty. Over a dozen different fields and more than 30 specialties. Individual Cost: $359 - Hospital Admins: 23 thousand in all with data for the CEO, CFO, CIO, COO and more Individual Cost: $229 - Dentists and Related Dental Services: 597 thousand records in all Individual Cost: $219 If you buy the directory of physicians you will get the other 2 for free. Contact us at (206) 600-5313 or send an email to [EMAIL PROTECTED] Reply with 'exit' in the subject if you choose not to remain in our records - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
