Re: RELENG_7 ata panic on atacontrol attach
On Wed, 1 Apr 2009, Alexander Motin wrote: AM AM AM atapci3: nVidia nForce MCP55 SATA300 controller port AM AM AM 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem AM AM 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 AM AM AM AM atacontrol detach ata7 AM AM - insert ATA disk (ad14) AM AM atacontrol attach ata7 AM AM AM pinics with Fatal trap 12: page fault while in kernel mode AM AM AM Any kernel verbose messages before it? AM AM Nope. Just AM AM ata7: [ITHREAD]^M AM ^M AM ^M AM Fatal trap 12: page fault while in kernel mode^M AM AM and approx 15 seconds of wait between ata channel detection and the panic. AM AM Are you sure that you have verbose messages enabled during boot or via AM sysctl? It looks a bit too quiet. Ah, you're right, on this server I turned off boot_verbose. Will recheck. AM RELENG_7 branch ATA maintenance is a bit difficult for me now due to big AM differences from the HEAD. It makes me wish to sync them as there is still AM too much time before 7.x EOL. May be I will do it after the 7.2 release AM process finished. Now is probably not the best time to do it. Fully understood. The only thing I wish to add is that RELENG_7 ata is much more picky in reinitializations (e.g., disk swaps) than RELENG_6. Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 ata panic on atacontrol attach
On Thu, 2 Apr 2009, Dmitry Morozovsky wrote: DM AM AM AM atapci3: nVidia nForce MCP55 SATA300 controller port DM AM AM DM AM 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem DM AM AM 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 DM AM AM AM AM atacontrol detach ata7 DM AM AM - insert ATA disk (ad14) DM AM AM atacontrol attach ata7 DM AM AM AM pinics with Fatal trap 12: page fault while in kernel mode DM AM AM AM Any kernel verbose messages before it? got it: ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7: [MPSAFE]^M ata7: [ITHREAD]^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB Seagate ST3750330AS SD04 at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M GEOM_LABEL: Label ufs/moose09 removed.^M [-- MARK -- Thu Apr 2 17:00:00 2009] GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M GEOM_LABEL: Label ufs/moose09 removed.^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7: ata7: [MPSAFE]^M CONNECT requested^M ata7: [ITHREAD]^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad: ad14 already exists; skipping it^M ad: ad14 already exists; skipping it^M ^M ^M Fatal trap 12: page fault while in kernel mode^M -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 ata panic on atacontrol attach
Dmitry Morozovsky wrote: On Thu, 2 Apr 2009, Dmitry Morozovsky wrote: DM AM AM AM atapci3: nVidia nForce MCP55 SATA300 controller port DM AM AM DM AM 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem DM AM AM 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 DM AM AM AM AM atacontrol detach ata7 DM AM AM - insert ATA disk (ad14) DM AM AM atacontrol attach ata7 DM AM AM AM pinics with Fatal trap 12: page fault while in kernel mode DM AM AM AM Any kernel verbose messages before it? got it: ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7: [MPSAFE]^M ata7: [ITHREAD]^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB Seagate ST3750330AS SD04 at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M GEOM_LABEL: Label ufs/moose09 removed.^M [-- MARK -- Thu Apr 2 17:00:00 2009] GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M GEOM_LABEL: Label ufs/moose09 removed.^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7: ata7: [MPSAFE]^M CONNECT requested^M ata7: [ITHREAD]^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M This looks like race between PATA reset sequence and SATA hot plug events. For AHCI it is handled by masking interrupts during reset. How it is expected to be done here, I am not sure. You can just disable hot plug by commenting respective part of of ata_sata_phy_check_events() function. ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad: ad14 already exists; skipping it^M ad: ad14 already exists; skipping it^M ^M ^M Fatal trap 12: page fault while in kernel mode^M It looks alike to crash I have already fixed on CURRENT: http://svn.freebsd.org/changeset/base/188464 -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 ata panic on atacontrol attach
On Thu, 2 Apr 2009, Alexander Motin wrote: AM ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M AM ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM ad: ad14 already exists; skipping it^M AM ad: ad14 already exists; skipping it^M AM ^M AM ^M AM Fatal trap 12: page fault while in kernel mode^M AM AM It looks alike to crash I have already fixed on CURRENT: AM http://svn.freebsd.org/changeset/base/188464 Seems to be. Would you please ask re@ for MFC approval? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 ata panic on atacontrol attach
Dmitry Morozovsky wrote: On Thu, 2 Apr 2009, Alexander Motin wrote: AM ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M AM ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM ad: ad14 already exists; skipping it^M AM ad: ad14 already exists; skipping it^M AM ^M AM ^M AM Fatal trap 12: page fault while in kernel mode^M AM AM It looks alike to crash I have already fixed on CURRENT: AM http://svn.freebsd.org/changeset/base/188464 Seems to be. Would you please ask re@ for MFC approval? This is not actually a fix for original problem, but it may help to avoid system crash. Can you confirm that it helps you, as I haven't tested it on STABLE yet, I am doing it now. If it helps, I will ask r...@. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 ata panic on atacontrol attach
On Thu, 2 Apr 2009, Alexander Motin wrote: AM Dmitry Morozovsky wrote: AM On Thu, 2 Apr 2009, Alexander Motin wrote: AM AM AM ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M AM AM ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM AM ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM AM ad: ad14 already exists; skipping it^M AM AM ad: ad14 already exists; skipping it^M AM AM ^M AM AM ^M AM AM Fatal trap 12: page fault while in kernel mode^M AM AM AM It looks alike to crash I have already fixed on CURRENT: AM AM http://svn.freebsd.org/changeset/base/188464 AM AM Seems to be. Would you please ask re@ for MFC approval? AM AM This is not actually a fix for original problem, but it may help to avoid AM system crash. Can you confirm that it helps you, as I haven't tested it on AM STABLE yet, I am doing it now. If it helps, I will ask r...@. Well, partially. Machine survived a dozed of detach-remove-insert-attach cycles (which it definitly could not before). However, it it still paniced on hot-remove-insert (could not dump): ata7: DISCONNECT requested^M ata7: DISCONNECTED^M GEOM_LABEL: Label ufs/moose09 removed.^M ata7: CONNECT requested^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=80 ostat1=00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M [a bunch of it] ata7: DISCONNECT requested^M ata7: ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB Seagate ST3750330AS SD04 at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB Seagate ST3750330AS SD04 at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB Seagate ST3750330AS SD04 at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB Seagate ST3750330AS SD04 at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB Seagate ST3750330AS SD04 at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB Seagate ST3750330AS SD04 at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M ^M ^M Fatal
Re: RELENG_7 ata panic on atacontrol attach
On Thu, 2 Apr 2009, Dmitry Morozovsky wrote: DM Some other hot reinserts finished successfully. Well, a couple minutes later after hot-reinsert machine paniced again (but now it seems related to ZFS): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x28 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0836964 stack pointer = 0x28:0xfa466bd4 frame pointer = 0x28:0xfa466be4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (arc_reclaim_thread) trap number = 12 panic: page fault cpuid = 1 Uptime: 11m8s Physical memory: 2039 MB Dumping 300 MB: 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0533535 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06cfce3 in trap_fatal (frame=0xfa466b94, eva=40) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc06cff40 in trap_pfault (frame=0xfa466b94, usermode=0, eva=40) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc06d08e6 in trap (frame=0xfa466b94) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc06b5b5b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0836964 in avl_destroy_nodes (tree=0xc9a2d540, cookie=0xfa466bf4) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:933 #8 0xc088b873 in mze_destroy (zap=Variable zap is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:175 #9 0xc088bbf3 in zap_evict (db=0xcca1cdac, vzap=0xc9a2d500) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:472 #10 0xc084c818 in dbuf_evict_user (db=0xcca1cdac) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:224 #11 0xc084d655 in dbuf_clear (db=0xcca1cdac) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1281 #12 0xc084d762 in dbuf_evict (db=0xcca1cdac) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:237 #13 0xc084db76 in dbuf_do_evict (private=0xc90d5cbc) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1458 #14 0xc0847517 in arc_do_user_evicts () at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1321 #15 0xc084a584 in arc_reclaim_thread (dummy=0x0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1551 #16 0xc050d877 in fork_exit (callout=0xc084a380 arc_reclaim_thread, arg=0x0, frame=0xfa466d38) at /usr/src/sys/kern/kern_fork.c:810 #17 0xc06b5bd0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RELENG_7/i386: ZFS constant panic on file system writes
Pawel, could you please help me a bit with *very* unpleasant situation: one of my servers with very large ZFS reboots on most write requests to one (largest, which effectively prohibits recreating) ZFS file system with panic: avl_find() succeeded inside avl_add() (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0533535 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0836a20 in avl_add (tree=Variable tree is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 #4 0xc088c39f in zap_lockdir (os=0xc555a590, obj=6108, tx=0x0, lti=RW_READER, fatreader=1, zapp=0xfc6907f8) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:231 #5 0xc088cc0f in zap_lookup (os=0xc555a590, zapobj=6108, name=0xfc6908bc daily.20080701.gz, integer_size=8, num_integers=1, buf=0xfc69083c) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:509 #6 0xc089e25d in zfs_dirent_lock (dlpp=0xfc690878, dzp=0xc709f570, name=0xfc6908bc daily.20080701.gz, zpp=0xfc690874, flag=Variable flag is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:173 #7 0xc089e43e in zfs_dirlook (dzp=0xc709f570, name=0xfc6908bc daily.20080701.gz, vpp=0xfc690b5c) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:271 #8 0xc08a8653 in zfs_freebsd_lookup (ap=0xfc690a00) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1080 #9 0xc06dab42 in VOP_CACHEDLOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a00) at vnode_if.c:153 #10 0xc05a402c in vfs_cache_lookup (ap=0xfc690a84) at vnode_if.h:83 #11 0xc06dc816 in VOP_LOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a84) at vnode_if.c:99 #12 0xc05aa681 in lookup (ndp=0xfc690b48) at vnode_if.h:57 #13 0xc05ab308 in namei (ndp=0xfc690b48) at /usr/src/sys/kern/vfs_lookup.c:215 #14 0xc05ba07f in kern_lstat (td=0xc5186af0, path=0xbfbfd088 Address 0xbfbfd088 out of bounds, pathseg=UIO_USERSPACE, sbp=0xfc690c18) at /usr/src/sys/kern/vfs_syscalls.c:2184 #15 0xc05ba22f in lstat (td=0xc5186af0, uap=0xfc690cfc) at /usr/src/sys/kern/vfs_syscalls.c:2167 #16 0xc06d0288 in syscall (frame=0xfc690d38) at /usr/src/sys/i386/i386/trap.c:1090 #17 0xc06b5bc0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #18 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) this is fresh RELENG_7/i386 with (I suppose, unrelated) patch to ata from mav@ Thanks in advance. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
7.2-PRERELEASE X-server hang in drmwtq
Hi. In last time, I have a problem with stability on my system: 7.2-PRERELEASE Thu Apr 2 20:20:31 MSD 2009 amd64 (UP); ati 9800-XT From time to time the x-server go in drmwtq state if the AIGLX is enabled. This usually happens when creating a new window. If I setup hw.dri.0.debug to 1, I get a lot of messages: [drm: pid1469: drm_ioctl] pid = 1469, cmd = 0x80046457, nr = 0x57, dev 0xff0001306800, auth = 1 [drm: pid1469: drm_ioctl] returning -1 I can see a recurring message in in ktrace: 1469 Xorg PSIG SIGALRM caught handler = 0x4dca90 mask = 0x0 code = 0x0 1469 Xorg CALL sigreturn (0x7fffe5b0) 1469 Xorg RET sigreturn JUSTRETURN 1469 Xorg CALL ioctl (0xa, 0x80046457, 0x8156e807c) 1469 Xorg RET ioctl RESTART The problems started after vblank rework in the STABLE. The first time I got a panic when i try to restart or shutdown x-server, but the problem with panic was solved (for me ;)) quickly. I am ready to provide any additional information. Many thanks for your work. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 7.2-BETA1 Available
The first of the test builds for the FreeBSD 7.2-RELEASE cycle is now
available. Testing of two recent changes to the system would be
particularly valuable. The bce(4) network driver was updated a few days
ago. And some significant work was done on the threading libraries a
short time ago that is known to fix several major issues but testing to
see if it introduced any regressions would be appreciated.
The target schedule for the release is available here:
http://www.freebsd.org/releases/7.2R/schedule.html
So far we're just one day off target (BETA1 builds started Tuesday).
The ISO images and FTP install trees are available on the FreeBSD Mirror
sites. Using the primary site as an example:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.2/
where ${arch} is one of amd64 i386, ia64, pc98, powerpc, or sparc64.
Checksums for the ISO images are at the bottom of this message. The
amd64 and i386 sets include a *preliminary* set of packages.
If you would like to do a source-based update to 7.2-BETA1 from an
already installed machine you can update your tree to RELENG_7 using
normal cvsup/csup methods.
The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases. Systems running 7.0-RELEASE or
7.1-RELEASE can upgrade as follows:
# freebsd-update upgrade -r 7.2-BETA1
During this process, FreeBSD Update may ask the user to help by merging
some configuration files or by confirming that the automatically performed
merging was done correctly.
# freebsd-update install
The system must be rebooted with the newly installed kernel before continuing.
# shutdown -r now
After rebooting, freebsd-update needs to be run again to install the new
userland components, and the system needs to be rebooted again:
# freebsd-update install
# shutdown -r now
Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to
upgrade to FreeBSD 7.2-BETA1, but will be prompted to rebuild all third-party
applications (e.g., anything installed from the ports tree) after the second
invocation of freebsd-update install, in order to handle differences in the
system libraries between FreeBSD 6.x and FreeBSD 7.x.
NOTE: Due to a recently uncovered bug, FreeBSD Update may fail while
downloading updates. If this occurs, please use the mirror
update1.freebsd.org, by running freebsd-update with the -s
update1.freebsd.org flag added; this mirror should be immune to this
bug.
Checksums:
MD5 (7.2-BETA1-amd64-bootonly.iso) = 112490bebd43f407bb8ef8bae2d0cc05
MD5 (7.2-BETA1-amd64-disc1.iso) = 742fd7ed423f77761ae6112a81931716
MD5 (7.2-BETA1-amd64-disc2.iso) = c733ea160e94b4e355c8da7dd54e4135
MD5 (7.2-BETA1-amd64-disc3.iso) = 0111313462034b4bca982e81d61ea17d
MD5 (7.2-BETA1-amd64-docs.iso) = 03b601464047aa483d2706577cfb3a74
MD5 (7.2-BETA1-amd64-dvd1.iso) = bd08de1b3bf525f7bd597d7f99b9a0fd
MD5 (7.2-BETA1-amd64-livefs.iso) = 9ed0331a0d612ea4e98c80b1447a45c6
MD5 (7.2-BETA1-i386-bootonly.iso) = 2ba4d30be7a95ff9ca91e3d4ef8a35f6
MD5 (7.2-BETA1-i386-disc1.iso) = 6933fd6b9f7ee500397c0c54aa831408
MD5 (7.2-BETA1-i386-disc2.iso) = bfc682aaec7f9df8919da31987c9d8fb
MD5 (7.2-BETA1-i386-disc3.iso) = 600030debe096c10b348c726462f9ce1
MD5 (7.2-BETA1-i386-docs.iso) = 04faa50ba321cf2b402c8a99828f58e2
MD5 (7.2-BETA1-i386-dvd1.iso) = 6603b9ca9c09b8c1c92613441bb154ad
MD5 (7.2-BETA1-i386-livefs.iso) = cda0a13ba0453e1d885c0c613f34c758
MD5 (7.2-BETA1-ia64-bootonly.iso) = b20eba8d3113ab8882c5c47e1a3df2d2
MD5 (7.2-BETA1-ia64-disc1.iso) = c208adb4539d9f0c9ee17133289e3601
MD5 (7.2-BETA1-ia64-disc2.iso) = eee4987b3686609658fdaccc5960070e
MD5 (7.2-BETA1-ia64-disc3.iso) = e7bb48a107e73955ece1a5c156060c34
MD5 (7.2-BETA1-ia64-docs.iso) = edc30334bb334f6adc53142af214a532
MD5 (7.2-BETA1-ia64-livefs.iso) = f6e54bb4cd582d20be8c8896b56d10b9
MD5 (7.2-BETA1-powerpc-bootonly.iso) = eadb2fa7cd289300f65e1bc246ec41bb
MD5 (7.2-BETA1-powerpc-disc1.iso) = 463352649f74208e3421c2bdda400e47
MD5 (7.2-BETA1-powerpc-disc2.iso) = 2ec54888eae7931e4ca869fd151856c2
MD5 (7.2-BETA1-powerpc-disc3.iso) = a657ec95fef82c98af1a111d74181dff
MD5 (7.2-BETA1-powerpc-docs.iso) = 4061d9d75aa86de96f0682695dd8040b
MD5 (7.2-BETA1-sparc64-bootonly.iso) = 93469eab2b36d3f3f1115f603252487d
MD5 (7.2-BETA1-sparc64-disc1.iso) = d517489f2048896cd8295f862bcfb6f2
MD5 (7.2-BETA1-sparc64-docs.iso) = e750843e3bb2c91aa31a8fdada2a062f
SHA256 (7.2-BETA1-amd64-bootonly.iso) =
88d4d5042a309ab3ccd701250919f81ec80d79c8b3854413919bc6070e456083
SHA256 (7.2-BETA1-amd64-disc1.iso) =
62f6eada40404630e0a98a5e9005a88053675285b4c5f40e7c8535d13f148805
SHA256 (7.2-BETA1-amd64-disc2.iso) =
40c6ad096eb02be1a3ce1dad4ace04e56557258ebb853969120819e8a81ca8aa
SHA256 (7.2-BETA1-amd64-disc3.iso) =
c3430a4e47d4a4428d5d4719b1ec8907b4a7b36d9c663c41ef02e9795a5ba9cb
SHA256 (7.2-BETA1-amd64-docs.iso) =
24dcf4707734439e1fc2c206cba12b951987314208706476386bf5d83fc65699
SHA256 (7.2-BETA1-amd64-dvd1.iso) =
Re: 7.2-PRERELEASE X-server hang in drmwtq
On Fri, 2009-04-03 at 02:23 +0400, Artem Kim wrote: Hi. In last time, I have a problem with stability on my system: 7.2-PRERELEASE Thu Apr 2 20:20:31 MSD 2009 amd64 (UP); ati 9800-XT From time to time the x-server go in drmwtq state if the AIGLX is enabled. This usually happens when creating a new window. If I setup hw.dri.0.debug to 1, I get a lot of messages: [drm: pid1469: drm_ioctl] pid = 1469, cmd = 0x80046457, nr = 0x57, dev 0xff0001306800, auth = 1 [drm: pid1469: drm_ioctl] returning -1 I can see a recurring message in in ktrace: 1469 Xorg PSIG SIGALRM caught handler = 0x4dca90 mask = 0x0 code = 0x0 1469 Xorg CALL sigreturn (0x7fffe5b0) 1469 Xorg RET sigreturn JUSTRETURN 1469 Xorg CALL ioctl (0xa, 0x80046457, 0x8156e807c) 1469 Xorg RET ioctl RESTART The problems started after vblank rework in the STABLE. The first time I got a panic when i try to restart or shutdown x-server, but the problem with panic was solved (for me ;)) quickly. I am ready to provide any additional information. Many thanks for your work. Ok, I haven't really seen a problem on ati. Intel is a nightmare... I think that I have it all sorted out now, but in order to deal with some of this, I am having to rework all of the drivers. robert. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
