device /dev/cd1 not visible

I have an internal DVD-ROM detected as /dev/cd0 which works OK. When I plug the external USB DVD-RW drive it is show in messages as: Jun 20 16:36:11 illbsd kernel: ugen1.4: Device> at usbus1 Jun 20 16:36:11 illbsd kernel: umass0 on uhub3 Jun 20 16:36:11 illbsd kernel: umass0: Device, class

Re: /dev/crypto not being used in 12-STABLE

On 18. 12. 7., Jung-uk Kim wrote: > On 18. 12. 7., Jeremy Chadwick wrote: >> https://github.com/openssl/openssl/pull/3744/files#diff-e4eb329834da3d36278b1b7d943b3bc9 >> >> *) Add devcrypto engine. This has been implemented against >> cryptodev-linux, >> then adjusted to work on FreeBSD

Re: /dev/crypto not being used in 12-STABLE

ttps://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html >>> https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html >>> >>> Based on what I can tell, OpenSSL 1.1.1 or thereabouts removed the >>> cryptodev OpenSSL engine, w

Re: /dev/crypto not being used in 12-STABLE

18-December/090202.html > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html > > > > Based on what I can tell, OpenSSL 1.1.1 or thereabouts removed the > > cryptodev OpenSSL engine, which was a tie-in to BSD's cryptodev(4), > > which is accessed

Re: /dev/crypto not being used in 12-STABLE

On Fri, 2018-12-07 at 18:38 -0500, Jung-uk Kim wrote: > > So while OpenSSL now uses more of its own native C and assembly code > > (e.g. for AES-NI support), and that's certainly faster than all the > > overhead that cryptodev(4) brings with it (see jhb@'s post), I wonder: > >  > > 1. What happens

Re: /dev/crypto not being used in 12-STABLE

02.html > > Based on what I can tell, OpenSSL 1.1.1 or thereabouts removed the > cryptodev OpenSSL engine, which was a tie-in to BSD's cryptodev(4), > which is accessed via /dev/crypto and related crypto(4) ioctls. > > Instead, they offered a replacement engine called devcrypto (wha

Re: /dev/crypto not being used in 12-STABLE

rectly. To elaborate further, aesni(4) is only useful to accelerate in-kernel crypto use (e.g. IPSec or GELI). The fact that /dev/crypto trys to use it by default is a bug (IMO) that I'm planning on addressi

Re: /dev/crypto not being used in 12-STABLE

the cryptodev OpenSSL engine, which was a tie-in to BSD's cryptodev(4), which is accessed via /dev/crypto and related crypto(4) ioctls. Instead, they offered a replacement engine called devcrypto (what an awful name), with the primary focus being against something from Linux called cryptodev-linux

Re: /dev/crypto not being used in 12-STABLE

On Thu, Dec 06, 2018 at 04:48:35PM -0700, John Nielsen wrote: > Is aesni(4) even required if all you want is userland acceleration? > No, it is not. Same for rdrand_rng(4), if an application uses hw random source directly. ___

Re: /dev/crypto not being used in 12-STABLE

LE to 12-STABLE recently >>>> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). >>>> I noticed today that neither machine seems to be utilizing /dev/crypto. >>>> Typically I see at least ssh/sshd have the device open plus some programs &g

Re: /dev/crypto not being used in 12-STABLE

EASE r341380 and the other is 12.0-PRERELEASE r341391). >>> I noticed today that neither machine seems to be utilizing /dev/crypto. >>> Typically I see at least ssh/sshd have the device open plus some programs >>> from ports. But 'fuser' doesn't list any processes on e

Re: /dev/crypto not being used in 12-STABLE

d two physical machines from 11-STABLE to 12-STABLE recently >>>> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). >>>> I noticed today that neither machine seems to be utilizing /dev/crypto. >>>> Typically I see at least ssh/sshd have the d

Re: /dev/crypto not being used in 12-STABLE

t; (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). > >> I noticed today that neither machine seems to be utilizing /dev/crypto. > >> Typically I see at least ssh/sshd have the device open plus some programs > >> from ports. But 'fuser'

Re: /dev/crypto not being used in 12-STABLE

EASE r341380 and the other is 12.0-PRERELEASE r341391). >>> I noticed today that neither machine seems to be utilizing /dev/crypto. >>> Typically I see at least ssh/sshd have the device open plus some programs >>> from ports. But 'fuser' doesn't list any processes on e

Re: /dev/crypto not being used in 12-STABLE

