Re: smsc95xx performance bug: eth vs usb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 31, 2011 at 9:38 PM, DJ Delorie <dj@xxxxxxxxxx> wrote:
>
>> This is confusing me now... I can only find
>> linux-2.6/drivers/net/usb/smsc95xx.c, which definitely is not
>> providing a usb-hub (like linux-2.6/drivers/usb/core/hub.c) and also
>> not a USB-storage interface.
>
> http://www.smsc.com/media/Downloads_Public/Data_Sheets/9514.pdf
>
> See page 6 for a block diagram of the SMSC LAN9514 chip, if that helps
> understand the hardware.

So, that seems to be one chip, which provides at least presents two
USB-devices (one hub with 4-ports for other devices and one
ethernet-port). The information can be found in Chapters 1.1.2, 1.1.3
and Chapter 3 which describes the descriptors that can be programmed
in the EEPROM.

It is possible to unbind the smsc95xx from the ethernet-device (via
sysfs). Obviously you could unload the module already (it was does not
seem to be compiled in your kernel). Unloading a driver is similar to
unbinding the port/device/driver.

>From my understanding in an other reply you sent to the list,
unloading the smsc95xx module does not make a difference, you seem to
be able to reproduce the behavior with different devices (serial-port
and usb-mouse).

It seems that the smsc95xx module can not be kept responsible for the
bad performance of your drive. Other points that might investigation,
include the USB-controller on your PandaBoard (ehci, ohci, ...) or
possibly the USB-storage-stack. It might well be that there is an
issue around the scheduling of the interrupt-handling done by the
USB-controller...

Note that USB-mouses tend to be USB-1.x and USB-storage is usually
USB-2.x. Different USB-versions are normally handled by different
USB-controllers and therefore have their own drivers (for example,
ehci = USB-2, uhci = USB-1). /proc/interrupts might point you to some
more ideas. Possibly the USB2-controller uses a different interrupt
than the USB1-controller and the serial-port. Depending the driver
used for your USB2-controller, you might have some module-parameters
that influence interrupt-handling:

$ modinfo ehci-hcd
filename:       /lib/modules/2.6.38.3-kw/kernel/drivers/usb/host/ehci-hcd.ko
alias:          platform:orion-ehci
license:        GPL
author:         David Brownell
description:    USB 2.0 'Enhanced' Host Controller (EHCI) Driver
alias:          pci:v*d*sv*sd*bc0Csc03i20*
depends:        usbcore
vermagic:       2.6.38.3-kw preempt mod_unload ARMv5
parm:           log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int)
parm:           park:park setting; 1-3 back-to-back async packets (uint)
parm:           ignore_oc:ignore bogus hardware overcurrent indications (bool)
parm:           hird:host initiated resume duration, +1 for each 75us (int)


HTH,
Niels
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux