NetBSD Problem Report #47720

From www@NetBSD.org  Fri Apr  5 23:14:52 2013
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 2412F63F2B9
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  5 Apr 2013 23:14:52 +0000 (UTC)
Message-Id: <20130405231451.685C663F2B9@www.NetBSD.org>
Date: Fri,  5 Apr 2013 23:14:51 +0000 (UTC)
From: kimtwain0@gmail.com
Reply-To: kimtwain0@gmail.com
To: gnats-bugs@NetBSD.org
Subject: Kernel Panic on dom0 shutdown or reboot when using RAIDframe
X-Send-Pr-Version: www-1.0

>Number:         47720
>Notify-List:    gson@gson.org
>Category:       port-xen
>Synopsis:       Kernel Panic on dom0 shutdown or reboot when using RAIDframe
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bouyer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 05 23:15:00 +0000 2013
>Closed-Date:    Tue Apr 14 21:13:16 +0000 2015
>Last-Modified:  Tue Apr 14 21:13:16 +0000 2015
>Originator:     Kim fantasyname Twain
>Release:        6.0.1
>Organization:
>Environment:
NetBSD netbsdxen.home 6.0.1 NetBSD 6.0.1 (XEN3_DOM0) amd64
>Description:
Issuing a shutdown or reboot on NetBSD running in a XEN dom0, with an active raid1 array, causes a kernel panic and a forced root filesystem check on reboot, and the array parity status may become dirty. The array doesn't contain any mounted filesystem.

Screenshot of the kernel panic occurring in virtualbox: 

https://lh6.googleusercontent.com/-WTqK2kPydh0/UV9THX5Z7GI/AAAAAAAAAkI/CAWP2P3Pwe0/s800/Schermata+2013-04-06+alle+00.40.42+1.png
>How-To-Repeat:
1. Install NetBSD 6.0.1 on wd0
2. Create a RAIDframe array (raid1) using wd1 and wd2
3. Install xentools41, xenkernel41 and extract netbsd-XEN3_DOM0.gz (version 6.0.1) as /netbsd.dom0
4. Add 
"xenbackendd=YES
xend=YES
xendomains=YES
xenwatchdog=YES" to /etc/rc.conf
5. Create a new entry in /boot.cfg menu=Xen:load /netbsd.dom0 console=pc;multiboot /usr/pkg/xen41-kernel/xen.gz dom0_mem=256M
6. Reboot into xen
7. Issue a shutdown or a reboot
>Fix:

>Release-Note:

