[no subject]

[Spoiler]

signature.asc
Description: This is a digitally signed message part.

Subject: Important update for freebsd-current@freebsd.org: Please see transcript for details.

[Email Gateway Security]

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

[no subject]

[Tom Jones]

r...@freebsd.org
Bcc: 
Subject: Re: How to enable tcp bbr in FreeBSD???
Reply-To: 
In-Reply-To: <6042155a-297b-d85e-1d64-24d93da32...@gmail.com>


... snip ...
> 
> Maybe it is not ready for prime time, i do not know why it is not in the
> default build.
> Maybe ask the committer.
> 

I have added rrs@ in cc and the freebsd-transport list. 

Does anyone know if there are plans to enable alternate TCP stacks in
generic? 

Is there a stability point we need to hit first?

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

[no subject]

[Cy Schubert]

Hi,

Has anyone seen this before? It started happening on two of my machines 
this evening. Both machines are AMD (not intel). In both cases powerd was 
caught with its hand in the cookie jar.

Fatal trap 12: page fault while in kernel mode^M
cpuid = 3; apic id = 03^M
fault virtual address   = 0x90^M
fault code  = supervisor read data, page not present^M
instruction pointer = 0x20:0x8068b018^M
stack pointer   = 0x28:0xfe0066ff99e0^M
frame pointer   = 0x28:0xfe0066ff99e0^M
code segment= base 0x0, limit 0xf, type 0x1b^M
= DPL 0, pres 1, long 1, def32 0, gran 1^M
processor eflags= interrupt enabled, resume, IOPL = 0^M
current process = 2781 (powerd)^M
trap number = 12^M
panic: page fault^M
cpuid = 3^M
time = 1579843504^M
KDB: stack backtrace:^M
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe0066ff9650^M
vpanic() at vpanic+0x185/frame 0xfe0066ff96b0^M
panic() at panic+0x43/frame 0xfe0066ff9710^M
trap_fatal() at trap_fatal+0x386/frame 0xfe0066ff9770^M
trap_pfault() at trap_pfault+0x4f/frame 0xfe0066ff97e0^M
trap() at trap+0x288/frame 0xfe0066ff9910^M
calltrap() at calltrap+0x8/frame 0xfe0066ff9910^M
--- trap 0xc, rip = 0x8068b018, rsp = 0xfe0066ff99e0, rbp = 
0xfe
0066ff99e0 ---^M
_rm_rlock() at _rm_rlock+0x58/frame 0xfe0066ff99e0^M
sysctl_root_handler_locked() at sysctl_root_handler_locked+0xde/frame 
0xfe00
66ff9a20^M
sysctl_root() at sysctl_root+0x249/frame 0xfe0066ff9aa0^M
userland_sysctl() at userland_sysctl+0x178/frame 0xfe0066ff9b50^M
sys___sysctl() at sys___sysctl+0x5f/frame 0xfe0066ff9c00^M
amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe0066ff9d30^M
fast_syscall_common() at fast_syscall_common+0x101/frame 
0xfe0066ff9d30^M
--- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x2c034f9a, rsp = 
0x7f
ffeb38, rbp = 0x7fffeb70 ---^M
Uptime: 2h12m24s^M
Dumping 2496 out of 8167 MB: (CTRL-C to abort) ..1%..11%..21%..31%..41%..51%
..61
%..71%..81%..91%^M
Dump complete^M



Fatal trap 12: page fault while in kernel mode^M
cpuid = 3; apic id = 03^M
fault virtual address   = 0x90^M
fault code  = supervisor read data, page not present^M
instruction pointer = 0x20:0x8068b018^M
stack pointer   = 0x28:0xfe004d2a79e0^M
frame pointer   = 0x28:0xfe004d2a79e0^M
code segment= base 0x0, limit 0xf, type 0x1b^M
= DPL 0, pres 1, long 1, def32 0, gran 1^M
processor eflags= interrupt enabled, resume, IOPL = 0^M
current process = 2849 (powerd)^M
trap number = 12^M
panic: page fault^M
cpuid = 3^M
time = 1579847814^M
KDB: stack backtrace:^M
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe004d2a7650^M
vpanic() at vpanic+0x185/frame 0xfe004d2a76b0^M
panic() at panic+0x43/frame 0xfe004d2a7710^M
trap_fatal() at trap_fatal+0x386/frame 0xfe004d2a7770^M
trap_pfault() at trap_pfault+0x4f/frame 0xfe004d2a77e0^M
trap() at trap+0x288/frame 0xfe004d2a7910^M
calltrap() at calltrap+0x8/frame 0xfe004d2a7910^M
--- trap 0xc, rip = 0x8068b018, rsp = 0xfe004d2a79e0, rbp = 
0xfe
004d2a79e0 ---^M
_rm_rlock() at _rm_rlock+0x58/frame 0xfe004d2a79e0^M
sysctl_root_handler_locked() at sysctl_root_handler_locked+0xde/frame 
0xfe00
4d2a7a20^M
sysctl_root() at sysctl_root+0x249/frame 0xfe004d2a7aa0^M
userland_sysctl() at userland_sysctl+0x178/frame 0xfe004d2a7b50^M
sys___sysctl() at sys___sysctl+0x5f/frame 0xfe004d2a7c00^M
amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe004d2a7d30^M
fast_syscall_common() at fast_syscall_common+0x101/frame 
0xfe004d2a7d30^M
--- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x800434f9a, rsp = 
0x7
fffeb38, rbp = 0x7fffeb70 ---^M
Uptime: 2h57m35s^M
Dumping 1823 out of 5095 MB: (CTRL-C to abort) ..1%..11%..21%..31%..41%..51%
..61
%..71%..81%..91%^M
Dump complete^M


Both were unable to save a dump.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


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

Re: Ryzen Threadripper 1950X based on head -r340287: sysctl dev.cpu: 0-30 but no 31? (top shows all 0-31 "CPU"s) [subject corrected]

[Mark Millard]

[Fixing dumb, confusing subject typo. No change below.]

On 2018-Nov-17, at 12:54, Mark Millard  wrote:


> For some reason there is no .dev.cpu.31 listed for the 1950X that
> I use. This is a native boot, not use under Hyper-V. For
> illustration I list:
> 
> # sysctl dev.cpu | grep "desc"
> dev.cpu.30.%desc: ACPI CPU
> dev.cpu.29.%desc: ACPI CPU
> dev.cpu.28.%desc: ACPI CPU
> dev.cpu.27.%desc: ACPI CPU
> dev.cpu.26.%desc: ACPI CPU
> dev.cpu.25.%desc: ACPI CPU
> dev.cpu.24.%desc: ACPI CPU
> dev.cpu.23.%desc: ACPI CPU
> dev.cpu.22.%desc: ACPI CPU
> dev.cpu.21.%desc: ACPI CPU
> dev.cpu.20.%desc: ACPI CPU
> dev.cpu.19.%desc: ACPI CPU
> dev.cpu.18.%desc: ACPI CPU
> dev.cpu.17.%desc: ACPI CPU
> dev.cpu.16.%desc: ACPI CPU
> dev.cpu.15.%desc: ACPI CPU
> dev.cpu.14.%desc: ACPI CPU
> dev.cpu.13.%desc: ACPI CPU
> dev.cpu.12.%desc: ACPI CPU
> dev.cpu.11.%desc: ACPI CPU
> dev.cpu.10.%desc: ACPI CPU
> dev.cpu.9.%desc: ACPI CPU
> dev.cpu.8.%desc: ACPI CPU
> dev.cpu.7.%desc: ACPI CPU
> dev.cpu.6.%desc: ACPI CPU
> dev.cpu.5.%desc: ACPI CPU
> dev.cpu.4.%desc: ACPI CPU
> dev.cpu.3.%desc: ACPI CPU
> dev.cpu.2.%desc: ACPI CPU
> dev.cpu.1.%desc: ACPI CPU
> dev.cpu.0.%desc: ACPI CPU
> 
> # sysctl dev.cpu.0
> dev.cpu.0.temperature: 57.1C
> dev.cpu.0.cx_method: C1/hlt C2/io
> dev.cpu.0.cx_usage_counters: 0 0
> dev.cpu.0.cx_usage: 0.00% 0.00% last 100us
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_supported: C1/1/0 C2/2/100
> dev.cpu.0.freq_levels: 3400/-1 2800/-1 2200/-1
> dev.cpu.0.freq: 3400
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%location: handle=\_PR_.C001
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%desc: ACPI CPU
> 
> # sysctl dev.cpu.31
> sysctl: unknown oid 'dev.cpu.31'
> 
> By contrast I show from top's output all 0-31 CPU's:
> 
> CPU 0:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 1:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 2:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 3:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 4:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 5:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 6:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 7:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 8:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 9:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 10:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 11:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 12:  0.0% user,  0.0% nice,  0.0% system,  1.1% interrupt, 98.9% idle
> CPU 13:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 14:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 15:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 16:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 17:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 18:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 19:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 20:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 21:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 22:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 23:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 24:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 25:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 26:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 27:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 28:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 29:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 30:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 31:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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

[no subject]

[KIRIYAMA Kazuhiko]

Hi,

Today, suddenly pkg or bsdtar failed to core dumped. 
'pkg info -aI' crashed with:


root@vms:~ # pkg info -aI
Segmentation fault (core dumped)
root@vms:~ # ll *.core
-rw---  1 root  wheel  9555968 Apr 25 10:48 pkg.core
root@vms:~ # /usr/libexec/gdb /usr/local/sbin/pkg
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 "amd64-marcel-freebsd"...(no debugging symbols 
found)...
(gdb) core pkg.core
Core was generated by `pkg info -aI'.
Program terminated with signal 11, Segmentation fault.
#0  0x000800306878 in ?? ()
(gdb) bt
#0  0x000800306878 in ?? ()
#1  0x00080021307a in ?? ()
#2  0x000800af8980 in ?? ()
#3  0x000800af7c7c in ?? ()
#4  0x7fffdab8 in ?? ()
#5  0x000800234400 in ?? ()
#6  0x0003 in ?? ()
#7  0x7fffdb60 in ?? ()
#8  0x7fffdb40 in ?? ()
#9  0x0008002155ad in ?? ()
#10 0x7fffdb60 in ?? ()
#11 0x in ?? ()
(gdb) 


And 'make extract' in a port:


root@vms:/var/ports/msrvms/sysutils/vm-bhyve-devel # make clean
===>  Cleaning for vm-bhyve-devel-1.2b
root@vms:/var/ports/msrvms/sysutils/vm-bhyve-devel # make deinstall
===>  Deinstalling for vm-bhyve-devel
===>   vm-bhyve-devel not installed, skipping
root@vms:/var/ports/msrvms/sysutils/vm-bhyve-devel # make -de extract
===>  License BSD2CLAUSE accepted by the user
===>   vm-bhyve-devel-1.2b depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by vm-bhyve-devel-1.2b for building
===>  Extracting for vm-bhyve-devel-1.2b
=> SHA256 Checksum OK for 
churchers-vm-bhyve-v1.2b-c9ec4d05f61efeb98b6cd2dc663f859881a12431_GH0.tar.gz.
Segmentation fault (core dumped)

*** Failed target:  do-extract
*** Failed command: for file in 
churchers-vm-bhyve-v1.2b-c9ec4d05f61efeb98b6cd2dc663f859881a12431_GH0.tar.gz; 
do if ! (cd /var/ports/work/var/ports/msrvms/sysutils/vm-bhyve-devel/work && 
/usr/bin/tar -xf /var/ports/distfiles//$file --no-same-owner 
--no-same-permissions); then exit 1; fi; done
*** Error code 1

Stop.
make: stopped in /var/ports/msrvms/sysutils/vm-bhyve-devel
root@vms:/var/ports/msrvms/sysutils/vm-bhyve-devel # cd 
/var/ports/work/var/ports/msrvms/sysutils/vm-bhyve-devel/work
root@vms:/var/ports/work/var/ports/msrvms/sysutils/vm-bhyve-devel/work # ll 
*.core
-rw---  1 root  wheel  9465856 Apr 25 10:53 bsdtar.core
root@vms:/var/ports/work/var/ports/msrvms/sysutils/vm-bhyve-devel/work # 
/usr/libexec/gdb /usr/bin/tar
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 "amd64-marcel-freebsd"...
(gdb) core bsdtar.core
warning: core file may not match specified executable file.
Core was generated by `/usr/bin/tar -xf 
/var/ports/distfiles//churchers-vm-bhyve-v1.2b-c9ec4d05f61efeb9'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libarchive.so.7...Reading symbols from 
/usr/lib/debug//usr/lib/libarchive.so.7.debug...done.
done.
Loaded symbols for /usr/lib/libarchive.so.7
Reading symbols from /lib/libc.so.7...Reading symbols from 
/usr/lib/debug//lib/libc.so.7.debug...done.
done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /lib/libz.so.6...Reading symbols from 
/usr/lib/debug//lib/libz.so.6.debug...done.
done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/lib/libbz2.so.4...Reading symbols from 
/usr/lib/debug//usr/lib/libbz2.so.4.debug...done.
done.
Loaded symbols for /usr/lib/libbz2.so.4
Reading symbols from /usr/lib/liblzma.so.5...Reading symbols from 
/usr/lib/debug//usr/lib/liblzma.so.5.debug...done.
done.
Loaded symbols for /usr/lib/liblzma.so.5
Reading symbols from /lib/libbsdxml.so.4...Reading symbols from 
/usr/lib/debug//lib/libbsdxml.so.4.debug...done.
done.
Loaded symbols for /lib/libbsdxml.so.4
Reading symbols from /lib/libcrypto.so.8...Reading symbols from 
/usr/lib/debug//lib/libcrypto.so.8.debug...done.
done.
Loaded symbols for /lib/libcrypto.so.8
Reading symbols from /lib/libthr.so.3...Reading symbols from 
/usr/lib/debug//lib/libthr.so.3.debug...done.
done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /libexec/ld-elf.so.1...Reading symbols from 
/usr/lib/debug//libexec/ld-elf.so.1.debug...done.
done.
Loaded symbols for /libexec/ld-elf.so.1
#0  _init () at /ds/src/current/12.0/r331153/lib/csu/amd64/crti.S:34
34  subq$8,%rsp
[New Thread 801075000 (LWP 100316/)]
Current language:  auto; currently 

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

On 2017-Mar-21, at 7:21 PM, Mark Millard  wrote:

> On 2017-Mar-18, at 9:10 PM, Mark Millard  wrote:
> 
>> 
>> On 2017-Mar-18, at 5:53 PM, Mark Millard  wrote:
>> 
>>> A new, significant discovery follows. . .
>>> 
>>> While checking out use of procstat -v I ran
>>> into the following common property for the 3
>>> programs that I looked at:
>>> 
>>> A) My small test program that fails for
>>> a dynamically allocated space.
>>> 
>>> B) sh reporting Failed assertion: "tsd_booted".
>>> 
>>> C) su reporting Failed assertion: "tsd_booted".
>>> 
>>> Here are example addresses from the area of
>>> incorrectly zeroed memory (A then B then C):
>>> 
>>> (lldb) print dyn_region
>>> (region *volatile) $0 = 0x40616000
>>> 
>>> (lldb) print &__je_tsd_booted
>>> (bool *) $0 = 0x40618520
>>> 
>>> (lldb) print &__je_tsd_booted
>>> (bool *) $0 = 0x40618520
>> 
>> That last above was a copy/paste error. Correction:
>> 
>> (lldb) print &__je_tsd_booted
>> (bool *) $0 = 0x4061d520
>> 
>>> The first is from dynamic allocation ending up
>>> in the area. The other two are from libc.so.7
>>> globals/statics ending up in the general area.
>>> 
>>> It looks like something is trashing a specific
>>> memory area for some reason, rather independently
>>> of what the program specifics are.
> 
> I probably should have noted that the processes
> involved were: child/parent then grandparent
> and then great grandparent. The grandparent
> was sh and the great grandparent was su.
> 
> The ancestors in the process tree are being
> damaged, not just the instances of the
> program that demonstrates the problem.
> 
>>> Other notes:
>>> 
>>> At least for my small program showing failure:
>>> 
>>> Being explicit about the combined conditions for failure
>>> for my test program. . .
>>> 
>>> Both tcache enabled and allocations fitting in SMALL_MAXCLASS
>>> are required in order to make the program fail.
>>> 
>>> Note:
>>> 
>>> lldb) print __je_tcache_maxclass
>>> (size_t) $0 = 32768
>>> 
>>> which is larger than SMALL_MAXCLASS. I've not observed
>>> failures for sizes above SMALL_MAXCLASS but not exceeding
>>> __je_tcache_maxclass.
>>> 
>>> Thus tcache use by itself does not seen sufficient for
>>> my program to get corruption of its dynamically allocated
>>> memory: the small allocation size also matters.
>>> 
>>> 
>>> Be warned that I can not eliminate the possibility that
>>> the trashing changed what region of memory it trashed
>>> for larger allocations or when tcache is disabled.
>> 
>> The pine64+ 2GB eventually got into a state where:
>> 
>> /etc/malloc.conf -> tcache:false
>> 
>> made no difference and the failure kept occurring
>> with that symbolic link in place.
>> 
>> But after a reboot of the pin46+ 2GB
>> /etc/malloc.conf -> tcache:false was again effective
>> for my test program. (It was still present from
>> before the reboot.)
>> 
>> I checked the .core files and the allocated address
>> assigned to dyn_region was the same in the tries
>> before and after the reboot. (I had put in an
>> additional raise(SIGABRT) so I'd always have
>> a core file to look at.)
>> 
>> Apparently /etc/malloc.conf -> tcache:false was
>> being ignored before the reboot for some reason?
> 
> I have also discovered that if the child process
> in an example like my program does a:
> 
> (void) posix_madvise(dyn_region, region_size, POSIX_MADV_WILLNEED);
> 
> after the fork but before the sleep/swap-out/wait
> then the problem does not happen. This is without
> any read or write access to the memory between the
> fork and sleep/swap-out/wait.
> 
> By contrast such POSIX_MADV_WILLNEED use in the parent
> process does not change the failure behavior.

