[Bug 231705] pom(6) incorrect output

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231705

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 210432] vt(4) does not support boot time splash screen

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210432

Mateusz Piotrowski <0...@freebsd.org> changed:

   What|Removed |Added

 Status|New |Open
 CC||0...@freebsd.org
   Assignee|b...@freebsd.org|0...@freebsd.org

--- Comment #3 from Mateusz Piotrowski <0...@freebsd.org> ---
I've started working on this feature.

I'm happy to listen to your suggestions & ideas.

Project's wiki:
https://wiki.freebsd.org/MateuszPiotrowski/ImproveVtSplashScreenSupport

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 220344] [patch] Unhardcode vt(4) splash screen colors

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220344

Mateusz Piotrowski <0...@freebsd.org> changed:

   What|Removed |Added

 Status|New |Open
   Assignee|b...@freebsd.org|0...@freebsd.org
 CC||0...@freebsd.org
 Blocks||210432

--- Comment #1 from Mateusz Piotrowski <0...@freebsd.org> ---
Thanks for the patch. I've started working on improving vt(4) splash screen
support recently and I am not yet sure if I am going to use your patch.

Anyway, I'll block the main Bugzilla PR (210432) with this PR so that we don't
forget about it.


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210432
[Bug 210432] vt(4) does not support boot time splash screen
-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231713] mmc_calculate_clock() does not work properly for cards with bus_timing_normal only

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231713

Bug ID: 231713
   Summary: mmc_calculate_clock() does not work properly for cards
with bus_timing_normal only
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: sebastian.hu...@embedded-brains.de

We have

static int
mmc_calculate_clock(struct mmc_softc *sc)
{
...
/*
 * HS400 must be tuned in HS200 mode, so in case of HS400 we begin
 * with HS200 following the sequence as described in "6.6.2.2 HS200
 * timing mode selection" of the eMMC specification v5.1, too, and
 * switch to max_timing later.  HS400ES requires no tuning and, thus,
 * can be switch to directly, but requires the same detour via high
 * speed mode as does HS400 (see mmc_switch_to_hs400()).
 */
hs400 = max_timing == bus_timing_mmc_hs400;
timing = hs400 == true ? bus_timing_mmc_hs200 : max_timing;
for (i = 0; i < sc->child_count; i++) {
ivar = device_get_ivars(sc->child_list[i]);
if ((ivar->timings & ~(1 << bus_timing_normal)) == 0)
continue;
...
/* Set clock (must be done before initial tuning). */
mmcbr_set_clock(dev, max_dtr);
mmcbr_update_ios(dev);
...
}
(void)mmc_select_card(sc, 0);
return (max_dtr);
}

So, for cards with ivar->timings == bus_timing_normal the mmcbr_set_clock(dev,
max_dtr) is not called. This way the clock stays at SD_MMC_CARD_ID_FREQUENCY ==
400kHz. I think this problem was introduced with:

commit 398d5fc6afb7ce20f0cf9ecc4fe286e72afdbf29
Author: marius 
Date:   Sun Jul 23 16:11:47 2017 +

o Add support for eMMC HS200 and HS400 bus speed modes at 200 MHz to
  sdhci(4), mmc(4) and mmcsd(4). For the most part, this consists of:

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


CASH FOR USED AND VINTAGE GEAR

2018-09-25 Thread sa...@londonvintageguitars.com
View online version

 
 
This email has been sent to freebsd-bugs@freebsd.org, click here to unsubscribe
.
 
Denmark Street Guitars | London | UK 
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231080] callout struture corruption and panic

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231080

--- Comment #16 from Sean Bruno  ---
INVARIANTS does not crash.  I waited for several days and no fault detected.

I updated the hosts to ALPHA6 and one of the hosts crashed after a few days of
uptime.

I have dumped the crash/kernel/debug into
freefall.freebsd.org:~sbruno/service1.rbsd.tar again.  It still looks like
corruption of the callout structs.  

I can try bisecting, but I'm unsure how to make the machine reliably fall over
except to wait for 48 hours.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231457] Out of swap space on ZFS

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231457

--- Comment #2 from Mike  ---
Update: since adjusting vfs.zfs.arc_max to half RAM (rather than all of it
which was an oversight) and rebooting, problem has not manifested.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231724] No work consoles at booting 11.2-releng

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231724

Bug ID: 231724
   Summary: No work consoles at booting 11.2-releng
   Product: Base System
   Version: 11.2-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: y...@shvets.name