>Audit-Trail:
From: Kim Twain <kimtwain0@gmail.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-xen/47720
Date: Sat, 6 Apr 2013 03:32:00 +0200

 --047d7bea3f988bfd5404d9a72b2b
 Content-Type: text/plain; charset=ISO-8859-1

 kernel: page fault trap, code=0
 stopped in pid 34.1 (halt) at netbsd:bus_space_read_4+0x8: movl 0(%rdx),%eax
 bus_space_read_4() at netbsd:bus_space_read_4+0x8
 Xresume_xenev6() t netbsd:Xresume_xenev6+0x47
 --- interrupt ---
 Xspllower() at netbsd:Xspllower+0xe
 rf_paritymap_kern_write() at netbsd_rf_paritymap_kern_write+0x42
 rf_paritymap_write_locked() at netbsd:rf_paritymap_write_locked+0xb5
 rf_paritymap_destroy() at netbsd:rf:paritymap_destroy+0x62
 rf_paritymap_detach() at netbsd:rf_paritymap_detach+0x4f
 rf_Shutdown() at netbsd:rf_Shutdown+0x157
 raid_detach() at netbsd:raid_detach+0x88
 config_detach() at netbsd:config_detach+0x80
 config_detach_all() at netbsd:config_detach_all+0x7d
 cpu_reboot() at netbsd:cpu_reboot+0x135
 sys_reboot() at netbsd:sys_reboot+0x73
 syscall() at netbsd:syscall+0xc4
 ds 4
 es 8748
 fs 6
 gs dc80
 rdi ffffffff80b73120 x86_mem
 rsi ffffa00017610000
 rbp ffffa000190187f8
 rbx ffffa000011b7000
 rdx ffffa000176100c0
 rcx 4
 rax ffffa000011b7078
 r8 3
 r9 ffffa000010e2768
 r10 0
 r11 0
 r12 0
 r13 0
 r14 ffffa0000117a000
 r15 22
 rip ffffffff801dbdc8 bus_space_read_4+0x8
 cs e030
 rflags 10202
 rsp ffffa00019018770
 ss e02b
 netbsd:bus_space_read_4+0x8: movl 0(%rdx),%eax

 I was unable to obtain a dump: sync returns "dump on dev 0,48 not possible"

 --047d7bea3f988bfd5404d9a72b2b
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable

 <div dir=3D"ltr"><div>kernel: page fault trap, code=3D0</div><div>stopped i=
 n pid 34.1 (halt) at<span class=3D"" style=3D"white-space:pre">	</span>netb=
 sd:bus_space_read_4+0x8:<span class=3D"" style=3D"white-space:pre">	</span>=
 movl 0(%rdx),%eax</div>
 <div>bus_space_read_4() at netbsd:bus_space_read_4+0x8</div><div>Xresume_xe=
 nev6() t netbsd:Xresume_xenev6+0x47</div><div>--- interrupt ---</div><div>X=
 spllower() at netbsd:Xspllower+0xe</div><div>rf_paritymap_kern_write() at n=
 etbsd_rf_paritymap_kern_write+0x42</div>
 <div>rf_paritymap_write_locked() at netbsd:rf_paritymap_write_locked+0xb5</=
 div><div>rf_paritymap_destroy() at netbsd:rf:paritymap_destroy+0x62</div><d=
 iv>rf_paritymap_detach() at netbsd:rf_paritymap_detach+0x4f</div><div>rf_Sh=
 utdown() at netbsd:rf_Shutdown+0x157</div>
 <div>raid_detach() at netbsd:raid_detach+0x88</div><div>config_detach() at =
 netbsd:config_detach+0x80</div><div>config_detach_all() at netbsd:config_de=
 tach_all+0x7d</div><div>cpu_reboot() at netbsd:cpu_reboot+0x135</div><div>
 sys_reboot() at netbsd:sys_reboot+0x73</div><div>syscall() at netbsd:syscal=
 l+0xc4</div><div>ds<span class=3D"" style=3D"white-space:pre">	</span>4</di=
 v><div>es<span class=3D"" style=3D"white-space:pre">	</span>8748</div><div>=
 fs<span class=3D"" style=3D"white-space:pre">	</span>6</div>
 <div>gs<span class=3D"" style=3D"white-space:pre">	</span>dc80</div><div>rd=
 i<span class=3D"" style=3D"white-space:pre">	</span>ffffffff80b73120<span c=
 lass=3D"" style=3D"white-space:pre">	</span>x86_mem</div><div>rsi<span clas=
 s=3D"" style=3D"white-space:pre">	</span>ffffa00017610000</div>
 <div>rbp<span class=3D"" style=3D"white-space:pre">	</span>ffffa000190187f8=
 </div><div>rbx<span class=3D"" style=3D"white-space:pre">	</span>ffffa00001=
 1b7000</div><div>rdx<span class=3D"" style=3D"white-space:pre">	</span>ffff=
 a000176100c0</div>
 <div>rcx<span class=3D"" style=3D"white-space:pre">	</span>4</div><div>rax<=
 span class=3D"" style=3D"white-space:pre">	</span>ffffa000011b7078</div><di=
 v>r8<span class=3D"" style=3D"white-space:pre">	</span>3</div><div>r9<span =
 class=3D"" style=3D"white-space:pre">	</span>ffffa000010e2768</div>
 <div>r10<span class=3D"" style=3D"white-space:pre">	</span>0</div><div>r11<=
 span class=3D"" style=3D"white-space:pre">	</span>0</div><div>r12<span clas=
 s=3D"" style=3D"white-space:pre">	</span>0</div><div>r13<span class=3D"" st=
 yle=3D"white-space:pre">	</span>0</div>
 <div>r14<span class=3D"" style=3D"white-space:pre">	</span>ffffa0000117a000=
 </div><div>r15<span class=3D"" style=3D"white-space:pre">	</span>22</div><d=
 iv>rip<span class=3D"" style=3D"white-space:pre">	</span>ffffffff801dbdc8<s=
 pan class=3D"" style=3D"white-space:pre">	</span>bus_space_read_4+0x8</div>
 <div>cs<span class=3D"" style=3D"white-space:pre">	</span>e030</div><div>rf=
 lags<span class=3D"" style=3D"white-space:pre">	</span>10202</div><div>rsp<=
 span class=3D"" style=3D"white-space:pre">	</span>ffffa00019018770</div><di=
 v>ss<span class=3D"" style=3D"white-space:pre">	</span>e02b</div>
 <div>netbsd:bus_space_read_4+0x8:<span class=3D"" style=3D"white-space:pre"=
 >	</span>movl<span class=3D"" style=3D"white-space:pre">	</span>0(%rdx),%ea=
 x</div><div><br></div><div style>I was unable to obtain a dump: sync return=
 s &quot;dump on dev 0,48 not possible&quot;</div>
 </div>

 --047d7bea3f988bfd5404d9a72b2b--

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
        netbsd-bugs@NetBSD.org, kimtwain0@gmail.com
