On 09/10/13 07:56, Martin Pieuchot wrote: > On 10/09/13(Tue) 07:15, RD Thrush wrote: >> On 09/10/13 04:42, Martin Pieuchot wrote: >>> [...] >>> >>> Thanks for this detailed bug report. >>> >>> You're saying that you have 2 amd64 systems with the same problem but >>> I see only the dmesg for one machine, does the other has the same ehci >>> controller? >> >> Apparently one is ATI and the other Intel. >> <http://arp.thrush.com/openbsd/ehci_idone/v1/> has two console captures, >> "v1.1" and "v1.2", for the other machine after an ehci_idone hang (I hadn't >> made the panic patch yet). I was able to generate a ddb interrupt to stop >> the spew and gather some additional ddb info. The forementioned directory >> also has acpidump, pcidump, biosdecode, and dmidecode previously collected >> from the same kernel. >> >> If you want/need further info about the 'v1' machine, let me know and I'll >> boot OpenBSD and get the info. > > It would be nice if you could reproduce the manipulation you did with > the other machine and set ehcidebug to 5 before switching your kvm.
With ehcidebug=5 on the v1 machine, switching the kvm resulted in a continual ddb loop, I wasn't able to generate a ddb interrupt via the serial console; however, the pc keyboard was able to drop into ddb where I collected some additional info. 'boot sync' resulted in the panic I'd patched (earlier in thread) to stop the initial hang. I had to do a hard reset to regain control. <http://arp.thrush.com/openbsd/ehci_idone/v1/v1-2> has the capture of the serial console for that session. WRT to the other machine, x4, I installed the patch and have not yet had a problem. However, with ehcidebug=5, the following 2 line message is issued about once per second: ehci_intrlist_timeout ehci_check_intr: ex=0xffff800000238c00 That periodic message did not occur with the v1 machine. Sorry for the delay in reporting...