t;> noticed today that neither machine seems to be utilizing /dev/crypto. >> Typically I see at least ssh/sshd have the device open plus some programs >> from ports. But 'fuser' doesn't list any processes on either machine: >> >> # fuser /dev/crypto >> /dev/crypt

Re: /dev/crypto not being used in 12-STABLE

On Thu, Dec 6, 2018 at 11:37 AM John Nielsen wrote: > > I have upgraded two physical machines from 11-STABLE to 12-STABLE recently > (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). I > noticed today that neither machine seems to be utilizing /dev/crypto.

Re: /dev/crypto not being used in 12-STABLE

On Thu, 06 Dec 2018 20:19:44 +0100, John Nielsen wrote: > > I have upgraded two physical machines from 11-STABLE to 12-STABLE > recently (one is 12.0-PRERELEASE r341380 and the other is > 12.0-PRERELEASE r341391). I noticed today that neither machine seems > to be utilizing /dev/cr

/dev/crypto not being used in 12-STABLE

I have upgraded two physical machines from 11-STABLE to 12-STABLE recently (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). I noticed today that neither machine seems to be utilizing /dev/crypto. Typically I see at least ssh/sshd have the device open plus some programs

Re: svn commit: r334152 - in stable/11/sys: amd64/amd64 amd64/include dev/cpuctl i386/include x86/acpica x86/include x86/x86

On 5/25/2018 1:47 PM, Konstantin Belousov wrote: >> cpu I586_CPU >> options CPU_GEODE >> ident ALIX_DSK > You do not have the SMP option in the config, right ? Sorry, yes, you are correct. This config is for a single core CPU. I have these 3 commented out as well.

Re: svn commit: r334152 - in stable/11/sys: amd64/amd64 amd64/include dev/cpuctl i386/include x86/acpica x86/include x86/x86

On Fri, May 25, 2018 at 01:21:00PM -0400, Mike Tancsa wrote: > On 5/24/2018 9:17 AM, Konstantin Belousov wrote: > > Author: kib > > Date: Thu May 24 13:17:24 2018 > > New Revision: 334152 > > URL: https://svnweb.freebsd.org/changeset/base/334152 > > > > Log: > > MFC r334004: > > Add Intel

Re: svn commit: r334152 - in stable/11/sys: amd64/amd64 amd64/include dev/cpuctl i386/include x86/acpica x86/include x86/x86

On 5/24/2018 9:17 AM, Konstantin Belousov wrote: > Author: kib > Date: Thu May 24 13:17:24 2018 > New Revision: 334152 > URL: https://svnweb.freebsd.org/changeset/base/334152 > > Log: > MFC r334004: > Add Intel Spec Store Bypass Disable control. > > This also includes the

stable/11 -r326142 (e.g.): "cat /dev/null | zstd --stdout" gets "/usr/bin/zstd: Undefined symbol "stat@FBSD_1.5"

# cat /dev/null | zstd --stdout /usr/bin/zstd: Undefined symbol "stat@FBSD_1.5" # freebsd-version -ku 11.1-STABLE 11.1-STABLE # uname -apKU FreeBSD FBSDFS 11.1-STABLE FreeBSD 11.1-STABLE r326142 amd64 amd64 1101506 1101506 It was built from source: # svnlite info /usr/src/ Path:

Re: zfs, iSCSI and volmode=dev

t;> >> I have an iSCSI production system that exports a large number of >> zvols as the iSCSI targets. System is running FreeBSD >> 11.0-RELEASE-p7 and initially all of the zvols were confugured >> with default volmode. I've read that it's recommended

Re: zfs, iSCSI and volmode=dev

BSD 11.0-RELEASE-p7 and initially all of the zvols were confugured with default volmode. I've read that it's recommended to use them in dev mode, so the system isn't bothered with all of these geom structures, so I've switched all of the zvols to dev mode, then I exported/import

Re: zfs, iSCSI and volmode=dev

fault volmode. I've read that it's > recommended to use them in dev mode, so the system isn't bothered with all > of these geom structures, so I've switched all of the zvols to dev mode, > then I exported/imported the pools back. Surprisingly, the performance has > fallen down like 10

Re: zfs, iSCSI and volmode=dev

I have an iSCSI production system that exports a large number of zvols as the iSCSI targets. System is running FreeBSD 11.0-RELEASE-p7 and initially all of the zvols were confugured with default volmode. I've read that it's recommended to use them in dev mode, so the system isn't bothered

zfs, iSCSI and volmode=dev

Hi, I have an iSCSI production system that exports a large number of zvols as the iSCSI targets. System is running FreeBSD 11.0-RELEASE-p7 and initially all of the zvols were confugured with default volmode. I've read that it's recommended to use them in dev mode, so the system isn't

Re: svn commit: r322875 - head/sys/dev/nvme

2017-08-28 11:02 GMT+02:00 Mark Millard : > Based on the same main.cc as before . . . > > g++7 -std=c++98 main.cc > g++7 -Wpedantic -std=c++98 main.cc > g++7 -std=c++03 main.cc > g++7 -Wpedantic -std=c++03 main.cc > > no longer complain (so no error, no > warning). Perfect!

Re: svn commit: r322875 - head/sys/dev/nvme

On 2017-Aug-27, at 11:54 PM, Ed Schouten wrote: > 2017-08-25 14:53 GMT+02:00 Ed Schouten : >> 2017-08-25 9:46 GMT+02:00 Mark Millard : >>> It appears that at least 11.1-STABLE -r322807 does not handle >>> -std=c++98 styles of use of _Static_assert for g++7 in that >>> g++7 reports an error: >>

Re: svn commit: r322875 - head/sys/dev/nvme

Mark, 2017-08-25 14:53 GMT+02:00 Ed Schouten : > 2017-08-25 9:46 GMT+02:00 Mark Millard : >> It appears that at least 11.1-STABLE -r322807 does not handle >> -std=c++98 styles of use of _Static_assert for g++7 in that >> g++7 reports an error: > > Maybe we need

Re: svn commit: r322875 - head/sys/dev/nvme

On Fri, Aug 25, 2017 at 6:53 AM, Ed Schouten wrote: > 2017-08-25 9:46 GMT+02:00 Mark Millard : > > It appears that at least 11.1-STABLE -r322807 does not handle > > -std=c++98 styles of use of _Static_assert for g++7 in that > > g++7 reports an error: > > Maybe

Re: svn commit: r322875 - head/sys/dev/nvme

2017-08-25 9:46 GMT+02:00 Mark Millard : > It appears that at least 11.1-STABLE -r322807 does not handle > -std=c++98 styles of use of _Static_assert for g++7 in that > g++7 reports an error: Maybe we need to do something like this? Index: sys/sys/cdefs.h

Re: svn commit: r322875 - head/sys/dev/nvme

entation. sys/cdefs.h defines it to generate a zero-length array if > the condition is true or a negative-length array if it is false, emulating > the behaviour (though giving less helpful error messages) > >> >> As I understand head/sys/dev/nvme/nvme.h use by >> C+

Re: svn commit: r322875 - head/sys/dev/nvme

2017-08-25 8:32 GMT+02:00 Mark Millard : >> # g++49 main.cc >> main.cc:2:15: error: expected constructor, destructor, or type conversion >> before '(' token >> _Static_assert(1,"Test"); Yeah, that's because GCC is such a pain in the neck compiler that it doesn't want to

Re: svn commit: r322875 - head/sys/dev/nvme

ro-length array if the condition is true or a negative-length array if it is false, emulating the behaviour (though giving less helpful error messages) > > As I understand head/sys/dev/nvme/nvme.h use by > C++ code could now reject attempts to use > _Static_assert . In C++, _Static_asser

Re: svn commit: r322875 - head/sys/dev/nvme

nd rely on CTASSERT. Switch to using _Static_assert instead. > > MFC After: 3 days > Sponsored by: Netflix > > Modified: > head/sys/dev/nvme/nvme.h > head/sys/dev/nvme/nvme_util.c As I remember _Static_assert is from C11, not the older C99. As I understand head/sys/dev/nvm

Re: What is /dev/zfs?

on that device during > one execution and I'm asking myself what it tries > to do. > > Thanks! > Patrick The zpool and zfs commands do everything through ioctls, and /dev/zfs is the device node those ioctls are bound to. You can't read from it or write to it; all you can with /

What is /dev/zfs?

Hi, folks any pointer to an explanation would be nice, there seems to be no zfs(4) manpage ... Reason for asking: I have a piece of software that uses 14,000 ioctl() calls on that device during one execution and I'm asking myself what it tries to do. Thanks! Patrick signature.asc Description:

[LOR] 11.1-BETA1 dev/md/md.c <-> vm/vm_pager.c - lost begnin matchlist

