List Info

Thread: Re: xen 3.1 problem (Re: xen 3.1.0 is there)




Re: xen 3.1 problem (Re: xen 3.1.0 is there)
user name
2007-06-19 18:38:44
   On Jun 19, 20:53, Manuel Bouyer wrote:
   > Subject: Re: xen 3.1 problem (Re: xen 3.1.0 is
there)
   > Is the first panic() also a "read_psl() ==
0" one ?

Yes.  Let me show it again.

mmapbatch: remap error 14!
mmapbatch: remap error 14!
mmapbatch: remap error 14!
mmapbatch: remap error 14!
Jun 20 08:21:07 fs ntpd[1082]: bind() fd 30, family 24, port
123, scope 7, addr
fe80::f00b:a4ff:fecf:7503, in6_is_addr_multicast=0 flags=17
fails: Can't assign
requested address
Jun 20 08:21:07 fs ntpd[1082]: unable to create socket on
tap0 (9) for fe80::f00b:a4ff:fecf:7503#123
panic: kernel diagnostic assertion "read_psl() ==
0" failed: file
"/mnt/raid/netbsd/20070520/src/sys/arch/xen/i386/pmap.c
", line 2189
Stopped in pid 204.1 (qemu-dm) at netbsd:cpu_Debugger+0x4:  
     popl
%
ebp

   > This would mean something disabled interrupts
between copyout() and
   > pmap_load() and failed to reenable them, but I
didn't find anything obvious.
   > copyout() itself doesn't call pmap_load() so there's
probably a trap in
   > between that isn't shown by ddb.

Thanks.  I think this is very minor bug since only few of
us
are having this problem.  This problem was started between
5/15 and 5/20.  I guess when NetBSD became 4.99.20, this
problem was begun.  I'm still tracking down when and where
it's begun.

-- Kazushi
It took me fifteen years to discover that I had no talent
for writing,
but I couldn't give up because by that time I was too
famous.
		-- Robert Benchly

Re: xen 3.1 problem (Re: xen 3.1.0 is there)
country flaguser name
Australia
2007-06-19 20:16:01
On Wed, Jun 20, 2007 at 08:38:44AM +0900, Kazushi Marukawa wrote: > > This would mean something disabled interrupts between copyout() and > > pmap_load() and failed to reenable them, but I didn't find anything obvious. > > copyout() itself doesn't call pmap_load() so there's probably a trap in > > between that isn't shown by ddb. > > Thanks. I think this is very minor bug since only few of us > are having this problem. That puzzles me too. I wonder if it's something specific to a particular driver we use that others don't? Shall we compare kernel configs? Mine's attached. The only things I'm using that might be unusual for hardware + drivers are: - cgd - bce (the special limited dma mapping) While it's a great idea to do the binary date search looking for a culprit change, I suspect you'll hit the big merge as the culprit, and then it would help to have something else to direct the search.
  Approximate file size 14153 bytes
[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )