[PlanetCCRMA] Re: 2.6.7 ccrma kernel and usb / nvidia support
Rick B
zajelo3 at cfl.rr.com
Mon Nov 22 10:59:01 PST 2004
Shayne O'Connor wrote:
>Found out some more info after unpacking the libnjb source files (i had
>been using a gnomad2 rpm which included libnjb):
>
>
>
>
>>2. When I run the sample programs, I get "No NJB devices found", or a
>> silent failure (i.e., nothing happens and you get a prompt back)
>>
>> If you are on Linux, you need to mount the usbdevfs filesystem,
>> and ensure that you have read/write permission to the "files"
>> there. For more information, see
>> http://www.linux-usb.org/FAQ.html#gs3
>>
>> You should also verify that you have the latest libusb sources
>> from SourceForge (you may need to grab them via CVS) if you
>> have libusb v0.1.3b or earlier.
>>
>> Under BSD, make sure you have read/write access to the ugen*
>> and usb* devices in /dev. ugen support will need to be built in your
>> kernel (not required for BSD 5.x and higher, which builds devices
>> on the fly)
>>
>>
>
>
>I also found this, which i don't know if it's relevant, but during boot up after this started happening again,
>I noticed it said something about an irq when loading the usb devices:
>
>
>
>>Q: Why doesn't USB work at all? I get "device not accepting address".
>>
>>A: You may have some problem with your PCI setup that's preventing your USB host controller from getting hardware interrupts. When Linux submits a request, but never hears back from the controller, this is the diagnostic you'll see. To see if this is the problem, look at /proc/interrupts to see if the interrupt count for your host controller driver ever goes up. If it doesn't, this is the problem: either your BIOS isn't telling the truth to Linux (ACPI sometimes confuses these things, or setting the expected OS to windows in your BIOS), or Linux doesn't understand what it's saying.
>>
>>
>
>here's my listing for that - is it usual to have ethernet, usb and soundcard all on the one irq?
>
> CPU0
>
>
>> 0: 2328511 XT-PIC timer
>> 1: 1834 XT-PIC i8042
>> 2: 0 XT-PIC cascade
>> 5: 100000 XT-PIC ehci_hcd, ohci_hcd
>> 8: 1 XT-PIC rtc
>> 9: 0 XT-PIC acpi
>> 11: 283918 XT-PIC ohci_hcd, eth0, EMU10K1
>> 12: 111706 XT-PIC i8042
>> 14: 50952 XT-PIC ide0
>> 15: 23887 XT-PIC ide1
>>NMI: 0
>>ERR: 0
>>
>>
>
>shayne
>
>_______________________________________________
>PlanetCCRMA mailing list
>PlanetCCRMA at ccrma.stanford.edu
>http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
>
>
>
Shayne,
As far as the audio card sharing interrupts, you can "shuffle the
cards" so to speak by physically taking it out and moving it to another
pci slot. Different pci slots on your machine will be assigned to
different irqs, so you might have to try several different slots to get
it where you want it. Looking at your /proc/interrupts output you can
see that irq 10 is open and that seems to be the best irq for audio
cards from everything I've ever read about the subject. Here's a link
that explains more about the irq issue:
http://sourceforge.net/mailarchive/forum.php?thread_id=1079993&forum_id=7073
I've heard that acpi has caused some problems with FC1 and the 2.4
kernel, but I dont now if that applies to the 2.6 kernel too. On FC1 &
FC2 you can pass the "acpi=off" argument to the kernel by adding it to
the kernel boot line in grub.conf like so:
title Fedora Core (2.6.7-1.437.1.ll.rhfc2.ccrma)
root (hd0,1)
kernel /vmlinuz-2.6.7-1.437.1.ll.rhfc2.ccrma ro root=/dev/hda3 rhgb
acpi=off apm=off quiet
initrd /initrd-2.6.7-1.437.1.ll.rhfc2.ccrma.img
Hope this solves your problem.
Rick B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/planetccrma/attachments/20041122/67e4f500/attachment.html>
More information about the PlanetCCRMA
mailing list