found a previous report about: lock order reversal: 1st 0xfe03bca22c10 bufwait (bufwait) @ /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/vm_pager.c:370 2nd 0xf8001f9ff068 ufs (ufs) @ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/md/md.c:942 stack backtrace: #0 0x805e79b0

Re: /dev/dri registration

subdevice=0x34d6 class=0x03 at slot=0 function=0 dbsf=pci0:1:0:0 drm0 drmn0 nvidia0 But /dev/dri don't exist! # kldstat Id Refs AddressSize Name 1 80 0x8020 17e87f8 kernel 21 0x819e9000 309780 zfs.ko 32

Re: /dev/dri registration

=0x0a20 subvendor=0x1458 subdevice=0x34d6 class=0x03 at slot=0 function=0 dbsf=pci0:1:0:0 drm0 drmn0 nvidia0 But /dev/dri don't exist! # kldstat Id Refs AddressSize Name 1 80 0x8020 17e87f8 kernel 21

/dev/dri registration

=0 dbsf=pci0:1:0:0 drm0 drmn0 nvidia0 But /dev/dri don't exist! # kldstat Id Refs AddressSize Name 1 80 0x8020 17e87f8 kernel 21 0x819e9000 309780 zfs.ko 32 0x81cf3000 6040 opensolaris.ko 4

Re: ASM1062 AHCI timeouts, ppt(4) BAR aligning [Was: Re: svn commit: r309251 - head/sys/dev/ahci]

d by the device. Unfortunately I don't have > those fancy drives to try, but I'll try to reproduce it with regular CD > drive when I get back home after short New Year holidays. Oic, then I need to test the patch with regular SSD usage! I have had problems with the asm1062 when I used it

Re: ASM1062 AHCI timeouts, ppt(4) BAR aligning [Was: Re: svn commit: r309251 - head/sys/dev/ahci]

On 29.12.2016 10:35, Harry Schmalzbauer wrote: > I'd like to report that this doesn't fix timeouts for me (applied to > 11-stable). > > For example my REV120 works without problems on Intel-AHCI but not on > ASM1062-AHCI. > Even attaching gives different output. Both look fine at first: > #

ASM1062 AHCI timeouts, ppt(4) BAR aligning [Was: Re: svn commit: r309251 - head/sys/dev/ahci]

