[PlanetCCRMA] Re: 2.6.7 ccrma kernel and usb / nvidia support

[Rick B]

Rick B wrote:

> 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

Shayne,
    I forgot to add that sometime your bios might have settings to 
adjust irqs also.

                Rick B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/planetccrma/attachments/20041122/3abead3d/attachment.html>