Hi Randy,
here is EXACT error message:
from /var/log/messages
Mar 2 10:02:12 localhost kernel: usb_control/bulk_msg: timeout
Mar 2 10:02:12 localhost kernel: usb-uhci.c: interrupt, status 2, frame#
263
Mar 2 10:02:12 localhost kernel: usb-uhci.c: interrupt, status 2, frame#
265
Mar 2 10:02:1
David Brownell wrote:
>
> There are two problems I see.
>
> (1) CONFIG_SLAB_DEBUG breaks the documented
> requirement that the slab cache return adequately aligned
> data ...
adequately aligned for the _cpu_, not for some controllers. It's neither
documented that HW_CACHEALIGN aligns to 16 byte
You didn't send me the patch... :)
Don't worry, newbie... it's a common mistake, even for the pros.
Matt
On Tue, Mar 06, 2001 at 10:33:02PM -0600, [EMAIL PROTECTED] wrote:
> On Sun, Mar 04, 2001 at 11:14:14AM -0800, Matthew Dharm wrote:
> > We're definately getting closer here...
>
> I think I
On Sun, Mar 04, 2001 at 11:14:14AM -0800, Matthew Dharm wrote:
> We're definately getting closer here...
I think I might be even closer with this patch. I've progressed from
13k down to 2k. This is a great lesson on how kernel hacking is easier
than it seems.
> For now, I'd rather have a patch
Hmm ... seems I should really get around to submitting that ioctl
patch. With that, user mode drivers like the rio tools (and gPhoto,
jUSB, ...) can all boot kernel drivers off devices they'll handle.
Would you update the rio tools to use that, if it were available?
- Dave
- Original Messa
> we also need to get rid of bus_to_virt().
Hi Steve! Haven't forgotten about that. At the end of this
message is the interface to what I'm working on just now.
As in, coded but not debugged.
This interface sort of combines kmem_cache() options
(flags like SLAB_POISON, GFP_ATOMIC) with the
pci
These two patches basically come from Steve Longerbeam
(MontaVista) and are part of what's needed to make OHCI
work on MIPS and other platforms (ARM, ...) that
- ohci-hcca.patch ... makes one of the types of memory
shared between host and HC use "pci consistent" memory.
- ochi
A Crud... Don't you hate it when you ask a question to everyone, then
at the last moment (just after you've sent out the message) you figure out
what's going wrong? The Hotplug scripts had automatically loaded the
kernel driver, so it was interfering with the ioctl calls. Sorry about
that f
Hey everyone. We're in the process of reworking the Rio500 (and
hopefully, soon Rio600) utils to utilize libusb. One thing that I'm
coming across, at least for me, is that usb_claim_interface and
usb_set_altinterface are returning errors... (-1 specifically) Is this
normal? I tried to trace t
David Brownell wrote:
> I'm all for fixing the slab allocator to allocated
from non-cached
> memory (heh, trust me - don't look at usb-ohci-sa.h :-)
Sorry -- already did! :) There's a MIPS patch too;
I hope to
start fixing this soon "for real".
Just a riminder that we also need to get rid
> > ACPI defines processor power-saving states C0, C1, C2 and C3. We cannot
> > enter C3 if there is busmastering activity, and so we check BM_STS. If this
> > is high when it should not be, and we are therefore not using C3, we are
> > losing battery life.
>
> USB causes continuous bus mastering
> ACPI defines processor power-saving states C0, C1, C2 and C3. We cannot
> enter C3 if there is busmastering activity, and so we check BM_STS. If this
> is high when it should not be, and we are therefore not using C3, we are
> losing battery life.
USB causes continuous bus mastering.
> 1. The
Hi all,
Problem:
We are seeing the BM_STS bit stuck at 1, when the USB driver is enabled on
Linux.
Why this is important:
ACPI defines processor power-saving states C0, C1, C2 and C3. We cannot
enter C3 if there is busmastering activity, and so we check BM_STS. If this
is high when it should not
> I'm all for fixing the slab allocator to allocated from non-cached
> memory (heh, trust me - don't look at usb-ohci-sa.h :-)
Sorry -- already did! :) There's a MIPS patch too; I hope to
start fixing this soon "for real".
> but, shouldn't a distinction be made between hardware cache alig
[EMAIL PROTECTED] said:
> Alpha is big endian, right?
Wrong. Little endian, 64bit.
Actually, it can be run in big-endian mode, but is not in general,
certainly not under Linux.
--
Steve Williams"The woods are lovely, dark and deep.
[EMAIL PROTECTED] But I have pro
Brad Parker writes:
> Alpha is big endian, right?
Nope, little-endian (natively at least, it might have a big-endian
mode for all I know).
> Can anyone explain how usb-ohci.c works on big endian machines? (like the
> iMac?) I know it does, but why? (in terms of little-endian/big-endian)
>
>
I'm all for fixing the slab allocator to allocated from non-cached
memory (heh, trust me - don't look at usb-ohci-sa.h :-)
but, shouldn't a distinction be made between hardware cache alignment
and strict hardware required alignment?
hardware cache alignment - nice to have, speeds up the cod
> Anyways, is this the end of the discussion regarding my patch?
I think one of the maintainers for usb-uhci (Georg) said he'd
want the general fix ...
> Manfred said plainly "usb-uhci is broken", Alan kinda
> manuevered around my small problem, Dave Brownell looks
> unconvinced. So?
There are
Stephen Williams wrote:
>
>I have a Linux/alpha system running 2.2.18, and a LInux/ix86 system
>also with 2.2.18. The Linux/ix86 system supports the ohci-usb boards
>I have just fine. I tried them in my alpha, and I get in my logs
>messages like:
>
>Mar 5 13:33:41 icarus kernel: usb.c: USB new d
Hi,
I just failed to get an Acer Modem 56 Surf USB
(Model AMU-AE00) running with Linux. The acm driver
doesn't accept this modem. I was reading a little bit
in acm.c, but I don't know enough about USB protocols
to understand everything.
The reason for not accepting the modem is, that
it doesn't
Hi,
IF you are actually working on a kernel USB driver,
sure, you can (should) #include
How are you compiling? What gcc options?
Maybe you are missing -O2
That's Optimization level 2.
Or maybe you are missing -D__KERNEL__
?
I wouldn't suggest using any library other than
linux/lib/lib.a .
~R
Title: RE: [linux-usb-devel] Including usb.h
>> What have I done wrong ? How to include usb.h ? or should I use an other
>> library ?
>>
>> I know that it is a stupid question but I really don't know where is the
>> problem...
>> I am nearly a newbie in usb and after having read the usb spec
> What have I done wrong ? How to include usb.h ? or should I use an other
> library ?
>
> I know that it is a stupid question but I really don't know where is the
> problem...
> I am nearly a newbie in usb and after having read the usb specs and the
> programming guide I still need a little help
Title: Including usb.h
Hi,
I'm developping a driver for a usb device. For the moment I just try to make a program that can handle the device. I have to send to it some urbs which are vendor-defined requests to its interface (it doesn't even have endpoints !).
So I think the functions deliv
> > At the time, I didn't feel like creating a custom sub-allocator just
> > for USB, ...
> >
> > I'd be good to get it done "properly" at some point though.
>
> Something like
>
> struct pci_pool *pci_alloc_consistent_pool(int objectsize, int align)
struct pci_pool *
pci_create_consist
Sorry, I don't think I'll make time to put into
developing any patch without the chip errata
unless it's just to prevent that chip from initting.
With a chip erratum like that one, consistent
failure modes aren't guaranteed. But you're
right to imply there may be other gremlins
at play here.
-
Hi!
> I'm from the world of "I hate rebooting", so maybe I'm just weird, but if
> a new USB device comes along, and it requires an entry, it would be useful
> to have that as part of the information on the device. Then a user would
> add the entry via a proc or a dev file, plug in the device,
27 matches
Mail list logo
