NetBSD Problem Report #29291

From www@netbsd.org  Tue Feb  8 16:54:48 2005
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
	id 536D263B400; Tue,  8 Feb 2005 16:54:48 +0000 (UTC)
Message-Id: <20050208165448.536D263B400@narn.netbsd.org>
Date: Tue,  8 Feb 2005 16:54:48 +0000 (UTC)
From: kessi@teles.de
Reply-To: kessi@teles.de
To: gnats-bugs@netbsd.org
Subject: No kernel crash dump on panic
X-Send-Pr-Version: www-1.0

>Number:         29291
>Category:       kern
>Synopsis:       No kernel crash dump on panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 08 16:55:00 +0000 2005
>Closed-Date:    
>Last-Modified:  Wed Feb 16 15:11:00 +0000 2005
>Originator:     Jens Kessmeier
>Release:        2.0
>Organization:
TELES AG
>Environment:
NetBSD iswitch2.teles.de 2.0 NetBSD 2.0 (ISWITCH) #17: Thu Feb  3 12:46:08  2005  admin@COMPILE:/usr2/isdn/NetBSD-2.0/usr/src/sys/arch/i386/compile/ISWITCH i386

>Description:
A LKM, called tlsload, owns an interface to trigger a kernel crash dump. This interface calls panic. I think, the expected result is a
kernel crash dump or core dump, but no dump is written.

