, and the reset code notices
that the descriptors have changed (thanks to the updated firmware) and so
marks the device as NOTATTACHED. The user program immediately closes the
file descriptor because its work is done, and not until khubd wakes up
does the rest of the processing take place.
Alan
longer
connected.
Please apply.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
= drivers/usb/core/devio.c 1.134 vs edited =
--- 1.134/drivers/usb/core/devio.c 2004-11-05 13:06:30 -05:00
+++ edited/drivers/usb/core/devio.c 2004-12-10 11:27:01 -05:00
@@ -523,13 +
On Tue, 7 Dec 2004, David Brownell wrote:
> > On Saturday 04 December 2004 11:51 am, Alan Stern wrote:
>
> > > In fact, I suggested skipping the class-specific reset entirely and
> > > proceeding directly to the port reset, because that's what Windows does.
&g
which devices
need the time delay and what the delay should be, since we know that one
size doesn't fit all and some non-Genesys devices also need the delay.
For now this will have to do.
Alan Stern
On Mon, 13 Dec 2004, Jan De Luyck wrote:
> I'm currently using the drive with a ude
ess is added to awd.wqh so that it can sleep during the "while
(timeout && !awd.done)" loop. Since schedule_timeout doesn't change
the process state, it will return immediately if the state isn't set
beforehand to TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE.
Alan Ster
ntrollers have several problems. This one is new to me, though
other people may know about it.
> Can a workaround for this issue be put into the
> kernel? I know that it shouldn't have to be this way.
It's impossible to say whether the problem can be worked around in the
kern
r 2.6, can you
provide the information requested at the top of the unusual_devs.h file?
Can you also provide a usb-storage verbose debugging log showing how the
device fails to work when the entry is not present?
Alan Stern
---
SF email
hing serious has happened,
usb_reset_device will realize it and will force a logical disconnect (or
else khubd will catch it later on). However this reasoning may not be
entirely correct, and I would appreciate external feedback.
Alan Stern
= drivers/usb/core/hub.c 1.215 vs edited =
--- 1.215/drivers/u
roblem on my system that
prevented the port resets from working with the CD writer.
Alan Stern
= drivers/usb/storage/scsiglue.c 1.90 vs edited =
--- 1.90/drivers/usb/storage/scsiglue.c 2004-11-22 13:42:02 -05:00
+++ edited/drivers/usb/storage/scsiglue.c 2004-12-17 11:27:47 -
s only on the initial startup problems with
> 3. Thanks.
There's no way to tell what's happening unless you do what I suggested
before: turn on the USB debugging switch in the kernel configuration and
rebuild the USB drivers. The debugging information that will
More
extensive changes would be needed to make effective use of the
per-endpoint queues now available, and it's probably not worth the effort.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
= drivers/usb/gadget/dummy_hcd.c 1.19 vs edited =
--- 1.19/drivers/usb/ga
eers who designed the USB firmware than on the particular
storage technology involved.
Alan Stern
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which pro
On Wed, 15 Dec 2004, Greg KH wrote:
> On Mon, Dec 13, 2004 at 10:03:47AM -0500, Alan Stern wrote:
> > Greg:
> >
> > This patch fixes a bug in the usbfs code. The driver is too zealous about
> > checking for disconnected devices before doing things. In particular,
David:
Is it just a simple mistake that sl811h_probe returns 0 if it can't
allocate its private data structure? I'm going to assume that it is and
change the value to -ENOMEM.
Alan Stern
---
SF email is sponsored by - The IT Pro
On Sun, 19 Dec 2004, David Brownell wrote:
> On Sunday 19 December 2004 8:07 am, Alan Stern wrote:
> > David:
> >
> > Is it just a simple mistake that sl811h_probe returns 0 if it can't
> > allocate its private data structure? I'm going to assume that it is
On Mon, 20 Dec 2004, Sara Fonseca wrote:
> Hi,
>
> Are any of the mode pages mandatory when for a pen drive?
No, they are not. You can omit all of them.
Alan Stern
---
SF email is sponsored by - The IT Product Guide
Read honest
know that things don't work as well as they used to.
Maybe a reasonable answer would be to ask distributors not to enable ub,
and leave it up to individual users to configure it when they want to.
That is the default setting in Kconfig, after all.
Alan Stern
---
too hard to add a sysfs interface for that sort of
thing.
Alan Stern
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up
work okay. I'm not able to
test the SL811 or non-PCI OHCI drivers.
There's still more to come, but I haven't finished writing and testing
them yet. These are all the patches I had submitted after the 2.6.10
freeze went into effect.
Alan Stern
-
.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
diff -u a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
--- a/drivers/usb/core/hcd-pci.cSat Dec 18 11:51:07 2004
+++ b/drivers/usb/core/hcd-pci.cSat Dec 18 13:54:45 2004
@@ -124,7 +124,7 @@
//
Greg:
This patch alters the EHCI driver, removing the routine that allocates the
hcd structure and introducing inline functions to convert safely between
the public and private hcd structures.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
diff -u a/drivers/usb/host/ehci-d
allocation routine is now gone. That particular aspect should be reviewed
by David, but for now it seems to work.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
diff -u a/drivers/usb/host/ohci-dbg.c b/drivers/usb/host/ohci-dbg.c
--- a/drivers/usb/host/ohci-dbg.c Sat Dec 18 11
Greg:
This patch alters the UHCI driver, removing the routine that allocates the
hcd structure and introducing inline functions to convert safely between
the public and private hcd structures.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
diff -u a/drivers/usb/host/uhci-h
Greg:
This patch alters the non-PCI OHCI drivers, removing the routines that
allocate the hcd structures and introducing inline functions to convert
safely between the public and private hcd structures.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
diff -u a/drivers/usb/hos
Greg:
This patch alters the dummy_hcd driver, removing the routine that
allocates the hcd structure and introducing inline functions to convert
safely between the public and private hcd structures.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
diff -u a/drivers/usb/
e the bus number as well as the driver name -- which was
the original impetus for writing all these patches in the first place!
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
diff -u a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
--- a/drivers/usb/core/hcd-pci.c
Greg:
This patch alters the non-PCI OHCI drivers, removing the code now present
in the core and adding the appropriate function calls. It also adds some
missing iounmap() calls.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
diff -u a/drivers/usb/host/ohci-lh7a404.c b/d
Greg:
This patch alters the dummy_hcd driver, removing the code now present
in the core and adding the appropriate function calls.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
diff -u a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
--- a/drivers/usb/
t value sent
by the device.
Alan Stern
Sent-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
--- a/drivers/usb/core/hub.cFri Dec 17 14:00:09 2004
+++ b/drivers/usb/core/hub.cSun Dec 19 12:07:33 2004
@@ -240,15 +240,24 @@
ther than
the hub device. This simplifies disconnect/unbind testing.
Don't print a debugging message about hub events while not
holding some lock to protect the hub.
Remember to drop the reference acquired above if we fail to
lock the hub.
Alan St
ease apply.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
--- a/drivers/usb/core/hub.hSun Dec 19 12:14:19 2004
+++ b/drivers/usb/core/hub.hSun Dec 19 12:14:07 2004
@@ -186,7 +186,7 @@
extern void usb_hub_tt_clear_buffer (struct usb_device *dev, int pipe);
the
children[] array, but that's a lot better than all the additions of 1 that
were there before. To emphasize the nature of this change, I renamed the
"port" local variable to "port1" every place it is used.
Please apply.
Alan Stern
Signed-off-by: Alan Stern &
ong-period interrupts, for example); one of them
might need to be dequeued while the HC is suspended.
The second patch is my first pass at implementing root-hub polling
control. It contains changes only to usbcore, but obviously the HCDs will
want to be updated as well. Take a look and let m
ld never be used at all! After all, the code containing it might one
day be moved to a context where interrupts are not known to be enabled.
If it should never be used, what's it doing in the kernel?
Alan Stern
---
SF email is sponso
ey = 0x03
(Medium error) with ASC = 0x12 or 0x13 (Address mark not found for ID or
Data field). But if there's data you can read then you should use it.
Alan Stern
---
SF email is sponsored by - The IT Product Guide
Read honest & candid
On Mon, 20 Dec 2004, David Brownell wrote:
> On Monday 20 December 2004 8:09 am, Alan Stern wrote:
> > Greg:
> >
> > This patch alters the non-PCI OHCI drivers,
>
> ... again including the non-OHCI "sl811-hcd" driver.
Yes; I forgot to update that part of th
be suspended with outstanding
> > URBs still in flight (long-period interrupts, for example); one of them
> > might need to be dequeued while the HC is suspended.
>
> Operations on suspended devices are errors though; hence
> "should never happen". The device should be re
about
that in my usb-storage autosuspend patch -- until I tried it!)
My real point is that usbcore does not _guarantee_ that URBs will never be
unlinked while a host controller is suspended, so saying it "should never
happen" is misleading. It _can_ happen under the right circumstances
On Tue, 21 Dec 2004, Oliver Neukum wrote:
> imho you should not have active URBs for suspended devices in the first
> place.
I agree that you should not. Should usbcore be changed so that you
_cannot_?
Alan Stern
---
SF em
mstances will never
> > arise, or else HCDs have to be prepared for it.
>
> And I'm saying that if usbcore doesn't do that, it should.
> Hence the WARN_ON, which would fire in any cases there's
> a potential problem. Have you seen it fire?
Never. Of course, I ha
On Mon, 20 Dec 2004, Greg KH wrote:
> Ok, I'm holding off on applying these for now until David agrees on
> them.
Fine with me.
> Alan, I've applied all of the other ones.
I noticed, and I'm glad to get them out in the public eye
a few times, then it tries to read the partition table anyway.
> The card reader isn't too happy about this.
>
> What am I missing?
You also have to report Media Not Present in response to TEST UNIT READY.
(By definition, a non-failure return for that command means the device is
re a lot of cheap mass product usb2.0-ide
> hdd's out there which use this chipset (i checked 8 of this type which i
> could examine - and in 7 of them was this genesys chipset).
Alan Stern
---
SF email is sponsored by - The IT Produ
nts it from working
correctly when the card is installed.
If you want to get more information about what goes wrong when the card is
in the camera, you will have to turn on the usb-storage verbose debugging
option in your kernel configuration and post the system log showing all
t
On Tue, 21 Dec 2004, Pete Zaitcev wrote:
> On Tue, 21 Dec 2004 10:17:11 -0500 (EST), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > It's not for lack of submission. I sent the revised version of that patch
> > to Pete Zaitcev on two separate occasions.
>
>
et cleaned up.
It would be nice to find out what part of the cleanup isn't happening
right. Do you know at what point that "fatal error" occurs? Is it during
probe? Can you post a short patch that will simulate the same effect?
I will spen
the as424b-as426b patches, without the bus glue changes. Maybe that will
> > make a difference.
>
> Hold off on that a bit yet. I may yet be persuaded that your
> current patches are just fine; like I said, I just wanted a
> chance to think about them properly!
Okay, I'll keep
ing
> unique to the HP8200 which would allow us to do e.g.:
> if (some condition)
> //device is hp8200
> else
> //device is flash
Nothing that I know of. But I am far from being an expert on the hp8200.
Alan Stern
--
e hp8200 and the
> flash readers use the ATA/ATAPI transport. Or are you suggesting that the
> hp8200 implements ATA but not ATAPI?
Well, the IDENTIFY PACKET DEVICE command looks relevant. Beyond that, you
need to rely on appropriate packet commands. INQUIRY is
roc/bus/usb/devices listing
appears to be an Iomega DVDRW. Did it not show up in the listing for some
reason?
Alan Stern
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on h
8200's *do* support these?
Don't ask me; I know zero about the HP8200. However the shuttle_usbat
driver does seem to use packet commands, according to the comments in the
source code.
Doesn't the fact that the flash version returns a
Check your system log for error messages from usb-storage. If there
aren't any, and the device indicates that the data transfers are all
working well, then I don't see what more can be fixed (at this level,
anyway).
Alan Stern
-
affic, you can send just the portion corresponding to
the uhci_result_control routine.)
Alan Stern
--- a/drivers/usb/host/uhci-hcd.c Mon Dec 20 09:45:03 2004
+++ b/drivers/usb/host/uhci-hcd.c Fri Dec 24 15:35:22 2004
@@ -236,11 +236,11 @@
{
struct urb_priv *urbp = (stru
cam...
That error is going to be pretty rare in any event, since it can happen
only when the USB host controller modifies a memory value at precisely the
wrong instant. But with the code fixed, now it shouldn't happen at all.
This is a great example showing how leaving in an apparently useless
.
You say your kernel has oopsed? But the message you sent in before was
not an oops; it was just a "Badness" warning.
The disassembled code you attached looked almost exactly the same as the
code you sent before, as though the patch had not been applied at all.
Are you sur
gt; >
> Sorry once more. It looks like I run patch with --dry-run option and
> later forget to apply patch for real. Please, see attachment now.
Yes, this looks much better. There shouldn't be any problems running with
this version of the code.
Alan Stern
---
ACPI is the culprit. Have you tried booting
with "acpi=off", in both 2.6.9 and 2.6.10?
Alan Stern
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Disco
On Wed, 29 Dec 2004, Paul Ionescu wrote:
> --- Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > Nothing relevant has changed in the uhci_hcd driver,
> > so far as I know.
> > I'd be inclined to guess that ACPI is the culprit.
> > Have you tried bootin
Under 2.6.9 that file would be in the /proc/driver/uhci/ directory, but it
was recently moved to the debugfs filesystem, and I'm not sure whether
that move was done before or after 2.6.10 was released.
Alan Stern
---
The SF.Net emai
hem from serious ones
> which might also occur - such as actual CRC errors?
It sounds like you're doing things right. Maybe the device is
deliberately generating bad CRCs?
Alan Stern
---
The SF.Net email is sponsored by: Beat the po
hen it works.
> Maybe, when I reload uhci-hcd, it does some
> reinitialization of the usb controller.
Yes, but it also does reinitialization during resume.
What does the debugging file show?
Alan Stern
> --- Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Wed, 29 Dec 2004,
simply a missing response. Not surprising,
considering this happens when the pipe has been turned off.
So the problem you face is determining whether -EILSEQ indicates a genuine
CRC error or a missing response. In the end maybe it doesn't matter very
much -- either way you failed to re
d perfectly
> I hope this error helps you some.
I believe this problem has been fixed in the 2.6.10 kernel.
Alan Stern
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from
se apply.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
= drivers/usb/host/uhci-hcd.c 1.150 vs edited =
--- 1.150/drivers/usb/host/uhci-hcd.c 2004-12-18 10:22:52 -05:00
+++ edited/drivers/usb/host/uhci-hcd.c 2005-01-03 10:21:16 -05:00
@@ -236,11 +236,11 @@
{
g a single "volatile", I can make the compiler
do all that work for me, with no errors.
In David's words, it's a tradeoff. As the maintainer, I decided to go
in favor of simplicity and ease-of-maintenance.
Alan Stern
ts where the
"volatile" causes abominable code generation.
Alan Stern
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fu
ssibility is to write a userspace program. Use libusb to send
the commands you need, and then use the USBDEVFS_CONNECT ioctl to cause
the usb-storage driver to rebind to the stick.
The advantage of this approach is that it's simpler and easier than
B_DEBUG!). Then
post the contents of /proc/driver/uhci/... (whichever file corresponds to
the controller your mouse is plugged into):
before the suspend (and then don't touch the mouse),
after the suspend (before touching the mouse),
after moving the mouse.
There ma
ust voicing and opinion.
All right. Given the weight of opinion and experience coming down on this
matter, I will redo the patch using barriers instead of volatile.
Alan Stern
---
The SF.Net email is sponsored by: Beat the post-holiday blu
e
> INQUIRY commands, as he wants.
In fact it probably _won't_ run before the INQUIRY commands etc. The
initial probing will fail. But then the program can run and when it
rebinds the drivers, probing will start all over again. Presumably the
second time it will work.
Alan Stern
-
time unload ehci-hcd by hand? Preferably before plugging in the mouse,
but in any case before doing the suspend.
Alan Stern
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt f
is similar to other reports I've seen, showing strange interactions
between an EHCI controller and its companion. It's not clear how to tell
whether the problem lies in the hardware, the BIOS, in ACPI, or in the
EHCI driver.
Alan Stern
--
ror handler in the first place.
No way to tell from the information provided, but I suspect the haldaemon
process isn't doing what it should.
Srihari, can you try reproducing this after rebuilding the usb-storage
driver with CONFIG_USB_STORAGE_DEBUG=y?
Alan Stern
---
local variables to help prevent repeated accesses. No use is made of
the "volatile" keyword. :-)
Please apply.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
= drivers/usb/host/uhci-debug.c 1.27 vs edited =
--- 1.27/drivers/usb/host/uhci-debug.c 2004-12-16
o new
> device.
> If I rmmod/insmod the uhci-hcd at this point, it
> works.
> So I think is not an IRQ problem.
>
> Thanks,
> Paul
Have you been able to see what information is in the debugging file,
/proc/driver/uhci/[controller ID]?
Alan Stern
--
ack
trace for the khubd process? (This may work out better if you switch to
single-user mode and kill unnecessary daemons before doing the swsusp.)
Alan Stern
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE li
uhci_hcd :00:1d.2: suspend_hc
That looks good to me. And the mouse was still working...?
David, any idea on what could be messing up the flip-flop setting?
Alan Stern
---
The SF.Net email is sponsored by: Beat the post-holiday blues
ld_scheme_first=y"
module parameter for usbcore.
Incidentally, if anyone can suggest why some devices like this one fail
with the new initialization scheme while (presumably) working correctly
with Windows, I would like to here it. The intent of the
I just
wanted to know whether or not you had set it.
Alan Stern
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp
On Wed, 5 Jan 2005, David Brownell wrote:
> On Wednesday 05 January 2005 1:33 pm, Alan Stern wrote:
>
> > David, any idea on what could be messing up the flip-flop setting?
>
> Is EHCI being resumed before UHCI -- or afterwards?
EHCI was resumed after
ol.
Devices are resumed in the same order they were detected initially. I
think the only way to solve this problem is to find a workaround for EHCI
controllers that act weird when they resume.
Alan Stern
---
The SF.Net email is sponsored
little sence for me because I'm
> a newcomer in USB :(
Everything in your log looked normal. And it should only have taken a few
seconds. What happened during the remainder of the 3-5 minutes of
waiting?
> Could somebody be so kind to point me what I did wrong?
As far as I can see, y
any normal read;
> so usb_internal_control_msg() would
>
> return length ? length : retv;
>
> I forget why I never submitted a patch to do that.
Are there are drivers that actually care about this? What about the usbfs
API? The i
or it . Even if I use the
> unusual_devs device for Mass storage by
> adding one entry of special device , It is hard to implement it. Am I right?
I don't think you need to do this. Linux already includes an encryption
option with the loop device driver. You can
er of device :00:1d.1 to
> 64
> uhci_hcd :00:1d.2: resume from PCI D0 (legacy)
> PCI: Setting latency timer of device :00:1d.2 to
> 64
> ehci_hcd :00:1d.7: resume from PCI D3hot
I think you've run across another indication that the suspend/resume
support in the U
; resume it is not there anymore, and I have to
> pull/plug the device again.
Just out of curiosity, does the same thing happen with CONFIG_USB_SUSPEND
if you rmmod ehci-hcd before suspending? Does a device plugged in to the
UHCI controller continue to work af
riptor() retries when it gets garbage;
> but in that code path, you don't retry.
The code _does_ retry, following a port reset. Anyway, if a short read
confuses the device, how does immediately repeating the short read manage
to unconfuse it?
> Another question is whether those devices w
the UHCI controllers (the same
problem as Oliver is seeing).
What shows up in the system log when you do the rmmod/insmod after the
resume? It's surprising that things don't quiet down and start working
again.
Alan Stern
---
The SF.Net
set if PORT_OWNER was set?
It's also possible that the flip-flop is changed during the suspend
operation rather than the resume operation. Perhaps Oliver can add some
debugging lines to print the values of the regs->port_status[] entries in
those
t of three hcd
patches.
There are some other things we should do too, like removing the recursion
from the USB suspend/resume code. The suspend routines seem to
misunderstand the idea of a power-off suspend. And certainly the
comments, if not the
On Thu, 6 Jan 2005, Oliver Neukum wrote:
> Am Donnerstag, 6. Januar 2005 20:11 schrieb Alan Stern:
> > It's also possible that the flip-flop is changed during the suspend
> > operation rather than the resume operation. Perhaps Oliver can add some
> > debugging lines
sly like that third pseudo-resume case.
It's worth checking this out. Oliver, after resuming with both uhci-hcd
and ehci-hcd loaded, try doing lspci -xxx for the UHCI controller. The
two bytes at offset 0xc0 are of interest.
Do you have Legacy USB support enabled in your BIOS
On Thu, 6 Jan 2005, David Brownell wrote:
> On Thursday 06 January 2005 1:01 pm, Alan Stern wrote:
> >
> > If the power was shut off entirely, upon resume the controller would have
> > seen a connect change event. No such event shows up in the system logs
> > you po
vable'
> option. The Storage Gadget works properly in both cases.
It's nice to know that Linux can handle some devices better than Windows
can!
Alan Stern
---
The SF.Net email is sponsored by: Beat the post-holid
ts?
I think you have summed up the situation correctly. Development support
for period transactions through TTs is proceeding, but slowly. In the
meantime, two possible workarounds are to plug the audio device directly
into the computer or to use a USB-1.1 hub.
Alan Stern
-
y support off indicates that nothing much changes.
> I've noticed during writing out the image there are several wake_up,resume
> cycles from uhci.
They don't show up in your log, for obvious reasons. It may be perfectly
innocuous; before writing out the image the PM core awakens ev
"fdisk /dev/uba".
He also mentioned that _sometimes_ Windows will mount his gadget without
problems. It wouldn't do that if there was an invalid partition table.
Alan Stern
---
The SF.Net email is sponsored by: Beat the post-h
; > under Linux when not forcing short reads ... :)
> >
> > That's why I think we should always use both schemes.
>
> Yes, I think that'd be a less troublesome default.
>
> But I also think we need to make all the control transfer
store the correct PORT_OWNER setting.
You think so? I'm a little doubtful that writing a UHCI configuration
space register will cause a change to an EHCI port status bit, but who
knows...
I'll send a patch for Oliver to try later on.
Alan Stern
---
ith all the details
of the EHCI driver. It's faintly possible that plugging the drive into a
different USB port would work better.
If you still can't get anything with the debugging option, try running
without the debugging code and rmmod ehci-hcd before plugging in the
device.
901 - 1000 of 6560 matches
Mail list logo
