GEOM_PART: integrity check failed (mirror/gm0, MBR) on FreeBSD 8.3-RELEASE

[Mark Knight]

I just did a source upgrade from 8.2 to 8.3.  System boots but has this 
warning:


GEOM_PART: integrity check failed (mirror/gm0, MBR)

Google points to issues with FreeBSD 9 and the need to migrate to GPT 
but I wasn't expecting this with 8.3!


Are there any quick fixes to eliminate this warning or is it safe to 
ignore please?


sudo gpart list:

Geom name: mirror/gm0
modified: false
state: CORRUPT
fwheads: 255
fwsectors: 63
last: 976773166
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: mirror/gm0s1
   Mediasize: 500107829760 (465G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r2w2e3
   attrib: active
   rawtype: 165
   length: 500107829760
   offset: 32256
   type: freebsd
   index: 1
   end: 976773167
   start: 63
Consumers:
1. Name: mirror/gm0
   Mediasize: 500107861504 (465G)
   Sectorsize: 512
   Mode: r2w2e5

Geom name: mirror/gm0s1
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 976773104
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: mirror/gm0s1a
   Mediasize: 498597888000 (464G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r1w1e1
   rawtype: 7
   length: 498597888000
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 973823999
   start: 0
2. Name: mirror/gm0s1b
   Mediasize: 1509941760 (1.4G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 381713920
   Mode: r1w1e0
   rawtype: 1
   length: 1509941760
   offset: 498597888000
   type: freebsd-swap
   index: 2
   end: 976773104
   start: 973824000
Consumers:
1. Name: mirror/gm0s1
   Mediasize: 500107829760 (465G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r2w2e3
--
Mark A. R. Knight   finger: ma...@knigma.org
Tel: +44 7880 556751http://www.knigma.org/
___
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 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS

[Mark Knight]

I'm trying to do the usual src code upgrade from FreeBSD 10.3 to 10.4, 
as I've done many times before with earlier version bumps.


However, for some reason the 10.4 kernel seems to break my system, 
either with the 10.3 or 10.4 userland.


The main issue seems to be some sort of deadlock. For example, on the 
console, following boot (which seems fairly normal) I can login to the 
console as root, but when I try to use commands like su or sudo to 
switch to another user, that command hangs and at that point CTRL-C is 
useless: I have to switch to another tty. Trying to login via ssh over 
the network also fails but neither case gives me any obvious clues in 
logs. If I switch back to a 10.3 kernel sanity is restored.


Not sure if it's related, but on boot I see these new errors that 
weren't present on 10.3:



[1] ACPI Error: Mutex [0x0] is not acquired, cannot release 
(20160527/utmutex-386)
[1] ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147)
[1] ACPI Error: Mutex [0x0] is not acquired, cannot release 
(20160527/utmutex-386)
[1] ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147

I've dumped the  kernel boot log here:

http://www.knigma.org/scratch/010418.10.4.txt

I'm struggling to pin down the cause, so I'm hoping this mail might jog 
a memory or provide a pointer please?


Motherboard is a PRIME H270M-PLUS with the latest BIOS.

Thanks!!
--
Mark Knight
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS

[Mark Knight]

On 02/04/2018 06:56, Eugene Grosbein wrote:

What does it show if you press "CTRL-T" to see a status of "hung" process?


Typically CTRL-T shows [sysctl mem]. In some circumstances I can CTRL-C 
(e.g. if su hangs), in others I cannot (e.g. with sudo).



Does it help if you comment out the line mentioning /dev/console in the 
/etc/syslog.conf
and apply the change with killall -1 syslogd ?


Doing that "killall -HUP syslogd" hangs with (sysctl mem) - as does 
"service syslogd restart" but after a fresh reboot, no - removing that 
line didn't help at all. Thanks for getting my hopes up :)


Moving ~/myuser/.bashrc out of the way (it really doesn't contain much 
apart from setting a bunch of aliases), allows me to login as myself, 
but "sudo -u myuser -s" still hangs.


I just got a truss output of "sudo -u myuser -s" per the file below, 
perhaps that contains a clue?


# sudo -u myuser -s >& sudo.truss.log

http://www.knigma.org/scratch/sudo.truss.log

Flipping back to a 10.3 kernel makes everything happy (just as well, as 
the machine in question is my main router/firewall, so it's a right pain 
when it's not working).


Thanks in advance for any fresh ideas; I'm really not sure where to go 
with this!

--
Mark Knight
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS

[Mark Knight]

On 02/04/2018 14:44, Eugene Grosbein wrote:

3. Boot new kernel using nextboot(8) and see if it will crash instead of 
deadlock
and if so, fill the PR to Bugzilla.


Thanks again. Drat, no crash. The only difference was a few new errors 
during the boot - which I'm assuming are unrelated.



Apr  2 17:27:58 shrewd kernel: [16] lock order reversal:
Apr  2 17:27:58 shrewd kernel: [16]  1st 0xf80077653418 ufs (ufs) @ 
/usr/src/sys/kern/vfs_subr.c:2253
Apr  2 17:27:58 shrewd kernel: [16]  2nd 0xfe03dbe7d218 bufwait (bufwait) @ 
/usr/src/sys/ufs/ffs/ffs_vnops.c:262
Apr  2 17:27:58 shrewd kernel: [16]  3rd 0xf80077c089a0 ufs (ufs) @ 
/usr/src/sys/kern/vfs_subr.c:2253
Apr  2 17:27:58 shrewd kernel: [16] KDB: stack backtrace:
Apr  2 17:27:58 shrewd kernel: [16] db_trace_self_wrapper() at 
db_trace_self_wrapper+0x2b/frame 0xfe0462049b30
Apr  2 17:27:58 shrewd kernel: [16] kdb_backtrace() at kdb_backtrace+0x39/frame 
0xfe0462049be0
Apr  2 17:27:58 shrewd kernel: [16] witness_checkorder() at 
witness_checkorder+0xe2b/frame 0xfe0462049c70
Apr  2 17:27:58 shrewd kernel: [16] __lockmgr_args() at 
__lockmgr_args+0x988/frame 0xfe0462049d90
Apr  2 17:27:58 shrewd kernel: [16] ffs_lock() at ffs_lock+0x84/frame 
0xfe0462049de0
Apr  2 17:27:58 shrewd kernel: [16] VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 
0xfe0462
Apr  2 17:27:58 shrewd kernel: 049e10
Apr  2 17:27:59 shrewd kernel: [16] _vn_lock() at _vn_lock+0xaa/frame 
0xfe0462049e80
Apr  2 17:27:59 shrewd kernel: [16] vget() at vget+0x67/frame 0xfe0462049ec0
Apr  2 17:27:59 shrewd kernel: [16] vfs_hash_get() at vfs_hash_get+0xe1/frame 
0xfe0462049f10
Apr  2 17:27:59 shrewd kernel: [16] ffs_vgetf() at ffs_vgetf+0x40/frame 
0xfe0462049fa0
Apr  2 17:27:59 shrewd kernel: [16] softdep_sync_buf() at 
softdep_sync_buf+0xa25/frame 0xfe046204a090
Apr  2 17:27:59 shrewd kernel: [16] ffs_syncvnode() at 
ffs_syncvnode+0x286/frame 0xfe046204a110
Apr  2 17:27:59 shrewd kernel: [16] ffs_truncate() at ffs_truncate+0x6a9/frame 
0xfe046204a2f0
Apr  2 17:27:59 shrewd kernel: [16] ufs_direnter() at ufs_direnter+0x7c8/frame 
0xfe046204a3b0
Apr  2 17:27:59 shrewd kernel: [16] ufs_makeinode() at 
ufs_makeinode+0x5d9/frame 0xfe046204a570
Apr  2 17:27:59 shrewd kernel: [16] ufs_create() at ufs_create+0x34/frame 
0xfe046204a590
Apr  2 17:27:59 shrewd kernel: [16] VOP_CREATE_APV() at 
VOP_CREATE_APV+0xf1/frame 0xfe046204a5c0
Apr  2 17:27:59 shrewd kernel: [16] vn_open_cred() at vn_open_cred+0x2c3/frame 
0xfe046204a720
Apr  2 17:27:59 shrewd kernel: [16] kern_openat() at kern_openat+0x26f/frame 
0xfe046204a8a0
Apr  2 17:27:59 shrewd kernel: [16] amd64_syscall() at 
amd64_syscall+0x2c6/frame 0xfe046204a9b0
Apr  2 17:27:59 shrewd kernel: [16] Xfast_syscall() at Xfast_syscall+0xfb/frame 
0xfe046204a9b0
Apr  2 17:27:59 shrewd kernel: [16] --- syscall (5, FreeBSD ELF64, sys_open), 
rip = 0x801fcc9aa, rsp = 0x7fffdfdf9c38, rbp = 0x7fffdfdf9c60 ---
Apr  2 17:28:48 shrewd kernel: [66] lock order reversal:
Apr  2 17:28:48 shrewd kernel: [66]  1st 0xfe03dbf949f8 bufwait (bufwait) @ 
/usr/src/sys/kern/vfs_bio.c:3130
Apr  2 17:28:48 shrewd kernel: [66]  2nd 0xf8000b741000 dirhash (dirhash) @ 
/usr/src/sys/ufs/ufs/ufs_dirhash.c:280
Apr  2 17:28:48 shrewd kernel: [66] KDB: stack backtrace:
Apr  2 17:28:48 shrewd kernel: [66] db_trace_self_wrapper() at 
db_trace_self_wrapper+0x2b/frame 0xfe0462185130
Apr  2 17:28:48 shrewd kernel: [66] kdb_backtrace() at kdb_backtrace+0x39/frame 
0xfe04621851e0
Apr  2 17:28:48 shrewd kernel: [66] witness_checkorder() at 
witness_checkorder+0xe2b/frame 0xfe0462185270
Apr  2 17:28:48 shrewd kernel: [66] _sx_xlock() at _sx_xlock+0x75/frame 
0xfe04621852b0
Apr  2 17:28:48 shrewd kernel: [66] ufsdirhash_add() at 
ufsdirhash_add+0x3a/frame 0xfe04621852f0
Apr  2 17:28:48 shrewd kernel: [66] ufs_direnter() at ufs_direnter+0x622/frame 
0xfe04621853b0
Apr  2 17:28:48 shrewd kernel: [66] ufs_makeinode() at 
ufs_makeinode+0x5d9/frame 0xfe0462185570
Apr  2 17:28:48 shrewd kernel: [66] ufs_create() at ufs_create+0x34/frame 
0xfe0462185590
Apr  2 17:28:48 shrewd kernel: [66] VOP_CREATE_APV() at 
VOP_CREATE_APV+0xf1/frame 0xfe04621855c0
Apr  2 17:28:48 shrewd kernel: [66] vn_open_cred() at vn_open_cred+0x2c3/frame 
0xfe0462185720
Apr  2 17:28:48 shrewd kernel: [66] kern_openat() at kern_openat+0x26f/frame 
0xfe04621858a0
Apr  2 17:28:48 shrewd kernel: [66] amd64_syscall() at 
amd64_syscall+0x2c6/frame 0xfe04621859b0
Apr  2 17:28:48 shrewd kernel: [66] Xfast_syscall() at Xfast_syscall+0xfb/frame 
0xfe04621859b0
Apr  2 17:28:48 shrewd kernel: [66] --- syscall (499, FreeBSD ELF64, 
sys_openat), rip = 0x80174cb7a, rsp = 0x7fff7f58, rbp = 0x7fff7fd0 ---


--
Mark Knight
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, sen

Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS

[Mark Knight]

On 02/04/2018 18:35, Eugene Grosbein wrote:

Use such debugging kernel to drop to the debugger when deadlock occurs
using Ctr-Alt-ESC and type "call doadump", you should get crashdump anyway.
Then use "reboot" or just power cycle to get crashdump stored to /var/crash.

Then fill a PR and reply with the number.


Thank you. Please see:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213

Hopefully I've provided links to the necessary files. Let me know if 
anything else is useful!


Best regards, Mark
--
Mark Knight
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

6.1 panic after approx. 49 days uptime

[Mark Knight]

Just awoke to fine my home server (6.1-RELEASE) had panicked during its
daily update of /usr/ports with an uptime of 49 days.

Stack trace is here:

  

Looks file system related to me.  Any advice appreciated.

Cheers,
-- 
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7880 556751http://www.knigma.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.1 panic after approx. 49 days uptime

[Mark Knight]

In message <[EMAIL PROTECTED]>, Kostik 
Belousov <[EMAIL PROTECTED]> writes

On Sun, Jul 16, 2006 at 09:32:47AM +0100, Mark Knight wrote:

Just awoke to fine my home server (6.1-RELEASE) had panicked during its
daily update of /usr/ports with an uptime of 49 days.

Stack trace is here:

  <http://www.knigma.org.uk/scratch/crash_160706.txt>

Looks file system related to me.  Any advice appreciated.


If you still have the core dump at hands, go to frame #7 and post the
output of the commands "p *vp" and "p *(vp->v_mount)".


Appended to log file (in case of mail formatting) and reproduced here:

(kgdb) p *(vp)
$3 = {v_type = VBAD, v_tag = 0xc0791704 "none", v_op = 0xc07d89e0, v_data = 
0x0, v_mount = 0x0,
  v_nmntvnodes = {tqe_next = 0x0, tqe_prev = 0xc3250014}, v_un = {vu_mount = 
0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 
0xc295f570},
  v_hash = 3269747, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 
0x0, tqh_last = 0xc335cbe0},
  v_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = 
{lk_interlock = 0xc08073dc,
lk_flags = 64, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, 
lk_prio = 80,
lk_wmesg = 0xc07a24ed "ufs", lk_timo = 51, lk_lockholder = 0x, 
lk_newlock = 0x0},
  v_interlock = {mtx_object = {lo_class = 0xc07e0644, lo_name = 0xc07a3a55 "vnode 
interlock",
  lo_type = 0xc07a3a55 "vnode interlock", lo_flags = 196608, lo_list = 
{tqe_next = 0x0,
tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, 
v_vnlock = 0xc335cc08,
  v_holdcnt = 1, v_usecount = 0, v_iflag = 128, v_vflag = 0, v_writecount = 0, 
v_freelist = {
tqe_next = 0xc3248990, tqe_prev = 0xc080d22c}, v_bufobj = {bo_mtx = 
0xc335cc2c, bo_clean = {bv_hd = {
tqh_first = 0x0, tqh_last = 0xc335cc74}, bv_root = 0x0, bv_cnt = 0}, 
bo_dirty = {bv_hd = {
tqh_first = 0x0, tqh_last = 0xc335cc84}, bv_root = 0x0, bv_cnt = 0}, 
bo_numoutput = 0, bo_flag = 0,
bo_ops = 0xc07e6564, bo_bsize = 8192, bo_object = 0x0, bo_synclist = 
{le_next = 0x0, le_prev = 0x0},
bo_private = 0xc335cbb0, __bo_vnode = 0xc335cbb0}, v_pollinfo = 0x0, 
v_label = 0x0}
(kgdb) p *(vp->v_mount)
Cannot access memory at address 0x0
(kgdb)

Thanks,
--
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7880 556751http://www.knigma.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD 6.0 sudden kernel panic

[Mark Knight]

In message <[EMAIL PROTECTED]>, Lukasz Jaroszewski 
<[EMAIL PROTECTED]> writes

I did nothing special when suddenly my freebsd rebooted:

[snip]

 Version String: FreeBSD 6.0-RELEASE #1: Tue Mar 14 10:40:21 CET 2006
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC-NIETYKALNI

[snip]

#7  0xc05fec64 in closef (fp=0xc1826120, td=0xc28f4780)
   at /usr/src/sys/kern/kern_descrip.c:1876
1876   vfslocked = VFS_LOCK_GIANT(vp->v_mount);
Current language:  auto; currently c
(kgdb) p vp
$2 = (struct vnode *) 0xc1e1fbb0
(kgdb) p vp-v_mount
No symbol "v_mount" in current context.
(kgdb) p vp->v_mount
$3 = (struct mount *) 0x0


Looks similar to a panic I just reported on 6.1

Cheers,
--
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7880 556751http://www.knigma.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.1 panic after approx. 49 days uptime

[Mark Knight]

In message <[EMAIL PROTECTED]>, Kostik 
Belousov <[EMAIL PROTECTED]> writes

Thank you for the data. As I see, the problem could be worked around by
the following patch:

[snip]

I'll try loading this on my box later today.  Thank you!!


What seems to be quite untrivial is testing.


Quite!


Did you had unmount
some filesystem before that panic happen ?


No; I was fast asleep!  I think the panic happened while executing a 
cron job that does a "cvs update" in /usr/ports.  The same job ran 
successfully every morning for the preceding 48 days.


Cheers,
--
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7880 556751http://www.knigma.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

wicontrol on 5.3

[Mark Knight]

I just successfully completed a source code upgrade from 4.10 to 5.3. 
All pretty perfect and seamless, thank you!

However, just noticed a problem when I run:
[EMAIL PROTECTED] wicontrol -i wi0 -C
[1/1614089728]: 32:80:00:00:00:00, 61.0.0.0, sig: 0, noise: 0, qual: 0
[2/1614089728]: 00:00:00:00:00:00, 0.0.0.0, sig: 0, noise: 0, qual: 0
[3/1614089728]: 00:00:00:00:00:00, 0.0.0.0, sig: 0, noise: 0, qual: 0
...
[255/1614089728]: 50:f7:40:54:00:00, 117.3.142.104, sig: 22591508, noise: 
-850395136, qual: -1862341760
[256/1614089728]: ff:54:24:10:8d:44, 80.247.64.24, sig: 131072, noise: 
1754137461, qual: 6797380
[257/1614089728]: 00:00:50:cd:80:eb, 112.236.191.191, sig: 4, noise: 
-1077941116, qual: 24
Bus error (core dumped)
There should only be a couple of wireless stations listed.  wi0 is 
running in hostap mode.

dmesg reports:
wi0:  mem 0xf15ff000-0xf15f irq 11 at device 10.0 on pci1
wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI)
wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9)
wi0: Ethernet address: 00:09:5b:2f:b3:03
wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
Cheers,
--
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7973 410732http://www.knigma.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

dump dumping core

[Mark Knight]

With RELENG_5 from yesterday, as well from a week or so ago I'm finding 
that dump is failing.  Must admit, this is the first time I've tried to 
run a backup since migrating from RELENG_4 to RELENG_5.

fsck -f / marks the file system as clean.
Any ideas?
[EMAIL PROTECTED] dump -0a -b 512 -f - / > /dev/null
  DUMP: WARNING: should use -L when dumping live read-write filesystems!
  DUMP: Date of this level 0 dump: Mon Jan  3 21:38:32 2005
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/ad0s1a (/) to standard output
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 21084554 tape blocks.
  DUMP: 0.00% done, finished in 0:00 at Mon Jan  3 21:38:44 2005
  DUMP: dumping (Pass III) [directories]
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
Segmentation fault (core dumped)
[EMAIL PROTECTED] gdb /sbin/dump -c dump.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are 
welcome to change it and/or distribute copies of it under certain
conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was 
configured as "i386-marcel-freebsd"...
Core was generated by `dump'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x2814a687 in memcpy () from /lib/libc.so.5
(gdb) bt
#0  0x2814a687 in memcpy () from /lib/libc.so.5
#1  0x080506a7 in bread (blkno=1001, buf=0x82b4000 "", size=0)
at /usr/src/sbin/dump/traverse.c:785
#2  0x0804e406 in doslave (cmd=4, slave_number=0)
at /usr/src/sbin/dump/tape.c:787
#3  0x0804e235 in enslave () at /usr/src/sbin/dump/tape.c:725
#4  0x0804df6f in startnewtape (top=1) at /usr/src/sbin/dump/tape.c:630
#5  0x0804b309 in main (argc=0, argv=0xbfbfec48)
at /usr/src/sbin/dump/main.c:503
(gdb) up
#1  0x080506a7 in bread (blkno=1001, buf=0x82b4000 "", size=0)
at /usr/src/sbin/dump/traverse.c:785
785 memcpy(&buf[xfer], tmpbuf, resid);
(gdb) print resid
$1 = -512
Cheers,
--
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7973 410732http://www.knigma.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: dump dumping core

[Mark Knight]

In message <[EMAIL PROTECTED]>, Mark Knight 
<[EMAIL PROTECTED]> writes
With RELENG_5 from yesterday, as well from a week or so ago I'm finding 
that dump is failing.  Must admit, this is the first time I've tried to 
run a backup since migrating from RELENG_4 to RELENG_5.

fsck -f / marks the file system as clean.
Any ideas?
[EMAIL PROTECTED] dump -0a -b 512 -f - / > /dev/null
The -b 512 (or other large values), seems to be the key to making it 
crash (on various inodes).  Sometimes the error is "master/slave 
protocol botched" instead.

Until I find the cause, the workaround of "don't do that then" seems 
appropriate.  At least it wasn't fs corruption ;)
--
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7973 410732http://www.knigma.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: XFree86-4.1 appears to be broken

[Mark Knight]

In article <[EMAIL PROTECTED]>, Fritz Heinrichmeyer
<[EMAIL PROTECTED]> writes
>Building breaks because there is an old font library involved:
>Workaround:
>gzip /usr/X11R6/lib/libXft.so.1 for the time of build.

I needed to employ this workaround.

With my DB815EEA m/b with i815 chip set, I can report utter failure to
run X - nothing but a black screen each time the X server starts,
accompanied with 100% X server cpu utilisation. No errors in
/var/log/XFree, other than is appears to stop rather abruptly after:

...
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Loading /usr/X11R6/lib/modules/libddc.a
(II) Module ddc: vendor="The XFree86 Project"
compiled for 4.1.0, module version = 1.0.0
ABI class: XFree86 Video Driver, version 0.4

Investigating...
-- 
Mark A. R. Knight
Tel: +44 7973 410732  http://www.knigma.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: XFree86-4.1 appears to be broken

[Mark Knight]

In article <[EMAIL PROTECTED]>, Mark Knight <[EMAIL PROTECTED]>
writes

>Investigating...

Adding 'Option "NoDDC"' to the driver configuration files these symptoms
for me.
-- 
Mark A. R. Knight
Tel: +44 7973 410732  http://www.knigma.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Strange cable TCP performance

[Mark Knight]

I've a box running -stable dated 22nd December.  The box contains two
fxp interfaces.  One interface is attached to my internal network
(fxp0), and the other is attached directly to a newly installed Samsung
SCM-140 cable modem (fxp1), and hence NTL's business broadband service.
fxp1 is running natd, although removing the divert rule appears to make
no difference to the symptoms described below.

My broadband service claims 500kb/s download and 256kb/s upload.

Download performance in fine as I expect.  However, upload performance
is not.

Using ftp to put a 512kB file from this system, or wget to pull the same
file either via http or ftp, speeds always start around the 30kB/s.
However, this typically drops after a few seconds to 15-17kB/s.  I've
tried these tests at various times of day, to various well connected
sites, and this is both repeatable and consistent.  The same affect is
observed with larger files; once the transfer rate has fallen, it does
not usually increase.

However, if I use either a Windows or a -current box, attached via fxp0
(or an0), and using the -stable box as their default router, upload
performance is reliably increased to at least 27kB/s.

In summary, systems other than the router itself appear to sustain
approximately twice the upload rate of the -stable router itself.

Various diagnostic outputs are located at:

   http://www.knigma.org/freebsd/cable/slow.txt

A 512Kb test file containing random data is available at:

   http://www.shrewd.knigma.org/test/fullfile
   ftp://ftp.knigma.org/pub/download/fullfile

I've tried tweaking a few inet sysctl's without noticeable affect,
although I'll admit to not really knowing what I'm doing with these ;)

Any advice appreciated, thank you,
-- 
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7973 410732http://www.knigma.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Kernel core dump in recent 4.8-STABLE

[Mark Knight]

In message <[EMAIL PROTECTED]>, Mark Knight 
<[EMAIL PROTECTED]> writes
I just updated my system to RELENG_4 from Tuesday morning, and saw a
crash as X started.  Unfortunately, It was a remote restart, so I had to
win a race to move xdm out of the way before the system crashed ;)
Regressing my world and kernel back to:

  -rRELENG_4 -D "2003/06/06 13:20:00 PDT"

appears to remove this problem.  Moving forward to:

  -rRELENG_4 -D "2003/06/08 13:20:00 PDT"

makes it return, providing a remarkably similar window to the apache 
panics thread.
--
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7880 556751http://www.knigma.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel core dump in recent 4.8-STABLE

[Mark Knight]

In message <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] writes
That commit broke kernel modules depending on the layout of struct
proc.  Since recompiling the kernel module isn't an option for third
party binary modules, the new p_fdtol variable should be moved to the
end of struct proc.
Problem solved, thank you :)

It would have been mga.ko (from the drm-kmod port), that was triggering 
this problem for me.

Cheers,
--
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7880 556751http://www.knigma.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: strange problem with: ed driver / 4.9-PRE

[Mark Knight]

In message <[EMAIL PROTECTED]>, Peter Jeremy 
<[EMAIL PROTECTED]> writes
I've bumped into this with the vlan driver as well.  I believe the fix
is to patch ifconfig(8) so that it checks for "DEVICE" as well as
"if_DEVICE" and skips the load if either is found.  I don't believe
this change is especially risky.
I'm still seeing this with -stable dated 26th September.  It appears to 
be covered by bug number 55279.  miibus and ed0 are both statically 
compiled into my kernel, and these devices are not mentioned in /boot/*

Despite this, the following boot time errors are reported:

module_register: module miibus/ukphy already exists!
linker_file_sysinit "miibus.ko" failed to register! 17
module_register: module pccard/ed already exists!
linker_file_sysinit "if_ed.ko" failed to register! 17
and kldstat reports:

-bash-2.05b$ kldstat
Id Refs AddressSize Name
 14 0xc010 2768c8   kernel
 32 0xc092d000 e000 miibus.ko
 41 0xc094 a000 if_ed.ko
 51 0xc09b3000 15000linux.ko
For full kernel/dmesg:

  http://www.knigma.org.uk/~mkn/roys_error.txt

The problem appears to be that the ed driver module is named "ed" (as 
reported by kldstat -v), rather than "if_ed",  causing ifconfig to 
attempt to load the module.  Could this be corrected for 4.9-RELEASE 
please?

Many thanks,
--
Mark A. R. Knight   finger: [EMAIL PROTECTED]
Tel: +44 7973 410732http://www.knigma.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"