Re: [linux-usb-devel] question on interaction with driver core
New requests are effectively blocked for usb-storage, if nothing else. Our queue depth is 1 command. Matt On Thu, Mar 20, 2003 at 01:07:23AM +0100, Oliver Neukum wrote: > Am Donnerstag, 20. März 2003 01:04 schrieb Matthew Dharm: > > I'm not certain this is a problem... > > > > I know blocking is legal in the SCSI error-handling context. Other I/O > > will continue during this time. > > Blocking as such is OK. Blocking on IO that is waiting for your own device > to process IO requests is not OK. The SCSI layer guarantees that a driver > gets no more requests while the error handler is running, doesn't it? > > Regards > Oliver -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Would you mind not using our Web server? We're trying to have a game of Quake here. -- Greg User Friendly, 5/11/1998 pgp0.pgp Description: PGP signature
Re: [linux-usb-devel] Re: 2.4.21-pre5 kernel Oops, USB related (and some other problems)
I have also seen this oops. I will try to reproduce it. Duncan. --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: 2.4.21-pre5 kernel Oops, USB related (and some other problems)
Am Mittwoch, 19. März 2003 23:29 schrieb [EMAIL PROTECTED]: > Hi, > > First, this seems to be a reproducible oops. Second, the kernel oops > messages, ksymoops outputs and some other stuff I thought might be of > use, can be found at > > http://stekt.oulu.fi/~flexy/Oops.tar > > Then, about my hardware, > > Epox M762A SMP board with AMD-760MPX chipset > 2*MP1600+, NOT overclocked > 512MB Crucial ECC memory, Correct+Scrub set [EMAIL PROTECTED] > Intel PRO/1000MT 1Gb NIC > Intel build in 100Mb NIC > S3 PCI display adapter > Adaptec ATA RAID 2400A, with 4 disks at raid5 > HP PSC750 (USB) > > In the Oops.tar, there is two directories, 1 and 2. In directory 1, > there is a Oops with this hardware and in 2, there is Oops with onboard > USB hub disabled from bios and PCI USB adapter in use. I don't know the > exact type of the adapter, but it came with MSI K7 Master-L motherboard, > allmost the same motherboard as this Epox. And it seems to use the same > driver. What are you doing when the USB related oops occurs? Regards Oliver This information is included also in the Oops.tar at the URL above. I was accessing /proc/bus/usb/devices with cat command. BR, Flexy --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] reduce stack usage in cdc-ether
On Sun, Mar 16, 2003 at 09:19:19PM -0800, Randy.Dunlap wrote: > Hi Brad, > > This patch to 2.5.64 reduces the large stack usage in > log_device_info() [and makes it static to boot]. > > Please apply. I've applied this to my trees, thanks. greg k-h --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Update for usb-skeleton
On Mon, Mar 17, 2003 at 01:35:58PM -0500, Alan Stern wrote: > Greg: > > My update for usb-skeleton seems to have gotten lost in the shuffle, so > here it is again -- all wrapped up in one nice little patch. It's been > tested by three different people and passed with flying colors. Please > apply. Sorry for the delay, I've applied this now. Thanks a lot for updating this driver. greg k-h --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: 2.4.21-pre5 kernel Oops, USB related (and some other problems)
Am Mittwoch, 19. März 2003 23:29 schrieb [EMAIL PROTECTED]: > Hi, > > First, this seems to be a reproducible oops. Second, the kernel oops > messages, ksymoops outputs and some other stuff I thought might be of > use, can be found at > > http://stekt.oulu.fi/~flexy/Oops.tar > > Then, about my hardware, > > Epox M762A SMP board with AMD-760MPX chipset > 2*MP1600+, NOT overclocked > 512MB Crucial ECC memory, Correct+Scrub set [EMAIL PROTECTED] > Intel PRO/1000MT 1Gb NIC > Intel build in 100Mb NIC > S3 PCI display adapter > Adaptec ATA RAID 2400A, with 4 disks at raid5 > HP PSC750 (USB) > > In the Oops.tar, there is two directories, 1 and 2. In directory 1, > there is a Oops with this hardware and in 2, there is Oops with onboard > USB hub disabled from bios and PCI USB adapter in use. I don't know the > exact type of the adapter, but it came with MSI K7 Master-L motherboard, > allmost the same motherboard as this Epox. And it seems to use the same > driver. What are you doing when the USB related oops occurs? Regards Oliver --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] cleanup of synchronous API
Am Mittwoch, 19. März 2003 23:39 schrieb David Brownell: > Oliver Neukum wrote: > > Hi Dave, > > > > does this remove your doubts about race conditions in the synchronous > > API? > > It's a lot closer ... I'll try it. Yes, it's odd that there > was no pre-existing "wait_event_timeout()", and that's the > call we need to make that implementation behave right. I thought about that. I still have no clue as to the reason. > Some further cleanup: abolish "struct usb_api_data", it's > exactly the same as "struct completion". Then likely that > completion callback can just call complete(). And why are > you initializing the waitqueue head twice? Also: if I Do I? Where? Cerebral insufficiency, most likely. It's past midnight here. > were doing it, I'd not use the synchronous unlink call; > "ought not" to matter, but we can be more sure than that. That's dangerous. We must have absolute confidence about whether the message has gone over the wire or not. Suppose it's a reset. We'd have a device at address zero without knowing it. So this seems to be the easiest way. > Curiously enough, I seem to have found a way to reproduce > the previous "raced timeout" message -- which is IMO proof > that my doubts were well deserved. (Specifically the ones > about the implementation being broken; API is another issue.) > > Basically, with the system under heavy USB loads (two EHCI > devices putting 20+ MByte/sec loads, plus the device side > logic of one of those -- net 70+ MByte/sec!) and interrupt > load to match ... system latencies were high enough that I > couldn't enumerate a new device. I got the "raced" message, > then first khubd and then the rest of the USB stack locked > up. There was another wierdness going on too, but clearly > the synchronization replaced by your patch was also broken. This is odd. How was the system load? Doesn't it have to be insanely high for a kernel thread not running for several seconds after being woken up? Or is this an IO scheduling bug? Control messages should have priority over bulk, shouldn't they? Regards Oliver --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] question on interaction with driver core
Am Donnerstag, 20. März 2003 01:04 schrieb Matthew Dharm: > I'm not certain this is a problem... > > I know blocking is legal in the SCSI error-handling context. Other I/O > will continue during this time. Blocking as such is OK. Blocking on IO that is waiting for your own device to process IO requests is not OK. The SCSI layer guarantees that a driver gets no more requests while the error handler is running, doesn't it? Regards Oliver --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] question on interaction with driver core
I'm not certain this is a problem...
I know blocking is legal in the SCSI error-handling context. Other I/O
will continue during this time.
I have to think about this some more
Matt
On Thu, Mar 20, 2003 at 12:48:02AM +0100, Oliver Neukum wrote:
> Am Mittwoch, 19. März 2003 23:46 schrieb Greg KH:
> > On Fri, Mar 14, 2003 at 07:56:27AM -0800, David Brownell wrote:
> > > Oliver Neukum wrote:
> > > >am I right in assuming that any disconnects/probes _must_ be done
> > > > through driver core? Or is calling usb_device_remove() directly still
> > > > legal?
> > >
> > > I'm not even sure why usb_device_{probe,remove}() are even exported.
> >
> > Someone needs to fix up the usb-storage driver for these functions to be
> > made private.
>
> I just thought about this. It's much less trivial than I thought.
> The patch I made for cleaning up reset is crap.
> We cannot ignore it either. Today I saw a mouse with memory stick
> reader. If this is HID+storage, multiinterface devices are no longer
> theory.
>
> The problem is somewhat involved and I might even be wrong.
> Upon device reset the interfaces whose drivers do not make a reset
> must be notified that they cannot use the device while we reset it.
> Currently this is done via disconnect()ing all interfaces.
> This is potentially lethal. This is done as part of the block io error
> handling path. This means that all memory allocations must be made
> GFP_NOIO or GFP_ATOMIC. Now please correct me if I am wrong,
> but the hotplugging subsystem does exactly that, doesn't it?
>
> Regards
> Oliver
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
I see you've been reading alt.sex.chubby.sheep voraciously.
-- Tanya
User Friendly, 11/24/97
pgp0.pgp
Description: PGP signature
Re: [linux-usb-devel] question on interaction with driver core
On Fri, Mar 14, 2003 at 07:56:27AM -0800, David Brownell wrote:
> Oliver Neukum wrote:
> >
> >am I right in assuming that any disconnects/probes _must_ be done through
> >driver core? Or is calling usb_device_remove() directly still legal?
>
> I'm not even sure why usb_device_{probe,remove}() are even exported.
Someone needs to fix up the usb-storage driver for these functions to be
made private.
Please... :)
thanks,
greg k-h
---
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Memory leak in auerswald driver
On Sun, Mar 16, 2003 at 01:02:23PM +0100, Wolfgang Mües wrote: > Hello Greg, > > Oleg Drokin <[EMAIL PROTECTED]> has reported a memory leak in auerbuf.c, > which is only exposed under low memory conditions. > > The appended patch fixes this leak. It is for 2.4.21. > Please apply. Applied, thanks. But next time, such a small patch didn't have to be tarred and compressed :) thanks, greg k-h --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.5.65 regression with SA-1111 OHCI: USB devicenot accepting new address
Christopher Hoover wrote: I'm seeng regression with OHCI under 2.5.65: my device, a Blue Gear B091H1 Bluetooth dongle, fails to accept its address under 2.5.65. If I reboot under 2.5.59, it works OK although I do get an initial "USB device not accepting new address". Additional details: I cannot get any of several devices I've tried to accept an address, so the problem is not specific to the BT dongle. Odd. It didn't change since 2.5.64, and that was working fine for me -- on PCI that is. So my first guess would be something related to sa platform changes. - Dave --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] cleanup of synchronous API
Oliver Neukum wrote: Hi Dave, does this remove your doubts about race conditions in the synchronous API? It's a lot closer ... I'll try it. Yes, it's odd that there was no pre-existing "wait_event_timeout()", and that's the call we need to make that implementation behave right. Some further cleanup: abolish "struct usb_api_data", it's exactly the same as "struct completion". Then likely that completion callback can just call complete(). And why are you initializing the waitqueue head twice? Also: if I were doing it, I'd not use the synchronous unlink call; "ought not" to matter, but we can be more sure than that. Curiously enough, I seem to have found a way to reproduce the previous "raced timeout" message -- which is IMO proof that my doubts were well deserved. (Specifically the ones about the implementation being broken; API is another issue.) Basically, with the system under heavy USB loads (two EHCI devices putting 20+ MByte/sec loads, plus the device side logic of one of those -- net 70+ MByte/sec!) and interrupt load to match ... system latencies were high enough that I couldn't enumerate a new device. I got the "raced" message, then first khubd and then the rest of the USB stack locked up. There was another wierdness going on too, but clearly the synchronization replaced by your patch was also broken. - Dave --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] 2.5.65 regression with SA-1111 OHCI: USB device not accepting new address
> > I'm seeng regression with OHCI under 2.5.65: my device, a Blue Gear > B091H1 Bluetooth dongle, fails to accept its address under > 2.5.65. If I reboot under 2.5.59, it works OK although I do > get an initial "USB device not accepting new address". Additional details: I cannot get any of several devices I've tried to accept an address, so the problem is not specific to the BT dongle. -ch --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] cleanup of synchronous API
> From: Oliver Neukum <[EMAIL PROTECTED]> > Date: Wed, 19 Mar 2003 22:13:07 +0100 > > > From: Oliver Neukum <[EMAIL PROTECTED]> > > > Date: Wed, 19 Mar 2003 21:44:10 +0100 > > > > > > +#define __wait_event_timeout(wq, condition, ret) \ > > > + if (condition) \ > > > + break; \ > > > > I find it deeply disturbing to see this sort of trick. > > For one thing, it constrains you to a macro implementation. > > Why don't you take it to linux-kernel? > > I don't understand this remark. Could you elaborate? > What's wrong about adding the fourth macro of this kind to the > macros already present there? I asked on linux-kernel and nobody > so far has answered. Oh well, whatever. Indeed, it's all there already. -- Pete --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.5.65 regression with SA-1111 OHCI: USB device not accepting new address
I upgraded my SA-1110/SA- platform from 2.5.59-rmk1 to 2.5.65-rmk1. I'm seeng regression with OHCI under 2.5.65: my device, a Blue Gear B091H1 Bluetooth dongle, fails to accept its address under 2.5.65. If I reboot under 2.5.59, it works OK although I do get an initial "USB device not accepting new address". Logs follow for both the working 2.5.59 and the not working 2.5.65. Any thoughts before I dig into this further? Ciao, -ch - 2.5.65 -- does not work Linux version 2.5.65-rmk1-ch1 ([EMAIL PROTECTED]) (gcc version 2.95.4 20010319 (prerelease)) #4 Wed Mar 19 12:15:33 PST 2003 CPU: StrongARM-1110 [6901b110] revision 0 (ARMv4) Machine: Hewlett-Packard Laboratories BadgePAD 4 drivers/usb/host/ohci-sa.c: ohci-hcd (SA-) at 0xcc800400, irq 109 Please use the 'usbfs' filetype instead, the 'usbdevfs' name is deprecated. sa-ohci 0400: new USB bus registered, assigned bus number 1 usb usb1: Product: SA- OHCI usb usb1: Manufacturer: Linux 2.5.65-rmk1-ch1 ohci-hcd usb usb1: SerialNumber: sa hub 1-0:0: USB hub found hub 1-0:0: 1 port detected hub 1-0:0: debounce: port 1: delay 100ms stable 4 status 0x101 hub 1-0:0: new USB device on port 1, assigned address 2 usb 1-1: USB device not accepting new address=2 (error=-32) hub 1-0:0: new USB device on port 1, assigned address 3 usb 1-1: USB device not accepting new address=3 (error=-32) - 2.5.59 -- does not work Linux version 2.5.59-rmk1-ch1 ([EMAIL PROTECTED]) (gcc version 2.95.4 20010319 (prerelease)) #1 Thu Mar 6 18:53:43 PST 2003 CPU: StrongARM-1110 [6901b110] revision 0 (ARMv4) Machine: Hewlett-Packard Laboratories BadgePAD 4 ... drivers/usb/host/ohci-sa.c: 2002-Sep-17 USB 1.1 'Open' Host Controller (OHCI) Driver (SA-) drivers/usb/host/ohci-sa.c: block sizes: ed 64 td 64 drivers/usb/host/ohci-sa.c: starting SA- OHCI USB Controller drivers/usb/host/ohci-sa.c: ohci-hcd (SA-) at 0xcc800400, irq 109 Please use the 'usbfs' filetype instead, the 'usbdevfs' name is deprecated. sa-ohci 0400: new USB bus registered, assigned bus number 1 sa-ohci 0400: USB HC reset_hc sa: ctrl = 0x0 ; sa-ohci 0400: root hub device address 1 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 drivers/usb/core/usb.c: usb_hotplug usb usb1: usb_new_device - registering interface 1-0:0 hub 1-0:0: usb_device_probe hub 1-0:0: usb_device_probe - got id hub 1-0:0: USB hub found hub 1-0:0: 1 port detected hub 1-0:0: standalone hub hub 1-0:0: ganged power switching hub 1-0:0: global over-current protection hub 1-0:0: Port indicators are not supported hub 1-0:0: power on to power good time: 4ms hub 1-0:0: hub controller current requirement: 0mA hub 1-0:0: local power source is good hub 1-0:0: no over-current condition exists hub 1-0:0: enabling power on all ports drivers/usb/core/usb.c: usb_hotplug sa-ohci 0400: created debug files sa-ohci 0400: OHCI controller state sa-ohci 0400: OHCI 1.0, with legacy support registers sa-ohci 0400: control: 0x008f HCFS=operational IE PLE CBSR=3 sa-ohci 0400: cmdstatus: 0x SOC=0 sa-ohci 0400: intrstatus: 0x0044 RHSC SF sa-ohci 0400: intrenable: 0x8012 MIE UE WDH sa-ohci 0400: hcca frame #0020 sa-ohci 0400: roothub.a: 02000201 POTPGT=2 NPS NDP=1 sa-ohci 0400: roothub.b: PPCM= DR= sa-ohci 0400: roothub.status: sa-ohci 0400: roothub.portstatus [0] = 0x0100 PPS sa-ohci 0400: GetStatus roothub.portstatus [1] = 0x00010101 CSC PPS CCS hub 1-0:0: port 1, status 101, change 1, 12 Mb/s hub 1-0:0: debounce: port 1: delay 100ms stable 4 status 0x101 sa-ohci 0400: GetStatus roothub.portstatus [1] = 0x00100103 PRSC PPS PES CCS hub 1-0:0: new USB device on port 1, assigned address 2 usb 1-1: urb c3f97d20 usb-sa-1 ep-0-OUT cc 5 --> status -110 usb 1-1: urb c3f97c00 usb-sa-1 ep-0-OUT cc 5 --> status -110 usb 1-1: USB device not accepting new address=2 (error=-110) sa-ohci 0400: GetStatus roothub.portstatus [1] = 0x00100103 PRSC PPS PES CCS hub 1-0:0: new USB device on port 1, assigned address 3 usb 1-1: new device strings: Mfr=0, Product=0, SerialNumber=0 drivers/usb/core/usb.c: usb_hotplug usb 1-1: usb_new_device - registering interface 1-1:0 drivers/usb/core/usb.c: usb_hotplug usb 1-1: usb_new_device - registering interface 1-1:1 drivers/usb/core/usb.c: usb_hotplug usb 1-1: usb_new_device - registering interface 1-1:2 drivers/usb/core/usb.c: usb_hotplug --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/l
Re: [linux-usb-devel] cleanup of synchronous API
Am Mittwoch, 19. März 2003 22:00 schrieb Pete Zaitcev: > > From: Oliver Neukum <[EMAIL PROTECTED]> > > Date: Wed, 19 Mar 2003 21:44:10 +0100 > > > > +#define __wait_event_timeout(wq, condition, ret) \ > > + if (condition) \ > > + break; \ > > I find it deeply disturbing to see this sort of trick. > For one thing, it constrains you to a macro implementation. > Why don't you take it to linux-kernel? I don't understand this remark. Could you elaborate? What's wrong about adding the fourth macro of this kind to the macros already present there? I asked on linux-kernel and nobody so far has answered. As these are the new macros in 2.5 exactly for such purposes shouldn't such macros be used? What exactly is the problem you see here? Regards Oliver --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.4.21-pre5: oops on hotplug restart (ehci/uhci)
On Wednesday 19 March 2003 15:36, David Brownell wrote: > Duncan Sands wrote: > > From time to time when booting 2.4.21-pre5, the > > hotplug script for my usb modem seems to be run > > three times. If I then try to restart the hotplug > > subsystem, I systematically get an oops: > > > > ehci-hcd 00:10.3: remove state 3 > > usb.c: USB disconnect on device 00:10.3-0 address 1 > > usb.c: USB bus 1 deregistered > > usb.c: USB disconnect on device 00:0a.0-0 address 1 > > usb.c: USB bus 2 deregistered > > usb.c: USB disconnect on device 00:10.2-0 address 1 > > usb.c: USB bus 3 deregistered > > usb.c: USB disconnect on device 00:10.1-0 address 1 > > usb.c: USB disconnect on device 00:10.1-2 address 2 > > usb.c: USB bus 4 deregistered > > usb.c: USB disconnect on device 00:10.0-0 address 1 > > usb.c: USB bus 5 deregistered > > So five root hubs got removed through the "rmmod" sequence. > One of them had a device connected to it at that time. > > That one, 00:10.1, would seem to be a UHCI controller, > given that 00:10.3 is a VT8235 (VIA), and that we heard > > from the UHCI controller: > > kmem_cache_destroy: Can't free all objects c158ea08 > > uhci: not all urb_priv's were freed > > Not clear why that didn't shut down completely; maybe > Johannes knows. I could believe it was related to the > way your device enumerated three times ... could be that > something didn't get cleaned up properly. > > The "oops" below is because the old slab cache didn't get > destroyed, so that a new one (with the same name) couldn't > get created. (Me, I'd rather see kmem_cache_create just > fail rather than BUG out...) > > > Nothing here seems to implicate the EHCI code. Hi Dave, thanks for your comments. I didn't realize that kmem_cache_create would BUG, I assumed the USB code was failing to deal with the error condition. By the way, I wanted to thank you for your clear explanation of the possibly problematic interaction of DMA and CPU writes due to cache flushing. I'm afraid your email got eaten by a massive system failure here - but fortunately I archived it in a few neurons first. Ciao, Duncan. --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] cleanup of synchronous API
> From: Oliver Neukum <[EMAIL PROTECTED]> > Date: Wed, 19 Mar 2003 21:44:10 +0100 > +#define __wait_event_timeout(wq, condition, ret) \ > + if (condition) \ > + break; \ I find it deeply disturbing to see this sort of trick. For one thing, it constrains you to a macro implementation. Why don't you take it to linux-kernel? -- Pete --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] cleanup of synchronous API
Hi Dave,
does this remove your doubts about race conditions in the synchronous API?
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[EMAIL PROTECTED], 2003-03-19 21:40:48+01:00, [EMAIL PROTECTED]
- cleanup of synchronous API
drivers/usb/core/message.c | 55 ++---
include/linux/wait.h | 26 +
2 files changed, 48 insertions(+), 33 deletions(-)
diff -Nru a/drivers/usb/core/message.c b/drivers/usb/core/message.c
--- a/drivers/usb/core/message.cWed Mar 19 21:41:41 2003
+++ b/drivers/usb/core/message.cWed Mar 19 21:41:41 2003
@@ -34,49 +34,34 @@
init_waitqueue_head(&awd.wqh);
awd.done = 0;
-
- set_current_state(TASK_UNINTERRUPTIBLE);
- add_wait_queue(&awd.wqh, &wait);
-
urb->context = &awd;
- status = usb_submit_urb(urb, GFP_ATOMIC);
+ status = usb_submit_urb(urb, GFP_NOIO);
if (status) {
// something went wrong
- usb_free_urb(urb);
- set_current_state(TASK_RUNNING);
- remove_wait_queue(&awd.wqh, &wait);
return status;
}
- while (timeout && !awd.done)
- {
- timeout = schedule_timeout(timeout);
- set_current_state(TASK_UNINTERRUPTIBLE);
- rmb();
+ wait_event_timeout(awd.wqh, awd.done != 0, timeout);
+
+ if (!awd.done) {
+ /* failure, we have to kill the urb */
+ int ulrv;
+
+ ulrv = usb_unlink_urb(urb);
+ /* we may have lost the race */
+ if (!ulrv) {
+ /* we've won */
+ return -ETIMEDOUT;
+ }
+ /* we've lost - falling back to normal path */
}
- set_current_state(TASK_RUNNING);
- remove_wait_queue(&awd.wqh, &wait);
-
- if (!timeout && !awd.done) {
- if (urb->status != -EINPROGRESS) { /* No callback?!! */
- printk(KERN_ERR "usb: raced timeout, "
- "pipe 0x%x status %d time left %d\n",
- urb->pipe, urb->status, timeout);
- status = urb->status;
- } else {
- warn("usb_control/bulk_msg: timeout");
- usb_unlink_urb(urb); // remove urb safely
- status = -ETIMEDOUT;
- }
- } else
- status = urb->status;
+ status = urb->status;
if (actual_length)
*actual_length = urb->actual_length;
-
- usb_free_urb(urb);
- return status;
+
+ return status;
}
/*---*/
@@ -96,6 +81,7 @@
usb_api_blocking_completion, 0);
retv = usb_start_wait_urb(urb, timeout, &length);
+ usb_free_urb(urb);
if (retv < 0)
return retv;
else
@@ -182,6 +168,7 @@
void *data, int len, int *actual_length, int timeout)
{
struct urb *urb;
+ int r;
if (len < 0)
return -EINVAL;
@@ -193,7 +180,9 @@
usb_fill_bulk_urb(urb, usb_dev, pipe, data, len,
usb_api_blocking_completion, 0);
- return usb_start_wait_urb(urb,timeout,actual_length);
+ r = usb_start_wait_urb(urb,timeout,actual_length);
+ usb_free_urb(urb);
+ return r;
}
/*---*/
diff -Nru a/include/linux/wait.h b/include/linux/wait.h
--- a/include/linux/wait.h Wed Mar 19 21:41:41 2003
+++ b/include/linux/wait.h Wed Mar 19 21:41:41 2003
@@ -173,6 +173,32 @@
__ret; \
})
+#define __wait_event_timeout(wq, condition, ret) \
+do { \
+ wait_queue_t __wait;\
+ init_waitqueue_entry(&__wait, current); \
+ \
+ add_wait_queue(&wq, &__wait); \
+ for (;;) { \
+ set_current_state(TASK_UNINTERRUPTIBLE);\
+ if (condition) \
+ break; \
+ ret = schedule_timeout(ret);\
+ if (!ret) \
+ bre
Re: [linux-usb-devel] Belkin Compact Flash card reader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 Mar 2003 at 5:36am, Gary A. Gorgen wrote: > I'm have not used the Beklin CF reader, BUT... > > Vendor "55aa" is the required vendor code for the NEC-131 controller, > when it' in test/factory mode. It' possible that a batch of products got > shipped with factory firmware. > > If this is the case, the serial number should be valid. (not garbage) > The serial number is set when the factory firmware is loaded. The vendor > string "OCI-USB" looks ok. Ah, interesting. The relevant lines from /proc/bus/usb/devices are: T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=55aa ProdID=b000 Rev= 5.00 S: Manufacturer= S: Product=USB CompactFlash S: SerialNumber=58F14C32F1 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms It has a serial number (my friend's doesn't). > Here'a something, I NEVER thought I'd say, "Try it with Windoz". :-) > If it has factory firmware in it, it won't work there either. It works fine under Windows. What a pain. On Wed, 19 Mar 2003 at 10:05am, Alan Stern wrote: > Dave: > > You didn't say what version of Linux you were running. Try installing > 2.4.21-current and see if that makes a difference. A couple of changes > were made to the usb-storage driver fairly recently that might address > the problem you see. > > Alan Stern Apologies, those logs were from 2.4.20. 2.4.21-rc5 fails similarly. Dave - -- Dave Turner [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- iD8DBQE+eNPDeFNVJYkmfV8RAoyTAJ9zeWy3u7x9CxSBr12wD33G2oaQFwCfZ26C K5rATSuUDjvWjimDUYZBJ10= =Nd4x -END PGP SIGNATURE- --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] USB speedtouch: get rid of atmsar
On Tue, Mar 18, 2003 at 12:23:16PM +0100, Duncan Sands wrote: > There are really only two patches: add atmsar stuff into > speedtouch.c; and update the Makefile. The other changes > are: delete atmsar.c and atmsar.h, rename speedtouch.c to > speedtch.c. If you prefer to do the deleting and renaming > by hand, I could send you patches that only modify > speedtouch.c and the Makefile. Nah, this works. My scripts and bk handled the deletes and rename just fine. Applied. thanks, greg k-h --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH]fix to synchronous API regarding memory allocation
On Tue, Mar 18, 2003 at 10:26:23AM +0100, Oliver Neukum wrote: > Hi, > > some part of the synchronous API is used in the block io error handling > code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL. Applied, thanks. greg k-h --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] USB speedtouch: cosmetic comment changes
On Tue, Mar 18, 2003 at 09:55:02AM +0100, Duncan Sands wrote: > speedtouch.c | 53 ++--- > 1 files changed, 14 insertions(+), 39 deletions(-) Applied, thanks. greg k-h --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] fxload improvement ideas, CVS branch names
David Brownell said: > Hmm, maybe the problem is with the "libusb" API then ... which > would suggest that's where the fix should be. I don't know > who's maintaining it lately. Johannes Erdfelt and a few others: http://sf.net/projects/libusb Development is reasonably active, but most of the new features are going into the 1.x branch. > User mode APIs for the host side of Linux are a bit problematic. > I understand that MS-Windows has an especially bogus model for > discovering devices, but the MacOS X is more reasonable; and > that neither offers the relatively full access Linux does. Still haven't collected my thoughts enough to post a proposal to libusb-devel: extending the API would be nice, but would require changes to all of the low-level libusb source files. Are you proposing the addition an alternate usb_open() function that could take a usbfs path? Not sure what the BSDs have in this vein, but I'm pretty sure that OS X doesn't have such a facility. Also, I don't think libusb supports Windows yet (AFAIK, you would need a VxD to do anything other than detect devices, and call HID functions), but I'd be happy to be proven wrong on that count. -- Charles Lepple <[EMAIL PROTECTED]> http://www.ghz.cc/charles/ --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch 2.5.65] ehci-hcd, don't use PCI MWI
On Wed, Mar 19, 2003 at 07:53:35AM -0800, David Brownell wrote: > Jeff Garzik wrote: > > Please don't -- Ivan has a patch for this, let's get that in instead. > > I'd be happy with that, except on the 2.4 trees where we haven't > seen such a patch yet. (So Greg -- please hold off on this > for 2.5 unless/until it becomes clear Ivan's patch won't happen.) Hopefully I'll post the updated patch tomorrow. Right now I'm chasing down weird problem - 2.5.65 broke networking on one of my boxes. So far I figured out that reverting serial/core changes fixes that. Incredibly... Ivan. --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] fxload improvement ideas, CVS branch names
David Brownell said: > Charles Lepple wrote: [...] >> * cross-platform libusb support: [...] > In general, it's worth avoiding multiple code paths. If "libusb" > will do the vendor control messages, just use it everywhere; it'll be > simpler to maintain/debug that way. I am reminded of an Edsger Dijkstra quote: "Computing's central challenge, viz. 'How not to make a mess of it', has /not/ been met." Right after making the LIBUSB branch, I realized the problem: sending control messages isn't the problem, opening the proper device is. IMHO, libusb does an excellent job of abstracting USB devices, but this abstraction makes it difficult for fxload to handle its original job of downloading firmware to a specific device (and not just any device that matches a given VID/PID). Without breaking encapsulation, the only way for a libusb-based fxload to honor the requested device path is to search all of the devices found by libusb and identify where bus->filename and dev->filename match. This doesn't solve my original problem (the motivation for considering libusb in the first place), which was to not have two separate programs for loading EZ-USB chips under Linux and (in my case) Mac OS X. Under OS X, since fxload wouldn't be called by hotplug scripts, I would want to match by VID/PID anyway, but that doesn't warrant the aforementioned kludge for Linux. I'm going to ponder this one some more, but I'm leaning towards not trying to merge the libusb-enabled version back into the main branch. Suggestions welcome. -- Charles Lepple <[EMAIL PROTECTED]> http://www.ghz.cc/charles/ --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch 2.5.65] ehci-hcd, don't use PCI MWI
Jeff Garzik wrote: On Wed, Mar 19, 2003 at 07:21:42AM -0800, David Brownell wrote: Hi, Some users have been sending init logs for Athlon kernels that include PCI warning messages about the PCI cache line size getting set incorrectly ... where the kernel thinks that the right value is 16 bytes. Since 64 bytes is the right number, it's dangerous to enable MWI on such systems. This patch stops trying to use MWI; it's a workaround for the misbehavior of that PCI cacheline-setting code. Please apply to 2.5 and 2.4 trees. Please don't -- Ivan has a patch for this, let's get that in instead. I'd be happy with that, except on the 2.4 trees where we haven't seen such a patch yet. (So Greg -- please hold off on this for 2.5 unless/until it becomes clear Ivan's patch won't happen.) We all acknowledge your patch is a workaround, but this sort of fix does not belong in the mainstream kernel. We want to fix it The Right Way(tm), once. And since a patch already exists for this... Yep, I figured CC'ing LKML would help move things forward ... :) - Dave We need to get IvanK's extended-save-restore-state patch in, too. Ivan, would you be up for a repost on lkml? Jeff --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb to serial converter driver???
How do you plan to realize the hardware ? One USB hub with 5 USB-serial converters or a new device ? --Kentropy --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch 2.5.65] ehci-hcd, don't use PCI MWI
On Wed, Mar 19, 2003 at 07:21:42AM -0800, David Brownell wrote: > Hi, > > Some users have been sending init logs for Athlon kernels that > include PCI warning messages about the PCI cache line size > getting set incorrectly ... where the kernel thinks that the > right value is 16 bytes. Since 64 bytes is the right number, > it's dangerous to enable MWI on such systems. > > This patch stops trying to use MWI; it's a workaround for the > misbehavior of that PCI cacheline-setting code. Please apply > to 2.5 and 2.4 trees. Please don't -- Ivan has a patch for this, let's get that in instead. We all acknowledge your patch is a workaround, but this sort of fix does not belong in the mainstream kernel. We want to fix it The Right Way(tm), once. And since a patch already exists for this... We need to get IvanK's extended-save-restore-state patch in, too. Ivan, would you be up for a repost on lkml? Jeff --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 2.5.65] ehci-hcd, don't use PCI MWI
Hi, Some users have been sending init logs for Athlon kernels that include PCI warning messages about the PCI cache line size getting set incorrectly ... where the kernel thinks that the right value is 16 bytes. Since 64 bytes is the right number, it's dangerous to enable MWI on such systems. This patch stops trying to use MWI; it's a workaround for the misbehavior of that PCI cacheline-setting code. Please apply to 2.5 and 2.4 trees. - Dave --- 1.45/drivers/usb/host/ehci-hcd.cMon Feb 24 03:30:38 2003 +++ edited/drivers/usb/host/ehci-hcd.c Wed Mar 19 07:05:33 2003 @@ -432,7 +432,11 @@ } /* help hc dma work well with cachelines */ - pci_set_mwi (ehci->hcd.pdev); + /* NOTE: disabled until it works reliably ... some x86/Athlon +* kernels are thinking 16 byte cachelines, not 64 byte ones, +* so clearly the MWI prep logic is wrong. +*/ + // pci_set_mwi (ehci->hcd.pdev); /* clear interrupt enables, set irq latency */ temp = readl (&ehci->regs->command) & 0xff;
[linux-usb-devel] Prolific USB-serial converter
Hi to all, I am facing a problem using a Prolific USB to serial converter. It work fine with my linuxbos RH8.0 but I have this problem when connected to a SA1110 custom board I am using kernel-2.4.18-rmk7 Does anybody could suggest me how to solve this problem ? USBReset: full speed Device attached hub.c: USB new device connect on bus1/1, assigned device number 2 usbserial.c: PL-2303 converter detected usbserial.c: PL-2303 converter now attached to ttyUSB0 (or usb/tts/0 for devfs) $ echo HELLO > /dev/ttyUSB0 SOF interrupt: td_array->len = 0x1, s/b: 0 INTERRUPT URB:[ 2c5] dev: 2,ep: 1-I,type:INTR,flags: 0,len:0/10,stat:-115(ff8d) hc_simple.h: data(0/10): stat:-115 SOF interrupt: td_array->len = 0x1, s/b: 0 INTERRUPT URB:[ 32c] dev: 2,ep: 1-I,type:INTR,flags: 0,len:0/10,stat:-115(ff8d) hc_simple.h: data(0/10): stat:-115 SOF interrupt: td_array->len = 0x1, s/b: 0 INTERRUPT URB:[ 393] dev: 2,ep: 1-I,type:INTR,flags: 0,len:0/10,stat:-115(ff8d) hc_simple.h: data(0/10): stat:-115 SOF interrupt: td_array->len = 0x1, s/b: 0 INTERRUPT URB:[ 3fa] dev: 2,ep: 1-I,type:INTR,flags: 0,len:0/10,stat:-115(ff8d) hc_simple.h: data(0/10): stat:-115 SOF interrupt: td_array->len = 0x1, s/b: 0 INTERRUPT URB:[ 461] dev: 2,ep: 1-I,type:INTR,flags: 0,len:0/10,stat:-115(ff8d) hc_simple.h: data(0/10): stat:-115 SOF interrupt: td_array->len = 0x1, s/b: 0 INTERRUPT URB:[ 4c8] dev: 2,ep: 1-I,type:INTR,flags: 0,len:0/10,stat:-115(ff8d) hc_simple.h: data(0/10): stat:-115 SOF interrupt: td_array->len = 0x1, s/b: 0 INTERRUPT URB:[ 52f] dev: 2,ep: 1-I,type:INTR,flags: 0,len:0/10,stat:-115(ff8d) hc_simple.h: data(0/10): stat:-115 SOF interrupt: td_array->len = 0x1, s/b: 0 TIA --Kentropy --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb to serial converter driver???
Have you looked at the existing serial driver? On Wed, 19 Mar 2003, tiwari siddharth wrote: > Hi all, > > I'm looking forward to develop a USB driver for a > device(USB to serial coverter), which has some 5 > serial ports on it and is connected to my hosts USB > port. > I have already done a background study of programming > for USB drivers in Linux. > So plz. suggest me of where to start peeping into the > drivers provided by linux or is there an already > existing driver which serves the same purpose. > I'll be grateful for any kind of help. > > cheers, > Sid. > > __ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > > > --- > This SF.net email is sponsored by: Does your code think in ink? > You could win a Tablet PC. Get a free Tablet PC hat just for playing. > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > ___ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > -- /+-\ |Stephen J. Gowdy | SLAC, MailStop 34, | |http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road, | |http://calendar.yahoo.com/gowdy | Menlo Park CA 94025, USA | |EMail: [EMAIL PROTECTED] | Tel: +1 650 926 3144 | \+-/ --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB analogic modem and ACM driver
- Original Message - From: "Oliver Neukum" <[EMAIL PROTECTED]> To: "Kentropy" <[EMAIL PROTECTED]> Sent: Tuesday, March 11, 2003 4:18 PM Subject: Re: [linux-usb-devel] USB analogic modem and ACM driver > > > some clarifications: 1. If I enable ACM support into the kernek-2.4.19 can > > I use an ACM compilat modem with no other driver ? 2. If yes, which USB > > analogic56K modems are ACM compliants ? > > 1. Yes. > 2. I have no idea. Hi Oliver, thank you for answering. I wonder how can you say that I can use an ACM compliant modem with no other driver If I enable ACM support into the kernek-2.4.19, if you don't tell me which USB analogic56K modems are ACM compliants ? How did you test that ? Which modem did you use ? TIA --Kentropy --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Belkin Compact Flash card reader
On Tue, 18 Mar 2003, Dave Turner wrote: > Hi all, > > I've recently bought a USB Compact Flash card reader from Belkin on the > recommendation of a friend who had no problem getting his working under Linux. > Of course, Belkin seem to have changed something and I'm having trouble > getting going. > usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes > usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096 > usb-storage: usb_stor_transfer_partial(): transfer complete > usb-storage: usb_stor_transfer_partial(): xfer 1536 bytes > usb-storage: command_abort() called > usb-storage: usb_stor_bulk_msg() returned -104 xferred 64/1536 > usb-storage: usb_stor_transfer_partial(): unknown error > usb-storage: Bulk data transfer result 0x2 > usb-storage: Attempting to get CSW... > uhci.c: uhci_submit_urb: urb not available to submit (status = -104) > usb-storage: Bulk status result = -22 > usb-storage: -- transport indicates error, resetting > usb-storage: Bulk reset requested > usb_control/bulk_msg: timeout > usb-storage: Bulk soft reset failed -110 > usb-storage: scsi cmd done, result=0x7 > usb-storage: *** thread sleeping. > > That's it. The umount process hangs so deeply I cannot kill it and I'm stuck > until (horror!) I reboot. Dave: You didn't say what version of Linux you were running. Try installing 2.4.21-current and see if that makes a difference. A couple of changes were made to the usb-storage driver fairly recently that might address the problem you see. Alan Stern --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: EHCI Improvements
Jonathan Thorpe wrote: Greetings, A few days ago, Asrock released a new BIOS for the motherboard that I have been using as my primary test computer for the VT8235. The BIOS changelog doesn't specifically mention any improvements to PCI handling and everything else appears to be fairly unrelated (except for the USB boot which now works really well) - see http://www.asrock.com.tw/support/bios/Info/K7VT2_Info.txt Looks like the BIOS changelog might be incomplete then ... this is a rather curious discovery. Since the update, the computer has not hang once during data read/write operations to the USB 2.0 HDD on the VIA EHCI controller. I thought this would have been the recent EHCI code if anything, but after reverting back to the previous version of the BIOS (1.20), the computer was back to writing perfectly, then hanging when the read operations were performed on the USB 2.0 HDD. The only way I could get it to hang was unloading and loading the EHCI driver twice - this is understandable and not normal practice. Actually, not understandable to me. I've never seen it, and would not expect it ever to happen. The VIA EPIA-M and EPOX are still two problem computers with the EHCI and may be suffering from something that the BIOS configures improperly. When I updated the BIOS, I ensured that all settings remained the same to avoid any confusion and the same IRQs are assigned to the same devices. Could this case provide any clues as to why the VT8235 still hangs like crazy on some computers? Yes, but likely the details of the clue are available exclusively to the folk who updated that BIOS ... Is there any data that I can provide which may provide some clues? On my system that's currently running 2.4.21-pre5-ac3, here are some logs I created. The files starting in 120 are from the computer running the BIOS 1.20, and the files starting in 130 are those which are from the computer running BIOS 1.30: http://users.bigpond.net.au/linux/ehci/120_dmesg http://users.bigpond.net.au/linux/ehci/130_dmesg The main worrisome thing there is that PCI warning message that says it expected a PCI cache line size of 16 bytes; the right number is 64 bytes, and that wrong value could lead to some problems. You might want to comment out the line in "ehci-hcd.c" that calls pci_set_mwi(). http://users.bigpond.net.au/linux/ehci/120_lspci-vvv http://users.bigpond.net.au/linux/ehci/130_lspci-vvv http://users.bigpond.net.au/linux/ehci/120_interrupts http://users.bigpond.net.au/linux/ehci/130_interrupts I intend on recompiling the kernel later on today with EHCI debugging messages; will these be of any help? Likely not, since the failure is more subtle than those diagnostics are intended to report. - Dave Thanks, Jonathan Thorpe --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.4.21-pre5: oops on hotplug restart (ehci/uhci)
Duncan Sands wrote: From time to time when booting 2.4.21-pre5, the hotplug script for my usb modem seems to be run three times. If I then try to restart the hotplug subsystem, I systematically get an oops: ehci-hcd 00:10.3: remove state 3 usb.c: USB disconnect on device 00:10.3-0 address 1 usb.c: USB bus 1 deregistered usb.c: USB disconnect on device 00:0a.0-0 address 1 usb.c: USB bus 2 deregistered usb.c: USB disconnect on device 00:10.2-0 address 1 usb.c: USB bus 3 deregistered usb.c: USB disconnect on device 00:10.1-0 address 1 usb.c: USB disconnect on device 00:10.1-2 address 2 usb.c: USB bus 4 deregistered usb.c: USB disconnect on device 00:10.0-0 address 1 usb.c: USB bus 5 deregistered So five root hubs got removed through the "rmmod" sequence. One of them had a device connected to it at that time. That one, 00:10.1, would seem to be a UHCI controller, given that 00:10.3 is a VT8235 (VIA), and that we heard from the UHCI controller: kmem_cache_destroy: Can't free all objects c158ea08 uhci: not all urb_priv's were freed Not clear why that didn't shut down completely; maybe Johannes knows. I could believe it was related to the way your device enumerated three times ... could be that something didn't get cleaned up properly. The "oops" below is because the old slab cache didn't get destroyed, so that a new one (with the same name) couldn't get created. (Me, I'd rather see kmem_cache_create just fail rather than BUG out...) Nothing here seems to implicate the EHCI code. - Dave ehci-hcd 00:10.3: VIA Technologies, Inc. USB 2.0 ehci-hcd 00:10.3: irq 21, pci mem e088ef00 usb.c: new USB bus registered, assigned bus number 1 ehci-hcd 00:10.3: USB 2.0 enabled, EHCI 1.00, driver 2003-Jan-22 hub.c: USB hub found hub.c: 6 ports detected uhci.c: USB Universal Host Controller Interface driver v1.1 kernel BUG at slab.c:815! invalid operand: CPU:0 EIP:0010:[]Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: c158ea74 ecx: c158ea00 edx: c158ea6c esi: c158ea66 edi: e089536f ebp: c158ea6c esp: deb55ed0 ds: 0018 es: 0018 ss: 0018 Process modprobe.moduti (pid: 1064, stackpage=deb55000) Stack: 003c deb55ee8 c158ea94 fffc 0038 fff4 e089 e0894e15 e0895361 003c 0040 ffea c011bef6 e0890060 08084ff0 6390 Call Trace:[] [] [] [] [] [] Code: 0f 0b 2f 03 fc a5 23 c0 8b 01 89 ca 89 c1 0f 0d 00 81 fa 44 EIP; c013203d<= ebx; c158ea74 <_end+12aca1c/20582028> ecx; c158ea00 <_end+12ac9a8/20582028> edx; c158ea6c <_end+12aca14/20582028> esi; c158ea66 <_end+12aca0e/20582028> edi; e089536f <[uhci].text.end+3f0/11a1> ebp; c158ea6c <_end+12aca14/20582028> esp; deb55ed0 <_end+1e873e78/20582028> Trace; e0894e15 <[uhci]uhci_hcd_init+b5/140> Trace; e0895361 <[uhci].text.end+3e2/11a1> Trace; c011bef6 Trace; e0890060 <[ehci-hcd].data.end+3c79/3c99> Trace; e0890060 <[ehci-hcd].data.end+3c79/3c99> Trace; c010733f Code; c013203d <_EIP>: Code; c013203d<= 0: 0f 0b ud2a <= Code; c013203f 2: 2fdas Code; c0132040 3: 03 fc add%esp,%edi Code; c0132042 5: a5movsl %ds:(%esi),%es:(%edi) Code; c0132043 6: 23 c0 and%eax,%eax Code; c0132045 8: 8b 01 mov(%ecx),%eax Code; c0132047 a: 89 ca mov%ecx,%edx Code; c0132049 c: 89 c1 mov%eax,%ecx Code; c013204b e: 0f 0d 00 prefetch (%eax) Code; c013204e 11: 81 fa 44 00 00 00 cmp$0x44,%edx 1 warning issued. Results may not be reliable. /etc/hotplug/usb.rc: line 373: 1064 Segmentation fault modprobe -q uhci >/dev/null 2>&1 <3>hub.c: port 5 over-current change hub.c: port 6 over-current change --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] usb to serial converter driver???
Hi all, I'm looking forward to develop a USB driver for a device(USB to serial coverter), which has some 5 serial ports on it and is connected to my hosts USB port. I have already done a background study of programming for USB drivers in Linux. So plz. suggest me of where to start peeping into the drivers provided by linux or is there an already existing driver which serves the same purpose. I'll be grateful for any kind of help. cheers, Sid. __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Belkin Compact Flash card reader
Dave Turner wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > >Hi all, > >I've recently bought a USB Compact Flash card reader from Belkin on the > *** snip *** > >04e6:000a for manufacturer:model and mine is 55aa:b000. Also >/proc/scsi/scsi reports mine as Vendor OCI-USB and his eUSB. There are >other differences which I will post if you think they might be helpful but >this is going to be long as it is... I'm have not used the Beklin CF reader, BUT... Vendor "55aa" is the required vendor code for the NEC-131 controller, when it' in test/factory mode. It' possible that a batch of products got shipped with factory firmware. If this is the case, the serial number should be valid. (not garbage) The serial number is set when the factory firmware is loaded. The vendor string "OCI-USB" looks ok. I would think, if it's a Beklin product, it would have a Beklin vendor ID. Being able to read & write to the device, would be dependant upon the firmware. Here'a something, I NEVER thought I'd say, "Try it with Windoz". :-) If it has factory firmware in it, it won't work there either. If vendor "55aa" is a valid vendor ID, then ignore this, it's probably wrong. Just my $.02, gary, -- Gary A. Gorgen | "From ideas to PRODUCTS" | Tunxis Design Inc. [EMAIL PROTECTED]| 10470 Pineville Ave. Cupertino, Ca. 95014 | Phone: (408) 973-1542 --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] USB-Serial ftdi_sio works with HP MT608-2
Hello, I have a HP MT608-2 USB-to-Serial Converter and it works with the ftdi_sio driver, I didn't found it in the USBserial readme, so I thought it would help if I report this to you. Below ist my syslog output when I attach the converter to the USB bus: Mar 14 09:12:57 bender kernel: hub.c: new USB device 00:1f.2-1, assigned address 4 Mar 14 09:12:57 bender kernel: usb.c: USB device 4 (vend/prod 0x403/0x6001) is not claimed by any active driver. Mar 14 09:13:00 bender /etc/hotplug/usb.agent: Setup ftdi_sio for USB product 403/6001/200 Mar 14 09:13:00 bender kernel: usb.c: registered new driver serial Mar 14 09:13:00 bender kernel: usbserial.c: USB Serial support registered for Generic Mar 14 09:13:00 bender kernel: usbserial.c: USB Serial Driver core v1.4 Mar 14 09:13:00 bender kernel: usbserial.c: USB Serial support registered for FTDI SIO Mar 14 09:13:00 bender kernel: usbserial.c: USB Serial support registered for FTDI 8U232AM Mar 14 09:13:00 bender kernel: usbserial.c: FTDI 8U232AM converter detected Mar 14 09:13:00 bender kernel: usbserial.c: FTDI 8U232AM converter now attached to ttyUSB0 (or usb/tts/0 for devfs) Mar 14 09:13:00 bender kernel: ftdi_sio.c: v1.2.1:USB FTDI Serial Converters Driver -- Johannes Ullmann E-Mail: [EMAIL PROTECTED] Phone: +43-(0)664-3234051 ICQ#: 13498421 :wq --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.4.21-pre5: oops on hotplug restart (ehci/uhci)
From time to time when booting 2.4.21-pre5, the hotplug script for my usb modem seems to be run three times. If I then try to restart the hotplug subsystem, I systematically get an oops: ehci-hcd 00:10.3: remove state 3 usb.c: USB disconnect on device 00:10.3-0 address 1 usb.c: USB bus 1 deregistered usb.c: USB disconnect on device 00:0a.0-0 address 1 usb.c: USB bus 2 deregistered usb.c: USB disconnect on device 00:10.2-0 address 1 usb.c: USB bus 3 deregistered usb.c: USB disconnect on device 00:10.1-0 address 1 usb.c: USB disconnect on device 00:10.1-2 address 2 usb.c: USB bus 4 deregistered usb.c: USB disconnect on device 00:10.0-0 address 1 usb.c: USB bus 5 deregistered kmem_cache_destroy: Can't free all objects c158ea08 uhci: not all urb_priv's were freed ehci-hcd 00:10.3: VIA Technologies, Inc. USB 2.0 ehci-hcd 00:10.3: irq 21, pci mem e088ef00 usb.c: new USB bus registered, assigned bus number 1 ehci-hcd 00:10.3: USB 2.0 enabled, EHCI 1.00, driver 2003-Jan-22 hub.c: USB hub found hub.c: 6 ports detected uhci.c: USB Universal Host Controller Interface driver v1.1 kernel BUG at slab.c:815! invalid operand: CPU:0 EIP:0010:[]Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: c158ea74 ecx: c158ea00 edx: c158ea6c esi: c158ea66 edi: e089536f ebp: c158ea6c esp: deb55ed0 ds: 0018 es: 0018 ss: 0018 Process modprobe.moduti (pid: 1064, stackpage=deb55000) Stack: 003c deb55ee8 c158ea94 fffc 0038 fff4 e089 e0894e15 e0895361 003c 0040 ffea c011bef6 e0890060 08084ff0 6390 Call Trace:[] [] [] [] [] [] Code: 0f 0b 2f 03 fc a5 23 c0 8b 01 89 ca 89 c1 0f 0d 00 81 fa 44 >>EIP; c013203d<= >>ebx; c158ea74 <_end+12aca1c/20582028> >>ecx; c158ea00 <_end+12ac9a8/20582028> >>edx; c158ea6c <_end+12aca14/20582028> >>esi; c158ea66 <_end+12aca0e/20582028> >>edi; e089536f <[uhci].text.end+3f0/11a1> >>ebp; c158ea6c <_end+12aca14/20582028> >>esp; deb55ed0 <_end+1e873e78/20582028> Trace; e0894e15 <[uhci]uhci_hcd_init+b5/140> Trace; e0895361 <[uhci].text.end+3e2/11a1> Trace; c011bef6 Trace; e0890060 <[ehci-hcd].data.end+3c79/3c99> Trace; e0890060 <[ehci-hcd].data.end+3c79/3c99> Trace; c010733f Code; c013203d <_EIP>: Code; c013203d<= 0: 0f 0b ud2a <= Code; c013203f 2: 2fdas Code; c0132040 3: 03 fc add%esp,%edi Code; c0132042 5: a5movsl %ds:(%esi),%es:(%edi) Code; c0132043 6: 23 c0 and%eax,%eax Code; c0132045 8: 8b 01 mov(%ecx),%eax Code; c0132047 a: 89 ca mov%ecx,%edx Code; c0132049 c: 89 c1 mov%eax,%ecx Code; c013204b e: 0f 0d 00 prefetch (%eax) Code; c013204e 11: 81 fa 44 00 00 00 cmp$0x44,%edx 1 warning issued. Results may not be reliable. /etc/hotplug/usb.rc: line 373: 1064 Segmentation fault modprobe -q uhci >/dev/null 2>&1 <3>hub.c: port 5 over-current change hub.c: port 6 over-current change --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