Subject: Re: port-xen/47720: Kernel Panic on dom0 shutdown or reboot when
 using RAIDframe
Date: Sat, 6 Apr 2013 11:21:47 +0200

 On Fri, Apr 05, 2013 at 11:15:01PM +0000, kimtwain0@gmail.com wrote:
 > [...]
 > >How-To-Repeat:
 > 1. Install NetBSD 6.0.1 on wd0
 > 2. Create a RAIDframe array (raid1) using wd1 and wd2
 > 3. Install xentools41, xenkernel41 and extract netbsd-XEN3_DOM0.gz (version 6.0.1) as /netbsd.dom0
 > 4. Add 
 > "xenbackendd=YES
 > xend=YES
 > xendomains=YES
 > xenwatchdog=YES" to /etc/rc.conf
 > 5. Create a new entry in /boot.cfg menu=Xen:load /netbsd.dom0 console=pc;multiboot /usr/pkg/xen41-kernel/xen.gz dom0_mem=256M
 > 6. Reboot into xen
 > 7. Issue a shutdown or a reboot

 All my Xen servers have multiple raidframe on wd?, and I've never
 seen this, so there must be something else.

 On Sat, Apr 06, 2013 at 01:35:02AM +0000, Kim Twain wrote:
 >  kernel: page fault trap, code=0
 >  stopped in pid 34.1 (halt) at netbsd:bus_space_read_4+0x8: movl 0(%rdx),%eax
 >  bus_space_read_4() at netbsd:bus_space_read_4+0x8
 >  Xresume_xenev6() t netbsd:Xresume_xenev6+0x47
 >  --- interrupt ---

 Xresume_xenev6() doesn't call bus_space_read_4(), there is other
 functions in between, and this is the information missing.
 Can you try to rebuild the kernel with -O0, and maybe some -fno-...
 options, like -fno-optimize-sibling-calls


 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
        netbsd-bugs@NetBSD.org, kimtwain0@gmail.com
Subject: Re: port-xen/47720: Kernel Panic on dom0 shutdown or reboot when
 using RAIDframe
Date: Sat, 6 Apr 2013 11:41:29 +0200

 On Sat, Apr 06, 2013 at 11:21:47AM +0200, Manuel Bouyer wrote:
 > On Sat, Apr 06, 2013 at 01:35:02AM +0000, Kim Twain wrote:
 > >  kernel: page fault trap, code=0
 > >  stopped in pid 34.1 (halt) at netbsd:bus_space_read_4+0x8: movl 0(%rdx),%eax
 > >  bus_space_read_4() at netbsd:bus_space_read_4+0x8
 > >  Xresume_xenev6() t netbsd:Xresume_xenev6+0x47
 > >  --- interrupt ---
 > 
 > Xresume_xenev6() doesn't call bus_space_read_4(), there is other

 BTW, what is event 6 mapped to on your system ?

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-xen/47720 (Kernel Panic on dom0 shutdown or reboot when using RAIDframe)
Date: Sat, 3 Jan 2015 18:19:42 +0200

 I am seeing a crash on shutdown of a Xen dom0 similar to that reported
 in port-xen/47720 after installing NetBSD/amd64 6.1.5 with Xen 4.2 as
 a Xen dom0 per <http://wiki.netbsd.org/ports/xen/howto/>, even though
 I am not using RAIDframe.

 Running the following shell script will reproduce the bug by doing an
 automated install of NetBSD/amd64 6.1.5 with Xen 4.2 in a qemu virtual
 machine and then attempting to shut it down (requires misc/py-anita
 from pkgsrc, >5G of disk, and >1h of time):

    http://www.gson.org/netbsd/bugs/47720/pr47720.sh

 -- 
 Andreas Gustafsson, gson@gson.org

