[Bug 241980] panic: I/O to pool appears to be hung on vdev

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241980

--- Comment #19 from Andriy Gapon  ---
(In reply to Eugene Grosbein from comment #18)
There is no reason why deadman_enabled had to be read-only. But the code needs
to be careful to stop and restart the callout when the deadman logic is
disabled and enabled.  Maybe we can have the callout always running, then we
need to check the flag in the callout callback.

Also, I think that there is a bug in the early warning code.  I think that the
warning timeout is 8 times longer that the regular timeout.

The best way to debug the problem would be to get a crash dump.
Maybe you could try to add a dedicated dump disk and connect it to a different
controller, etc.
But if you can't get that to work, then I suggest that you add more useful
information to the early warning.  You can print a pointer to zio and a pointer
to vdev.  Then you'd be able to use kgdb on a live kernel and you would have a
place to start.

Just my 2 cents as they say.

-- 
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 241980] panic: I/O to pool appears to be hung on vdev

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241980

--- Comment #20 from Eugene Grosbein  ---
This is dedicated server in Hetzner. Well, it has another SATA controller seen
as:

ahci0@pci0:0:17:5:  class=0x010601 card=0x07161028 chip=0xa1d28086 rev=0x09
hdr=0x00
vendor = 'Intel Corporation'
device = 'C620 Series Chipset Family SSATA Controller [AHCI mode]'
class  = mass storage
subclass   = SATA

But first I'd like to disable panicing by zfs_deadman and see if distinct ZFS
boot pool is alive in such moment. I already tried booting patched zfs.ko by
means of nextboot.conf and
module_path="/boot/nextboot;/boot/kernel;/boot/modules". Additionally, I've
enabled hardware watchdog in BIOS setup (the server has distinct public IP for
console via virtual KVM) and enabled watchdogd.

Sadly, I made a misprint and it booted with default unpatched zfs.ko and I
missed that, so another same panic that occured today gave me little but
interesting information: the watchdog works and dmesg buffer is not cleared
between reboots, so I have KDB trace in /var/log/kernel.log after reboot
(kern.* messages logged there). I've fixed the misprint, will reboot again and
wait.

Thank you for your remark about early warning, now I see you are right. I'll
fix it.

-- 
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 242106] [panic] zfree(0xe4e9690,8224): wild pointer during install from 12.1R amd64 ISO in Parallels VM

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242106

Bug ID: 242106
   Summary: [panic] zfree(0xe4e9690,8224): wild pointer during
install from 12.1R amd64 ISO in Parallels VM
   Product: Base System
   Version: 12.1-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: d...@freebsd.org

Created attachment 209278
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=209278&action=edit
parallels vm boot screen

..
FreeBSD/x86 bootstrap loader revision 1.1
cd0: read 1 sector(s) from 8094719 to 0xe000 (8x8000): 0x1

panic: zfree(0xe4e9690,8224): wild pointer
--> Press a key on the console to reboot <--

- Parallels v15
- sha of downloaded images matches
- happens with mini iso and full iso
- doesn't matter if I use SATA or IDE connection in vm
- doesn't matter if I change emulation/hypervisor engine in vm

-- 
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 241714] /usr/bin/diff --tabsize dies with SIGSEGV

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241714

--- Comment #4 from rlwestl...@gmail.com ---
Oh, that explains it. I thought it crashed even if I passed it an option
because I was trying to pass it with a space. You're right, with --tabisze=3 it
doesn't crash.

-- 
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 133213] arp and sshd errors on 7.1-PRERELEASE

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133213

Ed Maste  changed:

   What|Removed |Added

 Resolution|--- |Overcome By Events
 Status|Open|Closed
 CC||ema...@freebsd.org

--- Comment #5 from Ed Maste  ---
7.x is out of support long ago. Please submit a new issue if this problem
recurs on contemporary FreeBSD.

-- 
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 241831] freebsd-update from 11.3 to 12.1 causes error messages "Directory not empty"

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241831

pvo...@uos.de changed:

   What|Removed |Added

 CC||pvo...@uos.de

--- Comment #3 from pvo...@uos.de ---
Well, can confirm exactly the same error/warning on two different machines
during 11.3 -> 12.1 upgrade.