nux does too. > > MFC after: 1 month > > Modified: > head/sys/dev/ahci/ahci.c > > Modified: head/sys/dev/ahci/ahci.c > ====== > --- head/sys/dev/ahci/ahci.c Mon Nov 28 15:14:31 2016(r3

Re: Problems while reading from /dev/cd0

t; When i try to read the Disk via 'tar tvvf /dev/cd0' >> >> i get the following output >> >> -rw-r--r-- 0 root wheel 5793264611 1 Jan 2015 file1.db >> tar: Error reading '/dev/cd0' >> Archive Format: POSIX ustar format, Compression: none >> tar: Error ex

Re: Problems while reading from /dev/cd0

On 23 Aug 2016, at 08:50, Gerhard Schmidt <esta...@ze.tum.de> wrote: > > I'm having some very curios Problems while reading from an BD-R recorded > as a tar directly on the disk without a filesystem. > > When i try to read the Disk via 'tar tvvf /dev/cd0' > > i get th

Problems while reading from /dev/cd0

Hi, I'm having some very curios Problems while reading from an BD-R recorded as a tar directly on the disk without a filesystem. When i try to read the Disk via 'tar tvvf /dev/cd0' i get the following output -rw-r--r-- 0 root wheel 5793264611 1 Jan 2015 file1.db tar: Error reading '/dev

stable/11 -r304029: amd64-gcc says: sys/dev/hptmv/vdevice.h error: variably modified '_ArrayTables' at file scope

not blocked by the problem.] Attempting to build stable/11 -r304029 for TARGET_ARCH=amd64 with amd64-gcc (amd64-xtoolchain-gcc) reports: /usr/src/sys/dev/hptmv/vdevice.h:145:2: error: variably modified '_ArrayTables' at file scope [-Werror] BYTE_ArrayTables[MAX_ARRAY_PER_VBUS * ARRAY_VDEV_SIZE

Re: svn commit: r303107 - in stable/10/sys/dev: e1000 ixgb ixgbe ixl

-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -Werror /usr/src/sys/dev/ed/if_ed_pci.c ctfconvert -L VERSION -g if_ed_pci.o awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/eisa/eisa_if.m -c ;

FYI: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys

to r301451. > > > >Differential Revision: https://reviews.freebsd.org/D6634 > > > > Modified: > > head/sys/arm/arm/nexus.c > > head/sys/arm64/arm64/gic_v3.c > > head/sys/arm64/arm64/nexus.c > >head/sys/dev/fdt/simplebus.c > >

Re: [Bug 210953] 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to build: dev/ahci/ahci.c:288:22: error: unknown conversion type character 'b' in format; too many arguments for format

> On Jul 9, 2016, at 23:03, Mark Millard wrote: > > On 2016-Jul-9, at 8:53 PM, Ngie Cooper wrote: > >>> On Jul 9, 2016, at 18:52, bugzilla-nore...@freebsd.org wrote: >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210953 >>> >>> Mark Millard

Re: [Bug 210953] 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to build: dev/ahci/ahci.c:288:22: error: unknown conversion type character 'b' in format; too many arguments for format

On 2016-Jul-9, at 8:53 PM, Ngie Cooper wrote: >> On Jul 9, 2016, at 18:52, bugzilla-nore...@freebsd.org wrote: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210953 >> >> Mark Millard changed: > > I accidentally committed this regression to kern.mk. I don't have

Re: [Bug 210953] 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to build: dev/ahci/ahci.c:288:22: error: unknown conversion type character 'b' in format; too many arguments for format

rk Millard markmi at dsl-only.net On 2016-Jul-9, at 6:19 PM, Mark Millard wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210953 > > >Bug ID: 210953 > Summary: 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to > build: d

[Bug 210953] 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to build: dev/ahci/ahci.c:288:22: error: unknown conversion type character 'b' in format; too many arguments for format

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210953 > > > Bug ID: 210953 >Summary: 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to > build: dev/ahci/ahci.c:288:22: error: unknown > conversion type ch

Re: /dev/led soekris 6501.

On Thu, 3 Mar 2016 08:10:54 +0100 Peter Ankerstål wrote: > I see. To my understanding this works on older soekris hardware but I > havent tested it myself. In that case, I would report it in Bugzilla. (I wasn't aware of led(4) - thanks!) -- Torfinn Ingolfsen

Re: /dev/led soekris 6501.

On Wed, 2 Mar 2016 19:18:20 -0800 Tom Samplonius wrote: > > >> > >> How come there is no support for “ready" and “error" leds on the soekris > >> 6501 even though it seems fairly easy to control them? > >> > > > > a) perhaps no developer have that board? > > b) nobody

Re: /dev/led soekris 6501.

o so? c) There is no generally accepted meaning for what “ready” or “error” LEDs might mean in FreeBSD, so implementing a driver for these LEDs may be a solution in a search of a problem. I see. To my understanding this works on older soekris hardware but I havent tested it myself. Also the /dev/led/error is sp

Re: /dev/led soekris 6501.

>> >> How come there is no support for “ready" and “error" leds on the soekris >> 6501 even though it seems fairly easy to control them? >> > > a) perhaps no developer have that board? > b) nobody has written the necessary code to do so? > c) There is no generally accepted meaning for what

Re: /dev/led soekris 6501.

On Wed, 2 Mar 2016 18:21:15 +0100 Peter Ankerstål wrote: > Hi! > > How come there is no support for “ready" and “error" leds on the soekris 6501 > even though it seems fairly easy to control them? > > Please see >

/dev/led soekris 6501.

Hi! How come there is no support for “ready" and “error" leds on the soekris 6501 even though it seems fairly easy to control them? Please see http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06738.html and http://ross.vc/?p=183 smime.p7s Description: S/MIME cryptographic

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

On Sat, Feb 06, 2016 at 07:46:02PM -0500, mike tancsa wrote: > Sure, I will try Monday when at the office Actually, thinking about it, could you please try the following patch on top of the previous one/r295287? https://people.freebsd.org/~marius/e1000_max_scatter_tso_10.diff Thanks Marius

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

On Mon, Feb 08, 2016 at 02:24:42PM -0500, Mike Tancsa wrote: > On 2/8/2016 4:10 AM, Marius Strobl wrote: > > On Sat, Feb 06, 2016 at 07:46:02PM -0500, mike tancsa wrote: > >> Sure, I will try Monday when at the office > > > > Actually, thinking about it, could you please try the following > >

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

On 2/8/2016 4:10 AM, Marius Strobl wrote: > On Sat, Feb 06, 2016 at 07:46:02PM -0500, mike tancsa wrote: >> Sure, I will try Monday when at the office > > Actually, thinking about it, could you please try the following > patch on top of the previous one/r295287? >

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