From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc: bouyer@antioche.eu.org
Subject: Re: port-xen/47720 (Kernel Panic on dom0 shutdown or reboot when using RAIDframe)
Date: Sat, 10 Jan 2015 18:47:20 +0200

 Here's the console output from one of my panics:

   # halt -p
   Jan 10 16:29:54  halt: halted by root
   Jan 10 16:29:54  syslogd[140]: Exiting on signal 15
   syncing disks... done
   cd0: detached
   atapibus0: detached
   atabus1: detached
   makphy0: detached
   wm0: detached
   pchb0: detached
   fatal page fault in supervisor mode
   trap type 6 code 0 rip ffffffff801dbf78 cs e030 rflags 202 cr2  ffffa0000c3d00c0 cpl 6 rsp ffffa0000dd306d0
   Skipping crash dump on recursive panic
   panic: trap
   cpu0: Begin traceback...
   printf_nolog() at netbsd:printf_nolog
   startlwp() at netbsd:startlwp
   alltraps() at netbsd:alltraps+0x9f
   Xresume_xenev6() at netbsd:Xresume_xenev6+0x47
   --- interrupt ---
   Xspllower() at netbsd:Xspllower+0xe
   VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x54
   wapbl_doio() at netbsd:wapbl_doio+0x9f
   wapbl_buffered_flush() at netbsd:wapbl_buffered_flush+0x3b
   wapbl_write_commit() at netbsd:wapbl_write_commit+0x23
   wapbl_flush() at netbsd:wapbl_flush+0x4cd
   ffs_flushfiles() at netbsd:ffs_flushfiles+0xf5
   ffs_unmount() at netbsd:ffs_unmount+0x3f
   dounmount() at netbsd:dounmount+0x9c
   vfs_unmount_forceone() at netbsd:vfs_unmount_forceone+0x63
   cpu_reboot() at netbsd:cpu_reboot+0x147
   sys_reboot() at netbsd:sys_reboot+0x73
   syscall() at netbsd:syscall+0xc4
   cpu0: End traceback...
   wd0: flush cache command didn't complete
   rebooting...

 In an earlier mail, Manuel Bouyer asked:
 > BTW, what is event 6 mapped to on your system ?

 What commands should I run to determine that?
 -- 
 Andreas Gustafsson, gson@gson.org

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-xen/47720 (Kernel Panic on dom0 shutdown or reboot when
 using RAIDframe)
