Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk
On Sun, 3 Feb 2008, Kostik Belousov wrote:
KB Di you have the UFS volume mounted from the eSATA drive ? If yes, then the
KB panic is the natural consequence of the device disappearing from under the
KB UFS. If not, and fault address 0x3020e0b30 looks suspicious, it could mean
KB some kernel memory corruption.
yes, there is (were) UFS2 on eSATA.
KB Anyway, it would be interesting to look at the vnode vp content from the
KB frame #10, and to lookup the mount point together with a device it comes
KB from.
(kgdb) fr 10
#10 0x8029dcf3 in vn_stat (vp=0xff004728b9b0,
sb=0xd79f79f0, active_cred=Variable active_cred is not available.
) at vnode_if.h:286
286 vnode_if.h: No such file or directory.
in vnode_if.h
(kgdb) p vp
$1 = (struct vnode *) 0xff004728b9b0
(kgdb) p *vp
$2 = {v_type = VDIR, v_tag = 0x8039319c ufs, v_op =
0x804e98e0, v_data = 0xff003fab0480, v_mount = 0xff00050dc650,
v_nmntvnodes = {
tqe_next = 0xff004728bba0, tqe_prev = 0xff004728f218}, v_un =
{vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist
= {le_next = 0x0,
le_prev = 0x808c10e0}, v_hash = 215211, v_cache_src = {lh_first =
0xff003f4d5000}, v_cache_dst = {tqh_first = 0xff0026fcca90, tqh_last =
0xff0026fccab0},
v_dd = 0xff00470a49b0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen =
0, v_lock = {lk_object = {lo_name = 0x8039319c ufs, lo_type =
0x8039319c ufs,
lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0},
lod_witness = 0x0}}, lk_interlock = 0x80514730, lk_flags = 262208,
lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 51,
lk_lockholder = 0xff000179c340, lk_newlock = 0x0}, v_interlock =
{lock_object = {
lo_name = 0x8039e4da vnode interlock, lo_type =
0x8039e4da vnode interlock, lo_flags = 16973824, lo_witness_data =
{lod_list = {stqe_next = 0x0},
lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock =
0xff004728ba48, v_holdcnt = 3, v_usecount = 2, v_iflag = 0, v_vflag = 0,
v_writecount = 0,
v_freelist = {tqe_next = 0x0, tqe_prev = 0xff004728b900}, v_bufobj =
{bo_mtx = 0xff004728ba98, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last =
0xff004728bb08},
bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0,
tqh_last = 0xff004728bb28}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0,
bo_flag = 0,
bo_ops = 0x804dd3e0, bo_bsize = 65536, bo_object =
0xff0047994680, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private =
0xff004728b9b0,
__bo_vnode = 0xff004728b9b0}, v_pollinfo = 0x0, v_label = 0x0}
I think tere are at least two problems here:
- panic when non-essential UFS mounted partition disappears
- particular disappearing eSATA drive from eSATA channel of TX4. Relevant error
messages are
Feb 2 19:29:18 kern.crit hamster kernel: ata7: reiniting channel ..
Feb 2 19:29:18 kern.crit hamster kernel: ata7: SATA connect time=0ms
Feb 2 19:29:18 kern.crit hamster kernel: ata7: reset tp1 mask=01 ostat0=d0
ostat1=00
Feb 2 19:29:18 kern.crit hamster kernel: ata7: stat0=0xd0 err=0x00 lsb=0x36
msb=0x72
Feb 2 19:29:26 kern.crit hamster last message repeated 87 times
Feb 2 19:29:27 kern.crit hamster kernel:
Feb 2 19:29:27 kern.crit hamster kernel: ata7: stat0=0xd0 err=0x00 lsb=0x36
msb=0x72
Feb 2 19:29:49 kern.crit hamster last message repeated 221 times
Feb 2 19:29:49 kern.crit hamster kernel: ata7: reset tp2 stat0=d0 stat1=00
devices=0x0
Feb 2 19:29:49 kern.crit hamster kernel: ad14: FAILURE - device detached
Feb 2 19:29:49 kern.crit hamster kernel: ad1g4_:v fdse_tdaocnhee(d):
Feb 2 19:29:49 kern.crit hamster kernel: ad14a[aRtEaA7D:( orfefisneitt=
d1o2n4e0 9.1.43
Feb 2 19:29:49 kern.crit hamster kernel: 2960, length=131072)]error = 6
Feb 2 19:29:49 kern.crit hamster kernel:
g_vfs_done():ad14a[READ(offset=124091564032, length=131072)]error = 6
Feb 2 19:29:49 kern.crit hamster kernel:
g_vfs_done():ad14a[READ(offset=124091695104, length=131072)]error = 6
... and zillion of g_vfs_gone after.
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Broadcom Netlink BCM5906M
Hi! There is any plan for the ethernet driver Broadcom BCM5906M? I have a new laptop (Dell Vostro 1400) with this ethernet, but doesn't work with bge or any b*e driver :-( Thank you very much and please, excuse me the cross-posting. -- Have a nice day ;-) TooManySecrets Dijo Confucio: Exígete mucho a ti mismo y espera poco de los demás. Así te ahorrarás disgustos. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Broadcom Netlink BCM5906M
I have a dell vostro 1000 and I had the nic working under 6.2 using NDIS but I have have not been able to get my NIC working under 6.3 or 7 using any windows drivers and ndis. Darran http://www.deejc.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of TooMany Secrets Sent: 03 February 2008 09:48 To: freebsd-stable Cc: [EMAIL PROTECTED] Subject: Broadcom Netlink BCM5906M Hi! There is any plan for the ethernet driver Broadcom BCM5906M? I have a new laptop (Dell Vostro 1400) with this ethernet, but doesn't work with bge or any b*e driver :-( Thank you very much and please, excuse me the cross-posting. -- Have a nice day ;-) TooManySecrets Dijo Confucio: Exígete mucho a ti mismo y espera poco de los demás. Así te ahorrarás disgustos. smime.p7s Description: S/MIME cryptographic signature
[releng_7 tinderbox] failure on amd64/amd64
TB --- 2008-02-03 08:49:47 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-03 08:49:47 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2008-02-03 08:49:47 - cleaning the object tree TB --- 2008-02-03 08:50:15 - cvsupping the source tree TB --- 2008-02-03 08:50:15 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2008-02-03 08:50:22 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-03 08:50:22 - cd /src TB --- 2008-02-03 08:50:22 - /usr/bin/make -B buildworld World build started on Sun Feb 3 08:50:23 UTC 2008 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Sun Feb 3 10:18:11 UTC 2008 TB --- 2008-02-03 10:18:11 - generating LINT kernel config TB --- 2008-02-03 10:18:11 - cd /src/sys/amd64/conf TB --- 2008-02-03 10:18:11 - /usr/bin/make -B LINT TB --- 2008-02-03 10:18:11 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-03 10:18:11 - cd /src TB --- 2008-02-03 10:18:11 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Feb 3 10:18:11 UTC 2008 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rp/../../dev/rp/rp.c cc -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rp/../../dev/rp/rp_pci.c ld -d -warn-common -r -d -o rp.ko rp.o rp_pci.o : export_syms awk -f /src/sys/modules/rp/../../conf/kmod_syms.awk rp.ko export_syms | xargs -J% objcopy % rp.ko objcopy --strip-debug rp.ko === rr232x (all) make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-03 10:36:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-03 10:36:43 - ERROR: failed to build lint kernel TB --- 2008-02-03 10:36:43 - tinderbox aborted TB --- 5427.78 user 562.95 system 6415.42 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk
On Sun, Feb 03, 2008 at 12:05:44PM +0300, Dmitry Morozovsky wrote:
On Sun, 3 Feb 2008, Kostik Belousov wrote:
KB Di you have the UFS volume mounted from the eSATA drive ? If yes, then the
KB panic is the natural consequence of the device disappearing from under the
KB UFS. If not, and fault address 0x3020e0b30 looks suspicious, it could mean
KB some kernel memory corruption.
yes, there is (were) UFS2 on eSATA.
KB Anyway, it would be interesting to look at the vnode vp content from the
KB frame #10, and to lookup the mount point together with a device it comes
KB from.
(kgdb) fr 10
#10 0x8029dcf3 in vn_stat (vp=0xff004728b9b0,
sb=0xd79f79f0, active_cred=Variable active_cred is not available.
) at vnode_if.h:286
286 vnode_if.h: No such file or directory.
in vnode_if.h
(kgdb) p vp
$1 = (struct vnode *) 0xff004728b9b0
(kgdb) p *vp
$2 = {v_type = VDIR, v_tag = 0x8039319c ufs, v_op =
0x804e98e0, v_data = 0xff003fab0480, v_mount =
0xff00050dc650,
The *v_mount and *(struct ufs_mount *)(v_mount-mnt_data) content shall
be enough to confirm that vnode comes from the lost partition.
v_nmntvnodes = {
tqe_next = 0xff004728bba0, tqe_prev = 0xff004728f218}, v_un =
{vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0},
v_hashlist
= {le_next = 0x0,
le_prev = 0x808c10e0}, v_hash = 215211, v_cache_src = {lh_first =
0xff003f4d5000}, v_cache_dst = {tqh_first = 0xff0026fcca90, tqh_last
=
0xff0026fccab0},
v_dd = 0xff00470a49b0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen =
0, v_lock = {lk_object = {lo_name = 0x8039319c ufs, lo_type =
0x8039319c ufs,
lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0},
lod_witness = 0x0}}, lk_interlock = 0x80514730, lk_flags = 262208,
lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 51,
lk_lockholder = 0xff000179c340, lk_newlock = 0x0}, v_interlock =
{lock_object = {
lo_name = 0x8039e4da vnode interlock, lo_type =
0x8039e4da vnode interlock, lo_flags = 16973824, lo_witness_data =
{lod_list = {stqe_next = 0x0},
lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock =
0xff004728ba48, v_holdcnt = 3, v_usecount = 2, v_iflag = 0, v_vflag = 0,
v_writecount = 0,
v_freelist = {tqe_next = 0x0, tqe_prev = 0xff004728b900}, v_bufobj =
{bo_mtx = 0xff004728ba98, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last
=
0xff004728bb08},
bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0,
tqh_last = 0xff004728bb28}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0,
bo_flag = 0,
bo_ops = 0x804dd3e0, bo_bsize = 65536, bo_object =
0xff0047994680, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private
=
0xff004728b9b0,
__bo_vnode = 0xff004728b9b0}, v_pollinfo = 0x0, v_label = 0x0}
I think tere are at least two problems here:
- panic when non-essential UFS mounted partition disappears
Unfortunately, FreeBSD has no concept of the unessential mount; I wish
the mount option onerror=nopanic too :).
- particular disappearing eSATA drive from eSATA channel of TX4. Relevant
error
messages are
This looks more like the hardware problem, and it only induced the known
kernel deficiency.
Feb 2 19:29:18 kern.crit hamster kernel: ata7: reiniting channel ..
Feb 2 19:29:18 kern.crit hamster kernel: ata7: SATA connect time=0ms
Feb 2 19:29:18 kern.crit hamster kernel: ata7: reset tp1 mask=01 ostat0=d0
ostat1=00
Feb 2 19:29:18 kern.crit hamster kernel: ata7: stat0=0xd0 err=0x00
lsb=0x36
msb=0x72
Feb 2 19:29:26 kern.crit hamster last message repeated 87 times
Feb 2 19:29:27 kern.crit hamster kernel:
Feb 2 19:29:27 kern.crit hamster kernel: ata7: stat0=0xd0 err=0x00
lsb=0x36
msb=0x72
Feb 2 19:29:49 kern.crit hamster last message repeated 221 times
Feb 2 19:29:49 kern.crit hamster kernel: ata7: reset tp2 stat0=d0 stat1=00
devices=0x0
Feb 2 19:29:49 kern.crit hamster kernel: ad14: FAILURE - device detached
Feb 2 19:29:49 kern.crit hamster kernel: ad1g4_:v fdse_tdaocnhee(d):
Feb 2 19:29:49 kern.crit hamster kernel: ad14a[aRtEaA7D:( orfefisneitt=
d1o2n4e0 9.1.43
Feb 2 19:29:49 kern.crit hamster kernel: 2960, length=131072)]error = 6
Feb 2 19:29:49 kern.crit hamster kernel:
g_vfs_done():ad14a[READ(offset=124091564032, length=131072)]error = 6
Feb 2 19:29:49 kern.crit hamster kernel:
g_vfs_done():ad14a[READ(offset=124091695104, length=131072)]error = 6
... and zillion of g_vfs_gone after.
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle ---
[releng_7 tinderbox] failure on i386/i386
TB --- 2008-02-03 09:40:09 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-03 09:40:09 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-02-03 09:40:09 - cleaning the object tree TB --- 2008-02-03 09:40:31 - cvsupping the source tree TB --- 2008-02-03 09:40:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-02-03 09:40:37 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-03 09:40:37 - cd /src TB --- 2008-02-03 09:40:37 - /usr/bin/make -B buildworld World build started on Sun Feb 3 09:40:38 UTC 2008 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sun Feb 3 10:42:58 UTC 2008 TB --- 2008-02-03 10:42:58 - generating LINT kernel config TB --- 2008-02-03 10:42:58 - cd /src/sys/i386/conf TB --- 2008-02-03 10:42:58 - /usr/bin/make -B LINT TB --- 2008-02-03 10:42:59 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-03 10:42:59 - cd /src TB --- 2008-02-03 10:42:59 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Feb 3 10:42:59 UTC 2008 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rp/../../dev/rp/rp_pci.c ld -d -warn-common -r -d -o rp.kld rp.o rp_pci.o : export_syms awk -f /src/sys/modules/rp/../../conf/kmod_syms.awk rp.kld export_syms | xargs -J% objcopy % rp.kld ld -Bshareable -d -warn-common -o rp.ko rp.kld objcopy --strip-debug rp.ko === rr232x (all) make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-03 11:04:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-03 11:04:34 - ERROR: failed to build lint kernel TB --- 2008-02-03 11:04:34 - tinderbox aborted TB --- 4358.50 user 411.61 system 5065.52 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk
On Sun, 3 Feb 2008, Kostik Belousov wrote:
KB (kgdb) p *vp
KB $2 = {v_type = VDIR, v_tag = 0x8039319c ufs, v_op =
KB 0x804e98e0, v_data = 0xff003fab0480, v_mount =
0xff00050dc650,
KB The *v_mount and *(struct ufs_mount *)(v_mount-mnt_data) content shall
KB be enough to confirm that vnode comes from the lost partition.
sure:
...
f_mntfromname = /dev/ad14a,
f_mntonname = /media/esata,
but I was sure it was from there.
KB I think tere are at least two problems here:
KB - panic when non-essential UFS mounted partition disappears
KB Unfortunately, FreeBSD has no concept of the unessential mount; I wish
KB the mount option onerror=nopanic too :).
What disturbs me even more - mount was read-only. I can understand the
panic when some unwritten data may be lost approach, but on read-only...
KB - particular disappearing eSATA drive from eSATA channel of TX4. Relevant
error
KB messages are
KB This looks more like the hardware problem, and it only induced the known
KB kernel deficiency.
That's why I put Soeren on CC list ;)
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
gjournal panic 7.0-RC1
I had originally enabled gjournal and seemed to have no problems but I was seeing errors in messages regarding dma write failures and after some research concluded I had setup gjournal incorrectly. I setup the gjournal again properly with soft updates disabled and doing a fresh newfs, mount showed it as enabled and I had the .journal mounted. Started copying files to it from another partition as I wanted to set that up on gjournal also and the copying I felt would be a good stress test to see if the errors stop, the errors were gone and I felt great but as it was about 80 gig of data to copy I went away to do something else for a bit. Came back to see box had rebooted itself from a journal related panic. panic: Journal overflow (joffset=49905408 active=499691355136 inactive=4990$ cpuid = 0 7.0-RC1 Fair to say this is not as stable as ufs + soft updates then? googling did show other occurances of problem or is there a patch/workaround for the issue? disks are both 500 gig each. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal panic 7.0-RC1
Chris wrote: Came back to see box had rebooted itself from a journal related panic. panic: Journal overflow (joffset=49905408 active=499691355136 inactive=4990$ cpuid = 0 AFAIK this means that the journal is too small for your machine - try doubling it until there are no more panics. If so, this is the same class of errors as ZFS (some would call it tuning errors), only this time the space reserved for the on-disk journal is too small, and the fast drives fill it up before data can be transfered from the journal to the data area. signature.asc Description: OpenPGP digital signature
Re: gjournal panic 7.0-RC1
On Sun, Feb 03, 2008 at 09:35:44PM +0100, Ivan Voras wrote: Chris wrote: Came back to see box had rebooted itself from a journal related panic. panic: Journal overflow (joffset=49905408 active=499691355136 inactive=4990$ cpuid = 0 AFAIK this means that the journal is too small for your machine - try doubling it until there are no more panics. If so, this is the same class of errors as ZFS (some would call it tuning errors), only this time the space reserved for the on-disk journal is too small, and the fast drives fill it up before data can be transfered from the journal to the data area. Is there something stopping gjournal from temporarily blocking writes to the journal to allow it to flush the journaled data to the provider? Thanks, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal panic 7.0-RC1
Ivan Voras wrote: Chris wrote: Came back to see box had rebooted itself from a journal related panic. panic: Journal overflow (joffset=49905408 active=499691355136 inactive=4990$ cpuid = 0 AFAIK this means that the journal is too small for your machine - try doubling it until there are no more panics. If so, this is the same class of errors as ZFS (some would call it tuning errors), only this time the space reserved for the on-disk journal is too small, and the fast drives fill it up before data can be transfered from the journal to the data area. I did some experimentation with gjournal a few weeks ago to determine how I might partition a new server, as well as how large to make my journals and where. I did find that for the computers I have tested so far, a 1 gig (default size) journal seems to be sufficient, but half of that or less is asking for trouble and I could not find any workarounds to reduce the chances of panic when I was already stuck with a too-small journal I created a while ago. I also found the -s parameter is vague in that it does not say what units it accepts (appears to be bytes) and I *could not* get it to make a journal inside a data partition any bigger than somewhere around 1.7 gigs. Some values of -s seemed to wrap around to a smaller number, while other values gave errors about being too small (when they weren't) or invalid size. The only way I could force a journal size 2G or larger was to make a separate partition for journal. On the server I was setting up, I decided to make my (journaled) data partitions da0s1d,e,f and the journals da0s2d,e,f. I'm just getting this out there to the list because I don't have time to debug it further. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal panic 7.0-RC1
I did some experimentation with gjournal a few weeks ago to determine how I might partition a new server, as well as how large to make my journals and where. I did find that for the computers I have tested so far, a 1 gig (default size) journal seems to be sufficient, but half of that or less is asking for trouble and I could not find any workarounds to reduce the chances of panic when I was already stuck with a too-small journal I created a while ago. I also found the -s parameter is vague in that it does not say what units it accepts (appears to be bytes) and I *could not* get it to make a journal inside a data partition any bigger than somewhere around 1.7 gigs. Some values of -s seemed to wrap around to a smaller number, while other values gave errors about being too small (when they weren't) or invalid size. The only way I could force a journal size 2G or larger was to make a separate partition for journal. On the server I was setting up, I decided to make my (journaled) data partitions da0s1d,e,f and the journals da0s2d,e,f. I'm just getting this out there to the list because I don't have time to debug it further. thanks for this info I have spent some 8 hours on this today and it seems the documentation for this is somewhat lacking all information required, the server is handling large 50meg files, I have an identical server that hasnt beetouched by gjournal and even after I had setup gjournal properly so no more errors I then found the write speeds were pretty poor, with hd load very high in vmstat. My initial impressions of gjournal is complicated to setup, unstable and slow write speeds however I have not given up yet and may play with it a little more tommorow. The errors that were appearing are these. ad4: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=662870719 This is not hd failure but occurs when the gjournal was enabled on the initial newfs but has no actual journal location. I stopped these errors after the proper configuration but of course had that single panic. If the only advantage of journaling is to avoid slow fsck's then I may decide I can live without it, the real attraction to me was been able to use the much glamorised async which is what made me so shocked when write speeds were low. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal panic 7.0-RC1
AFAIK this means that the journal is too small for your machine - try doubling it until there are no more panics. If so, this is the same class of errors as ZFS (some would call it tuning errors), only this time the space reserved for the on-disk journal is too small, and the fast drives fill it up before data can be transfered from the journal to the data area. To double it is to do another newfs and start from scratch again or can I somehow increase the size without losing the data on the drive? Does a larger journal incease write speeds as I am finding them very poor around 60% of a sync + soft updates drive. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal panic 7.0-RC1
Gary Palmer wrote: On Sun, Feb 03, 2008 at 09:35:44PM +0100, Ivan Voras wrote: If so, this is the same class of errors as ZFS (some would call it tuning errors), only this time the space reserved for the on-disk journal is too small, and the fast drives fill it up before data can be transfered from the journal to the data area. Is there something stopping gjournal from temporarily blocking writes to the journal to allow it to flush the journaled data to the provider? I've done something like that in the past, but I don't know if Pawel's gjournal has this implemented. I feel that a good solution could be to somehow pause the file system at the VFS layer not to generate requests that would result in IO writes - this could (in theory...) help with ZFS. signature.asc Description: OpenPGP digital signature
Re: gjournal panic 7.0-RC1
Chris wrote: If the only advantage of journaling is to avoid slow fsck's then I may decide I can live without it, the real attraction to me was been able to use the much glamorised async which is what made me so shocked when write speeds were low. If I understood this thread correctly, the impression of poor performance is based on a configuration where both the journal and the data are on the same physical drive. Intuitively, this will likely penalize any transaction on the volume, read or write, since you're asking the drive to not only accumulate a queue of information to the journal in one region of the disk but also to flush that data in idle time to a region in the data space on that same disk at a significant seek-length away. I would think that journaling on one drive and storing the resultant data-set on another would improve performance enormously (reduced seek-lengths) and more so if they were 1) high-rpm drives (less rotational latency) and 2) on different buses (no bus/controller contention), Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal panic 7.0-RC1
If I understood this thread correctly, the impression of poor performance is based on a configuration where both the journal and the data are on the same physical drive. Intuitively, this will likely penalize any transaction on the volume, read or write, since you're asking the drive to not only accumulate a queue of information to the journal in one region of the disk but also to flush that data in idle time to a region in the data space on that same disk at a significant seek-length away. I would think that journaling on one drive and storing the resultant data-set on another would improve performance enormously (reduced seek-lengths) and more so if they were 1) high-rpm drives (less rotational latency) and 2) on different buses (no bus/controller contention), Michael Yes I have suspected this, there is 2 physical drives in the machine so this would be possible, if its possible to swap the journals round so they journaling for each other I will give it a go tommorow. They both sata 300 drives. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal panic 7.0-RC1
Michael Butler wrote: I would think that journaling on one drive and storing the resultant data-set on another would improve performance enormously (reduced seek-lengths) and more so if they were 1) high-rpm drives (less rotational latency) and 2) on different buses (no bus/controller contention), There are (very near) limits to what you can do with such a setup: the drive that holds the external journal needs to be much faster than the data drive, since it will become the main bottleneck in IO. It has to be faster mostly in sequential IO, seeks are only present when transferring journal data to the main drives while under simultaneous write IO from the file system. Ideally, the journal drive would have to deliver at least twice as sequential IO as the main drive to maximize the potential performance. Thus, using a conveniently small medium as an USB flash drive is not very useful (the high seek rate will remain unused and sequential performance is generally lower than regular drives) I've done some benchmarking. The setup is: three 7.5k RPM drives, two in RAID0, one for the journal. Here's a summary of the results: UFS+SU: bonnie++: writes: 102 MB/s, rewrites: 47 MB/s, reads: 103 MB/s postmark: 110 trans/s UFS+GJ: bonnie++: writes: 35 MB/s, rewrites: 22 MB/s, reads: 99 MB/s postmark: 123 trans/s UFS+GJ-detached: bonnie++: writes: 46 MB/s, rewrites: 36 MB/s, reads: 100 MB/s postmark: 263 trans/s Postmark is configured to have a bias for writing a lot of small files, and benefits a lot from the detached journal. Margins of errors are around +/- 3 MB/s for bonnie++ and around 15 trans/s for postmark. For comparison, here are the results for Linux 2.6.23, regular ext3: bonnie++: writes: 105 MB/s, rewrites: 52 MB/s, reads: 128 MB/s postmark: 173 trans/s signature.asc Description: OpenPGP digital signature
Re: gjournal panic 7.0-RC1
Chris wrote: AFAIK this means that the journal is too small for your machine - try doubling it until there are no more panics. If so, this is the same class of errors as ZFS (some would call it tuning errors), only this time the space reserved for the on-disk journal is too small, and the fast drives fill it up before data can be transfered from the journal to the data area. To double it is to do another newfs and start from scratch again or can I somehow increase the size without losing the data on the drive? If you use an external journal, you can re-create the journal keep the data, if you use an inline journal on the same drive as the file system (the default configuration), you need to re-create both the journal and the file system (newfs). Does a larger journal incease write speeds as I am finding them very poor around 60% of a sync + soft updates drive. No. An external journal could help you to increase the performance. signature.asc Description: OpenPGP digital signature
Re: 6.3 nfe: strange behavior after hand
On Fri, Feb 01, 2008 at 03:56:17PM +0200, Andriy Gapon wrote: on 01/02/2008 15:42 Andriy Gapon said the following: on 01/02/2008 14:36 Pyun YongHyeon said the following: After applying attached patch and let me know the output of devid : xxx, revid : xxx, pwr = xxx. It would be even better if you can show me the above message for working/non-working case. Applied the patch with correction to actually print rev instead of dev for the second time :-) This is in working case: devid : 269, revid : a3, pwr = 0003 A clarification: I just applied the patch, recompiled and re-loaded the module. There was no reboot/poweroff/reset in between. Will wait for the non-working situation. Revert previous patch and try attached patch again and let me know how it goes. -- Regards, Pyun YongHyeon --- sys/dev/nfe/if_nfe.c.orig 2008-02-02 04:36:24.0 +0900 +++ sys/dev/nfe/if_nfe.c2008-02-04 12:47:11.0 +0900 @@ -763,12 +763,6 @@ if ((sc-nfe_flags NFE_PWR_MGMT) == 0) return; - NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_RESET | NFE_RXTX_BIT2); - NFE_WRITE(sc, NFE_MAC_RESET, NFE_MAC_RESET_MAGIC); - DELAY(100); - NFE_WRITE(sc, NFE_MAC_RESET, 0); - DELAY(100); - NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_BIT2); pwr = NFE_READ(sc, NFE_PWR2_CTL); pwr = ~NFE_PWR2_WAKEUP_MASK; if (sc-nfe_revid = 0xa3 @@ -776,6 +770,12 @@ sc-nfe_devid == PCI_PRODUCT_NVIDIA_NFORCE430_LAN2)) pwr |= NFE_PWR2_REVA3; NFE_WRITE(sc, NFE_PWR2_CTL, pwr); + NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_RESET | NFE_RXTX_BIT2); + NFE_WRITE(sc, NFE_MAC_RESET, NFE_MAC_RESET_MAGIC); + DELAY(100); + NFE_WRITE(sc, NFE_MAC_RESET, 0); + DELAY(100); + NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_BIT2); } ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
On Mon, 4 Feb 2008, Ganbold wrote: I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down What does fstat /dev/cuad0 say? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
/dev/cuad0: Device busy
Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down daemon# uname -an FreeBSD daemon.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Mon Jan 14 16:49:57 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 It seems like no other program is using serial port. How to check whether something is using serial port? Any idea? thanks, Ganbold -- If you think the problem is bad now, just wait until we've solved it. -- Arthur Kasspe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Daniel O'Connor wrote: On Mon, 4 Feb 2008, Ganbold wrote: I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down What does fstat /dev/cuad0 say? It says: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# Ganbold -- We'll have solar energy when the power companies develop a sunbeam meter. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down Does the same happen if you do `cu -l ttyd0 -s 9600`? How to check whether something is using serial port? Any idea? fstat should help here. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Jeremy Chadwick wrote: On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down Does the same happen if you do `cu -l ttyd0 -s 9600`? It works and fstat shows: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# fstat /dev/ttyd0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root cu 55743 /dev 41 crw--- ttyd0 rw /dev/ttyd0 root cu 55733 /dev 41 crw--- ttyd0 rw /dev/ttyd0 daemon# Is it expected behaviour? thanks, Ganbold How to check whether something is using serial port? Any idea? fstat should help here. -- Success is in the minds of Fools. -- William Wrenshaw, 1578 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
On Mon, Feb 04, 2008 at 02:37:31PM +0800, Ganbold wrote: Jeremy Chadwick wrote: On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down Does the same happen if you do `cu -l ttyd0 -s 9600`? It works and fstat shows: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# fstat /dev/ttyd0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root cu 55743 /dev 41 crw--- ttyd0 rw /dev/ttyd0 root cu 55733 /dev 41 crw--- ttyd0 rw /dev/ttyd0 daemon# Is it expected behaviour? As far as I know, yes. On all of our machines which utilise getty(8) on ttyd0 (as listed in /etc/ttys): $ grep ttyd0 /etc/ttys ttyd0 /usr/libexec/getty std.115200 xterm on secure $ fstat /dev/ttyd0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root getty 373760 /dev 36 crw--- ttyd0 rw /dev/ttyd0 root getty 373761 /dev 36 crw--- ttyd0 rw /dev/ttyd0 root getty 373762 /dev 36 crw--- ttyd0 rw /dev/ttyd0 Additionally, see Section 23.2.5 of the below document: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Personally, I never understood the concept of dial-in and call-out devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... The distinction exists to allow an application to wait on the dial-in port for incoming calls and another application to make outgoing call mean time using the same port as call-out while the port is idle. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
