Re: Delay in 14.0-RELEASE cycle and blocking items

[Alexey Dokuchaev]

On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote:
> ...
> There is no feasible way we are going to make the branch point of
> stable/14 in time, with that scheduled for May 12, 2023 with the above
> points.  That said, this is not an all-inclusive list, but the more
> major items on our radar at the moment.

Does this delay mean we might get Clang 16 in the base?  Current 15.0.7
hits assertion on one of my ports which had allegedly been fixed in 16.
Also, AFAIU it comes with better support for modern C++, e.g. ranges.

./danfe

Re: Disk partitions disappear when mounting others

[Alexey Dokuchaev]

On Sun, Dec 25, 2022 at 09:32:55AM -0700, Warner Losh wrote:
> On Sun, Dec 25, 2022, 1:02 AM Alexey Dokuchaev  wrote:
> > ...
> > The problem is that once I mount my old FreeBSD partition, e.g.
> > /dev/ada0s2a, those LVM nodes are gone, logging this:
> >
> >   GEOM_LINUX_LVM: disk pv0 already initialised in fedora
> >   GEOM_LINUX_LVM: Disk diskid/DISK-XXX1s4+0001 removed from pv0.
> >   GEOM_LINUX_LVM: Device linux_lvm/fedora-swap removed.
> >   GEOM_LINUX_LVM: Device linux_lvm/fedora-home removed.
> >   GEOM_LINUX_LVM: Device linux_lvm/fedora-root removed.
> >
> > If I unmount /dev/ada0s2a and mount any Fedora's partition, then I can
> > longer access other slices as there's only /dev/ada0 remains; ``gpart
> > show'' also does not list them, but only those under diskid/DISK-XXX1.
> >
> > Why is this happening?  What should I fix to stop my partitions from
> > disappearing and reappearing?
> 
> Something has them open. My guess is the Linux lvm geom provider opens too
> many things. It's been standard geom behavior to remove the other device
> aliases in /dev when one is open.

Well, yeah, but it's weird to see that on a detached harddrive.  It's not
like it's still opened under another operating system, I'm simply mounting
existing partitions one by one to move my data to a new SSD.

> Though the problem may be in tasting during open since gpart list shows
> them gone.

I've found out that putting either geom_linux_lvm_load="YES" or kern.geom.
label.disk_ident.enable=0 in /boot/loader.conf remedies the problem.  Just
in case someone encounters the same issue.  When I was still booting off
this disk, I had geom_linux_lvm_load="YES" so that's probably why it did
not bite me before.

./danfe

Disk partitions disappear when mounting others

[Alexey Dokuchaev]

Hi there,

I'm in the process of moving my data from a dying HDD, and just noticed
something weird.  It's an MBR partitioned drive, and there is a FreeBSD
slice and Fedora LVM in EBR, accessible as 
/dev/linux_lvm/fedora-{swap,home,root}.

The problem is that once I mount my old FreeBSD partition, e.g.
/dev/ada0s2a, those LVM nodes are gone, logging this:

  GEOM_LINUX_LVM: disk pv0 already initialised in fedora
  GEOM_LINUX_LVM: Disk diskid/DISK-XXX1s4+0001 removed from pv0.
  GEOM_LINUX_LVM: Device linux_lvm/fedora-swap removed.
  GEOM_LINUX_LVM: Device linux_lvm/fedora-home removed.
  GEOM_LINUX_LVM: Device linux_lvm/fedora-root removed.

If I unmount /dev/ada0s2a and mount any Fedora's partition, then I can
longer access other slices as there's only /dev/ada0 remains; ``gpart show''
also does not list them, but only those under diskid/DISK-XXX1.

Why is this happening?  What should I fix to stop my partitions from
disappearing and reappearing?  Thanks,

./danfe

Re: Considering stepping down from all of my FreeBSD responsibilities

[Alexey Dokuchaev]

On Fri, Apr 01, 2022 at 02:20:31PM +0900, Yasuhiro Kimura wrote:
> Hi Glen,
> 
> From: Glen Barber 
> Subject: Considering stepping down from all of my FreeBSD responsibilities
> Date: Fri, 1 Apr 2022 00:15:02 +
> 
> > Dear community,
> > 
> > Given the mental toll the past two years or so have taken on me, I have
> > decided to step down from all of my "hats" within the Project, and take
> > some time to sort out what my future looks like going forward.
> > 
> > Happy April 1st.  I'm not going anywhere.  :-)
> 
> We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-)
> 
> Cf. 
> https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001055.html

I don't think 2.2.10 is warranted.  2.2.9 (or was it 2.2.8?) had improved
Quake II support in Linuxolator, but since then we've got several native
ports available in our collection which play just fine (modulo the problems
caused by that shitty linuxish graphics stack we're confined to these days).

./danfe

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

[Alexey Dokuchaev]

On Tue, Dec 14, 2021 at 09:27:01AM -0800, John Baldwin wrote:
> On 12/14/21 2:14 AM, Alexey Dokuchaev wrote:
> > How do you mean?  Most FreeBSD people, not some random Twitter crowd,
> > want the bell to be on by default, but it's still off.
> 
> I don't know that that's true, and I myself am not sure that I want it
> back on by default.  Previously my laptop had a rather annoying beep
> whose volume I couldn't control that I actually prefer to have off
> normally.

Is it still annoying after Warner had fixed the frequency?  In that
unfortunate case, you should probably disable it just for yourself.
Disabling it for everyone by default mutes an important communication
channel which is useful for low-level debugging and troubleshooting.
It is often the only way to understand if machine is working or not.

./danfe

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

[Alexey Dokuchaev]

On Tue, Dec 14, 2021 at 11:27:07AM +0100, Emmanuel Vadot wrote:
> On Tue, 14 Dec 2021 10:14:24 +0000 Alexey Dokuchaev wrote:
> > ...
> > I know that I had problemless desktop some 10-5 years ago, okayish
> > desktop ~three years ago, tolerable experience with 4.16.x DRM bits
> > and shitty one with current 5.4.x (FWIW, 5.x had been problematic
> > for me since the beginning, but previously it was fairly easy to
> > build drm-fbsd12.0-kmod on -CURRENT to avoid regressions, now the
> > source bases had divered too far enough; it's probably still possible
> > to patch, but would take longer time).
> 
> Any PR open for your issues?

At first I was going to say something about such PRs would be closed
as overcome by events anyways, but I like the change of your tone, so
I won't. :)

I've just ordered a Full HD IPS screen for my laptop so I could play
modern (well, relatively modern) games, thus I expect I'd be sticking
my hands into X11 stack deeper.  I'll collect my notes and stories in
a submittable shape and file them.

> Well this telegram chat is still a community one, I don't see how it
> makes a difference.

Well, it'a a group of actual FreeBSD users vs. Twitter where random
people who probably don't even use FreeBSD could see the poll and would
gladly click on preloaded correct answer.

> Also I can't see the poll result.

Hmm, indeed, it does not display results even when viewed via browser,
that is, unlogged.  OTOH you should really try Telegram, there's nothing
better right now on the market.

./danfe

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

[Alexey Dokuchaev]

On Tue, Dec 14, 2021 at 09:14:27AM +0100, Emmanuel Vadot wrote:
> On Tue, 14 Dec 2021 07:11:28 +0000 Alexey Dokuchaev wrote:
> > ...
> > Oh, you know, it's about steadily deteriorating quality of our gfx
> > stack once we had started pulling things from Linux.
> 
> Right.
> That just proves that you know nothing and will just complain on
> everything "new".

I know that I had problemless desktop some 10-5 years ago, okayish
desktop ~three years ago, tolerable experience with 4.16.x DRM bits
and shitty one with current 5.4.x (FWIW, 5.x had been problematic
for me since the beginning, but previously it was fairly easy to
build drm-fbsd12.0-kmod on -CURRENT to avoid regressions, now the
source bases had divered too far enough; it's probably still possible
to patch, but would take longer time).

> We've *always* pulled drm bits from Linux, always.

You know what I've meant.

> > In FreeBSD chat and with less biased poll than the one Warner had posted
> > on Twitter, most people had actually voted against making it off by
> > default: https://t.me/FreeBSD1/25129.
> 
> So nothing changes then?

How do you mean?  Most FreeBSD people, not some random Twitter crowd, want
the bell to be on by default, but it's still off.

./danfe

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

[Alexey Dokuchaev]

On Mon, Dec 13, 2021 at 06:32:22PM +0100, Emmanuel Vadot wrote:
> On Mon, 13 Dec 2021 17:01:43 +0000 Alexey Dokuchaev wrote:
> > On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote:
> > > ...
> > > However, it was a bit harder to see this originally as the 915kms driver
> > > tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which
> > > recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a
> > > bad idea).
> > 
> > Funny how these new Linuxish DRM bits could affect so many things. :(
> 
> What is this comment about exactly?

Oh, you know, it's about steadily deteriorating quality of our gfx stack
once we had started pulling things from Linux.

> > > The fact that that sysbeep is off so I couldn't tell if typing in commands
> > > was doing anything vs emitting errors probably didn't improve trying to
> > > diagnose the hang as "sitting in ddb" initially, though I don't know if
> > > DDB itself emits a beep for invalid commands, etc.
> > 
> > Now that Warner had fixed the beeper frequency, why we still didn't enable
> > it back on by default?
> 
> Because all people who wanted it off wasn't because it wasn't the
> right vt100 frequency, they just wanted it off.

In FreeBSD chat and with less biased poll than the one Warner had posted
on Twitter, most people had actually voted against making it off by
default: https://t.me/FreeBSD1/25129.  If John's assumption that muting
it pessimizes debugging is correct, it really leaves no strong reasons
NOT to turn it back on by default.

./danfe

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

[Alexey Dokuchaev]

On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote:
> ...
> However, it was a bit harder to see this originally as the 915kms driver
> tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which
> recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a
> bad idea).