Date: Sat, 10 Jan 2015 18:08:32 +0100

 On Sat, Jan 10, 2015 at 06:47:20PM +0200, Andreas Gustafsson wrote:
 > Here's the console output from one of my panics:
 > 
 >   # halt -p
 >   Jan 10 16:29:54  halt: halted by root
 >   Jan 10 16:29:54  syslogd[140]: Exiting on signal 15
 >   syncing disks... done
 >   cd0: detached
 >   atapibus0: detached
 >   atabus1: detached
 >   makphy0: detached
 >   wm0: detached
 >   pchb0: detached
 >   fatal page fault in supervisor mode
 >   trap type 6 code 0 rip ffffffff801dbf78 cs e030 rflags 202 cr2  ffffa0000c3d00c0 cpl 6 rsp ffffa0000dd306d0
 >   Skipping crash dump on recursive panic
 >   panic: trap
 >   cpu0: Begin traceback...
 >   printf_nolog() at netbsd:printf_nolog
 >   startlwp() at netbsd:startlwp
 >   alltraps() at netbsd:alltraps+0x9f
 >   Xresume_xenev6() at netbsd:Xresume_xenev6+0x47
 >   --- interrupt ---
 >   Xspllower() at netbsd:Xspllower+0xe
 >   VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x54
 >   wapbl_doio() at netbsd:wapbl_doio+0x9f
 >   wapbl_buffered_flush() at netbsd:wapbl_buffered_flush+0x3b
 >   wapbl_write_commit() at netbsd:wapbl_write_commit+0x23
 >   wapbl_flush() at netbsd:wapbl_flush+0x4cd
 >   ffs_flushfiles() at netbsd:ffs_flushfiles+0xf5
 >   ffs_unmount() at netbsd:ffs_unmount+0x3f
 >   dounmount() at netbsd:dounmount+0x9c
 >   vfs_unmount_forceone() at netbsd:vfs_unmount_forceone+0x63
 >   cpu_reboot() at netbsd:cpu_reboot+0x147
 >   sys_reboot() at netbsd:sys_reboot+0x73
 >   syscall() at netbsd:syscall+0xc4
 >   cpu0: End traceback...
 >   wd0: flush cache command didn't complete
 >   rebooting...
 > 
 > In an earlier mail, Manuel Bouyer asked:
 > > BTW, what is event 6 mapped to on your system ?
 > 
 > What commands should I run to determine that?

 dmesg | egrep 'event channel 6'

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Andreas Gustafsson <gson@gson.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-xen/47720 (Kernel Panic on dom0 shutdown or reboot when
 using RAIDframe)
Date: Sat, 10 Jan 2015 19:21:42 +0200

 Manuel Bouyer wrote:
 > > > BTW, what is event 6 mapped to on your system ?

 piixide0 in my case.  Here are the relevant parts of the dmesg:

   piixide0 at pci0 dev 1 function 1: Intel 82371SB IDE Interface (PIIX3) (rev. 0x00)
   piixide0: bus-master DMA support present
   piixide0: primary channel wired to compatibility mode
   piixide0: primary channel interrupting at ioapic0 pin 14, event channel 6
   atabus0 at piixide0 channel 0
   piixide0: secondary channel wired to compatibility mode
   piixide0: secondary channel interrupting at ioapic0 pin 15, event channel 7
   atabus1 at piixide0 channel 1
   [...]
   wd0 at atabus0 drive 0
   wd0: <QEMU HARDDISK>
   wd0: drive supports 16-sector PIO transfers, LBA48 addressing
   wd0: 4096 MB, 8322 cyl, 16 head, 63 sec, 512 bytes/sect x 8388608 sectors
   wd0: 32-bit data port
   wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
   wd0(piixide0:0:0): using PIO mode 4, DMA mode 2 (using DMA)
   atapibus0 at atabus1: 2 targets
   cd0 at atapibus0 drive 0: <QEMU DVD-ROM, QM00003, 2.2.0> cdrom removable
   cd0: 32-bit data port
   cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
   cd0(piixide0:1:0): using PIO mode 4, DMA mode 2 (using DMA)

 -- 
 Andreas Gustafsson, gson@gson.org

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
        netbsd-bugs@NetBSD.org, kimtwain0@gmail.com
Subject: Re: port-xen/47720 (Kernel Panic on dom0 shutdown or reboot when
 using RAIDframe)