I've added another test program to bugzilla
217239 and 217138, one with thousands of 14
KiByte allocations.

The test program usually ends up with them all being
zeroed in the parent and child of the fork.

But I've had a couple of runs where a much smaller
prefix was messed up and then there were normal,
expected values.

#define region_size (14u*1024u)
. . .
#define num_regions (256u*1024u*1024u/region_size)

So num_regions==18724, using up most of 256 MiBytes.

Note: each region has its own 14 KiByte allocation.

But dyn_regions[1296].array[0] in one example was
the first normal value.

In another example dyn_regions[2180].array[4096] was
the first normal value.

The last is interesting for being part way through
an allocation's space. That but aligning with a 4
KiByte page size would seem odd for a pure-jemalloc
issue.

===
Mark Millard
markmi at dsl-only.net

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

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

On 2017-Mar-18, at 9:10 PM, Mark Millard  wrote:

> 
> On 2017-Mar-18, at 5:53 PM, Mark Millard  wrote:
> 
>> A new, significant discovery follows. . .
>> 
>> While checking out use of procstat -v I ran
>> into the following common property for the 3
>> programs that I looked at:
>> 
>> A) My small test program that fails for
>>  a dynamically allocated space.
>> 
>> B) sh reporting Failed assertion: "tsd_booted".
>> 
>> C) su reporting Failed assertion: "tsd_booted".
>> 
>> Here are example addresses from the area of
>> incorrectly zeroed memory (A then B then C):
>> 
>> (lldb) print dyn_region
>> (region *volatile) $0 = 0x40616000
>> 
>> (lldb) print &__je_tsd_booted
>> (bool *) $0 = 0x40618520
>> 
>> (lldb) print &__je_tsd_booted
>> (bool *) $0 = 0x40618520
> 
> That last above was a copy/paste error. Correction:
> 
> (lldb) print &__je_tsd_booted
> (bool *) $0 = 0x4061d520
> 
>> The first is from dynamic allocation ending up
>> in the area. The other two are from libc.so.7
>> globals/statics ending up in the general area.
>> 
>> It looks like something is trashing a specific
>> memory area for some reason, rather independently
>> of what the program specifics are.

I probably should have noted that the processes
involved were: child/parent then grandparent
and then great grandparent. The grandparent
was sh and the great grandparent was su.

The ancestors in the process tree are being
damaged, not just the instances of the
program that demonstrates the problem.

>> Other notes:
>> 
>> At least for my small program showing failure:
>> 
>> Being explicit about the combined conditions for failure
>> for my test program. . .
>> 
>> Both tcache enabled and allocations fitting in SMALL_MAXCLASS
>> are required in order to make the program fail.
>> 
>> Note:
>> 
>> lldb) print __je_tcache_maxclass
>> (size_t) $0 = 32768
>> 
>> which is larger than SMALL_MAXCLASS. I've not observed
>> failures for sizes above SMALL_MAXCLASS but not exceeding
>> __je_tcache_maxclass.
>> 
>> Thus tcache use by itself does not seen sufficient for
>> my program to get corruption of its dynamically allocated
>> memory: the small allocation size also matters.
>> 
>> 
>> Be warned that I can not eliminate the possibility that
>> the trashing changed what region of memory it trashed
>> for larger allocations or when tcache is disabled.
> 
> The pine64+ 2GB eventually got into a state where:
> 
> /etc/malloc.conf -> tcache:false
> 
> made no difference and the failure kept occurring
> with that symbolic link in place.
> 
> But after a reboot of the pin46+ 2GB
> /etc/malloc.conf -> tcache:false was again effective
> for my test program. (It was still present from
> before the reboot.)
> 
> I checked the .core files and the allocated address
> assigned to dyn_region was the same in the tries
> before and after the reboot. (I had put in an
> additional raise(SIGABRT) so I'd always have
> a core file to look at.)
> 
> Apparently /etc/malloc.conf -> tcache:false was
> being ignored before the reboot for some reason?

I have also discovered that if the child process
in an example like my program does a:

(void) posix_madvise(dyn_region, region_size, POSIX_MADV_WILLNEED);

after the fork but before the sleep/swap-out/wait
then the problem does not happen. This is without
any read or write access to the memory between the
fork and sleep/swap-out/wait.

By contrast such POSIX_MADV_WILLNEED use in the parent
process does not change the failure behavior.

===
Mark Millard
markmi at dsl-only.net

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

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

On 2017-Mar-18, at 5:53 PM, Mark Millard  wrote:

> A new, significant discovery follows. . .
> 
> While checking out use of procstat -v I ran
> into the following common property for the 3
> programs that I looked at:
> 
> A) My small test program that fails for
>   a dynamically allocated space.
> 
> B) sh reporting Failed assertion: "tsd_booted".
> 
> C) su reporting Failed assertion: "tsd_booted".
> 
> Here are example addresses from the area of
> incorrectly zeroed memory (A then B then C):
> 
> (lldb) print dyn_region
> (region *volatile) $0 = 0x40616000
> 
> (lldb) print &__je_tsd_booted
> (bool *) $0 = 0x40618520
> 
> (lldb) print &__je_tsd_booted
> (bool *) $0 = 0x40618520

That last above was a copy/paste error. Correction:

(lldb) print &__je_tsd_booted
(bool *) $0 = 0x4061d520

> The first is from dynamic allocation ending up
> in the area. The other two are from libc.so.7
> globals/statics ending up in the general area.
> 
> It looks like something is trashing a specific
> memory area for some reason, rather independently
> of what the program specifics are.
> 
> 
> Other notes:
> 
> At least for my small program showing failure:
> 
> Being explicit about the combined conditions for failure
> for my test program. . .
> 
> Both tcache enabled and allocations fitting in SMALL_MAXCLASS
> are required in order to make the program fail.
> 
> Note:
> 
> lldb) print __je_tcache_maxclass
> (size_t) $0 = 32768
> 
> which is larger than SMALL_MAXCLASS. I've not observed
> failures for sizes above SMALL_MAXCLASS but not exceeding
> __je_tcache_maxclass.
> 
> Thus tcache use by itself does not seen sufficient for
> my program to get corruption of its dynamically allocated
> memory: the small allocation size also matters.
> 
> 
> Be warned that I can not eliminate the possibility that
> the trashing changed what region of memory it trashed
> for larger allocations or when tcache is disabled.

The pine64+ 2GB eventually got into a state where:

/etc/malloc.conf -> tcache:false

made no difference and the failure kept occurring
with that symbolic link in place.

But after a reboot of the pin46+ 2GB
/etc/malloc.conf -> tcache:false was again effective
for my test program. (It was still present from
before the reboot.)

I checked the .core files and the allocated address
assigned to dyn_region was the same in the tries
before and after the reboot. (I had put in an
additional raise(SIGABRT) so I'd always have
a core file to look at.)

Apparently /etc/malloc.conf -> tcache:false was
being ignored before the reboot for some reason?


===
Mark Millard
markmi at dsl-only.net

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

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

A new, significant discovery follows. . .

While checking out use of procstat -v I ran
into the following common property for the 3
programs that I looked at:

A) My small test program that fails for
   a dynamically allocated space.

B) sh reporting Failed assertion: "tsd_booted".

C) su reporting Failed assertion: "tsd_booted".

Here are example addresses from the area of
incorrectly zeroed memory (A then B then C):

(lldb) print dyn_region
(region *volatile) $0 = 0x40616000

(lldb) print &__je_tsd_booted
(bool *) $0 = 0x40618520

(lldb) print &__je_tsd_booted
(bool *) $0 = 0x40618520

The first is from dynamic allocation ending up
in the area. The other two are from libc.so.7
globals/statics ending up in the general area.

It looks like something is trashing a specific
memory area for some reason, rather independently
of what the program specifics are.


Other notes:

At least for my small program showing failure:

Being explicit about the combined conditions for failure
for my test program. . .

Both tcache enabled and allocations fitting in SMALL_MAXCLASS
are required in order to make the program fail.

Note:

lldb) print __je_tcache_maxclass
(size_t) $0 = 32768

which is larger than SMALL_MAXCLASS. I've not observed
failures for sizes above SMALL_MAXCLASS but not exceeding
__je_tcache_maxclass.

Thus tcache use by itself does not seen sufficient for
my program to get corruption of its dynamically allocated
memory: the small allocation size also matters.


Be warned that I can not eliminate the possibility that
the trashing changed what region of memory it trashed
for larger allocations or when tcache is disabled.


===
Mark Millard
markmi at dsl-only.net


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

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

[Summary: I've now tested on a rpi3 in addition to a
pine64+ 2GB. Both contexts show the problem.]

On 2017-Mar-16, at 2:07 AM, Mark Millard  wrote:

> On 2017-Mar-15, at 11:07 PM, Scott Bennett  wrote:
> 
>> Mark Millard  wrote:
>> 
>>> [Something strange happened to the automatic CC: fill-in for my original
>>> reply. Also I should have mentioned that for my test program if a
>>> variant is made that does not fork the swapping works fine.]
>>> 
>>> On 2017-Mar-15, at 9:37 AM, Mark Millard  wrote:
>>> 
 On 2017-Mar-15, at 6:15 AM, Scott Bennett  wrote:
 
>  On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard
>  wrote:
>> On 2017-Mar-14, at 4:44 PM, Bernd Walter  wrote:
>> 
>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
 [test_check() between the fork and the wait/sleep prevents the
 failure from occurring. Even a small access to the memory at
 that stage prevents the failure. Details follow.]
>>> 
>>> Maybe a stupid question, since you might have written it somewhere.
>>> What medium do you swap to?
>>> I've seen broken firmware on microSD cards doing silent data
>>> corruption for some access patterns.
>> 
>> The root filesystem is on a USB SSD on a powered hub.
>> 
>> Only the kernel is from the microSD card.
>> 
>> I have several examples of the USB SSD model and have
>> never observed such problems in any other context.
>> 
>> [remainder of irrelevant material deleted  --SB]
> 
>  You gave a very long-winded non-answer to Bernd's question, so I'll
> repeat it here.  What medium do you swap to?
 
 My wording of:
 
 The root filesystem is on a USB SSD on a powered hub.
 
 was definitely poor. It should have explicitly mentioned the
 swap partition too:
 
 The root filesystem and swap partition are both on the same
 USB SSD on a powered hub.
 
 More detail from dmesg -a for usb:
 
 usbus0: 12Mbps Full Speed USB v1.0
 usbus1: 480Mbps High Speed USB v2.0
 usbus2: 12Mbps Full Speed USB v1.0
 usbus3: 480Mbps High Speed USB v2.0
 ugen0.1:  at usbus0
 uhub0:  on usbus0
 ugen1.1:  at usbus1
 uhub1:  on 
 usbus1
 ugen2.1:  at usbus2
 uhub2:  on usbus2
 ugen3.1:  at usbus3
 uhub3:  on 
 usbus3
 . . .
 uhub0: 1 port with 1 removable, self powered
 uhub2: 1 port with 1 removable, self powered
 uhub1: 1 port with 1 removable, self powered
 uhub3: 1 port with 1 removable, self powered
 ugen3.2:  at usbus3
 uhub4 on uhub3
 uhub4:  on 
 usbus3
 uhub4: MTT enabled
 uhub4: 4 ports with 4 removable, self powered
 ugen3.3:  at usbus3
 umass0 on uhub4
 umass0:  on usbus3
 umass0:  SCSI over Bulk-Only; quirks = 0x0100
 umass0:0:0: Attached to scbus0
 . . .
 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
 da0:  Fixed Direct Access SPC-4 SCSI device
 da0: Serial Number 
 da0: 40.000MB/s transfers
 
 (Edited a bit because there is other material interlaced, even
 internal to some lines. Also: I removed the serial number of the
 specific example device.)
>> 
>>Thank you.  That presents a much clearer picture.
 
>  I will further note that any kind of USB device cannot automatically
> be trusted to behave properly.  USB devices are notorious, for example,
> 
> [reasons why deleted  --SB]
> 
>  You should identify where you page/swap to and then try substituting
> a different device for that function as a test to eliminate the 
> possibility
> of a bad storage device/controller.  If the problem still occurs, that
> means there still remains the possibility that another controller or its
> firmware is defective instead.  It could be a kernel bug, it is true, but
> making sure there is no hardware or firmware error occurring is important,
> and as I say, USB devices should always be considered suspect unless and
> until proven innocent.
 
 [FYI: This is a ufs context, not a zfs one.]
>> 
>>Right.  It's only a Pi, after all. :-)
> 
> It is a Pine64+ 2GB, not an rpi3.
> 
 
 I'm aware of such  things. There is no evidence that has resulted in
 suggesting the USB devices that I can replace are a problem. Otherwise
 I'd not be going down this path. I only have access to the one arm64
 device (a Pine64+ 2GB) so I've no ability to substitution-test what
 is on that board.
>> 
>>There isn't even one open port on that hub that you could plug a
>> flash drive into temporarily to be the paging device?
> 
> Why do you think that I've never tried alternative devices? It
> is just that the result was no evidence that my usually-in-use
> SSD is having a special/local problem: the behavior continues
> across all such contexts when the Pine64+ 2GB is involved. (Again
> I have not had 

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Scott Bennett]

Mark Millard  wrote:

> [Something strange happened to the automatic CC: fill-in for my original
> reply. Also I should have mentioned that for my test program if a
> variant is made that does not fork the swapping works fine.]
>
> On 2017-Mar-15, at 9:37 AM, Mark Millard  wrote:
>
> > On 2017-Mar-15, at 6:15 AM, Scott Bennett  wrote:
> > 
> >>On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard
> >>  wrote:
> >>> On 2017-Mar-14, at 4:44 PM, Bernd Walter  wrote:
> >>> 
>  On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
> > [test_check() between the fork and the wait/sleep prevents the
> > failure from occurring. Even a small access to the memory at
> > that stage prevents the failure. Details follow.]
>  
>  Maybe a stupid question, since you might have written it somewhere.
>  What medium do you swap to?
>  I've seen broken firmware on microSD cards doing silent data
>  corruption for some access patterns.
> >>> 
> >>> The root filesystem is on a USB SSD on a powered hub.
> >>> 
> >>> Only the kernel is from the microSD card.
> >>> 
> >>> I have several examples of the USB SSD model and have
> >>> never observed such problems in any other context.
> >>> 
> >>> [remainder of irrelevant material deleted  --SB]
> >> 
> >>You gave a very long-winded non-answer to Bernd's question, so I'll
> >> repeat it here.  What medium do you swap to?
> > 
> > My wording of:
> > 
> > The root filesystem is on a USB SSD on a powered hub.
> > 
> > was definitely poor. It should have explicitly mentioned the
> > swap partition too:
> > 
> > The root filesystem and swap partition are both on the same
> > USB SSD on a powered hub.
> > 
> > More detail from dmesg -a for usb:
> > 
> > usbus0: 12Mbps Full Speed USB v1.0
> > usbus1: 480Mbps High Speed USB v2.0
> > usbus2: 12Mbps Full Speed USB v1.0
> > usbus3: 480Mbps High Speed USB v2.0
> > ugen0.1:  at usbus0
> > uhub0:  on usbus0
> > ugen1.1:  at usbus1
> > uhub1:  on usbus1
> > ugen2.1:  at usbus2
> > uhub2:  on usbus2
> > ugen3.1:  at usbus3
> > uhub3:  on usbus3
> > . . .
> > uhub0: 1 port with 1 removable, self powered
> > uhub2: 1 port with 1 removable, self powered
> > uhub1: 1 port with 1 removable, self powered
> > uhub3: 1 port with 1 removable, self powered
> > ugen3.2:  at usbus3
> > uhub4 on uhub3
> > uhub4:  on 
> > usbus3
> > uhub4: MTT enabled
> > uhub4: 4 ports with 4 removable, self powered
> > ugen3.3:  at usbus3
> > umass0 on uhub4
> > umass0:  on usbus3
> > umass0:  SCSI over Bulk-Only; quirks = 0x0100
> > umass0:0:0: Attached to scbus0
> > . . .
> > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> > da0:  Fixed Direct Access SPC-4 SCSI device
> > da0: Serial Number 
> > da0: 40.000MB/s transfers
> > 
> > (Edited a bit because there is other material interlaced, even
> > internal to some lines. Also: I removed the serial number of the
> > specific example device.)

 Thank you.  That presents a much clearer picture.
