LOR & kernel trap
I am build freebsd-current w/ cvs snap on 2003.11.11
and have some problem:
1. LOR
lock order reversal
1st 0xc1b05690 rtentry (rtentry) @ /usr/src/sys/net/rtsock.c:388
2nd 0xc15e187c radix node head (radix node head) @ /usr/src/sys/net/route.c:1114
Stack backtrace:
backtrace(c06126bc,c15e187c,c061775a,c061775a,c06177b0) at backtrace+0x17
witness_lock(c15e187c,8,c06177b0,45a,1) at witness_lock+0x672
_mtx_lock_flags(c15e187c,0,c06177b0,45a,c1b05690) at _mtx_lock_flags+0xba
rt_setgate(c1b05600,c1ad6440,c1b05b78,185,0) at rt_setgate+0x3b8
route_output(c0e11500,c16fc550,b0,c0e11500,1f50) at route_output+0x6aa
raw_usend(c16fc550,0,c0e11500,0,0) at raw_usend+0x73
rts_send(c16fc550,0,c0e11500,0,0) at rts_send+0x35
sosend(c16fc550,0,c6a8bc7c,c0e11500,0) at sosend+0x44d
soo_write(c1a01c38,c6a8bc7c,c1b74780,0,c1afd000) at soo_write+0x70
dofilewrite(c1afd000,c1a01c38,8,bfbfe870,b0) at dofilewrite+0xf8
write(c1afd000,c6a8bd10,c062c0e1,3ee,3) at write+0x6e
syscall(2f,2f,2f,8,3) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4), eip = 0x28283c2f, esp = 0xbfbfe65c, ebp = 0xbfbfe688 ---
2. kernel trap
cpuid = 0 acic id = 00
ip 0x8:0xc04955ed
sp 0x10:0xc6a8babc
fp 0x10:0xc6a8bac0
code segment base 0 limit f type 0x1b DPL 0 pres 1 def32 1 gran 1
eflags interrupt enabled IOPL = 0
current process 562 (ppp)
kernel: type 30 trap, code = 0
stopet at critical_exit+0x2d: jmp critical_exit+0x36
gdb -k /.1/obj/usr/src/sys/SLW/kernel.debug
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
(kgdb) l *0xc04955ed
0xc04955ed is in critical_exit (machine/cpufunc.h:358).
353 }
354
355 static __inline void
356 write_eflags(u_int ef)
357 {
358 __asm __volatile("pushl %0; popfl" : : "r" (ef));
359 }
360
361 static __inline void
362 wrmsr(u_int msr, u_int64_t newval)
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR & kernel trap
> > I am build freebsd-current w/ cvs snap on 2003.11.11 > > and have some problem: > > > > 2. kernel trap > > > > cpuid = 0 acic id = 00 > > This has been fixed in later snaps. Thanks, I now try 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Fri Nov 21 23:12:09 MSK 2003. This trap seems fixed. And I now see 'kernel: stray irq7' -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
> If you want access to fetch early on in this way, you could make a local > branch and maintain the change for your own site, or you could boot from > a FreeBSD live CD, or use sysinstall from the installation CD to install > a package. I don't see fetch as a requirement for diskless clients. Wrong. Not diskless. Simple w/o CD, DVD, FDC. Only HDD. -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
psmintr not attached w/ acpi
If acpi enabled PS/2 mouse failed to work and irq12 cold't attach
to psmintr.
Is this problem "reporting PS/2 mouse resource before atkbdc"?
psmcpnp0 irq 12 on acpi0
atkbdc0: port 0x64,0x60 irq 1 on acpi0
atkbd0: flags 0x1 irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0047
atkbd: keyboard ID 0x41ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d
psm0: current command byte:0047
psm0: irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3-00, 3 buttons
psm0: config:, flags:, packet size:4
psm0: syncmask:08, syncbits:08
vmstat -i
interrupt total rate
irq0: clk 64245 99
irq1: atkbd0 1 0
irq8: rtc 82235127
irq11: xl0 uhci0+737 1
irq13: npx01 0
irq14: ata0 2411 3
irq15: ata1 52 0
Total 149682232
Device (PS2M)
{
Name (_HID, EisaId ("PNP0F13"))
Method (_STA, 0, NotSerialized)
{
If (LEqual (PS2F, 0x00))
{
Return (0x0F)
}
Else
{
Return (0x00)
}
}
Method (_CRS, 0, NotSerialized)
{
Name (BUF1, Buffer (0x05)
{
0x22, 0x00, 0x10, 0x79, 0x00
})
Name (BUF2, Buffer (0x15)
{
0x47, 0x01, 0x60, 0x00, 0x60, 0x00, 0x01, 0x01,
0x47, 0x01, 0x64, 0x00, 0x64, 0x00, 0x01, 0x01,
0x22, 0x00, 0x10, 0x79, 0x00
})
If (LEqual (KBDI, 0x01))
{
Return (BUF2)
}
Else
{
Return (BUF1)
}
}
}
Device (PS2K)
{
Name (_HID, EisaId ("PNP0303"))
Method (_STA, 0, NotSerialized)
{
If (LEqual (KBDI, 0x01))
{
Return (0x00)
}
Else
{
Return (0x0F)
}
}
Name (_CRS, Buffer (0x15)
{
0x47, 0x01, 0x60, 0x00, 0x60, 0x00, 0x01, 0x01,
0x47, 0x01, 0x64, 0x00, 0x64, 0x00, 0x01, 0x01,
0x22, 0x02, 0x00, 0x79, 0x00
})
}
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: psmintr not attached w/ acpi
On Mon, Dec 01, 2003 at 09:48:40AM -0800, Nate Lawson wrote: > Your ASL indicates that it returns different values for present (based on > PS2F) and current resources (based on KBDI). Please send me the URL to > the full ASL so I can see what sets those two variables. http://zxy.spb.ru/acpi.dump Do you need additional information? -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: psmintr not attached w/ acpi
On Mon, Dec 01, 2003 at 10:59:49AM -0800, Nate Lawson wrote:
> > On Mon, Dec 01, 2003 at 09:48:40AM -0800, Nate Lawson wrote:
> > > Your ASL indicates that it returns different values for present (based on
> > > PS2F) and current resources (based on KBDI). Please send me the URL to
> > > the full ASL so I can see what sets those two variables.
> >
> > http://zxy.spb.ru/acpi.dump
> >
> > Do you need additional information?
>
> Try this workaround, recompile your asl, set dsdt_load in loader.conf.
> See acpi(4) if you need info on this process. I think your BIOS needs a
> workaround. I wonder if the MS interpreter ignores _STA for some devices.
I try recompile asl and got some errors:
===
iasl acpi.dump
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030619 [Nov 25 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
acpi.dump84: And (SUSF, 0x02, STAT)
Error1037 -^ syntax error
ASL Input: acpi.dump - 3574 lines, 113232 bytes, 12 keywords
Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 9 Optimizations
===
I commented out this line and try again.
===
iasl acpi.dump
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030619 [Nov 25 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
acpi.dump 352: Method (\_WAK, 1, NotSerialized)
Warning 2026 - ^ Reserved method must return a value (_WAK)
acpi.dump 382: Store (Local0, Local0)
Error1013 - ^ Method local variable is not initialized
(Local0)
acpi.dump 387: Store (Local0, Local0)
Error1013 - ^ Method local variable is not initialized
(Local0)
acpi.dump 1609: ICF0, 2,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1610: ICF1, 2,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1612: WPPE, 1,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1614: FAS0, 2,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1615: FAS1, 2
Error1051 - ^ Access width of Field Unit extends beyond
region limit
ASL Input: acpi.dump - 3850 lines, 119353 bytes, 1690 keywords
Compilation complete. 7 Errors, 1 Warnings, 0 Remarks, 345 Optimizations
===
What is wrong?
> --- slawa-IntelLaptop.asl.origMon Dec 1 10:54:18 2003
> +++ slawa-IntelLaptop.asl Mon Dec 1 10:57:39 2003
> @@ -3353,14 +3353,7 @@
> Name (_HID, EisaId ("PNP0F13"))
> Method (_STA, 0, NotSerialized)
> {
> -If (LEqual (PS2F, 0x00))
> -{
> Return (0x0F)
> -}
> -Else
> -{
> -Return (0x00)
> - }
> }
>
> Method (_CRS, 0, NotSerialized)
>
> -Nate
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A page fault in subr_turnstile.c:propogate_priority()
On Wed, Dec 03, 2003 at 05:43:13PM +0300, Igor Sysoev wrote:
> panic: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address = 0xe5
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc053f197
> stack pointer = 0x10:0xe3c21c80
> frame pointer = 0x10:0xe3c21ca0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = 42 (irq29: ahd0)
> trap number = 12
> panic: page fault
> cpuid = 2;
> boot() called on cpu#2
>
> syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue
> cpuid = 2;
> boot() called on cpu#2
> Uptime: 1d2h4m15s
> Dumping 2047 MB
> jmp0xc053f2b2
> 0xc053f187 :cmp(%edi),%ebx
> 0xc053f189 :
> je 0xc053f290
> 0xc053f18f :mov0x24(%ebx),%eax
> 0xc053f192 :mov0x4(%eax),%eax
> 0xc053f195 :mov(%eax),%edx
>
> [ FAULT ]
>
/usr/src/sys/kern/subr_turnstile.c:256
td1 = TAILQ_PREV(td, threadqueue, td_lockq);
if (td1->td_priority <= pri) {
mtx_unlock_spin(&tc->tc_lock);
continue;
}
> 0xc053f197 :movzbl 0xe5(%edx),%eax
> 0xc053f19e :cmp0xfff0(%ebp),%eax
> 0xc053f1a1 :
> jle0xc053f290
> 0xc053f1a7 :call 0xc051e650
> 0xc053f1ac :mov%fs:0x0,%edx
> 0xc053f1b3 :mov$0x4,%eax
> 0xc053f1b8 :lock cmpxchg %edx,0xc06ac7fc
> 0xc053f1c0 :sete %al
> 0xc053f1c3 : movzbl %al,%eax
> 0xc053f1c6 :test %eax,%eax
> 0xc053f1c8 :
> jne0xc053f210
> 0xc053f1ca :mov%fs:0x0,%edx
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is 4k desktop possible on freebsd-12?
On Wed, Oct 10, 2018 at 11:17:03AM +0100, tech-lists wrote: > > so would this indicate the card is 4k capable but the HDMI port on the > card is not? Or the port on the monitor? Or something else? for 4K@60FPS you need DP connection. ___ 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: is 4k desktop possible on freebsd-12?
On Wed, Oct 10, 2018 at 02:57:39PM +0100, tech-lists wrote: > On 10/10/2018 13:45, Slawa Olhovchenkov wrote: > > for 4K@60FPS you need DP connection. > > problem is monitor only has HDMI. I'm not sure it'll 4k@30fps is an > acceptable mode for it; need to check You need check HDMI 2.0 available on video card and monitor. For HDMI 1.4 you need check of support both card and monitor support 4K@24. ___ 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: leaked swap?
On Mon, Mar 18, 2019 at 11:00:10PM +0200, Andriy Gapon wrote: > On 18/03/2019 20:01, Andrey Fesenko wrote: > > Not this? ZFS use wired and not clean only reboot? > > https://reviews.freebsd.org/D7538?id=25108 > > Wired memory surely has nothing to do with swap. Wired memory can pressure to swapable memory ___ 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: leaked swap?
On Tue, Mar 19, 2019 at 04:07:45PM +0200, Andriy Gapon wrote: > On 19/03/2019 15:02, Slawa Olhovchenkov wrote: > > On Mon, Mar 18, 2019 at 11:00:10PM +0200, Andriy Gapon wrote: > > > >> On 18/03/2019 20:01, Andrey Fesenko wrote: > >>> Not this? ZFS use wired and not clean only reboot? > >>> https://reviews.freebsd.org/D7538?id=25108 > >> > >> Wired memory surely has nothing to do with swap. > > > > Wired memory can pressure to swapable memory > > > > Yes, it can. But I am interested in what is in the swap. Not what caused it > to > go to the swap. procstat -v -a | awk '$10 == "sw"' ? ___ 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: Lockdown adaX numbers to allow booting ?
On Thu, Sep 19, 2019 at 06:04:54PM +0200, Michael Gmelin wrote: > > > > On 19. Sep 2019, at 17:57, Kurt Jaeger wrote: > > > > Hi! > > > >>> We have a system with 10 SATA disks. 2 disks are for the system, > >>> 8 disks drive a data pool 'bck', configured as raidz2, for backup > >>> purposes: > >>> > >>> bck72.8T 38.7T 34.1T- - 1%53% 1.00x > >>> ONLINE - > > > >>> The problem is that if all 10 disks are connected, the system > >>> looses track from where it should boot and fails to boot (serial boot > >>> log): > > > >> Why this order does change? One would expect disks 0 and 1 to be OS disks > >> and the rest for data??? > > > > 0+1 are 2.5", and the initial setup was: > > - we installed system disks as zroot > > - shipped the box to the housing facility > > - booted and added the drives > > > > At that time we did not do additional tests about the disk/boot sequence > > etc. > > > >> Also the question is, what you mean with ???system looses track > > > > I interpret the hang during boot as 'it looses track'. So I guess > > it tries to read the kernel from the wrong drives. > > > >> disk4 becomes adaX? why it matters, are you using ufs on boot disks? > > > > No, zpool only. > > > > I've made a few more details available here: > > > > https://people.freebsd.org/~pi/host/dmesg.txt > > https://people.freebsd.org/~pi/host/devlist.txt > > https://people.freebsd.org/~pi/host/gpart.txt > > https://people.freebsd.org/~pi/host/pciconf.txt > > https://people.freebsd.org/~pi/host/zpool.txt > > What about gpart output of the pool drives? > > In general you would create zpools using gptids or gpt labels, not the > devices, so you’re independent of device numbering. The boot loader should > only be installed on drives that contain the boot pool (maybe you have old > boot loaders on data drives?). ZFS work w/ ZFS labels, not w/ device names/gptids/gpt labels. You don't worry about changed device names aroud reboots. ___ 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: Lockdown adaX numbers to allow booting ?
On Fri, Sep 20, 2019 at 08:29:08AM -0700, Freddie Cash wrote: > On Fri, Sep 20, 2019 at 7:35 AM Slawa Olhovchenkov wrote: > > > On Thu, Sep 19, 2019 at 06:04:54PM +0200, Michael Gmelin wrote: > > > What about gpart output of the pool drives? > > > > > > In general you would create zpools using gptids or gpt labels, not the > > devices, so you’re independent of device numbering. The boot loader should > > only be installed on drives that contain the boot pool (maybe you have old > > boot loaders on data drives?). > > > > ZFS work w/ ZFS labels, not w/ device names/gptids/gpt labels. > > You don't worry about changed device names aroud reboots. > > > > Very true, from ZFS' point of view. It writes a ZFS label to whichever > GEOM provider you hand it (file, iSCSI device, raw device, MBR partition, > GPT partition, etc), and it will find it's pool members based on those > labels. ZFS doesn't care where the device is physically connected in the > system, just that it is connected. > > But the ZFS labels aren't what it will display in "zpool list -v" or "zpool > status" output. That will show the GEOM provider you gave it (and, > depending on the order that GEOM tastes the devices, and what's > enabled/disabled in loader.conf, that output can change). That's where > it's useful to have human-readable, descriptive labels (like GPT partition > labels), and to disable all the GEOM ID systems you won't be using via > loader.conf. So that when things go sideways, and a disk dies, you can > find it quickly and easily. Much easier to replace "gpt/jbod3-a6" in a > multi-chassis storage system with 100+ drives than to figure out which bay > corresponds to "ada73" after a couple of reboots that may or may not have > changed the PCI bus enumeration direction, or after replacing an HBA that Location of device in multi-chassis storage system is different story. I am don't know how to field engineer insert disks in chassis. For me simple is find in /var/run/dmesg.boot S/N <=> daXY mapping and turn ON led by sas2ircu. > enumerates drives a different way (da vs ada), or after a BIOS/EFI upgrade > that renumbers things, or any other number of situations. (We've run into > most of these, and have come to rely on GPT partition labels for just this > reason; and we stick the drive serial number on the outside of the bay, > just in case). > It's not a ZFS requirement. It just makes things easier for the admin down > the road. Especially if the admin team changes or inherits systems. :) This is need many manual work at setup and build time. DC field engineer make servers for me and don't do this work for me. ___ 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: Lockdown adaX numbers to allow booting ?
On Fri, Sep 20, 2019 at 01:06:29PM -0400, Garrett Wollman wrote: > In article <20190920155304.gn3...@zxy.spb.ru>, s...@zxy.spb.ru writes: > > >Location of device in multi-chassis storage system is different story. > >I am don't know how to field engineer insert disks in chassis. > >For me simple is find in /var/run/dmesg.boot S/N <=> daXY mapping and > >turn ON led by sas2ircu. > > sesutil does this for you! > > # sesutil locate daXY on > # sesutil locate daXY off > > So long as your enclosure supports SES (all the modern ones I've seen > do) and is enumerable by ses(4). In theory there is no difference between theory and practice. But, in practice, there is. # sesutil map ses0: Enclosure Name: AHCI SGPIO Enclosure Enclosure ID:0 Element 0, Type: Array Device Slot Status: Unsupported (0x00 0x00 0x00 0x00) Element 1, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 000 Element 2, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 001 Element 3, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 002 Element 4, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 003 ses1: Enclosure Name: AHCI SGPIO Enclosure Enclosure ID:0 Element 0, Type: Array Device Slot Status: Unsupported (0x00 0x00 0x00 0x00) Element 1, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 000 Element 2, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 001 Element 3, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 002 Element 4, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 003 Element 5, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 004 Element 6, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 005 # sesutil locate ada0 on sesutil: Count not find the SES id of device 'ada0' # sesutil locate da0 on sesutil: Count not find the SES id of device 'da0' # sas2ircu 0 DISPLAY LSI Corporation SAS2 IR Configuration Utility. Version 20.00.00.00 (2014.09.18) Copyright (c) 2008-2014 LSI Corporation. All rights reserved. Read configuration has been initiated for controller 0 Controller information Controller type : SAS2308_1 BIOS version: 7.39.02.00 Firmware version: 20.00.07.00 Channel description : 1 Serial Attached SCSI Initiator ID: 0 Maximum physical devices: 255 Concurrent commands supported : 8192 Slot: 1 Segment : 0 Bus : 1 Device : 0 Function: 0 RAID Support: No IR Volume information Physical device information Initiator at ID #0 Device is a Hard disk Enclosure # : 1 Slot # : 0 SAS Address : 4433221-1-0300- State : Ready (RDY) Size (in MB)/(in sectors) : 7630885/15628053167 Manufacturer: ATA Model Number: TOSHIBA HDWN180 Firmware Revision : GX2M Serial No : 79HSK0PHFAVG GUID: N/A Protocol: SATA Drive Type : SATA_HDD Device is a Hard disk Enclosure # : 1 Slot # : 1 SAS Address : 4433221-1-0200- State : Ready (RDY) Size (in MB)/(in sectors) : 7630885/15628053167 Manufacturer: ATA
Re: [CURRENT] hostapd: WPA w/ EAP-TTLS or EAP-PEAP or EAP-TLS ?
On Fri, Oct 03, 2014 at 03:14:53PM +0200, O. Hartmann wrote: > > Where is the support on WPA with EAP-TTLS or EAP-PEAP or EAP-TLS in hostapd? > > Trying to circumvent FreeBSD's very poor documentation on the options of > hostapd, I found > lots of howtos for Linuxes of different flavours utilizing obviously the same > hostapd > basis. But whenever I try to configure one of the above mentioned auth > methods for a > gateway I try to configure (CURRENT, 10.1-PRE), I get an error. > > What is up here? You need to recompile source. And patching some Makefiles, AFAIR. ___ 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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote:
> Hi all,
>
> We are starting the release process of pkg 1.4, we want to have a better
> release
> process than with every single previous version of pkg. For that we will need
> you help!
I have issuse, but I am not test on 1.4.
I upgrade php (5.5.15 -> 5.5.17), pecl-memcache don't change version.
pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-memcache).
> pkg-devel has been updated to the latest version of pkg as of alpha2.
>
> Changes you can expect in pkg 1.4 are the following:
> - Loads of bug fixes
> - Stricter checking of the path passed via the plist
> - Removal of the bundled libyaml
> - new --raw-format to chose the output format for info -R and search -R
> - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10:amd64)
> the old ABI is available as a fallback in ALTABI
linux packages still freebsd:10:x86:32 ?
> - pkg check now support a quiet mode
> - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging
> configuration files
> - new @config keyword to mark a file as a config file (during
> upgrade/reinstallation it will try to merge the configuration with the one
> the
> user may have modified) an option AUTOMERGE is available to prevent
> automerging if automerge fails a .pkgnew file will be created along with the
> untouched user version of the configuration
> - The update procedure has been improved and speed up a lot (in particular for
> machine with low resources)
> - The unique identifier has been modified to be pkgname meaning now ports can
> be
> moved in new categories without having to be considered a different package
> - Only libraries starting by lib* are added to the provided libraries
> - General speed up of all operations
>
> We need help in testing, but we also need help in writing regression tests !
> The more we have tests the more stable the releases will be.
>
> The release will also allow to be able to package base!
>
> regards,
> Bapt
___
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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 01:24:52PM +0100, Baptiste Daroussin wrote:
> On Wed, Oct 29, 2014 at 04:13:26PM +0400, Slawa Olhovchenkov wrote:
> > On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote:
> >
> > > Hi all,
> > >
> > > We are starting the release process of pkg 1.4, we want to have a better
> > > release
> > > process than with every single previous version of pkg. For that we will
> > > need
> > > you help!
> >
> > I have issuse, but I am not test on 1.4.
> > I upgrade php (5.5.15 -> 5.5.17), pecl-memcache don't change version.
> > pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-memcache).
>
> This is a problem with the port infrastructure for pecl
What problem?
deps: {
php55-session: {
origin: "www/php55-session",
version: "5.5.17_1"
},
php55: {
origin: "lang/php55",
version: "5.5.17_1"
},
php55-zlib: {
origin: "archivers/php55-zlib",
version: "5.5.17_1"
}
}
> > > pkg-devel has been updated to the latest version of pkg as of alpha2.
> > >
> > > Changes you can expect in pkg 1.4 are the following:
> > > - Loads of bug fixes
> > > - Stricter checking of the path passed via the plist
> > > - Removal of the bundled libyaml
> > > - new --raw-format to chose the output format for info -R and search -R
> > > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become
> > > FreeBSD:10:amd64)
> > > the old ABI is available as a fallback in ALTABI
> >
> > linux packages still freebsd:10:x86:32 ?
>
> Yes for now, we plan to change that later.
>
> regards,
> Bapt
___
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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 01:40:25PM +0100, Baptiste Daroussin wrote:
> On Wed, Oct 29, 2014 at 04:31:57PM +0400, Slawa Olhovchenkov wrote:
> > On Wed, Oct 29, 2014 at 01:24:52PM +0100, Baptiste Daroussin wrote:
> >
> > > On Wed, Oct 29, 2014 at 04:13:26PM +0400, Slawa Olhovchenkov wrote:
> > > > On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > We are starting the release process of pkg 1.4, we want to have a
> > > > > better release
> > > > > process than with every single previous version of pkg. For that we
> > > > > will need
> > > > > you help!
> > > >
> > > > I have issuse, but I am not test on 1.4.
> > > > I upgrade php (5.5.15 -> 5.5.17), pecl-memcache don't change version.
> > > > pkg uprgade don't reinstall pecl-memcache (pourdure rebuild
> > > > pecl-memcache).
> > >
> > > This is a problem with the port infrastructure for pecl
> >
> > What problem?
> >
> > deps: {
> > php55-session: {
> > origin: "www/php55-session",
> > version: "5.5.17_1"
> > },
> > php55: {
> > origin: "lang/php55",
> > version: "5.5.17_1"
> > },
> > php55-zlib: {
> > origin: "archivers/php55-zlib",
> > version: "5.5.17_1"
> > }
> > }
> >
> How can we know pecl-memcache has to be reinstalled?
>
> We won't reinstall each time a version of a dep changes :)
And what is solution?
May be some flag on package (php) for reinstall all deps?
___
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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 01:53:04PM +0100, Baptiste Daroussin wrote: > > > How can we know pecl-memcache has to be reinstalled? > > > > > > We won't reinstall each time a version of a dep changes :) > > > > And what is solution? > > May be some flag on package (php) for reinstall all deps? > > I do have no idea, I'm open for suggestions :) > Either on the package side with triggers but that means implementing trigger > in > package > Or in package side with provide/requires saying that this packages requires an > exact version of php meaning in case of upgrade of php the version would have > changed May be (as workaround) some database witch this packages? List, or regexp. This is need for some binary modules and don't need for "text" modules. But for some cases -- and for "text" modules too. > Or someone has to be clever and find a ports only solution. On ports side pecl-memcache rebuild on php version changed. > Why the help does a minor version has an inpact on the pecl? isn't the abi > stable over minor versions? I am don't know -- I am not php guru. As result -- memcache module don't loaded and "class Memcache not found". May be just strict version check. ___ 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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 03:07:14PM +0100, Baptiste Daroussin wrote: > > > Why the help does a minor version has an inpact on the pecl? isn't the abi > > > stable over minor versions? > > > > I am don't know -- I am not php guru. > > As result -- memcache module don't loaded and "class Memcache not > > found". > > May be just strict version check. > > > > From what I do read from here: > https://wiki.php.net/rfc/releaseprocess#releases_cycle > > only going from X.Y to X.Y+1 needs to rebuild the extensions. > and going from X.Y.Z to X.Y.Z+1 should be compatible I don't know. May be this is specific only for pecl-memcache. May be reinstalling php lost information about installed extensions. ___ 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"
systat -ifstat on high-speed links
I am try to use 'systat -ifstat 1' when traffic over network intrface about 35Gbit. systat show about 2.5Gbit. Where is problem? ___ 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: systat -ifstat on high-speed links
On Mon, Nov 03, 2014 at 11:58:56AM -0500, Ryan Stone wrote: > http://svnweb.freebsd.org/changeset/base/272284 Date: Mon Sep 29 17:38:50 2014 UTC (4 weeks, 6 days ago) MFC after: 1 week MFC stoped? ___ 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: netmap: extension to store user data per packet/slot?
On Tue, Nov 11, 2014 at 10:13:54PM +0100, Franco Fichtner wrote:
> Hi Luigi,
> hi all,
>
> so I was running into logistics issues with netmap(4)
> with regard to zero-copy and redirection through pipes:
> working on a load-balancing framework revealed that it
> is very hard to track a packet's origins to later move
> it onward to the respective outgoing interface, be it
> another device or the host stack.
>
> Long story short: user data needs to be stored for the
> packet buffer or slot.
I think need configurable (by sysctl) space recerved before packet.
This is may be used as user data. Or for insert VLAN/MPLS/QinQ/etc
headers.
More general: tilera have good api for this.
> There are three ways that I can see so far:
>
> (1) Allocate a netmap pipe pair for each interface,
> in case of transparent mode also a pipe for the
> host stack each. That's a lot of pipes and
> most likely insane, but it won't extend the ABI.
>
> (2) Store the additional data in the actual buffer.
> That is sort of ok, but seems sluggish WRT cache
> behaviour -- maybe the buffer won't be read but
> it needs to be written. Sure, we can store it at
> the end, but there already resides the packet
> timestamp if enabled (if I recall correctly).
> Wouldn't extend the ABI per se, but might collide
> with the timestamping
>
> (3) Make room in struct netmap_slot itself like this:
>
> diff --git a/sys/net/netmap.h b/sys/net/netmap.h
> index 15ebf73..d0a9c0e 100644
> --- a/sys/net/netmap.h
> +++ b/sys/net/netmap.h
> @@ -147,6 +147,7 @@ struct netmap_slot {
> uint16_t len; /* length for this slot */
> uint16_t flags; /* buf changed, etc. */
> uint64_t ptr; /* pointer for indirect buffers */
> + uint64_t userdata; /* reserved storage for caller */
> };
>
> It could also be broken down in two fields with uint32_t
> each; not sure what would be more sensible. This of course
> requires an API bump, although it should be backwards
> compatible.
>
> Any feedback on this is highly appreciated.
>
>
> Cheers,
> Franco
> ___
> 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"
Re: simple task to speed up booting
On Sun, Dec 14, 2014 at 07:52:11AM -0700, Ian Lepore wrote:
> On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
> > The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
> > large part of our boot time on systems with slow-ish serial consoles.
> >
> > I think right now it takes a step for each 512 byte read, reducing that
> > to once every 64kB or even 1MB would be an improvement with the kind of
> > kernel sizes we have today.
> >
>
> I experimented with that a while ago using the attached patch and was
> disappointed with the results. As I vaguely remember it, a divisor of 8
> looked fine, but had no significant speedup. With a divisor of 32 the
> difference was measureable (only like 1.5 seconds or so faster), but it
> gave the impression that something was wrong, and the overall perception
> was that it was slower rather than faster, despite what a stopwatch
> said.
>
> I was testing at 115kbps, maybe at 9600 it would be significant. I
> don't understand why anything these days is still defaulting to 9600.
> It's the 21st century, but we never got the George Jetson flying cars we
> were promised, and apparently we're never going to break loose from the
> standards set by accoustic-coupled modems.
You not always working with self-owned servers.
Default is 9600,8n1
___
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: any primer on running bhyve guests sharing disk with host ?
On Sat, Jan 03, 2015 at 05:15:11PM +0100, Luigi Rizzo wrote: > Hi, > in order to do some kernel testing, I would like to run bhyve guests > using (through NFS, probably) the host's file system. > diskless(8) is probably one way to go, i was wondering if > someone has instructions for that. > Specifically: > - how to "bhyveload" a kernel (rather than the full disk image); > as an alternative, given a kernel, something to build an image > that can be passed to bhyveload > > - how to pass the necessary config (rootpath) to the client > without having to rely on a specialized dhcp server > > I used to be familiar with diskless configs, so i can probably sort > out the server side myself. May be I missunderstand you, but diskless client-specific config relay on client IP address (ex: /conf/ip/1.2.3.4/...). Also, diskless boot relay on BIOS network support (by PXE, for example), with working NIC, assigned IP address and etc. ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: > On 01/14/15 15:31, Hans Petter Selasky wrote: > > On 01/11/15 19:08, Jason Wolfe wrote: > >> Hans, > >> > >> We've had 50 machines running 10.1-STABLE with this patch for the > >> better part of a week without issue. Prior we would have seen a panic > >> every few days at the least, so things are looking very promising on > >> our front. > >> > >> Jason > > > > Hi, > > > > I've updated D1438 including the manual page changes needed for > > timeout.9 aswell in addition to a minor fix for those using timeout() > > and untimeout() and KTR(). > > > > https://reviews.freebsd.org/D1438 > > > > --HPS > > FYI: > > Now in -current: > > https://svnweb.freebsd.org/changeset/base/277213 > > Thanks for all good comments and reviews. Only stability impovement? Or performance 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"
Re: DigitalOcean offers VMs with FreeBSD!
On Thu, Jan 15, 2015 at 06:28:23PM +0300, Lev Serebryakov wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 15.01.2015 14:29, Lev Serebryakov wrote: > > > https://www.digitalocean.com/company/blog/presenting-freebsd-how-we-made-it-happen/ > > > > I didn't see this news on mailing lists :) > But here are some thread about FreeBSD is way slower than Linux in > these virtual installations > > https://news.ycombinator.com/item?id=487 May be IOPS quotation? Can you test with dd and custom kernel with MAXPHYS=1048576 ? ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Thu, Jan 15, 2015 at 04:51:00PM +0100, Hans Petter Selasky wrote: > On 01/15/15 16:46, Slawa Olhovchenkov wrote: > > On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: > > > > Only stability impovement? > > Or performance too? > > Hi, > > Stability improvement mostly. Should not affect performance from what I > know. Some changes are made about when and how we can select a different > callback CPU for a callout callback. Try reading the updated timeout(9) I am not kernel guru and can't be draw a conclusion from manual page. > man manual page first. Maybe it answers your question. Else feel free to > ask here. As I understand performance for massive TCP connections (tens of thousands connections) will be same, no improvement, no degraded? (very high lock congestion on TCP timers working). ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Thu, Jan 15, 2015 at 05:42:36PM +0100, Hans Petter Selasky wrote: > On 01/15/15 16:58, Slawa Olhovchenkov wrote: > > On Thu, Jan 15, 2015 at 04:51:00PM +0100, Hans Petter Selasky wrote: > > > >> On 01/15/15 16:46, Slawa Olhovchenkov wrote: > >>> On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: > >>> > >>> Only stability impovement? > >>> Or performance too? > >> > >> Hi, > >> > >> Stability improvement mostly. Should not affect performance from what I > >> know. Some changes are made about when and how we can select a different > >> callback CPU for a callout callback. Try reading the updated timeout(9) > > > > I am not kernel guru and can't be draw a conclusion from manual page. > > > >> man manual page first. Maybe it answers your question. Else feel free to > >> ask here. > > > > As I understand performance for massive TCP connections (tens of > > thousands connections) will be same, no improvement, no degraded? > > (very high lock congestion on TCP timers working). > > Hi, > > There is no difference in memory footprint per TCP connection. > > There is no significant different in the amount of code executed when a > callout is started/stopped or reset. > > There might be a reduction in the number of times the spinlocks inside > the callout subsystem are locked/unlocked, due to some simplifications > made and checks for redundant locking. > > The changes are mainly about closing some races in the callout subsystem > and cornercases towards the TCP/IP stack which use callouts. > > There is a patch for the TCP/IP stack coming possibly next week to take > advantage of the new callout_drain_async() function. It is not ready > yet, and I'm waiting for the current callout patch to settle first. Thanks. I am going to try this patch in 10-STABLE branch. ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: > On 01/17/15 23:18, Hans Petter Selasky wrote: > > On 01/17/15 20:11, Jason Wolfe wrote: > >> > >> HPS, > >> > >> Just to give a quick status update, this patch has most certainly > >> resolved our spin lock held too long panics on stable/10. > >> > >> Thank you to JHB for spending some time digging into the issue and > >> leading us to td_slpcallout as the culprit, and HPS for your rewrite. > >> I had heard rumors of other being affected by similar issues, so this > >> seems like a fine candidate for an MFC if possible. > >> > >> Jason > >> > > > > Hi Jason, > > > > I'm glad to hear that my patch has resolved your issue and I'm happy we > > now have a more stable system. > > > > It was actually a co-worker at work which wrote some bad code which I > > started debugging which then lead me to look at the callout subsystem. > > One bug kills the other ;-) > > > > I'm planning a MFC to 10-stable - yes, and will possibly add the > > _callout_stop_safe() function to not break binary compatibility with > > existing drivers as part of the MFC. > > > > --HPS > > Hi, > > Here is a followup patch for the TCP stack like I mentioned in the > beginning of the work done on the callout subsystem: > > https://reviews.freebsd.org/D1563 > > If someone has a setup for massive TCP testing please give it a spin. I have on 10.1 (with applied r261906). ___ 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: tzsetup - UTC user question
On Tue, Feb 03, 2015 at 03:08:38PM +1000, Paul Koch wrote: > > Since the default option for "Select local or UTC clock" changed from > "No" to "Yes", we are seeing many customers who incorrectly answer this > question! > > This screws up things in our app because we store all data in UTC. > > A few observations... > > Most people don't know what "CMOS clock" is. Maybe change the wording > to "BIOS clock" or "Hardware Clock" ?? > > The person doing the install may not know what the clock is currently set > to, especially when installing in a VM. Perhaps the screen should display > the current machine time so they can correctly answer the question. > > Why was the default changed from "No" to "Yes" ? or change ntpd_sync_on_start="YES" to force correct time. in most case for hardware platform CMOS time contains garbage. ___ 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: Dual booting FreeBSD and Win95
On Wed, Apr 08, 2015 at 03:30:41PM -0400, Ryan Stone wrote: > No, this isn't a late April Fools joke. :( > > I find myself in a situation where I need to integrate my employer's > manufacturing process with a third-party OEM's process. My employer's > hardware tests are all FreeBSD-based while the OEM is Windows 95 based. I > need to come up with a way to integrate them together. > > We're looking at dual-booting FreeBSD and Win95. We're thinking of booting > into Win95, the OEM can do their thing, switch to booting FreeBSD, run our > tests and produce a .csv file with the results, and then boot back into > Win95 for them to finish up. Ideally we would like to switch the boot > slice without human interaction. > > I've been playing around with trying to set one only slice as active to > make the loader boot it, but it appears that doesn't actually work. > boot0cfg would cover half of the use case (switching from FreeBSD back to > Win95), but I'm not sure how I could do the original switch from Win95 to > FreeBSD. > > We've discussed just switching hard drives, but we really want to shoot for > a 100% automated process. Anybody have any ideas? If hardware recognised by Win95 do next: 1. create MBR patition table. first patition dedicate to Win95. next partiton to freebsd 2. install Win95 3. Install FreeBSD with FreeBSD boot manager. 4. (optional) create windows95 boot.ini for fail back load FreeBSD ___ 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: Dual booting FreeBSD and Win95
On Wed, Apr 08, 2015 at 08:09:42PM +, Marcin Cieslak wrote: > On Wed, 8 Apr 2015, Slawa Olhovchenkov wrote: > > > On Wed, Apr 08, 2015 at 03:30:41PM -0400, Ryan Stone wrote: > > 4. (optional) create windows95 boot.ini for fail back load FreeBSD > > http://support.microsoft.com/en-us/kb/157992 > > I think boot.ini comes with ntldr, and Win95/98 started DOS-like.. > Oh, yes. ___ 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: Dual booting FreeBSD and Win95
On Wed, Apr 08, 2015 at 03:30:41PM -0400, Ryan Stone wrote: > I've been playing around with trying to set one only slice as active to > make the loader boot it, but it appears that doesn't actually work. > boot0cfg would cover half of the use case (switching from FreeBSD back to > Win95), but I'm not sure how I could do the original switch from Win95 to > FreeBSD. For this you must use any fdisk-like dos utility can change active partiton mark. Sorry, I am currently don't have neir Win95 or DOS for advice and/or test. As I remember this utilitys must be exist. May this article help you to automate fdisk from Win95 http://www.computerhope.com/fdiskhlp.htm ___ 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 IOMMU/DMAR with DELL 3020
On Thu, Apr 09, 2015 at 11:35:12AM +0300, Konstantin Belousov wrote: > On Thu, Apr 09, 2015 at 10:28:10AM +0200, Gustau P?rez wrote: > >Yup, sorry for the error. I checked the micro in the ark and it has vt-d: > > > > http://goo.gl/CZZRHz > It only indicates that the CPU/northbridge has the hardware, but BIOS must > do a work to configure it and to inform the OS about the configuration. > Your BIOS did not. > > > > >in the bios, there's only one option to enable virtualization > > support, which is ticked. > > > >The complete log is here: > > > > http://dpaste.com/28FDMJQ > > > Dmesg would not give you any useful information there. A DMAR table > is either present, or is it not. In the later case, OS cannot use the > hardware, and if no option in BIOS is present, your only choice is to > complain to the machine/BIOS vendor. May be some OS utilites can do same work? This is theoretically capable? ___ 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: Dual booting FreeBSD and Win95
On Thu, Apr 09, 2015 at 11:13:58AM +, Marcin Cieslak wrote: > On Thu, 9 Apr 2015, Slawa Olhovchenkov wrote: > > > On Wed, Apr 08, 2015 at 03:30:41PM -0400, Ryan Stone wrote: > > > > > I've been playing around with trying to set one only slice as active to > > > make the loader boot it, but it appears that doesn't actually work. > > > boot0cfg would cover half of the use case (switching from FreeBSD back to > > > Win95), but I'm not sure how I could do the original switch from Win95 to > > > FreeBSD. > > > > For this you must use any fdisk-like dos utility can change active > > partiton mark. Sorry, I am currently don't have neir Win95 or DOS for > > advice and/or test. As I remember this utilitys must be exist. > > We have a bunch of cool tools in > > ftp://ftp.freebsd.org/pub/FreeBSD/tools/ pfdisk may be nice. Oh, unzip from base system (and tar) don't support implode metod! > like bootinst.exe, alternative boot managers etc. etc. > > //Marcin ___ 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 IOMMU/DMAR with DELL 3020
On Thu, Apr 09, 2015 at 01:03:35PM +0300, Konstantin Belousov wrote: > On Thu, Apr 09, 2015 at 11:52:33AM +0300, Slawa Olhovchenkov wrote: > > On Thu, Apr 09, 2015 at 11:35:12AM +0300, Konstantin Belousov wrote: > > > > > On Thu, Apr 09, 2015 at 10:28:10AM +0200, Gustau P?rez wrote: > > > >Yup, sorry for the error. I checked the micro in the ark and it has > > > > vt-d: > > > > > > > > http://goo.gl/CZZRHz > > > It only indicates that the CPU/northbridge has the hardware, but BIOS must > > > do a work to configure it and to inform the OS about the configuration. > > > Your BIOS did not. > > > > > > > > > > >in the bios, there's only one option to enable virtualization > > > > support, which is ticked. > > > > > > > >The complete log is here: > > > > > > > > http://dpaste.com/28FDMJQ > > > > > > > Dmesg would not give you any useful information there. A DMAR table > > > is either present, or is it not. In the later case, OS cannot use the > > > hardware, and if no option in BIOS is present, your only choice is to > > > complain to the machine/BIOS vendor. > > > > May be some OS utilites can do same work? > > This is theoretically capable? > > No, OS must know the peculiarities of the particular chipset. But also, Someone may be know this and wrote support in utility. May be chipset datashit available. I am don't talk about 'universal, out of box support in OS'. I am talk about theoretically utility, that perform some operations after OS load. Also, I am interesting by OS-control interleaving memory (in multi-socket configuration). This is totaly imposible or just very complex? > it must know the intimate details of the BIOS operation, since several > facilities perform background DMA transfers not under the OS control. > Examples are USB legacy emulation, BMC working with the main memory, > or UMA GPU in BIOS-configured mode. Normally, BIOS communicates the > requirements of such facilities to OS using RMRR records in the DMAR > table. ___ 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: pkg 1.5.0 is out
On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: > Hi all, > > Final pkg 1.5.0 has been released. pkg 1.5.1 at 'pkg upgrade' propose === New packages to be INSTALLED: nvidia-driver: 346.47 linux-c6-libGLU: 10.1 === I am use nvidia-driver-340: # pkg info nvidia-driver-340-340.76 nvidia-driver-340-340.76 Name : nvidia-driver-340 Version: 340.76 Installed on : Tue Mar 10 16:15:59 MSK 2015 Origin : x11/nvidia-driver-340 Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : x11 kld Licenses : NVIDIA Maintainer : da...@freebsd.org WWW: http://www.nvidia.com/object/unix.html Comment: NVidia graphics card binary drivers for hardware OpenGL rendering Options: ACPI_PM: on DOCS : on LINUX : on WBINVD : off Shared Libs required: libXext.so.6 libX11.so.6 Shared Libs provided: libvdpau_nvidia.so.1 libnvidia-glsi.so.1 libnvidia-glcore.so.1 libnvidia-eglcore.so.1 libnvidia-cfg.so.1 libglx.so.1 libGLESv2.so.2 libGLESv1_CM.so.1 libGL.so.1 libEGL.so.1 Annotations: repo_type : binary repository : ivs Flat size : 209MiB ___ 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: help with sandybridge/ivybridge hwpmc NUMA DRAM counters
On Wed, Apr 22, 2015 at 11:38:22PM -0700, Adrian Chadd wrote: > hi all, > > I'm having a spot of problem trying to get the local/remote dram > counters working on the NUMA sandybridge and ivybridge systems here. > > Things work fine using intel-pcm, but those same counters don't work with > hwpmc. > > Sandybridge - there's apparently an MSR that needs to be fiddled if > the counters are active. > > Ivybridge - the v1 and v2 chips have different local/remote dram > counters, and on my v2 setup there's actually /two/ LOCAL_DRAM: # pmccontrol -L | grep DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.REMOTE_DRAM CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.05-MHz K8-class CPU) > adrian@testbox1:~/git/github/erikarn/freebsd/sys/dev/hwpmc % > pmccontrol -L | grep DRAM > MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM > MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM > MEM_LOAD_UOPS_LLC_MISS_RETIRED.REMOTE_DRAM > > Now, i may be able to get to figuring this out at some point in the > distant future, but I'd really appreciate any help I can get now. I'm > now at the point with the NUMA affinity API stuff where I'm now > chasing down when things are correctly working with local/remote RAM, > and I'd really like to use hwpmc in sampling mode to work on it. > > Thanks for any help! > > > > -adrian > ___ > 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"
Re: help with sandybridge/ivybridge hwpmc NUMA DRAM counters
On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: > Yeah, on stable/10. But on -HEAD it's different. There's two entries - > one for d3_01 and one for d3_03. What CPU model? ___ 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: help with sandybridge/ivybridge hwpmc NUMA DRAM counters
On Thu, Apr 23, 2015 at 12:24:06AM -0700, Adrian Chadd wrote: > On 23 April 2015 at 00:22, Slawa Olhovchenkov wrote: > > On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: > > > >> Yeah, on stable/10. But on -HEAD it's different. There's two entries - > >> one for d3_01 and one for d3_03. > > > > What CPU model? > > CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.06-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x306e4 Family=0x6 Model=0x3e Stepping=4 Same with me? ___ 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: help with sandybridge/ivybridge hwpmc NUMA DRAM counters
On Thu, Apr 23, 2015 at 10:24:55AM +0300, Slawa Olhovchenkov wrote: > On Thu, Apr 23, 2015 at 12:24:06AM -0700, Adrian Chadd wrote: > > > On 23 April 2015 at 00:22, Slawa Olhovchenkov wrote: > > > On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: > > > > > >> Yeah, on stable/10. But on -HEAD it's different. There's two entries - > > >> one for d3_01 and one for d3_03. > > > > > > What CPU model? > > > > CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.06-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x306e4 Family=0x6 Model=0x3e Stepping=4 > > Same with me? May be in you case E5-269x? ___ 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: Increase BUFSIZ to 8192
On Tue, May 12, 2015 at 06:31:33AM +, Poul-Henning Kamp wrote: > >Also, you'd probably see even better performance by increasing the > >size to 64k, [...] > > easy: > 8K on 32bit > 64k on 64bit Need benchmarking. May be 16K is local maximum (L1 cache-efficient). ___ 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: Increase BUFSIZ to 8192
On Thu, May 14, 2015 at 08:53:05AM -0600, Ian Lepore wrote: > At least I'm inclined to ponder it. Apparently nobody else is. People > running servers with more GB of ram than grains of sand on the beach > won't care about things like 64k buffers used by /bin/sh to read a line > of text, and all the world is big servers now, right? I have setups with servering tens of gigabits pers second from one server. Default send_lowat (SO_SNDLOWAT) is 2048. Settnig to 128K increase load. Setting to 16k slightly reduce. Not so simple. ___ 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: ixl and BOOTP
On Mon, May 18, 2015 at 02:42:51PM +, Eggert, Lars wrote: > > Legacy mode, and it hangs in the kernel. > > Without if_ixl in loader.conf, it does the usual BOOTP logic: ^^^ ^^ > Sending DHCP Discover packet from interface ix0 (90:e2:ba:77:d4:9c) ^^ > Sending DHCP Discover packet from interface ix1 (90:e2:ba:77:d4:9d) ^^ how this is posible? ___ 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: broken release generation when
On Sat, Jun 13, 2015 at 02:35:46PM +, Glen Barber wrote: > [re@ CC'd] > > On Sat, Jun 13, 2015 at 02:34:37PM +0200, Oliver Pinter wrote: > > Hi all! > > > > We got build error with custom BRANCH= in newvers.sh. The release > > process unable to generate the ISO files but they not stopped with > > error, just ignore them, and continue with memstick images. > > > > > > cp /jenkins/workspace/HardenedBSD-stable-master-amd64/release/rc.local > > bootonly/etc > > sh > > /jenkins/workspace/HardenedBSD-stable-master-amd64/release/amd64/mkisoimages.sh > > -b 11_0_CURRENT_HARDENEDBSD_amd64_BO bootonly.iso bootonly > > 100+0 records in > > 100+0 records out > > 409600 bytes transferred in 0.007822 secs (52361998 bytes/sec) > > newfs_msdos: cannot get number of sectors per track: Operation not supported > > newfs_msdos: cannot get number of heads: Operation not supported > > newfs_msdos: trim 44 sectors to adjust to a multiple of 63 > > /dev/md0: 717 sectors in 717 FAT12 clusters (512 bytes/cluster) > > BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512 > > Sectors=756 Media=0xf8 FATsecs=3 SecPerTrack=63 Heads=1 HiddenSecs=0 > > makefs: error: The Disk Label must be at most 32 characters long > > usage: makefs [-t fs-type] [-o fs-options] [-d debug-mask] [-B endian] > > [-S sector-size] [-M minimum-size] [-m maximum-size] [-s image-size] > > [-b free-blocks] [-f free-files] [-F mtree-specfile] [-xZ] > > [-N userdb-dir] image-file directory | manifest [extra-directory ...] > > > > I think at this point either: > > 1) VOLUME_LABEL should be removed; or > 2) VOLUME_LABEL should be only set if 'uname -s' returns 'FreeBSD'. > > There have been multiple reports of issues with this, and the workaround > for edge cases is getting far too ugly at this point, so I prefer option > (1). makefs must truncate label and don't return error. ___ 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: MS DNS doesn't answer to CURRENT under Hyper-V
On Tue, Jul 07, 2015 at 02:50:49PM +0300, Pavel Timofeev wrote: > Hi! > I have a test virtual machine which runs CURRENT under Hyper-V. It's > amd64 r285198 now. > It can't get any response from MS DNS server. Well, it could two or > three weeks ago, but after upgrade it's not able to do it anymore. > Google DNS answers without problems meanwhile (sic!). > > What I do: > # host google.ru 192.168.25.3 > I see that MS DNS (192.168.25.3) server receives these packets, but > ignores them. > And no matter how my system asks MS DNS. Every daemon can't get response too. > > I know that nothing was changed in MS DNS server. No doubt. > Then I tried different available CURRENT snapshot ISOs. > > FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso - MS DNS does not > answer. > > FreeBSD-11.0-CURRENT-amd64-20150625-r284814-disc1.iso - MS DNS does not > answer. > > FreeBSD-11.0-CURRENT-amd64-20150618-r284544-disc1.iso - MS DNS answers! > > So something was committed to CURRENT between 20150618 and 20150625. > This something ruins communication with MS DNS. > > Then I tried latest > FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso on bare metal - > MS DNS answered! > > Looks like that something is related to Hyper-V code. > > Maybe it changes packets somehow? I can gather and provide more info > (tcpdump?) if you ask, it's not a problem! Author: whu Date: Wed Jun 24 06:01:29 2015 New Revision: 284746 URL: https://svnweb.freebsd.org/changeset/base/284746 Log: TSO and checksum offloading support for Netvsc driver on Hyper-V. = Try tcpdump/wireshark on FreeBSD and MS DNS host. Check validating IP/UDP checksums. Try off checksum offloading on network interface (ifconfig ifname -txcsum -rxcsum) ___ 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: MS DNS doesn't answer to CURRENT under Hyper-V
On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote: > Well, turning off checksum offloading by `ifconfig hn0 -txcsum > -rxcsum` definitely helps. > > As for tcpdump I'm not completely sure if I did it right, but I see > "bad udp cksum" phrase: > > # tcpdump -i hn0 -vvv -nn udp dst port 53 > tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture size > 262144 bytes > 18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags [none], > proto UDP (17), length 51) > 192.168.25.26.45683 > 192.168.25.3.53: [bad udp cksum 0xb39e -> > 0xf210!] 52886+ A? ya.ru. (23) > 18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags [none], > proto UDP (17), length 51) > 192.168.25.26.12575 > 192.168.25.3.53: [bad udp cksum 0xb39e -> > 0x7365!] 52886+ A? ya.ru. (23) tcpdump "bad udp cksum" is normal on FreeBSD host in case checksum offload (and may be need only for help finding issuse in code). Need wireshark capturing from MS DNS host (or from mirroring port). ___ 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: MS DNS doesn't answer to CURRENT under Hyper-V
On Wed, Jul 08, 2015 at 11:05:39AM +0300, Pavel Timofeev wrote: > Ok, r284746 is the root of the problem. MS DNS works under r284745 and > doesn't work under r284746. > Slawa, what should I look at in wireshark output? I think developers can want look at same packet before entering in NIC and after receiving MS DNS server. I.e. hexdump of all packet. FreeBSD's tcpdump do this by `tcpdump -X` for IPv4 payload and `tcpdump -XX` for IPv4 and Ethernet payload (wireshark by default include ethernet, for easy comparasion do same). wireshar do same by 'Export Packet Dissections' 'as plain text' with checked 'Packet Deatils - All expanded' and 'Packet Bytes'. This is will be very verbose output. > 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov : > > On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote: > > > >> Well, turning off checksum offloading by `ifconfig hn0 -txcsum > >> -rxcsum` definitely helps. > >> > >> As for tcpdump I'm not completely sure if I did it right, but I see > >> "bad udp cksum" phrase: > >> > >> # tcpdump -i hn0 -vvv -nn udp dst port 53 > >> tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture size > >> 262144 bytes > >> 18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags [none], > >> proto UDP (17), length 51) > >> 192.168.25.26.45683 > 192.168.25.3.53: [bad udp cksum 0xb39e -> > >> 0xf210!] 52886+ A? ya.ru. (23) > >> 18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags [none], > >> proto UDP (17), length 51) > >> 192.168.25.26.12575 > 192.168.25.3.53: [bad udp cksum 0xb39e -> > >> 0x7365!] 52886+ A? ya.ru. (23) > > > > tcpdump "bad udp cksum" is normal on FreeBSD host in case checksum > > offload (and may be need only for help finding issuse in code). Need > > wireshark capturing from MS DNS host (or from mirroring port). ___ 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: duration of buildworld
On Mon, Jul 27, 2015 at 07:58:04AM +0200, Matthias Apitz wrote: > > Hello, > > Yesterday I grabbed r285885 from SVN and launched a > > # make -j2 buildworld > > which is still running after 19 hours on a server of 2 CPU of the type > Intel(R) Core(TM)2 Extreme CPU X9100 @ 3.06GHz and 4 GByte memory. > > Last time in January with r276659 on the same host it took only some 8 > hours, IIRC. > > Is there anything wrong of what could cause this change of the build > time? May be swap trashing on clang compilation? ___ 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: duration of buildworld
On Mon, Jul 27, 2015 at 01:06:15PM +0100, David Chisnall wrote: > On 27 Jul 2015, at 13:00, Slawa Olhovchenkov wrote: > > > > May be swap trashing on clang compilation? > > 4GB ought to be enough for building clang with -j2. A few of the > template-heavy files can use 500+MB of RAM compiling and linking > with BFD ld can easily hit 1GB (a lot more for a debug build - don't > try this on a 32-bit system!). I am try building 9.x with lot of memory and see about 1GB consumption when comiling (not linking) four clang library. I am don't know how clang in head consumption memory with self-compilation. And we don't know about available memory at this system (may be firefox runing?) ___ 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: duration of buildworld
On Mon, Jul 27, 2015 at 08:47:04PM +0200, Matthias Apitz wrote: > El d'ia Monday, July 27, 2015 a las 03:00:06PM +0300, Slawa Olhovchenkov > escribi'o: > > > On Mon, Jul 27, 2015 at 07:58:04AM +0200, Matthias Apitz wrote: > > > > > > > > Hello, > > > > > > Yesterday I grabbed r285885 from SVN and launched a > > > > > > # make -j2 buildworld > > > > > > which is still running after 19 hours on a server of 2 CPU of the type > > > Intel(R) Core(TM)2 Extreme CPU X9100 @ 3.06GHz and 4 GByte memory. > > > > > > Last time in January with r276659 on the same host it took only some 8 > > > hours, IIRC. > > > > > > Is there anything wrong of what could cause this change of the build > > > time? > > > > May be swap trashing on clang compilation? > > This pointed in the right direction. I have had 6x 1 GByte additional > swap partitions to plain files mounted (because I needed this to get > the eclipse port compiled within poudriere). After changing the fstab and > reboot, the 'make buildkernel' takes only half an hour. > > Why is this? swap to ZFS volume don't work some time ago (don't know about current status). May be swap to file on ZFS don't work also? ___ 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: duration of buildworld
On Mon, Jul 27, 2015 at 09:40:39PM +0200, Matthias Apitz wrote: > El d'ia Monday, July 27, 2015 a las 10:34:10PM +0300, Slawa Olhovchenkov > escribi'o: > > > > This pointed in the right direction. I have had 6x 1 GByte additional > > > swap partitions to plain files mounted (because I needed this to get > > > the eclipse port compiled within poudriere). After changing the fstab and > > > reboot, the 'make buildkernel' takes only half an hour. > > > > > > Why is this? > > > > swap to ZFS volume don't work some time ago (don't know about current > > status). > > May be swap to file on ZFS don't work also? > > I do not use ZFS. No idea. May be someone know about current status swap in file on UFS. This is work for me some time ago. ___ 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: [CFT] rewrite of the merge(1) utility
On Tue, Aug 04, 2015 at 10:00:06PM -0700, John Baldwin wrote: > On Sunday, July 26, 2015 03:26:22 AM Baptiste Daroussin wrote: > > Hi all, > > > > I was botherd to not have the merge(1) utility available in base (for > > etcupdate) > > when building base WITHOUT_RCS. > > > > So I have rewritten a merge(1) utility which should be compatible. > > > > I used the 3-way merge code from the fossil VCS instead of making it call > > diff3. > > All I have done from the fossil code is adapting it to use sbuf(9). > > > > The bonus for end users is the merge from fossil can resolve situation > > where the > > diff3 in base cannot. (which explains a "failure" with the GNU RCS test > > suite) > > > > meaning etcupdate will be more happy merge configuration files. > > Thanks! This will save me from having to hack etcupdate to use diff3 instead > of merge. Hi, can I use etcupdate to update /etc w/o source tree? I.e. I take from new distro /var/db/etcupdate and try to update /etc? ___ 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: [CFT] rewrite of the merge(1) utility
On Thu, Aug 13, 2015 at 08:23:02AM -0700, John Baldwin wrote: > On Thursday, August 13, 2015 04:13:43 PM Slawa Olhovchenkov wrote: > > On Tue, Aug 04, 2015 at 10:00:06PM -0700, John Baldwin wrote: > > > > > On Sunday, July 26, 2015 03:26:22 AM Baptiste Daroussin wrote: > > > > Hi all, > > > > > > > > I was botherd to not have the merge(1) utility available in base (for > > > > etcupdate) > > > > when building base WITHOUT_RCS. > > > > > > > > So I have rewritten a merge(1) utility which should be compatible. > > > > > > > > I used the 3-way merge code from the fossil VCS instead of making it > > > > call diff3. > > > > All I have done from the fossil code is adapting it to use sbuf(9). > > > > > > > > The bonus for end users is the merge from fossil can resolve situation > > > > where the > > > > diff3 in base cannot. (which explains a "failure" with the GNU RCS test > > > > suite) > > > > > > > > meaning etcupdate will be more happy merge configuration files. > > > > > > Thanks! This will save me from having to hack etcupdate to use diff3 > > > instead > > > of merge. > > > > Hi, can I use etcupdate to update /etc w/o source tree? > > I.e. I take from new distro /var/db/etcupdate and try to update /etc? > > etcupdate does a 3-way merge of an "old" stock /etc and a "new" stock /etc > into /etc. The "old" stock /etc is always stored in /var/db/etcupdate. > The "new" stock /etc has to come from somewhere. One option is to generate > it from /usr/src (e.g. after a buildworld). However, you can also pregenerate > tarballs from a /usr/src tree on one machine and then use those tarballs > instead of generating an /etc tree from /usr/src on another machine. I've > used this for upgrades of a cluster of machines where a single machine would > build release "images" that were basically a buildworld + an 'etcupdate build' > from the corresponding src tree. I then used 'etcupdate -t /path/to/tarball' > to update /etc after installing the new world. > > The idea is that for something like freebsd-update one could ship the latest > etcupdate build tarball on each update to do a full 3-way merge of /etc. What about /var/db/etcupdate from install media? Can I use this? What best way for work with /var/db/etcupdate from install media (storing, saving and etc)? ___ 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: [CFT] rewrite of the merge(1) utility
On Fri, Aug 14, 2015 at 12:14:28AM +0300, Slawa Olhovchenkov wrote: > On Thu, Aug 13, 2015 at 08:23:02AM -0700, John Baldwin wrote: > > > On Thursday, August 13, 2015 04:13:43 PM Slawa Olhovchenkov wrote: > > > On Tue, Aug 04, 2015 at 10:00:06PM -0700, John Baldwin wrote: > > > > > > > On Sunday, July 26, 2015 03:26:22 AM Baptiste Daroussin wrote: > > > > > Hi all, > > > > > > > > > > I was botherd to not have the merge(1) utility available in base (for > > > > > etcupdate) > > > > > when building base WITHOUT_RCS. > > > > > > > > > > So I have rewritten a merge(1) utility which should be compatible. > > > > > > > > > > I used the 3-way merge code from the fossil VCS instead of making it > > > > > call diff3. > > > > > All I have done from the fossil code is adapting it to use sbuf(9). > > > > > > > > > > The bonus for end users is the merge from fossil can resolve > > > > > situation where the > > > > > diff3 in base cannot. (which explains a "failure" with the GNU RCS > > > > > test suite) > > > > > > > > > > meaning etcupdate will be more happy merge configuration files. > > > > > > > > Thanks! This will save me from having to hack etcupdate to use diff3 > > > > instead > > > > of merge. > > > > > > Hi, can I use etcupdate to update /etc w/o source tree? > > > I.e. I take from new distro /var/db/etcupdate and try to update /etc? > > > > etcupdate does a 3-way merge of an "old" stock /etc and a "new" stock /etc > > into /etc. The "old" stock /etc is always stored in /var/db/etcupdate. > > The "new" stock /etc has to come from somewhere. One option is to generate > > it from /usr/src (e.g. after a buildworld). However, you can also > > pregenerate > > tarballs from a /usr/src tree on one machine and then use those tarballs > > instead of generating an /etc tree from /usr/src on another machine. I've > > used this for upgrades of a cluster of machines where a single machine would > > build release "images" that were basically a buildworld + an 'etcupdate > > build' > > from the corresponding src tree. I then used 'etcupdate -t > > /path/to/tarball' > > to update /etc after installing the new world. > > > > The idea is that for something like freebsd-update one could ship the latest > > etcupdate build tarball on each update to do a full 3-way merge of /etc. > > What about /var/db/etcupdate from install media? > Can I use this? > What best way for work with /var/db/etcupdate from install media > (storing, saving and etc)? As I see, /var/db/etcupdate/current match installed version. Is this enough? How I use this? ___ 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: [CFT] rewrite of the merge(1) utility
On Fri, Aug 14, 2015 at 11:19:15PM +0800, Julian Elischer wrote: > On 8/13/15 11:23 PM, John Baldwin wrote: > > On Thursday, August 13, 2015 04:13:43 PM Slawa Olhovchenkov wrote: > >> On Tue, Aug 04, 2015 at 10:00:06PM -0700, John Baldwin wrote: > >> > >>> On Sunday, July 26, 2015 03:26:22 AM Baptiste Daroussin wrote: > >>>> Hi all, > >>>> > >>>> I was botherd to not have the merge(1) utility available in base (for > >>>> etcupdate) > >>>> when building base WITHOUT_RCS. > >>>> > >>>> So I have rewritten a merge(1) utility which should be compatible. > >>>> > >>>> I used the 3-way merge code from the fossil VCS instead of making it > >>>> call diff3. > >>>> All I have done from the fossil code is adapting it to use sbuf(9). > >>>> > >>>> The bonus for end users is the merge from fossil can resolve situation > >>>> where the > >>>> diff3 in base cannot. (which explains a "failure" with the GNU RCS test > >>>> suite) > >>>> > >>>> meaning etcupdate will be more happy merge configuration files. > >>> Thanks! This will save me from having to hack etcupdate to use diff3 > >>> instead > >>> of merge. > >> Hi, can I use etcupdate to update /etc w/o source tree? > >> I.e. I take from new distro /var/db/etcupdate and try to update /etc? > > etcupdate does a 3-way merge of an "old" stock /etc and a "new" stock /etc > > into /etc. The "old" stock /etc is always stored in /var/db/etcupdate. > > The "new" stock /etc has to come from somewhere. One option is to generate > > it from /usr/src (e.g. after a buildworld). However, you can also > > pregenerate > > tarballs from a /usr/src tree on one machine and then use those tarballs > > instead of generating an /etc tree from /usr/src on another machine. I've > > used this for upgrades of a cluster of machines where a single machine would > > build release "images" that were basically a buildworld + an 'etcupdate > > build' > > from the corresponding src tree. I then used 'etcupdate -t > > /path/to/tarball' > > to update /etc after installing the new world. > > > > The idea is that for something like freebsd-update one could ship the latest > > etcupdate build tarball on each update to do a full 3-way merge of /etc. > > > what is the rational for using etcupdate instead of mergemaster when > upgrading? I am try to eliminate using source in upgrading path. (On build host run release.sh for some revision and using base.txz/kernel.XYZ.txz for upgrade together with beadm) ___ 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: [CFT] rewrite of the merge(1) utility
On Fri, Aug 14, 2015 at 10:52:04AM -0700, John Baldwin wrote: > On Friday, August 14, 2015 10:39:51 AM Slawa Olhovchenkov wrote: > > On Fri, Aug 14, 2015 at 12:14:28AM +0300, Slawa Olhovchenkov wrote: > > > > > On Thu, Aug 13, 2015 at 08:23:02AM -0700, John Baldwin wrote: > > > > > > > On Thursday, August 13, 2015 04:13:43 PM Slawa Olhovchenkov wrote: > > > > > On Tue, Aug 04, 2015 at 10:00:06PM -0700, John Baldwin wrote: > > > > > > > > > > > On Sunday, July 26, 2015 03:26:22 AM Baptiste Daroussin wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > I was botherd to not have the merge(1) utility available in base > > > > > > > (for etcupdate) > > > > > > > when building base WITHOUT_RCS. > > > > > > > > > > > > > > So I have rewritten a merge(1) utility which should be compatible. > > > > > > > > > > > > > > I used the 3-way merge code from the fossil VCS instead of making > > > > > > > it call diff3. > > > > > > > All I have done from the fossil code is adapting it to use > > > > > > > sbuf(9). > > > > > > > > > > > > > > The bonus for end users is the merge from fossil can resolve > > > > > > > situation where the > > > > > > > diff3 in base cannot. (which explains a "failure" with the GNU > > > > > > > RCS test suite) > > > > > > > > > > > > > > meaning etcupdate will be more happy merge configuration files. > > > > > > > > > > > > Thanks! This will save me from having to hack etcupdate to use > > > > > > diff3 instead > > > > > > of merge. > > > > > > > > > > Hi, can I use etcupdate to update /etc w/o source tree? > > > > > I.e. I take from new distro /var/db/etcupdate and try to update /etc? > > > > > > > > etcupdate does a 3-way merge of an "old" stock /etc and a "new" stock > > > > /etc > > > > into /etc. The "old" stock /etc is always stored in /var/db/etcupdate. > > > > The "new" stock /etc has to come from somewhere. One option is to > > > > generate > > > > it from /usr/src (e.g. after a buildworld). However, you can also > > > > pregenerate > > > > tarballs from a /usr/src tree on one machine and then use those tarballs > > > > instead of generating an /etc tree from /usr/src on another machine. > > > > I've > > > > used this for upgrades of a cluster of machines where a single machine > > > > would > > > > build release "images" that were basically a buildworld + an 'etcupdate > > > > build' > > > > from the corresponding src tree. I then used 'etcupdate -t > > > > /path/to/tarball' > > > > to update /etc after installing the new world. > > > > > > > > The idea is that for something like freebsd-update one could ship the > > > > latest > > > > etcupdate build tarball on each update to do a full 3-way merge of /etc. > > > > > > What about /var/db/etcupdate from install media? > > > Can I use this? > > > What best way for work with /var/db/etcupdate from install media > > > (storing, saving and etc)? > > > > As I see, /var/db/etcupdate/current match installed version. > > Is this enough? > > How I use this? > > There are a few ways. Newer installs do bootstrap it for you, so if you > follow the traditional source upgrade method you can just run 'etcupdate' > in place of 'mergemaster'. If you do not want to have a /usr/src tree, > how are you updating your world? yes, I don't want to have /usr/src tree. I have buld host and run release.sh. After done I use R/ftp/*.txz for extract on target host. I see var/db/etcupdate/current in base.txz. But I don't cleanly understund etcupdate: - is this enough (var/db/etcupdate/current from base.txz)? - what is best way to preserve var/db/etcupdate/current before extract? - do I need some work for record changes in /etc? ___ 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: [CFT] rewrite of the merge(1) utility
On Fri, Aug 14, 2015 at 12:59:30PM -0700, John Baldwin wrote: > > > There are a few ways. Newer installs do bootstrap it for you, so if you > > > follow the traditional source upgrade method you can just run 'etcupdate' > > > in place of 'mergemaster'. If you do not want to have a /usr/src tree, > > > how are you updating your world? > > > > yes, I don't want to have /usr/src tree. > > I have buld host and run release.sh. > > After done I use R/ftp/*.txz for extract on target host. > > I see var/db/etcupdate/current in base.txz. > > But I don't cleanly understund etcupdate: > > - is this enough (var/db/etcupdate/current from base.txz)? > > - what is best way to preserve var/db/etcupdate/current before > >extract? > > - do I need some work for record changes in /etc? > > In this model, I think etcupdate isn't really what you need/want. > For one, if you extract base.txz it already overwrites your files > in /etc and loses any local changes (including any files that Of couse, I am dont extract from base.txz /etc and /var itself, only var/db/etcupdate. > etcupdate would upgrade). It doesn't lose new files like /etc/fstab > or /etc/rc.conf, but if you make changes to existing files (like > /etc/ttys) then extracting base.txz will overwrite those with the > stock versions. If you wanted to not overwrite /etc then you could > use etcupdate to merge in the changes to /etc instead. However, > you would need to do something like this: > > 1) Ignore /etc and /var/db/etcupdate/current when you extract >base.txz via --exclude. Actual command is: tar xf - --exclude ./boot/device.hints ./COPYRIGHT boot dev media mnt proc tmp bin lib libexec rescue sbin usr because tar don't allow include/exclude and var in base.txz also contains var/log/sendmail.st, var/crash/minfree, var/db/mergemaster.mtree, var/db/locate.database. > 2) Extract just /var/db/etcupdate/current from base.txz to >some other temporary location (/some/tmp/path). > > 3) Create a new tarball from that tree >( tar cfy foo.tbz -C /some/tmp/path/var/db/etcupdate/current . ) > > 4) Use foo.tbz with etcupdate as the tarball (etcupdate -t foo.tbz) Thanks, I try this. > Alternatively, you could save on steps 2 + 3 by patching your release > process to run 'etcupdate build' (you can see where the current release > Makefile runs 'etcupdate extract' and use 'build' with the same options). > > -- > John Baldwin ___ 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: r286615: /usr/libexec/ftpd broken!
On Tue, Aug 18, 2015 at 07:35:25AM -0700, Marcel Moolenaar wrote: > > > On Aug 17, 2015, at 10:15 PM, O. Hartmann > > wrote: > > > > Port security/heimdal installs its own ftpd with its appropriate manpages. > > Ugh :-( > > It would have been so nice if man(1) would have told you that there > were 2 ftpd manpages and that you need to specify which one you want. > That should raise an eyebrow right away... Some time ago man(1) show all ftpd manpages. ___ 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: r286615: /usr/libexec/ftpd broken!
On Tue, Aug 18, 2015 at 11:38:47AM -0400, Benjamin Kaduk wrote: > On Tue, 18 Aug 2015, Marcel Moolenaar wrote: > > > > On Aug 17, 2015, at 10:15 PM, O. Hartmann > > > wrote: > > > > > > Port security/heimdal installs its own ftpd with its appropriate manpages. > > > > Ugh :-( > > I would argue that heimdal should not be in the business of supplying an > ftpd. Kerberos-enabled ftp basically does not offer any advantages over > scp. OPENSSH_NONE_CIPHER is OFF by default, i.e. ftp can give more speed. ___ 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: r286615: /usr/libexec/ftpd broken!
On Tue, Aug 18, 2015 at 09:01:27AM -0700, Garrett Cooper wrote: > > > On Aug 18, 2015, at 08:57, Slawa Olhovchenkov wrote: > > > > On Tue, Aug 18, 2015 at 11:38:47AM -0400, Benjamin Kaduk wrote: > > > >> On Tue, 18 Aug 2015, Marcel Moolenaar wrote: > >> > >>>> On Aug 17, 2015, at 10:15 PM, O. Hartmann > >>>> wrote: > >>>> > >>>> Port security/heimdal installs its own ftpd with its appropriate > >>>> manpages. > >>> > >>> Ugh :-( > >> > >> I would argue that heimdal should not be in the business of supplying an > >> ftpd. Kerberos-enabled ftp basically does not offer any advantages over > >> scp. > > > > OPENSSH_NONE_CIPHER is OFF by default, i.e. ftp can give more speed. > > More pragmatically, there are less ssh clients (openssh or bust > really), whereas there are more ftp clients (Firefox, Chrome, > ftp(1), python, etc). In this context you must talk about kerberos-enabled ftp client. ___ 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: [drm:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer
On Sat, Aug 29, 2015 at 11:15:53PM +0300, Ruslan Makhmatkhanov wrote:
> Hello,
>
> I'm getting tons of this in /var/log/messages:
> error: [drm:pid9:i915_gem_object_unbind] *ERROR* Attempting to unbind
> pinned buffer
>
> As far I understand [1], this case is harmless and there is no point to
> print it with DRM_ERROR - DRM_DEBUG is sufficient. Can we please change
> it in our tree like it done in patch attached? Thanks.
>
> PS. In Linux 3.8 [2] this check was changed by removing the warning
> altogether and just returning -EBUSY, so may be we can do just this to
> reduce the diff ;).
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=50075
> [2]
> http://lxr.free-electrons.com/source/drivers/gpu/drm/i915/i915_gem.c?v=3.8
>
> --
> Regards,
> Ruslan
>
> T.O.S. Of Reality
> Index: sys/dev/drm2/i915/i915_gem.c
> ===
> --- sys/dev/drm2/i915/i915_gem.c (revision 287214)
> +++ sys/dev/drm2/i915/i915_gem.c (working copy)
> @@ -2528,7 +2528,7 @@
> return 0;
>
> if (obj->pin_count) {
> - DRM_ERROR("Attempting to unbind pinned buffer\n");
> + DRM_DEBUG("Attempting to unbind pinned buffer\n");
> return -EINVAL;
> }
>
I think this is not root of cause, this is only cause of other error:
=== dmesg
info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
error: [drm:pid12:i915_hangcheck_hung] *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.
==
This cause:
=== Xorg.log
[51.010] (EE) intel(0): Detected a hung GPU, disabling acceleration.
[51.010] (EE) intel(0): When reporting this, please include
i915_error_state from debugfs and the full dmesg.
=
and after this you see Attempting to unbind pinned buffer.
I am see this in STABLE after Aug upgrade. I am don't see this at 2014-Oct
STABLE.
___
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: [drm:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer
On Sun, Aug 30, 2015 at 04:06:04PM +0300, Slawa Olhovchenkov wrote:
> On Sat, Aug 29, 2015 at 11:15:53PM +0300, Ruslan Makhmatkhanov wrote:
>
> > Hello,
> >
> > I'm getting tons of this in /var/log/messages:
> > error: [drm:pid9:i915_gem_object_unbind] *ERROR* Attempting to unbind
> > pinned buffer
> >
> > As far I understand [1], this case is harmless and there is no point to
> > print it with DRM_ERROR - DRM_DEBUG is sufficient. Can we please change
> > it in our tree like it done in patch attached? Thanks.
> >
> > PS. In Linux 3.8 [2] this check was changed by removing the warning
> > altogether and just returning -EBUSY, so may be we can do just this to
> > reduce the diff ;).
> >
> > [1] https://bugs.freedesktop.org/show_bug.cgi?id=50075
> > [2]
> > http://lxr.free-electrons.com/source/drivers/gpu/drm/i915/i915_gem.c?v=3.8
> >
> > --
> > Regards,
> > Ruslan
> >
> > T.O.S. Of Reality
>
> > Index: sys/dev/drm2/i915/i915_gem.c
> > ===
> > --- sys/dev/drm2/i915/i915_gem.c(revision 287214)
> > +++ sys/dev/drm2/i915/i915_gem.c(working copy)
> > @@ -2528,7 +2528,7 @@
> > return 0;
> >
> > if (obj->pin_count) {
> > - DRM_ERROR("Attempting to unbind pinned buffer\n");
> > + DRM_DEBUG("Attempting to unbind pinned buffer\n");
> > return -EINVAL;
> > }
> >
>
> I think this is not root of cause, this is only cause of other error:
>
> === dmesg
> info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
> error: [drm:pid12:i915_hangcheck_hung] *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.
> ==
>
> This cause:
>
> === Xorg.log
> [51.010] (EE) intel(0): Detected a hung GPU, disabling acceleration.
> [51.010] (EE) intel(0): When reporting this, please include
> i915_error_state from debugfs and the full dmesg.
> =
>
> and after this you see Attempting to unbind pinned buffer.
>
> I am see this in STABLE after Aug upgrade. I am don't see this at 2014-Oct
> STABLE.
For -STABLE:
r280368 -- All works OK (no error messages, video playback work)
r280369 -- All works OK (no error messages, video playback work)
r282141 -- error: [drm:pid5:i915_gem_object_unbind] *ERROR* Attempting to
unbind pinned buffer (video don't tested)
r282199 -- error: [drm:pid12:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU hung (video don't work)
___
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: [drm:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer
On Sun, Aug 30, 2015 at 09:58:31PM +0300, Ruslan Makhmatkhanov wrote: > >> I think this is not root of cause, this is only cause of other error: > >> > >> === dmesg > >> info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 > >> error: [drm:pid12:i915_hangcheck_hung] *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. > >> == > >> > >> This cause: > >> > >> === Xorg.log > >> [51.010] (EE) intel(0): Detected a hung GPU, disabling acceleration. > >> [51.010] (EE) intel(0): When reporting this, please include > >> i915_error_state from debugfs and the full dmesg. > >> = > >> > >> and after this you see Attempting to unbind pinned buffer. > >> > >> I am see this in STABLE after Aug upgrade. I am don't see this at 2014-Oct > >> STABLE. > > > > For -STABLE: > > > > r280368 -- All works OK (no error messages, video playback work) > > r280369 -- All works OK (no error messages, video playback work) > > r282141 -- error: [drm:pid5:i915_gem_object_unbind] *ERROR* Attempting to > > unbind pinned buffer (video don't tested) > > r282199 -- error: [drm:pid12:i915_hangcheck_hung] *ERROR* Hangcheck timer > > elapsed... GPU hung (video don't work) > > No doubt that this is not the root cause, but frankly I haven't that > "GPU hung" messages in my system. I have others like this one triggered > on shutdown: > error: [drm:pid1041:intel_lvds_enable] *ERROR* timed out waiting for > panel to power off > > And this one spamming almost with the same frequency as "pinned buffer": > error: [drm:pid1016:gen6_sanitize_pm] *ERROR* Power management > discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 000d, was 180d > > But I had not investigated that yet and not sure they are related. > It's on r287029 head. All of this related to import new DRI/DRM code and such code in Linux have same problems. r282141 in stable related to r279599 and r275209 in current. Can you try to revert r279599? ___ 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: [drm:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer
On Sun, Aug 30, 2015 at 11:59:26PM +0300, Ruslan Makhmatkhanov wrote:
> Slawa Olhovchenkov wrote on 08/30/2015 22:17:
> > On Sun, Aug 30, 2015 at 09:58:31PM +0300, Ruslan Makhmatkhanov wrote:
>
> >> No doubt that this is not the root cause, but frankly I haven't that
> >> "GPU hung" messages in my system. I have others like this one triggered
> >> on shutdown:
> >> error: [drm:pid1041:intel_lvds_enable] *ERROR* timed out waiting for
> >> panel to power off
> >>
> >> And this one spamming almost with the same frequency as "pinned buffer":
> >> error: [drm:pid1016:gen6_sanitize_pm] *ERROR* Power management
> >> discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 000d, was 180d
> >>
> >> But I had not investigated that yet and not sure they are related.
> >> It's on r287029 head.
> >
> > All of this related to import new DRI/DRM code and such code in Linux
> > have same problems.
> > r282141 in stable related to r279599 and r275209 in current.
> > Can you try to revert r279599?
>
> You are right. After reverting r279599 two of this messages ("timed out
> waiting for panel to power off" and "unbind pinned buffer") disappeared,
> while "Power management discrepancy" is still there. Should I try to
> revert r275209 too?
I think r275209 is not relevant here.
___
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: kernel dtrace and current
On Sun, Sep 13, 2015 at 08:53:33PM +, Mark Johnston wrote:
> On Sun, Sep 13, 2015 at 04:23:23PM +0300, Alexander V. Chernikov wrote:
> > Hello all,
> >
> > I keep running in
> > "dtrace: failed to compile script: "/usr/lib/dtrace/psinfo.d", line 39:
> > failed to copy type of 'pr_uid': Type information is in parent and
> > unavailable"
> > message more and more often while trying to trace different -current
> > kernels.
> >
> > Typically the reason besides that is the number of types embedded in kernel
> > CTF:
> > ctfdump -S /boot/kernel/kernel | awk '$0~/of types/{print$6}'
> > 37160
> >
> > We are bound to 32k of types by CTF format (and numbers above 32k (e.g.w/
> > highest bit set) are considered "child" types with the information stored
> > in "parent").
> > ctfmerge ignores this fact and instead of yelling emits type indices above
> > 32k. On the other hand, libctf sees such indices while parsing sections and
> > since there is no
> > "parent" for kernel, it emits the error above and stops.
> >
> > Thankfully, r287234 really improved the situation for ctfmerge, but there
> > are still several thousands of identical structures and the total number is
> > close to 32k.
>
> r281797 and r287234 should have fixed most instances of duplicate type
> definitions. At the moment, amd64 GENERIC and GENERIC-NODEBUG have
> roughly 25K types in their respective CTF containers; there is a small
> handful of duplicates, but at least some of them are legitimate (some
> pairs of drivers redefine the same types, e.g. aac(4)/aacraid(4) or
> mps(4)/mpr(4)).
>
> Could you post a config that results in the large number of duplicates
> you mention above?
>
> >
> > Personally I solved this by removing unneeded devices from
> > GENERIC-inherited configs.
> > I wonder, however if this can be handled better.
>
> FWIW, removing old drivers from GENERIC would be straightforward if we
> could auto-load KLDs based on device IDs.
We can just unconditionaly load all current drivers from GENERIC as
KLD. This is as good as ever.
___
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: Intel Haswell support - Any updates?
On Thu, Sep 17, 2015 at 12:43:59PM +0100, David Chisnall wrote: > On 17 Sep 2015, at 11:31, Lundberg, Johannes > wrote: > > > > Anyway, I wish the foundation would support the graphics team by sponsoring > > this development... > > The Foundation did fund a lot of this work, and likely will again. > The problem is not willingness of the Foundation to fund it, nor > availability of funds. As with WiFi, it's availability of people > who have both the competence and interest to do the work and the > availability to work as consultants for the Foundation. > > Long term, the real solution is to convince GPU vendors to put as > much effort into funding FreeBSD driver development as they do into > funding Linux and Windows driver development. The Foundation has > been reaching out in this direction, but it's far more compelling if > people can document cases where lack of FreeBSD support has cost a > vendor sales. If you've bought a system with an nVidia or AMD GPU > (or, ideally, if your company has bought a few thousand) because of > lack of FreeBSD support from Intel, then let Intel know. Impotant: if you already buy Intel system -- Intel will be ignored you, only future sales important. ___ 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: Intel Haswell support - Any updates?
On Fri, Sep 18, 2015 at 12:50:16PM -0700, Adrian Chadd wrote: > Hi, > > Just run -HEAD. Outside of occasional hiccups, a whole bunch of us use > it for day to day work, and it works fine. Some years ago -HEAD break may be one at month, now -HEAD break some times at week, and, may be, persistent break (em/igb, callout, i915 on 945G (yes, this is also break on -stable, but on stable simple revert two commit and will be nice, on -head you got many coomits)). Development is ipmotant and development w/o breaks imposibles, but current -HEAD not to agree with genareal user. ___ 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: Add isboot iSCSI boot driver to FreeBSD
On Wed, Sep 23, 2015 at 11:25:20PM +0200, Edward Tomasz Napierala wrote: > On 0923T0916, John Nielsen wrote: > > On Sep 23, 2015, at 2:12 AM, Yonas Yanfa wrote: > > > > > isboot is a iSCSI boot driver written by Daisuke Aoyama that allows you > > > to boot your root partition using iSCSI. > > [,,,] > > > This was first announced way back in June, 2010: > > > > > > https://lists.freebsd.org/pipermail/freebsd-scsi/2010-June/004425.html > > > > > > I've tested the current version (v0.2.10) and it works with FreeBSD 10.2 > > > booting a ZFS on root installation: > > > > > > http://www.peach.ne.jp/archives/isboot/isboot-0.2.10.tar.gz > > > > > > I've used iSCSI boot with Ubuntu Server for a while and it's been very > > > useful. I'm looking forward to FreeBSD having the same capability > > > built-in. > > > > +1. I have used this module in the past and it is extremely useful. Thanks > > for the pointer, I wasn't aware it had been updated for FreeBSD 10.x so > > recently. I've also wondered why this is not part of FreeBSD by default. > > > > Aoyama-san, do you have any objection to this code being included in > > FreeBSD? If not, can you formally assign it a BSD or other friendly > > license? Thank you again for the work! > > > > Trasz (or anyone), is there other work to support iSCSI booting and/or IBFT > > on FreeBSD? Anything else isboot might conflict with? Any problems with > > integrating the code or with the code itself? > > The basic problem with isboot is that it only works with the old iSCSI > initiator, which is now marked obsolete. AFAIK there is no ready solution We have more then one iSCSI initiator? Other then iscsi_initiator(4)? ___ 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: Add isboot iSCSI boot driver to FreeBSD
On Wed, Sep 23, 2015 at 05:21:00PM -0600, John Nielsen wrote: > On Sep 23, 2015, at 3:25 PM, Edward Tomasz Napierala > wrote: > > > On 0923T0916, John Nielsen wrote: > >> On Sep 23, 2015, at 2:12 AM, Yonas Yanfa wrote: > >> > >>> isboot is a iSCSI boot driver written by Daisuke Aoyama that allows you > >>> to boot your root partition using iSCSI. > >> [,,,] > >>> This was first announced way back in June, 2010: > >>> > >>> https://lists.freebsd.org/pipermail/freebsd-scsi/2010-June/004425.html > >>> > >>> I've tested the current version (v0.2.10) and it works with FreeBSD 10.2 > >>> booting a ZFS on root installation: > >>> > >>> http://www.peach.ne.jp/archives/isboot/isboot-0.2.10.tar.gz > >>> > >>> I've used iSCSI boot with Ubuntu Server for a while and it's been very > >>> useful. I'm looking forward to FreeBSD having the same capability > >>> built-in. > >> > >> +1. I have used this module in the past and it is extremely useful. Thanks > >> for the pointer, I wasn't aware it had been updated for FreeBSD 10.x so > >> recently. I've also wondered why this is not part of FreeBSD by default. > >> > >> Aoyama-san, do you have any objection to this code being included in > >> FreeBSD? If not, can you formally assign it a BSD or other friendly > >> license? Thank you again for the work! > >> > >> Trasz (or anyone), is there other work to support iSCSI booting and/or > >> IBFT on FreeBSD? Anything else isboot might conflict with? Any problems > >> with integrating the code or with the code itself? > > > > The basic problem with isboot is that it only works with the old iSCSI > > initiator, which is now marked obsolete. AFAIK there is no ready solution > > that works with the new one - however, it should be possible to use upcoming > > reroot support to achieve this: boot with a temporary rootfs, mounted from > > a ramdisk preloaded by loader(8), setup an iSCSI session, and then replace > > the temporary rootfs with the real one, mounted over iSCSI. > > Ah, thank you for clarifying. I forgot that 10.x still supports the old > initiator. > > The reroot approach sounds interesting but less straightforward. The beauty > of isboot is that the kernel-loaded from a normal root disk that happens to > be iSCSI-connected-knows how to re-establish its network and iSCSI > connections just from the information in the iSCSI Boot Firmware Table, i.e. > native iSCSI booting. I'd love to see the same approach continued with the > new initiator. I suspect that a new implementation could re-use all of the > IBFT code and most of the networking code, but I don't know how hard the > remaining pieces would be. I may have a chance to look in to it but a kernel > programmer I am not, sadly. > > I think a "native" iSCSI reroot approach could be feasible at some > point; for me that would mean that the loader could load the kernel > and a standard-ish (or easily auto-generated) mfsroot from the iSCSI > volume seamlessly, then something in the mfsroot parses the IBFT and > sets up the network and iSCSI connections before switching root. mfsroot auto-generated by loader? cool for stay in sync mfsroot with main tree. ___ 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: dumpdev in loader.conf vs rc.d/dumpon
On Thu, Sep 24, 2015 at 11:28:05AM +0300, Andrey V. Elsukov wrote: > On 23.09.2015 19:57, Andriy Gapon wrote: > > I do not have a strong opinion. Either option, rc.d/dumpon change or > > geom_dev > > change, is fine with me. > > I added the ability to set dumpdev via loader. But I wasn't aware that > it was used in rc.d script. > > If you have set dumpdev kenv, it will be already enabled in the time > when rc.d/dumpon will be run. So, I think it is useless to try to > enable dumpdev again. I prefer remove this old code from rc.d script. rc.d script can redirect dump to device, not available at boot time, iSCSI disk, for examle. dumpdev at boot time can be less size, sufficient for dumping at booting, but insufficient at working time. ___ 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: dumpdev in loader.conf vs rc.d/dumpon
On Thu, Sep 24, 2015 at 02:27:13PM +0300, Andrey V. Elsukov wrote: > On 24.09.2015 14:18, Slawa Olhovchenkov wrote: > > On Thu, Sep 24, 2015 at 11:28:05AM +0300, Andrey V. Elsukov wrote: > > > >> On 23.09.2015 19:57, Andriy Gapon wrote: > >>> I do not have a strong opinion. Either option, rc.d/dumpon change or > >>> geom_dev > >>> change, is fine with me. > >> > >> I added the ability to set dumpdev via loader. But I wasn't aware that > >> it was used in rc.d script. > >> > >> If you have set dumpdev kenv, it will be already enabled in the time > >> when rc.d/dumpon will be run. So, I think it is useless to try to > >> enable dumpdev again. I prefer remove this old code from rc.d script. > > > > rc.d script can redirect dump to device, not available at boot time, > > iSCSI disk, for examle. > > It doesn't matter. When device will appear, it will be tasted by > geom_dev and marked as device applicable for dumping. How many dump device you can select? > > dumpdev at boot time can be less size, sufficient for dumping at > > booting, but insufficient at working time. > > This also doesn't matter. Its size doesn't checked. I am don't talk about checking size. I can know about inssuficient size of device. For example, host with 3TB of RAM, booted from small SSD. This SSD have 16GB slice for dumping. This is sufficent if trouble happen at boot time. This is insuuficient if trouble happen later, after using all 3TB. rc.d script can be used for select iSCSI destination, for dumping after succesefull boot. > Did you read dumpon script and saw how it use dumpdev tunable? ___ 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: dumpdev in loader.conf vs rc.d/dumpon
On Thu, Sep 24, 2015 at 02:37:39PM +0300, Andrey V. Elsukov wrote: > On 24.09.2015 14:37, Slawa Olhovchenkov wrote: > > For example, host with 3TB of RAM, booted from small SSD. > > This SSD have 16GB slice for dumping. This is sufficent if trouble > > happen at boot time. This is insuuficient if trouble happen later, > > after using all 3TB. rc.d script can be used for select iSCSI > > destination, for dumping after succesefull boot. > > Did you read dumpon script and saw how it uses dumpdev tunable? This is script try it in case dumpdev=auto, before trying swap partition. ___ 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: dumpdev in loader.conf vs rc.d/dumpon
On Thu, Sep 24, 2015 at 02:56:55PM +0300, Andrey V. Elsukov wrote:
> On 24.09.2015 14:45, Slawa Olhovchenkov wrote:
> > On Thu, Sep 24, 2015 at 02:37:39PM +0300, Andrey V. Elsukov wrote:
> >
> >> On 24.09.2015 14:37, Slawa Olhovchenkov wrote:
> >>> For example, host with 3TB of RAM, booted from small SSD.
> >>> This SSD have 16GB slice for dumping. This is sufficent if trouble
> >>> happen at boot time. This is insuuficient if trouble happen later,
> >>> after using all 3TB. rc.d script can be used for select iSCSI
> >>> destination, for dumping after succesefull boot.
> >>
> >> Did you read dumpon script and saw how it uses dumpdev tunable?
> >
> > This is script try it in case dumpdev=auto, before trying swap
> > partition.
>
> Yes.
>
> 1. If you did set dumpdev from loader prompt or from /boot/loader.conf,
> and you didn't configured it in rc.conf, then this choice will be
> applied by geom_dev. Then it will be applied again by rc.d/dumpon.
>
> 2. If you did set dumpdev from loader prompt or from /boot/loader.conf,
> and you did configured it in rc.conf, then first of will be selected
> dumpdev from loader, then will be selected one from rc.conf.
>
> 3. If you didn't set dumpdev from loader prompt or from
> /boot/loader.conf, and you didn't configured it in rc.conf, then one of
> swap partition will be selected.
>
> In the end we can see, if we apply the following patch, then nothing
> will be affected.
1. If no swap configured in fstab, but configured dumpdev from loader
prompt symlink in devfs for savecore not created.
2. If swap configured in fstab and dumpdev configured from loader prompt
(and different from swap) -- dumpdev changed (unexpectedly?).
> Index: dumpon
> ===
> --- dumpon(revision 288047)
> +++ dumpon(working copy)
> @@ -34,11 +34,6 @@ dumpon_start()
> [Nn][Oo] | '')
> ;;
> [Aa][Uu][Tt][Oo])
> - dev=$(/bin/kenv -q dumpdev)
> - if [ -n "${dev}" ] ; then
> - dumpon_try "${dev}"
> - return $?
> - fi
> while read dev mp type more ; do
> [ "${type}" = "swap" ] || continue
> [ -c "${dev}" ] || continue
>
>
> PS. loader(8) has many variables where device name is used, and none of
> them uses /dev/ prefix.
PS. This is another stranges: devfs may be mounted not only to /dev,
but in many places /dev/ prefix is hardcoded and no notes in docs.
___
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: dumpdev in loader.conf vs rc.d/dumpon
On Thu, Sep 24, 2015 at 10:58:00PM +0200, Pawel Jakub Dawidek wrote: > On Thu, Sep 24, 2015 at 02:18:50PM +0300, Slawa Olhovchenkov wrote: > > On Thu, Sep 24, 2015 at 11:28:05AM +0300, Andrey V. Elsukov wrote: > > > > > On 23.09.2015 19:57, Andriy Gapon wrote: > > > > I do not have a strong opinion. Either option, rc.d/dumpon change or > > > > geom_dev > > > > change, is fine with me. > > > > > > I added the ability to set dumpdev via loader. But I wasn't aware that > > > it was used in rc.d script. > > > > > > If you have set dumpdev kenv, it will be already enabled in the time > > > when rc.d/dumpon will be run. So, I think it is useless to try to > > > enable dumpdev again. I prefer remove this old code from rc.d script. > > > > rc.d script can redirect dump to device, not available at boot time, > > iSCSI disk, for examle. > > No. Dump device is very special. It runs in an environment when kernel > already paniced, there are no interrupt, so there is no networking. > Storage controllers have special methods to handle dumping kernel memory > - it doesn't go through GEOM, it cannot go through GEOM as the scheduler > doesn't work too. Can be ZFS VOL act as dump device? ___ 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: Depreciate and remove gbde
On Mon, Oct 19, 2015 at 01:52:05AM -0700, Perry Hutchison wrote: > Anton Shterenlikht wrote: > > > I use gbde. > > Can switch to geli, if required, > > but please provide detailed instructions > > for switching before removing gbde. > > Such instructions would presumably be included in the UPDATING > entry. > > An additional consideration: If there is no convert-in-place > mechanism -- i.e. the only way to convert a gbde FS to geli is to > backup, wipe, and restore (thus involving considerable downtime) > -- it will give some unknown number of production users a strong > motivation to freeze at [last version of FreeBSD to include gbde > support]. This must be show-stoper for removing gbde. ___ 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: OpenSSH HPN
On Tue, Nov 10, 2015 at 10:42:49AM +0100, Dag-Erling Smørgrav wrote: > Some of you may have noticed that OpenSSH in base is lagging far behind > the upstream code. > > The main reason for this is the burden of maintaining the HPN patches. > They are extensive, very intrusive, and touch parts of the OpenSSH code > that change significantly in every release. Since they are not > regularly updated, I have to choose between trying to resolve the > conflicts myself (hoping I don't break anything) or waiting for them to > catch up and then figuring out how to apply the new version. > > Therefore, I would like to remove the HPN patches from base and refer > anyone who really needs them to the openssh-portable port, which has > them as a default option. I would also like to remove the NONE cipher > patch, which is also available in the port (off by default, just like in > base). I am plan to use NONE and HPN for bulk transfer, but don't see performance improvement, in both cases I see only 500Mbit/s. ___ 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: OpenSSH HPN
On Tue, Nov 10, 2015 at 09:52:16AM -0800, John-Mark Gurney wrote: > Dag-Erling Smrgrav wrote this message on Tue, Nov 10, 2015 at 10:42 +0100: > > Therefore, I would like to remove the HPN patches from base and refer > > anyone who really needs them to the openssh-portable port, which has > > them as a default option. I would also like to remove the NONE cipher > > patch, which is also available in the port (off by default, just like in > > base). > > My vote is to remove the HPN patches. First, the NONE cipher made more > sense back when we didn't have AES-NI widely available, and you were > seriously limited by it's performance. Now we have both aes-gcm and > chacha-poly which it's performance should be more than acceptable for > today's uses (i.e. cipher performance is 2GB/sec+). > > Second, I did some testing recently due to a thread on -net, and I > found no significant (not run statistically though) difference in > performance between in HEAD ssh and OpenSSH 7.1p1. I started a wiki > page to talk about this: > https://wiki.freebsd.org/SSHPerf Hmm, I see in this page max speed 20MB/sec. This is too small. What is problem? With modern 40G NIC wanted speed about 20Gbit/s. 10Gbit/s at least. ___ 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: OpenSSH HPN
On Tue, Nov 10, 2015 at 11:59:30PM -0800, John-Mark Gurney wrote: > Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800: > > On Wednesday, 11 November 2015, Bryan Drewery wrote: > > > > > On 11/10/15 9:52 AM, John-Mark Gurney wrote: > > > > My vote is to remove the HPN patches. First, the NONE cipher made more > > > > sense back when we didn't have AES-NI widely available, and you were > > > > seriously limited by it's performance. Now we have both aes-gcm and > > > > chacha-poly which it's performance should be more than acceptable for > > > > today's uses (i.e. cipher performance is 2GB/sec+). > > > > > > AES-NI doesn't help the absurdity of double-encrypting when using scp or > > > rsync/ssh over an encrypted VPN, which is where NONE makes sense to use > > > for me. > > > > I have to agree that there are cases when the NONE cipher makes sense, and > > it is up to the end user to make sure they know what they are doing. > > > > Personally I have used it at home to backup my old FreeBSD server (which > > does not have AESNI) over a dedicated network connection to a backup server > > using rsync/ssh. Since it was not possible for anyone else to be on that > > local network, and the server was so old it didn't have AESNI and would > > soon be retired, using the NONE cipher sped up the transfer significantly. > > If you have a trusted network, why not just use nc? I think you kidding: - scp need only one command on initiator side and no additional setup on target. simple, well know. - nc need additional work on target, need synchronization for file names with target, also need ssh to target for start, etc... Too complex. ___ 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: OpenSSH HPN
On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote: > Bryan Drewery writes: > > Another thing that I did with the port was restore the tcpwrapper > > support that upstream removed. Again, if we decide it is not worth > > keeping in base I will remove it as default in the port. > > I want to keep tcpwrapper support - it is another reason why I still > haven't upgraded OpenSSH, but to the best of my knowledge, it is far > less intrusive than HPN. Can you explain what is problem? I am see openssh in base and openssh in ports (more recent version) with same functionaly patches. You talk about trouble to upgrade. What is root? openssh in base have different vendor and/or license? Or something else? PS: As I today know, kerberos heimdal is practicaly dead as opensource project. Have FreeBSD planed switch to MIT Kerberos? I am know about security/krb5. ___ 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: OpenSSH HPN
On Wed, Nov 11, 2015 at 07:18:31PM +0100, Dag-Erling Smørgrav wrote: > Slawa Olhovchenkov writes: > > Can you explain what is problem? > > Radical suggestion: read the first email in the thread. I am read and don't understund (you talk about trouble of maintaining the HPN patches). I see patched version in ports. This version maintaining. What is problem? Differnt openssh? Quality of patches? Different branches? ports branch is worse (by some reaason) base branch? > > PS: As I today know, kerberos heimdal is practicaly dead as opensource > > project. Have FreeBSD planed switch to MIT Kerberos? I am know about > > security/krb5. > > We switched from MIT to Heimdal at some point in the past for some > reason I don't remember. MIT and Heimdal are *not* interchangeable at I think because MIT stop development in the past. > the source or binary level, so switching back is not trivial. I am know about this. ___ 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: OpenSSH HPN
On Wed, Nov 11, 2015 at 10:18:08AM -0800, Bryan Drewery wrote: > On 11/11/2015 10:13 AM, Slawa Olhovchenkov wrote: > > On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote: > > > >> Bryan Drewery writes: > >>> Another thing that I did with the port was restore the tcpwrapper > >>> support that upstream removed. Again, if we decide it is not worth > >>> keeping in base I will remove it as default in the port. > >> > >> I want to keep tcpwrapper support - it is another reason why I still > >> haven't upgraded OpenSSH, but to the best of my knowledge, it is far > >> less intrusive than HPN. > > > > Can you explain what is problem? > > I am see openssh in base and openssh in ports (more recent version) > > with same functionaly patches. > > You talk about trouble to upgrade. What is root? > > openssh in base have different vendor and/or license? > > Or something else? > > > > PS: As I today know, kerberos heimdal is practicaly dead as opensource > > project. Have FreeBSD planed switch to MIT Kerberos? > > I am know about security/krb5. > > > > IMHO the problem comes down to time. Patching an upstream project > increases maintenance cost for upgrading it. Every patch adds up. When > you become busy and don't have time to pay attention to every little > change made in a release, hearing 'removed tcpwrappers support' or > 'refactored the code for libssh usage' makes it sound like 1 more > thing you must deal with to upgrade that code base and more effort to > validate that your patches are right. We obviously don't want to just > drop in the latest code and throw it out there as broken. SSH is quite > critical and we want to ensure our changes are still right, and that > doing something like adding tcpwrappers back in won't introduce some > security bug that upstream was coy about. Some for as ports version? Or ports version different? Or port mantainer have more time (this is not to blame for DES)? I am just don't know what is different between port ssh and base ssh. We need ssh 6.x in base, not 7.x as in port (why?) and this is need independed work on pathes? I am missing somehow commonplace for others. ___ 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: OpenSSH HPN
On Wed, Nov 11, 2015 at 03:58:35PM -0800, Bryan Drewery wrote: > > Some for as ports version? > > Or ports version different? > > Or port mantainer have more time (this is not to blame for DES)? > > I am just don't know what is different between port ssh and base ssh. > > We need ssh 6.x in base, not 7.x as in port (why?) and this is need > > independed work on pathes? > > I am missing somehow commonplace for others. > > > > I am the ports maintainer. That was my opinion on why OpenSSH falls > behind. There is no real difference between the base and port version > except that the port version has some more optional patches, and is > easier to push updates for through ports and packages, rather than an > Errata through freebsd-update or a full release to get to the latest > OpenSSH version. This impact only to deploy, not to patch, right? Or bugs found around NPH/NONE patches? > There have been many times where the base version was more up-to-date > than the port as well due to the lack of a maintainer or the previously > mentioned patch blockers. ___ 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: OpenSSH HPN
On Wed, Nov 11, 2015 at 01:32:27PM -0800, Bryan Drewery wrote: > On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote: > > I would also like to remove the NONE cipher > > patch, which is also available in the port (off by default, just like in > > base). > > Fun fact, it's been broken in the port for several months with no > complaints. It was just reported and fixed upstream in the last day and > I wrote in a similar fix in the port. That speaks a lot about its usage > in the port currently. I am try using NPH/NONE with base ssh and confused: don't see performance rise, too complex to enable and too complex for use. ___ 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: OpenSSH HPN
On Thu, Nov 12, 2015 at 12:15:35PM -0500, Allan Jude wrote: > On 2015-11-11 19:06, Slawa Olhovchenkov wrote: > > On Wed, Nov 11, 2015 at 01:32:27PM -0800, Bryan Drewery wrote: > > > >> On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote: > >>> I would also like to remove the NONE cipher > >>> patch, which is also available in the port (off by default, just like in > >>> base). > >> > >> Fun fact, it's been broken in the port for several months with no > >> complaints. It was just reported and fixed upstream in the last day and > >> I wrote in a similar fix in the port. That speaks a lot about its usage > >> in the port currently. > > > > I am try using NPH/NONE with base ssh and confused: don't see > > performance rise, too complex to enable and too complex for use. > > > > ___ > > 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" > > > > I did a few quick (and dirty) benchmarks and it shows that the NONE > cipher definitely makes a difference. Version of OpenSSL also seems to > make a difference, as one might expect. > > Note: openssh from ports seems to link against both base and ports > libcrypto, I am still trying to make sure this isn't corrupting my > benchmark results. > > I am still debugging my dummynet setup to be able to prove that HPN > makes a difference (but it does). > > https://wiki.freebsd.org/SSHPerf I see you test NONE only on OpenSSH_7.1p1/1.0.2d. I am try OpenSSH_6.6.1p1./1.0.1p (both side) I am got about 500Mbit/s. For OpenSSH_6.6.1p1/NONE I am got abot same. I am don't see this combination in you table (OpenSSH_6.6.1p1./1.0.1p ix0 OpenSSH_6.6.1p1./1.0.1p) ___ 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: OpenSSH HPN
On Thu, Nov 12, 2015 at 12:51:30PM -0500, Allan Jude wrote: > On 2015-11-12 12:44, Slawa Olhovchenkov wrote: > > On Thu, Nov 12, 2015 at 12:15:35PM -0500, Allan Jude wrote: > > > >> On 2015-11-11 19:06, Slawa Olhovchenkov wrote: > >>> On Wed, Nov 11, 2015 at 01:32:27PM -0800, Bryan Drewery wrote: > >>> > >>>> On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote: > >>>>> I would also like to remove the NONE cipher > >>>>> patch, which is also available in the port (off by default, just like in > >>>>> base). > >>>> > >>>> Fun fact, it's been broken in the port for several months with no > >>>> complaints. It was just reported and fixed upstream in the last day and > >>>> I wrote in a similar fix in the port. That speaks a lot about its usage > >>>> in the port currently. > >>> > >>> I am try using NPH/NONE with base ssh and confused: don't see > >>> performance rise, too complex to enable and too complex for use. > >>> > >>> ___ > >>> 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" > >>> > >> > >> I did a few quick (and dirty) benchmarks and it shows that the NONE > >> cipher definitely makes a difference. Version of OpenSSL also seems to > >> make a difference, as one might expect. > >> > >> Note: openssh from ports seems to link against both base and ports > >> libcrypto, I am still trying to make sure this isn't corrupting my > >> benchmark results. > >> > >> I am still debugging my dummynet setup to be able to prove that HPN > >> makes a difference (but it does). > >> > >> https://wiki.freebsd.org/SSHPerf > > > > I see you test NONE only on OpenSSH_7.1p1/1.0.2d. > > I am try OpenSSH_6.6.1p1./1.0.1p (both side) > > I am got about 500Mbit/s. > > For OpenSSH_6.6.1p1/NONE I am got abot same. > > > > I am don't see this combination in you table (OpenSSH_6.6.1p1./1.0.1p ix0 > > OpenSSH_6.6.1p1./1.0.1p) > > > > If NONE is actually being used, big warnings will be printed to your screen: > > WARNING: ENABLED NONE CIPHER > WARNING: ENABLED NONE CIPHER > > If you don't see this, NONE is not being used. I am see this, of couse. ___ 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: FreeBsd MCA Panic Crash !!
On Mon, Jan 04, 2016 at 03:34:09AM -0700, shahzaibcb wrote: > Hi, > > We've switched to FreeBSD recently to accomodate large video storage as we > are running video streaming website. So the job of the FreeBSD is to > transcode the uploaded videos using ffmpeg and serve them to users via nginx > webserver but so far our experience is not very good with it. It crashes > every 2-3 days and we're unable to track down the problem. The server specs > are pretty high : > > > Supermicro X5690 (12 cores, 24 threads - 2u) > 96GB RAM > 12x3TB RAID-10 (HBA-LSI9211) > > Here is the screenshot of recent crash : > > http://prntscr.com/9er3pk > > One thing worth mentioning is, before going down there's no load on server, > more or less free RAM usually is around 12GB. We've tried following > solutions so far : > > > - Updated FreeBSD OS > - Replaced 800W PS with 900W > - We've reduced CMOS from MAX(26x) to 18x as suggested in this post Do you try to replace CPU? > http://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic > > The solution we've not performed so far is : > > - Disable mca using (hw.mca.enabled: 0) - As we're getting MCA panics. > > Here is the crash dump : > > [root@cw001 /var/crash]# mcelog --no-dmi --ascii --file core.txt.1 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 3 BANK 5 > MISC 0 ADDR 802bf6a69 > MCG status:MCIP > MCi status: > Uncorrected error > Error enabled > MCi_MISC register valid > MCi_ADDR register valid > Processor context corrupt > MCA: Internal Timer error > STATUS be800400 MCGSTATUS 4 > MCGCAP 1c09 APICID 3 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 44 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 2 BANK 5 > MISC 0 ADDR 802bf6a69 > MCG status:MCIP > MCi status: > Uncorrected error > Error enabled > MCi_MISC register valid > MCi_ADDR register valid > Processor context corrupt > MCA: Internal Timer error > STATUS be800400 MCGSTATUS 4 > MCGCAP 1c09 APICID 2 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 44 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 3 BANK 5 > MISC 0 ADDR 802bf6a69 > MCG status:MCIP > MCi status: > Uncorrected error > Error enabled > MCi_MISC register valid > MCi_ADDR register valid > Processor context corrupt > MCA: Internal Timer error > STATUS be800400 MCGSTATUS 4 > MCGCAP 1c09 APICID 3 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 44 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 2 BANK 5 > MISC 0 ADDR 802bf6a69 > MCG status:MCIP > MCi status: > Uncorrected error > Error enabled > MCi_MISC register valid > MCi_ADDR register valid > Processor context corrupt > MCA: Internal Timer error > STATUS be800400 MCGSTATUS 4 > MCGCAP 1c09 APICID 2 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 44 > > --- > > I showed those Hardware errors to Vendor from whom we purchased Supermicro > servers . This is what he has to say : > > --- > Why do you not made one test environment with CentOS or one other Linux that > you know to use, and see if you have same errors ??? if not than you know > that the errors come from OS not from hardware. ( CentOS, RedHead….work > diferend like FreeBSD – work direct on hardware if you don’t have the right > kernel settings can the server crashed. CentOS , RedHead…. don’t work direct > on hardware and distribute the resource load better and you have better > control and you can better debug one situation) > --- > > Now we're on a black hole and unable to find that either issue with FreeBSD > or Hardware. We're thinking to disable mca in loader.conf but ppl are not > suggesting it. If you guys can help us, it'd be very kind. > > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/FreeBsd-MCA-Panic-Crash-tp6064691.html > Sent from the freebsd-current mailing list archive at Nabble.com. > ___ > 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" ___ 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: CAM Shingled Disk support patches available
On Mon, Jan 18, 2016 at 05:37:04PM -0500, Kenneth D. Merry wrote: > I have a new set of SMR patches available. See below for the full > explanation. > > The primary change here is that I have added SMR support to the ada(4) > driver. I spent some time considering whether to try to make the da(4) and > ada(4) probe infrastructure somewhat common, but in the end concluded it > would be too involved with not enough code reduction (if any) in the end. > > So, although the ideas are similar, the probe logic is separate. > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, > etc.) for SATA protocol shingled drives isn't active. For both the da(4) > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > register down to the drive. > > In the ada(4) case, we need to add the register to struct ccb_ataio and > add support in one or more of the underlying SATA drivers, e.g. ahci(4). > > In the da(4) case, it will require an update of the T-10 SAT spec to > provide a way to pass the Auxiliary register down via the SCSI ATA > PASS-THROUGH command, and then a subsquent update of the SAT layer in > various vendors' SAS controller firmware. At that point, there may be > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and > we may be able to just issue the SCSI version of the commands instead of > composing ATA commands in the da(4) driver. (We'll still need to keep the > ATA passthrough version for a while at least to support controllers that > don't have the updated translation code.) Please, check me: currenly SMR lack of support in SCSI devices? On [hardvare] vendor level? Currenly only SATA controllers compatible with SMR (on command level)? (I am don't talk about FreeBSD support, question about common state). ___ 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: CAM Shingled Disk support patches available
On Tue, Jan 19, 2016 at 11:38:31AM -0500, Kenneth D. Merry wrote: > On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > > On Mon, Jan 18, 2016 at 05:37:04PM -0500, Kenneth D. Merry wrote: > > > > > I have a new set of SMR patches available. See below for the full > > > explanation. > > > > > > The primary change here is that I have added SMR support to the ada(4) > > > driver. I spent some time considering whether to try to make the da(4) > > > and > > > ada(4) probe infrastructure somewhat common, but in the end concluded it > > > would be too involved with not enough code reduction (if any) in the end. > > > > > > So, although the ideas are similar, the probe logic is separate. > > > > > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, > > > etc.) for SATA protocol shingled drives isn't active. For both the da(4) > > > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > > > register down to the drive. > > > > > > In the ada(4) case, we need to add the register to struct ccb_ataio and > > > add support in one or more of the underlying SATA drivers, e.g. ahci(4). > > > > > > In the da(4) case, it will require an update of the T-10 SAT spec to > > > provide a way to pass the Auxiliary register down via the SCSI ATA > > > PASS-THROUGH command, and then a subsquent update of the SAT layer in > > > various vendors' SAS controller firmware. At that point, there may be > > > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and > > > we may be able to just issue the SCSI version of the commands instead of > > > composing ATA commands in the da(4) driver. (We'll still need to keep the > > > ATA passthrough version for a while at least to support controllers that > > > don't have the updated translation code.) > > > > Please, check me: currenly SMR lack of support in SCSI devices? On > > [hardvare] vendor level? Currenly only SATA controllers compatible > > with SMR (on command level)? (I am don't talk about FreeBSD support, > > question about common state). > > No, there are SAS/SCSI SMR drives in development, and there is the SCSI ZBC > spec that defines the command set. I don't know whether any vendors are > shipping SAS/SCSI SMR drives yet. > > You can use SATA drives (SMR or not) with either a SATA controller or a SAS > controller. But the way you talk to a SATA drive through a SAS controller > is with SCSI commands. There is a SCSI spec (SAT) that defines the mapping > of SCSI commands to ATA commands. It has recently been updated to support > mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers > have not caught up with the spec. > > So to use a SATA SMR drive with a SAS controller that doesn't know how to > map SMR commands from SCSI to ATA, you have to send the ATA SMR commands > through the SCSI ATA PASS-THROUGH command. That just bypasses the usual > translations, and allows sending ATA commands in something like their > native form. What in case of expanders an port replicatiors (SATA drives and HBA SAS controllers, of course)? Need expander be compatible with SMR? Or any expander with SATA support automaticly compatible? ___ 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: CAM Shingled Disk support patches available
On Tue, Jan 19, 2016 at 12:06:41PM -0500, Kenneth D. Merry wrote: > On Tue, Jan 19, 2016 at 20:02:52 +0300, Slawa Olhovchenkov wrote: > > On Tue, Jan 19, 2016 at 11:38:31AM -0500, Kenneth D. Merry wrote: > > > > > On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > > > > On Mon, Jan 18, 2016 at 05:37:04PM -0500, Kenneth D. Merry wrote: > > > > > > > > > I have a new set of SMR patches available. See below for the full > > > > > explanation. > > > > > > > > > > The primary change here is that I have added SMR support to the ada(4) > > > > > driver. I spent some time considering whether to try to make the > > > > > da(4) and > > > > > ada(4) probe infrastructure somewhat common, but in the end concluded > > > > > it > > > > > would be too involved with not enough code reduction (if any) in the > > > > > end. > > > > > > > > > > So, although the ideas are similar, the probe logic is separate. > > > > > > > > > > Note that NCQ support for SMR commands (Report Zones, Reset Write > > > > > Pointer, > > > > > etc.) for SATA protocol shingled drives isn't active. For both the > > > > > da(4) > > > > > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > > > > > register down to the drive. > > > > > > > > > > In the ada(4) case, we need to add the register to struct ccb_ataio > > > > > and > > > > > add support in one or more of the underlying SATA drivers, e.g. > > > > > ahci(4). > > > > > > > > > > In the da(4) case, it will require an update of the T-10 SAT spec to > > > > > provide a way to pass the Auxiliary register down via the SCSI ATA > > > > > PASS-THROUGH command, and then a subsquent update of the SAT layer in > > > > > various vendors' SAS controller firmware. At that point, there may > > > > > be > > > > > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, > > > > > and > > > > > we may be able to just issue the SCSI version of the commands instead > > > > > of > > > > > composing ATA commands in the da(4) driver. (We'll still need to > > > > > keep the > > > > > ATA passthrough version for a while at least to support controllers > > > > > that > > > > > don't have the updated translation code.) > > > > > > > > Please, check me: currenly SMR lack of support in SCSI devices? On > > > > [hardvare] vendor level? Currenly only SATA controllers compatible > > > > with SMR (on command level)? (I am don't talk about FreeBSD support, > > > > question about common state). > > > > > > No, there are SAS/SCSI SMR drives in development, and there is the SCSI > > > ZBC > > > spec that defines the command set. I don't know whether any vendors are > > > shipping SAS/SCSI SMR drives yet. > > > > > > You can use SATA drives (SMR or not) with either a SATA controller or a > > > SAS > > > controller. But the way you talk to a SATA drive through a SAS controller > > > is with SCSI commands. There is a SCSI spec (SAT) that defines the > > > mapping > > > of SCSI commands to ATA commands. It has recently been updated to support > > > mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers > > > have not caught up with the spec. > > > > > > So to use a SATA SMR drive with a SAS controller that doesn't know how to > > > map SMR commands from SCSI to ATA, you have to send the ATA SMR commands > > > through the SCSI ATA PASS-THROUGH command. That just bypasses the usual > > > translations, and allows sending ATA commands in something like their > > > native form. > > > > What in case of expanders an port replicatiors (SATA drives and HBA > > SAS controllers, of course)? Need expander be compatible with SMR? Or > > any expander with SATA support automaticly compatible? > > Expanders and port replicators shouldn't matter. The place where you need > to know about SMR is the place where the native ATA or SCSI drive commands > are generated. Expanders and port replicators typically just pass commands > through. Thanks for clarification! ___ 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: HPN and None options in OpenSSH
On Fri, Jan 22, 2016 at 03:31:22PM +0100, Dag-Erling Smørgrav wrote: > The HPN and None cipher patches have been removed from FreeBSD-CURRENT. > I intend to remove them from FreeBSD-STABLE this weekend. Can you do some small discurs about ssh+kerberos? I am try to use FreeBSD with $HOME over kerberoized NFS. For kerberoized NFS gssd need to find cache file "called /tmp/krb5cc_, where is the effective uid for the RPC caller" (from `man gssd`). sshd contrary create cache file for received ticket called /tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is this strong security requirement or [FreeBSD/upstream] can be patched (or introduce option) to use /tmp/krb5cc_ as cache file for received ticket? ___ 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: HPN and None options in OpenSSH
On Sun, Jan 24, 2016 at 03:50:45PM +0100, Dag-Erling Smørgrav wrote:
> Slawa Olhovchenkov writes:
> > Can you do some small discurs about ssh+kerberos?
> > I am try to use FreeBSD with $HOME over kerberoized NFS.
> > For kerberoized NFS gssd need to find cache file "called
> > /tmp/krb5cc_, where is the effective uid for the RPC
> > caller" (from `man gssd`).
> >
> > sshd contrary create cache file for received ticket called
> > /tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is
> > this strong security requirement or [FreeBSD/upstream] can be patched
> > (or introduce option) to use /tmp/krb5cc_ as cache file for
> > received ticket?
>
> I wasn't aware of that. It should be easy to patch, but in the
Yes, I am already do ugly patch for me (2 files need to patch), but patch in
upstream preffered.
> meantime, you can try something like this in .bashrc or whatever:
Imposible. For accessing .bashrc on kerberoized NFS need correct
/tmp/krb5cc_.
> krb5cc_uid="/tmp/krb5cc_$(id -u)"
> if [ -n "${KRB5CCNAME}" -a "${KRB5CCNAME}" != "${krb5ccuid}" ] ; then
> if mv "${KRB5CCNAME}" "${krb5ccuid}" ; then
> export KRB5CCNAME="${krb5ccuid}"
> else
> echo "Unable to rename krb5 credential cache" >&2
> fi
> fi
> unset krb5ccuid
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no
___
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: HPN and None options in OpenSSH
On Sun, Jan 24, 2016 at 04:09:05PM +0100, Dag-Erling Smørgrav wrote: > Slawa Olhovchenkov writes: > > Dag-Erling Smørgrav writes: > > > In the meantime, you can try something like this in .bashrc or > > > whatever: > > Imposible. For accessing .bashrc on kerberoized NFS need correct > > /tmp/krb5cc_. > > /etc/profile, then. OK, what about tcsh, zsh, fish and scp/sftp? ___ 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: HPN and None options in OpenSSH
On Sun, Jan 24, 2016 at 04:21:17PM +0100, Dag-Erling Smørgrav wrote: > Slawa Olhovchenkov writes: > > OK, what about tcsh, zsh, fish and scp/sftp? > > I apologize for trying to help you out by suggesting a hack that works > at least some of the time until I can get a permanent fix in. I should > instead have hopped in my time machine, jumped back a few years, and > fixed the bug before it affected you. No hard feelings? Sorry about not clear exposition. I think this is not hack nor permanent solution and decline modification ssh source. I am already have working solution (localy apllied patch at time `make release`). I can show my ugly patch, but I think his partially not clear and not all edge cases checked. ___ 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: HPN and None options in OpenSSH
On Mon, Jan 25, 2016 at 12:28:20PM +0100, Jan Bramkamp wrote:
>
>
> On 24/01/16 15:50, Dag-Erling Smørgrav wrote:
> > Slawa Olhovchenkov writes:
> >> Can you do some small discurs about ssh+kerberos?
> >> I am try to use FreeBSD with $HOME over kerberoized NFS.
> >> For kerberoized NFS gssd need to find cache file "called
> >> /tmp/krb5cc_, where is the effective uid for the RPC
> >> caller" (from `man gssd`).
> >>
> >> sshd contrary create cache file for received ticket called
> >> /tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is
> >> this strong security requirement or [FreeBSD/upstream] can be patched
> >> (or introduce option) to use /tmp/krb5cc_ as cache file for
> >> received ticket?
> >
> > I wasn't aware of that. It should be easy to patch, but in the
> > meantime, you can try something like this in .bashrc or whatever:
> >
> > krb5cc_uid="/tmp/krb5cc_$(id -u)"
> > if [ -n "${KRB5CCNAME}" -a "${KRB5CCNAME}" != "${krb5ccuid}" ] ; then
> > if mv "${KRB5CCNAME}" "${krb5ccuid}" ; then
> > export KRB5CCNAME="${krb5ccuid}"
> > else
> > echo "Unable to rename krb5 credential cache" >&2
> > fi
> > fi
> > unset krb5ccuid
>
> If $KRB5CCNAME is set during PAM session setup than the pam_exec module
> might allow a reliable implementation along those lines:
>
>- Stop if $KRBCCNAME is invalid (klist -t)
>- Stop if /tmp/krb5cc_$UID is already valid and has enough time left
>- Copy the ticket to /tmp and rename it to /tmp/krb5cc_$UID.
>
> Keep in mind that this approach leaves valid tickets in /tmp after the
> SSH session ends while OpenSSH normally does its best to tie forwarded
> tickets to a SSH session.
Please check me: you propose to add to /etc/pam.d/sshd string like
session requiredpam_exec.so /patch/to/some/scripts
and do above checks in this scripts?
'session' executed after 'account' phase, on 'account' phase NFS must
be already accessed (for checks presents some files in $HOME and
importing/executing/interpretating, like .login_conf, .k5login and
etc).
___
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: Packaging the FreeBSD base system with pkg(8)
On Thu, Jan 28, 2016 at 02:18:06PM +0100, Baptiste Daroussin wrote: > On Thu, Jan 28, 2016 at 12:46:39PM +, Thomas Mueller wrote: > > from Glen Barber: > > > > > As many know, work has been in progress for quite some time to provide > > > the ability to package and upgrade the FreeBSD base system using pkg(8). > > > The majority of the initial implementation has provided much of the core > > > functionality to make this possible, however much work still needs to be > > > done. > > > > (snip) > > > > Would the base system all be one package? > > multiple packages with meta packages to represent the whole base so you have > the > best of both world :) > > > > In Linux, everything is part of a package, even the kernel, but something > > comparable to FreeBSD or NetBSD base system would have many packages. > > > > Will it be possible to upgrade base system with portmaster or portupgrade, > > and would that be better than the current procedure in UPDATING? > > No but one will be able to simply run pkg upgrade (and built himself the > packages) > > > > Would pkg then be able to show a package's required shared libraries > > including shared libraries from the base system? I was recently stung by > > pkg not showing required shared libraries from the base system. > > Yes, but but real usage of it would happen in a second step because of many > rought edges to be deal with. but yes the information would be available > > see: > https://www.youtube.com/watch?v=Br6izhH5P1I > and > https://www.youtube.com/watch?v=v7px6ktoDAI > > for a bigger view of what happened (note that some detail my have change a > bit, > the overall remains the same) What about upgrade strongly outdated system? For example 11.0 at time 18.0? I.e. packages for 11.0 don't available, pkg from 11.0 don't undertund package base from 18.0 and etc. ___ 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: Packaging the FreeBSD base system with pkg(8)
On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote: > >> Yes, but but real usage of it would happen in a second step because of many > >> rought edges to be deal with. but yes the information would be available > >> > >> see: > >> https://www.youtube.com/watch?v=Br6izhH5P1I > >> and > >> https://www.youtube.com/watch?v=v7px6ktoDAI > >> > >> for a bigger view of what happened (note that some detail my have change a > >> bit, > >> the overall remains the same) > > > > What about upgrade strongly outdated system? > > For example 11.0 at time 18.0? I.e. packages for 11.0 don't available, > > pkg from 11.0 don't undertund package base from 18.0 and etc. > > ___ > > 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" > > > > According to our current release schedule, FreeBSD 18.0 will not come > out for 35 years (2051). Schedule may be changed. How you calculate this? As I see next mayor release gone in 2 year. 18-11=7, 14 years, in 2030. Ok, let 15.0 or 16. I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why I can't planed about 11 to 18 upgrade? > The general approach would appear to be just downloading new packages > and updating the system. For a drastic upgrade like that, you'd likely > have to build a newer version of pkg from ports. You kidding. Ports from 18.0 cant't be build on 11.0. This trivial expirence, ports tree incomatible change every 5-6 years. > The approach for offering an upgrade from 10.x to 11.0 will be the more > interesting endeavour. I am guess this is already study. My interests in long run. ___ 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: Packaging the FreeBSD base system with pkg(8)
On Thu, Jan 28, 2016 at 12:04:00PM -0500, Allan Jude wrote: > On 2016-01-28 12:00, Slawa Olhovchenkov wrote: > > On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote: > > > >>>> Yes, but but real usage of it would happen in a second step because of > >>>> many > >>>> rought edges to be deal with. but yes the information would be available > >>>> > >>>> see: > >>>> https://www.youtube.com/watch?v=Br6izhH5P1I > >>>> and > >>>> https://www.youtube.com/watch?v=v7px6ktoDAI > >>>> > >>>> for a bigger view of what happened (note that some detail my have change > >>>> a bit, > >>>> the overall remains the same) > >>> > >>> What about upgrade strongly outdated system? > >>> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available, > >>> pkg from 11.0 don't undertund package base from 18.0 and etc. > >>> ___ > >>> 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" > >>> > >> > >> According to our current release schedule, FreeBSD 18.0 will not come > >> out for 35 years (2051). > > > > Schedule may be changed. > > How you calculate this? As I see next mayor release gone in 2 year. > > 18-11=7, 14 years, in 2030. > > Ok, let 15.0 or 16. > > I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why > > I can't planed about 11 to 18 upgrade? > > > > You are correct sorry, I was thinking of the 5 year lifecycle of each > release, not the 2 year cadence of new releases. > > Upgrading from an End-of-Life release is specifically not supported. Where is documented? Curently source based upgraded suported to last stable direct from 7.0. Last supported release now is 9.3. Upgrade to 7.0 supported from 5.3. Upgrade to 5.3 supported from, hmm, I think last 3-STABLE (or any 3.x?). Upgrade from 2.x to 3.x is aout-elf upgrade. As result, source upgrade supported in 3 step upgrade from any current elf release to last stable. Because ALL source history preserved. I think preserving all binary packages from previos releases is imposible. > It is not a burden that RE@ should have to deal with. Please distinguish 'not supported' and 'prohibited'. This position reduce to 'lost time to system upgrade? format C: and install any other OS with more liberal upgrade policy'. Time to system upgrade may be lost by multiple reasons, for example -- lost previos staff. ___ 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: Packaging the FreeBSD base system with pkg(8)
On Thu, Jan 28, 2016 at 09:28:32AM -0800, NGie Cooper wrote: > > > On Jan 28, 2016, at 08:06, Slawa Olhovchenkov wrote: > > > ... > > > What about upgrade strongly outdated system? > > For example 11.0 at time 18.0? I.e. packages for 11.0 don't available, > > pkg from 11.0 don't undertund package base from 18.0 and etc. > > This is an important question to ask and solve. There might be > points in time where seamless upgrades are not possible, and instead > you need to hop from release to release (this is not ideal, but it > could happen). I see two side of this problem: support in sofware and support in infrastructure (ftp.freebsd.org and etc.). Because pkg is not part of base FreeBSD and live in ports -- this hops need to preserve (and testing?) packages collections for all past releases and don't move it to archive. And regular resigning package databases. And I miss somewere. > For instance, at $work we're allowing upgrades from version X to Y, > and Y to Z, but not direct upgrades from X to Z. Part of the > rationale behind this change is, deprecation of platforms and the > change in upgrade framework, which requires upgrading from blessed > releases proven to work with the new framework. This is common practic, yes. This is acceptably if possible got all necessary in time 18.0 for upgrade from 11.0. ___ 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"