Date: Sat, 10 Jan 2015 18:30:26 +0100

 On Sat, Jan 10, 2015 at 05:25:00PM +0000, Andreas Gustafsson wrote:
 > The following reply was made to PR port-xen/47720; it has been noted by GNATS.
 > 
 > From: Andreas Gustafsson <gson@gson.org>
 > To: Manuel Bouyer <bouyer@antioche.eu.org>
 > Cc: gnats-bugs@NetBSD.org
 > Subject: Re: port-xen/47720 (Kernel Panic on dom0 shutdown or reboot when
 >  using RAIDframe)
 > Date: Sat, 10 Jan 2015 19:21:42 +0200
 > 
 >  Manuel Bouyer wrote:
 >  > > > BTW, what is event 6 mapped to on your system ?
 >  
 >  piixide0 in my case.  Here are the relevant parts of the dmesg:
 >  
 >    piixide0 at pci0 dev 1 function 1: Intel 82371SB IDE Interface (PIIX3) (rev. 0x00)
 >    piixide0: bus-master DMA support present
 >    piixide0: primary channel wired to compatibility mode
 >    piixide0: primary channel interrupting at ioapic0 pin 14, event channel 6
 >    atabus0 at piixide0 channel 0
 >    piixide0: secondary channel wired to compatibility mode
 >    piixide0: secondary channel interrupting at ioapic0 pin 15, event channel 7
 >    atabus1 at piixide0 channel 1
 >    [...]
 >    wd0 at atabus0 drive 0
 >    wd0: <QEMU HARDDISK>
 >    wd0: drive supports 16-sector PIO transfers, LBA48 addressing
 >    wd0: 4096 MB, 8322 cyl, 16 head, 63 sec, 512 bytes/sect x 8388608 sectors
 >    wd0: 32-bit data port
 >    wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
 >    wd0(piixide0:0:0): using PIO mode 4, DMA mode 2 (using DMA)
 >    atapibus0 at atabus1: 2 targets
 >    cd0 at atapibus0 drive 0: <QEMU DVD-ROM, QM00003, 2.2.0> cdrom removable
 >    cd0: 32-bit data port
 >    cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
 >    cd0(piixide0:1:0): using PIO mode 4, DMA mode 2 (using DMA)

 is pciide0 detached when the panic happens ?

 If so it's a know problem: events are not properly shut down on device
 detach. Code for this needs to be written.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Andreas Gustafsson <gson@gson.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-xen/47720 (Kernel Panic on dom0 shutdown or reboot when
 using RAIDframe)
Date: Mon, 12 Jan 2015 16:49:11 +0200

 Manuel Bouyer wrote:
 > is pciide0 detached when the panic happens ?

 Based on the console messages included in an earlier message, it
 doesn't look that way: none of the the "foo: detached" messages
 printed before the panic mentions pciide0 nor piixide0.

 > If so it's a know problem: events are not properly shut down on device
 > detach. Code for this needs to be written.

 What's the PR number for this?
 -- 
 Andreas Gustafsson, gson@gson.org

From: "Manuel Bouyer" <bouyer@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/47720 CVS commit: src/sys/arch/xen
Date: Sat, 14 Mar 2015 10:49:36 +0000

 Module Name:	src
 Committed By:	bouyer
 Date:		Sat Mar 14 10:49:36 UTC 2015

 Modified Files:
 	src/sys/arch/xen/include: evtchn.h
 	src/sys/arch/xen/xen: evtchn.c pci_intr_machdep.c

 Log Message:
 Properly implemement pci_intr_disestablish(9), so that interrupt
 handlers stop being called when the device has been detached.
 Should fix PR port-xen/47720 (which turns out to not be related to raidframe).
 While there fix possible races in event_remove_handler() and pirq_establish().


 To generate a diff of this commit:
 cvs rdiff -u -r1.22 -r1.23 src/sys/arch/xen/include/evtchn.h
 cvs rdiff -u -r1.70 -r1.71 src/sys/arch/xen/xen/evtchn.c
 cvs rdiff -u -r1.16 -r1.17 src/sys/arch/xen/xen/pci_intr_machdep.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: port-xen-maintainer->bouyer
Responsible-Changed-By: bouyer@NetBSD.org
Responsible-Changed-When: Sat, 14 Mar 2015 10:54:35 +0000
Responsible-Changed-Why:
.


State-Changed-From-To: open->feedback
State-Changed-By: bouyer@NetBSD.org
State-Changed-When: Sat, 14 Mar 2015 10:54:35 +0000
State-Changed-Why:
Should be fixed in HEAD, the following revision should apply cleanly to
the netbsd-6 and netbsd-7 branches:
src/sys/arch/xen/include/evtchn.h 1.23
src/sys/arch/xen/xen/evtchn.c 1.71
src/sys/arch/xen/xen/pci_intr_machdep.c 1.17

please test !