Feb  8 13:17:06 iswitch2 /netbsd: panic: BUGCHECK: 0x47110005 0x1 0xbbbbbbbb 0xcccccccc 0xdddddddd
Feb  8 13:17:06 iswitch2 /netbsd: 
Feb  8 13:17:06 iswitch2 /netbsd: Begin traceback...
Feb  8 13:17:06 iswitch2 /netbsd: load_bug_check(47110005,1,bbbbbbbb,cccccccc,dddddddd) at tlsload:load_bug_check+0x1f
Feb  8 13:17:06 iswitch2 /netbsd: tlsload_ioctl(a500,20004c12,c5146ea4,1,c4bcde5c) at tlsload:tlsload_ioctl+0x217
Feb  8 13:17:06 iswitch2 /netbsd: spec_ioctl(c5146d84,c0de095c,c5146dcc,c0759ff0,c05b8100) at netbsd:spec_ioctl+0x49
Feb  8 13:17:06 iswitch2 /netbsd: VOP_IOCTL2(c5686cd4,20004c12,c5146ea4,1,c0af2e80) at netbsd:VOP_IOCTL2+0x46
Feb  8 13:17:06 iswitch2 /netbsd: vn_ioctl(c4bc79d8,20004c12,c5146ea4,c4bcde5c,0) at netbsd:vn_ioctl+0x7b
Feb  8 13:17:06 iswitch2 /netbsd: sys_ioctl(c4b9ab58,c5146f64,c5146f5c,0,c0b57000) at netbsd:sys_ioctl+0x122
Feb  8 13:17:06 iswitch2 /netbsd: syscall_plain() at netbsd:syscall_plain+0x7e
Feb  8 13:17:06 iswitch2 /netbsd: --- syscall (number 54) ---
Feb  8 13:17:06 iswitch2 /netbsd: 0x480f43b3:
Feb  8 13:17:06 iswitch2 /netbsd: End traceback...
Feb  8 13:17:06 iswitch2 /netbsd: syncing disks... 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
Feb  8 13:17:06 iswitch2 /netbsd: 
Feb  8 13:17:06 iswitch2 /netbsd: dumping to dev 4,1 offset 1511
Feb  8 13:17:06 iswitch2 /netbsd: dump i/o error
Feb  8 13:17:06 iswitch2 /netbsd: 
Feb  8 13:17:06 iswitch2 /netbsd: 
Feb  8 13:17:06 iswitch2 /netbsd: sd0(ahc1:0:6:0): polling command not done
Feb  8 13:17:06 iswitch2 /netbsd: panic: scsipi_execute_xs
Feb  8 13:17:06 iswitch2 /netbsd: Begin traceback...
Feb  8 13:17:06 iswitch2 /netbsd: scsipi_execute_xs(c0b85128,c5146c14,a,0,a) at netbsd:scsipi_execute_xs+0x1b9
Feb  8 13:17:06 iswitch2 /netbsd: scsi_scsipi_cmd(c0bcc400,0,c5146c14,a,0) at netbsd:scsi_scsipi_cmd+0x2e
Feb  8 13:17:06 iswitch2 /netbsd: scsipi_command(c0bcc400,0,c5146c14,a,0) at netbsd:scsipi_command+0x48
Feb  8 13:17:06 iswitch2 /netbsd: sd_flush(c0bcd600,3,1,c4b9ab58,100) at netbsd:sd_flush+0x6d
Feb  8 13:17:06 iswitch2 /netbsd: sd_shutdown(c0bcd600,0,0,100,100) at netbsd:sd_shutdown+0x23
Feb  8 13:17:07 iswitch2 /netbsd: doshutdownhooks(c50a2280,0,c5146cbc,c037bf18,100) at netbsd:doshutdownhooks+0x2a
Feb  8 13:17:07 iswitch2 /netbsd: cpu_reboot(100,0,c4bb4a50,c4bafb88,1852) at netbsd:cpu_reboot+0x5e
Feb  8 13:17:07 iswitch2 /netbsd: panic(c50a2280,47110005,1,bbbbbbbb,cccccccc) at netbsd:panic+0x108
Feb  8 13:17:07 iswitch2 /netbsd: load_bug_check(47110005,1,bbbbbbbb,cccccccc,dddddddd) at tlsload:load_bug_check+0x1f
Feb  8 13:17:07 iswitch2 /netbsd: tlsload_ioctl(a500,20004c12,c5146ea4,1,c4bcde5c) at tlsload:tlsload_ioctl+0x217
Feb  8 13:17:07 iswitch2 /netbsd: spec_ioctl(c5146d84,c0de095c,c5146dcc,c0759ff0,c05b8100) at netbsd:spec_ioctl+0x49
Feb  8 13:17:07 iswitch2 /netbsd: VOP_IOCTL2(c5686cd4,20004c12,c5146ea4,1,c0af2e80) at netbsd:VOP_IOCTL2+0x46
Feb  8 13:17:07 iswitch2 /netbsd: vn_ioctl(c4bc79d8,20004c12,c5146ea4,c4bcde5c,0) at netbsd:vn_ioctl+0x7b
Feb  8 13:17:07 iswitch2 /netbsd: sys_ioctl(c4b9ab58,c5146f64,c5146f5c,0,c0b57000) at netbsd:sys_ioctl+0x122
Feb  8 13:17:07 iswitch2 /netbsd: syscall_plain() at netbsd:syscall_plain+0x7e
Feb  8 13:17:07 iswitch2 /netbsd: --- syscall (number 54) ---
Feb  8 13:17:07 iswitch2 /netbsd: 0x480f43b3:
Feb  8 13:17:07 iswitch2 /netbsd: End traceback...
Feb  8 13:17:07 iswitch2 /netbsd: 
Feb  8 13:17:07 iswitch2 /netbsd: dumping to dev 4,1 offset 1511
Feb  8 13:17:07 iswitch2 /netbsd: dump device not ready
Feb  8 13:17:07 iswitch2 /netbsd: 
Feb  8 13:17:07 iswitch2 /netbsd: 
Feb  8 13:17:07 iswitch2 /netbsd: rebooting...
Feb  8 13:17:07 iswitch2 /netbsd: NetBSD 2.0 (ISWITCH) #17: Thu Feb  3 12:46:08  2005
Feb  8 13:17:07 iswitch2 /netbsd: 	admin@COMPILE:/usr2/isdn/NetBSD-2.0/usr/src/sys/arch/i386/compile/ISWITCH
Feb  8 13:17:07 iswitch2 /netbsd: total memory = 127 MB
Feb  8 13:17:07 iswitch2 /netbsd: avail memory = 117 MB
Feb  8 13:17:07 iswitch2 /netbsd: BIOS32 rev. 0 found at 0xfd820
Feb  8 13:17:07 iswitch2 /netbsd: mainbus0 (root)
Feb  8 13:17:07 iswitch2 /netbsd: cpu0 at mainbus0: (uniprocessor)
Feb  8 13:17:07 iswitch2 /netbsd: cpu0: Intel Mobile Pentium II (686-class), 333.29 MHz, id 0x66a
Feb  8 13:17:07 iswitch2 /netbsd: cpu0: features 183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR>
Feb  8 13:17:07 iswitch2 /netbsd: cpu0: features 183f9ff<PGE,MCA,CMOV,PAT,PSE36,MMX>
Feb  8 13:17:07 iswitch2 /netbsd: cpu0: features 183f9ff<FXSR>
Feb  8 13:17:07 iswitch2 /netbsd: cpu0: I-cache 16 KB 32B/line 4-way, D-cache 16 KB 32B/line 4-way
Feb  8 13:17:07 iswitch2 /netbsd: cpu0: L2 cache 256 KB 32B/line 4-way
Feb  8 13:17:07 iswitch2 /netbsd: cpu0: ITLB 32 4 KB entries 4-way, 2 4 MB entries fully associative
Feb  8 13:17:07 iswitch2 /netbsd: cpu0: DTLB 64 4 KB entries 4-way, 8 4 MB entries 4-way
Feb  8 13:17:07 iswitch2 /netbsd: cpu0: 16 page colors
Feb  8 13:17:07 iswitch2 /netbsd: pci0 at mainbus0 bus 0: configuration mode 1
Feb  8 13:17:07 iswitch2 /netbsd: pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
Feb  8 13:17:07 iswitch2 /netbsd: pchb0 at pci0 dev 0 function 0
Feb  8 13:17:07 iswitch2 /netbsd: pchb0: Intel 82443BX Host Bridge/Controller (rev. 0x03)
Feb  8 13:17:07 iswitch2 /netbsd: agp0 at pchb0: aperture at 0xf8000000, size 0x4000000
Feb  8 13:17:07 iswitch2 /netbsd: ppb0 at pci0 dev 1 function 0: Intel 82443BX AGP Interface (rev. 0x03)
Feb  8 13:17:08 iswitch2 /netbsd: pci1 at ppb0 bus 1
Feb  8 13:17:08 iswitch2 /netbsd: pci1: i/o space, memory space enabled
Feb  8 13:17:08 iswitch2 /netbsd: vga1 at pci1 dev 0 function 0: Intel i740 Graphics Accelerator (rev. 0x21)
Feb  8 13:17:08 iswitch2 /netbsd: wsdisplay0 at vga1 kbdmux 1: console (80x25, vt100 emulation)
Feb  8 13:17:08 iswitch2 /netbsd: wsmux1: connecting to wsdisplay0
Feb  8 13:17:08 iswitch2 /netbsd: pcib0 at pci0 dev 7 function 0
Feb  8 13:17:08 iswitch2 /netbsd: pcib0: Intel 82371AB PCI-to-ISA Bridge (PIIX4) (rev. 0x02)
Feb  8 13:17:08 iswitch2 /netbsd: piixide0 at pci0 dev 7 function 1
Feb  8 13:17:08 iswitch2 /netbsd: piixide0: Intel 82371AB IDE controller (PIIX4) (rev. 0x01)
Feb  8 13:17:08 iswitch2 /netbsd: piixide0: device disabled (at device)
Feb  8 13:17:08 iswitch2 /netbsd: uhci0 at pci0 dev 7 function 2: Intel 82371AB USB Host Controller (PIIX4) (rev. 0x01)
Feb  8 13:17:08 iswitch2 /netbsd: uhci0: interrupting at irq 10
Feb  8 13:17:08 iswitch2 /netbsd: usb0 at uhci0: USB revision 1.0
Feb  8 13:17:08 iswitch2 /netbsd: uhub0 at usb0
Feb  8 13:17:09 iswitch2 /netbsd: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
Feb  8 13:17:09 iswitch2 /netbsd: uhub0: 2 ports with 2 removable, self powered
Feb  8 13:17:09 iswitch2 /netbsd: Intel 82371AB Power Management Controller (PIIX4) (miscellaneous bridge, revision 0x02) at pci0 dev 7 function 3 not configured
Feb  8 13:17:09 iswitch2 /netbsd: ppb1 at pci0 dev 17 function 0: Digital Equipment DECchip 21150 PCI-PCI Bridge (rev. 0x04)
Feb  8 13:17:09 iswitch2 /netbsd: pci2 at ppb1 bus 2
Feb  8 13:17:09 iswitch2 /netbsd: pci2: i/o space, memory space enabled, rd/line, wr/inv ok
Feb  8 13:17:09 iswitch2 /netbsd: fxp0 at pci0 dev 18 function 0: i82559 Ethernet, rev 8
Feb  8 13:17:09 iswitch2 /netbsd: fxp0: interrupting at irq 5
Feb  8 13:17:09 iswitch2 /netbsd: fxp0: Ethernet address 08:00:3e:2a:36:63
Feb  8 13:17:09 iswitch2 /netbsd: inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
Feb  8 13:17:09 iswitch2 /netbsd: inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Feb  8 13:17:09 iswitch2 /netbsd: fxp1 at pci0 dev 19 function 0: i82559 Ethernet, rev 8
Feb  8 13:17:09 iswitch2 /netbsd: fxp1: interrupting at irq 10
Feb  8 13:17:09 iswitch2 /netbsd: fxp1: Ethernet address 08:00:3e:2a:36:62
Feb  8 13:17:09 iswitch2 /netbsd: inphy1 at fxp1 phy 1: i82555 10/100 media interface, rev. 4
Feb  8 13:17:09 iswitch2 /netbsd: inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Feb  8 13:17:09 iswitch2 /netbsd: ahc1 at pci0 dev 20 function 0: Adaptec aic7880 Ultra SCSI adapter
Feb  8 13:17:09 iswitch2 /netbsd: ahc1: interrupting at irq 10
Feb  8 13:17:09 iswitch2 /netbsd: ahc1: aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
Feb  8 13:17:09 iswitch2 /netbsd: scsibus0 at ahc1: 16 targets, 8 luns per target
Feb  8 13:17:09 iswitch2 /netbsd: isa0 at pcib0
Feb  8 13:17:10 iswitch2 /netbsd: com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
Feb  8 13:17:10 iswitch2 /netbsd: com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
Feb  8 13:17:10 iswitch2 /netbsd: pckbc0 at isa0 port 0x60-0x64
Feb  8 13:17:10 iswitch2 /netbsd: pckbd0 at pckbc0 (kbd slot)
Feb  8 13:17:10 iswitch2 /netbsd: pckbc0: using irq 1 for kbd slot
Feb  8 13:17:10 iswitch2 /netbsd: wskbd0 at pckbd0: console keyboard, using wsdisplay0
Feb  8 13:17:10 iswitch2 /netbsd: pms0 at pckbc0 (aux slot)
Feb  8 13:17:10 iswitch2 /netbsd: pckbc0: using irq 12 for aux slot
Feb  8 13:17:10 iswitch2 /netbsd: wsmouse0 at pms0 mux 0
Feb  8 13:17:10 iswitch2 /netbsd: pcppi0 at isa0 port 0x61
Feb  8 13:17:10 iswitch2 /netbsd: midi0 at pcppi0: PC speaker
Feb  8 13:17:10 iswitch2 /netbsd: sysbeep0 at pcppi0
Feb  8 13:17:10 iswitch2 /netbsd: isapnp0 at isa0 port 0x279: ISA Plug 'n Play device support
Feb  8 13:17:10 iswitch2 /netbsd: npx0 at isa0 port 0xf0-0xff: using exception 16
Feb  8 13:17:10 iswitch2 /netbsd: fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
Feb  8 13:17:10 iswitch2 /netbsd: isapnp0: no ISA Plug 'n Play devices found
Feb  8 13:17:10 iswitch2 /netbsd: fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
Feb  8 13:17:10 iswitch2 /netbsd: Kernelized RAIDframe activated
Feb  8 13:17:10 iswitch2 /netbsd: scsibus0: waiting 2 seconds for devices to settle...
Feb  8 13:17:10 iswitch2 /netbsd: sd0 at scsibus0 target 6 lun 0: <IBM, DDRS-34560W, S97B> disk fixed
Feb  8 13:17:10 iswitch2 /netbsd: sd0: 4357 MB, 8387 cyl, 5 head, 212 sec, 512 bytes/sect x 8925000 sectors
Feb  8 13:17:10 iswitch2 /netbsd: sd0: sync (172.00ns offset 8), 16-bit (11.626MB/s) transfers, tagged queueing
Feb  8 13:17:10 iswitch2 /netbsd: boot device: sd0
Feb  8 13:17:10 iswitch2 /netbsd: root on sd0a dumps on sd0b
Feb  8 13:17:10 iswitch2 /netbsd: root file system type: ffs
Feb  8 13:17:10 iswitch2 /netbsd: wsdisplay0: screen 1 added (80x25, vt100 emulation)
Feb  8 13:17:10 iswitch2 /netbsd: wsdisplay0: screen 2 added (80x25, vt100 emulation)
Feb  8 13:17:11 iswitch2 /netbsd: wsdisplay0: screen 3 added (80x25, vt100 emulation)
Feb  8 13:17:11 iswitch2 /netbsd: wsdisplay0: screen 4 added (80x25, vt100 emulation)
Feb  8 13:17:07 iswitch2 savecore: no core dump