On Tue, Feb 02, 2016 at 09:49:59AM -0500, Mike Tancsa wrote: > On 1/30/2016 12:26 PM, Marius Strobl wrote: > > On Sat, Jan 30, 2016 at 11:47:19AM -0500, Mike Tancsa wrote: > >> On 1/29/2016 8:23 PM, Marius Strobl wrote: > >>> On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike Tancsa wrote: > >

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

On 2/1/2016 5:27 PM, Marius Strobl wrote: > On Mon, Feb 01, 2016 at 05:11:29PM -0500, Mike Tancsa wrote: >> On 1/30/2016 12:26 PM, Marius Strobl wrote: >>> >>> Ah, okay, that at least makes sense. Can you please verify that with >>> the attached patch applied, you have a setup that works out of

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

On 1/30/2016 12:26 PM, Marius Strobl wrote: > On Sat, Jan 30, 2016 at 11:47:19AM -0500, Mike Tancsa wrote: >> On 1/29/2016 8:23 PM, Marius Strobl wrote: >>> On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike Tancsa wrote: No multi queue. Stock GENERIC kernel with a couple of things removed.

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

_tso_gig_only_10.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: sys/dev/e1000/if_em.c |======= |--- sys/dev/e1000/if_em.c (revision 294962) |+++ sys/dev/e1000/if_em.c (working copy)

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

> > > Hi, > The patch does not apply cleanly Hrm, it does here on stable/10. If your checkout is unaltered, the only thing I can think of is that the patch got corrupted when sent by e-mail. I've put it online: https://people.freebsd.org/~marius/em_tso_gig_only_10.diff marius@alchemy:/ho

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

oks like a unified diff to me... The text leading up to this was: ------ |Index: sys/dev/e1000/if_em.c |======= |--- sys/dev/e1000/if_em.c (revision 294962) |+++ sys/dev/e1000/if_em.c

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

utput was after I turned off tso as > Harry suggested to try. Its been 24hrs and I have not seen any resets. > I will wait another 36hrs or so and then turn it back on to see if the > problem comes back. > > this link is 100Mb. Ah, okay, that at least m

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

On 1/29/2016 8:23 PM, Marius Strobl wrote: > On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike Tancsa wrote: >> >> No multi queue. Stock GENERIC kernel with a couple of things removed. >> hw.em are just the defaults. I will try without TSO >> >> % ifconfig em0 >> em0:

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

Thanks, I will apply and try it early Monday morning ! On January 30, 2016 12:26:31 PM Marius Strobl wrote: On Sat, Jan 30, 2016 at 11:47:19AM -0500, Mike Tancsa wrote: On 1/29/2016 8:23 PM, Marius Strobl wrote: > On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike

Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap

On 1/27/2016 5:31 PM, Marius Strobl wrote: > Author: marius > Date: Wed Jan 27 22:31:08 2016 > New Revision: 294958 > URL: https://svnweb.freebsd.org/changeset/base/294958 > > Log: > Sync the e1000 drivers with what's in head as of r294327, modulo parts > that don't apply to stable/10 (driver

Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike Tancsa wrote: > > No multi queue. Stock GENERIC kernel with a couple of things removed. > hw.em are just the defaults. I will try without TSO > > % ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > >

Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap

Bezüglich Mike Tancsa's Nachricht vom 29.01.2016 19:08 (localtime): > On 1/27/2016 5:31 PM, Marius Strobl wrote: >> Author: marius >> Date: Wed Jan 27 22:31:08 2016 >> New Revision: 294958 >> URL: https://svnweb.freebsd.org/changeset/base/294958 >> >> Log: >> Sync the e1000 drivers with what's

possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)

On 1/29/2016 1:42 PM, Harry Schmalzbauer wrote: >> # pciconf -lBvcb em0 >> em0@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82573E Gigabit Ethernet Controller (Copper)' > > I guess you haven't

em(4) watchdog timeout redemption [Was: Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap]

Bezüglich Marius Strobl's Nachricht vom 27.01.2016 23:31 (localtime): > Author: marius > Date: Wed Jan 27 22:31:08 2016 > New Revision: 294958 > URL: https://svnweb.freebsd.org/changeset/base/294958 > > Log: > Sync the e1000 drivers with what's in head as of r294327, modulo parts > that don't

Re: dev/random warning on 10-STABLE after r292122 up till r292855