Funny how these new Linuxish DRM bits could affect so many things. :(

> The fact that that sysbeep is off so I couldn't tell if typing in commands
> was doing anything vs emitting errors probably didn't improve trying to
> diagnose the hang as "sitting in ddb" initially, though I don't know if
> DDB itself emits a beep for invalid commands, etc.

Now that Warner had fixed the beeper frequency, why we still didn't enable
it back on by default?

./danfe

Re: loading drm crashes system

[Alexey Dokuchaev]

On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote:
> Niclas Zeising asks:
> > When did it stop working?
> 
> September ... I _think_.

Yeah, that sounds about right.

There are known issues with Radeon cards, they were quite well supported
a year ago, then something got broken.  I've promised to bisect this and
find the cause, but there were several syscall-related changes in -CURRENT
though the course of the last year, so bisecting just the kernel is not
enough (machine won't get to login prompt if the userland does not match),
which cripples the process.

I still intend to take this quest, just not sure when. :(

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: .debug files, skip?

[Alexey Dokuchaev]

On Sun, Apr 05, 2020 at 07:41:38PM -0400, Ed Maste wrote:
> On Sun, 5 Apr 2020 at 08:32, Jeffrey Bouquet wrote:
> >
> > A recent build[k,w] [ ** stable  12.1] and many .debug files I'd
> > like to skip if poss. A knob?
> 
> Yes, from src.conf(5):
>  WITHOUT_DEBUG_FILES
>  Set to avoid building or installing standalone debug
>  files for each executable binary and shared library.

I have "MK_DEBUG_FILES=no" in /etc/make.conf, which one is more correct?

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: make delete-old: missing some files?

[Alexey Dokuchaev]

On Sun, Oct 27, 2019 at 07:40:36PM +0700, Alexey Dokuchaev wrote:
> On Thu, Oct 24, 2019 at 11:07:16AM -0700, John Baldwin wrote:
> > On 10/22/19 8:42 PM, Alexey Dokuchaev wrote:
> > > On Tue, Oct 22, 2019 at 04:34:53PM -0700, John Baldwin wrote:
> > >> ...
> > >> These are from the OpenSSL 1.1.1 commit.  However, they are tagged as
> > >> OLD_LIBS and check-old-libs and delete-old-libs should be automatically
> > >> deleting these?  Does 'make check-old' report these files as
> > >> old libraries?
> > > 
> > > I've manually placed one of those back on the filesystem and `make
> > > check-old' reported it (twice!) under libraries.  But after r353907 it
> > > get cleaned up properly with `make delete-old'.
> > 
> > Hmm, then 'make delete-old-libs' should already delete them without needing
> > r353907.  The issue with r353907 is if someone doesn't delete the
> > actual libraries via 'make delete-old-libs' but then tries to debug an
> > application that was using the old openssl and crashed, we'd no longer
> > have debug symbols if the crash was in one of those libraries.  That
> > matters less for OpenSSL engines, but matters more for something like
> > libutil, etc. hence why we delete debug symbols as part of delete-old-libs
> > instead of delete-old.
> > 
> > If 'make delete-old-libs' deletes these files already, then we should
> > probably revert r353907.
> 
> I've reverted r353907, and `make delete-old-libs' deleted those files.

So what was the final decision, did you guys sort it out?  I've seen that
r353907 was MFC'ed while it was still being discussed, hence my question:
https://svnweb.freebsd.org/base?view=revision=354150.

> Also, I've noticed that `lib/libdtrace.so.2' is listed twice in the
> tools/build/mk/OptionalObsoleteFiles.inc, which is probably another bug.

What about DTrace-related issues (this and the previous one)?

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: make delete-old: missing some files?

[Alexey Dokuchaev]

On Thu, Oct 24, 2019 at 11:07:16AM -0700, John Baldwin wrote:
> On 10/22/19 8:42 PM, Alexey Dokuchaev wrote:
> > On Tue, Oct 22, 2019 at 04:34:53PM -0700, John Baldwin wrote:
> >> ...
> >> These are from the OpenSSL 1.1.1 commit.  However, they are tagged as
> >> OLD_LIBS and check-old-libs and delete-old-libs should be automatically
> >> deleting these?  Does 'make check-old' report these files as
> >> old libraries?
> > 
> > I've manually placed one of those back on the filesystem and `make
> > check-old' reported it (twice!) under libraries.  But after r353907 it
> > get cleaned up properly with `make delete-old'.
> 
> Hmm, then 'make delete-old-libs' should already delete them without needing
> r353907.  The issue with r353907 is if someone doesn't delete the
> actual libraries via 'make delete-old-libs' but then tries to debug an
> application that was using the old openssl and crashed, we'd no longer
> have debug symbols if the crash was in one of those libraries.  That
> matters less for OpenSSL engines, but matters more for something like
> libutil, etc. hence why we delete debug symbols as part of delete-old-libs
> instead of delete-old.
> 
> If 'make delete-old-libs' deletes these files already, then we should
> probably revert r353907.

I've reverted r353907, and `make delete-old-libs' deleted those files.
Also, I've noticed that `lib/libdtrace.so.2' is listed twice in the
tools/build/mk/OptionalObsoleteFiles.inc, which is probably another bug.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: make delete-old: missing some files?

[Alexey Dokuchaev]

On Tue, Oct 22, 2019 at 04:34:53PM -0700, John Baldwin wrote:
> On 10/18/19 10:05 AM, Alexey Dokuchaev wrote:
> > hi there,
> > 
> > i've made my -CURRENT world and installed, but "make delete-old" tells
> > me it cannot remove some directories:
> > 
> >>>> Removing old directories
> > rmdir: /usr/share/dtrace: Directory not empty
> > rmdir: /usr/lib/dtrace: Directory not empty

Apparently, these are because I've started to put WITHOUT_CDDL=yes in
/etc/src.conf since recently:

$ find /usr/lib/dtrace -type f
/usr/lib/dtrace/siftr.d
/usr/lib/dtrace/mbuf.d
/usr/lib/dtrace/socket.d

$ find /usr/share/dtrace -type f
/usr/share/dtrace/nfsattrstats
/usr/share/dtrace/siftr
/usr/share/dtrace/blocking
/usr/share/dtrace/tcpdebug

I can see some dtrace/*.d files in OptionalObsoleteFiles.inc, perhaps
these are missing?

> > # find /usr/lib/debug/usr/lib/engines
> > /usr/lib/debug/usr/lib/engines
> > /usr/lib/debug/usr/lib/engines/lib4758cca.so.debug
> > ...
> 
> These are from the OpenSSL 1.1.1 commit.  However, they are tagged as
> OLD_LIBS and check-old-libs and delete-old-libs should be automatically
> deleting these?  Does 'make check-old' report these files as
> old libraries?

I've manually placed one of those back on the filesystem and `make
check-old' reported it (twice!) under libraries.  But after r353907 it
get cleaned up properly with `make delete-old'.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

make delete-old: missing some files?

[Alexey Dokuchaev]

hi there,

i've made my -CURRENT world and installed, but "make delete-old" tells
me it cannot remove some directories:

>>> Removing old directories
rmdir: /usr/share/dtrace: Directory not empty
rmdir: /usr/lib/dtrace: Directory not empty
rmdir: /usr/lib/debug/usr/tests/libexec/rtld-elf: Directory not empty
rmdir: /usr/lib/debug/usr/tests/libexec: Directory not empty
rmdir: /usr/lib/debug/usr/tests: Directory not empty
rmdir: /usr/lib/debug/usr/lib/i18n: Directory not empty
rmdir: /usr/lib/debug/usr/lib/engines: Directory not empty
rmdir: /usr/lib/debug/usr/lib: Directory not empty
rmdir: /usr/lib/debug/usr: Directory not empty

taking /usr/lib/debug/usr/lib/engines as an example:

# find /usr/lib/debug/usr/lib/engines
/usr/lib/debug/usr/lib/engines
/usr/lib/debug/usr/lib/engines/lib4758cca.so.debug
/usr/lib/debug/usr/lib/engines/libaep.so.debug
/usr/lib/debug/usr/lib/engines/libatalla.so.debug
/usr/lib/debug/usr/lib/engines/libcapi.so.debug
/usr/lib/debug/usr/lib/engines/libchil.so.debug
/usr/lib/debug/usr/lib/engines/libcswift.so.debug
/usr/lib/debug/usr/lib/engines/libgost.so.debug
/usr/lib/debug/usr/lib/engines/libnuron.so.debug
/usr/lib/debug/usr/lib/engines/libsureware.so.debug
/usr/lib/debug/usr/lib/engines/libubsec.so.debug

am i missing something, or ObsoleteFiles.inc lacks a few entries?

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AESNI, /dev/crypto, and new OpenSSL

[Alexey Dokuchaev]

On Fri, Dec 21, 2018 at 01:10:07AM +0700, Alexey Dokuchaev wrote:
> On Thu, Dec 20, 2018 at 09:33:41AM -0800, Freddie Cash wrote:
> > On Thu, Dec 20, 2018 at 9:21 AM Alexey Dokuchaev  wrote:
> > > Had something got broken here, or I'm misunderstanding how this machinery
> > > now works?
> > 
> > Start reading here:
> > 
> > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090195.html
> > 
> > That thread covers this issue.  :)  Along with the "fix" for it.
> 
> Thanks for the pointer.  I've checked both -current and -hackers MLs prior
> to posting, but didn't expect this would show up on -stable first. :)

In case people find this thread and want quick answers without having to
deviate to -stable, here's a quick summary and my speed test results, with
some quotes from delphij@, jhb@, et al.:

1) aesni(4) and crypto[dev](4) modules are not required now for OpenSSL,
   and userland acceleration in general, to work;

2) On capable systems, AES-NI would be used automatically.  In fact, it's
   much faster to use the AES-NI instructions in userland than to use a
   system call that copies the data into a kernel buffer, uses the same
   AES-NI instructions, then copies the data back out again along with
   the overhead of a pair of user <--> kernel transitions.

  (Note from me: if you've observed very strange results when using -evp
   with aesni(4) + BSD cryptodev engine on OpenSSL 1.0.2, it was probably
   because of that user <--> kernel multicopying.)

Some quick naive benchmarks on AMD A8-5550M APU (results were trimmed for
brevity):

baseline: openssl speed -elapsed aes-128-cbc:

16 bytes64 bytes256 bytes   1024 bytes  8192 bytes  16384 bytes
35922.35k   39346.28k   40492.29k   94625.81k   95194.36k95619.24k

hardware extensions: openssl speed -elapsed -evp aes-128-cbc

16 bytes64 bytes256 bytes   1024 bytes  8192 bytes  16384 bytes
133823.08k  186960.39k  226363.05k  238189.15k  241782.56k   241646.38k

AES-NI disabled: env OPENSSL_ia32cap="~0x200" openssl speed
 -elapsed -evp aes-128-cbc:

16 bytes64 bytes256 bytes   1024 bytes  8192 bytes  16384 bytes
54820.92k   64884.98k   69229.02k   70424.31k   70731.22k70714.02k

It's interesting how -evp run w/o AES-NI got capped at ~67 GB/s, while
the baseline had sustained at ~91 GB/s.  AES-NI run had reached pretty
solid ~230 GB/s.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AESNI, /dev/crypto, and new OpenSSL

[Alexey Dokuchaev]

On Thu, Dec 20, 2018 at 09:33:41AM -0800, Freddie Cash wrote:
> On Thu, Dec 20, 2018 at 9:21 AM Alexey Dokuchaev  wrote:
> > Had something got broken here, or I'm misunderstanding how this machinery
> > now works?
> 
> Start reading here:
> 
> https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090195.html
> 
> That thread covers this issue.  :)  Along with the "fix" for it.

Thanks for the pointer.  I've checked both -current and -hackers MLs prior
to posting, but didn't expect this would show up on -stable first. :)

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

AESNI, /dev/crypto, and new OpenSSL

[Alexey Dokuchaev]

Hi there,

For many years, OpenSSL was quite vocal about which hw-accelerated algos
it can use:

$ uname -UK
1200058 1200058
$ openssl version
OpenSSL 1.0.2n-freebsd  7 Dec 2017

$ openssl engine -c -t
(cryptodev) BSD cryptodev engine
 [RSA, DSA, DH] <<< word count = 3
 [ available ]
(dynamic) Dynamic engine loading support
 [ unavailable ]

# kldload aesni <<< loading AESNI(4)

$ openssl engine -c -t
(cryptodev) BSD cryptodev engine
 [RSA, DSA, DH, AES-128-CBC, AES-192-CBC, AES-256-CBC]  <<< word count = 6
 [ available ]
(dynamic) Dynamic engine loading support
 [ unavailable ]

Since recently[*], OpenSSL had switched to some new engine.  Now, the
output is less verbose and seemingly unaffected by the presence of the
aesni.ko module (or lack thereof):

$ uname -UK
135 135
$ openssl version
OpenSSL 1.1.1a-freebsd  20 Nov 2018

$ openssl engine -c -t
(devcrypto) /dev/crypto engine
 [ available ]  <<< which ones???
(dynamic) Dynamic engine loading support
 [ unavailable ]

This does not look right.  Also, now the popular "openssl speed -elapsed"
benchmark apparently does not use kernel AESNI support even when it is
loaded, because `system' CPU load is nearly zero (previously, in presence
of aesni.ko, user load would drop to zero while system load would show
that it's the kernel who's doing the job).

Had something got broken here, or I'm misunderstanding how this machinery
now works?

./danfe

[*] http://freshbsd.org/commit/freebsd/src/342009
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The future of ZFS in FreeBSD

[Alexey Dokuchaev]

On Thu, Dec 20, 2018 at 03:49:38PM +0500, Eugene M. Zheganin wrote:
> On 19.12.2018 23:32, Allan Jude wrote:
> > The biggest thing to remember is that this is still OpenZFS, and still
> > run by the same developers as it has been. We are just commonizing on
> > the repo that has the most features integrated into it.
> 
> Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because
> there is no such thing in ZoL?

+1.  I'm also worried if this would bring more Linuxish bits into our
kernel (cf. LinuxKPI).  Also, I thought that ZFS was never really native
to Linux but implemented through SPL (Solaris Porting Layer), and Linux'
VFS is not ARC-aware unlike Solaris and FreeBSD.

It would be quite upsetting to see ZFS as we know it in FreeBSD become
pessimized because of those things. :-(

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Fwd: nvidia-driver build error (last ports, FreeBSD-HEAD)

[Alexey Dokuchaev]

On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote:
> 
>  Перенаправленное сообщение 
> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD)
> Дата: Tue, 21 Aug 2018 16:41:42 +0700
> От: Alex V. Petrov 
> Кому: FreeBSD Ports 

Should be fixed as of r477761.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: swapping is completely broken in -CURRENT r334649?

[Alexey Dokuchaev]

On Wed, Jun 27, 2018 at 07:55:26AM -0400, Mark Johnston wrote:
> On Wed, Jun 27, 2018 at 10:46:38AM +0000, Alexey Dokuchaev wrote:
> > On Fri, Jun 15, 2018 at 04:40:22AM -0400, Mark Johnston wrote:
> > > ...
> > > The change was committed as r334752.  Are you seeing unexpected OOM
> > > kills on or after that revision?
> > 
> > I've just discovered this thread.  I've updated my -CURRENT desktop ca.
> > June 4th and my X.org session crashes within several minutes.  This is
> > on i386 system with 4G RAM.
> > 
> > I cannot get SVN revision of that kernel because something got broken
> > and it was not embedded in the image. :-(
> > 
> > Rebooting with kernel="kernel.old" from May 12th made this problem go
> > away.  Is the root cause is known at this time?  Which revision shall
> > I try to see whether it does not exhibit this bug any longer?  Thanks,
> 
> As noted earlier in the thread, r329882 introduced a problem where
> out-of-memory kills were taking place despite an abundance of free pages
> and swap space.  That bug was fixed in r334752.  If you are seeing a
> problem that is fixed in a kernel from May 12th, then it is possibly
> unrelated to this bug, but it is worth testing r334752 or later to
> confirm.

Thanks, I can confirm that r334752 fixed the out-of-memory kills for me
now that I've been running it for two weeks without a single problem.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: swapping is completely broken in -CURRENT r334649?

[Alexey Dokuchaev]

On Fri, Jun 15, 2018 at 04:40:22AM -0400, Mark Johnston wrote:
> ...
> The change was committed as r334752.  Are you seeing unexpected OOM
> kills on or after that revision?

I've just discovered this thread.  I've updated my -CURRENT desktop ca.
June 4th and my X.org session crashes within several minutes.  This is
on i386 system with 4G RAM.

I cannot get SVN revision of that kernel because something got broken
and it was not embedded in the image. :-(

Rebooting with kernel="kernel.old" from May 12th made this problem go
away.  Is the root cause is known at this time?  Which revision shall
I try to see whether it does not exhibit this bug any longer?  Thanks,

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Error build nvidia-driver with r334555

[Alexey Dokuchaev]

On Sun, Jun 03, 2018 at 09:42:22PM +0900, Tomoaki AOKI wrote:
> This is caused by r334533 and/or r334534 (memset-related changes).
> sysutils/lsof is also affected.
> 
> You should revert r334533 and r334534 temporarily until nvidia-driver
> support this change.

nVidia driver port was fixed as of r471574.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: couple of nvidia-driver issues

[Alexey Dokuchaev]

On Thu, Dec 07, 2017 at 11:33:51AM +0200, Andriy Gapon wrote:
> ...
> 
> I've done some work with a debugger and it seems that there is code that does
> something like this:
> 
> char *last = NULL;
> 
> while (1) {
>   ...
> 
> The binary patch is here: https://people.freebsd.org/~avg/nvidia-smi.bsdiff

Appreciate taking very close look Andriy.

> It's been a while since I posted the patch and there are no comments yet.
> I can only add that I am running an INVARIANTS and WITNESS enabled kernel all
> the time and before the patch I was getting kernel panics every now and then.
> Since I started using the patch I haven't had a single nvidia panic yet.

I'll collect all the feedback from you over past few weeks and try to update
the driver within couple of days.  Thanks!

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Alexey Dokuchaev]

Sorry Matthew, forgot to reply to this one.

On Wed, Apr 05, 2017 at 07:01:35PM +0200, Matthew Rezny wrote:
> On Wednesday 05 April 2017 16:15:41 Alexey Dokuchaev wrote:
> > ...
> > Hmm, I don't quite get it: shouldn't static linking actually increase
> > the binaries (and thus the package) size?
> 
> I might have reversed static and shared somewhere in the linking
> explanation, or not properly described the situation. [...]

Understood, makes sense now.

> There was a brief period in which llvm39 was fully switched to dynamic
> linking, which made it considerably smaller but caused runtime problems
> (and was also likely to be slower).

That still sounds like the most sane way to go; provided those problems
are/would be fixed, I hope for that switch to happen again one day.  (I
somewhat doubt that "slower" was noticeable enough to worry about.)

> The best solution to cut rebuild time for LLVM is ccache.

Indeed, ccache helps greatly.  Now that I've managed to cut down package
times as well, situation with LLVM ports no longer looks as bad as I
originally saw it; thank you.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Alexey Dokuchaev]

On Wed, Apr 05, 2017 at 08:46:22PM +0200, Mathieu Arnold wrote:
> Le 05/04/2017 ?? 19:20, Alexey Dokuchaev a ??crit :
> > On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote:
> >> Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit :
> >>> ...
> >>> That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me.
> >> 
> >> So, you are comparing the size of the llvm39 package with the size of
> >> the llvm40 after extraction ?
> > 
> > Ha, didn't realize it, I'm so dumb.  What [is] the size of llvm40-*.txz
> > then?  I don't have it cached locally yet...
> 
> On my builds:
> 
> -rw-r--r--  6 nobody  wheel  256105968  4 avr.  17:54 llvm39-3.9.1_4.txz
> -rw-r--r--  6 nobody  wheel  304951340  4 avr.  18:02 llvm40-4.0.0_2.txz

Thanks, now it all makes sense, sorry for confusion.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Alexey Dokuchaev]

On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote:
> Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit :
> > ...
> > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me.
> 
> So, you are comparing the size of the llvm39 package with the size of
> the llvm40 after extraction ?

Ha, didn't realize it, I'm so dumb.  What the size of llvm40-*.txz then?
I don't have it cached locally yet...

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Alexey Dokuchaev]

On Thu, Mar 30, 2017 at 07:26:43PM +0200, Matthew Rezny wrote:
> LLVM 3.8 introduced the option to build a shared LLVM library, which is
> what Mesa needs for use at runtime (for e.g. compiling shaders), separate
> from linking to it. Previous versions only had one option, if the library
> was built then all the LLVM binaries were staticly linked to it. [...]
> 
> llvm{35,36,37} are statically linked and thus smaller than normal. llvm38
> switched to dynamic linking, the default, thus the size grew.

Hmm, I don't quite get it: shouldn't static linking actually increase the
binaries (and thus the package) size?

> I assume llvm40 will be a bit bigger, but do not expect to see another
> jump as you've observed.

As Mark Millard reports:

> I've also tried without WITH_DEBUG= and now. . .
> 
> # pkg delete llvm40
> Checking integrity... done (0 conflicting)
> Deinstallation has been requested for the following 1 packages (of 0
> packages in the universe):
> 
> Installed packages to be REMOVED:
> llvm40-4.0.0
> 
> Number of packages to be removed: 1
> 
> The operation will free 1 GiB.

That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me.
I'm surely looking forward modularization of LLVM port; rebuilding it
every time becomes a real PITA given that X11 stack requires it. :-(

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Alexey Dokuchaev]

On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote:
> On 26 Mar 2017, at 23:36, Mark Millard  wrote:
> > ...
> > Also interesting was:
> > 
> > Installed packages to be REMOVED:
> > llvm40-4.0.0.r4
> > 
> > Number of packages to be removed: 1
> > 
> > The operation will free 49 GiB.
> 
> Yes, this is big.  But there is no real need to build the llvm ports
> with debug information, unless you want to hack on llvm itself.

Cc'ing jmd@ and rezny@.

I've been watching increasing size of our LLVM packages with increasing
worry.  This is from my tinderbox cache:

  $ % env LANG=C ls -lh llvm3*
  -rw-r--r--  1 root  wheel17M Jan 29  2016 llvm35-3.5.2_1.txz
  -rw-r--r--  1 root  wheel18M Mar  7  2016 llvm36-3.6.2_2.txz
  -rw-r--r--  1 root  wheel27M Feb 28 01:05 llvm37-3.7.1_4.txz
  -rw-r--r--  1 root  wheel   207M Jan 19 18:20 llvm38-3.8.1_5.txz
  -rw-r--r--  1 root  wheel   244M Mar 23 16:42 llvm39-3.9.1_2.txz

Dimitry, do you know what had causes such a huge bump in 37 -> 38?

They take lots of time to build and package.  And given that llvm
is indirect dependency of any X11-related port, it pessimises their
build times as well (devel/libclc now requires devel/llvm40 after
r437268).

With 49 GiB llvm40, I guess I won't be able to build-test post as my
hardware would just not be capable enough.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Thinkpad T410: resume broken

[Alexey Dokuchaev]

On Thu, Feb 18, 2016 at 09:51:08AM -0800, John Baldwin wrote:
> On Thursday, February 18, 2016 10:56:29 PM Alexey Dokuchaev wrote:
> > # pciconf -lc pci0:0:0
> > hostb0@pci0:0:0:0:  class=0x06 card=0x83191033 chip=0x25908086 
> > rev=0x04 hdr=0x00
> > cap 09[e0] = vendor (length 9) Intel cap 2 version 1
> 
> Humm, perhaps PCI0 is not at 0:0.  Can you find the _ADR method for
> _SB_.PCI0?  That contains the "slot" and "function" as two words, e.g.
> 0x10002 would correspond to the 'pci0:1:2' device (or possibly pci0:2:1,
> don't recall the order off the top of my head).

Seems it's all zeros:

Device (PCI0)
{
...
Name (_ADR, 0x00)  // _ADR: Address

I've uploaded the dump on freefall [1], perhaps I've missed something so
you can have a better/sharper look.

./danfe

[1] http://people.freebsd.org/~danfe/nec_versa_s950.asl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Thinkpad T410: resume broken

[Alexey Dokuchaev]

On Thu, Feb 18, 2016 at 10:02:17AM -0800, Adrian Chadd wrote:
> [snip]
> 
> Someone should sit me down with pizza and "help" me just modularise
> the vesa/fb code so we can use it in vt.
> 
> It isn't /that/ hard, I've just been preoccupied.

And before it happens, someone(tm) could write a few paragraphs of current
state of affairs and codependencies between sc(4), vt(4), and VESA. :-)

Hopefully this would lower the degree of "black magic" surrounding this
code and help with some [1] related PRs.

./danfe

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174504
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Thinkpad T410: resume broken

[Alexey Dokuchaev]

On Thu, Feb 18, 2016 at 09:48:40AM -0800, John Baldwin wrote:
> On Thursday, February 18, 2016 09:47:12 PM Alexey Dokuchaev wrote:
> > On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote:
> > > On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote:
> > > vesa.ko shouldn't be working with KMS.  KMS turns off the legacy VGA
> > > emulation in the hardware when it starts which prevents VESA from
> > > working (VESA requires the legacy VGA interface).
> > 
> > Hmm, could this explain why vesa.ko can be loaded from loader.conf, but
> > not via kldload(8)?  OTOH, kldload'ing it later does not seem to work
> > (ir)regardless of whether i915kms.ko is loaded or not...
> 
> You might load it from loader.conf but it might then fail with an error
> about failing to register in dmesg.  In that case it is effectively
> ignored.

By "can be loaded from loader.conf" I mean that it's reported in kldstat(8)
output.  I'm still unsure if I understand all implications of having or not
having VESA kernel option or vesa.ko loaded in vt(4)+KMS world.  E.g., do I
understand correctly that vesa.ko is not needed (or might even cause certain
problems) with vt(4)+KMS, and "options VESA" is left in GENERIC as part of
syscons(4) support, and will likely go south together with syscons(4) some
day?

> > I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence
> > I'll ask: do [Intel or Radeon graphics] laptops suspend/resume without
> > issues in X11 or on the naked console as well?  (In a shop, I could only
> > quickly test our X11-less memstick image.)
> 
> Once KMS is loaded they resume fine.  They require the KMS driver to turn
> the LCD panel back on.  Without KMS they also "resume" but the screen is off
> so you can't see anything.  However, you can type blind and run commands.
> If the network is up you can ssh into the laptop, etc. after resume.
> [...]
> On HEAD you need to set kern.vty=sc to use sc(4) instead of vt(4).  For
> suspend/resume without X that should be sufficient.  You would only need
> the old drm drivers for X.
> [...]
> Note that for the HP netbook, resume in console with vt(4) does not work
> without KMS (due to vt(4) not supporting VESA).

OK I see, makes sense.  So my best bet would be to try suspend/resume with
vt(4)+KMS, then if it fails try with kern.vty=sc (in the context of GENERIC
kernel and pure console).

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Thinkpad T410: resume broken

[Alexey Dokuchaev]

On Thu, Feb 18, 2016 at 06:55:03AM -0800, John Baldwin wrote:
> On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote:
> > I've started to observe similar lines in the logs after updating to
> > fresh -CURRENT, upon resume (on a different laptop though, not T410):
> > 
> >   pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER
> >   acpi0: cleared fixed power button status
> > 
> > If these messages are legit, I'm wondering why I didn't see them on 8.4,
> > and if it might affect suspend/resume sequence (broken right now)?
> 
> [...] Your BIOS said "please put this device in D2 during suspend" and your
> device's capabilities said "I don't support D2".  You can confirm this by
> looking up the _S3 method of your _SB_.PCIO device to find out what state is
> requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see
> what D states are listed as supported.

This?:

Scope (\_SB)
{
Name (ECOK, 0x00)
Device (PCI0)
{
Method (_S3D, 0, NotSerialized)  // _S3D: S3 Device State
{
Return (0x02)
}
...

# pciconf -lc pci0:0:0
hostb0@pci0:0:0:0:  class=0x06 card=0x83191033 chip=0x25908086 rev=0x04 
hdr=0x00
cap 09[e0] = vendor (length 9) Intel cap 2 version 1

# pciconf -rb pci0:0:0 0xe0:0xff
09 00 09 21 02 a2 8b 90  0a 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 05 00 10 00 00 00

> There's not much we can do if your BIOS lies to us.

As long as we can patch ACPI tables, lying BIOS should not be a problem, no?

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Thinkpad T410: resume broken

[Alexey Dokuchaev]

On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote:
> On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote:
> > On Sat, May 17, 2014 at 08:20:03AM -0400, John Baldwin wrote:
> > > VESA needs to be removed for i915kms, but I've no idea if it needs to be
> > > removed for Nvidia.  The video reset code was reworked in 10 so that
> > > having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9,
> > > but in theory it works more often.
> > 
> > This (VESA needs to be removed for i915kms) is news to me: I don't see it
> > mentioned in UPDATING, and "options VESA" presents in -CURRENT's (post-KMS
> > era) GENERIC kernel config.  So what's the real deal here? :-)
> 
> This is an old mail you are responding to.  You no longer need to remove
> VESA for kms.

Ah OK, that would explain it, thanks.

> vesa.ko shouldn't be working with KMS.  KMS turns off the legacy VGA
> emulation in the hardware when it starts which prevents VESA from working
> (VESA requires the legacy VGA interface).

Hmm, could this explain why vesa.ko can be loaded from loader.conf, but
not via kldload(8)?  OTOH, kldload'ing it later does not seem to work
(ir)regardless of whether i915kms.ko is loaded or not...

> I never have to hit the power button more than once to resume on a laptop
> where resume works though.
> 
> (True on my X220 and on a T440 both with Intel or Radeon graphics (all
> using KMS).

I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence
I'll ask: do aforementioned laptops suspend/resume without issues in X11
or on the naked console as well?  (In a shop, I could only quickly test
our X11-less memstick image.)

> > Needless to say, suspend/resume worked nearly flawlessly under stable/8
> > and stable/7 FWIW.
> 
> If it worked here, then this means you could try using sc(4) + the old drm
> (not drm2).  This means your laptop is old enough to still turn the LCD panel
> back on in its BIOS during resume like my HP netbook.  However, I don't know
> for how much longer Xorg will support the older drm (if it even does now).

Well, technically, my laptop *does* resume with vt(4) + i915kms, just it
takes a lot of power button hits and quite some time (up to several minutes),
unless it dies somewhere during the process.  I'll retest it against
GENERIC and report in a separate email.  On a related note, how does one
configure sc(4) with old drm (vs. drm2) shall I need to try that?

> FWIW, the HP netbook resumes fine with KMS as well for me.  One caveat
> though is that if you are using vt(4) and haven't yet loaded KMS it won't
> resume (due to vt(4) not having the equivalent of VESA).  With sc(4) the
> netbook was always able to resume.

Right.  So far, I've been booting, kldloading i915kms.ko, zzz(8), resume.
No X.Org was involved -- given how fragile suspend/resume is ATM, I'd like
to iron out the issues with the pure console first.

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Thinkpad T410: resume broken

[Alexey Dokuchaev]

On Fri, May 23, 2014 at 10:00:30AM -0400, John Baldwin wrote:
> On Wednesday, May 21, 2014 3:43:49 pm Jan Henrik Sylvester wrote:
> > Looking through dmesg, it seems that other USB devices (build-in) are
> > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after
> > resume, just not the mouse.
> > 
> > Are these lines likely related?
> > 
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_:
> > AE_BAD_PARAMETER
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1:
> > AE_BAD_PARAMETER
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2:
> > AE_BAD_PARAMETER
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4:
> > AE_BAD_PARAMETER
> > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5:
> > AE_BAD_PARAMETER
> 
> These are probably not related.  These man that your BIOS explicitly told
> the OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5]
> are probably PCI-PCI bridges that represent the downstream ports of your
> PCI-e root complex) in the D2 state when suspending, but the devices don't
> actually support D2 (most PCI devices only support D0 (full on) and D3
> (full off)).

I've started to observe similar lines in the logs after updating to fresh
-CURRENT, upon resume (on a different laptop though, not T410):

  pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER
  acpi0: cleared fixed power button status

If these messages are legit, I'm wondering why I didn't see them on 8.4,
and if it might affect suspend/resume sequence (broken right now)?  Thanks,

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Unable to kldload vesa.ko (but works from loader.conf)

[Alexey Dokuchaev]

Hi there,

I've decided to give -CURRENT a try on my i386 laptop with a 915GM video
(supported by i915kms.ko) @ r295286; minimal kernel with most of the stuff
loaded from /boot/loader.conf.

While debugging suspend/resume issues, I've found out that loading vesa.ko
now apparently only works from /boot/loader.conf: doing it manually from
the command line after logging in gives me this error in dmesg(8):

module_register_init: MOD_LOAD (vesa, 0x, 0) error 19

Some scattered reports on the net did not shed the light on whether this
is expected behavior these days (which is a bit unexpected for a stable/8
user) or a regression due to lack of testing of standalone vesa.ko since
VESA is a default option in GENERIC.  Shall I file a PR?

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SMBus controller

[Alexey Dokuchaev]

On Sat, Jun 14, 2014 at 09:39:18PM +0200, Kurt Jaeger wrote:
 http://en.wikipedia.org/wiki/System_Management_Bus
 
 You can read some system status values (CPU temp etc).
 
 In the ports, check sysutils/xmbmon or sysutils/healthd
 whether it detects anything.

It can also be used to talk to one's computer memory (sysutils/i2c-tools),
something like this:

  # kldload smb.ko ichsmb.ko
  # cd /usr/ports/sysutils/i2c-tools  make extract
  # perl work/i2c-tools-3.1.0/eeprom/decode-dimms

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Fri, May 09, 2014 at 02:38:16PM +0900, Yonghyeon PYUN wrote:
 On Thu, May 08, 2014 at 05:23:32PM +, Alexey Dokuchaev wrote:
  I just had a chance to plug the Ethernet cable directly into my laptop's
  bge(4) port, and it immediately negotiated at 1000baseT; but with the 
  switch,
  it can only feel fine with 10baseT/UTP (after some 1000baseT-no carrier flip
  flopping).  So it looks like it fails to talk to the switch.  Given that 
  this
  switch of mine in a simple (dumb) piece of equipment, any ideas how to help
  ale(4) to negotiate with it at full speed?
 
 Because there is no publicly available data sheet for Atheros F1
 PHY I'm not sure what could be done in this case.  The only thing
 I can think of at this moment is announcement of next page in auto
 negotiation. [...]
 Try attached patch and let me know whether this makes any
 difference for you.  You may have to cold boot the box because
 stock driver used to clear next page bit in auto-negotiation.

Thanks for the patch, but it does not make any noticeable difference.  I'll
try to boot some Ubuntu livecd to see if it works there; eventually I might
have to simply go out and buy some PCI-E gigE card. :(

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Tue, Mar 05, 2013 at 09:14:11AM +, Alexey Dokuchaev wrote:
 On Tue, Mar 05, 2013 at 05:57:03PM +0900, YongHyeon PYUN wrote:
  Hmm, Does the switch support EEE feature? If yes, would you try
  disabling it?
 
 I do not think it [1] does; plus I cannot do much about this switch, as I'm
 pretty far away from it right now.
 
 [1] 
 http://netgear.com/home/products/switches-and-access-points/unmanaged-switches/GS608.aspx
  (got it about 4 years ago)

I just had a chance to plug the Ethernet cable directly into my laptop's
bge(4) port, and it immediately negotiated at 1000baseT; but with the switch,
it can only feel fine with 10baseT/UTP (after some 1000baseT-no carrier flip
flopping).  So it looks like it fails to talk to the switch.  Given that this
switch of mine in a simple (dumb) piece of equipment, any ideas how to help
ale(4) to negotiate with it at full speed?

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Leaving the Desktop Market

[Alexey Dokuchaev]

On Tue, Apr 01, 2014 at 03:10:22PM -0700, Kevin Oberman wrote:
 FreeBSD desktop since 3.3 (makes me a newbie!) I really dislike pulseaudio
 and have managed to live without it. Firefox works fine without it.
 Unfortunately they dropped OSS support a while go, so I now must use alsa,
 but it works well and without the pain of dealing with pulseaudio, a
 solution in search of a problem it I ever saw one.

PA should just die, of course, just like that kid's other products.  OSS
is so nice; it supports all those nifty features like per-application mixing
and stuff, we have a very strong implementation of it (kudos to ariff@, let
me remind us all: http://people.freebsd.org/~ariff/SOUND_4.TXT.html).

Giving Firerox back its OSS support is my on TODO list, unfortunately I do
not have any idea when (or if) I can look at it, but that would be a nice
step in dealsificaion of our Ports Collection.  OSS was, and should remain,
the standard Unixish sound system API.

 Audio output is pretty system dependent, but I had little problem getting
 my audio to auto-switch to headphones when I plugged them in. The setup is
 a bit ugly,but I only had to check the available PINs (ugly, ugly) and set
 up stuff once. It just works.

Not always, unfortunately.  I also had a working pin override configuration
in /boot/loader.conf, but after r236750 (major snd_hda driver rewrite) it
stopped working.  I've reported it and tried to get some support from mav@
but he never replied.  Since then, I have to carry pre-r236750 version of
snd_hda(4) to have working sound.

 Power is an issue and I find the current defaults suck. Read mav's article
 on the subject on the wiki.

From reading that article, I've only added hw.pci.do_power_nodriver=3 and
hw.pci.do_power_resume=0 to /boot/loader.conf.  More aggressive settings,
like cx_lowest=C2, made my laptop very sluggish and unpleasant to operate;
powerd(8) behaves sanely with no tuning, so I wouldn't say that our current
defaults suck.  The reason why we're behind on the green lane is because
we generally do not pay much attention when it comes to power-saving during
development of FreeBSD.  (I'd like to be proven wrong.)

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Leaving the Desktop Market

[Alexey Dokuchaev]

On Thu, Apr 03, 2014 at 11:21:34AM +0200, Matthias Gamsjager wrote:
  Since when is GIMP an alternative to Lightroom?  I was talking about
  raw processors, not raster image manipulators.
 
 The opensource alternatives to Lightroom come not close to the original.

They maybe not yet a drop-in replacement, but they are competitive enough
to be discussed on photo forums (read: outside open source geeky cabal):

http://www.pentaxforums.com/forums/32-digital-processing-software-printing/242584-darktable-vs-lightroom.html
http://photo.stackexchange.com/questions/37238/how-does-darktable-compare-to-adobe-lightroom-for-editing-jpegs
http://photo.stackexchange.com/questions/23272/simple-comparison-of-lightroom-4-corel-aftershot-pro-darktable
http://www.dpreview.com/forums/post/39475179

As they say, The differences in actual editing are negligible. It's not
even worth migrating between the two.  LR comes with a price-tag, Darktable
comes with bugs.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Leaving the Desktop Market

[Alexey Dokuchaev]

On Thu, Apr 03, 2014 at 09:49:31AM +0200, Matthias Gamsjager wrote:
  There are a few alternatives to Lightroom available in Ports Collection,
  you might want to give them a try one day.
 
 offtopic:
 But it does not even come close to Lightroom. Gimp is also not even
 close to Photoshop. Maybe Pixelmator. But Gimp? The UI and usability
 is such a mess.

Since when is GIMP an alternative to Lightroom?  I was talking about
raw processors, not raster image manipulators.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Leaving the Desktop Market

[Alexey Dokuchaev]

On Tue, Apr 01, 2014 at 08:38:28AM +0100, David Chisnall wrote:
 On 1 Apr 2014, at 08:11, Jordan Hubbard j...@mail.turbofuzz.com wrote:
  1. Power.  As you point out, being truly power efficient is a complete
  top-to-bottom engineering effort and it takes a lot more than just trying
  to idle the processor whenever possible to achieve that.  You need to
  optimize all of the hot-spot routines in the system for power efficiency
  (which actually involves a fair amount of micro architecture knowledge),
  you need a kernel scheduler that is power management aware, you need a
  process management system that runs as few things as possible and knows
  how to schedule things during package wake-up intervals, you need timers
  to be coalesced at the level where applications consume them, the list
  just goes on and on.  It's a lot of engineering work, and to drive that
  work you also need a lot of telemetry data and people with big sticks
  running around hitting people who write power-inefficient code.  FreeBSD
  has neither.

Thanks Jordan, this is an excellent elaboration on why exactly we're behind
on the green lane, and on power-neglective FreeBSD development overall.

 Just a small note here: Improving power management is something that the
 Core Team and the Foundation have jointly identified as an important goal,
 in particular for mobile/embedded scenarios.  We're currently coordinating
 potential sponsors for the work and soliciting proposals from people
 interested in doing the work.  If you know of anyone in either category
 then please drop either me, core, or the Foundation an email.
 
 Some things have already seen progress, for example Davide's calloutng work
 includes timer coalescing, but there are still a lot of, uh, opportunities
 for improvement.  The Symbian EKA2 book has some very interesting detail on
 their power management infrastructure, which would be worth looking at for
 anyone interested in working on this, and I believe your former employer
 had some expertise in this area.

Now that's something I'm glad to hear.  It would be cool if FreeBSD gained
some power-efficient software that run smoothly together with hardware (and
laptops in particular) developed by Jordan's former employer. ;-)

 For example, currently hald wakes up every 30 seconds and polls the optical
 drive if you have one.  Why?  Because there's no devd event when a CD is
 inserted, so the only way for it to get these notifications is polling.

I'm surprised to find out that our devd(8) does not emit some event on CD
insertion.  On the other, if by hald you mean the one installed by the
`sysutils/hal' port, I've personally never run it, and do not recommend it
to anyone.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Leaving the Desktop Market

[Alexey Dokuchaev]

On Tue, Apr 01, 2014 at 06:40:18PM -0400, Garrett Wollman wrote:
 Hmmm.  I'm a bit biased here, but I've been using FreeBSD on the
 desktop since, well, before it was called FreeBSD.  It's still my
 primary platform for nearly everything (except photo management, which
 drove me to a Mac laptop so I could run Lightroom, and those few

There are a few alternatives to Lightroom available in Ports Collection,
you might want to give them a try one day.

 remaining Web sites that still bury all their content inside Flash).

That's easy: Flash sites should be avoided.  Most of them are using this
technology for showing stupid ads anyway, not for something useful.  I
still recall a friend of mine actually *loved* that his iPhone does not
support Flash: it essentially enabled (ad|spam)-free Web browsing (alas,
those fuckers had caught up since then).

 But let's be clear that different people have different requirements
 for a desktop.  My requirements are relatively simple: twm, xterm,
 XEmacs, vlc, LaTeX, xpdf, a Jabber client (psi), $VCS_OF_CHOICE,
 gnucash, and at least two Web browsers (I use Opera for most stuff and
 Firefox for promiscuous-mode browsing).  [...]
 
 Other people have rather different requirements, and that's OK.  But
 let's please not break the applications for which FreeBSD is very good
 now (and has actually gotten substantially better).

Application availability does not, unfortunately, round up some perfect
desktop.  I fear that Linux-centric development of hardware drivers, X.org
and all that shit is getting more and more divergent from FreeBSD, and
soon enough we'll get the situation I haven't seen for some 15 years: we
are again far behind on modern HW support.

Power-saving techniques, most notably working sleep-resume and competitive
batter life are also our weak points at the moment.  I'd like to replace
my old laptop (which runs 8.4-STABLE almost perfectly), but how far can I
go with, say, recent MacBook Pro?

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r263096 sparc64: casperd: Unable to receive message from client: Cannot allocate memory.

[Alexey Dokuchaev]

On Fri, Mar 14, 2014 at 02:54:43PM +0100, Jilles Tjoelker wrote:
 On Thu, Mar 13, 2014 at 05:14:56AM -0700, Anton Shterenlikht wrote:
  Mar 13 12:08:48 casperd[1313]: [ERROR] (casperd) Unable to receive message 
  from client: Cannot allocate memory.
  Mar 13 12:08:50 last message repeated 2 times
  Mar 13 12:09:57 casperd[1313]: [ERROR] (casperd) Unable to receive message 
  from client: Cannot allocate memory.

I'm seeing this as well on fresh -CURRENT/powerpc when trying to ping(8)
something with casperd(8) enabled; albeit a bit different (s/Cannot allocate
memory/Invalid argument/).

 It looks like a bug causes the big endian flag to be lost. As a
 result, the bits are interpreted as little endian and an extremely large
 allocation is attempted. Try this patch:
 
 Index: lib/libnv/nvlist.c
 ===
 --- lib/libnv/nvlist.c(revision 262358)
 +++ lib/libnv/nvlist.c(working copy)
 @@ -582,7 +582,7 @@ nvlist_check_header(struct nvlist_header *nvlhdrp)
   errno = EINVAL;
   return (false);
   }
 - if ((nvlhdrp-nvlh_flags = ~NV_FLAG_ALL_MASK) != 0) {
 + if ((nvlhdrp-nvlh_flags  ~NV_FLAG_ALL_MASK) != 0) {
   errno = EINVAL;
   return (false);
   }

This patch alone (without touching lib/libnv/msgio.c) fixed it for me
(applied, rebuilt/reinstalled libnv, restared casperd(8)), thank you! :)

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Alexey Dokuchaev]

On Mon, Mar 10, 2014 at 03:41:16PM +0800, Kevin Lo wrote:
 On 2014/02/10 20:21, Alexey Dokuchaev wrote:
 To augment this a bit: I also came across one of these dongles (vendor
 0x0bda product 0x8176) that gave me this timeout waiting for checksum
 report message.  Retrying didn't help, but plugging the dongle out and
 then back in did.  After powercycling the machine, I had to replug it
 again.  Once replugged, the dongle seems to work fine (I rebuilt kernel
 and some ports via NFS over it thus far).
 
 This suggests that the driver (or more generic part of the USB stack)
 does not initialize something correctly, while full plug-and-play thing
 does it.  Any ideas?
 
 We have to reset the bit of the R92C_MCUFWDL associated with checksum report
 before writing firmware.  Could you try this patch? Thanks.

Shit.  I'd like to help, but no longer have access to the dongle.  If I find
anything similar (or find a way to get access to original dongle remotely),
I'll let you know. :(

Thanks for working on these things Kevin, I appreciate it.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Reboot with newcons (vt/vt_vga) + ATI Radeon HD 4350 on i386

[Alexey Dokuchaev]

Hi there,

Following my previous more of less successful experience with newcons on
-CURRENT/amd64 and some ATI/AMD card, I've decided to give it a try here
on i386 with somewhat older HD 4350, also from ATI.  Unfortunately, this
time newcons'ified GENERIC kernel + startx = reboot (core.txt attached).

Same happens (reboot) if kldload radeonkms is done on the console;
kldload'ing radeon.ko allows the box to survive startx(1), but it fails
with (EE) RADEON(0): Kernel modesetting setup failed in Xorg.0.log.

Switching back to syscons(4) allows me to start X.org (with KMS-related
modules successfully loaded and DRI enabled).  This' all sans xorg.conf.

  $ kldstat | grep radeonkms
  111 0xc79c2000 fd000radeonkms.ko
  161 0xc7e75000 2000 radeonkmsfw_RV710_pfp.ko
  171 0xc7e77000 3000 radeonkmsfw_RV710_me.ko
  181 0xc7e7a000 3000 radeonkmsfw_R700_rlc.ko

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: newcons comming

[Alexey Dokuchaev]

On Mon, Feb 10, 2014 at 09:09:43PM -0500, Ed Maste wrote:
 You should be able to manually load the kms modules to switch to
 native resolution, without starting X.

Indeed, kldload'ing radeonmks.so switched LCD to its native resolution.
What if I am on CRT (which has many native resolutions).  Is there way
to select particular one (other than patching source code)?

 On 10 February 2014 16:07, Alexey Dokuchaev da...@freebsd.org wrote:
  Also, even at native resolution, switching consoles takes LCD considerable
  time to redraw screen contents.  Looks like it's not accelerated at all...
 
 Can you quantify considerable time, and describe the hardware on
 which you observe this?

It means that I can see that top part of the screen is drawn before bottom
one (I've made a lame video: https://vidd.me/NqM).  This is on some NEC
AS231WM monitor connected to RV410 (Radeon X700 Pro), per pciconf(8).

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Alexey Dokuchaev]

On Tue, Oct 15, 2013 at 11:13:56PM -0700, Rui Paulo wrote:
 On 8 Oct 2013, at 10:41, Julian H. Stacey j...@berklix.com wrote:
  I too am seeing
  urtwn0: timeout waiting for checksum report
 
 Sorry, this is a know problem that I haven't been able to figure out...
 It probably exists in the OpenBSD driver as well. Usually retrying works.

To augment this a bit: I also came across one of these dongles (vendor
0x0bda product 0x8176) that gave me this timeout waiting for checksum
report message.  Retrying didn't help, but plugging the dongle out and
then back in did.  After powercycling the machine, I had to replug it
again.  Once replugged, the dongle seems to work fine (I rebuilt kernel
and some ports via NFS over it thus far).

This suggests that the driver (or more generic part of the USB stack)
does not initialize something correctly, while full plug-and-play thing
does it.  Any ideas?

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Alexey Dokuchaev]

On Mon, Feb 10, 2014 at 01:25:06PM +0100, Hans Petter Selasky wrote:
 On 02/10/14 13:21, Alexey Dokuchaev wrote:
 To augment this a bit: I also came across one of these dongles (vendor
 0x0bda product 0x8176) that gave me this timeout waiting for checksum
 report message.  Retrying didn't help, but plugging the dongle out and
 then back in did.  After powercycling the machine, I had to replug it
 again.  Once replugged, the dongle seems to work fine (I rebuilt kernel
 and some ports via NFS over it thus far).
 
 Looking at output from usbdump -i usbusX -f Y might give you some clues.
 Else have you tried usbconfig -d X.Y reset.

Hmm; I've added if_urtwn_load=YES and some ifconfig...=WPA DHCP lines
to rc.conf and surprisingly it came up OK after reboot.  usbdump is full
of these lines (timestamps trimmed):

usbus0.3 SUBM-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=0,IVAL=0
usbus0.3 DONE-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=384,IVAL=0,ERR=0
   ^^^ sometimes 256

If I notice checksum timeout situation again, I'll post an update; thank
you for the tips.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: newcons comming

[Alexey Dokuchaev]

On Sun, Nov 03, 2013 at 11:16:53PM -0800, Kevin Oberman wrote:
 Are you booting directly to X or using startx from the console? In either
 case, I think that i915kms should auto-load at the start of X, so you
 should not need to pre-load it.

Just switched to newcons on fresh -CURRENT, seem to work fine so far.  Going
to X (via startx) does load required modules automagically (radeonkms.ko and
radeonkmsfw_R420_cp.ko in my case).

Switching to and from the console also works now (did not work with syscons),
but screen resolution remains the one X sets (LCD native).  I thought that
going back to console would restore its original, somewhat closer to 80x25
resolution, but it did not.  Which brings me to my first question:

1. Before going X, switching consoles took considerable time (about or more
than one second).  Every time my monitor briefly displayed mode information
pane like it does when new mode is being switched.  It does not happen after
X was loaded, and while console text is pretty small now (LCD runs at native
resolution for all consoles, text ones + X), I'm wondering why it cannot be
done up front, without having to startx first.

Also, even at native resolution, switching consoles takes LCD considerable
time to redraw screen contents.  Looks like it's not accelerated at all...

2. Is there way to change fonts apart from patching the kernel source code
and using tools from https://github.com/emaste/fontstuff?  Can I use more
than one font (e.g. for different Unicode code point ranges)?

 Does newcons require VESA? If not, you should be able to remove it from
 your kernel to get suspend/resume working from X.

I didn't know that VESA (in kernel or kldloaded) can cause problems; can you
give any pointers (e.g. reports on the maillists)?  I've seen FreeBSD fail
to come out of resume too often and want to check if VESA could be the cause.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Alexey Dokuchaev]

On Thu, Dec 19, 2013 at 09:56:31AM +0800, Kevin Lo wrote:
 Your usb wlan dongles use RTL8188EU chip which is currently not
 supported by any of drivers.

I see; I guess I should not have believed when I was told that most likely
all it would take is id-patch urtwn(4). ;-)

Does anyone know if support is being worked on?  Given an increased
popularity of these dongles, perhaps a wiki page would be nice for
those of us who want to get an idea if some particular chip is supported
before buying them (online).

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Alexey Dokuchaev]

On Fri, Dec 20, 2013 at 01:35:37PM +0800, Kevin Lo wrote:
 I'd like to port it after finishing RT5373 driver support. :-)

Nice, looking forward to it. :)

 Here's a site you could use for info about your wireless device:
 http://wikidevi.com/wiki/TP-LINK_TL-WN723N_v3

Thank you Kevin.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Alexey Dokuchaev]

On Sun, Oct 06, 2013 at 10:24:09AM -0700, Alfred Perlstein wrote:
 I got one of these (if_urtwn) and it works enough to download about a meg
 or so before the watchdog kicks in and I have to ifconfig down/up it to
 get it to respond again.
 
 I even have a patch pending to add the usb identifier for this.

Same here; someone at $work bought couple of these teeny dongles.  I've
applied small id patch (attached), and tried to use it (it reportedly
works flawlessly under Linux using this [*] driver).  I could load the
module, but MAC address was clearly bogus (00:00:30:34:43:30); yet I've
created wlan0 just to find out that there is no list scan results, and
wpa_supplicant(8) gives me this in an endless loop (GENERIC kernel, so
I presume all wlan-related stuff should be in place):

   Successfully initialized wpa_supplicant
   ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured
   wlan0: Failed to initiate AP scan

This is on relatively fresh 11-CURRENT as of Oct 18th, i386.  Any clues?
It would be nice to get more of these little guys to work, esp. there is
working Linux driver available for reference.

./danfe

[*] https://github.com/liwei/rpi-rtl8188eu
Index: usbdevs
===
--- usbdevs	(revision 256716)
+++ usbdevs	(working copy)
@@ -3602,6 +3602,7 @@
 product REALTEK RTL8188CU_COMBO	0x8754	RTL8188CU
 product REALTEK RTL8191CU	0x8177	RTL8191CU
 product REALTEK RTL8192CU	0x8178	RTL8192CU
+product REALTEK RTL8188EU	0x8179	RTL8188EU
 product REALTEK RTL8192CE	0x817c	RTL8192CE
 product REALTEK RTL8188RU_1	0x817d	RTL8188RU
 product REALTEK RTL8712		0x8712	RTL8712
Index: wlan/if_urtwn.c
===
--- wlan/if_urtwn.c	(revision 256716)
+++ wlan/if_urtwn.c	(working copy)
@@ -138,6 +138,7 @@
 	URTWN_DEV(REALTEK,	RTL8191CU),
 	URTWN_DEV(REALTEK,	RTL8192CE),
 	URTWN_DEV(REALTEK,	RTL8192CU),
+	URTWN_DEV(REALTEK,	RTL8188EU),
 	URTWN_DEV(SITECOMEU,	RTL8188CU_1),
 	URTWN_DEV(SITECOMEU,	RTL8188CU_2),
 	URTWN_DEV(SITECOMEU,	RTL8192CU),
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fatal trap 12: page fault while in kernel mode (FUSE related?)

[Alexey Dokuchaev]

On Thu, Oct 31, 2013 at 09:59:42AM -0700, Kevin Oberman wrote:
 On Tue, Oct 29, 2013 at 3:24 AM, Alexey Dokuchaev da...@nsu.ru wrote:
  I was running out of space on my UFS partition and decided to use big NTFS
  one I also have on the drive.  I've mounted it with ntfs-3g and our native
  fuse.ko.  I needed the scratch space to built Open/LibreOffice on it *LOL*.
  Well, it failed with a panic (see the excerpt from text core at the end of
  this email; full debug info is available upon request).
 
 I get a very similar panic when I attempt an rsync from a remote system
 to my NTFS drive. Very easy to reproduce. Something in fuse goes off the
 rails under active R/W activity, it seems.

Hmm, given more people are seeing it, and it's not too hard to reproduce,
I hope it can be tracked down and nailed.  I will enable debugging features
in my kernel so I can gather some data when this shit happens again to me.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: MACHINE_CPU detection b0rked?

[Alexey Dokuchaev]

On Thu, Oct 31, 2013 at 11:35:34AM +0100, Tijl Coosemans wrote:
 bsd.cpu.mk redefines CPUTYPE sometimes and that doesn't work if you
 pass it as a command line argument.  You can only set this variable
 in make.conf.

Indeed, thanks; setting in make.conf works, however the fact that redefined
variables cannot be bootstrapped from command line looks like a bug to me.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

MACHINE_CPU detection b0rked?

[Alexey Dokuchaev]

Hi,

Judging from /usr/share/mk/bsd.cpu.mk, it knows about both core and
core2 and should be able to give me the list of features these CPUs
support.  However, I'm puzzled:

$ make -V MACHINE_CPU CPUTYPE=core2
ssse3 sse3 sse2 sse i686 mmx i586 i486
$ fmake -V MACHINE_CPU CPUTYPE=core2
ssse3 sse3 sse2 sse i686 mmx i586 i486
$ make -V MACHINE_CPU CPUTYPE=core
i486
$ fmake -V MACHINE_CPU CPUTYPE=core
i486 i486
$ uname -Um
i386 110

WTF? :)

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Fatal trap 12: page fault while in kernel mode (FUSE related?)

[Alexey Dokuchaev]

Hi again,

I was running out of space on my UFS partition and decided to use big NTFS
one I also have on the drive.  I've mounted it with ntfs-3g and our native
fuse.ko.  I needed the scratch space to built Open/LibreOffice on it *LOL*.
Well, it failed with a panic (see the excerpt from text core at the end of
this email; full debug info is available upon request).

This is on fresh 11-CURRENT, i386.

./danfe

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x64
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xcae6adb6
stack pointer   = 0x28:0xf0ac29a0
frame pointer   = 0x28:0xf0ac2a0c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 14116 (conftest)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0xc0aed942 at kdb_backtrace+0x52
#1 0xc0ab37e1 at panic+0x121
#2 0xc0f8df09 at trap_fatal+0x339
#3 0xc0f8e23d at trap_pfault+0x31d
#4 0xc0f8d819 at trap+0x519
#5 0xc0f776ec at calltrap+0x6
#6 0xc0fb2864 at VOP_CREATE_APV+0x94
#7 0xc0b355ab at uipc_bindat+0x36b
#8 0xc0b33307 at uipc_bind+0x27
#9 0xc0b2c277 at kern_bindat+0x147
#10 0xc0b2c064 at sys_bind+0x74
#11 0xc0f8e939 at syscall+0x479
#12 0xc0f77781 at Xint0x80_syscall+0x21
Uptime: 1d23h57m34s
Physical memory: 2027 MB
...
(kgdb) #0  doadump (textdump=-961984384) at pcpu.h:233
#1  0xc0ab3459 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2  0xc0ab381f in panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:754
#3  0xc0f8df09 in trap_fatal (frame=value optimized out, eva=100)
at /usr/src/sys/i386/i386/trap.c:1047
#4  0xc0f8e23d in trap_pfault (frame=0x0, usermode=value optimized out, 
eva=0) at /usr/src/sys/i386/i386/trap.c:859
#5  0xc0f8d819 in trap (frame=0xf0ac2960) at /usr/src/sys/i386/i386/trap.c:556
#6  0xc0f776ec in calltrap () at /usr/src/sys/i386/i386/exception.s:170
#7  0xcae6adb6 in fuse_vnop_create (ap=0x0)
at /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vnops.c:368
#8  0xc0fb2864 in VOP_CREATE_APV (vop=value optimized out, a=0xf0ac2b88)
at vnode_if.c:265
#9  0xc0b355ab in uipc_bindat (so=0xf0ac2b20, nam=value optimized out, 
td=value optimized out) at vnode_if.h:109
#10 0xc0b33307 in uipc_bind (so=0xc80ab9f0, nam=0xc8580e80, td=0xce271620)
at /usr/src/sys/kern/uipc_usrreq.c:573
#11 0xc0b2c277 in kern_bindat (td=0xce271620, dirfd=value optimized out, 
fd=value optimized out, sa=0xce271620)
at /usr/src/sys/kern/uipc_syscalls.c:283
#12 0xc0b2c064 in sys_bind (td=0x0, uap=value optimized out)
at /usr/src/sys/kern/uipc_syscalls.c:297
#13 0xc0f8e939 in syscall (frame=value optimized out) at subr_syscall.c:134
#14 0xc0f77781 in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:270
#15 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb) 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

panic: softdep_deallocate_dependencies: unrecovered I/O error

[Alexey Dokuchaev]

Hi there,

Just now my pretty fresh 11-CURRENT rebooted unexpectedly in the middle of
'svn up'.  Some information from core.txt.0 (full version available upon
request) given in the end of this email.  (Machine: 11.0-CURRENT/i386 built
on Oct 18, GENERIC kernel, default install, single / partition with J+SU.)

This particular crash is worrisome for me for the following reasons:

- I had lost some data; /usr/ports (checked out copy) become corrupted:
  some files have zero size; also svn(1) now reports that repo version is
  12(!); I never had experienced such a fuckup with FreeBSD in years; it
  makes 10.0 look particularly bad: I can even cope with FreeBSD becoming
  bloated and slow, but I definitely cannot tolerate data loss -- we are
  not Linux after all;

- I've already seen these 'error=11' messaged on -CURRENT before, again,
  while doing 'svn up'; I've followed up [1] about it on -hackers@ on Oct
  1st; avg@ game me some advice [2], but I did not have a chance to see if
  it helps yet (I've never seen those errors again on my laptop, until it
  happened today on another box also running -CURRENT); perhaps this panic
  can somehow expedite investigation.

./danfe

[1] http://docs.freebsd.org/cgi/mid.cgi?20131001192955.GA27965
[2] http://docs.freebsd.org/cgi/mid.cgi?524B2555.7030408

Unread portion of the kernel message buffer:
g_vfs_done():ada0s3a[WRITE(offset=11688411136, length=32768)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11688476672, length=131072)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11688607744, length=32768)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11689328640, length=32768)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11689394176, length=131072)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11689525248, length=65536)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11689820160, length=131072)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11690704896, length=131072)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11691196416, length=131072)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11691327488, length=131072)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11691458560, length=131072)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11691589632, length=131072)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11691720704, length=131072)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=11692081152, length=98304)]error = 11
g_vfs_done():ada0s3a[WRITE(offset=10815619072, length=4096)]error = 11
/: got error 11 while accessing filesystem
panic: softdep_deallocate_dependencies: unrecovered I/O error
cpuid = 0
KDB: stack backtrace:
#0 0xc0aed942 at kdb_backtrace+0x52
#1 0xc0ab37e1 at panic+0x121
#2 0xc0d044b1 at softdep_deallocate_dependencies+0x71
#3 0xc0b39ce6 at brelse+0x86
#4 0xc0b3d470 at bufdone+0x60
#5 0xc0a1967a at g_vfs_done+0x27a
#6 0xc0b3cf24 at biodone+0x54
#7 0xc0a15f04 at g_io_schedule_up+0x1d4
#8 0xc0a1649d at g_up_procbody+0x6d
#9 0xc0a82ab3 at fork_exit+0xa3
#10 0xc0f77794 at fork_trampoline+0x8
...
(kgdb) #0  doadump (textdump=-961984384) at pcpu.h:233
#1  0xc0ab3459 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2  0xc0ab381f in panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:754
#3  0xc0d044b1 in softdep_deallocate_dependencies (bp=value optimized out)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:13595
#4  0xc0b39ce6 in brelse (bp=0xe1a8b850) at buf.h:427
#5  0xc0b3d470 in bufdone (bp=value optimized out)
at /usr/src/sys/kern/vfs_bio.c:3759
#6  0xc0a1967a in g_vfs_done (bip=value optimized out)
at /usr/src/sys/geom/geom_vfs.c:161
#7  0xc0b3cf24 in biodone (bp=0xce43fe40) at /usr/src/sys/kern/vfs_bio.c:3579
#8  0xc0a15f04 in g_io_schedule_up (tp=0xc6a91930)
at /usr/src/sys/geom/geom_io.c:799
#9  0xc0a1649d in g_up_procbody (arg=0x0) at /usr/src/sys/geom/geom_kern.c:98
#10 0xc0a82ab3 in fork_exit (callout=0xc0a16430 g_up_procbody)
at /usr/src/sys/kern/kern_fork.c:995
#11 0xc0f77794 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:279
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Cross-buildkernel (i386-amd64) is broken?

[Alexey Dokuchaev]

On Fri, Sep 06, 2013 at 10:46:49AM -0700, John-Mark Gurney wrote:
 Alexey Dokuchaev wrote this message on Sat, Sep 07, 2013 at 00:29 +0700:
  On Fri, Sep 06, 2013 at 10:08:20AM -0700, hiren panchasara wrote:
   On Fri, Sep 6, 2013 at 8:12 AM, Alexey Dokuchaev da...@nsu.ru wrote:
Hi there,
   
I've been trying to cross-build an amd64 kernel on i386 host on recent
-CURRENT for a while, and it fails like this:
   
   Not entirely sure but you _probably_ need to make toolchain first?
  
  Hmm, now that you've mentioned it, I vaguely recall that when not doing
  complete 'make world', that might be in order.  Thanks, I will try it
  tomorrow.
 
 or make kernel-toolchain if you don't want to build as much..

Right, that's what I need.  I'm having problems with amd64 kernel panicing
immediately on boot on my Lenovo E5500 based workstation, while with i386,
things are fine.  So I want just the kernel right now, nothing else.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Cross-buildkernel (i386-amd64) is broken?

[Alexey Dokuchaev]

On Fri, Sep 06, 2013 at 10:08:20AM -0700, hiren panchasara wrote:
 On Fri, Sep 6, 2013 at 8:12 AM, Alexey Dokuchaev da...@nsu.ru wrote:
  Hi there,
 
  I've been trying to cross-build an amd64 kernel on i386 host on recent
  -CURRENT for a while, and it fails like this:
 
 Not entirely sure but you _probably_ need to make toolchain first?

Hmm, now that you've mentioned it, I vaguely recall that when not doing
complete 'make world', that might be in order.  Thanks, I will try it
tomorrow.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Cross-buildkernel (i386-amd64) is broken?

[Alexey Dokuchaev]

Hi there,

I've been trying to cross-build an amd64 kernel on i386 host on recent
-CURRENT for a while, and it fails like this:

  $ cd /usr/src  make buildkernel TARGET=amd64 TARGET_ARCH=amd64
  [...]
  In file included from /usr/src/sys/amd64/amd64/genassym.c:46:
  In file included from /usr/src/sys/sys/buf.h:260:
  In file included from /usr/src/sys/sys/proc.h:62:
  /usr/src/sys/sys/pcpu.h:188:1: error: static_assert failed compile-time 
assertion failed
  CTASSERT((PAGE_SIZE / sizeof(struct pcpu)) * sizeof(struct pcpu) == 
PAGE_SIZE);

Full log is available here: http://193.124.210.26/xbuild-amd64.log

I remember it used to work before (at least at Jun 28th, when I've build
my last kernel this way).  Is is a well known issue?  How do I remedy it?
Thanks.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fun with nvi

[Alexey Dokuchaev]

On Sat, Aug 10, 2013 at 10:33:20AM -0700, Peter Wemm wrote:
 I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2.
 
 https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1
 https://github.com/lichray/nvi2
 
 The goal was to update the multibyte handling in nvi-1.79 (the one we
 have in our tree) in such a way we could import it.

Yes, please do something about our base(1) being unable to talk in anything
non-ASCII.  I'm using editors/nvi-devel now, which was WIDECHAR option, and
was wondering why those changes were never imported into the base.

How is nvi 1.81.6 (per editors/nvi-devel) is different from nvi2, btw?

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fun with nvi

[Alexey Dokuchaev]

On Sun, Aug 11, 2013 at 02:15:15AM -0700, Peter Wemm wrote:
 On Sun, Aug 11, 2013 at 1:35 AM, Alexey Dokuchaev da...@freebsd.org wrote:
  Yes, please do something about our base(1) being unable to talk in anything
  non-ASCII.  I'm using editors/nvi-devel now, which was WIDECHAR option, and
  was wondering why those changes were never imported into the base.

Yuck, pardon my typos: it should read base vi(1) and has WIDECHAR option.

  How is nvi 1.81.6 (per editors/nvi-devel) is different from nvi2, btw?
 
 The original reason was that nvi-devel switched from the db-1.x API to
 db-3/db-4 which were sleepycat licensed, and are now Oracle.  It was a
 big chunk of code at the time.  eg:
 USE_BDB=42+
 CONFIGURE_ARGS+=--with-db-prefix=${LOCALBASE}
 
 nvi2 is nvi-1.79 from base with a serious cleanup pass.  The
 iconv/multibyte code will look quite familiar if you've looked at the
 nvi-devel code, along with a cherry-picking of additions from nvi-m17n
 for better CJK/non-utf8 support.

Understood, thanks for the insight.

 nvi2 does not have the same level of sophisticated encoding detection
 that nvi-m17n has.

I don't care too much about encoding detection since all sane parts of the
world would have switched to UTF-8 by now. ;-)

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Updating from 9.1-release to svn head: what might be the problem?

[Alexey Dokuchaev]

On Tue, Jun 18, 2013 at 10:21:33PM +0700, Alexey Dokuchaev wrote:
 I've been trying to install fresh -CURRENT (in VirtualBox/i386), and since
 recent snapshots did not work for me, had to do this by first installing
 from 9.1-release .iso.  After svn co .../head /usr/src and standard make
 world/kernel/mergemaster procedure (w/out any custom settings in make.conf
 or src.conf), I apparently keep getting screwed up system [...]

It's getting strange: colleague at $work convinced me to try VMware Player,
and I reluctantly agreed...  Well, with that thing I managed to install
Marchish -CURRENT snapshot, successfully rebuild the world, and now building
my ports...  So I'm puzzled: is it my hands, broken 9.1 - 10.0 upgrade, or
some VirtualBox vs. VMplayer issue?..

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Updating from 9.1-release to svn head: what might be the problem?

[Alexey Dokuchaev]

Hi there,

I've been trying to install fresh -CURRENT (in VirtualBox/i386), and since
recent snapshots did not work for me, had to do this by first installing
from 9.1-release .iso.  After svn co .../head /usr/src and standard make
world/kernel/mergemaster procedure (w/out any custom settings in make.conf
or src.conf), I apparently keep getting screwed up system (repeated twice
from scratch already):

  1) mtree is complaining that BSD.usr.dist's line 1150 is too long (wtf?)
  2) trying to do 'wc -l .../BSD.usr.dist' results in immediate segfault
 (wc -l /etc/passwd works though)
  3) installing anything from ports fails due to checksum mismatch of
 pkg-1.0.13.tar.xz distfile, while checksums actually match if verified
 manually (wtf?)

Am I doing something wrong, or perhaps missed some vital UPDATING note?

Thanks.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Tue, Mar 05, 2013 at 04:43:15PM +0900, YongHyeon PYUN wrote:
   Could you disable WOL before rebooting your box?
  
  # ifconfig ale0 -wol
  # reboot
  
  It came up as 100baseTX. :(
 
 You don't use any manual link configuration, right?

Right, everything is auto (that is, the defaults).

 When you see the controller established a 100Mbps link, how about
 restarting auto-negotiation? Does that also result in 100Mbps link?

# ifconfig ale0 media auto
# ifconfig ale0 | egrep -v ether\|inet
ale0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=c319aTXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet autoselect (100baseTX full-duplex)
status: active

Tried a few times, no difference.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Tue, Mar 05, 2013 at 05:57:03PM +0900, YongHyeon PYUN wrote:
 Hmm, Does the switch support EEE feature? If yes, would you try
 disabling it?

I do not think it [1] does; plus I cannot do much about this switch, as I'm
pretty far away from it right now.

./danfe

[1] 
http://netgear.com/home/products/switches-and-access-points/unmanaged-switches/GS608.aspx
 (got it about 4 years ago)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Mon, Mar 04, 2013 at 04:06:32PM +0900, YongHyeon PYUN wrote:
 On Mon, Mar 04, 2013 at 06:59:40AM +, Alexey Dokuchaev wrote:
  Better this time, I'm having 1000baseT again! :-)
 
 Thanks a lot for testing and patience!
 Could you reboot multiple times and check whether you reliably get
 a gigabit link?

Yes, multiple reboots was a good idea, it's not very stable:

1st reboot: 100baseTX (!)
2nd reboot: 1000baseT
3rd reboot: 1000baseT
4th reboot: 1000baseT
5th reboot: 100baseTX (!)
6th reboot: 100baseTX (!)
7th reboot: 1000baseT
8th reboot: 100baseTX (!)
9th reboot: 1000baseT
10th reboot:1000baseT

I've tried various combinations of just reboot, shutdown -r +1m and pinging
some host while waiting for reboot.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Tue, Mar 05, 2013 at 02:49:20PM +0900, YongHyeon PYUN wrote:
 On Mon, Mar 04, 2013 at 08:18:58AM +, Alexey Dokuchaev wrote:
  Yes, multiple reboots was a good idea, it's not very stable: [...]
  
  I've tried various combinations of just reboot, shutdown -r +1m and
  pinging some host while waiting for reboot.
 
 Could you disable WOL before rebooting your box?

# ifconfig ale0 -wol
# reboot

It came up as 100baseTX. :(

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Mon, Feb 25, 2013 at 05:23:44PM +0900, YongHyeon PYUN wrote:
 Then have no idea at this moment. Can you try other OS and check
 whether it can establish a gigabit link?

I did not have a chance to try other OS, because machine paniced during
tinderbuilding of a large port.  Unfortunately I don't have a backtrace, as
I needed to ask my friends to reboot it (I myself do not have direct access
to it right now).

However, after reboot ale0 come up at 1000baseT full-duplex, with patched
driver (longer delays in ale_phy_reset()).  I've reverted this change and
rebooted again, but it again come up as GigE.  I cannot power down the box
completely, since there is no one around who can bring it back right now
(press the power button).

That said, it looks quite weird to me at this point.  Previously it was
rebooted a few times, and link speed was always 100mbps.  Patching the
driver and re-kldloading it did not help, but after reboot, link speed is
1000ish even with unpatched driver.  :-/

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Sun, Mar 03, 2013 at 09:53:30AM +, Alexey Dokuchaev wrote:
 However, after reboot ale0 come up at 1000baseT full-duplex, with patched
 driver (longer delays in ale_phy_reset()).  I've reverted this change and
 rebooted again, but it again come up as GigE.

Alas, after make kernel, link come up as 100mbps again, playing with
delays and rebooting (several times) did not make it GigE.  I'm not sure
what's actually affecting it. :-(

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Mon, Mar 04, 2013 at 09:50:44AM +0900, YongHyeon PYUN wrote:
 On Sun, Mar 03, 2013 at 12:00:10PM +, Alexey Dokuchaev wrote:
  Alas, after make kernel, link come up as 100mbps again, playing with
  delays and rebooting (several times) did not make it GigE.  I'm not sure
  what's actually affecting it. :-(
 
 Would you try attached patch?

Yes, it did help.  With 2000us delays (I didn't revert them since you didn't
ask), machine came up after make kernel and reboot with ale0 in GigE mode.

I'll be happy to conduct more tests for you, if needed, thanks!

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Mon, Mar 04, 2013 at 11:10:59AM +0900, YongHyeon PYUN wrote:
 On Mon, Mar 04, 2013 at 01:53:44AM +, Alexey Dokuchaev wrote:
  Yes, it did help.  With 2000us delays (I didn't revert them [...]
 
 Great! But it seems 2ms delays is too much.  Could you revert the change
 (2000us delays) and try it again?

Reverting if_ale.c, making kernel, and reboot gave me 100baseTX again; :-(
second reboot (with the same kernel) did not help.  Bumping delays to 2ms
(just to make sure) restored GigE mode upon 1st reboot after make kernel.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Mon, Mar 04, 2013 at 02:23:28PM +0900, YongHyeon PYUN wrote:
 Ok, here is final diff which combines two things you've tested.
 So revert any changes before applying it.
 Let me know how it goes on your box.

Hmm, apparently something went wrong, as I'm back to 100baseTX after make
kernel and reboot...

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Mon, Mar 04, 2013 at 03:29:44PM +0900, YongHyeon PYUN wrote:
 On Mon, Mar 04, 2013 at 05:59:48AM +, Alexey Dokuchaev wrote:
  On Mon, Mar 04, 2013 at 02:23:28PM +0900, YongHyeon PYUN wrote:
   Ok, here is final diff which combines two things you've tested.
   So revert any changes before applying it.
   Let me know how it goes on your box.
  
  Hmm, apparently something went wrong, as I'm back to 100baseTX after make
  kernel and reboot...
 
 Hmm, updated diff again.

Better this time, I'm having 1000baseT again! :-)

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Thu, Feb 21, 2013 at 05:33:35PM +0900, YongHyeon PYUN wrote:
 On Wed, Feb 20, 2013 at 06:08:53AM +, Alexey Dokuchaev wrote:
  $ dmesg | egrep ale\|atphy
  ale0: Atheros AR8121/AR8113/AR8114 PCIe Ethernet port 0xcc00-0xcc7f mem 
  0xfe9c-0xfe9f irq 17 at device 0.0 on pci2
  ale0: 960 Tx FIFO, 1024 Rx FIFO
  ale0: Using 1 MSI messages.
  ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode.
  miibus0: MII bus on ale0
  atphy0: Atheros F1 10/100/1000 PHY PHY 0 on miibus0
  atphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
  1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
  
  $ devinfo -rv | grep atphy
  atphy0 pnpinfo oui=0xc82e model=0x1 rev=0x9 at phyno=0
 
 Hmm, it's still not clear whether the controller is Gigabit or not.
 Could you try attached patch and let me the output?

ale_flags = 0x0040

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Fri, Feb 22, 2013 at 10:13:08AM +0900, YongHyeon PYUN wrote:
 On Thu, Feb 21, 2013 at 12:43:44PM +, Alexey Dokuchaev wrote:
  ale_flags = 0x0040
 
 Thanks for the info. Indeed, your controller is AR8121 Gigabit
 etherent(L1E). I guess the PHY initialization is not complete.
 Would you try attached patch?

Thanks for the patch.  Unfortunately, it's still 100baseTX full-duplex
after driver reload.  Even tried delaying for 3000, no difference. :(

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

Hi there,

I've recently put back online one of my home servers, updated to the latest
-CURRENT code.  All went fine, but one thing bothers me.  This box bears
Asus P5Q Pro mobo, with the following onboard NIC:

ale0@pci0:2:0:0:class=0x02 card=0x82261043 chip=0x10261969
rev=0xb0 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR8121/AR8113/AR8114 Gigabit or Fast Ethernet'
class  = network
subclass   = ethernet

According the the specs, it should be GigE.  In fact, when plugged into a
capable switch, it displays green (gig) status (same on the switch), but
once being initialized by the kernel, it downgrades to yellowish 100mbps
(real speeds agree).

I'm not sure why it happens; maybe it's somehow related to a handful of
those ale0: link state changed to DOWN/UP flip-flops I see in dmesg(8),
before it can finally obtain DHCP lease?

I remember these adapters had problems in the past, like infamous Corrupted
MAC on input disconnect messages, but I don't recall that I could not use
it in GigE mode.  Anything I can do about it?  Googling did not help much:
most reports date back to ca. 2009, and apparently were ironed out in later
revisions (e.g. selectively disabling checksum offloading).  Thanks,

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ale(4) cannot negotiate as GigE

[Alexey Dokuchaev]

On Wed, Feb 20, 2013 at 01:37:39PM +0900, YongHyeon PYUN wrote:
 On Tue, Feb 19, 2013 at 08:23:02AM +, Alexey Dokuchaev wrote:
  ale0@pci0:2:0:0:class=0x02 card=0x82261043 chip=0x10261969
  rev=0xb0 hdr=0x00
  vendor = 'Atheros Communications Inc.'
  device = 'AR8121/AR8113/AR8114 Gigabit or Fast Ethernet'
  class  = network
  subclass   = ethernet
  
  According the the specs, it should be GigE. [...]
 
 There is a fast etherenet version(L2E) so I'm not sure what you
 have. Could you show me dmesg output(ale(4)  atphy(4) only) and
 devinfo -rv | grep atphy?

$ dmesg | egrep ale\|atphy
ale0: Atheros AR8121/AR8113/AR8114 PCIe Ethernet port 0xcc00-0xcc7f mem 
0xfe9c-0xfe9f irq 17 at device 0.0 on pci2
ale0: 960 Tx FIFO, 1024 Rx FIFO
ale0: Using 1 MSI messages.
ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode.
miibus0: MII bus on ale0
atphy0: Atheros F1 10/100/1000 PHY PHY 0 on miibus0
atphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 
1000baseT-FDX-master, auto, auto-flow

$ devinfo -rv | grep atphy
atphy0 pnpinfo oui=0xc82e model=0x1 rev=0x9 at phyno=0

  I'm not sure why it happens; maybe it's somehow related to a handful of
  those ale0: link state changed to DOWN/UP flip-flops I see in dmesg(8),
  before it can finally obtain DHCP lease?
 
 That's normal when you initiate auto-negotiation with dhclient.

Yes, I've already seen your lengthy explanation [1], thanks!

  I remember these adapters had problems in the past, like infamous
  Corrupted MAC on input disconnect messages, but I don't recall that I
  could not use it in GigE mode. [...]
 
 If you still see the Corrupted MAC on input message, let me know.

No, those are long gone now (hopefully; at least I haven't seen them for a
while).

./danfe

[1] http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020662.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Loading uart module fails

[Alexey Dokuchaev]

On Fri, Feb 24, 2012 at 12:22:36PM -0500, John Baldwin wrote:
 Try this for fixing the panic.  New-bus was not clearing the description
 if a device's attach routine failed.

Thanks, this patch indeed fixes the panic.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Loading uart module fails

[Alexey Dokuchaev]

On Thu, Feb 23, 2012 at 08:28:47AM -0500, John Baldwin wrote:
 Hmm, can you see what 'dev-nameunit' is?  Maybe just do 'p *dev' actually
 and reply with that.

(kgdb) p *dev
$1 = {ops = 0xc50de000, link = {tqe_next = 0xc5271380, tqe_prev =
0xc5271184},
  devlink = {tqe_next = 0xc5271380, tqe_prev = 0xc527118c},
  parent = 0xc51fca80, children = {tqh_first = 0x0, tqh_last = 0xc5271318},
  driver = 0x0, devclass = 0xc5270a40, unit = 0,
  nameunit = 0xc5006a00 uart0,
  desc = 0xc5511205 Address 0xc5511205 out of bounds, busy = 0,
  state = DS_NOTPRESENT, devflags = 0, flags = 35, order = 30,
  ivars = 0xc5270d00, softc = 0x0, sysctl_ctx = {tqh_first = 0x0,
tqh_last = 0x0}, sysctl_tree = 0x0}

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Loading uart module fails

[Alexey Dokuchaev]

On Wed, Jan 19, 2011 at 08:14:19AM -0500, John Baldwin wrote:
 On Wednesday, January 19, 2011 5:08:10 am Bruce Cran wrote:
  On Tue, 18 Jan 2011 11:25:38 -0500
  John Baldwin j...@freebsd.org wrote:
  
   Oh, the uart[01] devices already exist.  I suspect if you removed the
   hints from /boot/device.hints and then kldloaded uart you would be
   ok.  I think this is an old bug that might also be in 8.x.
  
  I'm running -CURRENT from a couple of weeks ago so it if it's an old
  bug it apparently hasn't been fixed yet.
 
 Yes, I don't think it is fixed, and I think 8.x is likely broken in this 
 regard as well.  Can you verify that removing the hints fixes the issue?

Same thing here, default uart settings in /boot/device.hints prevent the
module from loading correctly.  Moreover, unloading it and then doing
devinfo -rv panics my 8.3-PRERELEASE laptop:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xc5511205
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc05783ad
stack pointer   = 0x28:0xe789c994
frame pointer   = 0x28:0xe789c99c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2522 (devinfo)

(kgdb) bt
...
#10 0xc05783ad in strlcpy (dst=0xe789c9d8 ,
src=0xc5511205 Address 0xc5511205 out of bounds, siz=32)
at /usr/src/sys/libkern/strlcpy.c:54
#11 0xc050b1df in sysctl_devices (oidp=0xc06f4880, arg1=0xe789cc04, arg2=2,
req=0xe789cb8c) at /usr/src/sys/kern/subr_bus.c:4575
#12 0xc04efb23 in sysctl_root (oidp=Variable oidp is not available.
) at /usr/src/sys/kern/kern_sysctl.c:1455
#13 0xc04efdc2 in userland_sysctl (td=0xc5d6c5c0, name=0xe789cbf8,
namelen=5,
old=0xbfbfea9c, oldlenp=0xbfbfea94, inkernel=0, new=0x0, newlen=0,
retval=0xe789cc58, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1565
#14 0xc04f014a in __sysctl (td=0xc5d6c5c0, uap=0xe789ccec)
...
(kgdb) f 11
#11 0xc050b1df in sysctl_devices (oidp=0xc06f4880, arg1=0xe789cc04, arg2=2,
req=0xe789cb8c) at /usr/src/sys/kern/subr_bus.c:4575
4575strlcpy(udev.dv_desc, dev-desc, sizeof(udev.dv_desc));
(kgdb) l
4570udev.dv_handle = (uintptr_t)dev;
4571udev.dv_parent = (uintptr_t)dev-parent;
4572if (dev-nameunit != NULL)
4573strlcpy(udev.dv_name, dev-nameunit, 
sizeof(udev.dv_name));
4574if (dev-desc != NULL)
4575strlcpy(udev.dv_desc, dev-desc, sizeof(udev.dv_desc));
4576if (dev-driver != NULL  dev-driver-name != NULL)
4577strlcpy(udev.dv_drivername, dev-driver-name,
4578sizeof(udev.dv_drivername));
4579bus_child_pnpinfo_str(dev, udev.dv_pnpinfo, 
sizeof(udev.dv_pnpinfo));

HTH, feel free to ask for more...

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x11/nvidia-driver / Compilation has failed

[Alexey Dokuchaev]

On Thu, Oct 06, 2011 at 01:35:14AM +, Nali Toja wrote:
 Ali Mashtizadeh mashtiza...@gmail.com writes:
  2011/8/31 Alexey Dokuchaev da...@freebsd.org:
  On Mon, Aug 29, 2011 at 02:59:48PM +0200, Olivier Smedts wrote:
  2011/8/29 ken k...@tydfam.jp:
   Could I test your patch for nvidia-driver, too?
   I cannot find your patch in this mail.
 
  I took the patch in :
  http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html
 
  And it worked for me.
 
  Should be fixed in the port itself now (also updated to 280.13).
 
  Is there any reason I should still be hitting this bug when building
  on 9-STABLE? With Linux compatibility disabled I can build the driver,
  but the kernel refuses to load it saying it's incompatible with my
  kernel version.
 
 Only if you're using 285.05.09 with the port. And it'd affect both
 /stable/9 and /head users.
 
   // from src/nv-freebsd.h:
   #if __FreeBSD_version = 900041
   #include sys/capability.h
   #else
   #define fget(td, fd, cap, fp) fget(td, fd, fp)
   #endif
 
 Can you commit below tiny change? It should make testing the new version a
 bit easier for people who are impatient to wait for the next port update.
 
 That version also includes tunable support similar to ports/156386.

Port was updated to serve the most recent release from NVidia, 285.05.09.
Please test and report of any issues.

Thanks,

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x11/nvidia-driver / Compilation has failed

[Alexey Dokuchaev]

On Mon, Aug 29, 2011 at 02:59:48PM +0200, Olivier Smedts wrote:
 2011/8/29 ken k...@tydfam.jp:
   Could I test your patch for nvidia-driver, too?
   I cannot find your patch in this mail.
 
 I took the patch in :
 http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html
 
 And it worked for me.

Should be fixed in the port itself now (also updated to 280.13).

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Is nvidia-driver 256.53 expected to work on -current?

[Alexey Dokuchaev]

On Sun, Oct 17, 2010 at 11:32:00PM +, Alexander Best wrote:
 i'm running 256.52 on HEAD (amd64) without any issues. the 260.X drivers all
 freze my computer when i exit X.
 
 it's quite easy to work around the isse that the nvidia drivers fail to 
 compile
 on HEAD. simply change the line #if __FreeBSD_version = 90 in
 src/nv-freebsd.h to #if __FreeBSD_version = 100.

Or install from ports, which also patch the driver to support -CURRENT.

./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [patch] FreeBSD Port: nvidia-driver-1.0.4365

[Alexey Dokuchaev]

On Wed, Sep 03, 2003 at 03:08:30PM +0400, Sergey A. Osokin wrote:
 On Wed, Sep 03, 2003 at 01:01:55PM +0200, Harald Schmalzbauer wrote:
  
  with today's -current the nvidia port failed to compile.
  With a bit luck I found that there seems to be a misstype in the 
  src/nvidia_sysctl.c. I'm no programmer so I don't know if this has changed 
  recently or if it has always been an error but the old gcc didn't complain (I 
  think the former)
  
  To make it short: I created patch.aa in files and it works fine with today's 
  -current.
  
  I don't have any -stable so if it is only an 5.x issue there someone shuld 
  correct the port to make the patch OS-dependent.
  
  Please commit the patch.
 
 Hmm, where is the patch?
 danfe: please review the patch :-)

I'll surely do; right now there are several patches sitting in my queue
pending for review.  Just take some patience, I'll take care of all
issues during next couple of days.

./danfe

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [patch] FreeBSD Port: nvidia-driver-1.0.4365

[Alexey Dokuchaev]

On Wed, Sep 03, 2003 at 12:14:52PM +0100, Matt wrote:
 Sergey A. Osokin wrote:
 
 On Wed, Sep 03, 2003 at 01:01:55PM +0200, Harald Schmalzbauer wrote:
 
 with today's -current the nvidia port failed to compile.
 With a bit luck I found that there seems to be a misstype in the 
 src/nvidia_sysctl.c. I'm no programmer so I don't know if this has 
 changed recently or if it has always been an error but the old gcc didn't 
 complain (I think the former)
 
 To make it short: I created patch.aa in files and it works fine with 
 today's -current.
 
 I don't have any -stable so if it is only an 5.x issue there someone 
 shuld correct the port to make the patch OS-dependent.
 
 Please commit the patch.
 
 
 Hmm, where is the patch?
 danfe: please review the patch :-)
 
 
 A constant in one of the kernel header file seems to have been renamed. 
 Change PCIR_HEADERTYPE to PCIR_HDRTYPE in nvidia_sysctl.c and all will 
 be well.
 
 There is a pr for this which is ports/56157.

I'm aware of this.  However, people seem to be having other problems
with nvidia-driver on -current; they have sent patches for those as
well.  I'll review all of patches and deal with issues during very next
day or two.

./danfe

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ** HEADS UP ** changes to /usr/lib/crt*.o

[Alexey Dokuchaev]

Hello!

On Sat, 28 Oct 2000, David O'Brien wrote:

 I am switching us from using or native crt{begin,end}.c to GCC's
 crtstuff.c in the building of /usr/lib/crt{begin,end}.o.
 
 Testing a new world with this change not show any problems.
 HOWEVER, I have only done cursory testing with already installed ports
 (shared binaries and libs) and our current set of Packages.  (especially
 since ``pkg_add -r'' is broken and no one will take responsibility for
 it)
 
 If you find any problems, I'd like to know ASAP as I hope to MFC this for
 4.2-RELEASE.

What caused such a change?  I mean, what the purpose of it, what set of
problems should it (probably?) solve?

Thanks.

--
WADR,
DAN Fe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new rc.network6 and rc.firewall6

[Alexey Dokuchaev]

On Tue, 24 Oct 2000, Terry Lambert wrote:

  Well, would not be this stepping aside from BSD startup sequence, which we
  all know and love?  Having dozens of small files instead of pair of
  big ones always frustrates me when I have to work with linux.
 
 Install a binary package that needs to be started when the
 system is booted and needs to be shutdown when the system
 is shutdown.

That's what /usr/local/etc/rc.d/ was for for years!  Put all your
application-specific scripts there, but leave base-system monotilithic
startup alone :-)

--
WBR,
DAN Fe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new rc.network6 and rc.firewall6

[Alexey Dokuchaev]

 Well, we *already* have over a dozen /etc/rc.* files on -current.  And
 we *don't* have the advantage of a consistent interface to control all
 the functions in /etc/rc. If you break things up, then if you need to
 restart the mail server, just go "/etc/rc.d/sendmail restart". dhcpd?
 "/etc/rc.d/sendmail/dhcpd restart". Etc.

Actually, the point is that writing TONS of scripts to get your work
done (that's what Linux world does) always pissed me off.  You have a
shell script that is in fact a wrapper for another shell script, and like
this in turn it goes on and on and on again.  Icky! :-)  I don't like
how Linux smells.

Why can't I simply write kill -1 `cat /var/run/sendmail.pid`?  I don't
consider it being sagnificantly longer than writing /etc/rc.d/sendmail
restart.  After all, if your typing speed is good enough, it doesn't
really matter whether you type in 30 or 20 chars.

--
JMHO,
DAN Fe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new rc.network6 and rc.firewall6

[Alexey Dokuchaev]

On Tue, 24 Oct 2000, David O'Brien wrote:

 On Tue, Oct 24, 2000 at 04:23:40PM +0700, Alexey Dokuchaev wrote:
  Why can't I simply write kill -1 `cat /var/run/sendmail.pid`?
 
 What about deamons that don't understand `kill -HUP'?  Sendmail didn't
 until very reciently.  ``/etc/rc.d/some-deamon restart'' does the right
 thing reguardless how involved that might be.

Though I see your point, actually, many UNIX books, including some pretty
old ones, refer to sending HUP signal as standard way of
restarting/resetting daemons.


./danfe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new rc.network6 and rc.firewall6

[Alexey Dokuchaev]

On Sun, 22 Oct 2000, David O'Brien wrote:

 On Sat, Oct 21, 2000 at 11:05:37AM -0700, Jordan Hubbard wrote:
   I wish to update rc.network6 and introduce rc.firewall6.
  
  H.  I must confess that I see /etc as getting rather cluttered
  these days.  Is there no way to perhaps collapse some of the most
  related functionality into single files and start passing arguments
  or something?  Just a comment..
 
 At BSDcon Luke M showed me what the NetBSD 1.5 rc files look like.
 They've moved them all to /etc/rc.d/ and made them very granular (as
 SVR4, but w/o leading numbers in the filenames).  The NetBSD
 implementation also solved all the issues people have brought up in the
 past -- dependacies, etc...
 
 We should just move to using their rc code.

Well, would not be this stepping aside from BSD startup sequence, which we
all know and love?  Having dozens of small files instead of pair of
big ones always frustrates me when I have to work with linux.

--
With all due respect,
DAN Fe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new rc.network6 and rc.firewall6

[Alexey Dokuchaev]

On Mon, 23 Oct 2000, Garrett Rooney wrote:

 On Tue, Oct 24, 2000 at 04:49:40AM +0700, Alexey Dokuchaev wrote:
  Well, would not be this stepping aside from BSD startup sequence, which we
  all know and love?  Having dozens of small files instead of pair of
  big ones always frustrates me when I have to work with linux.
 
 well, it's a single directory full of small files, as opposed to a bunch
 of directories, each with its own collection of files, with ugly numbers
 at the beginning of each one.  that's better in my book.
 
 and at the very least, with a number of smaller files, assuming they're
 named well, you can find what you're looking for faster, and not have
 to dig though the one monolithic script to find out how sometihng is
 working.

Still, it would be better if I could choose between "classical" and "new"
startup layout, say, somewhere at the installation stage.

--
With best and kind regards,
DAN Fe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new rc.network6 and rc.firewall6

[Alexey Dokuchaev]

On Mon, 23 Oct 2000, Brandon D. Valentine wrote:

 On Tue, 24 Oct 2000, Alexey Dokuchaev wrote:
 
 Still, it would be better if I could choose between "classical" and "new"
 startup layout, say, somewhere at the installation stage.
 
 Well if you're that stubborn there's no reason that the "new" layout
 could not be compiled into a monolithic script.  In fact perhaps you
 could be the one to step forward and write the code to compile that
 script.  ;-)

That's an idea!  Gotta co recent -CURRENT right now!

--
./danfe




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message