>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:
From: fredb@immanent.net (Frederick Bruckman)
To: kessi@teles.de, gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/29291: No kernel crash dump on panic
Date: Fri, 11 Feb 2005 17:09:29 -0600 (CST)

 In article <20050208165500.5355563B845@narn.netbsd.org>,
 	kessi@teles.de writes:

 > A LKM, called tlsload, owns an interface to trigger a kernel crash dump. This interface calls panic. I think, the expected result is a
 > kernel crash dump or core dump, but no dump is written.
 > 
 > Feb  8 13:17:06 iswitch2 /netbsd: --- syscall (number 54) ---
 > Feb  8 13:17:06 iswitch2 /netbsd: 0x480f43b3:
 > Feb  8 13:17:06 iswitch2 /netbsd: End traceback...
 > Feb  8 13:17:06 iswitch2 /netbsd: syncing disks... 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
 > Feb  8 13:17:06 iswitch2 /netbsd: 
 > Feb  8 13:17:06 iswitch2 /netbsd: dumping to dev 4,1 offset 1511
 > Feb  8 13:17:06 iswitch2 /netbsd: dump i/o error
 > Feb  8 13:17:06 iswitch2 /netbsd: 
 > Feb  8 13:17:06 iswitch2 /netbsd: 
 > Feb  8 13:17:06 iswitch2 /netbsd: sd0(ahc1:0:6:0): polling command not done
 > Feb  8 13:17:06 iswitch2 /netbsd: panic: scsipi_execute_xs

 In my experience, after a failed "sync" attempt, the scsi driver is usually
 too horked for the dump to take. If you set DDB_ONPANIC in the kernel config
 or with sysctl (see panic(9)), you'll drop into ddb, where you can try to skip
 the sync with "reboot 0x104". The 0x4 flag means "don't sync". (See ddb(4)).
 The apparently undocumented 0x100 flag means "try to dump".


 Frederick

