search for: getblk

...t 2.4 defintion, but I don't care for obsolete junk). Index: src/super.c =================================================================== --- src/super.c (revision 1014) +++ src/super.c (working copy) @@ -799,7 +799,7 @@ /* get first two blocks */ for (i=0; i<2; i++) { - bhs[i] = getblk (OCFS_GET_BLOCKDEV(sb), i, 512); + bhs[i] = sb_getblk(sb, i); if (bhs[i] == NULL) { LOG_ERROR_STATUS(status = -EIO); goto leave; Index: src/journal.c =================================================================== --- src/journal.c (revision 1014) +++ src/journal.c (working copy) @@...

...ltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff8074c912, rsp = 0xffffffffab79fff0, rbp = 0xffffffffb4acf6f0 --- smp_tlb_shootdown() at smp_tlb_shootdown+0x82 pmap_invalidate_range() at pmap_invalidate_range+0xae vfs_vmio_release() at vfs_vmio_release+0x120 getnewbuf() at getnewbuf+0x7be getblk() at getblk+0x308 cluster_read() at cluster_read+0xc5 ffs_read() at ffs_read+0x37d vn_read() at vn_read+0x17b dofileread() at dofileread+0xa1 kern_preadv() at kern_preadv+0x66 pread() at pread+0x58 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (475, FreeBSD ELF64, pre...

...55/80] [journal_cancel_revoke+251/368] [do_get_write_access+1183/1216] Apr 17 21:40:13 mofo kernel: [<c015ca9b>] [<c015861f>] [<c02cbf85>] [<c0158677>] [<c015ca9b>] [<c015861f>] Apr 17 21:40:13 mofo kernel: [ext3_alloc_block+25/32] [ext3_alloc_branch+85/720] [getblk+40/96] [getblk+57/96] [bread+22/112] [ext3_do_update_inode+759/896] Apr 17 21:40:13 mofo kernel: [<c014f649>] [<c014f965>] [<c012e778>] [<c012e789>] [<c012e9c6>] [<c0152117>] Apr 17 21:40:13 mofo kernel: [ext3_do_update_inode+852/896] [do_get_write_access+118...

...*before* doing a journal_get_write_access() on its parent's buffer. Duh. - Four debugging fields have been removed from buffer_head. b_alloc_transaction, etc. These were debug fields which I couldn't find a use for in 2.4. In 2.2, these were set in ext3_new_block() when we do a getblk() on the new block. In 2.4, we don't do the getblk() any more... - Some tightening of the way commit feeds buffers into the request queues. At present, 256 buffers are fed into ll_rw_block() before we run tq_disk. I *was* pushing thousands down. It doesn't seem to make much diff...

...55/80] [journal_cancel_revoke+251/368] [do_get_write_access+1183/1216] Apr 17 21:40:13 mofo kernel: [<c015ca9b>] [<c015861f>] [<c02cbf85>] [<c0158677>] [<c015ca9b>] [<c015861f>] Apr 17 21:40:13 mofo kernel: [ext3_alloc_block+25/32] [ext3_alloc_branch+85/720] [getblk+40/96] [getblk+57/96] [bread+22/112] [ext3_do_update_inode+759/896] Apr 17 21:40:13 mofo kernel: [<c014f649>] [<c014f965>] [<c012e778>] [<c012e789>] [<c012e9c6>] [<c0152117>] Apr 17 21:40:13 mofo kernel: [ext3_do_update_inode+852/896] [do_get_write_access+118...

...c,1c,c532f900,0,c,...) at trap_fatal+0x2ce trap_pfault(e78e78ac,0,1c) at trap_pfault+0x1f7 trap(e78e0008,c06a0028,e78e0028,200012,d9156118,...) at trap+0x325 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc06fd937, esp = 0xe78e78ec, ebp = 0xe78e7914 --- getnewbuf(0,0,4000,4000) at getnewbuf+0x1bb getblk(c5964cc0,0,0,4000,0,...) at getblk+0x360 cluster_read(c5964cc0,46e5,0,0,0,...) at cluster_read+0xde ffs_read(e78e7b08) at ffs_read+0x25f VOP_READ_APV(c0a65560,e78e7b08) at VOP_READ_APV+0x38 nfsrv_read(c69b3800,c520d900,c532f900,e78e7c98,0,...) at nfsrv_read+0xb16 nfssvc_nfsd(c532f900) at nfssvc_nfs...

http://www.sample.banga.lt/crash.gif System - fully (except kernel) updated RedHat 7.3. Filesystems - ext3 in default ordered mode. What could be the cause of the crash? Kernel update will solve the problem? Thanks, Mindaugas

...1d 8b 41 04 8b 11 89 42 04 >>EIP; c0126506 <kmem_cache_alloc+66/b0> <===== Trace; c012f292 <get_unused_buffer_head+32/80> Trace; c012f31c <create_buffers+1c/e0> Trace; c0130782 <grow_dev_page+62/a0> Trace; c0130978 <grow_buffers+b8/100> Trace; c012efa6 <getblk+26/40> Trace; c015de42 <journal_get_descriptor_buffer+32/50> Trace; c014b6cc <read_kcore+17c/480> Trace; c0110760 <schedule+2c0/2f0> Trace; c015d92a <kjournald+10a/1a0> Trace; c015d800 <commit_timeout+0/10> Trace; c01054e8 <kernel_thread+28/40> Code; c0126506...

