[email protected] wrote: > ----- Original Message ----- >> Date: Wed, 02 Sep 2009 22:27:30 -0500 >> From: Steven Stallion <[email protected]> >> To: [email protected] >> Subject: [driver-discuss] Hard hang during interrupt processing >> >> >> All, >> >> I have been finishing up support for the RTL8029(AS) chipsets for >> support in Parallels VMs and have stumbled across a rather nasty issue >> seen during packet reception in the re(7D) ISR. >> >> Essentially, under heavy/moderate load, the machine hard hangs. >> Unfortunately my main test machine is a uniproc, and the deadman timer >> has not been of any use. >> >> Earlier this evening, I fired up the driver in an Ultra 24 (dual core), >> reproduced the hang, and was able to break into kmdb. After doing a bit >> of digging around, ::cpustack on the hung processor revealed the >> following call stack: >> >> resume_from_intr >> ddi_io_put8 >> av_dispatch_autovect >> dispatch_hardint >> switch_sp_and_call >> >> Unfortunately, the dump device timed out, so I was unable to save the >> core (hence the psuedo backtrace above). >> >> What I find particularly peculiar here, is no kthread in the system was >> anywhere near the re`re_intr ISR or anywhere else in the re module. >> >> Garrett mentioned that he may have seen something similar to this >> before, but was unable to recall anything specific. >> >> Ideas? > > Hi Steve,
Hello Masa! > If it is an interrupt handler related issue, I'd like to check following. > > Did rx overrun happen? No; In the case of an rx overrun, I disable all interrupts, and reset the device (this is a similar approach to the FreeBSD driver). > Do you use a mutex to make register page selection and register > read/write operations atomic? I use a single mutex to protect reads and writes; I factored out the page access since 95% of the code was in a read or write anyway. > Do you reset interrupt signal explicitly by clearing and setting > interrupt mask register in the interrupt handler? I don't - the documentation didn't seem to indicate this. Upon entering the ISR, I verify that the device is indeed the one responsible for generating the interrupt by reading from the ISR register, and then immediately acknowledge the interrupt by writing the same value back in. I do not modify the IMR register in any way. Cheers, Steve _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
