Actually the timer goes off and the UART gets checked manually, and everything has passed through by that point so execution continues. I think there's supposed to be an interrupt or something for when the UART finishes, so there may be an issue with that never showing up.
Gabe Black wrote: > As a vote in favor of the usefulness of something like this, I think > I've identified -a- problem with it. There's a close system call that's > called on file descriptor 0 which is connected to the UART. The kernel > starts waiting for the buffer to drain, but it never does for some > reason and it just wakes up every now and then to give it another shot. > I don't know if this has anything to do with the segfault, but I'd guess > this is partially from me implementing all interrupts like they're edge > triggered rather than level triggered like the UART apparently expects. > If the UART starts driving its interrupt line while they're disabled for > some reason, that will get lost and some count could end up out of > balance. I'm going to be working on my somewhat hacky interrupt wiring > scheme to make it less hacky and something I'm willing to push, and in > the process I'll probably try to fix this too. > > To the folks with more kernel experience than me, does that sound > like a reasonable theory? Is there something else that might make it > wait forever? It seems to think it's got 7 characters in the buffer > which seems like a very small number compared to how much output it's > generated. > > Gabe > > Gabe Black wrote: > >> Unfortunately, decreasing the TLB size to one was a red haring >> (sic?). With only one entry, if an instruction or an access spans pages >> (which takes amazingly long to happen), the TLB thrashes back and forth >> in that one entry and never gets anywhere. Now what I'm trying to do to >> get a better handle on the flow of the program is to implement a tracer, >> like the one you get with the Exec traceflag, but that prints out the >> parameters and return value of system calls. I have a simple version of >> this hacked in already, but there are probably four things that prevent >> it from working as well as it could. Three of those are mapping syscall >> numbers to names, knowing how many arguments there are, and knowing >> which are string pointers so the string can be gathered with functional >> accesses. The fourth is identifying when you're entering or exiting a >> syscall in the first place. For the first group, I'm just simply >> ignoring those issues and printing the raw syscall number and the values >> in each of the argument registers. For the last one, I'm doing a >> hardcoded check for the mnemonics of fitting instructions as they go by >> which you can imagine is hardly efficient or flexible. >> >> At least some of the information I'd like to get at, like syscall >> names at least, is already present in m5 but is only compiled in for SE. >> Other bits of information like the number and types of arguments would >> be harder to get at. I was thinking for system call and system return >> instructions the IsSyscall and IsReturn and/or IsCall could be used to >> generically identify the instructions of interest. Does anyone have any >> thoughts about whether this is worthwhile and how best to get the >> information it would need gathered together? >> >> Gabe >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
