--- "Yates, John" <email@example.com> wrote:
> Hello all,
> I am having a problem using a PCI USB 2.0 Hi-Speed
> controller (EHCI) with
> the dbau1500 eval kit with kernel 2.4.26. I have
> traced the problem down to
> a call to atomic_add() (in
> include/asm-mips/atomic.h) that uses assembly to
> access ll/sc registers of the mips architecture. If
> I override CPU options
> and disable ll/sc when configuring the kernel,
> everything works fine.
Hmm, that sounds suspicuous. I would guess the ll/sc
is just a symptom you're seeing, but that's probably
not the root of the problem. If you disable ll/sc, the
kernel has to emulate those instructions, if your
userland code uses them, which changes the
characteristics of the system, including timings.
There's probably a timing problem somewhere, but ...
that's just a guess.
> However this causes the atomic_add() to use
> local_irq_save()/local_irq_restore(). I am assuming
> this will cause quite a
> performance hit since atomic_add() gets called all
> over the place. I should
> include that the ll/sc version of atomic_add() seems
> to work fine until the
> call from the usb infrastructure.
> Below is a code trail that leads to the call to
> hub.c: usb_hub_port_connect_change()
> usb.c: usb_set_address()
> usb.c: usb_control_msg()
> usb.c: usb_internal_control_msg()
> usb.c: usb_start_wait_urb()
> usb.c: usb_submit_urb()
> usb.c: submit_urb()
> hcd.c: hcd_submit_urb()
> host/ehci-hcd.c: ehci_urb_enqueue() (urb_enqueue
> function ptr)
> host/ehci-q.c: submit_async()
> host/ehci-q.c: qh_append_tds()
> host/ehci-mem.c: qh_get()
> atomic.h atomic_inc()
> atomic.h #define atomic_inc(v) atomic_add(1,(v))
> uses ll/sc
> To reproduce my results:
> Plug in a Hi-Speed USB 2.0 controller into your pci
> slot and boot with a usb
> ehci enabled kernel. Be sure to disable the non-pci
> usb host that is
> built-in to the au1500 when building the kernel. (I
> have tried two
> controllers (NEC and ALi) with identical results.)
> Plug a Hi-Speed device (thumb drive or external HD)
> into the controller.
> (system stops responding here)
> Low/Full speed devices work without a problem
> because they use the ohci or
> uhci drivers.
> Any help or direction will be greatly appreciated.