One of my servers (Xeon X3330 on TYAN Toledo S5211) is loaded without work
consoles.
During booting displays: Booting ... And nothing more.

All main services are loads: ssh, mail, etc. The server works,
but there are no devices created: ttyv0, ttyv1, ttyv2, … etc
and no work consoles.

In the same time consoles works, if vt (virtual terminal console driver) to
change to sc in
/boot/loader.conf:

kern.vty=sc

How to make work vt?

dmesg with sc:
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.2-RELEASE-p3 #0 r338696: Sun Sep 16 01:28:53 EEST 2018
root@gw1:/usr/obj/usr/src/sys/KERNEL amd64
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM
6.0.0)
CPU: Intel(R) Xeon(R) CPU   X3330  @ 2.66GHz (2660.06-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
 
Features=0xbfebfbff
 
Features2=0xc08e3fd
  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 4294967296 (4096 MB)
avail memory = 4088619008 (3899 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
ioapic0  irqs 0-23 on motherboard
SMP: AP CPU #3 Launched!
SMP: AP CPU #1 Launched!
SMP: AP CPU #2 Launched!
Timecounter "TSC-low" frequency 1330027676 Hz quality 1000
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
nexus0
smbios0:  at iomem 0xf6c30-0xf6c4e on motherboard
smbios0: Version: 2.33
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 on
acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 450
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Event timer "HPET3" frequency 14318180 Hz quality 440
atrtc0:  port 0x70-0x71 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  irq 16 at device 1.0 on pci0
pci1:  on pcib1
siis0:  port 0x2000-0x207f mem
0xf4104000-0xf410407f,0xf410-0xf4103fff irq 16 at device 0.0 on pci1
siisch0:  at channel 0 on siis0
siisch1:  at channel 1 on siis0
(noperiph:siisch0:0:-1:): rescan already queued
(noperiph:siisch1:0:-1:): rescan already queued
uhci0:  port 0x1820-0x183f irq 16 at device
26.0 on pci0
usbus0 on uhci0
usbus0: 12Mbps Full Speed USB v1.0
uhci1:  port 0x1840-0x185f irq 17 at device
26.1 on pci0
usbus1 on uhci1
usbus1: 12Mbps Full Speed USB v1.0
ehci0:  mem 0xf4601800-0xf4601bff irq
18 at device 26.7 on pci0
usbus2: EHCI version 1.0
usbus2 on ehci0
usbus2: 480Mbps High Speed USB v2.0
pcib2:  irq 16 at device 28.0 on pci0
pcib2: [GIANT-LOCKED]
pci2:  on pcib2
pcib3:  at device 0.0 on pci2
pci3:  on pcib3
pcib4:  irq 16 at device 28.4 on pci0
pcib4: [GIANT-LOCKED]
pci4:  on pcib4
em0:  port 0x3000-0x301f mem
0xf408-0xf409,0xf400-0xf407 irq 16 at device 0.0 on pci4
em0: Using an MSI interrupt
em0: Ethernet address: 00:e0:81:ba:ad:90
em0: netmap queues/slots: TX 1/1024, RX 1/1024
pcib5:  irq 17 at device 28.5 on pci0
pcib5: [GIANT-LOCKED]
pci5:  on pcib5
em1:  port 0x4000-0x401f mem
0xf428-0xf429,0xf420-0xf427 irq 17 at device 0.0 on pci5
em1: Using an MSI interrupt
em1: Ethernet address: 00:e0:81:ba:ad:91
em1: netmap queues/slots: TX 1/1024, RX 1/1024
uhci2:  port 0x1860-0x187f irq 16 at device
29.0 on pci0
usbus3 on uhci2
usbus3: 12Mbps Full Speed USB v1.0
uhci3:  port 0x1880-0x189f irq 17 at device
29.1 on pci0
usbus4 on uhci3
usbus4: 12Mbps Full Speed USB v1.0
uhci4:  port 0x18a0-0x18bf irq 18 at device
29.2 on pci0
usbus5 on uhci4
usbus5: 12Mbps Full Speed USB v1.0
uhci5:  port 0x18c0-0x18df irq 19 at device
29.3 on pci0
usbus6 on uhci5
usbus6: 12Mbps Full Speed USB v1.0
ehci1:  mem 0xf4601c00-0xf4601fff irq
1

[Bug 231724] No work consoles at booting 11.2-releng

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231724

Yaroslav Shvets  changed:

   What|Removed |Added

 CC||y...@shvets.name
   Keywords||vt

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231724] No work consoles at booting 11.2-releng

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231724

Mark Linimon  changed:

   What|Removed |Added

   Keywords||regression

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231725] [ZFS] cannot disable vfs.zfs.compressed_arc_enabled on 10.4-RELEASE

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231725

