>>> I'm having a problem with some hardware and I think it is a bug.
>>
>> Maybe. But mostly your issues are warn() messages from the driver,
>> which won't always indicate bugs. I suspect maybe this driver should
>> use dbg() not warn().
>
>
> Should I try simply replacing the warns with dbg()? where is dbg
> declared? is it the same argument list/types?
UTSL. Yes, same <linux/usb.h> header, yes.
> Well I'd have to say that it is not a hardware problem because this usb
> ethernet thing works perfectly on the UHCI based machine. The ethernet
> cables and everything is identical to both machines. How would I try to
> figure out why this is being sent? where is it sent from? What
> determines the CRC or toggle problem and how can I figure out why it is
> incorrect
Even if the ethernet, usb adapter, and usb cables are unchanged you
still have different hardware beginning at the root hub 'A' socket
you're plugging in to. So you might have to say it, but nothing
you've said so far shows it'd be a true statement ... :)
The tool you'd want is called generically a "sniffer", and vendors
like CATC sell them. It's hardware you plug in, which monitors
and records every transaction (USB in this case) and tells you what
really happened.
Whose OHCI implementation is this, by the way? ("lspci -v" output.)
There a lot of them around, maybe you have one which doesn't work
so well. (Most work just fine on Linux.)
>>> 3) System hard reboots - this is wierd, and has happened only 3
>>> times, but I'll start something like ping apple.com or using
>>> links/lynx to go somewhere, screen blanks, and I get the BIOS screen
>>> and it's starting back up.
>>> 3) Kernel Panic - This is even more rare, I think mainly with kernel
>>> 2.5.33 with the preemptive stuff included.
>>
>>
>> Are you running with "debug memory allocations" enabled? I tend to run
>> with that at all times; it'll notice many bugs before they get a chance
>> to corrupt things very much. Both of these #3 modes are pretty far gone.
>
>
> I'm not sure. Probably not. Is that a kernel compile option? I haven't
> seen it. Where do I find it, how do I enable it?
Did you look for it? It's there under kernel hacking options,
right off the top "make menuconfig" menu.
>> My initial suspicion is that if there's a bug it's not in the ohci code,
>> since if it were then a lot of other people would see the same problems.
>
>
> I agree. I read in the archives though that the rlt8150 driver went
> through some "conversion" to use the urb something or other, I thought
> perhaps that when doing so, something in the interaction between the
> different hubs was incorrect for ohci..? But I am too lost to know left
> from right in this situation.
Sorry, I have no shortcuts to offer. The map is the kernel source
code, and let the hardware be your compass ... you'll have to start
like the rest of us did! :)
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
