experimental qemu-devel port update, please test!

[Attilio Rao]

Eric Anderson wrote:
> On 07/09/07 09:28, Attilio Rao wrote:
>> Eric Anderson wrote:
>>> On 07/09/07 08:00, Eric Anderson wrote:
>>>> Juergen Lock wrote:
>>>>> On Sun, Jul 08, 2007 at 01:15:35PM -0500, Eric Anderson wrote:
>>>>>> On 07/07/07 09:02, Juergen Lock wrote:
>>>>>>> In article <468EFF46.4060001 at freebsd.org> you write:
>>>>>>>> On 07/05/07 22:31, Eric Anderson wrote:
>>>>>>>> [...]
>>>>>>>> Although now I have the issue where using kqemu-kmod causes my 
>>>>>>>> system to reboot or power off.  :(
>>>>>>>>
>>>>>>>> Any ideas?
>>>>>>> This seems to be a -current issue, it doesn't happen for me at least
>>>>>>> (6.2 and previously also 6.1.)  You could check if it is dependent
>>>>>>> on the version of the used qemu (the 0.9.0 port, the version of
>>>>>>> qemu-devel in ports, or the not-yet-committed updated I posted),
>>>>>>> but I doubt it.  What may help is finding out which commit to 
>>>>>>> -current
>>>>>>> started kqemu to break (find an older version that worked, then
>>>>>>> binary-search), or at least a backtrace from a kernel compiled
>>>>>>> without -fomit-frame-pointer (putting DDB in the config seems to do
>>>>>>> that for amd64 at least, but rebuild the entire kernel.)  There also
>>>>>>> is an open issue for kqemu on amd64 smp,
>>>>>>>     http://www.freebsd.org/cgi/query-pr.cgi?pr=113430
>>>>>>> dunno if its related...
>>>>>>>     Juergen
>>>>>> My host is i386, SMP, and it also happens with the current 
>>>>>> qemu-devel port.  It must have been something in -CURRENT that 
>>>>>> changed, probably since May15th-ish.  I can't do a binary search 
>>>>>> anytime soon to find it.  In the past, I've recompiled kqemu and 
>>>>>> that has done the trick.  I have all the debugging built in, but 
>>>>>> that doesn't stop the system from rebooting or powering off.
>>>>> Hmm an UP kernel might be worth a try too...
>>>>>
>>>>>     Juergen
>>>>
>>>> Hmm - with and without UP, I get a panic, but I managed to catch a 
>>>> panic in _vm_map_lock, something like:
>>>>
>>>> _vm_map_lock()
>>>> vm_map_wire()
>>>> kqemu_lock_user_page()
>>>> mon_user_map()
>>>>
>>>>
>>>> I'll try to get a real bt..
>>>>
>>>> Eric
>>> Hmm - I suspect this commit or something near it is the issue:
>>>
>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_map.c.diff?r1=1.384;r2=1.385;sortby=date;f=h;f=u 
>>
>>
>> don't think so, as it just does a 1:1 translation with the old code 
>> (passing 0 as argument and casting the return value).
>>
>> What kind of panic it is (what message it prints out)?
>>
>> Attilio
>>
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x82
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc0928f00
> stack pointer           = 0x28:0xe57b7a3c
> frame pointer           = 0x28:0xe57b7a50
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 69 (qemu)
> 
> 
> #9  0xc0928f00 in _vm_map_lock (map=0x1, file=0x0, line=0) at 
> /usr/src/sys/vm/vm_map.c:421
> #10 0xc092986d in vm_map_wire (map=0x1, start=677306368, end=677310464, 
> flags=1) at /usr/src/sys/vm/vm_map.c:1964
> 
> Maybe not that exact file, but I think that series of commits is 
> related.  I believe before that everything worked fine (around May 15th 
> or so).
> 
> What else would you like me to try?

Would you see if accesses to map structure are MPSAFE and don't present 
racy accesses?

Thanks,
Attilio