Bug ID: 231725
   Summary: [ZFS] cannot disable vfs.zfs.compressed_arc_enabled on
10.4-RELEASE
   Product: Base System
   Version: 10.4-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: carlos.po...@gmail.com

Dear FreeBSD Bugzilla community,

I'm having some kernel panics on one production server after updating FreeBSD
from 10.3-RELEASE to 10.4-RELEASE.

I noticed that vfs.zfs.compressed_arc_enabled appeared in 10.4-RELEASE, and
this feature make FreeBSD unstable in our VMware ESXi 6.0 environment. We had
some issues with 11.x in the past, and as a workaround, we switched back to
10.3-RELEASE.

More details in this thread I opened in the community forum:
https://forums.freebsd.org/threads/kernel-panic-after-upgrading-to-11-1.62499/

I tried to set: vfs.zfs.compressed_arc_enabled="0" in /boot/loader.conf but the
parameter keeps "1" after reboot.

I tried the same on a fresh 11.2-RELEASE server and the configuration was
successful.

Can we have a look at this?

Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231725] [ZFS] cannot disable vfs.zfs.compressed_arc_enabled on 10.4-RELEASE

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231725

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|f...@freebsd.org
   Keywords||regression

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 229235] vt(4) of 11.2-RELEASE is broken with hardware dependent problem.

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229235

free...@givesno.info changed:

   What|Removed |Added

 CC||free...@givesno.info

--- Comment #19 from free...@givesno.info ---
(In reply to Yasuhiro KIMURA from comment #11)
With regard to the re0 watchdog timeout, it's a known issue with the built-in
FreeBSD driver.  I compiled the latest Realtek driver (1.95) for the pfSense
project's 2.4.4 release (based on FreeBSD 11.2-RELEASE-p3) which works fine. 
If you're interested, I posted the binary here:
https://forum.netgate.com/topic/135850/official-realtek-driver-binary-1-95-for-2-4-4-release

Instructions for how to use it are here:
https://forum.netgate.com/topic/133536/official-realtek-driver-v1-95-binary

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231058] no support for active PS/2 multiplexing results in erratic behaviour of Synaptics touchpad on HP 8560w

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231058

--- Comment #2 from Michael Figiel  ---
Created attachment 197498
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=197498&action=edit
acpidump ps2m section

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231058] no support for active PS/2 multiplexing results in erratic behaviour of Synaptics touchpad on HP 8560w

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231058

--- Comment #3 from Michael Figiel  ---
(In reply to Vladimir Kondratyev from comment #1)
Hello Vladimir,
sorry for responding late and thank you for looking into it. 

I toyed with the controller and can give you some more info:
the machine (hp 8560w) claims to have following devices attached to aux port of
the i8042:
port 0: the trackpoint, the one returning ext. id 0x46
port 1,2 : nothing
port 3: touchpad, returning id 0x47

I've attached acpi PS2M section from the HP 8560w, it lists two id strings
starting with SYN -- maybe both devices are Synaptics' ?

The active multiplexer implementation on 8560w doesn't work as expected: I
can't disable single ports (that should be possible by sending 0x9[0-3] and
0xA7 sequence), so I always get data from both devices.

I'll attach the log of the initialization of the 0x47 device. It doesn't
advertise passthrough.

The trackpoint is recognized as a generic PS/2 mouse, it reports only two
buttons, but actually all three are working.

I've got two mostly working configurations: 
1) I send all commands to port 3, to the touchpad, and get working Synaptics
touchpad, with occasional device resests if I touch the trackpoint or any of
it's buttons (no passthrough on that machine, at least not advertised by the
touchpad) -- you are right, the trackpoint sends generic ps2 packets, but
additionally there ist the issue of interleaving both data streams.

2) I send all commands to port 0, and get a generic PS2 mouse. I removed the id
0x46 from psm.c, so this is the situation before your patch. All buttons work, 
but  it's two times button one, two times two and two times button three,
without any possiblity to tell them apart - not a big deal. I think,
occasionally there are problems with interleaving both streams but generally it
works well. But then there is no point enabling multiplexing in first place...

