Alan and David,
The following message is from the owner of the "Shark" camera and the
PCChips board which has caused all the excitement.
Theodore Kilgore
-- Forwarded message --
Date: Wed, 05 Jan 2005 17:54:53 -0500
From: Daniel Dickinson <[EMAIL PROTECTED]>
To: Theodore Kilgore <[E
> The storage gadget takes a backing file and exposes it to a USB host as
> a disk. Can I also mount that as a filesystem on the system running the
> gadget driver? I'm guessing not -- that sounds like two things mounting
> the same device and is probably a Really Bad Idea.
I imagine it'd work f
I'd like a confirmation of my understanding of the storage gadget
driver:
The storage gadget takes a backing file and exposes it to a USB host as
a disk. Can I also mount that as a filesystem on the system running the
gadget driver? I'm guessing not -- that sounds like two things mounting
the sa
> -Original Message-
> From: Alan Stern [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 04, 2005 10:53 PM
> To: Hou Xiang ZHU
> Cc: USB development list
> Subject: Re: [linux-usb-devel] Re: Add UFI command to Mass
> storage device driver
>
>
> On Tue, 4 Jan 2005, Matthew Dharm wrot
On Wednesday 05 January 2005 12:53 pm, Alan Stern wrote:
> I don't know about that low speed "Unlink after no-IRQ" message,
That's some kind of IRQ setup problem. If there isn't a
FAQ on how to tweak IRQ setup in Linux, there should be!
There are options for APIC, Local-APIC, ACPI, and PCI, all
o
Hi.
I have tried kernels 2.6.8 and 2.6.9 and now 2.6.10 all with the same
results. My Zoom 2985 USB modem works perfectly with 2.6.7 but not
with any kernel since then.
Below is some information that I think is relevant. If I can be of
any further help in solving this problem, just let me know.
Fingering BIOS/SMM code as the guilty party should
speed up fixes or workarounds.
- Dave
This changes the OHCI "USB HC TakeOver failed" message to be a bit
more informative, by fingering the root cause: a BIOS/SMM bug.
That way they're more likely to either bug the board vendor, or find
workarou
Those two drivers are pushin' up daisies.
- Dave
Two minor Makefile fixes, catching up to some driver removals.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- a/drivers/usb/Makefile 2005-01-05 12:21:54 -08:00
+++ b/drivers/usb/Makefile 2005-01-05 12:21:54 -08:00
@@ -9,7 +9,7 @@
obj-$(CON
Please merge.
- Dave
This provides basic definitions to support "USB2 Debug Devices", as
supported by certain EHCI root hub ports (from ALI, Intel, NVidia, and
other vendors). Docs are available at Intel's USB spec webpage.
The basic idea is to help debug "legacy free" systems, with no serial po
Sometimes chip evaluation samples are packaged onto
PCI card with a bridge (e.g. from PLX). In production
systems the bridge is never used, and the chip sits on
a platform bus.
This patch lets drivers for such chips be written to
reflect that hardware setup: the chip itself uses
the platform_bus
More cleaning out of my BK tree; please merge.
- Dave
Minor cleanups to the isp130_omap driver: enable the right
amount of VBUS current draw in non-OTG configurations; get rid
of a warning from GCC 2.95.3 ("int" function returns no value);
use kcalloc() not kmalloc+memset.
Signed-off-by: David B
Addressing various questions folk have had; please merge.
- Dave
Some minor doc/comment fixes for USB.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- a/include/linux/usb.h 2005-01-05 12:21:53 -08:00
+++ b/include/linux/usb.h 2005-01-05 12:21:53 -08:00
@@ -729,8 +729,8 @@
* to poll for t
On Wednesday 05 January 2005 2:26 pm, Alan Stern wrote:
> 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 afterward
We seem to have tracked some annoying board-coupled EHCI startup
problems to a chip bug, with a simple workaround. Please merge.
- Dave
This fixes OSDL bugid #3056 for at least some users, where the EHCI
driver gets a "fatal error" IRQ on startup ... only on certain boards,
starting with the 2.6.
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 UHCI.
Alan Stern
--
The dmesg from a kernel 2.6.10 with CONFIG_USB_DEBUG
is bellow:
suspended without any device plugged, resumed, plugged
a device in.
uhci_hcd :00:1d.1: suspend_hc
PM: Preparing system for suspend
ehci_hcd :00:1d.7: --> PCI D3hot
uhci_hcd :00:1d.2: suspend_hc
uhci_hcd :00:1d.2: --> P
Hi Alan,
CONFIG_USB_SUSPEND is not set.
Should I try to set it ?
I thought it is for something else from its attached
help, that's why I left it unset.
Thanks,
Paul
--- Alan Stern <[EMAIL PROTECTED]> wrote:
> Very interesting indeed. This indicates that the
> problem isn't with the
> uhci-hc
Hi Alan,
I just compiled a new kernel with both
CONFIG_USB_SUSPEND and CONFIG_USB_DEBUG, and now it
works if nothing is plugged in USB when I suspend the
machine.
If I have something plugged in at suspend time, after
resume it is not there anymore, and I have to
pull/plug the device again.
I will
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?
---
The SF.Net email is sponsored by: Beat the post-holiday blues
On Wed, 5 Jan 2005, Paul Ionescu wrote:
> Hi Alan,
>
> CONFIG_USB_SUSPEND is not set.
> Should I try to set it ?
> I thought it is for something else from its attached
> help, that's why I left it unset.
No, leaving it unset is fine (and probably best, for the moment). I just
wanted to know w
Am Mittwoch, 5. Januar 2005 22:33 schrieb Alan Stern:
> That looks good to me. And the mouse was still working...?
Yes. To summarize:
EHCI+UHCI: usb totally crashed
EHCI+UHCI+SUSPEND: needs unplug/plug cycle
UHCI only: works
UHCI + SUSPEND: works
In addition, EHCI has an additional strange eff
Am Mittwoch, 5. Januar 2005 15:55 schrieb Alan Stern:
> On Tue, 4 Jan 2005, Oliver Neukum wrote:
>
> > Right on. A kernel without ehci wakes up with a working mouse.
> > Here's the log:
>
> > Do you want it with CONFIG_USB_SUSPEND?
>
> That would be a good thing to try. According to your first
On Wed, 5 Jan 2005, Jason L Tibbitts III wrote:
> Forgive me if this has been discussed recently; I've just joined this
> list but I did search the list archives for about an hour with no
> luck.
>
> I'm trying to bring up a machine with a Gigabyte GA-8TRS350MT
> motherboard which has an ATI RS35
On Wed, 5 Jan 2005, Oliver Neukum wrote:
> Here's the log of UHCI only, CONFIG_USB_SUSPEND enabled:
> Jan 5 21:54:14 macbeth kernel: usb 1-1: RESUME
> Jan 5 21:54:14 macbeth kernel: uhci_hcd :00:1d.0: port 1 portsc 0195,01
> Jan 5 21:54:14 macbeth kernel: usb 1-1: usb resume
> Jan 5 21:54
On Wed, 5 Jan 2005, Paul Ionescu wrote:
> After resume, without any devices plugged:
> HC status
> usbcmd= 0008 Maxp32 EGSM
> usbstat = 0020 HCHalted
> usbint= 000f
> usbfrnum = (0)344
> flbaseadd = 173d8344
> sof = 40
> stat1 = 0080
Hi Alan,
Yes, I completely forgot, but here it is:
before suspend, without any devices plugged:
HC status
usbcmd= 0008 Maxp32 EGSM
usbstat = 0020 HCHalted
usbint= 000f
usbfrnum = (1)278
flbaseadd = 173d8278
sof = 40
stat1 = 0080
On Wednesday 05 January 2005 18:12, David Brownell wrote:
> On Wednesday 05 January 2005 3:58 am, Pedro Venda wrote:
> > David Brownell wrote:
> > | OK, try this slightly modified version. Looks like
> > | the Intel chip sets the HALT bit then spontaneously
> > | clears it, while the ALI may never
Forgive me if this has been discussed recently; I've just joined this
list but I did search the list archives for about an hour with no
luck.
I'm trying to bring up a machine with a Gigabyte GA-8TRS350MT
motherboard which has an ATI RS350 chipset. I didn't think this was
anything really new, but
Hi Stefan,
I tried with and without ehci-hcd loaded.
In fact, right now on kernel 2.6.10, only ehci-hcd is
surviving a suspend resume cycle without rmmod/insmod.
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 5. Januar 2005 17:46 schrieb Paul
> Ionescu:
> > Hi Bjorn,
> >
> > I tr
On Wed, 5 Jan 2005, Paul Ionescu wrote:
> Hi Bjorn,
>
> I tried with "pci=routeirq" but the same behaviour.
> Then I isolate uhci_hcd to be alone on IRQ 9, and I
> can see that after a susp/resume cycle, the irq 9
> count is still incrementing, but lsusb shows no new
> device.
> If I rmmod/insmod
On Wednesday 05 January 2005 3:58 am, Pedro Venda wrote:
> David Brownell wrote:
> |
> | OK, try this slightly modified version. Looks like
> | the Intel chip sets the HALT bit then spontaneously
> | clears it, while the ALI may never set it.
>
> this one has a different output, although I don't
On Wednesday 05 January 2005 6:40 am, Christian Iversen wrote:
> I've been running with this patch for some time now (well, at least 10 days),
> and I haven't had any problems of any kind. USB just seems to work for me
> now. Of course, that could be pure luck, but since David and I looked at
>
On Tuesday 04 January 2005 7:43 pm, Alan Cox wrote:
> This I noticed in the docs: The support is for USB 1.0 not 1.1 OHCI 1.0
> for USB 1.0
All OHCI controllers I've seen are for "OHCI 1.0". :)
The spec I use says "OHCI 1.0a", it's not clear what changed
between the 1.0 and 1.0a versions. Proba
Am Mittwoch, 5. Januar 2005 17:46 schrieb Paul Ionescu:
> Hi Bjorn,
>
> I tried with "pci=routeirq" but the same behaviour.
> Then I isolate uhci_hcd to be alone on IRQ 9, and I
> can see that after a susp/resume cycle, the irq 9
> count is still incrementing, but lsusb shows no new
> device.
> If
Hi Bjorn,
I tried with "pci=routeirq" but the same behaviour.
Then I isolate uhci_hcd to be alone on IRQ 9, and I
can see that after a susp/resume cycle, the irq 9
count is still incrementing, but lsusb shows no new
device.
If I rmmod/insmod the uhci-hcd at this point, it
works.
So I think is not
Greg:
This is a revised patch to fix a problem in the UHCI driver, in which the
compiler incorrectly optimizes certain accesses to DMA-able memory
addresses. The patch reorganizes the code to use special accessor
routines including a compiler optimization barrier, and stores the results
in loca
On Wed, 5 Jan 2005, Andrew Morton wrote:
> Looks like the scsi-vs-usb-storage bunfight isn't yet settled...
>
>
> Begin forwarded message:
>
> Date: Fri, 31 Dec 2004 14:44:44 +1100
> From: Srihari Vijayaraghavan <[EMAIL PROTECTED]>
> To: linux-kernel@vger.kernel.org
> Subject: [BUG] USB Storage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Iversen wrote:
| On Wednesday 05 January 2005 12:58, Pedro Venda wrote:
|
|>David Brownell wrote:
|>| On Tuesday 04 January 2005 4:31 am, Pedro Venda wrote:
|>|>David Brownell wrote:
|>|>| On Monday 03 January 2005 5:05 pm, you wrote:
|>|>|>Da
> There's a more comprehensive fix for this in 2.6, as needed to
> support the more generic driver infrastructure for devices
> ("driver model") that aren't on PCI
OK, that's good to hear. I'm not so familiar with 2.6 but I see that the USB
code has undergone major changes.
> act like PCI. The
Thanks for the replies.
> I am positive about it, but I am not thrilled with extra #ifdef's.
> I need to look closer, maybe it can be abstracted a little bit.
It works but I agree it's a bit ugly.
> Also, a patch to run 2.4 under Xen is not about to be merged anyway, right?
> So, this cannot be
On Tue, 4 Jan 2005, Oliver Neukum wrote:
> Right on. A kernel without ehci wakes up with a working mouse.
> Here's the log:
> Do you want it with CONFIG_USB_SUSPEND?
That would be a good thing to try. According to your first debugging
log, sometime during the suspend/resume procedure the mouse
On Wednesday 05 January 2005 12:58, Pedro Venda wrote:
> David Brownell wrote:
> | On Tuesday 04 January 2005 4:31 am, Pedro Venda wrote:
> |>David Brownell wrote:
> |>| On Monday 03 January 2005 5:05 pm, you wrote:
> |>|>David Brownell wrote:
> |>|>| It's something wierd that started a while back,
Am 2005-01-05 12:31 +0200 schrieb Olav Kongas:
> reset pin, while software reset is achieved by writing to
> proper isp116x registers and should therefore be platform
> independent.
Ok, I agree...
> Until now, I have failed to get the software reset working.
Me also :) But I am at it...
Konsti
On Wed, 2005-01-05 at 00:14 -0800, Andrew Morton wrote:
> Looks like the scsi-vs-usb-storage bunfight isn't yet settled...
Actually, this one looks pretty clear cut:
According to the trace, we get into error handling for a removed device.
This:
> RIP {:usb_storage:bus_reset+66} RSP <01002f9a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Brownell wrote:
| On Tuesday 04 January 2005 4:31 am, Pedro Venda wrote:
|
|>David Brownell wrote:
|>| On Monday 03 January 2005 5:05 pm, you wrote:
|>|
|>|>David Brownell wrote:
|>|>| It's something wierd that started a while back, and so far
|>|
> At first I am going to implement a small software Reset Routine
> between the /* */ in my platform setup.
> I hope a software Reset is as good as a Hardware Reset there.
I propose that we use terminology as it is in the isp116x
datasheets: hardware reset means asserting the isp116x's
reset pin,
Am 2005-01-04 22:24 +0200 schrieb Olav Kongas:
> enabled. Therefore, soon after umplugging you shouldn't see
> interrupts as all the submitted urbs should be dequeued.
Ok. I really didn't know for sure. Good point.
> These printouts look ok.
For me too. No really weird things to see.
But these
This should be self-evident. Patch by Rogier Wolff.
diff -urp -X dontdiff linux-2.4.29-pre3/drivers/usb/serial/ftdi_sio.c
linux-2.4.29-pre3-sx3/drivers/usb/serial/ftdi_sio.c
--- linux-2.4.29-pre3/drivers/usb/serial/ftdi_sio.c 2004-08-10
13:43:36.0 -0700
+++ linux-2.4.29-pre3-sx3/driv
Looks like the scsi-vs-usb-storage bunfight isn't yet settled...
Begin forwarded message:
Date: Fri, 31 Dec 2004 14:44:44 +1100
From: Srihari Vijayaraghavan <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Subject: [BUG] USB Storage OOPS and a D state process in 2.6.10
Can easily reproduc
49 matches
Mail list logo
