kern/147951: VIMAGE + CARP = kernel crash

2010-06-17 Thread Konstantin 

Number: 147951
Category:   kern
Synopsis:   VIMAGE + CARP = kernel crash
Confidential:   no
Severity:   serious
Priority:   medium
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Thu Jun 17 20:20:02 UTC 2010
Closed-Date:
Last-Modified:
Originator: Konstantin
Release:8.0 RELEASE, 8.1 BETA 1
Organization:
VAENGA telecom
Environment:
FreeBSD WEB2 8.0-RELEASE FreeBSD 8.0-RELEASE #1: Thu Jun 17 19:38:21 MSD 2010   
  r...@web2:/usr/obj/usr/src/sys/G-VIMAGE-MR  amd64
Description:
FreeBSD crashes on carp interface creation.
Tested on:
 - 8.0 RELEASE
 - 8.1 BETA 1

Full kernel config in attachement.
How-To-Repeat:
Startup point: clean installation.
Add following options to GENERIC kernel:

options VIMAGE
options ROUTETABLES=16
options DEVICE_POLLING
device  carp

rebuild kernel
boot with new kernel

ifconfig bge0 10.0.0.1/24
ifconfig carp0 create
ifconfig carp0 vhid 4 pass 12345 advbase 1 advskew 20 10.0.0.2/24

kernel crash
Fix:
Remove following options from kernel config:

options VIMAGE


Patch attached with submission follows:

#
# GENERIC -- Generic kernel configuration file for FreeBSD/amd64
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.4.2.2 2009/11/09 23:48:01 
kensmith Exp $

cpu HAMMER
ident   GENERIC

# To statically compile in device wiring instead of /boot/device.hints
#hints  GENERIC.hints # Default places to look for devices.

# Use the following to compile in values accessible to the kernel
# through getenv() (or kenv(1) in userland). The format of the file
# is 'variable=value', see kenv(1)
#
# env   GENERIC.env

#makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols

options VIMAGE
options ROUTETABLES=16
options DEVICE_POLLING  # Speedup network

options SCHED_ULE   # ULE scheduler
options PREEMPTION  # Enable kernel thread preemption
options INET# InterNETworking
options INET6   # IPv6 communications protocols
# SCTP option is not compatible with options VIMAGE
# options   SCTP# Stream Control Transmission Protocol
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options UFS_GJOURNAL# Enable gjournal-based UFS journaling
options MD_ROOT # MD is a potential root device
options NFSCLIENT   # Network Filesystem Client
options NFSSERVER   # Network Filesystem Server
options NFSLOCKD# Network Lock Manager
options NFS_ROOT# NFS usable as /, requires NFSCLIENT
options MSDOSFS # MSDOS Filesystem
options CD9660  # ISO 9660 Filesystem
options PROCFS  # Process filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_PART_GPT   # GUID Partition Tables.
options GEOM_LABEL  # Provides labelization
options COMPAT_43TTY# BSD 4.3 TTY compat (sgtty)
options COMPAT_IA32 # Compatible with i386 binaries
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options COMPAT_FREEBSD6 # Compatible with FreeBSD6
options COMPAT_FREEBSD7 # Compatible with FreeBSD7
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
options KTRACE  # ktrace(1) support
options STACK   # stack(9) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores

kern/181257: bge link status change

2013-08-13 Thread Konstantin 

Number: 181257
Category:   kern
Synopsis:   bge link status change
Confidential:   no
Severity:   non-critical
Priority:   low
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Tue Aug 13 09:20:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Konstantin
Release:9.1-RELEASE and 9.2-BETA1
Organization:
Environment:
1-st system 
FreeBSD BSD_ev1 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 
UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

2-nd system
FreeBSD smtp1.merlion.ru 9.2-BETA1 FreeBSD 9.2-BETA1 #0 r253470: Sun Mar  3 
19:01:47 MSK 2013 root@dcgate1:/usr/obj/usr/src/sys/GATE  amd64

