Re: CLang and WERROR

[S . N . Grigoriev]

13.06.2012, 01:07, "Dimitry Andric" :
> On 2012-06-12 16:42, S.N.Grigoriev wrote:
>
>>  I've found out that CLang requires again NO_WERROR= and WERROR= statements 
>> in /etc/src.conf to build kernel from fresh sources. Older sources (at least 
>> up to June 4) did not require that. The following error occures:
>>
>>  clang -O2 -pipe -nostdinc -I/usr/include -I. 
>> -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99  -Wsystem-headers -Werror -Wall 
>> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
>> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
>> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
>> -Wno-pointer-sign  -o aicasm aicasm.o aicasm_symbol.o aicasm_gram.o 
>> aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll
>>  clang: error: argument unused during compilation: '-nostdinc'
>
> ...
>
> Ah, thanks for noticing.  I had forgotten to merge one additional change
> that was needed.
>
> Please update your stable/9 to r236975, which should fix this.

It works fine for me. Thanks, Dimitry!

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

Re: lost ZFS pool

[Damien Fleuriot]

On 12 Jun 2012, at 20:17, "Nenhum_de_Nos"  wrote:

> hail,
> 
> I write just to make sure its dead. I've lost the first disk on a ZFS pool 
> (jbod). Now I can't
> mount it with only the second disk. The first disk clicks to death :(
> 
> [root@optimus ~]# zpool status
>  pool: pool
> state: UNAVAIL
> status: One or more devices could not be opened.  There are insufficient
>replicas for the pool to continue functioning.
> action: Attach the missing device and online it using 'zpool online'.
>   see: http://www.sun.com/msg/ZFS-8000-3C
> scrub: none requested
> config:
> 
>NAME  STATE READ WRITE CKSUM
>pool  UNAVAIL  0 0 0  insufficient replicas
>  label/zfs1  UNAVAIL  0 0 0  cannot open
>  label/zfs2  ONLINE   0 0
> 
> I have a spare disk (blank), but even though I can't make it online again ...
> 
> is there any hope I can read the files in that disk ?
> 
> thanks,
> 
> matheus
> 

Johan has the right of it, you're splitting data between your 2 devices a la 
raid0, this means both disks are required for the pool to function.

Your data is gone and you're not recovering any of it.

You will want to follow Johan's recommendation of using mirror (raid1),  raidz 
(raid5) or even raidz2 (raid6) to ensure data integrity and availability.



Note that using raid does *not* exempt you from running backups.

As has been pointed out already (Jeremy Chadwick was that you ?), with large 
disks ( >1TB ) you encounter the risk of another disk in your raid array 
failing while you're rebuilding on the replacement drive, because of the high 
IO.

Also, while I am a proponent of using the full disk for ZFS (as opposed to a 
slice), it is recommended to use slices and shave off roughly 100mb from the 
disk space available when creating your pool.

This way, if an old disk fails and you replace it with one the same size but 
from another manufacturer (the size may vary a bit, imagine if it's 2mb 
smaller, you can't use it in your pool !) you won't face the 
problem.___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mpt: Unable to memory map registers

[Andrey Zonov]

On 6/13/12 12:51 AM, John Baldwin wrote:

On Tuesday, June 12, 2012 3:53:09 pm Andrey Zonov wrote:

On 6/12/12 10:06 PM, John Baldwin wrote:



[snip]

Ok, I've added some more debugging.  The patch is a bit larger now and you

can

fetch it from www.freebsd.org/~jhb/patches/pcib_debug.patch



New dmesg is in attach.


Sheesh, found another bug (wasn't masking 'front' properly).

Try updated patch (same URL).



Great!  It works!

dmesg as always attached.

--
Andrey Zonov
Physical memory chunk(s):
0x0001 - 0x0009bfff, 573440 bytes (140 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x00f67000 - 0xdff9, 3741552640 bytes (913465 pages)
0xdffae000 - 0xdffa, 8192 bytes (2 pages)
0x0001 - 0x0007e2ea7fff, 29576822784 bytes (7220904 pages)
avail memory = 33113874432 (31579 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <090808 APIC1308>
INTR: Adding local APIC 1 as a target
INTR: Adding local APIC 2 as a target
INTR: Adding local APIC 3 as a target
INTR: Adding local APIC 4 as a target
INTR: Adding local APIC 5 as a target
INTR: Adding local APIC 6 as a target
INTR: Adding local APIC 7 as a target
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
 cpu4 (AP): APIC ID:  4
 cpu5 (AP): APIC ID:  5
 cpu6 (AP): APIC ID:  6
 cpu7 (AP): APIC ID:  7
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 3
APIC: CPU 2 has ACPI ID 5
APIC: CPU 3 has ACPI ID 7
APIC: CPU 4 has ACPI ID 2
APIC: CPU 5 has ACPI ID 4
APIC: CPU 6 has ACPI ID 6
APIC: CPU 7 has ACPI ID 8
x86bios:  IVT 0x00-0x0004ff at 0xfe00
x86bios: SSEG 0x098000-0x098fff at 0xff800029
x86bios: EBDA 0x09e000-0x09 at 0xfe09e000
x86bios:  ROM 0x0a-0x0fefff at 0xfe0a
WARNING: VIMAGE (virtualized network stack) is a highly experimental feature.
ULE: setup cpu 0
ULE: setup cpu 1
ULE: setup cpu 2
ULE: setup cpu 3
ULE: setup cpu 4
ULE: setup cpu 5
ULE: setup cpu 6
ULE: setup cpu 7
ACPI: RSDP 0xf9960 00024 (v02 ACPIAM)
ACPI: XSDT 0xdffb0100 00074 (v01 090808 XSDT1308 20080908 MSFT 0097)
ACPI: FACP 0xdffb0290 000F4 (v03 090808 FACP1308 20080908 MSFT 0097)
ACPI: DSDT 0xdffb04d0 05414 (v01  CLSea CLSea007 0007 INTL 20051117)
ACPI: FACS 0xdffbe000 00040
ACPI: APIC 0xdffb0390 000AA (v01 090808 APIC1308 20080908 MSFT 0097)
ACPI: MCFG 0xdffb0490 0003C (v01 090808 OEMMCFG  20080908 MSFT 0097)
ACPI: OEMB 0xdffbe040 00071 (v01 090808 OEMB1308 20080908 MSFT 0097)
ACPI: HPET 0xdffb58f0 00038 (v01 090808 OEMHPET  20080908 MSFT 0097)
ACPI: ASF! 0xdffb5928 00083 (v32 AMIASF E7230ASF 0001 INTL 20051117)
ACPI: EINJ 0xdffb59b0 00130 (v01  AMIER AMI_EINJ 20080908 MSFT 0097)
ACPI: BERT 0xdffb5b40 00030 (v01  AMIER AMI_BERT 20080908 MSFT 0097)
ACPI: ERST 0xdffb5b70 001B0 (v01  AMIER AMI_ERST 20080908 MSFT 0097)
ACPI: HEST 0xdffb5d20 000A8 (v01  AMIER AMI_HEST 20080908 MSFT 0097)
MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec0
ioapic0: Routing external 8259A's -> intpin 0
MADT: Found IO APIC ID 9, Interrupt 24 at 0xfec88000
MADT: Found IO APIC ID 10, Interrupt 48 at 0xfec89000
MADT: Interrupt override: source 0, irq 2
ioapic0: Routing IRQ 0 -> intpin 2
MADT: Interrupt override: source 9, irq 9
ioapic0: intpin 9 trigger: level
lapic: Routing NMI -> LINT1
lapic: LINT1 trigger: edge
lapic: LINT1 polarity: high
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
ioapic2  irqs 48-71 on motherboard
cpu0 BSP:
 ID: 0x   VER: 0x00050014 LDR: 0x DFR: 0x
  lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff
  timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400
kbd: new array size 4
kbd1 at kbdmux0
mem: 
nfslock: pseudo-device
null: 
random: 
cpuctl: access to MSR registers/cpuid info.
io: 
acpi0: <090808 XSDT1308> on motherboard
PCIe: Memory Mapped configuration base @ 0xe000
ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48
ACPI: Executed 1 blocks of module-level executable AML code
acpi0: Power Button (fixed)
acpi0: reservation of fed1c000, 4000 (3) failed
acpi0: reservation of fed2, 25000 (3) failed
acpi0: reservation of fed45000, 5b000 (3) failed
acpi0: reservation of feda, 2 (3) failed
acpi0: reservation of fec01000, 7f000 (3) failed
acpi0: reservation of fec8, 6000 (3) failed
acpi0: reservation of fec86000, a000 (3) failed
acpi0: reservation of ff00, 40 (3) failed
acpi0: reservation of ff40, 40 (3) failed
acpi0: reservation of ff80, 40 (3) failed
acpi0: reservation of ffc0, 40 (3) failed
acpi0: reservation of fec0, 1000 (3) failed
acpi0: reservation of fee0, 1000 (3) failed
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, dff0 (3) failed
cpu0:  on acpi0
cpu0: switching to generic Cx mode
cp

Re: lost ZFS pool

[Johan Hendriks]

Nenhum_de_Nos schreef:

hail,

I write just to make sure its dead. I've lost the first disk on a ZFS pool 
(jbod). Now I can't
mount it with only the second disk. The first disk clicks to death :(

[root@optimus ~]# zpool status
   pool: pool
  state: UNAVAIL
status: One or more devices could not be opened.  There are insufficient
 replicas for the pool to continue functioning.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-3C
  scrub: none requested
config:

 NAME  STATE READ WRITE CKSUM
 pool  UNAVAIL  0 0 0  insufficient replicas
   label/zfs1  UNAVAIL  0 0 0  cannot open
   label/zfs2  ONLINE   0 0

I have a spare disk (blank), but even though I can't make it online again ...

is there any hope I can read the files in that disk ?

thanks,

matheus



If i read your pool correct, you do not have raidz, or a mirrored pool.
You are just striping the data on both disks. This means you cannot 
loose any disk in the pool.


In the future use a mirrored pool, or a raidz pool.
In this case the pool is lost.

regards
Johan Hendriks



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

Re: CLang and WERROR

[Dimitry Andric]

On 2012-06-12 16:42, S.N.Grigoriev wrote:
> I've found out that CLang requires again NO_WERROR= and WERROR= statements in 
> /etc/src.conf to build kernel from fresh sources. Older sources (at least up 
> to June 4) did not require that. The following error occures:
> 
> clang -O2 -pipe -nostdinc -I/usr/include -I. 
> -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99  -Wsystem-headers -Werror -Wall 
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
> -Wno-pointer-sign  -o aicasm aicasm.o aicasm_symbol.o aicasm_gram.o 
> aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll
> clang: error: argument unused during compilation: '-nostdinc'
...

Ah, thanks for noticing.  I had forgotten to merge one additional change
that was needed.

Please update your stable/9 to r236975, which should fix this.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mpt: Unable to memory map registers

[John Baldwin]

On Tuesday, June 12, 2012 3:53:09 pm Andrey Zonov wrote:
> On 6/12/12 10:06 PM, John Baldwin wrote:
> >
> [snip]
> > Ok, I've added some more debugging.  The patch is a bit larger now and you 
can
> > fetch it from www.freebsd.org/~jhb/patches/pcib_debug.patch
> >
> 
> New dmesg is in attach.

Sheesh, found another bug (wasn't masking 'front' properly).

Try updated patch (same URL).

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

Re: mpt: Unable to memory map registers

[Andrey Zonov]

On 6/12/12 10:06 PM, John Baldwin wrote:



[snip]

Ok, I've added some more debugging.  The patch is a bit larger now and you can
fetch it from www.freebsd.org/~jhb/patches/pcib_debug.patch



New dmesg is in attach.

--
Andrey Zonov
MP Configuration Table version 1.4 found at 0x800fcb70
Table 'FACP' at 0xdffb0290
Table 'APIC' at 0xdffb0390
APIC: Found table at 0xdffb0390
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 2: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 3: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 4: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 5: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 6: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 7: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 8: enabled
SMP: Added CPU 7 (AP)
Copyright (c) 1992-2012 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 9.0-STABLE #0 r+fffa9c7-dirty: Tue Jun 12 22:58:33 MSK 2012
r...@dst-dev.yandex.ru:/usr/obj/usr/src/sys/stable9-amd64-dtrace amd64
Preloaded elf kernel "/boot/kernel.test/kernel" at 0x80f1b000.
Calibrating TSC clock ... TSC clock: 2826307647 Hz
CPU: Intel(R) Xeon(R) CPU   E5440  @ 2.83GHz (2826.31-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x1067a  Family = 6  Model = 17  Stepping = 10
  
Features=0xbfebfbff
  
Features2=0xc0ce3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  TSC: P-state invariant, performance statistics
real memory  = 34359738368 (32768 MB)
Physical memory chunk(s):
0x0001 - 0x0009bfff, 573440 bytes (140 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x00f67000 - 0xdff9, 3741552640 bytes (913465 pages)
0xdffae000 - 0xdffa, 8192 bytes (2 pages)
0x0001 - 0x0007e2ea7fff, 29576822784 bytes (7220904 pages)
avail memory = 33113874432 (31579 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <090808 APIC1308>
INTR: Adding local APIC 1 as a target
INTR: Adding local APIC 2 as a target
INTR: Adding local APIC 3 as a target
INTR: Adding local APIC 4 as a target
INTR: Adding local APIC 5 as a target
INTR: Adding local APIC 6 as a target
INTR: Adding local APIC 7 as a target
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
 cpu4 (AP): APIC ID:  4
 cpu5 (AP): APIC ID:  5
 cpu6 (AP): APIC ID:  6
 cpu7 (AP): APIC ID:  7
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 3
APIC: CPU 2 has ACPI ID 5
APIC: CPU 3 has ACPI ID 7
APIC: CPU 4 has ACPI ID 2
APIC: CPU 5 has ACPI ID 4
APIC: CPU 6 has ACPI ID 6
APIC: CPU 7 has ACPI ID 8
x86bios:  IVT 0x00-0x0004ff at 0xfe00
x86bios: SSEG 0x098000-0x098fff at 0xff800029
x86bios: EBDA 0x09e000-0x09 at 0xfe09e000
x86bios:  ROM 0x0a-0x0fefff at 0xfe0a
WARNING: VIMAGE (virtualized network stack) is a highly experimental feature.
ULE: setup cpu 0
ULE: setup cpu 1
ULE: setup cpu 2
ULE: setup cpu 3
ULE: setup cpu 4
ULE: setup cpu 5
ULE: setup cpu 6
ULE: setup cpu 7
ACPI: RSDP 0xf9960 00024 (v02 ACPIAM)
ACPI: XSDT 0xdffb0100 00074 (v01 090808 XSDT1308 20080908 MSFT 0097)
ACPI: FACP 0xdffb0290 000F4 (v03 090808 FACP1308 20080908 MSFT 0097)
ACPI: DSDT 0xdffb04d0 05414 (v01  CLSea CLSea007 0007 INTL 20051117)
ACPI: FACS 0xdffbe000 00040
ACPI: APIC 0xdffb0390 000AA (v01 090808 APIC1308 20080908 MSFT 0097)
ACPI: MCFG 0xdffb0490 0003C (v01 090808 OEMMCFG  20080908 MSFT 0097)
ACPI: OEMB 0xdffbe040 00071 (v01 090808 OEMB1308 20080908 MSFT 0097)
ACPI: HPET 0xdffb58f0 00038 (v01 090808 OEMHPET  20080908 MSFT 0097)
ACPI: ASF! 0xdffb5928 00083 (v32 AMIASF E7230ASF 0001 INTL 20051117)
ACPI: EINJ 0xdffb59b0 00130 (v01  AMIER AMI_EINJ 20080908 MSFT 0097)
ACPI: BERT 0xdffb5b40 00030 (v01  AMIER AMI_BERT 20080908 MSFT 0097)
ACPI: ERST 0xdffb5b70 001B0 (v01  AMIER AMI_ERST 20080908 MSFT 0097)
ACPI: HEST 0xdffb5d20 000A8 (v01  AMIER AMI_HEST 20080908 MSFT 0097)
MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec0
ioapic0: Routing external 8259A's -> intpin 0
MADT: Found IO APIC ID 9, Interrupt 24 at 0xfec88000
MADT: Found IO APIC ID 10, Interrupt 48 at 0xfec89000
MADT: Interrupt override: source 0, irq 2
ioapic0: Routing IRQ 0 -> intpin 2
MADT: Interrupt override: source 9, irq 9
ioapic0: intpin 9 trigger: level
lapic: Routing NMI -> LINT1
lapic: LINT1 trigger: edge
lapic: LINT1 polarity: high
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
ioapic2  irqs 48-71 on motherboard
cpu0 BSP:
 ID: 0x   VER: 0x000

lost ZFS pool

[Nenhum_de_Nos]

hail,

I write just to make sure its dead. I've lost the first disk on a ZFS pool 
(jbod). Now I can't
mount it with only the second disk. The first disk clicks to death :(

[root@optimus ~]# zpool status
  pool: pool
 state: UNAVAIL
status: One or more devices could not be opened.  There are insufficient
replicas for the pool to continue functioning.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-3C
 scrub: none requested
config:

NAME  STATE READ WRITE CKSUM
pool  UNAVAIL  0 0 0  insufficient replicas
  label/zfs1  UNAVAIL  0 0 0  cannot open
  label/zfs2  ONLINE   0 0

I have a spare disk (blank), but even though I can't make it online again ...

is there any hope I can read the files in that disk ?

thanks,

matheus


-- 
We will call you Cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://en.wikipedia.org/wiki/Posting_style
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mpt: Unable to memory map registers

[John Baldwin]

On Monday, June 11, 2012 5:01:18 pm Andrey Zonov wrote:
> On 6/12/12 12:19 AM, John Baldwin wrote:
> > On Monday, June 11, 2012 11:25:38 am Andrey Zonov wrote:
> >> On 6/11/12 6:19 PM, John Baldwin wrote:
> >>> On Saturday, June 09, 2012 3:06:19 pm Andrey Zonov wrote:
>  On 6/9/12 9:35 PM, Marius Strobl wrote:
> > On Sat, Jun 09, 2012 at 12:58:05PM +0400, Andrey Zonov wrote:
> >> On 6/8/12 10:27 PM, John Baldwin wrote:
> >>> On Friday, June 08, 2012 11:48:50 am Andrey Zonov wrote:
>  On Fri, Jun 8, 2012 at 7:19 PM, John Baldwin 
wrote:
> > On Friday, June 08, 2012 3:14:19 am Andrey Zonov wrote:
> >> On 6/7/12 10:02 PM, Andrey Zonov wrote:
> >>> Hi,
> >>>
> >>> I just upgraded a few machines from 8.2-STABLE (r221983) to 9.0-
> >>> STABLE
> >>> (r234600) and now they can't find any disk because SAS 
controller
> >>> cannot
> >>> initialize with the following diagnostic:
> >>>
> >>> mpt0: port 0xd000-0xd0ff irq 26 
at
> >>> device
> >>> 3.0 on pci6
> >>> mpt0: 0x4000 bytes of rid 0x14 res 3 failed (0, 
0x).
> >>> mpt0: Unable to memory map registers.
> >>> mpt0: Giving Up.
> >>>
> >>> pciconf -lv:
> >>> mpt0@pci0:6:3:0: class=0x01 card=0x81dd1043 chip=0x00541000
> >>> rev=0x02
> >>> hdr=0x00
> >>> vendor = 'LSI Logic / Symbios Logic'
> >>> device = 'SAS1068 PCI-X Fusion-MPT SAS'
> >>> class = mass storage
> >>> subclass = SCSI
> >>>
> >>> I tried to boot to latest HEAD and found the same problem. I 
also
> >>> tried
> >>> to build kernel with mpt driver from my 8.2. Controller didn't
> >>> initialize with the same diagnostic. So it looks like the 
problem is
> >>> not
> >>> in mpt driver.
> >>>
> >>> Any help would be appreciated.
> >>>
> >>
> >> +jhb@
> >>
> >> Hi John,
> >>
> >> Could you please help me with the problem above?  It looks like 
the
> >> problem is in PCI code and you changed things there.
> >
> > Can you get a verbose dmesg?
> >
> 
>  Yes, it's in attach.
> >>>
> >>> Can you get the output of 'devinfo -u' and 'devinfo -rv' from a 
broken
> >>> kernel?
> >>>
> >>
> >> Attached.
> >>
> >>> Can you also try setting 'debug.acpi.disable=sysres' in the loader?
> >>>
> >>
> >> Didn't help.
> >>
> >
> > That's probably due to a typo, the corret loader tunable is
> > debug.acpi.disabled=sysres (note the 'd').
> >
> 
>  This helps, thanks!  Please explain what this means.
> >>>
> >>> Well, it's working around a bug in your BIOS, but in this case FreeBSD 
should
> >>> have coped fine and it didn't.  Please try using this patch without that
> >>> tunable and get a verbose dmesg please:
> >>
> >> Unfortunately didn't work.
> >
> > Ah, it did work a bit, but it uncovered a larger bug.  I didn't make the
> > PCI-PCI bridge driver recursively grow windows.  Try this:
> >
> 
> Still no luck.

Ok, I've added some more debugging.  The patch is a bit larger now and you can 
fetch it from www.freebsd.org/~jhb/patches/pcib_debug.patch

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

Re: GCC-4.6-20120608 has a corrupt archive or a bad checksum

[Damien Fleuriot]

On 6/12/12 7:04 PM, Gerald Pfeifer wrote:
> John Merryweather Cooper wrote:
>> Bad distfile or checksum for lang/gcc46
> 
> The mirror you are using per your e-mail --
> ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/sources.redhat.com/
> -- provides a broken image.
> 
> I have done several downloads myself, from the original source
> and other mirrors, and always get the correct checksum (and a
> matching tarball), that is, the one matching gcc46/distinfo in
> FreeBSD Ports CVS.
> 
> If you download directly from 
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120608/gcc-4.6-20120608.tar.bz2
> and put that into ports/distfiles, that should work?  Alternatively,
> download repeatedly until it hits a different mirror?
> 
> Gerald
>

Now, call my paranoid but shouldn't he warn the mirror's operator ?

Could be a bad transfer from the main site to the mirror , could be a
hijacked source.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: GCC-4.6-20120608 has a corrupt archive or a bad checksum

[Gerald Pfeifer]

John Merryweather Cooper wrote:
> Bad distfile or checksum for lang/gcc46

The mirror you are using per your e-mail --
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/sources.redhat.com/
-- provides a broken image.

I have done several downloads myself, from the original source
and other mirrors, and always get the correct checksum (and a
matching tarball), that is, the one matching gcc46/distinfo in
FreeBSD Ports CVS.

If you download directly from 
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120608/gcc-4.6-20120608.tar.bz2
and put that into ports/distfiles, that should work?  Alternatively,
download repeatedly until it hits a different mirror?

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

ANNOUNCE: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-12:02.ipv6refcount

[FreeBSD Errata Notices]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

=
FreeBSD-EN-12:02.ipv6refcount   Errata Notice
  The FreeBSD Project

Topic:  Reference count errors in IPv6 code

Category:   core
Modules:sys_netinet sys_netinet6
Announced:  2012-06-12
Credits:Scott Long, Rui Paulo, Maksim Yevmenkin
Affects:FreeBSD 8.0 and later
Corrected:  2012-06-09 22:44:49 UTC (RELENG_8, 8.3-STABLE)
2012-06-12 12:10:10 UTC (RELENG_8_3, 8.3-RELEASE-p3)
2012-06-12 12:10:10 UTC (RELENG_8_2, 8.2-RELEASE-p9)
2012-06-12 12:10:10 UTC (RELENG_8_1, 8.1-RELEASE-p11)
2012-06-09 22:44:24 UTC (RELENG_9, 9.0-STABLE)
2012-06-12 12:10:10 UTC (RELENG_9_0, 9.0-RELEASE-p3)

For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
http://security.freebsd.org/>.

I.   Background

The FreeBSD network stack implements Internet Protocol version 6 (IPv6),
the successor to IPv4.  IPv6 is now seeing widespread deployment.

Reference counts are a programming technology used by the FreeBSD kernel
to maintain stability of objects while in use.

II.  Problem Description

The FreeBSD IPv4 and IPv6 kernel implementations employ reference counts to
protect IP addresses configured on network interfaces.  Due to multiple
bugs, IPv6 address references may be improperly acquired or released; IPv4
is unaffected.

III. Impact

Under high IPv6 network load, reference counts may improperly hit zero
due to overflow or underflow, causing an IPv6 address, which is still in
use, to be freed.  This will lead to a kernel panic on next access.

IV.  Workaround

No workaround is available, but systems not using any IPv6 communication
are not affected.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 8-STABLE, or 9-STABLE, or to the
RELENG_8_3, RELENG_8_2, RELENG_8_1, or RELENG_9_0 security branch dated
after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 8.3, 8.2,
8.1, and 9.0 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 8.1-RELEASE, 8.2-RELEASE, and 9.0-RELEASE]
# fetch http://security.FreeBSD.org/patches/EN-12:02/ipv6refcount.patch
# fetch http://security.FreeBSD.org/patches/EN-12:02/ipv6refcount.patch.asc

[FreeBSD 8.3-RELEASE]
# fetch http://security.FreeBSD.org/patches/EN-12:02/ipv6refcount-83.patch
# fetch http://security.FreeBSD.org/patches/EN-12:02/ipv6refcount-83.patch.asc

b) Apply the patch.

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.

3) To update your vulnerable system via a binary patch:

Systems running 8.3-RELEASE, 8.2-RELEASE, 8.1-RELEASE, or 9.0-RELEASE on
the i386 or amd64 platforms can be updated via the freebsd-update(8)
utility:

# freebsd-update fetch
# freebsd-update install

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

CVS:

Branch   Revision
  Path
- -
RELENG_8
  sys/netinet/tcp_input.c  1.411.2.22
  sys/netinet6/in6.c   1.121.2.28
  sys/netinet6/ip6_input.c  1.132.2.9
RELENG_8_3
  src/UPDATING 1.632.2.26.2.5
  src/sys/conf/newvers.sh   1.83.2.15.2.7
  sys/netinet/tcp_input.c  1.411.2.19.2.2
  sys/netinet6/in6.c   1.121.2.23.2.2
  sys/netinet6/ip6_input.c  1.132.2.6.4.2
RELENG_8_2
  src/UPDATING1.632.2.19.2.11
  src/sys/conf/newvers.sh  1.83.2.12.2.14
  sys/netinet/tcp_input.c   1.411.2.9.2.2
  sys/netinet6/in6.c   1.121.2.12.2.2
  sys/netinet6/ip6_input.c  1.132.2.6.2.2
RELENG_8_1
  src/UPDATING1.632.2.14.2.14
  src/sys/conf/newvers.sh  1.83.2.10.2.15
  sys/netinet/tcp_input.c   1.411.2.6.2.2
  sys/netinet6/in6.c   1.121.2.11.2.2
  sys/netinet6/ip6_input.c  1.132.2.4.2.2
RELENG_9
  sys/netinet/tcp_input.c  

CLang and WERROR

[S . N . Grigoriev]

Hi, list

I've found out that CLang requires again NO_WERROR= and WERROR= statements in 
/etc/src.conf to build kernel from fresh sources. Older sources (at least up to 
June 4) did not require that. The following error occures:

clang -O2 -pipe -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm 
-std=gnu99  -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wno-pointer-sign  -o aicasm aicasm.o aicasm_symbol.o 
aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll
clang: error: argument unused during compilation: '-nostdinc'
*** [aicasm] Error code 1

Stop in /usr/obj/usr/src/sys/GENERIC.
*** [buildkernel] Error code 1

Stop in /usr/src.
*** [buildkernel] Error code 1

Stop in /usr/src.

Is such a behaviour normal and expected?

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

Re: su problem

[Sami Halabi]

%su -m root -c 'cd /etc/ssh/ && sed -i .bak -e "s/PermitRootLogin
no/PermitRootLogin yes/"'
Password:
load: 0.00  cmd: su 42619 [ttydcd] 3.20r 0.00u 0.00s 0% 2088k

:(
I think there is no good solution but driving to the machine itself...

Sami

On Tue, Jun 12, 2012 at 4:10 PM, Damien Fleuriot  wrote:

> On 6/12/12 3:00 PM, Oliver Fromme wrote:
> > Damien Fleuriot  wrote:
> >  > Ok so, I've read all the replies so far and I'm a bit perplexed.
> >  >
> >  > Sami, before you drive 3 hours to and 3 hours fro, kindly log in as
> sody
> >  > over SSH, then try "login" to connect *locally* as the root user.
> >
> > That won't work.  Unless you've disabled the "securetty" check
> > in /etc/pam.d/login, but it is there for a reason.
> >
> > Best regards
> >Oliver
> >
>
>
> Aw :(
>
>
> With a bit of luck, anything that would just start a command without
> trying for an actual shell ?
>
> Perhaps su -m root -c 'cd /etc/ssh/ && sed -i .bak -e "s/PermitRootLogin
> no/PermitRootLogin yes/"' ?
>
> That way he could toggle remote root logins.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>



-- 
Sami Halabi
Information Systems Engineer
NMS Projects Expert
FreeBSD SysAdmin Expert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: IPv6 and CARP crashes boxes

[Damien Fleuriot]

On 6/12/12 3:05 PM, Adam Strohl wrote:
> On 6/12/2012 19:48, Pete French wrote:
>> I ran into some - aliases on a CARP integface did not seem
>> to work proprly - but if you workaround that then it appears
>> to work fine. We are using it in production with no problems.
> 
> I have noticed this issue (CARP + IPv4 aliases) with older (pre 9.x)
> versions of FreeBSD.
> 
> I maintain some legacy 6.2 servers and had to eventually add ifconfig
> statements inside rc.local to get the links to coalesce.  6.2 appears to
> ignore _alias directives entirely inside rc.conf, and has real issues
> if you add/delete aliases to a CARP interface while its up (both peers
> end up thinking they're MASTER).
> 
> In 9.x it all works as expected at least for IPv4 (rc.conf
> carp_alias entries, aliases, on the fly reconfiguring).
> 


Like Pete, we haven't experienced problems related to aliases either here.

Running on a variety of 8.1-RELEASE , 8.2-PRERELEASE, 8.2-RELEASE, and
now thankfully 8.3-STABLE ;)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: IPv6 and CARP crashes boxes

[Damien Fleuriot]

On 6/12/12 3:03 PM, Pete French wrote:
>> Thanks for the feedback Pete, what are you running ?
>>
>> We're on 8-STABLE here.
> 
> Yup, same here - aactually running a very recent STABLE now,
> but for most of this year it's been on one from January. The
> one running on the firewalls is from May 7th, and that works
> beautifully.
> 

Hmmm you might want to update again then, 2 SAs published late in may:

http://security.freebsd.org/advisories/FreeBSD-SA-12:01.openssl.asc
http://security.freebsd.org/advisories/FreeBSD-SA-12:02.crypt.asc



>> I've got some spare time on my hands actually, I'm gonna try some more
>> today, both on an ipv6-only carp, then on a v4+v6.
> 
> Ok, let us know how you get on - the config here is very simple, reproduced
> below for your viewing pleasure ;) This is from the 'active' firewall:
> 
>   ifconfig_em0="inet 10.32.10.1/16"
>   ipv6_ifconfig_em0="2a02:1658:1:2:a32f::1/64"
>   ifconfig_em1="inet 178.250.73.196/27"
>   ipv6_ifconfig_em1="2a02:1658:1:1::1:2/64"
> 
>   ifconfig_carp0="vhid 10 pass  10.32.10.6/16"
>   ifconfig_carp1="vhid 20 pass  178.250.73.198/27"
>   ipv6_ifconfig_carp2="vhid 30 pass  2a02:1658:1:2:a32f::6/64"
>   ipv6_ifconfig_carp3="vhid 40 pass  2a02:1658:1:1::1:1/64"
> 
> -pete.

Thanks, will keep the thread updated ;)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: su problem

[Damien Fleuriot]

On 6/12/12 3:00 PM, Oliver Fromme wrote:
> Damien Fleuriot  wrote:
>  > Ok so, I've read all the replies so far and I'm a bit perplexed.
>  > 
>  > Sami, before you drive 3 hours to and 3 hours fro, kindly log in as sody
>  > over SSH, then try "login" to connect *locally* as the root user.
> 
> That won't work.  Unless you've disabled the "securetty" check
> in /etc/pam.d/login, but it is there for a reason.
> 
> Best regards
>Oliver
> 


Aw :(


With a bit of luck, anything that would just start a command without
trying for an actual shell ?

Perhaps su -m root -c 'cd /etc/ssh/ && sed -i .bak -e "s/PermitRootLogin
no/PermitRootLogin yes/"' ?

That way he could toggle remote root logins.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: IPv6 and CARP crashes boxes

[Adam Strohl]

On 6/12/2012 20:08, Pete French wrote:

I have noticed this issue (CARP + IPv4 aliases) with older (pre 9.x)
versions of FreeBSD.


Ah, just to be clear, the only problems I had with aliases weher IPv6 - it
always worked properly with IPv4. But I didnt try on anything pre 8.1!

-pete.


Doh, I caught this just as I hit send :P

--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ULE Scheduler

[Momchil Ivanov]

At Tue, 12 Jun 2012 14:03:10 +0200 (CEST),
Oliver Fromme wrote:
> 
> Momchil Ivanov  wrote:
>  > I was just curious why both processes are hopping around,
>  > because I would naively think that should not happen.
> 
> I'll try to explain ...
> 
> There are always many more processes and threads being executed
> beside the two CPU-bound ones that you see at the top of the
> top(1) display.  For example, there are at least 15 threads
> inside the kernel (see "ps -auxww") that are scheduled every
> now and then.  Or look at "vmstat -i" output to see the
> interrupt statistics:  Several hundred times per second,
> the interrupt handlers have to be executed.
> 
> So, what happens is that an interrupt occurs (from a hardware
> clock, from a hard disk controller, from an input device, or
> anything else).  Then your process is _removed_ from the core
> on which it is currently executing, and the interrupt handler
> starts executing.  The same can happen on the second core at
> the same time, because different kernel threads can execute
> simultaneously (if they don't share resources).  Now, if the
> interrupt handler on one of the two cores is done, your own
> process has a chance to be scheduled again.  In this moment,
> it does not matter at all on which core it is going to be
> executed.  The only difference is cache contents, but the
> first-level-caches are usually too small anyway.  The ULE
> scheduler takes a lot of information into account when making
> the decision, including cache affinity (the 4BSD scheduler
> doesn't know about that at all).

So the L2 cache is shared between both cores and hence it's size does
not matter at all?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: IPv6 and CARP crashes boxes

[Pete French]

> I have noticed this issue (CARP + IPv4 aliases) with older (pre 9.x) 
> versions of FreeBSD.

Ah, just to be clear, the only problems I had with aliases weher IPv6 - it
always worked properly with IPv4. But I didnt try on anything pre 8.1!

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

Re: IPv6 and CARP crashes boxes

[Adam Strohl]

On 6/12/2012 19:48, Pete French wrote:

I ran into some - aliases on a CARP integface did not seem
to work proprly - but if you workaround that then it appears
to work fine. We are using it in production with no problems.


I have noticed this issue (CARP + IPv4 aliases) with older (pre 9.x) 
versions of FreeBSD.


I maintain some legacy 6.2 servers and had to eventually add ifconfig 
statements inside rc.local to get the links to coalesce.  6.2 appears to 
ignore _alias directives entirely inside rc.conf, and has real issues 
if you add/delete aliases to a CARP interface while its up (both peers 
end up thinking they're MASTER).


In 9.x it all works as expected at least for IPv4 (rc.conf 
carp_alias entries, aliases, on the fly reconfiguring).


--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: IPv6 and CARP crashes boxes

[Pete French]

> Thanks for the feedback Pete, what are you running ?
>
> We're on 8-STABLE here.

Yup, same here - aactually running a very recent STABLE now,
but for most of this year it's been on one from January. The
one running on the firewalls is from May 7th, and that works
beautifully.

> I've got some spare time on my hands actually, I'm gonna try some more
> today, both on an ipv6-only carp, then on a v4+v6.

Ok, let us know how you get on - the config here is very simple, reproduced
below for your viewing pleasure ;) This is from the 'active' firewall:

ifconfig_em0="inet 10.32.10.1/16"
ipv6_ifconfig_em0="2a02:1658:1:2:a32f::1/64"
ifconfig_em1="inet 178.250.73.196/27"
ipv6_ifconfig_em1="2a02:1658:1:1::1:2/64"

ifconfig_carp0="vhid 10 pass  10.32.10.6/16"
ifconfig_carp1="vhid 20 pass  178.250.73.198/27"
ipv6_ifconfig_carp2="vhid 30 pass  2a02:1658:1:2:a32f::6/64"
ipv6_ifconfig_carp3="vhid 40 pass  2a02:1658:1:1::1:1/64"

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

Re: su problem

[Oliver Fromme]

Damien Fleuriot  wrote:
 > Ok so, I've read all the replies so far and I'm a bit perplexed.
 > 
 > Sami, before you drive 3 hours to and 3 hours fro, kindly log in as sody
 > over SSH, then try "login" to connect *locally* as the root user.

That won't work.  Unless you've disabled the "securetty" check
in /etc/pam.d/login, but it is there for a reason.

Best regards
   Oliver


-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"It combines all the worst aspects of C and Lisp:  a billion different
sublanguages in one monolithic executable.  It combines the power of C
with the readability of PostScript."
-- Jamie Zawinski, when asked: "What's wrong with perl?"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: IPv6 and CARP crashes boxes

[Damien Fleuriot]

On 6/12/12 2:48 PM, Pete French wrote:
> Meant to reply to this at the time, but have been away...
> 
>> Has anyone else run into problems when using IPv6 + CARP ?
> 
> I ran into some - aliases on a CARP integface did not seem
> to work proprly - but if you workaround that then it appears
> to work fine. We are using it in production with no problems.
> 
>> I plan to hold a presentation at work on IP6 and why we should start
>> using it, however I cannot promote the use of IP6 without redundancy
>> between firewalls like we currently do with CARP + pfsync.
> 
> The redundancy with pfsync works properly - an ssh session
> is maintained through the firewalls when they failover. I
> configure my machines to use a paiur of carp interfaces on each
> physical port, so I am not mixing IPv4 and IPv6 on the same
> interface. I onyl did that as an experiment when I was trying
> to work around the aliases problem, but have kept it for "tidnyess"
> 
> Basically our experience of the setup has been very positive - our
> main connectivity issues have come from the HE/Cogent peering squabble
> rather than any FreeBSD/Carp/PF failing.
> 
> cheers,
> 
> -pete.


Thanks for the feedback Pete, what are you running ?

We're on 8-STABLE here.

I've got some spare time on my hands actually, I'm gonna try some more
today, both on an ipv6-only carp, then on a v4+v6.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: IPv6 and CARP crashes boxes

[Pete French]

Meant to reply to this at the time, but have been away...

> Has anyone else run into problems when using IPv6 + CARP ?

I ran into some - aliases on a CARP integface did not seem
to work proprly - but if you workaround that then it appears
to work fine. We are using it in production with no problems.

> I plan to hold a presentation at work on IP6 and why we should start
> using it, however I cannot promote the use of IP6 without redundancy
> between firewalls like we currently do with CARP + pfsync.

The redundancy with pfsync works properly - an ssh session
is maintained through the firewalls when they failover. I
configure my machines to use a paiur of carp interfaces on each
physical port, so I am not mixing IPv4 and IPv6 on the same
interface. I onyl did that as an experiment when I was trying
to work around the aliases problem, but have kept it for "tidnyess"

Basically our experience of the setup has been very positive - our
main connectivity issues have come from the HE/Cogent peering squabble
rather than any FreeBSD/Carp/PF failing.

cheers,

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

Re: ULE Scheduler

[Oliver Fromme]

Momchil Ivanov  wrote:
 > I was just curious why both processes are hopping around,
 > because I would naively think that should not happen.

I'll try to explain ...

There are always many more processes and threads being executed
beside the two CPU-bound ones that you see at the top of the
top(1) display.  For example, there are at least 15 threads
inside the kernel (see "ps -auxww") that are scheduled every
now and then.  Or look at "vmstat -i" output to see the
interrupt statistics:  Several hundred times per second,
the interrupt handlers have to be executed.

So, what happens is that an interrupt occurs (from a hardware
clock, from a hard disk controller, from an input device, or
anything else).  Then your process is _removed_ from the core
on which it is currently executing, and the interrupt handler
starts executing.  The same can happen on the second core at
the same time, because different kernel threads can execute
simultaneously (if they don't share resources).  Now, if the
interrupt handler on one of the two cores is done, your own
process has a chance to be scheduled again.  In this moment,
it does not matter at all on which core it is going to be
executed.  The only difference is cache contents, but the
first-level-caches are usually too small anyway.  The ULE
scheduler takes a lot of information into account when making
the decision, including cache affinity (the 4BSD scheduler
doesn't know about that at all).

All of that happens several hundreds times per second.  You
don't have a chance to see it with a tool like top(1).

 > > Have you read Daniel Kalchev's reply in this thread?
 > > He explained very well why that's not a problem usually.
 > 
 > No, I haven't received that one.

Ok, I've appended it below.

Best regards
   Oliver

 begin of quoted text 

From: Daniel Kalchev 
Subject: Re: ULE Scheduler
Date: Thu, 7 Jun 2012 12:19:43 +0200 (CEST)
Message-ID: <4fd07ea0.8020...@digsys.bg>

On 07.06.12 11:16, Momchil Ivanov wrote:
 > Though, it was strange seeing both processes hopping around... I will
 > probably go back to the 4BSD scheduler if my laptop does another
 > self-shutdown in the next few days as Doug suggested.

You never run just two processes on FreeBSD, ever. The kernel too runs
multiple threads.

However small the CPU usage of the other processes is, they must run
from time to time, kicking out at least one of your CPU intensive
processes, possibly kicking them out both, as well. When that happens,
and they are queued to run again it does not matter much on which core
they ran before, because chances are it's cache will be invalidated
anyway. Also, different CPUs have different cache affinity. ULE is
supposed to be aware of this, while the 4BSD scheduler is not.

In any case, on an older single/dual core CPU there is rarely any
difference between both schedulers. Differences might appear in modern
multi-core CPUs..

Daniel

 end of quoted text 


-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"What is this talk of 'release'?  We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake."
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: su problem

[Damien Fleuriot]

On 6/9/12 9:55 AM, Sami Halabi wrote:
> Hi,
> I Just finished upgrade from FBSD-8.1-R fresh system to FBSD-8.3-p2.
> once done, i created regular accounts, in wheel group.
> 
> first all was okay, but suddenly i found my self blocked out, because i
> can't ssh as root, and i can't su either, when i su i get this:
> %su -
> Password:
> 
> and it stuck in that state whitout givving me root shell #.
> 
> any ideas how to solve this problem? the system is in the servers farm and
> i need to drive 3 hours each direction, so if there is remote solution i
> would appreciate it.
> 
> 
> %more /etc/group
> # $FreeBSD: src/etc/group,v 1.35.10.2.2.1 2012/03/03 06:15:13 kensmith Exp $
> #
> wheel:*:0:root,sody
> .
> .
> .
> sody:*:1001:
> 
> Thanks in advance,
> 

Ok so, I've read all the replies so far and I'm a bit perplexed.


Sami, before you drive 3 hours to and 3 hours fro, kindly log in as sody
over SSH, then try "login" to connect *locally* as the root user.


If that works, you'll at least have recovered root access and will be
able to install sudo, which should help you a great deal.

Of course there's still the matter of finding what's wrong with your
machine, afterwards.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: su problem

[Damien Fleuriot]

On 6/10/12 1:52 PM, Daniel Braniss wrote:
>> Sami Halabi  wrote:
>>  > Hi Oliver,
>>  > I saw you had similar problem for console on 2010
>>  > 
>> http://freebsd.1045724.n5.nabble.com/Serial-console-problems-with-stab=le-8-td3950684.html
>>
>> No, I don't think that the problem is related.  My problem
>> was with the serial console, while you don't have a serial
>> console attached at all (at least you didn't mention it).
>>
>>  > but the thread wasn't ended by recommendation or conclusions by you.
>>  >
>>  > did you solve that problem then?
>>
>> No, I came to the conclusion that the serial console support
>> in FreeBSD 8 was broken somehow.  So I removed the console
>> cable; it's running with an old VGA CRT as the console for
>> now.  Fortunately I require console access very seldom, so
>> I don't have to drive to that machine often.  It's still
>> annoying, but I didn't find a better solution; downgrading
>> to 7.x isn't an option.
>>
> just for the record, serial on 8.x works fine! the device naming has changed
> from sio to uart, and maybe some features. We use it on all our servers, even
> redirecting it where possible via ILO,IMPI,DRAC.  and is great for debuging
> or saving long trips :-)
> 
> WARNING: control access to these devices, specialy since root can login
> on the console!
> 
> danny
>

Daniel, would you kindly elaborate on the DRAC console redirection thingy ?

We're using Dells here and I loathe having to use their web interface
and the java app to get a console shell.

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

Re: Why Are You NOT Using FreeBSD ?

[H]

On Tuesday 12 June 2012 07:10 Chris Rees wrote:
> 
> > are essential for a desktop to work properly
> > 
> > of course the package collection needs then something similar to
> 
> portversion,
> 
> > but not based on ports tree versions, in order to find available updates
> > 
> > who then wants to customize or learn or who dares, can use the ports tree
> 
> You have hit the nail right on the head there, and that is the intention
> with pkgng.  Please feel free to have a go with it using the beta repos :)
> 
> Chris

yooo ... but I unfortunately since some time pkgng completes the ports tree 
novell  :)


cc  -O2 -pipe -march=athlon-mp -fno-strict-aliasing -march=athlon-mp -std=c99 
-I/dados/ports/ports-mgmt/pkg/work/pkg-1.0-beta15/libpkg  -
I/dados/ports/ports-mgmt/pkg/work/pkg-1.0-beta15/libpkg/../external/sqlite  -
I/dados/ports/ports-mgmt/pkg/work/pkg-1.0-
beta15/libpkg/../external/libyaml/include -DPREFIX=\"/usr/local\" -g -O0 -
std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -
Wold-style-definition -Wno-pointer-sign -c usergroup.c -o usergroup.o
cc1: warnings being treated as errors
In file included from usergroup.c:36:
private/gr_util.h:27: warning: redundant redeclaration of 'gr_copy'
/usr/include/libutil.h:165: warning: previous declaration of 'gr_copy' was 
here
private/gr_util.h:28: warning: redundant redeclaration of 'gr_fini'
/usr/include/libutil.h:168: warning: previous declaration of 'gr_fini' was here
private/gr_util.h:29: warning: redundant redeclaration of 'gr_init'
/usr/include/libutil.h:169: warning: previous declaration of 'gr_init' was 
here
private/gr_util.h:30: warning: redundant redeclaration of 'gr_lock'
/usr/include/libutil.h:170: warning: previous declaration of 'gr_lock' was 
here
private/gr_util.h:31: warning: redundant redeclaration of 'gr_mkdb'
/usr/include/libutil.h:172: warning: previous declaration of 'gr_mkdb' was 
here
private/gr_util.h:32: warning: redundant redeclaration of 'gr_tmp'
/usr/include/libutil.h:173: warning: previous declaration of 'gr_tmp' was here
*** Error code 1

Stop in /dados/ports/ports-mgmt/pkg/work/pkg-1.0-beta15/libpkg.
*** Error code 1

Stop in /dados/ports/ports-mgmt/pkg/work/pkg-1.0-beta15.
*** Error code 1



Hans





-- 

H
+55 17 4141.


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

Re: su problem

[Oliver Pinter]

truss, ktrace

the sody user is member of wheel?

On 6/12/12, Ronald Klop  wrote:
> On Mon, 11 Jun 2012 15:53:34 +0200, Sami Halabi  wrote:
>
>> Hi,
>> I opened 2 terminals with user sody.
>> in first i hit "su -", and supplied password, it was stcuked.
>> in the other I did:
>>
>> %ps xau | grep su
>> sody  39830  0.0  0.0  9124  1500   0  S+4:51PM   0:00.00 grep su
>> root  39812  0.0  0.0 21732  2088   1  I 4:49PM   0:00.00 su -
>> root  39813  0.0  0.0 21732  2108   1  I+4:49PM   0:00.00 su -
>> %procstat -kk 39812
>>   PIDTID COMM TDNAME   KSTACK
>> %procstat -kk 39813
>>   PIDTID COMM TDNAME   KSTACK
>> %
>>
>
> Mmmm, I'm out of options than. Maybe somebody else has a good idea.
>
> Ronald.
>
>
>>
>> Sami
>>
>> On Mon, Jun 11, 2012 at 11:14 AM, Ronald Klop
>> wrote:
>>
>>> On Sat, 09 Jun 2012 18:42:27 +0200, Eugene Grosbein 
>>> wrote:
>>>
>>>  09.06.2012 19:47, Sami Halabi пишет:

> %su -
> Password:
> load: 0.00  cmd: su 30588 [ttydcd] 0.91r 0.00u 0.00s 0% 2092k
>

 Perpaps, your system had no keyboard attached at boot time;
 or for some other reason it booted with /dev/console being serial
 console
 instead of vidconsole. su locks trying to access serial console
 that is /dev/ttyd0 by default and has Carrier Detect flag enabled.
 Hence, it waits for CD on the first serial port (miserably and
 hopelessly).

 You can check if it's true with "sysctl kern.console" command.
 You could ask someone to boot the system with keyboard attached -
 no need to type anything, though. The system should detect it
 and assingn /dev/ttyv0 as /dev/console instead of /dev/ttyd0.
 And "su" won't lock.

 Eugene Grosbein

>>>
>>>
>>> Can you see what su is doing with procstat -kk ?
>>>
>>> __**_
>>> freebsd-stable@freebsd.org mailing list
>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable
>>> To unsubscribe, send any mail to
>>> "freebsd-stable-unsubscribe@**freebsd.org
>>> "
>>>
>>
>>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Why Are You NOT Using FreeBSD ?

[Chris Rees]

On Jun 12, 2012 10:48 AM, "H"  wrote:
>
> On Monday 11 June 2012 20:59 Chuck Swiger wrote:
> > Hi, Dave--
> >
> > On Jun 11, 2012, at 4:35 PM, Dave Hayes wrote:
> > [ ... ]
> >
> > > Do I have this wrong? Anyone see a problem with this picture?
> > > What can we do to "just upgrade" in a safe fashion when we want to?
> >
> > Two things help tremendously:
> >
> > #1: Have working backups.  If you run into a problem, roll back the
> > system to a working state.  If you cannot restore a working system
> > easily, fix your backup solution until you can rollback easily.
> >
> > #2: Have a package-building box and test builds before installing
> > new package builds to other boxes.  Your downtime for upgrades
> > to the rest of your boxes become minimized.
> >
> > Regards,
>
>
> of course it helps ...
>
> but please do not forget that most people just want their desktop up to
date
> and have a working kde (or any other) environment
>
> I believe the ports tree simply must? should? be seen as it is, partially
good
> working, and partially a jorney to very dark places , depends on which
ports
> and how many  you have installed
>
> in any case it is for somebody who knows what he does and can find his
way out,
> or is courageous, a "normal desktop user" probably is not able to upgrade
kde4
> properly and ends up with an unusable machine
>
>
>
> On Monday 11 June 2012 20:20 Dave Hayes wrote:
> > Rainer Duffner  writes:
> > > Sometimes, options only make sense in context of the selection of
> > > options of other ports and it thus may no be easily explainable in one
> > > line.
> >
> > I don't understand Are you saying this is a reason not to document what
> > these options do?
>
>
> both here deepen the "lead into the dark" theory
>
>
> On Sunday 10 June 2012 14:10 O. Hartmann wrote:
> > "portmaster" does even more damage. Sometimed a port reels in some newly
> > updates, a port gets deleted. if on of the to be updated prerquisits
> > fail, the port in question isn't there anymore.
>
>
> this is caused of ports tree's install script maior logic failure, BTW by
> portmaster AND portupgrade and it happens quite often,
>
> as already commented, nobody sits in front of the screen and watch the
compile
> process so this problems go under at first sight
>
> I think, correcting this, would help a lot and may solve a lot of existing
> [hidden] problems.
>
> I see only one way, having a complete package collection for easy upgrade
>
> most of you do not like it, but you must look at the competitors, Fedoras
> upgrade system works, user do not need the newest features and none of
them
> are essential for a desktop to work properly
>
> of course the package collection needs then something similar to
portversion,
> but not based on ports tree versions, in order to find available updates
>
> who then wants to customize or learn or who dares, can use the ports tree

You have hit the nail right on the head there, and that is the intention
with pkgng.  Please feel free to have a go with it using the beta repos :)

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

Re: ULE Scheduler

[Momchil Ivanov]

At Tue, 12 Jun 2012 11:11:36 +0200 (CEST),
Oliver Fromme wrote:
> 
> ?? ??  wrote:
>  > I compiled the same kernel with the 4BSD scheduler today and it seems
>  > that the processes jump accross cores too.
> 
> What exactly is the problem that you're seeing?  Do you have
> performance problems?  If so, then they're probably *not*
> caused by processes "jumping across cores".

When my laptop said bye bye because of the heat I thougt it might be
the scheduler, which was a mistake since I got 30 C reduction on full
load after cleaning. Therefore, I don't think that there is any
problem. I was just curious why both processes are hopping around,
because I would naively think that should not happen. Note that I am
neither software nor hardware expert, but a mere user of both. I tried
the 4BSD scheduler just because Dough asked if I did. For me the
question is resolved and I thank all of you for the replies.

> Have you read Daniel Kalchev's reply in this thread?
> He explained very well why that's not a problem usually.

No, I haven't received that one.

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

Re: su problem

[Ronald Klop]

On Mon, 11 Jun 2012 15:53:34 +0200, Sami Halabi  wrote:


Hi,
I opened 2 terminals with user sody.
in first i hit "su -", and supplied password, it was stcuked.
in the other I did:

%ps xau | grep su
sody  39830  0.0  0.0  9124  1500   0  S+4:51PM   0:00.00 grep su
root  39812  0.0  0.0 21732  2088   1  I 4:49PM   0:00.00 su -
root  39813  0.0  0.0 21732  2108   1  I+4:49PM   0:00.00 su -
%procstat -kk 39812
  PIDTID COMM TDNAME   KSTACK
%procstat -kk 39813
  PIDTID COMM TDNAME   KSTACK
%



Mmmm, I'm out of options than. Maybe somebody else has a good idea.

Ronald.




Sami

On Mon, Jun 11, 2012 at 11:14 AM, Ronald Klop
wrote:


On Sat, 09 Jun 2012 18:42:27 +0200, Eugene Grosbein 
wrote:

 09.06.2012 19:47, Sami Halabi пишет:



%su -
Password:
load: 0.00  cmd: su 30588 [ttydcd] 0.91r 0.00u 0.00s 0% 2092k



Perpaps, your system had no keyboard attached at boot time;
or for some other reason it booted with /dev/console being serial  
console

instead of vidconsole. su locks trying to access serial console
that is /dev/ttyd0 by default and has Carrier Detect flag enabled.
Hence, it waits for CD on the first serial port (miserably and
hopelessly).

You can check if it's true with "sysctl kern.console" command.
You could ask someone to boot the system with keyboard attached -
no need to type anything, though. The system should detect it
and assingn /dev/ttyv0 as /dev/console instead of /dev/ttyd0.
And "su" won't lock.

Eugene Grosbein




Can you see what su is doing with procstat -kk ?

__**_
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable
To unsubscribe, send any mail to  
"freebsd-stable-unsubscribe@**freebsd.org

"





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

Re: Why Are You NOT Using FreeBSD ?

[H]

On Monday 11 June 2012 20:59 Chuck Swiger wrote:
> Hi, Dave--
> 
> On Jun 11, 2012, at 4:35 PM, Dave Hayes wrote:
> [ ... ]
> 
> > Do I have this wrong? Anyone see a problem with this picture?
> > What can we do to "just upgrade" in a safe fashion when we want to?
> 
> Two things help tremendously:
> 
> #1: Have working backups.  If you run into a problem, roll back the
> system to a working state.  If you cannot restore a working system
> easily, fix your backup solution until you can rollback easily.
> 
> #2: Have a package-building box and test builds before installing
> new package builds to other boxes.  Your downtime for upgrades
> to the rest of your boxes become minimized.
> 
> Regards,


of course it helps ...

but please do not forget that most people just want their desktop up to date 
and have a working kde (or any other) environment

I believe the ports tree simply must? should? be seen as it is, partially good 
working, and partially a jorney to very dark places , depends on which ports 
and how many  you have installed 

in any case it is for somebody who knows what he does and can find his way out, 
or is courageous, a "normal desktop user" probably is not able to upgrade kde4 
properly and ends up with an unusable machine



On Monday 11 June 2012 20:20 Dave Hayes wrote:
> Rainer Duffner  writes:
> > Sometimes, options only make sense in context of the selection of
> > options of other ports and it thus may no be easily explainable in one
> > line.
> 
> I don't understand Are you saying this is a reason not to document what
> these options do?


both here deepen the "lead into the dark" theory


On Sunday 10 June 2012 14:10 O. Hartmann wrote:
> "portmaster" does even more damage. Sometimed a port reels in some newly
> updates, a port gets deleted. if on of the to be updated prerquisits
> fail, the port in question isn't there anymore.


this is caused of ports tree's install script maior logic failure, BTW by 
portmaster AND portupgrade and it happens quite often, 

as already commented, nobody sits in front of the screen and watch the compile 
process so this problems go under at first sight

I think, correcting this, would help a lot and may solve a lot of existing 
[hidden] problems. 

I see only one way, having a complete package collection for easy upgrade

most of you do not like it, but you must look at the competitors, Fedoras 
upgrade system works, user do not need the newest features and none of them 
are essential for a desktop to work properly

of course the package collection needs then something similar to portversion, 
but not based on ports tree versions, in order to find available updates

who then wants to customize or learn or who dares, can use the ports tree

after all I guess any further effort on ports goes nowhere because it depends 
at the end on the maintainer and/or committer and people use to fail, that is 
so and nobody can change that. 

Of course It would be nice to find this "eval" behaviour of deleting 
accidentially installed ports corrected

what is worth working on is a complete package collection and a propper update 
tool for it


Hans







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

Re: ULE Scheduler

[Oliver Fromme]

?? ??  wrote:
 > I compiled the same kernel with the 4BSD scheduler today and it seems
 > that the processes jump accross cores too.

What exactly is the problem that you're seeing?  Do you have
performance problems?  If so, then they're probably *not*
caused by processes "jumping across cores".

Have you read Daniel Kalchev's reply in this thread?
He explained very well why that's not a problem usually.

Also note that top(1) only shows one snapshot every second
or two.  It does not show you the hundreds (or thousands)
of thread switches that happen every second.  In fact,
top(1) shows a very misleading picture because it creates
the wrong impression that your CPU-bound processes are
almost the only ones being scheduled on your cores.

Most of the time, people looking at top(1) see problems that
don't exist.  Another example is the amount of "free" memory
displayed by top that is often misinterpreted.

I suggest you just keep the standard scheduler (i.e. ULE).
If you don't have a performance problem (i.e. a problem that
you can measure by other means than top), then don't try to
fix it.  Chances are you make things worse.

Best regards
   Oliver


-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
-- Chris Torek
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Why Are You NOT Using FreeBSD ?

[Mark Andrews]

In message <7b6e5361-b109-498e-b22f-96a94dec3...@mac.com>, Chuck Swiger writes:
> Hi, Dave--
> 
> On Jun 11, 2012, at 4:35 PM, Dave Hayes wrote:
> [ ... ]
> > Do I have this wrong? Anyone see a problem with this picture?
> > What can we do to "just upgrade" in a safe fashion when we want to? 
> 
> Two things help tremendously:
> 
> #1: Have working backups.  If you run into a problem, roll back the
> system to a working state.  If you cannot restore a working system
> easily, fix your backup solution until you can rollback easily.
> 
> #2: Have a package-building box and test builds before installing
> new package builds to other boxes.  Your downtime for upgrades
> to the rest of your boxes become minimized.

Note: this doesn't require multiple physical systems to do.  A jail
/ chroot area will give you a perfectly fine build / test system
for ports.  It just uses a bit of disk space.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ULE Scheduler

[Lars Engels]

On Mon, Jun 11, 2012 at 09:06:26PM +0200,   wrote:
> At Sat, 09 Jun 2012 20:23:44 -0700,
> Doug Barton wrote:
> > 
> > On 06/06/2012 18:16, Doug Barton wrote:
> > > On 06/06/2012 18:01,   wrote:
> > >> Is there some remedy?
> > > 
> > > Try the 4BSD scheduler.
> > 
> > Did you ever try this? Did it help?
> 
> I compiled the same kernel with the 4BSD scheduler today and it seems
> that the processes jump accross cores too. My "eye" measure with "top"
> fells like it's more stable and probably converges faster to a stable
> state after "top" jumps accross cores. But in order to talk with
> numbers, I need to replace "top" with somethings that dumps the
> process number and the cpu id continuously in order to get some
> statistics out of it, otherwise you can just forget all the things
> that I have written. Is there an easy way to do that and are you
> interested?

Maybe sysutils/atop is useful here?


pgptC22WWH1mW.pgp
Description: PGP signature