-- 
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 240356] sshd Connection closed by 127.0.0.1 port ???

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240356

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org
 Status|New |Closed
 Resolution|--- |Works As Intended

--- Comment #1 from Ed Maste  ---
sshd is just logging that you have something connecting to the ssh port, and
then disconnecting before authentication. If you want to avoid this message
you'll need to find out what is making the connection and stop it from doing
so.

A quick Google search suggests Nagios ssh check might have this behaviour - see
https://support.microfocus.com/kb/doc.php?id=7014539

-- 
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 214226] sshd RekeyLimit does not appear to change the maximum amount of data

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214226

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #1 from Ed Maste  ---
Which sshd version?

-- 
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 242109] riscv64 build with binutils 2.33.1

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242109

Bug ID: 242109
   Summary: riscv64 build with binutils 2.33.1
   Product: Base System
   Version: CURRENT
  Hardware: Any
   URL: https://reviews.freebsd.org/D22457
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: lw...@freebsd.org

riscv64 build fails with binutils 2.33.1:

```
/usr/local/bin/riscv64-unknown-freebsd12.0-gcc
--sysroot=/scratch/tmp/lwhsu/obj/scratch/tmp/lwhsu/src/riscv.riscv64/tmp
-B/usr/local/riscv64-unknown-freebsd12.0/bin/ -O2 -pipe -march=rv64imafdc
-mabi=lp64d -I. -I/scratch/tmp/lwhsu/src/usr.sbin/jail -DINET6 -DINET -g
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
-Wno-error=address -Wno-error=array-bounds -Wno-error=attributes
-Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered
-Wno-error=deprecated-declarations -Wno-error=enum-compare -Wno-error=extra
-Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing
-Wno-error=uninitialized -Wno-error=unused-but-set-variable
-Wno-error=unused-function -Wno-error=unused-value
-Wno-error=misleading-indentation -Wno-error=nonnull-compare
-Wno-error=shift-negative-value -Wno-error=tautological-compare
-Wno-error=unused-const-variable -Wno-error=bool-operation
-Wno-error=deprecated -Wno-error=expansion-to-defined
-Wno-error=format-overflow -Wno-error=format-truncation
-Wno-error=implicit-fallthrough -Wno-error=int-in-bool-context
-Wno-error=memset-elt-size -Wno-error=noexcept-type -Wno-error=nonnull
-Wno-error=pointer-compare -Wno-error=stringop-overflow
-Wno-error=aggressive-loop-optimizations -Wno-error=cast-function-type
-Wno-error=catch-value -Wno-error=multistatement-macros -Wno-error=restrict
-Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation-o
jail.full jail.o command.o config.o state.o jaillex.o jailparse.o   -ljail 
-lkvm  -lutil
jailparse.o: in function `yyparse':
/scratch/tmp/lwhsu/src/usr.sbin/jail/jailparse.y:75:(.text+0xfe): relocation
truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
collect2: error: ld returned 1 exit status
*** [jail.full] Error code 1