Description:
bge interfaces doesn't logging link state changes.
Interface is up and status is active, after unplugging cable there's no message 
either in /var/log/messages nor on console (kern.consmute=0). If plug cable in 
interface, there's no message in log also.
But if exec ifconfig command when cable unplaged - message appears. After 
plug cable back appears link up message.
How-To-Repeat:
1.Plug network cable into bge interface, bring it up.
2.Unplug cable from bge interface. (there's no log messages)
3.Plug cable back. (still no messages)
4. Unplug cable from bge interface. (still no messages)
5. exec ifconfig command from terminal.
6. Message 'link down' appears.
7. Plug cable in bge interface. Link change to up appears.
8. If unplug cable from bge there's no message until ifconfig executed.
Fix:
There's no way to solve the problem.

Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

kern/181375: disk free space blackhole magic

2013-08-18 Thread Konstantin 

Number: 181375
Category:   kern
Synopsis:   disk free space blackhole magic
Confidential:   no
Severity:   non-critical
Priority:   low
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Sun Aug 18 14:30:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Konstantin
Release:FreeBSD 8.3 - FreeBSD 8.4
Organization:
Kaspersky Lab
Environment:
FreeBSD 8.3-RELEASE-p5 FreeBSD 8.3-RELEASE-p5 #1: Thu Dec  6 17:13:30 UTC 2012  
   r...@tb.kaspersky-labs.com:/usr/obj/usr/src/sys/GENERIC  amd64

FreeBSD test 8.4-RELEASE FreeBSD 8.4-RELEASE #0 r251259: Sun Jun  2 21:26:57 
UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

Description:
FreeBSD 8.3 - FreeBSD 8.4
amd64
SMP
soft updates
noatime

A daemon running as unprivileged user writes a log. Newsyslog rotates this log 
every hour and compress it by gzip. Some time later (about 1-2 weeks on our 
real systems) filesystem gets full. df and du show different results. Kill 
processes ('/etc/rc.d/jail stop' to be honest) doesn't help. Finally, it is 
impossible to umount this partition. We get Device busy error, but fstat 
and/or lsof doesn't show something. We know about open file deletion issue
and other reasons why df and du shows different results, but it looks like it 
is not our case. Our real systems use jail environment, but it is possible to 
repeat this strange behavior without jail. We could not repeat this on non-SMP 
system, but it is not heavily tested.

Below are more details:

# tunefs -p /dev/mfid0p4
tunefs: POSIX.1e ACLs: (-a)disabled
tunefs: NFSv4 ACLs: (-N)   disabled
tunefs: MAC multilabel: (-l)   disabled
tunefs: soft updates: (-n) enabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  2048
tunefs: average file size: (-f)16384
tunefs: average number of files in a directory: (-s)   64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: optimization preference: (-o)  time
tunefs: volume label: (-L) 

We tested with disabled Soft Updates. It did not help.

/etc/fstat:

/dev/mfid0p4/jail   ufs rw,noatime  2   2

We tested without noatime options. It did not help.

jail newsyslog.conf:

/var/log/urep.txt   kuser:logv  664 24  *   1   Z 
/var/run/kur.service.pid

real logs:

-rw-rw-r--   1 1001  1002  17361916663 Aug 16 18:59 urep.txt
-rw-rw-r--   1 1001  1002   5801630304 Aug 16 18:00 urep.txt.0.gz
-rw-rw-r--   1 1001  1002   4950129578 Aug 16 17:00 urep.txt.1.gz
-rw-rw-r--   1 1001  1002   2333474330 Aug 16 08:00 urep.txt.10.gz
-rw-rw-r--   1 1001  1002   1154592135 Aug 16 07:00 urep.txt.11.gz
-rw-rw-r--   1 1001  1002783671738 Aug 16 06:00 urep.txt.12.gz
-rw-rw-r--   1 1001  1002641988029 Aug 16 05:00 urep.txt.13.gz
-rw-rw-r--   1 1001  1002711639597 Aug 16 04:00 urep.txt.14.gz
-rw-rw-r--   1 1001  1002858166595 Aug 16 03:00 urep.txt.15.gz
-rw-rw-r--   1 1001  1002   1129264281 Aug 16 02:00 urep.txt.16.gz
-rw-rw-r--   1 1001  1002   1825284327 Aug 16 01:00 urep.txt.17.gz
-rw-rw-r--   1 1001  1002   2336803342 Aug 16 00:00 urep.txt.18.gz
-rw-rw-r--   1 1001  1002   2412378597 Aug 15 23:00 urep.txt.19.gz
-rw-rw-r--   1 1001  1002   5808607921 Aug 16 16:00 urep.txt.2.gz
-rw-rw-r--   1 1001  1002   2751801103 Aug 15 22:00 urep.txt.20.gz
-rw-rw-r--   1 1001  1002   2546710751 Aug 15 21:00 urep.txt.21.gz
-rw-rw-r--   1 1001  1002   2540838045 Aug 15 20:00 urep.txt.22.gz
-rw-rw-r--   1 1001  1002   3015737372 Aug 15 19:00 urep.txt.23.gz
-rw-rw-r--   1 1001  1002   3251842089 Aug 15 18:00 urep.txt.24.gz
-rw-rw-r--   1 1001  1002   5239690207 Aug 16 15:00 urep.txt.3.gz
-rw-rw-r--   1 1001  1002   6059472499 Aug 16 14:00 urep.txt.4.gz
-rw-rw-r--   1 1001  1002   6249745715 Aug 16 13:00 urep.txt.5.gz
-rw-rw-r--   1 1001  1002   6314110754 Aug 16 12:00 urep.txt.6.gz
-rw-rw-r--   1 1001  1002   6142097019 Aug 16 11:00 urep.txt.7.gz
-rw-rw-r--   1 1001  1002   5700280821 Aug 16 10:00 urep.txt.8.gz
-rw-rw-r--   1 1001  1002   3843021410 Aug 16 09:00 urep.txt.9.gz

# dmesg
pid 81826 (ksn_urlrepd), uid 1001 inumber 15002792 on /jail: filesystem full
pid 81826 (ksn_urlrepd), uid 1001 inumber 15002792 on /jail: filesystem full
pid 81826 (ksn_urlrepd), uid 1001 inumber 15002792 on /jail: filesystem full
pid 81826 (ksn_urlrepd), uid 1001 inumber 15002792 on /jail: filesystem full

# df -h
Filesystem  SizeUsed   Avail Capacity  Mounted on
/dev/mfid0p29.7G1.1G8.0G12%/
devfs   1.0k1.0k  0B   100%/dev
/dev/mfid0p4256G238G

misc/183126: ������� ������������� FreeBSD - �� ������

2013-10-20 Thread konstantin 

Number: 183126
Category:   misc
Synopsis:   ËÏÍÁÎÄÕ ÒÁÚÒÁÂÏÔÞÉËÏ× FreeBSD - ÎÁ ÐÅÎÓÉÀ
Confidential:   no
Severity:   non-critical
Priority:   low
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  update
Submitter-Id:   current-users
Arrival-Date:   Sun Oct 20 14:20:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: konstantin
Release:9.1, 9.2
Organization:
myhouse
Environment:
Description:
áÄÒÅÓÁ ÎÁÈÏÖÄÅÎÉÑ ÐÏÒÔÏ× ÍÅÎÑÀÔÓÑ ÎÅÓËÏÌØËÏ ÒÁÚ × ÓÕÔËÉ!!!
How-To-Repeat:

Fix:
úÁËÒÙÔØ ÒÁÚÒÁÂÏÔËÕ ÓÉÓÔÅÍÙ, É ÚÁÎÑÔØÓÑ ÞÅÍ-ÔÏ ÂÏÌÅÅ ÐÏÌÅÚÎÙÍ ÄÌÑ ÏÂÝÅÓÔ×Á. óÅÔÉ 
ÚÁÂÉ×ÁÔØ ÎÅ ÂÕÄÅÔÅ. 

Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

kern/184466: kernel doesn't compilling with options NFS_DEBUG

2013-12-03 Thread Konstantin 

Number: 184466
Category:   kern
Synopsis:   kernel doesn't compilling with options NFS_DEBUG
Confidential:   no
Severity:   non-critical
Priority:   low
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Tue Dec 03 09:50:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Konstantin
Release:9.2 RELEASE
Organization:
home
Environment:
FreeBSD web_storage1 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 
22:50:31 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  
amd64

Description:
I inserted 
options NFS_DEBUG
in kernel config and try to build kernel
building stops with following:

linking kernel.debug
nfs_clbio.o: In function `ncl_asyncio':
/usr/src/sys/fs/nfsclient/nfs_clbio.c:1457: undefined reference to `nfs_debug'
/usr/src/sys/fs/nfsclient/nfs_clbio.c:1500: undefined reference to `nfs_debug'
/usr/src/sys/fs/nfsclient/nfs_clbio.c:1474: undefined reference to `nfs_debug'
/usr/src/sys/fs/nfsclient/nfs_clbio.c:1443: undefined reference to `nfs_debug'
/usr/src/sys/fs/nfsclient/nfs_clbio.c:1534: undefined reference to `nfs_debug'
nfs_clnfsiod.o:/usr/src/sys/fs/nfsclient/nfs_clnfsiod.c:319: more undefined 
references to `nfs_debug' follow
*** [kernel.debug] Error code 1

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

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

Stop in /usr/src.

How-To-Repeat:
Recompile kernel with
options NFS_DEBUG

Fix:


Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

misc/152988: no need for ip6fw in /etc/netstart

2010-12-10 Thread Konstantin 

Number: 152988
Category:   misc
Synopsis:   no need for ip6fw in /etc/netstart
Confidential:   no
Severity:   non-critical
Priority:   low
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Fri Dec 10 13:30:10 UTC 2010
Closed-Date:
Last-Modified:
Originator: Konstantin
Release:8.1
Organization:
Kasperksy Lab 
Environment:
FreeBSD  8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010 
r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

Description:
# /etc/netstart
..
/etc/netstart.orig: /etc/rc.d/ip6fw: not found
..

# fgrep ip6fw /etc/netstart
/etc/rc.d/ip6fw ${_start}
#

# find /etc/rc.d/ -name ip6fw
#

there is no ip6fw script in 8.1 any more, but it presents in /etc/netstart
How-To-Repeat:
just run /etc/netstart =)
and 
Fix:
--- /etc/netstart.orig  2010-12-10 16:21:34.0 +0300
+++ /etc/netstart   2010-12-10 16:22:11.0 +0300
@@ -55,7 +55,6 @@
 /etc/rc.d/dhclient ${_start}
 /etc/rc.d/ppp ${_start}
 /etc/rc.d/ipfw ${_start}
-/etc/rc.d/ip6fw ${_start}
 /etc/rc.d/network_ipv6 ${_start}
 /etc/rc.d/routing ${_start}
 /etc/rc.d/mroute6d ${_start}

Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

kern/155004: kernel panic in bce0 driver

2011-02-24 Thread Konstantin 

Number: 155004
Category:   kern
Synopsis:   kernel panic in bce0 driver
Confidential:   no
Severity:   serious
Priority:   low
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Thu Feb 24 14:10:07 UTC 2011
Closed-Date:
Last-Modified:
Originator: Konstantin
Release:7.3
Organization:
Kasperksy Lab
Environment:
FreeBSD 7.3-RELEASE-p2 FreeBSD 7.3-RELEASE-p2 #0: Fri Sep 10 16:59:11 MSD 2010  
   root@/usr/obj/usr/src/sys/GENERIC  amd64

Description:
We have some IBM System x3550 servers with Broadcom NetXtreme II BCM5708 NICs.
Sometimes kernel panic occurs on them under high load (about 900-950Mbs and 
70-90 kpps).   

# kgdb kernel.debug /var/crash/vmcore.6

Unread portion of the kernel message buffer:
118Feb 22 15:39:51 d-ca1 syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...1 0 done
All buffers synced.
Uptime: 29m2s

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x10
fault code  = supervisor read data, page not present
instruction pointer = 0x8:0x802bed2a
stack pointer   = 0x10:0xff80001b7b70
frame pointer   = 0x10:0x0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 30 (irq257: bce1)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 29m2s
Physical memory: 4082 MB
Dumping 1385 MB: 1370 1354 1338 1322 1306 1290 1274 1258 1242 1226 1210 1194 
1178 1162 1146 1130 1114 1098 1082 1066 1050 1034 1018 1002 986 970 954 938 922 
906 890 874 858 842 826 810 794 778 762 746 730 714 698 682 666 650 634 618 602 
586 570 554 538 522 506 490 474 458 442 426 410 394 378 362 346 330 314 298 282 
266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10

(kgdb) where 
#0  doadump () at pcpu.h:195
#1  0x0004 in ?? ()
#2  0x805285f9 in boot (howto=260) at 
/usr/src/sys/kern/kern_shutdown.c:418
#3  0x80528a02 in panic (fmt=0x104 Address 0x104 out of bounds) at 
/usr/src/sys/kern/kern_shutdown.c:574
#4  0x807ec813 in trap_fatal (frame=0xff000158aae0, eva=Variable 
eva is not available.
) at /usr/src/sys/amd64/amd64/trap.c:777
#5  0x807ecbe5 in trap_pfault (frame=0xff80001b7ac0, usermode=0) at 
/usr/src/sys/amd64/amd64/trap.c:693
#6  0x807ed50c in trap (frame=0xff80001b7ac0) at 
/usr/src/sys/amd64/amd64/trap.c:464
#7  0x807d614e in calltrap () at 
/usr/src/sys/amd64/amd64/exception.S:218
#8  0x802bed2a in bce_intr (xsc=Variable xsc is not available.
) at /usr/src/sys/dev/bce/if_bce.c:5771
#9  0x80506a92 in ithread_loop (arg=0xff000158ea60) at 
/usr/src/sys/kern/kern_intr.c:1181
#10 0x805034e3 in fork_exit (callout=0x80506930 ithread_loop, 
arg=0xff000158ea60, frame=0xff80001b7c80)
at /usr/src/sys/kern/kern_fork.c:811
#11 0x807d652e in fork_trampoline () at 
/usr/src/sys/amd64/amd64/exception.S:554
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x0001 in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0x in ?? ()
#20 0x in ?? ()
#21 0x in ?? ()
---Type return to continue, or q return to quit---

(kgdb) up 8
#8  0x802bed2a in bce_intr (xsc=Variable xsc is not available.
) at /usr/src/sys/dev/bce/if_bce.c:5771
5771sc-rx_mbuf_ptr[sw_rx_cons_idx] = NULL;

(kgdb) p *sc
$2 = {bce_ifp = 0xff0001591800, bce_dev = 0xff0001575100, bce_unit = 1 
'\001', bce_res_mem = 0xff0001688c00, bce_ifmedia = {ifm_mask = 0,
ifm_media = 0, ifm_cur = 0x0, ifm_list = {lh_first = 0x0}, ifm_change = 0, 
ifm_status = 0}, bce_btag = 1, bce_bhandle = 18446742977654030336,
  bce_vhandle = 18446742977654030336, bce_res_irq = 0xff0001688580, bce_mtx 
= {lock_object = {lo_name = 0xff00015856d0 bce1,
  lo_type = 0x80856f26 network driver, lo_flags = 16973824, 
lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}},
mtx_lock = 18446742974220511970, mtx_recurse = 0}, bce_intr = 
0x802bea80 bce_intr, bce_intrhand = 0xff0001688b00, bce_irq_rid = 
1,
  bce_msi_count = 1, bce_chipid = 1460146208, bce_flags = 97, bce_cap_flags = 
9, bce_phy_flags = 2, bce_shared_hw_cfg = 325, bce_port_hw_cfg = 0,
  max_bus_addr = 1099511627775, bus_speed_mhz = 133, link_width = 0, link_speed 
= 0, bce_flash_info = 0x80a64330, bce_flash_size = 270336

kern/156545: mv could break UFS on SMP systems

2011-04-21 Thread Konstantin 

Number: 156545
Category:   kern
Synopsis:   mv could break UFS on SMP systems
Confidential:   no
Severity:   serious
Priority:   low
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Thu Apr 21 10:20:08 UTC 2011
Closed-Date:
Last-Modified:
Originator: Konstantin
Release:8.X/7.X
Organization:
Kasperksy Lab
Environment:
# uname -a
FreeBSD test-host 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Thu Apr  7 14:23:20 UTC 
2011 root@host:/usr/obj/amd64/usr/src/sys/GENERIC  amd64

Description:
We have found out a strange mv(1) behaviour on SMP systems with UFS. If two or 
more processes are trying to move the same dir from one source, it could break 
UFS.
It works on 7.X/8.X amd64 systems. Actually, i think, it works on all systems 
with SMP on all platforms.
I guess that the problem is somewhere in ./sys/ufs/ufs/ufs_vnops.c because i 
can't repeat it for an example on ZFS partition.

After UFS break you will see this: 

# mount
/dev/da0p2 on / (ufs, local, noatime)
devfs on /dev (devfs, local, multilabel)
/dev/da0p4 on /data (ufs, local, noatime, soft-updates)

# cd /data/test

# ls -lai
total 40
11540480 drwxr-xr-x  5 root  wheel512 Apr 21 17:30 .
   2 drwxr-xr-x  8 root  wheel512 Apr 21 17:29 ..
11543482 drwxr-xr-x  3 root  wheel  16384 Apr 21 17:37 dst1
11543483 drwxr-xr-x  3 root  wheel512 Apr 21 17:37 dst2
11540481 drwxr-xr-x  2 root  wheel  16384 Apr 21 17:37 src
   4 -rw-r--r--  1 root  wheel738 Apr 21 17:33 test.pl

# ls -lai dst1
total 20
11543482 drwxr-xr-x  3 root  wheel  16384 Apr 21 17:37 .
11540480 drwxr-xr-x  5 root  wheel512 Apr 21 17:30 ..
11541475 drwx--  3 root  wheel512 Apr 21 17:36 03qOT

# ls -lai dst2
total 6
11543483 drwxr-xr-x  3 root  wheel  512 Apr 21 17:37 .
11540480 drwxr-xr-x  5 root  wheel  512 Apr 21 17:30 ..
11541475 drwx--  3 root  wheel  512 Apr 21 17:36 03qOT

# rm -rf dst1/03qOT
rm: dst1/03qOT: Invalid argument

# rm -rf dst2/03qOT
rm: dst2/03qOT: Invalid argument

The only way to fix it is to unmount the partition and run the fsck on it. 

# fsck -vy /data
start /data wait fsck_ufs -y /dev/da0p4
** /dev/da0p4
** Last Mounted on /data
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
/test/dst1/03qOT IS AN EXTRANEOUS HARD LINK TO DIRECTORY /test/dst1/03qOT

REMOVE? yes

BAD INODE NUMBER FOR '..'  I=11541475  OWNER=root MODE=40700
SIZE=512 MTIME=Apr 21 17:36 2011
DIR=/test/dst2/03qOT

UNEXPECTED SOFT UPDATE INCONSISTENCY

FIX? yes

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT DIR I=11541475  OWNER=root MODE=40700
SIZE=512 MTIME=Apr 21 17:36 2011  COUNT 3 SHOULD BE 2
ADJUST? yes

LINK COUNT DIR I=11543482  OWNER=root MODE=40755
SIZE=16384 MTIME=Apr 21 17:37 2011  COUNT 3 SHOULD BE 2
ADJUST? yes

** Phase 5 - Check Cyl groups
7757 files, 87291 used, 134202352 free (256 frags, 16775262 blocks, 0.0% 
fragmentation)

* FILE SYSTEM IS CLEAN *

* FILE SYSTEM WAS MODIFIED *
How-To-Repeat:
You can use this script to repeat the problem:

#!/usr/local/bin/perl
use strict;

my $iterations = 50;
my $dirs = 1000;

mkdir 'src';

for(1..$iterations)
{
  print Iterations $_\n;
  do_test();
}

sub do_test
{
  print Creating $dirs sample directories...\n;

  for(1..$dirs)
  {
my $dirname = `mktemp -d src/X`;
chomp $dirname;
system(touch $dirname/data  touch $dirname/meta);
print $_ ;
}

print done\n;

my ($pid1, $pid2) = (do_job('src', 'dst1'), do_job('src', 'dst2'));
waitpid($pid1, 0);
waitpid($pid2, 0);
}

sub do_job
{
  my ($src, $dst) = @_;
  
  my $pid = fork();
  return $pid if $pid != 0;
  
  system(mkdir -p $dst  ls $src | xargs -I _ mv -n $src/_ $dst);
  system(rm -rf $dst/*) == 0 or die;
  
  exit(0);
}
Fix:


Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

misc/157499: fetch confused me with it's error message

2011-06-01 Thread Konstantin 

Number: 157499
Category:   misc
Synopsis:   fetch confused me with it's error message
Confidential:   no
Severity:   non-critical
Priority:   low
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Wed Jun 01 14:20:05 UTC 2011
Closed-Date:
Last-Modified:
Originator: Konstantin
Release:8.2-RELEASE/7.3-RELEASE
Organization:
Kaspersky Lab
Environment:
FreeBSD ourhost.kaspersky.com 7.3-RELEASE-p3 FreeBSD 7.3-RELEASE-p3 #0: Tue Sep 
21 18:03:17 MSD 2010 
r...@ourhost.kaspersky.com:/usr/obj/usr/src/sys/GENERIC  amd64

Description:
I have found out some strange error handling in /usr/bin/fetch.
Here it is: 

# fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz
fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Syntax 
error, command unrecognized

So it's very confusing error message. With some extra debug it looks more 
clear: 

# fetch -vvv ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz
scheme:   [ftp]
user: []
password: []
host: [ftp.freebsd.org]
port: [0]
document: [/pub/FreeBSD/ports/ports/ports.tar.gz]
--- ftp.freebsd.org:21
looking up ftp.freebsd.org
connecting to ftp.freebsd.org:21
 220 Welcome to freebsd.isc.org.
How-To-Repeat:

Fix:


Release-Note:
Audit-Trail:
Unformatted:
  USER anonymous
  331 Please specify the password.
  PASS r...@h-ksn-hkg-fe-2.kaspersky-labs.com
  500 OOPS: cannot change directory:/home/ftp
 fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Syntax 
error, command unrecognized
 
 # host ftp.freebsd.org
 ftp.freebsd.org has address 204.152.184.73
 ftp.freebsd.org has address 87.51.34.132
 ftp.freebsd.org has address 149.20.64.73
 ftp.freebsd.org has IPv6 address 2001:4f8:0:2::e
 ftp.freebsd.org has IPv6 address 2001:6c8:2:600::132
 
 Actually this problem exists only with 204.152.184.73 server. See ftp connect 
to it:
 # ftp
 ftp open ftp.freebsd.org
 Trying 204.152.184.73...
 Connected to ftp.freebsd.org.
 220 Welcome to freebsd.isc.org.
 Name (ftp.freebsd.org:root): ftp
 331 Please specify the password.
 Password:
 500 OOPS: cannot change directory:/home/ftp
 ftp: Login failed.
 ftp exit
 500 OOPS: priv_sock_get_cmd
 
 I don't know why fetch on 7.3 sticked to this server and I had error 'Syntax 
error, command unrecognized' every time I run fetch. It could be some problem 
in DNS resolving algorithm on 7.3. On 8.2 fetch works with different servers, 
so I had this error n ot very often.
 
 Anyway, error message 'Syntax error, command unrecognized' on some FTP 
problems sounds very confusing for me.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

misc/159707: Olson's timezone database is old for Russia in 7.X/8.X

2011-08-12 Thread Konstantin 

Number: 159707
Category:   misc
Synopsis:   Olson's timezone database is old for Russia in 7.X/8.X
Confidential:   no
Severity:   non-critical
Priority:   low
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Fri Aug 12 11:10:08 UTC 2011
Closed-Date:
Last-Modified:
Originator: Konstantin
Release:8.X/7.X
Organization:
Kaspersky Lab
Environment:
Description:
The problem is that in 7.X and 8.X (except CURRENT 8-STABLE) Olson’s timezone 
database for Europe is obsolete. 
I have found current version 8.33 only in RELENG_8.
This spring Russian government had canceled Daylight saving time.
So if you are still using 7.X or 8.0, 8.1, 8.2 in Russia, this fall you will 
definitely have problems with you timezone.
Whole country will stay with UTC+4 and you will back to winter time UTC+3. That 
is not good at all =)

Please update share/zoneinfo in src and add new /usr/share/zoneinfo/ files in 
binary update. 
How-To-Repeat:

Fix:
1) Download new europe version from ftp://elsie.nci.nih.gov/pub/ or from 
RELENG_8 to /usr/src/share/zoneinfo/
2) cd /usr/src/share/zoneinfo/
4) make clean; make install
5) (if it's needed) 
cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

kern/150858: GEOM_LABEL is not compatible with newfs -r flag

2010-09-22 Thread Konstantin Kukushkin 

Number: 150858
Category:   kern
Synopsis:   GEOM_LABEL is not compatible with newfs -r flag
Confidential:   no
Severity:   non-critical
Priority:   medium
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Wed Sep 22 12:00:12 UTC 2010
Closed-Date:
Last-Modified:
Originator: Konstantin Kukushkin
Release:8.1-STABLE
Organization:
Rambler
Environment:
FreeBSD dash.local 8.1-STABLE FreeBSD 8.1-STABLE #0: Wed Sep 22 13:18:16 MSD 
2010 r...@dash.local:/var/tmp/obj/usr/src/sys/EEE8  i386
Description:
For any provider, GEOM_LABEL strictly checks that ufs occupied all its
space. But filesystem can be smaller, in case if newfs(8) was run with
-r flag. So, GEOM_LABEL is not compatible with newfs -r flag.

When check is more permissive (as in attached patch) all work OK:
[pts/0] r...@dash:/usr/home/dark# uname -rp
8.1-STABLE i386
[pts/0] r...@dash:/usr/home/dark# ll /dev/ufsid/
total 0
crw-r-  1 root  operator0,  93 22 ÓÅÎ 17:24 4992d90831a79611
[pts/0] r...@dash:/usr/home/dark# mdconfig -s 32m
md0
[pts/0] r...@dash:/usr/home/dark# newfs -r 4 -U /dev/md0
/dev/md0: 32.0MB (65532 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 8.00MB, 512 blks, 1024 inodes.
with soft updates
super-block backups (for fsck -b #) at:
 160, 16544, 32928, 49312
[pts/0] r...@dash:/usr/home/dark# ll /dev/ufsid/
total 0
crw-r-  1 root  operator0,  93 22 ÓÅÎ 17:24 4992d90831a79611
crw-r-  1 root  operator0, 118 22 ÓÅÎ 13:38 4c99ce860db39b88
[pts/0] r...@dash:/usr/home/dark# glabel status
  Name  Status  Components
  ntfs/sys N/A  ada0s1
   msdosfs/SYS N/A  ada0s2
  msdosfs/BIOS N/A  ada0s3
  ntfs/BIG N/A  ada1s2
ufsid/4992d90831a79611 N/A  ada1s1a
ufsid/4c99ce860db39b88 N/A  md0 
How-To-Repeat:
radius# uname -rp
8.1-20100726-SNAP i386
radius# ll /dev/ufsid/
total 0
crw-r-  1 root  operator0,  98 21 ÓÅÎ 22:01 4c98f1c148b0469b
crw-r-  1 root  operator0,  99 21 ÓÅÎ 22:01 4c98f1c978a6bb52
radius# mdconfig -s 32m
md0
radius# newfs -r 4 -U /dev/md0
/dev/md0: 32.0MB (65532 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 8.00MB, 512 blks, 1024 inodes.
with soft updates
super-block backups (for fsck -b #) at:
 160, 16544, 32928, 49312
radius# ll /dev/ufsid/
total 0
crw-r-  1 root  operator0,  98 21 ÓÅÎ 22:01 4c98f1c148b0469b
crw-r-  1 root  operator0,  99 21 ÓÅÎ 22:01 4c98f1c978a6bb52
radius# glabel status
  Name  Status  Components
ufsid/4c98f1c148b0469b N/A  ada2d
ufsid/4c98f1c978a6bb52 N/A  ada3d
Fix:
Use attached patch.

Patch attached with submission follows:

--- /sys/geom/label/g_label_ufs.c.orig  2010-07-11 23:06:52.0 +0400
+++ /sys/geom/label/g_label_ufs.c   2010-09-22 12:21:23.0 +0400
@@ -83,10 +83,10 @@
continue;
/* Check for magic and make sure things are the right size */
if (fs-fs_magic == FS_UFS1_MAGIC  fs-fs_fsize  0 
-   pp-mediasize / fs-fs_fsize == fs-fs_old_size) {
+   pp-mediasize / fs-fs_fsize = fs-fs_old_size) {
/* Valid UFS1. */
} else if (fs-fs_magic == FS_UFS2_MAGIC  fs-fs_fsize  0 
-   pp-mediasize / fs-fs_fsize == fs-fs_size) {
+   pp-mediasize / fs-fs_fsize = fs-fs_size) {
/* Valid UFS2. */
} else {
g_free(fs);


Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan)

2012-03-26 Thread Konstantin Belousov 
The following reply was made to PR kern/166340; it has been noted by GNATS.

From: Konstantin Belousov kostik...@gmail.com
To: Christian Esken christian.es...@trivago.com
Cc: bug-follo...@freebsd.org, a...@freebsd.org
Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable 
sleep with apparently no syscall (empty wchan)
Date: Mon, 26 Mar 2012 16:51:42 +0300

 Thank you for the data. Semi-obviously, the callout_stop() call in
 sleepq_check_timeout() have to return 0, otherwise we would not call
 mi_switch() there. But I do not see how this can happen, because
 the callout state, printed from kgdb, still indicates that callout
 is pending. Callout cannot be reset while in sleepq code.
 
 So there are two possible routes to go forward: preferrable is for
 you to extract the self-contained C program that would illustrate
 the issue and send this sample to me. Second is to recompile your
 kernel with INVARIANTS/WITNESS and possibly KTR and see what happen.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan)

2012-03-27 Thread Konstantin Belousov 
The following reply was made to PR kern/166340; it has been noted by GNATS.

From: Konstantin Belousov kostik...@gmail.com
To: Christian Esken christian.es...@trivago.com
Cc: bug-follo...@freebsd.org, a...@freebsd.org
Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable 
sleep with apparently no syscall (empty wchan)
Date: Tue, 27 Mar 2012 20:46:26 +0300

 --KldKAdupQSLqpq2E
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Mar 27, 2012 at 05:30:48PM +0200, Christian Esken wrote:
  Konstantin Belousov wrote:
   Thank you for the data. Semi-obviously, the callout_stop() call in
   sleepq_check_timeout() have to return 0, otherwise we would not call
   mi_switch() there. But I do not see how this can happen, because
   the callout state, printed from kgdb, still indicates that callout
   is pending. Callout cannot be reset while in sleepq code.
  =20
   So there are two possible routes to go forward: preferrable is for
   you to extract the self-contained C program that would illustrate
   the issue and send this sample to me. Second is to recompile your
   kernel with INVARIANTS/WITNESS and possibly KTR and see what happen.
 =20
  I repeated the test with INVARIANTS/WITNESS and KTR compiled in
  (actually WITNESS was already included during the last test).
 =20
  I ran KTR with nothing filtered out, and formatted the dump with
  ktrdump -cftH  -i ktr.out. The whole log is excessive (1GB), so
  I have extrated two short sections (see attachment).
 =20
  The first section shows the last action of the application, namely a
  succselful sendto() to a TCP socket, and then waiting for an answer via
  recvfrom().
  The second section illustrates the lock/unlock sequence of the sleep
  mutex for the recfrom(). It goes like LOCK, LOCK, UNLOCK.
 =20
  This time the signal status is different. We have a pending signal:
  USER PID  PPID  PENDING   CAUGHT  IGNORED  BLOCKED STAT WCHAN
  nobody  9163 1 4000 80005006 79f880100 D-=20
 =20
  Looks like SIGPROF (27). Just wondering where it comes from.
 =20
 This is irrelevant, and probably red-herring. The issue there is failing
 callout_stop() while callout seems to be still pending. Also, mask 0x4000
 of the pending signals indicates that SIGTERM is pending, not SIGPROF.
 
 I probably want the data from your ktr dump, either all entries for
 the stuck process and all entries for facility CALLOUT, or just the
 whole dump.
 
 Last entries of your log shred do not make much sense, since the process
 must enter _sleep() function which logs this fact right after locking
 sleepq. But log ends on so_rcv mutex lock.
 
 Please, when collecting the data, collect the whole set, i.e.
 include procstat -kk pid output together with the ktr, as well as kgdb
 output, so that I can be sure that we chasing one, and not N bugs.
 
 --KldKAdupQSLqpq2E
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (FreeBSD)
 
 iEYEARECAAYFAk9x/PIACgkQC3+MBN1Mb4hbeACfYyUTEE5GV/SeDO4fNf4ErfHY
 27oAoIGj2TMOBtQRi5P+q/v+nrKOFhFb
 =0tFs
 -END PGP SIGNATURE-
 
 --KldKAdupQSLqpq2E--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

Re: kern/128870: [pccbb] Interrupt Storm when plugging in PCMCIA Card (HP NC8000 Notebook)

2012-06-04 Thread Konstantin Vasilev 
The following reply was made to PR kern/128870; it has been noted by GNATS.

From: Konstantin Vasilev konstantin.vasil...@gmail.com
To: bug-follo...@freebsd.org, a_wehrm...@hotmail.com
Cc:  
Subject: Re: kern/128870: [pccbb] Interrupt Storm when plugging in PCMCIA
 Card (HP NC8000 Notebook)
Date: Mon, 04 Jun 2012 15:23:23 +0400

 Hi all,
 
 I have the same problem on 9.0 RELEASE.
 Wireless card driver is ath.
 Interrupt storm dramatically slows my system.
 
 --
 With best regards,
 Konstantin Vasilev
 
 
  
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

bin/171279: bsnmpd can reply from other address

2012-09-03 Thread Konstantin Kukushkin 

Number: 171279
Category:   bin
Synopsis:   bsnmpd can reply from other address
Confidential:   no
Severity:   serious
Priority:   medium
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Mon Sep 03 14:50:04 UTC 2012
Closed-Date:
Last-Modified:
Originator: Konstantin Kukushkin
Release:FreeBSD 9.0-STABLE amd64
Organization:
Rambler Internet Holding, LLC
Environment:
System: FreeBSD vpn1-m1.rambler.ru 9.0-STABLE FreeBSD 9.0-STABLE #2 r231584M: 
Mon Feb 13 18:24:25 MSK 2012 
gleb...@vpn1-m1.rambler.ru:/usr/obj/usr/home/glebius/9/sys/VPN amd64

Description:
bsnmpd by default listen INADDR_ANY, and on multihomed system daemon 
can receive queries to some addresses.
When replying to query bsdnmp simply use sendto(), so OS build response 
datagram with source ip nearest to sender, which can be not equal to 
destination ip on source query.
This is ok for net-snmp utils like snmpget  snmpwalk, but this can't work with 
statefull firewalls like ipfw(4) or pf(4).

Please fix it.

How-To-Repeat:
I used multihomed host vpn1-m1:
[pts/2] dark@vpn1-m1:~ ( ifconfig bge0 inet ; ifconfig lo0 inet )|grep inet
inet 81.19.94.147 netmask 0xfff8 broadcast 81.19.94.151
inet 127.0.0.1 netmask 0xff00 
inet 81.19.64.133 netmask 0x 
inet 81.19.79.1 netmask 0x 
with ``onestarted`` bsnmpd:
[pts/2] dark@vpn1-m1:~ sudo /etc/rc.d/bsnmpd onestart
Starting bsnmpd.
[pts/2] dark@vpn1-m1:~ sockstat | grep 'bsnmpd.*161'
root bsnmpd 38365 6  udp4   *:161 *:*

and other host for query to address, routed to vpn1-m1:
[pts/53] dark@dark:~ ifconfig re0 inet|grep inet
inet 81.19.64.109 netmask 0xffe0 broadcast 81.19.64.127

[pts/53] dark@dark:~ snmpget -v 2c -c public 81.19.64.133 sysDescr.0
Timeout: No Response from 81.19.64.133.

tcpdump on multihomed host shows that bsnmpd reply from source other that query 
destination:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bge0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:17:16.007788 IP 81.19.64.109.60689  81.19.64.133.161:  GetRequest(28)  
.1.3.6.1.2.1.1.1.0
15:17:16.008005 IP 81.19.94.147.161  81.19.64.109.60689:  GetResponse(76)  
.1.3.6.1.2.1.1.1.0=vpn1-m1.rambler.ru 4212937669 FreeBSD 9.0-STABLE
Fix:

Other udp servers like named try to create listen socket bind()'ed on adresses 
from getifaddrs() output, not INADDR_ANY. While daemon receiving query on 
bind()'ed socket it knows on which address query was sent, and can reply right.
Unfortunately I don't know any other mechanism getting datagram destination 
address in FreeBSD, in Linux there is 'IP_PKTINFO' socket option for this.
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

Re: bin/171662: procstat(1) fails to recognize AT_TIMEKEEP

2012-09-15 Thread Konstantin Belousov 
The following reply was made to PR bin/171662; it has been noted by GNATS.

From: Konstantin Belousov kostik...@gmail.com
To: Jan Beich jbe...@tormail.org
Cc: freebsd-gnats-sub...@freebsd.org, troc...@freebsd.org
Subject: Re: bin/171662: procstat(1) fails to recognize AT_TIMEKEEP
Date: Sat, 15 Sep 2012 17:04:42 +0300

 --Gs9iBZf6UKWgztis
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sat, Sep 15, 2012 at 02:26:36AM -0900, Jan Beich wrote:
 =20
  Number: 171662
  Category:   bin
  Synopsis:   procstat(1) fails to recognize AT_TIMEKEEP
  Confidential:   no
  Severity:   non-critical
  Priority:   low
  Responsible:freebsd-bugs
  State:  open
  Quarter:   =20
  Keywords:  =20
  Date-Required:
  Class:  sw-bug
  Submitter-Id:   current-users
  Arrival-Date:   Sat Sep 15 11:50:09 UTC 2012
  Closed-Date:
  Last-Modified:
  Originator: Jan Beich
  Release:FreeBSD 10.0-CURRENT amd64
  Organization:
  Environment:
  Description:
  How-To-Repeat:
  $ procstat -x $(pgrep firefox)
PID COMM AUXV VALUE
  90996 firefox  AT_PHDR  0x400040
  90996 firefox  AT_PHENT 56
  90996 firefox  AT_PHNUM 8
  90996 firefox  AT_PAGESZ4096
  90996 firefox  AT_FLAGS 0
  90996 firefox  AT_ENTRY 0x401790
  90996 firefox  AT_BASE  0x80060d000
  90996 firefox  AT_EXECPATH  0x7fffefc8
  90996 firefox  AT_OSRELDATE 118
  90996 firefox  AT_CANARY0x7fffef88
  90996 firefox  AT_CANARYLEN 64
  90996 firefox  AT_NCPUS 2
  90996 firefox  AT_PAGESIZES 0x7fffef70
  90996 firefox  AT_PAGESIZESLEN  24
  90996 firefox22 0x7190
  90996 firefox  AT_STACKPROT EXECUTABLE
  Fix:
  Release-Note:
  Audit-Trail:
  Unformatted:
 
 Yes, I forgot about procstat at all when I added AT_TIMEKEEP.
 
 I also noted that AT_COUNT is defined in the switch statement, which
 is not useful. AT_COUNT is not an auxv at all, it is just count.
 
 diff --git a/usr.bin/procstat/procstat_auxv.c b/usr.bin/procstat/procstat_a=
 uxv.c
 index 9bf7afb..b78e13a 100644
 --- a/usr.bin/procstat/procstat_auxv.c
 +++ b/usr.bin/procstat/procstat_auxv.c
 @@ -231,9 +231,11 @@ procstat_auxv(struct kinfo_proc *kipp)
else
PRINT(AT_STACKPROT, %s, EXECUTABLE);
break;
 -  case AT_COUNT:
 -  PRINT(AT_COUNT, %ld, (long)auxv[i].a_un.a_val);
 +#ifdef AT_TIMEKEEP
 +  case AT_TIMEKEEP:
 +  PRINT(AT_TIMEKEEP, %p, auxv[i].a_un.a_ptr);
break;
 +#endif
default:
PRINT_UNKNOWN(auxv[i].a_type, auxv[i].a_un.a_val);
break;
 
 --Gs9iBZf6UKWgztis
 Content-Type: application/pgp-signature
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (FreeBSD)
 
 iEYEARECAAYFAlBUivoACgkQC3+MBN1Mb4hzpgCfbYe5K3wLrY3o6jqEwMt+CaiL
 OGsAn3+FVxju/YcO6AFi4ZQGaA1qexxg
 =J8Zi
 -END PGP SIGNATURE-
 
 --Gs9iBZf6UKWgztis--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

RE: misc/157499: fetch confused me with it's error message

2011-06-02 Thread Konstantin Malov 
The following reply was made to PR bin/157499; it has been noted by GNATS.

From: Konstantin Malov konstantin.ma...@kaspersky.com
To: Jaakko Heinonen j...@freebsd.org
Cc: bug-follo...@freebsd.org bug-follo...@freebsd.org
Subject: RE: misc/157499: fetch confused me with it's error message
Date: Thu, 2 Jun 2011 12:48:07 +0400

 I agree with this.
 So real problem is that this error message 'Syntax error, command unrecogni=
 zed' appears with warnx function:=20
 warnx(%s: %s, URL, fetchLastErrString);=20
 
 There are three such places in fetch.c where warnx is used without addition=
 al information about error cause. I don't know what to add in this place:=20
 
 402 /* set the protocol timeout. */
 403 fetchTimeout =3D timeout;
 404
 405 /* just print size */
 406 if (s_flag) {
 407 if (timeout)
 408 alarm(timeout);
 409 r =3D fetchStat(url, us, flags);
 410 if (timeout)
 411 alarm(0);
 412 if (sigalrm || sigint)
 413 goto signal;
 414 if (r =3D=3D -1) {
 415 warnx(%s, fetchLastErrString);
 416 goto failure;
 417 }
 418 if (us.size =3D=3D -1)
 419 printf(Unknown\n);
 420 else
 421 printf(%jd\n, (intmax_t)us.size);
 422 goto success;
 423 }
 
 But for last two I can suggest this patch:=20
 
 --- fetch.c.orig2011-06-02 12:06:26.0 +0400
 +++ fetch.c 2011-06-02 12:28:25.0 +0400
 @@ -463,7 +463,7 @@
 if (sigalrm || sigint)
 goto signal;
 if (f =3D=3D NULL) {
 -   warnx(%s: %s, URL, fetchLastErrString);
 +   warnx(data fetch from '%s' failed with error: %s, URL, fe=
 tchLastErrString);
 if (i_flag  strcmp(url-scheme, SCHEME_HTTP) =3D=3D 0
  fetchLastErrCode =3D=3D FETCH_OK
  strcmp(fetchLastErrString, Not Modified) =3D=3D 0)=
  {
 @@ -574,7 +574,7 @@
  */
 url-offset =3D 0;
 if ((f =3D fetchXGet(url, us, flags)) =3D=3D NULL)=
  {
 -   warnx(%s: %s, URL, fetchLastErrString);
 +   warnx(data fetch from '%s' failed with err=
 or: %s, URL, fetchLastErrString);
 goto failure;
 }
 if (sigint)
 
 -Original Message-
 From: Jaakko Heinonen [mailto:j...@freebsd.org]=20
 Sent: Thursday, June 02, 2011 12:01 PM
 To: Konstantin Malov
 Cc: bug-follo...@freebsd.org
 Subject: Re: misc/157499: fetch confused me with it's error message
 
 On 2011-06-01, Konstantin wrote:
  I have found out some strange error handling in /usr/bin/fetch.
  Here it is:=20
 =20
  # fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz
  fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Syntax=
  error, command unrecognized
 
USER anonymous
331 Please specify the password.
PASS r...@h-ksn-hkg-fe-2.kaspersky-labs.com
500 OOPS: cannot change directory:/home/ftp
   fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Synta=
 x error, command unrecognized
 
 This is how reply code 500 is defined in RFC 959:
 
 500Syntax error, command unrecognized.
This may include errors such as command line too long.
 
 --=20
 Jaakko
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64

2013-06-28 Thread Konstantin Belousov 
The following reply was made to PR kern/131597; it has been noted by GNATS.

From: Konstantin Belousov kostik...@gmail.com
To: John Baldwin j...@freebsd.org
Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, thera...@freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD
 7.1/amd64
Date: Fri, 28 Jun 2013 20:17:21 +0300

 --hhtCH1hro9pJkPIH
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Jun 28, 2013 at 08:47:55AM -0400, John Baldwin wrote:
  Looking at this again, the patch committed in 178807 is just wrong and sh=
 ould=20
  be reverted.  There is no state in rtld that needs to be protected via a =
 write=20
  lock.  GCC is too lazy to use their own locking to protect shared state=
 =20
  between threads and wants the runtime linker to enforce this.  Their=20
  justification that glibc doesn't allow concurrent execution of this isn't=
  a=20
  valid excuse.  For an API like this that just walks a list and invokes a=
 =20
  callback, if the callback manipulates shared state owned by the caller, t=
 he=20
  caller should be responsible for sychronizing access to it, not rtld!
 =20
  Instead I think we should apply the patch in the original GCC bug to our =
 in-
  tree GCC and to our GCC ports.  This should remove the sigprocmask calls =
 and
  not penalize other users of dl_iterate_phdr() for GCC's poor behavior.
 
 In other words, we should become knowingly incompatible with the stock
 GCC and with other consumers of dl_iterate_phdr(), like libunwind ?
 E.g. libunwind ability to unwind from the signal handler relies on
 this behaviour.
 
 --hhtCH1hro9pJkPIH
 Content-Type: application/pgp-signature
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.20 (FreeBSD)
 
 iQIcBAEBAgAGBQJRzcUgAAoJEJDCuSvBvK1BBuwQAIWoFrFkw9Op7RybuuAw9K5h
 f49+JDpcscYrQcF8KSYWiUdV3ZcoBnubqKpT+6vWm5MQ4PwUCEv3ouKAhD/oe4n+
 oJg3pQz+mFicI7s0Wr3rJFyf0vO5wcHnxDOq7XdjHIPlGqTZcnOjubdCJ42xpZkT
 7004JA8B8WHitjh+9qJGQWOUDfBzUWDE3WwieqpYnKricnFhJh8/6gTg6abbZGkE
 6szxxKdPMUHJ28X54HU1DV9A2TJgfjLsGIzneQtfpOp7TTIyTKfn2hFHp5eLhWB/
 voH0HAegdg7ew3MaCl2fnGKb6UR0h3yShowp3KfH1LozmZNDw6C/6VSKwy55aSYY
 GaVXlWEhniim7NaRgP2okdMPEz07pUt3KoIN5mQGrlvgusTUa7YXcrwCm97l72dT
 EqjgffvFUPmmHP38jhgf/wkI1aQ6tY7eSqSLDM+MMBX6TnPKx4EAr3H/tc79idEx
 O89zUHFJPuI7YY563O+dR0Bm09kIDPVNb3hTG09JF2KCxY3QYlje8Iu5ndKOLCi+
 HvFwnTLpDEFEd22oNWdSeNUq97Rr2mAMSv5dk9A+a8mtsRbzPSeuylIKSEEKquDu
 USJ2ZyISoTnZbb6Iz6SYkZRn8vOBRUfBbpPRcAJh2FkBTegl7JE7dS3tM7C26uzf
 MxGTc8YbAXTWA1XFxyZR
 =hwdp
 -END PGP SIGNATURE-
 
 --hhtCH1hro9pJkPIH--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64

2013-06-28 Thread Konstantin Belousov 
The following reply was made to PR kern/131597; it has been noted by GNATS.

From: Konstantin Belousov kostik...@gmail.com
To: John Baldwin j...@freebsd.org
Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, thera...@freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD
 7.1/amd64
Date: Fri, 28 Jun 2013 20:45:38 +0300

 --8C4Pdt+UNHoLxtm5
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Jun 28, 2013 at 01:38:39PM -0400, John Baldwin wrote:
  On Friday, June 28, 2013 1:17:21 pm Konstantin Belousov wrote:
   On Fri, Jun 28, 2013 at 08:47:55AM -0400, John Baldwin wrote:
Looking at this again, the patch committed in 178807 is just wrong an=
 d should=20
be reverted.  There is no state in rtld that needs to be protected vi=
 a a write=20
lock.  GCC is too lazy to use their own locking to protect shared sta=
 te=20
between threads and wants the runtime linker to enforce this.  Their=
 =20
justification that glibc doesn't allow concurrent execution of this i=
 sn't a=20
valid excuse.  For an API like this that just walks a list and invoke=
 s a=20
callback, if the callback manipulates shared state owned by the calle=
 r, the=20
caller should be responsible for sychronizing access to it, not rtld!
   =20
Instead I think we should apply the patch in the original GCC bug to =
 our in-
tree GCC and to our GCC ports.  This should remove the sigprocmask ca=
 lls and
not penalize other users of dl_iterate_phdr() for GCC's poor behavior.
  =20
   In other words, we should become knowingly incompatible with the stock
   GCC and with other consumers of dl_iterate_phdr(), like libunwind ?
   E.g. libunwind ability to unwind from the signal handler relies on
   this behaviour.
 =20
  Does libunwind depend on rtld single-threading to lock state shared with
  other threads?  If it does it should manage that itself.  If GCC and/or
  libunwind want to share arbitrary state between threads, or protect state
  from being accessed by a signal handler, then GCC and/or libunwind should
  manage that.  rtld can't possibly (and shouldn't) know the rules about
  how that state that is private to GCC/libunwind is managed.
 libunwind depends on the dl_iterate_phdr() signal-safety.
 
 =20
  What if you had a consumer of this that wanted to access the state outside
  of the callback?  Then it already has to manage all the locking itself to
  be safe anyway.
 =20
  Put another way, requiring dl_iterate_phdr() to providing locking for con=
 sumers
  would be equivalent to code assuming that C++'s for_each() template in
  algorithm provided locking to callers.  That is entirely upside-down.
 
 I think I should revive the fast sigprocmask patch.
 
 --8C4Pdt+UNHoLxtm5
 Content-Type: application/pgp-signature
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.20 (FreeBSD)
 
 iQIcBAEBAgAGBQJRzcvBAAoJEJDCuSvBvK1B9UgP/jne8523ys+JZDGUn9izYhJk
 LlT5LSSARhTcbREEsIevB5VQt2pbDtKsca/fCtLmaasPN5cb8XgLeyy1J3caB742
 LdrXLcczv8PvSJM0D7EDTH6ktGrmAl0i9cHb8sLqHuPAD7/ZNBJRfJXWdRe4Rs3r
 /A78kqAdyGlJAupQ+2ocbtsIOg8F1G3L3b7iZ+gA7+txErCv5th6H3+lXalpF+8X
 40FDUvpoU9roOesa9vKcQLFWcBMedLkVmTujmHrvFfMuz6zXu+0Anje5Zc0LPOSu
 hst4vYimFxn/VXQuU5qmGKhhz0o0jtwJzdF836aJotx2tsQWuBLWZiKSBffKQFeB
 D6aK0GlMlK/i6LQD+LeJbjB+k0/jxgK6ZtdetUPnPCUjeHE5IKDrm1Z0yMzMC/20
 H5AQ3WdFR7Jvu11ZK6jp2aqX6BDUTTwW85c1Y/k2n5+I48vD1EDXRDO73aQkHyM8
 0EU5kCPS1CRbXsf4XeGlye/YhJBNS7Hp/tdNSjhSjHckA78xLUsoKeo6LfCmFtG6
 GT8oDSmyugQl6QwCNzNp9bjKJ3wSI1TZjBr8GNQI/kXZJpaJkFb6mzLLLhUbjtt/
 XHrA2gaJDE9eTlOohoBO8zJ8bXe1ykK/YuduXdsAfpqKH4KckkEqUiA1ptrMV7C6
 9olJnLJJMrgbMjv955u6
 =/5H4
 -END PGP SIGNATURE-
 
 --8C4Pdt+UNHoLxtm5--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64

2013-06-30 Thread Konstantin Belousov 
The following reply was made to PR kern/131597; it has been noted by GNATS.

From: Konstantin Belousov kostik...@gmail.com
To: Jilles Tjoelker jil...@stack.nl
Cc: bug-follo...@freebsd.org, John Baldwin j...@freebsd.org,
guilla...@morinfr.org, thera...@freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD
 7.1/amd64
Date: Mon, 1 Jul 2013 03:24:06 +0300

 --tdVUlQTxnujgnAno
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sun, Jun 30, 2013 at 11:28:55PM +0200, Jilles Tjoelker wrote:
  On Sun, Jun 30, 2013 at 06:12:32AM +0300, Konstantin Belousov wrote:
   On Sat, Jun 29, 2013 at 11:53:35PM +0200, Jilles Tjoelker wrote:
On Fri, 28 Jun 2013 20:45:38 +0300, Konstantin Belousov wrote:
   As I said, libunwind relies on the signal blocking behaviour to be able
   to unwind from the signal handler.
 =20
  OK :(
 =20
I am a bit concerned, though, that this is only needed for the
unthreaded programming environment. libthr has an efficient method for
postponing signals that avoids system calls. Moving that mechanism to
libc, although it is a bit hard, may be an option.
 =20
   Well, the right answer then is, in fact, to merge libc and libthr.
   I implemented ELF filters as the first required step, but did not
   progressed the task further.
 =20
   IMO the merge is mostly mechanical, the complication is due to the fact
   that the work should be done in branch and takes a lot of time. As
   result, the libc and libthr changes during development are conflicting
   and have to be constantly resolved.
 =20
  A full merge would make people unhappy who want a separate unthreaded
  programming environment so that, for example, libstdc++ can allocate
  smaller data structures without locks. (Note that this requires breaking
  pthread_once() in the unthreaded programming environment.)
 libgcc++ could switch to the method used by all other platforms, on
 the FreeBSD too.  It seems that the presence of the pthread_cancel()
 symbol works as an indicator.  We can easily implement the switch
 locally, and I am sure that upstream will accept such change.
 
 =20
  However, even without pthread_create() and pthread_once(), a lot of
  functionality could be moved from libthr to libc, assuming we are
  willing to declare mixing and matching libc and libthr versions
  completely unsupported (by adding a check). For example, the signal
  handling, cancellation checks and errno. In the case of dynamic linking,
  a partial merge will require fewer symbols to be exported
  FBSDprivate_1.0 which reduces PLT indirection and will make up for some
  overhead.
 We already do not support mixing different versions of libc and libthr,
 since libthr copies the pthread stubs over the libc table.
 
 =20
  An example of this partial merge is lib/libc/gen/sem_new.c.
 
 In fact, the export of the pthread* symbols from libc is very unfortunate.
 
 --tdVUlQTxnujgnAno
 Content-Type: application/pgp-signature
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.20 (FreeBSD)
 
 iQIcBAEBAgAGBQJR0MwlAAoJEJDCuSvBvK1BSkwP+wa9pn0DcrxOlt16Kl5bARph
 +yQriobX54RilXMBEuhB07IFxN+iECGgbXieq3iPMhY5Q925doZIjIKViFfnPWfy
 MD4dpQKxpVInL77/GOPeBzGcqNtMg/Ubfn4pKAP9Mmv+mNIjPOVOka8zzDwTCyrR
 NkNMyA4bNtUWVnb6y1yb1t2PUP3W9RTjhbC9xgfCwXzL1IwwWZwMv0+Ate75E5EY
 I7F+eOUqhCWNHUHfw4ezF7ZqB7faY9/ScGJTKbOlJ8C9h0BtnNeb/zCZXsgu4+UN
 Gt6LtpQib5eya05braKOJVaALpksQ+MHTNvWmMmodBLnjHu4fyVfBTmAwNkk+VnQ
 UaXMpGsiuGev4ebfF3ccVDVYgsUXM4mZM+RmyBoMKJ64fNtXO+esBNSBqAPH2GzK
 WE426lq+MPXj4kG5WXGiW7oDY4L1jYM8yEH+E5NL1MdEXZmDiKvPvRQjEfnaB8HJ
 9XgJCKEDSPuxD1lkmLhLzEke0SCN+r+CoDbbyL5MSPzCSQjeYxCy27iO7yg/G/65
 +wzPwLTtR2V/ujuDcYUVXCDff/Uqcs44rlcfQ9fzpOyWa0Z2bZ+7zyVs4xhwhW4Y
 Y8tV+yLXRjwPMyoUv+ODDbEZlUpob2Kj9wiVqB/9r4lwunDpDUzTq1v2+JNl9jTr
 R1ZGkOAUMKWZzxhaJqgj
 =N7Lu
 -END PGP SIGNATURE-
 
 --tdVUlQTxnujgnAno--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org

Re: [Bug 207223] acpica/acpi_battery.c: introduce hw.acpi.battery.rate sysctl

2016-03-10 Thread Konstantin Schukraft 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/10/2016 15:35, bugzilla-nore...@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207223
> 
> --- Comment #4 from Sean Bruno  --- hrm.  Is it
> mW/second or something?  A rate indicates some factor of time.
> 
Watt already is Joule/second, i.e. Energy per Time
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJW4ZWBAAoJEH3raMNeVmMFoCcQAKDx6JonRNEbcLRs1f40ObNg
UTiLfgFtlh+N5PlXxFIwOThir18EC/cOk/v0E+/jy6FDjp6Pg2xKuQxyQpgIi3I3
0pZMq8+s5NMF29asWdJ3ogh1JfgV1kialU9bXkm9eMzvC5/9pRVhTSR4Y49QJUO2
T4vcybE8K61pJI+K5vacHY3wwE7AL7aHE0srlrD6EUXgFcQ238vUwEVYE2w0fZrD
XKvOTl2tCQs8WnY1n80zjB/eh8x3Bd1q/hWu9WdIrZTyh8tbSgQwVZMQ4bUx6Bep
FTuHSgkW28SZ+drlwjg9/Mlv+VZLSsOIJkXV5v9H4+Ylln1hYktlndyBTyVq9c1x
wqhzizGUimmCUl00eRmlEG65JO4ArRxsnhrsV8gBUKj6HqMQ/Bu7UmLU8if69/lH
6xGCDMBxSKViBYAzrCvTNTzrKHrTu1ESKE4mz32wZ7cwo/nqAX114o4nnmdkk8tb
/rp6jmmYAVezoSWp9r/zzl3zHMBU5WWFV5eBDmHvzT+pWrfLhO61sL5SHZz9JqUk
UWmQiQ258OvgWRLFCodncKvnUVqglit2QtUjJnWtzIjHbfbmQCvZmfb934al5GsB
qbz3G4lIVTtBtoeV8XtLZtx/pFQDnzyG+2jXV/YWh6lZpsPI8+HLDMd+QQPWm31X
DozkOtiwz12PSq+2T3lx
=7dwQ
-END PGP SIGNATURE-
___
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"

Re: vt [was: Re: [Bug 235564] INDEX.keymaps for vt contains "from-" keymaps but the files are missing]

2020-03-09 Thread Konstantin Belousov 
On Mon, Mar 09, 2020 at 10:37:52AM -0400, Ed Maste wrote:
> On Sun, 8 Mar 2020 at 17:13, Andy Farkas  wrote:
> >
> > Is anyone actually working on the vt(4) driver?  Will it ever
> > become feature-parity with the old sc(4) driver?
> 
> Yes, and yes. What specific missing functionality are you affected by?
> 
> > I've noticed some weird things happening on my console recently...
> > like psychedelicly-colour-coded kernel messages.. far out, man.
> 
> I don't think this is related to vt(4), but it would help if you
> provided more details (including the version you're running).
Take a look at r334530.
___
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"