Re: Recent Problems with RELENG_7 i386
--- On Thu, 10/9/08, Jeremy Chadwick [EMAIL PROTECTED] wrote: From: Jeremy Chadwick [EMAIL PROTECTED] Subject: Re: Recent Problems with RELENG_7 i386 To: bf [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Date: Thursday, October 9, 2008, 1:12 AM On Wed, Oct 08, 2008 at 10:00:32PM -0700, bf wrote: --- On Wed, 10/8/08, Jeremy Chadwick [EMAIL PROTECTED] wrote: From: Jeremy Chadwick [EMAIL PROTECTED] Subject: Re: Recent Problems with RELENG_7 i386 To: bf [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Date: Wednesday, October 8, 2008, 2:36 PM On Wed, Oct 08, 2008 at 10:19:47AM -0700, bf wrote: After updating to RELENG_7 i386 of this weekend, I have been having problems with my machine. When booting normally, the system slows or hangs at the login prompt. If I am able to continue past the prompt, I sometimes experience erratic mouse behavior, and a subsequent hang, after varying lengths of time, even under light workloads. The same problem does not seem to occur in single-user mode, and did not occur with the RELENG_7 i386 of just over a week ago. I have been unable to obtain crashdumps so far, and the only log messages I can find that weren't present before are notices like those recorded below: Oct 8 11:00:40 myhost kernel: t_delta 15.fd80bdcb75b60200 too short This comes from src/sys/kern/kern_tc.c, around line 908. I'm not familiar with the kernel, but two ideas come to mind: 1) If you have Intel SpeedStep (EIST) or AMD Cool'n'Quiet enabled in your BIOS, try disabling it, 2) If you're using powerd, disable it (I don't see it enabled), 3) Try keeping HZ at 1000 (the default). Thanks, Jeremy, for taking the time to consider my question and reply. My CPU is pre-Cool'n'Quiet, and as far as I can tell I had disabled all forms of power management that may affect the clock speeds. I have found that by raising kern.hz to 250, or by using the default, I no longer receive the t_delta is too short messages, and the other problems are no longer apparent. My question is: why did this occur now? I don't know. We can't rewind time and find out system parameters and kernel details from 6 months ago. :-) Well, actually, with version control, we can -- if we're willing to take the trouble. My local settings haven't changed much, and the load we're talking about is not some pattern lost in the mists of time, but simply booting up. But I'm not suggesting going to any such lengths: the changed behavior occurred after the most recent changes to RELENG_7, in the past two weeks or less. Like you, I haven't taken the time to delve into the inner workings of the kernel, and so I was hoping that someone who had been monitoring RELENG_7's behavior (it's being tested before-and-after commits fairly often during this pre-release freeze, right?) or someone who had made recent changes might be able to narrow it down even further, either by pointing to some changes that might have tipped my machine over the edge at kern.hz=100, or by ruling out FreeBSD changes entirely and pointing the finger at some hardware problem. Some of the related sysctls are: kern.timecounter.tick: 1 kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-safe kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 4294967295 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-safe.mask: 16777215 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.ACPI-safe.quality: 850 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.frequency: 906349154 kern.timecounter.tc.TSC.quality: 800 vfs.timestamp_precision: 0 machdep.acpi_timer_freq: 3579545 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.attimer.0.%desc: AT realtime clock dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.PIB_.RTC_ dev.attimer.0.%pnpinfo: _HID=PNP0B00 _UID=0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%desc: AT timer dev.attimer.1.%driver: attimer dev.attimer.1.%location: handle=\_SB_.PCI0.PIB_.TIME dev.attimer.1.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.1.%parent: acpi0 dev.pmtimer.0.%driver: pmtimer dev.pmtimer.0.%parent: isa0 and my original message showed how some of the timers were handled during booting up. I don't think these have changed since 12 Sept., when jhb@ changed local_apic.c in SVN rev 182982. So that change _alone_ would not have caused my problem. More recently, kib@ committed changes to db_trace.c, devfs, vm, ata, and to various kernel routines; and rwatson@ made changes to udp, tcp, sockets, and ipfw. Regards, b.
Re: Problem with dump stalling
On Wed, Oct 08, 2008, David Peall wrote: I'm running 7.0-RELEASE-p4 and trying to backup to an external USB drive. I'm using the following command dump -a0Lf /backup/diskimages/root /dev/mfid0s1a [...] But it just stops at a random percentage, the system continues to run and the processes are killable? This is a know bug which mainly affects multi-core CPU systems. It is fixed in RELENG_7, see also PR bin/121684 [1] where the relevant patch is referenced. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/121684 -cs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with dump stalling
On Thu, Oct 09, 2008 at 12:08:17PM +0200, Christoph Schug wrote: On Wed, Oct 08, 2008, David Peall wrote: I'm running 7.0-RELEASE-p4 and trying to backup to an external USB drive. I'm using the following command dump -a0Lf /backup/diskimages/root /dev/mfid0s1a [...] But it just stops at a random percentage, the system continues to run and the processes are killable? This is a know bug which mainly affects multi-core CPU systems. It is fixed in RELENG_7 see also PR bin/121684 [1] where the relevant patch is referenced. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/121684 This was fixed on HEAD in revision 1.48 (March 13th), with the comment MFC: 1 week. The commit to RELENG_7 did not happen until April 19th, see revision 1.39.2.3: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c The PR referenced in the CVS commit is PR 117603. David, can you verify you're using a version of src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? If so, the problem David is experiencing is different. If not, David will need to csup and then rebuild world and kernel (do NOT just do one; do both) to pick up the changes. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sidetrack [was Re: 'at now' not working as expected]
On Thu, 9 Oct 2008, Andrew D wrote: Ian Smith wrote: On Wed, 8 Oct 2008, Peter Wemm wrote: [..] My tolerance for hacking at(1) code was exceeded when I added hacks for 'at sunrise' and 'at sunset' support to a local version. It wasn't pretty, especially when handling things like '30 minutes before sunrise' etc. (I use this for home automation stuff) Peter, just curious .. from where do you pull the current sunrise/sunset info for your location, and in what form? In Australia, you get it from Geoscience Australia. http://www.ga.gov.au/geodesy/astro/sunrise.jsp Just need a few curl queries and then extract the required info from the html source :) HTH Sure does, thanks Andrew. Saved as text, very amenable to a bit of grep 'n awking. Took transit times too, useful for calibrating solar clocks. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sidetrack [was Re: 'at now' not working as expected]
Hi Ian, Ian Smith wrote: On Wed, 8 Oct 2008, Peter Wemm wrote: [..] My tolerance for hacking at(1) code was exceeded when I added hacks for 'at sunrise' and 'at sunset' support to a local version. It wasn't pretty, especially when handling things like '30 minutes before sunrise' etc. (I use this for home automation stuff) Peter, just curious .. from where do you pull the current sunrise/sunset info for your location, and in what form? In Australia, you get it from Geoscience Australia. http://www.ga.gov.au/geodesy/astro/sunrise.jsp Just need a few curl queries and then extract the required info from the html source :) HTH cya Andrew cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with dump stalling
On Thu, Oct 09, 2008 at 01:58:39PM +0200, David Peall wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Jeremy Chadwick Sent: 09 October 2008 12:45 PM To: Christoph Schug Cc: freebsd-stable@freebsd.org; David Peall Subject: Re: Problem with dump stalling This was fixed on HEAD in revision 1.48 (March 13th), with the comment MFC: 1 week. The commit to RELENG_7 did not happen until April 19th, see revision 1.39.2.3: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c The PR referenced in the CVS commit is PR 117603. David, can you verify you're using a version of src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? If so, the problem David is experiencing is different. If not, David will need to csup and then rebuild world and kernel (do NOT just do one; do both) to pick up the changes. I'm using stable: FreeBSD ochre.school.za 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #0: Tue Sep 2 18:48:24 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 I don't update via source only via binaries, how would I tell? I'm not sure. I don't use freebsd-update, so I don't do binary-only upgrades. Someone else will have to chime in here for assistance. But I can tell you that freebsd-update does not get all the updates to certain things. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sidetrack
Andrew D [EMAIL PROTECTED] writes: Hi Ian, Ian Smith wrote: On Wed, 8 Oct 2008, Peter Wemm wrote: [..] My tolerance for hacking at(1) code was exceeded when I added hacks for 'at sunrise' and 'at sunset' support to a local version. It wasn't pretty, especially when handling things like '30 minutes before sunrise' etc. (I use this for home automation stuff) Peter, just curious .. from where do you pull the current sunrise/sunset info for your location, and in what form? In Australia, you get it from Geoscience Australia. http://www.ga.gov.au/geodesy/astro/sunrise.jsp Just need a few curl queries and then extract the required info from the html source :) You can get and hack the code they're using, too. On your Freebsd box, you can use astro/sscalc among a bunch of other ways of calculating the solar data. [My favorite example: emacs has lisp code for doing it, with glue for using it in the diary mode] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Userland PPP not deleting old IP on disconnect
Hi, I am using userland PPP to do PPPoE and I am finding that it isn't deleting the old IP from tun0 when the link goes down, eg Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: logout - hangup Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: Connect time: 950 secs: 2711068 octets in, 39993514 octets out [midget 22:00] ~ ifconfig tun0 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1500 inet 121.45.251.180 -- 203.16.215.184 netmask 0x Opened by PID 53728 I have the following config.. default: set device /dev/cuaa0 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ AT \ OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT set speed 115200 set ctsrts on set server /var/run/ppp/tun%d foobar set urgent tcp 22 set urgent udp 27010 27011 27012 27013 27014 27015 27016 27017 27018 27019 27020 27960 14577 14578 14579 14580 set log Phase Chat IPCP CCP tun command connect internode: set device PPPoE:em0 set ifaddr 0.0.0.0/0 0.0.0.0/0 resolv readonly disable pap enable dns set cd 5 set dial set login set redial 5+30-120 0 enable lqr enable echo set lqrperiod 3 set reconnect 10 10 set authname username set authkey password add default HISADDR I don't have any linkup/linkdown scripts.. Any one have an idea why this would be happening? System is a FreeBSD midget.dons.net.au 7.0-STABLE FreeBSD 7.0-STABLE #1: Sun Jun 1 19:20:18 CST 2008 [EMAIL PROTECTED]:/data/obj/data/src/sys/GENERIC i386 Thanks. -- 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 signature.asc Description: This is a digitally signed message part.
Re: Userland PPP not deleting old IP on disconnect
Hi Fellow Node user :), I have the same + similar issue. Daniel O'Connor wrote: Hi, I am using userland PPP to do PPPoE and I am finding that it isn't deleting the old IP from tun0 when the link goes down, eg Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: logout - hangup Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: Connect time: 950 secs: 2711068 octets in, 39993514 octets out [midget 22:00] ~ ifconfig tun0 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1500 inet 121.45.251.180 -- 203.16.215.184 netmask 0x Opened by PID 53728 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492 inet 121.45.215.128 -- 203.16.215.183 netmask 0x inet 121.45.69.26 -- 203.16.215.186 netmask 0x Opened by PID 90863 The second line only shows up when the gateway is different between IP assignments from the ISP. I have no idea if this blocks access to the previous IP, not that it's a major issue. uname -a FreeBSD gateway.abdulla 7.0-STABLE FreeBSD 7.0-STABLE #1: Sat Jun 21 03:10:37 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERN i386 My ppp setup is almost the same. Cheers cya Andrew I have the following config.. default: set device /dev/cuaa0 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ AT \ OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT set speed 115200 set ctsrts on set server /var/run/ppp/tun%d foobar set urgent tcp 22 set urgent udp 27010 27011 27012 27013 27014 27015 27016 27017 27018 27019 27020 27960 14577 14578 14579 14580 set log Phase Chat IPCP CCP tun command connect internode: set device PPPoE:em0 set ifaddr 0.0.0.0/0 0.0.0.0/0 resolv readonly disable pap enable dns set cd 5 set dial set login set redial 5+30-120 0 enable lqr enable echo set lqrperiod 3 set reconnect 10 10 set authname username set authkey password add default HISADDR I don't have any linkup/linkdown scripts.. Any one have an idea why this would be happening? System is a FreeBSD midget.dons.net.au 7.0-STABLE FreeBSD 7.0-STABLE #1: Sun Jun 1 19:20:18 CST 2008 [EMAIL PROTECTED]:/data/obj/data/src/sys/GENERIC i386 Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problem with dump stalling
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Jeremy Chadwick Sent: 09 October 2008 12:45 PM To: Christoph Schug Cc: freebsd-stable@freebsd.org; David Peall Subject: Re: Problem with dump stalling This was fixed on HEAD in revision 1.48 (March 13th), with the comment MFC: 1 week. The commit to RELENG_7 did not happen until April 19th, see revision 1.39.2.3: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c The PR referenced in the CVS commit is PR 117603. David, can you verify you're using a version of src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? If so, the problem David is experiencing is different. If not, David will need to csup and then rebuild world and kernel (do NOT just do one; do both) to pick up the changes. I'm using stable: FreeBSD ochre.school.za 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #0: Tue Sep 2 18:48:24 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 I don't update via source only via binaries, how would I tell? Regards -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problem with dump stalling
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Jeremy Chadwick Sent: 09 October 2008 12:45 PM To: Christoph Schug Cc: freebsd-stable@freebsd.org; David Peall Subject: Re: Problem with dump stalling This was fixed on HEAD in revision 1.48 (March 13th), with the comment MFC: 1 week. The commit to RELENG_7 did not happen until April 19th, see revision 1.39.2.3: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c The PR referenced in the CVS commit is PR 117603. David, can you verify you're using a version of src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? If so, the problem David is experiencing is different. If not, David will need to csup and then rebuild world and kernel (do NOT just do one; do both) to pick up the changes. I have two identical machines the second one is displaying the same problems. I'm going to do a cvsup update and build work and kernel, the only partition on this server that is UFS is the /boot/ partition as its running ZFS on the others yet is still fails the dump that. If there is anyone willing to dedicate some time to this problem I will assist where I can? Regards -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help me to develop a FreeBSD patch for gcc-4.2.1
--- On Wed, 10/8/08, Alexander Kabaev [EMAIL PROTECTED] wrote: If you still have CVS tree available, you can do 'cvs diff -rFSF' in contrib/gcc and apply the patches to files gcc-4.2.1/gcc. Hi Alexander Here is how I made the patch: cd ~ mkdir -pv freebsd cd freebsd cvs -d [EMAIL PROTECTED]:/home/ncvs co -rRELENG_7 src cvs diff -rFSF FreeBSD-gcc-4.2.1.patch I have applied the patch on a fresh copy of gcc-4.2.1 and compiled. As before it develops errors: ../../gcc-4.2.1/gcc/c-format.c: In function 'check_format_info_main': ../../gcc-4.2.1/gcc/c-format.c:1780: error: 'flag_format_extensions' undeclared (first use in this function) ../../gcc-4.2.1/gcc/c-format.c:1780: error: (Each undeclared identifier is reported only once ../../gcc-4.2.1/gcc/c-format.c:1780: error: for each function it appears in.) gmake[2]: *** [c-format.o] Error 1 Have I missed out something? Could you help me to move forward from here? For an example, I can over come the above error by adding following lines to the gcc-4.2.1/gcc/config/i386/i386.opt: fformat-extensions Common Report Var(flag_format_extensions) Init(0) Allow FreeBSD kernel-specific printf format specifiers. Is that the correct move forward? Best regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with dump stalling
On Thu, Oct 09, 2008 at 01:58:39PM +0200, David Peall wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Jeremy Chadwick Sent: 09 October 2008 12:45 PM To: Christoph Schug Cc: freebsd-stable@freebsd.org; David Peall Subject: Re: Problem with dump stalling This was fixed on HEAD in revision 1.48 (March 13th), with the comment MFC: 1 week. The commit to RELENG_7 did not happen until April 19th, see revision 1.39.2.3: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c The PR referenced in the CVS commit is PR 117603. David, can you verify you're using a version of src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? If so, the problem David is experiencing is different. If not, David will need to csup and then rebuild world and kernel (do NOT just do one; do both) to pick up the changes. I'm using stable: FreeBSD ochre.school.za 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #0: Tue Sep 2 18:48:24 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 I don't update via source only via binaries, how would I tell? Regards Try running: ident /boot/kernel/kernel | grep subr_sleepqueue That should give you the CVS id for the appropriate file Regards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent Problems with RELENG_7 i386
On Wed, 8 Oct 2008, Jeremy Chadwick wrote: On Wed, Oct 08, 2008 at 10:00:32PM -0700, bf wrote: --- On Wed, 10/8/08, Jeremy Chadwick [EMAIL PROTECTED] wrote: [..] Oct 8 11:00:40 myhost kernel: t_delta 15.fd80bdcb75b60200 too short This comes from src/sys/kern/kern_tc.c, around line 908. I'm not familiar with the kernel, but two ideas come to mind: 1) If you have Intel SpeedStep (EIST) or AMD Cool'n'Quiet enabled in your BIOS, try disabling it, 2) If you're using powerd, disable it (I don't see it enabled), 3) Try keeping HZ at 1000 (the default). Thanks, Jeremy, for taking the time to consider my question and reply. My CPU is pre-Cool'n'Quiet, and as far as I can tell I had disabled all forms of power management that may affect the clock speeds. I have found that by raising kern.hz to 250, or by using the default, I no longer receive the t_delta is too short messages, and the other problems are no longer apparent. My question is: why did this occur now? I don't know. We can't rewind time and find out system parameters and kernel details from 6 months ago. :-) I'm thinking it might have something to do with the timecounter selected by the kernel, but as I said, we can't rewind time to find out what things were in the past. The kernel environment variables I'm talking about are kern.timecounter. sysctl kern.timecounter could help shed some light here, maybe. It would at least allow us to see what timecounters are available on your system, and if a bad/unreliable one is being selected automatically. I see bf has since posted these values, but I'd already clipped stuff from the original post with kernel config and verbose dmesg, already wondering why the two didn't match, like: | options HZ=1000 | options DEVICE_POLLING but | CPU: AMD Athlon(tm) Processor (906.35-MHz 686-class CPU) | Timecounter ACPI-safe frequency 3579545 Hz quality 850 | inittimecounter(0)... Timecounters tick every 10.000 msec ie HZ=100, as mentioned, and using ACPI-safe as later confirmed. So it's either a different kernel or bf updated kern.hz from loader.conf? I have been using a similar configuration for months now without any apparent problems. My original goal in using a lower kern.hz was to avoid burdening my machine with excessive context switching. This is over my head, technically. I would need to pull John Baldwin into this, since he knows a bit about both (timecounters and context switching). I'm just a simple caveman. :-) Me too, but as I get to run much slower gear than many here, I have some small insight into what timer ticks work well with older kit. Not that a 900MHz Athlon should have any trouble with HZ=1000 at all, whereas on a 300MHz Celeron that's way too fast, pushing idle load up considerably. I saw the relevant section of kern_tc.c before I wrote my first message, but when skimming through the changes in RELENG_7 over the past week or two, I couldn't see any commit that may have directly affected kernel timekeeping. Has some new workload been imposed on the system by recent changes, that may have made a kern.hz of 100 insufficient? Is this tuneable setting properly implemented, so that all parts of the base system are using it's current value rather than the default? Could some of my hardware, such as my RTC, be malfunctioning? Well, I believe HZ was increased from 100 to 1000 long ago (RELENG_6?) as a default. I'm really not sure of the implications of decreasing it, besides having less granularity for some things (the only things I know of would be something pertaining to firewalls, I just can't remember what. My brain is full. :-) ) You need a day off :) But yes, RELENG_5 still had HZ=100 default, long after the 'average' CPU clock frequency was 10 or more times faster than the 166MHz Pentiums and such (mostly then on only 100Mbps ethernet) that were comfortable at 100Hz slicing. 1000Hz was a big shift to catch up. In a day or so playing around with it years ago, I found 200-250Hz good for 300MHz, 500Hz a bit much, 1000Hz way too busy, and find my 1133MHz P3-M happy enough at 1000Hz, though I've done no specific tests on it. Some people had perhaps similar clock issues when their fast processors were throttling/stepping down to very low speeds (100, even 75MHz) while still slicing at 1000Hz, which I didn't find too surprising. Limiting minimum CPU freq to 300Mz or more seemed to solve many such issues, but I haven't your perseverance for digging up the relevant threads .. Even in 5.5-S (/sys/conf/NOTES and /sys/i386/conf/NOTES) HZ=1000 or 2000 was suggested for DEVICE_POLLING (which bf included in config, though maybe it's not enabled?) and HZ=1000 or more was recommended when using DUMMYNET with ipfw - to provide smoother queue dispatching, I gather.
Re: Recent Problems with RELENG_7 i386
On Fri, Oct 10, 2008 at 03:51:02AM +1100, Ian Smith wrote: I see bf has since posted these values, but I'd already clipped stuff from the original post with kernel config and verbose dmesg, already wondering why the two didn't match, like: | options HZ=1000 | options DEVICE_POLLING but | CPU: AMD Athlon(tm) Processor (906.35-MHz 686-class CPU) | Timecounter ACPI-safe frequency 3579545 Hz quality 850 | inittimecounter(0)... Timecounters tick every 10.000 msec ie HZ=100, as mentioned, and using ACPI-safe as later confirmed. So it's either a different kernel or bf updated kern.hz from loader.conf? Yep -- his original mail had loader.conf shown, with this in it (near the bottom): kern.hz=100 Well, I believe HZ was increased from 100 to 1000 long ago (RELENG_6?) as a default. I'm really not sure of the implications of decreasing it, besides having less granularity for some things (the only things I know of would be something pertaining to firewalls, I just can't remember what. My brain is full. :-) ) You need a day off :) But yes, RELENG_5 still had HZ=100 default, long after the 'average' CPU clock frequency was 10 or more times faster than the 166MHz Pentiums and such (mostly then on only 100Mbps ethernet) that were comfortable at 100Hz slicing. 1000Hz was a big shift to catch up. In a day or so playing around with it years ago, I found 200-250Hz good for 300MHz, 500Hz a bit much, 1000Hz way too busy, and find my 1133MHz P3-M happy enough at 1000Hz, though I've done no specific tests on it. Some people had perhaps similar clock issues when their fast processors were throttling/stepping down to very low speeds (100, even 75MHz) while still slicing at 1000Hz, which I didn't find too surprising. Limiting minimum CPU freq to 300Mz or more seemed to solve many such issues, but I haven't your perseverance for digging up the relevant threads .. Even in 5.5-S (/sys/conf/NOTES and /sys/i386/conf/NOTES) HZ=1000 or 2000 was suggested for DEVICE_POLLING (which bf included in config, though maybe it's not enabled?) and HZ=1000 or more was recommended when using DUMMYNET with ipfw - to provide smoother queue dispatching, I gather. Bottom line, IMHO, bf should probably run the default 1000Hz, 500 at least, on an Athlon 900. With powerd, maybe set min. freq = 150MHz? Wow, this is fantastic information. You've just educated me a great bit about the history and use of HZ. I've always had a general idea of its importance and key role, but I was never fully aware of the history. P.S. -- I need more like 6 months off. I've never taken an official (read: real) vacation my entire life. Maybe some day I'll get to travel to Seoul and visit Pyun Yong-Hyeon and drink lots of soju. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stable 7.0 and nslookup help command
Kevin Oberman wrote: More importantly, dig(1) uses the standard resolver routines while nslookup has its own. Actually you have that backwards. :) dig generates a raw dns request packet and sends it out on the wire itself, more or less acting as if it were an actual name server. Therefore if you are trying to debug problems with a name server it is the better choice. host uses the name servers in /etc/resolv.conf and more or less acts as a local stub resolver. It's a good choice if you just want to get the answer to what does this resolve to? It's also a good tool for debugging what's happening when an application on your system is getting an answer other than the one you think it should get. nslookup actually uses the local stub resolver, and has the benefit of having been around a long time so it's something people know. It's also a good tool to debug the local stub resolver if you're getting an answer other than what you think you should be getting, and/or different from what dig/host say. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
7.1 i386 PXE
Hi, list I tryin update my install server. Look like 7.1 i386 pxe boot broken. My own release build is 7.1-i386-2008-10-05 Could somebody test this functionality and confirm or disprove my results. WBR Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.1 i386 PXE
On Thu, Oct 09, 2008 at 09:08:42PM +0400, Dmitriy Kirhlarov wrote: I tryin update my install server. Look like 7.1 i386 pxe boot broken. My own release build is 7.1-i386-2008-10-05 Could somebody test this functionality and confirm or disprove my results. What's broken about it? What behaviour happens? Are you aware of the mfsroot bug (see step 7 below): http://jdc.parodius.com/freebsd/pxeboot_serial_install.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent Problems with RELENG_7 i386
On Thu, 9 Oct 2008, Jeremy Chadwick wrote: On Fri, Oct 10, 2008 at 03:51:02AM +1100, Ian Smith wrote: Well, I believe HZ was increased from 100 to 1000 long ago (RELENG_6?) as a default. I'm really not sure of the implications of decreasing it, besides having less granularity for some things (the only things I know of would be something pertaining to firewalls, I just can't remember what. My brain is full. :-) ) You need a day off :) But yes, RELENG_5 still had HZ=100 default, long after the 'average' CPU clock frequency was 10 or more times faster than the 166MHz Pentiums and such (mostly then on only 100Mbps ethernet) that were comfortable at 100Hz slicing. 1000Hz was a big shift to catch up. In a day or so playing around with it years ago, I found 200-250Hz good for 300MHz, 500Hz a bit much, 1000Hz way too busy, and find my 1133MHz P3-M happy enough at 1000Hz, though I've done no specific tests on it. Some people had perhaps similar clock issues when their fast processors were throttling/stepping down to very low speeds (100, even 75MHz) while still slicing at 1000Hz, which I didn't find too surprising. Limiting minimum CPU freq to 300Mz or more seemed to solve many such issues, but I haven't your perseverance for digging up the relevant threads .. Even in 5.5-S (/sys/conf/NOTES and /sys/i386/conf/NOTES) HZ=1000 or 2000 was suggested for DEVICE_POLLING (which bf included in config, though maybe it's not enabled?) and HZ=1000 or more was recommended when using DUMMYNET with ipfw - to provide smoother queue dispatching, I gather. Bottom line, IMHO, bf should probably run the default 1000Hz, 500 at least, on an Athlon 900. With powerd, maybe set min. freq = 150MHz? Wow, this is fantastic information. You've just educated me a great bit about the history and use of HZ. I've always had a general idea of its importance and key role, but I was never fully aware of the history. Not to pull this too much further OT, but in the original message there was a comment about HZ and context switching. I care for a number of FBSD boxes that are stuffed full of qmail processes. Context switches are always through the roof when the boxes are busy. My layman's understanding of context switching is very vague - in short I assume it's some type of overhead from the kernel having to move between servicing different processes. Altering HZ to tune this is very intriguing to me, so if anyone would like to explain, I'm all ears. P.S. -- I need more like 6 months off. I've never taken an official (read: real) vacation my entire life. Maybe some day I'll get to travel to Seoul and visit Pyun Yong-Hyeon and drink lots of soju. :-) Join the f***ing club. I'm still waiting for my honeymoon after two years of being married. :) Charles -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.1 i386 PXE
Hi Dmitriy, On Thu, Oct 09, 2008 at 09:08:42PM +0400, Dmitriy Kirhlarov wrote: I tryin update my install server. Look like 7.1 i386 pxe boot broken. My own release build is 7.1-i386-2008-10-05 Hmm, I tried it a few days ago and it worked fine for me. What kind of error are you seeing? Regards, -- Rink P.W. Springer- http://rink.nu Anyway boys, this is America. Just because you get more votes doesn't mean you win. - Fox Mulder ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.1 i386 PXE
Jeremy Chadwick wrote: Dmitriy Kirhlarov wrote: I tryin update my install server. Look like 7.1 i386 pxe boot broken. My own release build is 7.1-i386-2008-10-05 Could somebody test this functionality and confirm or disprove my results. What's broken about it? What behaviour happens? Are you aware of the mfsroot bug (see step 7 below): http://jdc.parodius.com/freebsd/pxeboot_serial_install.html It is a problem with memory management in the boot loader. I hit exactly the same problem during my experiments with the graphical boot loader, even without PXE and mfsroot involved. The problem is that the btx client breaks and behaves erratically when it runs out of memory. By default it can only use a part of the lower 640 KB of RAM, which isn't very much, given that the loader binary itself is already 250 KB, and the gzip decompressor requires quite some temporary memory for its dictionary. Unfortunately, debugging these things in the boot loader isn't exactly trivial. You can't just load it into gdb and single step it. If you want to boot via PXE but still use a gzipped mfs- root, a workaround is to skip loader.4th and beastie.4th, and instead boot the kernel directly from loader.rc. This should save enough memory to get you through. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a God to make them do anything useful. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problem with dump stalling
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Gary Palmer Sent: 09 October 2008 05:36 PM To: David Peall Cc: freebsd-stable@freebsd.org; Jeremy Chadwick; Christoph Schug Subject: Re: Problem with dump stalling -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Jeremy Chadwick Sent: 09 October 2008 12:45 PM To: Christoph Schug Cc: freebsd-stable@freebsd.org; David Peall Subject: Re: Problem with dump stalling David, can you verify you're using a version of src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? If so, the problem David is experiencing is different. If not, David will need to csup and then rebuild world and kernel (do NOT just do one; do both) to pick up the changes. Try running: ident /boot/kernel/kernel | grep subr_sleepqueue Thank you Gary: $FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39.4.1 2008/01/29 16:37:04 jhb Exp $ Which is indeed newer that 1.39.2.3 and dump on UFS2 is still a problem. -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Userland PPP not deleting old IP on disconnect
On Thu, 9 Oct 2008, Andrew D wrote: Hi Fellow Node user :), I have the same + similar issue. Daniel O'Connor wrote: Hi, I am using userland PPP to do PPPoE and I am finding that it isn't deleting the old IP from tun0 when the link goes down, eg Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: logout - hangup Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: Connect time: 950 secs: 2711068 octets in, 39993514 octets out [midget 22:00] ~ ifconfig tun0 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1500 inet 121.45.251.180 -- 203.16.215.184 netmask 0x Opened by PID 53728 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492 inet 121.45.215.128 -- 203.16.215.183 netmask 0x inet 121.45.69.26 -- 203.16.215.186 netmask 0x Opened by PID 90863 The second line only shows up when the gateway is different between IP assignments from the ISP. I have no idea if this blocks access to the previous IP, not that it's a major issue. I wouldn't care too much except that ddclient looks at tun0 to find the IP to report to dyndns and gets the wrong one.. -- 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 signature.asc Description: This is a digitally signed message part.
Re: sidetrack [was Re: 'at now' not working as expected]
On Thu, Oct 9, 2008 at 4:19 AM, Andrew D [EMAIL PROTECTED] wrote: Hi Ian, Ian Smith wrote: On Wed, 8 Oct 2008, Peter Wemm wrote: [..] My tolerance for hacking at(1) code was exceeded when I added hacks for 'at sunrise' and 'at sunset' support to a local version. It wasn't pretty, especially when handling things like '30 minutes before sunrise' etc. (I use this for home automation stuff) Peter, just curious .. from where do you pull the current sunrise/sunset info for your location, and in what form? In Australia, you get it from Geoscience Australia. http://www.ga.gov.au/geodesy/astro/sunrise.jsp Just need a few curl queries and then extract the required info from the html source :) I just calculate it from my lat/lon. Its not particularly hard. I found a bunch of massively over-complicated code examples (mostly in javascript, or worse) that usually was GPL'ed. I ended up finding the original public domain code that was written in basic and did a simple conversion of that. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sidetrack [was Re: 'at now' not working as expected]
Also, if you happen to have a handheld GPS unit, it almost certainly has a menu option to tell you the sunrise and sunset times at your current position. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sidetrack [was Re: 'at now' not working as expected]
Matthew Dillon wrote: Also, if you happen to have a handheld GPS unit, it almost certainly has a menu option to tell you the sunrise and sunset times at your current position. The attached program (not mine - credits in the header) does this effectively given your current position as input, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sidetrack [was Re: 'at now' not working as expected]
I wrote:
The attached program (not mine - credits in the header) does this
effectively given your current position as input,
Inserted as text since it got stripped last time ..
/*
SUNRISET.C - computes Sun rise/set times, start/end of twilight, and
the length of the day at any date and latitude
Written as DAYLEN.C, 1989-08-16
Modified to SUNRISET.C, 1992-12-01
(c) Paul Schlyter, 1989, 1992
This program may be used by anyone for any purpose, iff:
1. it is not being sold for profit
2. this notice is not removed
*/
#include stdio.h
#include math.h
/* A macro to compute the number of days elapsed since 2000 Jan 0.0 */
/* (which is equal to 1999 Dec 31, 0h UT) */
#define days_since_2000_Jan_0(y,m,d) \
(367L*(y)-((7*((y)+(((m)+9)/12)))/4)+((275*(m))/9)+(d)-730530L)
/* Some conversion factors between radians and degrees */
#ifndef PI
#define PI3.1415926535897932384
#endif
#define RADEG ( 180.0 / PI )
#define DEGRAD( PI / 180.0 )
/* The trigonometric functions in degrees */
#define sind(x) sin((x)*DEGRAD)
#define cosd(x) cos((x)*DEGRAD)
#define tand(x) tan((x)*DEGRAD)
#define atand(x)(RADEG*atan(x))
#define asind(x)(RADEG*asin(x))
#define acosd(x)(RADEG*acos(x))
#define atan2d(y,x) (RADEG*atan2(y,x))
/* Following are some macros around the workhorse function __daylen__ */
/* They mainly fill in the desired values for the reference altitude*/
/* below the horizon, and also selects whether this altitude should */
/* refer to the Sun's center or its upper limb. */
/* This macro computes the length of the day, from sunrise to sunset. */
/* Sunrise/set is considered to occur when the Sun's upper limb is */
/* 35 arc minutes below the horizon (this accounts for the refraction */
/* of the Earth's atmosphere). */
#define day_length(year,month,day,lon,lat) \
__daylen__( year, month, day, lon, lat, -35.0/60.0, 1 )
/* This macro computes the length of the day, including civil twilight. */
/* Civil twilight starts/ends when the Sun's center is 6 degrees below */
/* the horizon. */
#define day_civil_twilight_length(year,month,day,lon,lat) \
__daylen__( year, month, day, lon, lat, -6.0, 0 )
/* This macro computes the length of the day, incl. nautical twilight. */
/* Nautical twilight starts/ends when the Sun's center is 12 degrees*/
/* below the horizon. */
#define day_nautical_twilight_length(year,month,day,lon,lat) \
__daylen__( year, month, day, lon, lat, -12.0, 0 )
/* This macro computes the length of the day, incl. astronomical
twilight. */
/* Astronomical twilight starts/ends when the Sun's center is 18 degrees
*/
/* below the horizon.*/
#define day_astronomical_twilight_length(year,month,day,lon,lat) \
__daylen__( year, month, day, lon, lat, -18.0, 0 )
/* This macro computes times for sunrise/sunset. */
/* Sunrise/set is considered to occur when the Sun's upper limb is */
/* 35 arc minutes below the horizon (this accounts for the refraction */
/* of the Earth's atmosphere). */
#define sun_rise_set(year,month,day,lon,lat,rise,set) \
__sunriset__( year, month, day, lon, lat, -35.0/60.0, 1, rise, set )
/* This macro computes the start and end times of civil twilight. */
/* Civil twilight starts/ends when the Sun's center is 6 degrees below */
/* the horizon. */
#define civil_twilight(year,month,day,lon,lat,start,end) \
__sunriset__( year, month, day, lon, lat, -6.0, 0, start, end )
/* This macro computes the start and end times of nautical twilight.*/
/* Nautical twilight starts/ends when the Sun's center is 12 degrees*/
/* below the horizon. */
#define nautical_twilight(year,month,day,lon,lat,start,end) \
__sunriset__( year, month, day, lon, lat, -12.0, 0, start, end )
/* This macro computes the start and end times of astronomical twilight.
*/
/* Astronomical twilight starts/ends when the Sun's center is 18 degrees
*/
/* below the horizon.*/
#define astronomical_twilight(year,month,day,lon,lat,start,end) \
__sunriset__( year, month, day, lon, lat, -18.0, 0, start, end )
/* Function prototypes */
double
__daylen__ (int year, int month, int day, double lon, double lat,
double altit, int upper_limb);
int
__sunriset__ (int year, int month, int day, double lon, double lat,
double altit, int upper_limb, double *rise, double *set);
void sunpos (double d, double *lon, double *r);
void sun_RA_dec (double d, double *RA, double *dec, double *r);
double revolution (double x);
double rev180 (double x);
double GMST0 (double d);
/* A small test program */
void
main (void)
{
int year, month, day;
double lon, lat;
double daylen, civlen, nautlen, astrlen;
double rise, set, civ_start, civ_end, naut_start, naut_end, astr_start,
astr_end;
int rs, civ, naut, astr;
Re: Userland PPP not deleting old IP on disconnect
At 08:22 AM 10/9/2008, Andrew D wrote: Hi Fellow Node user :), I have the same + similar issue. Hi, What about adding disable iface-alias iface-alias Default: Enabled if -nat is specified. This option simply tells ppp to add new interface addresses to the interface rather than replacing them. The option can only be enabled if network address translation is enabled (``nat enable yes''). With this option enabled, ppp will pass traffic for old interface addresses through the NAT engine (see libalias(3)), resulting in the ability (in -auto mode) to properly connect the process that caused the PPP link to come up in the first place. Disabling NAT with ``nat enable no'' will also disable `iface-alias'. Daniel O'Connor wrote: Hi, I am using userland PPP to do PPPoE and I am finding that it isn't deleting the old IP from tun0 when the link goes down, eg Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: logout - hangup Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: Connect time: 950 secs: 2711068 octets in, 39993514 octets out [midget 22:00] ~ ifconfig tun0 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1500 inet 121.45.251.180 -- 203.16.215.184 netmask 0x Opened by PID 53728 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492 inet 121.45.215.128 -- 203.16.215.183 netmask 0x inet 121.45.69.26 -- 203.16.215.186 netmask 0x Opened by PID 90863 The second line only shows up when the gateway is different between IP assignments from the ISP. I have no idea if this blocks access to the previous IP, not that it's a major issue. uname -a FreeBSD gateway.abdulla 7.0-STABLE FreeBSD 7.0-STABLE #1: Sat Jun 21 03:10:37 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERN i386 My ppp setup is almost the same. Cheers cya Andrew I have the following config.. default: set device /dev/cuaa0 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ AT \ OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT set speed 115200 set ctsrts on set server /var/run/ppp/tun%d foobar set urgent tcp 22 set urgent udp 27010 27011 27012 27013 27014 27015 27016 27017 27018 27019 27020 27960 14577 14578 14579 14580 set log Phase Chat IPCP CCP tun command connect internode: set device PPPoE:em0 set ifaddr 0.0.0.0/0 0.0.0.0/0 resolv readonly disable pap enable dns set cd 5 set dial set login set redial 5+30-120 0 enable lqr enable echo set lqrperiod 3 set reconnect 10 10 set authname username set authkey password add default HISADDR I don't have any linkup/linkdown scripts.. Any one have an idea why this would be happening? System is a FreeBSD midget.dons.net.au 7.0-STABLE FreeBSD 7.0-STABLE #1: Sun Jun 1 19:20:18 CST 2008 [EMAIL PROTECTED]:/data/obj/data/src/sys/GENERIC i386 Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Userland PPP not deleting old IP on disconnect
On Fri, 10 Oct 2008, Mike Tancsa wrote: At 08:22 AM 10/9/2008, Andrew D wrote: Hi Fellow Node user :), I have the same + similar issue. What about adding disable iface-alias iface-alias Default: Enabled if -nat is specified. This option simply tells ppp to add new interface addresses to the interface rather than replacing them. The option can only be enabled if network address translation is enabled (``nat enable yes''). I've added that and nat enable no (even though it was not enabled) and I'll see how I go. -- 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 signature.asc Description: This is a digitally signed message part.
Re: can not wake on lan after halt -p (or shutdown -p now) on releng_7 and releng_7_0
On Mon, Oct 06, 2008 at 06:13:34PM +0300, Georgi Iovchev wrote: Hello list I have a shutdown problem. I have a machine with gigabyte GA-G33M-DS2R motherboard. Integrated network card is Realtek 8111B. I can not wake the computer after I shutdown it from FreeBSD. It is a dualboot system - windows xp and freebsd. If I shutdown the computer from windows - later I can wake it up with magic packet. Even if i shutdown the machine on the boot menu with the power button - than later I can wake on lan. The only situation where I CANNOT wake it is when I shutdown the machine from freebsd (halt -p). First I tested with 7.0-RELEASE-p5 amd64 (RELENG_7_0) and than I upgraded to 7.1 PRERELASE amd64 (RELENG_7). I also tested with two network cards - the integrated one Realtek 8111B and another one Intel PRO1000PT PCI-E with WOL enabled. Don't know WOL issue of em(4) but re(4) should respond to WOL. 7.0-RELEASE had no support for WOL so RELENG_7 or 7.1-PRERELEASE should be used to experiment WOL. With both nics and both freebsd versions the situation is the same - after shutdown from bsd the computer is not able to wake on lan. The Because you can wake up your sytem from Windows shutdown I think your BIOS is already configured to allow wakeup from WOL. Would you compare ethernet address of re(4) to Winwods? Have you tried to send Magic packets to FreeBSD box? You may also try suspend your box with acpiconf and resume from WOL. indication on the switch port says that after shut down there is active link. That indicates the controller is alive so it shall respond to WOL if it was correctly configured to receive WOL packets. Have you tried to send Magic packets to FreeBSD box? Here is some information after last update: [EMAIL PROTECTED] ~]# uname -a FreeBSD backup.pulsar.bg 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Mon Oct 6 17:01:26 EEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYCONF amd64 [EMAIL PROTECTED] ~]# pciconf -lv ... [EMAIL PROTECTED]:3:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet ... Show me dmesg output pertinent to re(4). -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can not wake on lan after halt -p (or shutdown -p now) on releng_7 and releng_7_0
On Mon, 6 Oct 2008, Georgi Iovchev wrote: I have a shutdown problem. I have a machine with gigabyte GA-G33M-DS2R motherboard. Integrated network card is Realtek 8111B. I can not wake the computer after I shutdown it from FreeBSD. It is a dualboot system - windows xp and freebsd. If I shutdown the computer from windows - later I can wake it up with magic packet. Even if i shutdown the machine on the boot menu with the power button - than later I can wake on lan. The only situation where I CANNOT wake it is when I shutdown the machine from freebsd (halt -p). First I tested with 7.0-RELEASE-p5 amd64 (RELENG_7_0) and than I upgraded to 7.1 PRERELASE amd64 (RELENG_7). I also tested with two network cards - the integrated one Realtek 8111B and another one Intel PRO1000PT PCI-E with WOL enabled. With both nics and both freebsd versions the situation is the same - after shutdown from bsd the computer is not able to wake on lan. The indication on the switch port says that after shut down there is active link. I have a similar problem with an Intel SR1200 Pentium 3-class system, using fxp(4) cards, although I haven't yet tried the `halt -p` command. I was discussing WoL with a colleague recently and he suggested that on some Linux systems he needed to use `ethtool -s eth0 wol g` on every boot to maintain the WoL status. From the ethtool(1) manpage: wol p|u|m|b|a|g|s|d... Set Wake-on-LAN options. Not all devices support this. g Wake on MagicPacket(tm) From my reading, this might be necessary if the driver clears the flag during initialisation of the card. kern/83807 was filed to fix this issue for sis(4), but was never committed. However, work is apparently being done in 8-CURRENT to support exposing the WoL settings to ifconfig: see http://wiki.freebsd.org/WakeOnLan . Until that work lands in a release, I think we're out of luck. (Another administrator has also suggested that, on Linux at least, using the 'ifdown' command will destroy WoL status, but I don't think that's an issue here.) Hope that helps. I'm sure any contributions to the effort to add driver support will be appreciated. David Adam [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with dump stalling
On Fri, Oct 10, 2008 at 12:14:09AM +0200, David Peall wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Gary Palmer Sent: 09 October 2008 05:36 PM To: David Peall Cc: freebsd-stable@freebsd.org; Jeremy Chadwick; Christoph Schug Subject: Re: Problem with dump stalling -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Jeremy Chadwick Sent: 09 October 2008 12:45 PM To: Christoph Schug Cc: freebsd-stable@freebsd.org; David Peall Subject: Re: Problem with dump stalling David, can you verify you're using a version of src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? If so, the problem David is experiencing is different. If not, David will need to csup and then rebuild world and kernel (do NOT just do one; do both) to pick up the changes. Try running: ident /boot/kernel/kernel | grep subr_sleepqueue Thank you Gary: $FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39.4.1 2008/01/29 16:37:04 jhb Exp $ Which is indeed newer that 1.39.2.3 and dump on UFS2 is still a problem. Okay wait a minute here. We can't go purely off of the version number, because the version numbers differ per tag (HEAD/CURRENT, RELENG_7, RELENG_7_0, and so on). 1.39.2.3 was committed to RELENG_7 on 2008/04/19. The timestamp shown for you src/sys/kern/subr_sleepqueue.c is 2008/01/29. So I would say you **do not** have the fix. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