> The simpler way is to enable multiplexing only for synaptics devices and just 
> > only for configuring/querying stage and return to legacy mode after.
> trackpad/trackpoint packet separation problem should be solved in that case.
This amounts to hidden multiplexing -- the data streams of both devices will be
interleaved, at the level of three bytes. Additionally, the controller might
try to be helpfull, and mangle the data (e.g. using bit 3 of byte one of a
packet to mark the source, a problem with six byte packets). But I haven't
tried it - that's just what this document claims. 

I think, with this special hardware there are only two viable solutions:
1) removing the 0x46 id, leaving i8042 in legacy mode and using the touchpad
and the stick as one generic ps/2 device. One has no gestures, no multi-touch
(two fingers scrolling), but I think it's possible to configure the scrolling
zones on the edges in X11. Actually that sounds like reverting your change :-/

2) to implement a proper multiplexing driver

If you want any logs/traces I'd be happy to provide them. I think it should be
possible to give you access via ssh to the 8560w, at least for a few days.

But if you think that's not worth the effort, it's OK, because solution 1) is
good enough for me, I can maintain a patch locally, there is no point in 
reverting your change if it works well for others.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231058] no support for active PS/2 multiplexing results in erratic behaviour of Synaptics touchpad on HP 8560w

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231058

--- Comment #4 from Michael Figiel  ---
Created attachment 197499
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=197499&action=edit
Synaptics touchpad initialization log

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231058] no support for active PS/2 multiplexing results in erratic behaviour of Synaptics touchpad on HP 8560w

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231058

--- Comment #5 from Michael Figiel  ---
Created attachment 197500
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=197500&action=edit
trackpoint initialization log

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231334] 12-ALPHA's make installworld DESTDIR=/mnt/current fails due to improper ntpd user check of /etc/passwd file

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231334

Kubilay Kocak  changed:

   What|Removed |Added

 Status|New |Open
Summary|[patch] 12-ALPHA's make |12-ALPHA's make
   |installworld|installworld
   |DESTDIR=/mnt/current fails  |DESTDIR=/mnt/current fails
   |due to improper ntpd user   |due to improper ntpd user
   |check of /etc/passwd file   |check of /etc/passwd file
   Assignee|b...@freebsd.org|i...@freebsd.org
   Keywords||needs-qa

--- Comment #5 from Kubilay Kocak  ---
Assign to original committer of ntp uid additions [1] to review the DESTDIR
patch for validity and resolution

[1] base r336525
base r336526
base r336562

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231080] callout struture corruption and panic

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231080

--- Comment #17 from Mark Johnston  ---
(In reply to Sean Bruno from comment #16)
The new kernel dump is more useful.  The callout looks like this:

$2 = {
  c_links = {
le = {
  le_next = 0x11777be9162acbc1,
  le_prev = 0x80c9a01a
},
sle = {
  sle_next = 0x11777be9162acbc1
},
tqe = {
  tqe_next = 0x11777be9162acbc1,
  tqe_prev = 0x80c9a01a
}
  },
  c_time = 577765376,
  c_precision = 0,
  c_arg = 0x6,
  c_func = 0x158,
  c_lock = 0x0,
  c_flags = 0,
  c_iflags = 0,
  c_cpu = 0
}
(kgdb) x/s 0x80c9a01a
0x80c9a01a: "dr->dt.di.dr_mtx"

So the second long word is the beginning of the dr_mtx field of a
dbuf_dirty_record_t.  (The 0x6 indicates that the lock is already destroyed.)
It thus looks like the structure containing the callout was freed and
reused for a dbuf_dirty_record_t.  These records are allocated using malloc(9)
and would come from the 512 byte zone (the mutex is at byte offset 192), so
we're looking for a structure between 256 and 512 bytes in size containing
a struct callout at byte offset 184, assuming that nothing called uma_reclaim()
before the dbuf_dirty_record_t was allocated.  Since there's been very little
page daemon activity on this system, I think that's a safe assumption for now.

Using ctfdump -t on the kernel and modules, I find two structures with these
properties: struct ata_request and struct lle_entry.  The latter seems to be a
more likely candidate for use-after-free.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231080] callout struture corruption and panic

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231080

--- Comment #18 from Mark Johnston  ---
(In reply to Mark Johnston from comment #17)
s/lle_entry/llentry/

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 231457] Out of swap space on ZFS

2018-09-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231457

--- Comment #3 from di...@dz.dn.ua ---
vfs.zfs.arc_max = 0.6 * RAM
by default, at least on 1/2/4G RAM.
Tune to 0.5 * RAM in /boot/loader.conf (and reboot) has no effect in my case.

Remember that you need to occupying all physical memory, and almost the entire
swap space, to reproduce this problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"