on 10.2-RELEASE amd64. > > random device not loaded; using insecure entropy > > The full dmesg can be seen here > http://dmesgd.nycbug.org/index.cgi?action=dmesgd=view=2871 > > I checked in svn and there are no recent changes to sys/dev/random . > > Does anyone have any insi

Re: dev/random warning on 10-STABLE after r292122 up till r292855

dmesgd=view=2871 >> >> I checked in svn and there are no recent changes to sys/dev/random . >> >> Does anyone have any insight into this ? >> > > It's more of an informational message about seeding the random number > generator. Probably man 4 random is the bes

Re: dev/random warning on 10-STABLE after r292122 up till r292855

On 2016-Jan-04 16:44:49 -0500, Mark Saad wrote: >On boot dmesg logs the following warning not seen on 10.2-RELEASE amd64. > >random device not loaded; using insecure entropy When I first noticed this, I investigated and worked out that it's related to how the random

Re: dev/random warning on 10-STABLE after r292122 up till r292855

andom device is unblocked. > > -- > Peter Jeremy > Peter I agree it looks like its not really a big deal; what I cant find is what changed to make this even print out. The commits for this warning are from a long time ago. Off hand they are from 2014 or 2012. There were no change

Re: dev/random warning on 10-STABLE after r292122 up till r292855

Mark, > At NYC*BUG we are looking into a warning seen on FreeBSD 10-STABLE amd64 > starting at or about r292122 and still up till r292855. > random device not loaded; using insecure entropy I noticed this message a while back and again yesterday on my i386 which runs no modules, just a custom

dev/random warning on 10-STABLE after r292122 up till r292855

://dmesgd.nycbug.org/index.cgi?action=dmesgd=view=2871 I checked in svn and there are no recent changes to sys/dev/random . Does anyone have any insight into this ? -- mark saad | nones...@longcount.org ___ freebsd-stable@freebsd.org mailing list https

Re: jail: /etc/rc: cannot create /dev/null: Operation not supported

/etc/rc + stty status ^T /etc/rc: cannot create /dev/null: Operation not supported + trap : 2 + trap 'echo '\''Boot interrupted'\''; exit 1' 3 + HOME=/ + PATH=/sbin:/bin:/usr/sbin:/usr/bin + export HOME PATH + [ '' = autoboot ] + autoboot=no + _boot=quietstart + /sbin/sysctl -n

Re: jail: /etc/rc: cannot create /dev/null: Operation not supported

/dev/null: Operation not supported + trap : 2 + trap 'echo '\''Boot interrupted'\''; exit 1' 3 + HOME=/ + PATH=/sbin:/bin:/usr/sbin:/usr/bin + export HOME PATH + [ '' = autoboot ] + autoboot=no + _boot=quietstart + /sbin/sysctl -n vfs.nfs.diskless_valid /etc/rc: cannot create /dev/null: Operation

Re: jail: /etc/rc: cannot create /dev/null: Operation not supported

On 2015-07-17 01:41, James Gritton wrote: On 2015-07-15 13:52, Per olof Ljungmark wrote: FreeBSD 10.2-PRERELEASE #0 r284949 The jail can be started, but when /etc/rc is executed: root@mar:/ # sh -x /etc/rc + stty status ^T /etc/rc: cannot create /dev/null: Operation not supported + trap

Re: jail: /etc/rc: cannot create /dev/null: Operation not supported

On 2015-07-15 13:52, Per olof Ljungmark wrote: FreeBSD 10.2-PRERELEASE #0 r284949 The jail can be started, but when /etc/rc is executed: root@mar:/ # sh -x /etc/rc + stty status ^T /etc/rc: cannot create /dev/null: Operation not supported + trap : 2 + trap 'echo '\''Boot interrupted'\''; exit

jail: /etc/rc: cannot create /dev/null: Operation not supported

FreeBSD 10.2-PRERELEASE #0 r284949 The jail can be started, but when /etc/rc is executed: root@mar:/ # sh -x /etc/rc + stty status ^T /etc/rc: cannot create /dev/null: Operation not supported + trap : 2 + trap 'echo '\''Boot interrupted'\''; exit 1' 3 + HOME=/ + PATH=/sbin:/bin:/usr/sbin:/usr

Re: Make buildkernel fails on /usr/src/sys/dev/ata/atapi-cam.c

My daily stable/9 build ( boot) was successful at r235604: FreeBSD g1-227.catwhisker.org 9.0-STABLE FreeBSD 9.0-STABLE #162 235604M: Fri May 18 04:39:02 PDT 2012 +r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 Peace, david -- David H. Wolfskill

