On Sun, 20 Dec 2009, Filip Zyzniewski wrote: > > No. It results from the value of the NPS bit in the hardware > > HcRhDescriptorA register. If value of NPS is 1 then you get that "no > > power switching" message. If you want to enable power switching, you > > might be able to do it by editing ohci-sa1111.c: Make it clear the NPS > > bit. > > I have cleared it but it still reports this way. Are you certain you cleared it? Maybe you wrote a 0 but the hardware kept the bit set to 1. There's no question that NPS controls the "no power switching" message. Look at ohci_hub_descriptor() in ohci-hub.c: If NPS is set then the routine sets the 2 bit in wHubCharacteristics. And look at hub_configure() in drivers/usb/core/hub.c: If the 2 bit is set in wHubCharacteristics then it prints the "no power switching" message. > This cannot be the > cause of communication problems however, can it? No. > > You should post some usbmon traces. You should also get a stack trace > > (Alt-SysRq-T) to find out where rmmod hangs. And you should check out > > the contents of the debugging files under > > /sys/kernel/debug/usb/ohci/0400/. > > To do this effectively I need to learn more about USB. For now I have > only sysrq-t result: > http://filip.eu.org/jornada/usb_host/dmesgs/rmmod_trace.txt > I will dive into it soon. It suggests that khubd is stuck waiting for ohci-hcd to do something. Probably waiting for an interrupt. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