...(howto=260) at ../../kern/kern_shutdown.c:316 #2 0xc0236c04 in poweroff_wait (junk=0xc041ef00, howto=-813081692) at ../../kern/kern_shutdown.c:595 #3 0xc02310db in lockmgr (lkp=0xcf895bcc, flags=33620002, interlkp=0xc04f5be4, p=0xdfab4440) at ../../kern/kern_lock.c:337 #4 0xc025e010 in getblk (vp=0xde97cb40, blkno=41922624, size=16384, slpflag=0, slptimeo=0) at ../../sys/buf.h:305 #5 0xc025c16e in bread (vp=0xde97cb40, blkno=41922624, size=16384, cred=0x0, bpp=0xdfb05a7c) at ../../kern/vfs_bio.c:510 #6 0xc033901c in ffs_blkfree (ip=0xdfb05aa8, bno=10486952, size=16384) a...

...691 #9 0xc01d5233 in vop_stdbwrite (ap=0xd08d3d58) at /usr/src/sys/kern/vfs_default.c:344 #10 0xc01d5049 in vop_defaultop (ap=0xd08d3d58) at /usr/src/sys/kern/vfs_default.c:152 #11 0xc02b7185 in ufs_vnoperate (ap=0xd08d3d58) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2376 #12 0xc01d137a in getblk (vp=0xd0b28840, blkno=0, size=16384, slpflag=0, slptimeo=0) at vnode_if.h:1193 #13 0xc01d377a in cluster_read (vp=0xd0b28840, filesize=65536, lblkno=0, size=16384, cred=0x0, totread=260, seqcount=2, bpp=0xd08d3e44) at /usr/src/sys/kern/vfs_cluster.c:119 #14 0xc02af407 in ffs_read (ap...

...fer_uptodate(bh))) + err = -EIO; lock_journal(journal); goto wait_for_ctlbuf; } @@ -650,6 +661,8 @@ bh->b_end_io = journal_end_buffer_io_sync; submit_bh(WRITE, bh); wait_on_buffer(bh); + if (unlikely(!buffer_uptodate(bh))) + err = -EIO; put_bh(bh); /* One for getblk() */ journal_unlock_journal_head(descriptor); } @@ -661,6 +674,9 @@ skip_commit: /* The journal should be unlocked by now. */ + if (err) + __journal_abort_hard(journal); + /* Call any callbacks that had been registered for handles in this * transaction. It is up to the callback...

I have a FreeBSD 4.8-Release machine that I upgraded from a 4.5 or 4.4 machine. It works just great for about 9 days, then processes will not die. It starts to become a problem when I can't kill processes, restart services, connections hang, and I can't reboot or shutdown, I have to do a hard reset. I can't really find anything in the logs to indicate what is giving me

I've been playing around with snapshots lately but I've got a problem on one of my servers running 7-STABLE amd64: FreeBSD paladin 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8: Mon Nov 10 20:49:51 GMT 2008 tdb@paladin:/usr/obj/usr/src/sys/PALADIN amd64 I run the mksnap_ffs command to take the snapshot and some time later the system completely freezes up: paladin# cd /u2/.snap/ paladin#

...nt is zero cpuid = 5 KDB: stack backtrace: #0 0xffffffff80490268 at kdb_backtrace+0x68 #1 0xffffffff8045630a at panic+0x21a #2 0xffffffff8068bbc2 at vm_page_unwire+0x102 #3 0xffffffff804d857e at vfs_vmio_release+0x10e #4 0xffffffff804dadc8 at getnewbuf+0x468 #5 0xffffffff804dbb2f at getblk+0x5df #6 0xffffffff80632bb1 at ffs_balloc_ufs2+0x15c1 #7 0xffffffff8065a8d6 at ffs_write+0x246 #8 0xffffffff8070a18f at VOP_WRITE_APV+0x11f #9 0xffffffff80505e77 at vn_write+0x1f7 #10 0xffffffff80503b51 at vn_io_fault+0xb1 #11 0xffffffff804a387c at dofilewrite+0x9c #12 0xffffffff804a3...

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

....02 200573 2 0.03 185846 gen_ruby.ll 29 183851 4 0.02 169929 4 0.02 169929 gentwf.ll 1 55799 0 0.01 55766 0 0.01 55766 gesummv.ll 12 24932 0 0.01 24881 0 0.01 24881 getargs.ll 1 8175 0 0.01 8149 0 0.01 8149 get_audio.ll 19 84570 0 0.01 84539 0 0.01 84539 getbits.ll 8 20663 0 0.01 20628 0 0.01 20628 getblk.ll 4 82909 0 0.02 82874 0 0.01 82874 getDeleteCommand.ll 1 21890 0 0.01 21865 0 0.01 21865 getFloat.ll 1 6791 0 0.01 6766 0 0.01 6766 gethdr.ll 20 71934 0 0.01 71899 0 0.02 71899 getij.ll 1 8281 0 0.01 8255 0 0.01 8255 getInitCommand.ll 1 5634 0 0.01 5609 0 0.01 5609 getInsertCommand.ll 1 17537 0 0...