From: Jens Kessmeier <j.kessmeier@teles.de>
To: "'gnats-bugs@gnats.netbsd.org'" <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: kern/29291
Date: Mon, 14 Feb 2005 16:57:50 +0100

 Pretty new information about ddb(4), reboot, DDB_ONPANIC, panic(9). Nice to
 know it.

 You say: In my experience, after a failed "sync" attempt, the scsi driver is
 usually too horked for the dump to take.

 Right, that is our problem. If you repeat my test stuff, or something else
 with a panic, you will see 80 times no dump and
 1 time a dump. Your solution is fine in development. For a crashed server
 machine far from home, in a dark room, on weekend, at night with your
 girlfriend,  you will drive or what ever to the console? Please, please say
 that is not what you want.

 Let us talk about another solution. Why failed the "sync" or why is the scsi
 driver too horked?

From: fredb@immanent.net (Frederick Bruckman)
To: Jens Kessmeier <j.kessmeier@teles.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/29291
Date: Mon, 14 Feb 2005 11:48:57 -0600 (CST)

 In article <20050214155701.A371963B845@narn.netbsd.org>,
 	Jens Kessmeier <j.kessmeier@teles.de> writes:
 >  
 >  You say: In my experience, after a failed "sync" attempt, the scsi driver is
 >  usually too horked for the dump to take.
 >  
 >  Right, that is our problem. If you repeat my test stuff, or something else
 >  with a panic, you will see 80 times no dump and
 >  1 time a dump. Your solution is fine in development. For a crashed server
 >  machine far from home, in a dark room, on weekend, at night with your
 >  girlfriend,  you will drive or what ever to the console? Please, please say
 >  that is not what you want.

 Huh? So why don't you tell us exactly what you want to hear?

 Notice that, in your original example, panic(9) with no ddb
 still managed to reboot, which is generally what you'd want
 in a production environment. The detailed issue is that the
 second panic in scsipi_execute_xs() caused an immediate reboot
 (as panic(9) is documented to do), because to continue under
 those conditions could be damaging to the file store, and is
 not likely to produce a useful core in any case.

 >  Let us talk about another solution. Why failed the "sync" or why is the scsi
 >  driver too horked?

 I guess your LKM corrupted some critical kernel data structure.
 You must know, that it's a monolithic kernel -- so it's always
 going to be possible for an LKM to screw things up very badly,
 so badly that even a core dump is impossible.


 Frederick

