Re: drm / drm2 removal in 12
On 8/22/18 3:54 AM, Matthew Macy wrote: > Just in case anyone misses the change to UPDATING: > > 20180821: > drm and drm2 have been removed. Users on powerpc, 32-bit hardware, > or with GPUs predating Radeon and i915 will need to install the > graphics/drm-legacy-kmod. All other users should be able to use > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > Note that this applies only to 12. Thanks for the headsup. Will graphics/drm-stable-kmod be updated on 11-STABLE from 4.11 to 4.15? Currently, OpenCL stuff ist broken with drm-stable-kmod and amdgpu... -Thanks, cpghost. > -M smime.p7s Description: S/MIME Cryptographic Signature
Re: Ryzen issues on FreeBSD ? (with sort of workaround)
On 06/26/18 13:29, Konstantin Belousov wrote: > On Tue, Jun 26, 2018 at 11:31:26AM +0100, Pete French wrote: >>> On 06/18/2018 09:34, Pete French wrote: >>>> Preseumably in the slightly longer term these workarounds go into the >>>> actual kernel if it detects Ryzen ? >>> >>> Yes, Kostik said he would code this into the kernel after he gets enough >>> feedback. >> >> So, I've been running with the sysctl and cputl fixes from >> https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html >> for a couple of weeks now, with all the default settings back on (including >> SMT) and it now completely stable, so consider this one more point of >> feedback Same here on FreeBSD monster 11.2-BETA2 FreeBSD 11.2-BETA2 #1 r334062: Tue May 22 23:46:29 CEST 2018 root@monster:/usr/obj/usr/src/sys/GENERIC amd64 with a Threadripper 1950X and % sudo x86info -a | grep Microcode Microcode patch level: 0x8001136 Without that script, the system would lockup up to 5-6 times a day. Now running without any lockup at all for 3 days, with all kinds of workload from idle to torture tests. Too early to tell, but it looks good for now. CPU: AMD Ryzen Threadripper 1950X 16-Core Processor (3393.71-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics Thanks, -cpghost. smime.p7s Description: S/MIME Cryptographic Signature
Re: how to mirror cvs or svn with rsync
On Sat, Nov 14, 2009 at 09:38:11PM +0300, Nikolay Tychina wrote: Having a mirror accessible from our network for free would help users to get sources for free. Incoming traffic from Internet costs money, that's problem. So you need to mirror /usr/src, and not the whole repository with all its history, right? What I do here is to csup /usr/src on one reference machine every now and then, and then distribute that directory with rsync to all other 500+ machines inside. Actually, I do a little bit more: I compile the sources on the reference machine, and rsync /usr/obj to the other machines too, saving some 500+ buildworlds as well. I could nfs mount /usr/src and /usr/obj from the reference server to the internal machines, but I have enough diskspace there, and rsync is good enough for us. You could also explore a similar mechanism w.r.t. /usr/ports, /usr/local, /var/db/ports, /var/db/pkg etc..., if you want to save external bandwidth downloading ports and distfiles, or CPU cycles compiling all this on your internal machines. But this requires slightly more care, though it works quite well too. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: how to mirror cvs or svn with rsync
On Sat, Nov 14, 2009 at 11:39:03PM +0300, Nikolay Tychina wrote: Well, reference machine doesn't even run FreeBSD. I need to mirror src (say, checkout of RELENG_8). According to /usr/src/contrib/csup/README, csup can run on Linux or other Unixoids too: Csup should build and run fine under any *BSD OS (that includes FreeBSD, NetBSD, OpenBSD and DragonFlyBSD), as well as Linux and Darwin. If you have a problem building from source, drop me a mail! So the reference machine running csup doesn't even need to run FreeBSD. :-) Another problem is that only rsync may be used on the reference machine. :) If you're referring to firewall rules: csup connects by default to TCP port 5999 of the csup server(s). This is an outbound connection only, as there is no need to punch a hole in the firewall to allow for incoming connections. Maybe talking to your network admin would resolve the problem? Alternatively, there may be someone running a rsync daemon (over ssh?) who could provide you with /usr/src? Or there may be someone running a cvsup daemon on rsync's or http's port, so you could punch right through your firewall with csup -p 873 or csup -p 80 (or something similar)? -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: No sound after update to RC2 from RC1.
On Thu, Oct 29, 2009 at 04:05:33PM -0700, Jakub Lach wrote: mav-3 wrote: Jakub Lach wrote: Yes, I tried tracing related changes to no avail, furthermore I didn't change anything related in my configuration. Dmesg gives some insight: hdac0: Tracing association 1 (2) hdac0: Unable to trace pin 24 to ADC 20, undo traces hdac0: Pin 24 traced to ADC 21 hdac0: Unable to trace pin 29 to ADC 21, undo traces hdac0: Association 1 (2) trace failed Full dmesg + sndstat http://senduit.com/8fdabe It tells that file has expired. -- Alexander Motin You mean that my device.hints file is no longer valid? What triggered it? He meant, the hosting provider senduit.com has expired your dmesg + sndstat: File has expired The file you are trying to download has expired and is no longer available. Without dmesg + sndstat output, noone can debug your problem. -best regards, Jakub Lach Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unnamed POSIX shared semaphores
On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote: Hello, According to sem_init(3), we can't have shared unnamed semaphores. However, the following code snippet seems to work just fine: -- cut here -- sem_t semaphore; if (sem_init(semaphore, 1, 10) 0) std::cout Couldn't init semaphore: strerror(errno) std::endl; if (sem_wait(semaphore) 0) std::cout Couldn't decrement semaphore: strerror(errno) std::endl; int val; sem_getvalue(semaphore, val); std::cout Value is val std::endl; -- and here -- Is this a case where sem_init() silently reports success, or should be the man page get an update? You may want to read the comments in /usr/src/lib/libc/gen/sem.c regarding sem_init(). But yes, the man page is somewhat unclear and I'm not sure the last paragraph is still totally accurate. Thanks, Vlad -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: page fault in sis.ko / drm.ko
On Sat, Apr 18, 2009 at 01:58:39PM -0500, Robert Noland wrote: On Sat, 2009-04-18 at 19:13 +0200, cpghost wrote: Could a drm guru please have a look at kern/133554? Give this patch a try, it looks like the sis driver doesn't have irq's. The patch solves kern/133554 here. sis is working again (including xv etc...), and no more panics. It would be nice if it could still be included in 7.2-RELEASE. ;-) Kind regards and many thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
page fault in sis.ko / drm.ko
Could a drm guru please have a look at kern/133554? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: page fault in sis.ko / drm.ko
On Sat, Apr 18, 2009 at 01:58:39PM -0500, Robert Noland wrote:
On Sat, 2009-04-18 at 19:13 +0200, cpghost wrote:
Could a drm guru please have a look at kern/133554?
Thanks,
-cpghost.
Give this patch a try, it looks like the sis driver doesn't have irq's.
Ah, thank you. I'll try this tomorrow as soon as I'm in front of
this box again, and will report back.
Kind regards,
-cpghost.
robert.
--
Robert Noland rnol...@freebsd.org
FreeBSD
Index: dev/drm/drm_drv.c
===
--- dev/drm/drm_drv.c (revision 190987)
+++ dev/drm/drm_drv.c (working copy)
@@ -134,7 +134,7 @@
.d_flags = D_TRACKCLOSE
};
-int drm_msi = 1; /* Enable by default. */
+static int drm_msi = 1; /* Enable by default. */
TUNABLE_INT(hw.drm.msi, drm_msi);
static struct drm_msi_blacklist_entry drm_msi_blacklist[] = {
@@ -228,28 +228,31 @@
dev-pci_vendor = pci_get_vendor(dev-device);
dev-pci_device = pci_get_device(dev-device);
- if (drm_msi
- !drm_msi_is_blacklisted(dev-pci_vendor, dev-pci_device)) {
- msicount = pci_msi_count(dev-device);
- DRM_DEBUG(MSI count = %d\n, msicount);
- if (msicount 1)
- msicount = 1;
+ if (drm_core_check_feature(dev, DRIVER_HAVE_IRQ)) {
+ if (drm_msi
+ !drm_msi_is_blacklisted(dev-pci_vendor, dev-pci_device)) {
+ msicount = pci_msi_count(dev-device);
+ DRM_DEBUG(MSI count = %d\n, msicount);
+ if (msicount 1)
+ msicount = 1;
- if (pci_alloc_msi(dev-device, msicount) == 0) {
- DRM_INFO(MSI enabled %d message(s)\n, msicount);
- dev-msi_enabled = 1;
- dev-irqrid = 1;
+ if (pci_alloc_msi(dev-device, msicount) == 0) {
+ DRM_INFO(MSI enabled %d message(s)\n,
+ msicount);
+ dev-msi_enabled = 1;
+ dev-irqrid = 1;
+ }
}
- }
- dev-irqr = bus_alloc_resource_any(dev-device, SYS_RES_IRQ,
- dev-irqrid, RF_SHAREABLE);
- if (!dev-irqr) {
- return ENOENT;
+ dev-irqr = bus_alloc_resource_any(dev-device, SYS_RES_IRQ,
+ dev-irqrid, RF_SHAREABLE);
+ if (!dev-irqr) {
+ return ENOENT;
+ }
+
+ dev-irq = (int) rman_get_start(dev-irqr);
}
- dev-irq = (int) rman_get_start(dev-irqr);
-
mtx_init(dev-dev_lock, drmdev, NULL, MTX_DEF);
mtx_init(dev-irq_lock, drmirq, NULL, MTX_DEF);
mtx_init(dev-vbl_lock, drmvbl, NULL, MTX_DEF);
--
Cordula's Web. http://www.cordula.ws/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dump | restore fails: unknown tape header type 1853384566
On Wed, Mar 25, 2009 at 12:04:18PM -0400, Mikhail T. wrote: Generally, when dumping read-write mounted filesystems, one is supposed to use snapshots, but that is very buggy on its own (leading to kernel crashes), so it is safer to rely on the FS being idle, if it can not be forced into read-only for some other reason. Perhaps your kernel/world is not recent enough? There used to be problems with snapshots, including hangs or crashes, but IIRC, they disappeared completly a couple of months ago, at least for me. (no, sorry, I can't pinpoint the exact date, and much less the exact revision nr). Snapshots alone, and dump -L + restore (on RELENG_7/amd64) working flawlessly here on 20+ rack-mounted servers; some to tape, some to SAN, but I'm probably just lucky. BTW, that's what makes this problem so intractable: those who could debug it, can't reproduce it on their machines. It's scary to know there's a bug lurking in there. -mi -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
On Wed, Feb 25, 2009 at 11:04:29AM +, Robert Watson wrote: On Wed, 25 Feb 2009, Pete French wrote: FYI, I'm currently awaiting testing results from Pete on the MFC of a number of routing table locking fixes, and once that's merged (hopefully tomorrow?) I'll start on the patches in the above PR. I've taken a crash-course in routing table locking in the last few days... :-) Just to let you know that I have had zero crashes since I out the patch live on sunday. Of course thats only three days, but it does look very much like it has fixed it. I am also running with the other routing table patch too.. At this point no news is good news, as it is just sitting there ticking away nicely to itself. I will roll it out to a few more machines over the next few days. But looking good so far, I would encourage other people to try the ptches if they are having problems... Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I can look at the PR and get that in-progress. Since the code affected by the PR is no longer in 8.x, I'll merge directly to 7.x, and probably fairly quickly since you've had it in production for a while. Great! I hope this patch will also fix the mysterious hangs I've experienced on Soekris routers since nov/dec 2008. Will try in a few days and report back any further hangs. Robert N M Watson Computer Laboratory University of Cambridge Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
buildworld broken
Who broken RELENG_7 (as of Feb 22 18:24 UTC)? === usr.sbin/ifmcstat (all) cc -O2 -fno-strict-aliasing -pipe -DINET6 -DWITH_KVM -Wsystem-headers -Wall -Wn o-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/ifmcstat/ ifmcstat.c /usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function 'ifmcstat_getifmaddrs': /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: 'pllasa' undeclared (first use in this function) /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: (Each undeclared identifier is reported only once /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: for each function it appears i n.) *** Error code 1 Stop in /usr/src/usr.sbin/ifmcstat. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: buildworld broken
On Sun, Feb 22, 2009 at 09:32:57PM +0100, cpghost wrote: Who broken RELENG_7 (as of Feb 22 18:24 UTC)? === usr.sbin/ifmcstat (all) cc -O2 -fno-strict-aliasing -pipe -DINET6 -DWITH_KVM -Wsystem-headers -Wall -Wn o-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/ifmcstat/ ifmcstat.c /usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function 'ifmcstat_getifmaddrs': /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: 'pllasa' undeclared (first use in this function) /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: (Each undeclared identifier is reported only once /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: for each function it appears i n.) *** Error code 1 Stop in /usr/src/usr.sbin/ifmcstat. *** Error code 1 Nevermind, it is probably already fixed: http://lists.freebsd.org/pipermail/svn-src-stable/2009-February/000854.html Sorry for the noise. Rebuilding world now... ;) -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
On Sun, Feb 08, 2009 at 05:11:02PM +0200, Stefan Lambrev wrote: Hi all, In this thread someone mention a problem with soekris devices. I personally have one of those new soekris devices and installed 7.1R and it is very easy to freeze it. All that I have to do is to copy big file vfer WIFI (atheros) with speed higher then 1-2MB/s. It takes less then 2 minutes to freeze. I wonder if there is some improvement in 7.1-stable so I can try it or if I can help by compiling debug kernel? But I'm not sure if this is the same problem as it may be just the wireless driver in my case. One some net4801's without WIFI, I also experience frequent freezes after a couple of hours up to 2-5 days... so it's probably not only ath related. What's your kern.hz value? In my /boot/loader.conf, it is set to 100. Could you try it too, and see if you can still freeze the box (just to rule out some weird timing / interrupt issue)? Best Wishes, Stefan Lambrev ICQ# 24134177 Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Soekris 4801 hangs (was Re: Hangs, maybe a clue)
# USB Double Bulk Pipe devices
device ugen# Generic
-- cut here ---
As you see, no atkbdc, psm, kbdmux, sc, etc but still sporadic
hangs... :(
The hangs only seem to happen on AMD hardware; I have several
ich{3,5}+p3 or p4 machines that don't hang.
Before I figured that out I noticed some PHK notes about enabling the
hardware watchdog and did that too, but did the upgrade mentioned above
before any watchdog hits. I haven't seen any spontaneous reboots (which
a watchdog hit would look like) since the reconfig either.
-- Pete
Regards,
-cpghost.
--
Cordula's Web. http://www.cordula.ws/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Soekris 4801 hangs (was Re: Hangs, maybe a clue)
On Sun, Jan 18, 2009 at 09:30:05PM -0500, Pete Carah wrote: I've had some mysterious hangs which I notice that several others have too. Two of the machines in question are Soekris 4801's running as routers; this is hard to handle ddb with (though possible for one of them...) I started noticing this sometime in December. My laptop finally hung in a state where I could do a ps (waiting a long time for the response.) The strange and likely related to the hang was softdepflush in R state with 43 MINUTES of cpu. (the machine has been up maybe an hour.) I'm seeing those hangs on Soekris 4801 routers running RELENG_7 as well. The boxes are used as SoHo appliances and run mpd5, pf, named, postfix, cyrus-imapd, lighttpd, openntpd and sshd. On all of them, softupdates are enabled on all partitions except root and they use real HDDs (not compact flash). The hangs appear now every 2 or 3 days at different times. They don't seem related to traffic type (heavy p2p, normal upload/download, or idle) and also seem independent on disk activity (i.e. there's no more during 3am than other time). They were less frequent before Dec 1st, and IIRC the last RELENG_7 that was nearly hang-free was 2008-11-07. IMHO, it could be some kind of resource leak (?), but I'm not sure. Since the only serial port is used by getty, I'm not sure how to break into the debugger and how to trace the problem (and I'm not experienced enough for this). :( -- Pete Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.1-PRERELEASE: asus M3A / Phenom X4 / powerd freeze
On Fri, Dec 12, 2008 at 12:01:29AM +0100, Arno J. Klaassen wrote: yet another powerd SOS : on an ASUS M3A78-EM MB with Phenom 9750 and 8 gig memory, starting powerd freezes the box after slowing down a bit cpu frequency. (... snip ...) dev.cpu.0.freq_levels: 2398/-1 2098/-1 1798/-1 1498/-1 1199/-1 899/-1 599/-1 299/-1 further : - I set debug.cpufreq.lowest superior to 1500 : system remains up but only when pushing really slightly - I set debug.cpufreq.lowest inferior to 1100 : freeze garantueed Same here. Running with debug.cpufreq.lowest=1240 in /boot/loader.conf to prevent freezes. This is a FreeBSD 7.1-PRERELEASE #0: Sat Nov 8 14:18:05 CET 2008 r...@textbox:/usr/obj/usr/src/sys/GENERIC running in amd64 and i386 mode with ACPI enabled (default): CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f23 Stepping = 3 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR, PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,b23 AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM, 3DNow!+,3DNow! AMD Features2=0x7ffLAHF,CMP,SVM,ExtAPIC,CR8,b5,b6,b7, Prefetch,b9,b10 Cores per package: 4 using an MSI board with SB600 chipset and newest BIOS. No idea why the system freezes below approx 1200 MHz. But apparently, this bug is quite common and affects a lot of systems with Phenoms. :( - I define hint.acpi_throttle.0.disabled=1 in loader.conf then no dev.cpu.0.freq is showing up ... (as if only acpi_throttle is attaching and not powernow) Let me know what I can test further. Best, Arno Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ifconfig(8) interface description field
On Tue, Nov 18, 2008 at 10:34:24AM +0100, [EMAIL PROTECTED] wrote: Oh yeah, since we're in wishful thinking mode, I want interface descriptions too... Have you looked at the 'name' and 'group' keywords in ifconfig(8)? If this isn't what you want, please expand on your wish. It is not what I want. On routers, switches and lots of other boxes from most vendors you can associate a description string with each interface - where interface can be a physical port, or for instance a VLAN based interface. This description string is useful to document things like - what is the box at the other end of the cable connected to this port - what is the port at the other end of the cable connected to this port - what is the circuit id for the circuit this port is connected to - what is this port used for etc. Typical example, from one of our switches (Cisco syntax): interface GigabitEthernet0/12 description TO: fs1.td ID: BTN-11510092 TXT: gi1/0/7 EoSDH 50 Mbps switchport trunk allowed vlan 123,770,1024,1500,1504,1528,1536 showing the first three points I mentioned above. Such a description string is can normally be retrieved using SNMP. Yes, that's a very useful addition. I'm administering a lot of Cisco boxes, and this desc field has been extremely useful over the years. Maybe an ifi_desc field could be added to: /usr/src/sys/net/if.h:struct if_data and some glue so that ifconfig(8) can read and write to it? How long should this field be at most? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig(8) interface description field
On Tue, Nov 18, 2008 at 12:48:06PM +, Gavin Atkinson wrote: On Tue, 2008-11-18 at 12:38 +0100, cpghost wrote: On Tue, Nov 18, 2008 at 10:34:24AM +0100, [EMAIL PROTECTED] wrote: Oh yeah, since we're in wishful thinking mode, I want interface descriptions too... Have you looked at the 'name' and 'group' keywords in ifconfig(8)? If this isn't what you want, please expand on your wish. It is not what I want. On routers, switches and lots of other boxes from most vendors you can associate a description string with each interface - where interface can be a physical port, or for instance a VLAN based interface. This description string is useful to document things like - what is the box at the other end of the cable connected to this port - what is the port at the other end of the cable connected to this port - what is the circuit id for the circuit this port is connected to - what is this port used for etc. Typical example, from one of our switches (Cisco syntax): interface GigabitEthernet0/12 description TO: fs1.td ID: BTN-11510092 TXT: gi1/0/7 EoSDH 50 Mbps switchport trunk allowed vlan 123,770,1024,1500,1504,1528,1536 showing the first three points I mentioned above. Such a description string is can normally be retrieved using SNMP. Yes, that's a very useful addition. I'm administering a lot of Cisco boxes, and this desc field has been extremely useful over the years. Maybe an ifi_desc field could be added to: /usr/src/sys/net/if.h:struct if_data and some glue so that ifconfig(8) can read and write to it? How long should this field be at most? Patches already existfor one method of implementing this, see PR kern/83622. Gavin Ah yes, that was exactly what I was thinking of! Thank you for the hint! -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig(8) interface description field
On Tue, Nov 18, 2008 at 12:07:32PM +, Bjoern A. Zeeb wrote: On Tue, 18 Nov 2008, cpghost wrote: On Tue, Nov 18, 2008 at 10:34:24AM +0100, [EMAIL PROTECTED] wrote: Oh yeah, since we're in wishful thinking mode, I want interface descriptions too... Have you looked at the 'name' and 'group' keywords in ifconfig(8)? If this isn't what you want, please expand on your wish. It is not what I want. On routers, switches and lots of other boxes from most vendors you can associate a description string with each interface - where interface can be a physical port, or for instance a VLAN based interface. This description string is useful to document things like - what is the box at the other end of the cable connected to this port - what is the port at the other end of the cable connected to this port - what is the circuit id for the circuit this port is connected to - what is this port used for etc. Typical example, from one of our switches (Cisco syntax): interface GigabitEthernet0/12 description TO: fs1.td ID: BTN-11510092 TXT: gi1/0/7 EoSDH 50 Mbps switchport trunk allowed vlan 123,770,1024,1500,1504,1528,1536 showing the first three points I mentioned above. Such a description string is can normally be retrieved using SNMP. Yes, that's a very useful addition. I'm administering a lot of Cisco boxes, and this desc field has been extremely useful over the years. Maybe an ifi_desc field could be added to: /usr/src/sys/net/if.h:struct if_data and some glue so that ifconfig(8) can read and write to it? How long should this field be at most? This is nothing the really belongs in the kernel. Add an interface to set/get the information per interface (index, name, ...) and store the actual data in a file maybe. Make the format extensible to store other meta data that people may want to think along with it in the future. After all you want the information to be peristent over a reboot so you have to write it out somehow anyway. Yes, but some interfaces are created on-the-fly, and you never know in advance which name they'll get (think of tunN, ngN etc...). If those interfaces are meant to be queried frequently (every few minutes or so) by an snmpd, wouldn't it be more inefficient to check an external file than get the meta data from the kernel? Some network management apps could also decide to use the description field as a repository for more dynamic data; data that could be queried by applications running on the hosts. Here too, would'nt it be more efficient if descr. were in-kernel? For persistence, an /etc/rc.d script could always set the static interface descriptions via ifconfig calls any way it likes, including reading those definitions from a config file. Everything else will probably be set remotely via the network management software, which itself has its own persistence store (usually a database). Just my 0.02CAD /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig(8) interface description field
On Tue, Nov 18, 2008 at 02:23:05PM +0100, cpghost wrote: On Tue, Nov 18, 2008 at 12:07:32PM +, Bjoern A. Zeeb wrote: On Tue, 18 Nov 2008, cpghost wrote: On Tue, Nov 18, 2008 at 10:34:24AM +0100, [EMAIL PROTECTED] wrote: Oh yeah, since we're in wishful thinking mode, I want interface descriptions too... Have you looked at the 'name' and 'group' keywords in ifconfig(8)? If this isn't what you want, please expand on your wish. It is not what I want. On routers, switches and lots of other boxes from most vendors you can associate a description string with each interface - where interface can be a physical port, or for instance a VLAN based interface. This description string is useful to document things like - what is the box at the other end of the cable connected to this port - what is the port at the other end of the cable connected to this port - what is the circuit id for the circuit this port is connected to - what is this port used for etc. Typical example, from one of our switches (Cisco syntax): interface GigabitEthernet0/12 description TO: fs1.td ID: BTN-11510092 TXT: gi1/0/7 EoSDH 50 Mbps switchport trunk allowed vlan 123,770,1024,1500,1504,1528,1536 showing the first three points I mentioned above. Such a description string is can normally be retrieved using SNMP. Yes, that's a very useful addition. I'm administering a lot of Cisco boxes, and this desc field has been extremely useful over the years. Maybe an ifi_desc field could be added to: /usr/src/sys/net/if.h:struct if_data and some glue so that ifconfig(8) can read and write to it? How long should this field be at most? This is nothing the really belongs in the kernel. Add an interface to set/get the information per interface (index, name, ...) and store the actual data in a file maybe. Make the format extensible to store other meta data that people may want to think along with it in the future. After all you want the information to be peristent over a reboot so you have to write it out somehow anyway. Yes, but some interfaces are created on-the-fly, and you never know in advance which name they'll get (think of tunN, ngN etc...). If those interfaces are meant to be queried frequently (every few minutes or so) by an snmpd, wouldn't it be more inefficient to check an external file than get the meta data from the kernel? Some network management apps could also decide to use the description field as a repository for more dynamic data; data that could be queried by applications running on the hosts. Here too, would'nt it be more efficient if descr. were in-kernel? For persistence, an /etc/rc.d script could always set the static interface descriptions via ifconfig calls any way it likes, including reading those definitions from a config file. Everything else will probably be set remotely via the network management software, which itself has its own persistence store (usually a database). Another reason you want to avoid using a file for this: what about appliances that run as dedicated routers and boot from a flash-based read-only filesystem? How would you change the interface description (remotely or on the console) if you can't write to a file? Bjoern A. Zeeb Stop bit received. Insert coin for new game. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig(8) interface description field
On Tue, Nov 18, 2008 at 01:58:09PM +, Bjoern A. Zeeb wrote: Some network management apps could also decide to use the description field as a repository for more dynamic data; data that could be queried by applications running on the hosts. Here too, would'nt it be more efficient if descr. were in-kernel? For persistence, an /etc/rc.d script could always set the static interface descriptions via ifconfig calls any way it likes, including reading those definitions from a config file. Everything else will probably be set remotely via the network management software, which itself has its own persistence store (usually a database). Another reason you want to avoid using a file for this: what about appliances that run as dedicated routers and boot from a flash-based read-only filesystem? How would you change the interface description (remotely or on the console) if you can't write to a file? So how would you make it persistent across a reboot if you cannot write it anywhere? This would be done remotely by the network management system (NMS) The NMS will notice that the node rebooted, and will send to its snmpd the description of its interfaces. snmpd runs on the node, and will call an ifconfig ioctl to store this description in kernel memory. From then on, you could ssh to the box, and look around by calling ifconfig(8) manually: you'all immediately know what each interface is intended for. If you have hundreds of nodes, you'll appreciate the convenience! The presistence occurs at the NMS site: it is merely mirrored onto the nodes. So why store this on the nodes at all, as it is redundant and already persistently available in the NMS? Well, in practice, NMS can and do break down every now and then for all kinds of reasons (database problems, server problems, network problems to the NMS server, ...). But a NOC can't afford to wait for the NMS be available again to reconfigure some important nodes on a backbone. Even when the NMS is down, you'll still have to manually ifconfig(8) some interfaces on crucial backbone nodes. When the NMS is available again, it will poll all the snmpd of its managed hosts, and will update its own database if things changed in the mean time on the nodes. That's the easiest way to synchronize the NMS database back with the manual changes at the nodes that occured while the NMS was down. (Sure, there's a little time window where information can be lost: that's just after the manual ifconfig(8) and the polling of the snmpd by the NMS. But, hey, if THIS happened, you could still use some logfile (script(1)?) of your manual changes to catch this. The normal workflow is to manage at the NMS and to push the data to the nodes, the reverse workflow is for emergencies only.) The point I'm trying to make, is that diskless systems, or systems with read-only filesystems should still be configurable, remotely and manually; and the configuration data (in this case it's the description strings of its interfaces) will have to be stored in memory. For something as trivial as description strings, kernel memory seems like a good idea. If user memory is preferred and absolutely needed, one could always write an ifconfigd daemon and store it there; but *that* seems like overkill for such a simple change. Bjoern A. Zeeb Stop bit received. Insert coin for new game. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
On Thu, Oct 02, 2008 at 06:51:06PM +0200, Oliver Lehmann wrote: today I'd a crash again - I was not able to get a crash dump (thought a panic at the end of the kdb would do it but didn't - should have called dumpon before ;)) - so here now the information I was able to retrieve: Ok, what I've got so far is wrinting stuff out to the console when the system hangs up: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 ... and now the debugger stuff: [snipped] So.. no idea? anyone? If it's PATA, check the cabling, then check it again, and just to make sure, replace the cable even if the system used to work flawlessly in the past. I've had this on a few servers, but replacing the cables always fixed the problem for me. Oh, btw, you can reproduce this exact behavior on diskless workstations with an NFS-mounted swap. IIRC, it even happened on VERY slow hardware with GBDE or GELI-encrypted swap partitions; but I'm not 100% sure it was due to slowness (it could have been a bad cabling issue as well). -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: powerd freezes system on lower cpu speeds
On Wed, Aug 27, 2008 at 10:22:08PM -0400, John Baldwin wrote: On Wednesday 27 August 2008 09:40:20 am cpghost wrote: Hello, I'm building a new system with an AMD Phenom 9350e Quad-Core: FreeBSD phenom.example.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Aug 26 19:49:24 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/\ src/sys/GENERIC i386 Everything's running smoothly, until I start powerd. As soon as that happens, the system freezes hard. Trying powerd in the foreground with -v shows that it decreased the frequencies a few times, but then hangs the system. So I've tried this manually: # sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 1985/-1 1736/-1 1488/-1 1240/-1 992/-1 744/-1 496/-1 248/-1 # sysctl dev.cpu.0.freq dev.cpu.0.freq: 1985 powerd freezed the system after reaching 1240 when trying 992. If I set the frequency manually down to 1240 with: # sysctl dev.cpu.0.freq=1240 everything's fine. But as soon as I try setting it further down (992, 744, 496 or 248), the system freezes too, just the same as with powerd. This is 100% reproducible. So what's going on here? Hard to say. My HP nc6220 laptop gets into a lockup where it spends all its time processing ACPI events (I think for some of the thermal monitoring the BIOS does) if I drop the CPU speed below 400. Interesting. So it's probably some bug in the BIOS? I've tried a lot of different settings there, from failsafe to optimized, selectively turning Cool Quiet and other options on or off... but to no avail. I'll still have to test with another OS though to rule out an FBSD bug, but that's currently not an option on that box... unless I could find a stand-alone utility to boot and try without an OS. :) I just set debug.cpufreq.lowest in /boot/loader.conf. Good hint! I've set it to 1240 now, and powerd works like a charm (at least down to 1240 MHz and back up again). It's a good work around for now. John Baldwin Thanks for the help, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
powerd freezes system on lower cpu speeds
Hello, I'm building a new system with an AMD Phenom 9350e Quad-Core: FreeBSD phenom.example.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Aug 26 19:49:24 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/\ src/sys/GENERIC i386 Everything's running smoothly, until I start powerd. As soon as that happens, the system freezes hard. Trying powerd in the foreground with -v shows that it decreased the frequencies a few times, but then hangs the system. So I've tried this manually: # sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 1985/-1 1736/-1 1488/-1 1240/-1 992/-1 744/-1 496/-1 248/-1 # sysctl dev.cpu.0.freq dev.cpu.0.freq: 1985 powerd freezed the system after reaching 1240 when trying 992. If I set the frequency manually down to 1240 with: # sysctl dev.cpu.0.freq=1240 everything's fine. But as soon as I try setting it further down (992, 744, 496 or 248), the system freezes too, just the same as with powerd. This is 100% reproducible. So what's going on here? Thanks, -cpghost. Oh, here's dmesg, if it helps: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Tue Aug 26 19:49:24 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) 9350e Quad-Core Processor (1995.68-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x100f23 Stepping = 3 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,b23 AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,b26,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x7ffLAHF,CMP,SVM,ExtAPIC,CR8,b5,b6,b7,Prefetch,b9,b10 Cores per package: 4 real memory = 2079916032 (1983 MB) avail memory = 2025545728 (1931 MB) ACPI APIC Table: 052808 APIC1156 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 Version 2.1 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: 052808 RSDT1156 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of fff0, 10 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7bf0 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xc000-0xc0ff mem 0xf800-0xfbff,0xfe8f-0xfe8f,0xfe70-0xfe7f irq 18 at device 5.0 on pci1 pcm0: ATI (Unknown) High Definition Audio Controller mem 0xfe8e8000-0xfe8ebfff irq 19 at device 5.1 on pci1 pcm0: [ITHREAD] pcib2: ACPI PCI-PCI bridge irq 17 at device 5.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 18 at device 6.0 on pci0 pci3: ACPI PCI bus on pcib3 ohci0: OHCI (generic) USB controller mem 0xfe6ff000-0xfe6f irq 16 at device 18.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: OHCI (generic) USB controller mem 0xfe6fe000-0xfe6fefff irq 16 at device 18.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: OHCI (generic) USB controller on ohci1 usb1: USB revision 1.0 uhub1: ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfe6fd800-0xfe6fd8ff irq 17 at device 18.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: EHCI (generic) USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb2 uhub2: 6 ports with 6 removable, self powered ohci2: OHCI (generic) USB controller mem 0xfe6fc000-0xfe6fcfff irq 18 at device 19.0 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: OHCI (generic) USB controller on ohci2 usb3: USB revision 1.0 uhub3: ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb3 uhub3: 3 ports with 3 removable, self powered ohci3: OHCI (generic) USB controller mem 0xfe6fb000
Re: FreeBSD 7.1 and BIND exploit
On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: I'm curious, is djbdns exploitable, too? Does it randomize the source ports of UDP queries? Apparently, djbdns had randomization of the source ports a long time ago... Of course, all solutions that randomize ports are really just security by obscurity, because by shuffling ports you're hiding the way to poison your cache... a little. True, but there is currently no better solution, AFAIK. The problem is inherent in the way DNS queries work. Yes indeed. If I understand all this correctly, it's because the transaction ID that has to be sent back is only 2 bytes long, and if the query port doesn't change as well with every query, that can be cracked in milliseconds: sending 65536 DNS queries to a constant port is just way too easy! The namespace is way too small, and there's no way to fix this by switching to, say, 4 bytes or even more for the transaction ID without breaking existing resolvers; actually without breaking the protocol itself. Best regards Oliver cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
sched_ule(1) and sched_4bsd(1)
Hello, the man-pages sched_4bsd(1) and sched_ule(1) as of FreeBSD 7.0-STABLE #0: Sat Jun 28 22:44:54 CEST 2008 both state that SCHED_4BSD is the default scheduler. Yet SCHED_ULE is now in GENERIC, and not SCHED_4BSD! Are the man-pages wrong, or is it better to change SCHED_ULE back to SCHED_4BSD in a custom kernel config file? I'm using SCHED_ULE on UP systems for quite some time now, and there don't seem to be any regressions so far... Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sched_ule(1) and sched_4bsd(1)
On Sun, 29 Jun 2008 19:26:55 -0700 Kevin Oberman [EMAIL PROTECTED] wrote: Date: Mon, 30 Jun 2008 03:24:02 +0200 From: cpghost [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hello, the man-pages sched_4bsd(1) and sched_ule(1) as of FreeBSD 7.0-STABLE #0: Sat Jun 28 22:44:54 CEST 2008 both state that SCHED_4BSD is the default scheduler. Yet SCHED_ULE is now in GENERIC, and not SCHED_4BSD! Are the man-pages wrong, or is it better to change SCHED_ULE back to SCHED_4BSD in a custom kernel config file? I'm using SCHED_ULE on UP systems for quite some time now, and there don't seem to be any regressions so far... Looks like the man pages are a bit outdated. 4BSD was in GENERIC in 7.0-RELEASE, but it was changed to ULE in stable shortly after the release of 7.0. Ah, thank you. ;) Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: option HZ=?
On Wed, Jan 30, 2008 at 02:55:30PM +0200, Stefan Lambrev wrote: Greetings, I want to know what is the bad effect of increasing HZ too much? And when is too much? What problems can I expect when HZ2000? Can I change this value without pre-compiling the kernel? You can change HZ by adding a line to /boot/loader.conf like this: kern.hz=100 (it works on RELENG_6 and RELENG_7 and I'm using this conservative setting on all my boxes, since I don't need faster context switching) If you set HZ too high, the kernel will spend too much overhead on unnecessary context switching, and it may even reach a point (with very high values of HZ) where interrupt service routines get interrupted way too often by clock ticks; i.e. interrupts would eventually come in faster than the kernel can service them. Because all docs I found for HZ is in src/sys/conf/NOTES and it doesn't say much. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 14:01:27 -0800 Julian Elischer [EMAIL PROTECTED] wrote: cpghost wrote: On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: --- manually restarting ppp(1), then: 17:10:47.306928 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] [Service-Name] 17:10:47.306939 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] [Service-Name] we still have 2 sessions instead of 1, but there is less confusion so things sort themselves out. Just one more thing: If I remember correctly, sending two PADIs in quick succession was ppp's normal behaviour for *years* now (is it expected or required by the protocol? I don't know). I've always wondered why it was so. But that didn't cause any harm as it seemed one of the two PADO was picked up and eventually turned into a session. -cpghost. btw try mpd as well. So... I'm running net/mpd5 on that router for a few days now, and it managed 3 forced disconnects in a row and no session chaos at all, while ppp(8) would probably have initiated a lot of parallel sessions again but no connection. So up until now (but perhaps it's too early to be sure?), net/mpd5 is fine, while ppp(8) is not. Btw, I've compared the sources of ppp(8) from 2007-09-24/25 when it was still working, and 2007-11-30 when I've updated the router, and there's NO difference there at all. Whatever broke ppp(8), it was not ppp(8) but something else (I suspect ng_pppoe.c): maybe the code clean up exposed some hidden bug in ppp(8)? I hope ppp(8) will be fixed before 6.3-RELEASE; even though net/mpd5 is excellent and very snappy as well. ;-) Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 14:02:50 -0800 Julian Elischer [EMAIL PROTECTED] wrote: Adding brian to CC list. Alexander Motin wrote: cpghost wrote: I think such behaviour can take place if ppp daemon for some reason don't waits for reply but closes session immediately after sending connect request. If it so it also explains original no matching session errors as for the answer received time session/hook can already be destroyed. Provide please your ppp configuration files and part of detailed log file (set log All) describing connection attempts. ppp.conf already sent. I don't have a 'set log All' turned on, but maybe the following logfile of the aborted session would help? http://www.cordula.ws/tests/ppp-tcpdump.txt Here is part of your logs which proves my assumption that it is ppp who creates numerous sessions: Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: closed - opening Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: opening - dial Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: dial - carrier Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Disconnected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: carrier - hangup Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connect time: 0 secs: 0 octets in, 0 octets out Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: 7070012 packets in, 6467630 packets out Dec 9 17:06:07 fw ppp[35265]: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Dec 9 17:06:07 2007 Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: hangup - closed Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Dead Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: closed - opening Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: opening - dial Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: dial - carrier Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Disconnected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: carrier - hangup Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connect time: 0 secs: 0 octets in, 0 octets out Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: 7070012 packets in, 6467630 packets out Dec 9 17:06:07 fw ppp[35265]: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Dec 9 17:06:07 2007 Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: hangup - closed Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Dead Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish For the some reason ppp logs Disconnected! message and terminates session (which is strange as it have not logged any message from ng_ppp node) just to initiate new without delay. Could you enable any more logs to understant why is it Disconnected!? Here's a new, more detailed log: http://www.cordula.ws/tests/ppp-tcpdump2.txt That's all I can do here. I guess it's up to Brian now... If you have some patches for ppp, I'd be happy to try them and report back. Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Thu, 6 Dec 2007 16:11:07 +0100 cpghost [EMAIL PROTECTED] wrote: On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Will do; but I'll first have to wait 24h from now to get a forcibly disconnected session (I've just had to restart ppp again). All right, I've got a good tcpdump now: # tcpdump -i sis0 -n -pes 0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:06:08.400881 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0C263C1] [Service-Name] 17:06:08.400891 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0ED45C1] [Service-Name] 17:06:08.400898 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C263C1] [Service-Name] 17:06:08.400904 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80CA63C1] [Service-Name] 17:06:08.400910 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80C963C1] [Service-Name] 17:06:08.528227 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0xC0C263C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.488679 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x806320C1] [Service-Name] 17:08:08.488690 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40D063C1] [Service-Name] 17:08:08.488696 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x00C063C1] [Service-Name] 17:08:08.488702 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40CE63C1] [Service-Name] 17:08:08.488708 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80EC45C1] [Service-Name] 17:08:08.552036 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x806320C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.557191 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x40D063C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.572971 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x00C063C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.577148 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x40CE63C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.581343 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x80EC45C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:10:08.577488 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80D063C1] [Service-Name] 17:10:08.577499 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80C463C1] [Service-Name] 17:10:08.577505 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: cpghost wrote: On Thu, 6 Dec 2007 16:11:07 +0100 cpghost [EMAIL PROTECTED] wrote: On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Will do; but I'll first have to wait 24h from now to get a forcibly disconnected session (I've just had to restart ppp again). All right, I've got a good tcpdump now: # tcpdump -i sis0 -n -pes 0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:06:08.400881 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0C263C1] [Service-Name] 17:06:08.400891 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0ED45C1] [Service-Name] 17:06:08.400898 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C263C1] [Service-Name] 17:06:08.400904 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80CA63C1] [Service-Name] 17:06:08.400910 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80C963C1] [Service-Name] why are we sending PADIs for 4 different sessions? what does ngctl list show? Right now, with the working connection: # ngctl list There are 6 total nodes: Name: ngctl53522Type: socketID: 02ec Num hooks: 0 Name: unnamed Type: socketID: 02eb Num hooks: 1 Name: unnamed Type: pppoe ID: 0005 Num hooks: 2 Name: sis2 Type: ether ID: 0003 Num hooks: 0 Name: sis1 Type: ether ID: 0002 Num hooks: 0 Name: sis0 Type: ether ID: 0001 Num hooks: 1 17:06:08.528227 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0xC0C263C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] they respond to the first one we sent. this info should now be sent the ppp daemon. 17:08:08.488679 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x806320C1] [Service-Name] 17:08:08.488690 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40D063C1] [Service-Name] 17:08:08.488696 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x00C063C1] [Service-Name] 17:08:08.488702 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40CE63C1] [Service-Name] 17:08:08.488708 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80EC45C1] [Service-Name] hey these are 4 more new pppoe sessions making 8 Are they just accumlating from each try? maybe we are not cleaning up? 17:08:08.552036 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x806320C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.557191 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x40D063C1] [Service-Name] [AC-Cookie
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: --- manually restarting ppp(1), then: 17:10:47.306928 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] [Service-Name] 17:10:47.306939 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] [Service-Name] we still have 2 sessions instead of 1, but there is less confusion so things sort themselves out. Just one more thing: If I remember correctly, sending two PADIs in quick succession was ppp's normal behaviour for *years* now (is it expected or required by the protocol? I don't know). I've always wondered why it was so. But that didn't cause any harm as it seemed one of the two PADO was picked up and eventually turned into a session. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 22:57:46 +0200 Alexander Motin [EMAIL PROTECTED] wrote: Your host generates huge number of simultaneous session requests. Looking on different Host-Uniq values it should be different ng_pppoe sessions/hooks as Host-Uniq is actually pointer to the hook/session internal data and it stays persistent for all packets of the same session. So it looks that something creates those many hooks. I think such behaviour can take place if ppp daemon for some reason don't waits for reply but closes session immediately after sending connect request. If it so it also explains original no matching session errors as for the answer received time session/hook can already be destroyed. Provide please your ppp configuration files and part of detailed log file (set log All) describing connection attempts. ppp.conf already sent. I don't have a 'set log All' turned on, but maybe the following logfile of the aborted session would help? http://www.cordula.ws/tests/ppp-tcpdump.txt PS: I am not ppp daemon expert, but quick code look shows that connection waiting can be configured with 'set cd ...' command. Setting 'set cd 0' gives results close to yours. Have you something like that in your configuration? Uh... I'm not sure I understand what you're asking for here? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 23:52:01 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: I think such behaviour can take place if ppp daemon for some reason don't waits for reply but closes session immediately after sending connect request. If it so it also explains original no matching session errors as for the answer received time session/hook can already be destroyed. Provide please your ppp configuration files and part of detailed log file (set log All) describing connection attempts. ppp.conf already sent. I don't have a 'set log All' turned on, but maybe the following logfile of the aborted session would help? http://www.cordula.ws/tests/ppp-tcpdump.txt Here is part of your logs which proves my assumption that it is ppp who creates numerous sessions: Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: closed - opening Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: opening - dial Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: dial - carrier Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Disconnected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: carrier - hangup Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connect time: 0 secs: 0 octets in, 0 octets out Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: 7070012 packets in, 6467630 packets out Dec 9 17:06:07 fw ppp[35265]: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Dec 9 17:06:07 2007 Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: hangup - closed Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Dead Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: closed - opening Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: opening - dial Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: dial - carrier Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Disconnected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: carrier - hangup Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connect time: 0 secs: 0 octets in, 0 octets out Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: 7070012 packets in, 6467630 packets out Dec 9 17:06:07 fw ppp[35265]: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Dec 9 17:06:07 2007 Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: hangup - closed Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Dead Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish For the some reason ppp logs Disconnected! message and terminates session (which is strange as it have not logged any message from ng_ppp node) just to initiate new without delay. Could you enable any more logs to understant why is it Disconnected!? If you let me know which one to turn on: PPP ON fw set log +connect PPP ON fw show log Log: Log: CCP Chat Command Connect IPCP LCP Phase Tun Warning Error Alert Local: Warning Error Alert PPP ON fw I've briefly tried to turn on 'all' but since it's an active router but a slow box, I'd rather not log this for very long... :( it generates huge logs VERY fast. PPP ON fw set log all PPP ON fw show log Log: Async CBCP CCP Chat Command Connect Debug DNS Filter HDLC ID0 IPCP IPV6CP LCP LQM Phase Physical Radius Sync TCP/IP Timer Tun Warning Error Alert Local: Warning Error Alert PPP ON fw set log phase chat lcp ipcp ccp tun command PPP ON fw Should I try to re-connect with all enabled now? Of course, it will reset the 24h period... -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 14:01:27 -0800 Julian Elischer [EMAIL PROTECTED] wrote: cpghost wrote: On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: --- manually restarting ppp(1), then: 17:10:47.306928 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] [Service-Name] 17:10:47.306939 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] [Service-Name] we still have 2 sessions instead of 1, but there is less confusion so things sort themselves out. Just one more thing: If I remember correctly, sending two PADIs in quick succession was ppp's normal behaviour for *years* now (is it expected or required by the protocol? I don't know). I've always wondered why it was so. But that didn't cause any harm as it seemed one of the two PADO was picked up and eventually turned into a session. -cpghost. btw try mpd as well. Never did before, but I'll definitely try it in a few days... ;) -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Hi again, no luck this time: I just went through the 24h disconnect with tcpdump watching, but this time, ppp did reconnect flawlessly: [... packets belonging to ses 0x1d06 ..., then:] 16:03:28.367734 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 64: PPPoE PADT [ses 0x1d06] 16:03:28.368035 00:00:24:c2:45:74 00:90:1a:a0:15:b7, ethertype PPPoE D (0x8863), length 38: PPPoE PADT [ses 0x1d06] [Generic-Error session closed] 16:06:22.211545 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x405B1AC1] [Service-Name] 16:06:22.383675 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x405B1AC1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 16:06:22.383871 00:00:24:c2:45:74 00:90:1a:a0:15:b7, ethertype PPPoE D (0x8863), length 66: PPPoE PADR [Host-Uniq 0x405B1AC1] [AC-Cookie ..7\t.K.,.!y.y.E] [AC-Name DSSX43-erx] [Service-Name] 16:06:22.503154 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADS [ses 0xb6b] [Service-Name] [Host-Uniq 0x405B1AC1] [AC-Name DSSX43-erx] [AC-Cookie ..7\t.K.,.!y.y.E] 16:06:24.243677 00:00:24:c2:45:74 00:90:1a:a0:15:b7, ethertype PPPoE S (0x8864), length 36: PPPoE [ses 0xb6b] LCP (0xc021), length 16: LCP, Conf-Request (0x01), id 4, length 16 [... more LCP packets belonging to ses 0xb6b ...] So the PADT/PADI/PADO/PADR/PADS sequence is correct. Maybe the PADT got lost on its way to this box the last times? Would ng_pppoe.c handle this case gracefully? Anyway, I will monitor this a few more days with tcpdump and report back should a no matching session come up again. Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Will do; but I'll first have to wait 24h from now to get a forcibly disconnected session (I've just had to restart ppp again). Thanks for looking into this. ;) - -- Alexander Motin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
Hello, Since I've updated a RELENG_6 router a few days ago, a long gone problem with ppp cropped up (again?); and I'm suspecting a regression between ng_pppoe.c 1.74.2.3 and 1.74.2.4. The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). Since that router is not within easy reach, I'd rather not take the risk to compile a kernel with the old ng_pppoe.c, and have that box crash/hosed. Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quation about HZ kernel option
On Thu, 4 Oct 2007 19:42:33 +0400 Artem Kuchin [EMAIL PROTECTED] wrote: Craig Boston wrote: On Thu, Oct 04, 2007 at 02:32:39PM +0200, Oliver Fromme wrote: In that case, I would recommend not to override the default at all (which is 1000). ISTM that it would be better to use kern.hz=100 in this case. My reasoning is that a web server shouldn't be terribly sensitive to latency, so it's better to have longer quantums to get more work done without context switching overhead. If you're not using polling, you'll be getting interrupts for network traffic anyway. That what i personally thought. However 100 seems to be too rough. I just feel so, no reasoning behind this ;) Maybe 200-300 is better than 100 and better than 1000? I wonder how to build a test case for this to find best settings for web server, so others will not stuggle with this on the future. Why would 100 Hz be too rough? Up until recently, very big high traffic web servers were running just fine at 100Hz and some still do today. As Craig said, it's even better to keep the quantum long, so that more work can be done. It makes sense to get rid of client requests as soon as possible, and this is easier done with 100Hz than with higher clock rates. And since context switching happens much more frequently than that (at every blocking syscall, including disk- and network I/O), the server will still be very much responsive anyway. AFAICS, polling(4) is the only scenario where a faster clock makes sense on a web server, and if you absolutely have to do polling, anything below 800Hz to 1000Hz wouldn't make sense anyway. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp redial unsuccessful
On Fri, Oct 06, 2006 at 08:02:02PM +0200, Ulrich Spoerlein wrote: I cranked up the debug logging, and compared my ppp login attempts with your logfile. I get multiple Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: deflink: RecvConfigReq(12) state = Initial Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: IPADDR[6] 213.191.89.20 Oct 6 18:29:43 coyote ppp[67945]: tun0: IPCP: deflink: Oops, RCR in Initial. Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: deflink: RecvConfigReq(13) state = Initial Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: IPADDR[6] 213.191.89.20 Oct 6 18:29:46 coyote ppp[67945]: tun0: IPCP: deflink: Oops, RCR in Initial. Using Google Search then led me to the follow posts [1], that describe the problem in more detail. 'disable ipv6cp' should do the trick, I'll check this ASAP. Yesterday, I've had a brand new 6.2-PRERELEASE Oct 4th box installed on T-Com ADSL, using the same ppp.conf from my previous post. I've just logged into this box and seen a successful disconnect/reconnect, as always after 24hrs. Everything seems all right with ppp and T-Com ADSL. Ulrich Spoerlein Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp redial unsuccessful
On Wed, Oct 04, 2006 at 08:51:48PM +0200, Ulrich Spoerlein wrote: Hello all, with my ADSL provider (a reseller of the german Telekom), I'm unable to make ppp redial after the link has been lost. With Telekom, you usually get disconnected every 24h hours, but you can simply reconnect if our ppp would support it. Have you added this to /etc/rc.conf? ppp_mode=ddial Ulrich Spoerlein Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp redial unsuccessful
On Wed, Oct 04, 2006 at 03:37:37PM -0400, Nick Gustas wrote: On Wed, Oct 04, 2006 at 08:51:48PM +0200, Ulrich Spoerlein wrote: with my ADSL provider (a reseller of the german Telekom), I'm unable to make ppp redial after the link has been lost. With Telekom, you usually get disconnected every 24h hours, but you can simply reconnect if our ppp would support it. Have you added this to /etc/rc.conf? ppp_mode=ddial Yes of course, as you can see, ppp(8) is not exiting, but entering an redial endless loop ... Not that it helps you much, but I do see working pppoe redial behavior with Yahoo/ATT dsl at a client site in the US. I can unhook the dsl line and it will autoreconnect as soon as it's plugged in again. In the event of a provider outage it comes back up on its own. The current ppp session has been running for 59 days, longest session was 353 days, but the server had to be moved for remodeling. Same here. I've got some 6.1-STABLE boxes running since 70 days uninterrupted on german T-Com ADSL (PPPoE). ppp redials automatically without any problems there. The question is: did something change in the source of ppp or ng_pppoe in the mean time to cause breakage? I have currently no *physical* access to a fresh box on T-Com to confirm that previously working setup is now broken. ppp commandline: /usr/sbin/ppp -quiet -ddial -nat papchap Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp redial unsuccessful
) state = Opened Oct 4 03:07:24 fw ppp[219]: LCP: deflink: SendIdent(105) state = Opened Oct 4 03:07:24 fw ppp[219]: LCP: MAGICNUM 6607d07b Oct 4 03:07:24 fw ppp[219]: LCP: TEXT user-ppp 3.4.2 (built Jul 22 2006) Oct 4 03:07:24 fw ppp[219]: Phase: deflink: his = PAP, mine = none Oct 4 03:07:24 fw ppp[219]: Phase: Pap Output: X Oct 4 03:07:24 fw ppp[219]: LCP: deflink: RecvEchoReply(0) state = Opened Oct 4 03:07:24 fw ppp[219]: Phase: Pap Input: SUCCESS () Oct 4 03:07:24 fw ppp[219]: IPCP: Using trigger address 0.0.0.0 Oct 4 03:07:24 fw ppp[219]: CCP: FSM: Using deflink as a transport Oct 4 03:07:24 fw ppp[219]: CCP: deflink: State change Initial -- Closed Oct 4 03:07:24 fw ppp[219]: CCP: deflink: LayerStart. Oct 4 03:07:24 fw ppp[219]: CCP: MPPE: Not usable without CHAP81 Oct 4 03:07:24 fw ppp[219]: CCP: deflink: SendConfigReq(1) state = Closed Oct 4 03:07:24 fw ppp[219]: CCP: [EMPTY] Oct 4 03:07:24 fw ppp[219]: CCP: deflink: State change Closed -- Req-Sent Oct 4 03:07:24 fw ppp[219]: Phase: deflink: lcp - open Oct 4 03:07:24 fw ppp[219]: Phase: bundle: Network Oct 4 03:07:24 fw ppp[219]: IPCP: FSM: Using deflink as a transport Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: State change Initial -- Closed Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: LayerStart. Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: SendConfigReq(151) state = Closed Oct 4 03:07:24 fw ppp[219]: IPCP: IPADDR[6] 0.0.0.0 Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: State change Closed -- Req-Sent Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: RecvConfigReq(1) state = Req-Sent Oct 4 03:07:24 fw ppp[219]: IPCP: IPADDR[6] 222.222.222.222 Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: SendConfigAck(1) state = Req-Sent Oct 4 03:07:24 fw ppp[219]: IPCP: IPADDR[6] 222.222.222.222 Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: State change Req-Sent -- Ack-Sent Oct 4 03:07:24 fw ppp[219]: LCP: deflink: RecvProtocolRej(2) state = Opened Oct 4 03:07:24 fw ppp[219]: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected! Oct 4 03:07:24 fw ppp[219]: CCP: deflink: State change Req-Sent -- Stopped Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: RecvConfigNak(151) state = Ack-Sent Oct 4 03:07:24 fw ppp[219]: IPCP: IPADDR[6] 111.222.111.222 Oct 4 03:07:24 fw ppp[219]: IPCP: IPADDR[6] changing address: 0.0.0.0 -- 111.222.111.222 Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: SendConfigReq(152) state = Ack-Sent Oct 4 03:07:24 fw ppp[219]: IPCP: IPADDR[6] 111.222.111.222 Oct 4 03:07:24 fw ppp[219]: LCP: deflink: RecvProtocolRej(3) state = Opened Oct 4 03:07:24 fw ppp[219]: LCP: deflink: -- Protocol 0x8057 (Internet Protocol V6 Control Protocol) was rejected! Oct 4 03:07:24 fw ppp[219]: Phase: deflink: IPV6CP protocol reject closes IPV6CP ! Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: RecvConfigAck(152) state = Ack-Sent Oct 4 03:07:24 fw ppp[219]: IPCP: IPADDR[6] 111.222.111.222 Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: State change Ack-Sent -- Opened Oct 4 03:07:24 fw ppp[219]: IPCP: deflink: LayerUp. Oct 4 03:07:24 fw ppp[219]: IPCP: myaddr 111.222.111.222 hisaddr = 222.222.222.222 Oct 4 03:07:25 fw ppp[219]: LCP: deflink: RecvEchoRequest(1) state = Opened Oct 4 03:07:25 fw ppp[219]: LCP: deflink: SendEchoReply(1) state = Opened Oct 4 03:07:54 fw ppp[219]: LCP: deflink: SendEchoRequest(1) state = Opened Oct 4 03:07:54 fw ppp[219]: LCP: deflink: RecvEchoReply(1) state = Opened Here's /etc/ppp/ppp.conf: default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) isp-dsl: set device PPPoE:sis0 #set MTU 1492 #set MRU 1492 set MTU 1460 set MRU 1460 set dial set crtscts off set speed sync #accept lqr #enable lqr #enable lqr echo disable lqr set echoperiod 30 enable echo disable deflate disable pred1 disable vjcomp disable acfcomp disable protocomp set log Phase LCP IPCP CCP Warning Error Alert set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 set login set authname X set authkey set timeout 0 add default HISADDR set server /var/run/internet 0177 Ulrich Spoerlein Good luck! -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/midi and /dev/sequencer
On Wed, Aug 24, 2005 at 11:02:04AM +0100, Ben Paley wrote: On Wednesday 24 August 2005 04:27, Robert Backhaus wrote: On 8/24/05, Ben Paley [EMAIL PROTECTED] wrote: Hello, I'm running 5.4-STABLE, cvsupped and everything rebuilt Mon Aug 22. Does anyone know what's happening with MIDI? I've got no /dev/midi or /dev/sequencer and don't know if it's even possible to turn them on in the kernel at the moment. I've also managed to compile and run Rosegarden-4 - it claims to work with arts instead of ALSA but I'm not having any luck starting it with sequencer or midi... any ideas? Thanks, Ben There is slow work being done by one developer to reestablish midi. A set of patches was posted here for 5.4, and they aparently worked. I couldn't get them to compile on CURRENT, though. I was not able to locate a site on it, and the patch was posted to this list on Apr 26 by conrads(a)cox.net . He may be able to find you a later patch set from Mat. Perhaps running some linux distro under qemu which supports MIDI could temporarily help? Anyone tried this? Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with 5.4-RELEASE when typing on console?
On Fri, May 06, 2005 at 07:59:03PM -0400, Scott Ullrich wrote:
I cvsupped a bit ago and now when I type on the console I get a panic:
[...]
Has anyone seen this problem or could this be something on my end?
Could that be related to the recent heads up?
HEADS-UP: Problem with RELENG_5{_4}
Scott
-cpghost.
--
Cordula's Web. http://www.cordula.ws/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Can't kldload pf
Hello, on RELENG_5, cvsupped March 9th, I can't kldload pf: fw# kldload pf kldload: can't load pf: No such file or directory fw# kldload /boot/kernel/pf.ko kldload: can't load /boot/kernel/pf.ko: No such file or directory fw# kldstat Id Refs AddressSize Name 16 0xc040 2a8a44 kernel 21 0xc0c28000 6000 geom_bde.ko 34 0xc0d14000 12000netgraph.ko 42 0xc0d2a000 4000 ng_ether.ko 51 0xc0d2f000 7000 ng_pppoe.ko 61 0xc0d37000 5000 ng_socket.ko fw# ls -l /boot/kernel/pf* -r-xr-xr-x 1 root wheel 170382 Mar 10 17:18 /boot/kernel/pf.ko fw# sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules Attached is the kernel config file. Any idea what's going wrong here? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ # SOEKRIS kernel config file. machine i386 #cpuI386_CPU cpu I486_CPU cpu I586_CPU ident SOEKRIS options CPU_SOEKRIS #Enable Soekris hardware stuff. options CPU_GEODE #GEODE GL1100 Chips (Soekris) #device pf #Enable PF. options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking #optionsINET6 # InterNETworking V6. options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=8000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. #device apic# I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives options ATA_STATIC_ID # Static device numbering device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device miibus # MII bus support device sis # Silicon Integrated Systems SiS 900/SiS 7016 # Pseudo devices. device loop# Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory disks # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device usb # USB Bus (required) #device udbp# USB Double Bulk Pipe devices device ugen# Generic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't kldload pf
On Thu, Mar 10, 2005 at 07:13:51PM +0100, Max Laier wrote: On Thursday 10 March 2005 18:52, [EMAIL PROTECTED] wrote: on RELENG_5, cvsupped March 9th, I can't kldload pf: fw# kldload pf kldload: can't load pf: No such file or directory You don't have options INET6 in your kernel config, but the pf module assumes that it is there. You can either built pf into the kernel (since you are building a custom kernel anyway), rebuild the module without that assumption (see the module's Makefile) or you can reenable options INET6 in the kernel. Yes, INET6 is needed indeed. That was the catch! Adding options INET6 solved the problem. The ENOENT error returned from kldload is a bit misleading, though. Ugh... yes ;). Perhaps that should be documented in pf(4)? Thanks a lot! -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News Kind regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't kldload pf
On Fri, Mar 11, 2005 at 09:34:00AM +1030, Daniel O'Connor wrote: On Fri, 11 Mar 2005 08:33, [EMAIL PROTECTED] wrote: On Thu, Mar 10, 2005 at 07:13:51PM +0100, Max Laier wrote: On Thursday 10 March 2005 18:52, [EMAIL PROTECTED] wrote: on RELENG_5, cvsupped March 9th, I can't kldload pf: fw# kldload pf kldload: can't load pf: No such file or directory You don't have options INET6 in your kernel config, but the pf module assumes that it is there. You can either built pf into the kernel (since you are building a custom kernel anyway), rebuild the module without that assumption (see the module's Makefile) or you can reenable options INET6 in the kernel. Yes, INET6 is needed indeed. That was the catch! Adding options INET6 solved the problem. The ENOENT error returned from kldload is a bit misleading, though. Ugh... yes ;). Perhaps that should be documented in pf(4)? It's not pf per se.. If you ran dmesg after your kldload attempts you'd see the kernel linker complaining about being unable to resolve some IPv6 related symbols. Other possibility is to do.. cd /usr/src/sys/modules/pf make NO_INET6= install and load it again. Interesting. I'll try this next time. Many thanks, -cpghost. Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HZ=1000 on slow CPUs considered harmful?
On Tue, Feb 22, 2005 at 07:56:03PM +, Robert Watson wrote: In 6-CURRENT, HZ is 1000 for amd64, i386, and ia64, but 100 for other platforms (i.e., ppc, arm, and alpha). I'm not opposed to merging the HZ change to RELENG_5 at some point, but given that occasional nits, such as the TCP nit, are turning up, I think it's worth waiting until after 5.4. Wouldn't that be a problem for slow CPUs like VIA C3 (EPIA) or GEODE (Soekris)? For fast CPUs, it's not that much overhead, but for slow CPUs? Can HZ remain user-configurable? Robert N M Watson Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp -nat broken [solved]
On Fri, Oct 29, 2004 at 09:52:51AM +0200, Peter Ulrich Kruppa wrote:
On Tue, 26 Oct 2004, Peter Ulrich Kruppa wrote:
learn that named and BIND have changed. I did the respective
changes and edited two entries in /var/named/etc/named/named.conf
1) I commented
listen-on {127.0.0.1;};
Instead of opening a 53/tcp, 53/udp port to the world (ANYADDR),
you may prefer to restrict the address range to your internal LAN only,
with something like (replace 192.168.10.0/24 accordingly):
listen-on { 127.0.0.1; 192.168.10.0/24; };
Check with 'sockstat -46' to be sure.
2) I put my two nameserver IPs (from /etc/resolv.conf) into
forwarders {
195.62.99.42;
195.62.97.177;
};
They are not absolutely necessary: named is perfectly able to
query root and other servers itself. You could experiment with
or without forwarders, and pick the configuration that is faster
for you. As a general rule of thumb: Forwarders are good for
recursive queries, because only one query will travel through
your ADSL link, other queries being done by your ISPs nameservers.
They are also good, because you can profit from your ISPs nameservers'
cache. But they can hinder performance, should one or both of those
nameservers be down for whatever reason.
Cheers,
cpghost.
--
Cordula's Web. http://www.cordula.ws/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp -nat broken???
On Wed, Oct 27, 2004 at 05:11:54PM +0200, Samuel Trommel wrote: Primary nameserver 195.62.99.42 Secundary nameserver 195.62.97.177 Yes, that works, thank you so far, but ... I never had to do this before this way. I always simply set my gateway as name-server and I wonder what has changed the last week or so. Just imagine, I had to upgrade our school's gateway/proxy (which And that is where dhcpd comes in to play:D Just setup a DHCP-server and you are done.. Well, sorry to chime in here, but you're just suggesting a work around, not a real solution (which is to be running a caching named on the gateway machine). Uli, could you check if your named works as expected? The following applies to 5.x, adjust as necessary for 4.x: 1. does named indeed run on the gateway? gw# ps ax | grep named 277 ?? Ss 8:29.33 /usr/sbin/named -u bind -t /var/named 18582 ?? Ss 1:54.00 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/r 81756 p1 S+ 0:00.02 grep named 2. does named listen on all relevant interfaces (sockstat -46)? You should get something like this: gw# sockstat -46 | grep bind bind named 277 20 udp4 192.168.254.1:53 *:* bind named 277 21 tcp4 192.168.254.1:53 *:* bind named 277 22 udp4 127.0.0.1:53 *:* bind named 277 23 tcp4 127.0.0.1:53 *:* bind named 277 24 udp4 *:59582 *:* bind named 277 25 tcp4 127.0.0.1:953 *:* (one random port must be open to the outside world, so named can get replies (?), other ports must be open to the inside net(s)) 3. using dig from the gateway, querying the local named, whan happens? 4. using dig from a host != gateway (on your local net), what happens? 5. Can you ping outside NUMERICAL IP address from your local net? % ping 66.94.229.254(www.altavista.com) Regards, cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp -nat broken???
On Wed, Oct 27, 2004 at 11:42:08PM +0200, Samuel Trommel wrote: You should have read the whole thread first cpghost:) Ah... yes! You're right. I've missed the first few entries. My mistake. Please disregard. Sorry, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
