Re: Cannot find announcement that min supported i386 CPU is now i686

[Christoph Moench-Tegeder]

## Warner Losh (i...@bsdimp.com):

> The default is to compile for i686.

That's really not obvious from the obvious documentation.
Both Hardware Notes and the Handbook ("2.2. Minimum Hardware Requirements")
state support for 486 and up, but there's no hint that you had to
roll you own distribution set for anything below 686. Also, GENERIC's
conf on i386 has flags I486_CPU and up.

Regards,
Christoph

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

Re: Cannot find announcement that min supported i386 CPU is now i686

[Christoph Moench-Tegeder]

## Charles Lecklider via freebsd-stable (freebsd-stable@freebsd.org):

> As you can see from objdump below, clearly a decision was made that 11.4
> would no longer support anything before a i686.

Given that the hardware notes
https://www.freebsd.org/releases/11.4R/hardware.html#proc-i386
explicitely claim 80486 compatibility, I'd guess this was not a
consciuous decision but a blunder which wasn't caught (perhaps as
hardware of that vintage is getting rare these days. That box
must be old enough to buy alcohol by now?).

Regards,
Christoph

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

Re: session mgmt: does POSIX indeed prohibit NOOP execution?

[Christoph Moench-Tegeder]

## Peter (pe...@citylink.dinoex.sub.org):

> > Not much room to argue?
> 
> Why that? This is not about laws you have to follow blindly whether
> you understand them or not, this is all about an Outcome - a working
> machine that should properly function.

"Not much to argue about what behaviour is required by the standard".
The standard could have been written to require different behaviour
and most probably still make sense, but it wasn't; but at least it's
unambiguous. After that, the discussion is rather... philosophical.

Regards,
Christoph

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

Re: Light GeoIP support dropped?

[Christoph Moench-Tegeder]

## Alexander Koeppe (forma...@online.de):

> since I've upgraded to FreeBSD 12, I don't find a package providing
> the lightweight geoip database API incl. GeoIP.h and libGeoIP.so.

The so-called "legacy" database format used by libGeoIP has been
discontinued by MaxMind, and is only available for paying customers:
https://blog.maxmind.com/2018/01/02/discontinuation-of-the-geolite-legacy-databases/

For that reason, net/GeoIP has been removed quite some time ago:
https://svnweb.freebsd.org/ports?view=revision=493168

And the free (as in no payment required) GeoLite2 databases have seen some
licensing/handling changes, too:
https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/

Regards,
Christoph

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

Re: session mgmt: does POSIX indeed prohibit NOOP execution?

[Christoph Moench-Tegeder]

## Peter (pe...@citylink.dinoex.sub.org):