make[4]: stopped in /scratch/tmp/lwhsu/src/usr.sbin/jail
1 error
```

Workaround patch at https://reviews.freebsd.org/D22457

-- 
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 242109] riscv64 build with binutils 2.33.1

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242109

--- Comment #1 from commit-h...@freebsd.org ---
A commit references this bug:

Author: lwhsu
Date: Wed Nov 20 16:20:49 UTC 2019
New revision: 354896
URL: https://svnweb.freebsd.org/changeset/base/354896

Log:
  Workaround riscv64 build when using binutils 2.33.1

  PR:   242109
  Reviewed by:  bapt
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D22457

Changes:
  head/usr.sbin/jail/Makefile

-- 
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 242111] devd.conf(5) attach rule doesn't work for USB devices

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242111

Bug ID: 242111
   Summary: devd.conf(5) attach rule doesn't work for USB devices
   Product: Base System
   Version: 12.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: y...@freebsd.org

I tried to use this rule:
> attach 0 {
> match "vendor"  "0x04b4";
> match "product" "0x6022";
> action "/bin/echo hello $device-name >> /tmp/dev.txt";
> };

but it doesn't work (no /tmp/dev.txt appears).


But this rule works:
> notify 100 {
> match "system"  "USB";
> match "subsystem"   "DEVICE";
> match "type""ATTACH";
> match "vendor"  "0x04b4";
> match "product" "0x6022";
> action "/bin/echo hello $device-name >> /tmp/dev.txt";
> };


Some other system-supplied rules in /etc/devd.conf use the first form too,
which means that they also wouldn't work when the matching device would appear?




> ugen8.5:  at usbus8

FreeBSD xx.xx.xx 12.0-STABLE FreeBSD 12.0-STABLE r347548 GENERIC  amd64

-- 
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 242109] riscv64 build with binutils 2.33.1

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242109

--- Comment #2 from commit-h...@freebsd.org ---
A commit references this bug:

Author: lwhsu
Date: Wed Nov 20 16:35:59 UTC 2019
New revision: 354899
URL: https://svnweb.freebsd.org/changeset/base/354899

Log:
  Limit the workaround to riscv only

  PR:   242109
  Sponsored by: The FreeBSD Foundation

Changes:
  head/usr.sbin/jail/Makefile

-- 
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 242111] devd.conf(5) attach rule doesn't work for USB devices

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242111

--- Comment #1 from Yuri Victorovich  ---
Additionally, $device-name expands to the empty string for in the above
command.

-- 
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 242109] riscv64 build with binutils 2.33.1

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242109

--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:

Author: lwhsu
Date: Wed Nov 20 16:54:22 UTC 2019
New revision: 354900
URL: https://svnweb.freebsd.org/changeset/base/354900

Log:
  Use the correct variable, also limit the scope to bfd

  PR:   242109
  Reported by:  jhb
  Sponsored by: The FreeBSD Foundation

Changes:
  head/usr.sbin/jail/Makefile

-- 
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 242087] aacraid: with system aacraid instead of vendor aacraid, all disks from the controller disappeared

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242087

--- Comment #2 from Igor  ---
Sorry, I did not put it very clearly. The problem occurred when I switching
vendor aacu64.ko (for FreeBSD9) to vendor aacraidu.ko (for FreeBSD10). The
behavior of the vendor driver and the system driver are the same in FreeBSD10
and higher.

How can I add the 3rd bit to the disk flag?

-- 
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 242109] riscv64 build with binutils 2.33.1

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242109

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #4 from Ed Maste  ---
build is failing in cirrus-ci with

--- cleandir_subdir_usr.sbin ---
make[4]: "/tmp/cirrus-ci-build/usr.sbin/jail/Makefile" line 21: Malformed
conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")

https://cirrus-ci.com/task/6720128841940992?command=main#L11090

-- 
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 242087] aacraid: with system aacraid instead of vendor aacraid, all disks from the controller disappeared

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242087

--- Comment #3 from Andriy Gapon  ---
Maybe something like
hint.aacraid.0.flags="0x8"
in /boot/device.hints ?

-- 
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 241710] please increase ARG_MAX

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241710

--- Comment #16 from Pedro F. Giffuni  ---
Created attachment 209299
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=209299&action=edit
Option 1: double ARG_MAX for all platforms

Attempt to summarise the options:

Option 1: Double ARG_MAX and keep the same value consistently in all archs.

(May break some platforms like ARM7 that are KVA constrained - needs approval
by ARM expert).

-- 
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 241710] please increase ARG_MAX

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241710

Pedro F. Giffuni  changed:

   What|Removed |Added

 Attachment #209195|0   |1
is obsolete||

--- Comment #17 from Pedro F. Giffuni  ---
Created attachment 209300
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=209300&action=edit
Option 2: leave ARG_MAX untouched for IPL32 but increment for LP64

Option 2: discriminate ARG_MAX for different args but greatly increment the
value for others.

2X is enough to build Code Aster, but perhaps 3X is a better value(?). Illumos
uses ~4X for ILP32 (they don't support ARM) and ~8X for _LP64.

-- 
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 241710] please increase ARG_MAX

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241710

John Baldwin  changed:

   What|Removed |Added

 CC||j...@freebsd.org

--- Comment #18 from John Baldwin  ---
Perhaps we could just let the ARM folks figure out if there is a problem and if
so they can add an #ifdef?  On a quad-core ARMv7 (e.g. my RPi), doubling
ARG_MAX would use an additional 2MB of KVA (256K * (2 * 4 CPUs)).  I don't know
if we have any non-terrible ways to see the kernel_map.  I have some gdb
scripts that I've only tested on amd64 but do handle submaps.  I thought we had
a hack to export the kernel map via pid 0 for procstat -v, but that doesn't
seem to work for me.

-- 
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 242128] Add ID for Diamond Multimedia BVU195 Display Link device

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242128

Bug ID: 242128
   Summary: Add ID for Diamond Multimedia BVU195 Display Link
device
   Product: Base System
   Version: 12.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: dar...@dons.net.au

Created attachment 209308
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=209308&action=edit
patch

With this diff I can run X etc..
I only tested it at 1280x1024 but it seemed fine - the chip type is a guess
though, I am not sure how to find out what it is.

I disassembled the device but the heatsink is glued on to it so it's hard to
find out.

-- 
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 242128] Add ID for Diamond Multimedia BVU195 Display Link device

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242128

dar...@dons.net.au changed:

   What|Removed |Added

  Component|kern|usb
   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 242128] Add ID for Diamond Multimedia BVU195 Display Link device

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242128

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|u...@freebsd.org
   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 242131] libusb_set_auto_detach_kernel_driver(3) causes libusb_claim_interface(3) to fail

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242131

Bug ID: 242131
   Summary: libusb_set_auto_detach_kernel_driver(3) causes
libusb_claim_interface(3) to fail
   Product: Base System
   Version: 12.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: y...@freebsd.org
 Attachment #209310 text/plain
 mime type:

Created attachment 209310
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=209310&action=edit
usb.cpp

The attached usb.cpp fails (when the supported device is present) at
libusb_claim_interface when libusb_set_auto_detach_kernel_driver is called
before it.

Removing libusb_set_auto_detach_kernel_driver makes libusb_claim_interface to
succeed.

I had to patch the port misc/openhantek with the workaround for this issue in
order to make it to work.

-- 
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 242131] libusb_set_auto_detach_kernel_driver(3) causes libusb_claim_interface(3) to fail

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242131

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|u...@freebsd.org
  Component|misc|usb

-- 
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 242132] Wrong GSS credentials cache expiration date for indefinite tickets

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242132

Bug ID: 242132
   Summary: Wrong GSS credentials cache expiration date for
indefinite tickets
   Product: Base System
   Version: 12.1-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: p...@lysator.liu.se

Created attachment 209312
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=209312&action=edit
Patch to fix the cred_lifetime bug and add a kern.rpc.gss.lifetime_max sysctl

This is a bug that probably never happens in real life, or is masked by other
factors, but I think it's a bug anyway...

In
/usr/src/sys/rpc/rpcsec_gss/svc_rpcsec_gss.c:svc_rpc_gss_accept_sec_context()
there is a check:

 if (cred_lifetime == GSS_C_INDEFINITE)
cred_lifetime = time_uptime + 24*60*60;

client->cl_expiration = time_uptime + cred_lifetime;

The assignment in the if-statement should be "cred_lifetime = 24*60*60;"
because the current code would set client->cl_expiration to
2*time_uptime+24*60*60 - if it ever was GSS_C_INDEFINITE. Atleast until year
2106 or so (when the unsigned 32bit cred_lifetime will wrap around)... 

Cache entries are invalidated when NFS shares are unmounted and most Kerberos
tickets do have a lifetime (10 hours typically) so this probably almost never
happens in real life but anyway...

I'd also like to propose adding a sysctl() where one can cap the cred_lifetime
to a lower value than the default (which is the ticket lifetime - about 10
hours on a "typical" system). With the current code a user being added to a new
group will not be "visible" for NFS until after the GSS cache entry expires (if
the user have something NFS-mounted from that server). It might be a good idea
to be able to force a lower timeout (like 1 hour or so).

-- 
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 242132] fix wrong GSS credentials cache expiration date for indefinite tickets

2019-11-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242132

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch
Summary|Wrong GSS credentials cache |fix wrong GSS credentials
   |expiration date for |cache expiration date for
   |indefinite tickets  |indefinite tickets

-- 
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"