From: Karsten Wiese <fzuuzf(a)googlemail.com> Date: Sat, 12 May 2012 23:18:22 +0200 hmmmm.... shame.... lenovo specs said, of course, "USB 2.0". mrph. any way around this currently? cheers! .pltk.

On 05/13/2012 03:13 AM, plutek wrote: yes, http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-October/029511.h…

On 05/13/2012 07:45 PM, plutek wrote: No, not that I can tell. "0000:00:1d.0" is the USB hub/controller, right? The idea is to use the uhci_hcd (USB1) driver instead of ehci_hcd (USB2). -- Maybe the module is not loaded? `lsmod | grep uhci_hcd` `ls /sys/bus/pci/drivers/uhci_hcd/` If they're modules: `rmmod ehci_hcd; modprobe uhci_hcd`; that'll force all USB ports into 1.X mode; may be worth a try before playing with dedicated per port bindings. Anyway, there might be something else going on: as both Karsten and Clemens noted, these "Intel Corporation Cougar Point [..] controllers use a different driver" and "There have been fixes recently. Try updating the kernel." robin

You do not have a UHCI controller. You only have EHCI controllers. On your machine, all USB 1.1 is handled by transaction translators in your EHCI controller's root hub. The UHCI driver is not a USB 1.1 driver-- it's a driver for UHCI hardware which happens to be for USB 1.1, and which you do not have at all. Older machines paired a UHCI and EHCI controller to handle USB 1.1 and 2.0; newer machines use EHCI for both. The linux EHCI TT scheduler is not very good. I wrote a new one from scratch a few years ago, but the kernel people considered it low priority and I got sick of maintaining it against updates, as they dropped it from testing kernels whenever any other incoming patch conflicted. OTOH, the EHCI hardware itself is much more reliable than the UHCI hardware, which apparently suffers from isochronous dropouts even when the driver functions perfectly. Monty

Robin Gareus wrote: The problem would be with the driver (which stays the same), not with the hardware. Furthermore, it's probably that the EHCI driver issues are not related with this problem, as they result in a failure to allocate bandwidth and not in increased latency. It's likely that some other hardware or driver or power management interferes with processing. If this is done by the BIOS, there is no way around it. Regards, Clemens

From: Monty Montgomery <xiphmont(a)gmail.com> Date: Sun, 13 May 2012 16:40:28 -0400 alrighty, i've compiled some kernels and also tested most of what's in the AVLinux repository, and now i have some interesting data: two general caveats: neither compiling myself nor whether or not PAE is enabled seems to matter much. also, this is all still on my new ThinkPad T520. 3.0.6-avl-5 and 3.0.16-avl-7 are the only two which are really useful for me... my RME Multiface on ExpressCard is solid at 64x2 under load, and my ART USB Dual Tube Pre seems solid under load at 128x4 (although the 3.0.16 might need to go to 256x4 -- i haven't lived with it long enough to know -- i do think the xruns are creeping in earlier on 3.0.16 than on 3.0.6). 3.0.30-avl-8 makes the RME useless -- Jack starts, but crashes almost as soon as i start any application (even just jack_mixer alone!). with the USB interface, my system locks up when i start my test puredata patch, even at latencies higher than 128x4. anything higher than 3.0.30 behaves similarly to 3.0.30 with both cards. i tested up to 3.4.0.rc7. it's hard to get really accurate numbers without a LOT of time on controlled testing, which i really don't have right now, but from observations of the system in use, it seems pretty obvious that there's a breakpoint somewhere between 3.0.16 and 3.0.30, at which something changed, making both of my interfaces severely less usable. i'm particularly surprised about the RME hardware, which has always been solid for me on various systems and kernels over the years. i don't know whether that gives anybody enough info to tell much of anything, but perhaps it's useful... for now, i'm running 3.0.6-avl-5-pae in production/performance. cheers!

From: david <gnome(a)hawaii.rr.com> Subject: Re: [LAU] USB on ThinkPad T520 Date: Mon, 14 May 2012 08:23:45 -1000 to see my entire 6Gb of RAM... but others have pointed out, probably rightly, that i'm very unlikely to really need more than 3Gb anyways. so, for safety, i'll switch back to 3.0.6-avl-5 for the time being. thanks... cheers! .pltk.

On 05/14/2012 09:22 AM, plutek wrote: Oh, yah, sorry, I forgot about that senseless limitation of AVLinux. That's why I don't use it. None of my 32-bit hardware supports PAE, and the 64-bit hardware doesn't need PAE. My 64-bit system has 12GB RAM, but it needs it for working with big panoramas. Probably the audio uses don't need that much for my simple uses. -- David gnome(a)hawaii.rr.com authenticity, honesty, community http://clanjones.org/david/ http://dancing-treefrog.deviantart.com/

On 05/15/2012 10:32 PM, hermann wrote: So why does maintainer require PAE in the first place? Only needed to get around memory limitation of 32-bit mode, in a day when even the little dual-core processor running my wife's netbook is 64-bit. 'Sokay, whatever maintainer wants to maintain for themselves. -- David gnome(a)hawaii.rr.com authenticity, honesty, community http://clanjones.org/david/ http://dancing-treefrog.deviantart.com/

From: Clemens Ladisch <clemens(a)ladisch.de> Date: Sat, 12 May 2012 20:30:29 +0200 alright, here they are: root@palnote:/home/plutek# lspci 00:00.0 Host bridge: Intel Corporation Sandy Bridge DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation Cougar Point HECI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation Cougar Point High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 2 (rev b4) 00:1c.3 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 4 (rev b4) 00:1c.4 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 5 (rev b4) 00:1d.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation Cougar Point LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation Cougar Point 6 port SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation Cougar Point SMBus Controller (rev 04) 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01) 0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 08) 0d:00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 04) root@palnote:/home/plutek# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 243 0 0 0 IO-APIC-edge timer 1: 1511 0 0 0 IO-APIC-edge i8042 8: 1 0 0 0 IO-APIC-edge rtc0 9: 28481 0 0 0 IO-APIC-fasteoi acpi 12: 15976 0 0 0 IO-APIC-edge i8042 16: 18305 0 0 0 IO-APIC-fasteoi mmc0, ehci_hcd:usb1, mei 23: 60179021 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2 40: 2989 0 0 0 PCI-MSI-edge 41: 573 0 0 0 PCI-MSI-edge firewire_ohci 42: 9506 0 0 0 PCI-MSI-edge ahci 43: 311111 0 0 0 PCI-MSI-edge i915 NMI: 0 0 0 0 Non-maskable interrupts LOC: 1193738 4643806 1633507 1673425 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RES: 9862796 73470954 19362597 18060482 Rescheduling interrupts CAL: 21749 5487 20141 22523 Function call interrupts TLB: 258 357 304 486 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 123 123 123 123 Machine check polls ERR: 0 MIS: 0 thanks much.... cheers! .pltk.