'll run extended tests to verify that this is indeed sufficient. If so,
the delay could still be bumped up to 7 frames to be safe without any
additional performance hit.
Mike
-
This SF.net email is sponsored by: Splunk Inc.
red.
Either way, this patch in its current form isn't safe.
Mike
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files
Alan Stern wrote:
> On Fri, 6 Jul 2007, Mike Nuss wrote:
>
>>> If all else fails and you can't get timely interrupts, you can always
>>> fall back on a kernel timer. Scan through the data structures once a
>>> second or thereabouts. As an optimization,
David Brownell wrote:
> On Thursday 05 July 2007, Mike Nuss wrote:
>> I'm at a loss. It really looks like the HC just "skipped" a step for no
>> reason.
>
> I forget ... did you already try removing that special case
> at the top of the IRQ handler, wh
Alan Stern wrote:
> On Fri, 6 Jul 2007, Mike Nuss wrote:
>
>> On the hardware side though, DI relates to how many frames the HC will
>> wait until HccaDoneHead will be updated, and the WDH IRQ isn't sent
>> until that happens. But since the TD never gets properly r
Alan Stern wrote:
> On Fri, 6 Jul 2007, Mike Nuss wrote:
>
>>> Here's what I meant. Normally SOF interrupts are disabled, but when
>>> the driver gets a completion interrupt for an URB it could turn on the
>>> SOF interrupt for the next frame only. Then w
Alan Stern wrote:
> On Thu, 5 Jul 2007, Mike Nuss wrote:
> > There are three time periods in question.
> >
> > A = before there is any problem
> >
> > B = a read seems to have completed, the HC has advanced HeadP, but
> > failed to put the completed TD on the
nal event that's causing it to behave erratically.
If it does turn out to be a problem with their silicon, we'll notify ZF
of the problem. I'll move my fix completely down into the OHCI driver
space, assuming we can decide on a reasonable place to do the check. It
can be de
Mike Nuss wrote:
> David Brownell wrote:
>> Hmm. Here's a theory. The way that the current code unlinks
>> an ED is to set the SKIP bit *AND* remove the ED from the relevant
>> part of the schedule.
>>
>> Maybe ... the hardware gets confused when the ED does
D from the schedule. But that
doesn't necessarily reflect all real world situations ;) And since the
TD queue never builds up, it doesn't seem like the type of use the spec
was expecting.
The ED (de)scheduling code is completely unknown to me at this point.
I'll get familiar with it.
Mike
David Brownell wrote:
> On Wednesday 02 May 2007, Mike Nuss wrote:
>
> It's possible that the SKIP bit isn't handled correctly.
>
> I've not looked at that code in some time, but I seem to
> recall thinking that setting SKIP was an action more in
> the &q
Alan Stern wrote:
>
> On Fri, 4 May 2007, Mike Nuss wrote:
>
> > Further support (I dumped the 'dummy' td before freeing it). This is a
> > new trace so the addresses won't match the last trace.
> >
> > kernel: ohci_hcd :00:13.0: leak ed c3e8e
t this
operation to be atomic. What happens if the HC is updating headP during
this block? I would think the driver could potentially overwrite it with
the old value.
Mike
-
This SF.net email is sponsored by DB2 Express
d. But by the time it's obvious
there's a problem, it's too late for that.
I guess one experiment would be to reenqueue the TD after this happens.
That would indicate whether the controller 'missed' the TD or whether
the endpoint is really hung.
Mike
--
td c3e8d8c0; urb index
0; hw next td 03e8d8c0
ohci_hcd :00:13.0: info CC=0 (CARRY) DI=0 SETUP
ohci_hcd :00:13.0: cbp be (len 0)
ohci_hcd :00:13.0: free ed->dummy: td c3e8d8c0
ed->dummy has a non-
> To enqueue a new TD, the HCD fills the old dummy TD and appends a new
TD
> to the end of the list. It should then update TailP. It *looks* like
the
> HCD appended a TD to the queue next but didn't update ed->dummy or
> TailP.
(scratch the word "next" from the last sentence.)
---
the HCD
has added anything to the queue.
To enqueue a new TD, the HCD fills the old dummy TD and appends a new TD
to the end of the list. It should then update TailP. It *looks* like the
HCD appended a TD to the queue next but didn't update ed->dummy or
TailP.
Does that make any sense?
M
Mike Nuss wrote:
> David Brownell wrote:
>> So, trying for some (bad) ASCII art here
>>
>> TDs 1-4 submitted to ED,
>> HC completed a few (say, 1 & 2)
>>
>> ed.tail ---+
>> ed.head --
inks:skip ed
user.err kernel: ohci_hcd :00:13.0: leak ed c2b8f140 (#82) state 0
(has tds)
user.err kernel: ohci_hcd :00:13.0: free td c2daa440
Mike
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C -
rupt
> deferral mechanism (TD_DI_SET) affects this. Try disabling it;
> the difference _should_ be only a significant (up to 6x) increase
> in the number of IRQs you get.
I tried this and it made no difference that I could see. It still failed
after a few hours.
Mike
And the results are... ?
finish_unlinks is getting called in the 'sanitize' path of
ohci_endpoint_disable(). The test "if (td->td-dma != head)" passes, and
it jumps to the skip_ed path.
Is there anything in particular in /sys/cl
On Friday 27 April 2007, David Brownell wrote:
> On Friday 27 April 2007, Mike Nuss wrote:
> > Sometimes upon removing one of our devices (for which we have a
custom
> USB driver), OHCI fails
> > to free all the associated resources with the device. The problem is
> always as
't know what
the issue was that led to the creation of the quirk, but it seems like
it's in the same ballpark.
I think it's pretty clear there's an underlying hardware issue, but
maybe there is a workaround. I added the additional debug code you
suggested to get a better idea of wha
ays
> hangs while disabling the read endpoint. I added a few lines of debug code
> to ohci-hcd.c and hcd.c to try to figure out what's going on, and traced
> it to the usb_kill_urb on line 1386 of hcd.c.
I forgot to mention that this is on the 2.6.20.6 kernel
returns. What would cause that to happen? It
seems like that this point, we know the device is long gone, so there should be
some way to force the issue.
When this occurs the only solution I've found is to reboot, as the ohci module
can't be unloaded while it's in
as there is a clean interface to it (via
libusb or whatever) and I can address devices geographically (the app I
work on has the hardware connected to fixed ports on the hubs so
geographical addressing is useful for what I am doing).
Mike
--
still done through proc? Is the project looking for
any maintainers? Not that I could be one or anything, just wondering.
Thanks,
Mike Panetta.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net&#
on number to be bumped up (Neil: Why aren't you listed as a
maintainer?) then it's not my place to debate it. I may have my opinion
but it's not my driver. Greg KH, as a shepherd for all this might feel
differently however...
-Mike
--
Bill Marr <[EMAIL PROTECTED]>
>
> On Wednesday 28 March 2007 12:21am, Mike Isely wrote:
> > Bill Marr <[EMAIL PROTECTED]> wrote:
[...]
> > It's a DeLorme Earthmate GPS; no "LT-20" however.
>
> Ah, OK... good. I didn't realize they h
he driver was essentially useless for me, before those patches. I
could get some life out of the hardware, but usually within a few
seconds to a minute the device would lock up and the driver would go
insane.
In a much older kernel (2.6.10 IIRC) with an older cypress_m8 driver,
it actually worked _be
On Mon, 26 Mar 2007, Marr wrote:
> Greetings,
>
> *** Please CC: me on replies -- I'm not subscribed.
>
> A patch by Mike Isely that went into what became kernel 2.6.19 has modified
> 'cypress_m8.c' in such a way that it makes the DeLorme Earthmate LT-20
--- /usr/share/hwdata/usb.ids 2007-02-28 10:31:51.0 -0800
***
*** 1195,1224
--- 1195,1225
050a Cinch Connectors
050b Cable System International
050c InnoMedia, Inc.
050d Belkin Components
0103 F5U103 Serial Adapter [etek]
0108 F1DE108B
I have been working on a usb kernel driver for the frontier designs "tranzport"
control surface. It's a pretty unique device - 20 character LCD, 7 lights, 21
buttons, and a shuttle wheel.
Anyway, as I have something that more or less works better than the current
ardour2 libusb driver...
and as
--- usb.ids 2007-02-02 09:23:20.0 -0800
***
*** 388,393
--- 388,394
0005 Type 6 Keyboard
0100 3-button Mouse
0431 Itac Systems, Inc.
+ 0100 Mouse-Trak 3-button Track Ball
0432 Unisys Corp.
0433 Alps Electric, Inc.
1101 I
cept for asm-parisc/statfs.h ... but i'll do that
shortly once i finish pulling the parisc git tree
-mike
pgpOg33BCvRAd.pgp
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge
the trivial attached patch fixes ioctl defines in usbdevice_fs.h that are
exported to userspace to use __u32 rather than u32
-mike
pgpWnQycdrPqW.pgp
Description: PGP signature
Use __u32 rather than u32 in userspace ioctl defines.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
--- a/i
>
> Am Donnerstag, 4. Januar 2007 17:39 schrieb Mike King:
> > CLASS_SPECIFIC CMD (secret command) value=0, index=1, length=0
> > SET_CONFIGURATION config value = 1,index=0,length=0
> > reset
> > reset
> > reset
> >
>
> On Thu, 4 Jan 2007, Mike King wrote:
>
> > Alan,
> >
> > >
> > > On Thu, 4 Jan 2007, Mike King wrote:
> > >
> > > > > > > > Anytime a SET_CONFIGURATION is sent to the device without being
> > > > > &
Alan,
>
> On Thu, 4 Jan 2007, Mike King wrote:
>
> > > > > > Anytime a SET_CONFIGURATION is sent to the device without being
> > > > > > preceeded
> > > > > > by the secret vendor specific command the device reverts to the
>
>
> Am Donnerstag, 4. Januar 2007 07:30 schrieb Mike King:
> > Let me repeat this. Upon seeing the secret command, the next call to
> > a SET_CONFIGURATION will cause the BB to reset itself and actually change
> > the device descriptor from indicating it uses the
>
> Am Donnerstag, 4. Januar 2007 08:25 schrieb Mike King:
> > >
> > > Am Donnerstag, 4. Januar 2007 07:58 schrieb Mike King:
> > > > >
> > > > > Am Donnerstag, 4. Januar 2007 07:30 schrieb Mike King:
> > > > &
>
> Am Donnerstag, 4. Januar 2007 07:58 schrieb Mike King:
> > >
> > > Am Donnerstag, 4. Januar 2007 07:30 schrieb Mike King:
> > > > Anytime a SET_CONFIGURATION is sent to the device without being
> > > > preceeded
> > > > by
>
> Am Donnerstag, 4. Januar 2007 07:30 schrieb Mike King:
> > Anytime a SET_CONFIGURATION is sent to the device without being preceeded
> > by the secret vendor specific command the device reverts to the previous
> > device descriptor data indicating 100ma. A normal
ception of assigning the device address.
What I need is to bind the driver to a device and not an interface and
have USB core do nothing more than assign the device address.
Suggestions ? Comments ?
Thanks,
Mike King
Hewlett-Packard
USB Gurus,
Are endpoint addresses unique across a device ?
In other words, can a device with 2 interfaces have an endpoint in
each interface that is address 0x81. Or would they have to be distinct,
like 0x81 in one and 0x82 in the other one ?
Thanks,
Mike King
Hewlett-Packard
sparsity of information, but any ideas would be
helpful.
Thanks,
Mike
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on
chip changes, so that maintenance issue
should be moot. It would be like saying that someone needs to maintain
the man page describing the syscall interface to the kernel, an
interface that has not changed in years, maybe even since the linux
kernel
Alan Stern wrote:
> On Mon, 2 Oct 2006, Mike Panetta wrote:
>
> > I have written a patch based on the companion patch that will allow me
> > to disable arbitrary ports on my EHCI root hubs for a product we are
> > working on (The system has a very naughty built on compa
USB devices are pretty much
hardwired and always exist, so there is only one plug event at boot time.
Thanks,
Mike
--- kernel-2.6.16.19/linux-2.6.16.19/drivers/usb/host/ehci-hcd.c
2006-09-26 15:53:34.0 -0400
+++ kernel-2.6.16.19-mike/linux-2.6.16.19/drivers/usb/host/ehci-hcd.c
From: Mike Isely <[EMAIL PROTECTED]>
Fix usb core function error return checks to look for negative errno
values, not positive errno values. This bug had rendered those checks
useless. Also remove attempted error recovery on control endpoints
for EPIPE - with control endpoints EPIPE do
From: Mike Isely <[EMAIL PROTECTED]>
When receiving a fatal error from the USB core, e.g. EILSEQ (which can
happen if the polling interval is too short), fail gracefully.
Previously the driver would fill the log with useless error messages
or (more alarmingly) silently spin forever try
From: Mike Isely <[EMAIL PROTECTED]>
Rather than directly filling in URB fields, it's safer to use
usb_fill_int_urb(). This improves robustness of the driver; URB
changes in the future will not go uninitialized here. That point not
withstanding, this driver should at least be self
From: Mike Isely <[EMAIL PROTECTED]>
The polling interval for the device can't always be 1msec. If it is
too quick, the device can fail causing a fatal (to the driver) EILSEQ
error from the USB core. The actual correct value is reported by the
device as part of its configuration d
On Mon, 28 Aug 2006, Greg KH wrote:
> On Sat, Aug 26, 2006 at 01:13:06PM -0500, Mike Isely wrote:
>> diff -uprN -X linux-2.6.18-rc4/Documentation/dontdiff
>> linux-2.6.18-rc4/drivers/usb/serial/cypress_m8.c
>> p1/drivers/usb/serial/cypress_m8.c
>> --- linux-2.
From: Mike Isely <[EMAIL PROTECTED]>
When receiving a fatal error from the USB core, e.g. EILSEQ (which can
happen if the polling interval is too short), fail gracefully.
Previously the driver would fill the log with useless error messages
or (more alarmingly) silently spin forever try
From: Mike Isely <[EMAIL PROTECTED]>
The polling interval for the device can't always be 1msec. If it is
too quick, the device can fail causing a fatal (to the driver) EILSEQ
error from the USB core. The actual correct value is reported by the
device as part of its configuration d
From: Mike Isely <[EMAIL PROTECTED]>
Rather than directly filling in URB fields, it's safer to use
usb_fill_int_urb(). This improves robustness of the driver; URB
changes in the future will not go uninitialized here. That point not
withstanding, this driver should at least be self
From: Mike Isely <[EMAIL PROTECTED]>
Fix usb core function error return checks to look for negative errno
values, not positive errno values. This bug had rendered those checks
useless. Also remove attempted error recovery on control endpoints
for EPIPE - with control endpoints EPIPE do
On Fri, 25 Aug 2006, Greg KH wrote:
> On Wed, Aug 16, 2006 at 11:17:10PM -0500, Mike Isely wrote:
>> From: Mike Isely <[EMAIL PROTECTED]>
>>
>> ---
>>
>> This patch set is baselined against vanilla kernel 2.6.17.6.
>
> Can you resend this whole patch
On Thu, 17 Aug 2006, Lonnie Mendez wrote:
> On Wed, 2006-08-16 at 23:17 -0500, Mike Isely wrote:
>> From: Mike Isely <[EMAIL PROTECTED]>
>>
>> When receiving a fatal error from the USB core, e.g. EILSEQ (which can
>> happen if the polling interval is too short), f
on there's still no cost in code size or performance,
and the presence of the value becomes a hint to the developer that the
initial value is important. I would not have made this change purely for
the sake of making it, but it was just an unconscious part of the la
From: Mike Isely <[EMAIL PROTECTED]>
When receiving a fatal error from the USB core, e.g. EILSEQ (which can
happen if the polling interval is too short), fail gracefully.
Previously the driver would fill the log with useless error messages
or (more alarmingly) silently spin forever try
From: Mike Isely <[EMAIL PROTECTED]>
Fix usb core function error return checks to look for negative errno
values, not positive errno values. This bug had rendered those checks
useless. Also remove attempted error recovery on control endpoints
for EPIPE - with control endpoints EPIPE do
From: Mike Isely <[EMAIL PROTECTED]>
Rather than directly filling in URB fields, it's safer to use
usb_fill_int_urb(). This improves robustness of the driver; URB
changes in the future will not go uninitialized here. That point not
withstanding, this driver should at least be self
From: Mike Isely <[EMAIL PROTECTED]>
The polling interval for the device can't always be 1msec. If it is
too quick, the device can fail causing a fatal (to the driver) EILSEQ
error from the USB core. The actual correct value is reported by the
device as part of its configuration d
Thank you very much for the pointers. Hopefully they will help me shed
some light on things. I am also hopefully getting a USB bus analyzer to
do some snooping for me. If I have any more questions expect to see
them here. :)
Thanks again,
Mike
Greg KH wrote:
On Fri, May 19, 2006 at 12:20
ey didnt seem to help much.
/*
* USB FX2 Converter driver, based on the USB Keyspan PDA
* Xircom / Entregra Converter driver.
*
* Copyright (C) 2006 - 2006 Mike Panetta <[EMAIL PROTECTED]>
* Copyright (C) 1999 - 2001 Greg Kroah-Hartman <[EMAIL PROTECTED]>
* Copyright (C) 1999,
Was that just a coincidence or is it really
working better for you now?
-Mike
--
| Mike Isely | PGP fingerprint
Spammers Die!! | | 03 54 43 4D 75 E5 CC 92
| isely @ pobox (dot) c
rd or of the
via patch I got from Alan. It's not clear now.
Maybe Mike can help?
Any chance you can attach a separate USB controller to your system and
test with that?
-Mike
--
| Mike Isely | PGP fingerprint
Spammers Di
expected,
my driver is unbound on the write of bConfigurationValue and probe is not
called again.
-Mike
>
> On Tue, 1 Nov 2005, Mike King wrote:
>
> > Alan,
> >
> > Nothing was resolved on this failure. I haven't been able to try it
> > on 2.6.14 becaus
program and WinXP kernel driver supplied by the vendor. I use both the
snoopy filter driver on WinXP as well as a Finisar USB Bus Analyzer and the
device appears to work correctly. So, it looks like a case of multi
configuration devices not working properly on 2.6.9.
-Mike
>
> On Tu
erent states.
You will see in Step 5 that there is a uhci failure. Again, this is 2.6.9.
I will try moving to a newer kernel now.
-Mike
= CUT HERE
==
Step 1: Just after
>
> Am Dienstag, 25. Oktober 2005 22:01 schrieb Mike King:
> > Oliver,
> >
> > > Hi,
> > >
> > > could you post the decoded version? Are you sure your driver's tables
> > > match the second configuration's interface?
> > >
does match the second config. Actually, my driver currently matches any
USB device plugged in.
-Mike
=== usbview ===
Fingerprint Sensor
Speed: 12Mb/s (full)
USB Version: 1.10
Device Class: ff(vend.)
Device Subclass: ff
Device Protocol: ff
Max
Oliver,
>
> Am Dienstag, 25. Oktober 2005 20:22 schrieb Mike King:
> > Usb Gurus,
> >
> > I am working on a biometric device (fingerprint reader) for Linux. This
> > device has 2 configs and I need to use the 2nd config. On initial connect
> > to the syst
nning 2.6.9.
Any clues what is happening ? Any ideas on how I can select config #2.
Thanks in advance,
Mike
---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certificatio
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-09-15 at 15:19 -0700, Mike Anderson wrote:
> > A side effect of not applying Alan's previous patch that added
> > SHOST_RECOVERY to the SHOST_CANCEL: state is that we will not move to the
> > SHOST_CANCEL a
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-09-15 at 15:57 -0400, James Bottomley wrote:
> > I haven't had time to review the eh changes, but I was going to reply to
> > the other one (basically there's a better way to try to close the device
> > add/host remove race using the host st
Dear Torsten
>
> Hi Mike,
>
> I'm using an i.MX controller too and I'm testing your imx_udc driver.
> The controller is an i.MXL @200MHz.
It is the same with my platform.
>
> Patching the kernel (2.6.10-rc2), compiling and loading the driver
> works fine. I&
fstab, Do i need
any other setting?
best regard
Mike,Lee
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id
David Brownell wrote:
>On Friday 06 May 2005 9:15 pm, mike lee wrote:
>
>
>>David Brownell wrote:
>>
>>
>>>>On Wednesday 04 May 2005 7:34 pm, mike lee wrote:
>>>>
>>>>
>>>>
>>>
David Brownell wrote:
>>On Wednesday 04 May 2005 7:34 pm, mike lee wrote:
>>
>>
>
>
>>>>Hi all
>>>>I just finish my draft version gadget controller driver on imx
>>>>platform,
>>>>
>>>>
>>
Hi all
I just finish my draft version gadget controller driver on imx
platform, but how can i benefit from the hotplug function provided from
kernel? Do i need to provide the hotplug function in my driver, and
example for hotplugging gadget?
Thanks for any help
best regard
Mike Lee
3, error -32
<6>usb 3-2: new full speed USB device using uhci_hcd and address 54
<3>usb 3-2: device descriptor read/64, error -32
<3>usb 3-2: can't set config #3, error -32
<3>usb 3-2: can't set config #3, error -32
<
200.
>
for example zero.c, it use bcdUSB 0x200 but if you do not set
GADGET_DUALSPEED. it will not include the device_qualifier, this will
mislead the host to ask for a descriptor which the device do not know
and result in a protocol stall.
change all the gadget driver bcdUSB to
0x110 to make the host stop asking for any USB2.0 request. Is there
any better method to do that?
Would gadget driver queue any data when there is no OUT/IN from host?
Thanks for any help
best regard
Mike,Lee
ake a wrong start. Could any body give me some info on this? and how to
get start on controller driver?
Thanks for helping
best regard
Mike,Lee
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundr
Alan Stern [EMAIL PROTECTED] wrote:
> And Mike Anderson's response was
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=110538854224319&w=2
>
> His explanation was "Currently scsi_host_cancel being called from
> scsi_remove_host appears to not do anythi
ut spent a
fair amount of time searching the web for the solution
before I posted this request.
Thanks,
Mike
***
dmesg output
ohci_hcd :00:05.0: NEC Corporation USB
ohci_hcd :00:05.0: irq 29, pci mem 0x49004000
kobject usb2: registeri
Petko Manolov wrote:
Definitly a good idea to set that - although nothing in the driver
accesses it :-)
Well, not directly. However, pegasus_get/set_settings() is doing so
through mii_ethtool_gset() for example. Look at drivers/net/mii.c;
ahh, it all makes sense now :)
and yes, the original s
Petko Manolov wrote:
On Thu, 13 Jan 2005, Mike Nix wrote:
I tested this by calling it from enable_net_traffic so that carrier was
checked whenever the interface was configured "up" - I then ran
"ifconfig eth2 down;ifconfig eth2 up" inserting / removing the cable
betwee
Alan Stern [EMAIL PROTECTED] wrote:
> Jan 10 20:49:08 desktop kernel: scsi113 : SCSI emulation for USB Mass Storage
> devices
> Jan 10 20:49:08 desktop kernel: usb-storage: device found at 113
> Jan 10 20:49:08 desktop kernel: usb-storage: waiting for device to settle
> before scanning
> Jan 10
Dear All
Which doc should i read to port usb gadget to new MCU? where can i
set the register on the driver?
Or anyone try on MC9328MXL?
Best Regard
Mike,Lee
---
This Newsletter Sponsored by: Macrovision
For reliable Linux application
mike wrote:
Fillod Stephane wrote:
My situation is , to make my ARM-based board to be a USB mass
storage disk from outside view. I am using Motorola M9328MXL
development board with USB client.
So your board is going to be an USB peripheral, right?
My question is how can i utilize mtd
2.6.X? which folders are needed? driver/usb/gadget/* and
include/linux/usb_*?
I look follow the gadget and don;t see any usb driver on M9328MXL ,
Do i need to code a new driver for gadget?
Thanks very much
Mike,Lee
---
This Newsletter
.X?
which folders are needed? driver/usb/gadget/* and include/linux/usb_*?
I look follow the gadget and don;t see any usb driver on M9328MXL ,
Do i need to code a new driver for gadget?
Thanks very much
Mike,Lee
---
This Newsletter
Mike Christie wrote:
James Bottomley wrote:
On Tue, 2004-10-26 at 14:08, Mike Christie wrote:
The null state and and oops are becuase of this
http://marc.theaimsgroup.com/?l=linux-scsi&m=109733573729283&w=2
Oh yeah. that patch is not correct, but if you correctly modify i
James Bottomley wrote:
On Tue, 2004-10-26 at 14:08, Mike Christie wrote:
The null state and and oops are becuase of this
http://marc.theaimsgroup.com/?l=linux-scsi&m=109733573729283&w=2
Oh yeah. that patch is not correct, but if you correctly modify it to
use device_for_each_child per Chr
Mike Christie wrote:
[EMAIL PROTECTED] wrote:
On Thu, 21 Oct 2004, Alan Stern wrote:
On Thu, 21 Oct 2004 [EMAIL PROTECTED] wrote:
After successful write on USB DVD-R writer (HP-200j), system
oops's when unpluging USB device.
Same thing with 2.6.9-rc2mm1.
Try applying this patch:
[EMAIL PROTECTED] wrote:
On Thu, 21 Oct 2004, Alan Stern wrote:
On Thu, 21 Oct 2004 [EMAIL PROTECTED] wrote:
After successful write on USB DVD-R writer (HP-200j), system oops's when unpluging USB
device.
Same thing with 2.6.9-rc2mm1.
Try applying this patch:
http://marc.theaimsgroup.com/?l=linux
1 - 100 of 146 matches
Mail list logo
