Re: vt(4) chops off the leftmost three columns
> On Jan 12, 2017, at 18:13, Ed Maste wrote: > > On 12 January 2017 at 18:50, Alan Somers wrote: >> I've seen three separate machines where FreeBSD11's vt(4) driver chops >> off the leftmost three columns of the screen. Rendering simply starts >> at the beginning of the fourth column. In all cases, setting >> "kern.vty=sc" corrects the problem. > > Or try setting hw.vga.textmode=1 > > Did you observe this with IPMI redirected video or an attached monitor > (or a combination)? I’ll have to double check, but I’m pretty sure I’ve seen this with my Haswell box (Escher) over VGA using my projector. Thanks, -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
Re: vt(4) chops off the leftmost three columns
On 12 January 2017 at 18:50, Alan Somers wrote: > I've seen three separate machines where FreeBSD11's vt(4) driver chops > off the leftmost three columns of the screen. Rendering simply starts > at the beginning of the fourth column. In all cases, setting > "kern.vty=sc" corrects the problem. Or try setting hw.vga.textmode=1 Did you observe this with IPMI redirected video or an attached monitor (or a combination)? ___ 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: vt(4) chops off the leftmost three columns
Alan Somers wrote: I've seen three separate machines where FreeBSD11's vt(4) driver chops off the leftmost three columns of the screen. Rendering simply starts at the beginning of the fourth column. In all cases, setting "kern.vty=sc" corrects the problem. The three different systems are: 1) Haswell CPU with SuperMicro X10DRH-IT motherboard 2) Gainestown CPU with Dell S99 motherboard 3) Via Nano X2 CPU with VIA EPIA-M900 motherboard I don't have time to hack on vt myself as long as sc works fine. But if there's any way that I can help a vt developer, I'd be happy to do it. -Alan VT(4) already has open problems that no one is working on so may as well add this as another pr. VT should have had better testing before becoming the default in 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"
TSC as timecounter makes system lag
Hi all, since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium T4200 notebook lagged a lot. System time was running a lot slower, sometimes even looked like it freezed. Keystroke repeat rate was slow too. Since system time is slow, I tried to change timecounter from default TSC to HPET. And it resumed normal immediately. The same world binary works fine on other Ivybridge and Haswell desktops, so I assume this may be related to CPU or mainboard generations. version is FreeBSD jsli-nb 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311687: Mon Jan 9 04:07:27 CST 2017 jsli@4cbsd:/personal/freebsd/obj/x64/personal/freebsd/fbsdsrc/sys/MINIMAL-NODEBUG amd64 and CPU is CPU: Pentium(R) Dual-Core CPU T4200 @ 2.00GHz (1995.04-MHz K8-class CPU) Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10 Features=0xbfebfbff Features2=0xc00e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics Tested similar OS rev on another Intel Core 2 Duo E7400 Wolfdale (the same generation as the Pentium T4200). The same lag also happens on it. BTW on both system, cpuX:timer interrupts do not fire at all and count remains 0. -Jia-Shiun ___ 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"
vt(4) chops off the leftmost three columns
I've seen three separate machines where FreeBSD11's vt(4) driver chops off the leftmost three columns of the screen. Rendering simply starts at the beginning of the fourth column. In all cases, setting "kern.vty=sc" corrects the problem. The three different systems are: 1) Haswell CPU with SuperMicro X10DRH-IT motherboard 2) Gainestown CPU with Dell S99 motherboard 3) Via Nano X2 CPU with VIA EPIA-M900 motherboard I don't have time to hack on vt myself as long as sc works fine. But if there's any way that I can help a vt developer, I'd be happy to do it. -Alan ___ 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"
build world broken on r311461
Broken on camcontrol clang -O2 -pipe -DRESCUE -MD -MF.depend.camcontrol.o -MTcamcontrol.o -std=gn u99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W - Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -W return-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wc ast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-st yle-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-argum ents -c /usr/src/sbin/camcontrol/camcontrol.c -o camcontrol.o /usr/src/sbin/camcontrol/camcontrol.c:4000:2: error: implicit declaration of function 'scsi_mode_sense_subpage' is invalid in C99 [-Werror,-Wimplicit-function-declaration] scsi_mode_sense_subpage(&ccb->csio, ^ /usr/src/sbin/camcontrol/camcontrol.c:4000:2: note: did you mean 'scsi_mode_sense_len'? /usr/include/cam/scsi/scsi_all.h:3987:7: note: 'scsi_mode_sense_len' declared here voidscsi_mode_sense_len(struct ccb_scsiio *csio, u_int32_t retries, ^ 1 error generated. *** Error code 1 Stop. make[6]: stopped in /usr/src/sbin/camcontrol root@valfenda:/usr # uname -a FreeBSD valfenda 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311461: Thu Jan 5 22:46:38 UTC 2017 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@valfenda:/usr # root@valfenda:/usr # cat /etc/make.conf NO_USE_GCC="YES" CC=clang CXX=clang++ CPP=clang-cpp --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ ___ 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: r311568 makes freerdp very slow
On Thursday, January 12, 2017 12:42:11 PM Shawn Webb wrote: > On Thu, Jan 12, 2017 at 06:05:08PM +0100, Jakob Alvermark wrote: > > Hi, > > > > r311568 Set MORETOCOME for AIO write requests on a socket. > > > > After this commit freerdp is very slow. > > > > Before the password prompt would appear immediately when connecting to a > > server. Now it takes 5-10 seconds. After entering the password, another > > 5-10 seconds until I am connected. > > Once connected, there is a considerable lag. > > > > What could be the problem? > > I don't know what the problem is, but I am seeing the same symptom. Can you get a ktrace of the freerdp process during this? The commit should only be setting MORETOCOME if multiple aio_write requests are queued to the same socket (so that TCP can batch them into a single packet). However, it should not affect an application just calling aio_write() on a socket once. -- 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: r311568 makes freerdp very slow
On Thu, Jan 12, 2017 at 06:05:08PM +0100, Jakob Alvermark wrote: > Hi, > > r311568 Set MORETOCOME for AIO write requests on a socket. > > After this commit freerdp is very slow. > > Before the password prompt would appear immediately when connecting to a > server. Now it takes 5-10 seconds. After entering the password, another > 5-10 seconds until I am connected. > Once connected, there is a considerable lag. > > What could be the problem? I don't know what the problem is, but I am seeing the same symptom. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
r311568 makes freerdp very slow
Hi, r311568 Set MORETOCOME for AIO write requests on a socket. After this commit freerdp is very slow. Before the password prompt would appear immediately when connecting to a server. Now it takes 5-10 seconds. After entering the password, another 5-10 seconds until I am connected. Once connected, there is a considerable lag. What could be the problem? Best regards, Jakob Alvermark ___ 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: CURRENT: em0 NIC freezes under heavy I/O on net
On 01/11/17 01:27, O. Hartmann wrote: > Running recent CURRENT (FreeBSD 12.0-CURRENT #5 r311919: Wed Jan 11 08:24:28 > CET 2017 amd64), the system freezes when doing a rsync over automounted > (autofs) NFSv4 filesystem, mounted from another CURRENT server (same revision, > but with BCM NICs). > > The host in question is a Fujitsu Celsius M740 equipted with an Intel NIC: > > [...] > em0: port 0xf020-0xf03f mem > 0xfb30-0xfb31,0xfb339000-0xfb339fff at device 25.0 numa-domain 0 on > pci1 em0: attach_pre capping queues at 1 em0: using 1024 tx descriptors and > 1024 rx descriptors em0: msix_init qsets capped at 1 > em0: Unable to map MSIX table > em0: Using an MSI interrupt > em0: allocated for 1 tx_queues > em0: allocated for 1 rx_queues > em0: netmap queues/slots: TX 1/1024, RX 1/1024 > [...] > > The pciconf output reveals: > > em0@pci0:0:25:0:class=0x02 card=0x11ed1734 chip=0x153a8086 > rev=0x05 > hdr=0x00 vendor = 'Intel Corporation' > device = 'Ethernet Connection I217-LM' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xfb30, size 131072, enabled > bar [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled > bar [18] = type I/O Port, range 32, base 0xf020, size 32, enabled > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 13[e0] = PCI Advanced Features: FLR TP > > I have a customized kernel. The NIC has revealed itself all the time as an > "emX" device (never as igbX). The kernel contains device netmap (if > relevevant). > > The phenomenon: > > Syncing a poudriere repository between to remote hosts, I use rsync on a NGSv4 > exported filesystem, mounted via AUTOFS. So far, this work two days ago > perfectly. Since yesterday, syncing brings down the network connection - the > connection is simply dead. Terminating the rsync, bringing em0 down and up > again doesn't help much, for short moments, the connection is established, but > dies within seconds. Restarting via "service netif restart" all network > services have the same effect: after the desaster, it is impossible for me to > bring back the NIC/connection to normal, I have to reboot. The same happens > when having heavy network load, but it takes a time and even rsync isn't > "deadly" within the same timeframe - it takes sometimes a couple of seconds, > another takes only one or two seconds to make the connection die. > > I checked with dd'ing a large file over that connection, it takes several > seconds then to make the connection freezing (so, someone could reproduce iy > not ncessarily using rsync). > > Kind regards, > > oh If you have the time today or tomorrow. Can you please capture 'sysctl dev.em.0' and post it here? In addition, I would like to have this patch tested in your configuration: https://people.freebsd.org/~sbruno/em_tx_limit.diff Finally, if you have any loader.conf entries for hw.em, please post them as well. sean signature.asc Description: OpenPGP digital signature
r311977: kernel build failure when NANDFS in kernel
On r311977, buildkernel fails with the error shown below. Kernel ist
customised and "options NANDFS" has been added as well as "device nand"
- the error shown suggest that is has to do with NANDFS.
[...]
===> cc/cc_cdg (all)
--- nand_geom.o ---
/usr/src/sys/dev/nand/nand_geom.c:419:2: error: must use 'struct' tag
to refer to type 'disk' disk->d_rotation_rate = DISK_RR_NON_ROTATING;
^
struct
/usr/src/sys/dev/nand/nand_geom.c:419:6: error: expected identifier or
'(' disk->d_rotation_rate = DISK_RR_NON_ROTATING;
^
2 errors generated.
*** [nand_geom.o] Error code 1
___
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_HEAD_amd64_gcc - Build #1761 - Fixed
FreeBSD_HEAD_amd64_gcc - Build #1761 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1761/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1761/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1761/console Change summaries: 311974 by sobomax: Fix slight type mismatch between so_options defined in sys/socketvar.h and tw_so_options defined here which is supposed to be a copy of the former (short vs u_short respectively). Switch tw_so_options to be "signed short" to match the type of the field it's inherited from. 311972 by ngie: Add __BIT and __BITS macros from NetBSD to help support new testcases MFC after: 1 week 311971 by mav: Report random flash storage as non-rotating to GEOM_DISK. While doing it, introduce respective constants in geom_disk.h. MFC after: 1 week 311969 by ngie: Remove __HAVE_LONG_DOUBLE #define from t_strtod.c and place it in Makefile This is to enable support in other testcases Inspired by lib/msun/tests/Makefile . MFC after: 1 week 311968 by ngie: Fix lib/libc/sys/access_test after r311925 sys/param.h needs to be #included in order for __FreeBSD_version to be checked MFC after: 13 days 311964 by cem: g_raid: Prevent tasters from attempting excessively large reads Some g_raid tasters attempt metadata reads in multiples of the provider sectorsize. Reads larger than MAXPHYS are invalid, so detect and abort in such situations. Spiritually similar to r217305 / PR 147851. PR: 214721 Sponsored by: Dell EMC Isilon 311963 by rpokala: Remove writability requirement for single-mbuf, contiguous-range m_pulldown() m_pulldown() only needs to determine if a mbuf is writable if it is going to copy data into the data region of an existing mbuf. It does this to create a contiguous data region in a single mbuf from multiple mbufs in the chain. If the requested memory region is already contiguous and nothing needs to change, the mbuf does not need to be writeable. Submitted by: Brian Mueller Reviewed by:bz MFC after: 1 week Sponsored by: Panasas Differential Revision: https://reviews.freebsd.org/D9053 311962 by arybchik: sfxge(4): stats refresh in SW should depend on HW update period The period should be taken into account by the function which refreshes driver stats. Reviewed by:philip Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D9130 311961 by arybchik: sfxge(4): do not ignore requested MAC stats update period Firmware version which takes PERIOD_MS parameter into account is required. Reviewed by:philip Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D9129 311958 by scottl: Print out the number of queues/MSIx vectors. Sponsored by: Netflix 311954 by ian: Rework tty_drain() to poll the hardware for completion, and restore drain timeout handling to historical freebsd behavior. The primary reason for these changes is the need to have tty_drain() call ttydevsw_busy() at some reasonable sub-second rate, to poll hardware that doesn't signal an interrupt when the transmit shift register becomes empty (which includes virtually all USB serial hardware). Such hardware hangs in a ttyout wait, because it never gets an opportunity to trigger a wakeup from the sleep in tty_drain() by calling ttydisc_getc() again, after handing the last of the buffered data to the hardware. While researching the history of changes to tty_drain() I stumbled across some email describing the historical BSD behavior of tcdrain() and close() on serial ports, and the ability of comcontrol(1) to control timeout behavior. Using that and some advice from Bruce Evans as a guide, I've put together these changes to implement the hardware polling and restore the historical timeout behaviors... - tty_drain() now calls ttydevsw_busy() in a loop at 10 Hz to accomodate hardware that requires polling for busy state. - The "new historical" behavior for draining during close(2) is retained: the drain timeout is "1 second without making any progress". When the 1-second timeout expires, if the count of bytes remaining in the tty layer buffer is smaller than last time, the timeout is extended for another second. Unfortunately, the same logic cannot be extended all the way down to the hardware, because the interface to that layer is a simple busy/not-busy indication. - Due to the previous point, an application that needs a guarantee that all data has been transmitted must use TIOCDRAIN/tcdrain(3) before calling close(2). - The historical behavior of honoring the drainwait setting for TIOCDRAIN (used by tcdrain(3)) is restored. - The historical kern.drainwait sysctl to control the global default drainwait time is restored, but is now named kern.tty_drainwait. - The historical def
