Could you please tell me if there's a solution or if i could do more
tests to let someone make a new patch ? :)
Try the patches in these posts on the VIA EHCI thread:
- usb-storage patch from Alan Stern
http://marc.theaimsgroup.com/?l=linux-usb-develm=104528462604039w=2
- QH state
Greg KH wrote:
Yes, this is a problem, the module can be unloaded and then the
completion fuction can be called.
How? I don't see it. Unless the driver completely violates
basic rules like implementing disconnect() correctly, which
will break more than just module unloading.
I'm trying
Charles Lepple wrote:
While writing USB firmware for the PIC16C765, I noticed that lsusb can't
read the string descriptors from even the stock Microchip firmware. This
seems to be limited to lsusb, as the strings show up in
/proc/bus/usb/devices and in the HID driver's initialization message.
I'm trying to fix up the usb device reference counting
logic right now and running into issues where host controllers try to
access urbs after their devices have been removed from the system :(
Not supposed to happen ... when they call giveback(), that's supposed to
mean they've forgotten about
In 2.4, uhci.c holds a reference to the device until after it's done
calling the completion handler.
Now in 2.5, the hcd layer doesn't hold that reference anymore it seems.
That should be fixed.
Seems like a UHCI-specific expectation, so it's UHCI that should
be adding the extra reference
(Gary, your system clock is set well into the future; UTC?)
Gary A. Gorgen wrote:
David Brownell wrote:
Thanks for the info about what 2.5.61 shows ... seems more polite.
It doesn't seem to be giving you Unrecoverable Error (UE) failures,
unlike the 2.4 usb-ohci code. (At least, not without
This patch resolves a modprobe issue in some configurations.
By all rights drivers/usb/class/Makefile.lib is in the wrong
directory (class not net), but moving files is better (IMO)
with BK magic. Changing that would also involve lib/Makefile too.
Please merge to Linus' tree.
- Dave
diff -Nru
-dbg.c Tue Feb 18 17:35:33 2003
@@ -5,7 +5,6 @@
* (C) Copyright 2000-2002 David Brownell [EMAIL PROTECTED]
*
* This file is licenced under the GPL.
- * $Id: ohci-dbg.c,v 1.4 2002/03/27 20:40:40 dbrownell Exp
This is the rest of the work to make the driver not care which
version of the OS it's using, so the difference between the 2.5
and 2.5 versions can just be a small patch with stuff that has
a real need to be different.
Please merge to Linus' latest.
- Dave
[EMAIL PROTECTED], 2003-02-18
Hi,
...
They don't make that assumption (don't reference devices that way),
so they don't need to. So that change should be UHCI-specific.
You said that they rely on having a valid device pointer. They must do
reference counting then.
They never make a copy of urb-dev ... so they relying
This gets rid of some potentially scarey messages I've recently
seen on disconnect, bad hash for a TD ... it's really a no hash
case, and this prevents the message in some cases where that's
not an issue. Likely this is what Gary Gorgen noticed, but even
he had a different problem, this message
but the hcd drivers should have already canceled them, right? Hm, but
Nope, the only way an hcd can know the device is gone is by
calling the misnamed bus-op-deallocate() routine. And
because of the mess stemming from that misnaming, that code
path doesn't even try to do that any more.
Greg KH wrote:
On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
Greg KH wrote:
Hm, maybe we should mark the device gone at the beginning of this call,
or right at the time we realize it's gone in the hub driver. That would
keep drivers from submitting urbs from within
But what about drivers that fire off urbs and don't keep a pointer to
them around? They don't know if all of their urbs are completed or not,
nor should they really care. The visor driver is one good example of
this.
It would certainly simplify things if that (b) change I mentioned
were to
This makes test 10 verify that completions are returned in-order,
resolving a FIXME. OHCI and EHCI do, but UHCI doesn't. (*) That
simplified a cleanup of the queue fault tests to make it easier
to handle optional faults (with one or more failure modes).
It also returns a lost subcase that
Greg KH wrote:
On Wed, Feb 19, 2003 at 05:08:14PM -0800, David Brownell wrote:
But what about drivers that fire off urbs and don't keep a pointer to
them around? They don't know if all of their urbs are completed or not,
nor should they really care. The visor driver is one good example
Oliver Neukum wrote:
For (b) there are several options. Today we expect (b1) device
driver handles all in disconnect(), except that to guard against
bugs there sometimes (b2) HCD may need to get involved. I'd
think a cleaner solution would be (b3) usbcore kills them all;
less work for device
Oliver Neukum wrote:
But we don't really _have_ to keep track of all of them, right? And it
Someone needs to, but it doesn't need to be the device driver. The
current approach has hcd.c do it, part of usbcore.
A part that doesn't need to be used. It's a little late to break all the
little
A per-device list is sufficient, and a lot cheaper to maintain.
Doing it per-interface would add work to the submit path that's
hardly ever needed ... better to have that work delayed until
it's actually needed.
Then how to implement usb_reset_device() ?
In some straightforward manner.
Hi,
I'd like to start playing with this, can you send out some patches that
I can add to my local tree? Or I guess I can pull them from your bk
tree, if you don't mind.
I'll circulate patches a bit later, after I merge some updates to make
that loopback configuration actually do work. That
Greg KH wrote:
On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
The philosophy is often called programming by contract.
And the contract is: usbcore agrees to work with your driver
and do everything right, if your driver agrees to do a few
specific things. One of those specific
This is fundamentally the problem. Your vision of how stuff is supposed
to work in the USB code is solely your vision and doesn't match what was
intended when I wrote the code or what the majority of the code does.
You can keep thinking whatever you want, but it ain't reality.
ERm, person 1's
Back to the patch I've attached. It's against 2.4.19-pre3 (I'll update
to Greg's CVS tree) and hasn't had the level of testing necessary to
call it good. I also want to recheck that I caught all of the necessary
paths.
Seems like the main change there is that after disconnect, EDs
get cleaned up
Oliver Neukum wrote:
Under some circumstances, most obviously the disconnect ioctl,
we need to disconnect only one of the interfaces of a device.
How are we to do that if we queue by device only?
Are there or are there not both (a) a set of URBs to check,
and (b) records of the current
A better way to say it may be: if that's not what disconnect()
means, than what the heck _does_ it mean? There are a whole LOT
of answers in current use. Clearly the idea is to prohibit some
kinds of behavior. Which ones? And why _not_ all of them?
It means that the device is physically gone,
[ re your potential usb-ohci/2.4 patch ]
It won't leak EDs on power management. The cleanup will just be deferred
until power comes back on. Big deal.
Not on the D3cold resume path -- that can't be deferred.
I haven't looked at the PM paths yet, but if the D3cold path is via
normal PCI exit
Gary A. Gorgen wrote:
Does this provide any clues ?
I'm still suspecting it's a combination of (a) device bugs,
causing the timeouts, (b) usb-ohci bugs, fixed in ohci-hcd,
making those oopses.
- Dave
---
This SF.net email is sponsored by:
Why should drivers use usb_get_dev in probe, and usb_put_dev in disconnect?
No reason. A reference is already done by the core which covers the
reference for that whole period of time.
A reference which is no longer valid after disconnect() ...
Hmm, that sounds like that other thread... a
I just want to point out that from a pragmatic perspective, those
changes (bug fixes if you insist) won't break drivers that have
already been adhering to the stricter contract I described.
Yes and no.
The OHCI fix I sent was necessary even with your stricter contract.
And how could that
Controller Driver) for USB.
- *
+ *
* (C) Copyright 1999 Roman Weissgaerber [EMAIL PROTECTED]
* (C) Copyright 2000-2002 David Brownell [EMAIL PROTECTED]
- *
+ *
* This file is licenced under the GPL
@@ -701,12 +701,6 @@
* usb_get_dev - increments the reference count of the usb device structure
* @dev: the device being referenced
*
- * Each live reference to a device should be refcounted.
- *
- * Drivers for USB interfaces should normally record such references in
- * their probe() methods,
This patch resolves a FIXME, which happens to make many of
the VIA problems act significantly less severe. The change
defers unlinking any QH that just became idle, since it's not
unlikely it'll be used again before many milliseconds pass.
It reduces the number of unlink interrupts (IAA), and
Looks to me like this 2.5.62+ kernel doesn't yet behave sanely
during a hot unplug in usb ... did those scsi changes get into
the 2.5.63 kernel?
- Dave
OOPS after powering off a usb2 disk
disk was looping 'hdparm -tT /dev/sda1'
USB core/hcd shutdown seems just fine.
Greg KH wrote:
On Tue, Feb 25, 2003 at 08:42:10AM +0100, Duncan Sands wrote:
The other way is to follow Dave's contract.
Heh, or we could make lives easier for driver writers by not requiring
such a complicated contract that almost none of the current drivers
follow :)
Actually, I'd say it's
Yes, a configuration change is:
1. Lock device
2. Disconnect all interfaces
3. Send control message
4. Unlock device
5. Probe all the device's interfaces
To a driver changing a configuration is an unplug, replug cycle.
Make that probe()/disconnect() ... :)
Something I want (eventually) to see
Peter Schildmann wrote:
recently I brought a ST5481 based ISDN terminal adapter (Typhoon 50456)
that works with the st5481_hisax driver.
Sometimes I get errors like these:
Feb 22 01:33:58 verdi kernel: st5481_b.c: usb_b_out: usb_submit_urb failed,status=-22
Feb 22 01:33:58 verdi kernel:
Greg KH wrote:
On Wed, Feb 26, 2003 at 10:37:30PM +0100, Henning Meier-Geinitz wrote:
Unable to handle kernel NULL pointer dereference at virtual address
...
Call Trace:
[c01e2c10] ohci_irq+0x130/0x1d8
David, any clues?
Only that (as Henning noted) something about your patch caused
Something I want (eventually) to see between steps 2 4 is
notifying the hcd to clear each endpoint's configuration data.
That state is known to hardware (OHCI and EHCI) so changing it
needs hardware synchronization.
Interesting. Could you point me at the code in question?
The 2.4 OHCI code has
The crash doesn't happen if I move back the irq unlink from
destroy_scanner to disconnect_scanner:
Which points at the ohci driver not allowing usb_unlink_urb() to be
called after the device is disconnected. David, is this true?
Certainly. disconnect() is in charge of doing such unlinks.
-
Which points at the ohci driver not allowing usb_unlink_urb() to be
called after the device is disconnected. David, is this true?
Certainly. disconnect() is in charge of doing such unlinks.
But we shouldn't oops if unlink() is called after disconnect(), right?
Just to make this more clear:
Hi,
This patch merges the USB state definitions from the ARM Linux
code (inside the sa1100 driver) and uses them to track what can
be done with the device. That replaces the recently added
udev-present flag with a more complete/standard state model.
There are a few changes that might affect
Oopsing is undesirable, true, but is one of the consequences of
not implementing disconnect() right. And it has the advantage
of not facilitating the subtle falure modes coming from components
having different notions of device (or interface) state.
The the host controller driver should be
This exhibits a build error when OHCI_VERBOSE_DEBUG is enabled:
Odd, I guess the build I tested was when that was enabled
without first enabling debugging. The fix is trivial.
(Greg, please merge.)
- Dave
--- 1.61/drivers/usb/host/ohci-q.c Mon Feb 24 03:30:39 2003
+++
Noticed this through www.theinquirer.net :
http://www.dct-net.co.jp/special/usb_hot.html
But what I want to know is why they advertise
Windows and Mac support, but not Linux ... does
a coffee (tea?) cup warmer really need some kind
of device driver? :)
- Dave
Here's a patch that tweaks a different area of the code.
Makes a difference for me; maybe for you too?
- Dave
--- 1.70/drivers/usb/host/ehci-q.c Mon Feb 24 03:30:38 2003
+++ edited/drivers/usb/host/ehci-q.cSun Mar 2 23:25:09 2003
@@ -712,6 +712,11 @@
if (!(cmd CMD_ASE))
Hi,
Could you bk mv drivers/usb/hcd drivers/usb/host and then apply
this patch? That will let most 2.5 host controller driver patches
apply directly to 2.4 ... helping both releases, since 2.5 has more
fixes while 2.4 has more users. (And testers!)
I've got a few other 2.4 patches in the queue,
Hi,
This is the 2.4 version of a fix that's been in 2.4 for some
time now: when an HCD dies a premature death, its cleanup
needs to be done in a task context. The most likely case for
that would be physical cardbus eject without driver shutdown.
Please merge.
- Dave
--- 1.13/drivers/usb/hcd.c
This patch syncs the 2.4 version with the latest from 2.5 ...
to make it easier for folk to use this before the host
directory rename, I decided not to depend on that patch yet.
VIA users will see the most benefit from this, as well as
anyone rebooting with usb-only configurations.
- uses reboot
David Brownell wrote:
This patch syncs the 2.4 version with the latest from 2.5 ...
to make it easier for folk to use this before the host
directory rename, I decided not to depend on that patch yet.
Whoops ... apologies. This is the version that applies
to generic 2.4.21-pre5, the preceding
Jonathan Thorpe wrote:
David,
Thanks for the patch. I applied it against 2.4.21-pre4-ac6 and found that
writing to the USB 2.0 HDD on the VT8235 was still perfect, but the
computer would still hang (lock up completely) after reading the same
amount of data from USB 2.0 HDD.
So what did the
Or instead use USB 2.0 hubs connected to a USB 2.0 root hub,
where ((480 Mbit/sec net)/24 devices) == 20 Mbit/sec per
device means there's plenty of bulk bandwidth (since no
DSL technology I've heard of goes above around 6 Mbit/sec)
hmm, I should've known this earlier. I thought that only USB2
Alan Stern wrote:
I think it's probably okay to apply this patch. More testing would be
good, but I don't have any suitable hardware. And I think a
software-loopback sort of test wouldn't address many of my changes very
well.
Ah, but gadget zero plus the software loopback HCD will emulate most
Alan Stern wrote:
On Tue, 4 Mar 2003, David Brownell wrote:
Alan Stern wrote:
I think it's probably okay to apply this patch. More testing would be
good, but I don't have any suitable hardware. And I think a
software-loopback sort of test wouldn't address many of my changes very
well.
Ah
Alan Stern wrote:
Here is a slightly updated patch for usb-skeleton.c. It has been tested
minimally with real hardware, but David Brownell would like to see some
more tests using gadget zero.
I just did, to a 2.5.62ish system running gadget zero on real hardware.
It seemed to behave, though
P.S. to David: I want to look into writing a replacement for the
usb_bulk_msg() family of routines along the lines you described (probably
following the usb_sg_xxx calls as a model). It seems clear that a
prerequisite is a version of wait_for_completion() that also takes a
timeout. I
Greg KH wrote:
On Fri, Feb 28, 2003 at 02:46:45PM -0800, David Brownell wrote:
+/* the chapter 9 device states */
+
+enum usb_device_state {
+ USB_STATE_ATTACHED = 0, /* only attached */
+ USB_STATE_POWERED,
+ USB_STATE_DEFAULT, /* limited
But the host side can't track SUSPENDED reasonably anyway, and does
not need to. It's the other states that are interesting. I agree
that if we wanted to do anything with SUSPENDED it'd need thought.
Hm, I thought that if you suspend a device, that the host knows about
it. But it's been a
Updated version attached, includes a new pseudostate NOTATTACHED
as well as comments about the four different SUSPENDED states.
This should apply to 2.5.64 just fine.
- Dave
David Brownell wrote:
Hi,
This patch merges the USB state definitions from the ARM Linux
code (inside the sa1100 driver
Mar 6 11:59:27 Webdesktop kernel: ehci-hcd 00:10.3: VIA Technologies,
Inc. USB 2.0
Mar 6 11:59:27 Webdesktop kernel: ehci-hcd 00:10.3: irq 12, pci mem
d28c4d00
Mar 6 11:59:27 Webdesktop kernel: usb.c: new USB bus registered, assigned
bus number 4
Mar 6 11:59:27 Webdesktop kernel: ehci-hcd
Jonathan Thorpe wrote:
Hi David,
***Mar 6 11:59:27 Webdesktop kernel: PCI: 00:10.3 PCI cache line size
set incorrectly (32 bytes) by BIOS/FW.
***Mar 6 11:59:27 Webdesktop kernel: PCI: 00:10.3 cache line size too
large - expecting 16.
Odd -- what kind of CPU does that have?
An AthlonXP
Jonathan Thorpe wrote:
After sending the IRQ stats to you, I decided to do the same for the NEC
USB 2.0 card that I have running on the VT8235. It appears that the NEC
2.0 card is more unstable on the VT8235 than VT8235's EHCI controller
itself (the NEC USB 2.0 controller is otherwise rock solid
Christopher Li wrote:
Sorry. I make a mistake. I mix up the PCMCIA and Card bus.
They share the same slot and have the same pcmcia-cs pakcage.
The problem is that PCMCIA is really a form factor,
one that supports several different kinds of electrical
signaling:
- ISA ... the original version,
Just to be clear:
- usb_unlink_urb() doesn't care any more about that state.
(There seemed to be agreement that it must not matter.)
There is agreement, yes. But right now the host controllers can't
handle this check not being there. I've put it back in, with a big
FIXME comment.
You mean just
Just to be clear:
- usb_unlink_urb() doesn't care any more about that state.
(There seemed to be agreement that it must not matter.)
There is agreement, yes. But right now the host controllers can't
handle this check not being there. I've put it back in, with a big
FIXME comment.
You mean just
When I do several back to usb_bulk_msg calls (64 byte writes), I notice
each one takes about 1 ms to complete. I decided to probe the usb trace
on the hardware. I noticed that even when the device and driver are
idle, I see packets being transmitted every 1ms. I am showing my
ignorance here,
Alan Stern wrote:
David and Greg:
Stepping back and trying to look at the bigger picture led to the
following thoughts regarding the synchronous API.
Is there an extra A in the Subject: then? :)
First of all, what's the reason for including usb_control_msg() and
usb_bulk_msg() in the API at
Jouni Ryno wrote:
I'm developing driver for EZUSB-based system. When I use continuous
iso-transfer (several urbs connected in the ring), every 986 (sometimes
+-3) I get 1 or more urbs, which complete in reverse order.
For example, start_frames in completion routine show up like
20, 21, 23, 22, 24.
Joshua Wise wrote:
Here is the Oops log dumped to the display right before the system locks up:
It's not very useful unless you include ksymoops output... can
you get that, and resend along with kernel information (like the
version etc). It'd also be good to have objdump -dr output
for the
Alan Stern wrote:
They could be distributed this way:
frame: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
period 1: * * * * * * * * * * * * * * * *
period 2: * * * * * * * *
period 4: *
Oliver Neukum wrote:
That means that you can't tell. So you must assume the worst.
The only safe usage with kmalloced memory is to have exactly
one buffer per kmalloced area and to start the buffer at offset 0.
None of the host controller hardware has alignment restrictions
for the start of DMA
Alan Stern wrote:
Or would it? The urb in question has to be allocated and freed somehow,
and either the driver or the core has to take care of this. By (2), this
ought to be handled by the core. So the submit routine allocates the urb
and passes a pointer to it back to the caller, while the
Alan Stern wrote:
Your comments
have given me a new idea.
The major purpose of adding the facility to cancel synchronous messages is
to allow drivers to unlink the corresponding urbs during disconnect().
Okay, so let's keep the existing API pretty much as it is, but add an
additional
Hi,
The major purpose of adding the facility to cancel synchronous messages is
to allow drivers to unlink the corresponding urbs during disconnect().
Okay, so let's keep the existing API pretty much as it is, but add an
additional argument to usb_bulk/control_msg(). This extra argument will
be
Oliver Neukum wrote:
And as near as I can tell, nobody has ever needed usb_unlink_one()
like we have today, except as a way to build usb_unlink_all().
How about SCSI abort and network timeout ?
SCSI abort applies to one request ... which often means
dozens of queued urbs. Perhaps in the future
It just needs an USB2.0 USB to SCSI bridge.
Do they really exist? And will usb-storage use those
capabilities? :)
And assuming they did, killing all the requests on that
endpoint at once would do what I think you're suggesting:
kill a single SCSI request, like start this write.
They wouldn't
Greg KH wrote:
First off, sorry for the delay, been swamped with non-usb stuff...
On Wed, Mar 05, 2003 at 12:35:26PM -0800, David Brownell wrote:
Greg, you seemed willing to merge the first version of this when it
came around (2.5.50 or so), though you seemed to agree that it'd be
worth trying
Greg KH wrote:
On Fri, Mar 14, 2003 at 03:48:24AM +0100, Oliver Neukum wrote:
Hi Greg,
you recently asked whether the module pointers could be removed.
I looked at the question and the answers is that they cannot be removed.
The ioctl into the driver through usbfs makes that impossible.
Ah
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.
---
This
[EMAIL PROTECTED] wrote:
Hi,
I'm developing a device driver for an external USB-connected GPIB
(IEEE488) interface. Many years' experience with device driver
development, but new to Linux.
You mean USB Test and Measurement Class (TMC) support?
Or a proprietary version of such a thing?
Either
You know, in all this email I think one of the key issues
has somehow not gotten brought out: the need to let the
I/O requests get canceled when the task gets signaled.
Or at least having an option to do that.
Alan Stern wrote:
On Wed, 12 Mar 2003, David Brownell wrote:
I only put
usbaudio: device 2 interface 1 altsetting 0 does not have an endpoint
...
usbaudio: device 2 interface 3 altsetting 0 does not have an endpoint
No particular idea why you have the problem, but I thought
it was worth pointing out that these two messages are bogus.
By definition, altsetting zero
Charles Lepple wrote:
I have a few new feature ideas for fxload, and I was wondering if there
is a preferred branch naming convention for linux-hotplug. A lot of
folks tend to use uppercase for the branch names, and in the absence of
any other suggestions, that's what I'll probably use.
OK by
Oliver Neukum wrote:
Am Montag, 17. März 2003 21:09 schrieb David Brownell:
You know, in all this email I think one of the key issues
has somehow not gotten brought out: the need to let the
I/O requests get canceled when the task gets signaled.
Or at least having an option to do that.
You mean
Oliver Neukum wrote:
What's wrong with using the fine macros provided in 2.5 to sleep with
TASK_INTERRUPTIBLE and unlink in the interruption case?
The current synchronous calls force TASK_UNINTERRUPTIBLE,
and I don't know what macros you're talking about that
would do all that. Is there some
The same kind of thing holds true for khubd and enumeration. Any
task doing a config change (like set_interface) should block signals,
but otherwise I suspect all synchronous calls should be interruptible
by default ... though someone ought to look for other cases where
that's not true.
Should
Alan Stern wrote:
If you mean that nobody has ever needed to cancel just a single
synchronous message except as part of cancelling all of them for a
disconnect, I agree.
Yes. Same is true when the driver uses asynchronous models too.
Surely you don't mean to say that drivers call
Greg KH wrote:
On Tue, Mar 18, 2003 at 11:39:42AM +0100, Wim Heirman wrote:
Hello,
I'm writing a driver for a data aquisition device based on the FX2. The
device is generating packets of different sizes. I'd like to have a function
that reads all data that's available and return as quickly as
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
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
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
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
Here's an updated version of Oliver's patch, changing:
- uses struct completion for simplicity
- the wait_event_timeout() logic is now like the other macros
which can return before the event happens: returns a value
- clarity for MAX_SCHEDULE_TIMEOUT scenarios, by using the
standard
Spang Oliver wrote:
Hi All,
I get the following log each time I disconnect a hub (had to type it from the display, so its not complete). I do not have the problem with 2.5.64.
A more complete oops trace would help of course; if you
could use a serial console, or even just hack the stack dump
code
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.
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
I get the following log each time I disconnect a hub (had to type it
from the display, so its not complete). I do not have the problem with
2.5.64.
I see something like this also when unloading a host controller driver.
I had one of those, then it went away when I removed that check
of yours
Charles Lepple wrote:
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
Hi,
1.
does anybody have any experience with async usb transfers? When I say
asynchronous transfers I refer to non-blocking (write/read/ioctl) calls the
user thread can test or wait for their completion.
In the write/read/ioctl it is no problem to pass an urb down asynchronously.
But how do
Robert Schwebel wrote:
can somebody tell me what the current state of the USB gadget support
is? I would like to make a network connection from a windows or linux
machine to an embedded linux system having a PXA25x USB Device
controller onboard, and I'm wondering if other people have already done
Matthew Dharm wrote:
It looks like sd_mod.ko isn't getting loaded. Load it manually and it
should all work.
Matt
Or try this /etc/hotplug/scsi.agent ...
#!/bin/bash
#
# SCSI hotplug agent for 2.5 kernels
#
#
ACTION=add
#
DEVPATH=devices/scsi0/0:0:0:0
#
cd /etc/hotplug
. hotplug.functions
case
1 - 100 of 5112 matches
Mail list logo
