[Bug 224498] ls -lh does not display properly around 1MB, 1GB, ...

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498

--- Comment #4 from Masachika ISHIZUKA  ---
(In reply to Pawel Biernacki from comment #3)

Thank you for patch.
I apply this patch to 12.0-CURRENT r327074, the right value is shown with ls
-lh.

-- 
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 224498] ls -lh does not display properly around 1MB, 1GB, ...

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498

Mark Linimon  changed:

   What|Removed |Added

Summary|ls -lh dose not display |ls -lh does not display
   |properly around 1MB, 1GB,   |properly around 1MB, 1GB,
   |... |...
   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 224512] new device ID for nctgpio.c (APU3)

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224512

Mark Linimon  changed:

   What|Removed |Added

Summary|new device ID for nctgpio   |new device ID for nctgpio.c
   |(APU3)  |(APU3)
   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 224512] new device ID for nctgpio (APU3)

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224512

Bug ID: 224512
   Summary: new device ID for nctgpio (APU3)
   Product: Base System
   Version: 11.1-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: m...@sentex.net

Created attachment 189024
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189024=edit
patch against driver source

The PCEngines APU3 has a new gpio chip that is not recognized by the existing
driver due to a new ID.  The attached simple diff provides GPIO functionality
to the APU3 and FreeBSD.
kldload /tmp/nctgpio.ko

gpio0:  at port 0x2e-0x2f on isa0
gpiobus0:  on gpio0
gpioc0:  on gpio0

# gpioctl -l
pin 00: 1   GPIO00
pin 01: 1   GPIO01
pin 02: 1   GPIO02
pin 03: 1   GPIO03
pin 04: 1   GPIO04
pin 05: 1   GPIO05
pin 06: 1   GPIO06
pin 07: 1   GPIO07
pin 08: 1   GPIO08
pin 09: 1   GPIO09
pin 10: 1   GPIO10
pin 11: 1   GPIO11
pin 12: 1   GPIO12
pin 13: 1   GPIO13
pin 14: 1   GPIO14
pin 15: 1   GPIO15
# sysctl -a | grep gpio
dev.gpioc.0.%parent: gpio0
dev.gpioc.0.%pnpinfo: 
dev.gpioc.0.%location: 
dev.gpioc.0.%driver: gpioc
dev.gpioc.0.%desc: GPIO controller
dev.gpioc.%parent: 
dev.gpiobus.0.%parent: gpio0
dev.gpiobus.0.%pnpinfo: 
dev.gpiobus.0.%location: 
dev.gpiobus.0.%driver: gpiobus
dev.gpiobus.0.%desc: GPIO bus
dev.gpiobus.%parent: 
dev.gpio.0.%parent: isa0
dev.gpio.0.%pnpinfo: 
dev.gpio.0.%location: 
dev.gpio.0.%driver: gpio
dev.gpio.0.%desc: Nuvoton NCT5104D (PC-Engines APU3)
dev.gpio.%parent: 
#

-- 
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 224498] ls -lh dose not display properly around 1MB, 1GB, ...

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498

--- Comment #3 from Pawel Biernacki  ---
Please see https://reviews.freebsd.org/D13578 for proposed patch.

Issue was caused by the way the final value was calculated in snprintf call,
where remainder and divisor/2 was added back to the divided number. If
remainder + divisor/2 was larger than 1024, it added 1 to the final value. If
the final value as already 999 (as in the example reported), that brought it to
1000. If the buffer length provided was 4 (as is the case with ls), that left
no space for the unit character. 
Same issue was also present for other numbers if too small buffer lengths where
used.

The fix continues the division of the original number if the above case happens
-- added the appropriate check to the for loop performing the division. This
lowers the value shown, to make it fit into the buffer space provided (1.0M for
4 character buffer, as used by ls).

-- 
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 224426] fetch -i runs in an endless loop

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224426

Zak  changed:

   What|Removed |Added

 CC||zsnaf...@edu.uwaterloo.ca