State-Changed-From-To: open->closed
State-Changed-By: fredb@netbsd.org
State-Changed-When: Mon, 14 Feb 2005 19:51:32 +0000
State-Changed-Why:

There's no bug here. If you really, really wanted to force
a coredump unconditionally, you could call reboot(2) directly.

I have updated the ddb(4) man page to reflect how to force
a coredump (in ddb).

Good luck with debugging your LKM, and thanks for using NetBSD.



From: Jens Kessmeier <j.kessmeier@teles.de>
To: "'gnats-bugs@gnats.netbsd.org'" <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: kern/29291
Date: Tue, 15 Feb 2005 10:50:24 +0100

 Frederick what are you doing? 

 You closed the Bugreport and that is not right! What are the facts? You are
 guessing, you say you know what i want,
 you read uncarefully, do not understand humor and make me believe, that i am
 stupid and then you decied there is no
 bug and close the report. I am angry! I like NetBSD! It is fantastic to work
 with this operating system. All the people, who are
 working on NetBSD, do a great job. And then you, who are you?

 Grrr, i must cool down. Perhaps it is possible to explain the bug a second
 time. 

 Jens Kessmeier

From: Allen Briggs <briggs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/29291
Date: Tue, 15 Feb 2005 09:53:33 -0500

 >  Grrr, i must cool down. Perhaps it is possible to explain the bug a second
 >  time. 

 In my reading of the PR, I think it would make sense to
 research a little more and file a new PR.  Or two.

 It looks to me like there are two problems here:

 	* "syncing disks" fails.  It would be good to understand why--
 	  perhaps this is something caused by the LKM or where it's
 	  panicing.

 	* Dumping fails after the sync fails.  This is something that
 	  it might be possible to fix, but it is not clear what,
 	  specifically, is broken.  Perhaps we can do something in
 	  the SCSI driver to reset things before attempting the dump.

 In any case, these are two different, but possibly related, issues
 that should probably have separate PRs.  If you're working on an LKM,
 perhaps you have the resources to help narrow down each of these a
 bit more and file a new PR for each of these.  Since you have a system
 where you can readily reproduce the issues, you're in a good position
 to help track it down.

 Thanks,
 -allen

 -- 
                   Use NetBSD!  http://www.netbsd.org/

State-Changed-From-To: closed->open
State-Changed-By: fredb@netbsd.org
State-Changed-When: Tue, 15 Feb 2005 20:02:45 +0000
State-Changed-Why:

Re-opened at user's request.



From: Jens Kessmeier <j.kessmeier@teles.de>
To: "'gnats-bugs@gnats.netbsd.org'" <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: kern/29291
Date: Wed, 16 Feb 2005 16:11:47 +0100

 This is a word! Thank you Allen.

 I will file a new PR for each of these. The first one is "syncing disk
 fails" (kern/29400).

>Unformatted:

Home	PR Database Search