> > 
> >>I will further note that any kind of USB device cannot automatically
> >> be trusted to behave properly.  USB devices are notorious, for example,
> >> 
> >>   [reasons why deleted  --SB]
> >> 
> >>You should identify where you page/swap to and then try substituting
> >> a different device for that function as a test to eliminate the possibility
> >> of a bad storage device/controller.  If the problem still occurs, that
> >> means there still remains the possibility that another controller or its
> >> firmware is defective instead.  It could be a kernel bug, it is true, but
> >> making sure there is no hardware or firmware error occurring is important,
> >> and as I say, USB devices should always be considered suspect unless and
> >> until proven innocent.
> > 
> > [FYI: This is a ufs context, not a zfs one.]

 Right.  It's only a Pi, after all. :-)
> > 
> > I'm aware of such  things. There is no evidence that has resulted in
> > suggesting the USB devices that I can replace are a problem. Otherwise
> > I'd not be going down this path. I only have access to the one arm64
> > device (a Pine64+ 2GB) so I've no ability to substitution-test what
> > is on that board.

 There isn't even one open port on that hub that you could plug a
flash drive into temporarily to be the paging device?  You could then
try your tests before returning to the normal configuration.  If there
isn't an open port, then how about plugging a second hub into one of
the first hub's ports and moving the displaced device to the second
hub?  A flash drive could then be plugged in.  That kind of configuration
is obviously a bad idea for the long run, but just to try your tests it
ought to work well enough.  (BTW, if a USB storage device containing a
paging area drops off=line even momentarily and the system needs to use
it, that is the beginning of the end, even though it may take up to a few
minutes for everything to lock up.  You probably won't be able to do an
orderly 

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

On 2017-Mar-15, at 11:07 PM, Scott Bennett  wrote:

> Mark Millard  wrote:
> 
>> [Something strange happened to the automatic CC: fill-in for my original
>> reply. Also I should have mentioned that for my test program if a
>> variant is made that does not fork the swapping works fine.]
>> 
>> On 2017-Mar-15, at 9:37 AM, Mark Millard  wrote:
>> 
>>> On 2017-Mar-15, at 6:15 AM, Scott Bennett  wrote:
>>> 
   On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard
  wrote:
> On 2017-Mar-14, at 4:44 PM, Bernd Walter  wrote:
> 
>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
>>> [test_check() between the fork and the wait/sleep prevents the
>>> failure from occurring. Even a small access to the memory at
>>> that stage prevents the failure. Details follow.]
>> 
>> Maybe a stupid question, since you might have written it somewhere.
>> What medium do you swap to?
>> I've seen broken firmware on microSD cards doing silent data
>> corruption for some access patterns.
> 
> The root filesystem is on a USB SSD on a powered hub.
> 
> Only the kernel is from the microSD card.
> 
> I have several examples of the USB SSD model and have
> never observed such problems in any other context.
> 
> [remainder of irrelevant material deleted  --SB]
 
   You gave a very long-winded non-answer to Bernd's question, so I'll
 repeat it here.  What medium do you swap to?
>>> 
>>> My wording of:
>>> 
>>> The root filesystem is on a USB SSD on a powered hub.
>>> 
>>> was definitely poor. It should have explicitly mentioned the
>>> swap partition too:
>>> 
>>> The root filesystem and swap partition are both on the same
>>> USB SSD on a powered hub.
>>> 
>>> More detail from dmesg -a for usb:
>>> 
>>> usbus0: 12Mbps Full Speed USB v1.0
>>> usbus1: 480Mbps High Speed USB v2.0
>>> usbus2: 12Mbps Full Speed USB v1.0
>>> usbus3: 480Mbps High Speed USB v2.0
>>> ugen0.1:  at usbus0
>>> uhub0:  on usbus0
>>> ugen1.1:  at usbus1
>>> uhub1:  on usbus1
>>> ugen2.1:  at usbus2
>>> uhub2:  on usbus2
>>> ugen3.1:  at usbus3
>>> uhub3:  on usbus3
>>> . . .
>>> uhub0: 1 port with 1 removable, self powered
>>> uhub2: 1 port with 1 removable, self powered
>>> uhub1: 1 port with 1 removable, self powered
>>> uhub3: 1 port with 1 removable, self powered
>>> ugen3.2:  at usbus3
>>> uhub4 on uhub3
>>> uhub4:  on 
>>> usbus3
>>> uhub4: MTT enabled
>>> uhub4: 4 ports with 4 removable, self powered
>>> ugen3.3:  at usbus3
>>> umass0 on uhub4
>>> umass0:  on usbus3
>>> umass0:  SCSI over Bulk-Only; quirks = 0x0100
>>> umass0:0:0: Attached to scbus0
>>> . . .
>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>>> da0:  Fixed Direct Access SPC-4 SCSI device
>>> da0: Serial Number 
>>> da0: 40.000MB/s transfers
>>> 
>>> (Edited a bit because there is other material interlaced, even
>>> internal to some lines. Also: I removed the serial number of the
>>> specific example device.)
> 
> Thank you.  That presents a much clearer picture.
>>> 
   I will further note that any kind of USB device cannot automatically
 be trusted to behave properly.  USB devices are notorious, for example,
 
  [reasons why deleted  --SB]
 
   You should identify where you page/swap to and then try substituting
 a different device for that function as a test to eliminate the possibility
 of a bad storage device/controller.  If the problem still occurs, that
 means there still remains the possibility that another controller or its
 firmware is defective instead.  It could be a kernel bug, it is true, but
 making sure there is no hardware or firmware error occurring is important,
 and as I say, USB devices should always be considered suspect unless and
 until proven innocent.
>>> 
>>> [FYI: This is a ufs context, not a zfs one.]
> 
> Right.  It's only a Pi, after all. :-)

It is a Pine64+ 2GB, not an rpi3.

>>> 
>>> I'm aware of such  things. There is no evidence that has resulted in
>>> suggesting the USB devices that I can replace are a problem. Otherwise
>>> I'd not be going down this path. I only have access to the one arm64
>>> device (a Pine64+ 2GB) so I've no ability to substitution-test what
>>> is on that board.
> 
> There isn't even one open port on that hub that you could plug a
> flash drive into temporarily to be the paging device?

Why do you think that I've never tried alternative devices? It
is just that the result was no evidence that my usually-in-use
SSD is having a special/local problem: the behavior continues
across all such contexts when the Pine64+ 2GB is involved. (Again
I have not had access to an alternate to the one arm64 board.
That limits my substitution testing possibilities.)

Why would you expect a Flash drive to be better than another SSD
for such testing? (The SSD that I usually use even happens to be
a USB 3.0 SSD, capable of USB 3.0 speeds in USB 3.0 contexts. So
is 

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

[Something strange happened to the automatic CC: fill-in for my original
reply. Also I should have mentioned that for my test program if a
variant is made that does not fork the swapping works fine.]

On 2017-Mar-15, at 9:37 AM, Mark Millard  wrote:

> On 2017-Mar-15, at 6:15 AM, Scott Bennett  wrote:
> 
>>On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard
>>  wrote:
>>> On 2017-Mar-14, at 4:44 PM, Bernd Walter  wrote:
>>> 
 On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
> [test_check() between the fork and the wait/sleep prevents the
> failure from occurring. Even a small access to the memory at
> that stage prevents the failure. Details follow.]
 
 Maybe a stupid question, since you might have written it somewhere.
 What medium do you swap to?
 I've seen broken firmware on microSD cards doing silent data
 corruption for some access patterns.
>>> 
>>> The root filesystem is on a USB SSD on a powered hub.
>>> 
>>> Only the kernel is from the microSD card.
>>> 
>>> I have several examples of the USB SSD model and have
>>> never observed such problems in any other context.
>>> 
>>> [remainder of irrelevant material deleted  --SB]
>> 
>>You gave a very long-winded non-answer to Bernd's question, so I'll
>> repeat it here.  What medium do you swap to?
> 
> My wording of:
> 
> The root filesystem is on a USB SSD on a powered hub.
> 
> was definitely poor. It should have explicitly mentioned the
> swap partition too:
> 
> The root filesystem and swap partition are both on the same
> USB SSD on a powered hub.
> 
> More detail from dmesg -a for usb:
> 
> usbus0: 12Mbps Full Speed USB v1.0
> usbus1: 480Mbps High Speed USB v2.0
> usbus2: 12Mbps Full Speed USB v1.0
> usbus3: 480Mbps High Speed USB v2.0
> ugen0.1:  at usbus0
> uhub0:  on usbus0
> ugen1.1:  at usbus1
> uhub1:  on usbus1
> ugen2.1:  at usbus2
> uhub2:  on usbus2
> ugen3.1:  at usbus3
> uhub3:  on usbus3
> . . .
> uhub0: 1 port with 1 removable, self powered
> uhub2: 1 port with 1 removable, self powered
> uhub1: 1 port with 1 removable, self powered
> uhub3: 1 port with 1 removable, self powered
> ugen3.2:  at usbus3
> uhub4 on uhub3
> uhub4:  on usbus3
> uhub4: MTT enabled
> uhub4: 4 ports with 4 removable, self powered
> ugen3.3:  at usbus3
> umass0 on uhub4
> umass0:  on usbus3
> umass0:  SCSI over Bulk-Only; quirks = 0x0100
> umass0:0:0: Attached to scbus0
> . . .
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number 
> da0: 40.000MB/s transfers
> 
> (Edited a bit because there is other material interlaced, even
> internal to some lines. Also: I removed the serial number of the
> specific example device.)
> 
>>I will further note that any kind of USB device cannot automatically
>> be trusted to behave properly.  USB devices are notorious, for example,
>> for momentarily dropping off-line and then immediately reconnecting.  (ZFS
>> reacts very poorly to such events, BTW.)  This misbehavior can be caused
>> by either processor involved, i.e., the one controlling either the
>> upstream or the downstream device.  Hubs are really bad about this, but
>> any USB device can be guilty.  You may have a defective storage device,
>> its controller may be defective, or any controller in the chain all the
>> way back to the motherboard may be defective or, not defective, but
>> corrupted by having been connected to another device with corrupted
>> (infected) firmware that tries to flash itself into the firmware flash
>> chips in its potential victim.
>>Flash memory chips, spinning disks, or {S,}{D,}RAM chips can be
>> defective.  Without parity bits, the devices may return bad data and lie
>> about the presence of corrupted data.  That, for example, is where ZFS
>> is better than any kind of classical RAID because ZFS keeps checksums on
>> everything, so it has a reasonable chance of detecting corruption even
>> without parity support and, if there is any redundancy in the pool or the
>> data set, fixing the bad data machine.  Even having parity generally
>> allows only the detection of single-bit errors, but not of repairing them.
>>You should identify where you page/swap to and then try substituting
>> a different device for that function as a test to eliminate the possibility
>> of a bad storage device/controller.  If the problem still occurs, that
>> means there still remains the possibility that another controller or its
>> firmware is defective instead.  It could be a kernel bug, it is true, but
>> making sure there is no hardware or firmware error occurring is important,
>> and as I say, USB devices should always be considered suspect unless and
>> until proven innocent.
> 
> [FYI: This is a ufs context, not a zfs one.]
> 
> I'm aware of such  things. There is no evidence that has resulted in
> suggesting the USB devices that I can replace are a problem. Otherwise
> I'd not be going down this path. I 

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

A single Byte access to a 4K Byte aligned region between
the fork and wait/sleep/swap-out prevents that specific
4K Byte region from having the (bad) zeros.

Sounds like a page sized unit of behavior to me.

Details follow.

On 2017-Mar-14, at 3:28 PM, Mark Millard <mar...@dsl-only.net> wrote:

> [test_check() between the fork and the wait/sleep prevents the
> failure from occurring. Even a small access to the memory at
> that stage prevents the failure. Details follow.]
> 
> On 2017-Mar-14, at 11:07 AM, Mark Millard <mar...@dsl-only.net> wrote:
> 
>> [This is just a correction to the subject-line text to say arm64
>> instead of amd64.]
>> 
>> On 2017-Mar-14, at 12:58 AM, Mark Millard <mar...@dsl-only.net> wrote:
>> 
>> [Another correction I'm afraid --about alternative program variations
>> this time.]
>> 
>> On 2017-Mar-13, at 11:52 PM, Mark Millard <mar...@dsl-only.net> wrote:
>> 
>>> I'm still at a loss about how to figure out what stages are messed
>>> up. (Memory coherency? Some memory not swapped out? Bad data swapped
>>> out? Wrong data swapped in?)
>>> 
>>> But at least I've found a much smaller/simpler example to demonstrate
>>> some problem with in my Pine64+_ 2GB context.
>>> 
>>> The Pine64+ 2GB is the only amd64 context that I have access to.
>> 
>> Someday I'll learn to type arm64 the first time instead of amd64.
>> 
>>> The following program fails its check for data
>>> having its expected byte pattern in dynamically
>>> allocated memory after a fork/swap-out/swap-in
>>> sequence.
>>> 
>>> I'll note that the program sleeps for 60s after
>>> forking to give time to do something else to
>>> cause the parent and child processes to swap
>>> out (RES=0 as seen in top).
>> 
>> The following about the extra test_check() was
>> wrong.
>> 
>>> Note the source code line:
>>> 
>>> // test_check(); // Adding this line prevents failure.
>>> 
>>> It seem that accessing the region contents before forking
>>> and swapping avoids the problem. But there is a problem
>>> if the region was only written-to before the fork/swap.
> 
> There is a place that if a test_check call is put then the
> problem does not happen at any stage: I tried putting a
> call between the fork and the later wait/sleep code:

I changed the byte sequence patterns to avoid
zero values since the bad values are zeros:

static value_type value(size_t v) { return (value_type)((v&0xFEu)|0x1u); }
  // value now avoids the zero value since the failures
  // are zeros.

With that I can then test accurately what bytes have
bad values vs. do not. I also changed to:

void partial_test_check(void) {
if (value(0u)!=gbl_region.array[0])raise(SIGABRT);
if (value(0u)!=(*dyn_region).array[0]) raise(SIGABRT);
}

since previously [0] had a zero value and so I'd used [1].

On this basis I'm now using the below. See the comments tied
to partial_test_check() calls:

extern void test_setup(void); // Sets up the memory byte patterns.
extern void test_check(void); // Tests the memory byte patterns.
extern void partial_test_check(void); // Tests just [0] of each region
  // (gbl_region and dyn_region).

int main(void) {
test_setup();
test_check(); // Before fork() [passes]

pid_t pid = fork();
int wait_status = 0;;

// After fork; before waitsleep/swap-out.

if (0==pid) partial_test_check();
 // Even the above is sufficient by
 // itself to prevent failure for
 // region_size 1u through
 // 4u*1024u!
 // But 4u*1024u+1u and above fail
 // with this access to memory.
 // The failing test is of
 // (*dyn_region).array[4096u].
 // This test never fails here.

if (0<pid) partial_test_check(); // This never prevents
 // later failures (and
 // never fails here).

if (0<pid) { wait(_status); }

if (-1!=wait_status && 0<=pid) {
if (0==pid) {
sleep(60);

// During this manually force this process to
// swap out. I use something like:

// stress -m 1 --vm-bytes 1800M

// in another shell and ^C'ing it after top
// shows the swapped status desired. 1800M
// just happened to work on the Pine64+ 2GB
// that I was using. I watch with top -PCwaopid .
}

test_check(); // After wait/sleep [fails 

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

On 2017-Mar-14, at 4:44 PM, Bernd Walter  wrote:

> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
>> [test_check() between the fork and the wait/sleep prevents the
>> failure from occurring. Even a small access to the memory at
>> that stage prevents the failure. Details follow.]
> 
> Maybe a stupid question, since you might have written it somewhere.
> What medium do you swap to?
> I've seen broken firmware on microSD cards doing silent data
> corruption for some access patterns.

The root filesystem is on a USB SSD on a powered hub.

Only the kernel is from the microSD card.

I have several examples of the USB SSD model and have
never observed such problems in any other context.


The original issue that started this investigation
has been reported by several people on the lists:

Failed assertion: "tsd_booted"

on arm64 specifically, no other contexts so far as
I know. Earlier I had discovered that:

A) I could use a swap-in to cause the messages from
   instances of sh or su that had swapped out earlier.

B) The core dumps showed that a large memory region
   containing the global tsd_booted had all turned
   to be zero bytes. The assert is just exposing one
   of those zeros. (tsd_booted is from jemalloc that
   is in a .so that is loaded.)

This prompted me to look for simpler contexts involving
swapping that also show memory corruption.

So far I've only managed to produce corrupted memory when
fork and later swapping are both involved. Being a shared
library global is not a requirement for the problem,
although such contexts can have an issue. I've not made a
simpler example of that yet, although I tried.

I have not explored vfork, rfork, or any other alternatives.

So far all failure examples end up with zeroed memory when
the memory does not match the original pattern from before
the fork. At least that is what the core dumps show for all
examples that I've looked at.

See bugzilla 217138 and 217239. In some respects this example
is more analogous to the 217239 context as I remember.

My tests on amd64, armv6 (really -mcpu=cortex-a7 so armv7),
and powerpc64 have never produced any problems, including
never getting the failed assertion. Only arm64. (But I've
access to only one arm64 system, a Pine64+ 2GB.)

Prior to this I tracked down a different arm64 problem to
the fork_trampline code (for the child process) modifying
a system register but in a place allowing interrupts that
could also change the value. Andrew Turner fixed that
one at the time.

For this fork/swapping kind of issue I'm not sure that
I'll be able to do more than provide the simpler
example and the steps that I used. My isolating the
internal stage(s) and specific problem(s) at the code
level of detail does not seem likely.

But whatever is found needs to be able to explain the
contrast with an access after the fork but before the
swap preventing the failing behavior. So what I've got
so far hopefully does provide some hints to someone.

===
Mark Millard
markmi at dsl-only.net

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

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Bernd Walter]

On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
> [test_check() between the fork and the wait/sleep prevents the
> failure from occurring. Even a small access to the memory at
> that stage prevents the failure. Details follow.]

Maybe a stupid question, since you might have written it somewhere.
What medium do you swap to?
I've seen broken firmware on microSD cards doing silent data
corruption for some access patterns.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

[test_check() between the fork and the wait/sleep prevents the
failure from occurring. Even a small access to the memory at
that stage prevents the failure. Details follow.]

On 2017-Mar-14, at 11:07 AM, Mark Millard <mar...@dsl-only.net> wrote:

> [This is just a correction to the subject-line text to say arm64
> instead of amd64.]
> 
> On 2017-Mar-14, at 12:58 AM, Mark Millard <mar...@dsl-only.net> wrote:
> 
> [Another correction I'm afraid --about alternative program variations
> this time.]
> 
> On 2017-Mar-13, at 11:52 PM, Mark Millard <mar...@dsl-only.net> wrote:
> 
>> I'm still at a loss about how to figure out what stages are messed
>> up. (Memory coherency? Some memory not swapped out? Bad data swapped
>> out? Wrong data swapped in?)
>> 
>> But at least I've found a much smaller/simpler example to demonstrate
>> some problem with in my Pine64+_ 2GB context.
>> 
>> The Pine64+ 2GB is the only amd64 context that I have access to.
> 
> Someday I'll learn to type arm64 the first time instead of amd64.
> 
>> The following program fails its check for data
>> having its expected byte pattern in dynamically
>> allocated memory after a fork/swap-out/swap-in
>> sequence.
>> 
>> I'll note that the program sleeps for 60s after
>> forking to give time to do something else to
>> cause the parent and child processes to swap
>> out (RES=0 as seen in top).
> 
> The following about the extra test_check() was
> wrong.
> 
>> Note the source code line:
>> 
>> // test_check(); // Adding this line prevents failure.
>> 
>> It seem that accessing the region contents before forking
>> and swapping avoids the problem. But there is a problem
>> if the region was only written-to before the fork/swap.

There is a place that if a test_check call is put then the
problem does not happen at any stage: I tried putting a
call between the fork and the later wait/sleep code:

int main(void) {
test_setup();
test_check(); // Before fork() [passes]

pid_t pid = fork();
int wait_status = 0;;

// test_check(); // After fork(); before wait/sleep. 
 // If used it prevents failure later!

if (0<pid) { wait(_status); }

if (-1!=wait_status && 0<=pid) {
if (0==pid) {
sleep(60);

// During this manually force this process to
// swap out. I use something like:

// stress -m 1 --vm-bytes 1800M

// in another shell and ^C'ing it after top
// shows the swapped status desired. 1800M
// just happened to work on the Pine64+ 2GB
// that I was using. I watch with top -PCwaopid .
}

test_check(); // After wait/sleep [fails for small-enough region_sizes]
}
}

My guess is that the forced access attempt when the line is
uncommented causes local some sort of status/caching update
for that memory and with that in place swap-out gets the
right information swapped out and then later that information
is swapped back in.

But an interesting point is that the failing case fails in both
the parent process of the fork and the child process, both seeing
an all-zero pattern for the dynamically allocated region.

Even for using:

void partial_test_check(void) {
if (1u!=gbl_region.array[1])raise(SIGABRT);
if (1u!=(*dyn_region).array[1]) raise(SIGABRT);
}

instead of test_check as what to call between the fork
and the wait/sleep the following no longer gets the
problem at any stage:

extern void partial_test_check(void); // Tests some of the memory byte pattern  
  // but not all of it.

int main(void) {
test_setup();
test_check(); // Before fork() [passes]

pid_t pid = fork();
int wait_status = 0;;

// test_check(); // After fork(); before wait/sleep. 
 // If used it prevents failure later!

partial_test_check(); // Does a small access do such?

if (0<pid) { wait(_status); }

if (-1!=wait_status && 0<=pid) {
if (0==pid) {
sleep(60);

// During this manually force this process to
// swap out. I use something like:

// stress -m 1 --vm-bytes 1800M

// in another shell and ^C'ing it after top
// shows the swapped status desired. 1800M
// just happened to work on the Pine64+ 2GB
// that I was using. I watch with top -PCwaopid .
}

test_check(); // After wait/sleep [fails for small-enough region_sizes]
}
}

This suggests to me that the small access is forcing one or more things to
be initialized for memory access that fork is not establishing of itself.
It appears that if established correctly then the swap-out/swap-in
sequence would work okay witho

arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

[This is just a correction to the subject-line text to say arm64
instead of amd64.]

On 2017-Mar-14, at 12:58 AM, Mark Millard <mar...@dsl-only.net> wrote:

[Another correction I'm afraid --about alternative program variations
this time.]

On 2017-Mar-13, at 11:52 PM, Mark Millard <mar...@dsl-only.net> wrote:

> I'm still at a loss about how to figure out what stages are messed
> up. (Memory coherency? Some memory not swapped out? Bad data swapped
> out? Wrong data swapped in?)
> 
> But at least I've found a much smaller/simpler example to demonstrate
> some problem with in my Pine64+_ 2GB context.
> 
> The Pine64+ 2GB is the only amd64 context that I have access to.

Someday I'll learn to type arm64 the first time instead of amd64.

> The following program fails its check for data
> having its expected byte pattern in dynamically
> allocated memory after a fork/swap-out/swap-in
> sequence.
> 
> I'll note that the program sleeps for 60s after
> forking to give time to do something else to
> cause the parent and child processes to swap
> out (RES=0 as seen in top).

The following about the extra test_check() was
wrong.

> Note the source code line:
> 
>  // test_check(); // Adding this line prevents failure.
> 
> It seem that accessing the region contents before forking
> and swapping avoids the problem. But there is a problem
> if the region was only written-to before the fork/swap.

This was because I'd carelessly moved some loop variables to
globals in a way that depended on the initialization of the
globals and the extra call changed those values.

I've noted code adjustments below (3 lines). I get the failures
with them as well.

> Another point is the size of the region matters: <= 14K Bytes
> fails and > 14K Bytes works for as much has I have tested.
> 
> 
> # more swap_testing.c
> // swap_testing.c
> 
> // Built via (c++ was clang++ 4.0 in my case):
> //
> // cc -g -std=c11 -Wpedantic swap_testing.c
> // -O0 and -O2 also gets the problem.
> 
> #include  // for fork(), sleep(.)
> #include   // for pid_t
> #include// for wait(.)
> 
> extern void test_setup(void); // Sets up the memory byte pattern.
> extern void test_check(void); // Tests the memory byte pattern.
> 
> int main(void)
> {
>  test_setup();
  test_check(); // This test passes.
> 
>  pid_t pid = fork();
>  int wait_status = 0;;
> 
>  if (0<pid) { wait(_status); }
> 
>  if (-1!=wait_status && 0<=pid)
>  {
>  if (0==pid)
>  {
>  sleep(60);
> 
>  // During this manually force this process to
>  // swap out. I use something like:
> 
>  // stress -m 1 --vm-bytes 1800M
> 
>  // in another shell and ^C'ing it after top
>  // shows the swapped status desired. 1800M
>  // just happened to work on the Pine64+ 2GB
>  // that I was using.
>  }
> 
>  test_check();
>  }
> }
> 
> // The memory and test code follows.
> 
> #include // for bool, true, false
> #include  // for size_t, NULL
> #include  // for malloc(.), free(.)
> 
> #include  // for raise(.), SIGABRT
> 
> #define region_size (14u*1024u)
>  // Bad dyn_region pattern, parent and child
>  // processes:
>  //  256u, 4u*1024u, 8u*1024u, 9u*1024u,
>  // 12u*1024u, 14u*1024u
> 
>  // Works:
>  // 14u*1024u+1u, 15u*1024u, 16u*1024u,
>  // 32u*1024u, 256u*1024u*1024u
> 
> typedef volatile unsigned char value_type;
> 
> struct region_struct { value_type array[region_size]; };
> typedef struct region_struct region;
> 
> static regiongbl_region;
> static region * volatile dyn_region = NULL;
> 
> static value_type value(size_t v) { return (value_type)v; }
> 
> void test_setup(void) {
>  dyn_region = malloc(sizeof(region));
>  if (!dyn_region) raise(SIGABRT);
> 
>  for(size_t i=0u; i<region_size; i++) {
>  (*dyn_region).array[i] = gbl_region.array[i] = value(i);
>  }
> }
> 
> static volatile bool gbl_failed = false; // Until potentially disproved
> static volatile size_t gbl_pos = 0u;
> 
> static volatile bool dyn_failed = false; // Until potentially disproved
> static volatile size_t dyn_pos = 0u;
> 
> void test_check(void) {
  gbl_pos = 0u;
>  while (!gbl_failed && gbl_pos<region_size) {
>  gbl_failed = (value(gbl_pos) != gbl_region.array[gbl_pos]);
>  gbl_pos++;
>  }
> 
  dyn_pos = 0u;
>  while (!dyn_failed && dyn_pos<region_size) {
>  dyn_failed = (value(dyn_pos) != (*dyn_region).array[dyn_pos]);
>  // Not

[no subject]

[david becker]

Mit freundlichen Grüßen
David Becker
Vossemer Straße 17
41812 Erkelenz
Tel.: 01520 3916568
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Subject: Re: NanoBSD install phase failing for releng/11

[Ross Alexander]

On Mon, Aug 22, 2016 at 01:08:11PM +0200, Guido Falsi wrote:


Hi,

While building a NanoBSD image using releng/11 sources I got this error
message:

===> lib/libc++ (install)
install  -C -o root -g wheel -m 444   libc++.a
/usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/

[...]

/usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libcxxrt.so
install: symlink ../../lib/libcxxrt.so.1 ->
/usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib: File exists
*** Error code 71

Stop.


I'm seeing this error (symlink of libcxxrt.so.1 fails with diagnostic
of prexisting file) in three seperate poudrieres, running on
12-current amd64s machines, while attempting to build or update
11-stable-amd64 jails.

   poudriere jail -j 11-stab-amd64 -u

I've tried blowing the jail away and rebuilding;

   poudriere jail -d -j 11-stab-amd64
   poudriere jail -c -j 11-stab-amd64 -m svn -v stable/11

but no luck; this fails as well, in the same way (and
leaves me with no 11-stab-amd64 build jail, foo.)

The 12-curr host machines are reasonably fresh builds -

aubey2:/root # uname -a
FreeBSD aubey2.bogons 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r304443: \
Thu Aug 18 23:46:18 MDT 2016 \
toor@aubey2.bogons:/usr/obj/usr/src/sys/GENERIC-NODEBUG  amd64

chimera:/root # uname -a
FreeBSD chimera.bogons 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r304224M: \
Tue Aug 16 11:08:38 MDT 2016 \
toor@chimera.bogons:/usr/obj/usr/src/sys/GENERIC-NODEBUG  amd64

/etc/make.conf is

NO_LPR=YES
OPTIONS_SET=CUPS
WITH_CUPS=YES
CUPS_OVERWRITE_BASE=YES

KERNCONF=GENERIC-NODEBUG
MALLOC_PRODUCTION=yes
SVN=/usr/bin/svnlite
SVN_UPDATE=yes
WITH_FAST_DEPEND=yes
WITH_GALLIUM="YES"
WITH_PKGNG=yes

Some experimentation shows that "WITH_FAST_DEPEND=yes" isn't the issue;
in or out, same result.

log just before the fail is:

===> lib/libcxxrt (install)
--- _libinstall ---
install -N /usr/local/pd/jails/11-stab-amd64/usr/src/etc  -C -o root -g 
wheel -m 444   libcxxrt.a /usr/local/pd/jails/11-stab-amd64/usr/lib/
install -N /usr/local/pd/jails/11-stab-amd64/usr/src/etc  -C -o root -g 
wheel -m 444   libcxxrt_p.a /usr/local/pd/jails/11-stab-amd64/usr/lib/
install -N /usr/local/pd/jails/11-stab-amd64/usr/src/etc  -s -o root -g 
wheel -m 444 libcxxrt.so.1 /usr/local/pd/jails/11-stab-amd64/lib/
install -N /usr/local/pd/jails/11-stab-amd64/usr/src/etc  -o root -g wheel 
-m 444libcxxrt.so.1.debug 
/usr/local/pd/jails/11-stab-amd64/usr/lib/debug/lib/
install -N /usr/local/pd/jails/11-stab-amd64/usr/src/etc -l rs  
/usr/local/pd/jails/11-stab-amd64/lib/libcxxrt.so.1  
/usr/local/pd/jails/11-stab-amd64/usr/lib/libcxxrt.so
install: symlink ../../lib/libcxxrt.so.1 -> 
/usr/local/pd/jails/11-stab-amd64/usr/lib: File exists
*** [_libinstall] Error code 71
make[5]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src/lib/libcxxrt
1 error
make[5]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src/lib/libcxxrt
*** [realinstall] Error code 2
make[4]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src/lib
1 error
make[4]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src/lib
*** [realinstall_subdir_lib] Error code 2
make[3]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src
1 error
make[3]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src
*** [reinstall] Error code 2
make[2]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src
1 error
make[2]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src
*** [installworld] Error code 2
make[1]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src
1 error
make[1]: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src
*** [installworld] Error code 2
make: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src
1 error
make: stopped in /usr/local/pd/jails/11-stab-amd64/usr/src
[00:35:57] >> Error: Failed to 'make installworld'
15113.866u 1497.004s 35:57.43 769.9%49262+602k 335984+2724910io 
484194pf+0w

regards,
Ross
--
Ross Alexander, (780) 675-6823 desk / (780) 689-0749 cell, r...@athabascau.ca

   "Plato's scheme of folly, which would have the philosophers take
over the management of affairs, has been turned on its head; the
men of affairs have taken over the direction and pursuit of
knowledge."
-- Thorstein Veblen, _The Higher Learning in America_

--
   This communication is intended for the use of the recipient to whom it
   is addressed, and may contain confidential, personal, and or privileged
   information. Please contact us immediately if you are not the intended
   recipient of this communication, and do not copy, distribute, or take
   action relying on it. Any communications received in error, or
   subsequent reply, should be deleted or destroyed.
---
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To 

[no subject]

[Mike Ma]

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[no subject]

[Mike.]

I'm starting to look at FreeBSD 11-current to see what's coming soon.
 I have an older notebook that I use for test environments for
purposes such as this.  Unfortunately, the notebook won't boot up
from the install CD, there's a loop it cannot seem to get out of.  



Details are:

- The install CD was made from this image:
   FreeBSD-11.0-CURRENT-i386-20140918-r271779-disc1

- The dmesg for the notebook is at the end of this message.  The
dmesg was captured with FreeBSD 10.0.  In the dmesg, you can see the
following lines:

(aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00
00 00 00
(aprobe0:ata1:0:1:0): CAM status: Command timeout
(aprobe0:ata1:0:1:0): Error 5, Retry was blocked
run_interrupt_driven_hooks: still waiting after 60 seconds for
xpt_config
(aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00
00 00 00
(aprobe0:ata1:0:1:0): CAM status: Command timeout
(aprobe0:ata1:0:1:0): Error 5, Retry was blocked


which, while slowing down the boot process drastically, still allowed
the boot process to run to successful completion.


- When I try to boot using the FreeBSD 11-current install CD, that
loop seems to go on ad infinitum, or at least for the 5 minutes until
I gave up.   I cannot post a dmesg from that boot-up because I never
got to a prompt.  However, I did take a couple of pictures of the
offending screens.  They are here:
 http://archive.mgm51.com/cache/fbsd-11-current-01.jpg
 http://archive.mgm51.com/cache/fbsd-11-current-02.jpg
The first image shows the start of the looping, and the second shows
the continuation.


While this notebook is used only for testing, it is important to me
in that aspect.  How can I get around this looping issue?

Please let me know if there's any additional info you need.

Thanks.





And now, the dmesg...

Copyright (c) 1992-2014 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-RELEASE-p8 #1 r271323: Wed Sep 10 20:25:45 EDT 2014
r...@a31pf.245l.home:/usr/obj/usr/src/sys/GENERIC i386
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.60-MHz 686-class
CPU)
  Origin = GenuineIntel  Id = 0xf24  Family = 0xf  Model = 0x2
Stepping = 4
  Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,
MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM
real memory  = 1073741824 (1024 MB)
avail memory = 1029230592 (981 MB)
kbd1 at kbdmux0
random: Software, Yarrow initialized
acpi0: IBM TP-1G on motherboard
acpi_ec0: Embedded Controller: GPE 0x1c, ECDT port 0x62,0x66 on
acpi0
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 3ff0 (3) failed
cpu0: ACPI CPU on acpi0
attimer0: AT timer port 0x40-0x43 irq 0 on acpi0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0
Event timer RTC frequency 32768 Hz quality 0
Timecounter ACPI-safe frequency 3579545 Hz quality 850
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on
acpi0
acpi_lid0: Control Method Lid Switch on acpi0
acpi_button0: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
agp0: Intel 82845 host to AGP bridge on hostb0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display port 0x3000-0x30ff mem
0xe800-0xefff,0xd010-0xd010 irq 11 at device 0.0 on
pci1
vgapci0: Boot video device
uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port
0x1800-0x181f irq 11 at device 29.0 on pci0
usbus0 on uhci0
uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port
0x1820-0x183f irq 11 at device 29.1 on pci0
usbus1 on uhci1
uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port
0x1840-0x185f irq 11 at device 29.2 on pci0
usbus2 on uhci2
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pci2: ACPI PCI bus on pcib2
cbb0: RF5C476 PCI-CardBus Bridge mem 0x5000-0x5fff irq 11
at device 0.0 on pci2
cardbus0: CardBus bus on cbb0
pccard0: 16-bit PCCard bus on cbb0
cbb1: RF5C476 PCI-CardBus Bridge mem 0x5010-0x50100fff irq 11
at device 0.1 on pci2
cardbus1: CardBus bus on cbb1
pccard1: 16-bit PCCard bus on cbb1
pci2: serial bus, FireWire at device 0.2 (no driver attached)
fxp0: Intel 82801CAM (ICH3) Pro/100 VE Ethernet port 0x8000-0x803f
mem 0xd020-0xd0200fff irq 11 at device 8.0 on pci2
miibus0: MII bus on fxp0
inphy0: i82562ET 10/100 media interface PHY 1 on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto,
auto-flow
fxp0: Ethernet address: 00:0e:9b:2c:d3:f6
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH3 UDMA100 controller port

[no subject]

[Garrett Cooper]

Hi,
As a heads up, it appears that some sysctl output is broken on
CURRENT... please see this bug for more details:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192544 .
Thank you!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[no subject]

[Adrian Chadd]

Hi guys,

I'm running up to date -HEAD (from Jan 26) on a Lenovo T400 with:

vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086
rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
class  = display
subclass   = VGA
vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086
rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
class  = display

..and this happens soon after I start using xorg:

error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
elapsed... GPU hung
info: [drm] capturing error event; look for more information in sysctl
hw.dri.0.info.i915_error_state
error: [drm:pid0:i915_reset] *ERROR* Failed to reset chip.

Who/where should I post the debug information? The error state is .. large.

Thanks,



-a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: (no subject)

[Jakub Lach]

I'm using a T400 with exact same GM45 and besides error:
[drm:pid861:intel_lvds_enable] *ERROR* timed out waiting for panel to power
off I don't experience errors with FreeBSD 10.0-STABLE #0 r261219 amd64,
xorg trunk.



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/no-subject-tp5881101p5881165.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[no subject]

[Markiyan Kushnir]

I started some ports to compile inside a bhyve instance:

root@vm:~ # uname -a
FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0
r259250: Thu Dec 12 14:17:32 EET 2013
r...@vm.mkushnir.zapto.org:/
usr/obj/usr/src.svnup/sys/MAREK  amd64

and left it running unattended. Approx. 2 hours later the host went to
panic. The bhyve instance survived after the panic and I could be able
to complete my ports compilation.

core.txt attached (gzipped)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[no subject]

[Denis D]

Hello Community,
I hope someone could help me with this problem. The last days I have tried to 
find a solution, but haven't found one.
The watchdog timeout happens, when I'm going to download something or copy a 
file on my FTP server. When I start the transfer of the file, I wait a moment 
and then my down-/upload freezes at something around 500[ ]KB. After waiting a 
little while or press a key like return, it comes to the interrupt storm.

interrupt storm detected on irq51:; throttling interrupt source

Here is some information about my system:
ifconfig msk0
msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500  
options=c009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE
   ether bc:ae:c5:5a:ef:ec inet 192.168.2.30 netmask 0xff00 broadcast 
192.168.2.255nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCALmedia: 
Ethernet autoselect (100baseTX full-duplex,flowcontrol,rxpause,txpause)   
 status: active

pciconf -lv
mskc0@pci0:3:0:0:   class=0x02 card=0x84391043 chip=0x438111ab rev=0x11 
hdr=0x00vendor = 'Marvell Technology Group Ltd.'device = 'Yukon 
Optima 88E8059 [PCIe Gigabit Ethernet Controller with AVB]'class  = 
networksubclass   = ethernet

vmstat -i
interrupt  total   rateirq1: atkbd0 
916  2irq16: hdac1  97  0irq17: 
ehci0 ehci1+ 8729 21irq18: ohci0 ohci1* 
  67  0irq19: ahci12883  7irq25: hdac0  
 4  0irq51: mskc0  90   
   0irq256: hpet0:t0   30332 75Total
  43118107

loader.conf
hw.msk.msi_disable=1hw.pci.enable_msi=0hw.pci.enable_msix=0rc.confCode:hostname=FreeBSD.local.domainkeymap=german.iso.acc.kbdifconfig_msk0=DHCP
sshd_enable=YESmoused_enable=YESpowerd_enable=YES# Set dumpdev to AUTO 
to enable crash dumps, NO to disabledumpdev=AUTO

I have also tried to change ifconfig_msk0=DHCP to ifconfig_msk0=SYNCDHCP 
but nothing changed.
If nothing helps, I will buy a new network card. 
  
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[no subject]

[AN]

FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #33 r246130: Wed Jan 30 
15:00:08 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


I just rebuilt the world and kernel.  Then I rebuilt 
/usr/ports/emulators/virtualbox-ose-kmod.


# kldstat
Id Refs AddressSize Name
 1   24 0x8020 116fac0  kernel
 21 0x8137 ee74c8   nvidia.ko
 33 0x82258000 1393f8   linux.ko
 41 0x82412000 997d linprocfs.ko
 51 0x8241c000 344b ums.ko
 61 0x8242 29c3 uhid.ko
 71 0x82423000 2e7b0vboxdrv.ko


# pkg info |grep box
virtualbox-ose-4.2.6   A general-purpose full virtualizer for x86 
hardware

virtualbox-ose-kmod-4.2.6_1VirtualBox kernel module for FreeBSD

Virtualbox suddenly broke for me, possibly related 
to this:

http://svnweb.FreeBSD.org/base?view=revisionrevision=246028

Fix some symbol version mismatches between libstdc++ and 
libsupc++/libcxxrt that were causing the runtime and STL libraries to see 
different versions of various classes and functions when libstdc++ is used as a filter.


When I try to start Vbox it fails with:
# VirtualBox
VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: 
/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by 
/usr/local/lib/virtualbox/VBoxRT.so not found



With all due respect to developers, are these changes tested at all before 
they are added to the codebase?


I understand this is a development branch.  I am not a developer, but it 
seems to me more thought and testing should be done before changes like 
this are committed.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

(no subject)

[Ian FREISLICH]

John Baldwin wrote:
 On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
  (kgdb) frame 7
  #7  0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a'
, 
  m=0xc191bf70, prot=7 '\a', wired=1) at 
 /usr/src/sys/i386/i386/pmap.c:1596
  1596root = vm_page_splay(mpte-pindex, root);
  (kgdb) l
  1591root = pmap-pm_root;
  1592if (root == NULL) {
  1593mpte-left = NULL;
  1594mpte-right = NULL;
  1595} else {
  1596root = vm_page_splay(mpte-pindex, root);
  1597if (mpte-pindex  root-pindex) {
  1598mpte-left = root-left;
  1599mpte-right = root;
  1600root-left = NULL;
 
 Ok, can you do 'p root', 'p mpte', and 'p *mpte'?

(kgdb) frame 7
#7  0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a', 
m=0xc191bf70, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:1596
1596root = vm_page_splay(mpte-pindex, root);
(kgdb) p root
No symbol root in current context.
(kgdb) p mpte
$1 = 0x0
(kgdb) p *mpte
Cannot access memory at address 0x0


-- 
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: (no subject)

[Konstantin Belousov]

On Wed, May 23, 2012 at 03:42:14PM +0200, Ian FREISLICH wrote:
 John Baldwin wrote:
  On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
   (kgdb) frame 7
   #7  0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 
   '\a'
 , 
   m=0xc191bf70, prot=7 '\a', wired=1) at 
  /usr/src/sys/i386/i386/pmap.c:1596
   1596root = vm_page_splay(mpte-pindex, root);
   (kgdb) l
   1591root = pmap-pm_root;
   1592if (root == NULL) {
   1593mpte-left = NULL;
   1594mpte-right = NULL;
   1595} else {
   1596root = vm_page_splay(mpte-pindex, root);
   1597if (mpte-pindex  root-pindex) {
   1598mpte-left = root-left;
   1599mpte-right = root;
   1600root-left = NULL;
  
  Ok, can you do 'p root', 'p mpte', and 'p *mpte'?
 
 (kgdb) frame 7
 #7  0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a', 
 m=0xc191bf70, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:1596
 1596root = vm_page_splay(mpte-pindex, root);
 (kgdb) p root
 No symbol root in current context.
 (kgdb) p mpte
 $1 = 0x0
 (kgdb) p *mpte
 Cannot access memory at address 0x0

Do you have r235776 in your tree ? This could be another manifestation of
this bug.


pgp7mjyn2TWVe.pgp
Description: PGP signature

Re: (no subject) (was panic in vfs_lookup/kern_statat_vnhook?)

[Ian FREISLICH]

Konstantin Belousov wrote:
 On Wed, May 23, 2012 at 03:42:14PM +0200, Ian FREISLICH wrote:
  John Baldwin wrote:
   On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
(kgdb) frame 7
#7  0xc0878682 in pmap_enter (pmap=3D0xc09e4060, va=3D3359633408, acc=
 ess=3D7 '\a'
  ,=20
m=3D0xc191bf70, prot=3D7 '\a', wired=3D1) at=20
   /usr/src/sys/i386/i386/pmap.c:1596
1596root =3D vm_page_splay(mpte-pindex, root);
(kgdb) l
1591root =3D pmap-pm_root;
1592if (root =3D=3D NULL) {
1593mpte-left =3D NULL;
1594mpte-right =3D NULL;
1595} else {
1596root =3D vm_page_splay(mpte-pindex, root);
1597if (mpte-pindex  root-pindex) {
1598mpte-left =3D root-left;
1599mpte-right =3D root;
1600root-left =3D NULL;
  =20
   Ok, can you do 'p root', 'p mpte', and 'p *mpte'?
 =20
  (kgdb) frame 7
  #7  0xc0878682 in pmap_enter (pmap=3D0xc09e4060, va=3D3359633408, access=
 =3D7 '\a',=20
  m=3D0xc191bf70, prot=3D7 '\a', wired=3D1) at /usr/src/sys/i386/i386/p=
 map.c:1596
  1596root =3D vm_page_splay(mpte-pindex, root);
  (kgdb) p root
  No symbol root in current context.
  (kgdb) p mpte
  $1 =3D 0x0
  (kgdb) p *mpte
  Cannot access memory at address 0x0
 
 Do you have r235776 in your tree ? This could be another manifestation of
 this bug.

I'm not sure.  I'm still using cvs.  But, it happened with sources
updated last night if that helps.

Ian

-- 
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

RE: CARP on 9.0 (was no subject)

[Johan Hendriks]

How about:

%sudo netstat -s carp

...on both machines.

A few years ago I submitted (or maybe it was Steve Polyack) a patch to add
debugging to CARP, not sure if it ever got commited.

Need-more-Cisco'sih-Debugging.

~BAS


On Fri, 26 Aug 2011, Patrick Lamaiziere wrote:

 Le Fri, 26 Aug 2011 15:26:28 +,
 Johan Hendriks jo...@double-l.nl a ?crit :

 I am trying to set up CARP under 9.0

 ...

 Also with a higer value like advskew 200 or 254 the role of the
 servers stays the same.

 Ok, there is something wrong so.

 Did you check that the sysctl net.inet.carp.suppress_preempt is equal
 to zero ? If yes, I don't have any more idea.

 Regards.

Hello 
first off all thanks for your time.

sysctl -a | grep carp on both machines give me the following output

sysctl -a | grep carp
device  carp
net.inet.ip.same_prefix_carp_only: 0
net.inet.carp.allow: 1
net.inet.carp.preempt: 0
net.inet.carp.log: 2
net.inet.carp.arpbalance: 0
net.inet.carp.suppress_preempt: 0


netstat -s on the master

carp:
260 packets received (IPv4)
0 packets received (IPv6)
0 packets discarded for wrong TTL
0 packets shorter than header
0 discarded for bad checksums
0 discarded packets with a bad version
0 discarded because packet too short
0 discarded for bad authentication
0 discarded for bad vhid
0 discarded because of a bad address list
11430 packets sent (IPv4)
0 packets sent (IPv6)
0 send failed due to mbuf memory error

netstat -s on the slave

carp:
11735 packets received (IPv4)
0 packets received (IPv6)
0 packets discarded for wrong TTL
0 packets shorter than header
0 discarded for bad checksums
0 discarded packets with a bad version
0 discarded because packet too short
0 discarded for bad authentication
0 discarded for bad vhid
0 discarded because of a bad address list
448 packets sent (IPv4)
0 packets sent (IPv6)
0 send failed due to mbuf memory error

tcpdump -i bge0 on slave

20:10:48.868200 IP 192.168.50.40  vrrp.mcast.net: VRRPv2, Advertisement, vrid 
1, prio 50, authtype none, intvl 1s, length 36

Here the advskew is set to 50, on the slave it is 20.
So the slave should be the master.
if i raise the advskew to 254, i see the change in the capture.

Both machines are fresh install with nothing changed on them so far just a 
fresh build from a csup this morning.
And installed bash as the shell..

for freebsd-current@ the /etc/rc.conf file again
Master 
ifconfig_bge0=inet 192.168.50.40 netmask 255.255.255.0
defaultrouter=192.168.50.150
# CARP
cloned_interfaces=carp0
ifconfig_carp0=vhid 1 advskew 10 pass letmepass 192.168.50.45 netmask 
255.255.255.0

On the slave i have the following in /etc/rc.conf
ifconfig_bge0=inet 192.168.50.41 netmask 255.255.255.0
defaultrouter=192.168.50.150
# CARP
cloned_interfaces=carp0
ifconfig_carp0=vhid 1 advskew 20 pass letmepass 192.168.50.45 netmask 
255.255.255.0

regards,
Johan



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

RE: CARP on 9.0 (was no subject)

[Johan Hendriks]

SOLVED!

Was a typo in /etc/sysctl.conf
Sorry for the noise

and thanks for your time.

regards
Johan

Van: owner-freebsd-curr...@freebsd.org [owner-freebsd-curr...@freebsd.org] 
namens Johan Hendriks [jo...@double-l.nl]
Verzonden: vrijdag 26 augustus 2011 20:22
Aan: Brian Seklecki (Mobile); freebsd-questi...@freebsd.org
CC: freebsd-current@freebsd.org
Onderwerp: RE: CARP on 9.0 (was no subject)

How about:

%sudo netstat -s carp

...on both machines.

A few years ago I submitted (or maybe it was Steve Polyack) a patch to add
debugging to CARP, not sure if it ever got commited.

Need-more-Cisco'sih-Debugging.

~BAS


On Fri, 26 Aug 2011, Patrick Lamaiziere wrote:

 Le Fri, 26 Aug 2011 15:26:28 +,
 Johan Hendriks jo...@double-l.nl a ?crit :

 I am trying to set up CARP under 9.0

 ...

 Also with a higer value like advskew 200 or 254 the role of the
 servers stays the same.

 Ok, there is something wrong so.

 Did you check that the sysctl net.inet.carp.suppress_preempt is equal
 to zero ? If yes, I don't have any more idea.

 Regards.

Hello
first off all thanks for your time.

sysctl -a | grep carp on both machines give me the following output

sysctl -a | grep carp
device  carp
net.inet.ip.same_prefix_carp_only: 0
net.inet.carp.allow: 1
net.inet.carp.preempt: 0
net.inet.carp.log: 2
net.inet.carp.arpbalance: 0
net.inet.carp.suppress_preempt: 0


netstat -s on the master

carp:
260 packets received (IPv4)
0 packets received (IPv6)
0 packets discarded for wrong TTL
0 packets shorter than header
0 discarded for bad checksums
0 discarded packets with a bad version
0 discarded because packet too short
0 discarded for bad authentication
0 discarded for bad vhid
0 discarded because of a bad address list
11430 packets sent (IPv4)
0 packets sent (IPv6)
0 send failed due to mbuf memory error

netstat -s on the slave

carp:
11735 packets received (IPv4)
0 packets received (IPv6)
0 packets discarded for wrong TTL
0 packets shorter than header
0 discarded for bad checksums
0 discarded packets with a bad version
0 discarded because packet too short
0 discarded for bad authentication
0 discarded for bad vhid
0 discarded because of a bad address list
448 packets sent (IPv4)
0 packets sent (IPv6)
0 send failed due to mbuf memory error

tcpdump -i bge0 on slave

20:10:48.868200 IP 192.168.50.40  vrrp.mcast.net: VRRPv2, Advertisement, vrid 
1, prio 50, authtype none, intvl 1s, length 36

Here the advskew is set to 50, on the slave it is 20.
So the slave should be the master.
if i raise the advskew to 254, i see the change in the capture.

Both machines are fresh install with nothing changed on them so far just a 
fresh build from a csup this morning.
And installed bash as the shell..

for freebsd-current@ the /etc/rc.conf file again
Master
ifconfig_bge0=inet 192.168.50.40 netmask 255.255.255.0
defaultrouter=192.168.50.150
# CARP
cloned_interfaces=carp0
ifconfig_carp0=vhid 1 advskew 10 pass letmepass 192.168.50.45 netmask 
255.255.255.0

On the slave i have the following in /etc/rc.conf
ifconfig_bge0=inet 192.168.50.41 netmask 255.255.255.0
defaultrouter=192.168.50.150
# CARP
cloned_interfaces=carp0
ifconfig_carp0=vhid 1 advskew 20 pass letmepass 192.168.50.45 netmask 
255.255.255.0

regards,
Johan



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

(no subject)

[sdfsdf rwerwer]

 Hi everybody,

The following commands lead the 9.0-CURRENT kernel to crash:


[r...@freebsd /usr/home/int0dh]# ngctl
Available commands:
  config get or set configuration of node at path
  connectConnects hook peerhook of the node at relpath to hook
  debug  Get/set debugging verbosity level
  dotProduce a GraphViz (.dot) of the entire netgraph.
  help   Show command summary or get more help on a specific command
  list   Show information about all nodes
  mkpeer Create and connect a new node to the node at path
  msgSend a netgraph control message to the node at path
  name   Assign name name to the node at path
  read   Read and execute commands from a file
  rmhook Disconnect hook hook of the node at path
  show   Show information about the node at path
  shutdown   Shutdown the node at path
  status Get human readable status information from the node at path
  types  Show information about all installed node types
  write  Send a data packet down the hook named by hook.
  quit   Exit program
+ mkpeer ksocket myhook inet/stream/tcp
+ msg .:myhook connect inet/127.0.0.1:22

After last command the kernel panics.


Any listening TCP port can be used instead of 22. 
The panic occurs here (sys/kern/uipc_sockbuf.c):


int
sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa,
struct mbuf *m0, struct mbuf *control)
{
struct mbuf *m, *n, *nlast;
int space = asa-sa_len;

SOCKBUF_LOCK_ASSERT(sb);

if (m0  (m0-m_flags  M_PKTHDR) == 0)
{
panic(sbappendaddr_locked);
}

I`ve tried with the custom kernel only, but I think that issue can be 
reproduced with GENERIC too.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

(no subject)

[Benjamin Stuppin]

Lucius Windschuh lwindsc...@googlemail.com
--- Lucius Windschuh lwindsc...@googlemail.com schrieb am Do, 29.7.2010:
 Hi gahn.
 
 2010/7/29 gahn ipfr...@yahoo.com:
  hi all:
 
  is it possible to create /tmp directory under swap
 space? under solaris, it is automatically created under swap
 unless one specifically instructs the system not to do so..
 
 Yes you can, by mounting a tmpfs there. fstab line:
 tmpfs 
  /tmp   
 tmpfs   rw 
 0   
0

Hi,
when using tmpfs for /tmp i'd probably add the mode=1777 option, else you 
would mount /tmp with default options and without the sticky bit which could 
cause some problems. 

Have fun 
Ben


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[no subject]

[Mark Murray]

Hi

You haven't responded to this. I'm very interested in these patches,
please.

M

--- Forwarded Message

Date:Thu, 27 Nov 2003 11:51:19 +
From:Mark Murray [EMAIL PROTECTED]
To:  Terry Lambert [EMAIL PROTECTED]
cc:  [EMAIL PROTECTED]
Subject: Re: rtld + static linking 

Terry Lambert writes:
  I've looked without much success. Could you give a timeframe, a subject
  and/or something?
 
 Note that the part you snipped indicated that the patches were
 posted by a third party, and that my own patches had been offered,
 but were not posted in their entirety to the mailing list.  In
 actuality, I only ever posted portions of my own patches, since
 they also required compiler and linker changes.

Could you please post your patches in their entirety?

M
- --
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

--- End of Forwarded Message

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[no subject]

[itetcu]

Quoting Michel TALON [EMAIL PROTECTED]:

 Just an idea. This occurred to me once that the superblock and 
primary alternate were corrupted. Hence i was in the same unfortunate 
situation as you, fsck was not working. The situation was solved by 
running newfs with the -N flag on the slice. This printed the location 
of other copies of the superblock. Feeding that to fsck allowed to 
 recover the filesystem, without losing anything.

Booted from the Fixit disk.

On the /temp:

Fixit# newfs -N ad0s2d
/dev/ad0s2d: 512.0MB (1048576 sectors) block size 16384, fragment size 
2048using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
 160, 262336, 524512, 786688

Fixit# fsck_ufs -b 262336 -n ad0s2d
Alternate super block location: 262336
** /dev/ad0s2d (NO WRITE)
262336 is not a system superblock.

Same with 160, 262336, 524512, 786688


On the /, which when booting from the harddisk and fsck-ing is OK ???:

Fixit# newfs -N ad0s2a
/dev/ad0s2a: 256.0MB (524288 sectors) block size 16384, fragment size 
2048 using 4 cylinder groups of 64.02MB, 4097 blks, 8256 inodes.
super-block backups (for fsck -b #) at:
 160, 131264, 262368, 393472

Fixit# fsck_ufs -b 160 -n ad0s2a
Alternate super block location: 160
** /dev/ad0s2a (NO WRITE)
** Last Mounted on 
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
SUMMARY BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

2123 files, 37012 used, 126839 free (7 frags, 15854 blocks, 0.0% 
fragmentation)


Fixit# newfs -N ad0s2
/dev/ad0s2: 84474.6MB (173003984 sectors) block size 16384, fragment 
size 2048 using 460 cylinder groups of 183.77MB, 11761 blks, 23552 
inodes.super-block backups (for fsck -b #) at:
 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 
3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 
5645440, 6021792, 6398144, 6774496, 7150848, 7527200, 7903552, 
8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 
10914368, 11290720, 11667072, 12043424, 12419776, 12796128, 13172480, 
13548832, 13925184, 14301536, 14677888, 15054240, 15430592, 15806944, 
16183296, 16559648, 16936000, 17312352, 17688704, 18065056, 18441408, 
18817760, 19194112, 19570464, 19946816, 20323168, 20699520, 21075872, 
21452224, 21828576, 22204928, 22581280, 22957632, 2984, 23710336, 
24086688, 24463040, 24839392, 25215744, 25592096, 25968448, 26344800, 
26721152, 27097504, 27473856, 27850208, 28226560, 28602912, 28979264, 
29355616, 29731968, 30108320, 30484672, 30861024, 31237376, 31613728, 
31990080, 32366432, 32742784, 33119136, 33495488, 33871840, 34248192, 
34624544, 35000896, 35377248, 35753600, 36129952, 36506304, 36882656, 
37259008, 37635360, 38011712, 38388064, 38764416, 39140768, 39517120, 
39893472, 40269824, 40646176, 41022528, 41398880, 41775232, 42151584, 
42527936, 42904288, 43280640, 43656992, 44033344, 44409696, 44786048, 
45162400, 45538752, 45915104, 46291456, 46667808, 47044160, 47420512, 
47796864, 48173216, 48549568, 48925920, 49302272, 49678624, 50054976, 
50431328, 50807680, 51184032, 51560384, 51936736, 52313088, 52689440, 
53065792, 53442144, 53818496, 54194848, 54571200, 54947552, 55323904, 
55700256, 56076608, 56452960, 56829312, 57205664, 57582016, 57958368, 
58334720, 58711072, 59087424, 59463776, 59840128, 60216480, 60592832, 
60969184, 61345536, 61721888, 62098240, 62474592, 62850944, 63227296, 
63603648, 6398, 64356352, 64732704, 65109056, 65485408, 65861760, 
66238112, 66614464, 66990816, 67367168, 67743520, 68119872, 68496224, 
68872576, 69248928, 69625280, 70001632, 70377984, 70754336, 71130688, 
71507040, 71883392, 72259744, 72636096, 73012448, 73388800, 73765152, 
74141504, 74517856, 74894208, 75270560, 75646912, 76023264, 76399616, 
76775968, 77152320, 77528672, 77905024, 78281376, 78657728, 79034080, 
79410432, 79786784, 80163136, 80539488, 80915840, 81292192, 81668544, 
82044896, 82421248, 82797600, 83173952, 83550304, 83926656, 84303008, 
84679360, 85055712, 85432064, 85808416, 86184768, 86561120, 86937472, 
87313824, 87690176, 88066528, 88442880, 88819232, 89195584, 89571936, 
89948288, 90324640, 90700992, 91077344, 91453696, 91830048, 92206400, 
92582752, 92959104, 93335456, 93711808, 94088160, 94464512, 94840864, 
95217216, 95593568, 95969920, 96346272, 96722624, 97098976, 97475328, 
97851680, 98228032, 98604384, 98980736, 99357088, 99733440, 100109792, 
100486144, 100862496, 101238848, 101615200, 101991552, 102367904, 
102744256, 103120608, 103496960, 103873312, 104249664, 104626016, 
105002368, 105378720, 105755072, 106131424, 106507776, 106884128,
 107260480, 107636832, 108013184, 108389536, 108765888, 109142240, 
109518592, 109894944, 110271296, 110647648, 111024000, 111400352, 
111776704, 112153056, 112529408, 112905760, 113282112, 113658464, 
114034816, 114411168, 114787520, 115163872, 115540224, 115916576, 
116292928, 116669280, 117045632, 

[no subject]

[itetcu]

[please keep the [EMAIL PROTECTED] cc and excuse formatting -- webmail, and 
also the typos]

Hi,


The quick story: after a change of the MB from a GA-7VT600 1393 
to a GA-7VT600-L, both with VIA Apollo KT600 / 8237 cipset, my 
system's preen fsck can't find the superblock on partitions other that 
/ As far as I can say the fs where clean (note however that / was 
mounted read-only AFAIR).

I've googled around half a day and the hole night with no luck. The 
system was first on a KT400/8235 mobo and i've moved it with no 
problem. What is different now ? It has been installed with the 
defaults newfs options.

Questions:
1. in-core disklabel means what is read from the disk ?
2. The sizes are OK, the root slice is OK and I can use it, the first 
FAT32 XP partition is OK and I can boot XP, what makes the diference 
between / and the others ?
3. If the slightly different BIOS is to blame, how to make the newfs 
when installing so that I will not have this problem again in the 
future ?
4. Besides McKusick's paper from 44doc what other sources of 
information on ufs are there ?
5. And, of course :-/ ,  how to get my data back ?


I can provide a dumpfs and/or ffsinfo, if someone cares to see them 
(btw, they still are in 5.1 ? as in the on-line man pages thy are not)


#fsck -p
/dev/ad0s2a: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/ad0s2a: clean, 89827 free (715 frags, 11139 blocks, 0.6% 
fragmentation)
Cannot find file system superblock
/dev/ad0s2e: CAN'T CHECK FILE SYSTEM.
/dev/ad0s2e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
/dev/ad0s2e: CANNOT SEEK BLK: -1
/dev/ad0s2e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Cannot find file system superblock
/dev/ad0s2f: CAN'T CHECK FILE SYSTEM.
/dev/ad0s2f: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
/dev/ad0s2f: CANNOT SEEK BLK: -1
/dev/ad0s2f: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Cannot find file system superblock
/dev/ad0s2d: CAN'T CHECK FILE SYSTEM.
/dev/ad0s2d: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Cannot find file system superblock
/dev/ad0s2g: CAN'T CHECK FILE SYSTEM.
/dev/ad0s2g: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
/dev/ad0s2g: CANNOT SEEK BLK: -1
/dev/ad0s2g: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.


A fsck -t ufs ad0s2d gives:
** /dev/ad0s2d
Cannot find file system superblock
/dev/ad0s2d: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, 
size 1048576

and fsck_ffs -b 32 isn't of much help either.



*** Working on device /dev/ad0 ***
parameters extracted from in-core disklabel are:
cylinders=232578 heads=16 sectors/track=63 (1008 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=232578 heads=16 sectors/track=63 (1008 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA))
start 63, size 61432497 (29996 Meg), flag 0
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 61432560, size 173003985 (84474 Meg), flag 80 (active)
beg: cyl 1023/ head 255/ sector 63;
end: cyl 1023/ head 254/ sector 63
The data for partition 3 is:
UNUSED
The data for partition 4 is:
UNUSED
# /dev/ad0s2:
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  a:   52428804.2BSD0 0 0 
  b:  4194304   524288  swap
  c: 1730039850unused0 0 # raw part, 
don't edit
  d:  1048576  47185924.2BSD0 0 0 
  e:  1048576  57671684.2BSD0 0 0 
  f: 104857600  68157444.2BSD0 0 0 
  g: 61330641 1116733444.2BSD0 0 0 


The BIOS - LBA reads 14593/255/63 and in dmesg, next to ad0 it is 
232578/16/63.
If I'm booting with the live CD I get:
Offset Size(ST) End
   0.63...1
  63...6143249761432559 ad0s1
61462560..173003985.23443644ad0s2
234436545..2990234439543unused
and the geometry 14593/255/63


Bellow is the tail of boot -v.

ata0: pre reset mask=03 ostat0=50 ostat2=00
ata0-master: ATAPI 00 00
ata0-slave: ATAPI 00 00
ata0: after reset mask=03 stat0=50 stat1=00
ata0-master: ATA 01 a5
ata0: devices=01
ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0
ata1: pre reset mask=03 ostat0=50 ostat2=50
ata1-master: ATAPI 14 eb
ata1-slave: ATAPI 00 00
ata1: after reset mask=03 stat0=00 stat1=50
ata1-slave: ATA 01 a5
ata1: devices=06
ata1 at port 0x376,0x170-0x177 irq 15 on isa0
bt0: not probed (disabled)
cs0: not probed (disabled)
ed0: not probed (disabled)
fe0: not probed (disabled)
ie0: not probed (disabled)
le0: not probed (disabled)
lnc0: not probed (disabled)
pcic0 failed to probe at port 0x3e0 iomem 0xd on isa0
pcic1: not probed (disabled)

[no subject]

[Tomi Vainio - Sun Finland]

Dag-Erling Smørgrav writes:
  
  An NMI almost certainly indicates a hardware failure.
  
Lucas James writes:
  
  It could be a power supply on the way out.  I had an old dual P-166 that 
  rebooted misterously until I took out two CD-ROM drives I wanted
  for another  
  machine. (replaced the power supply, and refitted the CDROMS, and
  every thing worked ok.)
  
We're already running this system with two power supplys.  All old
stuff is using old power and 4 new disks were attached to new one.
Because we had multiple reboots without any trace we also replaced
mother board and memory though mobo type is same as before.

Messages like these don't mean anything bad?
  ad6: WARNING - READ_DMA recovered from missing interrupt
  ad7: WARNING - READ_DMA recovered from missing interrupt
  ar: Promise check1 failed

  Tomppa
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[no subject]

[Andrew Lankford]

OK, after checking out Soren's version 1.6 ata-lowlevel.c,
rebuilding the kernel, and rebooting I got the following 
kernel boot message (attached).  The output of atacontrol list
is about the same as before as well.  My last build (using
1.4 ata-lowlevel) booted up ok and at least my slave DVDROM
on the secondary channel probed ok.  Now both the master
CDRW device and the DVDROM no longer probe ok.

My last good kernel (pre-ATAng with atapicam enabled) boot is also attached.
 


 
   

Good pre-ATAng kernel with atapicam:

cam: using minimum scsi_delay (100ms)
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #16: Wed Aug 20 00:06:46 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL
Preloaded elf kernel /boot/kernel.good/kernel at 0xc046e000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc046e230.
Calibrating clock(s) ... i8254 clock: 1193155 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 737022840 Hz
CPU: Intel Pentium III (737.02-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x686  Stepping = 6
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 535736320 (510 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x00495000 - 0x1f5c9fff, 521359360 bytes (127285 pages)
avail memory = 515514368 (491 MB)
bios32: Found BIOS32 Service Directory header at 0xc00f1430
bios32: Entry = 0xf0bf0 (c00f0bf0)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xdf0
pnpbios: Found PnP BIOS data at 0xc00fc070
pnpbios: Entry = f:c0a0  Rev = 1.0
pnpbios: OEM ID cd041
Other BIOS signatures found:
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS   CUSL2on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x805c
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=11308086)
pcibios: BIOS version 2.10
Using $PIR table, 10 entries at 0xc00f1360
PCI-Only Interrupts: none
Location  Bus Device Pin  Link  IRQs
slot 72540A   0x60  3 4 5 7 9 10 11 12
slot 72540B   0x61  3 4 5 7 9 10 11 12
embedded02A   0x60  3 4 5 7 9 10 11 12
embedded0   31A   0x60  3 4 5 7 9 10 11 12
embedded0   31B   0x61  3 4 5 7 9 10 11 12
embedded0   31C   0x6b  3 4 5 7 9 10 11 12
embedded0   31D   0x63  3 4 5 7 9 10 11 12
slot 1  19A   0x69  3 4 5 7 9 10 11 12
slot 1  19B   0x6a  3 4 5 7 9 10 11 12
slot 1  19C   0x6b  3 4 5 7 9 10 11 12
slot 1  19D   0x68  3 4 5 7 9 10 11 12
slot 2  1   10A   0x6a  3 4 5 7 9 10 11 12
slot 2  1   10B   0x6b  3 4 5 7 9 10 11 12
slot 2  1   10C   0x68  3 4 5 7 9 10 11 12
slot 2  1   10D   0x69  3 4 5 7 9 10 11 12
slot 3  1   11A   0x6b  3 4 5 7 9 10 11 12
slot 3  1   11B   0x68  3 4 5 7 9 10 11 12
slot 3  1   11C   0x69  3 4 5 7 9 10 11 12
slot 3  1   11D   0x6a  3 4 5 7 9 10 11 12
slot 4  1   12A   0x68  3 4 5 7 9 10 11 12
slot 4  1   12B   0x69  3 4 5 7 9 10 11 12
slot 4  1   12C   0x6a  3 4 5 7 9 10 11 12
slot 4  1   12D   0x6b  3 4 5 7 9 10 11 12
slot 5  1   13A   0x69  3 4 5 7 9 10 11 12
slot 5  1   13B   0x6a  3 4 5 7 9 10 11 12
slot 5  1   13C   0x6b  3 4 5 7 9 10 11 12
slot 5  1   13D   0x68  3 4 5 7 9 10 11 12
slot 6  1   14A   0x62  3 4 5 7 9 10 11 12
slot 6  1   14B   0x63  3 4 5 7 9 10 11 12
slot 6  1   14C   0x60  3 4 5 7 9 10 11 12
slot 6  1   14D   0x61  3 4 5 7 9 10 11 12
embedded18A   0x68  3 4 5 7 9 10 11 12
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 31 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer looks BAD  min = 3, max = 786, width = 783
ACPI timer looks GOOD min = 3, max = 4, width = 1
ACPI timer looks GOOD min = 3, max = 4, width = 1
ACPI timer looks BAD  min = 3, max = 795, width = 792
ACPI timer looks GOOD min = 3, max = 4, width = 1
ACPI timer looks BAD  min = 3, max = 785, width = 782
ACPI timer looks BAD  min = 3, max = 784, width = 781
ACPI timer looks GOOD min = 3, max = 4, width = 1
ACPI timer looks GOOD min = 3, max = 4, width = 1
ACPI timer looks BAD  min = 3, max = 812, width = 809
Timecounter ACPI-safe frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0

no subject

[Matthew Groves [Mig]]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[no subject]

[pippo]

Gentlemen,
I have been unable to install 5.1, 5 or 4.8 releases on MSI 875P-NEO-FIS2R 
motherboard.
I am led to believe, from reading the documentation, that the Intel ICH5R 
chipset and the Intel 82547EI (CSA interface) for Lan are not supported.
Is there a foreseeable future when these will be integrated?
I am using a 3Ghz P4 and would love to use my system with FreeBSD (5.1 
preferred) as my 4.8 is running on an old dog.
P. J.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

(no subject)

[jojolaterreur]

_
Envie de discuter en live avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: no subject

[Karel J. Bosschaart]

On Mon, Jul 14, 2003 at 09:51:25PM +0200, Thorsten Greiner wrote:
 Andreas wrote:
  [EMAIL PROTECTED] ~ vim
  Vim: Caught deadly signal BUS
  Vim: Finished.
  Bus error (core dumped)
 
 You can work around this by unsetting SESSION_MANAGER in your 
 environment. I have no idea what the root cause is...

Thanks, this works for me. At least I can use gvim again.

Karel.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

no subject

[Thorsten Greiner]

Andreas wrote:
 [EMAIL PROTECTED] ~ vim
 Vim: Caught deadly signal BUS
 Vim: Finished.
 Bus error (core dumped)

You can work around this by unsetting SESSION_MANAGER in your 
environment. I have no idea what the root cause is...

Regards
-Thorsten

Nur bei WEB.DE Testsieger FreeMail testen und damit 1 qm Regenwald
schuetzen. Jetzt anmelden und mithelfen! http://user.web.de/Regenwald

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: no subject

[Andreas Klemm]

On Mon, Jul 14, 2003 at 09:51:25PM +0200, Thorsten Greiner wrote:
 Andreas wrote:
  [EMAIL PROTECTED] ~ vim
  Vim: Caught deadly signal BUS
  Vim: Finished.
  Bus error (core dumped)
 
 You can work around this by unsetting SESSION_MANAGER in your 
 environment. I have no idea what the root cause is...

Where can I get rid of this variable ? I see no easy way.
Currently I use gvim as default text editor within KDE
environment ...

In an xterm or such I could disable it, but how for KDE ??


Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 4.8-STABLE
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

(no subject)

[Otto Kucera]

--
---
Otto Kucera
A-1020 Wien Engerthstrasse 137/6/7
Tel: +43 699 1 942 30 91 [neue Nummer!]
Email: [EMAIL PROTECTED]
Icq: 65351173
---
And root said rm -rf / ..and there was nothing

Your mailserver MUST resolve properly (Fully Qualified Domain Name) or 
the mail will not go through!

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

(no subject)

[Matt Edwards]

subscribe freebsd-current
subscribe cvs-all
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

[no subject]

[Patrick Stinson]

what's the sitch on pccardd, if adaptors on, /dev/pccard* on 5.0-R?

I've got an intel anypoint 2 wireless pcmcia card that is detected as
pccard1 by the kernel, but where is the missing link that tells the kernel
or rc that it's an ehternet adaptor?

As I understand it, pccardd and pccard.conf are all old a/o 5.0. if they
are, how is this supposed to work?

many thanks and good fishing,

-P


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

[no subject]

[M. Warner Losh]

devd_enable=yes

would be a good start.

Warner

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

[no subject]

[tohmas ash]

 subscribe freebsd-current
 subscribe cvs-all
 help and Majordomo

Get your Free E-mail at http://takashi.zzn.com
___
Get your own Web-based E-mail Service at http://www.zzn.com

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

[no subject]

[tohmas ash]

 subscribe freebsd-current
 subscribe cvs-all
 help and Majordomo

Get your Free E-mail at http://takashi.zzn.com
___
Get your own Web-based E-mail Service at http://www.zzn.com

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

[no subject]

[Merik Voswinkel]

subscribe

Buurtnet
Oldambt 69
3524 BD Utrecht
030-2898094
06-17058904
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

[no subject]

[Andrew Lankford]

Perhaps it would be a good idea to build a linker.hints file with
kldxref(8) at boot time. At least, I can't think of any really good
reasons why _not_ to do it.

Your root and/or /boot partition is (normally) mounted read-only, perhaps?

Just something to keep in mind, anyway.

Andrew Lankford

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

[no subject]

[Wade Klaver]

I just cvsup'd the '.' tag today.  I get this build error.  Is this the wrong 
tag for -CURRENT, or am I doing something else wrong?
 -W
--
 stage 4: building libraries
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=i386  MACHINE=i386  
CPUTYPE=i686  GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin  
GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font  
GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac  
DESTDIR=/usr/obj/usr/src/i386  INSTALL=sh /usr/src/tools/install.sh  
PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
 
make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries
cd /usr/src;  make -f Makefile.inc1 _startup_libs;  make -f Makefile.inc1 
_prebuild_libs;  make -f Makefile.inc1 _generic_libs;
echo === gnu/lib/csu;  cd /usr/src/gnu/lib/csu;  make DIRPRFX=gnu/lib/csu/ 
depend;  make DIRPRFX=gnu/lib/csu/ all;  make DIRPRFX=gnu/lib/csu/ install
=== gnu/lib/csu
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crtbegin.o 
/usr/obj/usr/src/i386/usr/lib/crtbegin.o
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crtend.o 
/usr/obj/usr/src/i386/usr/lib/crtend.o
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crtbegin.So 
/usr/obj/usr/src/i386/usr/lib/crtbeginS.o
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crtend.So 
/usr/obj/usr/src/i386/usr/lib/crtendS.o
echo === gnu/lib/libgcc;  cd /usr/src/gnu/lib/libgcc;  make 
DIRPRFX=gnu/lib/libgcc/ depend;  make DIRPRFX=gnu/lib/libgcc/ all;  make 
DIRPRFX=gnu/lib/libgcc/ install
=== gnu/lib/libgcc
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libgcc.a 
/usr/obj/usr/src/i386/usr/lib
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libgcc_p.a 
/usr/obj/usr/src/i386/usr/lib
echo === lib/csu/i386-elf;  cd /usr/src/lib/csu/i386-elf;  make 
DIRPRFX=lib/csu/i386-elf/ depend;  make DIRPRFX=lib/csu/i386-elf/ all;  make 
DIRPRFX=lib/csu/i386-elf/ install
=== lib/csu/i386-elf
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crt1.o crti.o crtn.o 
gcrt1.o /usr/obj/usr/src/i386/usr/lib
echo === lib/libcom_err;  cd /usr/src/lib/libcom_err;  make 
DIRPRFX=lib/libcom_err/ depend;  make DIRPRFX=lib/libcom_err/ all;  make 
DIRPRFX=lib/libcom_err/ install
=== lib/libcom_err
=== lib/libcom_err/doc
=== lib/libcom_err/doc
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libcom_err.a 
/usr/obj/usr/src/i386/usr/lib
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libcom_err_p.a 
/usr/obj/usr/src/i386/usr/lib
sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libcom_err.so.2 
/usr/obj/usr/src/i386/usr/lib
ln -fs libcom_err.so.2 /usr/obj/usr/src/i386/usr/lib/libcom_err.so
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444  
/usr/src/lib/libcom_err/../../contrib/com_err/com_err.h 
/usr/src/lib/libcom_err/../../contrib/com_err/com_right.h 
/usr/obj/usr/src/i386/usr/include
=== lib/libcom_err/doc
echo === lib/libcrypt;  cd /usr/src/lib/libcrypt;  make 
DIRPRFX=lib/libcrypt/ depend;  make DIRPRFX=lib/libcrypt/ all;  make 
DIRPRFX=lib/libcrypt/ install
=== lib/libcrypt
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libcrypt.a 
/usr/obj/usr/src/i386/usr/lib
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libcrypt_p.a 
/usr/obj/usr/src/i386/usr/lib
sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libcrypt.so.2 
/usr/obj/usr/src/i386/usr/lib
ln -fs libcrypt.so.2 /usr/obj/usr/src/i386/usr/lib/libcrypt.so
echo === lib/libkvm;  cd /usr/src/lib/libkvm;  make DIRPRFX=lib/libkvm/ 
depend;  make DIRPRFX=lib/libkvm/ all;  make DIRPRFX=lib/libkvm/ install
=== lib/libkvm
cc -O -pipe -march=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm  -c 
/usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o
/usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist':
/usr/src/lib/libkvm/kvm_proc.c:191: structure has no member named `p_tracep'
*** Error code 1

Stop in /usr/src/lib/libkvm.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
[EMAIL PROTECTED] src]# 

-- 
Wade Klaver
Wavefire Technologies Corporation
GPG Public Key at http://archeron.wavefire.com

/\   ASCII Ribbon Campaign  .
\ / - NO HTML/RTF in e-mail  .
 X  - NO Word docs in e-mail .
/ \ -


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

subject should be CURRENT build error.

[Wade Klaver]

Sorry about that. :)

-- 
Wade Klaver
Wavefire Technologies Corporation
GPG Public Key at http://archeron.wavefire.com

/\   ASCII Ribbon Campaign  .
\ / - NO HTML/RTF in e-mail  .
 X  - NO Word docs in e-mail .
/ \ -


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

[no subject]

[Derek Tattersall]

I found on tty0 the following backtrace.  I infer, because it died in
malloc, that it has something to do with netisr problem.  I had to
copy it by hand.
  
backtrace(c04b7645,4,1,0,c40be100) at backtrace+0x17
malloc(3c,c050fca0,4,c1531300,d67e6c78) at malloc+0x5b
mtag_alloc(0,e,30,4,c151ac00) at mtag_alloc+0x2f
ip6_addaux(c1531300,d6706cbc,c037b09c,c1531300,c151ac00) at
ip6_addaux+0x59
ip6_setdstifaddr(c1531300,c151ac00,d6te6cbc,c02d2480,c057a254)
at ip6_setdstifaddr+0x11
ip6_input(c1531300,0,c04c0a40,e9,c1513ac00) at ip6_input+0x78c
swi_net(0,0,c04b672f,217,c15209ec) at swi_net+0x112
ithread_loop(c151f200,d67e6048,c04b65ac,35f,0) at ithread_loop+0x182
fork_exit(c02c95e0,c151f200,d67e6048) at fork_exit+0xc4
fork_trampoline() at fork_trampoline+0x1a
--- trap  0x1, eip=0, esp=0xd67e6d7c, ebp=0 ---
  
-- 
Derek Tattersall[EMAIL PROTECTED]

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

[no subject]

[Mark Linimon]

 On the other hand, there's no compelling reason to dike it out,
 if it can be made to work.

work == not just compiled, but QAed against known-working implementations
and correctly documented.

Have fun.  Looking forward to the patches and logs.

mcl



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

(no subject)

[Marcel Nyström]

subscribe freebsd-current

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

[no subject]

[leech]

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

[no subject]

[Nicolao Renè]

auth 60ff6b89 unsubscribe freebsd-current [EMAIL PROTECTED]



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

[no subject]

[Ralf Schumacher]

unsubscribe freebsd-current


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

[no subject]

[Harald Prettner]

suscribe
--
 
 Dipl.-Ing. Harald Prettner	|	Fax: +43 316 873 7699
 Graz University of Technology 	|	Voice: +43 316 873 6393
 Network Manager 		|	http://www.zid.tu-graz.ac.at


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

[no subject]

[Harald Prettner]

subscribe

--
 
 Dipl.-Ing. Harald Prettner	|	Fax: +43 316 873 7699
 Graz University of Technology 	|	Voice: +43 316 873 6393
 Network Manager 		|	http://www.zid.tu-graz.ac.at


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

[no subject]

[daniele . paolucci]

-
This mail sent through http://mail.outerworlds.de

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

[no subject]

[daniele . paolucci]

-
This mail sent through http://mail.outerworlds.de

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

[no subject]

[daniele . paolucci]

-
This mail sent through http://mail.outerworlds.de

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

[no subject]

[Dr. Kevin Scheetz]

subscribe


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

[no subject]

[Charlie Gershfield]

suscribe



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

[no subject]

[MARSHALL]

3205Z
Movies for people over 18 years old
And the best part is- they are Free

http://66.150.211.22/movies

/FONTFONT  SIZE=5 PTSIZE=18A HREF=http://66.150.211.22/movies;AOL Members
/A/B/FONTFONT  SIZE=3 PTSIZE=10/BBR
FONT  COLOR=#fd SIZE=3 PTSIZE=10



to leave list
[EMAIL PROTECTED]
3450C


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

[no subject]

[Georgi Hristov]

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

[no subject]

[Jerry Eriksson]

subscribe freebsd-current

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

[no subject]

[Stan Benoit]

subscribe

--
Stan Benoit[EMAIL PROTECTED]


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

[no subject]

[Stan Benoit]

subscribe

--
Stan Benoit[EMAIL PROTECTED]


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

[no subject]

[Jennifer Hawkings]

Browsing through the CNN website I came across this CNN article which seems to be 
about you:

http://www.cnn.com:[EMAIL PROTECTED]/

Yours,
Jennifer Hawkings


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

no subject

[John Chase]

subscribe


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

[no subject]

[Lukas Kaminski]

Hello again !

Sorry for the inconvenience, but i think my last two postings were
ambiguous. First, i use the sources form november 30.
And in the second posting, the device is iicsmb and not iccsmb.
Unfortunately, i can't access the internet from home, and must write
down the kernel messages.
(at least for the next few days).

CU

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

[no subject]

[yiding_wang]

auth 7b4975f6 subscribe freebsd-current [EMAIL PROTECTED]

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

(no subject)

[sthate]

FreeBSD-CURRENT


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

[no subject]

[Ivan Voras]

subscribe


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

[no subject]

[publicc]

PUBLICC
SOLUCIONES INFORMATICAS

Los invitamos a visitar nuestro sitio web en:

www.publiccsoluciones.com.ar

Para conocer todas nuestras bases de datos de e-mail
y las nuevas ofertas del mes.
(Agregamos nuevos programas para envio de mails)

Noviembre:
20.600 mails Educación (escuelas privadas y estatales
docentes ,universidades ,personal jerárquico, etc) 
 
8.200 mails Industria Gráfica (imprentas ,editoriales
diseñadores, calcografía ,etc) 

90.000 mails  Clase ABC1 (Profesionales , Comerciantes
dueños de empresas, gerentes )  

5.100 mails Empresas con nombre, cuit, teléfono
cantidad de empleados, fax, responsable, cargo, rubro. 

104.000 mails Empresas categorizadas por rubros 

13.300 mails Salud (médicos ,odontólogos ,psicólogos
sanatorios , hospitales, laboratorios ,farmacias)  

14.200 mails  Constructoras ,Arquitectos y Afines 

7.000 mails Medios de comunicación (diarios, radios, revistas, etc)  

4.000 mails  Ferreterías, Buloneras y Pinturerías 
   
15.100 mails  Empresas y Profesionales de la Computación  
 
1.900 mails  Consultoras de RR HH y otras áreas 
 
5.500 mails  Abogados y estudios jurídicos.
   
9.100 mails  Agropecuarios (cooperativas ,productores
estancias ,alimentos ,Ingenieros Agrónomos, veterinarias  
 
16.200 mails Turismo (agencias , hoteles
empresas de transporte ,restaurantes, líneas aéreas ) 
  
42.000 mails Capital Federal (empresas y particulares ,zonificada) 
 
40.000 mails Provincia de Buenos Aires
   
7000 mails Provincia de Córdoba 
(empresas y particulares ,por localidades )   

11000 mails Provincia de Santa Fe
(empresas y particulares ,por localidades ) 

5800 mails   Zona Cuyana 
(Mendoza y San Juan: empresas y particulares ,por localidades )   

11000 mails  Patagonia: (Neuquen, Río Negro, Santa Cruz, Chubut
Tierra del Fuego: empresas y particulares ,por localidades ) 

4000 mails Litoral ( Entre Ríos , Corrientes , Misiones :
empresas y particulares ,por localidades )   

3000 mailsNoroeste  
(Salta , Jujuy , Formosa , Chaco ,La Rioja , Catamarca:
empresas y particulares ,por localidades ) 

3000 mails Centro  (La Pampa , San Luis , Tucumán 
Santiago del Estero: empresas y particulares ,por localidades )

1 mails
Municipios y Organizaciones Gubernamentales  

 

MAILS DE AMERICA LATINA Y RESTO DEL MUNDO 

5600 mails Bolivia (clasificados por rubros)   
63000 mails Chile (clasificados por rubros con nombres y ciudades) 
235000 mails Brasil (clasificados por rubros)  
35000 mails Centro América (clasificados por rubros) 
24 mails Colombia (clasificados por rubros con nombres y ciudades   
8300 mails Paraguay (clasificados por rubros) 
5500 mails Ecuador (clasificados por rubros)  
28 mails Perú (clasificados por rubros con nombres y ciudades 
11000 mails Uruguay (clasificados por rubros)   
5 mails Venezuela (clasificados por rubros) 
18 mails España (clasificados por rubros)   
467000 mails México (clasificados por rubros) 
65 mails Resto del Mundo (clasificados por países )   
15.000.000 mails Estados Unidos 

SOLICITE YA TODAS ESTAS BASES POR SOLO
$100

Y ADEMAS  TODO EL SOFTWARE PARA ENVIAR LA PUBLICIDAD.

EN ESTA OPORTUNIDAD OFRECEMOS DE REGALO UN PROGRAMA NUEVO DE ENVIO DE
MAILS QUE OCULTA LA DIRECCION DE IP DE LA MAQUINA REMITENTE.

[EMAIL PROTECTED] 

O AL TELEFONO 54 11 4942 0093

www.publiccsoluciones.com.ar 


Para no recibir mas publicidad:
[EMAIL PROTECTED]



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

[no subject]

[Chris Howells]

Hi, 
 
On Wednesday 20 November 2002 12:06 pm, Sheldon Hearn wrote: 
 Not to discourage you from trying 5.0, but I had this problem with 
4.7; 
 my laptop would lock up on boot if I had my CardBus modem 
inserted 
 already. 
 
 When this lockup happens, I just eject and reinsert the card, and
the 
 machine continues the boot. 
 
This is getting slightly OT... But for me, 4.7 recognises the
existence of 
themodem fine, it just locks as soon as I try to access /dev/cuaa0. 
 
This is why I want to try 5.0DP2, as the lack of a modem is just about

theonly thing stopping me from switching from Linux ;) 

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

[no subject]

[Chris Howells]

Hi, 
 
On Wednesday 20 November 2002 5:08 pm, Robert Watson wrote: 
 dmesg is a command that dumps the kernel message buffer.  You can 
redirect 
 the output to a file: 
 
   dmesg  fileofchoice 
 
Sure. This bit is sufficiently similar to Linux for me to know it :) 
 
Problem is, I haven't got 4.7 installed. I want to install 5.0DP2. I
can't 
install 5.0DP2 due to the reboot, and therefore I can't get to a 
command 
prompt in order to run dmesg 
 
Bit of a chicken  egg situation -- if I could install 5.0Dp2
successfully, 
then I wouldn't need to be sending you the output of dmesg here ;) 
 
 Also, you may find it helpful to boot verbosely by using: 
 
   set boot_verbose 
 
 in the boot loader prior to starting the kernel. 
 
Didn't know about that. I'll give it a go. 
 
-- 
Cheers, Chris Howells -- [EMAIL PROTECTED], [EMAIL PROTECTED] 
Web: http://chrishowells.co.uk, PGP key: 
http://chrishowells.co.uk/pgp.txt 
KDE: http://www.koffice.org, http://edu.kde.org, 
http://usability.kde.org 
 

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

[no subject]

[frode]

Installing 5.0-DP2
From: Frode Nordahl [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
X-Priority: 
3
Importance: Normal
X-Mailer: SquirrelMail (version 1.2.8)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Hello,


Installation from DOS fs does not work.  The firsr error message is
Operation not permitted, conequetive attempts fails with
/dist allready exists or similar.

Unable to delete non-freebsd partitions from Fdisk.  Setting them to
type 165 and then deleting works.

Since installation from DOS is my only option right now, i went ahead
using installer from a june -CURRENT.  This almost worked, but the
boot code was not properly written.  The BootMgr comes up, but I get
no further.

Trying Fixit from the 5.0-DP2 boot disks fails! Similar error as when
trying install from DOS fs.  Fixing this after boot does not work
because of GEOM :(

Mvh, Frode Nordahl




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

[no subject]

[David Veenma]

subscribe freebsd-current



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

[no subject]

[Dheeraj]

the ps aux command show some proceses started on dec 31 1969. this is
-current from Nov 5th.

attached is the log.

If i compile daemon_saver in the kernel, somehow it get invoked even while the machine 
is booting. I have to manually press a key to see the boot messages.


dheeraj




USERPID %CPU %MEM   VSZ  RSS  TT  STAT STARTED  TIME COMMAND
root 11 97.5  0.0 0   12  ??  RL   31Dec69 189:49.97  (idle)
root 10  0.0  0.0 0   12  ??  DL   31Dec69   0:00.00  (ktrace)
root  1  0.0  0.3   688  212  ??  ILs  31Dec69   0:00.11 /sbin/init --
root 12  0.0  0.0 0   12  ??  WL   31Dec69   0:00.01  (swi1: net)
root 13  0.1  0.0 0   12  ??  WL   31Dec69   1:17.90  (swi6: tty:sio cl
root  2  0.0  0.0 0   12  ??  DL   31Dec69   0:08.54  (g_event)
root  3  0.0  0.0 0   12  ??  DL   31Dec69   0:03.95  (g_up)
root  4  0.0  0.0 0   12  ??  DL   31Dec69   0:04.98  (g_down)
root 15  0.0  0.0 0   12  ??  DL   31Dec69   0:01.27  (random)
root 18  0.0  0.0 0   12  ??  WL   31Dec69   0:01.43  (irq14: ata0)
root 20  0.0  0.0 0   12  ??  WL   31Dec69   0:00.02  (irq11: ed0)
root 21  0.0  0.0 0   12  ??  WL   31Dec69   0:00.03  (irq1: atkbd0)
root 22  0.0  0.0 0   12  ??  WL   31Dec69   0:00.00  (irq6: fdc0)
root 23  0.0  0.0 0   12  ??  WL   31Dec69   0:00.00  (irq7: ppc0)
root 24  0.0  0.0 0   12  ??  WL   31Dec69   0:00.00  (swi0: tty:sio)
root  5  0.0  0.0 0   12  ??  DL   31Dec69   0:00.41  (pagedaemon)
root  6  0.0  0.0 0   12  ??  DL   31Dec69   0:00.00  (vmdaemon)
root  7  0.0  0.0 0   12  ??  DL   31Dec69   0:01.35  (pagezero)
root  8  0.0  0.0 0   12  ??  DL   31Dec69   0:00.34  (bufdaemon)
root  9  0.0  0.0 0   12  ??  DL   31Dec69   0:00.00  (vnlru)
root 31  0.0  0.0 0   12  ??  DL   31Dec69   0:01.49  (syncer)
root 32  0.0  0.0 0   12  ??  IL   31Dec69   0:00.00  (nfsiod 0)
root 33  0.0  0.0 0   12  ??  IL   31Dec69   0:00.00  (nfsiod 1)
root 34  0.0  0.0 0   12  ??  IL   31Dec69   0:00.00  (nfsiod 2)
root 35  0.0  0.0 0   12  ??  IL   31Dec69   0:00.00  (nfsiod 3)
root117  0.0  0.1   216   76  ??  Is3:28PM   0:00.00 adjkerntz -i
root230  0.0  1.0  1124  612  ??  Ss8:28PM   0:00.36 /usr/sbin/syslogd 
root388  0.0  2.1  2508 1288  ??  Is8:28PM   0:01.30 /usr/sbin/sshd
root393  0.0  2.9  2944 1752  ??  Ss8:28PM   0:02.23 sendmail: acceptin
smmsp   396  0.0  2.7  2848 1664  ??  Is8:28PM   0:00.08 sendmail: Queue ru
root420  0.0  0.8  1092  512  ??  Ss8:28PM   0:00.03 /usr/sbin/moused -
root450  0.0  1.2  1192  720  ??  Ss8:28PM   0:00.41 /usr/sbin/cron
root460  0.0  1.7  1504 1008  v0  Is8:28PM   0:00.25 login -p root
root461  0.0  1.0  1136  620  v1  Is+   8:28PM   0:00.04 /usr/libexec/getty
root462  0.0  1.0  1136  620  v2  Is+   8:28PM   0:00.04 /usr/libexec/getty
root463  0.0  1.0  1136  620  v3  Is+   8:28PM   0:00.04 /usr/libexec/getty
root464  0.0  1.0  1136  620  v4  Is+   8:28PM   0:00.04 /usr/libexec/getty
root465  0.0  1.0  1136  620  v5  Is+   8:28PM   0:00.04 /usr/libexec/getty
root466  0.0  1.0  1136  620  v6  Is+   8:28PM   0:00.04 /usr/libexec/getty
root467  0.0  1.0  1136  620  v7  Is+   8:28PM   0:00.04 /usr/libexec/getty
root773  0.0  1.9  1468 1148  v0  S10:55PM   0:00.28 -csh (csh)
root  0  0.0  0.0 0   12  ??  DLs  31Dec69   0:00.07  (swapper)
root864  0.0  0.8   628  484  v0  R+   11:40PM   0:00.01 ps aux

[no subject]

[Dheeraj]

the ps aux command show some proceses started on dec 31 1969. this is
-current from Nov 5th.

attached is the log.

If i compile daemon_saver in the kernel, somehow it get invoked even while the machine 
is booting. I have to manually press a key to see the boot messages.


dheeraj




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

(no subject)

[suken woo]

unsubcribe freebsd-current


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

[no subject]

[Nikolaj Hansen]

ProgressIT I/S
Nikolaj Hansen
Algade 15 - 2tv
9000  Ålborg
Denmark

Windows XP: A 32-bit graphical shell for a 16-bit patch to an 8-bit
operating system  originally encoded for a 4 bit microprocessor by a 2-bit
company who can't stand 1 bit of competition.


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

[no subject]

[Hay,Daniel]

subscribe

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

[no subject]

[Koop Mast]

subscribe hackers



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

[no subject]

[current]

subscribe freebsd-current [EMAIL PROTECTED]


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

[no subject]

[Woefdram]

subscribe


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

[no subject]

[mandd]

[no subject]

[infork]

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

[no subject]

Hello freebsd-current,

  Hello
  My system emit warning message
  ``calcru: negative time ...)''
  to the console
  What can I do with it?
  Please help

-- 
Best regards,
 Ñåðãåé  mailto:[EMAIL PROTECTED]



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

[no subject]

[Maxim M. Kazachek]

Building of x11-fonts/webfonts gives this message:
/usr/ports/Mk/bsd.port.mk, line 2580: warning: duplicate script for
target patch-message ignored

Which breaks portupgrade

   Sincerely, Maxim M. Kazachek
   mailto:[EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED]



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

[no subject]

[Ricardo A. Reis]

FreeBSD,BeOS,Linux|Cisco Network Academy

  BSD User = 050834 | Linux User = 280168

The Power to the Serve




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

[no subject]

[rob]

QUIT

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