--- Comment #1 from Zak  ---
Created attachment 189014
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189014=edit
proposed patch to fetch to avoid endless loop

Not sure if this is the best solution, but it seems to work for the case you've
encountered. It looks like the issue is due to HTTP and HTTPS being treated
slightly differently. I don't know if this is indicative of a deeper problem
though.

-- 
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 224498] ls -lh dose not display properly around 1MB, 1GB, ...

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498

Pawel Biernacki  changed:

   What|Removed |Added

 CC||pawel.bierna...@gmail.com

--- Comment #2 from Pawel Biernacki  ---
I'm close to having a fix for this.  Root cause is outside ls.

-- 
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 224503] rpcbind: Broken in the face of signal termination

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224503

Conrad Meyer  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd...@freebsd.org
 CC||rmack...@freebsd.org

--- Comment #1 from Conrad Meyer  ---
Tentatively throwing at -fs@ as rpcbind is a component of NFS

-- 
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 224503] rpcbind: Broken in the face of signal termination

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224503

Bug ID: 224503
   Summary: rpcbind: Broken in the face of signal termination
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: c...@freebsd.org

Rpcbind may crash in signal-induced termination.

E.g.:

> (gdb) bt
> ...
> #12 __free (ptr=0x8006f8140) at jemalloc_jemalloc.c:1277
> #13 0x000800d4c8e7 in vector_free (esize=, vec= out>, count=, esize=, free_elem=)
> at /b/mnt/src/lib/libc/net/nsdispatch.c:250
> #14 nss_atexit () at /b/mnt/src/lib/libc/net/nsdispatch.c:577
> #15 0x000800d4d5b9 in __cxa_finalize (dso=0x0) at 
> /b/mnt/src/lib/libc/stdlib/atexit.c:200
> #16 0x000800cfe1ac in exit (status=2) at 
> /b/mnt/src/lib/libc/stdlib/exit.c:67
> #17 0x00404df5 in terminate (signum=-26832) at 
> /b/mnt/src/usr.sbin/rpcbind/rpcbind.c:860
> #18 0x00080337f67b in handle_signal (actp=, sig=15, 
> info=0x7fffa9f0, ucp=0x7fffa680) at 
> /b/mnt/src/lib/libthr/thread/thr_sig.c:240
> #19 0x00080337f263 in thr_sighandler (sig=15, info=0x7fffa9f0, 
> _ucp=0x800700210) at /b/mnt/src/lib/libthr/thread/thr_sig.c:183

rpcbind got a sig 15 (TERM) and attempted to call exit(3) from a signal
handler.  But, exit(3) is not an async-signal safe function.  Probably these
crashes are the result of the program manipulating jemalloc internal structures
at the time the SIGTERM is delivered and handled unsafely.

The cause can be explained:

195 /* catch the usual termination signals for graceful exit */
196 (void) signal(SIGCHLD, reap);
197 (void) signal(SIGINT, terminate);
198 (void) signal(SIGTERM, terminate);
199 (void) signal(SIGQUIT, terminate);
...

758 /*
759  * Catch the signal and die
760  */
761 static void
762 terminate(int signum __unused)
763 {
764 close(rpcbindlockfd);
765 #ifdef WARMSTART
766 syslog(LOG_ERR,
767 "rpcbind terminating on signal %d. Restart with \"rpcbind
-w\"",
768 signum);
769 write_warmstart();  /* Dump yourself */
770 #endif
771 exit(2);
772 }
...

// close(2) is async-safe -- rpcbindlockfd must be initalized before the signal
is
// delivered, though.
//
// syslog() is definitely not safe.
//
// write_warmstart() uses fopen(3), syslog(3), ... definitely not safe.
//
// Finally, exit(3) itself is not safe either.

857 void
858 reap(int dummy __unused)
859 {
860 int save_errno = errno;
861
862 while (wait3(NULL, WNOHANG, NULL) > 0)
863 ;
864 errno = save_errno;
865 }

// wait(2) and waitpid(2) are allowed, but wait3() is not documented as allowed
in
// sigaction(2).  It likely is allowed, though, given it is implemented
identically
// to wait(2) (in terms of wait4(2)).  So `reap` for SIGCHLD is probably ok.

