I've installed FreeBSD 6.0-CURRENT-SNAP005 (i386) on my stand-alone home
computer, which connects to the internet via adsl.
Being no expert, I don't presume to characterize the following
observations as "bugs" (except, perhaps, with regard to tcpdrop), but I
wonder if anyone else has experienced any of the same things.
1. In the past, using FreeBSD 4.9 and 4.10, I connected to my dsl
modem/router using pptpclient. With pptpclient on 6.0, however, I
noticed that download speed from the internet was very slow -- only
about 20 percent of the rate I was accustomed to. A check with top
revealed that pptp was utilizing 85 percent of the CPU. I recall seeing
a lock-order-reversal message on a couple of occasions. (See the log
excerpt below.)
2. I installed mpd to replace pptpclient. Downloading is fast again
and CPU usage is back to normal, but I notice a couple of minor quirks.
The first time after boot that I run my script to bring up the NIC (I
don't bring up the NIC on boot) and to launch mpd, no connection occurs.
On the second try it works, but I get the following message on standard
error: "WARNING: attempt to net_add_domain(netgraph) after
domainfinalize()." The warning is not repeated on subsequent connects.
I assume it is related to the loading of various ng modules.
3. I'm using pf with 6.0. When I kill (-SIGTERM) mpd to disconnect
from the internet, and before I bring down the NIC, the following error
message is returned: "pf_test6: kif == NULL, if_xname ng0." It
appears that pf is bothered by the disappearance of the ng0 interface.
4. After disconnecting from the internet I often have "stuck" tcp4
connections (perhaps due in part to my severe firewall rules). Thinking
to remedy this little annoyance with tcpdrop. I created a perl script
to parse the output of "netstat -n - f inet" and to call tcpdrop for
each inet connection except the NIC-to-modem connection. I've tried
running the script before and (mostly) after killing mpd. Sometimes it
actually works, but most times tcpdrop triggers a kernel panic and auto
reboot. I suspect that the differing results might be related to the
state of the connection(s), or to the number of them. Maybe it's safe
to dub this phenomenon a "bug" in view of the panic and reboot, even if
I'm doing something wrong.
5. I do a lot of work (or at least activity) from the console, and
enjoy the new VESA graphics console features. I compiled VESA and
SC_PIXEL_MODE into the kernel, and it works fine with my Radeon 7000
card -- except that the screen blanker does not blank the screen. The
cursor disappears, but otherwise the display persists. I suppose this
may be a necessary consequence of using graphics mode.
6. Having used the vnconfig utility and the vncrypt port in FreeBSD 4.x
to create file-backed encrypted devices, I applied an analogous
procedure using mdconfig and gbde in 6.0. Although it works, processing
of the encrypted file system seems quite sluggish with gbde compared to
vncrypt. (I do realize that encryption entails overhead, and that gbde
seems designed primarily for use with disks rather than files.)
By the way, informationally, the recent zlib patch for FreeBSD 5.x would
appear to work on 6.0. I actually did the one-line edit to inftrees.c
manually rather than running patch, but it was the same line with the
same line number employed by the patch. I also ran find-zlib, which
indicates that zlib 1.2.2 is statically linked in a few system files --
eg., libstand.a, pxeboot, and loader (shouldn't do much harm there!).
It's also statically linked, I think, in Opera 8.01, which could be
dangerous.
Log excerpt: one of the LORs with pptpclient --
Jul 3 23:32:55 localhost pptp[709]: anon
log[ctrlp_disp:pptp_ctrl.c:880]: Outgoing call established (call ID 0,
peer's call ID
0).
Jul 3 23:32:58 localhost kernel: lock order reversal
Jul 3 23:32:58 localhost kernel: 1st 0xc1b34270 rtentry (rtentry) @
/usr/src/sys/net/rtsock.c:434
Jul 3 23:32:58 localhost kernel: 2nd 0xc19ba77c radix node head (radix
node head) @ /usr/src/sys/net/route.c:148
Jul 3 23:32:58 localhost kernel: KDB: stack backtrace:
Jul 3 23:32:58 localhost kernel:
kdb_backtrace(0,,c09293f0,c0929418,c08b3b64) at
kdb_backtrace+0x29
Jul 3 23:32:58 localhost kernel:
witness_checkorder(c19ba77c,9,c085a11c,94) at witness_checkorder+0x564
Jul 3 23:32:58 localhost kernel:
_mtx_lock_flags(c19ba77c,0,c085a11c,94,7) at _mtx_lock_flags+0x5b
Jul 3 23:32:58 localhost kernel: rtalloc1(c1d39c78,0,0,d745ab3c,0) at
rtalloc1+0x61
Jul 3 23:32:58 localhost kernel:
ifa_ifwithroute(801,c1d39c5c,c1d39c78,c1b34270,c19ba700) at
ifa_ifwithroute+0x68
Jul 3 23:32:58 localhost kernel:
rt_getifa(d745ab3c,0,c1b34210,c1d39c00,c091f680) at rt_getifa+0xa6
Jul 3 23:32:58 localhost kernel:
route_output(c1a39400,c1b316f4,a0,c1a39400,1f60) at route_output+0x5c5
Jul 3 23:32:58 localhost kernel:
raw_usend(c1b316f4,0,c1a39400,0,0,c1a47300) at raw_usend+0x60
Jul 3 23:32:58 localhost