> When a program is invoked via /usr/sbin/daemon, it should already be
> session leader AND group leader, and then the above code WOULD be a
> NOOP, unless POSIX would require the setpgid() to fail and thereby the
> program to abort - which, btw, is NOT a NOOP :(

https://pubs.opengroup.org/onlinepubs/9699919799/
 "The setpgid() function shall fail if: [...] The process indicated by the
  pid argument is a session leader."

Not much room to argue?

Regards,
Christoph

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

Re: screen crashes on 11.3-STABLE

[Christoph Moench-Tegeder]

## Gareth de Vaux (sta...@lordcow.org):

> $ screen
> 
> [screen caught signal 11. (core dumped)]

Try this:
https://svnweb.freebsd.org/ports?view=revision=date=515868

If that doesn't help, we'll need at least a backtrace.

Regards,
Christoph

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

Re: screen crashes on 11.3-STABLE

[Christoph Moench-Tegeder]

That already had been reported here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241538 by Marcin.

My analysis: screen dumps core on terminals with TERM=xterm* or
TERM=rxvt* if they don't advertise Km ("key_mouse") capability
via termcap. A workaround is to set TERM to xterm-vt220 (which has
Km) (you could just set resource XTerm*termName to "xterm-vt220"
or use command line "xterm -tn xterm-vt220").
Patch at the PR.

Regards,
Christoph

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

Re: screen crashes on 11.3-STABLE

[Christoph Moench-Tegeder]

## Gareth de Vaux (sta...@lordcow.org):

> (there's no core dump).

ulimit -c

> This happens as a user or root, however screen runs fine on the host.

It coredumps here, too (on a 12.0-RELEASE) - I'm looking at it, there's
something fishy going on with the termcap data (the whole thing is
#define hell, and I never found termcap to be an easy-going data format,
so don't expectresults too soon).

Regards,
Christoph

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

Re: CFT: FreeBSD Package Base

[Christoph Moench-Tegeder]

## Christoph Moench-Tegeder (c...@burggraben.net):

> in a few entries without any detail. The Handbook (chapter 25.3) only
 ^ 23.5, of course.

Regards,
Christoph

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

Re: CFT: FreeBSD Package Base

[Christoph Moench-Tegeder]

## Lars Engels (lars.eng...@0x20.net):

> > What are the plans to get rid of the hellscape known as “mergemaster”?
> > Is there anything exciting and new there either in base or any of the
> > ixSystems projects?
> 
> There's /usr/sbin/etcupdate in base.

Unfortunately, the official documentation on upgrades does not mention
etcupdate at all. The release notes point to freebsd-update for binary
upgrades, and to /usr/src/UPDATING for source-based upgrades. UPDATING
only documents the mergemaster procedure; etcupdate is only mentioned
in a few entries without any detail. The Handbook (chapter 25.3) only
documents mergemaster. Even after speed-reading etcupdate(8) I'm not
sure how the two-step invocation of mergemaster has to be mapped to
etcupdate - I feel I'd be inventing my own procedure here (and, of
course, if it breaks I get to keep all the pieces).

This situation should be improved. Given that etcupdate is in all
supported releases, we can even update UPDATING and the Handbook.
So, does anyone have a pointer to the official procedure?

Regards,
Christoph

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

Re: ltmain.sh not found

[Christoph Moench-Tegeder]

## Willem Offermans (wil...@offermans.rompen.nl):

> Unfortunately it is probably not gawk in my case, which causes trouble.
> However, your response indicates that the problem will be solved after I
> have updated/reinstalled the guilty one.

There's sysutils/bsdadminscripts, which provides pkg_libchk: that's a
tool for checking if any port misses a shared library. It has been
rather helpful back when I was using portupgrade...

Regards,
Christoph

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

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Christoph Moench-Tegeder]

## Alexey Dokuchaev (da...@freebsd.org):

> > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> 
> Holy shit!  OK I guess I can understand removing 10 (I personally haven't
> seen one in a very long time) but 100 are omnipresent and most of my NICs
> are in fact 100.

Don't panic - they're talking about removing the 100 MBps NICS, not
the 100 GBps NICs.

Jokes aside - obviously there are very different populations of NICS.
Here, the only 100MBps interface is in the IP phone, and I would guess
that even most consumer hardware comes with a GBps interface on board
(heck, even RPis have a GBit interface, even if can't use more than 30%
of it's bandwith). Checking with a hardware-dealer: very few NICs in
their catalog are 100MBps, most are gigabit-grade.
I would have expected that things look different in the embedded world...
On the other hand, some data centers I know routinely use 10GBps, and
1 GBps is considered "legacy" there.

So, perceptions are very different... let's keep this rational and
make a list of cards still in use.

Regards,
Christoph

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

Re: Unable to boot memstick on APU2

[Christoph Moench-Tegeder]

## Stefan Bethke (s...@lassitu.de):

> I'm stumped by a weird error: loader loads the kernel, and the kernel
> probes the USB stick successfully, but da0 never shows up. I’ve tried
> with FreeBSD-11.1-RELEASE-amd64-memstick.img and
> FreeBSD-11.2-RELEASE-amd64-memstick.img.

I've had this happen with a rather old USB stick (back from the days
when 8GB was considered "huge", these days it's my boot stick...)
Letting the machine with the stick inserted sit a little on the
boot prompt did the trick for me. A newer stick "just worked fine",
so I wrote that off as "aging flash".

Regards,
Christoph

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

Re: ldconfig(8) oddity on 11.2-BETA3?

[Christoph Moench-Tegeder]

## Trond Endrestøl (trond.endres...@fagskolen.gjovik.no):

> The latest commits to the synth repo forces synth to copy /etc/rc.subr 
> and /etc/rc.d/ldconfig into each chroot.

Aha!
Yes, looking at 
https://github.com/jrmarino/synth/commit/465ab8d2133a9d1e15cbf46337a1a809f828495d
I think the issue is solved: synth in it's current incarnation from our
ports tree does not handle ports with USE_LDCONFIG in a way the ports
tree expects it.
Omitting rc.subr and rc.d from the ports build chroots may have it's
merits - but I wonder what else may break when using an incomplete base
system? Would using a pristine system with an empty rc.conf improve
matters?

Cc'ing Eric as the synth maintainer (as in port maintainer) - perhaps
it's possible to backport that commit until the next release? (I'm
not only "not a synth user", but also "rather inept with Ada").

Regards,
Christoph

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

Re: ldconfig(8) oddity on 11.2-BETA3?

[Christoph Moench-Tegeder]

There's discussion about nss-related linking failures in other ports:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228540
and the common denominator in there cases is synth (there are no problems
in poudriere). Over there, Trond had the idea that this might be related
to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228046 (commit
ports r469956) - has synth some special "optimization" for handling
ldconfig? (I'm not a synth user myself...)

Regards,
Christoph

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

Re: Userland PPP on ADSL

[Christoph Moench-Tegeder]

## O'Connor, Daniel (dar...@dons.net.au):

> This worked well for many moons but a while ago I found issues with the
> inbuilt PPP and ended up switching to mpd5 which has so far worked flawlessly.

I did switch from ppp to mpd5 quite a while ago, for performance reasons,
but beyond that, I didn't have any problems (if my notes are corrent,
that was on 10.0 or so).

> May  8 12:27:53 portero ppp[76165]: tun0: LCP: deflink: SendEchoReply(114) 
> state = Opened
> May  8 12:27:54 portero ppp[76165]: tun0: LCP: deflink: SendEchoRequest(38) 
> state = Opened
> May  8 12:27:54 portero ppp[76165]: tun0: LCP: deflink: RecvEchoReply(38) 
> state = Opened

That looks like LCP was still up? Have you tried turning the logging up?

Regards,
Christoph

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

Panic with Dual-Band WLANs on ath

[Christoph Moench-Tegeder]

Hi,

I've got a fairly reproducable kernel panic when trying to configure
two wlan devices on one ath card.

The basics: FreeBSD 11.1-RELEASE-p8 amd64

ath0@pci0:4:0:0:class=0x028000 card=0x3099168c chip=0x002a168c rev=0x01 
hdr=0x00
vendor = 'Qualcomm Atheros'
device = 'AR928X Wireless Network Adapter (PCI-Express)'
class  = network

(This is a Compex WLE200NX miniPCIe card in a PCEngines APU2:
https://www.compex.com.sg/product/wle200nx/ for specifications).

I want to create two access points on this device: one in 5Ghz and
one in 2.4GHz (5GHz gives good bandwidth, but cannot radio it's way
out of a cardboard box, so rather less-than-good coverage - and I
still have hardware which is not 5GHz capable; 2.4GHz has less bandwidth
but much better coverage (this is also true for my neighbours' networks,
so I've got quite some interference here)).

The naive approach was setting wlans_ath0="wlan0 wlan1" in rc.conf,
and configuring wlan0 and wlan1 in parallel (hostap and stuff).

Unfortunately, after short time (30 seconds to 5 minutes), I get a
kernel panic:

ath0: ath_rate_tx_complete: ts_rate=11 ts_finaltsi=0, final_rix=4
ath0: bad series0 hwrate 0xb, tries 7 ts_status 0x1

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x8164aefc
stack pointer   = 0x28:0xfe011bbfe8a0
frame pointer   = 0x28:0xfe011bbfe8f0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (irq40: ath0)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80585997 at kdb_backtrace+0x67
#1 0x80543a76 at vpanic+0x186
#2 0x805438e3 at panic+0x43
#3 0x8087c642 at trap_fatal+0x322
#4 0x8087c69b at trap_pfault+0x4b
#5 0x8087beba at trap+0x2ca
#6 0x8085ed20 at calltrap+0x8
#7 0x814e25c5 at ath_beacon_generate+0x45
#8 0x814e244b at ath_beacon_proc+0x22b
#9 0x814d066d at ath_intr+0x24d
#10 0x8050a0bc at intr_event_execute_handlers+0xec
#11 0x8050a3a6 at ithread_loop+0xd6
#12 0x80507715 at fork_exit+0x85
#13 0x8085f9ee at fork_trampoline+0xe

I can provide core dumps on request.

Is this a case of "don't do that"? In that case, an error message instead
of a kernel panic would be nice - it took me several roundtrips to
disable the wlans again, the box sometimes paniced faster than I could
fix my configuration.

For the time being I'm back to 2.4GHz only (which worked for several
days, as did 5GHz only - only the combination got my box panicing).

Any ideas?

Regards,
Christoph

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

Re: mc, xterm-clear, Ctrl-O and Home/End dilemma

[Christoph Moench-Tegeder]

## Eugene M. Zheganin (e...@norma.perm.ru):

> I use my FreeBSD desktop at work and from home wvia putty, so I really 
> want to solve this without learning keays each time (and it seems like 
> they aren't save on "Save setup".

Putty has quite a bunch of options to configure terminal behaviour,
and you can make it send different terminal identifiers (from your
description, I'm not sure where you switched terminal modes).
Maybe fiddling with putty or the terminal identifier will help?
Termcap even has a putty entry...

I'm not a putty user myself (I prefer xterm and openssh), so I can
only guess.

Regards,
Christoph

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

Re: VLAN problem on some em(4) cards

[Christoph Moench-Tegeder]

After repeating the "toggle all the flags" dance two more times and
a reboot later, vlans suddenly _do_ work on those interfaces, with
default flags. I have no idea what was messed up before - but now
the configuration survives reboot.
Sorry for all the panic.

Happy networking,
Christoph

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

Re: VLAN problem on some em(4) cards

[Christoph Moench-Tegeder]

## Kurt Jaeger (li...@opsec.eu):

> Have you tried fiddeling with the flags ?
> 
> options=4219b
> 
> examples:
> 
> ifconfig em0 -rxcsum -txcsum -wol
> ifconfig em0 -vlanmtu -vlanhwtag

I hadn't touched WOL, but almost everything else.
I also tried sysctl net.link.vlan.soft_pad (no effect, either).

> sysctl -a | grep dev.em | grep desc

dev.em.0.interrupts.rx_desc_min_thresh: 0
dev.em.0.queue_tx_0.no_desc_avail: 0
dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.6.1-k

This is the same for the non-working (82574L) and working (82579LM)
interfaces - that's why I though lspci would be more interesting.

Regards,
Christoph

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

Re: VLAN problem on some em(4) cards

[Christoph Moench-Tegeder]

## Ryan Stone (ryst...@gmail.com):

> tcpdump on em0 will show the vlan-tagged packets if everything is working
> correctly.  The fact that they are not showing up is a sign that something
> is not working correctly (or that your tcpdump filter isn't account for the
> vlan tag)

They do on the 82579LM (working) interface, but not on the 82574L
(non-working) interface. As I was working in a test setup, I
just tcpdumped "everything" (tcpdump -nevi em0).

Regards,
Christoph

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

VLAN problem on some em(4) cards

[Christoph Moench-Tegeder]

Hi,
while replacing a switch I ran into a problem with using 802.1q VLANs
(vlan(4)) on a em(4) card - that is, I could not get the card to work
with VLANs.
Details:
Software is FreeBSD 10.3-RELEASE i386 with a custom kernel (but has
em(4) and vlan(4) compiled in (not as a module)).
Hardware is a Soekris net6501-70, the interface in question is (pciconf)
em2@pci0:10:0:0:class=0x02 card=0x8086 chip=0x10d38086 rev=0x00
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
class  = network
subclass   = ethernet

The setup I wanted to create was a "router on a stick", that is having
3 (for starters) tagged VLANs on that one link between router and
switch. I was not able to get any packet through to the switch,
while tcpdump shows the packets on the vlan interface (but not on
the underlying em interface - I understand that this could be the
result of hardware vlan processing). I could not ping any host beyond
the switch nor the switch's management interface itself, I did not
even receive ARP replies.
I tried both manual creation of the vlan devices and the rc.conf/
netif mechanism - with the very same results ("doesn't work").
Experimenting with the vlanhw* flags on the em interface did not
result in any change.

To make sure it's not the switch (or my own mistake), I took another
host with an em interface - this time, it was a
em0@pci0:0:25:0:class=0x02 card=0x21ce17aa chip=0x15028086 rev=0x04
vendor = 'Intel Corporation'
device = '82579LM Gigabit Network Connection'
class  = network
subclass   = ethernet

(again 10.3-RELEASE, but amd64).
With this interface (connected to the very same switch port) I
had instantaneous success, so I guess the switch is ok and I'm
not totally mistaken in my doings.

Could anybody give a hint on how to further debug this or a pointer
to further reading?

Regards,
Christoph

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

Re: nVidia driver update today: renders X11 unusable

[Christoph Moench-Tegeder]

## O. Hartmann ([EMAIL PROTECTED]):

  Seems you've got an issue between X and firefox3; at least there's
  a note in the firefox3 release notes which desribes similar effects:
  https://bugzilla.mozilla.org/show_bug.cgi?id=411831
  Oh, but by the way, it's not an nvidia/nv issue; I've got the exactly
  same issues with radeonhd... Luckily, I do not depend that much on
  web browsers, let alone firefox3.
 The issue of X with firefox is well known and be aured I'm aware of 
 that. This issue I complained about is with nearly every client I use 
 under X - and that includes Firefox. This 'issue' renders a bunch of 
 FreeBSD boxes around here unusable, only those with non-G80 derived 
 graphics boards seem to be not infected by the problem, but every box 
 with FreeBSD (mostly 7.0/7.1).

Ah, that explains why I'm having only the usual firefox issue,
obviously my laptop's Quadro NVS 140M is not a G80-derived
chip (nautilus, gimp, gnumeric do wirk fine without black bars).
The first mails read as if all nvidia boards were affected.

Regards,
Christoph

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

Re: nVidia driver update today: renders X11 unusable

[Christoph Moench-Tegeder]

## O. Hartmann ([EMAIL PROTECTED]):

 My box at home has an older NV6800GT and I do not have this special 
 issue, but instead I do have another well known issue of box-freezing. 
 This also happens with 'nv'.

Whoa. Guess I'm lucky, as my nvidia chis is working, albeit quite
slowly. My radeonhd-based card at home is way faster, but exhibits
the same black-image-issue with firefox.

Regards,
Christoph

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

Re: nVidia driver update today: renders X11 unusable

[Christoph Moench-Tegeder]

## Volodymyr Kostyrko ([EMAIL PROTECTED]):

  Just upgraded my ports and installed the new xf86-video-nv driver. Well, 
  loggin out works now without crashing the Xorg server, but most fonts 
  now show up as balck bars - unreadable and ugly :-(
 Same for me, just some transparent pictures render transparency as 
 black, good example is reader.google.com. This also isn't new to me, 
 some pictures was shown like this in previous driver versions. I was 
 just a bit unsure who was bad at it.

Seems you've got an issue between X and firefox3; at least there's
a note in the firefox3 release notes which desribes similar effects:
https://bugzilla.mozilla.org/show_bug.cgi?id=411831
Oh, but by the way, it's not an nvidia/nv issue; I've got the exactly
same issues with radeonhd... Luckily, I do not depend that much on
web browsers, let alone firefox3.

Regards,
Christoph

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

Re: Large port updates

[Christoph Moench-Tegeder]

## Ivan Voras ([EMAIL PROTECTED]):

 Is there a best practice for automated updating large number of 
 interdependant ports? I keep my ports tree up-to-date, and sometimes I 
 wish to install applications that depend on a newer version of an 
 existing one, and fail.

portupgrade works in most cases, but...

 My current example is gnome. Recently, whatever I want to install 
 requires gnome2.8 - how to update the giant list of gnome libs  apps? 

Not in this case. Check /usr/ports/UPDATING 20041107:
: Do NOT use portupgrade(1) to update your GNOME 2.6 desktop to 2.8

Gruss,
Christoph

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

Re: Traffic shaping

[Christoph Moench-Tegeder]

## Peter Jeremy ([EMAIL PROTECTED]):

 ipfw/dummynet pipes only handle a single flow direction:  If you
 have something like
   ipfw NUMBER pipe 1 ip from any to any via ifX
 then both incoming and outgoing traffic share the pipe and you are
 limiting the combined uplink and downlink traffic - which probably
 isn't what you want.

Yes, I see.
My last experience with things like this suffered a little from a
slightly underfunctional implementation of bandwidth control (and
using dummynet/FreeBSD was not an option). I only had control
over the outgoing queue on the external interface, so I tried
slowing down slow start by limiting the acks from teh destination
to the source of the transfer based on calculations with packet
sizes and -rates (which seemed to be more than a little unreliable).
[Perhaps I could construct a scenario with some more interfaces,
where limiting the outgoing rates would be easier, but that would
be too far fetched for now].
So my problem in short: How much do I have to limit acks in the
direction with the lower bandwidth in order to control the
usage of the other direction? This is a little away from the
original thread, but I just would like to know (might come in
handy some time and perhaps I can ptimize my old solution
a little with other people's experience).

Regards,
cmt

-- 
Spare Space

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

Re: Traffic shaping

[Christoph Moench-Tegeder]

## Maarten de Vries ([EMAIL PROTECTED]):

 I could do with some hints regarding traffic shaping. My homenetwork is
 hooked up to an assymetrical (1536/256) ADSL line, using a FreeBSD 4.6
 system which provides the usual NAT/Gateway/Firewall services. I'm using
 dummynet to control the amount of bandwidth used by certain hosts on the
 network, which all works fine. However, I still suffer from latency when the
 maximum up- and/or downstream of the line is being utilized. If I understand
 it well, this happens because the buffer in the ADSL modem fills up
 completely at those occasions. Is there anyway to prevent this from
 happening?

Limit the maximum usage of your line to about 90% to 95%. This prevents
usage of the queue in your modem. However, this will not work if
queueing on the remote side is the problem (bulk transfers like downloads
come to mind); you are out of luck if the queue on the remote side is too
long.

Regards,
cmt

-- 
Spare Space

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

Re: Traffic shaping

[Christoph Moench-Tegeder]

## Daniel O'Connor ([EMAIL PROTECTED]):

 Actually, if you limit incoming TCP it will adapt to the correct speed.
 I do this at home without hassle (except the latency in games goes up
 from ~40 to ~100 but it is still acceptable)

How much do you have to limit TCP for the desired effect? I never
tried shaping on asymmetric lines, and the traffic ratio for a
single TCP bulk transfer (1500 (or little less in case of PPPoE,
PPTP, etc.) bytes incoming vs. 40 bytes outgoing) does not match
the up/down-ratio of his line (1:6) by any means.

Regards,
cmt

-- 
Spare Space

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