-- 
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 224498] ls -lh dose not display properly around 1MB, 1GB, ...

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498

Conrad Meyer  changed:

   What|Removed |Added

 CC||c...@freebsd.org

--- Comment #1 from Conrad Meyer  ---
Confirmed on CURRENT (August 28, 2017):

$ touch test1m test1g
$ truncate -s1023500 test1m
$ truncate -s1023500k test1g
$ ls -lhtr
...
-rw-r--r--   1 conrad  conrad   1000 Dec 21 09:09 test1g
-rw-r--r--   1 conrad  conrad   1000 Dec 21 09:09 test1m

Also observed the same behavior on CURRENT from yesterday (December 20, 2017),
r326983.

-- 
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 224498] ls -lh dose not display properly around 1MB, 1GB, ...

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498

Bug ID: 224498
   Summary: ls -lh dose not display properly around 1MB, 1GB, ...
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: i...@amail.plala.or.jp

ls -lh dose not display properly around 1MB, 1GB, ...

I tested on FreeBSD 11.1-RELEASE-p4 and 12-Current r326890 as follows.

% dd if=/dev/zero of=test-around-1mb bs=1023500 count=1
1+0 records in
1+0 records out
1023500 bytes transferred in 0.000443 secs (2307981987 bytes/sec)
% dd if=/dev/zero of=test-around-1gb bs=1023500k count=1
1+0 records in
1+0 records out
1048064000 bytes transferred in 0.416685 secs (2515240183 bytes/sec)
% ls -l test-around-1*
-rw-r--r--  1 ishizuka  wheel  1048064000 Dec 21 19:27 test-around-1gb
-rw-r--r--  1 ishizuka  wheel 1023500 Dec 21 19:27 test-around-1mb
% ls -lh test-around-1*
-rw-r--r--  1 ishizuka  wheel   1000 Dec 21 19:27 test-around-1gb
-rw-r--r--  1 ishizuka  wheel   1000 Dec 21 19:27 test-around-1mb

-- 
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 224496] mpr and mps drivers seems to have issues with large seagate drives

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496

Christoph Bubel  changed:

   What|Removed |Added

   Hardware|Any |amd64
   Severity|Affects Only Me |Affects Some People

-- 
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 224496] mpr and mps drivers seems to have issues with large seagate drives

2017-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496

Bug ID: 224496
   Summary: mpr and mps drivers seems to have issues with large
seagate drives
   Product: Base System
   Version: 11.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: cbu...@mailbox.org

Over on the Freenas forums several people reported issues with large (10TB)
Seagate drives (ST1NM0016 and ST1VN0004) and LSI controllers. Links to
the threads:
https://forums.freenas.org/index.php?threads/lsi-avago-9207-8i-with-seagate-10tb-enterprise-st1nm0016.58251/
https://forums.freenas.org/index.php?threads/synchronize-cache-command-timeout-error.55067/

I am using the ST1NM0016 drives and i am getting the following errors on a
LSI SAS2308 (mps driver) and on a LSI SAS3008 (mpr driver). This happens about
once every one or two weeks in low load situations. 

Here the logs:

(da2:mps0:0:1:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00
length 0 SMID 1010 command timeout cm 0xfef7cda0 ccb 0xf8018198d800
(noperiph:mps0:0:4294967295:0): SMID 1 Aborting command 0xfef7cda0
mps0: Sending reset from mpssas_send_abort for target ID 1
(da2:mps0:0:1:0): WRITE(16). CDB: 8a 00 00 00 00 02 e1 76 9f 88 00 00 00 08 00
00 length 4096 SMID 959 terminated ioc 804b scsi 0 state c xfer 0
mps0: Unfreezing devq for target ID 1
(da2:mps0:0:1:0): WRITE(16). CDB: 8a 00 00 00 00 02 e1 76 9f 88 00 00 00 08 00
00 
(da2:mps0:0:1:0): CAM status: CCB request completed with an error
(da2:mps0:0:1:0): Retrying command
(da2:mps0:0:1:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 
(da2:mps0:0:1:0): CAM status: Command timeout
(da2:mps0:0:1:0): Retrying command
(da2:mps0:0:1:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 
(da2:mps0:0:1:0): CAM status: SCSI Status Error
(da2:mps0:0:1:0): SCSI status: Check Condition
(da2:mps0:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus
device reset occurred)
(da2:mps0:0:1:0): Error 6, Retries exhausted
(da2:mps0:0:1:0): Invalidating pack

---

(da1:mpr0:0:4:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00
length 0 SMID 319 Aborting command 0xfef54a90
mpr0: Sending reset from mprsas_send_abort for target ID 4
(da1:mpr0:0:4:0): WRITE(16). CDB: 8a 00 00 00 00 03 35 b7 b9 f0 00 00 00 28 00
00 length 20480 SMID 320 terminated ioc 804b loginfo 3113 scsi 0 state c
xfer 0
mpr0: Unfreezing devq for target ID 4
(da1:mpr0:0:4:0): WRITE(16). CDB: 8a 00 00 00 00 03 35 b7 b9 f0 00 00 00 28 00
00 
(da1:mpr0:0:4:0): CAM status: CCB request completed with an error
(da1:mpr0:0:4:0): Retrying command
(da1:mpr0:0:4:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 
(da1:mpr0:0:4:0): CAM status: Command timeout
(da1:mpr0:0:4:0): Retrying command
(da1:mpr0:0:4:0): WRITE(16). CDB: 8a 00 00 00 00 03 35 b7 b9 f0 00 00 00 28 00
00 
(da1:mpr0:0:4:0): CAM status: SCSI Status Error
(da1:mpr0:0:4:0): SCSI status: Check Condition
(da1:mpr0:0:4:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus
device reset occurred)
(da1:mpr0:0:4:0): Retrying command (per sense data)
(da1:mpr0:0:4:0): WRITE(16). CDB: 8a 00 00 00 00 03 35 b7 ba 80 00 00 00 20 00
00 length 16384 SMID 653 terminated ioc 804b loginfo 31110e03 scsi 0 state c
xfer 0
(da1:mpr0:0:4:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00
length 0 SMID 711 terminated ioc 804b loginfo 311(da1:mpr0:0:4:0): WRITE(16).
CDB: 8a 00 00 00 00 03 35 b7 ba 80 00 00 00 20 00 00 
10e03 scsi 0 state c xfer 0
(da1:mpr0:0:4:0): CAM status: CCB request completed with an error
(da1:mpr0:0:4:0): Retrying command
(da1:mpr0:0:4:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 
(da1:mpr0:0:4:0): CAM status: CCB request completed with an error
(da1:mpr0:0:4:0): Retrying command
(da1:mpr0:0:4:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 
(da1:mpr0:0:4:0): CAM status: SCSI Status Error
(da1:mpr0:0:4:0): SCSI status: Check Condition
(da1:mpr0:0:4:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus
device reset occurred)
(da1:mpr0:0:4:0): Error 6, Retries exhausted
(da1:mpr0:0:4:0): Invalidating pack
(pass1:mpr0:0:4:0): ATA COMMAND PASS THROUGH(16). CDB: 85 06 2c 00 da 00 00 00
00 00 4f 00 c2 00 b0 00 length 0 SMID 797 terminated ioc 804b loginfo 31110e03
scsi 0 state c xfer 0
(pass1:mpr0:0:4:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0e 00 d0 00 01 00
00 00 4f 00 c2 00 b0 00 length 512 SMID 753 terminated ioc 804b loginfo
31110e03 scsi 0 state c xfer 0
(pass1:mpr0:0:4:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0e 00 d5 00 01 00
06 00 4f 00 c2 00 b0 00 length 512 SMID 846 terminated ioc 804b loginfo
31110e03 scsi 0 state c xfer 0
(pass1:mpr0:0:4:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0e 00 d5 00 01