Re: Make buildkernel fails on /usr/src/sys/dev/ata/atapi-cam.c

On Sat, May 19, 2012 at 1:50 AM, Thomas Mueller mueller...@insightbb.com wrote: My daily stable/9 build ( boot) was successful at r235604: FreeBSD g1-227.catwhisker.org 9.0-STABLE FreeBSD 9.0-STABLE #162 235604M: Fri May 18 04:39:02 PDT 2012

Re: Make buildkernel fails on /usr/src/sys/dev/ata/atapi-cam.c

My daily stable/9 build ( boot) was successful at r235604: FreeBSD g1-227.catwhisker.org 9.0-STABLE FreeBSD 9.0-STABLE #162 235604M: Fri May 18 04:39:02 PDT 2012 +r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 Peace, david -- David H. Wolfskill

Make buildkernel fails on /usr/src/sys/dev/ata/atapi-cam.c

-fstack-protector -Werror vers.c linking kernel.debug atapi-cam.o: In function `atapi_action': /usr/src/sys/dev/ata/atapi-cam.c:436: undefined reference to `ata_controlcmd' /usr/src/sys/dev/ata/atapi-cam.c:651: undefined reference to `ata_queue_request' *** Error code 1 Stop in /usr/obj/usr/src

Re: Make buildkernel fails on /usr/src/sys/dev/ata/atapi-cam.c

On Fri, May 18, 2012 at 02:02:02PM -0400, Thomas Mueller wrote: After a successful make buildworld with newly updated source tree, make buildkernel failed on atapi-cam.c : ... Is this a known problem? This is on RELENG_9 and just a couple hours ago. ... My daily stable/9 build ( boot)

Re: Make buildkernel fails on /usr/src/sys/dev/ata/atapi-cam.c

-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror  vers.c linking kernel.debug atapi-cam.o: In function `atapi_action': /usr/src/sys/dev/ata/atapi-cam.c:436: undefined reference to `ata_controlcmd' /usr/src/sys/dev/ata/atapi

[k...@freebsd.org: svn commit: r226067 - in stable/9: sbin/camcontrol share/examples/scsi_target share/misc sys/cam sys/cam/scsi sys/dev/ciss sys/dev/firewire sys/dev/iir sys/dev/iscsi/initiator sys/d

/camcontrol share/examples/scsi_target share/misc sys/cam sys/cam/scsi sys/dev/ciss sys/dev/firewire sys/dev/iir sys/dev/iscsi/initiator sys/dev/isp sys/dev/m... Author: ken Date: Thu Oct 6 19:15:51 2011 New Revision: 226067 URL: http://svn.freebsd.org/changeset/base/226067 Log: MFC r225950

8.2-STABLE: /dev/da* device is not created after attaching digital camera SONY DSC-S60

Hi, like in the topic, the /dev/da* device is not created: % dmesg ugen7.3: Sony at usbus7 umass0: Sony Sony DSC, class 0/0, rev 2.00/5.00, addr 3 on usbus7 umass0: RBC over CBI; quirks = 0x1000 umass0:4:0:-1: Attached to scbus4 % usbconfig ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST

gpt labels for zfs partitions don't appear in /dev/gpt

but zfs partitions don't have accesible gpt label in /dev/gpt: # glabel list Geom name: ada0p1 Providers: 1. Name: gptid/fe8c7129-bc68-11df-8955-0050dad823cd Mediasize: 65536 (64k) Sectorsize: 512 Stripesize: 0 Stripeoffset: 17408 Mode: r0w0e0

Re: gpt labels for zfs partitions don't appear in /dev/gpt

On 15.06.2011 15:43, Bartosz Stec wrote: As you see I have ada{0-2}p3 labeled as disk{0-2} All labeled partitions have valid gpt id but zfs partitions don't have accesible gpt label in /dev/gpt: It always worked so. Read geom(4) manual page, especially about SPOILING. As you see labels

Re: gpt labels for zfs partitions don't appear in /dev/gpt

W dniu 2011-06-15 14:12, Andrey V. Elsukov pisze: On 15.06.2011 15:43, Bartosz Stec wrote: As you see I have ada{0-2}p3 labeled as disk{0-2} All labeled partitions have valid gpt id but zfs partitions don't have accesible gpt label in /dev/gpt: It always worked so. Read geom(4) manual page

  1   2   3   4   5   >