On 12 Aug, bruce_at_cran.org.uk wrote: > On Sat, Aug 11, 2007 at 09:42:55PM -0700, Don Lewis wrote: > Thanks for your help. The revised patch doesn't change the behaviour; It was a shot in the dark ... > in > ehci_pci_givecontroller, eec has the value 0x1000001 and the > pci_read_config returns 0xC0002000. Disabling the > SMI bit doesn't help either, Whoops, bit 13 is set in this register. In my test code, I told you to use the mask ~0x200, but the mask should have been ~0x2000. > but something I have noticed it that > (both with and without the SMI disabling code) I get an 'f' printed on > the console occasionally, which is probably from the printf I put in, > "finished in ehci_pci_givecontroller": > > // code to disable SMI bit... > DPRINTF(("pci_write_config in ehci_pci_givecontroller\n")); > pci_write_config(...) > // end for loop > DPRINT(("finished in ehci_pci_givecontroller\n")); > // end of ehci_pci_givecontroller function > > which suggests that something is > causing the system to hang after the pci_write_config has finished. The logical thing would be the SMI triggered by the pci_write_config(). There might be some uncertainty about the timing of the interrupt, which would account for the uncertainty in the appearance of the 'f'.Received on Sun Aug 12 2007 - 15:51:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:16 UTC