From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/47720 CVS commit: [netbsd-7] src/sys/arch/xen
Date: Wed, 18 Mar 2015 04:42:11 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Wed Mar 18 04:42:11 UTC 2015

 Modified Files:
 	src/sys/arch/xen/include [netbsd-7]: evtchn.h
 	src/sys/arch/xen/xen [netbsd-7]: evtchn.c pci_intr_machdep.c

 Log Message:
 Pull up following revision(s) (requested by bouyer in ticket #618):
 	sys/arch/xen/include/evtchn.h: revision 1.23
 	sys/arch/xen/xen/evtchn.c: revision 1.71
 	sys/arch/xen/xen/pci_intr_machdep.c: revision 1.17
 Properly implemement pci_intr_disestablish(9), so that interrupt
 handlers stop being called when the device has been detached.
 Should fix PR port-xen/47720 (which turns out to not be related to raidframe).
 While there fix possible races in event_remove_handler() and pirq_establish().


 To generate a diff of this commit:
 cvs rdiff -u -r1.22 -r1.22.12.1 src/sys/arch/xen/include/evtchn.h
 cvs rdiff -u -r1.70 -r1.70.4.1 src/sys/arch/xen/xen/evtchn.c
 cvs rdiff -u -r1.16 -r1.16.4.1 src/sys/arch/xen/xen/pci_intr_machdep.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc: bouyer@NetBSD.org,
    port-xen-maintainer@netbsd.org,
    netbsd-bugs@netbsd.org,
    gnats-admin@netbsd.org,
    kimtwain0@gmail.com
Subject: Re: port-xen/47720 (Kernel Panic on dom0 shutdown or reboot when using RAIDframe)
Date: Wed, 18 Mar 2015 20:16:28 +0200

 bouyer@NetBSD.org wrote:
 > Should be fixed in HEAD, the following revision should apply cleanly to
 > the netbsd-6 and netbsd-7 branches:
 > src/sys/arch/xen/include/evtchn.h 1.23
 > src/sys/arch/xen/xen/evtchn.c 1.71
 > src/sys/arch/xen/xen/pci_intr_machdep.c 1.17
 > 
 > please test !

 I tested HEAD, and the panic no longer occurs.  Thank you!
 -- 
 Andreas Gustafsson, gson@gson.org

State-Changed-From-To: feedback->pending-pullups
State-Changed-By: bouyer@NetBSD.org
State-Changed-When: Wed, 18 Mar 2015 18:59:28 +0000
State-Changed-Why:
pullup-6 #1278. Already pulled up to netbsd-7. Shoud not be a problem on
netbsd-5.


From: "SAITOH Masanobu" <msaitoh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/47720 CVS commit: [netbsd-6] src/sys/arch/xen
Date: Tue, 14 Apr 2015 14:59:12 +0000

 Module Name:	src
 Committed By:	msaitoh
 Date:		Tue Apr 14 14:59:11 UTC 2015

 Modified Files:
 	src/sys/arch/xen/include [netbsd-6]: evtchn.h
 	src/sys/arch/xen/xen [netbsd-6]: evtchn.c pci_intr_machdep.c

 Log Message:
 Pull up following revision(s) (requested by bouyer in ticket #1278):
 	sys/arch/xen/include/evtchn.h: revision 1.23
 	sys/arch/xen/xen/evtchn.c: revision 1.71
 	sys/arch/xen/xen/pci_intr_machdep.c: revision 1.17
 Properly implemement pci_intr_disestablish(9), so that interrupt
 handlers stop being called when the device has been detached.
 Should fix PR port-xen/47720 (which turns out to not be related to raidframe).
 While there fix possible races in event_remove_handler() and pirq_establish().


 To generate a diff of this commit:
 cvs rdiff -u -r1.20 -r1.20.8.1 src/sys/arch/xen/include/evtchn.h
 cvs rdiff -u -r1.62.2.1 -r1.62.2.2 src/sys/arch/xen/xen/evtchn.c
 cvs rdiff -u -r1.15 -r1.15.8.1 src/sys/arch/xen/xen/pci_intr_machdep.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: pending-pullups->closed
State-Changed-By: bouyer@NetBSD.org
State-Changed-When: Tue, 14 Apr 2015 21:13:16 +0000
State-Changed-Why:
pulled up to netbsd-7 and netbsd-6


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.